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

Содержание

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

Использование роли 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/
```

Excluded Rules#

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

Эти правила требуют предварительной подготовки узла и осознанного выбора, поскольку их применение может привести к следующим последствиям:

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

Важно

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

Ниже приведены рекомендации по применению этих правил.

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

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

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

Создайте файл ansible.cfg со следующим содержимым:
ansible.cfg#
```
[defaults]
host_key_checking = False
inventory = inventory.yml
```

Создайте файл инвентаря inventory.yml, например:

inventory.yml#

---
all:
  hosts:
    node1.example.com:
      ansible_host: 192.168.56.11
      ansible_user: ansible

Создайте каталог playbooks/, а в нем – файл сценариев fstec.yml:
playbooks/fstec.yml#
```
---
- hosts: all
  gather_facts: false
  become: true
  vars:
    fstec_order: 21
    fstec_security_level: sl1
  collections:
    - astra.hardening
  tasks:
    - name: Run prepare task from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
        tasks_from: prepare
      vars:
        fstec_list_of_packages_custom: # Example custom apt list
          - network-manager
          - fly-dm
          - apache2
          - docker.io
          - sssd
          - bluez
          - quota
          - cups

    - name: Run preflight task from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
        tasks_from: preflight

    - name: Run remediation action from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
      vars:
        fstec_action: remediation

    - 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
```
В этом файле описаны основные этапы применения роли astra.hardening.fstec:
- Prepare for FSTEC hardening – подготовка узла к применению правил для выбранного приказа или набора правил. На этом этапе выполняются действия, необходимые для корректной работы роли (например, установка пакетов и подготовка окружения).
- Preflight for FSTEC hardening – предварительная проверка готовности узла. На этом этапе роль собирает необходимые факты и выполняет проверки, которые позволяют выявить несовместимости до внесения изменений.
- Apply FSTEC requirements – применение правил безопасности (remediation) и приведение параметров системы в соответствие требованиям ФСТЭК России, за исключением настроек, перечисленных в значении переменной disabled_rules.
- Reboot – обязательная перезагрузка узла после применения правил. Перезагрузка требуется для применения части настроек безопасности.
- Audit FSTEC requirements – повторный аудит параметров безопасности после перезагрузки для проверки результата.

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

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

playbooks/audit.yml#

---
- 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#

---
- hosts: all
  become: true
  vars:
    fstec_custom_list_of_rules:
      - user_filter_1
      - user_maxlogins_1
      - user_validityperiod_1
    fstec_user_expire_date: 2026-12-31
    fstec_disabled_rules:
      - auth_login_10
      - auth_sudo_1
      - limit_safepolicy_1
      - limit_safepolicy_2
      - limit_safepolicy_3
      - limit_safepolicy_7
      - limit_safepolicy_8
      - limit_safepolicy_10
      - user_mic_4
  tasks:
    - name: Run prepare task from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
        tasks_from: prepare
      vars:
        fstec_list_of_packages_custom:
          - sssd

    - name: Run preflight task from astra.hardening.fstec role
      ansible.builtin.include_role:
        name: astra.hardening.fstec
        tasks_from: preflight

    - 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.

Запуск сценария#

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

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

Для запуска задания автоматизации с помощью графической консоли 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   5       0           0       0       0       0           1           6   ▇▇▇▇▇▇

^b/PgUp page up     ^f/PgDn page down     ↑↓ scroll     esc back     [0-9] goto     :help help      Running

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

Статус задания выводится в правом нижнем углу. Дождитесь перехода задания в статус Successful.

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

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

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