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

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

Перевірте активні сесії й пристрої

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

Перевірте доступ сторонніх застосунків

Заняття про ідентичність також розглядало OAuth: кожне з’єднання «продовжити через» чи інтеграція з календарем — це постійний дозвіл на доступ, що діє, поки його не скасують. Більшість провайдерів перелічують кожен під’єднаний застосунок у налаштуваннях безпеки чи конфіденційності облікового запису, показуючи, що саме отримав кожен із них — читати пошту, керувати календарем, доступ до файлів — часто для сервісу, який ви спробували один раз роки тому й забули. Періодичне прополювання цього списку, видалення всього невикористаного чи невпізнаного, зменшує кількість шляхів до облікового запису, зовсім не торкаючись пароля.

Підтвердьте, що резервні копії справді існують, і де

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

Увімкніть журналювання й сповіщення там, де вони є

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

Перетворення цього на звичку, а не разову справу

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