Облачные данные нужно защищать. Удалить их или раскрыть к ним доступ может уволенный и потому разгневанный сотрудник, в конце концов их могут удалить случайным образом. Главный консультант Improving Марк Руньон приводит на портале Enterprisers Project советы, которые помогут обезопасить облачные активы предприятий.

Июльская статья под названием «Nightmare Scenario: Employee Deletes AWS Root Account» («Кошмарный сценарий: сотрудник удалил корневой аккаунт AWS») дает CIO пищу для размышлений. В ней говорится об имевшем место случае, когда к ИТ-директору консалтинговой компании Victory Джону Каннингему обратился один из ее бывших клиентов. Он столкнулся с очень серьезной проблемой: учетная запись компании с капитализацией в несколько миллионов долларов исчезла с сервиса AWS, а вместе с ней отключился колцентр, и в результате она фактически приостановила обслуживание клиентов. Клиент спрашивал Каннингема, как ему вернуть удаленный аккаунт.

Далее вскрылись такие подробности. Попавший в беду клиент недавно уволил сотрудника, который воспринял увольнение в штыки. В качестве отмщения он отключил всех пользователей в облачном корпоративном аккаунте, изменил привязанный к корневой учетной записи адрес электронной почты и пароль, фактически скрыв ее существование. Как следствие, аккаунт компании, которая управляла своим колцентром при помощи AWS Connect, был заблокирован и она больше не могла попасть в облако. Примечательно, что Amazon не смогла вмешаться в ситуацию и отменить внесенные изменения, поскольку они были признаны валидными. Возможно, уволенный сотрудник сменил пароль к аккаунту компании за день или два до увольнения, но это лишь предположение.

Самый быстрый способ устранить проблему — заставить бывшего сотрудника разблокировать аккаунт. Пострадавший работодатель обратился за помощью в ФБР. Чтобы решить проблему, потребовалось 24 часа.

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

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

Предприятие должно составить контрольный список с перечислением уволенных и детальным описанием ресурсов, к которым они имели доступ. Подразумевается, что все они должны быть отключены. Важная деталь: организации нужно удостовериться, что отключение доступа работает. Нужно в тестовом режиме отключить высокоуровневую учетную запись администратора и проверить, действительно ли перекрыт доступ к заблокированным аккаунтам.

2. Защитите корневой аккаунт. Важность защиты доступа к корневой учетной записи (root account) сложно переоценить. Она позволяет совершать практически любые действия в облачном окружении предприятия, поэтому ее защита является обязательной. Ниже приводится несколько мер, которые нужно предпринять для обеспечения ее безопасной работы:

  • установите для доступа к корневому аккаунту надежный пароль, который будет известен только ответственному персоналу;
  • установите оповещение, чтобы группа ответственных лиц могла получать уведомления, если кто-то попытается получить доступ к корневой учетной записи;
  • root account ни в коем случае не должен быть привязан к адресу электронной почты сотрудника;
  • защитите адрес электронной почты, привязанной к корневому аккаунту, чтобы предотвратить сброс пароля;
  • настройте многофакторную аутентификацию при помощи физического аппаратного токена, который хранится в пожаробезопасном сейфе;
  • корневой аккаунт не должен использоваться для ежедневного доступа.

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

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

При выборе модели резервного копирования, которая помимо основного аккаунта предусматривает наличие отдельной резервной учетной записи (cross-account backup model), применяются те же протоколы защиты, что и для основного аккаунта. Важная деталь: аккаунт, который требуется для создания снапшотов, важно настроить таким образом, чтобы ни у кого не было возможности удалить их. Взаимодействие между двумя учетными записями требуется автоматизировать, чтобы резервные копии всегда были в актуальном состоянии. Уведомления о сбоях резервного копирования должны поступать сразу нескольким лицам, чтобы в случае, если кто-то ушел в отпуск, другой мог быстро отреагировать.

4. Регулярно проверяйте доступ сотрудников. Неправильно настроенные облачные сервисы — довольно распространенное явление. Когда в прессе встречаются броские заголовки о взломе или утечке данных — это как раз об этом. По данным отчета McAfee «Cloud Adoption and Risk Report 2019», в среднем компания за месяц сталкивается с 2200 инцидентами, связанными с неправильными настройками в IaaS-сервисах. Как правило, облачные провайдеры выставляют все настройки по умолчанию, но с расчетом, что клиент сам будет управлять настройками безопасности. Для них это идеальный способ избавить себя от любых проблем безопасности, поскольку ответственность перекладывается на клиента. Как прогнозируют эксперты, в 2022 г. 95% инцидентов, связанных с безопасностью облаке, будут происходить по вине клиента.

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

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

Выводы

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