Информация об утечке данных в наше время преобладает в заголовках. Люди часто предполагают, что эти взломы осуществляются блестящими программистами. Из-за этих проблем некоторые ИТ-директора воздерживаются от использования публичных облачных сервисов. На самом деле, проблемы с облачной безопасностью обычно менее серьезны, чем думает большинство людей. Например, они могут быть связаны с простой неверной конфигурацией из-за человеческой ошибки.
Публичное облако безопасно. У таких поставщиков, как Microsoft, Amazon, Google и IBM, есть много экспертов по безопасности, которые поддерживают свои платформы. Лидеры должны признать, что облачная безопасность - это общая ответственность как поставщика, так и клиента. ИТ-отделы должны взять на себя ответственность за поддержку облачных ресурсов и убедиться, что они следуют рекомендациям по сохранности данных.
Ниже представлены некоторые из наиболее распространенных ошибок, которых следует избегать любой ценой.
Раскрытие секретов
Разработчики и инженеры должны прекратить хранить секреты в исходном коде приложения и файлах конфигурации. Как правило, это происходит из-за чистой лени. Приложения и сценарии автоматизации часто должны подключаться к другим системам и проверять подлинность, таким как серверы баз данных, службы хранения или API-интерфейсы платформы. Разработчики могут включать эти учетные данные в исходный код для подключения к внешним системам, поскольку для этого требуется меньше усилий.
Компании должны защищать свои данные, используя службу управления ключами. На платформе Azure Microsoft предлагает Key Vault, который можно использовать для безопасного хранения секретов в модулях аппаратной безопасности (HSM). Amazon Web Services (AWS) также предоставляет управляемую службу под названием Secrets Manager, которая предоставляет аналогичные возможности. Разработчики могут использовать эти сервисы.
Использование высокопривилегированных учетных записей для повседневного администрирования
Для обеспечения оптимальной безопасности учетные записи с полным доступом к платформе не следует использовать для общего обслуживания или текущих административных задач.
Когда кто-то создает новую учетную запись с таким провайдером, как Azure или AWS, первая получает полный контроль и неограниченный доступ ко всем службам, доступным внутри учетной записи. Иногда создатель продолжает использовать этот высокопривилегированный вход в систему для рутинных административных задач, что открывает их для бесчисленных потенциальных инцидентов, связанных с безопасностью. Злоумышленник может изменить пароль, заблокировать всех остальных, использовать кредитную карту, привязанную к учетной записи, украсть конфиденциальные данные и уничтожить ресурсы.
Предприятия могут создавать специальные административные учетные записи для сотрудников, которые поддерживают свои облачные сервисы. Затем им может быть предоставлен ограниченный доступ.
Не использовать многофакторную аутентификацию для учетных записей администратора
Создание индивидуальных учетных записей для администраторов - это только первый шаг к защите подписки на общедоступное облако. Стоит также требовать многофакторной аутентификации (MFA).
MFA добавляет второй уровень безопасности в процесс входа в систему. В дополнение к имени пользователя и паролю, MFA может потребоваться случайный код, сгенерированный чем-то, что есть у администратора, например, аппаратный брелок, ключ безопасности USB или смартфон с программным обеспечением виртуального устройства MFA. Даже текстовое сообщение может использоваться в качестве второго фактора аутентификации.
Неспособность реализовать принцип наименьших привилегий
Чтобы реализовать принцип наименьших привилегий, команды могут четко указать доступ, который они предоставляют к облачным ресурсам. Административные учетные записи должны получать только те разрешения безопасности, которые им требуются. Для некоторых организаций может иметь смысл предоставлять пользователям доступ к определенным периодам времени только с использованием своевременного доступа.
Также может потребоваться разрешить входящий доступ к протоколу HTTP для обслуживания общедоступного веб-приложения. Но это не означает, что протокол SSH - метод, используемый для удаленного администрирования - также должен быть неограниченным.
