Дерево страниц

Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 29 Следующий »



Данная статья применима к:

  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.7)
  • Astra Linux Special Edition РУСБ.10152-02 (очередное обновление 4.7)
  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.6)
  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5)
  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.4)
  • Astra Linux Special Edition РУСБ.10015-16 исп. 1 и исп. 2
  • Astra Linux Special Edition РУСБ.10265-01 (очередное обновление 8.1)

При установке и эксплуатации стороннего программного обеспечения (ПО) в информационных системах (ИС), функционирующих под управлением ОС Astra Linux Special Edition (ОС), должно учитываться следующее:

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

Требования по эксплуатации

ОС в аттестованных ИС должна функционировать в соответствии с указаниями по эксплуатации, приведенными в эксплуатационной документации.  Для Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.7) см.:

  1. «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1»  РУСБ.10015-01 97 01-1 п. 17.1:

    17.1. Обеспечение безопасности среды функционирования

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

    1) СВТ, предназначенное для установки и функционирования ОС, должно соответствовать требованиям, указанным в разделе 2 документа РУСБ.10015-01 31 01;

    2) для создания защищенной среды виртуализации изделие должно применяться совместно с аппаратным обеспечением, поддерживающим соответствующие технологии VT/SVM, в том числе при необходимости предоставления доступа виртуальным машинам к физическим устройствам;

    3) установка, управление и конфигурирование ОС должны проводиться в соответствии с эксплуатационной документацией;

    4) должна быть обеспечена защита от осуществления действий, направленных на нарушение физической целостности СВТ, на котором функционирует ОС;

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

    6) при использовании сетевого взаимодействия необходимо обеспечить доверенный канал передачи информации между СВТ, на которых установлена ОС (например,контроль несанкционированного подключения к ЛВС в пределах контролируемой зоны, защищенная передача сетевого трафика за пределами контролируемой зоны);

    7) должны быть определены лица, отвечающие за эксплуатацию и безопасность ОС, которым будут предоставлены административные полномочия в ОС. Данные лица не должны считаться нарушителем в модели угроз безопасности информации;

    8) лица, ответственные за эксплуатацию ОС, должны обеспечить, чтобы аутентификационная информация для каждой учетной записи пользователя ОС содержалась в тайне и была недоступна лицам, не уполномоченным использовать данную учетную запись.

  2. «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1»  РУСБ.10015-01 97 01-1 п. 17.2:

    17.2. Указания по эксплуатации ОС

    17.2.1. Перед началом эксплуатации ОС администратор безопасности должен обеспечить следующие условия:

    1) в случае разрешения интерактивного входа суперпользователя root для предотвращения подбора его пароля необходимо заблокировать возможность его удаленного входа в ОС посредством включения PAM-модуля pam_securetty в файл сценария /etc/pam.d/common-auth. Для этого необходимо в указанном файле в секции Primary block первой строкой добавить auth required pam_securetty.so;

    2) используя графическую утилиту fly-admin-smc («Управление политикой безопасности», см. электронную справку), запущенную от имени администратора через механизм sudo, в категории «Политики учетной записи» задать параметры для настройки политики паролей. Задать данные настройки можно также путем корректировки файлов сценариев:

    а) в файле/etc/pam.d/common-password в строке password requisite pam cracklib.so установить значение minlen=<минимальная_длина_пароля> и добавить параметры dcredit=-1, ucredit=-1 и lcredit=-1 (данные параметры устанавливают требования к сложности пароля);

    б) в файле /etc/login.defs для переменной PASS_MAX_DAYS установить требуемое значение максимального срока действия пароля в днях. Запрет повторного использования заданного числа последних паролей можно установить путем корректировки файла /etc/pam.d/common-password. Для этого в указанном файле в строке ...pam_unix.so добавить параметр remember=<число_паролей>;

    3) используя графическую утилиту fly-admin-smc («Управление политикой безопасности», см. электронную справку), запущенную от имени администратора через механизм sudo, в категории «Политики учетной записи» задать значения для настройки блокировки при неуспешных входах пользователя в систему. Данные параметры могут также быть установлены путем корректировки файла /etc/login.defs (параметры LOGIN_RETRIES и LOGIN_TIMEOUT);

    4) функции разграничения доступа, мандатного контроля целостности и гарантированного уничтожения (стирания) информации в полном объеме реализованы только для файловых систем ext2/ext3/ext4/xfs, поддерживающих расширенные (в т.ч. мандатные) атрибуты файловых объектов. При использовании других файловых систем необходимо учитывать данные ограничения. Установку ОС следует выполнять на системный раздел с файловой системой ext4/xfs;

    5) при необходимости установки в систему внешних модулей уровня ядра ОС, такие модули должны быть получены из доверенного источника, и перед их установкой с ОС должна осуществляться проверка их целостности;

    6) использование файловой системы NFS для доступа к сетевым дискам возможно при выполнении следующих условий:

    а) сетевые диски не предназначены для хранения файловых объектов, требующих обеспечения мандатного управления доступом к ним;
    б) версия используемого протокола NFS не ниже 3.

    17.2.2. При использовании механизма гарантированного удаления данных должны дополнительно быть выполнены следующие условия:

    1) при использовании разделов подкачки в ОС необходимо активировать в файле /etc/parsec/swap_wiper.conf их очистку согласно 8.1.

    17.2.3. При использовании мандатного контроля целостности должны дополнительно быть выполнены следующие условия:

    1) при использовании инструмента qemu-ga (из состава пакета qemu-guest-agent) значения параметров -p (в том числе при использовании опции -m unix-listen) и -t должны указывать на сокеты и файлы, уровни целостности которых совпадают с уровнем целостности запускаемого процесса.

    17.2.4. При использовании мандатного управления доступом должны дополнительно быть выполнены следующие условия:

    1) с использованием средств управления запуском служб должна быть отключена служба gpm для поддержки мыши в консольном режиме;

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

    3) в конфигурационном файле защищенного сервера печати из состава изделия /etc/cups/cupsd.conf не допускается установка значения None параметра DefaultAuthType (отключение аутентификации) и внесение изменений в параметры политики PARSEC, не соответствующих эксплуатационной документации;

    4) при использовании защищенного сервера СУБД из состава ОС в режиме мандатного управления доступом необходимо в конфигурационном файле кластера postgresql.conf для параметра enable_bitmapscan установить значение off и для параметра ac_ignore_socket_maclabel установить значение false;

    5) при использовании защищенного сервера СУБД из состава ОС в режиме мандатного управления доступом не допускается отключать аутентификацию субъектов доступа установкой в конфигурационном файле кластера pg_hba.conf режима trust (без аутентификации);

    6) при использовании защищенного комплекса программ электронной почты из состава ОС в режиме мандатного управления доступом конфигурационные параметры агента передачи электронной почты Exim и агента доставки электронной почты Dovecot не должны допускать отправку и прием сообщений электронной почты без аутентификации;

    7) для штатной работы ОС не допускается отключение администратором системы расширения XPARSEC у Х-сервера (использование отладочной опции XPARSEC=Disable в конфигурационных файлах Х-сервера, см. документ РУСБ.10015-01 31 01).

  3. «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1»  РУСБ.10015-01 97 01-1 п. 17.3:

    1.7.3. Условия применения ПО

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

    1) подменять файлы образа ядра vmlinuz-* и образов временной файловой системы начальной загрузки /boot/initrd.img-* (в случае отсутствия явной необходимости обновления отдельных компонентов, входящих в состав образа), находящиеся в каталоге /boot, файлы модулей ядра, находящиеся в каталоге /lib/modules, и прочие файлы, входящие в состав изделия или стороннего ПО;

    2) статически или динамически изменять таблицу системных вызовов и поля структуры типа security_operations и иных структур типа *security*;

    3) переопределять основной процесс ОС в конфигурационном файле загрузчика изделия путем установки параметра init=<полный_путь_к_исполняемому_файлу>;

    4) изменять параметры аутентификации пользователей в конфигурационных файлах PAM-сценариев, находящихся в каталоге /etc/pam.d;

    5) устанавливать подгружаемые модули аутентификации (PAM-модули), определяющие мандатные атрибуты сессии пользователя с использованием функций APIбиблиотеки libparsec-mac подсистемы безопасности PARSEC, имена которых начинаются с префиксов mac_set_, parsec_ или pdp_;

    6) устанавливать PAM-модули, определяющие привилегии PARSEC сессии пользователя с использованием функций API библиотеки libparsec-cap подсистемы безопасности PARSEC, имена которых начинаются с префиксов mcap или parsec_;

    7) устанавливать интерпретаторы команд, заменяющие интерпретаторы, входящие в состав изделия (bash, dash, PHP, Perl, Python, TCL, Ruby);

    8) получать доступ к памяти других процессов ПО с использованием привилегии CAP_SYS_PTRACE и системного вызова ptrace;

    9) изменять системное время (если наличие возможностей по изменению времени не предусмотрено функциональным назначением ПО);

    10) динамически изменять сегмент кода ядра ОС и использовать неэкспортируемые символы ядра ОС;

    11) осуществлять доступ к файлу ctl файловой системы parsecfs посредством системного вызова ioctl, минуя системные функции API-библиотек libparsec-*.

    17.3.2. Для ПО, функционирующего в среде ОС, должны соблюдаться следующие условия:

    1) необходимость и корректность использования в ПО привилегий администратора,прикладного программного интерфейса подсистемы безопасности PARSEC, мандатных привилегий, функционирования в пространстве ядра или только на высоком уровне механизма мандатного контроля целостности должны быть обоснованы в документации на данное ПО;

    2) для ПО, использующего модуль wsgi_mod для Apache из состава изделия, в документации разработчика ПО должен быть определен перечень сценариев работы модуля wsgi_mod. При этом должны быть исключены сценарии работы wsgi_mod в режимах, предусматривающих работу вне контекста пользователя и изменяющих процесс аутентификации.

    17.3.3. При использовании защищенного сервера печати из состава изделия установка и использование альтернативных серверов печати должны быть исключены.

    17.3.4. При использовании механизма мандатного управления доступом дополнительно должны соблюдаться следующие условия:

    1) ПО при обработке запросов пользователей не должно взаимодействовать с защищенной СУБД из состава изделия от имени пользователя с привилегиями PARSEC_CAP_SETMAC и PARSEC_CAP_CHMAC, позволяющими изменять мандатные атрибуты защищаемых объектов в СУБД;

    2) ПО, содержащее сетевые службы (программы, обрабатывающие запросы пользователей с применением протоколов стека TCP/IP), которые используют привилегии (PARSEC_CAP_SETMAC, PARSEC_CAP_CHMAC и PARSEC_CAP_PRIV_SOCK) и прикладной программный интерфейс подсистемы безопасности PARSEC из состава изделия, должно пройти сертификационные исследования, подтверждающие корректность реализации указанных служб;

    3) программный компонент RabbitMQ не применять при одновременной обработке данных с различными уровнями конфиденциальности либо для обеспечения взаимодействия процессов с различными уровнями доступа;

    4) ПО, обрабатывающее одновременно данные с различными уровнями конфиденциальности, не должно использовать программные пакеты Erlang.

  4. "Описание применения" РУСБ.10015-01 31 01:  см. Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.7). Эксплуатационная и дополнительная документация.

Требования по защите информации при аттестации ИС

1. ФСТЭК России

В отношении стороннего программного обеспечения, не реализующего функции безопасности и не используемого для обеспечения мер защиты информации в информационных системах, обязательная сертификация не требуется. Наличие у такого ПО сертификата соответствия не является необходимым условием для аттестации информационных систем. Обязательная сертификация по на соответствие требованиям безопасности информации такого программного обеспечения ФСТЭК России – не предусмотрена.
При этом в случае реализации в стороннем программном обеспечении функций безопасности информации может потребоваться его самостоятельная сертификация на соответствие требованиям безопасности информации ФСТЭК России.

При применении стороннего программного обеспечения, образующего совместно с ОС доверенную программную среду, необходимо выполнять требования раздела 17.3 эксплуатационного документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1» РУСБ.10015-01 97 01-1 (см. Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.7). Эксплуатационная и дополнительная документация).

2. Минобороны России

Прикладное программное обеспечение (вне зависимости от реализации функций безопасности) подлежит обязательной сертификации в системе МО РФ при выполнении хотя бы одного из следующих условий:

    • наличие требований о сертификации или соответствии требованиям по безопасности информации в тактико-техническом задании на проведение работ по разработке автоматизированной системы (программного обеспечения) в интересах МО РФ;

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

В случае выполнения любого из указанных условий стороннее программное обеспечение должно быть сертифицировано на соответствие требованиям по безопасности информации в составе разрабатываемого прикладного программного обеспечения. 
Если указанные условия НЕ выполняются, то необходимость сертификации применяемого программного обеспечения согласовывается с государственным заказчиком (заказывающим органом военного управления) и Восьмым управлением ГШ ВС РФ.

При применении стороннего программного обеспечения, образующего совместно с  ОС доверенную программную среду, необходимо выполнять требования раздела 17.3 эксплуатационного документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1» РУСБ.10015-01 97 01-1 (см. Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.7). Эксплуатационная и дополнительная документация).

3. ФСБ России

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

Применение ОС, а также применение стороннего программного обеспечения, функционирующего в среде ОС, должно осуществляться в соответствии с ограничениями по эксплуатации, приведенными в формуляре.

Устанавливаемые из сторонних репозиториев пакеты (в том числе из репозитория Astra Linux Common Edition) не подписаны на ключах разработчика и не будут работать при использовании замкнутой программной среды (ЗПС). Ключи для подписания пакетов можно запросить у разработчика (образец письма-заявки на получение цифровых ключей доступен по ссылке.

Указанные ограничения размещены на сайте astralinux.ru.

  • Нет меток