← [Раздел](README.md) · [Главная](../README.md)

# ISO 27001 — обзор для DevSecOps

## Цель

Понять структуру ISO/IEC 27001:2022, что такое ISMS (система управления информационной безопасностью) и какие контроли из Annex A можно закрывать средствами CI/CD, мониторинга и Kubernetes.

## Предварительно

- Базовые понятия: риск, уязвимость, инцидент (раздел [01](../01-chto-takoe-devsecops/README.md) или аналог).
- Опыт работы с Git и хотя бы одним CI (GitLab CI / GitHub Actions).

## Время

~45 минут чтения.

## Что такое ISO 27001

**ISO 27001** — международный стандарт на **систему управления** информационной безопасностью (Information Security Management System, ISMS). Сертификация по ISO 27001 не «лечит» уязвимости автоматически: она доказывает, что организация **осознанно управляет рисками** — политики, роли, процессы, измерение, улучшение.

Важно: стандарт описывает **процесс** (Plan–Do–Check–Act), а приложение **Annex A** — каталог из 93 контролей в 4 темах (организационные, люди, физические, технологические).

## Цикл PDCA в простых словах

| Этап | Вопрос | Пример в DevSecOps |
|------|--------|-------------------|
| Plan | Что защищаем и от чего? | Матрица рисков: репозиторий с ПДн — строгие сканы |
| Do | Что делаем? | SAST в MR, подпись образов, Vault для секретов |
| Check | Работает ли? | Метрики: % MR со сканом, время до патча CVE |
| Act | Что улучшаем? | Новое правило Semgrep после инцидента |

## Annex A и автоматизация

Не все 93 контроля «кодятся». Ниже — примеры, где DevSecOps даёт **технические доказательства**:

| Тема Annex A | Контроль (упрощённо) | Инструмент / практика |
|--------------|----------------------|------------------------|
| Управление доступом | Уникальные учётки, least privilege | RBAC в K8s, SSO в Git |
| Управление уязвимостями | Своевременные патчи | Trivy/Grype в CI, политика «блок при Critical» |
| Безопасная разработка | SDLC с проверками | Обязательный code review + SAST |
| Логирование | Аудит действий | Централизованные логи CI, audit log API K8s |
| Криптография | Защита данных в покое/транзите | TLS ingress, encrypted volumes |
| Управление инцидентами | Реагирование | Runbook, tabletop (см. [lab-04](../11-praktikum/lab-04-incident-tabletop.md)) |

Аудитор часто спрашивает не «какой у вас Trivy», а **где политика** и **как вы доказываете выполнение за последние 12 месяцев**.

## Statement of Applicability (SoA)

**SoA** — документ: какие контроли Annex A применимы, кто владелец, как реализованы, статус (внедрён / частично / не применим). DevSecOps помогает заполнить колонку «как реализовано» ссылками на:

- файл `.gitlab-ci.yml` с job `security_scan`;
- Helm values с `networkPolicy.enabled: true`;
- политику ротации секретов в Vault.

## Риск-ориентированный подход

ISO 27001 требует **оценки рисков** (risk assessment). Для инженера это значит:

1. Актив (например, API с заказами) → ценность и угрозы.
2. Уязвимость (открытый порт БД) → вероятность × ущерб.
3. Контроль (NetworkPolicy, только из namespace `app`) → снижение риска.
4. Остаточный риск → принятие руководством или доп. меры.

DevSecOps-метрика: не «закрыли 1000 CVE», а «критические в проде — 0 дольше N дней».

## Типичные ошибки при подготовке к аудиту

1. **Скриншоты вместо логов** — «у нас включён 2FA» без export событий входа.
2. **Разовый скан** — один отчёт Trivy за год; нужна **регулярность** и история.
3. **Исключения без срока** — «временно отключили SAST» без даты пересмотра.
4. **Секреты в SoA** — в документах только ссылки на системы, не пароли.

## Мини-глоссарий

- **ISMS** — система политик и процессов ИБ.
- **Контроль** — мера снижения риска (техническая или организационная).
- **Несоответствие (nonconformity)** — нарушение требования стандарта или своей политики.
- **Корректирующее действие** — что сделали, чтобы не повторилось.

## Самопроверка

1. Чем ISMS отличается от «списка инструментов безопасности»?
2. Назовите три контроля Annex A, которые можно подкрепить артефактами CI/CD.
3. Что такое SoA и зачем DevSecOps заполняет колонку «реализация»?
4. Почему метрика «0 Critical CVE в prod > 7 дней» лучше, чем «1000 находок закрыто»?

## Сертификация: что проверяют на месте

Аудит ISO 27001 Stage 1 / Stage 2 (упрощённо):

| Этап | Фокус |
|------|-------|
| Документы | Политики, SoA, risk assessment |
| Интервью | Роли, осведомлённость |
| Выборка | Доказательства за период |

Инженеру готовят **папку выборки**: 5–10 MR с зелёным security pipeline, 3 тикета на патчи CVE, export RBAC.

## Связь с другими фреймворками

| Фреймворк | Пересечение с ISO 27001 |
|-----------|-------------------------|
| SOC 2 | Trust principles, много общих контролей |
| PCI DSS | Если есть карты — жёстче сегментация |
| NIST CSF | Identify–Protect–Detect–Respond–Recover |
| CIS Controls | Технические меры, хороший мост к инструментам |

Не нужно зубрить все стандарты: достаточно понимать, что **аудитор ищет повторяемость**, а не разовый героизм.

## Пример risk register (фрагмент)

| Риск | Вероятность | Ущерб | Контроль | Остаток |
|------|-------------|-------|----------|---------|
| Утечка секрета в Git | Средняя | Высокий | Gitleaks + MR policy | Низкий |
| Непатченный Critical CVE | Средняя | Критический | Trivy gate | Средний |
| Несанкционированный exec в pod | Низкая | Высокий | Falco + RBAC audit | Низкий |

DevSecOps автоматизирует **контроль** и **доказательство** из третьей колонки.

## Вопросы аудитору (как инженеру)

- Какой период выборки артефактов CI?
- Достаточно ли JSON-отчётов или нужны подписанные PDF?
- Как оформлять risk acceptance для отложенного патча?

## Дальше

[GDPR и персональные данные](gdpr-i-personalnye-dannye.md) — правовой контекст для данных в приложениях и логах.