Личность — это новый периметр

Предыдущий урок провёл границу между тем, что защищает облачный провайдер, и тем, что должен защищать клиент. На стороне клиента одна вещь значит больше, чем все остальные вместе взятые: личность — кому разрешено входить и что он затем может сделать. У традиционной офисной сети была стена и запертая дверь; у облачной учётной записи есть форма входа, доступная из любой точки планеты в любой час. Защита этого входа — это на практике почти всё, что означает «безопасность в облаке».

Как учётные записи на самом деле захватывают

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

MFA и почему не все её формы равноценны

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

OAuth: разрешения, которые вы даёте другим приложениям

Каждый раз, когда вы нажимаете «продолжить через Google» или подключаете сервис планирования к своему календарю, вы используете OAuth, который собственная документация стандарта описывает как «отраслевой стандартный протокол авторизации». Его полезное свойство в том, что стороннее приложение никогда не видит ваш пароль — вы входите напрямую через своего провайдера, а затем одобряете конкретный, ограниченный набор разрешений, называемых областями доступа (scopes), для этого приложения. Его риск — именно в этом предоставлении разрешений: приложению планирования, которому нужно лишь читать статус занятости в вашем календаре, может быть запрошено — и рутинно предоставлено — разрешение читать и отправлять почту от вашего имени. Каждое подключённое приложение — это постоянное разрешение на доступ, действующее до тех пор, пока кто-нибудь его не отзовёт, поэтому последний урок этого курса посвящён проверке этого списка, а не только его правильной настройке один раз.

Утечка ключей: менее заметная родственница OAuth

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