Стандартизация в безопасности: ISO/IEC 19249

Безопасность информационных систем часто воспринимается как набор разрозненных практик: шифрование, антивирусы, firewalls, контроль доступа. Но у международных организаций вроде ISO (International Organization for Standardization) и IEC (International Electrotechnical Commission) другой подход. Они формализуют базовые принципы, из которых должны исходить архитекторы и инженеры при проектировании безопасных систем.

Одним из таких документов является ISO/IEC 19249:2017 “Information technology – Security techniques – Catalogue of architectural and design principles for secure products, systems and applications”.

Он описывает ключевые архитектурные и проектные принципы, которые должны учитываться при создании приложений, сервисов и инфраструктуры.

Зачем это нужно?

• Унификация терминов и подходов: инженеры в разных странах и компаниях говорят на одном языке.
• Повторяемость: одни и те же принципы применяются для разных систем и технологий.
• Практическая ценность: это не «бумажная бюрократия», а набор проверенных временем концепций, которые повышают надёжность и безопасность продуктов.

Пять архитектурных принципов ISO/IEC 19249

1. Разделение доменов (Domain Separation)

Каждый набор связанных компонентов (приложения, данные, сервисы) должен существовать в своём «домене» с общими атрибутами безопасности.

Пример: уровни привилегий процессора x86 — ядро ОС работает в ring 0, а пользовательские приложения в ring 3. Так предотвращается вмешательство одних процессов в работу других.

На практике: в Kubernetes мы используем namespaces и RBAC, чтобы разграничить доступ между командами и приложениями.

2. Многоуровневость (Layering)

Система делится на уровни (слои), где каждый слой предоставляет сервис верхнему и использует сервис нижнего. Это позволяет накладывать политику безопасности и контролировать корректность работы.

Пример: модель OSI в сетях — каждый слой выполняет свою функцию, а вместе они обеспечивают передачу данных.

На практике: в DevOps принято использовать Defence in Depth — безопасность внедряется на каждом уровне: сеть, контейнер, кластер, приложение.

3. Инкапсуляция (Encapsulation)

Принцип скрытия реализации и управления доступом. В ООП доступ к данным осуществляется только через методы объекта, а не напрямую.

Пример: в API мы предоставляем метод increment(), вместо прямой работы с переменной seconds.

На практике: использование API Gateway или сервисных контрактов — сервисы общаются только через строго определённые интерфейсы.

4. Избыточность (Redundancy)

Избыточные компоненты позволяют сохранить работоспособность и данные даже при сбоях.

Примеры:

• сервер с двумя блоками питания,
• массив RAID 5,
• резервные реплики базы данных.

На практике: SRE всегда планируют отказоустойчивость — репликации PostgreSQL, multi-AZ в облаках, backups + restore testing.

5. Виртуализация (Virtualization)

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

Помимо экономии ресурсов, это усиливает безопасность: контейнер или виртуальная машина изолированы друг от друга.

На практике: в Kubernetes мы используем контейнеры и виртуализацию для sandboxing подозрительных процессов или безопасного анализа вредоносного ПО.

Пять проектных принципов ISO/IEC 19249

1. Принцип наименьших привилегий (Least Privilege)

Давать только минимально необходимые права для выполнения задачи.

Пример: пользователю нужны права read, но не write.

На практике: в CI/CD — сервисные аккаунты GitLab Runner получают только доступ к нужному namespace, а не ко всему кластеру.

2. Минимизация поверхности атаки (Attack Surface Minimisation)

Чем меньше точек входа в систему, тем меньше вероятность компрометации.

Пример: отключение ненужных сервисов в Linux.

На практике: ограничение open ports в Kubernetes Pod, использование NetworkPolicy, удаление неиспользуемых API эндпоинтов.

3. Централизованная валидация параметров (Centralized Parameter Validation)

Все входные данные должны проверяться в одном месте, а не по-разному в каждом сервисе.

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

На практике: использование OpenAPI validation или middlewares в микросервисах.

4. Централизованные сервисы безопасности (Centralized General Security Services)

Общие механизмы безопасности выносятся в централизованное решение.

Пример: единый сервер аутентификации (Keycloak, OAuth2 Proxy) вместо множества разных реализаций в каждом сервисе.

На практике: SSO (Single Sign-On), централизованный Vault для хранения секретов.

5. Подготовка к ошибкам и исключениям (Preparing for Error and Exception Handling)

Ошибки должны обрабатываться безопасно и предсказуемо.

Пример: если firewall «падает», он должен блокировать трафик по умолчанию, а не пропускать всё.

На практике: дружелюбные ошибки в приложениях («Произошла ошибка, попробуйте позже») вместо дампов памяти, которые могут раскрыть конфиденциальные данные.

Заключение

ISO/IEC 19249 не предлагает конкретных технологий или инструментов. Это набор принципов, которые помогают инженерам мыслить правильно и проектировать системы так, чтобы безопасность была встроена в архитектуру, а не «прикручена сверху».

Для DevOps и SRE это особенно важно: мы строим инфраструктуру, которая должна быть устойчивой, масштабируемой и безопасной — и международные стандарты дают универсальный язык и набор правил для этого.