Возможности реализации требований РД «СВТ. Защита от НСД к информации. Показатели защищенности от несанкционированного доступа к информации» (РД СВТ) средствами операционной системы специального назначения Astra Linux Special Edition, очередные обновления 1.7 и 4.7
Принятые обозначения и сокращения
Возможности реализации требований РД «СВТ. Защита от НСД к информации. Показатели защищенности от несанкционированного доступа к информации» (РД СВТ) средствами операционной системы специального назначения Astra Linux Special Edition, очередные обновления 1.7 и 4.7
В следующей таблице приведены возможности реализации мер защиты согласно руководящему документу РД СВТ. Информация о гарантиях проектирования, составе конструкторской документации и контроле модификации не приведена в эксплуатационной документации на ОС. При разработке и сертификации СВТ на соответствие РД СВТ разработчикам СВТ необходимо разработать собственные документы по настоящим разделам.
| Классы защищенности | Средства реализации | Уровни защищенности Astra Linux | Способ реализации меры защиты с использованием штатных средств Astra Linux | Компоненты Astra Linux | Эксплуатационная документация и справочная информация по функционированию и настройке штатных средств защиты информации Astra Linux | |||||||||
| Требования | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Усиленный ("Воронеж") | Максимальный ("Смоленск") | |||||
| Первая группа | Вторая группа | Третья группа | Четвертая группа | |||||||||||
Дискреционный принцип контроля доступа. | ||||||||||||||
| КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.). Для каждой пары (субъект – объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту). КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа. Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов). Механизм, реализующий дискреционный принцип контроля доступа, должен предусматривать возможности санкционированного изменения ПРД, в том числе возможность санкционированного изменения списка пользователей СВТ и списка защищаемых объектов. Права изменять ПРД должны предоставляться выделенным субъектам (администрации, службе безопасности и т.д.). | + | + | + | + | + | + | Средства Astra Linux | + | + | В Astra Linux реализован механизм дискреционных ПРД именованных субъектов (пользователей) к именованным сущностям (объектам). На защищаемые именованные объекты устанавливаются (автоматически при их создании) базовые ПРД в виде идентификаторов номинальных субъектов (UID и GID), которые вправе распоряжаться доступом к данной сущности, и прав доступа к сущности. Дискреционное управление доступом применяется к каждой сущности и каждому субъекту. Определяются три вида доступа: чтение (read, r), запись (write, w) и исполнение (execution, x). Права доступа включают список (битовую маску) из девяти пунктов: по три вида доступа для трех классов — пользователя-владельца, группы-владельца и всех остальных. Каждый пункт в этом списке может быть либо разрешен, либо запрещен (равен 1 или 0). Дополнительно в Astra Linux механизмом дискреционных ПРД поддерживаются списки контроля доступа ACL (Access Control List), реализованные на основе расширенных атрибутов файловых систем. Реализация механизма дискреционных ПРД обеспечивает наличие для каждой пары (субъект-сущность) явное и недвусмысленное перечисление разрешенных типов доступа. Механизм, реализующий дискреционное управление доступом, обеспечивает возможность санкционированного изменения списка пользователей и списка защищаемых сущностей, являющихся файловыми объектами. Право изменения ПРД предоставлено выделенному субъекту-суперпользователю root (пользователю с UID, имеющим значение 0). Администратор может изменять права с использованием механизма sudo. Кроме того, права доступа к сущности, как указанные в битовой маске для трех классов (пользователя-владельца, группы-владельца и всех остальных), так и указанные в записях ACL, могут быть изменены субъектом, являющимся пользователем-владельцем сущности. | Дискреционное управление доступом, списки контроля доступа ACL | РКСЗ.1: п.3 "Дискреционное управление доступом" | ||
| Должны быть предусмотрены средства управления, ограничивающие распространение прав на доступ | + | + | + | + | + | Средства Astra Linux | + | + | Для управления дискреционными ПРД используется графическая утилита fly-fm («Менеджер файлов»). Для управления Linux-привилегиями пользователей системы используется графическая утилита fly-admin-smc («Управление политикой безопасности»). Также предусмотрены средства управления дискреционными ПРД в режиме командной строки. | Графическая утилита fly-fm («Менеджер файлов»), графическая утилита fly-admin-smc («Управление политикой безопасности»), средства управления в режиме командной строки. | РКСЗ.1: п.3 "Дискреционное управление доступом" | |||
| КСЗ должен содержать механизм, претворяющий в жизнь дискреционные ПРД, как для явных действий пользователя, так и для скрытых, обеспечивая тем самым защиту объектов от НСД (т.е. от доступа, не допустимого с точки зрения заданного ПРД). Под "явными" здесь подразумеваются действия, осуществляемые с использованием системных средств - системных макрокоманд, инструкций языков высокого уровня и т.д., а под "скрытыми" - иные действия, в том числе с использованием собственных программ работы с устройствами. | + | + | + | + | Средства Astra Linux | + | + | Решение задачи дискреционного управления доступом основано на реализации в Astra Linux соответствующего механизма. В Astra Linux механизм дискреционного управления доступом обеспечивает проверку дискреционных ПРД, формируемых в виде базовых ПРД операционных систем семейства Linux и представленных в виде идентификаторов субъектов (идентификатор пользователя (UID) и идентификатор группы (GID)), имеющих доступ к сущностям (чтение, запись, исполнение). Кроме того, для формирования дискреционных ПРД в Astra Linux используются списки контроля доступа (ACL) и механизм системных привилегий операционных систем семейства Linux. В состав Astra Linux входят защищенные комплексы программ: СУБД, электронной почты и гипертекстовой обработки данных. В защищенных комплексах программ электронной почты и гипертекстовой обработки данных защищаемыми сущностями являются сущности ФС. Таким образом, дискреционное управление доступом к ним обеспечивается также, как и к прочим сущностям ФС. В среде Astra Linux службы (.service), точки монтирования (.mount), устройства (.device), файлы подкачки (.swap), сокеты (*.socket) являются частью файловой системы, доступ к которой контролируется дискреционными ПРД обычным образом, следовательно, использование пользователем собственных программ работы с устройствами остается в рамках контроля этих правил. Реализация механизма дискреционных ПРД обеспечивает наличие для каждой пары (субъект-сущность) явное и недвусмысленное перечисление разрешенных типов доступа. | Мандатное управление доступом, МКЦ, Дискреционное управление доступом, Изоляция процессов, Очистка памяти (secdel), режим киоска, блокировка запуска программ df,chattr,arp,ip | РКСЗ.1: п.3 "Дискреционное управление доступом", ОП: п.4.1.4 "Дискреционное управление доступом". | ||||
| Дискреционные правила разграничения доступа должны быть эквивалентны мандатным правилам (т.е. всякий запрос на доступ должен быть одновременно санкционированным или несанкционированным одновременно и по дискреционным правилам, и по мандатным ПРД). | + | + | Средства Astra Linux | + | + | При обращении процесса к сущности (с запросом доступа определённого вида, т.е. на чтение, запись или исполнение) система проверяет совпадение идентификаторов владельцев процесса и владельцев файла в определённом порядке, и в зависимости от результата, применяет ту или иную группу прав. Принятие решения о запрете или разрешении доступа субъекта к сущности принимается на основе типа операции (чтение/запись/исполнение), мандатного контекста безопасности субъекта и мандатного контекста безопасности сущности. Проверка мандатных прав доступа к сущностям осуществляется одновременно с проверкой дискреционных прав доступа к ним. | Дискреционное управление доступом | РКСЗ.1: п.17.4 "Условия исключения скрытых каналов", РКЗС.1: п.3 "Дискреционное управление доступом" | ||||||
Мандатный принцип контроля доступа. | ||||||||||||||
| Должны сопоставляться классификационные метки каждого субъекта и каждого объекта, отражающие их место в соответствующей иерархии. Посредством этих меток субъектам и объектам должны назначаться классификационные уровни (уровни уязвимости, категории секретности и т.п.), являющиеся комбинациями иерархических и неиерархических категорий. Данные метки должны служить основой мандатного принципа разграничения доступа. | + | + | + | + | Средства Astra Linux | - | + | При реализации политики мандатного управления (разграничения) доступом ( МРД доступно только для уровня защищенности Astra Linux "Максимальный" ("Смоленск")) субъектам и сущностям задаются классификационные метки: уровни конфиденциальности и категории конфиденциальности. Иерархический уровень конфиденциальности (уровень конфиденциальности) определяет степень секретности сущности и соответствующий уровень доступа к ней, назначенный субъекту. Множество неиерархических категорий конфиденциальности (категории конфиденциальности) определяет набор категорий, доступных субъекту или назначенных сущности. Также сущностям могут быть присвоены дополнительные мандатные атрибуты управления доступом, позволяющие уточнять или изменять правила мандатного управления доступом для тех или иных субъектов или сущностей. Мандатные атрибуты субъекта (объекта) объединяются в мандатный контекст безопасности этого субъекта (объекта). | Мандатное управление доступом | РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности" | ||||
| Назначение мандатного контекста безопасности субъекта или сущности осуществляется администратором с помощью инструментов управления политикой безопасности локально или централизованно в соответствии с организационно-распорядительной документацией. | КСЗ при вводе новых данных в систему должен запрашивать и получать от санкционированного пользователя классификационные метки этих данных. При санкционированном занесении в список пользователей нового субъекта должно осуществляться сопоставление ему классификационных меток. Внешние классификационные метки (субъектов, объектов) должны точно соответствовать внутренним меткам (внутри КСЗ). | + | + | + | + | Средства Astra Linux | - | + | С каждым субъектом и сущностью доступа Astra Linux связан мандатный контекст безопасности, включающий в себя метку безопасности и дополнительные мандатные атрибуты управления доступом. При создании субъектом любой из сущностей, она наследует метку на основе мандатного контекста безопасности процесса. Субъекты или сущности, которым явно не задан мандатный контекст безопасности, считаются имеющими минимальный (нулевой) мандатный контекст безопасности, т.е. метка безопасности и все мандатные атрибуты имеют минимальные допустимые значения (например, равные нулю). Ввод пользователями информации осуществляется строго с учетом и в соответствии с установленными правилами разграничения доступа на основе типа операции (чтение, запись, исполнение), контекста безопасности пользователя и классификационной метки объекта (МРД доступно только для уровня защищенности Astra Linux "Максимальный" ("Смоленск")). Назначение мандатного контекста безопасности субъекта или сущности осуществляется администратором с помощью инструментов управления политикой безопасности локально или централизованно в соответствии с организационно-распорядительной документацией. | Мандатное управление доступом, графическая утилита fly-admin-smc. | РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности" | |||
| КСЗ должен реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов: | - субъект может читать объект, только если иерархическая классификация в классификационном уровне субъекта не меньше, чем иерархическая классификация в классификационном уровне объекта, и неиерархические категории в классификационном уровне субъекта включают в себя все иерархические категории в классификационном уровне объекта; | + | + | + | + | Средства Astra Linux | - | + | Субъект с определенным иерархическим уровнем конфиденциальности может получить доступ на чтение к сущности, если его уровень конфиденциальности не ниже уровня конфиденциальности сущности. Субъект с определенным набором категорий конфиденциальности может получить доступ на чтение к сущности, если в его наборе категорий конфиденциальности присутствуют категории конфиденциальности, заданные данной сущности. | Мандатное управление доступом | РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности" | |||
| - субъект осуществляет запись в объект, только если классификационный уровень субъекта в иерархической классификации не больше, чем классификационный уровень объекта в иерархической классификации, и все иерархические категории в классификационном уровне субъекта включаются в неиерархические категории в классификационном уровне объекта. | + | + | + | + | Средства Astra Linux | - | + | Субъект с определенным иерархическим уровнем конфиденциальности может получить доступ на запись к сущности, если его уровень конфиденциальности совпадает с уровнем конфиденциальности сущности. Субъект с определенным набором категорий конфиденциальности может получить доступ на запись к сущности, если его набор категорий конфиденциальности соответствует набору категорий конфиденциальности, заданному данной сущности. | Мандатное управление доступом | РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности" | ||||
| Реализация мандатных ПРД должна предусматривать возможности сопровождения: изменения классификационных уровней субъектов и объектов специально выделенными субъектами. | + | + | + | + | Средства Astra Linux | - | + | Для администрирования подсистем мандатного управления доступом и мандатного контроля целостности множество Linux привилегий расширено специальными привилегиями. Управление привилегиями пользователей выполняется только супер- пользователем с максимальным уровнем целостности, установленным в Astra Linux (администратору присваивается максимальный уровень целостности 63). Включение мандатного управления доступом происходит в процессе установки ОС, либо после установки Astra Linux с помощью инструмента astra-mac-control или используя графическую утилиту fly-admin-smc (МРД доступно только для уровня защищенности Astra Linux "Максимальный" ("Смоленск")). Режим МКЦ для Astra Linux может быть включен в процессе установки ОС, либо после установки Astra Linux выполняется с помощью инструмента astra-mic-control или используя графическую утилиту fly-admin-smc (режим МКЦ доступен для уровней защищенности Astra Linux "Усиленный" ("Воронеж") и "Максимальный" ("Смоленск")). | Мандатное управление доступом, инструмент astra-mac-control, графическая утилита fly-admin-smc. | РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности" | ||||
| В СВТ должен быть реализован диспетчер доступа, т.е. средство, осуществляющее перехват всех обращений субъектов к объектам, а также разграничение доступа в соответствии с заданным принципом разграничения доступа. При этом решение о санкционированности запроса на доступ должно приниматься только при одновременном разрешении его и дискреционными, и мандатными ПРД. Таким образом, должен контролироваться не только единичный акт доступа, но и потоки информации. | + | + | + | + | Средства Astra Linux | - | + | Монитор обращений из состава Astra Linux предусматривает дискреционное, мандатное (МРД доступно только для уровня защищенности Astra Linux "Максимальный" ("Смоленск")) и ролевое управление доступом (СУБД, ЕПП), а также реализацию мандатного контроля целостности (режим МКЦ доступен для уровней защищенности Astra Linux "Усиленный" ("Воронеж") и "Максимальный" ("Смоленск")). Монитор обращений гарантирует перехват каждого обращения субъекта к сущности (объекту). При обращении процесса к сущности (с запросом доступа определённого вида, т.е. на чтение, запись или исполнение) система проверяет совпадение идентификаторов владельцев процесса и владельцев файла в определённом порядке, и в зависимости от результата, применяет ту или иную группу прав. Принятие решения о запрете или разрешении доступа субъекта к сущности принимается на основе типа операции (чтение/запись/исполнение), мандатного контекста безопасности субъекта и мандатного контекста безопасности сущности. Проверка мандатных прав доступа к сущностям осуществляется одновременно с проверкой дискреционных прав доступа к ним. | Мандатное управление доступом, Дискреционное управление доступом. Управление полномочиями (привилегиями) локальных пользователей (fly-admin-smc), управление полномочиями (привилегиями/ролями) доменных пользователей (ALD/ FreeIPA) Дополнительно: МКЦ, управление доступом в БД, Организация домена (ЕПП) | РКСЗ.1: п.3 "Дискреционное управление доступом", РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности", ОП: п.4.1.4 "Дискреционное управление доступом", ОП: п.4.1.5 "Мандатное управление доступом и контроль целостности", ОП: п.4.1.17 "Обеспечение доступа к БД" | ||||
| Очистка памяти. | ||||||||||||||
| При первоначальном назначении или при перераспределении внешней памяти КСЗ должен предотвращать доступ субъекту к остаточной информации. | + | + | Средства Astra Linux | + | + | В Astra Linux реализован механизм очистки освобождаемой внешней памяти. Механизм может быть включен при установке Astra Linux . Дополнительные возможности по очистке остаточной информации предоставляет ядро с усиленной самозащитой Hardened. Набор изменений и опций ядра Hardened обеспечивает: - очистку остаточной информации в ядерном стеке (STACKLEAK); - очистку остаточной информации в ядерной куче (PAGE_POISONING). Реализованный в Astra Linux механизм очистки освобождаемой внешней памяти очищает неиспользуемые блоки ФС непосредственно при их освобождении, а также очищает разделы страничного обмена. | Astra-secdel-control (механизм безопасного удаления файлов), astra-swapwiper-control (очистка разделов подкачки при завершении работы ОС), ядро с усиленной самозащитой Hardened. | РКСЗ.1: п.8.1 " Очистка памяти" | ||||||
| КСЗ должен осуществлять очистку оперативной и внешней памяти. Очистка должна производиться путем записи маскирующей информации в память при ее освобождении (перераспределении). | + | + | + | Средства Astra Linux | + | + | Реализованный в Astra Linux механизм очистки освобождаемой внешней памяти очищает неиспользуемые блоки ФС непосредственно при их освобождении, а также очищает разделы страничного обмена. Данные любых удаляемых/урезаемых файлов в пределах заданной ФС предварительно очищаются предопределенной или псевдослучайной маскирующей последовательностью. | Astra-secdel-control (механизм безопасного удаления файлов), astra-swapwiper-control (очистка разделов подкачки при завершении работы ОС), ядро с усиленной самозащитой Hardened. | РКСЗ.1: п.8.1 " Очистка памяти" | |||||
| Изоляция модулей. | ||||||||||||||
| При наличии в СВТ мультипрограммирования в КСЗ должен существовать программно-технический механизм, изолирующий программные модули одного процесса (одного субъекта), от программных модулей других процессов (других субъектов) - т.е. в оперативной памяти ЭВМ программы разных пользователей должны быть защищены друг от друга. | + | + | + | + | Средства Astra Linux | + | + | Ядро Astra Linux обеспечивает для каждого процесса в системе собственное изолированное адресное пространство. Данный механизм изоляции основан на страничном механизме защиты памяти, а также механизме трансляции виртуального адреса в физический, поддерживаемый модулем управления памятью. Одни и те же виртуальные адреса (с которыми и работает процессор) преобразуются в разные физические для разных адресных пространств. Процесс не может несанкционированным образом получить доступ к пространству другого процесса, т.к.непривилегированный пользовательский процесс лишен возможности работать с физической памятью напрямую. | Изоляция процессов | ОП: п.4.1.6 «Изоляция процессов» РКСЗ.1: п.7 «Изоляция процессов» | ||||
| Гарантии изоляции должны быть основаны на архитектуре СВТ | + | + | Средства Astra Linux | + | + | Решение задачи изоляции процессов основано на архитектуре ядра ОС. Ядро Astra Linux обеспечивает для каждого процесса в системе собственное изолированное адресное пространство. | Изоляция процессов | РКСЗ.1: п.7.1 "Изоляция процессов ОС" ОП: п.4.1.6 «Изоляция процессов» | ||||||
| Маркировка документов. | ||||||||||||||
| При выводе защищаемой информации на документ в начале и конце проставляют штамп N 1 и заполняют его реквизиты в соответствии с Инструкцией N 0126-87 (п. 577). | + | + | + | + | Средства Astra Linux, Орг.меры | - | + | Защищенный комплекс программ печати и маркировки документов обеспечивает маркировку выводимых на печать документов. Маркировка доступна только для документов, которые отправляются на печать в ненулевой сессии (при режиме МРД, доступном на включение только для уровня защищенности Astra Linux "Максимальный" ("Смоленск")). Сервер печати, встроенный в Astra Linux, проверяет метку безопасности заданий, отправляемых на печать, и все задания, имеющие ненулевые метки безопасности, задерживает до проведения их маркировки. Маркировка отпечатанных листов документа осуществляется при соответствующей настройке защищенного комплекса программ печати и маркировки документов из состава Astra Linux. Выдача печатных документов сопровождается автоматической маркировкой каждого листа (страницы) документа его последовательным номером и учетными реквизитами АС с указанием на последнем листе документа общего количества листов (страниц) при соответствующей настройке защищенного комплекса программ печати и маркировки документов из состава Astra Linux. Маркировка задержанных заданий осуществляется специально назначенным пользователем (пользователями). Управление заданиями на печать и маркировкой документов осуществляется с помощью графической утилиты управления печатью из состава Astra Linux. | Маркировка документов, Сервер печати CUPS | РКСЗ.1: п.12 "Маркировка документов" РКСЗ.1: п.12.3 "Настройка маркера печати" | ||||
| Защита ввода и вывода на отчуждаемый физический носитель информации. | ||||||||||||||
| КСЗ должен различать каждое устройство ввода-вывода и каждый канал связи как произвольно используемые или идентифицированные ("помеченные"). При вводе с "помеченного" устройства (вывода на "помеченное" устройство) КСЗ должен обеспечивать соответствие между меткой вводимого (выводимого) объекта (классификационным уровнем) и меткой устройства. Такое же соответствие должно обеспечиваться при работе с "помеченным" каналом связи. | + | + | + | + | Средства Astra Linux | - | + | Astra Linux обеспечивает ввод-вывод информации на запрошенное пользователем устройство как для произвольно используемых им устройств, так и для идентифицированных (при совпадении маркировки). Astra Linux включает в себя механизм, обеспечивающий надежное сопоставление мандатного контекста пользователя с уровнем и категориями конфиденциальности, установленными для устройства. Кроме того, механизм сопоставления пользователя с устройством, реализованный в ОС, обеспечивает при проверке совпадения маркировок носителя и пользователя применение дискреционных ПРД. Средства регистрации устройств обеспечивают учет подключаемых устройств и съемных носителей в системе, установку дискреционных и мандатных атрибутов доступа пользователей к устройствам и создание дополнительных правил доступа к устройству (например, ограничение на подключение устройства только в определенный USB-порт). Сетевые соединения в Astra Linux рассматриваются как средство межпроцессного взаимодействия и также подвергаются мандатному контролю доступа. Для поддержки мандатного управления доступом в сетевые пакеты протокола IPv4 (IPv6) внедряются классификационные метки. Порядок присвоения классификационных меток и их формат соответствует национальному стандарту ГОСТ Р 58256-2018 «Защита информации. Управление потоками информации в информационной системе. Формат классификационных меток». Прием сетевых пакетов подчиняется мандатным ПРД. Следует отметить, что метка безопасности сокета может иметь тип, позволяющий создавать сетевые службы, принимающие соединения с любыми уровнями секретности. | Мандатное управление доступом (передача и контроль меток конфиденциальности при передаче информации по сети), Средства разграничения доступа к подключаемым устройствам (udev) | РКСЗ.1: п.4.10 "Сетевое взаимодействие" РА.1: п.17 «Средства разграничения доступа к подключаемым устройствам» | ||||
| Изменения в назначении и разметке устройств и каналов должны осуществляться только под контролем КСЗ. | + | + | + | + | Средства Astra Linux | - | + | В среде Astra Linux службы (.service), точки монтирования (.mount), устройства (блочные или символьные устройства ввода-вывода либо блочные устройства, которые могут быть смонтированы) (.device), файлы подкачки (.swap), сокеты (*.socket) являются частью файловой системы, доступ к которой контролируется мандатными и дискреционными ПРД обычным образом и, следовательно, все изменения остаются в рамках контроля этих правил. Взаимодействие при помощи сетевого протокола IPv4 (IPv6) осуществляется через программный интерфейс объектов доступа, являющихся элементами межпроцессного и сетевого взаимодействия (например, сетевых сокетов), которые обеспечивают обмен данными между процессами в рамках одной или нескольких ОС, объединенных в локальную вычислительную сеть. Для поддержки мандатного управления доступом в сетевые пакеты протокола IPv4 (IPv6) внедряются классификационные метки. Порядок присвоения классификационных меток и их формат соответствует национальному стандарту ГОСТ Р 58256-2018. Прием сетевых пакетов подчиняется мандатным ПРД. Контроль изменения в назначении и разметке устройств и каналов осуществляется с использованием встроенных механизмов защиты Astra Linux и штатных средств протоколирования и аудита. | Мандатное управление доступом, Дискреционное управление доступом, регистрация событий безопасности (auditd, zabbix) | РКСЗ.1: п.3 "Дискреционное управление доступом", РКСЗ.1: п.4 "Мандатное управление доступом и мандатный контроль целостности", ОП: п.4.1.4 "Дискреционное управление доступом", ОП: п.4.1.5 "Мандатное управление доступом и контроль целостности", РКСЗ.1: п.4.10 "Сетевое взаимодействие", РА.1: п.17 «Средства разграничения доступа к подключаемым устройствам», РА.1: п.4 «Системные службы, состояния и команды» | ||||
| Сопоставление пользователя с устройством. | ||||||||||||||
| КСЗ должен обеспечивать вывод информации на запрошенное пользователем устройство как для произвольно используемых устройств, так и для идентифицированных (при совпадении маркировки). | + | + | + | + | Средства Astra Linux | + | + | Astra Linux обеспечивает ввод-вывод информации на запрошенное пользователем устройство как для произвольно используемых им устройств, так и для идентифицированных (при совпадении маркировки). | Механизм сопоставления пользователя с устройством, Мандатное управление доступом, Дискреционное управление доступом. | РКСЗ.1: п.14 "Сопоставление пользователя с устройством" | ||||
| Идентифицированный КСЗ должен включать в себя механизм, посредством которого санкционированный пользователь надежно сопоставляется выделенному устройству. | + | + | + | + | Средства Astra Linux | + | + | Astra Linux включает в себя механизм, обеспечивающий надежное сопоставление мандатного контекста пользователя с уровнем и категориями конфиденциальности, установленными для устройства. Кроме того, механизм сопоставления пользователя с устройством, реализованный в ОС, обеспечивает при проверке совпадения маркировок носителя и пользователя применение дискреционных ПРД. | Механизм сопоставления пользователя с устройством, Мандатное управление доступом, Дискреционное управление доступом. | РКСЗ.1: п.14 "Сопоставление пользователя с устройством" | ||||
| Идентификация и аутентификация. | ||||||||||||||
| КСЗ должен требовать от пользователей идентифицировать себя при запросах на доступ. КСЗ должен подвергать проверке подлинность идентификации – осуществлять аутентификацию. КСЗ должен располагать необходимыми данными для идентификации и аутентификации. КСЗ должен препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась. | + | + | + | + | + | + | Средства Astra Linux | + | + | Идентификация и аутентификация пользователей осуществляется локально (по pam) или централизованно с помощью организации единого пространства пользователей (ЕПП), в основу которого положен доменный принцип построения сети с использованием сетевого протокола сквозной доверенной аутентификации. По умолчанию пользователям запрещены любые действия до прохождения процедур идентификации и аутентификации. | Локальная идентификация и аутентификация (PAM), Сквозная аутентификация (ЕПП), | ОП: п.4.1.2 "Идентификация и аутентификация", ОП: п.4.1.3 "Организация ЕПП" РА.1: п.8 "Средства организации ЕПП", РКСЗ.1: п.2 "Идентификация и аутентификация" | ||
| КСЗ должен обладать способностью надежно связывать полученную идентификацию со всеми действиями данного пользователя. | + | + | + | + | Средства Astra Linux | + | + | В Astra Linux реализована расширенная подсистема протоколирования, осуществляющая регистрацию событий действий пользователя по его идентификатору. | Локальная идентификация и аутентификация (PAM), Сквозная аутентификация (ЕПП), Регистрация событий безопасности (auditd) | ОП: п.4.1.2 "Идентификация и аутентификация", ОП: п.4.1.3 "Организация ЕПП" РА.1: п.8 "Средства организации ЕПП", РКСЗ.1: п.2 "Идентификация и аутентификация" РКСЗ.1: п.6 "Регистрация событий безопасности" ОП: п.4.1.7 «Регистрация событий безопасности» | ||||
| Регистрация. | ||||||||||||||
| КСЗ должен быть в состоянии осуществлять регистрацию следующих событий: | использование идентификационного и аутентификационного механизма; | + | + | + | + | + | Средства Astra Linux | + | + | В Astra Linux реализована расширенная подсистема протоколирования, осуществляющая регистрацию событий в двоичные файлы с использованием службы auditd, таких как использование идентификационного и аутентификационного механизма, запрос на доступ к защищаемому ресурсу (открытие файла, запуск программы и т. д.), создание и уничтожение объекта, действия по изменению ПРД. Протоколирование работает согласно заданным правилам, дополнительно администратором могут быть заданы собственные правила аудита. В Astra Linux поддерживается протоколирование событий на основе меток безопасности субъектов и объектов. Настройка регистрации осуществляется с помощью локальной и доменной политики безопасности. Просмотр регистрируемых событий осуществляется с использованием средств централизованного протоколирования и ведения журналов аудита событий безопасности (программы просмотра файлов журналов ksystemlog и утилиты ausearch). В параметрах регистрации указываются дата и время наступления события, идентификатор субъекта, осуществляющего регистрируемое действие, тип события, объект и тип доступа, результат (успешно или нет) действия. Для работы с подсистемой протоколирования могут использоваться средства управления протоколированием в режиме командной строки (setfaud, getfaud, useraud, psaud), а также графические утилиты, которые позволяют настраивать параметры регистрации событий и просмотра протоколов: - fly-admin-smc («Управление политикой безопасности») — управление протоколированием, привилегиями и мандатными атрибутами пользователей, работа с пользователями и группами; - system-config-audit («Конфигурация аудита») — включение и выключение регистрации событий аудита, настройка auditd, настройка журнала аудита, а также добавление, удаление и редактирование правил аудита; Для решения задач централизованного протоколирования и анализа журналов аудита, а также организации распределенного мониторинга сети, жизнеспособности и целостности серверов используется программное решение Zabbix. | Средства аудита (auditd, zabbix), Управление политикой безопасности fly-admin-smc (Аудит, Пользователи, Группы), Конфигурация аудита (system-config-audit), Системный журнал (ksystemlog) | РКСЗ.1: п.6 "Регистрация событий безопасности" Справка Astra Linux по работе с утилитой управления политикой безопасности fly-admin-smc и утилитой конфигурации аудита system-config-audit, по работе с программой просмотра файлов журналов ksystemlog | ||
| запрос на доступ к защищаемому ресурсу (открытие файла, запуск программы и т.д.); | + | + | + | + | + | |||||||||
| создание и уничтожение объекта; | + | + | + | + | + | |||||||||
| действия по изменению ПРД. | + | + | + | + | + | |||||||||
| Для каждого из этих событий должна регистрироваться следующая информация: | дата и время; | + | + | + | + | + | Средства Astra Linux | + | + | Средства аудита (auditd, zabbix), Управление политикой безопасности fly-admin-smc (Аудит, Пользователи, Группы), Конфигурация аудита (system-config-audit), Системный журнал (ksystemlog) | РКСЗ.1: п.6 "Регистрация событий безопасности" Справка Astra Linux по работе с утилитой управления политикой безопасности fly-admin-smc и утилитой конфигурации аудита system-config-audit, по работе с программой просмотра файлов журналов ksystemlog | |||
| субъект, осуществляющий регистрируемое действие; | + | + | + | + | + | |||||||||
| тип события (если регистрируется запрос на доступ, то следует отмечать объект и тип доступа); | + | + | + | + | + | |||||||||
| успешно ли осуществилось событие (обслужен запрос на доступ или нет). | + | + | + | + | + | |||||||||
| КСЗ должен содержать средства выборочного ознакомления с регистрационной информацией. | + | + | + | + | + | Средства Astra Linux | + | + | Для работы с подсистемой протоколирования Astra Linux включает в себя утилиту ksystemlog («Системный журнал») — выборочный просмотр протоколов аудита, которая позволяет настраивать параметры просмотра протоколов. | утилита ksystemlog («Системный журнал») | РКСЗ.1: п.6 "Регистрация событий безопасности" | |||
| должна быть предусмотрена регистрация всех попыток доступа, всех действий оператора и выделенных пользователей (администраторов защиты и т.п.). | + | + | + | + | Средства Astra Linux | + | + | Расширенная подсистема протоколирования Astra Linux осуществляет регистрацию всех попыток доступа, всех действий оператора и выделенных пользователей (администраторов защиты и т.п.). | Средства управления протоколированием в режиме командной строки (setfaud, getfaud, useraud, psaud), fly-admin-smc («Управление политикой безопасности»), System-config-audit («Конфигурация аудита») | РКСЗ.1: п.6 "Регистрация событий безопасности" | ||||
| Взаимодействие пользователя с КСЗ. | ||||||||||||||
| КСЗ должен быть хорошо структурирован, его структура должна быть модульной и четко определенной. | + | + | + | Средства Astra Linux | + | + | Для взаимодействия пользователя с КСЗ в Astra Linux используется защищенная графическая подсистема, в состав которой входит рабочий стол Fly. В состав рабочего стола Fly входит оконный менеджер и графические утилиты, которые могут быть использованы для администрирования ОС. Большинство утилит представляет собой графические оболочки соответствующих утилит командной строки. По умолчанию в графическую подсистему встроена мандатная защита. Мандатная защита позволяет администратору задавать отдельно для каждого пользователя разрешенный диапазон иерархических уровней конфиденциальности и неиерархических категорий конфиденциальности. Для этой цели следует используется графическая утилита fly-admin-smc. Графическая подсистема Astra Linux готова к работе с соблюдением мандатного управления доступом непосредственно после установки Astra Linux без проведения дополнительных настроек. | Защищенная графическая подсистема | РА.1: п.11 "Защищенная графическая подсистема" ОП: п.4.1.1 «Обеспечение пользовательского интерфейса» | |||||
| Интерфейс пользователя и КСЗ должен быть определен (вход в систему, запросы пользователей и КСЗ и т.п.). | + | + | + | |||||||||||
| Должна быть обеспечена надежность интерфейса пользователя и КСЗ. | + | + | + | |||||||||||
| Каждый интерфейс пользователя и КСЗ должен быть логически изолирован от других таких же интерфейсов. | + | + | + | |||||||||||
| Надежное восстановление | ||||||||||||||
| Процедуры восстановления после сбоев и отказов оборудования должны обеспечивать полное восстановление свойств КСЗ. | + | + | + | Средства Astra Linux | + | + | После сбоя в процессе перезагрузки Astra Linux автоматически выполняет программу проверки и восстановления ФС — fsck. После завершения загрузки Astra Linux в случае обнаружения повреждённых или изменённых файлов, возможно их восстановление с резервной копии. Если сбой привёл к выходу из строя жестких дисков, то после замены вышедшего из строя оборудования и переустановки Astra Linux с DVD-диска с дистрибутивом, пользовательские данные также могут быть восстановлены с резервной копии. Для выполнения операций резервного копирования и восстановления объектов ФС с сохранением и восстановлением мандатных атрибутов и атрибутов аудита в Astra Linux могут использоваться: 1) комплекс программ Bacula; 2) утилита архивирования tar В PostgreSQL существуют три подхода к резервному копированию данных: - SQL-дамп; - резервное копирование на уровне ФС; - непрерывное архивирование. | Программа проверки и восстановления ФС — fsck, комплекс программ Bacula, утилита архивирования tar, восстановления данных СУБД PostgreSQL | РКСЗ.1: п.10 "Надёжное функционирование" | |||||
| Целостность КСЗ | ||||||||||||||
| Должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части КСЗ. | + | + | + | + | + | Средства Astra Linux | + | + | Для обеспечения контроля целостности (в т.ч. контроля целостности КСЗ) в Astra Linux реализованы: - средство подсчёта контрольных сумм файлов и оптических дисков; - средство подсчёта контрольных сумм файлов в deb-пакетах; - средство контроля соответствия дистрибутиву - средства регламентного контроля целостности; - средства создания и проверки ЭП; - средства создания замкнутой программной среды. | Контроль целостности (afick, fly-admin-int-check), контроль целостности пакетов ПО (gostsum_from_deb), Дополнительно: ЗПС | РКСЗ.1: п.9 "Контроль целостности" | |||
| Программы КСЗ должны выполняться в отдельной части оперативной памяти. | + | + | + | + | Средства Astra Linux | + | + | Ядро Astra Linux обеспечивает для каждого процесса в системе собственное изолированное адресное пространство. Данный механизм изоляции основан на страничном механизме защиты памяти, а также механизме трансляции виртуального адреса в физический, поддерживаемый модулем управления памятью. Одни и те же виртуальные адреса (с которыми и работает процессор) преобразуются в разные физические для разных адресных пространств. Процесс не может несанкционированным образом получить доступ к пространству другого процесса, т. к. непривилегированный пользовательский процесс лишен возможности работать с физической памятью напрямую. | Архитектура ядра Astra Linux, Изоляция процессов | РКСЗ.1: п.7 "Изоляция процессов", ОП: п.4.1.6 «Изоляция процессов» | ||||
| Требование выполнения программ КСЗ в отдельной части оперативной памяти должно подвергаться верификации. | + | + | + | Средства Astra Linux | + | + | Требование выполнения программ КСЗ в отдельной части оперативной памяти верифицируются в процессе тестирования и сертификации | - | - | |||||
| Тестирование. | ||||||||||||||
| Должны тестироваться: | реализация дискреционных ПРД (перехват явных и скрытых запросов на доступ, правильное распознавание санкционированных и несанкционированных запросов на доступ в соответствии с дискреционными и мандатными правилами, верное сопоставление меток субъектов и объектов, запрос меток вновь вводимой информации, средства защиты механизма разграничения доступа, санкционированные изменения ПРД); | + | + | + | + | + | + | Средства Astra Linux | + | + | В состав Astra Linux входят средства тестирования функций СЗИ от НСД, находящиеся в каталоге usrlib/parsec/tests. Данный набор обеспечивает тестирование всех функций СЗИ от НСД из состава Astra Linux, включая: - дискреционное управление доступом, - идентификация и аутентификация, - запрет на доступ несанкционированного пользователя, - проверка очистки памяти и изоляции процессов, - проверка маркировки документов, - проверка контроля подключения съемных машинных носителей информации и сопоставления пользователя с устройством - регистрация событий безопасности, - механизм контроля целостности, - механизм надежного восстановления, Контроль дистрибуции осуществляется в процессе тестирования и сертификации. | Тестирование СЗИ | РКСЗ 2 | |
| невозможность присвоения субъектом себе новых прав; | + | + | + | + | + | + | ||||||||
| успешное осуществление идентификации и аутентификации, а также их средств защиты. | + | + | + | + | + | + | + | + | ||||||
| запрет на доступ несанкционированного пользователя; | + | + | + | + | + | + | ||||||||
| очистка оперативной и внешней памяти; | + | + | + | + | + | + | + | |||||||
| работа механизма изоляции процессов в оперативной памяти; | + | + | + | + | + | + | ||||||||
| маркировка документов; | + | + | + | + | + | + | ||||||||
| защита вода и вывода информации на отчуждаемый физический носитель и сопоставление пользователя с устройством | + | + | + | + | + | + | ||||||||
| регистрация событий, средства защиты регистрационной информации и возможность санкционированного ознакомления с ней; | + | + | + | + | + | + | + | |||||||
| работа механизма, осуществляющего контроль за целостностью КСЗ. | + | + | + | + | + | + | + | |||||||
| работа механизма надежного восстановления | + | + | + | + | + | |||||||||
| контроль дистрибуции | + | + | + | + | - | |||||||||
| Руководство для пользователя. | ||||||||||||||
| Документация на СВТ должна включать в себя краткое руководство для пользователя с описанием способов использования КСЗ и его интерфейса с пользователем. | + | + | + | + | + | + | Документация Astra Linux | + | + | Руководство пользователя РУСБ.10015-01 93 01 | - | РП | ||
| Руководство по КСЗ. | ||||||||||||||
| Руководство по КСЗ адресовано администратору защиты и должно содержать: | описание контролируемых функций; | + | + | + | + | + | + | Документация Astra Linux | + | + | Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1 п.1.2 «Контролируемые функции» | - | РКСЗ.1: п.1.2 "Контролируемые функции" | |
| руководство по генерации КСЗ; | + | + | + | + | + | + | Документация Astra Linux | + | + | Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1 п.15 «Генерация КСЗ» | - | РКСЗ.1: п.15 "Генерация КСЗ" | ||
| описание старта СВТ и процедур проверки правильности старта | + | + | + | + | + | + | Документация Astra Linux | + | + | Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1 п.1 «Общие сведения», Руководство администратора. Часть 1 РУСБ.10015-01 95 01-1 п.2 «Установка и настройка ОС». | - | РКСЗ.1: п.1 "Общие сведения", РА.1: п.2 "Установка и настройка ОС", | ||
| описание процедур работы со средствами регистрации | + | + | + | + | + | Документация Astra Linux | + | + | Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1 п.6 «Регистрация событий безопасности» | - | РКСЗ.1: п.6 "Регистрация событий безопасности" | |||
| руководство по средствам надежного восстановления | + | + | + | Документация Astra Linux | + | + | Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1 п.10 «Надежное функционирование» | - | РКСЗ.1: п.10 "Надежное функционирование" | |||||
| Должно быть представлено руководство по надежному восстановлению | + | + | Документация Astra Linux | + | + | Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1 п.10 «Надежное функционирование» | - | РКСЗ.1: п.10 "Надежное функционирование" | ||||||