Коротко для керівника
Переїзд у хмару нагадує оренду офісу: будівля, дах і вхід на орендодавцеві, а замок у вашому кабінеті й те, кому ви роздали ключі, на вас. У документації 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-аудиту компанії. Далі працюємо за шістьма кроками.
- Складіть перелік систем у хмарі й для кожної запишіть тип: віртуальна машина чи керований сервіс. Перевірка: у таблиці немає жодної системи без позначки типу та відповідального.
- Для кожної системи розпишіть, хто веде які шари: операційна система, оновлення, програма, брандмауер, дані, доступи. Перевірка: на кожен пункт записане прізвище або посада, а не «провайдер» без уточнення.
- Закрийте оновлення гостьових ОС і програм на віртуальних машинах: призначте графік і виконавця. Перевірка: є звіт про встановлені оновлення за останній місяць і список машин, які його не отримали.
- Перегляньте правила брандмауера (security group) і права доступу (IAM): приберіть зайве, залиште лише потрібне. Перевірка: кожне відкрите правило й кожен обліковий запис мають пояснення, навіщо вони існують; облікових записів звільнених співробітників немає.
- Визначте для даних класифікацію, шифрування та резервні копії. Про копії джерело прямо не говорить, тому питання «хто їх робить і де вони лежать» запишіть окремо. Перевірка: проведено пробне відновлення одного файла або бази й зафіксовано, скільки це зайняло.
- Звірте розподіл ролей із законами та вимогами, які стосуються вашої організації: джерело нагадує, що відповідальність клієнта залежить і від них. Перевірка: є короткий список вимог, до кожної прив'язаний власник і конкретний контроль.
Пріоритет
Тема планова, термінової загрози тут немає. Проте є порядок. Сьогодні достатньо з'ясувати, чи є віртуальні машини в хмарі, за оновлення яких ніхто не відповідає. Цього тижня виконайте кроки 1, 2 і 4. Кроки 3, 5 і 6 закладіть у найближче планове оновлення політик або квартальний перегляд IT.
Якщо немає свого адміністратора
У малих компаніях часто виходить так, що хмарою «займається той, хто її налаштував», і регулярної роботи за цим немає. Якщо у вашій компанії немає людини, яка стежить за оновленнями серверів у хмарі та правами доступу, ці задачі можна передати команді TakeIT.
Часті питання
Чи відповідає провайдер хмари за мої дані?
За документом AWS, у керованих сервісах на кшталт S3 і DynamoDB клієнт сам керує своїми даними, зокрема параметрами шифрування, класифікує активи та видає права через IAM. Провайдер відповідає за інфраструктуру, ОС і платформу. Тобто захищеність самих серверів і те, хто бачить ваші файли, це різні речі.
Достатньо, що провайдер сам оновлює платформу?
Ні, якщо ви використовуєте віртуальні машини. Гостьова операційна система з оновленнями й виправленнями безпеки та ваші застосунки лишаються вашою справою, а провайдер відповідає за шар віртуалізації й нижче. Тому неприбрані вразливості на вашій частині стеку нікому, крім вас, закривати не доведеться.
Чи залежить розподіл від обраних сервісів і вимог?
Так. Джерело зазначає, що відповідальність клієнта залежить від обраних сервісів, від того, як вони вбудовані в ІТ-середовище, та від законів і вимог, які стосуються організації. Тому універсальної таблиці «хто за що» немає, її треба складати під свої системи.
Чи діє така сама модель в інших провайдерів?
Наше джерело описує тільки AWS. В інших провайдерів розподіл може відрізнятися в деталях, тому його варто читати з їхньої документації та договору, а не переносити приклади звідси. Корисний мінімум: знайти, хто веде ОС, оновлення, брандмауер і доступи для кожного сервісу, яким ви користуєтеся.
Висновок
Хмара забирає турботу про залізо, живлення й приміщення, але не про налаштування, оновлення та доступи. Найкорисніша перша дія нічого не коштує: записати за кожною системою, хто за що відповідає. Решта кроків випливає з цього списку, а резервне копіювання й відновлення варто закріпити за конкретною людиною окремо.
Джерела
- Shared Responsibility Model (AWS) · 31 жовтня 2026 р.
