ISO 27001 для облачных сервисов и ЦОД: специфика и международное признание
👁 41
ISO 27001 для облачных провайдеров, SaaS и ЦОД 2026: Annex A облачные меры, ISO 27017/27018, Shared Responsibility, аудит и сертификация.
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 «Защита персонально идентифицируемой информации в публичных облаках» (требования к обработке ПДн в облаке — основа для GDPR-совместимости облачного провайдера); в августе 2025 года вышла третья редакция **ISO/IEC 27018:2025**, отменившая и заменившая версию 2019 года (выведена из обращения 26.08.2025) и приведённая в соответствие с ISO 27001:2022/27002:2022 — организациям, сертифицированным по редакции 2019 года, необходимо планировать переход. ЦОД дополнительно сертифицируется по классификации Tier I–IV стандарта Uptime Institute — что создаёт комплементарную систему: ISO 27001/27017/27018 покрывают ИБ-аспекты, Tier — физическую инфраструктуру и доступность. Комбинированная сертификация ISO 27001 + ISO 27017 + ISO 27018 является де-факто стандартом доказательства безопасности для крупных облачных провайдеров и запрашивается клиентами во всём мире. Смежный разбор сертификации ЦОД — в статье «СУИБ по ISO 27001: сертификация дата-центров (ЦОД) и облачных провайдеров».
☁️
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:2025
защита ПДн (PII) в публичных облаках; третья редакция вышла в августе 2025 (заменила версию 2019 года), выровнена с ISO 27001:2022; основа 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:2025
Защита ПДн (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 = сертификат, не принимаемый европейскими корпоративными клиентами.
Нет, в августе 2025 года вышла третья редакция ISO/IEC 27018:2025, которая отменила и заменила версию 2019 года (официально выведена из обращения 26.08.2025) и приведена в соответствие с ISO 27001:2022/27002:2022. Организациям, сертифицированным по старой редакции, необходимо планировать переход.
Обязательно ли облачному провайдеру сертифицироваться по всем трём стандартам сразу?
Нет. ISO 27001 — базовый обязательный СУИБ. ISO 27017 добавляет облачную специфику и рекомендуется всем провайдерам. ISO 27018 нужен именно при обработке персональных данных клиентов (PII) — то есть обязателен для большинства SaaS, но менее критичен для чистого IaaS без доступа к содержимому данных клиента.
Что такое Shared Responsibility Matrix и зачем она клиентам провайдера?
SRM — обязательный документ ISO 27017, который провайдер публикует для каждой модели сервиса (IaaS/PaaS/SaaS), явно разграничивая ответственность CSP и клиента (CSC) по каждой мере ИБ. Клиенты используют SRM при заполнении собственного Statement of Applicability, исключая меры, за которые отвечает провайдер, со ссылкой на его сертификат.
Достаточно ли задокументировать изоляцию между клиентами, не проводя реальных тестов?
Нет. Мера CLD.6.3.1 ISO 27017 требует технической изоляции виртуальных сред клиентов, и аудитор на Stage 2 вправе запросить отчёт о реальном тестировании cross-tenant penetration. Отсутствие такого теста — критическое несоответствие (Major Nonconformity), а не формальность.
Признаётся ли российский сертификат ISO 27001 европейскими и ближневосточными клиентами?
Признаётся только при условии, что сертификат выдан органом с аккредитацией IAF MLA — она обеспечивает глобальное взаимное признание. Сертификат от органа без такой аккредитации не принимается корпоративными клиентами в ЕС, GCC и APAC.
Заменяет ли ISO 27001 классификацию Tier ЦОД по Uptime Institute?
Нет, это взаимодополняющие, а не конкурирующие системы. Tier I-IV оценивает физическую инфраструктуру и доступность (резервирование питания, охлаждения, сети), а ISO 27001/27017 — информационную безопасность в целом. Для premium enterprise-клиентов ЦОД обычно предоставляет и то, и другое одновременно.