Риски автоматического устранения проблем с доступом к облаку

Риски автоматического устранения проблем с доступом к облаку

Источник · Перевод автора

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

Неверно настроенный или избыточный доступ к облаку «неизбежен», – написала Лори Робинсон (Lori Robinson), вице-президент SailPoint, облачного провайдера безопасности идентификационной информации. Даже при наличии «наиболее тщательно продуманной структуры управления» разрастающийся характер облачной среды и разнообразие постоянно происходящих изменений означают, что определенные процедуры время от времени игнорируются. По словам Робинсон, немедленное прекращение доступа после обнаружения проблемы – это «реакция коленного рефлекса». ИТ-команды должны сначала выяснить, какое влияние это окажет на существующие приложения и процессы, чтобы определить соответствующий план действий.

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

Неверная конфигурация, избыточное выделение ресурсов

Неверно настроенный доступ – распространенная проблема, поскольку облачный экземпляр настроен без надлежащей безопасности или контроля доступа. К базе данных или серверу хранения, предназначенному для использования во внутренних приложениях, может получить доступ любой пользователь в Интернете. Журнал доступа или шифрование могут быть не включены. Аутентификация может быть слабой или отсутствовать полностью. Когда это происходит и информация становится доступной, это подвергает людей риску кражи личных данных и других личных кибератак, а организации могут столкнуться с регулирующими действиями.

Ранее в этом году незащищенная корзина AWS S3 предоставила более 400 ГБ данных, представляющих примерно 500 000 документов, связанных с MCA Wizard, приложением для iOS и Android, разработанным Advantage Capital Funding и Argus Capital Funding. Данные в базе данных включали кредитные отчеты, банковские выписки, контракты, юридические документы, копии водительских прав, заказы на покупку и квитанции, налоговые декларации, информацию о социальном обеспечении и отчеты о транзакциях. В другом инциденте более 50000 историй болезни в службе тестирования COVID-19 в штате Юта были раскрыты из-за неправильно настроенной корзины AWS S3. Корзины S3, содержащие около 200 000 изображений сканированных изображений водительских прав, паспортов, государственных удостоверений личности, карточек медицинского страхования и других документов, удостоверяющих личность, были проиндексированы поисковыми системами, и к ним можно было получить доступ через Интернет без пароля.

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

Риски автоматизированного смягчения

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

Без контекста того, почему роли предоставляются таким образом, слепое лишение доступа может иметь последствия, потенциально закрывающие группы и новые проекты.

«Автоматизация мониторинга доступа к облаку – хороший первый шаг, который дает вам «что». Но вам также необходимо знать «как» и «почему», чтобы полностью понять, как предоставляется такой доступ для эффективного управления, – заявил Робинсон.