© 1995-2021 Компания «Инфосистемы Джет»
Риски перехода компании в облако и методы ее защиты
Информационная безопасность

Риски частных, публичных инфраструктурных облаков и облачных приложений. Как защитить компанию при переходе в cloud-среду?

Информационная безопасность Тема номера

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

24.10.2021

Посетителей: 84

Просмотров: 75

Время просмотра: 5.6 мин.

Риски частных, публичных инфраструктурных облаков и облачных приложений.

 

Как защитить компанию при переходе в cloud-среду?

 

Компании все активнее переходят в облака. При этом основным вопросом становится скорость перехода, а безопасность отходит на второй план. Как защитить бизнес в таких условиях?  

Собственную инфраструктуру компании можно сравнить с за́мком. Ей уделяется много внимания, и она хорошо защищена такими средствами, как межсетевые экраны и системы мониторинга (высокие стены и заполненный водой ров). Но в этом замке есть большие открытые ворота, ведущие к облачным сервисам. Зачастую в облаке отсутствуют какие-либо усиленные настройки безопасности и используется только базовая связка логин-пароль. Поэтому облако можно сравнить с открытым полем, около которого стоит охранник и проверяет пропуска.

 

Такое несоответствие вариантов защиты собственного ИТ-ландшафта (неприступный замок) и облака (открытое поле с охранником) как компрометирует оборону замка, так и подстегивает злоумышленников к атакам на компанию именно через облачную инфраструктуру.

 

Несколько примеров крупных инцидентов в облачных средах:

 

 

Давайте разберемся, какие конкретные риски ИБ связаны с использованием облака, как их минимизировать и какие средства защиты использовать. У облаков разного типа профили актуальных рисков тоже разные. 

 

Виды облаков:

 

  • Частные: компании строят их в собственной инфраструктуре для предоставления внутренних сервисов.
  • Публичные инфраструктурные облака (IaaS, PaaS): компании-провайдеры строят такие облака, чтобы оказывать услуги на коммерческой основе для рынка. Примерами таких облаков являются AWS, Azure, «Яндекс.Облако» и др.
  • Публичные облачные приложения (SaaS): в данном случае провайдер предоставляет доступ к готовому облачному приложению (например, Zoom или Microsoft OneDrive).

 

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

 

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

 

Упрощенно облако можно представить в виде 4 слоев:

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Упрощенно процесс построения частного облака можно разделить на 3 этапа:

 

  1. проектирование, 
  2. развертывание,
  3. эксплуатация.

 

Во время проектирования частного облака мы решаем следующие ключевые задачи:

 

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

 

На этапе развертывания частного облака важно убедиться в следующем:

 

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

 

На этапе эксплуатации важно предусмотреть все процедуры, которые будут поддерживать безопасность облака в ходе его использования:

 

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

 

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

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

Уведомления об обновлении тем – в вашей почте

IaaS, PaaS, SaaS. Раздел территории между провайдерами и клиентами облачных сервисов

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

Коммерческие ЦОД и облачные провайдеры: кто кого?

Появление публичных cloud-сервисов разнообразило возможности выбора для заказчиков, по тем или иным причинам отказавшихся от строительства собственных ЦОД.

Крупные компании готовы переносить системы в российские облака

В интервью нашему изданию Денис Абраменко рассказал, какие системы сервисная компания «Центр корпоративных решений», входящая в состав Fletcher Group, готов переносить в публичное облако и почему будущее ИТ-инфраструктур крупных компаний — за гибридными облачными моделями.

«Облачные вычисления». Взгляд из IBM

В последние годы многие эксперты пророчат революцию в мире ИТ благодаря новому подходу в организации инфраструктуры - облачным вычислениям. Согласно опросу IBM Global CIO Study 2009 более трети руководитель ИТ-отделов назвали это направление развития одним из самых важных в информационных технологиях.

Сервер аутентификации Kerberos

Идентификация и проверка подлинности пользователей (аутентификация) — это основное средство защиты информационных систем от одной из главных угроз — постороннего вмешательства. Если у злоумышленника нет средств для нелегального доступа, возможности ...

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

Государственная тайна - это информация, которая имеет непосредственное уголовно-правовое значение, связанное с обеспечением государственной безопасности

5000 слов о защите контейнеров

Функциональные ИБ-требования для защиты контейнеров. Как выбрать оптимальное решение? Перечень Enterprise и Open Source инструментов для защиты.

Проблемы безопасности виртуальных сред: заплаточный подход

Прошедший 2012-й год показал, что компании в России начали вести реальную работу в области обеспечения защиты своих виртуальных сред (ВС)

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня