Перехід на хмару часто сприймають так: «наші дані тепер у Google чи Microsoft, отже, вони й відповідають». Найдорожча ілюзія галузі. Відповідальність ділиться — і майже всі витоки стаються саме на тій половині, яка лишилася замовникові.
Спершу про самі слова
Запит «інформаційна кібербезпека» зшиває два поняття, які насправді вкладені одне в одне: захист цифрового простору — лише частина захисту відомостей загалом (докладний розбір меж — окремо).
Інформаційна безпека в ІТ — це прикладний зріз: захищеність систем, мереж, застосунків та облікових записів, якими компанія користується щодня. Хмара цей зріз не скасовує, а перевертає: звичні рубежі зникають, натомість з'являються нові.
Інформація про IT безпеку хмарних сервісів зазвичай зводиться до десятків чеклістів. Почати ж варто з одного поняття, без якого решта безглузда.
Модель спільної відповідальності
Постачальник відповідає за захищеність самої платформи:
- фізична охорона дата-центрів;
- обладнання, живлення, канали зв'язку;
- гіпервізор та базові служби.
Замовник відповідає за все, що робить усередині платформи:
- налаштування доступу — хто й що бачить;
- конфігурація сервісів (те саме «випадково публічне» сховище);
- власні відомості: класифікація, шифрування, резервні копії;
- облікові записи: паролі, другий фактор, права;
- застосунки й код, які розгортає.
| Модель сервісу | Що бере на себе постачальник | Що лишається замовникові |
|---|---|---|
| Оренда інфраструктури (IaaS) | Залізо, мережа, гіпервізор | Операційна система, оновлення, застосунки, доступи, відомості |
| Платформа (PaaS) | Плюс операційна система та середовище виконання | Код, конфігурація, доступи, відомості |
| Готовий сервіс (SaaS) | Плюс сам застосунок | Налаштування, ролі, відомості, облікові записи |
Правило, яке варто запам'ятати: що вищий рівень сервісу, то більше бере на себе постачальник — але доступи й ваші відомості лишаються вашими завжди. Жодна модель цього не змінює.
Юридичний бік: відповідальність не орендується
Технічну роботу справді можна перекласти на постачальника. Відповідальність перед клієнтом і регулятором — ні. Якщо база покупців витекла через хибне налаштування вашого сховища, пояснення «винна хмара» нікого не цікавить: перед людьми, чиї відомості опинилися назовні, відповідає компанія, яка їх зібрала.
Звідси й практичний висновок: договір із постачальником треба читати — саме там написано, за скільки годин вас сповістять після інциденту, де фізично зберігаються копії та що станеться, коли ви вирішите піти.
Спільна відповідальність на живому прикладі
Компанія орендує об'єктне сховище й тримає там скани договорів. Постачальник забезпечує надійність дисків, живлення дата-центру та стійкість служби — усе бездоганно. Адміністратор, налаштовуючи доступ підрядникові, ставить політику «читання дозволено всім»: так швидше, ніж розбиратися з ролями. Через місяць пошуковий робот індексує каталог, і скани договорів стають доступні будь-кому.
Хто винен? Формально постачальник виконав зобов'язання повністю. Технічно сховище відпрацювало рівно так, як його налаштували. Юридично відповідає компанія. Саме тому межу відповідальності треба знати ще до першого завантаженого файлу.
Типові помилки переходу
- Хибна конфігурація — головна причина витоків: сховище, відкрите «всьому світові», надто широкі ролі, службовий обліковий запис із правами адміністратора.
- Перенесення старих звичок — плаский доступ «як було раніше», відсутність сегментації, спільні паролі команди.
- Ілюзія резервної копії. Платформа реплікує вміст між зонами, але реплікація бекапом не є: помилкове видалення чи програма-вимагач знищать і копію. Потрібен окремий, ізольований архів.
- Тіньові сервіси. Команда підключає зручний інструмент карткою керівника, служба захисту дізнається згодом — уже після витоку.
- Ключі доступу, забуті серед коду. Токен, залитий до репозиторію, живе роками — і його знаходять автоматичні сканери, а не ваші аудитори.
- Журнали, яких немає. Багато сервісів зберігають записи подій обмежений час або взагалі вимикають детальне журналювання за замовчуванням. Компанія дізнається посеред розслідування — коли з'ясовується, що подій піврічної давнини просто не існує.
Останній пункт варто перевірити цього тижня. Розслідування без журналів перетворюється на ворожіння. Робочий порядок: увімкнути детальне журналювання, задати строк зберігання щонайменше рік і вивантажувати копію назовні — туди, куди скомпрометований адміністратор дотягнутися вже не зможе.
Як знаходять тіньові сервіси
Найпростіший спосіб коштує нуль: візьміть виписку корпоративної картки за півроку й порахуйте всі підписки. Другий спосіб — журнал запитів до служби імен: він показує, куди насправді ходять робочі станції. Зазвичай знаходиться десяток інструментів, яких служба захисту ніколи не бачила, — від файлообмінників до перекладачів документів, куди співробітники вставляють тексти договорів.
Інформаційна безпека у хмарі: що змінюється порівняно зі звичним ІТ
| Було (власний сервер) | Стало (оренда сервісу) |
|---|---|
| Рубіж — мережа офісу | Рубіж — обліковий запис |
| Захист — екран на вході | Захист — правильна конфігурація й ролі |
| Усе під фізичним контролем | Частина контролю — у постачальника |
| Зміни повільні, помилки помітні | Ресурси створюються за секунди, помилки — так само |
Головний зсув саме тут: новим рубежем став обліковий запис. Компрометація одного адміністративного входу відкриває все й одразу, без жодного зламу мережі. Тому багатофакторна автентифікація, мінімальні права та моніторинг подій адміністраторів стають критичними — а не «бажаними».
Хмарна інформаційна безпека взагалі тримається на трьох речах: хто зайшов, що йому дозволено й чи хтось за цим спостерігає.
Де фізично лежать ваші файли
Питання регіону виглядає бюрократичним рівно доти, доки не стає юридичним. Український бізнес масово переніс системи за кордон, і тепер копії договорів, кадрових документів та клієнтських баз лежать на серверах, підпорядкованих чужому праву. Наслідків щонайменше три: до вмісту можуть застосовуватися вимоги іншої держави, швидкість реакції підтримки залежить від часового поясу, а перенесення архіву назад коштуватиме грошей і часу.
Мінімум, який варто зафіксувати письмово: регіон зберігання, перелік країн, куди вміст може реплікуватися, і зобов'язання постачальника попереджати щодо зміни регіону.
Чого оренда сервісу не змінює
Три речі лишаються рівно там само, де були. Перше — навчання персоналу: фішинговий лист однаково приходить людині, а не постачальникові. Друге — керування доступами: звільнений працівник має втратити вхід того самого дня, байдуже, чий сервер. Третє — план дій на випадок інциденту: телефонувати підтримці посеред ночі, не маючи заздалегідь розписаних кроків, — погана стратегія.
Оренда змінює місце розташування ресурсів. Обов'язки вона не скасовує.
Як обирати постачальника
Перевірка перед підписанням договору коротка:
- Сертифікати. Чинний ISO 27001, звіти незалежних аудиторів, спеціальні заходи захисту.
- Розташування. Де фізично зберігаються відомості й куди їх можуть переносити.
- Сповіщення. За скільки годин постачальник зобов'язаний повідомити про інцидент — і чи взагалі зобов'язаний.
- Вихід. Як забрати архів, у якому форматі, скільки коштує вивантаження та коли постачальник зобов'язаний знищити копії.
Четвертий пункт згадують рідко, а він визначає, чи стане зручний сервіс пасткою через три роки.
Які стандарти застосовувати
- ISO/IEC 27017 — заходи захисту хмарних сервісів: окремо описано, що робить постачальник, а що замовник.
- ISO/IEC 27018 — поводження з персональними відомостями на боці постачальника.
- ISO/IEC 27001 — базова система управління, усередині якої живе решта.
Інформаційна безпека для використання хмарних послуг вимагає не окремої системи, а розширення наявної: ті самі активи, ризики й заходи, просто частина заходів тепер виконується чужими руками — і виконання треба перевіряти.
Практичний мінімум
- багатофакторна автентифікація — обов'язково всім адміністраторам, бажано всім;
- перевірка публічного доступу до сховищ (разова перевірка + автоматичний контроль);
- ролі за принципом мінімальних привілеїв, окремий запис на кожну задачу;
- окремі резервні копії поза платформою постачальника;
- увімкнене детальне журналювання й сповіщення про підозрілі дії;
- інвентаризація сервісів: хто, що й чиєю карткою оплатив.
Перелічене закриває більшість типових сценаріїв — і жоден пункт не потребує дорогих закупівель.