Урок 1 з 4 · 8 хв

Модель спільної відповідальності

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

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

Дві сторони однієї межі

Amazon Web Services називає свою версію цього поділу моделлю спільної відповідальності, розділяючи її на «безпеку самої хмари» та «безпеку в хмарі». AWS відповідає за перше: «апаратне забезпечення, програмне забезпечення, мережі та приміщення, що забезпечують роботу хмарних сервісів AWS» — фізичні дата-центри, оновлення інфраструктури, ті частини, які ви ніколи не змогли б перевірити чи налаштувати самостійно, навіть якби захотіли. Клієнт відповідає за друге, і AWS чітко вказує, що це включає для сервісів хмарного зберігання: «керування своїми даними (включно з параметрами шифрування), класифікацію своїх ресурсів і використання інструментів IAM» — тобто того, хто має право до них доступ.

Межа зміщується залежно від того, що ви використовуєте

Документація Microsoft наголошує на важливій деталі для кожного, хто обирає між різними типами хмарних сервісів: розділова лінія не фіксована, вона зміщується залежно від моделі сервісу. Її таблиця відповідальності перелічує дані клієнта, ідентичності облікових записів і керування доступом як завжди обов’язок клієнта, у кожній моделі, локально чи в хмарі. Але в міру переходу від інфраструктури як сервісу (оренда віртуальної машини, яку ви налаштовуєте самі) до програмного забезпечення як сервісу (використання готового застосунку на кшталт пошти чи сервісу спільного доступу до файлів) Microsoft бере на себе більше: операційні системи, код застосунку та налаштування мережі дедалі більше стають обов’язком Microsoft, а не вашим. Що ніколи не зміщується, за словами самої Microsoft, — це те, що «ви завжди зберігаєте» відповідальність за свої дані, свої облікові записи, свої клієнтські пристрої та свій контроль доступу.

Завжди обов’язок клієнта (за Microsoft)	Залежить від моделі сервісу
Ваші дані: класифікація, захист, вибір шифрування	Хто керує операційною системою (ви — в IaaS; провайдер — здебільшого в SaaS)
Ідентичності та облікові записи користувачів	Засоби контролю мережевої безпеки
Клієнтські пристрої (ноутбуки, телефони), що звертаються до сервісу	Налаштування та код на рівні застосунку
Керування доступом: хто може дістатися до чого і з якими правами	Фізична інфраструктура (завжди обов’язок провайдера, щойно ви в будь-якій хмарній моделі)

Чому бік клієнта важить більше, ніж здається

Для громадської організації, що використовує готовий сервіс спільного доступу до файлів чи пошти — програмне забезпечення як сервіс, модель, де провайдер бере на себе найбільше, — виникає спокуса вважати, що безпека провайдера тепер уся історія. Це не так. Бік лінії провайдера (його сервери, його мережа, його оновлення) зазвичай чудовий для великих сервісів; саме тому зловмисники рідко намагаються атакувати його напряму. Натомість вони цілять у бік клієнта: слабкий чи повторно використаний пароль, посилання, поширене ширше, ніж мало бути, обліковий запис без другого фактора. Кожна категорія зі списку «завжди обов’язок клієнта» вище також, не випадково, є темою наступного заняття цього курсу.

Питання, яке варто ставити про будь-який хмарний сервіс, яким ви користуєтесь

Перш ніж довіряти хмарному сервісу чутливі матеріали, варто знайти його власну документацію про спільну відповідальність (усі великі провайдери її публікують) і поставити два запитання: що провайдер фактично захищає за замовчуванням, і що явно залишено мені? Відповідь зазвичай чітко показує, від яких саме ваших власних звичок — розглянутих у решті цього курсу — насправді залежить безпека цих даних.

Головне

Хмарні провайдери забезпечують безпеку інфраструктури («безпека хмари»); клієнти забезпечують безпеку власних даних, ідентичностей і доступу («безпека в хмарі»).
Точна межа зміщується залежно від моделі сервісу: чим готовіший сервіс (SaaS проти IaaS), тим більше бере на себе провайдер.
Ваші дані, ваші облікові записи, ваші пристрої та ваш контроль доступу залишаються вашою відповідальністю в кожній хмарній моделі, за власною документацією Microsoft.
Більшість реальних інцидентів у хмарі трапляється на боці клієнта — слабкі паролі, надто широко поширені посилання, відсутня багатофакторна автентифікація, — а не через злам інфраструктури провайдера.
Кожен великий провайдер публікує власну документацію про спільну відповідальність; читання її для сервісу, яким ви користуєтесь, проясняє, що саме вам ще треба захищати.

Перевірте себе

1. У моделі спільної відповідальності AWS, що означає «безпека самої хмари»?
- Паролі та налаштування облікового запису клієнта
- Власна інфраструктура AWS: апаратне забезпечення, мережі та приміщення — Правильно.
- Сторонні застосунки, під’єднані до облікового запису AWS
- Дані, які клієнт вирішив зашифрувати
AWS відповідає за базову інфраструктуру; клієнт відповідає за те, що відбувається із сервісами, побудованими на ній («безпека в хмарі»).
2. За документацією Microsoft, яка відповідальність ніколи не переходить до провайдера, незалежно від моделі сервісу?
- Керування фізичним дата-центром
- Оновлення базової операційної системи в повністю керованому продукті SaaS
- Ваші дані, облікові записи, пристрої та керування доступом — Правильно.
- Керування фізичним мережевим обладнанням
Microsoft стверджує, що клієнти завжди зберігають відповідальність за свої дані, ідентичності, клієнтські пристрої та контроль доступу в кожній моделі розгортання.
3. Чому більшість реальних інцидентів безпеки в хмарі трапляється на боці клієнта в межах цієї відповідальності?
- Хмарні провайдери рідко добре захищають власну інфраструктуру
- Зловмисникам легше скористатися слабким паролем чи неправильно налаштованим доступом, ніж зламати дата-центр великого провайдера — Правильно.
- Клієнти юридично зобов’язані залишати свій бік незахищеним
- Спільна відповідальність не стосується малих організацій
Великі провайдери вкладають величезні кошти в безпеку інфраструктури, тож зловмисники частіше цілять у контрольований клієнтом бік: облікові дані, налаштування спільного доступу та керування доступом.

Застосуйте на практиці з FireAI

Застосуйте цей урок на своєму Mac.

Джерела

Застосуйте це на своєму Mac

Усі функції безкоштовно на 17 днів, без банківської картки.

Завантажити для Mac Документація