Стандарты на создание систем защиты данных

Автор: Пользователь скрыл имя, 18 Февраля 2013 в 15:40, реферат

Краткое описание

При создании корпоративных ЭИС возрастает роль систем защиты данных. В силу большой сложности разрабатываемых систем защиты данных требуется их сертификация специализированными организациями на соответствие международным и национальным стандартам. В этом случае повышается эффективность и качество разрабатываемых систем защиты данных и возрастает степень доверия заказчиков к внедряемым ЭИС.

Файлы: 1 файл

ЛК 2 Проектирование процессов защиты данных.doc

— 90.50 Кб (Скачать)

Лекция 25. Стандарты на создание систем защиты данных

При создании корпоративных  ЭИС возрастает роль систем защиты данных. В силу большой сложности  разрабатываемых систем защиты данных требуется их сертификация специализированными  организациями на соответствие международным и национальным стандартам. В этом случае повышается эффективность и качество разрабатываемых систем защиты данных и возрастает степень доверия заказчиков к внедряемым ЭИС.

Основные понятия, требования, методы и средства проектирования и оценки системы информационной безопасности для ЭИС отражены в следующих основополагающих документах [12, 38-41]:

∙  "Оранжевая книга" Национального центра защиты компьютеров США (TCSEC);

∙  "Гармонизированные критерии Европейских стран (ITSEC)";

∙  Рекомендации X.800;

∙  Концепция защиты от НСД Госкомиссии при Президенте РФ.

Знание критериев оценки информационной безопасности, изложенных в этих документах, способно помочь проектировщикам при  выборе и комплектовании аппаратно-программной  конфигурации ЭИС. Кроме того, в процессе эксплуатации администратор системы защиты информации должен ориентироваться на действия сертифицирующих органов, поскольку обслуживаемая система, скорее всего время от времени будет претерпевать изменения и нужно, во-первых, оценивать целесообразность модификаций и их последствия, а, во-вторых, соответствующим образом корректировать технологию пользования и администрирования системой. При этом целесообразно знать, на что обращают внимание при сертификации поскольку это позволяет сконцентрироваться на анализе критически важных аспектов, повышая качество защиты.

Остановимся на кратком рассмотрении состава основных понятий и подходов к проектированию и оценке системы  защиты информации в ЭИС, изложенных в этих документах.

25.1. "Оранжевая книга" Национального центра защиты компьютеров США (TCSEC)

"Оранжевая книга"  √ это название документа,  который был впервые опубликован  в августе 1983 г. в Министерстве  обороны США. В этом документе  дается пояснение понятия "безопасной  системы", которая "управляет посредством соответствующих средств доступом к информации так, что только должным образом авторизованные лица или процессы, действующие от их имени, получают право читать, писать, создавать и удалять информацию". Очевидно, однако, что абсолютно безопасных систем не существует, и речь идет не о безопасных, а о надежных системах.

В "Оранжевой книге" надежная система определяется как "система, использующая достаточные аппаратные и программные средства, чтобы  обеспечить одновременную обработку  информации разной степени секретности группой пользователей без нарушения прав доступа". Степень доверия, или надежность проектируемой или используемой системы защиты или ее компонентов, оценивается по двум основным критериям:

1) концепция безопасносности;

2) гарантированность. 

25.2. Концепция безопасности системы  защиты 

Концепция безопасности разрабатываемой системы √ "это набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь имеет право оперировать с определенными наборами данных. Чем надежнее система, тем строже и многообразнее должна быть концепция безопасности. В зависимости от сформулированной концепции можно выбирать конкретные механизмы, обеспечивающие безопасность системы. Концепция безопасности √ это активный компонент защиты, включающий в себя анализ возможных угроз и выбор мер противодействия" [12 ].

Концепция безопасности разрабатываемой системы согласно "Оранжевой книге" должна включать в себя следующие элементы:

∙  произвольное управление доступом;

∙  безопасность повторного использования объектов;

∙  метки безопасности;

∙  принудительное управление доступом.

Рассмотрим содержание перечисленных  элементов.

1.1. Произвольное управление доступом √ это метод ограничения доступа к объектам, основанный на учете личности субъекта или группы, в которую субъект входит. Произвольность управления состоит в том, что некоторое лицо (обычно владелец объекта) может по своему усмотрению давать другим субъектам или отбирать у них права доступа к объекту.

С концептуальной точки  зрения текущее состояние прав доступа  при произвольном управлении описывается  матрицей, в строках которой перечислены  субъекты, а в столбцах √ объекты. В клетках, расположенных на пересечении строк и столбцов, записываются способы доступа, допустимые для субъекта по отношению к объекту (например, чтение, запись, выполнение, возможность передачи прав другим субъектам и т.п.).

Очевидно, прямолинейное  представление подобной матрицы невозможно, поскольку она очень велика и разрежена (т.е. большинство клеток в ней пусты). В операционных системах более компактное представление матрицы доступа основывается или на структурировании совокупности субъектов (например, владелец/группа/прочие), или на механизме списков управления доступом, т.е. на представлении матрицы по столбцам, когда для каждого объекта перечисляются субъекты вместе с их правами доступа. За счет использования метасимволов можно компактно описывать группы субъектов, удерживая тем самым размеры списков управления доступом в разумных рамках.

Большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом. Главное его  достоинство √ гибкость, главные  недостатки √ рассредоточенность управления и сложность централизованного контроля, а также оторванность прав доступа от данных, что позволяет копировать секретную информацию в общедоступные файлы.

1.2. Безопасность повторного использования объектов √ важное на практике дополнение средств управления доступом, предохраняющее от случайного или преднамеренного извлечения секретной информации из "мусора". Безопасность повторного использования должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т.п.), для дисковых блоков и магнитных носителей в целом.

1.3. Метки безопасности ассоциируются с субъектами и объектами для реализации принудительного управления доступом. Метка субъекта описывает его благонадежность, метка объекта √ степень закрытости содержащейся в нем информации.

Согласно "Оранжевой  книге" метки безопасности состоят  из двух частей √ уровня секретности  и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:

∙  совершенно секретно;

∙  секретно;

∙  конфиденциально;

∙  несекретно.

Главная проблема, которую  необходимо решать в связи с метками, √ это обеспечение их целостности. Во-первых, не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши. Во-вторых, при любых операциях с данными метки должны оставаться правильными.

Одним из средств обеспечения  целостности меток безопасности является разделение устройств на многоуровневые и одноуровневые. На многоуровневых устройствах может храниться информация разного уровня секретности (точнее, лежащая в определенном диапазоне уровней). Одноуровневое устройство можно рассматривать как вырожденный случай многоуровневого, когда допустимый диапазон состоит из одного уровня. Зная уровень устройства, система может решить, допустимо ли записывать на него информацию с определенной меткой. Например, попытка напечатать совершенно секретную информацию на принтере общего пользования с уровнем "несекретно" потерпит неудачу.

1.4. Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Этот способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов).

Субъект может читать информацию из объекта, если уровень  секретности субъекта не ниже, чем  у объекта, а все категории, перечисленные  в метке безопасности объекта, присутствуют в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Смысл сформулированного правила понятен: читать можно только то, что положено.

Субъект может записывать информацию в объект, если метка  безопасности объекта доминирует над  меткой субъекта. В частности, "конфиденциальный" субъект может писать в секретные файлы, но не может √ в несекретные (разумеется, должны также выполняться ограничения на набор категорий).

После того как зафиксированы  метки безопасности субъектов и  объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение "разрешить доступ к объекту X еще и для пользователя Y". Конечно, можно изменить метку безопасности пользователя Y, но тогда он, скорее всего, получит доступ ко многим дополнительным объектам, а не только к X.

Принудительное управление доступом реализовано во многих вариантах  операционных систем и СУБД, отличающихся повышенными мерами безопасности. Независимо от практического использования  принципы принудительного управления являются удобным методологическим базисом для начальной классификации информации и распределения прав доступа. Удобнее проектировать в терминах уровней секретности и категорий, чем заполнять неструктурированную матрицу доступа. На практике произвольное и принудительное управление доступом сочетается в рамках одной системы, что позволяет использовать сильные стороны обоих подходов.

Если понимать систему  безопасности узко, т.е. как правила  разграничения доступа, то механизм подотчетности является дополнением подобной системы. Цель подотчетности √ в каждый момент времени знать, кто работает в системе и что он делает. Средства подотчетности делятся на три категории:

∙  идентификация и аутентификация;

∙  предоставление надежного пути;

∙  анализ регистрационной информации.

Рассмотрим эти категории  подробнее.

Идентификация и аутентификация. Прежде чем получить право совершать какие-либо действия в системе каждый пользователь должен идентифицировать себя. Обычный способ идентификации √ ввод имени пользователя при входе в систему. В свою очередь система должна проверить подлинность личности пользователя, т.е. что он является именно тем, за кого себя выдает. Стандартное средство проверки подлинности (аутентификации) √ пароль, хотя в принципе могут использоваться также разного рода личные карточки, биометрические устройства (сканирование роговицы или отпечатков пальцев) или их комбинация.

Предоставление надежного пути. Надежный путь связывает пользователя непосредственно с надежной вычислительной базой, минуя другие, потенциально опасные компоненты системы. Цель предоставления надежного пути √ дать пользователю возможность убедиться в подлинности обслуживающей его системы.

Задача обеспечения  надежного пути становится чрезвычайно  сложной, если пользователь общается с интеллектуальным терминалом, персональным компьютером или рабочей станцией, поскольку трудно гарантировать, что пользователь общается с подлинной программой login, а не с "Троянским конем".

Анализ регистрационной информации √ аудит имеет дело с действиями (событиями), затрагивающими безопасность системы. К таким событиям относятся:

∙  вход в систему (успешный или нет);

∙  выход из системы;

∙  обращение к удаленной системе;

∙  операции с файлами (открыть, закрыть, переименовать, удалить);

∙  смена привилегий или иных атрибутов безопасности (режима доступа, уровня благонадежности пользователя и т.п.).

Полный перечень событий, потенциально подлежащих регистрации, зависит от избранной системы  безопасности и от специфики ЭИС. Протоколирование помогает следить за пользователями и реконструировать прошедшие события. Реконструкция событий позволяет проанализировать случаи нарушений, понять, почему они стали возможны, оценить размеры ущерба и принять меры по недопущению подобных нарушений в будущем. При протоколировании события записывается следующая информация:

∙  дата и время события;

∙  уникальный идентификатор пользователя √ инициатора действия;

∙  тип события;

∙  результат действия (успех или неудача);

∙  источник запроса (например, имя терминала);

∙  имена затронутых объектов (например, открываемых или удаляемых файлов);

∙  описание изменений, внесенных в базы данных защиты (например, новая метка безопасности объекта);

∙  метки безопасности субъектов и объектов события.

Необходимо подчеркнуть важность не только сбора информации, но и ее регулярного и целенаправленного анализа. В плане анализа выгодное положение занимают средства аудита СУБД, поскольку к регистрационной информации могут естественным образом применяться произвольные SQL-запросы. Следовательно, появляется возможность для выявления подозрительных действий применять сложные эвристики.

25.3. Гарантированность системы  защиты 

Гарантированность √ "мера доверия, которая может быть оказана архитектуре и реализации системы. Гарантированность может проистекать как из тестирования, так и из проверки (формальной или нет) общего замысла и исполнения системы в целом и ее компонентов. Гарантированность показывает, насколько корректны механизмы, отвечающие за проведение в жизнь выбранной концепции безопасности. Гарантированность можно считать пассивным компонентом защиты, надзирающим за самими защитниками" [12 ].

Гарантированность √  это мера уверенности, с которой  можно утверждать, что для проведения в жизнь сформулированной концепции  безопасности выбран подходящий набор средств и что каждое из этих средств правильно исполняет отведенную ему роль. В "Оранжевой книге" рассматриваются два вида гарантированности √ операционная и технологическая. Операционная гарантированность относится к архитектурным и реализационным аспектам системы, в то время как технологическая √ к методам построения и сопровождения.

2.1. Операционная гарантированность √ это способ убедиться в том, что архитектура системы и ее реализация действительно проводят в жизнь избранную концепцию безопасности и включает в себя проверку следующих элементов:

Информация о работе Стандарты на создание систем защиты данных