Ідентичність — новий периметр

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

Як облікові записи насправді захоплюють

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

MFA і чому не всі форми рівнозначні

CISA прямо стверджує, що «користувачі, які вмикають MFA, значно рідше стають жертвами зламу», бо викраденого пароля самого по собі вже недостатньо. Але CISA також ранжує доступні форми MFA за стійкістю до фішингу, і цей рейтинг важливий: «єдина широкодоступна автентифікація, стійка до фішингу, — це автентифікація FIDO/WebAuthn» — стандарт, на якому базуються ключі доступу (passkeys) і апаратні ключі безпеки, розглянуті в курсі про криптографію. Код у текстовому повідомленні, за словами CISA, усе одно значно кращий, ніж відсутність другого фактора взагалі, але його може перехопити чи переспрямувати достатньо вмотивований зловмисник; push-сповіщення застосунку зі звіркою чисел перебувають десь посередині. Для хмарного облікового запису з чимось чутливим увімкнення найсильнішого варіанту MFA, який пропонує обліковий запис, — це крок з найвищою цінністю в цьому занятті.

OAuth: дозволи, які ви надаєте іншим застосункам

Щоразу, коли ви натискаєте «продовжити через Google» або під’єднуєте інструмент планування до свого календаря, ви користуєтеся OAuth, який власна документація стандарту описує як «галузевий стандартний протокол для авторизації». Його корисна властивість у тому, що сторонній застосунок ніколи не бачить ваш пароль — ви входите напряму через свого провайдера, а потім схвалюєте конкретний, обмежений набір дозволів, що звуться областями дії (scopes), для цього застосунку. Його ризик — саме в наданні цих дозволів: застосунок планування, якому потрібно лише читати вільні/зайняті проміжки вашого календаря, може попросити — і зазвичай отримати — дозвіл читати й надсилати пошту від вашого імені. Кожен під’єднаний застосунок — це постійний дозвіл на доступ, що діє, поки хтось його не скасує, тому останнє заняття цього курсу присвячене саме перегляду цього списку, а не лише його правильному налаштуванню один раз.

Витік ключів: менш помітний родич OAuth

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