Укрепление ваших облачных учётных записей

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

Проверяйте активные сеансы и устройства

Каждый крупный провайдер учётных записей ведёт список устройств и сеансов, в данный момент вошедших в систему, а также журнал недавней активности. Периодическая проверка отвечает на простой вопрос: находится ли в этой учётной записи кто-то, кроме тех, кто должен там быть? Незнакомое устройство, вход из неожиданного места или сеанс, который так и не завершился на устройстве, которым вы больше не владеете, — всё это стоит немедленно проверить, завершив сеанс и сменив пароль. Это напрямую следует из урока о личности ранее в этом курсе: украденный пароль остаётся полезным злоумышленнику ровно до тех пор, пока возникший из-за него сеанс остаётся незамеченным.

Проверяйте доступ сторонних приложений

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

Убедитесь, что резервные копии действительно существуют, и узнайте где

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

Включайте журналирование и оповещения там, где они есть

Большинство потребительских и небольших корпоративных облачных учётных записей предлагают ту или иную форму уведомления о безопасности — письмо или push-оповещение о новом входе, смене пароля или добавлении нового устройства. Обычно они включаются вручную или спрятаны в настройках, а не действуют по умолчанию. Их включение ничего не стоит и напрямую сокращает промежуток между компрометацией учётной записи и моментом, когда кто-то это заметит, а это часто и есть самый значимый фактор того, какой ущерб нанесёт вторжение.

Сделайте это привычкой, а не разовой задачей

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