РОЗДІЛ І РОЗРОБКА АЛГОРИТМУ БЕЗПЕЧНОГО

РОЗГОРТАННЯ ХМАРНИХ СЕРВІСІВ

2.1 Аналіз ризиків безпеки при використанні хмарних
технологій
Багато експертів застерігають від надмірного покладання на заяви
постачальників щодо безпеки хмарних обчислень, оскільки поширена
думка, що споживач хмарних послуг має рівень безпеки в хмарному
середовищі, який забезпечує постачальник.
У США Cloud Security Alliance випустив Cloud Controls Matrix. Цей
документ є переліком існуючих технологій захисту інформації, які можна
використовувати в хмарних сервісах.
Хоча деякі експерти вважають, що стандарти ISO 27001 і ISO 27002
можна використовувати для управління інформаційною безпекою при
побудові хмари SaaS, все ж необхідно розробити спеціальні стандарти для
хмарних обчислень.
Для хмарних середовищ загрози віддаленого злому та зараження
шкідливим кодом дуже значні через паралельне існування багатьох
віртуальних машин.
Особливістю віртуальної машини, яку необхідно враховувати, є
можливість її зараження в вимкненому стані, якщо доступ до сховища
образів віртуальної машини здійснюється через Інтернет.
Тому особливу увагу слід приділити політикам приватної безпеки,
особливо політикам розмежування доступу, інформаційних систем,
побудованих на основі технологій хмарних обчислень.
Варто також зазначити, що спеціалізовані засоби забезпечення
інформаційної безпеки, які використовуються в сучасних інформаційних
системах, знижують ефективність і швидкість обробки клієнтської
інформації в хмарі, а продукти хмарної безпеки, які допомагають подолати
цю проблему, наразі не сертифіковані в нашій країні. . Інформаційна
безпека повинна бути забезпечена по всьому ланцюжку, включаючи
постачальника хмарного рішення, споживача та тих, хто з’єднує їх зв’язок.
Споживач хмарних послуг зобов’язаний запровадити відповідну політику
безпеки у своїй системі, яка виключає передачу прав доступу до
інформацію, надану постачальником третім особам. Хмари не усувають
необхідності розробляти та впроваджувати політику безпеки в
споживчому сегменті та використовувати служби безпеки, призначені для
гарантування захисту робочих місць, призначених для користувача на
стороні споживача хмарних сервісів.
Відсутність контролю
Передавши свої особисті дані системі, керованій провайдером
хмари, клієнти більше не можуть мати винятковий контроль цих даних і
не можуть вжити будь-яких технічних та організаційних заходів,
необхідних для забезпечення доступності, цілісності, конфіденційності,
прозорості, ізоляції, сумісності та захисту від втручання.
Це відсутність контролю може проявлятися в такий спосіб:
− Недоступність через відсутність взаємодії: якщо постачальник
хмари спирається на патентовану технологію, то може виявитися
скрутним для клієнта переміщати дані та документи між різними
хмарними системами (перенесення даних) або для обміну інформацією з
особами, які використовують хмарні послуги інших постачальників
(функціональна сумісність).
− Відсутність цілісності викликана через спільне використання
ресурсів: хмари складаються із загальних систем та інфраструктур. Хмара
постачальника обробляє персональні дані, що надходять із широкого кола
джерел. І з погляду даних суб'єктів та організацій може статися конфлікт
інтересів або виникнути неясність мети.
 − Відсутність конфіденційності, а саме у запитах поліції
безпосередньо до постачальнику хмари: особисті дані, що обробляються у
хмарі, можуть бути запитані від правоохоронців. Існує ризик того, що
особисті дані можуть бути розкриті представниками правоохоронних
органів без поважної та законної основи.
− Відсутність здатності втручання через складність та динаміку
ланцюга аутсорсингу: хмарні сервіси, що пропонуються одним
постачальником, можуть виготовлятися шляхом комбінування послуг з
інших хмарних провайдерів, обчислень, які можуть бути динамічно додані
або видалені в процесі договору клієнта.
− Відсутність здатності втрутитися: провайдер хмари не може
забезпечити необхідними заходами та інструментами для надання
допомоги контролеру керування даними, наприклад, доступ, видалення
або виправлення даних.
− Відсутність ізоляції: хмарні послуги можуть використовувати свій
фізичний контроль над даними різних клієнтів та зв'язати персональні
дані. Якщо адміністратори мали достатні привілейовані права доступу (з
високим ступенем ризику ролей) вони могли б взяти це під контроль.
Відсутність прозорості
Недостатня прозорість операцій хмарного сервісу під час обробки
Інформація представляє небезпеку для контролерів. А також для суб'єктів
даних, тому що вони не можуть знати про потенційні загрози та ризики, і
тому не можуть вжити заходів, які вони вважатимуть необхідними.
Деякі потенційні загрози можуть виникати в контролері через те,
що:
− Технологічний ланцюжок проходить за участю кількох процесорів
та субпідрядників.
− Особисті дані обробляються у різних географічних районах. Це
безпосередньо впливає на права, що застосовуються до будь-яких
суперечок щодо захисту даних, які можуть виникнути між користувачем
та постачальником.
Неправильна конфігурація
Неправильна конфігурація параметрів безпеки хмари є основною
причиною витоку хмарних даних. Стратегії керування хмарною безпекою
багатьох організацій недостатні для захисту їх хмарної інфраструктури.
Цьому сприяє кілька факторів. Хмарна інфраструктура розроблена
таким чином, щоб її можна було легко використовувати та надавати
можливість легкого обміну даними, що ускладнює організаціям
забезпечення доступу до даних лише авторизованим сторонам. Крім того,
організації, які використовують хмарну інфраструктуру, також не мають
повної видимості та контролю над своєю інфраструктурою, а це означає,
що вони повинні покладатися на елементи керування безпекою, які надає
їхній постачальник хмарних послуг (CSP), щоб налаштувати та захистити
свої хмарні розгортання. Оскільки багато організацій не знайомі з
захистом хмарної інфраструктури та часто мають багатохмарні
розгортання – кожне з різним набором засобів безпеки, наданих
постачальником, неправильна конфігурація або помилка безпеки можуть
легко залишити хмарні ресурси організації відкритими для зловмисників.
Несанкціонований доступ
На відміну від локальної інфраструктури організації, їх хмарні
розгортання знаходяться поза периметром мережі та доступні
безпосередньо з загальнодоступного Інтернету. Хоча це є активом для
доступності цієї інфраструктури для співробітників і клієнтів, це також
полегшує зловмиснику отримання несанкціонованого доступу до хмарних
ресурсів організації. Неправильно налаштований захист або
скомпрометовані облікові дані можуть дозволити зловмиснику отримати
прямий доступ, можливо, без відома організації.
Незахищені інтерфейси/API
 CSP часто надають своїм клієнтам низку інтерфейсів прикладного
програмування (API) та інтерфейсів. Загалом, ці інтерфейси добре
задокументовані, щоб зробити їх зручними для використання клієнтами
CSP.
Однак це створює потенційні проблеми, якщо клієнт належним
чином не захистив інтерфейси своєї хмарної інфраструктури.
Документація, розроблена для клієнта, також може бути використана
кіберзлочинцем для виявлення та використання потенційних методів
доступу та викрадання конфіденційних даних із хмарного середовища
організації.
Викрадення акаунтів
Багато людей мають надзвичайно слабкий захист паролів,
включаючи повторне використання паролів і використання слабких
паролів. Ця проблема посилює вплив фішингових атак і витоку даних,
оскільки дає змогу використовувати один викрадений пароль для кількох
різних облікових записів.
Викрадення облікових записів є однією з найсерйозніших проблем
безпеки в хмарі, оскільки організації все більше покладаються на хмарну
інфраструктуру та програми для основних бізнес-функцій. Зловмисник,
маючи облікові дані співробітника, може отримати доступ до
конфіденційних даних або функцій, а скомпрометовані облікові дані
клієнта дають повний контроль над їхнім обліковим записом в Інтернеті.
Крім того, у хмарі організаціям часто не вистачає можливості
ідентифікувати ці загрози та реагувати на них так само ефективно, як у
локальній інфраструктурі.
Відсутність видимості
Хмарні ресурси організації розташовані за межами корпоративної
мережі та працюють на інфраструктурі, якою компанія не володіє. Як
наслідок, багато традиційних інструментів для досягнення видимості
мережі неефективні для хмарних середовищ, а деяким організаціям бракує
інструментів безпеки, орієнтованих на хмару. Це може обмежити здатність
організації відстежувати свої хмарні ресурси та захищати їх від атак.
Зовнішній обмін даними
Хмара створена для полегшення обміну даними. Багато хмар
надають можливість явно запросити співавтора електронною поштою або
надіслати посилання, яке дає змогу будь-кому, хто має URL-адресу,
отримати доступ до спільного ресурсу.
Хоча цей простий обмін даними є перевагою, він також може бути
серйозною проблемою безпеки хмари. Використання спільного доступу на
основі посилань – популярного варіанту, оскільки це простіше, ніж явно
запросити кожного співавтора – ускладнює контроль доступу до спільного
ресурсу. Спільне посилання може бути передане комусь іншому,
викрадене під час кібератаки або здогадане кіберзлочинцем, що
забезпечить несанкціонований доступ до спільного ресурсу. Крім того,
обмін на основі посилань унеможливлює скасування доступу лише до
одного одержувача спільного посилання.
Зловмисні інсайдери
Внутрішні загрози є серйозною проблемою безпеки для будь-якої
організації. Зловмисник уже має авторизований доступ до мережі
організації та деяких конфіденційних ресурсів, які вона містить. Спроби
отримати такий рівень доступу – це те, що відкриває більшість
зловмисників до їхньої цілі, що ускладнює для непідготовленої організації
виявлення зловмисного інсайдера.
У хмарі виявити зловмисника ще складніше. Завдяки хмарному
розгортанню компаніям не вистачає контролю над базовою
інфраструктурою, що робить багато традиційних рішень безпеки менш
ефективними. Це, а також той факт, що хмарна інфраструктура доступна
безпосередньо з загальнодоступного Інтернету та часто страждає від
неправильних конфігурацій безпеки, ще більше ускладнює виявлення
зловмисників.
Кібератаки
Кіберзлочинність – це бізнес, і кіберзлочинці обирають свої цілі на
основі очікуваної прибутковості своїх атак. Хмарна інфраструктура
доступна безпосередньо з загальнодоступного Інтернету, часто
неналежним чином захищена та містить велику кількість конфіденційних і
цінних даних. Крім того, хмара використовується багатьма різними
компаніями, а це означає, що успішна атака може бути повторена багато
разів з високою ймовірністю успіху. Як наслідок, хмарні розгортання
організацій є звичайною метою кібератак.
Атаки на відмову в обслуговуванні
Хмара має важливе значення для ведення бізнесу багатьма
організаціями. Вони використовують хмару для зберігання важливих
бізнес-даних і запуску важливих внутрішніх і клієнтських програм.
Це означає, що успішна атака типу «відмова в обслуговуванні»
(DoS) проти хмарної інфраструктури, швидше за все, матиме серйозний
вплив на низку різних компаній. У результаті DoS-атаки, коли зловмисник
вимагає викуп, щоб зупинити атаку, становлять значну загрозу для
хмарних ресурсів організації.
Втрата/витік даних
Хмарні середовища дозволяють легко обмінюватися даними, що
зберігаються в них. Ці середовища доступні безпосередньо з
загальнодоступного Інтернету та включають можливість легко
обмінюватися даними з іншими сторонами через прямі запрошення
електронною поштою або шляхом спільного використання
загальнодоступного посилання на дані.
Простота обміну даними в хмарі – хоча це головний актив і ключ до
співпраці в хмарі – викликає серйозні занепокоєння щодо втрати або
витоку даних. Насправді 69% організацій вказують на це як на найбільшу
проблему безпеки хмарних технологій. Обмін даними за допомогою
загальнодоступних посилань або налаштування хмарного сховища на
загальнодоступне робить їх доступними для будь-кого, хто знає про
посилання, і існують спеціальні інструменти для пошуку в Інтернеті цих
незахищених хмарних розгортань.
Конфіденційність/конфіденційність даних
Конфіденційність і конфіденційність даних є основною проблемою
для багатьох організацій. Положення про захист даних, як-от Загальний
регламент ЄС щодо захисту даних (GDPR), Закон про мобільність і
доступність медичного страхування (HIPAA), Стандарт безпеки даних
індустрії платіжних карток (PCI DSS) та багато інших зобов’язують
захистити дані клієнтів і накладають суворі штрафи за збої безпеки. Крім
того, організації мають велику кількість внутрішніх даних, необхідних для
збереження конкурентної переваги.
Розміщення цих даних у хмарі має свої переваги, але також створює
серйозні проблеми з безпекою для 66% організацій. Багато організацій
запровадили хмарні обчислення, але їм не вистачає знань, щоб
переконатися, що вони та їхні співробітники використовують їх безпечно.
У результаті конфіденційні дані знаходяться під загрозою розголошення,
про що свідчить величезна кількість порушень хмарних даних.
Випадкове розкриття облікових даних
Фішери зазвичай використовують хмарні програми та середовища як
привід для своїх фішингових атак. Зі зростанням використання хмарної
електронної пошти (G-Suite, Microsoft 365 тощо) і служб обміну
документами (Google Drive, Dropbox, OneDrive) співробітники звикли
отримувати електронні листи з посиланнями, які можуть попросити їх
підтвердити обліковий запис. облікові дані, перш ніж отримати доступ до
певного документа або веб-сайту.
 Це дозволяє кіберзлочинцям легко дізнатися облікові дані
співробітника для хмарних сервісів. У результаті випадкове відкриття
хмарних облікових даних викликає серйозне занепокоєння для 44%
організацій, оскільки це потенційно ставить під загрозу конфіденційність і
безпеку їхніх хмарних даних та інших ресурсів.
Реагування на інцидент
Багато організацій мають стратегії реагування на внутрішні
інциденти кібербезпеки. Оскільки організація володіє всією внутрішньою
мережевою інфраструктурою, а персонал служби безпеки працює на місці,
можна заблокувати інцидент. Крім того, це право власності на їх
інфраструктуру означає, що компанія, ймовірно, має видимість, необхідну
для визначення масштабу інциденту та виконання відповідних дій з
усунення.
Завдяки хмарній інфраструктурі компанія має лише часткову
видимість і право власності на свою інфраструктуру, що робить традиційні
процеси та інструменти безпеки неефективними. У результаті 44%
компаній стурбовані своєю здатністю ефективно реагувати на інциденти в
хмарі.
Відповідність законодавству та нормам
Правила захисту даних, такі як PCI DSS і HIPAA, вимагають від
організацій продемонструвати, що вони обмежують доступ до захищеної
інформації (даних кредитних карток, медичних записів пацієнтів тощо).
Це може вимагати створення фізично або логічно ізольованої частини
мережі організації, яка буде доступна лише для працівників, які мають
законну потребу в доступі до цих даних.
Під час переміщення даних, захищених цими та подібними
правилами, у хмару досягти та продемонструвати відповідність
нормативним вимогам може бути складніше. Завдяки хмарному
розгортанню організації мають можливість переглядати та контролювати
лише деякі рівні своєї інфраструктури. Як наслідок, 42% організацій
вважають відповідність законодавству та нормативним вимогам основною
проблемою безпеки хмари та потребують спеціалізованих рішень
відповідності хмарі.
Суверенітет даних/перебування/контроль
Більшість хмарних провайдерів мають кілька територіально
розподілених центрів обробки даних. Це допомагає підвищити
доступність і продуктивність хмарних ресурсів і полегшує для
постачальників послуг гарантування того, що вони здатні підтримувати
угоди про рівень обслуговування в умовах руйнівних подій, таких як
стихійні лиха, відключення електроенергії тощо.
Організації, які зберігають свої дані в хмарі, часто не знають, де
насправді зберігаються їхні дані в масиві центрів обробки даних CSP. Це
викликає серйозні занепокоєння щодо суверенітету даних, місця
проживання та контролю для 37% організацій. З нормативними актами
щодо захисту даних, такими як GDPR, які обмежують, куди можна
надсилати дані громадян ЄС, використання хмарної платформи з центрами
обробки даних за межами затверджених зон може привести організацію до
стану невідповідності нормативним вимогам. Крім того, різні юрисдикції
мають різні закони щодо доступу до даних для правозастосування та
національна безпека, що може вплинути на конфіденційність даних і
безпеку клієнтів організації.
Захист хмари
Хмара надає організаціям ряд переваг; однак він також має свої
власні загрози безпеці та проблеми. Хмарна інфраструктура дуже
відрізняється від локального центру обробки даних, і традиційні
інструменти та стратегії безпеки не завжди здатні ефективно захистити її.
Щоб отримати додаткові відомості про головні проблеми та загрози
безпеки в хмарі, завантажте звіт про безпеку в хмарі.
 2.2 Розгляд методів та способів для мінімізації ризиків

Погане управління доступом

Керування доступом є одним із найпоширеніших ризиків безпеки
хмарних обчислень. Точка доступу є ключем до всього. Ось чому хакери
так сильно націлюються на нього.
У 2016 році в LinkedIn стався масовий злам даних користувачів,
включаючи облікові дані (приблизно 164 мільйони).
Причинами були:
 недостатній антикризовий менеджмент
 неефективна інформаційна кампанія
 хитрість хакерів
 У результаті деякі облікові записи було зламано, і це
викликало серйозну полювання на їхніх системних адміністраторів у
найближчі місяці.
Ось ще один приклад хмарних загроз безпеки. Стало відомо, що
Facebook і Google зберігають паролі користувачів у відкритому вигляді.
Незважаючи на те, що витоків не було, ця практика майже призвела до
деяких.
Це лише деякі з багатьох прикладів.
Отже, як вирішити цю проблему?
Багатофакторна автентифікація є критично важливим компонентом
безпеки з боку користувача. Це додає рівень доступу до системи. Окрім
звичайного пароля, користувач отримує одноразовий ключ на приватному
пристрої. Обліковий запис блокується, а користувачеві надсилається
сповіщення про спробу злому.
Окремий макет для керування доступом на стороні обслуговування.
Таке розташування означає визначення доступності інформації для різних
типів користувачів. Наприклад, відділу маркетингу не потрібно мати
доступ до протоколів відділу забезпечення якості, і навпаки.
AWS який ми будемо використовувати має широкий функціонал для
налаштування безпекових груп, але основна проблема у більшості
випадків, це досить складне налаштування для звичайних розробників,
Яке тісно зв’язане з мережевими налаштуваннями. Схематичне
зображення місця безпекових груп відносно мережевих налаштувань.

Порушення даних і витік даних – основні проблеми безпеки хмари

Ризик безпеки хмари, пов’язаний із порушенням даних, є причинно-
наслідковим фактором. Якщо витік даних стався, це означає, що компанія
знехтувала деякими недоліками безпеки хмари, і це спричинило
природний наслідок.
Що таке порушення даних?
 Це нещасний випадок, коли доступ до інформації та її вилучення
здійснюється без дозволу. Ця подія зазвичай призводить до витоку даних
(також даних, розташованих там, де вони не повинні бути).
Конфіденційна інформація може бути відкритою для громадськості,
але зазвичай її продають на чорному ринку або зберігають за викуп.
У той час як масштаб наслідків залежить від навичок управління
кризою конкретної компанії, сама подія є плямою на репутації компанії.
Інформація в хмарному сховищі має кілька рівнів доступу. Ви не
можете просто наштовхнутися на це за звичайних обставин. Однак він
доступний з різних пристроїв і облікових записів з криптографічними
ключами. Іншими словами, хакер може проникнути в нього, якщо він знає
когось, хто має до нього доступ.
Ось як може закінчитися операція з витоку даних:
Все починається з того, що хакер вивчає структуру компанії на
предмет слабких місць (так званих експлойтів). Цей процес включає як
людей, так і технології.
Виявивши жертву, хакер знаходить спосіб підійти до цільової особи.
Ця операція включає виявлення акаунтів у соціальних мережах, інтересів і
можливих недоліків особи.
Після цього жертву обманом вимагають отримати доступ до мережі
компанії. Є два способи зробити це:
Технологічно через зловмисне програмне забезпечення, потайки
встановлене на комп’ютері жертви;
Соціальна інженерія шляхом завоювання довіри та переконання
когось надати свої облікові дані для входу;
Ось як кіберзлочинець використовує загрозу безпеці в хмарних
обчисленнях, отримує доступ до системи та витягує дані.
Найпомітнішим останнім витоком даних є той, що стався в Equifax у
2017 році. Це призвело до витоку персональних даних понад 143 мільйонів
споживачів. чому Розробники Equifax не оновили програмне забезпечення,
щоб усунути повідомлену вразливість. Цим скористалися хакери, і злам
стався.
Як уникнути витоку даних?
Хмарна система безпеки повинна мати багаторівневий підхід, який
перевіряє та охоплює весь обсяг активності користувачів на кожному
кроці. Ця практика включає:
Багатофакторна автентифікація - користувач повинен надати більше
ніж докази своєї особи та облікові дані доступу. Наприклад, введення
пароля, а потім отримання сповіщення на мобільний телефон із випадково
згенерованим рядком одноразових цифр, активним протягом короткого
періоду часу. Сьогодні це стало одним із стандартів хмарної безпеки.
Шифрування даних у стані спокою. Дані в спокої – це тип даних, які
зберігаються в системі, але не використовуються активно на різних
пристроях. Цей процес включає журнали, бази даних, набори даних тощо.
Брандмауер периметра між приватною та публічною мережами, який
контролює вхідний і вихідний трафік у системі;
Внутрішній брандмауер для моніторингу авторизованого трафіку та
виявлення аномалій;
Для AWS ці налаштування мають такий вигляд:
 Втрата даних
Якщо порушення даних було недостатньо серйозним, існує ще гірша
загроза безпеці хмари – вона може бути безповоротно втрачена, як сльози
під дощем. Втрата даних є одним із ризиків хмарної безпеки, який важко
передбачити, а ще важче впоратися.
Давайте розглянемо три найпоширеніші причини втрати даних:
Зміна даних - коли інформація якимось чином змінена і не може
бути повернута до попереднього стану. Ця проблема може виникнути з
динамічними базами даних.
Ненадійний збій носія інформації – коли дані втрачаються через проблеми
на стороні постачальника хмарних послуг.
Видалення даних — тобто випадкове чи неправомірне видалення
інформації із системи без резервних копій для відновлення. Зазвичай
причиною є людська помилка, безладна структура бази даних, системний
збій або зловмисний намір.
Втрата доступу - коли інформація все ще знаходиться в системі, але
недоступна через відсутність ключів шифрування та інших облікових
даних (наприклад, дані особистого облікового запису)
 Як запобігти втраті даних?
Резервні копії.
Часте резервне копіювання даних є найефективнішим способом
уникнути втрати даних у більшості їх форм. Вам потрібен розклад операції
та чітке визначення того, які дані придатні для резервного копіювання, а
які ні. Використовуйте програмне забезпечення для запобігання втраті
даних, щоб автоматизувати процес.
Георізноманіття — тобто коли фізичне розташування хмарних
серверів у центрах обробки даних розкидане й не залежить від
конкретного місця. Ця функція допомагає впоратися з наслідками
стихійних лих і відключень електроенергії.
Одним із найганебніших прикладів втрати даних є нещодавня
катастрофа MySpace.
Це призвело до 12 років активності користувачів і втрати
завантаженого вмісту. Ось що сталося. Під час процесу міграції в хмару в
2015 році виявилося, що через пошкодження даних було втрачено значну
кількість даних користувача (включаючи завантажені медіафайли, як-от
зображення та музику). Оскільки MySpace не робив резервні копії, не було
можливості відновити його. Коли користувачі почали задавати питання, в
службі підтримки сказали, що компанія працює над проблемою, і через
пару місяців правда розкрилася.
Важливість на потрібність резервного копіювання вже неодноразово
доведена та підкреслена, але, підкреслюючи актуальність магістерської
роботи, налаштування бекапів для малого та середнього бізнесу дорога та
складна робота, яка потребує окремих спеціалістів. Момент з
бекапуванням можна вирішити через автоматизацію налаштування цього
процесу з Terraform.
Незахищений API
 Інтерфейс користувача програми (він же API) є основним
інструментом, який використовується для роботи системи в хмарній
інфраструктурі.
Цей процес включає внутрішнє використання співробітниками
компанії та зовнішнє використання споживачами через такі продукти, як
мобільні або веб-додатки. Зовнішня сторона має вирішальне значення,
оскільки передача всіх даних забезпечує роботу служби та, натомість,
надає всі види аналітики. Доступність API створює значний ризик безпеки
хмари. Крім того, API бере участь у зборі даних із периферійних
обчислювальних пристроїв.
Багатофакторна автентифікація та шифрування є двома важливими
факторами, які забезпечують регуляцію системи та її захист від
пошкоджень.
Однак іноді конфігурація API не відповідає вимогам і містить
серйозні недоліки, які можуть поставити під загрозу його цілісність.
Найпоширеніші проблеми, які виникають:
Анонімний доступ (тобто доступ без автентифікації)
Відсутність контролю доступу (також може виникнути через
недбалість)
Багаторазові токени та паролі (часто використовуються в атаках
грубою силою)
Автентифікація з відкритим текстом (коли ви бачите введені дані на
екрані)
Найбільш яскравим прикладом незахищеного API в дії є скандал із
Cambridge Analytica. Facebook API мав глибокий доступ до даних
користувачів, і Cambridge Analytica використовувала його для власної
вигоди.
Як уникнути проблем з API?
Є кілька способів:
  Тестування на проникнення, яке імітує зовнішню атаку,
націлену на конкретні кінцеві точки API, намагається
порушити безпеку та отримати доступ до внутрішньої
інформації компанії.
 Загальні аудити безпеки системи
 Secure Socket Layer/Transport Layer Безпека шифрування для
передачі даних
 Багатофакторна автентифікація для запобігання
несанкціонованому доступу через порушення безпеки.
У нашому випадку ми зосередимось на останньому варіанті
боротьби з захистом API.
Неправильно налаштоване хмарне сховище
Неправильно налаштоване хмарне сховище є продовженням
небезпечної хмарної загрози безпеки API. Здебільшого проблеми з
безпекою хмарних обчислень виникають через недогляд і подальші
поверхневі перевірки.
Ось що відбувається.
Неправильна конфігурація хмари – це параметр для хмарних
серверів (для зберігання чи обчислень), який робить його вразливим до
злому.
Найпоширеніші типи неправильної конфігурації включають:
Хмарні налаштування безпеки сервера за замовчуванням зі
стандартним керуванням доступом і доступністю даних;
Невідповідне керування доступом – коли неавторизована особа
ненавмисно отримує доступ до конфіденційних даних;
Спотворений доступ до даних – коли конфіденційні дані
залишаються відкритими та не потребують авторизації.
 Хорошим прикладом неправильної конфігурації хмари є нещодавня
аварія Агентства національної безпеки. Схованка захищених документів
була доступна для перевірки із зовнішнього браузера.
Ось як цього уникнути.
Ретельно налаштування конфігурації хмарної безпеки під час
налаштування певного хмарного сервера. Хоча це здається очевидним,
його пропускають заради більш важливих речей, таких як зберігання
речей, не замислюючись про їх безпеку.
DoS-атака – атака типу «відмова в обслуговуванні».
Масштабованість є однією з значних переваг переходу на хмару.
Система може нести значне навантаження.
Але це не означає, що він може впоратися з більш несподіваним. Він
може перевантажитися і перестати працювати. Це серйозна загроза безпеці
хмари.
Іноді метою є не проникнути в систему, а зробити її непридатною
для клієнтів. Це називається атакою на відмову в обслуговуванні. По суті,
DoS - це старомодна система перевантаження з ракетним ранцем на задній
панелі.
Мета атаки на відмову в обслуговуванні — запобігти доступу
користувачів до додатків або порушити їхній робочий процес.
DoS — це спосіб порушити угоду про рівень обслуговування (SLA)
між компанією та клієнтом. Це втручання призводить до шкоди довірі до
компанії. Справа в тому, що однією з вимог SLA є якість послуги та її
доступність.
Відмова в обслуговуванні кладе цьому край.
Існує два основних типи DoS-атак:
Атака грубою силою з кількох джерел (класичний DDoS),
 Більш складні атаки, націлені на конкретні експлойти системи
(наприклад, візуалізація зображень, потокове передавання каналів або
доставка вмісту)
Під час DoS-атаки системні ресурси вичерпуються. Відсутність
ресурсів для масштабування спричиняє численні проблеми зі швидкістю
та стабільністю. Іноді це означає, що програма працює повільно або
просто не завантажується належним чином. Для користувачів це виглядає
як застрягти в пробці. Для компанії це завдання виявити та ліквідувати
джерела збою, а також збільшити витрати на збільшення використання
ресурсів.
Атака Sony PlayStation Network у 2014 році є одним із
найяскравіших прикладів атак типу «відмова в обслуговуванні». Він
спрямований на те, щоб розчарувати споживачів, виводячи з ладу систему
грубою силою та утримуючи її майже день.