Модель разделённой ответственности в IaaS для бизнеса

Переход в IaaS переносит часть инфраструктурных задач провайдеру, но не передаёт ему ответственность за приложения, учётные записи и смысл данных. Большинство конфликтов возникает не из-за отсутствия технологий, а из-за неописанной границы: каждая сторона считает, что конкретную настройку, резервную копию или проверку должна выполнить другая.

Модель разделённой ответственности нужно фиксировать для конкретной услуги и конфигурации. Название «IaaS» само по себе не определяет, кто администрирует операционную систему, устанавливает агенты защиты или восстанавливает базу.

Базовое разделение

В типовой модели провайдер отвечает за нижние уровни:

физическую площадку;
питание и охлаждение;
серверы и системы хранения;
физическую сеть;
виртуализационную платформу;
доступность заказанных инфраструктурных компонентов в пределах договора.

Заказчик обычно контролирует:

гостевую операционную систему;
обновления и конфигурацию ОС;
приложения;
учётные записи и права;
сетевые правила своего контура;
данные и сроки их хранения;
резервное копирование на уровне приложения;
соответствие системы своим требованиям.

Между этими зонами находятся управляемые услуги. Например, провайдер может администрировать ОС, межсетевой экран или резервное копирование, но только если это явно входит в услугу.

Постройте матрицу RACI

Для каждого процесса определите:

Responsible — кто выполняет;
Accountable — кто отвечает за результат;
Consulted — кого привлекают к решению;
Informed — кого уведомляют.

Минимальная матрица должна охватывать:

Процесс	Что зафиксировать
Создание VM	шаблон, сеть, владелец, теги
Обновление ОС	периодичность, окно, исключения
Управление доступом	источник учётных записей, MFA, отзыв
Резервное копирование	состав, расписание, срок, шифрование
Восстановление	инициатор, RPO/RTO, проверка
Мониторинг	метрики, пороги, получатель алерта
Инцидент	каналы, сроки, доказательства
Изменение ресурсов	согласование и лимиты
Удаление	подтверждение, сроки, остаточные копии

Фраза «резервное копирование включено» недостаточна. Нужно знать, что именно копируется, где хранится, кто следит за заданиями и кто выполняет тестовое восстановление.

Доступ к панели — критичный периметр

Компрометация панели управления IaaS может дать возможность создавать ресурсы, менять сетевые правила и удалять данные. Заказчику следует:

включить MFA;
разделить административные и повседневные учётные записи;
выдавать минимальные роли;
ограничить доступ доверенными сетями, если это возможно;
использовать персональные учётные записи;
журналировать изменения;
регулярно отзывать неиспользуемые права;
иметь аварийный порядок блокировки.

API-ключи инфраструктуры также требуют срока жизни, ротации и безопасного хранения. Не размещайте их в исходном коде и общих документах.

Сеть: граница проходит не по виртуальному кабелю

Провайдер обеспечивает работу своей физической и виртуальной сети, но правила сегментации обычно задаёт заказчик. Он определяет:

какие сервисы доступны извне;
какие подсети могут взаимодействовать;
где завершается VPN;
кому разрешён административный доступ;
какие потоки журналируются;
как ограничивается исходящий трафик.

Ошибочно открытый порт — это не обязательно отказ инфраструктуры. Поэтому сетевые правила должны проходить review и автоматическую проверку.

Данные и резервные копии

Хранилище с высокой доступностью не равно резервной копии. Репликация может быстро распространить удаление или повреждение на все копии.

Для каждого набора данных определите:

владелец;
классификация;
основной экземпляр;
RPO и RTO;
расписание копирования;
отдельный контур хранения;
защита от удаления;
срок хранения;
порядок восстановления;
подтверждение уничтожения.

Проверяйте восстановление, а не только статус задания. Практические схемы описаны в статье о резервном копировании и отказоустойчивости.

Мониторинг должен соединять два контура

Провайдер видит состояние площадки и платформы, заказчик — поведение ОС и приложения. Для быстрого расследования нужны обе стороны.

Согласуйте:

какие метрики предоставляет провайдер;
что собирается внутри VM;
единый часовой пояс и синхронизацию времени;
идентификаторы ресурсов;
сроки хранения журналов;
порядок передачи диагностических данных;
каналы уведомления об инцидентах.

SLA провайдера не заменяет SLO бизнес-сервиса. Виртуальная машина может быть доступна, пока приложение отвечает ошибкой. Связь между инфраструктурными и пользовательскими показателями описана в материале о SLI и SLO.

Что проверить в договоре

До миграции зафиксируйте:

точное описание услуги;
границы администрирования;
показатели доступности и исключения;
порядок плановых работ;
уведомление об инцидентах;
резервное копирование и восстановление;
размещение и перемещение данных;
доступ сотрудников подрядчика;
предоставление журналов;
прекращение услуги и выгрузку данных;
формат и срок удаления;
порядок изменения тарифов и ресурсов.

Лицензии и сертификаты провайдера относятся к определённой организации, деятельности или контуру. Они не превращают любую размещённую систему в автоматически соответствующую требованиям. Заказчик по-прежнему определяет применимые нормы и проверяет фактическую реализацию.

Проверка перед промышленным запуском

Создайте ресурс по утверждённому шаблону.
Проверьте сегментацию и внешний периметр.
Отзовите тестовую учётную запись.
Установите критичное обновление.
Восстановите данные в изолированную среду.
Смоделируйте недоступность одного компонента.
Проверьте алерты обеих сторон.
Запросите диагностические данные по процедуре поддержки.
Удалите тестовый ресурс и проверьте жизненный цикл копий.

Такой пилот показывает реальную границу ответственности лучше, чем общий список функций.

Как можем помочь

«Лоджик Телеком» может помочь описать матрицу ответственности, целевой контур IaaS, резервное копирование и эксплуатационные процедуры. Начните с одного сервиса и пройдите его жизненный цикл: создание, изменение, инцидент, восстановление и удаление.

Разделение ответственности в IaaS: что контролирует провайдер, а что заказчик