Облачные провайдеры (IaaS, PaaS, SaaS) и физические дата-центры (ЦОД) держат в своих руках непрерывность бизнеса миллионов компаний по всему миру. Если рухнет ферма серверов или произойдет утечка баз данных с хостинга, иски от корпоративных клиентов обанкротят провайдера. Именно поэтому наличие международного сертификата ISO/IEC 27001 (Система управления информационной безопасностью — СУИБ) является базовым (Tier-0) требованием для участия в IT-тендерах и работы с международным Enterprise-сектором.

Специфика ISO 27001:2022 для Cloud-индустрии

Новая редакция стандарта 2022 года впервые сделала акцент на облачную архитектуру. В Приложении "А" появился специальный контроль A.5.23 "Information security for use of cloud services". Он требует от провайдеров не просто "защищать серверы", а выстраивать прозрачную логику распределения ответственности между Провайдером и Клиентом (Shared Responsibility Model).

Уровень сервиса Ответственность за ИБ (Security Responsibility)
IaaS (Инфраструктура как услуга) Провайдер (Вы) отвечает за физическую безопасность ЦОД, питание, гипервизор и сеть. Клиент отвечает за настройку ОС, фаервола, шифрование БД и управление доступом своих админов.
PaaS (Платформа как услуга) Провайдер (Вы) отвечает за ОС, контейнеризацию (Kubernetes), СУБД. Клиент отвечает только за код своего приложения и логику доступов пользователей.
SaaS (ПО как услуга) Провайдер (Вы) несет 95% ответственности за ИБ, включая шифрование данных клиента, защиту от DDoS, пентесты кода и бэкапы.

Расширения стандарта: ISO 27017 и ISO 27018

Для "взрослого" Cloud-провайдера одного базового ISO 27001 часто недостаточно. Зарубежные клиенты требуют доказать, что вы умеете безопасно обрабатывать их данные в облаке. Для этого применяются два отраслевых "расширения", которые интегрируются прямо в вашу архитектуру СУИБ:

ISO/IEC 27017 (Безопасность облачных сервисов)

Стандарт разработан специально для облаков. Он расширяет контроли ISO 27001, добавляя жесткие требования к архитектуре Multi-tenant: как данные Компании А изолированы (логически или физически) от данных Компании Б на одном физическом сервере. Также 27017 регламентирует процедуру гарантированного уничтожения данных (Data Wiping) при расторжении договора с клиентом, чтобы его секреты не достались следующему арендатору "железа".

ISO/IEC 27018 (Защита персональных данных в облаке)

Критически важен для хостеров, хранящих PII (персонально идентифицируемую информацию). Стандарт (основанный на принципах европейского GDPR) прямо запрещает облачному провайдеру использовать базы данных клиентов для собственных маркетинговых целей (анализа Big Data для продажи рекламы). Также он требует обязательного криптографического шифрования баз данных (Data at Rest) и каналов связи (Data in Transit).

ЦОД: Физическая безопасность и Отказоустойчивость

Для операторов физических дата-центров (Colocation/Dedicated) фокус ISO 27001 смещается со "слоя программного кода" на железо и бетон. Основные проверяемые аудиторами области (Контроли Раздела A.7 — Physical security):

  • Периметр (A.7.1). Наличие заборов, КПП, "шлюзов-тамбуров" с биометрией, защищающих от Tailgating (прохода "паровозиком").
  • Защита от сбоев питания и климата (A.7.11 «Supporting utilities»). ISO 27001 требует оценки рисков перегрева. Проверяется архитектура ИБП (UPS), дизель-генераторы (DGU), системы прецизионного кондиционирования, а также газовое (не водяное!) пожаротушение в серверных залах. Уровень резервирования (N+1, 2N) должен соответствовать SLA, заявленному в клиентских договорах (интегрируясь с принципами Uptime Institute Tier I-IV).
  • Кабели и оборудование (A.7.12 «Cabling security»). Аудитор может заглянуть под фальшпол и проверить маркировку витой пары, физическое разделение силовых и оптических кабелей, чтобы исключить наводки (ЭМС) или случайный разрыв тракта.

SOC 2 vs ISO 27001: что выбрать IT-компании?

Российские аутсорс-разработчики и облачные платформы, выходящие на рынок США, часто сталкиваются с требованием предоставить отчет SOC 2 Type II. Важно понимать: ISO 27001 — это европейский/международный сертификат СУИБ, а SOC 2 — это сугубо американская система аудиторских отчетов (AICPA). SOC 2 не имеет жесткого чек-листа, аудитор оценивает ваши контроли по 5 принципам доверия (Trust Services Criteria). В идеале глобальная IT-корпорация должна иметь оба документа, так как они гармонично дополняют друг друга (Governance от ISO + Technical Proof от SOC).

Частые ошибки облачных стартапов на аудите

«У нас серверы на AWS, мы уже безопасны». Часто SaaS-стартап заявляет: "Наше приложение хостится на Amazon/Azure, у них есть ISO 27001, значит мы тоже в домике". Это грубейшая ошибка модели разделения ответственности. Аудитор TUV проверит, как вы сами управляете паролями своих DevOps-инженеров, как настраиваете S3-корзины (чтобы они не были публичными), и как шифруете API-ключи в коде.

Мертвый процесс управления уязвимостями (A.8.8). Разработчики облачной CRM исправно деплоили код, но не проводили регулярное сканирование зависимостей (NPM/Composer пакетов). Аудитор нашел в библиотеках известные CVE (уязвимости 10 из 10 по шкале CVSS). СУИБ требует не только "очищать код", но и выстроить процесс постоянного (Continuous) патч-менеджмента.

Вопросы и ответы

Достаточно ли того, что наш облачный провайдер (AWS, Azure) уже сертифицирован по ISO 27001?

Нет. Сертификат провайдера покрывает только его зону ответственности по модели Shared Responsibility (физическую инфраструктуру, гипервизор, сеть для IaaS) — настройку операционных систем, фаерволов, шифрования БД, управление доступом и безопасность собственного кода вы обязаны обеспечивать сами и подтверждать это отдельным сертификатом или хотя бы внутренним аудитом СУИБ.

Нужны ли ISO 27017 и ISO 27018, если у нас уже есть ISO 27001?

Формально нет, это добровольные расширения, но на практике зарубежные Enterprise-клиенты, особенно работающие с персональными данными, часто требуют именно комбинацию: ISO 27001 как базовую СУИБ, ISO 27017 для специфики multi-tenant облачной архитектуры и ISO 27018 для защиты PII. Без этих расширений некоторые крупные контракты просто не подписываются на этапе due diligence заказчика.

Что выбрать для выхода на рынок США — ISO 27001 или SOC 2?

Оптимально — оба документа, если бюджет позволяет: ISO 27001 подтверждает наличие управленческой системы (governance), а SOC 2 Type II — техническую проверку эффективности контролей за период (обычно 6-12 месяцев наблюдения). SOC 2 не имеет единого жёсткого чек-листа — аудитор оценивает контроли по применимым критериям доверия (Security обязателен, Availability/Processing Integrity/Confidentiality/Privacy — по потребности).

Как часто нужно проходить надзорный аудит СУИБ после сертификации?

Сертификат ISO 27001 действует 3 года, в течение которых орган по сертификации проводит промежуточные надзорные аудиты (обычно ежегодно), а по истечении трёх лет — полный ресертификационный аудит. Пропуск надзорного аудита в установленный срок ведёт к приостановке или аннулированию сертификата.

Обязательно ли физическое разделение данных разных клиентов в multi-tenant архитектуре?

Не обязательно физическое — допускается и логическая изоляция (например, через отдельные виртуальные машины, контейнеры или схемы шифрования с разными ключами на каждого арендатора), если она эффективно предотвращает доступ данных одной компании к данным другой на общем физическом сервере. Именно эту логику проверяет ISO/IEC 27017 при аудите multi-tenant инфраструктуры.

Что будет, если во время аудита найдут известную уязвимость (CVE) в используемых библиотеках?

Само наличие уязвимости не обязательно приводит к провалу аудита — критично, есть ли у компании работающий процесс управления техническими уязвимостями (контроль A.8.8): регулярное сканирование зависимостей, оценка риска найденной уязвимости и план её устранения в разумный срок. Отсутствие такого процесса как системы (а не разовое "нашли — исправили") расценивается как несоответствие.

Экспертное внедрение для IT и Telecom

Реестр Гарант обладает компетенцией для сопровождения высокотехнологичных IT-компаний. Мы выстраиваем процессы ИБ в среде CI/CD (DevSecOps), помогаем классифицировать облачные активы, описываем Shared Responsibility Matrix для ваших публичных оферт, интегрируем контроли ISO 27017/27018 в вашу СУИБ и организуем прохождение жестких сертификационных аудитов у признанных международных органов аккредитации (UKAS, DAkkS).

Другой обзор специфики ISO 27001 для облаков и ЦОД — в статье «ISO 27001 для облачных сервисов и ЦОД: специфика и международное признание». О синергии ISO 27001 и SOC 2 при экспорте в США — в статье «Информационная безопасность для ИТ-экспорта в США: синергия ISO 27001 и SOC 2».