Облачная НЕбезопасность и как с ней бороться

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

• Облако — это общая инфраструктура, которая делится между пользователями. Соответственно, один из основных вопросов безопасности — обеспечить изоляцию ресурсов так, чтобы пользователи облака видели и могли изменять только собственные ресурсы и чтобы ресурсы одного пользователя не могли помешать работе ресурсов других пользователей. Для защиты от этого риска необходимо реализовать надежную модель управления ролями и доступом, а также обеспечить необходимый уровень изоляции пользователей на уровне инфраструктуры облака (исключить влияние на соседей по физической инфраструктуре). 
• Следующий риск связан с перехватом контроля над платформой автоматизации частного облака. Найдя уязвимость в платформе или перехватив привилегированные учетные данные, от имени которых работает платформа, злоумышленник сможет управлять всеми ресурсами, развернутыми в облаке. Чтобы минимизировать такой риск, необходимо осуществить харденинг платформы в соответствии с рекомендациями вендора, обеспечить защиту сервисных учетных записей, использующихся платформой, и осуществлять постоянный мониторинг использования сервисных учетных записей платформы и изменений в ее конфигурации.
• Конечно же нельзя забывать и об отказоустойчивости облачной платформы, ведь проблемы с ее доступностью будут влиять и на все ИС, развернутые в облаке. В данном случае необходимо предусмотреть резервирование ключевых компонентов платформы и обеспечить резервное копирование данных.
• Нельзя не отметить риск использования уязвимых образов для развертывания ресурсов в облаке. Если хранилище образов, которые используются при развертывании ресурсов в облаке, не защищено, злоумышленник может подменить образы операционных систем на уязвимые. Таким образом, все виртуальные машины, развернутые в облаке, уже изначально будут уязвимыми. Чтобы предотвратить подобные атаки, необходимо как защитить доступ к репозиторию доверенных образов, так и выстроить надежный процесс развертывания инфраструктуры с проверкой целостности используемых образов.  

Риски для публичных инфраструктурных облаков

Рассмотрев основные риски для частного облака и пути их минимизации, перейдем к публичным облачным инфраструктурам. 

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

Соответственно, риски ИБ распределяются между зонами ответственности провайдера (отвечает за защиту и доступность облачной платформы и инфраструктуры облака) и пользователя (отвечает за использование облака в своей компании и безопасность развернутых в нем систем).

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

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

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

Итак, чтобы обеспечить безопасное использование публичного инфраструктурного облака, необходимо выполнить несколько ключевых шагов:

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

В этом может помочь класс решений CSPM (Cloud Security Posture Management). Такие решения от ведущих производителей средств ИБ подключаются к облачным средам, выполняют автоматизированный мониторинг и обеспечивают реагирование на события в облаке. В том числе они позволяют:

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

Решения этого класса позволяют обеспечивать безопасность облака с первого дня использования и применять наработки и лучшие практики для проактивного отслеживания и устранения уязвимостей.

Риски для облачных приложений

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

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

Помимо риска работы с ненадежным провайдером, компании часто сталкиваются с тем, что пользователи используют облачные приложения в обход службы безопасности. В таком случае реализация мер безопасности остается на усмотрение самих пользователей, для которых удобство использования сервиса стоит выше вопросов безопасности. Для предотвращения подобных ситуаций и выявления всех сервисов, которые используются в компании, можно использовать журналы сетевого оборудования либо решения CASB (Cloud Access Security Broker). CASB-решения идут с широкой базой облачных приложений и могут автоматически обнаруживать их применение, выявлять сотрудников, использующих эти сервисы, и отображать передаваемые ими данные. 

Следующим не менее важным риском безопасности для облачных приложений является утечка данных из облака. В облако невозможно поставить свой сервер DLP, а значит, обработка и распространение данных обходят все классические контроли. Для предотвращения этого потребуется либо выполнить настройку встроенных инструментов самого облачного сервиса, либо использовать CASB-решения. 

Заключительный, но не менее важный риск — небезопасная организация доступа к облачному приложению. Облачные сервисы позволяют подключиться пользователям из любой точки мира и с любого устройства, и к тому же поддерживают анонимные или гостевые подключения. Конечно, такой неограниченный доступ создает серьезные риски для безопасности. Чтобы им противодействовать, необходимо ограничить анонимный доступ и разрешить только безопасные подключения. Выполнить это можно на уровне облачного приложения или с помощью CASB.

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

1. выбор облачных приложений для использования в компании;
2. их внедрение;
3. их эксплуатация;
4. их вывод из использования.

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

При внедрении облачного приложения крайне важно интегрировать его с единой системой управления учетными записями в компании. Это значительно снизит риск появления «забытых» учетных записей (например, при увольнении сотрудника). Кроме того, необходимо реализовать все контроли безопасности и интегрировать приложение с системами безопасности компании, что позволит обеспечить ИБ при дальнейшей эксплуатации облачного сервиса.

Конечно же, нельзя забывать и о мониторинге событий в облаке и о периодическом отслеживании актуальности административных привилегий.

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