- •Безопасность вычислительных систем и сетей Учебное пособие
- •Раздел 1. Проектирование и оценка эффективности системы защиты информации 7
- •1.1. Основные понятия и базовые требования к средству защиты информации 7
- •Раздел 2. Проектирование системы защиты персональных данных 52
- •Раздел 3. Основополагающие методы обеспечения информационной безопасности 76
- •3.3. Разграничение доступа к ресурсам 98
- •3.4. Контроль целостности и аудит 163
- •3.5. Защита сети 168
- •3.6. Выводы по разделу 3 182
- •Раздел 1. Проектирование и оценка эффективности системы защиты информации
- •1.1. Основные понятия и базовые требования к средству защиты информации
- •1.1.1. Функциональная безопасность системного средства
- •1.1.1.1. Чем определяются требования к средствам защиты информации
- •1.1.1.2. Требования к достаточности набора механизмов защиты информации
- •1.1.1.2.1. Требования к защите конфиденциальной информации (к классу защищенности 1г)
- •1.1.1.2.2. Требования к защите секретной информации (к классу защищенности 1в)
- •1.1.1.3. Требования к корректности реализации механизмов защиты информации
- •1.1.2. Эксплуатационная безопасность системного средства
- •1.1.2.1. Основы теории надежности систем защиты информации. Основные понятия и определения
- •1.1.2.2. Оценка эксплуатационной безопасности современных ос
- •1.2. Построение системы защиты информации на основе выполения требований к достаточности набора механизмов защиты и корректности их реализации
- •1.3. Общий подход к проектированию системы защиты на основе оценки рисков
- •1.3.1. Общий подход к оценке эффективности системы защиты
- •1.3.2. Способы задания исходных параметров для оценки защищенности
- •1.3.3. Особенности проектирования системы защиты на основе оценки рисков
- •1.3.4. Применение метода последовательного выбора уступок
- •1.3.5. Проектирование системы защиты с избыточным функционалом системы защиты
- •1.4. Выводы по разделу 1.
- •Раздел 2. Проектирование системы защиты персональных данных
- •2.1. Основополагающие документы по защите персональных данных
- •2.2. Классификация испДн
- •2.3. Методика определения актуальных угроз
- •2.3.1 Порядок определения исходной безопасности испДн
- •2.3.2 Порядок определения актуальных угроз безопасности пДн из исходного множества угроз
- •2.3.3. Пример построения модели угроз безопасности пДн и определения актуальных угроз
- •2.4. Выводы по разделу 2.
- •Раздел 3. Основополагающие методы обеспечения информационной безопасности
- •3.1. Общая классификация методов защиты
- •3.2. Идентификация и аутентификация
- •3.2.1. Идентификация и аутентификация субъектов доступа
- •3.2.1.1. Идентификация и аутентификации субъекта доступа «пользователь»
- •3.2.1.1.1. Идентификация и аутентификации пользователя при входе в систему
- •2.2.1.1.2. Идентификация и аутентификации пользователя при доступе к ресурсам
- •3.2.1.2. Идентификация и аутентификации субъекта доступа «процесс»
- •3.2.2. Идентификация и аутентификация объектов доступа
- •3.2.2.1. Идентификация и аутентификация устройств
- •3.2.2.2. Идентификация и аутентификация файловых объектов
- •3.2.2.3. Идентификация и аутентификация сообщений, передаваемых по сети
- •3.3. Разграничение доступа к ресурсам
- •3.3.1. Общие положения
- •3.3.2. Определение и классификация задач, решаемых механизмами управления доступом к ресурсам
- •При функционировании защищаемого объекта в составе лвс дополнительно:
- •3.3.3. Требования к корректности решения задачи управления доступом
- •3.3.3.1. Каноническая модель управления доступом. Условие корректности механизма управления доступом
- •3.3.3.2. Понятие и классификация каналов взаимодействия субъектов доступа. Модели управления доступом с взаимодействием субъектов доступа.
- •3.3.3.3. Классификация методов управления виртуальными каналами взаимодействия субъектов доступа
- •2. В общем случае различие моделей управления доступом базируется на отличиях способов реализации канала взаимодействия субъектов доступа и методах управления им
- •3.3.4. Классификация механизмов управления доступом. Дискреционный и мандатный механизмы управления доступом
- •3.3.5. Разметка иерархических объектов доступа
- •3.3.6. Разграничения доступа для субъекта «процесс»
- •3.3.7. Разграничение доступа к объекту «процесс». Механизм обеспечения замкнутости программной среды
- •3.3.7.1. Механизм обеспечения замкнутости программной среды заданием пользователям списков исполняемых файлов
- •3.3.7.2. Механизм обеспечения замкнутости программной среды заданием пользователям каталогов с исполняемыми файлами, разрешенных на запуск
- •3.3.7.3. Расширение функциональных возможностей механизма обеспечения замкнутости программной среды
- •3.3.8. Управление доступом к каталогам, не разделяемым системой и приложениями
- •3.3.9. Ролевая модель разграничения доступа к ресурсам
- •3.3.10. Разделительная политика доступа к ресурсам. Сессионный контроль доступа
- •3.4. Контроль целостности и аудит
- •3.4.1. Контроль целостности
- •3.4.2. Аудит
- •3.5. Защита сети
- •3.5.1. Задача и способ защиты информации, обрабатываемой в составе лвс. Системный подход к проектированию системы защиты компьютерной информации в составе лвс
- •3.5.2. Задача и способ защиты доступа в сеть
- •5.5.2.1. Трансляция сетевых адресов и портов
- •3.5.2.2. Межсетевое экранирование
- •3.6. Выводы по разделу 3
1.1.1.3. Требования к корректности реализации механизмов защиты информации
Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе [1].
Например, в части реализации разграничительной политики доступа к объектам файловой системы, для средств, предназначенных для защиты конфиденциальной информации (5 класс СВТ), данные требования формулируются следующим образом:
КСЗ (комплекс средств защиты) должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).
Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту).
КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа.
Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).
Механизм, реализующий дискреционный принцип контроля доступа, должен предусматривать возможности санкционированного изменения правил разграничения доступа (ПРД), в том числе возможность санкционированного изменения списка пользователей СВТ и списка защищаемых объектов.
Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).
Данные требования формируют важнейший принцип построения защиты.
Проанализируем некоторые важнейшие из этих требований.
Основной принцип корректности защиты. Должна обеспечиваться индуктивность модели безопасности.
Модель безопасности принято считать индуктивной в том случае, если система, единожды установленная в безопасное состояние, находится в этом состоянии в процессе своего функционирования.
С учетом сказанного уточним (а в чем-то возможно переформулируем), требования к корректности реализации разграничительной политики доступа, представленные выше.
Очевидно, что индуктивность модели безопасности может достигаться только в том случае, когда пользователь априори исключен из схемы администрирования. Это определяется не только приведенными выше требованиями:
Механизм, реализующий дискреционный принцип контроля доступа, должен предусматривать возможности санкционированного изменения правил разграничения доступа (ПРД), в том числе возможность санкционированного изменения списка пользователей СВТ и списка защищаемых объектов.
Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.),
но и требованием:
Из схемы контроля доступа к ресурсам должна быть исключена сущность «Владение» объектом как таковая.
Обратим внимание на некоторое противоречие требований, сформулированных в нормативном документе. В этих требованиях речь идет о, так называемом, дискреционном принципе контроля доступа «КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа». Противоречие состоит в том, что само понятие дискреционный принцип контроля доступа основано на реализации схемы администрирования, предполагающей назначением прав доступа пользователем к создаваемому им объекту (т.е. на использовании сущности «Владения»). При этом в нормативном документе говорится о том, что «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)», т.е. не пользователю. Поэтому корректней далее говорить об избирательном принципе контроля доступа к ресурсам (см. выше), при этом соответствующее требование примет вид:
КСЗ должен содержать механизм, претворяющий в жизнь избирательные правила разграничения доступа.
Теперь обратимся к требованию «Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту)». На наш взгляд данное требование имеет смысл дополнить следующим образом:
Должна быть реализована разрешительная разграничительная политика доступа к ресурсам, состоящая в том, что право доступа устанавливать субъектам, а не присваивается в качестве атрибутов объектам (данное решение на практике используется для включения в схему контроля доступа сущности «Владения»), с указанием соответствующих объектов и типов доступа, которые разрешаются субъекту.
В этом случае становится невозможным какой-либо доступ к вновь создаваемому объекту, т.е. разграничительная политика доступа к ресурсам реализуется корректно.
В порядке замечания хотелось бы обратить внимание на следующее важное требование «Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов)». Во-первых, поскольку в качестве субъекта доступа нами рассматривается две сущности «Пользователь» и «Процесс» данное требование должно быть переформулировано соответствующим образом. Во-вторых, следует учитывать, что как пользователи, так и процессы могут быть и прикладными, и системными, то же относится и к объектам.
Обратимся к требованию: «Контроль доступа должен быть применим к каждому объекту и каждому субъекту…», т.е. речь идет как о прикладных, так и о системных субъектах и объектах. С учетом этого, данное требование, на наш взгляд, не мешает уточнить следующим образом:
Контроль доступа должен быть применим к каждому объекту (ресурсу) и каждому субъекту, включая системные субъекты и объекты.
Приведем пример, иллюстрирующий, к чему может привести невыполнение данного требования. Например, для ОС Windows субъектом является и учетная запись System, причем ОС Windows предоставляет сервис, связанный с возможностью запуска приложений от лица этой учетной записи (которая всегда присутствует в системе) – с ее правами. Но при этом не позволяет запрещать этой учетной записи, как следствие, и всем запускаемым под нею приложениям, модификацию системного диска. Выполняются ли при этом требования? Конечно же, нет, следовательно, уязвимость! Результат – угроза атак на расширение привилегий с целью получения прав пользователя System (соответственно, возможности полного управления защищаемым компьютером).
Замечание. Другие важные требования подробно рассмотрим в последующих разделах учебного пособия.