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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Застосування централізації даних та ідентичності

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

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

Вимога безпеки перш за все

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

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

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

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

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

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

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

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

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

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