Памятка разработчика#
Проектирование ПО и его архитектуры#
Описание архитектуры:
Сведения о принятых подходах и принципах к проектированию архитектуры ПО (инкапсуляция, инверсия зависимостей, уникальность, разделение задач, применение заимствованных компонентов и т.п)
Назначение ПО и сценарии его использования
Описание среды функционирования
Ограничение и указания по применению ПО
Проект ПО на уровне подсистем (модулей), включающий описание их назначения, структуры, особенностей реализации, применяемых языков программирования, взаимодействия друг с другом и другим ПО с указанием соответствующих интерфейсов, сетевых портов, протоколов и т.п.
Соблюдение требований, предъявляемых Astra Linux к прикладному ПО#
При применении стороннего программного обеспечения, образующего совместно с ОС доверенную программную среду, необходимо выполнять требования раздела 17.3 эксплуатационного документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1» РУСБ.10015-01 97 01-1
Исключение влияния на сертифицированные функции безопасности Astra Linux#
Исключение влияния на функции безопасности операционной системы
Не дублировать функции безопасности Astra Linux, не заменять пакеты, реализующие функции безопасности Astra Linux (https://wiki.astralinux.ru/x/5o3NAw);
Интегрироваться с функциями безопасности Astra Linux;
Проработать возможность функционирования НЕ под root или учетной записи высокоцелостного пользователя.
Архитектурный анализ#
Исследования кода при сертификации проходят в полном объеме и максимально глубоко для кода, составляющего поверхность атаки. Важно максимально сузить поверхность атаки.
Примечание
Поверхность атаки - совокупность интерфейсов и реализующих их модулей, посредством использования которых могут быть реализованы угрозы безопасности.
Минимизация поверхности атаки#
разработка должна сопровождаться моделированием;
должен соблюдать принцип разграничения и минимизации прав доступа, в том числе с использованием микросервисов, контейнеризации, виртуализации;
минимизация внешних интерфейсов;
приоритет использования управляемых языков, безопасных компиляторов;
проведение инвентаризации и исключение избыточности модулей в составе ПО (тем более для реализации прикладных бизнес-процессов, необязательных для функционирования)
определение в модулях, реализующих функции безопасности, значимые участки кода: только те, которые непосредственно относятся к реализации функций;
использование интерпретаторов из состава Astra Linux (репозиторий main).
Требования к исходному коду#
На все, компоненты, которые входят в состав ПО и которые непосредственно нужны для его функционирования, нужны исходные тексты.
Не допускается применение сторонних библиотек, модулей и т.д., на которые у разработчика не будет исходных текстов и лицензионных соглашений на использование.
В исходных текстах не должно быть бинарных файлов.
Примечание
Кроме тех компонентов, которые есть в составе основного (main) репозитория Astra Linux (такие компоненты рекомендуется вынести за пределы своего кода и предъявить в документации условия/требования к среде функционирования).
Если такие компоненты из состава Astra Linux есть, но не в том качестве, которое нужно для вашего ПО (например, не та версия), то:
компоненты Astra Linux, которые реализуют или поддерживают выполнение функций безопасности, - менять запрещено https://wiki.astralinux.ru/x/5o3NAw. подстраиваемся под них;
компоненты Astra Linux, не реализующие функции безопасности и не поддерживающие их или забираете себе в состав ПО и осуществляете сопровождение (они теперь ваши), или путем запроса в Astra Linux в ее состав включаются нужные пакеты.
Исходные тексты должны быть полные, достаточные для сборки дистрибутива. В исходных текстах не должно быть файлов, не использованных в процессе компиляции и сборки (избыточные файлы).
Исходные тексты не должны содержать файлов исходных текстов, разработанных на языках программирования, не заявленных в документации.
Необходимо использовать языки программирования, для которых есть анализаторы, это:
C, C++, Java, Go, Kotlin and C#, ABAP, Apex, ASP.NET, COBOL, Objective-C, Delphi, Groovy, HTML5, Java for Android, JavaScript, JSP, Pascal, Perl, PHP, PL/SQL, T/SQL, Python, Ruby, Rust, Scala, Solidity, Swift, TypeScript, VBA, VB.NET, VBScript, Visual Basic 6.0, Vyper, 1C, LotusScript, Dart, Rust.
НЕ использовать низкоуровневые языки, для которых нет анализаторов. Для таких языков выполняется только ручной анализ, для которого нормативным документом ФСТЭК России установлено ограничение в 10 000 строк. ИЛИ не допускать использование таких языков для модулей, входящих в поверхность атаки
Исключить из состава файлы, фактически не входящие в состав ПО, а лишь участвующие в процессе сборки и/или которые может обеспечить среда функционирования.
В исходных текстах не должно быть файлов, не реализующих функционал изделия (например, средства сборки, скрипты сборки, сборочное окружение, никаких компиляторов и прочих средств, которые применяются только для сборки, но не для функционирования потом продукта)
К среде функционирования должны быть предъявлены требования о наличии необходимого предустановленного ПО (не из состава продукта. Например, если ваше ПО используется СУБД изд состава ОС, - то требование о ее наличии в среде функционирования должны быть установлены в документации на разрабатываемое ПО).
Провести инвентаризацию кода. Запустить утилиту Sloc для определения применяемых языков программирования и их объема.
Требования к загрузочному модулю (установочному диску, дистрибутиву)#
Провести инвентаризацию исполняемых файлов: разобрать используемые файлы на группы:
собственный код (собирается из исходников), поставляется потребителю и необходимо для функционирования ПО по назначению;
заимствованное ПО (отсутствующее в составе основного репозитория Astra Linux (собирается из исходников), поставляется потребителю и необходимо для функционирования ПО по назначению;
заимствованное ПО, нужное только для сборки кода (используется в виде готовых предсобранных файлов);
заимствованное ПО, нужно только для разработки кода (используется в виде готовых предсобранных файлов).
Исключить из состава установочного диска файлы, фактически не входящие в состав ПО, а лишь участвующие в процессе сборки и/или которые может обеспечить среда функционирования.
Не должно быть файлов, не реализующих функционал изделия (например, средства сборки, скрипты сборки, сборочное окружение, никаких компиляторов и прочих средств, которые применяются только для сборки, но не для функционирования потом продукта)
В состав установочного дистрибутива (установочных файлов) должны входить только файлы, собранные из исходных текстов. Включение в состав «предсобранного» ПО — запрещено! (Кроме тех компонентов, которые есть в составе основного (main) репозитория Astra Linux. Они могут быть в предсобранном виде, тогда Инструкция по сборке должна учитывать нюансы, как Astra Linux используется при сборке)
Загрузочные модули должны формироваться строго в соответствии с «Инструкцией по сборке» из исходных текстов.
Включить в состав установочного диска файл с перечислением ВСЕХ исполняемых файлов продукта и их контрольных сумм
В результате сборки должны получить следующее:
логи сборки;
логи трассировки;
дистрибутив (установочные фалы).
Важно
При компиляции из исходников, написанных на компилируемых языках (С++ и прочих), исполняемые файлы обязательно должны быть «подписаны» на ключах Astra Linux для обеспечения функционирования в дальнейшем в режиме замкнутой программной среды.
Требования к процессу сборки#
Описание состава стенда «сборки» и среды сборки:
перечень технических средств (с техническими требованиями к ним, например, наличие устройств чтения/записи DVD-дисков и другими требованиями к минимальной конфигурации);
перечень программных средств (описание системы сборки, применяемых программных средств сборки и их опций (настроек), применяемого программного обеспечения (зависимых «пакетов») с указанном версионности и источника получения);
перечень программных дисков изделия для сборки (как минимум, исходные тексты).
Описание конкретных действий по:
подготовке стенда;
формированию бинарных пакетов (исполняемых файлов);
формированию образа установочного диска;
запись образа на диск;
фиксация контрольной суммы образа.
Требования к сборке:
обеспечивалась «повторяемость» сборки;
ПО, поставляемое потребителю, собиралось строго из исходных текстов (не включало готовые исполняемые модули, полученные от 3 стороны);
в процессе сборки все необходимые средства сборки были предустановлены в среде сборки, «выкачивание» онлайн необходимых компонент в процессе сборки — запрещено! Допускается использование корпоративной среды с заранее помещенными в нее нужными пакетами и зависимостями из интернета. Допускается выкачивать нужные пакеты и зависимости из интернета в процессе подготовки сборочной среды, в процессе самой сборки - нет.
Требования к тестированию#
Должны быть обеспечено наличие модульных (unit-тестов), регрессионных и автотестов на все модули ПО, составляющие поверхность атаки как минимум, как максимум - на все функциональные модули
Необходимо вести учет наличия (и рекомендуется — покрытия) тестов на модули ПО, осуществлять их актуализацию.
Тестовая документация должна включать:
план тестирования, содержащий тесты, которые необходимо выполнить, описание сценариев проведения каждого теста, учитывающее зависимости последовательности выполнения тестов от результатов других тестов, описание ресурсов, необходимых для проведения тестирования;
описание сопоставления тестов с интерфейсами функций безопасности средства, описанными в функциональной спецификации, демонстрирующее их полное покрытие тестами;
описание ожидаемых результатов тестирования, свидетельствующих об успешности выполнения тестов;
описание фактических результатов тестирования, их сопоставление с ожидаемыми результатами тестирования и на его основе – выводы об успешности тестов.
Тестовая документация на средство должна включать:
описание сопоставления тестов с подсистемами средства, демонстрирующее их полное покрытие тестами.
При проведении тестирования средства проводится оценка влияния на подсистемы средства, реализующие функции безопасности, иных подсистем средства.