ISO 27001 для облачных сервисов и ЦОД: специфика и международное признание
👁 23
ISO 27001 для облачных провайдеров, SaaS и ЦОД 2026: Annex A облачные меры, ISO 27017/27018, Shared Responsibility, аудит и сертификация. Тел.: +7 920-898-17-18.
ISO 27001 для облачных сервисов и ЦОД: специфика и международное признание
Облачные провайдеры, операторы ЦОД (центров обработки данных) и разработчики SaaS-платформ занимают принципиально особое положение в экосистеме информационной безопасности: они не только управляют собственными информационными рисками, но и несут ответственность за безопасность данных и рабочих нагрузок своих клиентов. Именно это обстоятельство делает сертификацию ISO 27001 для облачного бизнеса не просто полезной, а стратегически необходимой — большинство корпоративных заказчиков в Европе, США, Ближнем Востоке и всё чаще в России включают требование наличия ISO 27001 в квалификационные критерии для облачных поставщиков. ISO 27001:2022 в части облачных сервисов и ЦОД опирается на три взаимосвязанных стандарта: ISO 27001:2022 (базовый СУИБ с Annex A), ISO/IEC 27017:2015 «Руководство по мерам управления безопасностью для облачных сервисов» (дополнительные меры ИБ специфически для облака — добавляет 7 уникальных облачных мер к Annex A ISO 27001) и ISO/IEC 27018:2019 «Защита персонально идентифицируемой информации в публичных облаках» (требования к обработке ПДн в облаке — основа для GDPR-совместимости облачного провайдера). ЦОД дополнительно сертифицируется по классификации Tier I–IV стандарта Uptime Institute — что создаёт комплементарную систему: ISO 27001/27017/27018 покрывают ИБ-аспекты, Tier — физическую инфраструктуру и доступность. Комбинированная сертификация ISO 27001 + ISO 27017 + ISO 27018 является де-факто стандартом доказательства безопасности для крупных облачных провайдеров и запрашивается клиентами во всём мире.
☁️
ISO 27001:2022
базовый СУИБ; 93 меры Annex A; для облака критичны A.5.23 (облачные сервисы), A.8.16 (мониторинг), A.5.30 (непрерывность)
🛡️
ISO 27017
дополнительные меры ИБ для облачных сервисов; 7 уникальных облачных мер; роли CSP и CSC; Shared Responsibility Matrix
🔐
ISO 27018
защита ПДн (PII) в публичных облаках; основа GDPR-совместимости для облачного провайдера; особые требования к согласию и удалению
🌐
100+ стран
сертификат ISO 27001 от IAF MLA-аккредитованного органа признаётся во всём мире; обязательное требование для работы с EU, US и GCC корпоративными клиентами
Критические меры ISO 27001: A.7 (физическая безопасность ЦОД), A.8.1–A.8.3 (конечные устройства и управление ресурсами), A.8.7 (защита от вредоносного ПО на гипервизоре)
ISO 27017 специфика: CLD.6.3.1 (разделение виртуальной среды клиентов — «multi-tenancy» изоляция), CLD.9.5.2 (мониторинг активности клиентов в пределах разрешённого)
SRM: провайдер отвечает за физ. ЦОД, сеть, гипервизор; клиент — за ОС, приложения, данные, сетевые настройки ВМ
Приоритетные угрозы: VM escape (атака из ВМ на гипервизор), утечка данных через общую инфраструктуру, DDOS на сетевые интерфейсы
🏗️
PaaS — Platform as a Service
Провайдер предоставляет платформу разработки; клиент управляет приложениями и данными
Критические меры ISO 27001: A.8.25–A.8.28 (безопасная разработка и тестирование), A.5.19–A.5.21 (безопасность в цепочке поставок), A.5.15–A.5.18 (управление доступом)
ISO 27017 специфика: CLD.12.1.5 (администрирование и мониторинг операционных функций облака), CLD.8.1.5 (контроль привилегий в управлении виртуализацией)
SRM: провайдер отвечает за платформу, middleware, runtime; клиент — за код приложений, конфигурацию, данные
Приоритетные угрозы: небезопасный код клиентских приложений, инъекции через API платформы, утечка данных через sandbox
💻
SaaS — Software as a Service
Провайдер предоставляет приложение целиком; клиент управляет только данными и доступом
Критические меры ISO 27001: A.8.25–A.8.29 (безопасная разработка SDLC), A.5.14 (передача информации), A.5.12–A.5.13 (классификация и маркировка), A.8.11 (маскирование данных)
ISO 27018 специфика: обязательно при обработке ПДн клиентов; согласие, удаление данных по запросу, прозрачность субобработчиков, географические ограничения хранения
SRM: провайдер отвечает за всё кроме данных клиентов и настроек доступа; клиент — за IAM, использование данных
Приоритетные угрозы: компрометация аккаунтов, небезопасные API, незащищённые данные при multi-tenancy
A.5.23 — Новая мера 2022A.5.23 «Информационная безопасность при использовании облачных сервисов» — новая мера, добавленная в ISO 27001:2022. Требует: политику использования облачных сервисов; оценку и выбор облачных провайдеров по критериям ИБ; Shared Responsibility Matrix для каждого провайдера; требования к шифрованию данных в облаке; портабельность данных и условия выхода; мониторинг соответствия провайдера требованиям ИБ. Для ЦОД и облачных провайдеров — это зеркальная мера: они должны помочь клиентам закрыть A.5.23
Shared Responsibility MatrixМатрица разделения ответственности (SRM) — ключевой документ ISO 27017, определяющий кто — Cloud Service Provider (CSP) или Cloud Service Customer (CSC) — несёт ответственность за каждую конкретную меру ИБ. SRM публикуется CSP (провайдером) для каждой модели сервиса (IaaS/PaaS/SaaS). Для СУИБ клиента: SRM позволяет корректно заполнить SoA, исключив меры, за которые отвечает провайдер, с ссылкой на SRM и сертификат ISO 27001/27017 провайдера
Tier I–IV vs ISO 27001Классификация Uptime Institute Tier I–IV оценивает физическую инфраструктуру ЦОД: избыточность питания, охлаждения и сети; доступность (99,671% для Tier I до 99,9995% для Tier IV). ISO 27001 оценивает информационную безопасность в целом. Это дополняющие, не конкурирующие системы: Tier IV + ISO 27001 + ISO 27017 = полный набор подтверждений для premium enterprise-клиентов. Практически: большинство Tier III/IV ЦОД также имеют ISO 27001
SOC 2 Type II vs ISO 27001SOC 2 Type II (AICPA) — американская альтернатива ISO 27001 для оценки ИБ облачных сервисов. Ключевые отличия: SOC 2 — аудиторский отчёт о фактических практиках за период (6–12 месяцев); ISO 27001 — сертификация системы управления; SOC 2 признаётся преимущественно в США; ISO 27001 — глобально. Рекомендованная стратегия для российских облачных провайдеров: ISO 27001 + ISO 27017 для работы с европейскими и ближневосточными клиентами; SOC 2 Type II — при работе с американским рынком
ISO 27017 и ISO 27018 — расширения для облачного провайдера
ISO/IEC 27017:2015
Меры ИБ для облачных сервисов
7 уникальных облачных мер + уточнения к 35 мерам ISO 27001 Annex A
CLD.6.3.1 — разделение виртуальной среды между клиентами (multi-tenancy): требует технической изоляции VM/контейнеров и данных клиентов; ключевая мера для IaaS
CLD.8.1.5 — удаление активов при прекращении обслуживания: процедура гарантированного уничтожения данных клиента при завершении договора; зафиксированные сроки (обычно 30–90 дней)
CLD.9.5.1 — SLA по доступности и непрерывности: документированные RTO/RPO в договоре; мониторинг выполнения SLA; компенсации при нарушении
CLD.9.5.2 — мониторинг облачных сервисов: CSP осуществляет мониторинг в пределах, согласованных с клиентом; прозрачность о том, что именно мониторится
CLD.12.1.5 — администрирование операционной системы виртуализации: отдельные роли для управления гипервизором; PAM для доступа к инфраструктуре; регистрация всех административных действий
Shared Responsibility Matrix — обязательный документ ISO 27017: CSP публикует SRM, где явно разграничена ответственность провайдера и клиента по каждой мере ИБ; SRM предоставляется всем клиентам
Прозрачность субобработчиков: CSP раскрывает список субпровайдеров (субподрядчиков), имеющих доступ к данным клиентов; уведомление клиентов при добавлении новых субпровайдеров
ISO/IEC 27018:2019
Защита ПДн (PII) в публичных облаках
Требования к обработке персональных данных клиентов в публичном облаке
Согласие клиента (CSC) на обработку ПДн: CSP не использует данные клиентов в маркетинговых или иных целях без явного согласия; «данные клиента принадлежат клиенту» — ключевой принцип
Права субъектов ПДн через CSP: механизм передачи запросов на доступ, исправление, удаление ПДн (DSR) от конечного субъекта к CSC через CSP в установленные сроки
Географические ограничения хранения: CSP раскрывает страны, где хранятся и обрабатываются ПДн; запрет трансграничной передачи без согласования с CSC; соответствие GDPR Art.44–49
Прозрачность инцидентов с ПДн: обязательное уведомление CSC о нарушениях, затрагивающих ПДн, в сроки, позволяющие CSC выполнить обязательства по уведомлению регуляторов (GDPR: 72 часа)
Возврат и уничтожение ПДн: при расторжении договора — возврат всех ПДн клиенту в структурированном формате + гарантированное уничтожение копий у провайдера с записью
Политика ограниченного доступа персонала: сотрудники CSP не имеют доступа к содержимому ПДн клиентов без разрешения; все исключения — только по письменному согласованию с CSC; журнал доступа
Основа GDPR-совместимости: сертификат ISO 27018 признаётся как механизм сертификации по GDPR Art.42; облегчает переговоры с EU-клиентами о Data Processing Agreement (DPA)
Архитектура СУИБ: от Shared Responsibility до сертификата
Специфические меры ISO 27001 + 27017 для ЦОД и облачных провайдеров
Категория / мера
ISO 27001:2022
ISO 27017
Специфика для ЦОД / облака
Физическая безопасность ЦОД
A.7.1–A.7.14
Уточнение A.7.8
Контроль доступа в серверные залы; биометрия; видеонаблюдение 90+ дней; зоны безопасности; защита от природных катастроф; CCTV; Man-trap на входе
Изоляция мультиарендных сред
A.8.22
CLD.6.3.1
Технические меры изоляции VM/контейнеров; сетевая сегментация между клиентами; запрет cross-tenant доступа; тесты на проникновение между средами
Мониторинг и логирование
A.8.15–A.8.16
CLD.9.5.2
SIEM с хранением логов ≥1 года (ISO) / 3 года (ЦБ РФ); мониторинг доступа к данным клиентов; аномалии поведения (UEBA); экспорт логов клиентам по запросу
Управление привилегированным доступом
A.5.15–A.5.18
CLD.12.1.5
PAM (Privileged Access Management) для администраторов гипервизора; MFA для всего привилегированного доступа; принцип наименьших привилегий; сессионный аудит
Шифрование данных клиентов
A.8.24
Уточнение
Шифрование at rest и in transit для всех данных клиентов; управление ключами (KMS); BYOK (Bring Your Own Key) для enterprise-клиентов; аппаратные HSM
Непрерывность и DR
A.5.29–A.5.30
CLD.9.5.1
Задокументированные RTO/RPO в SLA; резервные ЦОД в разных географических зонах; тесты BCP/DR минимум раз в год; публичный status page
Удаление данных клиентов
A.8.10
CLD.8.1.5 + 27018
Гарантированное уничтожение данных при расторжении договора; сроки: 30–90 дней; DoD 5220.22M / NIST 800-88 стандарты уничтожения; сертификат об уничтожении клиенту
Безопасная разработка (для SaaS)
A.8.25–A.8.29
Специфика SaaS
SAST/DAST в CI/CD; ежегодный пентест всего приложения; Bug Bounty программа; OWASP Top 10 проверки; безопасный SDLC; разделение сред dev/test/prod
Международное признание: где принимается ISO 27001 облачного провайдера
🇪🇺
Европейский Союз
ISO 27001 + ISO 27018 = основа GDPR DPA; ENISA Cloud Certification Scheme (EUCS) рекомендует ISO 27001; NIS2 Directive требует СУИБ для essential entities
🇬🇧
Великобритания
NCSC Cyber Essentials Plus основан на ISO 27001; G-Cloud Framework требует ISO 27001 для правительственного облака; UK GDPR признаёт ISO 27018
🇸🇦
Саудовская Аравия / ОАЭ
NCA (National Cybersecurity Authority) требует ISO 27001 для CSP; SAMA Cyber Framework (банки); UAE IA Framework — ISO 27001 как базовый стандарт
🇸🇬
Сингапур / APAC
MAS TRM Guidelines (финансы) рекомендуют ISO 27001; MTCS (Multi-Tier Cloud Security) стандарт Сингапура базируется на ISO 27001/27017
🇷🇺
Россия
ГОСТ Р ИСО/МЭК 27001:2021 — национальный эквивалент; рекомендован ЦБ РФ; признаётся при аудитах регуляторов как свидетельство зрелой СУИБ; применим для экспортных сертификаций
🌐
Глобально — CSA STAR
Cloud Security Alliance STAR Certification Level 2 = ISO 27001 + CCM (Cloud Controls Matrix); признаётся корпоративными клиентами по всему миру как специализированный cloud security сертификат
Пошаговое внедрение СУИБ ISO 27001/27017/27018 для облачного провайдера
1
Scoping и определение облачных сервисов в области СУИБ
Определить область СУИБ: какие именно облачные сервисы и ЦОД-площадки включены; типы клиентов (B2B/B2C) и обрабатываемые данные (включая ПДн — тогда ISO 27018); составить реестр информационных активов с учётом multi-tenancy архитектуры; определить применимость ISO 27017 и/или 27018. Scoping должен соответствовать реальной границе ответственности CSP
2–3 нед.
2
Оценка рисков с учётом облачной специфики (§6.1.2)
Применить методологию оценки рисков к облачным угрозам: утечки данных через неправильно настроенный объект хранения, VM escape, атаки на API, инсайдерский доступ персонала к данным клиентов, атаки через субпровайдеров. Важно: оценивать риски не только для собственных активов, но и для данных всех категорий клиентов. CSA Cloud Threat Intelligence — рекомендуемый источник актуальных угроз
3–5 нед.
3
Разработка SoA с облачными мерами ISO 27017/27018
SoA для облачного провайдера: все 93 меры ISO 27001 Annex A + 7 уникальных мер ISO 27017 (CLD.6.3.1, CLD.8.1.5, CLD.9.5.1, CLD.9.5.2, CLD.12.1.5 и другие) + меры ISO 27018 (при обработке ПДн). Разработать Shared Responsibility Matrix для каждой модели сервиса (IaaS/PaaS/SaaS) — публичный документ для клиентов. Провести gap-анализ текущих технических мер против SoA
3–6 нед.
4
Реализация мер: изоляция, шифрование, PAM, мониторинг, DR
Ключевые технические меры для ЦОД/облака: внедрение или верификация SIEM с корреляцией событий по всем слоям стека; PAM для администраторов гипервизора; KMS/HSM для управления ключами шифрования; тестирование изоляции между клиентами; DR-тесты с достижением заявленных RTO/RPO; написание процедуры гарантированного уничтожения данных клиентов
3–8 мес.
5
Внутренний аудит + пентест + анализ со стороны руководства
Внутренний аудит охватывает: физическую безопасность ЦОД (выезд аудитора), логическую изоляцию сред, управление доступом, мониторинг. Пентест (обязателен для подтверждения изоляции в multi-tenancy): тест cross-tenant изоляции, тест API, внешний периметр. Анализ руководства: KPI СУИБ, метрики инцидентов, SLA выполнение, CSR-опросы клиентов
Аудитор с квалификацией ISO 27001 + облачная специализация проводит совместный аудит; Stage 1: документарная проверка SoA с облачными мерами + SRM; Stage 2: проверка технической реализации — демонстрация изоляции сред, PAM, KMS, DR-тест, журналы SIEM, процедура уничтожения данных. Три сертификата выдаются одновременно от одного органа
3–5 дней
Временная шкала проекта СУИБ для облачного провайдера
Мес. 1–2
Scoping + реестр активов + оценка рисков + SRM
Мес. 2–4
SoA (27001+27017+27018) + политики + процедуры
Мес. 4–10
Технические меры: SIEM, PAM, KMS, изоляция, DR
Мес. 10–13
Внутр. аудит + пентест + анализ руководства
Мес. 13–18
Сертификационный аудит → 3 сертификата ✓
* Небольшой SaaS (до 50 чел., зрелые DevSecOps): 8–12 месяцев. ЦОД / крупный облачный провайдер: 12–18 месяцев. Мультирегиональный провайдер (несколько ЦОД): 15–24 месяца. Наличие SOC 2 Type II ускоряет процесс на 3–4 месяца
Стоимость сертификации ISO 27001/27017/27018 для облачного провайдера
Консалтинг + SoA (малый SaaS)
₽500 000–1 500 000
Консалтинг + SoA (крупный ЦОД/облако)
₽3 000 000–10 000 000
Технические меры (SIEM, PAM, KMS, HSM)
₽2 000 000–20 000 000+
Пентест (cross-tenant + API + внешний)
₽300 000–1 500 000
Сертиф. аудит 27001+27017 (SaaS, до 100 чел.)
₽400 000–900 000
Сертиф. аудит 27001+27017+27018 (ЦОД)
₽900 000–2 500 000
Надзорный аудит (ежегодно)
₽250 000–700 000/год
Итого 1-й год (крупный ЦОД, «под ключ»)
₽7 000 000–35 000 000+
⚠ Пять критических ошибок при сертификации ISO 27001/27017 для облачного провайдера
Первая — некорректная SRM (Shared Responsibility Matrix): провайдер заявляет в SRM, что клиент отвечает за меры, которые фактически реализуются на стороне провайдера (или наоборот). Клиенты, аудируемые по ISO 27001, ссылаются на SRM при заполнении своих SoA — несоответствие реальности и SRM дискредитирует обе стороны. Вторая — отсутствие тестирования изоляции между клиентами: CLD.6.3.1 требует технической изоляции, но многие провайдеры лишь документируют меры, не проводя реальных тестов cross-tenant penetration. Аудитор Stage 2 может запросить отчёт о тестировании изоляции — его отсутствие = Major Nonconformity. Третья — процедура уничтожения данных клиентов существует только на бумаге: CLD.8.1.5 ISO 27017 требует реального, верифицируемого уничтожения данных при расторжении договора. Провайдеры часто «забывают» данные в резервных копиях, репликах DR или тестовых средах. Клиент вправе запросить сертификат об уничтожении — нужно иметь реальную процедуру. Четвёртая — политика доступа персонала к данным клиентов не соответствует ISO 27018: A.6.1 ISO 27018 запрещает использование данных клиентов в целях, не согласованных с клиентом. Прецеденты, когда персонал поддержки просматривал данные клиентов без согласования — прямое нарушение ISO 27018 и GDPR. Пятая — сертификат органа без IAF MLA-аккредитации: для международных клиентов (EU, GCC, APAC) только IAF MLA-аккредитованный орган обеспечивает глобальное признание. Российский орган без IAF MLA = сертификат, не принимаемый европейскими корпоративными клиентами.
Реестр Гарант — ISO 27001/27017/27018 для облачных провайдеров и ЦОД
Специализируемся на комплексной сертификации ISO 27001 + ISO 27017 + ISO 27018 для облачных провайдеров (IaaS/PaaS/SaaS), операторов ЦОД и SaaS-платформ с международным признанием: определение оптимального scoping с учётом multi-tenancy архитектуры и модели сервиса, разработка Shared Responsibility Matrix для каждой модели сервиса (публичный документ для клиентов), создание полного SoA с облачными мерами ISO 27017 (7 CLD-мер) и мерами ISO 27018 при обработке ПДн, технический gap-анализ: изоляция сред, PAM, KMS/HSM, SIEM, DR-тесты, организация пентеста с проверкой cross-tenant изоляции и безопасности API, подготовка к CSA STAR Level 2 как дополнению к ISO 27001/27017, подбор IAF MLA-аккредитованного органа с международным признанием сертификата, сопровождение Stage 1 и Stage 2 с демонстрацией технических мер.