Системы мониторинга и контроля целостности данных: файлов, папок, баз данных
Выбор средств защиты
Поиск
Мнение
Алексей Булихов
Задать вопрос
Описание и назначение
Средства контроля целостности данных применяются для контроля информационных ресурсов, файлов, каталогов и папок, при котором обеспечивается их неизменность, защита от модификации и искажения, на протяжении всего жизненного цикла. Этот параметр является критическим аспектом проектирования, реализации и использования любой информационной системы, которая хранит, обрабатывает или извлекает данные.
Главная цель обеспечения целостности данных заключается в том, чтобы информация изменялась только запланированным образом, а также сохранялась неизменной при следующем обращении, или, другими словами, была защищена от несанкционированных действий. Любые непреднамеренные изменения данных, возникающие в результате операций хранения, извлечения или обработки, включая воздействия вредоносных программ, неожиданный отказ оборудования или человеческий фактор — приводят к ошибкам целостности данных.
В информационных системах целостность данных, которые не отправляются за пределы системы, обеспечивается за счет отказоустойчивости и возможности восстановления данных, например, из резервных копий. В случае отправки файлов во внешние информационные системы могут применяться криптографические методы защиты информации, такие как:
Шифрование. Этот метод не может обеспечить полную защиту данных от модификации, из-за чего наравне с шифрованием применяют и другие методы обеспечения целостности данных. При передаче шифрованных данных может возникнуть ситуация, при которой могут быть удалены некоторые биты информации, изменен порядок их следования или злоумышленниками добавлены новые биты данных. Чтобы избежать этого, в криптографии применяется метод имитовставки, когда к шифрованным данным добавляется некоторое количество избыточной информации. Это позволяет снизить возможность расшифрования данных злоумышленниками.
Хэширование. Данный метод подразумевается преобразование данных с применением хэш-функции или определенного алгоритма в строку определенной длины. Особенностью хэширования является изменение всей строки, в случае даже минимального изменения входных данных.
Электронная подпись. В общем смысле электронную подпись относят к реквизитам электронных документов, при этом она обеспечивает юридическую значимость документа и его целостность за счет применения криптографического преобразования. Чтобы подписать документ электронной подписью, необходимо использовать закрытый ключ, который хранится у владельца электронной подписи. При этом электронная подпись позволяет проверить данные на наличие возможных несанкционированных изменений, а также авторство документа и неотказуемость.
Обеспечение целостности данных также является одной из функций средств защиты информации от несанкционированного доступа. Эти средства защиты производят отслеживание неизменности данных в автоматическом режиме по заранее настроенному расписанию. При этом помимо неизменности самих файлов, средства защиты могут проверять неизменность прав доступа к объектам и их атрибутов. В случае выявления ошибок при прохождении процедуры контроля целостности, средства защиты от несанкционированного доступа могут сигнализировать об этом администраторам безопасности, запрещать доступ в систему, сохранять изменения в файлах или откатывать ресурсы до первоначального состояния. При этом средства защиты от несанкционированного доступа предоставляют следующие алгоритмы проверки целостности данных: электронно-цифровая подпись (проверяется встроенная цифровая подпись данных), CRC32 (или расчет контрольных сумм файлов), хэш, имитовставка, полное совпадение.
Источник: www.anti-malware.ru
8.2. Контроль достоверности данных
Основная задача контроля достоверности данных состоит в определении местоположения искаженных данных и их исправлении. Различают три типа контроля достоверности: синтаксический, семантический, прагматический.
Синтаксический контроль обеспечивает проверку типа полей, наличие запрещенных символов, порядка следования реквизитов. Выполняется на основе описания входных документов.
Семантический контроль проверяет логические взаимосвязи значений реквизитов, непротиворечивость данных и их согласованность (например, при учете личного состава работающих предприятия, файл «Кадры» может проверяться на непротиворечивость таких реквизитов, как «почетное звание «ветеран труда» и «стаж работы < 20 лет»).
Прагматический контроль проверяет плотность, своевременность, полноту данных, предоставляемых для принятия решений. Выполняется на основе выходных документов.
Достоверность данных контролируется на всех этапах технологического процесса. Различают визуальные и программные методы контроля.
Визуальный контроль выполняется на домашинном и заключительном этапах.
Программный – на внутримашинном этапе. При этом обязателен контроль ввода данных, корректировки и любой другой операции, связанный с вмешательством пользователя в вычислительный процесс.
Программные методы контроля могут проверять отдельный реквизит, запись, группу записей, файл.
Отдельный реквизит проверяется методом предельных значений, для выполнения которого указываются нижняя и верхняя границы значений, с которыми производится сравнение. Отдельный реквизит может проверяться также методом смысловых проверок, который используется там, где можно написать формулу для контроля (например, сумма, количество, цена). И еще для проверки реквизита применяется метод контроля по списку допустимых значений (применяется в основном для реквизитов-признаков). Отдельно создается список допустимых кодов и, когда вводится признак, он сравнивается с этим списком. Недостаток этого метода заключается в том, что надо хранить и актуализировать список кодов.
При контроле записи применяют балансовый контроль и дублирование. При балансовом контроле подсчитывается контрольная сумма группы записей или всего файла, вводится в ЭВМ и программно сравнивается с автоматически подсчитанной на ЭВМ суммой.
Контроль группы записей и файла осуществляется в основном балансовым методом.
Защита данных от несанкционированного доступа, копирования, изменения реализуется программно-аппаратными методами и технологическими приемами. К программно-аппаратным средствам защиты относятся пароли, электронные идентификаторы, средства кодирования-декодирования данных.
Для кодирования, декодирования данных, программ и электронной подписи используются криптографические методы. Например, в США применяется криптографический стандарт, разработанный группой IETF. Экспорту она не подлежит. В нашей стране разработаны электронные ключи, например Novex Key, для защиты программ и данных в Windows.
Технологический контроль заключается в организации многоуровневой системы защиты программ и данных как средствами проверки паролей, электронных ключей, меток файла, использования программных продуктов, удовлетворяющих требованиям компьютерной безопасности, так и методами визуального и программного контроля достоверности, целостности, полноты данных. Технология защиты является многоуровневой и содержит следующие этапы:
- Входной контроль нового ПО или дискеты. Осуществляется группой специально подобранных детекторов, ревизоров и фильтров. Например, в состав группы можно включить SCAN AIDTEST TRU
- обучение персонала технологии защиты;
- обеспечение физической безопасности компьютера и магнитных носителей;
- выработка правил архивация;
- хранение отдельных файлов в шифрованном виде;
- создание и отработка плана восстановления винчестера и испорченной информации.
Как проверить контрольную сумму скачанного файла архива или образа. Как проверить хэш файла.
Проверка целостности файлов при передаче. Хеш-сумма
Источник: studfile.net
Целостность и подлинность передаваемой информации
Международное признание для защиты передаваемых сообщений получила программная система PGP (Pretty Good Privacy — очень высокая секретность), разработанная в США и объединяющая асимметричные и симметричные шифры. Являясь самой популярной программной криптосистемой в мире, PGP реализована для множества операционных сред — MS DOS, Windows 95, Windows NT, OS/2, UNIX, Linux, Mac OS, Amiga, Atari и др.
| № п/п | Средство | Назначение средства (область применения) | Тип средства |
| Снег (версия 1.0) | Система защиты информации от несанкционированного доступа для ПЭВМ IBM PC XT/AT. В нее входит СКЗД «Иней» | ПА | |
| Снег-ЛВС | Система защиты информации от несанкционированного доступа в локальных вычислительных сетях. В нее входит СКЗД «Иней» | ПА | |
| Кобра | Система защиты информации от несанкционированного доступа для ПЭВМ по четвертому классу защищенности средств вычислительной техники | П | |
| Страж (версия 1.1) | Программный комплекс защиты информации от несанкционированного доступа для ПЭВМ по второму классу защищенности средств вычислительной техники | П | |
| Марс | Комплекс программных средств защиты от несанкционированного доступа для персонального компьютера по третьему классу защищенности средств вычислительной техники | П | |
| Кютак-С | Автоматизированный программно-аппаратный комплекс по управлению и расчетам автозаправочных предприятий | ПА | |
| Сизам | Система защиты информации от несанкционированного доступа в локальных вычислительных сетях по классу защищенности 1Д (локальные вычислительные сети) и шестому классу защищенности от несанкционированного доступа | П | |
| DALLAS LOCK (версия 3.1) | Программно-аппаратный комплекс защиты от несанкционированного доступа и обработки конфиденциальной информации | ПА | |
| SECRET NET (версия 1.10) | Система защиты (включая ее локальную версию) по шестому классу защищенности для средств вычислительной техники | ПА | |
| СНЕГ 2.0 | Программное средство защиты информации от несанкционированного доступа в автоматизированных системах на базе автономной ПЭВМ с ОС MS DOS версий 5.0 и 6.22 по классу защищенности 1Б; по классу защищенности 2 — в сертифицированных средствах вычислительной техники | П |
Продолжение табл. 5.2
Продолжение табл. 5.2
Продолжение табл. 5.1
Примечание: П — программное средство; ПА — программно-аппаратное средство.
CASE-ТЕХНОЛОГИИ
На данный момент в технологии разработки программного обеспечения существуют два основных подхода к разработке информационных систем, отличающиеся критериями декомпозиции: функционально-модульный (структурный) и объектно-ориентированный.
Функционально-модульный подход основан на принципе алгоритмической декомпозиции с выделением функциональных элементов и установлением строгого порядка выполняемых действий.
Объектно-ориентированный подход основан на объектной декомпозиции с описанием поведения системы в терминах взаимодействия объектов.
Главным недостатком функционально-модульного подхода является однонаправленность информационных потоков и недостаточная обратная связь. В случае изменения требований к системе это приводит к полному перепроектированию, поэтому ошибки, заложенные на ранних этапах, сильно сказываются на продолжительности и стоимости разработки. Другой важной проблемой является неоднородность информационных ресурсов, используемых в большинстве информационных систем. В силу этих причин в настоящее время наибольшее распространение получил объектно-ориентированный подход.
Под CASE-технологией будем понимать комплекс программных средств, поддерживающих процессы создания и сопровождения программного обеспечения, включая анализ и формулировку требований, проектирование, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом (CASE-средство может обеспечивать поддержку только в заданных функциональных областях или в широком диапазоне функциональных областей) [5].
В связи с наличием двух подходов к проектированию программного обеспечения существуют CASE-технологии ориентированные на структурный подход, объектно-ориентированный подход, а также комбинированные. Однако сейчас наблюдается тенденция переориентации инструментальных средств, созданных для структурных методов разработки, на объектно-ориентированные методы, что объясняется следующими причинами:
• возможностью сборки программной системы из готовых компонентов, которые можно использовать повторно;
• возможностью накопления проектных решений в виде библиотек классов на основе механизмов наследования;
• простотой внесения изменений в проекты за счет инкапсуляции данных в объектах;
• быстрой адаптацией приложений к изменяющимся условиям за счет использования свойств наследования и полиформизма;
• возможностью организации параллельной работы аналитиков, проектировщиков и программистов.
Рассмотренные ранее (см. подразд. 3.1) концепции объектно-ориентированного подхода и распределенных вычислений стали базой для создания консорциума Object Management Group (OMG), членами которой являются более 500 ведущих компьютерных компаний (Sun, DEC, IBM, HP, Motorola и др.). Основным направлением деятельности консорциума является разработка спецификаций и стандартов для создания распределенных объектных систем в разнородных средах. Базисом стали спецификации под названием Object Management Architecture (ОМА).
ОМА состоит из четырех основных компонентов, представляющих спецификации различных уровней поддержки приложений (рис. 5.10):
• архитектура брокера запросов объектов (CORBA — Common Object Request Broker Architecture) определяет механизмы взаимодействия объектов в разнородной сети;
• объектные сервисы (Object Services) являются основными системными сервисами, используемыми разработчиками для создания приложений;
• универсальные средства (Common Facilities) являются высокоуровневыми системными сервисами, ориентированными на поддержку пользовательских приложений (электронная почта, средства печати и др.);
• прикладные объекты (Application Object) предназначены для решения конкретных прикладных задач.
Исходя из основных положений объектно-ориентированного подхода рассмотрим концепцию идеального объектно-ориентированного CASE-средства.
Существует несколько объектно-ориентированных методов, авторами наиболее распространенных из них являются Г.Буч, Д.Рам-бо, И.Джекобсон. В настоящее время наблюдается процесс сближения объектно-ориентированных методов. В частности, указанные выше авторы создали и выпустили несколько версий унифицированного метода UML (Unified Modeling Language — унифицированный язык моделирования).
Классическая постановка задачи разработки программной системы (инжиниринг) представляет собой спиральный цикл итеративного чередования этапов объектно-ориентированного анализа, проектирования и реализации (программирования).
В реальной практике в большинстве случаев имеется предыстория в виде совокупности разработанных и внедренных программ, которые целесообразно использовать при разработке новой системы. Процесс проектирования в таком случае основан на реинжиниринге программных кодов, при котором путем анализа текстов программ восстанавливается исходная модель программной системы.
Современные CASE-средства поддерживают процессы инжиниринга и автоматизированного реинжиниринга.
| Анализ | Проектирование | Реализация | |
| Возможность Возможность добавлять создавать пояснительные различные надписи представления к диаграммам и скрывать и в докумеп- ненужные тацию в данный момент слои системы | Возможность просматривать и выбирать элементы и бизнес-объекты для использования в системе | Возможность генерировать заготовки программного кода на нескольких объектно-ориентированных языках | |
| Среда для создания диаграмм разнообразных моделей | Возможность создания пользовательского интерфейса (поддержка OLE, ActiveX, OpenDoc, HTML) | Возможность проверки кода на синтаксическую корректность | |
| Поддержка различных нотаций | Возможность динамического моделирования событий в системе | Возможности определения бизнес-модели и бизнес-правил | Возможность генерировать код для 4GL и клиент-серверных продуктов (PowerBuilder, Forte, VisualAge, VisualWorks) |
| Возможность генерации документации для печати | Возможность динамической коррекции одной диаграммы из другой | Возможность связи с объектно-ориентированными базами данных и распределенными модулями(поддержка COBRA, DCOM, ПОР, HTML) | |
| Инфраструктура | |||
| Контроль версий. Блокирование и согласование частей системы при групповой разработке | Репозиторий | Возможность реинжиниринга программного кода, 4GL, клиент-серверных систем в диаграммы моделей |
Рис. 5.11. Идеальное объектно-ориентированное CASE-средство
Идеальное объектно-ориентированное CASE-средство (рис. 5.11) должно содержать четыре основных блока: анализ, проектирование, разработка и инфраструктура [34].
Основные требования к блоку анализа: 116
• возможность выбора выводимой на экран информации из всей совокупности данных, описывающих модели;
• согласованность диаграмм при хранении их в репозитарии;
• внесение комментариев в диаграммы и соответствующую документацию для фиксации проектных решений;
• возможность динамического моделирования в терминах событий;
• поддержка нескольких нотаций (хотя бы три нотации — Г.Буча, И.Джекобсона и ОМТ).
Основные требования к блоку проектирования:
• поддержка всего процесса проектирования приложения;
• возможность работы с библиотеками, средствами поиска и выбора;
• возможность разработки пользовательского интерфейса;
• поддержка стандартов OLE, ActiveX и доступ к библиотекам HTML или Java;
• поддержка разработки распределенных или двух- и трех-звенных клиент-серверных систем (работа с CORBA, DCOM, Internet).
Основные требования к блоку реализации:
• генерация кода полностью из диаграмм;
• возможность доработки приложений в клиент-серверных CASE-средствах типа Power Builder;
• реинжиниринг кодов и внесение соответствующих изменений в модель системы;
• наличие средств контроля, которые позволяют выявлять несоответствие между диаграммами и генерируемыми кодами и обнаруживать ошибки как на стадии проектирования, так и на стадии реализации.
Основные требования к блоку инфраструктуры:
• наличие репозитория на основе базы данных, отвечающего за генерацию кода, реинжиниринг, отображение кода на диаграммах, а также обеспечивающего соответствие между моделями и программными кодами;
• обеспечение командной работы (многопользовательской работы и управление версиями) и реинжиниринга.
В табл. 5.3 приведен обзор наиболее распространенных объектно-ориентированных CASE-средств [34].
Т а б л н ц а 5.3
| № | Продукт, фир- | Поддержи- | Используе- | Генера- | Описание |
| п/п | ма-разработчик | ваемые | мые коды | ция кода | |
| платформы | |||||
| BridgePoint (вер- | Unix, | Шлеер/ | C/C++ | Поддержка полного | |
| сия 3.2.1), Project | SIG-Irix | Меллор | жизненного цикла в рам- | ||
| Tehnology | ках методики «Шлеер/ | ||||
| Меллор», генерация кода | |||||
| Grapical Designer | Unix, | Г. Буч, | C/C++ | Генерация кода и реин- | |
| (версия 2.0), | Windows NT | И.Джекоб- | жиниринг для каждого из | ||
| Advanced Software | Windows 95 | сон, ОМТ, | поддерживаемых языков | ||
| Technologies | Шлеер/ | и методологий. Команд- | |||
| Меллор, | ная работа. Возможность | ||||
| UML.08 и | создания собственной но- | ||||
| структур- | тации | ||||
| ная нотация | |||||
| LifeModel for | Unix, | Мартин/ | С | Средство является верх- | |
| OOOIE (версия | Windows NT | Оделл | ним уровнем фирменного | ||
| 1), InteliCorp | (OOIE) | продукта искусственного | |||
| интеллекта Карра. Прото- | |||||
| типирование в режиме ин- | |||||
| терпретатора, генерация | |||||
| кода, создание экранов и | |||||
| т.д. Возможность про- | |||||
| граммирования на С или | |||||
| на внутреннем script- язы- | |||||
| ке типа Prolog | |||||
| ObjectTime, | Unix | ROOM | с++ | Создание и визуализа- | |
| ObjectTime Ltd | ция исполняемых моде- | ||||
| лей систем реального | |||||
| времени на основе ОО- | |||||
| методологии реального | |||||
| времени (ROOM). Внут- | |||||
| ренний script-язык — | |||||
| подмножество «Smalltalk» | |||||
| Objectory (версия | Unix, OS/2, | И. Джекоб- | с++, | Два варианта: Analysis | |
| 3.7), Rational | DOS5, | сон | Small- | Workbench для ОО-ана- | |
| Software | Windows | talk | лиза и Design Workbench | ||
| 3.1, 95, NT | для проектирования. Связь | ||||
| с VisualWorks и C++ | |||||
| Softbench. BPR на основе | |||||
| метода Джекобсона. Так | |||||
| как Objectory перешло к | |||||
| Rational, то неизвестно, | |||||
| как долго еще продукт бу- | |||||
| дет поддерживаться | |||||
| ObjectPartner | Unix | ОМТ | C++ | Распространяет Verilog, | |
| (версия 2.0), | а также Logiscope и Object- | ||||
| Verilog | Geode |
Продолжение табл. 5.3
| N° п/п | Продукт, фирма-разработчик | Поддерживаемые платформы | Используемые коды | Генерация кода | Описание |
| ObjectTeamEnter-prise (версия 1) Cayenne Software | Unix | OMT | C++ | Cayenne объединяет Cadre и Bachman technlology. Пользователям ObjectTeam (метод Шлеер/Меллор) предлагается обратиться к продуктам BridgePoint | |
| ObjectMaker (версия 4.2, 1995) MarkV | Unix, Windows 3.1,95, NT | 15 нотаций, в частности: Г. Буч, ОМТ, Шле-ер/Меллор, Код/Йор-дон и др. | Ada ’83, ’95, C/C++, Smalltalk | Общий репозиторий в сети, командная работа. Есть локальный продукт ObjectMaker Consulant | |
| Paradigm Plus (версия 3.0) Platinum Technology (formerly Protosoft) | Unix, OS/2, Windows 3.1, 95, NT | 8 нотаций, в частности: Г. Буч, ОМТ, Шле-ер/Меллор, Fusion и т.д. | Ada, C/C++, Smalltalk, Java | Генерация SQL, 00 и реляционные БД. Реинжиниринг для Forte, PowerBuilder, VisualWorks, Visual Smalltalk Enterprise, VisualAge, ObjectPro. Object-Store. OODB в качестве репозитория | |
| Ptech (версия 4.0), Ptech Inc. | Windows 95, NT, Unix | Мар-тин/Оделл (OOIE) | C++, Forte 2.0 | Интегрирован с Object-Store, Objectivity, ONTOS. Генерация кода для библиотек классов Tools.h++, USL | |
| Rational Rose (версия 3.0), Rational Software | Windows 3.1, 95, NT, UNIX (Solaris, HP UX, AIX) | Г.Буч, ОМТ | Ada, C++, Smalltalk, Visual Basic, Java, Forte SQL Windows, PowerBu ilder | Конвертация Буч/О МТ. Поддержка Java, COBRA. Реинжиниринг кода из Forte SQLWindows, PowerBuilder и ОО-языков. Объявлено о выпуске нового средства работы с COBRA. | |
| System Architect Object (версия 3.1), Popkin Software and System | Windows 3.1, OS/2 | Г. Буч, ОМТ, Шле-ер/Меллор, Код/Йор — дон, CRC, Л. Джекоб-сон | C++, Smalltalk, Java | Поддержка структурных методологий. BPR на основе IDEF-диаграмм. Связь с PowerBuilder |
Продолжение табл. 5.3
| N° п/п | Продукт, фирма-разработчик | Поддерживаемые платформы | Используемые коды | Генерация кода | Описание |
| Software through Pictures/OMT and BUCH (версия 3.2), Interactive Development Environments | Unix | OMT или Г. Буч, И.Джекоб-сон | C++, Smalltalk, Java и OMGI DL | Есть продукты для структурных методологий. CASE для BPR. Поддержка, Java, HTML, Netscape Navigator, COBRA, связь NetLinks Orbitaze, SNiFF+. Реинжиниринг | |
| SES/Objectbench (версия 2.2), Scientific and Engineering Software | Unix | ООА | C/C++ | Объектно-ориентированный анализ | |
| Together/C++, Object International | Windows 3. 1 | Код/Йор-дон | C++ | Версия для командной работы, работающая и под Windows 3.1 |
Сравнительный анализ CASE-систем показывает, что на сегодняшний день одним из наиболее приближенных к идеальному варианту CASE-средств является семейство Rational Rose фирмы Rational Software Corporation. Следует отметить, что именно здесь работают авторы унифицированного языка моделирования Г. Буч, Д. Рамбо и И. Джекобсон, под руководством которых ведется разработка нового CASE-средства, поддерживающего UML.
Выделим основные критерии оценки и выбора CASE-средств.
1. Функциональные характеристики:
• среда функционирования: проектная среда, программное обеспечение/технические средства, технологическая среда;
• функции, ориентированные на фазы жизненного цикла: моделирование, реализация, тестирование;
• общие функции: документирование, управление конфигурацией, управление проектом;
3. Простота использования;
7. Общие критерии (стоимость, затраты, эффект внедрения, характеристики поставщика).
Данные критерии подробно изложены в стандартах IEEE Std 1348—1995. IEEE recommended Practice for the Adoption of Computer — Aided Software Engineering (CASE) Tools и IEEE Std 1209—1992 Recommended Practice for the Evaluation and Selection of CASE Tools.
Источник: megalektsii.ru