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

Ответственность распределяется между сторонами, а ее границы зависят от модели облачного сервиса, состава подключенных услуг и условий договора. В базовой IaaS-инфраструктуре провайдер может поддерживать работоспособность серверов, систем хранения и гипервизоров, а клиент — администрировать операционные системы и приложения. При подключении управляемой базы данных, резервного копирования или DRaaS часть операций дополнительно поставщик берет на себя.

Такое распределение называют моделью разделённой ответственности, или Shared Responsibility Model. Она определяет, какие компоненты обслуживает провайдер, какие остаются под управлением клиента и кто отвечает за результат. Состав задач зависит от выбранной услуги, поэтому его нужно проверять в документации провайдера и закреплять в договоре.

Модель применяется не только к информационной безопасности. Она затрагивает доступность, производительность, резервное копирование, восстановление после аварий, управление конфигурациями и соблюдение нормативных требований.

В Linx Cloud границы ответственности для IaaS есть в отдельной RACI-матрице: в ней указано, какие операции выполняет провайдер, какие — клиент, а где нужны обе стороны. Документ открытый, поэтому можете посмотреть: матрица распределения ответственности Linx Cloud IaaS.

В собственной инфраструктуре граница обычно понятна. Компания приобретает оборудование, размещает его в серверной или дата-центре, устанавливает программное обеспечение и самостоятельно организует эксплуатацию. Если сервер перегревается, база данных перестает отвечать или резервная копия оказывается повреждена, искать причину приходится внутренней ИТ-команде и ее подрядчикам.

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

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

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

Другой пример: компания рассчитывает, что данные автоматически копируются на резервную площадку. После сбоя выясняется, что услуга резервного копирования не подключалась. Снапшоты на уровне гипервизора действительно создает провайдер — например, в матрице Linx Cloud это зона провайдера. Но снапшот живет в том же инфраструктурном контуре и не является независимой копией: за резервное копирование данных внутри виртуальной машины отвечает клиент. Чтобы избежать подобных ситуаций, используется модель разделенной ответственности.

Эта модель (Shared Responsibility Model) описывает, какие уровни информационной системы обслуживает провайдер, а какие остаются под управлением заказчика.

Облачная система состоит из нескольких слоев:

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

Передача одного слоя провайдеру не означает автоматической передачи всех остальных. Это распределение обусловлено моделью облачного сервиса. В IaaS клиент получает виртуальную инфраструктуру и самостоятельно управляет большей частью программного стека. В PaaS провайдер дополнительно обслуживает платформу исполнения, базы данных или контейнерную среду. В SaaS клиент пользуется готовым приложением, а поставщик управляет почти всеми техническими слоями.

Однако даже в SaaS часть ответственности остается у заказчика. Компания по-прежнему решает, кому выдавать доступ, какие данные загружать в систему, какие права назначать сотрудникам и как действовать при увольнении пользователя.

Модель разделенной ответственности применяется и при выполнении отраслевых требований. Например, PCI Security Standards Council прямо рассматривает безопасность облачной среды как совместную ответственность поставщика и клиента: стороны должны прописать обязанности и утвердить их для каждого применимого требования.

Точный состав ответственности определяется услугой и договором. Но в базовой IaaS-инфраструктуре провайдер управляет нижними инфраструктурными уровнями.

Провайдер обеспечивает работу дата-центра, в котором размещено оборудование. В его зону ответственности входят электропитание и резервные источники энергии, охлаждение, пожаротушение, физическая безопасность, контроль доступа и инженерный мониторинг.

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

В IaaS провайдер отвечает за работоспособность гипервизоров и управляющих компонентов облачной платформы. Он распределяет физические ресурсы между виртуальными средами, устраняет сбои платформы и поддерживает ее доступность в пределах заявленного SLA.

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

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

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

Например, виртуальная машина доступна на уровне платформы, но приложение внутри нее — остановлено. Поэтому ответственность провайдера за инфраструктурный слой не отменяет ответственности клиента за программную часть системы и ее конфигурацию.

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

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

• какие компоненты нужно дублировать;
• в каких зонах или на каких площадках их размещать;
• как переключать нагрузку;
• какие RTO (за сколько сервис должен вернуться в работу) и RPO (какой объем данных допустимо потерять) требуются бизнесу;
• сколько ресурсов понадобится при пиковом потреблении.

Перед настройкой инфраструктуры системы классифицируют по техническим зависимостям и требованиям к размещению. Linx Cloud может помочь собрать эту информацию, а критичность сервисов, допустимый простой и приоритет восстановления заказчик определяет вместе с владельцами бизнес-процессов.

В базовом IaaS клиент сам отвечает за операционные системы внутри виртуальных машин:

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

Если операционная система не обновлялась несколько лет и была скомпрометирована через известную уязвимость, сам факт размещения в облаке не переносит ответственность на провайдера. Исключение составляют управляемые услуги, в которых обслуживание ОС отдельно передано поставщику.

Заказчик отвечает за программное обеспечение, которое он разворачивает поверх инфраструктуры:

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

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

Большая часть инцидентов не требует физического доступа к серверу. Достаточно получить учетную запись с избыточными правами.

Поэтому бизнес обычно отвечает за:

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

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

Компания определяет, какие данные размещаются в облаке, кто имеет к ним доступ и как долго они должны храниться. Если речь идет о персональных данных, передача инфраструктуры провайдеру не снимает обязанностей с оператора. Статья 19 Федерального закона № 152-ФЗ требует от оператора принимать необходимые правовые, организационные и технические меры защиты либо обеспечивать их принятие. Поэтому заказчику необходимо определить:

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

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

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

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

Заказчик отвечает за безопасность ресурсов, развернутых внутри облачной среды:

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

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

Например, слишком широкое правило межсетевого экрана открывает административный интерфейс приложения в интернете. Если при этом используется стандартный пароль, причиной инцидента становится конфигурация клиентской среды. Облачная платформа в такой ситуации выполняет заданные настройки и предоставления сетевой доступности ресурса.

Если уязвимость находится в гипервизоре или управляющем компоненте платформы, доступ к которому есть только у поставщика, обновление и устранение уязвимости выполняет провайдер.

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

Резервное копирование — один из наиболее распространенных источников разногласий. Клиент создает виртуальную машину и предполагает, что провайдер автоматически хранит ее копию. Однако базовая услуга IaaS включает только вычислительные ресурсы и дисковое пространство. Резервное копирование в таком случае заказывается отдельно или настраивается средствами клиента. Кроме того, нужно различать несколько механизмов:

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

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

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

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

Также важно заранее определить срок хранения копий, порядок восстановления, ответственных за запуск процедуры, регулярность проверки копий и время, необходимое для возврата сервиса в работу.

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

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

Провайдер может отвечать за:

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

Заказчик обычно отвечает за:

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

Даже в управляемом DRaaS необходимо заранее определить, кто имеет право объявить аварию и инициировать переключение. В базе знаний Linx Cloud для DRaaS используется отдельная матрица ответственности, которая фиксирует границы между провайдером и клиентом при настройке репликации, тестировании, аварийном переключении и обратном переносе нагрузки.

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

Таблица показывает общий принцип распределения ответственности, но фактические границы зависят от состава услуг и условий договора. В IaaS часть задач можно передать провайдеру через дополнительные сервисы, например администрирование ОС, резервное копирование или мониторинг. При этом даже управляемые сервисы не снимают с клиента ответственность за данные, настройки приложений и контроль использования ресурсов.

SLA (соглашение об уровне сервиса) фиксирует конкретные показатели для определенной услуги. В SLA могут указываться:

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

При этом SLA не всегда включает восстановление приложений, возврат удаленных данных, исправление ошибок внутри ОС или достижение целевых RTO/RPO. Например, у Linx Cloud есть гарантированное SLA для облачных сервисов до 99,99%. Показатель относится к конкретной услуге и не означает автоматическую доступность приложения на том же уровне.

Одного общего раздела в договоре не всегда недостаточно. Для сложной инфраструктуры удобнее составить матрицу ответственности.

В строках перечисляют процессы и компоненты:

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

В столбцах указывают участников:

• облачный провайдер;
• внутренняя ИТ-команда;
• служба информационной безопасности;
• разработчики;
• внешний интегратор;
• владельцы бизнес-систем.

Для каждого действия определяют роль. Можно использовать модель RACI:

• R — Responsible: выполняет работу;
• A — Accountable: несет итоговую ответственность;
• C — Consulted: участвует в согласовании;
• I — Informed: получает информацию о результате.

Например, провайдер может выполнять восстановление виртуальной машины, руководитель ИТ — утверждать запуск процедуры, владелец приложения — проверять работоспособность, а служба безопасности — получать информацию об инциденте.

В документации Linx Cloud опубликована отдельная матрица распределения ответственности для IaaS. Она использует RACI и показывает, как роли провайдера и клиента распределяются между уровнями облачной инфраструктуры.

Главная ценность матрицы заключается не в самом документе. Она заставляет стороны заранее обсудить процессы, о которых иначе вспоминают только во время сбоя.

Даже при наличии SLA и технического описания услуги границы между провайдером и заказчиком могут оставаться неясными. Чаще всего проблема возникает не из-за отсутствия документов, а из-за слишком общих формулировок: в них не указано, кто выполняет конкретную операцию, кто контролирует результат и кто принимает решение при инциденте.

Перед переходом в облако важно заранее установить, кто за что отвечает, и закрепить это в договоре, SLA, техническом задании или матрице ответственности.

Стоит проверить, какие компоненты входят в услугу и кто отвечает за сеть, виртуальные маршрутизаторы, межсетевые экраны, резервирование и доступность инфраструктуры. Отдельно важно зафиксировать правила эксплуатации: кто обновляет ОС, контролирует ресурсы, работает с журналами и отвечает за мониторинг.

Необходимо заранее определить условия резервного копирования: где хранятся копии, как они защищены, кто выполняет тестовое восстановление и какие показатели RPO и срок хранения гарантируются. Для аварийного восстановления важно согласовать наличие резервной площадки, порядок переключения, целевые значения RTO и возврат в штатный режим.

Также стоит описать требования к безопасности и поддержке: управление доступами, работу с инцидентами, доступность каналов связи, сроки реакции и порядок эскалации. Все эти условия должны быть закреплены документально, чтобы при возникновении проблем у сторон не возникало разных трактовок ответственности.

Разделенная ответственность не означает, что бизнес должен самостоятельно заниматься всеми задачами выше уровня гипервизора. При необходимости часть операций можно передать провайдеру: администрирование операционных систем, мониторинг, резервное копирование, управление базами данных, аварийное восстановление, миграцию, настройку средств защиты и техническое сопровождение отдельных компонентов.

При этом такая передача должна быть четко зафиксирована. Формулировки вроде «провайдер помогает с инфраструктурой» не устанавливает зону ответственности. В договоре важно указать, какие именно операции выполняются, в каком режиме оказывается услуга, какие есть сроки реакции, права доступа, порядок изменений, ответственность за результат и возможные ограничения.

Чем точнее описаны условия взаимодействия, тем меньше риск разногласий при возникновении проблем.

При выборе облачного провайдера важно понимать не только набор доступных ресурсов, но и границы услуги.

В Linx Cloud распределение ролей для IaaS описано отдельной матрицей ответственности. Провайдер отвечает за инфраструктурный уровень облачной платформы, а заказчик — за управляемые им виртуальные ресурсы, приложения, данные и пользовательские настройки в пределах выбранной модели.

Если компании необходимо передать часть дополнительных задач, к облачной инфраструктуре можно подключить сервисы резервного копирования и аварийного восстановления. Linx Cloud предоставляет облачное резервное копирование для виртуальных и физических серверов, а также DRaaS для восстановления инфраструктуры на резервной площадке.

При этом подключение управляемого сервиса не отменяет участие заказчика. Бизнес по-прежнему определяет критичность систем, требования к RTO и RPO, политику хранения, состав защищаемых данных и критерии успешного восстановления.

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

Распределение ответственности лучше начинать с описания реальной инфраструктуры, а не с формулировок договора. Сначала нужно понять, из каких компонентов состоит сервис, кто ими управляет и какие действия выполняются при обычной эксплуатации и во время инцидента.

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

Для каждого компонента укажите конкретного владельца: провайдер, внутренняя ИТ-команда, служба информационной безопасности, разработка, DevOps, интегратор или владелец бизнес-системы. При этом важно указать роль каждого из них, чтобы было понятно, за какие решения и результаты они отвечают.

Формулировка «ИТ-отдел отвечает за приложение» слишком общая. Необходимо отдельно определить, кто устанавливает обновления, меняет конфигурацию, отслеживает ошибки, реагирует на предупреждения, проверяет резервные копии и подтверждает восстановление.

После этого модель нужно сверить с договором и SLA. Если операция фактически выполняется провайдером, но не закреплена документально, при инциденте возникнет спорная зона. Возможна и обратная ситуация: услуга оплачена, но внутренняя команда не включила ее в регламенты и продолжает выполнять работу самостоятельно.

Для проверки подойдет практический сценарий: критичное приложение перестало отвечать в нерабочее время. Команда должна последовательно определить, кто обнаруживает проблему, кто проверяет облачную платформу, кто анализирует операционную систему, кто связывается с провайдером, кто принимает решение о восстановлении и кто подтверждает работу бизнес-сервиса. Если последовательность требует импровизации, матрица ответственности пока не отражает реальный процесс.

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

Перед запуском облачной инфраструктуры проверьте следующие пункты:

☐ Определено, какие компоненты входят в услугу провайдера.

☐ Зафиксировано, кто администрирует гостевые операционные системы.

☐ Назначены ответственные за приложения и базы данных.

☐ Определено, кто создает пользователей и управляет правами.

☐ Понятно, входит ли резервное копирование в услугу.

☐ Установлены сроки хранения и периодичность создания копий.

☐ Назначен ответственный за проверку восстановления.

☐ RTO и RPO согласованы с бизнесом.

☐ Описан порядок объявления аварии и запуска DR.

☐ Зафиксирован владелец каждого бизнес-сервиса.

☐ Определены каналы связи и порядок эскалации.

☐ SLA соотнесен с архитектурой приложения.

☐ Матрица ответственности отражает фактическую инфраструктуру.

☐ Назначена дата следующего пересмотра документа.

Работа облачной инфраструктуры строится на разделении ответственности между провайдером и заказчиком. Провайдер отвечает за уровни, которые входят в его услугу. Заказчик отвечает за архитектуру систем, приложения, данные, пользователей и настройки, которые остаются под его контролем.

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

Эффективная модель ответственности должна быть заранее зафиксирована в договоре, SLA и технических регламентах. Если зоны ответственности определены и проверены на практике, облачная инфраструктура остается предсказуемой и управляемой.