Подписаться
Читать в телеграм
Риски частных, публичных инфраструктурных облаков и облачных приложений.
Как защитить компанию при переходе в cloud-среду?
Компании все активнее переходят в облака. При этом основным вопросом становится скорость перехода, а безопасность отходит на второй план. Как защитить бизнес в таких условиях?
Собственную инфраструктуру компании можно сравнить с за́мком. Ей уделяется много внимания, и она хорошо защищена такими средствами, как межсетевые экраны и системы мониторинга (высокие стены и заполненный водой ров). Но в этом замке есть большие открытые ворота, ведущие к облачным сервисам. Зачастую в облаке отсутствуют какие-либо усиленные настройки безопасности и используется только базовая связка логин-пароль. Поэтому облако можно сравнить с открытым полем, около которого стоит охранник и проверяет пропуска.
Такое несоответствие вариантов защиты собственного ИТ-ландшафта (неприступный замок) и облака (открытое поле с охранником) как компрометирует оборону замка, так и подстегивает злоумышленников к атакам на компанию именно через облачную инфраструктуру.
Несколько примеров крупных инцидентов в облачных средах:
Злоумышленники украли данные более чем 100 млн клиентов американского банка Capital One.
Данные 140 млн посетителей сети отелей MGM были украдены летом 2019 г.
- Данные 7,5 млн пользователей Adobe были обнаружены в публичном доступе из-за ошибки в конфигурации.
Давайте разберемся, какие конкретные риски ИБ связаны с использованием облака, как их минимизировать и какие средства защиты использовать. У облаков разного типа профили актуальных рисков тоже разные.
Виды облаков:
- Частные: компании строят их в собственной инфраструктуре для предоставления внутренних сервисов.
- Публичные инфраструктурные облака (IaaS, PaaS): компании-провайдеры строят такие облака, чтобы оказывать услуги на коммерческой основе для рынка. Примерами таких облаков являются AWS, Azure, «Яндекс.Облако» и др.
- Публичные облачные приложения (SaaS): в данном случае провайдер предоставляет доступ к готовому облачному приложению (например, Zoom или Microsoft OneDrive).
Риски для частных облаков
Основные риски связаны с построением надежной и безопасной системы, способной обслуживать большое количество внутренних пользователей и поддерживать критичные информационные системы.
Упрощенно облако можно представить в виде 4 слоев:
- набор инфраструктурных компонентов — серверы, сетевое оборудование, системы хранения данных;
- платформа автоматизации частного облака — система, которая производит развертывание и остановку ресурсов по запросу пользователей, контролирует потребление сервисов и выполняет многое другое;
- портал управления облачной инфраструктурой — с его помощью пользователи взаимодействуют с облаком, заказывая, изменяя и останавливая ресурсы;
- ресурсы, развернутые в облаке.
В случае с инфраструктурными компонентами не возникает никакой специфики с точки зрения ИБ. Как и в случае с традиционным ИТ-ландшафтом, нужно обезопасить доступ к физической инфраструктуре, обеспечить резервирование ключевых компонентов и т.п.
Когда же мы переходим на уровень платформы автоматизации частного облака, возникают вопросы. Разберемся с некоторыми из них и рассмотрим способы минимизировать проблемы:
- Облако — это общая инфраструктура, которая делится между пользователями. Соответственно, один из основных вопросов безопасности — обеспечить изоляцию ресурсов так, чтобы пользователи облака видели и могли изменять только собственные ресурсы и чтобы ресурсы одного пользователя не могли помешать работе ресурсов других пользователей. Для защиты от этого риска необходимо реализовать надежную модель управления ролями и доступом, а также обеспечить необходимый уровень изоляции пользователей на уровне инфраструктуры облака (исключить влияние на соседей по физической инфраструктуре).
- Следующий риск связан с перехватом контроля над платформой автоматизации частного облака. Найдя уязвимость в платформе или перехватив привилегированные учетные данные, от имени которых работает платформа, злоумышленник сможет управлять всеми ресурсами, развернутыми в облаке. Чтобы минимизировать такой риск, необходимо осуществить харденинг платформы в соответствии с рекомендациями вендора, обеспечить защиту сервисных учетных записей, использующихся платформой, и осуществлять постоянный мониторинг использования сервисных учетных записей платформы и изменений в ее конфигурации.
- Конечно же нельзя забывать и об отказоустойчивости облачной платформы, ведь проблемы с ее доступностью будут влиять и на все ИС, развернутые в облаке. В данном случае необходимо предусмотреть резервирование ключевых компонентов платформы и обеспечить резервное копирование данных.
- Нельзя не отметить риск использования уязвимых образов для развертывания ресурсов в облаке. Если хранилище образов, которые используются при развертывании ресурсов в облаке, не защищено, злоумышленник может подменить образы операционных систем на уязвимые. Таким образом, все виртуальные машины, развернутые в облаке, уже изначально будут уязвимыми. Чтобы предотвратить подобные атаки, необходимо как защитить доступ к репозиторию доверенных образов, так и выстроить надежный процесс развертывания инфраструктуры с проверкой целостности используемых образов.
Найдя уязвимость в платформе или перехватив привилегированные учетные данные, от имени которых работает платформа, злоумышленник сможет управлять всеми ресурсами, развернутыми в облаке.
Переходя на уровень портала управления облачной инфраструктурой, мы сталкиваемся с рисками, которые являются следствием небезопасного управления сотрудниками своими облачными средами.
- Так, пользователи могут некорректно разделить ресурсы между средами — например, развернуть ресурсы для тестовой и продуктивной версий в одном сегменте. Чтобы минимизировать этот риск, нужно обучить сотрудников работе с облаком и ознакомить их с рекомендациями и инструкциями.
- Кроме того, сотрудникам может быть предоставлен излишне высокий уровень доступа. Управление облачной инфраструктурой — это критичная функция, и назначение несоответствующих привилегий может привести к инцидентам, связанным с ошибками пользователей, а также к увеличению поверхности атаки. Чтобы снизить этот риск, необходимо назначать сотрудникам роли, строго соответствующие их функциональным обязанностям: например, предусмотреть роль владельца информационной системы, который сможет управлять бюджетом и отслеживать потребление ресурсов, но не сможет их останавливать или изменять.
И наконец, перейдем к уровню ресурсов, развернутых в облаке. Здесь мы сталкиваемся с рисками, аналогичными тем, что возникают в классической инфраструктуре. Но есть и особенность, связанная со спецификой облака: во-первых, ресурсы в нем могут очень быстро меняться, создаваться и уничтожаться; и, во-вторых, пользователи сами создают ресурсы в облаке и могут допустить ошибку, выбрав неправильные параметры безопасности.
- Ошибки в конфигурациях ресурсов — пользователи могут забыть зашифровать данные или не смогут обеспечить должную защиту при организации доступа к ресурсам из интернета.
- Небезопасная архитектура — развертывая ресурсы, пользователи могут не позаботиться о необходимом уровне сетевой изоляции между компонентами информационной системы или не реализовать параметры безопасности на уровне операционной системы.
Чтобы справиться с этой проблемой, следует разработать шаблоны безопасных конфигураций, которые пользователи будут использовать для реализации типовых инфраструктур. В дополнение к этому стоит предусмотреть автоматические параметры безопасности, которые станут включаться при определенных условиях. Например, если пользователь разворачивает веб-приложение, то в связку нужно включать WAF и автоматически применять необходимые параметры безопасности на уровне операционной системы.
Как можно заметить, частное облако тоже требует значительного внимания службы ИБ, хотя и разворачивается в собственной инфраструктуре.
Рассмотрим подходы к защите частного облака на примере нашей работы с заказчиками. Мы предлагаем им как построение уже защищенного частного облака, так и оценку безопасности и разработку рекомендаций для уже использующихся частных облаков.
Упрощенно процесс построения частного облака можно разделить на 3 этапа:
- проектирование,
- развертывание,
- эксплуатация.
Во время проектирования частного облака мы решаем следующие ключевые задачи:
- выявляем все узкие места и определяем критичные компоненты в архитектуре облака;
- оцениваем ролевую модель;
- формируем перечень контролей, которые закрываются встроенными компонентами облака;
- определяем необходимые наложенные средства защиты и оцениваем возможность переиспользования имеющихся лицензий и оборудования заказчика.
На этапе развертывания частного облака важно убедиться в следующем:
- все контроли безопасности реализованы в соответствии с изначальным планом;
- в процессе развертывания облака не было критичных отклонений от изначальной архитектуры;
- все временные учетные записи и доступы, необходимые на этапе развертывания, были закрыты после выполнения работ.
На этапе эксплуатации важно предусмотреть все процедуры, которые будут поддерживать безопасность облака в ходе его использования:
- Разработать требования к обслуживанию и поддержке ИБ частного облака. Этот раздел должен включать требования к управлению учетными записями, внесению изменений в облаке, мониторингу событий облачной платформы и другие аспекты.
- Разработать подходы к использованию частного облака внутри компании, которые будут определять необходимые для включения параметры и контроли при развертывании систем в облаке, разграничивать ответственность между командами разработки конечной системы и облачной платформы в части обеспечения безопасности.
- Определить механизмы непрерывного контроля за безопасностью пользовательских нагрузок в облаке. Такие организационные или технические меры должны обеспечить соответствие полезных нагрузок в облаке требованиям безопасности компании и выявлять небезопасные изменения, которые происходят в облаке.
Как видим, с одной стороны, обеспечение безопасности частного облака требует больших инвестиций, в том числе и со стороны безопасности. Однако повсеместная автоматизация, которая приходит с облаком, открывает новые возможности по непрерывному отслеживанию безопасности информационных систем компании и позволяет уйти от рутинных задач.
Риски для публичных инфраструктурных облаков
Рассмотрев основные риски для частного облака и пути их минимизации, перейдем к публичным облачным инфраструктурам.
Как и в случае с частным облаком, публичное инфраструктурное облако состоит из тех же основных компонентов. Ключевым же отличием является то, что за инфраструктурные компоненты и платформу автоматизации полностью отвечает провайдер, а у пользователей нет возможности влиять на работу этих компонентов.
Соответственно, риски ИБ распределяются между зонами ответственности провайдера (отвечает за защиту и доступность облачной платформы и инфраструктуры облака) и пользователя (отвечает за использование облака в своей компании и безопасность развернутых в нем систем).
Таким образом, риски безопасности на уровне инфраструктурных компонентов и платформы автоматизации остаются актуальными, но ответственность за их минимизацию берет на себя провайдер. А компания, пользующаяся услугами публичного облака, должна позаботиться о выборе надежного облачного провайдера, который сможет обеспечить соответствие как требованиям безопасности самой организации, так и предписаниям регуляторов.
В то же время к рискам на уровне портала управления облачной инфраструктурой, рассмотренным для частного облака, добавляется критичный пункт об управлении доступом к облаку. В отличие от частного облака, развернутого в собственной инфраструктуре компании, к публичному облаку может подключиться через интернет любой желающий. Поэтому так важно ограничить возможность подключаться к своей облачной среде всем устройствам и сетям, за исключением доверенных, и обеспечить усиленную проверку пользователей с помощью двухфакторной аутентификации.
Для ресурсов, развернутых в облаке, риски остаются теми же, что и для частного облака. Но стоит отметить и риск избыточного использования ресурсов. В отличие от собственной инфраструктуры, где потребление ресурсов ограничено мощностями ЦОДа.
в публичном облаке можно заказывать практически неограниченное количество ресурсов, и без должного мониторинга это может привести к существенным финансовым потерям.
Итак, чтобы обеспечить безопасное использование публичного инфраструктурного облака, необходимо выполнить несколько ключевых шагов:
- оценить надежность и защищенность облака провайдера;
- убедиться в том, что договор с провайдером точно описывает разделение ответственности сторон;
- обеспечить надежное и защищенное сетевое соединение с облаком;
- выполнять мониторинг событий и изменений в облаке;
- проводить периодическую проверку актуальности назначенных административных привилегий;
- осуществлять мониторинг безопасности развернутых в облаке систем;
- проверять безопасность конфигураций развернутых в облаке ресурсов;
- отслеживать сетевые взаимодействия систем внутри облака и с внешними сетями.
В этом может помочь класс решений CSPM (Cloud Security Posture Management). Такие решения от ведущих производителей средств ИБ подключаются к облачным средам, выполняют автоматизированный мониторинг и обеспечивают реагирование на события в облаке. В том числе они позволяют:
- автоматически проверять все развернутые ресурсы на соответствие политикам безопасности компании и лучшим практикам;
- выявлять и исправлять небезопасные конфигурации;
- отслеживать небезопасные сетевые соединения;
- проверять организацию доступа к облачной среде.
Решения этого класса позволяют обеспечивать безопасность облака с первого дня использования и применять наработки и лучшие практики для проактивного отслеживания и устранения уязвимостей.
Риски для облачных приложений
В случае облачных приложений провайдер берет на себя ответственность за все, что связано с работой самого приложения. В зоне ответственности пользователей остаются только безопасные настройка и использование приложения в своей организации.
Как и в случае с публичным инфраструктурным облаком, здесь критичным становится вопрос доверия к облачному провайдеру. Необходимо убедиться в том, что он обеспечивает все необходимые меры для обеспечения целостности, конфиденциальности и доступности облачного приложения и обрабатываемых в нем данных.
Помимо риска работы с ненадежным провайдером, компании часто сталкиваются с тем, что пользователи используют облачные приложения в обход службы безопасности. В таком случае реализация мер безопасности остается на усмотрение самих пользователей, для которых удобство использования сервиса стоит выше вопросов безопасности. Для предотвращения подобных ситуаций и выявления всех сервисов, которые используются в компании, можно использовать журналы сетевого оборудования либо решения CASB (Cloud Access Security Broker). CASB-решения идут с широкой базой облачных приложений и могут автоматически обнаруживать их применение, выявлять сотрудников, использующих эти сервисы, и отображать передаваемые ими данные.
Следующим не менее важным риском безопасности для облачных приложений является утечка данных из облака. В облако невозможно поставить свой сервер DLP, а значит, обработка и распространение данных обходят все классические контроли. Для предотвращения этого потребуется либо выполнить настройку встроенных инструментов самого облачного сервиса, либо использовать CASB-решения.
Заключительный, но не менее важный риск — небезопасная организация доступа к облачному приложению. Облачные сервисы позволяют подключиться пользователям из любой точки мира и с любого устройства, и к тому же поддерживают анонимные или гостевые подключения. Конечно, такой неограниченный доступ создает серьезные риски для безопасности. Чтобы им противодействовать, необходимо ограничить анонимный доступ и разрешить только безопасные подключения. Выполнить это можно на уровне облачного приложения или с помощью CASB.
Контроль за использованием облачных приложений осложняется и тем, что в компании используется множество облачных сервисов одновременно. Именно поэтому, помимо защиты уже выявленных приложений, в компании нужно разработать общий подход к работе с облачными приложениями. Такой подход должен обеспечивать выполнение требований безопасности в следующих ситуациях:
- выбор облачных приложений для использования в компании;
- их внедрение;
- их эксплуатация;
- их вывод из использования.
Процесс выбора облачных приложений должен быть формализованным и включать требования безопасности к самому облаку и к его использованию. Такие требования могут отличаться в зависимости от целевого использования приложения: более жесткие — для поддержки критичных процессов и обработки конфиденциальных данных, более мягкие — для некритичных. В зависимости от полученной картины актуальных требований безопасности, встроенных возможностей по ИБ самого сервиса и возможных компенсирующих мер, принимают решение о дальнейшем использовании сервиса в компании.
При внедрении облачного приложения крайне важно интегрировать его с единой системой управления учетными записями в компании. Это значительно снизит риск появления «забытых» учетных записей (например, при увольнении сотрудника). Кроме того, необходимо реализовать все контроли безопасности и интегрировать приложение с системами безопасности компании, что позволит обеспечить ИБ при дальнейшей эксплуатации облачного сервиса.
Для правильной эксплуатации облачного приложения необходимо выделить ответственного специалиста, который будет отслеживать обновления и изменения в приложении.
Конечно же, нельзя забывать и о мониторинге событий в облаке и о периодическом отслеживании актуальности административных привилегий.
На заключительном этапе жизненного цикла облачного сервиса нужно обеспечить сохранение всех необходимых данных из облака, таких как журналы событий, конфиденциальные данные компании и пр. После этого следует удалить все данные и убедиться в том, что на стороне провайдера обеспечивается процедура безопасного удаления данных клиентов.
Конечно же, мы обсудили только наиболее часто встречающиеся и общие риски безопасности. В зависимости от специфики использования облачных сред в вашей организации, профиль рисков может отличаться. Но ключевым остается вопрос постановки под контроль использования облачных решений внутри организации. Недостаточное внимание к вопросам защиты облаков влечет значительные риски при использовании самих облачных решений, а также создает опасность компрометации собственной инфраструктуры компании через облако.
Быстрое распространение облачных решений и особенности этой технологии требуют от службы безопасности компаний комплексного подхода к решению проблем. В «Джете» мы используем зарекомендовавший себя на многих проектах подход, позволяющий последовательно выстроить практику безопасного использования облаков — от фундаментальных контролей до уникальных для облака возможностей по автоматизации.
Не бойтесь сделать свой первый шаг к безопасному облачному будущему. Надеемся, наша статья поможет вам получить ответы на ключевые вопросы, а если вы столкнетесь с трудностями, то всегда будем рады помочь.
