Начните с точного соответствия дистрибутива профилю защиты. Без него – ни один лабораторный стенд не даст зелёный свет. Профиль – не рекомендация, а список конкретных требований: контроль целостности, разграничение доступа, идентификация, отчётность. Всё. Проверяйте, включена ли поддержка DAC, MAC и событийная модель – на уровне ядра и в userspace.
Нужны исходники? Конечно. Полный комплект: ядро, загрузчик, средства управления доступом, модули безопасности, служебные утилиты. Распаковали, проверили, описали. Без этого ни одна уполномоченная организация не возьмётся даже за приёмку. Сопроводите каждую сборку скриптом верификации. Пример:
sha256sum /opt/redos/bin/* > hashes.txt
Следующий шаг – изоляция. Минимизируйте влияние внешнего ПО. Забудьте про systemd-логгер на сетевом уровне. Всё локально. В auditd включите детализацию по PID и UID, а для объектов – по inode. Не делали раньше? Придётся. Это не опция, это требование для проверки неотказуемости событий.
Важно помнить: каждый модуль должен быть покрыт документацией – от архитектуры до интерфейсов безопасности. Без неё экспертиза будет отклонена.
Смотрите внимательно: версии компонентов не просто должны быть актуальны. Они должны быть стабилизированы. Использование свежих пакетов из unstable – прямой путь к провалу при проверке на воспроизводимость. Только закреплённые релизы. Конфигурации фиксируем через ansible-плейбуки. Например:
- name: Disable USB Storage
mount:
path: /media/usb
state: absent
Лицензии? Естественно, свободные. Но не все. Проверяйте наличие копий и соответствие типу использования. GPLv3 – допустим, но при условии полного раскрытия модификаций. BSD – предпочтительнее. В реестре ПО они учитываются по-разному. Убедитесь, что ваши зависимости туда входят. Нет – исключите.
Внимание! Использование неутверждённых криптосредств автоматически закрывает допуск к финальной аттестации. Используйте только те СКЗИ, что числятся в списке допущенных к применению в защищённых ИС.
Машинно-читаемые журналы – must-have. Используйте ausearch для формирования выгрузок. Анализ должен быть возможен без стороннего ПО. Идеально – консольный grep по логам. Никаких ELK-стеков, если они не сертифицированы.
Оформление отчётности – отдельный ад. Структура, принятая ФСТЭК, не терпит отступлений. Не сокращайте. Не пытайтесь оптимизировать. Подписи, печати, дата, серийник изделия. Всё в нужной форме, всё в нужном объёме. Примерный шаблон выдают в методичке 17.08.
Готовы пройти всё это? Тогда вперёд. И не рассчитывайте на то, что всё пройдёт с первого раза. Не пройдёт. Но это не повод откладывать. Это повод начать раньше.
Содержание статьи
Процедура подготовки документации Red OS для получения сертификата ФСТЭК
Сначала соберите полный список компонентов, входящих в поставку. Не поленитесь. Любая неучтённая библиотека – повод для отказа. Перечень должен включать как бинарные пакеты, так и зависимости, устанавливаемые при первом запуске. Выгрузка с помощью rpm:
rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" > packages.txt
После – маппинг компонентов на элементы модели угроз. Не просто «сетевой стек», а «стек TCP/IP с реализацией в ядре и userland-инструментами». Укажите точку входа, способ защиты, логи, исключения. Это костяк модели защищённости. Без него не примут даже титульный лист.
Документируйте архитектуру системы. Буквально. Блок-схемы, описание взаимодействий между подсистемами, контрольные точки. Формат – SVG или PDF. Не Word. Не PNG. Диаграммы должны быть читаемы без доп. ПО. Используйте graphviz:
dot -Tpdf security_model.dot -o model.pdf
Подготовьте руководство администратора. Не справочник. А описание действий в условиях реальной эксплуатации: настройка прав, аудит, обновления. Проверяющий не должен гадать, как запретить доступ к консоли. Он должен видеть конкретный шаг:
chmod 700 /usr/bin/loginctl
Техническое описание – отдельный блок. Все уязвимые места должны быть описаны с указанием механизмов защиты. ACL, SELinux, seccomp – в разрезе. Не «включено», а «запрещено выполнение syscalls группы SYS_ADMIN через фильтр по PID». Пример:
seccomp-bpf drop SYS_ADMIN pid=1324
Важно помнить: оформление нарушений в журнале – не прихоть. Без чётко определённых реакций и логов уровень доверия к сборке будет равен нулю.
Нормируйте отчётность. Все формы, листы регистрации, протоколы тестов – по ГОСТ. Используйте шаблоны 15408 и СТЭК-СТД-02. И никаких вольностей в формулировках. Пунктуация имеет значение. Серьёзно.
Последний рубеж – согласование документации с лабораторией. Сделайте предварительное ревью. Не подавайте сырой пакет. Это не убыстряет – это замедляет. Проверяющие тоже люди, но без пощады к шаблонным фразам и пустым диаграммам.
Помните! Даже если система работает безупречно, плохо оформленный комплект документов перечёркивает всё. Работает код – молодец. Не работает бумага – всё, в пролёт.
Особенности проведения испытаний Red OS на соответствие требованиям безопасности информации
Первое, что нужно – отключить все неиспользуемые сервисы. Абсолютно. Никаких avahi-daemon, cups и прочего хлама. Проверяющие будут сканировать открытые порты, искать ненужные демоны. И найдут.
Далее – настройка целостности. Без integrity-audit или AIDE не начнётся ни один сценарий. Конфиг минимален, но требует точности:
/etc/aide.conf
/etc FIPSRMD5 sha512
Тестируют всё: контроль доступа, событийность, реакцию системы на нарушения. Это не просто чекбокс. Это реальный запуск эксплойта. Да, они будут ломать ядро. Да, попытаются сбросить SELinux. И да, вас обвинят, если не сработает защита. Настраивайте audit.rules заранее:
-w /etc/shadow -p wa -k passwd_change
Процедура проверки MAC – кошмар. Нужно не просто включить SELinux, нужно чтобы он логировал, запрещал и был в режиме enforcing. Не permissive, не disabled, а только жесткий режим. Убедитесь:
getenforce
Ответ должен быть один: Enforcing. Всё остальное – отказ. Хотите пройти? Сделайте собственный SELinux-профиль под систему. Ручками.
Внимание! Использование стандартных политик типа targeted – путь в никуда. Проверяющие сравнивают профили с описанием архитектуры. Несовпадение – дисквалификация.
Вход по SSH? Только с двухфакторкой. Или через USB-ключ. Пароли – мимо. Логины – через PAM, с логгированием и ограничением по IP. Пример:
auth required pam_tally2.so deny=3 unlock_time=600
Атаки проводят вручную. Никаких автоматизированных сканеров. Человек с опытом просто лезет в систему. Смотрит, где дырка. И она будет. Ваша задача – чтобы она не дала контроль над системой. Уязвимость не запрещена. Эксплуатация – да.
- Проверяется раздельность ролей: администратор, пользователь, аудитор
- Оцениваются сценарии восстановления после сбоев
- Лог-файлы должны быть подписаны
- Каждое событие – с точным timestamp и user context
Особое внимание – криптосредствам. Только допущенные алгоритмы, только утверждённые библиотеки. OpenSSL? Только если пересобран с GOST-режимом и без динамических линковок. Выглядит так:
./config enable-gost no-shared
Важно помнить: каждая строка в протоколе испытаний должна соответствовать функции в документации. Несоответствие – повод признать результат недействительным.
Роль разработчика и заказчика в процессе сертификации Red OS
Разработчик отвечает за то, чтобы всё работало. Не просто «запускалось», а соответствовало методике проверки. Архитектура, исходники, контрольные суммы, патчи – всё должно быть документировано. И да, без живого доступа к репозиториям никто даже не посмотрит в вашу сторону. Публичные ссылки? Нет. Только архив с цифровой подписью и расшифровкой по SHA256:
sha256sum -c redos_sources.sha256
Заказчик – тот, кто платит и тот, кто подписывает. Его зона – составление технического задания. Именно он указывает, какие уровни доверия нужны, какие угрозы рассматриваются, какой контур эксплуатации. Неверно составленное ТЗ – точка отказа всей процедуры. Не утвердили модель угроз? Всё, стоп. Переписывайте.
Разработчик обязан обеспечить сборку по воспроизводимому сценарию. Один Makefile – не прокатит. Нужна автоматизированная система, фиксирующая версии, зависимости и флаги компиляции. Используйте rpmbuild или mock. Пример шаблона для systemd:
rpmbuild -ba SPECS/systemd.spec --define "_build_id_links none"
Заказчик участвует в проверках. Да, лично. Представитель должен быть в лаборатории при испытаниях, подтверждать соответствие протоколам, подписывать акты. Отказ от участия = аннулирование.
Важно помнить: разработчик не может самостоятельно подать комплект на оценку. Инициатива должна исходить от заказчика. Иначе весь процесс будет признан недействительным.
Ошибка номер один – попытка всё делегировать. Так не работает. Разработчик пишет код, сопровождает и объясняет. Заказчик – ведёт документацию, финансирует работы, принимает результаты. Без симметрии – всё рушится. Лаборатория не станет угадывать, кто отвечает за тестовые сценарии и кто должен устранять баги.
При доработке ПО обязанность разработчика – зафиксировать изменения, пересобрать компоненты, обновить документацию. Не просто внести правку в исходники. А сформировать новый релиз с инкрементной нумерацией и указанием причины изменений. Пример:
git tag v1.2.3-securityfix
Роль заказчика – проконтролировать, что изменения не нарушили допуски по модели угроз. Не знал – не освобождает. Проверяющий смотрит на это первым делом. Несоответствие хэшей – тревога. Несовпадение версий в отчётах – повторная проверка. Бюджет улетает, сроки горят.
Помните! Разделение зон ответственности – не формальность. Это механизм выживания проекта в условиях формальной оценки и жёсткого контроля. Ошиблись в ролях – проиграли.
Разработчик – машина исполнения. Заказчик – директива. Если один из них выпадет – процесс схлопнется. Внутри всё держится на точности. Наружу – только результат. И он должен быть непробиваемым. Без «но».
Требования к аппаратной платформе при сертификации Red OS по ФСТЭК
Используйте только те серверы и рабочие станции, которые прошли регистрацию в Едином реестре отечественного оборудования. Не ищите обходы. Не работаете на зарегистрированной платформе – даже не начинайте проверку. Пример: Эльбрус 8С или Байкал-М.
Проверьте поддержку процессорной архитектуры ядром. Поддержка не на бумаге, а реально – через dmesg и lscpu. Ошибки microcode в логах – отбой. Процедура останавливается. Модули ядра должны подгружаться автоматически. Без костылей.
dmesg | grep microcode
modprobe -c | grep platform
Платформа обязана обеспечивать загрузку через контролируемый механизм. Никаких UEFI Secure Boot, если не реализована собственная цепочка доверия. И никакого внешнего firmware без исходников. Сборка должна быть воспроизводима, BIOS – задокументирован.
Важно! Если не можете описать процедуру инициализации железа с точки зрения модели угроз – не пройдёте. Контроль на уровне загрузчика обязателен.
Сетевые адаптеры – без поддержки удалённого управления. AMT, iLO, IPMI – вырезать. Или отключать на аппаратном уровне. Наличие активных out-of-band каналов – автоматическая дисквалификация. Проверьте:
lspci | grep -i ethernet
dmidecode | grep -i remote
USB – минимально. Лучше – только клавиатура. Всё остальное – через ACL. И с логгированием в /var/log/audit/audit.log. Иначе не покажете управляемость устройств, и проверяющие это обязательно спросят.
- Видеокарты – без закрытых драйверов. Только open-source
- Дисковая подсистема – с поддержкой dm-integrity или аналогов
- RAID – аппаратный, но задокументированный
- Чип TPM – не обязателен, но плюсуется
Периферия – головная боль. Мыши, принтеры, мониторы – описываются. Вплоть до модели и версии прошивки. Если нет – убираем. Скрываем через udevadm или udev rules:
SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", ATTR{idProduct}=="YYYY", OPTIONS+="ignore_device"
Аппаратная платформа должна быть протестирована и приложена в виде спецификации. Да, целиком. Да, с номерами партий. Да, с серийными номерами. Нет – не примут. Даже если работает идеально. Бумага важнее исполнения.
Помните! Если при проверке выяснится, что тесты проводились на другой ревизии оборудования, результаты будут обнулены. Без права на оспаривание.
В конце – сделайте отчёт о совместимости. Не по шаблону. А со скриншотами, логами, дампами. И не забудьте подписать. Иначе вся конфигурация превратится в бесполезный набор железок. Всё, что не описано – считается недоверенным. Всё, что описано – может быть проверено.