Выполнение требований и рекомендаций ФСТЭК России

Содержание

Выполнение требований и рекомендаций ФСТЭК России#

Использование роли astra.hardening.fstec из реестра Automation Hub позволяет автоматизировать процесс аудита и настройки систем защиты ОС Astra Linux Special Edition в соответствии с требованиями, изложенными в следующих приказах ФСТЭК России:

Приказ № 17 от 11 февраля 2013 г. «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».
Приказ № 21 от 18 февраля 2013 г. «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».
Приказ № 239 от 25 декабря 2017 г. «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации».
Приказ № 31 от 14 марта 2014 г. «Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды».

Предупреждение

Роль astra.hardening.fstec доступна в режиме Technical Preview.

Описание сценария#

Процесс аудита и настройки систем безопасности ОС Astra Linux Special Edition с помощью роли astra.hardening.fstec состоит из следующих этапов:

Изучение поведения ОС с настройками по умолчанию.
Подготовка проекта Ansible.

Проект включает в себя следующие файлы:
- ansible.cfg – настройки Ansible;
- inventory.yml – описание инвентаря;
- playbooks/fstec.yml – сценарий настройки параметров безопасности ОС в соответствии с требованиями приказа ФСТЭК России;
- playbooks/fstec_custom.yml – сценарий пользовательской настройки параметров безопасности ОС в соответствии с требованиями приказа ФСТЭК России;
- playbooks/audit.yml – сценарий аудита параметров безопасности ОС в соответствии с требованиями приказа ФСТЭК России.
Запуск набора сценариев.
Проверка поведения ОС после изменения настроек безопасности.

Подготовка к работе#

Подготовьте окружение к управлению задачами автоматизации:

Разверните управляемый узел (например, виртуальную машину) под управлением ОС Astra Linux Special Edition, работающей в необходимом режиме защищенности.

Важно

Для демонстрации настройки узла в соответствии с требованиями ФСТЭК России на нем обязательно наличие графического интерфейса.
Настройте управляемый узел согласно инструкции.
Изучите описание роли astra.hardening.fstec и список исключенных правил.

Важно

Выведение правил из списка исключенных в роли fstec требует внимательного изучения применимости их к узлу и требований по дополнительным настройкам и подготовке переменных.
На своей рабочей станции подготовьте каталог для хранения файлов проекта, например:
```
mkdir ~/astra-fstec/
```

Исключенные правила#

Коллекция astra.hardening содержит правила, которые необходимы для выполнения требований ФСТЭК России, но требуют предварительной подготовки узла и осознанного выбора, поскольку их применение может привести к следующим последствиям:

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

Такие правила делятся на две группы:

Исключенные правила (Excluded Rules) – правила, исключенные из автоматического применения в роли astra.hardening.fstec. Их список задается переменной роли fstec_disabled_rules; по умолчанию в него входят правила user_mic_4, limit_safepolicy_1, limit_safepolicy_2, limit_safepolicy_3, limit_safepolicy_7, limit_safepolicy_8, limit_safepolicy_10 и auth_sudo_1.
Правила, применяемые автоматически в составе набора правил приказа: user_filter_1, user_maxlogins_1, user_validityperiod_1 и auth_login_10. Часть из них требует обязательных переменных fstec_ufw_allowed_ports и fstec_user_expire_date, описанных в секции Подготовка проекта Ansible.

Важно

Применяйте исключенные правила отдельным сценарием с использованием привилегий пользователя root. Перед запуском обязательно подготовьте план восстановления доступа.

Правила, исключенные по умолчанию#

Ниже приведены рекомендации по применению правил, входящих в значение переменной fstec_disabled_rules по умолчанию.

Правило	Особенности применения
`user_mic_4`	Управляет расширенным режимом мандатного контроля целостности через команду `/usr/sbin/astra-strictmode-control`. Перед использованием выполните проверку работы механизма контроля целостности, например, с помощью afick. Запуск правила при наличии конфликтов целостности системных файлов может привести к необратимой потере доступа к узлу.
`limit_safepolicy_1`	Блокирует доступ к оболочке `bash` для всех пользователей, кроме `root`.
`limit_safepolicy_2`	Блокирует выполнение скриптов и команд через интерпретаторы (`bash`, `sh` и другие) для всех пользователей, кроме `root`.
`limit_safepolicy_3`	Отключает автоматическую настройку сетевых интерфейсов и подключений, что влияет на работу служб и приложений, зависящих от динамического управления сетью. Система становится более статичной относительно сетевых настроек, так как требуется ручное или централизованное управление. Если текущий сеанс SSH будет прерван, повторно запустите сценарий после восстановления доступа.
`limit_safepolicy_7`	Блокирует системный механизм `ptrace` для всех пользователей, включая администраторов. В результате использования правила могут не работать отладчики процессов, системные трассировщики и инструменты мониторинга, зависящие от `ptrace`. Ограничение может нарушить работу ПО, которому требуется анализ поведения процессов, а также препятствовать дальнейшему полноценному применению сценариев Ansible. Если текущий сеанс SSH будет прерван, повторно запустите сценарий после восстановления доступа.
`limit_safepolicy_8`	Блокирует возможность устанавливать бит исполнения (execute bit) для файлов. Это ограничение запрещает пользователям, кроме `root`, устанавливать права на выполнение файлов.
`limit_safepolicy_10`	Включает overlay в корневой файловой системе. После включения содержимое корневой файловой системы монтируется в overlay одновременно с файловой системой, хранящейся в памяти. Из-за этого все изменения файлов сохраняются только в памяти, а файловая система, хранящаяся на носителе, остается без изменений. После перезагрузки все изменения теряются, и система каждый раз загружается в исходном состоянии. Эта функция может применяться в тех случаях, когда носитель, на котором расположена корневая файловая система, аппаратно защищен от записи, либо необходимо программно защитить ее от изменений. Функционал overlay не касается файловых систем, хранящихся на отдельных разделах, отличных от корневого. Если, например, `/home/` хранится на отдельном разделе или носителе, вносимые в него изменения будут сохраняться после перезагрузки. Правило необходимо применять после выполнения всех настроек системы и при условии, что важные данные и настройки размещены на отдельных разделах, которые не попадают под overlay и сохраняют изменения после перезагрузки. Если текущий сеанс SSH будет прерван, повторно запустите сценарий после восстановления доступа. Возможна блокировка дальнейшего полноценного применения сценариев Ansible.
`auth_sudo_1`	Включает требование ввода пароля при использовании `sudo`. Перед применением заранее настройте пароль необходимым пользователям.

Правила, применяемые с обязательными переменными#

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

Правило	Особенности применения
`user_filter_1`	Управляет межсетевым экраном (Firewall) через утилиту `ufw` и может заблокировать дальнейший доступ по SSH. Перед применением задайте переменную `fstec_ufw_allowed_ports` и обязательно разрешите в ней порт SSH: правила разрешения из этой переменной создаются до включения запрета входящих подключений по умолчанию. Если пакет `ufw` в системе отсутствует (например, в облачных образах ОС Astra Linux Special Edition он может не входить в состав системы), при аудите правило помечается как `Not Applicable`, и межсетевой экран не настраивается. Если текущий сеанс SSH будет прерван, повторно запустите сценарий после восстановления доступа.
`user_maxlogins_1`	Ограничивает максимальное число одновременных сеансов доступа пользователей на узле значением `1`. Если текущий сеанс SSH будет прерван, повторно запустите сценарий после восстановления доступа.
`user_validityperiod_1`	Настраивает дату истечения срока действия будущих учетных записей. Для применения правила передайте переменную `fstec_user_expire_date` в формате `YYYY-MM-DD`.
`auth_login_10`	Блокирует локальный вход в систему для всех, кроме администраторов, на компьютерах, входящих в домен. Перед применением убедитесь, что необходимые пользователи имеют административные права.

Подготовка проекта Ansible#

На управляющем узле подготовьте ресурсы, необходимые для использования Ansible.

Создайте файл ansible.cfg со следующим содержимым:
ansible.cfg#
```
[defaults]
host_key_checking = False
inventory = inventory.yml
```
Создайте файл инвентаря inventory.yml, например:
inventory.yml#
```
---
all:
  hosts:
    node1.example.com:
      ansible_user: ansible
```
Создайте каталог playbooks/, а в нем – файл сценариев fstec.yml:
playbooks/fstec.yml#
```
---
- name: Apply FSTEC requirements
  hosts: all
  gather_facts: false
  become: true
  vars:
    fstec_order: "21"
    fstec_security_level: sl1
    # Разрешенные входящие порты межсетевого экрана UFW (правило user_filter_1);
    # без разрешения порта 22/tcp удаленный доступ по SSH будет заблокирован
    fstec_ufw_allowed_ports:
      - port: "22"
        proto: tcp
    fstec_list_of_packages_custom: # Пример пользовательского списка пакетов apt
      - network-manager
      - fly-dm
      - apache2
      - docker.io
      - sssd
      - bluez
      - quota
      - cups
  collections:
    - astra.hardening
  # Роли-зависимости astra.hardening.prepare и astra.hardening.preflight
  # выполняются автоматически перед ролью astra.hardening.fstec
  tasks:
    - name: Run remediation action from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
      vars:
        fstec_action: remediation
        # Дата истечения срока действия создаваемых учетных записей
        # (правило user_validityperiod_1); строка в формате YYYY-MM-DD.
        # Значение задается здесь, а не в переменных плея, поскольку профиль
        # 21_sl1 содержит собственное значение, перекрывающее переменные плея
        fstec_user_expire_date: "2027-12-31"

    - name: Reboot
      ansible.builtin.reboot:

    - name: Run audit action from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
      vars:
        fstec_action: audit
```
Здесь:
- fstec_order – номер приказа ФСТЭК России в виде строки: "17", "21", "31" или "239".
- fstec_security_level – класс защищенности или уровень защищенности: для приказа № 21 – от sl1 до sl4, для остальных приказов – от k1 до k3. Пара значений fstec_order и fstec_security_level выбирает предопределенный набор правил роли.
- fstec_ufw_allowed_ports – порты, для которых разрешаются входящие подключения при включении межсетевого экрана UFW (правило user_filter_1). Обязательно разрешите порт SSH, иначе доступ к узлу будет потерян.
- fstec_user_expire_date – срок действия создаваемых учетных записей (правило user_validityperiod_1); строка в формате YYYY-MM-DD. Значение передается в разделе vars задачи, подключающей роль для этапа remediation, а не в переменных плея: переменные профиля приказа имеют более высокий приоритет, чем переменные плея, и перекрывают их.
Плей Apply FSTEC requirements состоит из следующих этапов:
- Подготовка и предварительная проверка узла. Роли-зависимости astra.hardening.prepare и astra.hardening.preflight выполняются автоматически перед ролью astra.hardening.fstec: устанавливаются необходимые пакеты, собираются факты об ОС и проверяется наличие обязательных переменных. В выводе задания эти этапы выглядят как задачи с префиксами astra.hardening.prepare : и astra.hardening.preflight : в начале плея.
- Run remediation action from astra.hardening.fstec role – применение правил безопасности (remediation) и приведение параметров системы в соответствие требованиям ФСТЭК России, за исключением правил, перечисленных в значении переменной fstec_disabled_rules.
- Reboot – обязательная перезагрузка узла после применения правил. Перезагрузка требуется для применения части настроек безопасности.
- Run audit action from astra.hardening.fstec role – повторный аудит параметров безопасности после перезагрузки для проверки результата.

Добавьте в каталог playbooks/ два дополнительных сценария:

audit.yml – аудит узла без внесения изменений для фиксации исходного состояния и проверки результата:

playbooks/audit.yml#

---
- name: Audit FSTEC requirements
  hosts: all
  gather_facts: false
  become: true
  vars:
    fstec_order: "21"
    fstec_security_level: sl1
  collections:
    - astra.hardening
  tasks:
    - name: Run audit action from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
      vars:
        fstec_action: audit

fstec_custom.yml – пример выборочного применения правил и передачи пользовательских переменных, например, fstec_user_expire_date для правила user_validityperiod_1:

playbooks/fstec_custom.yml#

---
- name: Apply custom set of FSTEC rules
  hosts: all
  gather_facts: false
  become: true
  vars:
    # Пользовательский набор правил; переменные fstec_order
    # и fstec_security_level при этом не задаются
    fstec_custom_list_of_rules:
      - user_filter_1
      - user_maxlogins_1
      - user_validityperiod_1
    # Разрешенные входящие порты межсетевого экрана UFW (правило user_filter_1);
    # без разрешения порта 22/tcp удаленный доступ по SSH будет заблокирован
    fstec_ufw_allowed_ports:
      - port: "22"
        proto: tcp
    # Дата истечения срока действия создаваемых учетных записей
    # (правило user_validityperiod_1); строка в формате YYYY-MM-DD
    fstec_user_expire_date: "2027-12-31"
    fstec_list_of_packages_custom: # Пример пользовательского списка пакетов apt
      - sssd
  collections:
    - astra.hardening
  # Роли-зависимости astra.hardening.prepare и astra.hardening.preflight
  # выполняются автоматически перед ролью astra.hardening.fstec
  tasks:
    - name: Run remediation
      ansible.builtin.include_role:
        name: astra.hardening.fstec
      vars:
        fstec_action: remediation

    - name: Reboot
      ansible.builtin.reboot:

    - name: Run audit
      ansible.builtin.include_role:
        name: astra.hardening.fstec
      vars:
        fstec_action: audit

Если для запуска заданий автоматизации используется Automation Controller, зафиксируйте сделанные в проекте изменения и опубликуйте их в репозитории Git.

Проверка настроек систем защиты по умолчанию#

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

в графическом режиме на управляемом узле;
в графической консоли Astra Automation.

Графический режим на управляемом узле#

Полная проверка поведения Astra Linux Special Edition 1.8 с настройками систем безопасности по умолчанию занимает длительное время. В демонстрационных целях проверьте только часть из них:

На управляемом узле авторизуйтесь с привилегиями администратора.
Запустите утилиту «Монитор безопасности»: Пуск ‣ Параметры ‣ Параметры системы.
В дереве настроек выберите Безопасность ‣ Монитор безопасности.
Нажмите на ссылку Нажмите сюда, для запроса аутентификации.
Введите пароль.
Убедитесь, что в списке Подсистемы безопасности отмечены красным следующие строки:
- блокировка системных команд (df, chattr, arp, ip, и т.д.);
- блокировка консоли для пользователей;
- блокировка интерпретаторов;
- блокировка макросов;
- запрет установки бита исполнения;
- межсетевой экран UFW — UFW не найден;
- системные ограничения ulimits;
- блокировка выключения/перезагрузки ПК для пользователей;
- запрет монтирования носителей непривилегированным пользователям;
- блокировка интерпретатора bash;
- режим работы файловой системы ОС - только чтение;
- ввод пароля для sudo;
- блокировка доступа пользователя root по протоколу SSH;
- защита SSH fail2ban;
- графический киоск.
В дереве настроек выберите Безопасность ‣ Пользователи и группы ‣ Пользователи.
Создайте непривилегированного пользователя.
Завершите работу с утилитой «Параметры системы».
Завершите активную сессию и авторизуйтесь в системе как непривилегированный пользователь.
Запустите утилиту «Терминал»: Пуск ‣ Программы ‣ Инструменты ‣ Терминал.
Убедитесь, что пользователю разрешено использование системной утилиты ip:
```
ip a
```
Когда использование утилиты разрешено, она выводит в терминал сведения об активных сетевых подключениях.

Графическая консоль Astra Automation#

Для проверки настроек систем защиты выполните действия, описанные в секции Запуск набора сценариев, однако на этапе создания шаблона задания укажите Playbook: playbooks/audit.yml вместо Playbook: playbooks/fstec.yml. В конце вывода задания задача Show FSTEC compliance report выводит отчет о состоянии правил: для узла с настройками по умолчанию значительная часть правил имеет статус compliant: false.

Запуск набора сценариев#

Способ запуска набора сценариев зависит от инструмента, используемого для управления задачами автоматизации.

Графическая консоль

Для запуска задания автоматизации с помощью графической консоли Astra Automation выполните следующие действия:

Для доступа к управляемому узлу создайте полномочие типа Machine.
Если для доступа к репозиторию с кодом проекта требуется авторизация, создайте полномочие типа Source Control.
Создайте проект со следующими свойствами:
- Название: ФСТЭК.
- Среда исполнения: выберите среду исполнения, использующую образ aa-full-ee.
  
  Примечание
  
  Среда исполнения на основе образа aa-full-ee используется в Automation Controller по умолчанию. Среду исполнения можно добавить самостоятельно, следуя инструкции.
- Тип системы управления исходным кодом: Git.
- URL системы управления исходным кодом: укажите ссылку на репозиторий с кодом проекта.
- Полномочие на систему управления исходным кодом: если для доступа к репозиторию с кодом проекта требуется авторизация, выберите созданное ранее полномочие типа Source Control.
Создайте обычный инвентарный список и добавьте в него сведения об управляемом узле.

Совет

В качестве источника сведений об управляемом узле можно использовать файл inventory.yml.
Создайте шаблон задания со следующими свойствами:
- Тип задания: Выполнение.
- Инвентарь: выберите инвентарь, созданный на предыдущем шаге.
- Проект: ФСТЭК.
- Playbook: playbooks/fstec.yml.
Запустите задание на основе созданного шаблона.

Ansible Navigator

При использовании Ansible Navigator для запуска сценария выполните команду:

ansible-navigator run playbooks/fstec.yml \
   --eei private-hub.example.com/aa-2.0/aa-full-ee

При этом открывается псевдографический интерфейс, в котором показывается ход выполнения задания, например:

  Play name                   Ok Changed Unreachable Failed Skipped Ignored In progress Task count  Progress
0│Apply FSTEC requirements  1181      80           0      0     177       0           0       1358  Complete

Для просмотра более подробной информации о ходе выполнения нажмите 0.

Выполнение сценария включает перезагрузку управляемого узла и может занимать более 20 минут.

Статус задания выводится в правом нижнем углу. Дождитесь перехода задания в статус Successful. После применения правил и перезагрузки задача повторного аудита Show FSTEC compliance report выводит отчет, в котором нет правил со статусом compliant: false.

Проверка состояния систем защиты#

Для проверки состояния систем защиты после настройки выполните следующие действия на настроенном узле:

Перезагрузите компьютер.
Авторизуйтесь от имени учетной записи с привилегиями администратора.
Запустите утилиту «Монитор безопасности»: Пуск ‣ Параметры ‣ Параметры системы.
В дереве настроек выберите Безопасность ‣ Монитор безопасности.
Нажмите на ссылку Нажмите сюда, для запроса аутентификации.
Введите пароль.
Убедитесь, что в списке Подсистемы безопасности уменьшилось количество строк, отмеченных красным.
Завершите работу с утилитой «Параметры системы».
Завершите активную сессию и авторизуйтесь в системе с учетными данными непривилегированного пользователя.
Запустите утилиту «Терминал»: Пуск ‣ Программы ‣ Инструменты ‣ Терминал.
Убедитесь, что теперь пользователю запрещено использование системной утилиты ip:
```
ip a
```
Когда использование утилиты запрещено, она выводит в терминал следующее сообщение:
```
bash: /usr/sbin/ip: Отказано в доступе
```

Особенности проекта#

Обратите внимание на следующие особенности выполненного проекта:

настройка параметров роли astra.hardening.fstec;
правила, необходимые для соответствия требованиям ФСТЭК России, но исключенные из роли astra.hardening.fstec;
способы получения информации о параметрах систем безопасности ОС до и после настройки.

Заключение#

В этом сценарии вы познакомились с основными шагами по настройке систем безопасности ОС Astra Linux Special Edition в соответствии с требованиями, изложенными в приказах ФСТЭК России:

Приказ № 17 от 11 февраля 2013 г.
Приказ № 21 от 18 февраля 2013 г.
Приказ № 239 от 25 декабря 2017 г.
Приказ № 31 от 14 марта 2014 г.

Из всей последовательности шагов важно выделить следующие действия:

проверка состояния систем защиты ОС до и после настройки;
создание и запуск набора сценариев Ansible, использующего роль astra.hardening.fstec.