Kubernetes и ISO 27001: какие контроли закрывает архитектура

Коротко. Платформа Kubernetes способна структурно закрыть примерно дюжину контролей Приложения A, то есть архитектура их обеспечивает, а не политика их описывает: управление доступом, сетевая сегментация, управление конфигурациями, управление изменениями, журналирование и управление ёмкостью. Она не может закрыть ни один контроль, предметом которого является решение, обязанность или человек, а это большая часть организационной и кадровой тем. Типичный провал — не отсутствующий контроль, а контроль, который платформа обеспечивает, но подтвердить его нельзя, потому что доказательства вышли за пределы срока хранения по умолчанию.

ISO 27001:2022 перечисляет в Приложении A 93 контроля по четырём темам: организационная, кадровая, физическая и технологическая. Платформенные команды обычно читают технологическую тему, узнают в ней почти всё и заключают, что кластер делает основную работу. Аудиторы обычно читают организационную тему, не находят её в кластере и заключают, что кластер ни при чём. Оба прочтения ошибочны одинаково: они считают платформу либо всем набором контролей, либо ничем, тогда как она представляет собой конкретный и устойчивый срез.

Этот текст описывает этот срез. Предполагается платформа, построенная так, как её сейчас строит большинство грамотных команд: декларативные манифесты в Git, непрерывная сверка состояния, контроль допуска, обеспечивающий политику, RBAC, в котором не у всех cluster-admin, и работающая сетевая политика. Ничего экзотического.

Содержание

Что архитектура обеспечивает структурно
Что она обеспечивает только при соответствующей настройке
Чего не закроет ни один кластер
Проблема доказательств, которая и есть настоящая
Как это ложится на Стандарты обеспечения информационной безопасности ОАЭ

1. Что архитектура обеспечивает структурно

Это те контроли, где правильно построенная платформа не является доказательством контроля, а является самим контролем. Различие важно: здесь аудитор, изучающий кластер, изучает сам контроль, а не отчёт о нём.

A.5.15 Управление доступом и A.8.2 Права привилегированного доступа. RBAC в Kubernetes — это реальная, принудительно применяемая модель авторизации с запретом по умолчанию. Привязывайте роли к группам из поставщика идентификации, а не к отдельным людям, и процесс приёма, перевода и увольнения превращается в изменение членства в группе, а не в операцию с кластером. Ловушка: почти в каждом кластере есть хотя бы одна долгоживущая сервисная учётная запись с cluster-admin, созданная при установке и никогда не удалённая, — она тихо разбирает контроль по частям.

A.8.20 Сетевая безопасность и A.8.22 Разделение сетей. NetworkPolicy обеспечивается CNI, а не документируется на схеме. Запрет по умолчанию на каждое пространство имён плюс явные разрешающие правила — это контроль сегментации, который аудитор может проверить попыткой соединения.

A.8.9 Управление конфигурациями. Самое сильное соответствие во всём стандарте. Декларативные манифесты с непрерывной сверкой означают, что дрейф конфигурации обнаруживается и откатывается самой системой, а это более сильное утверждение, чем то, что любая организация может сказать о своих серверах. Политика допуска превращает стандарт в исполняемое правило.

A.8.32 Управление изменениями. Изменение — это pull request с ревью, утверждением и сверкой состояния. Запись об утверждении и есть доказательство контроля, и она существует независимо от того, вспомнит ли кто-нибудь её подготовить.

A.8.6 Управление ёмкостью. Requests, limits и автомасштабирование — это управление ёмкостью, выраженное кодом, с историческими данными за ним.

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: payments
spec:
  podSelector:
    matchLabels: {app: ledger}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: {name: edge}
          podSelector:
            matchLabels: {app: gateway}
      ports:
        - protocol: TCP
          port: 8443

A.8.20 и A.8.22 как принудительно применяемые объекты, а не схема

2. Что она обеспечивает только при соответствующей настройке

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

A.8.7 Защита от вредоносного ПО и A.8.8 Управление техническими уязвимостями. Сканирование образов в конвейере необходимо, но недостаточно: сканирование на этапе сборки ничего не говорит об образе, который работает уже четыре месяца. Контроль закрывает контроль допуска, отклоняющий неподписанные или незакреплённые образы, плюс регулярная пересборка. Политика ниже закрывается при отказе, и только такая настройка что-то значит.

yaml

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-signed-images
spec:
  failurePolicy: Fail            # closed, not open
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]
  validations:
    - expression: >
        object.spec.template.spec.containers.all(c,
          c.image.startsWith('registry.internal/') &&
          c.image.contains('@sha256:'))
      message: "images must be internal and pinned by digest"

A.8.8 обеспечивается на допуске и закрывается при отказе

A.8.24 Использование криптографии. Секреты в Kubernetes закодированы в base64, а не зашифрованы, пока не настроено шифрование при хранении с использованием KMS. Аудиторы это знают и спрашивают. Внешний оператор секретов, забирающий их из настоящего менеджера секретов, — та схема, которая выдерживает этот вопрос, потому что она же отвечает, у кого ключ.

A.8.15 Журналирование и A.8.16 Мониторинг активности. Ответ на вопрос «кто что сделал» живёт в журнале аудита плоскости управления, а он часто выключен или включён со сроком хранения в несколько дней. Журналы нагрузок его не заменяют: они показывают, что сделало приложение, а не кто изменил платформу.

A.8.13 Резервное копирование информации. Копия etcd — это не копия платформы, как и копии томов без объектов, которые на них ссылаются. Контроль закрывается восстановлением, которое вы выполнили, а не задачей, которая отчиталась об успехе.

3. Чего не закроет ни один кластер

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

Три из них особенно часто ловят платформенно ориентированные организации:

A.5.7 Аналитика угроз и A.5.24–A.5.28, управление инцидентами. Кластер выдаёт оповещения. Он не выдаёт процесс реагирования, модель серьёзности, путь эскалации и запись о том, что инцидент был разобран после.
A.5.19–A.5.22, отношения с поставщиками. Каждый управляемый сервис в платформе — это поставщик, и контроль спрашивает, что и когда вы о нём проверили, а не какого вендора выбрали.
A.5.23 Информационная безопасность при использовании облачных сервисов. Единственный контроль, который выглядит принадлежащим платформенной команде и ей не принадлежит. Он о решении использовать сервис, об условиях, на которых оно было принято, и о том, что произойдёт при выходе.

Полезная модель: платформа может обеспечить правило, но не может владеть обязанностью.

4. Проблема доказательств, которая и есть настоящая

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

Текущее состояние доказательством не является. Контроль, который работал весь год, но не может быть подтверждён, получает ту же оценку, что и неработавший, потому что у аудитора нет способа их различить. Срок хранения по умолчанию в большинстве кластеров достаточно короткий, чтобы начало проверяемого окна было уже потеряно.

   Git (declared state)                    Cluster (actual state)
   ┌──────────────────────┐                ┌──────────────────────┐
   │ manifests + policy   │  reconcile ──▶ │ workloads            │
   │ reviewed, signed,    │ ◀── drift      │ RBAC, NetworkPolicy  │
   │ merged by 2 people   │                │ admission decisions  │
   └──────────┬───────────┘                └──────────┬───────────┘
              │                                       │
              │ commit history                        │ audit log + events
              ▼                                       ▼
   ┌────────────────────────────────────────────────────────────┐
   │ Evidence store (retained ≥ assessment window)              │
   │  who changed what, when, who approved, what was rejected   │
   └────────────────────────────────────────────────────────────┘
                              │
                              ▼
              Control shown OPERATING, not DECLARED

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

Решение архитектурное, а не процедурное. Обе половины картины — заявленное состояние в Git и фактическое состояние в кластере — уже порождают устойчивую запись. Git несёт, кто предложил изменение, кто его утвердил и когда оно было влито. Кластер несёт журнал аудита, решения контроля допуска, включая отклонения, и события сверки состояния. Направьте и то и другое в хранилище со сроком, превышающим окно вашей проверки, и каждый контроль выше становится подтверждаемым запросом, а не упражнением.

Отклонения значат больше, чем ожидает большинство команд. Политика допуска, которая ни разу ничего не отклонила, неотличима от той, что ничего не обеспечивает, и журнал отклонений — самое дешёвое доказательство того, что контроль живой.

5. Как это ложится на Стандарты обеспечения информационной безопасности ОАЭ

Для организаций в Эмиратах та же работа над платформой засчитывается дважды. Стандарты UAE IA (NESA) содержат 188 контролей в 15 семействах, и технические семейства с T1 по T9 покрывают ту же территорию, что и технологическая тема Приложения A: управление активами, управление доступом, сетевая безопасность, мониторинг и криптография. Платформа, построенная под перечисленные выше контроли ISO, удержит большинство технических контролей UAE IA сопоставлением, а не переделкой.

Не переносится форма обязательства. UAE IA помечает 35 контролей как всегда применимые независимо от вашей оценки рисков, и все они управленческие, а остальные выстраивает по уровням приоритета, где P1 можно усилить и нельзя ослабить. Это строже модели ISO, где применимость следует за оценкой рисков, а Положение о применимости обосновывает результат. Команда, построившая всё под ISO и решившая, что риск-ориентированная логика переносится, обнаружит разрыв ровно в тех контролях, которые кластер и не мог закрыть.

Там, где кластер работает в публичном облаке, добавляется ещё один слой, поскольку контроль, которым управляет провайдер, всё равно должны подтвердить вы. Это разобрано в справочнике по контролям облачной безопасности.

Что почитать дальше

ISO/IEC 27001:2022, Приложение A, и ISO/IEC 27002:2022 — руководство по внедрению каждого контроля
Регламент обеспечения информационной безопасности ОАЭ, версия 1.1, TDRA, Приложения A и B
NIST SP 800-190, Application Container Security Guide
CIS Kubernetes Benchmark — базовая конфигурация, которую предполагают контроли выше

Kubernetes и ISO 27001: какие контроли архитектура закрывает на самом деле