ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/5993| Title: | Система забезпечення кіберстійкості підприємства через призму хмарних технологій |
| Authors: | Панаско, Олена Миколаївна Проценко, Олександр Арнольдович |
| Keywords: | кiберстiйкiсть;вимоги до хмари;контролі;стійкість хмар;хмарна архітектура;провайдери хмарних сервісів |
| Issue Date: | 2024 |
| Abstract: | Основною метою є дослідження загальних концепцій та пошук вимог для забезпечення кіберстійкості підприємства в галузі хмарних технологій. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/5993 |
| Appears in Collections: | 125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| М_125_Проценко_Панаско.pdf Restricted Access | 949.47 kB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ЕЛЕКТРОННИХ ТЕХНОЛОГІЙ,
АВТОТРАНСПОРТУ ТА МАШИНОБУДУВАННЯ
КАФЕДРА РОБОТОТЕХНІЧНИХ І ТЕЛЕКОМУНІКАЦІЙНИХ СИСТЕМ
ТА КІБЕРБЕЗПЕКИ
До захисту допущено
завідувач кафедри РТСК
д.т.н., професор
_______________ В.В. Палагін
"_____" _____________ 2024 року
Пояснювальна записка
до дипломного роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему Система забезпечення кіберстійкості підприємства через призму
хмарних технологій
Виконав: студент 2 курсу, групи мБІ-31
Спеціальності 125 – ««Кібербезпека та захист
інформації»» ,
(шифр і назва спеціальності)
освітньої програми «Безпека інформаційних і ко-
мунікаційних систем»
(назва освітньої програми)
Проценко О.А.
(прізвище та ініціали)
Керівник Панаско О.М.
(прізвище та ініціали)
Рецензент Чепинога А.В.
(прізвище та ініціали)
Черкаси – 2024 року
Черкаський державний технологічний університет
Факультет Електронних технологій і робототехніки
Кафедра Робототехнічних і телекомунікаційних систем та кібербезпеки
Освітньо-кваліфікаційний рівень/освітній ступінь Магістр
ЗАТВЕРДЖУЮ
Завідувач кафедри
____________ Володимир ПАЛАГІН
«____»__________2024 р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Проценку Олександру Арнольдовичу
(прізвище, ім’я, по батькові)
1. Тема проекту (роботи): cистема забезпечення кіберстійкості підприємства
через призму хмарних технологій
Керівник роботи к.т.н., доцент Панаско Олена Миколаївна
(посада, науковий ступінь, вчене звання, прізвище, ім’я, по батькові)
затверджені наказом університету від «» травня 2024 р. №
2. Термін подання студентом роботи «26» листопада 2024 р.
3. Вихідні дані до роботи: контролі та вимоги для забезпечення кіберстійкості
підприємства, через призму хмарних технологій
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить
розробити): аналіз методологій та методів підвищення кіберстійкості,
застосування вимог до хмарних провайдерів та їх порівняння
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень)
презентація
Календарний план
№ Назва етапів кваліфікаційної Термін виконання
Примітка
з/п роботи магістра етапів роботи
1 Отримання теми 02.09.2024 Виконано
2 Огляд теоретичних основ 18.09.2024 Виконано
визначених стандартів
3 Ознайомлення з методами 30.09.2024 Виконано
забезпечення кіберстійкості хмар
4 Перегляд методологій для оцінки 12.10.2024 Виконано
стійкості
5 Огляд нормативної бази України 22.10.2024 Виконано
щодо хмарних технологій
6 Аналіз статистичних даних щодо 05.11.2024 Виконано
систем забезпечення
кіберстійкості на підприємстві
7 Ідентифікація систем, контролів 15.11.2024 Виконано
та вимог для підвищення
стійкості хмар
8 Порівняння показників стійкості 20.11.2024 Виконано
провайдерів
9 Підготовка до передзахисту 26.11.2024 Виконано
Студент ____________ Проценко О. А.
(підпис) (прізвище та ініціали)
Керівник роботи ____________ Панаско О. М.
(підпис) (прізвище та ініціали)
5
РЕФЕРАТ
Обсяг роботи 116 сторінок, 5 ілюстрацій, 11 таблиць та 35 джерел літератури.
Актуальна тенденція полягає в дослідженні контролів, які можуть забезпечити
кіберстійкість підприємства через призму хмарних технологій.
Основною метою є дослідження загальних концепцій та пошук вимог для
забезпечення кіберстійкості підприємства в галузі хмарних технологій.
Об’єктом дослідження являються методології та контролі для визначення
етапів підвищення кіберстійкості підприємства, націлених на хмару.
Предметом дослідження є забезпечення стану кіберстійкості на підприємстві
за допомогою питань, методик та контролів.
Задачі дипломної роботи:
• огляд систем та методів, які використовуються для забезпечення кіберстійкості
на підприємстві через хмару;
• вивчення питань та контролів, які застосовуються до хмарних провайдерів;
• визначення стійкості хмарних провайдерів.
Результати досліджень апробовано на 1st Ukrainian Scientific and Practical
Conference «Scientific Research Methodology – 2024» Черкаського державного
технологічного університету, 15-16 листопада 2024 року.
Ключові слова: кiберстiйкiсть, вимоги до хмари, контролі, питання до
провайдера, стійкість хмар.
6
ABSTRACT
The volume of work is 116 pages, 5 illustrations, 11 tables and 35 literature sources.
The current trend is to study controls that can ensure enterprise cyber resilience
through cloud technologies.
The main goal is to study general concepts and search for requirements for ensuring
enterprise cyber resilience in the field of cloud technologies.
The object of the study is methodologies and controls for determining the stages of
increasing enterprise cyber resilience, aimed at the cloud.
The subject of the study is ensuring the state of cyber resilience in the enterprise
using questions, methods and controls.
Tasks:
• review of systems and methods used to ensure cyber resilience in the enterprise via
the cloud;
• study of issues and controls that apply to cloud providers;
• determine the resilience of cloud providers.
The research results were tested on the 1st Ukrainian Scientific and Practical
Conference «Scientific Research Methodology – 2024» of Cherkasy State
Technological University, November 15-16, 2024.
Keywords: cyber resilience, cloud requirements, controls, questions for the provider,
cloud resilience.
7
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ, СКОРОЧЕНЬ І
ТЕРМІНІВ ..................................................................................................................... 8
ВСТУП .......................................................................................................................... 9
1 ТЕОРЕТИЧНА ОСНОВА ....................................................................................... 11
1.1 Поняття кіберстійкості ..................................................................................... 11
1.2 Підприємства в Україні .................................................................................... 15
1.3 Хмарні технології .............................................................................................. 17
Висновки по розділу 1 ............................................................................................... 20
2 ОСНОВНІ ПІДХОДИ ............................................................................................. 22
2.1 Методологія прогресування кіберстійкості ................................................... 22
2.2 Вимоги-питання до хмарних провайдерів ...................................................... 31
2.3 Огляд методів покращення стійкості .............................................................. 38
2.4 Cloud Security Alliance Cloud Controls Matrix ................................................ 47
Висновки по розділу 2 ............................................................................................... 58
3 ВИЗНАЧЕННЯ СТІЙКОСТІ ХМАРНИХ ПРОВАЙДЕРІВ ............................... 61
Висновки по розділу 3 ............................................................................................. 109
ВИСНОВКИ .............................................................................................................. 110
ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАНЬ ........................................................................... 112
8
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ,
СКОРОЧЕНЬ І ТЕРМІНІВ
ISF – Information Security Forum
CERT-UA – Computer Emergency Response Team of Ukraine
NIST – National Institute of Standards and Technology
IBM – International Business Machines Corporation
SLA – Service-level agreement
CCM – Cloud Controls Matrix
CSA – Cloud Security Alliance
SSRM – Shared Security Responsibility Model
CSP – Cloud Service Provider
CSC – Cloud Service Consumer
IaaS – Infrastructure as a Service
PaaS – Platform as a service
SaaS – Software as а service
CAIQ – Consensus Assessment Initiative Questionnaire
9
ВСТУП
Оскільки бізнес все більше покладається на хмарні технології, потреба в
надійній системі для забезпечення кіберстійкості підприємства стає
першочерговою. Ця концепція виходить за межі традиційних заходів
кібербезпеки, наголошуючи не лише на захисті, але й на відновленні та адаптації
перед атаками. Хмарні технології відіграють вирішальну роль у підвищенні цієї
стійкості, пропонуючи масштабовані рішення, які можуть динамічно
адаптуватися до нових загроз. За допомогою хмарних служб підприємства
можуть використовувати розширені функції безпеки, такі як автоматичний аудит
відповідності, виявлення загроз у реальному часі та шифрування даних.
Актуальність даної роботи полягає у визначенні контролів та вимог які можуть
вплинути на кіберстійкість у підприємстві. Згідно звіту на 2022 рік 59 відсотків
спеціалістів вважають, що терміни "кіберстійкість" та "кібербезпека" є
синонімами. Це підкреслює необхідність чіткого розуміння різних концепцій
захисту та відповідних стандартів. За прогнозами на 2024 рік, інвестиції в
кіберстійкість зростуть на 25%, що свідчить про зростаючу важливість цієї
концепції в умовах посилення кіберзагроз [1].
Основною метою є дослідження загальних концепцій та пошук вимог для
забезпечення кіберстійкості підприємства в галузі хмарних технологій.
Об’єктом дослідження являються методології та контролі для визначення
етапів підвищення кіберстійкості підприємства, націлених на хмару.
Предметом дослідження є забезпечення стану кіберстійкості на підприємстві
за допомогою питань, методик та контролів.
Методами дослідження є огляд новітніх статтей з відповідною темою,
використання стандартного інструментарію та здійснення аналізу кіберстійкості
хмарних провайдерів.
10
Новизна роботи полягає в тому, що одержано результати контролів для аналізу
кіберстійкості хмар на підприємстві та удосконалено базу для визначення
стійкості хмарних технологій.
Практичне значення роботи отриманих результатів звітів полягає у
можливості застосування контролів та методів для забезпеченння рівня
кіберстійкості через призму хмар.
11
1 ТЕОРЕТИЧНА ОСНОВА
1.1 Поняття кіберстійкості
Постійно зростаюча кількість кібератак і різноманітність кіберзагроз у звітах
за попередні роки демонструє ризик, який поточний кіберсценарій представляє
для компаній. Крім того, ці кіберзагрози націлені на малі та середні підприємства,
оскільки вони представляють значне корисне навантаження як група та часто
мають обмежені знання та ресурси, щоб протистояти цим загрозам.
Майже три чверті (72%) усіх респондентів сказали, що їх підприємство зазнала
інциденту протягом останніх 24 місяців, і майже чотири з 10 (40%) зазнали
інциденту за останній рік. Найбільш уразливими виявилися підприємства
середнього розміру: 42% зазнали інциденту минулого року. Невеликі
підприємства мали менше шансів постраждати: трохи більше третини (34%)
зіткнулися з інцидентом минулого року. Підприємства, які зазнали одного
інциденту, часто виявляють, що це не поодинокі випадки. Серед респондентів,
які повідомили, що їхня підприємство зазнало інцидентів за останні 12 місяців,
43% зазнали 10 і більше. Насправді, чверть цієї групи повідомила про 11-30
інцидентів, тоді як інші 16% зазнали від 31 до 60 випадків, тобто один інцидент
кожні 6-11 днів [2]. Цей сценарій кіберзагроз робить кіберінциденти одним із
найвпливовіших і одним із найімовірніших ризиків, з якими стикаються компанії
[3, 4].
З іншого боку, технології швидко розвиваються, роблячи сценарій
кіберзагрози більш нестабільним і протистояти йому ще важче. Наприклад,
Industry 4.0 представляє проблему підключення OT технологій до ІТ-подібних
мереж, яка була вивчена через складність, яку це додає при спробі захистити
мережі та системи [5, 6]. Сценарій агресивної кіберзагрози в поєднанні зі
швидкими змінами в технологіях зробив завдання створення захищених і
безвідмовних систем (мета традиційної кібербезпеки [7]) нереальним способом
12
захисту компанії від кіберінцидентів. У цьому сенсі кілька експертів і
підприємств [8, 9] погодилися, що кібербезпека потребує ширшого підходу, який
вони назвали кіберстійкістю.
Згідно з рішенням Ради національної безпеки і оборони України "Про
Стратегію кібербезпеки України", затвердженим Указом Президента України,
кіберстійкість визначається як здатність підприємства швидко адаптуватися до
внутрішніх і зовнішніх загроз у кіберпросторі, а також відновлювати та
підтримувати стабільну роботу системи [10]. Ця концепція, всупереч традиційній
кібербезпеці, має на меті зробити компанії та їхні системи безпечними до збоїв.
Ця, очевидно, незначна зміна точки зору перетворює кібербезпеку на набагато
більш надійну стратегію, яка готова реагувати, відновлюватися та адаптуватися
після інцидентів, що традиційно не було в пріоритетах кібербезпеки [11, 12].
Таким чином, кіберстійкість також може зробити підприємству більш надійними
проти мінливого сценарію кіберзагроз, з більш надійними та адаптованими
способами протистояти кіберзагрозам.
Хоча впровадження точки зору кіберстійкості може бути рішенням для
компаній, щоб протистояти поточній еволюції технологій і сценарію агресивної
кіберзагрози, кіберстійкість може виявитися важко реалізувати. Ця складність
виникає через те, що вона складається з кількох доменів (управління,
безперервність бізнесу, інформаційна безпека тощо) із сотнями політик [13, 14] і
складних зв’язків між цими доменами та політиками [15].
Форум інформаційної безпеки (ISF) — це група британських спеціалістів з
безпеки інформаційних технологій, що налічує понад 500 груп членів по всьому
світу, мета яких — розробити стандарти, посібники, рекомендації та практичні
настанови в аспекті кібербезпеки. ISF розділив загрозу та способи боротьби з 3
рівнями кібербезпеки [16], як показано на рисунку 1.
13
Рисунок 1.1 – Загальні рівні кібербезпеки
Інформаційна безпека або відома як конфіденційність, цілісність, доступність
(КЦД) представляє, як впоратися з впливом КЦД. Кібербезпека означає, як
боротися із загрозою більшого впливу, ніж КЦД. Кіберстійкість — це керування
невідомими загрозами з кожним показаним рівнем.
Цей фокусний зсув до кіберстійкості стає дедалі вирішальною подією та
метою в наступні роки. Кібератаки неминучі, і в основі будь-якої перспективної
стратегії кібербезпеки лежить стійкість рисунок 1.2 [17]. Лідери повинні
припустити, що інциденти більш імовірні, ніж будь-коли, і що супротивники
тепер більш здатні скомпрометувати або зламати системи чи підприємства. У
системі, операційному середовищі та ланцюгах постачання завжди будуть слабкі
місця та недоліки, якими зловмисники зможуть скористатися.
14
Рисунок 1.2 – Загальна ієрархія
Існує явний дисбаланс між захистом мережі та її атакою, і цей дисбаланс
продовжує зростати, оскільки стають доступні більш ефективні хакерські
ресурси за значно нижчою ціною. Але без постійних інвестицій і відданості
кіберстійкості, підприємства будуть більш уразливими до кібератак і, отже, з
більшою ймовірністю витримають наслідки для репутації, фінансів, операцій і
безпеки.
Ці події спричинили глибоке перезавантаження та адаптацію до традиційних
очікувань щодо управління кіберризиками та його підходів. Учасники
опитування чітко пояснюють, що цифровий ландшафт, який швидко змінюється,
і супутні загрози вимагають трансформації того, як підприємства, державні
органи та окремі особи концептуалізують і впроваджують операційну
кіберстійкість, а також розробляють тактику готовності до боротьби з наступним
поколінням ризиків.
Основні фактори, які обмежують кіберстійкість сучасних систем [18]:
• підприємства не розуміють що таке кіберстійкість, вони зосереджуються на
реагуванні на безпеку та відновленні;
15
• не існує єдиного методу та консенсусу щодо того, що являє собою комплексну
здатність кіберстійкості;
• підприємства стикаються з великими труднощами в точному розумінні
оцінюванні своєї кіберстійкості;
• фахівці не розуміють, як ефективно донести концепції керівникам бізнесу;
• важко підтримувати прозорість щодо своєї стійкості. Така невідкритість може
виникати через побоювання шкоди репутації або регулятивного контролю під
час визначення вразливостей або минулих інцидентів.
1.2 Підприємства в Україні
Зростання цифрових комунікацій та все більшої технологічної конвергенції
між фізичним та логічним та середовищами перетворює кібератаку з простої
можливості на майже неминучий факт. Питання полягає не в тому, чи відбудеться
атака, а в тому, як, коли, де і, якщо це можливо, чому. Це пояснюється тим, що
навіть найсучасніші системи захисту можуть бути зламані з часом через постійні
наступальні дії.
Цифрова війна проти України триває вже багато років. Згідно зі звітом
Microsoft [19], у 2021 році, ще до початку повномасштабного вторгнення, майже
20% усіх кібератак у світі були спрямовані на Україну (19 %). За цим показником
наша країна поступається лише США (46 %).
У 2022 році кількість кібератак значно зросла, майже потроївшись, за даними
Державного центру кіберзахисту. З 24 лютого до кінця року урядова команда
CERT-UA опрацювала 2 194 кіберінциденти. З них 120 атак були спрямовані на
фінансовий сектор, 156 – на комерційні підприємства.
Згідно зі звітом Microsoft, у 2024 році найбільш цільовою країною для атак на
території Європи є саме Україна. А саме близько 300 атак. Крім цього, російські
зловмисні групи атакують країни Європи найбільше 68%. Приблизно 75% цілей
були в Україні. Наша країна залишається країною, на яку найбільше націлюються
16
російські групи. Щодо секторів проведення атак, росія атакує у 33 % саме урядові
органи та у 15 % IT підприємства.
З червня 2023 року зловмисники, пов’язані з російською військовою
розвідкою, використовували принаймні два підходи, щоб отримати доступ до
українських військових і суміжних військових пристроїв:
• черв’яки, що передаються через USB: Aqua Blizzard — щодня отримуюються
доступ до 500–750 українських пристроїв через USB-доставку файлу Windows
ShortCut і сильно обфускований Powershell або VBScript. Сценарії встановлюють
команду та контроль, що полегшує крадіжку файлів певних типів. Оскільки
черв’яків та шкідливі USB важко локалізувати, і вони можуть потрапляти на
пристрої поза межами діяльності Aqua Blizzard, існує підвищений ризик того, що
USB та зловмисне програмне забезпечення потраплять у мережі за межами
українських систем та військових систем партнерів.
• Бот Amadey і торренти: Secret Blizzard і Seashell Blizzard отримують доступ до
якомога більшої кількості пристроїв, перш ніж шукати нові пристрої. Secret
Blizzard робить це, скориставшись сторонніми зараженнями, такими як
багатоцільові боти Amadey10, щоб завантажити спеціальний інструмент
розвідки, який допомагає операторам вирішити, чи розгортати свій бекдор
першого етапу. Seashell Blizzard пропонує шкідливі, піратські версії програмного
забезпечення Microsoft через торренти, часто просуваючи їх на українських
файлообмінних сайтах, щоб закріпитися в мережах [20].
Варто зазначити, що попри складні умови та численні виклики у сфері
кібербезпеки, Україна успішно їм протистоїть. У Національному індексі
кібербезпеки, який щороку публікує Фонд електронного врядування Естонії,
наша країна посідає 13-те місце. Крім цього, ми посідаємо 78 місце у
Глобальному індексі кібербезпеки [21].
17
Українські підприємсва стикаються з кількома проблемами у сфері цифрової
безпеки. Деякі аспекти їхнього кіберзахисту є недостатньо розвиненими. До
таких проблемних місць належать наступні [22]:
• суттєва залежність від іноземних постачальників програмного забезпечення;
• недостатній контроль за впровадженням заходів з кіберзахисту та
інформаційної безпеки;
• вразливість цифрової інфраструктури підприємств, викликана різним
розміщенням співробітників через віддалену роботу та передачу завдань на
аутсорсинг;
• слабке підґрунтя законодавства у сфері кібербезпеки та повільне
впровадження досвіду і нормативних актів ЄС та інших країн.
1.3 Хмарні технології
Оскільки підприємства все частіше переходять на цифрові платформи, хмарні
технології стали невід’ємною частиною підвищення кіберстійкості. Очікується,
що глобальний ринок хмарних обчислень досягне приблизно 600 мільярдів
доларів США в 2024 році, а сукупний річний темп зростання становитиме 16,3%
до 2026 року. Це зростання зумовлено широким впровадженням різних моделей
хмарних послуг, включаючи IaaS, PaaS SaaS. Наприклад, очікується, що витрати
кінцевих користувачів на IaaS зростуть на 26,6% у 2024 році, тоді як витрати на
PaaS зростуть на 21,5%. Ці статистичні дані підкреслюють критичну роль, яку
відіграють хмарні технології в сучасному бізнесі.
Оскільки кіберзагрози стають все більш складними та частотними,
підприємства все більше визнають, що традиційних підходів до кібербезпеки
недостатньо. Натомість вони звертаються до хмарних рішень, які пропонують
розширені функції безпеки та більшу гнучкість. Приголомшливі 94%
підприємств повідомляють про покращення стану безпеки після переходу на
18
хмару, підкреслюючи, як хмарні технології можуть підвищити стійкість до
кіберзагроз.
Розподіляючи робоче навантаження між кількома хмарними середовищами,
підприємства можуть зменшити ризики, пов’язані з окремими точками відмови.
Насправді 70% ІТ-лідерів вважають, що надійна гібридна хмарна стратегія є
важливою для успішної цифрової трансформації1. Цей підхід не тільки підвищує
безпеку, але й сприяє співпраці між командами та партнерами, створюючи
стійкішу екосистему.
Постійні інвестиції в хмарну інфраструктуру відображають ширше визнання
того, що стійкість перед обличчям кібервикликів вимагає інноваційних
технологічних рішень, які можуть адаптуватися до середовища, що постійно
змінюється [23, 24].
Відповідно до Закону України «Про хмарні послуги», технологія хмарних
обчислень визначається як концепція, що надає користувачам можливість
віддаленого доступу до хмарної інфраструктури за запитом через електронні
комунікаційні мережі.
Окрім цього, згідно закону хмара (хмарна інфраструктура) – це набір
динамічно розподілених і налаштовуваних хмарних ресурсів, які можуть бути
швидко надані користувачеві хмарних послуг і звільнені через глобальні та
локальні мережі передачі даних [25].
Щоб забезпечити кібербезпеку хмарних обчислень, спочатку потрібно
описати структуру самої хмарної системи. Такі гігантські підприємства, як NIST,
IBM і Microsoft, пропонують еталонні моделі для хмарних обчислень у цьому
відношенні.
Еталонну модель для хмарних обчислень пропонує IBM. Відповідно до
еталонної моделі IBM, модель системи хмарних обчислень визначається трьома
ролями: клієнт, оператор і розробник хмарного сервісу. Ці ролі можуть
виконувати окремі сутності, групи сутностей або підприємства. Ця архітектура
19
розглядає безпеку, стійкість до збоїв і продуктивність як загальні аспекти та
охоплює платформу керування хмарою, апаратну інфраструктуру та хмарні
служби.
Доступні еталонні моделі безпеки хмарних обчислень не описують рівень
віртуалізації та сервісу, а також важливі компоненти для забезпечення
кібербезпеки хмарних обчислень, не розглядають сенсорний рівень IoT (Інтернет
речей), який збирає введені текстові дані зловмисниками для здійснення
кібератак на хмарну інфраструктуру та проблеми кіберстійкості хмарних
обчислень взагалі. Модель можна представити так рисунок 1.3.
Рисунок 1.3 – Хмарна модель
Запропонована модель системи хмарних обчислень складається з двох
основних суб’єктів: хмарного клієнта та хмарного оператора. Ця модель
складається з таких рівнів: прикладний рівень, рівень обслуговування, рівень
20
віртуалізації, рівень передачі даних, рівень фізичних ресурсів, рівень сенсора
соціальних медіа IoT, рівень кібербезпеки та рівень кіберстійкості.
У рамках безпеки запропонованої моделі системи хмарних обчислень
розглядаються наступні питання:
• виявлення несправностей;
• конфіденційність конфіденційних даних;
• кластеризація кібератак;
• управління ідентифікацією;
• довірче управління;
• виявлення аномалій;
• планування завдань;
• оцінка ризиків;
• хмарний моніторинг безпеки;
• ідентифікація даних CTI (Cyber Threat Intelligence) з текстів соціальних медіа
та ідентифікація кіберзагроз [26].
Висновки по розділу 1
Отже, у цьому розділі було розглянуто визначення кіберстійкості, а також
наведено певну статистику стосовно ставлення кіберфахівців до цієї концепції.
З’ясовано, залежність та ієрархія між визначеннями: кіберстійкість, кібербезпека
та кіберризик. Визначені проблеми, з якими стикаються підприємства, коли
аналізують кіберстійкість черех призму хмарних технологій.
У зв'язку з агресією проти України, питання кіберстійкості підприємств стало
більш актуальним, ніж будь-коли. Встановлено, що потроєння кіберінцидентів у
2022 році вказує на те, що кібервійни не тільки тривають, але й загострюються за
серйозністю та частотою. Ця тенденція вимагає термінового посилення заходів
21
захисту. Слід враховувати, що концепція кіберстійкості базується на
комплексному систематичному підході.
Прогнозований ріст ринку хмарних обчислень підкреслює зростаючу
залежність від цифрових платформ і необхідність для підприємств адаптуватися
до сучасних технологічних вимог. Ця зміна є чітким свідченням того, наскільки
важливими стали хмарні послуги для ефективності та безпеки роботи. Розглянуто
підходи до побудови безпечних моделей.
22
2 ОСНОВНІ ПІДХОДИ
2.1 Методологія прогресування кіберстійкості
У підході використовується напівструктуровані інтерв’ю як джерело якісної
інформації, щоб отримати модель розвитку кіберстійкості. Напівструктуровані
інтерв’ю є засобом збору даних для якісного дослідження, корисного для збору
інформації про певну тему чи сферу з досвіду окремих осіб. У даному випадку
методологія використовується для збору інформації про розвиток політики
кіберстійкості. А саме від експертів трьох різних профілів: провайдерів
кібербезпеки, дослідників кібербезпеки та фахівців у підприємствах,
відповідальних за впровадження кібербезпеки. Зазвичай експерти обираються
завдяки їхньому багатому досвіду в галузі, а їхні різні профілі вибираються, щоб
додати три точки зору на одну й ту ж тему.
Використовуючи політики, розробляються напівструктуровані інтерв’ю, які
пізніше потрібно кількісно оцінити та проаналізувати, щоб визначити, як ця
політика буде прогресувати з часом.
Щоб отримати модель прогресування з точки зору експертів, інтерв’ю
розробляється систематична побудова моделі прогресування. Таблиця з
доменами та спрощеними політиками передається експертам у документі, який
слугує сценарієм. Цей документ має містить визначення «кіберстійкості» та
«моделі прогресу», а також цілі, мету, очікувані результати та наступну
двоетапну методологію:
Крок 1. Встановити відправну точку для кожної політики кіберстійкості. На
цьому кроці експертам потрібно пам’ятати про залежність між цими політиками
та власним досвідом, щоб поставити політики на початкову точку за шкалою від
1 до 5. Де один є найменш просунутою, найменш зрілою, а п’ять – найвищим
рівнем зрілості.
23
Крок 2: Описати, як політики прогресують на наступних кроках шкали.
Наприклад, якщо політика починається з третього рівня, як вона проявляється на
підприємстві на третьому рівні, потім на четвертому і, нарешті, на п’ятому рівні.
З цією інформацією експертів потрібно опитувати одного за іншим, а інтерв’ю
записувати, щоб забезпечити правильні записи інтерв’ю. Записи також потрібно
надіслати кожному експерту, щоб подвійно перевірити, чи правильно враховано
їхні ідеї, і уникнути неправильного запису даних та/або упередженого
тлумачення відповідей експертів. Огляд того, як отримана модель прогресу від
кожного експерта показана в таблиці 2.1.
Таблиця 2.1 – Модель прогресу
Домен Політика 1 2 3 4 5
Домен Політика№ Початковий Опис Опис Опис
№ 1 1 опис прогресії на прогресії прогресії
політики рівні 3 на рівні 4 на рівні
5
Політика№ Початковий Опис Опис
2 опис прогресії прогресії
політики на рівні 4 на рівні
5
Політика№ Початковий Опис Опис Опис
3 опис прогресії на прогресії прогресії
політики рівні 3 на рівні 4 на рівні
5
24
Кінець таблиці 2.1
Доме Політика Початкови Опис
н № 2 № 4 й опис прогресі
політики ї на
рівні 5
Політика Початкови Опис Опис Опис
№ 5 й опис прогресі прогресії прогресі
політики ї на на рівні 4 ї на
рівні 3 рівні 5
Політика Початкови Опис Опис Опис Опис
№ 6 й опис прогресії прогресі прогресії прогресі
політики на рівні 2 ї на на рівні 4 ї на
рівні 3 рівні 5
Щоб уникнути втоми під час інтерв’ю та, отже, упередженості через цю втому,
інтерв’ю обмежується однією годиною тридцять хвилинами. Сценарії експерти
мають отримати заздалегідь, а після інтерв’ю зробити записи їхніх ідей, що
дозволить експертам говорити вільно та без затримок.
Для аналізу записів можна викоритосвувати п’ятиетапну методологію аналізу
напівструктурованих інтерв’ю, запропоновану Шмідтом. Ці п’ять кроків:
1. Матеріально-орієнтоване формування аналітичних категорій. Етап полягає в
уважному читанні та розумінні окремих записів. На цьому кроці робляться
анотації до загальних концепцій, знайдених серед записів.
2. Об’єднання аналітичних категорій у керівництво для кодування. Етап полягає
у створенні категорій, які підсумовують різні типи прогресії, визначені
експертами. Ці типи прогресування визначаються шляхом групування загальних
шаблонів у прогресіях експертів (виявлених під час інтерв’ю) і називання цих
25
шаблонів якомога більш описовим. Наприклад для дослідження в таблиці
2.2 можна визначити такі типи прогресії.
3. Третій етап називається кодування матеріалу. Полягає в присвоєнні типу
прогресії кожному з політик і прогресій із записів кожного експерта. На цьому
кроці одному експерту можна призначити кілька кодів для кожної прогресії
політики.
4. Кількісне дослідження матеріалу, яке складається з двох частин: (1) визначення
того, чи був консенсус щодо початкової зрілості кожної політики та (2)
визначення, чи був консенсус щодо типу прогресування для кожної політики.
Таблиця 2.2 – Типи прогресії для кодування та їх визначення
Категорія Код Визначення
Збільшення інвестицій ЗІ Цей код призначається, коли опис прогресу
експерта стосувався збільшення ресурсів
(переважно економічних ресурсів),
призначених для реалізації/операції
політики.
Безперервність Б Цей код – коли опис прогресу експерта
ґрунтувався на збільшенні частоти
виконання дій політики на підприємстві
(тобто це робилося все частіше та частіше в
міру підвищення рівня).
26
Продовження таблиці 2.2
Специфіка С Цей код – коли прогрес експерта описує
підвищення рівня деталізації, на якому
політика виконується в міру зростання
зрілості підприємства (тобто вона
починалася в загальному вигляді та ставала
більш детальною та конкретною в міру
підвищення рівня).
Розширення Р Цей код – коли опис прогресу експерта
включає розширення дії політики в
підприємстві (наприклад, дію було виконано
в деяких розділах підприємства, і воно
почало виконуватися в більшій кількості
розділів із підвищенням рівня).
Формалізація Ф Цей код – коли опис прогресу експерта
посилається на документацію або
систематизацію дій (тобто, коли дії політики
стали інтуїтивно зрозумілими або
неформальними та стандартизувалися та
документувалися з підвищенням рівня).
Незалежність Н Цей код – коли в описі прогресу експерта
згадується про зменшення залежності
підприємства від допомоги постачальників
кібербезпеки або зовнішніх підприємств для
виконання завдань, пов’язаних із політикою.
27
Кінець таблиці 2.2
Оптимізація О Цей код – коли опис прогресу експерта
базується на вимірюванні та вдосконаленні
ключових показників ефективності (Key
Performance Indicators) для оптимізації
ефективності дій політики.
Проактивність П Цей код – коли опис прогресу експерта
представляв зміну ставлення підприємства
до дій політики (наприклад, від дотримання
до виконання її для власної передбачуваної
вигоди). Згадка про безперервне
вдосконалення дій, які не можуть бути
кількісно визначені, також була закодована
під цією категорією.
Немає прогресування Н Цей код – коли експерт вважає, що політика
була реалізована і не мала подальшого
прогресу, або коли початкова зрілість
вважалася рівнем 5.
Технології Т Цей код – коли опис прогресу експерта
стосується збільшення технологічних
рішень або вимагав більш передових
технологій для прогресу політики.
Щоб визначити, чи був консенсус щодо початкової зрілості, потрібно
розрахувати середнє значення, моду, підмоду та довірчі інтервали для середнього
значення. Мода є стартовою зрілістю з найбільшою кількістю експертів. Якщо
вона існувала, підмода вважається рівнем зрілості з частотою моди мінус один
(наприклад, якщо мода рівень 1 із п’ятьма експертами, а рівень 2 з чотирма
28
експертами, то рівень 2 є підмодою). З іншого боку, довірчий інтервал для
середнього значення розраховується для 95% впевненості. Довірчі інтервали
розраховуються, припускаючи нормальність даних, загальне припущення, яке
може дати задовільні результати навіть у ненормальних розподілах. Середнє
значення та межі довірчого інтервалу зазвичай округлюються, щоб мати цілі
значення. Після того, як зробити розрахунки, рішення про те, чи був консенсус,
приймається за допомогою дерева рішень з таблиці 2.1.
Як показано на рисунку 2.1, існує п’ять можливих випадків для кожної
політики. Для ясності ці випадки будуть пронумеровані в наступному описі за
допомогою №1-№5.
Рисунок 2.1 – Дерево рішень кількісного аналізу
Стан №1. Цей випадок досягається, коли округлене середнє значення
відрізнялося від моди. В цей час підмода є і дорівнює середньому значенню. У
цьому випадку консенсус вважається підмодою, оскільки велика група експертів
29
вважає це початковим рівнем зрілості політики, а експерти, які цього не зробили,
були ближче до цієї початкової зрілості, ніж до початкової зрілості моди.
Стан №2. Цей випадок досягається, коли округлене середнє значення
відрізняється від моди; В цей час підмода є, але не дорівнює середньому
значенню. У цьому випадку консенсусу не буде, оскільки ні мода, ні підмода не
є приблизно початковим рівнем зрілості, з якого експерт вважав, що політика
повинна починатися.
Стан №3. Цей випадок був досягається, коли мода та округлене середнє
значення не були рівними, не було підмоди, а лише довірчі інтервали (ДІ) містили
моду. У цьому випадку консенсус є мінімальним між модою та середнім
значенням. Цей критерій було застосовується, тому що мода та середнє значення
теоретично були не такими далекими, оскільки це було в ДІ середнього значення.
Причина вибору мінімуму з двох полягає в тому, що для підвищення
кіберстійкості більш вигідно диверсифікувати інвестиції в політику та почати
реалізацію якомога раніше.
Стан №4. Цей випадок досягається, коли мода та округлене середнє значення
були різними, не було підмоди, а довірчі інтервали (ДІ) не містили моди. У цьому
випадку не може бути досягнуто консенсусу, оскільки це означало, що багато
експертів розглядали один початковий термін зрілості, але цей початковий термін
був значно далеким від думок більшості інших експертів щодо початкового
терміну зрілості політики.
Стан №5. Нарешті, цей випадок досягається, коли округлене середнє значення
дорівнювало моді. У цьому випадку легко досягяється консенсус, оскільки це
означало, що більшість експертів вважали, що одна початкова зрілість є
переважаючою, і що експерти, які розходилися з цією думкою, не надто
розходилися з нею.
30
Щоб визначити, чи був консенсус щодо типів прогресії, розраховується мода
і відсоток узгодження моди. Відсоток згоди моди це відсоток експертів, які
вважають, що тип прогресування моди є основним типом прогресування. Це
означає, що частота моди ділиться на загальну кількість експертів, а не на
кількість загальних типів прогресії, призначених політиці, оскільки експерти
могли описувати прогресії, які були комбінацією різних типів прогресій. І
виходить, якщо відсоток згоди перевищував 50%, тип прогресії є консенсусним.
Крім цього, якщо відсоток згоди був нижчим, консенсусу щодо типу прогресу
політики не може бути.
5. Детальні інтерпретації окремих випадків полягають у створенні моделі
прогресування на основі інтерпретації найпоширенішої початкової точки для
кожної політики та її найпоширенішого типу прогресії (коду).
Короткий опис п’ятиетапної методології з результатами кожного кроку показано
на рисунку 2.2 [27, 28].
Рисунок 2.2 – Підсумок методології аналізу записів
31
2.2 Вимоги-питання до хмарних провайдерів
Деякі підприємства визначають та складають самостійно перелік питань, які
розглядаються як вимоги до провайдера.
Принцип 1. Захист даних під час передачі: дані підприємства повинні бути
належним чином захищені від підробки та прослуховування під час передачі
мережами всередині хмари та поза нею.
1) Які протоколи криптографічного захисту інформації використовуються для
захисту даних підприємства, під час їх передачі між пристроєм(ами) кінцевого
користувача та хмарою?
2) Які засоби і механізми захисту мережі надаються сервіс-провайдером для
безпечного підключення до хмари і для розмежування доступу всередині хмари?
3) Які механізми автентифікації користувачів підприємства та її партнерів
надаються сервіс-провайдером для доступу до ресурсів підприємства в хмарі?
4) За керування якими механізмами криптографічного захисту, автентифікації та
мережевого захисту відповідає сервіс-провайдер?
5) За керування якими механізмами криптографічного захисту, автентифікації та
мережевого захисту відповідає підприємства?
Принцип 2. Захист і кіберстійкість активів: повинні бути захищені від
фізичного втручання, втрати, пошкодження або вилучення дані підприємства та
компоненти хмари, що зберігають або обробляють ці дані.
1) В якій країні та в якому місці розташовані системи зберігання даних сервіс-
провайдера? З яких країн здійснюється адміністрування інформаційних систем
сервіс-провайдера?
2) Хто є власником і несе відповідальність за фізичний центр обробки даних?
3) Яке законодавство буде застосовано для вирішення питань між підприємства
як користувачем послуги та сервіс-провайдером?
32
4) В якому випадку сервіс-провайдер надає доступ до даних підприємства без
згоди підприємства?
5) Чи не суперечить зміст угоди з постачальником послуг законодавству, що
застосовується до підприємства?
6) Як забезпечуться контроль фізичної безпеки центрів обробки даних?
7) Чи було проведено аудит на місці? Чи відповідають результати аудиту
відомостям від сервіс-провайдера?
8) Чи шифрує сервіс-провайдер дані клієнтів у стані спокою в рамках послуги?
Які механізми?
9) Які додаткові вимоги до шифрування даних підприємства наявні? Зокрема:
шифрування носіїв даних;
шифрування даних в додатках / базах даних;
шифрування даних в оперативній пам’яті;
застосування сервіс-провайдером технології «шардинг».
10) Чи надає сервіс-провайдер можливість реалізувати ці вимоги?
11) Чи видаляються дані підприємства при переміщенні або повторному
використанні обладнання дата центру, або коли підприємства вимагає видалення
інформації з носія, на якому вона зберігалася? Яка наявна процедура?
12) Яким чином дані підприємства знищуються в кінці терміну їх зберігання або
у випадку завершення терміну дії угоди з сервіс-провайдером?
13) Які контрактні зобов'язання або угоди про рівень надання послуг (SLA)
пропонуються сервіс-провайдером? Чи передбачають зазначені зобов’язання
механізм компенсації шкоди, яка була нанесена підприємства у випадку перебоїв
у наданні хмарних послуг?
14) Які саме механізми сервіс-провайдера забезпечують необхідний рівень
доступності хмарних послуг?
33
15) Чи задовольняє вимогам підприємства щодо доступності систем / інформації
запропонований сервіс-провайдером варіант розміщення даних та ресурсів
підприємства в хмарі?
Принцип 3. Розмежування клієнтів: Впроваджені технічні засоби дата центру
гарантують, що служби одного клієнта дата центру не можуть отримати доступ
до служб (даних) іншого клієнта або впливати на них.
1) Яким чином сервіс-провайдер здійснює розмежування доступу між даними /
службами різних клієнтів, а саме для
розподілу обчислення;
розподілу сховища;
розподілу мережевого трафіку?
Принцип 4. Структура управління: система управління гарантує, що
процедурний, кадровий, фізичний і технічний контроль продовжать працювати
протягом усього терміну надання послуги.
1) Чи має сервіс-провайдер чітко ідентифікованого представника правління (або
особу з прямими делегованими повноваженнями), який відповідає за безпеку
хмарної послуги?
2) Чи наявна документована структура управління безпекою та управління
ризиками, які стосуються забезпечення інформаційної безпеки послуги?
3) Чи забезпечується аналіз та дотримання застосовних законодавчих і
нормативних вимог відносно до послуги, що надається? Яке саме законодавство
застосовно?
Принцип 5. Операційна безпека: постачальник хмарної послуги повинен
забезпечувати перешкоджання, виявлення або запобігання атакам.
1) Чи впроваджений сервіс-провайдером процес керування вразливістю для
виявлення, пріоритезації та усунення вразливостей у всіх компонентах послуги,
за які він відповідає?
2) Чи враховує наявний процес наступне:
34
сервіс-провайдер визначив часові рамки впровадження оновлень безпеки та
інших засобів керування вразливістю і дані терміни / засоби задовольняють
підприємства;
сервіс-провайдер бере на себе відповідальність за застосування оновлень
безпеки до всього програмного та апаратного забезпечення, включно з тими, де
вони залежать від зовнішніх постачальників (або стороннього ланцюга поставок);
сервіс-провайдер оцінює та реагує на потенційні нові загрози, вразливості або
методи використання, які можуть вплинути на сервіс підприємства?
3) Чи має сервіс-провайдер впроваджені інструменти моніторингу подій
інформаційної безпеки та процеси їх аналізу? Як саме здійснюється моніторинг?
4) Чи має сервіс-провайдер впроваджені процеси управління інцидентами
інформаційної безпеки?
5) Яким чином сервіс-провайдер взаємодіє з клієнтом у випадку інциденту
інформаційної безпеки? В яких випадках передбачається таке спілкування? Які
терміни визначені для інформування клієнта у випадку інциденту?
6) Чи забезпечує сервіс-провайдер керування та контроль внесення змін в
налаштування компонентів дата-центру? Які є вимоги та процедури?
7) Чи забезпечує сервіс-провайдер аналіз потенційних змін перед їх
впровадженням, в тому числі з точки зору інформаційної безпеки?
8) Чи інформує сервіс-провайдер клієнта перед внесенням змін, які потенційно
можуть впливати на доступність послуги? Які зміни відносяться до таких?
Принцип 6. Безпека персоналу: перевіряти та обмежувати дії персоналу
постачальника послуг.
1) Чи забезпечує сервіс-провайдер перевірку персоналу перед його наймом? Як
саме?
2) Чи проводить сервіс-провайдер регулярне навчання персоналу з питань
інформаційної безпеки та підвищення кваліфікації?
35
3) Чи забезпечує сервіс-провайдер контроль та наналіз дій адміністратора, який
отримує доступ до даних підприємства або вносить зміни, які впливають на
використання підприємства хмарної послуги?
4) Чи дотримується сервіс-провайдер наступних принципів:
адміністраторам і привілейованим користувачам лише тимчасово надаються
мінімальні адміністративні можливості у відповідь на конкретну проблему
(додаткові привілеї слід запитувати, якщо це необхідно);
запити на додаткові привілеї прив'язані або до запиту служби підтримки
клієнтів, або до внутрішнього запиту на зміну;
доступ до систем або інтерфейсів, які можуть надати доступ до даних клієнта,
надається лише за умови, що клієнт надав чітко обмежений у часі дозвіл на такий
доступ (це застосовується в кожному окремому випадку)?
Принцип 7. Безпечна розробка: хмарну інфраструктуру слід проектувати,
розробляти та розгортати таким чином, щоб мінімізувати загрози безпеці хмари
та доступності хмарних послуг.
1) Чи дотримується сервіс-провайдер наступних принципів:
сервіс-провайдер використовує життєвий цикл розробки програмного
забезпечення та систем;
сервіс-провайдер автоматизує конвеєр інтеграції та розгортання, який
використовується для надання хмарних послуг, щоб забезпечити безпеку,
послідовність і простежуваність;
сервіс-провайдер послуг чітко відокремлює своє виробниче середовище від
середовищ тестування чи розробки;
сервіс-провайдер послуг керує ризиками ланцюга постачання ;
сервіс-провайдер послуг стежить за рекомендаціями щодо безпеки системного
та прикладного програмного забезпечення та застосовує виправлення безпеки;
процеси конфігурації та управління ключами існують для забезпечення
цілісності хмарної служби протягом розробки, тестування та розгортання;
36
сервіс-провайдер підтримує свої послуги протягом тривалого часу та реагує на
нові та нові загрози?
2) Чим можна підтвердити факт дотримання?
Принцип 8. Безпека ланцюжка постачання: ланцюги постачання третіх сторін
повинні підтримувати всі принципи безпеки, які постачальник послуг стверджує,
що реалізує.
1) Які дані підприємства передаються стороннім постачальникам та їх
ланцюжкам поставок? За яких обставин?
2) Які вимоги до постачальників висуваються сервіс-провадером? Яким чином
сервіс-провайдер керує відповідністю своїх постачальників вимогам безпеки?
Принцип 9. Безпечне керування користувачами: постачальник послуг повинен
надати інструменти для безпечного керування використанням його послуг.
1) Яка визначена сервіс-провайдером модель використаня облікового запису
користувача, що забезпечує доступ до інструментів керування хмарною
послугою?
2) Які механізми захисту використовуються для авторизації доступу до даних і
послуг, включаючи доступ до інтерфейсів керування?
3) Яким чином здійснюється взаємодія між сервіс-провайднром та клієнтом?
Зокрема, отримання запитів на управління або підтримку (телефон, веб-портал,
електронна пошта тощо).
4) Чи може підприємства застосувати детальне керування доступом відповідно до
«принципу найменших привілеїв», увімкнувши як «стандартні», так і
«адміністративні» облікові записи користувачів?
5) Чи можуть інші клієнти сервіс-провайдера отримати доступ, змінити або
іншим чином вплинути на конфігурацію хмарних сервісів, що надані
підприємства?
Принцип 10. Ідентифікація та автентифікація: доступ до інтерфейсів хмари
повинен бути наданий виключно автентифікованим і авторизованим особам.
37
1) Чи має підприємства можливість використовувати політику паролів та
багатофакторну автентифікацію для доступу користувачів до хмари?
2) Чи впроваджує сервіс-провайдер політику безпечної ідентифікації та
автентифікації, яка передбачає:
використання менеджерів паролів
використання MFA через усі зовнішні інтерфейси
впровадження системи SSO?
Принцип 11. Захист зовнішніх інтерфейсів: усі зовнішні або менш надійні
інтерфейси хмари мають бути ідентифіковані та захищені.
1) Які інтерфейси або служби дата-центру доступні із мережі Інтернет?
2) Яким чином здійснюється захист інтерфейсів або служб дата-центру, що
доступні із мережі Інтернет?
Принцип 12. Безпечне адміністрування послуг: постачальник послуг повинен
розуміти високу цінність систем адміністрування.
1) Чи забезпечує сервіс-провайдер контроль та безпечне адміністрування
компонентів дата-центру?
2) Чи забезпечує сервіс-провайдер (з питань адміністрування):
контроль пристроїв та засобів, що використовуються для адміністрування
хмарних послуг, за допомогою регулярних і ретельних оцінок безпеки;
захист інтерфейсів адміністрування;
управляіння ризиками;
керування привілейованим доступом;
реєстрацію подій інформаційної безпеки та їх аналіз?
Принцип 13. Інформація аудитів та сповіщення клієнтів: Постачальник послуг
повинен надавати журнали, необхідні для моніторингу доступу до сервісів
підприємства та даних, що зберігаються в ній.
1) Чи надає сервіс-провайдер клієнту дані аудиту, що необхідні для розслідування
інцидентів та пов’язані із використанням хмарних послуг?
38
2) Яка саме інформація надається?
3) Чи сповіщає власних клієнтів сервіс-провайдер про виявлені атаки на дані
клієнтів або хмарні сервіси?
Принцип 14. Безпечне використання сервісу: Постачальник послуг повинен
облегшити виконання підприємства її обов’язків щодо захисту даних.
1) Висновки підприємства щодо:
досягнення цілей Принципів 1-13 за допомогою налаштування програмного та
апаратного забезпечення сервіс-провайдеру;
розуміння дій, необхідних для досягнення завдань інформаційної безпеки за
допомогою наданих інструментів захисту;
захисту власних даних;
відповідальності сервіс-провайдера за покращення безпеки послуги.
2.3 Огляд методів покращення стійкості
Центр даних (ЦД) використовуються як вагомий аргумент того, що безпека та
стійкість хмарних обчислень є вищими, ніж у традиційних парадигм. Це
забезпечується головним чином через те, що хмарні інфраструктури зазвичай
розміщуються в центрах даних з більшими можливостями, ніж ті, які можна
фінансувати або керуватиодним підприємством. Високий рівень резервування
ресурсів, чудова стійкість до живлення, чудова фізична безпека та надійні
мережеві зв’язки з магістралью Інтернету. Таким чином, ці базові характеристики
забезпечують стійкість цих середовищ за своєю природою. Таблиця 2.3
підсумовує цю літературу.
Таблиця 2.3 – Стійкість даних і фізичного рівня
Метод Модель Компоненти Обмеження
Резервні копії Фізична Фізична Висока вартість
інфраструктура
39
Продовження таблиці 2.3
Оптимальний Фізична Цетр даних Висока вартість
георозподіл ЦД
Розміщення сервера для IaaS Фізична Лише фізичний
резервного копіювання інфраструктура, рівень
віртуальних машин (ВМ) Центр даних
Оптимальна Фізична Фізична Нехмарний
маршрутизація з інфраструктура,
використанням Центр даних
балансування
навантаження та аналізу
графів
Топологія та Фізична Фізична Доступно лише для
демографічне/економічне інфраструктура, деяких CSP
розміщення ЦД Центр даних
Пошук дерева за методом Фізична Фізична Доступно лише для
Монте-Карло для інфраструктура, деяких CSP
надання ресурсів Центр даних,
Управління
ресурсами
Забезпечення ЦД для Фізична Фізична Висока вартість і
оптимізації ресурсів інфраструктура, складність
Центр даних,
Управління
ресурсами
40
Кінець таблиці 2.3
Агрегований обмін Фізична Фізична Обмежена
посиланнями інфраструктура, компартменталізація
Центр даних,
Управління
ресурсами
Симуляція сценаріїв Фізична Фізична Тільки моделювання
витривалості інфраструктура,
Центр даних
Використовувати Фізична Фізична Централізоване
програмно- інфраструктура, управління
конфігуровану мережу Центр даних
(Software-defined Віртуальна
Networking) для мережа,
витривалості Управління
ресурсами
Найбільш простим методом забезпечення стійкості даних є копії. У разі збою
відбувається доступ до копій або їх переміщення. Цей принцип лежить в основі
багатьох методів забезпечення відмовостійкості сховищ, таких як широко
розгорнуті незалежні диски з резервним масивом (Redundant Array Inexpensive
Disks). Зберігання, однак, є дорогим, тому шукають методи зниження вартості
резервування. Це не тільки вартість обладнання, а й методи забезпечення
логічності. Зараз існує прагнення перемістити більшу частину сховища
підприємства в хмарні інфраструктури через їх властиву стійкість до масового
резервування ресурсів і глобального віддаленого доступу. Таблиці 2.4, 2.5, 2.6
підсумовують дану інформацію [29].
41
Таблиця 2.4 – Методи збереження стійкості
Метод Модель Компоненти Обмеження
Планування аварійного IaaS Віртуальне Аварійне
відновлення на основі сховище відновлення не
витрат, копій завжди корисне для
надання послуг
Відновлення на основі IaaS Віртуальне Вартість у
коду сховище результаті груп
вузлів
Швидка евакуація даних IaaS/ Віртуальне Апріорне знання
(Rapid Data Evacuation) сховище катастроф, вимоги
перед катастрофою до пропускної
здатності
Накладання мережі на PaaS Віртуальне Висока вартість
різноманітне сховище на сховище, копії
кількох ЦД Віртуальна
мережа,
Управління
ресурсами,
Оркестровка
служби
Копії, що охоплюють IaaS Віртуальне Висока вартість
корельовані та сховище копії
некорельовані збої
42
Кінець таблиці 2.4
Зберігання в IaaS Віртуальне Висока вартість
різноманітних хмарах сховище, копії
Управління
ресурсами
Забезпечення безпеки на Client Клієнтські Лише на стороні
стороні клієнта хмарних пристрої клієнта
служб зберігання
Оглядова та гібридна IaaS Віртуальне Висока вартість
техніка між кодуванням сховище, копії
стирання та копіюванням Управління
ресурсами
Гомоморфний токен і IaaS Віртуальне Втрата даних із
дані про стирання сховище втратою ключа
Маршрутизація IaaS Центр даних, Апріорне знання
аварійного резервного Віртуальне катастроф, вимоги
копіювання з кількома сховище, до пропускної
ЦД Управління здатності
ресурсами
У цьому розділі стійкість рівня програми розглядається як перевірка окремого
інстанса, наприклад контейнера VMor, без урахування платформи кількох
програм. Таблиця 2.5 надає підсумок.
43
Таблиця 2.5 – Методи стійкості інстанса та Менеджера віртуальних машин
(Virtual Machine Manager)
Метод Модель Компоненти Обмеження
Миттєві знімки IaaS Віртуальна Висока вартість
віртуальної машини та інфраструктура копії та зберігання,
виявленням аномалій керування станом,
лише Windows
Проактивне відновлення IaaS Віртуальна Висока вартість
інфраструктура копії та зберігання,
керування станом,
відсутність захисту
від фізичних збоїв
Періодичні знімки та IaaS Віртуальна Висока вартість
відновлення інфраструктура копії та зберігання,
управління станом
Копії на рівні процесу, PaaS/IaaS Віртуальна Середня вартість
контрольних точок інфраструктура, копії та зберігання,
Управління управління станом,
ресурсами цілісність
віртуальної машини
Контрольні точки PaaS/IaaS Віртуальна Середня вартість
процесу інфраструктура, копії та зберігання,
Управління управління станом,
ресурсами цілісність
віртуальної машини
44
Кінець таблиці 2.5
Копія віртуальної IaaS Віртуальна Висока вартість
інфраструктури інфраструктура копії та зберігання,
управління станом
Копія віртуальної IaaS Віртуальна Висока вартість
інфраструктури інфраструктура, копії та зберігання,
Управління управління станом
ресурсами
Копії, контрольні точки IaaS Фізична Відповідальність за
HV за допомогою інфраструктура, порушення аномалії
процесу самоаналізу Віртуальна
інфраструктура
Різноманітність IaaS Фізична Потрібен вихідний
компілятора та інфраструктура, код програми
середовища виконання Віртуальна
інфраструктура,
Управління
ресурсами
Копії/відзеркалення IaaS Фізична Висока вартість
VMM з мінімальними інфраструктура, копії
витратами Віртуальна
інфраструктура,
Управління
ресурсами
45
Таблиця 2.6 – Методи стійкості хмарного керування
Метод Модель Компоненти Обмеження
Перезапуск контрольної IaaS Віртуальні
точки застосунку без стану ресурси,
після децентралізованого Оркестрація
DHT послуг,
Управління
ресурсів
Оптимізований перезапуск IaaS Віртуальні Висока вартість копії
контрольної точки для HPC ресурси,
з використанням VI Управління
ресурсів
Планування на основі GA, IaaS Віртуальні Висока початкова
однорідний розподіл ресурси, вартість ресурсів і
компонентів по всіх вузлах Планування лише веб-застосунок
Зниження балансу для IaaS Віртуальні Обмежені випадки
локальності даних і ресурси, використання
скорочення робочого часу Планування
Пакети завдань IaaS Віртуальні Витягнути, а потім
категорізовані для ресурси, обробити може
запобігання зловмисним Планування спричинити помилки
помилкам синхронізації
Ранжування якості IaaS Віртуальна Висока складність
компонентів і структура інфраструктура,
обслуговування для Оркестрація
зменшення кількості послуг
помилок
46
Кінець таблиці 2.6
Мінімізація ризиків за IaaS Віртуальні Висока складність
допомогою ранжування ресурси,
вмісту та розміщення Фізичні ресурси,
Центри даних
Змішане цілочисельне IaaS Віртуальні Концептуальний
лінійне програмування ресурси, онлайн
Фізичні ресурси,
Планування
Проміжне програмне IaaS/PaaS Віртуальна Складність і
забезпечення, орієнтоване інфраструктура, ресурсоємність
на копії Управління
ресурсами
Багатокомпонентне Phy/IaaS Управління Складність і
проміжне програмне ресурсами, ресурсоємність
забезпечення для Планування
забезпечення виконання
політик, визначених
виявленням аномалій
Копії мережевого IaaS/PaaS Віртуальна Висока складність і
протоколу (сокети, веб інфраструктура, вартість ресурсів,
тощо) Віртуальна лише веб-сокети
мережа,
Управління
ресурсами
47
2.4 Cloud Security Alliance Cloud Controls Matrix
Матриця керування хмарою (Cloud Controls Matrix) альянсу хмарної безпеки
(Cloud Security Alliance) надає фундаментальні принципи безпеки, засоби
керування та критерії контролю, щоб керувати постачальниками хмарних послуг
(Cloud Service Providers) і клієнтами хмарних послуг (Cloud Service Customers),
які прагнуть безпечного впровадження, оцінки та керування хмарними
службами, оцінки ризиків безпеки. CCM CSA надає детальну структуру
контролю, узгоджену з керівництвом із безпеки CSA, у якому зазначено, що
«найважливішим фактором безпеки є точно знати, хто за що відповідає в будь-
якому хмарному проєкті».
CCM тепер містить комплексну структуру для розмежування та проактивного
керування моделлю хмарної спільної відповідальності за безпеку (Shared
Security Responsibility Model) із прозорістю та підзвітністю в усій хмарній
системі.
Матриця керування хмарою версії 4 (CCM v4.0), опублікована у 2021 році,
містить основні елементи керування безпекою та конфіденційністю та додаткові
компоненти. До них належать основні рекомендації впровадження CCM, анкета
ініціативи оцінювання консенсусу (Consensus Assessment Initiative Questionnaire)
та ключові рекомендації аудиту засобів контролю CCM. CCM v4.0 також містить
корисну допоміжну інформацію для елементів керування CCM. Ця інформація
включає типові призначення прав власності на елементи керування SSRM, а
також відомості про область керування й застосовність, як-от: відповідність
архітектурі та зіставлення з іншими прийнятими в галузі рамками безпеки
(наприклад, ISO/IEC, AICPA, NIST, FedRAMP).
Отже, CCM — це комплексна система контролів кібербезпеки, розроблена для
надання набору структурованих і стандартизованих засобів контролю, які
вирішують питання безпеки та конфіденційності, пов’язані з хмарними
обчисленнями, допомагаючи підприємствам оцінювати та керувати ризиками,
48
пов’язаними з впровадженням хмарних сервісів. CCM було створено для
полегшення управління ризиками безпеки та конфіденційності в хмарних
обчисленнях.
Крім того, інструкції щодо впровадження CCM доповнюють структуру CCM,
надаючи вказівки щодо SSRM, які допомагають CSP і CSC розмежувати свої
обов’язки щодо безпеки під час впровадження, керування та підтримки кожного
з елементів керування CCM.
CCM з часом еволюціонував, щоб відповідати змінам у технологіях і
ландшафтах безпеки, завдяки чому структура залишалася актуальною та
ефективною у вирішенні динамічного характеру викликів хмарної безпеки. CCM
версії 4 є останньою ітерацією фреймворку, що містить 197 контрольних цілей у
17 доменах, що охоплюють усі ключові аспекти хмарних технологій, і зіставлено
з кількома галузевими та передовими стандартами безпеки, правилами та
фреймворками.
Основною метою CCM є стимулювання та сприяння ефективному та
комплексному управлінню ризиками безпеки та конфіденційності в екосистемі
хмарних обчислень. Незалежно від типу (CSP або CSC) і розміру підприємства
або моделей доставки або розгортання хмари (IaaS, PaaS або SaaS), CCM можна
використовувати для визначення, впрвадження та забезпення виконання вимог
безпеки та контролювати їх виконання. CCM допомагає компаніям у перекладі
їхніх внутрішніх організаційних, операційних і правових положень у
стандартизований набір політик, процедур і цілей технічного контролю, що
стосуються хмарних технологій.
CCM v4.0 складається з 17 доменів безпеки та 197 елементів керування. 17
доменів базувалися на документі з інструкціями з безпеки CSA та були натхненні
основними стандартами, такими як ISO 27001:2022. Кожен домен CCM визначає,
до якої категорії належить елемент керування [30].
• Аудит та підтвердження (Audit and Assurance)
49
Область A&A складається з шести контролів та дозволяє CSP та CSC
інформувати та встановлювати необхідну довіру для прийняття критичних
рішень, комунікації та звітування про ключові процеси, включно з процесами
контролю, охопленими CCM- через оцінку, перевірку,
та діяльність з перевірки. Цей домен призначений для підтримки CSP і CSC у
визначенні та впровадженні їхніх відповідних процесів управління аудитом для
підтримки планування аудиту, аналізу ризиків, оцінки контролю безпеки,
висновків, виправлення та звітування, а також їх перегляду та покладання на
атестації та підтверджуючі докази.
SSRM розмежовує обов’язки CSP та CSC у впровадженні контролю A&A у
хмарному середовищі. І CSP, і CSC несуть незалежну відповідальність за
встановлення надійної політики аудиту та гарантії, проведення регулярних
оцінок безпеки та дотримання відповідних стандартів і нормативних вимог.
• Безпека програми та інтерфейсу (Application and Interface Security)
AIS складається із семи контролів та зосереджується на захисті програмного
забезпечення та інтерфейсів, що використовуються в хмарі, допомагаючи
підприємствам у виявленні та зменшенні ризиків для хмарних ландшафтів на
етапі проектування та розробки застосунків. Впровадження засобів керування
безпекою в хмарі в цьому домені має вирішальне значення для CSP, щоб
забезпечити цілісність, конфіденційність і доступність застосунків та інтерфейсів
у своєму хмарному середовищі.
У SSRM CSP відповідають за безпеку базової інфраструктури, пропонуючи
безпечні застосунки та API, дотримуючись методів безпечного кодування,
встановлюючи базові рівні безпеки застосунків, проводячи автоматизоване
тестування безпеки додатків і забезпечуючи доступність і підтримку безпечних
середовищ виконання. CSC відповідають за безпеку своїх застосунків та
інтерфейсів, забезпечення належної конфігурації налаштувань безпеки,
50
оновлень, безпечної інтеграції нових систем, нових версій систем і застосунків,
дотримуючись найкращих практик залежно від моделі розгортання хмари.
• Управління безперервністю бізнесу та операційною стійкістю (Business
Continuity Management and Operational Resilience)
BCR складається з одинадцяти контролів та зосереджується на захисті
критичних бізнес-процесів, інфраструктури та послуг, мінімізації впливу збоїв і
забезпеченні безперервності бізнесу в умовах потенційно руйнівних подій.
Впровадження засобів керування хмарною безпекою в цьому домені має
першочергове значення як для CSP, так і для CSC, щоб забезпечити безперебійне
надання послуг і підтримувати операційну стійкість.
CSP і CSC відіграють різні, але взаємопов’язані ролі в забезпеченні стійкості
інфраструктури та безперервності бізнесу в хмарному середовищі. CSP
відповідають за планування, розробку та впровадження надійних технологій,
послуг, політик, процедур і процесів, що контролюють безперервність і
експлуатаційну стійкість хмари та хмарних сервісів, а також за прозоре
повідомлення CSC про стійкість і можливості відновлення своїх послуг. CSC
відповідають за оцінку й керування потенційними ризиками зриву бізнесу,
пов’язаними з їхніми даними та іншими ресурсами й активами, розміщеними в
хмарі. На основі аналізу ризиків CSC повинні сформулювати та впровадити
надійні стратегії забезпечення безперервності бізнесу, адаптовані до їхніх
конкретних вимог і пріоритетів, включаючи розробку та підтримку власних
комплексних планів забезпечення безперервності бізнесу та процедур, яких слід
дотримуватися у разі збою.
• Контроль змін і керування конфігурацією (Change Control and Configuration
Management)
CCC включає дев’ять елементів керування та зосереджується на управлінні та
захисті змін у хмарному середовищі, гарантуючи, що модифікації не створюють
вразливості та не ставлять під загрозу безпеку систем у хмарному середовищі.
51
Ефективне керування змінами є життєво важливим для забезпечення стабільної
та безпечної хмарної служби як для CSP, так і для CSC.
Якщо послуга пропонується як програмне забезпечення як послуга (SaaS),
CSP, як правило, бере на себе відповідальність за встановлення та підтримку
безпечного процесу керування змінами, забезпечення встановлення базових
параметрів конфігурації, проведення оцінки ризику змін і забезпечення
відповідного дозволу на всі зміни у хмарній інфраструктурі.
Для інфраструктури як послуги (IaaS) CSP, як правило, надаватиме лише
базову мережу та інфраструктуру на максимальному базовому рівні операційної
системи, тому керування змінами для всіх рівнів операційної системи та
конфігурації рівня додатків має бути розроблено, реалізовано, підтверджено та
керовано CSC.
Для платформи як послуги (PaaS) CSP забезпечує базову інфраструктуру та
конфігурацію операційної системи для прикладного рівня, тому CSC потрібен
для розробки конфігурації програми та впровадження, тому CSC має встановити
відповідний процес керування змінами, щоб забезпечити потрібну програму
надійно налаштовано для отримання бажаного результату без уразливостей і
моніторингу будь-яких відхилень від встановлених базових параметрів
конфігурації.
• Криптографія, шифрування та керування ключами (Cryptography, Encryption
and Key Management)
CEK складається з двадцяти одного контролю керування, спрямованої на
захист даних CSC за допомогою криптографічних методів, шифрування та
методів керування ключами. Домен CEK відіграє вирішальну роль у забезпеченні
відповідності вимогам різних нормативних стандартів щодо шифрування та
керування ключами, сприяючи конфіденційності та цілісності конфіденційної
інформації в хмарному середовищі.
52
У SSRM CSP зазвичай наглядають за керуванням криптографією,
шифруванням і керуванням ключами, забезпечуючи при цьому, щоб визначення
сфери відповідало найкращим галузевим практикам і нормативним вимогам. CSP
відповідають за управління основною інфраструктурою та криптографічними
службами, забезпечуючи безпечне зберігання ключів і можливості шифрування.
CSC відповідають за визначення та розподіл ролей і обов’язків у своїх
конкретних програмах і даних, шифрування конфіденційних даних перед
завантаженням, керування власними ключами шифрування, а також
впровадження криптографічних ризиків і процесів керування змінами у своєму
конкретному середовищі.
• Безпека центру обробки даних (Data-center Security)
DCS складається з п’ятнадцяти контролів керування, які є важливими для CSP
для захисту фізичної інфраструктури та середовища CSP, у якому розміщено дані
та програми CSC. Це включає захист фізичних активів, таких як фізична
інфраструктура та обладнання, від загроз безпеці, таких як несанкціонований
доступ і екологічні небезпеки.
У SSRM CSP несуть виключну відповідальність за безпеку фізичної
інфраструктури центру обробки даних, контроль навколишнього середовища та
загальну безпеку об’єкта. CSC не несуть відповідальності за безпеку центру
обробки даних, проте в контексті домену A&A повинні перевіряти відповідність
CSP засобам керування DCS.
• Безпека даних і управління життєвим циклом конфіденційності (Data Security
and Privacy Lifecycle Management)
DSP містить дев’ятнадцять контролів керування конфіденційністю та
безпекою даних. Ці засоби контролю не пов’язані з галуззю чи сектором і не
зосереджені на конкретній країні чи нормативних актах. Однак ці елементи
керування розроблено з урахуванням загальних елементів і вимог основних
нормативних актів щодо конфіденційності. Вони, як правило, застосовуються до
53
підприємств у всьому світі та, як очікується, слугуватимуть цінною базою — із
застереженням, що деяким підприємствам, які працюють у деяких місцях чи
секторах, можливо, доведеться запровадити додаткові засоби контролю захисту
даних.
Елементи керування DSP охоплюють повний життєвий цикл даних, від
створення до утилізації, включаючи конфіденційність даних, класифікацію
даних, інвентаризацію, збереження та процедури утилізації відповідно до всіх
застосовних законів і правил, стандартів і рівня ризику. Елементи керування в
DSP допомагають як CSP, так і CSC захищати відповідні дані та дотримуватись
законів і норм щодо захисту даних.
• Управління, управління ризиками та відповідність (Governance, Risk
Management and Compliance)
GRC включає вісім контролів, які допомагають CSP та CSC забезпечити
управління інформацією та пов’язане з ними управління корпоративними
ризиками (ERM), управління інформаційною безпекою та програми управління
відповідністю відповідно до хмарних пропозицій та побоювання.
Як правило, CSP і CSC незалежно відповідають за впровадження своїх
відповідних засобів управління, ризиків і відповідності, щоб охопити управління
та операції, включно з їхніми хмарними продуктами, послугами, активами,
процесами та постачальниками. Створення програми GRC є повністю
внутрішнім і унікальним для кожного підприємства.
• Людські ресурси (Human Resources)
HRS використовує тринадцять контролів керування, які допомагають
хмарним підприємствам керувати ризиками, пов’язаними з внутрішніми
загрозами, і гарантують, що персонал, який працює з конфіденційними даними,
заслуговує на довіру та має належне навчання. Ефективні заходи HRS захищають
від несанкціонованого доступу та порушень даних, спричинених людським
фактором, таким чином підтримуючи загальну безпеку.
54
У SSRM як CSP, так і CSC мають ролі та обов’язки щодо незалежного
впровадження засобів контролю безпеки HRS. Обидва, як правило, несуть
відповідальність, хоч і незалежно один від одного, за проведення перевірки
репутації, забезпечення постійного навчання безпеки для своїх співробітників і
забезпечення того, щоб їхній персонал був обізнаний про ризики хмарної безпеки
та найкращі методи безпеки.
• Керування ідентифікацією та доступом (Identity and Access Management)
IAM містить шістнадцять контролів, які допомагають CSP і CSC
дотримуватися найкращих практик безпеки в управлінні ідентифікацією та
доступом до функцій безпеки та даних у хмарному середовищі. Найкращі
практики, такі як принцип найменших привілеїв, розподіл обов’язків,
багатофакторна автентифікація, контроль доступу на основі ролей і атрибутів, є
ключовими для керування доступом до хмарних ресурсів.
І CSP, і CSC поділяють відповідальність за встановлення безпечного доступу
до хмарного середовища. CSP, як правило, відповідають за надання потужних
можливостей ідентифікації та доступу, функцій, елементів керування та
відповідних механізмів для CSC. CSC, як правило, відповідають за визначення
ролей користувачів і дозволів доступу на основі принципу найменших привілеїв,
відповідне застосування надійних механізмів автентифікації, керування повним
життєвим циклом ідентифікацій та їхніх рівнів доступу, включаючи надання
доступу користувачам, зміну та відкликання для хмари служби та моніторинг
активності користувачів, щоб виявити будь-яку підозрілу поведінку та реагувати
на неї.
• Інтероперабельність і портативність (Interoperability and Portability)
IPY CCM має чотири контролів керування для забезпечення взаємодії та
переносимості в хмарному середовищі. Впровадження надійних елементів
керування сумісністю та портативністю сприяє безпечному та безпечному обміну
даними між кількома платформами та CSP, дозволяючи CSC уникати блокування
55
постачальника та сприяючи створенню середовища, де взаємодію та
портативність не перешкоджають проблеми безпеки.
І CSP, і CSC незалежно один від одного поділяють відповідальність за
забезпечення сумісності та мобільності в хмарній екосистемі. CSP зазвичай
відповідають за впровадження стандартизованих протоколів зв’язку,
забезпечення безпечних каналів зв’язку, підтримку міжплатформної сумісності,
стандартизованих форматів даних, а також спільних протоколів обробки та
обміну даними. CSC відповідають за розуміння та використання інструментів,
наданих CSP, для безпечного резервного копіювання, передачі та відновлення
даних, у тому числі за допомогою сумісного шифрування даних. CSC також
повинні розуміти інтерфейси управління, моніторингу та звітності, які надаються
CSP, а також інтеграцію цих інтерфейсів між кількома середовищами. І CSP, і
CSC несуть спільну відповідальність за документування договірних зобов’язань
щодо перенесення даних, таких як визначення права власності на дані та
процедури міграції.
• Безпека інфраструктури та віртуалізації (Infrastructure and Virtualization
Security)
IVS складається з дев’яти контролів керування, які керують CSP та CSC у
впровадженні засобів керування для захисту інфраструктури та технологій
віртуалізації. Інфраструктура охоплює все обладнання, програмне забезпечення,
мережі, засоби тощо, необхідні для надання ІТ-послуг. Технології віртуалізації
використовують програмне забезпечення для створення рівня абстракції над
апаратним забезпеченням комп’ютера, що дозволяє розділити апаратні елементи
(такі як процесори, пам’ять, сховище тощо) на віртуальні комп’ютери.
Як CSP, так і CSC зазвичай відповідають за впровадження засобів контролю
IVS. CSP зазвичай відповідають за безпеку базової інфраструктури, включаючи
платформу (гіпервізор, віртуальні машини та хост-ОС) і технології мережевої
віртуалізації, впровадження сегментації та сегрегації мережі та надання
56
можливостей CSC для планування потужності та ресурсів. CSC зазвичай
відповідають за захист виділених їм ресурсів у віртуалізованому середовищі, як-
от посилення гостьових операційних систем, застосування патчів безпеки,
відключення непотрібних служб і керування доступом до платформ і
користувацьких інтерфейсів площини керування.
• Логування та моніторинг (Logging and Monitoring)
LOG використовує тринадцять контролів керування, які дозволяють CSP і
CSC збирати, зберігати, аналізувати та звітувати про дії та події, які відбуваються
в їх хмарному середовищі. Це, у свою чергу, допомагає виявляти і реагувати на
інциденти безпеки, проблеми з роботою та системні аномалії, дотримуватись
нормативних вимог, перевіряти та перевіряти ефективність засобів контролю
безпеки, а також покращувати стан безпеки та продуктивність.
Як CSP, так і CSC, як правило, відповідають за впровадження заходів
контролю та моніторингу. CSP зазвичай відповідають за журналювання та
моніторинг хмарної інфраструктури, включаючи операції на рівні мережі та
системи. Водночас CSC зазвичай відповідають за моніторинг і ведення журналів
у своїх розгорнутих додатках і службах, гарантуючи дотримання їхніх
конкретних вимог безпеки.
• Управління інцидентами безпеки, електронне виявлення та хмарна
криміналістика (Security Incident Management, E-Discovery, and Cloud Forensics)
SEF має вісім контролів керування, які є важливими для ефективного
управління і реагування на інциденти безпеки, проведення електронного
виявлення та проведення криміналістики в хмарі. Засоби керування допомагають
CSP і CSC своєчасно виявляти, аналізувати та реагувати на інциденти безпеки,
мінімізуючи вплив на бізнес-операції.
У SSRM CSP і CSC зазвичай відповідають за розробку чітко визначених планів
реагування на інциденти, встановлення чітких ролей і обов’язків, впровадження
показників, звітування про інциденти відповідним зацікавленим сторонам і
57
посилення процедур для ефективного вирішення інцидентів безпеки. Критичним
аспектом співпраці CSP і CSC є сортування потенційних інцидентів безпеки, що
часто вимагає спільних зусиль, де CSP може надати цінну інформацію про
потенційні джерела або першопричини події безпеки, тоді як CSC може внести
інформацію, специфічну для своїх даних, конфігурації, програм і активності
користувачів.
• Прозорість і підзвітність управління ланцюгом поставок (Supply Chain
Management Transparency and Accountability)
STA містить чотирнадцять контролів, які допомагають хмарним сторонам
окреслити широкий набір елементів керування ризиками в ланцюжку поставок,
наприклад, керування SSRM між CSP і CSC. Ці елементи керування дозволяють
стороннім постачальникам застосовувати належні заходи безпеки для захисту
конфіденційності, цілісності та доступності інформації, програм і послуг у
всьому стеку технологій. Ці засоби контролю також допомагають керувати
безпекою та дотриманням нормативних вимог у всьому ланцюжку постачання.
У SSRM CSP відповідають за безпеку та управління своїм ланцюгом поставок,
а також за забезпечення прозорості своїх операцій. CSC повинні оцінювати та
розуміти ризики, пов’язані з вибраними ними CSP та їхніми постачальниками в
ланцюзі поставок, а також забезпечити виконання їхніх вимог.
• Управління загрозами та вразливістю (Threat and Vulnerability Management)
TVM складається з десяти контролів, які допомагають CSP і CSC проактивно
виявляти та пом’якшувати загрози безпеці та вразливості в хмарному середовищі,
які можуть розвиватися та впливати на активи, архітектури безпеки, конструкції
та компоненти рішень.
У SSRM як CSP, так і CSC зазвичай відповідають за впровадження засобів
контролю безпеки TVM. CSP зазвичай відповідають за ідентифікацію, оцінку,
звітування та визначення пріоритетів усунення вразливостей в інфраструктурі
хосту, мережевих пристроях, технологіях віртуалізації, операційних системах,
58
програмах платформ, таких як бази даних і веб-програми. З іншого боку, CSC
відповідають за ідентифікацію, оцінку, звітування та пріоритетне усунення
вразливостей, пов’язаних із налаштуваннями безпеки додатків/API та
неправильними налаштуваннями доступу.
• Універсальне керування кінцевими точками (Universal Endpoint Management)
UEM складається з чотирнадцяти контролів і фокусується на впровадженні
засобів контролю для зменшення ризиків, пов'язаних з кінцевими точками, в тому
числі мобільними пристроями. Ризик, пов'язаний з мобільними обчисленнями і
безпекою кінцевих точок, в основному стосується поведінки користувачів і
обізнаності (або недостатньої обізнаності) про підхід компанії до прийнятного
використання пристроїв і технологій (наприклад, керовані проти некерованих,
корпоративні проти особистих).
Як CSP, так і CSC, як правило, несуть незалежну відповідальність за
впровадження засобів контролю безпеки UEM. CSP в першу чергу відповідають
за можливості управління кінцевими точками, такі як ведення інвентаризації всіх
кінцевих точок, затвердження служб і додатків, прийнятних для використання
кінцевими точками, впровадження заходів безпеки, таких як автоматичні екрани
блокування, брандмауери і виявлення шкідливого програмного забезпечення, а
також використання превентивних технологій, шифрування сховищ і технологій
запобігання втраті даних. У той же час, CSC відповідають за безпечне управління
своїми пристроями, забезпечення їх відповідності політикам безпеки,
встановленим CSP, за захист своїх даних.
Висновки по розділу 2
Для дослідження підвищення кіберстійкості через призму хмарних технологій
в розділі розглянуто методології, контролі та вимоги:
• методологія прогресування кіберстійкості;
• вимоги-питання до хмарних провайдерів;
59
• огляд методів покращення стійкості;
• матриця керування хмарою (Cloud Controls Matrix) альянсу хмарної безпеки
(Cloud Security Alliance).
Проаналізовано методи покращення стійкості, які можуть використати
підприємства. Визначено, що структура даних технік поділяється на:
• стійкість даних і фізичного рівня;
• збереження стійкості;
• стійкість інстанса та менеджера віртуальних машин;
• стійкість хмарного керування.
Крім, цього матриця керування хмарою уособолює 17 ключових категорій,
серед яких розглядається:
• аудит та підтвердження;
• безпека програми та інтерфейсу;
• управління безперервністю бізнесу та операційною стійкістю;
• контроль змін і керування конфігурацією;
• криптографія, шифрування та керування ключами;
• безпека центру обробки даних;
• безпека даних і управління життєвим циклом конфіденційності;
• управління, управління ризиками та відповідність;
• людські ресурси;
• керування ідентифікацією та доступом;
• інтероперабельність і портативність;
• безпека інфраструктури та віртуалізації;
• логування та моніторинг;
• управління інцидентами безпеки, електронне виявлення та хмарна
криміналістика;
• прозорість і підзвітність управління ланцюгом поставок;
60
• управління загрозами та вразливістю;
• універсальне керування кінцевими точками.
61
3 ВИЗНАЧЕННЯ СТІЙКОСТІ ХМАРНИХ ПРОВАЙДЕРІВ
Анкета ініціативи оцінювання консенсусу (Consensus Assessment Initiative
Questionnaire) надає клієнтам і аудиторам хмарних технологій запитання про стан
безпеки, дотримання найкращих практик CSA (CCM та інструкції з безпеки CSA)
і обов’язки клієнтів SSRM. CAIQ – це супровідний документ, розроблений для
підтримки кращого впровадження CCM. Тоді як CCM визначає специфікацію
контролю та вказівки щодо впровадження, CAIQ визначає питання для оцінки та
інформування про впровадження.
Зв’язок між контролем CCM і питаннями CAIQ часто один до багатьох. Це так
задумано, оскільки CCM базується на 197 елементах керування, тоді як остання
версія CAIQ (версія 4) містить 261 запитання. Залежно від характеру та
складності контролю CCM може бути поставлене одне або декілька запитань для
перевірки виконання певного контролю.
CAIQ, подібний до CCM, поставляється у форматі електронної таблиці зі
структурою, подібною до CCM. CAIQ включає стовпці для CSP, щоб відповісти
на запитання CAIQ («Так», «Ні» або «Не застосовано»), вказуючи право
власності SSRM на елементи керування CCM, яких стосується питання CAIQ.
CAIQ також містить стовпці для CSP, які описують, як вони виконують свої
частини контролю та будь-які пов’язані з ними обов’язки щодо безпеки клієнтів.
Постачальники хмарних послуг повинні розмежувати право власності на SSRM,
пояснити, як вони відповідають вимогам контролю, і роз’яснити обов’язки
клієнта щодо безпеки на рівні запитань.
CAIQ і CSA забезпечують структуру для CSP, щоб надати корисну
інформацію, яку поточні та потенційні клієнти можуть використовувати для
оцінки того, як було реалізовано засоби контролю. Крім того, ці інструменти
дозволяють провайдерам окреслити впровадження SSRM на користь клієнтів.
62
Далі для дослідження я наведу інформацію лише для найбільш поширених
хмарних провайдерів. Крім цього, я зазначу питання на які провайдери відповіли
«Ні» або «Не застосовано».
Отже в наступних таблиця показано такі категорії:
1. відповідь
• «Ні». Вимога від CCM не виконана. Дана опція вказує на те, що частина
контролю, про яку йде мова, не реалізована під час оцінювання. CSP має покласти
відповідальність за впровадження контролю на відповідну сторону в стовпці
«SSRM» і за бажанням уточнити «чому» (не було реалізовано) і «що» потрібно
зробити для його впровадження [31].
• «Не застосовано». Запитання не входить до сфери застосування та не
стосується хмарної служби, що оцінюється.
2. SSRM
• CSP: несе повну відповідальність і підзвітність за впровадження контролю
CCM.
• CSC: несе повну відповідальність за реалізацію контролю CCM.
• CSP і CSC: як CSP, так і CSC поділяють відповідальність за реалізацію
контролю CCM і підзвітність.
3. Опис CSP: означає як саме реалізована вимога CCM у хмарного провайдера.
4. Відповідальність CSC: означає, що має робити клієнт у розрізі певної вимоги.
63
Таблиця 3.1 – Для Microsoft Azure [32]
ID Питання Відповідь SSRM Опис CSP
UEM- Чи визначено, Не –– Azure не
14.1 впроваджено та застосовано дозволяє
оцінено процеси, кінцевим
процедури та технічні точкам
та/або договірні сторонніх
заходи для підтримки розробників
належної безпеки отримувати
сторонніх кінцевих доступ до
точок з доступом до робочого
активів підприємства? середовища.
Таблиця 3.2 – Для Google Cloud [33]
ID Питання Відповідь SSRM Опис CSP Відповідальність
CSC
BCR- Чи Ні CSP Google має ––
10.2 залучаються внутрішню
місцеві служби групу безпеки,
з надзвичайних яка виконує
ситуацій, якщо функції
це можливо, до зв’язку з
навчань? екстреним
персоналом.
64
Продовження таблиці 3.2
IAM- Чи визначені, Не CSP Google обмежує ––
11.1 запроваджені та застосовано доступ на
оцінені процеси основі
та процедури обов’язкових
для участі відомостей і
клієнтів, де це посадових
можливо, у обов’язків.
наданні доступу
для узгоджених
ролей
привілейованого
доступу з
високим рівнем
ризику
(визначених
оцінкою
організаційного
ризику)?
65
Кінець таблиці 3.2
IVS- Чи визначені та Не CSP У робочому Клієнти несуть
08.1 задокументован застосован і середовищі відповідальніст
і середовища о CS Google існують ь за
високого C середовища з ідентифікацію
ризику? високим рівнем та
довіри, які документуванн
вважаються я середовищ
середовищами високого
привілейованог ризику в
о доступу та інстансах,
забезпечуються якими керує
засобами клієнт.
контролю
доступу.
STA Чи Не CSP Google не має ––
-10.1 переглядаються застосован угод про
угоди про о ланцюжок
ланцюг поставок між
постачання між ними та
CSP і CSC клієнтами.
принаймні раз Google Cloud
на рік? підтримує угоди
про рівень
обслуговування
.
66
Таблиця 3.3 – Для Oracle Cloud [34]
ID Питання Відповідь SSR Опис CSP Відповідальність
M CSC
DSP Чи Не CSC Сфера дії Oracle Клієнти несуть
- проводиться застосован Cloud відповідальність
09.1 оцінка о Infrastructure за проектування,
впливу на зосереджена на розробку,
захист даних вмісті клієнтів і тестування,
(DPIA) під виключає впровадження,
час обробки особисті дані експлуатацію та
персональни клієнтів, підтримку
х даних і оскільки вони адміністративних
оцінювання використовують і технічних
походження, ся лише для засобів захисту
характеру, адміністративни для запобігання
особливосте х функцій. або виявлення
й і несанкціонованог
серйозності о доступу,
ризиків використання та
відповідно розкриття під час
до будь-яких введення,
законів, обробки,
нормативни збереження,
х актів і виведення та
практик? видалення даних
до, всередині або
з їх застосування.
67
Продовження таблиці 3.3
DSP- Чи визначено, Не CSP Див. DSP-09.1 У тій мірі, в якій
11.1 впроваджено застосовано і Oracle залучає
та оцінено CSC афілійованих осіб
процеси, Oracle і сторонніх
процедури та субпроцесорів
технічні для отримання
заходи, щоб доступу до
дозволити Персональної
суб’єктам інформації Служб
даних з метою надання
запитувати допомоги в
доступ до наданні Послуг,
персональних такі
даних, субпроцесори
змінювати чи підпадають під
видаляти їх той самий рівень
(відповідно до захисту та
чинних безпеки даних,
законів і що й Oracle.
нормативних
актів)?
68
Продовження таблиці 3.3
DSP- Чи визначено, Не CSP Див. DSP-09.1 Клієнти несуть
12.1 впроваджено застосовано і відповідальність
та оцінено CSC за проектування,
процеси, розробку,
процедури та тестування,
технічні впровадження,
заходи для експлуатацію та
забезпечення підтримку
обробки адміністративних і
персональних технічних засобів
даних захисту для
(відповідно до запобігання або
чинних виявлення
законів і несанкціонованого
правил і для доступу,
цілей, використання та
заявлених розкриття під час
суб’єкту введення, обробки,
даних)? збереження,
виведення та
видалення даних
до, всередині або з
їх застосування.
69
Продовження таблиці 3.3
DSP- Чи визначено, Не CSP Див. DSP-09.1 Див. DSP-12.1
13.1 впроваджено застосовано і
та оцінено CSC
процеси,
процедури та
технічні
заходи для
передачі та
додаткової
обробки
персональних
даних у
ланцюжку
постачання
послуг
(відповідно до
будь-яких
чинних законів
і нормативних
актів)?
70
Кінець таблиці 3.3
DSP- Чи отримано Не CSP Oracle Cloud Див. DSP-12.1
15.1 дозвіл від застосовано і Infrastructure не
власників CSC дозволяє
даних і чи використовувати
керовано виробничі дані в
відповідним невиробничих
ризиком перед середовищах.
реплікацією
або
використанням
виробничих
даних у
невиробничих
середовищах?
Таблиця 3.4 – Для AWS [35]
ID Питання Відповідь SSRM Опис CSP Відповідальність
CSC
BCR- Чи залучаються Ні CSP –– ––
10.2 до навчань
місцеві служби
з надзвичайних
ситуацій, якщо
це можливо?
71
Продовження таблиці 3.4
CCC- Чи положення Ні CSP Постійні ––
05.1 щодо обмеження оновлення про
змін, які зміни в сервісі.
безпосередньо Постійний
впливають на розвиток і
середовище, що вдосконалення
належить CSC, і послуг.
вимагають від Часте
орендарів впровадження
авторизувати нових
запити, пропозицій.
включено в Існуючі API
угоди про рівень доступні
обслуговування протягом 12
(SLA) між CSP і місяців після
CSC? оновлення.
Доступ до
інформаційної
панелі стану
служби.
Зобов’язання
щодо виконання
угод з клієнтами
дотримуються.
72
Продовження таблиці 3.4
CEK- Чи захищено Не CSC –– Клієнти
03.1 криптографічно застосовано можуть
захищені дані, застосовувати
що перебувають власні методи
у спокої та під шифрування.
час передавання, Тунелі IPSec до
за допомогою VPC
криптографічних зашифровані.
бібліотек, AWS KMS
сертифікованих полегшує
відповідно до створення та
затверджених контроль
стандартів? ключів.
Допомога в
дотриманні
нормативних
вимог.
73
Продовження таблиці 3.4
CEK- Чи Не CSC –– Клієнти
04.1 використовуються застосовано контролюють
відповідні управління
алгоритми своїми даними.
шифрування Клієнти
захисту даних, які вирішують, як
враховують класифікувати
класифікацію свій вміст.
даних, пов’язані AWS не знає,
ризики та який тип вмісту
зручність клієнт вирішує
використання зберігати в
технології AWS. Клієнти
шифрування? мають повні
повноваження
щодо свого
вмісту.
74
Продовження таблиці 3.4
CEK- Чи керуються Не CSC –– Клієнти
11.1 особистими застосовано вирішують, чи
ключами для хочуть вони
унікальної мети використовувати
та чи є AWS KMS для
криптографія зберігання
таємною? ключів
шифрування в
хмарі чи
використовувати
інші механізми
(локальний
HSM, інші
технології
керування
ключами) для
зберігання
ключів у своїх
локальних
середовищах.
75
Продовження таблиці 3.4
CEK- Чи змінюються Не CSC –– Клієнти можуть
12.1 криптографічні застосовано застосовувати
ключі на основі власні методи
періоду шифрування.
шифрування, Тунелі IPSec до
розрахованого з VPC
урахуванням зашифровані.
ризиків AWS KMS
розкриття полегшує
інформації та створення та
законодавчих і контроль
нормативних ключів.
вимог? Допомога в
дотриманні
нормативних
вимог.
76
Продовження таблиці 3.4
CEK- Чи Не CSC –– Див. CEK-03.1
13.1 криптографічні застосовано
ключі
відкликаються
та видаляються
до закінчення
встановленого
періоду
шифрування
відповідно до
визначених,
реалізованих і
оцінених
процесів,
процедур і
технічних
заходів,
включаючи
юридичні та
положення
нормативних
вимог?
77
Продовження таблиці 3.4
CEK- Чи визначено, Не CSC –– Див. CEK-03.1
14.1 впроваджено та застосовано
оцінено
процеси,
процедури та
технічні заходи
для знищення
непотрібних
ключів, щоб
усунути
знищення
ключів поза
безпечними
середовищами,
відкликання
ключів, що
зберігаються в
апаратних
модулях безпеки
(HSM), і
включити
відповідні
законодавчі та
нормативні
вимоги?
78
Продовження таблиці 3.4
CEK- Чи Не CSC –– Див. CEK-03.1
15.1 визначаються, застосовано
впроваджуються
та оцінюються
процеси,
процедури та
технічні заходи
для створення
ключів у
попередньо
активованому
стані (тобто,
коли вони були
згенеровані, але
не авторизовані
для
використання),
щоб включити
правові та
нормативні
вимоги?
79
Продовження таблиці 3.4
CEK- Чи Не CSC –– Див. CEK-03.1
16.1 визначаються, застосовано
впроваджуються
та оцінюються
процеси,
процедури та
технічні заходи
для моніторингу,
перегляду та
затвердження
ключових
переходів
(наприклад, з
будь-якого стану
до/з
призупинення)
для включення
правових і
нормативних
вимог?
80
Продовження таблиці 3.4
CEK- Чи Не CSC –– Див. CEK-03.1
17.1 визначаються, застосовано
впроваджуються
та оцінюються
процеси,
процедури та
технічні заходи
для деактивації
ключів (після
закінчення
терміну дії) для
включення
юридичних і
нормативних
вимог?
81
Продовження таблиці 3.4
CEK- Чи Не CSC –– Див. CEK-03.1
18.1 визначаються, застосовано
впроваджуються
та оцінюються
процеси,
процедури та
технічні заходи
для керування
архівованими
ключами в
захищеному
сховищі (що
потребує
мінімального
доступу) для
включення
юридичних і
нормативних
вимог?
82
Продовження таблиці 3.4
CEK- Чи Не CSC –– Клієнти AWS
19.1 визначаються, застосовано несуть
впроваджуються відповідальність
та оцінюються за керування
процеси, даними, які вони
процедури та розміщують у
технічні заходи службах AWS.
для шифрування AWS не знає,
інформації в який тип вмісту
конкретних клієнт вирішує
сценаріях зберігати в AWS,
(наприклад, і клієнт зберігає
лише в повний контроль
контрольованих над тим, як вони
обставинах і вибирають
згодом лише для класифікувати
дешифрування свій вміст, де він
даних і ніколи зберігається,
для використовується
шифрування) та захищений від
для включення розголошення.
правових і
нормативних
вимог?
83
Продовження таблиці 3.4
CEK- Чи Не CSC –– Див. CEK-03.1
21.1 визначаються, застосовано
впроваджуються
та оцінюються
процеси,
процедури та
технічні заходи
системи
керування
ключами для
відстеження та
звітування про
всі
криптографічні
матеріали та
зміни статусу,
які включають
положення
законодавчих та
нормативних
вимог?
84
Продовження таблиці 3.4
DSP- Чи створюється Не CSC –– Клієнти AWS
03.1 та застосовано несуть
підтримується відповідальність
інвентаризація за керування
даних для даними, які вони
конфіденційної розміщують у
та особистої службах AWS.
інформації (як AWS не знає,
мінімум)? який тип вмісту
DSP- Чи дані Не CSC –– клієнт вирішує
04.1 класифікуються застосовано зберігати в AWS,
за типом і і клієнт зберігає
рівнями повний контроль
чутливості? над тим, як вони
DSP- Чи створюється Не CSC –– вибирають
05.1 документація застосовано класифікувати
щодо потоку свій вміст, де він
даних, щоб зберігається,
визначити, які використовується
дані та захищений від
обробляються та розголошення.
де вони
зберігаються та
передаються?
85
Продовження таблиці 3.4
DSP- Чи перевіряється Не CSC –– Див. DSP-03.1
05.2 документація застосовано
потоку даних
через певні
проміжки часу,
принаймні раз на
рік і після будь-
яких змін?
DSP- Чи Не CSC ––
06.1 задокументовано застосовано
право власності
та
розпорядження
всіма
відповідними
особистими та
конфіденційними
даними?
DSP- Чи перевіряється Не CSC ––
06.2 принаймні раз на застосовано
рік документація
про право
власності та
управління
даними?
86
Продовження таблиці 3.4
DSP- Чи ґрунтуються Не CSC –– Див. DSP-03.1
08.1 системи, застосовано
продукти та
бізнес-практики
на принципах
конфіденційності
за проектом і
відповідно до
найкращих
галузевих
практик?
DSP- Чи налаштування Не CSC –– Клієнти AWS
08.2 конфіденційності застосовано несуть
систем відповідальність
налаштовано за за дотримання
замовчуванням і нормативних
відповідно до вимог у
всіх чинних юрисдикціях, у
законів і правил? яких веде свою
діяльність.
87
Продовження таблиці 3.4
DSP- Чи проводиться Не CSC –– Клієнти AWS
09.1 оцінка впливу застосовано несуть
на захист даних відповідальність
(DPIA) під час за керування
обробки даними, які вони
персональних розміщують у
даних і оцінки службах AWS.
походження, AWS не знає,
характеру, який тип вмісту
особливостей і клієнт вирішує
серйозності зберігати в AWS,
ризиків і клієнт зберігає
відповідно до повний контроль
будь-яких над тим, як вони
чинних законів, вибирають
нормативних класифікувати
актів і свій вміст, де він
найкращих зберігається,
галузевих використовується
практик? та захищений від
розголошення.
88
Продовження таблиці 3.4
DSP- Чи визначено, Не CSC –– Див. DSP-09.1
10.1 впроваджено та застосовано
оцінено процеси,
процедури та
технічні заходи,
щоб гарантувати,
що будь-яка
передача
персональних або
конфіденційних
даних захищена
від
несанкціонованого
доступу та
обробляється
лише в межах (як
це дозволено
відповідними
законами та
нормативними
актами)?
89
Продовження таблиці 3.4
DSP- Чи визначено, Не CSC –– Див. DSP-09.1
11.1 впроваджено та застосовано
оцінено процеси,
процедури та
технічні заходи,
щоб дозволити
суб’єктам даних
запитувати
доступ до
персональних
даних,
змінювати чи
видаляти їх
(відповідно до
чинних законів і
нормативних
актів)?
90
Продовження таблиці 3.4
DSP- Чи визначено, Не –– Клієнти AWS ––
13.1 впроваджено та застосовано несуть
оцінено процеси, відповідальність
процедури та за керування
технічні заходи даними у
для передачі та службах AWS.
додаткової AWS не знає,
обробки який тип вмісту
персональних клієнт вирішує
даних у зберігати, і
ланцюжку клієнт зберігає
постачання повний
послуг контроль. AWS
(відповідно до завчасно
будь-яких інформує наших
чинних законів і клієнтів про
нормативних будь-яких
актів)? субпідрядників.
Немає
субпідрядників,
уповноважених
AWS на доступ
до будь-якого
вмісту клієнта.
91
Продовження таблиці 3.4
DSP- Чи визначено, Не –– AWS завчасно ––
14.1 впроваджено та застосовано інформує наших
оцінено процеси, клієнтів про
процедури та будь-яких
технічні заходи, субпідрядників,
щоб розкрити які мають
власнику даних доступ до вмісту
деталі будь- клієнта, який ви
якого доступу до завантажуєте на
особистих або AWS,
конфіденційних включаючи
даних вміст, який може
суб’єктами містити особисті
обробки до дані. Немає
початку субпідрядників,
обробки? уповноважених
AWS на доступ
до будь-якого
вмісту, що
належить
клієнту, який ви
завантажуєте на
AWS.
92
Продовження таблиці 3.4
DSP- Чи отримано Не –– Дані клієнтів не ––
15.1 дозвіл від застосовано використовуються
власників даних для тестування.
і чи керовано
відповідним
ризиком перед
реплікацією або
використанням
виробничих
даних у
невиробничих
середовищах?
93
Продовження таблиці 3.4
DSP- Чи визначено та Не CSC –– Клієнти:
17.1 впроваджено застосовано • Визначають,
де буде
процеси, зберігатися
процедури та їхній
клієнтський
технічні заходи вміст.
для захисту • Клієнти
можуть
конфіденційних копіювати та
даних протягом створювати
резервні копії
усього свого
життєвого клієнтського
вмісту, і AWS
циклу? не буде
переміщувати
чи копіювати
клієнтський
вміст за межі
вибраних
клієнтом(-ами)
регіонів.
• Вибрати
захищений стан
свого
клієнтського
вмісту.
• Керуйте
доступом до
вмісту своїх
клієнтів і
послуг і
ресурсів AWS
через
користувачів,
групи, дозволи
та облікові дані.
94
DSP- Чи визначено та Не CSC –– Клієнти
19.1 впроваджено застосовано керують
процеси, доступом до
процедури та свого
технічні заходи клієнтського
для визначення контенту,
та послуг і
документування ресурсів AWS.
фізичних місць Ми надаємо
розташування розширений
даних, у тому набір функцій
числі регіонів, де доступу,
дані шифрування та
обробляються журналювання.
або резервні Ми не
копії? отримуємо
доступ і не
використовуємо
вміст клієнтів.
95
Продовження таблиці 3.4
IAM- Чи визначені, Ні –– –– ––
11.1 запроваджені та
оцінені процеси
та процедури для
участі клієнтів,
де це можливо, у
наданні доступу
для узгоджених
ролей
привілейованого
доступу з
високим рівнем
ризику
(визначених
оцінкою
організаційного
ризику)?
96
Продовження таблиці 3.4
IVS- Чи зашифровано Не CSC –– API AWS
03.2 зв’язок між застосовано доступні через
середовищами? захищені TLS
кінцеві точки,
які забезпечують
автентифікацію
сервера. Клієнти
можуть
використовувати
TLS для всіх
взаємодій із
AWS і в межах
свого
середовища.
AWS надає
відкриті
методології
шифрування та
дозволяє
клієнтам
шифрувати та
автентифікувати
весь трафік.
97
Продовження таблиці 3.4
IVS- Чи визначені та Не CSC –– Клієнти AWS
08.1 задокументовані застосовано несуть
середовища відповідальність
високого ризику? за керування
власною
сегментацією
мережі
відповідно до
визначених
вимог.
Всередині
сегментація
мережі AWS
узгоджується зі
стандартом ISO
27001.
LOG- Чи Не CSC –– Клієнти AWS
03.1 ідентифікуються застосовано несуть
та відстежуються відповідальність
події, пов’язані з за програми в
безпекою, у своєму
програмах та середовищі
базовій AWS.
інфраструктурі?
98
Продовження таблиці 3.4
LOG- Чи реєструються Не CSC –– Це
11.1 та застосовано відповідальність
відстежуються клієнта.
події керування
життєвим
циклом ключів,
щоб уможливити
аудит і
звітування про
використання
криптографічних
ключів?
99
Продовження таблиці 3.4
STA- Чи SSRM Не CSP AWS завчасно ––
02.1 застосовано, застосовано інформує
задокументовано, наших клієнтів
впроваджено та про будь-яких
керовано в субпідрядників,
усьому які мають
ланцюжку доступ до
поставок для вмісту клієнта,
пропозиції який ви
хмарних послуг? завантажуєте
на AWS,
включаючи
вміст, який
може містити
особисті дані.
Немає
субпідрядників,
уповноважених
AWS на доступ
до будь-якого
вмісту, що
належить
клієнту, який
ви
завантажуєте
на AWS.
100
Продовження таблиці 3.4
STA- Чи отримує CSC Не CSP Див. STA-02.1 ––
03.1 інструкції щодо застосовано
SSRM із
детальною
інформацією про
застосування
SSRM у всьому
ланцюжку
постачання?
101
Продовження таблиці 3.4
STA- Чи розроблено та Не CSP AWS проводить ––
07.1 підтримується застосовано періодичні
перелік усіх перевірки
зв’язків у ланцюзі постачальників
поставок? послуг SSRM і
STA- Чи періодично Не CSP спільного ––
08.1 CSP перевіряють застосовано розміщення.
фактори ризику, AWS підтримує
пов’язані з усіма стандартні
підприємствами в процеси
ланцюжку перевірки та
постачання? підписання
контрактів, які
включають
юридичні
перевірки з
урахуванням
захисту ресурсів
AWS. Немає
субпідрядників,
уповноважених
AWS на доступ
до будь-якого
вмісту.
102
Продовження таблиці 3.4
STA- Чи періодично Не CSP AWS не залучає ––
13.1 переглядаються застосовано третіх сторін для
політики та надання послуг
процедури ІТ- клієнтам, але
управління використовує
партнерів ланцюга умови спільного
постачання? розміщення в
STA- Чи визначено та Не CSP обмеженій. Ці ––
14.1 впроваджено застосовано засоби контролю
процес проведення перевіряються
періодичних двічі на рік під
оцінок безпеки для час наших
всіх підприємств аудитів SOC 1/2 і
ланцюга щорічно під час
постачання? наших аудитів
ISO 27001/17/18.
Немає
субпідрядників,
уповноважених
AWS на доступ
до будь-якого
контенту.
103
Продовження таблиці 3.4
TVM- Чи визначено, Ні CSP AWS Security ––
07.1 впроваджено та проводить
оцінено процеси, регулярне
процедури та сканування
технічні заходи вразливостей у
для виявлення операційній
вразливостей системі хоста,
активів, якими веб-програмі та
керує базах даних у
підприємство, середовищі AWS
щонайменше за допомогою
щомісяця? різноманітних
інструментів.
Зовнішня оцінка
вразливості
проводиться
стороннім
постачальником,
затвердженим
AWS,
щонайменше раз
на квартал.
104
Продовження таблиці 3.4
UEM- Чи визначені, Не –– Співробітники ––
05.1 впроваджені та застосовано AWS не мають
оцінені процеси, доступу, не
процедури та обробляють, не
технічні заходи змінюють дані
для забезпечення клієнтів під час
дотримання використання.
політик і засобів AWS має окремі
контролю для всіх середовища
кінцевих точок, CORP і PROD, які
яким дозволено відокремлені
доступ до систем одне від одного.
та/або зберігання, Лише схвалені
передача чи користувачі
обробка матимуть
організаційних можливість
даних? отримати доступ
UEM- Чи захищена Не CSP із CORP до ––
08.1 інформація від застосовано PROD. Система
несанкціонованого керує дозволами,
розголошення на вимагає
керованих схваленого
кінцевих точках за квитка, MFA, час
допомогою обмежений і всі
шифрування дії
пам’яті? відстежуються.
105
Продовження таблиці 3.4
UEM- Чи керовані Не –– Див. UEM-05.1 ––
11.1 кінцеві точки застосовано
налаштовані за
допомогою
технологій і
правил
запобігання втраті
даних (DLP)
відповідно до
оцінки ризику?
UEM- Чи ввімкнено Ні CSP –– ––
12.1 можливості
віддаленого
геолокації для всіх
керованих
мобільних
кінцевих точок?
106
Кінець таблиці 3.4
UEM- Чи визначено, Не –– Див. STA-13.1 ––
14.1 впроваджено та застосовано
оцінено процеси,
процедури та
технічні та/або
договірні заходи
для підтримки
належної безпеки
сторонніх
кінцевих точок з
доступом до
активів
підприємства?
Отже, можемо побачити що у всіх хмарних провайдерів є рішення як саме
реагувати на різні ситуації. Таблиця 3.5 підсумовує аналіз стійкості хмар.
Таблиця 3.5 – Підсумок
«Ні» «Не застосовано» Які категорії порушені
MS Azure 0 1 • Універсальне керування
кінцевими точками.
107
Продовження таблиці 3.5
Google cloud 1 3 • Управління безперервністю
бізнесу та операційною
стійкістю.
• Керування ідентифікацією та
доступом.
• Безпека інфраструктури та
віртуалізації.
• Прозорість і підзвітність
управління ланцюгом поставок.
Oracle cloud 0 5 • Безпека даних і управління
життєвим циклом
конфіденційності.
108
Кінець таблиці 3.5
AWS 5 42 • Управління безперервністю
бізнесу та операційною
стійкістю.
• Контроль змін і керування
конфігурацією.
• Криптографія, шифрування та
керування ключами.
• Безпека даних і управління
життєвим циклом
конфіденційності.
• Керування ідентифікацією та
доступом.
• Безпека інфраструктури та
віртуалізації.
• Логування та моніторинг
• Прозорість і підзвітність
управління ланцюгом поставок.
• Управління загрозами та
вразливістю.
• Універсальне керування
кінцевими точками.
109
Висновки по розділу 3
Відповідно в цьому розділі провівся аналіз структур, ідей та підпрактик
стійкості хмарних провайдерів. Було проведено дослідження чотирьох хмарних
інфраструктур: Microsoft Azure, Google cloud, Oracle cloud та AWS . Проведено
вивчення відповідей хмар на кожний контроль. В результаті порівняльного
аналізу було встановлено, що хмарні провайдери мають як слабкі, так і сильні
сторони. Тобто в даному контексті, певні контролі або не використовуються, або
перекладені на відповідальність клієнтів. До переваг Google cloud можна віднести
незастосування лише 4 вимог. Перевагою Oracle cloud є застосування всіх 261
контролів, окрім 5. Для даної хмари відповідальність за категорію «безпека даних
і управління життєвим циклом конфіденційності» переноситься на клієнтів.
В результаті дослідження встановлено, що з найменшою кількістю
невиконання конролів є саме Microsoft Azure. Для цієї хмари незастосовується
лише одна вимога – не визначені та не впроваджені процеси, процедури, а також
технічні і/або договірні заходи для забезпечення належної безпеки сторонніх
кінцевих точок, які мають доступ до активів підприємства. При цьому, з
найбільшою кількістю не відповідностей є саме AWS. Дана хмарна
інфраструктура не виконує 5 контролів та перекладає відповідальність на клієнтів
з 42 вимогами.
110
ВИСНОВКИ
У кваліфікаційній роботі було виконано дослідження, які направлені на
вивчення систем, контролів, вимог для забезпечення кіберстійкості підприємства
через призму хмарних технологій. Це дало можливість підібрати для вивчення та
аналізування відповідні підходи. Окрім цього, розглянуто контролі, які можуть
забезпечити стійкість підприємств, спираючись на хари. Постійне зростання
кібератак створює серйозні ризики, які можуть призвести до втрати
конфіденційних даних, шкоди репутації та значних фінансових втрат. З 2022 року
кількість шахрайств у сфері технологій зросла на 400%, що свідчить про
зростаючу активність кіберзлочинців у цій галузі.
Проведено дослідження для підвищення кіберстійкості через призму хмарних
інфраструктур. Проаналізовано застосування різних методологій, контролів та
вимог, які покращать хмарну стійкість.
Перелік підходів та практик має відображення у систематичності забезпечення
кіберстійкості.
В результаті проведеного дослідження встановлено, що хмарні провайдери
мають свої сильні та слабкі сторони. Microsoft Azure має ряд переваг, але не
виконується одна вимога. При чому Azure перекладає цей один контроль на
клієнтів. Водночас AWS теж має свої переваги, але не виконує 47 практик. Після
проведення дослідження було встановлено, що Microsoft Azure переважає у
стійкості. Однак, використання інших хмарних провайдерів не є повністю
критичним для клієнтів по відношенню до кіберстійкості.
Дане дослідження та контролі пропонують структуровані підходи для
забезпечння стійкості підприємств, які використовуються хмари, витримувати
кібератаки, виявлення вразливостей та розробки стратегій з метою підвищення
загального рівня кіберстійкості.
111
Дослідження було проведено для того, щоб проаналізувати реальні системи,
вимоги до хмар задля забезпечення кіберстійкості, збільшити розуміння
важливості безпеки підприємств в кіберпросторі, напрацювати матеріали для
створення належних стандартів, фреймворків та збільшити стійкість системи.
Підсумовуючи, впровадження ефективних систем і вимог до хмарних
провайдерів задля забезпечення кіберстійкості на рівні підприємства мають
вирішальне значення для підтримки надійної безпеки в сучасному цифровому
середовищі. Завдяки створенню системи кіберстійкості, підприємства отримують
можливість краще ідентифікувати свої вразливі місця, виявляти потенційні
загрози та вживати профілактичні заходи для захисту своїх цінних активів. Тому
пропонується використовувати різні підходи одночасно.
112
ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАНЬ
1. World Economic Forum. Global Cybersecurity Outlook [Електронний ресурс] –
2022 – С. 22-33 – Режим доступу:
https://www3.weforum.org/docs/WEF_Global_Cybersecurity_Outlook_2022.pdf?_gl
=1*1497y5w*_up*MQ..&gclid=CjwKCAjw4ZWkBhA4EiwAVJXwqWn_XQi1
AxWk23lqjY-v3e_UHKK9e0SuaA8W7qynvaO2XuOmiRkCaxoCZiUQAvD_BwE
2. Cloudflare, Shielding the Future: Europe’s Cyber Threat Landscape [Електронний
ресурс] – 2024 – С. 5-26 – Режим доступу: https://cf-
assets.www.cloudflare.com/slt3lc6tev37/75ElqwrRueH9MItWszjLYn/4846ff17abe16
ffa1ce286d2bdcfbbb6/Shielding-the-future-europes-cyber-threat-landscape.pdf
3. World Economic Forum, The global risks report 2024 [Електронний ресурс] –2024
– С. 2-115 – Режим доступу:
https://www3.weforum.org/docs/WEF_The_Global_Risks_Report_2024.pdf
4. Allianz Commercial, Allianz Risk Barometer: Identifying the major business risks
for 2024 [Електронний ресурс] – 2024 – С. 21-51 – Режим доступу:
https://commercial.allianz.com/content/dam/onemarketing/commercial/commercial/re
ports/Allianz-Risk-Barometer-2024.pdf
5. Schlaepfer R. C., Koch M., Merkhofer P. Industry 4.0 challenges and solutions for
the digital transformation and use of exponential technologies [Текст] – 2015 – С. 5-
13.
6. Wegner A., Graham J., Ribble E. A new approach to cyberphysical security in
Industry 4.0. In L. Thames, D. Schaefer. Cybersecurity for Industry 4.0: Analysis for
design and manufacturing [Електронний ресурс] – 2017 – С. 59–72 – Режим
доступу: https://doi.org/10.1007/978-3-319-50660-9_3
7. Fredrik Björck, Martin Henkel, Janis Stirna, and Jelena Zdravkovic. Cyber
Resilience – fundamentals for a definition [Електронний ресурс] – 2015 – Режим
доступу: 10.1007/978-3-319-16486-1_31
113
8. Deutscher S.A., Bohmayr W. , Asen A. Building a Cyberresilient Organization
[Текст] – 2017 – С. 2–8.
9. Sidney C Smith. Toward a Scientific Definition of Cyber Resilience [Електронний
ресурс] – 2023 – С. 5–42 – Режим доступу:
https://apps.dtic.mil/sti/trecms/pdf/AD1205369.pdf
10. Про рішення Ради національної безпеки і оборони України від 14 травня 2021
року "Про Стратегію кібербезпеки України": Указ Президента України від
26.08.2021 р. № 447/2021. – Режим доступу:
https://zakon.rada.gov.ua/laws/show/447/2021#Text
11. Schneier, B. The future of incident response. IEEE Secur. Priv [Електронний
ресурс] – 2014 – С. 1–2 – Режим доступу:
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6924685
12. Lorrie Faith Cranor. A Framework for Reasoning About the Human in the Loop
[Електронний ресурс] – 2008 – С. 1–15 – Режим доступу:
https://www.usenix.org/legacy/event/upsec08/tech/full_papers/cranor/cranor.pdf
13. NIST. Framework for Improving Critical Infrastructure Cybersecurity V 1.1
[Електронний ресурс] – 2018 – С. 1–41 – Режим доступу:
https://nvlpubs.nist.gov/nistpubs/cswp/nist.cswp.04162018.pdf
14. Center for Internet Security (CIS). CIS Controls V 7.1 [Текст] – 2019 – С. 5–23.;
15. Juan Francisco Carías, Leire Labaka, José María Sarriegi and Josune Hernantes.
Defining a Cyber Resilience Investment Strategy in an Industrial Internet of Things
Context [Електронний ресурс] – 2019 – С. 2–16 – Режим доступу:
https://www.mdpi.com/1424-8220/19/1/138
16. Ekkachat Baikloy, Prasong Praneetpolgrang, Nivet Jirawichitchai. Development of
Cyber Resilient Capability Maturity Model for Cloud Computing Services
[Електронний ресурс] – 2020 – С. 1–9 – Режим доступу:
https://www.temjournal.com/content/93/TEMJournalAugust_915_923.pdf
114
17. BOARD OF GOVERNORS OF THE FEDERAL RESERVE SYSTEM.
Cybersecurity and Financial System Resilience Report [Текст] – 2021 – С. 5–19.
18. World Economic Forum/ The Cyber Resilience Index: Advancing Organizational
Cyber Resilience [Електронний ресурс] – 2022 – С. 1–29 – Режим доступу:
https://www3.weforum.org/docs/WEF_Cyber_Resilience_Index_2022.pdf
19. Microsoft Digital Defense Report [Електронний ресурс] – 2021 – С. 2–56 –
Режим доступу: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWMFIi
20. Microsoft Digital Defense Report 2024: The foundations and new frontiers of
cybersecurity [Електронний ресурс] – 2024 – С. 1–46 – Режим доступу: https://cdn-
dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-
brand/documents/Microsoft%20Digital%20Defense%20Report%202024%20%281%
29.pdf
21. NCSI PROJECT MANAGEMENT [Електронний ресурс] – Режим доступу:
https://ncsi.ega.ee/country/ua/
22. Мінфін. Кібербезпека бізнесу Як виявити загрозу і вберегти дані та ресурси
компанії під час війни [Електронний ресурс] – Режим доступу:
https://www.project.minfin.com.ua/kiberbezpeka-biznesu-pid-chas-vijny
23. Mariusz Michalowski. 55 Cloud Computing Statistics for 2024 [Електронний
ресурс] – 2024 – Режим доступу: https://spacelift.io/blog/cloud-computing-statistics
24. Cody Slingerland. 101+ Cloud Computing Statistics That Will Blow Your Mind
(Updated 2024) – 2024 – Режим доступу: https://www.cloudzero.com/blog/cloud-
computing-statistics/
25. Про хмарні послуги : Закон України від 17.02.2022 № 2075-IX – Режим
доступу: https://zakon.rada.gov.ua/laws/show/2075-20#Text
26. Fargana Abdullayeva. Cyber resilience and cyber security issues of intelligent cloud
computing systems [Електронний ресурс] – 2023 – С. 1–16 – Режим доступу:
http://dx.doi.org/10.1016/j.rico.2023.100268
115
27. Juan F. Carías, Saioa Arrizabalaga, Leire Labaka and Josune Hernantes. Cyber
Resilience Progression Model [Електронний ресурс] – 2020 – С. 1–32 – Режим
доступу: https://www.mdpi.com/2076-3417/10/21/7393
28. Oleksandr Protsenko. METHODOLOGY FOR ENSURING CYBER
RESILIENCE IN THE CLOUD ENVIRONMENT AT THE ENTERPRISE [Text] //
1st Ukrainian Scientific and Practical Conference «Scientific Research Methodology –
2024» – 2024 – С. 1–3.
29. Thomas Welsh, Elhadj Benkhelifa. On Resilience in Cloud Computing: A Survey
of Techniques across the Cloud Domain [Електронний ресурс] – 2024 – С. 1–36 –
Режим доступу: https://dl.acm.org/doi/pdf/10.1145/3388922
30. Cloud Controls Matrix. CCM v4.0 Implementation Guidelines [Електронний
ресурс] – 2024 – С. 1–27 – Режим доступу:
https://cloudsecurityalliance.org/artifacts/ccm-v4-0-implementation-guidelines
31. Consensus Assessments. STAR Level 1: Security Questionnaire (CAIQ v4)
[Електронний ресурс] – Режим доступу:
https://cloudsecurityalliance.org/artifacts/star-level-1-security-questionnaire-caiq-v4
32. Microsoft Azure. Consensus Assessments Initiative Questionnaire v4.0.2
[Електронний ресурс] – Режим доступу:
https://cloudsecurityalliance.org/star/registry/microsoft/services/microsoft-azure
33. Google Cloud Platform. Consensus Assessments Initiative Questionnaire v4.0.2
[Електронний ресурс] – Режим доступу:
https://cloudsecurityalliance.org/star/registry/google/services/google-cloud
34. Oracle Cloud Infrastructure. Consensus Assessments Initiative Questionnaire
v4.0.2 [Електронний ресурс] – Режим доступу:
https://cloudsecurityalliance.org/star/registry/oracle-corporation/services/oracle-
cloud-infrastructure
116
35. Amazon Web Services. Consensus Assessments Initiative Questionnaire v4.0.2
[Електронний ресурс] – Режим доступу:
https://cloudsecurityalliance.org/star/registry/amazon/services/amazon-web-services