Коротко для руководителя
Переезд в облако похож на аренду офиса: здание, крыша и вход на арендодателе, а замок в вашем кабинете и то, кому вы раздали ключи, на вас. В документации AWS это называют моделью общей ответственности (Shared Responsibility Model): провайдер защищает инфраструктуру, клиент отвечает за свои системы, данные и настройки.
На практике провайдер берёт на себя оборудование, сеть, помещения и слой виртуализации. Всё, что вы разворачиваете сверху, остаётся вашим: обновления операционной системы, программы, правила брандмауэра, доступы к данным. Сколько именно работы остаётся на вас, зависит от типа сервиса. Это лучше выяснить до переезда, а не после первого инцидента.
Кого это касается
Тема касается компаний на 10–250 человек, которые держат серверы, базы или файлы в публичном облаке либо только планируют перенос серверов в облако. Источник описывает AWS, поэтому примеры ниже именно о нём. Логику распределения полезно проверить и у других провайдеров, но их границы нужно брать из их документации и договора.
Напрямую это не касается тех, кто держит всё на собственном сервере в офисе. Там делить ответственность не с кем: она полностью ваша, от розетки до паролей. Тем, кто просто пользуется готовой облачной почтой или похожим сервисом, этот материал даст общую рамку, но распределение ролей для таких сервисов нужно читать в их условиях.
Что это значит для компаний в Украине
Для украинского бизнеса вывод тот же, что и везде: облако меняет то, кто обслуживает физический слой, но не отменяет работу с вашими системами. Проблемы возникают, когда вместе с железом будто бы «переезжают» и обновления, и права доступа, и копии.
Реальные последствия будничные, без драматизма: устаревшая гостевая операционная система на виртуальной машине, лишний открытый порт, доступ бывшего сотрудника к хранилищу. Всё это решается порядком в распределении ролей, а не сложной техникой.
Как это работает
Модель делит ответственность на два уровня, и от выбранного сервиса зависит, где проходит граница. Ниже о том, как эта граница смещается.
Безопасность «of» облака и «in» облаке
AWS называет свою часть безопасностью самого облака (Security «of» the Cloud). Это аппаратура, программное обеспечение, сети и помещения, на которых работают сервисы. Часть клиента называется безопасностью в облаке (Security «in» the Cloud), и её объём определяется выбранными сервисами. Чем больше настроек сервис оставляет вам, тем больше работы на вашей стороне.
Виртуальная машина (IaaS)
Amazon EC2 в документации отнесён к модели «инфраструктура как услуга» (Infrastructure as a Service, IaaS). Провайдер даёт виртуальную машину, а всё, что внутри, ведёт клиент: операционную систему с обновлениями и исправлениями безопасности, установленные программы и утилиты, а также брандмауэр (security group) для каждой машины.
Проще говоря, виртуальной машине в облаке нужна та же дисциплина, что и физическому серверу в офисе. Если раньше сервер обслуживал администратор, переезд эту работу не отменяет. Меняется лишь то, что о замене диска и розетке вам больше переживать не нужно.
Управляемые сервисы
Для абстрагированных сервисов, таких как Amazon S3 и Amazon DynamoDB, провайдер ведёт инфраструктуру, операционную систему и платформы. Клиент подключается к точкам доступа, чтобы хранить и получать данные. Его зона сужается до самих данных: параметры шифрования, классификация активов и права, которые выдаются через инструменты IAM (управление идентификаторами и доступом).
Забота об обновлении системы исчезает, но остаётся вопрос «кто что может увидеть». Именно поэтому права доступа в управляемых сервисах стоит проверять внимательнее, чем кажется.
Три типа контролей
Источник различает контроли унаследованные, общие и специфические для клиента. Унаследованные клиент получает от провайдера полностью, например физические и средовые. Общие действуют на обоих уровнях, но в разном контексте: провайдер задаёт требования к инфраструктуре, а клиент сам реализует свою часть.
Примеры общих контролей из документа: управление обновлениями (провайдер исправляет инфраструктуру, клиент гостевую ОС и приложения), управление конфигурацией (провайдер настраивает свои устройства, клиент собственные ОС, базы и программы) и обучение (провайдер учит своих людей, вы своих). К специфическим контролям клиента относится, например, зонирование данных и маршрутизация между зонами безопасности. Так что обучение сотрудников в облаке не делегируется никому.
Варианты
Для компании среднего размера распределение ролей сводится к выбору одного из трёх вариантов. Чем ниже по списку, тем меньше технической работы на вашей стороне, но тем внимательнее нужно читать, что именно входит в услугу.
Собственный сервер в офисе
Всё на вас: помещение, питание, сеть, система, программы, данные. Это прозрачно, но включает и физические риски, связанные с помещением и питанием.
Виртуальная машина в публичном облаке
Физический слой и виртуализация переходят к провайдеру, а гостевая ОС, обновления, программы и брандмауэр остаются за вами. Это удобно, если у вас есть человек или команда, которая уже обслуживает серверы и просто меняет место их размещения.
Управляемый сервис
Провайдер ведёт платформу, вы отвечаете за данные, шифрование, классификацию и права. Работы по обслуживанию системы меньше, зато ошибка в настройке доступа становится основным риском.
Если часть задач вы передаёте внешнему исполнителю, например на IT-аутсорсинг, границы ответственности стоит зафиксировать письменно в договоре и читать их так же внимательно, как документацию облачного провайдера.
Как выбрать
Выбирать можно только тогда, когда видно, что именно вы переносите или уже перенесли. Если полного перечня систем нет, его можно составить самостоятельно или в рамках IT-аудита компании. Дальше работаем по шести шагам.
- Составьте перечень систем в облаке и для каждой запишите тип: виртуальная машина или управляемый сервис. Проверка: в таблице нет ни одной системы без отметки о типе и ответственном.
- Для каждой системы распишите, кто ведёт какие слои: операционная система, обновления, программа, брандмауэр, данные, доступы. Проверка: на каждый пункт записаны фамилия или должность, а не «провайдер» без уточнения.
- Закройте обновления гостевых ОС и программ на виртуальных машинах: назначьте график и исполнителя. Проверка: есть отчёт об установленных обновлениях за последний месяц и список машин, которые их не получили.
- Пересмотрите правила брандмауэра (security group) и права доступа (IAM): уберите лишнее, оставьте только нужное. Проверка: у каждого открытого правила и каждой учётной записи есть пояснение, зачем они существуют; учётных записей уволенных сотрудников нет.
- Определите для данных классификацию, шифрование и резервные копии. О копиях источник прямо не говорит, поэтому вопрос «кто их делает и где они лежат» запишите отдельно. Проверка: проведено пробное восстановление одного файла или базы и зафиксировано, сколько это заняло.
- Сверьте распределение ролей с законами и требованиями, которые касаются вашей организации: источник напоминает, что ответственность клиента зависит и от них. Проверка: есть короткий список требований, к каждому привязаны владелец и конкретный контроль.
Приоритет
Тема плановая, срочной угрозы здесь нет. Но порядок есть. Сегодня достаточно выяснить, есть ли в облаке виртуальные машины, за обновления которых никто не отвечает. На этой неделе выполните шаги 1, 2 и 4. Шаги 3, 5 и 6 заложите в ближайшее плановое обновление политик или квартальный пересмотр IT.
Если нет своего администратора
В небольших компаниях часто получается так, что облаком «занимается тот, кто его настроил», а регулярной работы за этим нет. Если в вашей компании нет человека, который следит за обновлениями серверов в облаке и правами доступа, эти задачи можно передать команде TakeIT.
Частые вопросы
Отвечает ли провайдер облака за мои данные?
По документу AWS, в управляемых сервисах вроде S3 и DynamoDB клиент сам управляет своими данными, в том числе параметрами шифрования, классифицирует активы и выдаёт права через IAM. Провайдер отвечает за инфраструктуру, ОС и платформу. То есть защищённость самих серверов и то, кто видит ваши файлы, это разные вещи.
Достаточно ли того, что провайдер сам обновляет платформу?
Нет, если вы используете виртуальные машины. Гостевая операционная система с обновлениями и исправлениями безопасности и ваши приложения остаются вашим делом, а провайдер отвечает за слой виртуализации и ниже. Поэтому незакрытые уязвимости на вашей части стека никто, кроме вас, не устранит.
Зависит ли распределение от выбранных сервисов и требований?
Да. Источник отмечает, что ответственность клиента зависит от выбранных сервисов, от того, как они встроены в IT-среду, а также от законов и требований, которые касаются организации. Поэтому универсальной таблицы «кто за что» нет, её нужно составлять под свои системы.
Действует ли такая же модель у других провайдеров?
Наш источник описывает только AWS. У других провайдеров распределение может отличаться в деталях, поэтому его стоит читать из их документации и договора, а не переносить примеры отсюда. Полезный минимум: выяснить, кто ведёт ОС, обновления, брандмауэр и доступы для каждого сервиса, которым вы пользуетесь.
Вывод
Облако забирает заботу о железе, питании и помещениях, но не о настройках, обновлениях и доступах. Самое полезное первое действие ничего не стоит: записать по каждой системе, кто за что отвечает. Остальные шаги вытекают из этого списка, а резервное копирование и восстановление стоит закрепить за конкретным человеком отдельно.
Источники
- Shared Responsibility Model (AWS) · 31 октября 2026 г.
