Функции безопасности#

Общие механизмы

1. Не запускаются контейнеры под UID 0 (root).

2. Не используются узловые ports.

3. Не запускаются привилегированные контейнеры.

4. Приложение не использует Persistent Volumes (PV) и любые другие решения, требующие персистентного хранения данных на стороне платформы k8s.

5. Не включена настройка automountServiceAccountToken для монтирования token сервисного аккаунта в файловой системе контейнера.

6. Осуществляется проверка отсутствия избыточных capabilities.

7. Проверка выдачи прав к volumes в соответствии с принципом наименьших привилегий.

8. При извлечении образов контейнеров из централизованного репозитория образов контейнеров исключено их кеширование.

9. При извлечении образов контейнеров из централизованного репозитория образов контейнеров осуществляется проверка их целостности. Ссылка на образ контейнера содержит его хеш-сумму sha256.

10. Не запускается контейнер с правами внесения изменений в его корневой файловой системе.

11. Система соответствует требованиям к обеспечению информационной безопасности в автоматизированных системах и обеспечивает:

• готовность и доступность данных и системы в целом всегда, когда в них возникнет необходимость;

• целостность и достоверность информации, обрабатываемой в системе;

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

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

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

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

13. В Системе реализованы следующие механизмы безопасности прикладного уровня:

• администрирование;

• управление правами доступа;

• идентификация и аутентификация;

• защита от несанкционированного доступа.

Механизмы управления правами доступа

Реализованы следующие механизмы управления правами доступа в Системе:

• механизм разграничения прав доступа реализован на основе ролей;

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

• ролевая модель охватывает и определяет доступ к данным, хранимым и обрабатываемым в Системе;

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

Механизмы идентификации и аутентификации

1. Взаимодействие с внешними системами поддерживает защиту интерфейсов взаимодействия с помощью TLS 1.2 и mTLS 1.2 и выше, с проверкой клиентского сертификата на разрешение к использованию при доступе к сервисам.

2. При взаимодействии с внешними системами поддерживается возможность контроля доступа к собственным интерфейсам на уровне сервисов и конкретных операций, реализуемых сервисом.

Механизмы защиты от несанкционированного доступа

1. Для обеспечения защиты от несанкционированного доступа в Системе реализованы:

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

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

2. Для взаимодействий между проектами и внешними АС обеспечивается двусторонняя аутентификация.

3. Все исходящие взаимодействия реализованы только с использованием mTLS 1.2 и выше (TLS 1.2).

4. Для безопасности всех входящих взаимодействий до проекта используется TLS 1.2 и выше.

Требования к архитектуре АС

1. Не реализованы внутри приложения функции изменения бизнес-логики самого или других приложений. При необходимости изменения бизнес-логики приложения формируется новый релиз приложения.

2. Создание и конфигурирование настроек кластера, его сопровождение и мониторинг проводятся исключительно в соответствии с утвержденными распоряжениями и регламентами.

Требования к образам контейнеров

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