Борючись з безпекою хмари? Як модель спільної відповідальності може допомогти

Перехід оперативних елементів у хмару може бути великим кроком вперед для бізнесу. Це дозволяє їм швидко масштабувати свої програми та послуги, зберігаючи свою організацію гнучкою у відповідь на зміну ринкових вимог.

Однак, збільшення прийняття хмари також може додати певний рівень плутанини щодо того, хто відповідає за управління безпекою даних. На жаль, багато бізнесів припускають, що коли дані клієнтів знаходяться поза їхньою владою, вони не несуть відповідальності за те, чи захищені вони. Але це небезпечне припущення.

Модель спільної відповідальності (SRM) була введена, щоб допомогти бізнесу та їхнім постачальникам хмарних послуг провести більш точні лінії щодо відповідальності за безпеку в цифрових середовищах. Нижче ми намалюємо яснішу картину того, як ця модель побудована і як вона може допомогти вам посилити безпеку вашого бізнесу.

Що таке модель спільної відповідальності (SRM)?

Є багато причин, чому бізнес вирішує перемістити частини або всю свою діяльність у хмару. Не потрібно налаштовувати сервери та бази даних або інші інфраструктурні елементи вручну, що може допомогти компаніям зменшити свої витрати та зменшити навантаження на їхні внутрішні команди. Однак бізнес іноді забуває, що вивантаження “управління” цієї інфраструктури не означає вивантаження “відповідальності” за дані, що зберігаються там.

SRM розділяє відповідальність між постачальником хмарних послуг (CSP) та бізнесом, з яким він співпрацює. Вона фактично описує, які аспекти безпеки належать кожній стороні, і як заходи безпеки повинні бути реалізовані та впроваджені на кожній стороні відносин.

Розуміння “У хмарі” проти “Хмара”

SRM побудована навколо положень щодо двох ключових термінів: У ХМАРІ та ХМАРА.

Коли ми говоримо про вимоги У ХМАРІ, ми говоримо про те, що постачальники хмарних послуг беруть на себе відповідальність. У цьому випадку ви можете подумати про постачальника хмарних послуг як про домовласника в квартирному комплексі. Вони відповідають за загальну безпеку будівель, яка включає в себе різні засоби безпеки, захищені ворота та протоколи входу, а також забезпечення роботи ключових комунальних послуг, таких як водопостачання та електричні системи.

У хмарних середовищах це означає встановлення та підтримку всіх мережевих пристроїв та вирішення будь-яких основних вимог обслуговування для забезпечення безперебійного функціонування середовищ.

Як клієнт хмари, ви відповідаєте за елементи У ХМАРІ. Наприклад, якщо ви зберігали інформацію в хмарі, ви завжди маєте певний рівень відповідальності за її безпеку. Хоча це не обов’язково означає, що ВСЯ відповідальність лежить на вас за її безпеку, ви все ж таки відповідаєте за речі, такі як управління ідентифікацією та доступом (IAM), безпека програми та зміцнення мережі.

Слизька шкала відповідальності

Через динамічну природу більшості хмарних середовищ та їхніх відносин з постачальниками хмарних послуг SRM працює на слизькій шкалі, з відповідальністю, що зсувається до певної міри залежно від типу робочих відносин. Нижче наведені три загальні моделі хмари та те, як вони відрізняються один від одного:

• Інфраструктура як послуга (IaaS): ця модель залишає постачальників хмарних послуг відповідальними за забезпечення безпеки певних основних компонентів хмари. Це включає в себе фізичні центри даних, сервери, апаратне забезпечення схову та рівень віртуалізації. Клієнти хмари відповідають за все, що знаходиться вище цього рівня, включаючи безпеку гостинної операційної системи (OS), управління всією середньою ланкою та час виконання, а також захист програмного коду та даних, що містяться в ньому.
• Платформа як послуга (PaaS): ця модель розширює більше відповідальності до постачальника хмарних послуг, який бере на себе управління операційними системами, системами баз даних або середовищами виконання. Вони також піклуватимуться про будь-яке обслуговування платформи. Для бізнесу це може суттєво зменшити навантаження на управління інфраструктурою, дозволяючи їм зосередитися більше на управлінні та забезпеченні безпеки програм.
• Програмне забезпечення як послуга (SaaS): ця модель є найбільш беззаботною формою для користувачів хмари, оскільки вона передає повну відповідальність за інфраструктуру до постачальника хмарних послуг. Однак це не означає, що відповідальність за безпеку повністю передається. Користувачі хмари все ж таки відповідають за управління доступом користувачів, дозволами та налаштуваннями безпеки на рівні адміністратора.

Чому розуміння SRM важливо

Видалення двозначності

Хоча багато організацій вважають, що їхня найбільша загроза для безпеки хмари є кібератакою, недорозуміння та неправильне тлумачення у відносинах хмари також є проблемою.

Якщо постачальники хмарних послуг та їхні клієнти неправильно припускають, що інша сторона займається певними завданнями безпеки, це може привести до серйозних уразливостей даних клієнтів. Розуміння SRM допомагає ліквідувати цю двозначність, надаючи обом сторонам більшу прозорість при створенні угод про рівень послуг (SLA) та виконанні взаємних вимог.

Уникання пастки надмірної делегації

Багато бізнесів, які нові у хмарних середовищах, помиляються щодо того, як працюють відповідальності у хмарі. Через те, що вони платять за “послугу”, часто припускається, що постачальник хмарних послуг займається всім від імені бізнесу.

Однак, коли мова йде про безпеку хмари, ви не хочете потрапити в пастку надмірної делегації, особливо щодо адміністративних засобів контролю безпеки, які ваш постачальник хмарних послуг встановив. SRM допомагає зберігати ці відповідальності в перспективі та утримує бізнес активно зайнятим у впровадженні політики захисту даних.

Закриття пробілів у відповідності

Розуміння стандартів безпеки відповідності іноді може стати нечітким для бізнесу, який вступає у хмарні середовища. Хоча всі постачальники хмарних послуг мають відповідальність за дотримання конкретних khungів відповідності, клієнт хмари також має відповідальність у цій сфері.

SRM описує відповідальність постачальників хмарних послуг щодо управління інфраструктурою, залишаючи клієнтів хмари відповідальними за те, як програми та послуги будуються та працюють, особливо щодо схову та доступу до даних клієнтів.

Як модель спільної відповідальності може допомогти покращити вашу безпеку

Кларифікація власності та попередження недорозумінь

Кожне завдання безпеки у ваших внутрішніх та зовнішніх середовищах повинно мати чітко встановлену безпеку власності. SRM робить це набагато легше для видалення будь-яких сірих зон щодо того, хто займається якою відповідальністю, і дозволяє вам розробити послідовне управління всередині та з постачальниками хмарних послуг.

Мати офіційну документацію щодо готовності до безпеки допомагає зменшити кількість уразливостей, які можуть бути використані через пов’язані програми та послуги, і ліквідує планування безпеки на основі припущень.

Оптимізація внутрішніх ресурсів безпеки

Розуміння ролі, яку постачальники хмарних послуг відіграють у управлінні інфраструктурою безпеки, робить його легшим для того, щоб ваші команди безпеки зосередилися на тих областях, які найбільш важливі для бізнесу.

Це дозволяє вам передати ресурсоємкі процеси, такі як патчування серверів або управління базами даних, до вашого постачальника хмарних послуг, що дозволяє вашим командам зосередитися більше на безпеці програмного коду, розробці та впровадженні нових політик доступу користувачів.

Застосування центральності даних та ідентифікації

Компоненти хмарної інфраструктури завжди можуть бути замінені під час порушення даних, але ваша фінансовая стабільність та репутація бізнесу можуть зазнати незворотного пошкодження під час такого самого інциденту.

Застосування SRM допомагає бізнесу менше покладатися на постачальника хмарних послуг для забезпечення безпеки та більше часу на розробку важливих принципів безпеки, які можуть бути застосовані до адміністраторів та інших ключових зацікавлених осіб у організації.

Вимога безпеки-першої конфігурації

Більшість нових хмарних послуг пропонують кілька налаштувань для безпеки хмари. Однак відсутність інформації щодо уразливостей конфігурації хмари може привести до суттєвих ризиків безпеки в майбутньому.

SRM допомагає бізнесу зосередитися на безпеці-першій конфігурації, надавши пріоритет промисловій відповідності над швидкістю та зручністю. Багато khungів безпеки зараз побудовані навколо політик SRM, забезпечуючи те, що нові конфігурації віртуальних машин або баз даних відповідають суворим вимогам до розгортання.

Крім того, послуги зовнішнього тестування на проникнення розроблені для розуміння вимог SRM під час проведення активних оцінок уразливостей, щоб побачити, як бізнес виконує свої відповідні обов’язки. Використання цих послуг може допомогти організаціям тестирувати свою безпеку, політики IAM, методи шифрування даних, щоб забезпечити відповідність найкращим промисловим стандартам.

Повышення видимості через аудит логування

Через те, що SRM зазвичай передбачає співпрацю та прозорість між постачальниками хмарних послуг та їхніми клієнтами, це допомагає тримати всіх більш обізнаними про ефективність їхньої зміцнення безпеки.

Аудит безпеки та активне моніторинг є обома важливими елементами виконання політики SRM як для постачальників хмарних послуг, так і для клієнтів хмари. Тепер є багато хмарних та сторонніх інструментів, доступних для бізнесу, щоб контролювати загальну міцність їхньої безпеки хмари та швидко та ефективно реагувати на нові ризики безпеки.

Все це означає більш проактивне планування безпеки для всіх, допомагаючи зменшити кількість інцидентів безпеки, які відбуваються, та зменшуючи ризики витоку даних.

Зробіть безпеку хмари вашим пріоритетом

Розгляд моделі спільної відповідальності як ключової частини вашої стратегії є критично важливим, оскільки ваш бізнес зростає.

Розуміння та визнання вашої ролі у безпеці хмари допомагає вам уникнути небезпечних припущень щодо відповідальності та більш активно займатися забезпеченням безпеки всіх ваших цифрових поверхонь атаки.