Разместил инфраструктуру в облаке — можно расслабиться и забыть. Именно так думают многие, пока не сталкиваются с утечкой данных, отказом сервиса или штрафом от регулятора. Облако — не магия, а сложная аренда. Ответственность за конфигурацию, доступы, резервное копирование и соответствие 152-ФЗ всё равно лежит на вас. Перенос в облако, это сдвиг ответственности, а не её исчезновение.
Модель совместной ответственности: что на самом деле предоставляет облако
Когда вы арендуете физический сервер, вы контролируете всё — от диска в корзине до температуры в ЦОД. Перенеся инфраструктуру в облако, вы как бы делегируете часть забот провайдеру. Но это делегирование имеет чёткие границы, которые часто остаются за кадром маркетинговых материалов. Эта граница и есть модель совместной ответственности.
Её суть проста: провайдер отвечает за безопасность «облака» как такового, а клиент — за безопасность того, что он в этом облаке размещает.
Стандартное разделение выглядит так:
- Ответственность провайдера: физическая безопасность дата-центров, устойчивость электроснабжения и систем охлаждения, безопасность гипервизора, физическая сеть. Проще говоря, всё то, к чему у вас как у арендатора виртуальной машины нет и не может быть физического доступа.
- Ваша ответственность: безопасность операционной системы на виртуальной машине, настройка межсетевых экранов и групп безопасности, управление доступом пользователей и ключами, шифрование данных на уровне приложения или файловой системы, резервное копирование ваших данных, настройка журналирования и мониторинга.
Модель может меняться в зависимости от типа сервиса. При использовании «сырой» виртуальной машины вы отвечаете за всё внутри неё. При переходе на управляемую базу данных вы делегируете провайдеру установку патчей и настройку кластера, но правила доступа и резервные копии данных — всё ещё ваша зона. В случае с бессерверными функциями ваша ответственность сужается до кода и его зависимостей, но логика его работы и обработка данных — на вас. Ключевая ошибка — думать, что раз инфраструктура «в облаке», то её безопасность — забота провайдера. Он гарантирует, что платформа работает, но не гарантирует, что вы настроили её безопасно.
Миф об «абсолютной доступности» и реальность SLA
Облачные провайдеры анонсируют доступность на уровне 99,9% и выше. Цифра внушает доверие, но её понимание поверхностно. SLA, это не гарантия, что ваш конкретный сервис будет работать без перерывов. Это юридическое обязательство, которое определяет финансовые компенсации при несоблюдении заявленных показателей. Компенсация обычно представляет собой кредит на будущее использование сервисов, а не денежную выплату. Если час простоя вашего приложения обернулся миллионными убытками, кредит в размере 10% от месячного счёта — слабое утешение.
Главное: SLA провайдера покрывает отказ его платформы. Он не покрывает ситуаций, когда доступность вашего приложения упала из-за ваших же ошибок:
- Некорректная конфигурация балансировщика нагрузки или группы автоскейлинга, из-за которой инстансы не переключаются при сбое.
- Ошибка в коде приложения, приводящая к каскадному падению всех экземпляров под нагрузкой.
- Исчерпание квот на ресурсы (например, лимит на количество виртуальных CPU в регионе), из-за чего нельзя создать новые инстансы для восстановления.
- Неправильная настройка маршрутов в виртуальной сети, блокирующая трафик.
Высокая доступность, это архитектура, которую вы должны спроектировать и реализовать сами, используя инструменты облака: размещение в нескольких зонах доступности, настройка Health Checks, автоматическое восстановление. Облако даёт инструменты, но не строит отказоустойчивую систему за вас.
Данные в облаке: кто и как их защищает?
«Ваши данные в безопасности» — ещё один распространённый тезис. Безопасность здесь означает, что провайдер предотвращает несанкционированный доступ к своим дискам и системам хранения. Но если вы оставили базу данных открытой для всех в интернете (0.0.0.0/0) с паролем admin/admin, провайдер не будет вас останавливать. Защита данных на уровне приложения — ваша обязанность.
Шифрование: когда оно работает, а когда — нет
Многие облачные сервисы хранения предлагают шифрование «по умолчанию». Это шифрование нередко является server-side encryption с ключами, управляемыми провайдером. Это защищает данные, если физический носитель будет украден или списан, но ключи от шифрования находятся у провайдера. Для соответствия строгим требованиям регуляторов часто необходимо использовать client-side encryption, где ключи генерируются и хранятся исключительно на вашей стороне. Провайдер в этом случае работает с уже зашифрованным «контейнером».
Есть и менее очевидный аспект: шифрование «в покое» не защищает данные «в движении». Если ваше приложение передаёт чувствительные данные между внутренними микросервисами по незашифрованным HTTP-соединениям внутри виртуальной сети, эти данные могут быть перехвачены при компрометации одной из нод.
Резервное копирование: ответственность за восстановление
Облачные провайдеры часто предоставляют инструменты для снапшотов дисков и бэкапов баз данных. Однако их политика хранения, частота создания и тестирование восстановления — ваша задача. Автоматический снапшот раз в сутки не спасёт, если вы обнаружили порчу данных через 23 часа после его создания. Хранение всех бэкапов в одном регионе чревато их потерей при масштабном сбое в этом регионе. Восстановление после полного удаления аккаунта администратором по ошибке — отдельный сценарий, который редко покрывается стандартными инструментами.
По сути, облако предоставляет удобные «кнопки» для создания копий, но стратегия резервного копирования — её гранулярность, RPO (целевая точка восстановления), RTO (целевое время восстановления) и географическое распределение — остаётся на ваше усмотрение и требует отдельного проектирования.
Соответствие 152-ФЗ и ФСТЭК: облако не делает вас автоматически совместимыми
Одно из самых опасных заблуждений — что аренда мощностей у облачного провайдера, имеющего аттестованный ЦОД или сертификаты ФСТЭК, автоматически переносит этот статус на вашу информационную систему. Это не так.
Соответствие требованиям регуляторов — многоуровневая задача:
- Уровень инфраструктуры провайдера. Действительно, провайдер должен иметь аттестованный по требованиям безопасности ЦОД, если вы обрабатываете персональные данные или гостайну. Но его аттестация — лишь необходимое условие, разрешающее вам там работать. Не достаточное.
- Уровень вашей системы. Вся ваша информационная система, развёрнутая на этой инфраструктуре, должна быть спроектирована, настроена и документирована в соответствии с приказами ФСТЭК. Это включает:
- Настройку средств защиты информации (СЗИ): виртуальных межсетевых экранов, систем обнаружения вторжений (IDS), антивирусов.
- Внедрение разграничения прав доступа, управления учётными записями, настройку аудита и журналирования всех значимых событий.
- Разработку организационно-распорядительной документации (положения, регламенты, инструкции), описывающей процессы в облачной среде.
- Уровень процесса аттестации. Аттестацию проходит конкретная информационная система (ИС). Вы, как оператор этой ИС, должны предоставить в ФСТЭК или лицензированную аттестующую лабораторию полный комплект документов, включая описание архитектуры в облаке, схему информационных потоков, настройки СЗИ. Факт размещения в облаке провайдера «X» лишь будет отражён в этих документах как характеристика инфраструктуры.
В итоге провайдер даёт вам «чистое поле» с определённым уровнем безопасности. Что вы на этом поле построите и сможете ли это подтвердить перед регулятором — целиком ваша ответственность. Многие провайдеры предлагают «регуляторные» образы виртуальных машин с предустановленными средствами защиты, но их настройка и интеграция в ваши процессы — опять же ваша задача.
Управление доступом и учётными записями: главный вектор атак
Самый распространённый инцидент в облаке — не взлом через нул-дей уязвимость, а компрометация учётной записи с широкими привилегиями. Root-аккаунт или учётная запись с ролью «Администратор», защищённая простым паролем и без многофакторной аутентификации (MFA), — мечта злоумышленника. Получив к ней доступ, он может отключить все системы защиты, скачать или зашифровать данные, уничтожить инфраструктуру.
Принцип наименьших привилегий в облаке критически важен. Вместо использования одной мощной учётной записи необходимо:
- Создавать отдельных пользователей или сервисные учётные записи для конкретных задач.
- Назначать роли с минимально необходимыми правами (например, роль только для просмотра логов или только для управления определённой группой виртуальных машин).
- Обязательно включать MFA для всех пользовательских аккаунтов, особенно административных.
- Регулярно проводить аудит выданных прав и отзывать неиспользуемые.
- Для сервисных аккаунтов использовать не долгоживущие пароли, а временные токены или привязку к экземплярам.
Провайдер предоставляет инструменты для всего этого (IAM-системы), но их грамотная настройка лежит на вас. История знает случаи, когда из-за утечки ключа от сервисного аккаунта злоумышленники майнили криптовалюту на огромных вычислительных мощностях клиента, что выливалось в астрономические счета за облачные ресурсы.
Заключение: облако как инструмент, а не волшебная палочка
Перенос в облако, это не способ снять с себя технические и регуляторные обязанности. Это переход от управления железом к управлению конфигурацией. Уровень абстракции повышается, а вместе с ним растёт и важность грамотного проектирования, автоматизации и контроля. Ответственность никуда не исчезает — она трансформируется. Вместо слежения за работой дисковых массивов вы должны следить за политиками безопасности IAM, корректностью шаблонов развёртывания, соответствием вашей архитектуры требованиям 152-ФЗ.
Облако даёт невиданную ранее скорость масштабирования и богатый набор сервисов. Но эта мощь требует соответствующей зрелости процессов. Без чёткого понимания модели совместной ответственности, стратегии резервного копирования и управления доступом ваше путешествие в облако может закончиться серьёзными инцидентами, финансовыми потерями и проблемами с регуляторами. Облако — ваш мощнейший союзник, но только если вы знаете правила совместной работы с ним.