Перенос данных и приложений в облака представляет собой новую проблему для корпоративных SOCов, которые не всегда готовы к мониторингу чужой инфраструктуры. По данным Netoskope среднее предприятие (видимо все-таки в США) использует 1246 различных облачных сервиса, что на 22% больше, чем год назад. 1246 облачных сервисов!!! 175 из них касаются HR-сервисов, 170 связано с маркетингом, 110 — в области коммуникаций и 76 в финансах и CRM. В Cisco используется “всего” 700 внешних облачных сервисов. Поэтому меня немного смущают эти цифры. Но в любом случае проблема не в них, а в том, что облака достаточно активно начинают применяться все большим числом компаний, которые хотели бы иметь те же возможности по мониторингу облачной инфраструктуры, как и в собственной сети. И эта тенденция нарастает — по данным американской счетной палаты к 2023 г. в США собираются закрыть 1200 ЦОДов (6250 уже закрылись). Но переход к облаку — это не просто “а давайте перенесем наши сервера к внешнему провайдеру». Новая ИТ-архитектура, новое программное обеспечение, новые процессы, новые ограничения… Все это вносит существенные изменения в работу не только ИТ, но и ИБ. И если с обеспечением безопасности самого облака провайдеры научились как-то справляться (благо рекомендаций достаточно много), то с облачным мониторингом ИБ, особенно на SaaS-платформах, есть существенные сложности, о которых мы и поговорим.
Допустим, ваша компания перенесла часть своей инфраструктуры в облако… Стоп. Не так. Если инфраструктура перенесена, а вы только сейчас задумываетесь о том, как будете ее мониторить, то вы уже проиграли. Если это не Amazon, Google или Microsoft (и то с оговорками), то вероятно у вас не будет много возможностей по мониторингу ваших данных и приложений. Хорошо, если вам дадут возможность работать с логами. Иногда данные о событиях безопасности будут доступны, но у вас к ним не будет доступа. Например, Office 365. Если у вас самая дешевая лицензия E1, то события безопасности вам вообще недоступны. При наличии лицензии E3 у вас данные хранятся всего за 90 дней и только при наличии E5 — длительность логов доступна в течение года (правда, тут тоже есть свои нюансы, связанные с необходимостью отдельно запрашивать ряд функций по работе с логами у поддержки Microsoft). Кстати, лицензия E3 гораздо слабее в части функций мониторинга, чем корпоративный Exchange. Чтобы добиться того же уровня, вам нужна лицензия E5 или дополнительная лицензия Advanced Compliance, которые могут потребовать дополнительных денег, которые не были учтены в вашей финансовой модели перехода к облачной инфраструктуре. И это только один пример недооценки вопросов, связанных с мониторингом ИБ облаков. В этой статье я, не претендуя на полноту изложения, хочу обратить внимания на некоторые нюансы, которые стоит учесть при выборе облачного провайдера с точки зрения безопасности. А в конце статьи будет дан чеклист, который стоит выполнить, прежде чем считать, что вопрос мониторинга облачной ИБ у вас решен.
Можно выделить несколько типичных проблем, приводящих к инцидентам в облачных средах, реагировать на которые службы ИБ не успевают или вообще не видят их:
Переход в облака — это всегда поиск баланса между желанием сохранить контроль над инфраструктурой и передачей ее в более профессиональные руки облачного провайдера, который специализируется на ее поддержании. И в области безопасности облачных сред этот баланс тоже необходимо искать. Тем более, что в зависимости от используемой модели предоставления облачных услуг (IaaS, PaaS, SaaS) этот баланс будет все время разным. При любом раскладе надо помнить, что все облачные провайдеры сегодня следуют так называемой модели разделяемой ответственности и разделяемой ИБ. За что-то отвечает облако, за что-то отвечает клиент, разместивший в облаке свои данные, свои приложения, свои виртуальные машины и иные ресурсы. Необдуманно было бы рассчитывать, что уйдя в облако, мы переложим всю ответственность на провайдера. Но и выстраивать всю безопасность самостоятельно при переходе в облако тоже неразумно. Необходим баланс, который будет зависеть от множества факторов: — стратегии управления рисками, модели угроз, имеющихся у облачного провайдера защитных механизмов, законодательства и пр.
Например, классификация данных, размещаемых в облаке, — это всегда ответственность заказчика. Облачный провайдер или внешний поставщик услуг ему может только помочь с инструментарием, который будет помогать маркировать данные в облаке, выявлять нарушения, удалять нарушающие законодательство данные или маскировать их с помощью того или иного метода. С другой стороны физическая безопасность — это всегда ответственность облачного провайдера, которой он не может поделиться с клиентами. А вот все, что находится между данными и физической инфраструктурой — как раз и является предметом обсуждения данной статьи. Например, доступность облака — это ответственность провайдера, а настройки правил МСЭ или включение шифрования — это уже ответственность клиента. В этой статьей мы попробуем посмотреть, какие механизмы мониторинга ИБ предоставляют сегодня различные популярные в России облачные провайдеры, каковы особенности их применения, и когда стоит посмотреть в сторону внешних наложенных решений (например, Cisco E-mail Security), расширяющие возможности вашего облака в части кибербезопасности. В ряде случаев, особенно в случае следования мультиоблачной стратегии, у вас не останется выбора кроме как использовать внешние решения по мониторингу ИБ сразу в нескольких облачных средах (например, Cisco CloudLock или Cisco Stealthwatch Cloud). Ну а в ряде случаев вы поймете, что выбранный вами (или навязанный вам) облачный провайдер не предлагает вообще никаких возможностей по мониторингу ИБ. Это неприятно, но тоже немало, так как позволяет адекватно оценивать уровень риска, связанный с работой с данным облаком.
Чтобы мониторить безопасность используемых вами облаков у вас есть всего три возможности:
Давайте посмотрим, какие особенности у каждого из этих вариантов. Но прежде нам необходимо понять общую схему, которая будет использоваться при мониторинге облачных платформ. Я бы выделил 6 основных компонентов процесса мониторинга ИБ в облаке:
Понимание этих компонентов позволит вам в дальнейшем оперативно определиться, что вы можете взять у своего провайдера, а что вам придется делать самому или с привлечением внешних консультантов.
Выше я уже написал, что очень многие облачные сервисы сегодня не предоставляют никакой возможности по мониторингу ИБ. Вообще, теме ИБ они уделяют не очень большое внимание. Например, один из популярных рооссийских сервисов по отправке в государственные органы отчетности через Интернет (специально не буду упоминать его имя). Весь раздел про безопасность этого сервиса крутится вокруг применения сертифицированных СКЗИ. Раздел по ИБ другого отечественного облачного сервиса по электронному документообороту не в пример больше. В нем говорится о сертификатах открытых ключей, сертифицированной криптографии, устранении web-уязвимостей, защите от DDoS-атак, применении МСЭ, резервном копировании и даже регулярном проведении аудита ИБ. Но о мониторинге ни слова, как и о возможности получения доступа к событиям ИБ, которые могут быть интересны клиентам этого поставщика услуг.
Вообще, по тому, как облачный провайдер описывает у себя на сайте и в документации вопросы ИБ, можно понять, насколько он вообще серьезно относится к этому вопросу. Например, если почитать руководства на продукты “Мой офис”, то там вообще нет ни слова про безопасность, а в документации на отдельный продукт “Мой офис. КС3”, предназначенный для защиты от несанкционированного доступа, есть обычное перечисление пунктов 17-го приказа ФСТЭК, который выполняет “Мой офис.КС3”, но не описано как выполняет и, самое главное, как интегрировать эти механизмы с корпоративной ИБ. Возможно такая документация и есть, но в публичном доступе, на сайте “Мой офис” я ее не нашел. Хотя может у меня просто доступа нет к этой секретной информации?..
У того же Битрикса ситуация на порядок лучше. В документации описаны форматы журналов событий и, что интересно, журнала вторжений, который содержит события, связанные с потенциальными угрозами для облачной платформы. Оттуда вы можете вытащить IP, имя пользователя или гостя, источник события, время, User Agent, тип события и т.п. Правда, работать с этими событиями вы можете либо из панели управления самим облаком, либо выгрузить данные в формате MS Excel. Автоматизировать работу с логами Битрикс сейчас затруднительно и вам придется часть работы выполнять вручную (выгрузка отчета и загрузка его в ваш SIEM). Но если вспомнить, что еще относительно недавно и такой возможности не было, то это большой прогресс. При этом хочу отметить, что и многие зарубежные облачные провайдеры предлагают схожий функционал “для начинающих” — либо смотри логи глазами через панель управления, либо выгружай данные к себе (правда, большинство выгружают данные в формате .csv, а не Excel).
Если не рассматривать вариант с отсутствием логов, то облачные провайдеры обычно предлагают вам три варианта для мониторинга событий безопасности — панели мониторинга, выгрузка данных и доступ к ним по API. Первое вроде как решает многие проблемы за вас, но это не совсем так, — при наличии нескольких журналов приходится переключаться между отображающими их экранами, теряя общую картину. Кроме того, облачный провайдер врядли предоставит вам возможность корреляции событий безопасности и вообще анализа их с точки зрения безопасности (обычно вы имеете дело с сырыми данными, в которых разбираться вам надо самостоятельно). Исключения есть и о них мы поговорим дальше. Наконец, стоит поинтересоваться, а какие события фиксирует ваш облачный провайдер, в каком формате, и насколько они соответствуют вашему процессу мониторинга ИБ? Например, идентификация и аутентификация пользователей и гостей. Тот же Битрикс позволяет вам по данным событиям зафиксировать дату и время данного события, имя пользователя или гостя (при наличии модуля “Веб-аналитика”), объект, к котором осуществлен доступ и другие типичные для web-сайта элементы. Но корпоративным службам ИБ может потребоваться информация о том, с доверенного ли устройства заходил пользователь в облако (например, в корпоративной сети такую задачу реализует Cisco ISE). А такая простая задача, как функция гео-IP, которая поможет определить не украдена ли учетная запись пользователя облачного сервиса? И даже если облачный провайдер вам ее предоставит, то этого мало. Тот же Cisco CloudLock не просто анализирует геолокацию, а использует для этого машинное обучение и анализирует исторические данные по каждому пользователю и отслеживает различные аномалии в попытках идентификации и аутентификации. Схожий функционал есть только у MS Azure (при наличии соответствующей подписки).
Есть еще одна сложность — так как для многих облачных провайдеров мониторинг ИБ — это новая тема, которой они только-только начинают заниматься, то они постоянно что-то меняют в своих решениях. Сегодня у них одна версия API, завтра другая, послезавтра третья. К этому тоже надо быть готовым. Тоже самое и с функциональностью, которая может меняться, что надо учитывать в своей системе мониторинга ИБ. Например, у Amazon сначала были отдельные сервисы мониторинга событий в облаке — AWS CloudTrail и AWS CloudWatch. Потом появился отдельный сервис мониторинга событий именно ИБ — AWS GuardDuty. Спустя какое-то время Amazon запустил новую систему управления Amazon Security Hub, которая включает в себя анализ данных, получаемых от GuardDuty, Amazon Inspector, Amazon Macie и ряда других. Другой пример, — инструмент интеграции логов Azure с SIEM — AzLog. Им активно пользовались многие вендоры SIEM, пока в 2018-м году Microsoft не объявила о прекращении его развития и поддержки, что поставило многих клиентов, пользовавшихся этим инструментом перед проблемой (как она разрешилась, мы поговорим далее).
Поэтому внимательно отслеживайте все функции по мониторингу, которые предлагает вам ваш облачный провайдер. Или доверьтесь внешним поставщикам решений, которые будут выступать в качестве посредников между вашим SOCом и облаком, которое вы хотите мониторить. Да, это будет дороже (хотя не всегда), но зато вы переложите всю ответственность на чужие плечи. Или не всю?.. Вспомним про концепцию разделяемой безопаности и поймем, что ничего переложить мы не сможем — придется самостоятельно разбираться в том, как разные облачные провайдеры обеспечивают мониторинг ИБ ваших данных, приложений, виртуальных машин и иных ресурсов, размещенных в облаке. И начнем мы с того, что предлагает Amazon в этоой части.
Да-да, я понимаю, что Amazon — это не самый лучший пример ввиду того, что это сервис американский и его могут блокировать в рамках борьбы с экстремизмом и распространением запрещенной на территории России информацией. Но в данной публикации я бы хотел просто показать, насколько отличаются разные облачные платформы по возможностям мониторинга ИБ и на что стоит обращать внимание при передаче своих ключевых процессов в облака с точки зрения безопасности. Ну а если какие-то из российских разработчиков облачных решений подчерпнут что-нибудь полезное для себя, то это вообще будет отлично.
Сначала надо сказать, что Amazon — это не неприступная крепость. С его клиентами регулярно случаются различные инциденты. Например, у Deep Root Analytics украли имена, адреса, даты рождения, телефоны 198 миллионов избирателей. У израильской компании Nice Systems украли 14 миллионов записей об абонентах Verizon. При этом встроенные возможности AWS позволяют вам обнаруживать широкий спектр инцидентов. Например:
Такое несоответствие связано с тем, что за безопасность данных заказчика, как мы выяснили выше, отвечает сам заказчик. И если он не побеспокоился о включении защитных механизмов и не включил инструменты мониторинга, то об инциденте он узнает только из СМИ или от своих клиентов.
Для выявления инцидентов можно использовать широкий спектр различных сервисов по мониторингу, разработанных Amazon (хотя они часто дополняются внешними инструментами, например, osquery). Так, в AWS отслеживаются все действия пользователей, независимо от того, как они осуществляются — через консоль управления, командную строку, SDK или иные сервисы AWS. Все записи о действиях каждой учетной записи AWS (включая имя пользователя, действие, сервис, параметры активности и ее результат) и использовании API доступны через сервис AWS CloudTrail. Вы можете просматривать эти события (например, вход в консоль AWS IAM) с консоли CloudTrail, анализировать их с помощью Amazon Athena или “отдать” их внешним решениям, например, Splunk, AlienVault и т.п. Сами логи AWS CloudTrail помещаются в вашу корзину AWS S3.
Два других сервиса AWS обеспечивают еще ряд важный возможностей по мониторингу. Во-первых, Amazon CloudWatch — это сервис мониторинга ресурсов и приложений AWS, который позволяет среди прочего выявлять и различные аномалии в вашем облаке. Все встроенные сервисы AWS, такие как Amazon Elastic Compute Cloud (сервера), Amazon Relational Database Service (базы данных), Amazon Elastic MapReduce (анализ данных) и еще 30 других сервисов Amazon, используют Amazon CloudWatch для хранения своих логов. Разработчики могут использовать открытый API от Amazon CloudWatch для добавления функции мониторинга журналов в пользовательские приложения и службы, что позволяет расширить спектр анализируемых событий в контексте ИБ.
Во-вторых, служба VPC Flow Logs позволяет анализировать сетевой трафик, отправляемый или получаемый вашими серверами AWS (снаружи или изнутри), а также между микросервисами. Когда какой-либо из ваших ресурсов AWS VPC взаимодействует с сетью, служба VPC Flow Logs записывает сведения о сетевом трафике, включая сетевой интерфейс источника и назначения, а также IP-адреса, порты, протокол, количество байтов и количество пакетов, которые вы видели. Те, кто имеет опыт работы с локальной сетевой безопасностью, признают это аналогом потоков NetFlow, которые могут создаваться коммутаторами, маршрутизаторами и межсетевыми экранами корпоративного уровня. Эти журналы важны для целей мониторинга ИБ, потому что они в отличие от событий о действиях пользователей и приложений, позволяет не пропускать еще и сетевое взаимодействие в виртуальной частной облачной среде AWS.
Таким образом, эти три службы AWS — AWS CloudTrail, Amazon CloudWatch и VPC Flow Logs — вместе обеспечивают достаточно эффективное представление об использовании вашей учетной записи, поведении пользователей, управлении инфраструктурой, активности приложений и служб, а также сетевой активности. Например, с их помощью можно детектировать следующие аномалии:
Amazon Web Services для целей кибербезопасности разработал также и иные сервисы, которые позволяют решать многие иные задачи. Например, в AWS есть встроенный сервис для аудита политик и конфигураций — AWS Config. Этот сервис обеспечивает непрерывный аудит ваших ресурсов AWS и их конфигураций. Рассмотрим простой пример: предположим, что вы хотите убедиться, что пароли пользователей отключены на всех ваших серверах и доступ возможен только на основе сертификатов. AWS Config позволяет легко проверить это для всех ваших серверов. Есть и другие политики, которые могут быть применены к вашим облачным серверам: «Ни один сервер не может использовать порт 22», «Только администраторы могут изменять правила межсетевого экрана» или «Только пользователь Ивашко может создавать новые учетные записи пользователей, и он может делать это только по вторникам». Летом 2016 года сервис AWS Config был расширен для автоматизации обнаружения нарушений разработанных политик. AWS Config Rules — это, по сути, непрерывные запросы конфигурации используемых вами сервисов Amazon, которые генерируют события в случае нарушения соответствующих политик. Например, вместо того, чтобы периодически выполнять запросы AWS Config для проверки того, что все диски виртуального сервера зашифрованы, AWS Config Rules можно использовать для постоянной проверки серверных дисков на предмет выполнения этого условия. И, что самое важное, в контексте данной публикации, любые нарушения генерят события, которые могут быть проанализированы вашей службой ИБ.
Есть в AWS и свои эквиваленты традиционным корпоративным решениям по ИБ, которые также генерят события безопасности, которые вы можете и должны анализировать:
Я не буду подробно расписывать все сервисы Amazon, которые могут быть полезны в контексте информационной безопасности. Главное, что надо понять, что все они могут генерить события, которые мы можем и должны анализировать в контексте ИБ, привлекая для этого как встроенные возможности самого Amazon, так и внешние решения, например, SIEM, которые могут забирать события безопасности в ваш центр мониторинга и анализировать их там наряду с событиями от других облачных сервисов или от внутренней инфраструктуры, периметра или мобильных устройств.
В любом случае все начинается с источников данных, которые предоставляют вам события ИБ. К таким источникам можно среди прочего отнести:
Amazon, предлагая такой спектр источников событий и инструментов по их генерации, при этом сильно ограничен в возможностях по анализу собранных данных в контексте ИБ. Вам придется самостоятельно изучать имеющиеся логи, выискивая в них соответствующие индикаторы компрометации. AWS Security Hub, который недавно запустил Amazon, призван решить эту проблему, став этаким облачным SIEM для AWS. Но пока он находится только в начале своего пути и ограничен как числом источников, с которыми он работает, так и иными ограничениями, установленными архитектурой и подписками самого Amazon.
Не хочу вступать в долгую полемику, какой из трех облачных провайдеров (Amazon, Microsoft или Google) лучше (тем более, что каждый из них имеет все-таки свою определенную специфику и подходит для решения своих задач); сосредоточимся на возможностях по мониторингу ИБ, которые предоставляют эти игроки. Надо признать, что Amazon AWS был одним из первых в этом сегменте и поэтому продвинулся дальше всех в части своих функций по ИБ (хотя многие признают, что пользоваться ими сложновато). Но это не значит, что мы проигнорируем возможности, которые предоставляют нам Microsoft с Google.
Продукция Microsoft всегда отличалась своей “открытостью” и в Azure ситуация аналогичная. Например, если AWS и GCP всегда исходят из концепции “все, что не разрешено, запрещено”, то у Azure подход прямо противоположный. Например, создавая виртуальную сеть в облаке и виртуальную машину в ней, все порты и протоколы по умолчанию открыты и разрешены. Поэтому, вам придется потратить чуть больше усилий по первоначальной настройке системы разграничения доступа в облаке от Microsoft. И это же накладывает на вас более жесткие требования в части мониторинга активности в облаке Azure.
У AWS есть особенность, связанная с тем, что когда вы мониторите свои виртуальные ресурсы, то если они находятся в разных регионах, то у вас появляются трудности в объединении всех событий и их единого анализа, для устранения которых вам надо прибегать к различным ухищрениям, типа создания собственного кода для AWS Lambda, который будет переносить события между регионами. В Azure такой проблемы нет — его механизм Activity Log отслеживает всю активность в рамках всей организации без ограничений. Тоже самое касается и AWS Security Hub, который был недавно разработан Amazon для консолидации многих функций безопасности в рамках единого центра безопасности, но только в рамках своего региона, что, правда, для России неактуально. В Azure присутствует свой Security Center, который не связан региональными ограничениями, предоставляя доступ ко всем функциям безопасности облачной платформы. Более того, для различных локальных команд он может предоставить свой набор защитных возможностей и, в том числе, управляемых ими осбытий безопасности. AWS Security Hub еще только стремится к тому, чтобы стать похожим на Azure Security Center. Но стоит добавить и ложку дегтя — вы можете выжать из Azure очень многое из того, что было описано ранее в AWS, но наиболее удобно это делается только для Azure AD, Azure Monitor и Azure Security Center. Все остальные защитные механизмы Azure, включая и анализ событий безопасности, управляются пока не самым удобным образом. Отчасти проблему решает API, который пронизывает все сервисы Microsoft Azure, но это потребует от вас дополнительных усилий по интеграции вашего облака с вашим SOC и наличия квалифицированных специалистов (собственно, как и с любым другим. SIEM, работающим с облачными API). Некоторые SIEM, о чем речь пойдет дальше, уже поддерживают Azure и могут автоматизировать задачу его мониторинга, но и с ним есть свои сложности — не все они могут забирать все логи, которые есть у Azure.
Сбор событий и их мониторинг в Azure предоставляется с помощью сервиса Azure Monitor, который является основным инструментом сбора, хранения и анализа данных в облаке Microsoft и его ресурсах — репозитории Git, контейнерах, виртуальных машинах, приложениях и т.п. Все данные, собираемаые Azure Monitor делятся на две категории — метрики, собираемые в реальном времени и описывающие ключевые показатели деятельности облака Azure, и журналы регистрации, содержащие данные, организованные в записи, характеризующие те или иные аспекты деятельности ресурсов и сервисов Azure. Кроме того, с помощью Data Collector API сервис Azure Monitor может собирать данные с любого REST-источника для выстраивания собственных сценариев мониторинга.
Вот несколько источников событий безопасности, которые предлагает вам Azure и к которым вы можете получить доступ через Azure Portal, CLI, PowerShell или REST API (а некоторые только через Azure Monitor / Insight API):
Для мониторинга вы можете использовать внешние SIEM или встроенный Azure Monitor и его расширения. Про системы управления событиями ИБ мы еще поговорим, а пока посмотрим, что нам предлагает сам Azure для анализа данных в контексте безопасности. Основным экраном для всего, что связано с безопасностью в Azure Monitor, является Log Analytics Security and Audit Dashboard (бесплатная версия поддерживает хранение ограниченного объема событий всего одну неделю). Эта панель поделена на 5 основных областей, визуализирующих сводную статистику по тому, что происходит в используемой вами облачной среде:
В качестве расширений Azure Monitor можно назвать Azure Key Vault (защита криптографических ключей в облаке), Malware Assessment (анализ защиты от вредоносного кода на виртуальных машинах), Azure Application Gateway Analytics (анализ, среди прочего, логов облачного межсетевого экрана) и т.п. Эти инструменты, обогащенные определенными правилами обработки событий, позволяют визуализировать различные аспекты деятельности облачных сервисов, в том числе и безопасности, и выявлять те или иные отклонения от работы. Но, как это часто бывает, любой дополнительный функционал требует соответствующей платной подписки, что потребует от вас соответствующих финансовых вливаний, которые вам надо планировать заранее.
У Azure есть ряд встроенных возможностей по мониторингу угроз, которые интегрированы в Azure AD, Azure Monitor и Azure Security Center. Среди них, например, обнаружение взаимодействия виртуальных машин с известными вредоносными IP (за счет наличия интеграции с сервисами Threat Intelligence от Microsoft), обнаружение вредоносных программ в облачной инфраструктуре за счет получения сигналов тревоги от виртуальных машин, размещенных в облаке, атаки типа “подбор пароля” на виртуальные машины, уязвимости в конфигурации системы идентификации пользователей, вход в систему с анонимайзеров или зараженных узлов, утечка учетных записей, вход в систему с непривычных местоположений и т.п. Azure сегодня — один из немногих облачных провайдеров, кто предлагает вам встроенные возможности Threat Intelligence для обогащения собранных событий ИБ.
Как уже было сказано выше, защитный функционал и, как следствием, генерируемые им события безопасности, доступен не всем пользователям одинаково, а требует наличия определенной подписки, включающей нужный вам функционал, который и генерит соответствующие события для мониторинга ИБ. Например, часть описанных в предыдущем абзаце функций по мониторингу аномалий в учетных записях доступна только в премиум лицензии P2 для сервиса Azure AD. Без нее вам, как и в случае AWS, придется анализировать собранные события безопасности «вручную». И, также, в зависимости от типа лицензии на Azure AD вам будет доступны не все события для анализа.
На портале Azure вы можете управлять как поисковыми запросами к интересующим вас журналам регистрации, так и настраивать дашборды для визуализации ключевых показателей ИБ. Кроме того, там же вы можете выбирать расширения Azure Monitor, которые позволяют вам расширить функциональность логов Azure Monitor и получить более глубокий анализ событий с точки зрения безопасности.
Если вам нужна не только возможность работы с логами, но всесторонний центр безопасности вашей облачной платформы Azure, включая управление политиками ИБ, то можно говорить о необходимости работы с Azure Security Center, большинство полезных функций которого доступно за отдельные деньги, например, обнаружение угроз, мониторинг вне Azure, оценка соответствия и т.п. (в бесплатной версии вам доступна только оценка безопасности и рекомендации по устранению выявленных проблем). Он консолидирует все вопросы безопасности в одном месте. По сути можно говорить о более высоком уровне ИБ, чем вам предоставляет Azure Monitor, так как в данном случае собранные по всей вашей облачной фабрике данные обогащаются с помощью множества источников, таких как Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) и Microsoft Security Response Center (MSRC), на которые накладываются различные навороченные алгоритмы машинного обучения и поведенческой аналитики, что в итоге должно повысить эффективность обнаружения угроз и реагирования на них.
Есть у Azure и свой SIEM — он появился в начале 2019-года. Это Azure Sentinel, который опирается на данные от Azure Monitor, а также может интегрироваться с. внешними решениями по безопасности (например, NGFW или WAF), список которых постоянно пополняется. Помимо этого, за счет интеграции Microsoft Graph Security API у вас появляется возможность подключать к Sentinel собственные фиды Threat Intelligence, что обогащает возможности по анализу инцидентов в вашем облаке Azure. Можно утверждать, что Azure Sentinel является первым «родным» SIEM, который появился у облачных провайдеров (тот же Splunk или ELK, которые можно разместить в облаке, например, AWS, все-таки разработаны не поставщиками традиционных облачных услуг). Azure Sentinel и Security Center можно было бы назвать SOCом для облака Azure и ими можно было бы и ограничиться (с определенными оговорками), если бы у вас больше не было никакой инфраструктуры и вы все свои вычислительные ресурсы перенесли в облако и это было бы облако Microsoft Azure.
Но так как встроенных возможностей Azure (даже при наличии подписки на Sentinel) часто не хватает для целей мониторинга ИБ и интеграции этого процесса с иными источниками событий безопасности (как облачными, так и внутренними), возникает необходимость в экспорте собранных данных во внешние системы, к числу которых может относиться и SIEM. Делается это как с помощью API, так и с помощью специальных расширений, которые официально имеются в данный момент только у следующих SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight и ELK. Еще недавно, таких SIEM было больше, но с 1-го июня 2019 года Microsoft прекратил поддержку Azure Log Integration Tool (AzLog), который на заре существования Azure и при отсутствии нормальной стандартизации работы с логами (Azure Monitor еще даже не существовало) позволял легко интегрировать внешние SIEM с облаком Microsoft. Сейчас ситуация поменялась и Microsoft рекомендует платформу Azure Event Hub, как основной инструмент интеграции для остальных SIEM. Многие уже осуществили такую интеграцию, но будьте внимательны, — они могут захватывать не все логи Azure, а лишь некоторые (смотрите в документации на вашу SIEM).
Завершая краткий экскурс в Azure, хочу дать общую рекомендацию по этому облачному сервису, — прежде чем что-то утверждать относительно функций мониторинга ИБ в Azure стоит их настроить очень внимательно и протестировать, что они работают так, как написано в документации и как вам рассказали консультанты Microsoft (а у них могут быть разные взгляды на работоспособность функций Azure). При наличии финансовых возможностей из Azure можно выжать очень много полезного в части мониторинга ИБ. Если же ваши ресурсы ограничены, то как и в случае AWS, вам придется рассчитывать только на собственные силы и сырые данные, которые вам предоставляет Azure Monitor. И помните, что многие функции мониторинга стоят денег и с ценовой политикой лучше ознакомиться заранее. Например, бесплатно вы можете хранить данные за 31 день объемом не более 5 Гб на заказчика — превышение этих значений потребует от вас дополнительно раскошелиться (примерно 2+ доллара за хранение каждого дополнительного Гб от заказчика и 0,1 доллара за хранение 1 Гб каждый дополнительный месяц). Работа с телеметрией приложений и метриками также может потребовать дополнительных финансовых средств, как и работа с алертами и уведомлениями (бесплатно доступен определенный лимит, которого может и не хватить для ваших нужд).
Google Cloud Platform на фоне AWS и Azure выглядит совсем юнцом, но это отчасти и хорошо. В отличие от AWS, который наращивал свои возможности, в том числе и защитные, постепенно, имея проблемы с централизацией; GCP, как и Azure, гораздо лучше управляется централизовано, что снижает число ошибок и время внедрения на предприятии. С точки зрения безопасности, GCP находится, как ни странно, между AWS и Azure. У него также единая для всей организации регистрация событий, но она неполна. Некоторые функции до сих еще в бета-режиме, но постепенно этот недостаток должен быть устранен и GCP станет более зрелой платформой с точки зрения мониторинга ИБ.
Основным инструментом для регистрации событий в GCP является Stackdriver Logging (аналог Azure Monitor), который позволяет вам собирать события по всей вашей облачной инфраструктуре (а также с AWS). С точки зрения безопасности в GCP каждая организация, проект или папка имеет четыре журнала регистрации:
Пример журнала: Access Transparency
Доступ к указанным логам возможен несколькими путями (примерно также как и ранее рассмотренных Azure и AWS) — через интерфейс Log Viewer, через API, через Google Cloud SDK или через страницу Activity вашего проекта, по которому вас интересуют события. Таким же образом их можно и экспортировать во внешние решения для дополнительного анализа. Последнее делается через экспорт логов в хранилище BigQuery или Cloud Pub/Sub.
Помимо Stackdriver Logging платформа GCP предлагает еще функционал Stackdriver Monitoring, который позволяет отслеживать ключевые метрики (производительность, наработка на отказ, общее состояние и т.п.) облачных сервисов и приложений. Обработанные специальным образом и визуализированные данные могут облегчить поиск проблем в вашей облачной инфраструктуре, в том числе и в контексте безопасности. Но надо отметить, что функционал этот будет не очень богат именно в контексте ИБ, так как на сегодняшний день GCP не имеет аналога того же AWS GuardDuty и не может выделять среди всех регистрируемых событий именно плохие (Google разработал Event Threat Detection, но пока он находится в бете и говорить о его полезности рановато). Stackdriver Monitoring можно было бы задействовать как систему обнаружения аномалий, которые затем будут расследоваться для поиска причин их возникновения. Но в условиях нехватки на рынке квалифицированного в области ИБ GCP персонала, это задача на данный момент выглядит непростой.
Также стоит привести список некоторых модулей по ИБ, которые могут быть применены в рамках вашего облака GCP, и которые схожи с тем, что предлагает AWS:
Многие из этих модулей генерят события безопасности, которые могут быть отправлены в хранилище BigQuery для анализа или экспорта в другие системы, включая и SIEM. Как уже писалось выше, GCP — активно развиваемая платформа и сейчас Google разрабатывает ряд новых модулей по ИБ для своей платформы. Среди них Event Threat Detection (сейчас доступен в бете), которые сканирует логи Stackdriver в поисках следов несанкционированной активности (аналог GuardDuty в AWS), или Policy Intelligence (доступен в альфе), который позволит разрабатывать интеллектуальные политики доступа к ресурсам GCP.
Я сделал небольшой обзор встроенных возможностей по мониторингу в популярных облачных платформах. Но есть ли у вас специалисты, которые способны работать с “сырыми” логами IaaS- провайдера (не все готовы покупать расширенные возможности AWS или Azure или Google)? Кроме того, многим известна пословица “доверяй, но проверяй”, которая в области безопасности верна как никогда. Насколько вы доверяете встроенным возможностям облачного провайдера, которые отдают вам события ИБ? Насколько они вообще фокусируются на ИБ?
Иногда стоит посмотреть в сторону наложенных решений по мониторингу облачных инфраструктур, которые могут дополнить встроенную безопасность облака, а иногда такие решения — единственный вариант получить данные по безопасности ваших данных и приложений, размещенных в облаке. Кроме того, они просто удобнее, так как берут на себя все задачи по анализу нужных логов, генерируемых разными облачными сервисами разных облачных провайдеров. В качестве примера такого наложенного решения можно привести Cisco Stealthwatch Cloud, который сфокусирован на единственной задаче — мониторинг аномалий ИБ в облачных средах, среди которых не только Amazon AWS, Microsoft Azure и Google Cloud Platform, но и частные облака.
AWS предоставляет гибкую платформу для вычислений, но эта гибкость приводит к тому, что компаниями легче совершать ошибки, приводящие к проблемам безопасности. И разделяемая модель ИБ только способствует этому. Запуск в облаке ПО с неизвестными уязвимостями (с известными может бороться, например, AWS Inspector или GCP Cloud Scanner), слабые пароли, некорректные конфигурации, инсайдеры и т.п. И все это отражается на поведении облачных ресурсов, за которыми может наблюдать Cisco Stealthwatch Cloud, являющийся системой мониторинга ИБ и обнаружения атак в. публичных и частных облаках.
Одной из ключевых особенностей Cisco Stealthwatch Cloud является возможность моделирования сущностей. С его помощью можно создать программную модель (то есть имитацию практически в реальном времени) каждого из ваших облачных ресурсов (неважно, будет ли это AWS, Azure, GCP или что-то иное). К ним могут относиться сервера и пользователи, а также типы ресурсов, специфичные для вашей облачной среды, такие как группы безопасности и группы автоматического масштабирования сервисов (auto-scale). Эти модели используют в качестве входных данных структурированные потоки данных, предоставляемые облачными сервисами. Например, для AWS это будут VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda и AWS IAM. Моделирование сущностей автоматически обнаруживает роль и поведение любого из ваших ресурсов (можно говорить о профилировании всей облачной активности). Среди таких ролей — мобильное устройство Android или Apple, сервер Citrix PVS, RDP-сервер, почтовый шлюз, клиент VoIP, терминальный сервер, контроллер домена и т.п. Затем он непрерывно отслеживает их поведение, чтобы определить, когда происходит рискованное или угрожающее безопасности поведение. Вы можете идентифицировать подбор пароля, DDoS-атаки, утечки данных, нелегальный удаленный доступ, действие вредоносного кода, сканирование уязвимостей и другие угрозы. Например, вот как выглядит обнаружение попытки удаленного доступа из нетипичной для вашей организации страны (Южная Корея) к кластеру Kubernetes по SSH:
А вот так выглядит предполагаемая утечка информации из базы данных Postgress в страну, взаимодействие с которой ранее не встречалось:
Наконец, вот так выглядит слишком большое число неудачных попыток доступа по SSH из Китая и Индонезии с внешнего удаленного устройства:
Или, предположим, что экземпляр сервера в VPC, согласно политике, никогда не должен быть точкой назначения для удаленного входа в систему. Предположим далее, что на этом компьютере произошел удаленный вход в систему из-за ошибочного изменения политики правил межсетевого экрана. Функция моделирования сущностей будет обнаруживать и сообщать об этой активности («Необычный удаленный доступ») в почти реальном времени и указывать на конкретный вызов API AWS CloudTrail, Azure Monitor или GCP Stackdriver Logging (включая имя пользователя, дату и время, среди прочих деталей), которые вызвали изменение в правило МСЭ. А затем эта информация может быть отдана в SIEM для анализа.
Аналогичные возможности реализуются для любой облачной среды, поддерживаемой Cisco Stealthwatch Cloud:
Моделирование сущностей — это уникальная форма автоматизации безопасности, которая может обнаружить ранее неизвестную проблему с вашими людьми, процессами или технологиями. Например, она позволяет обнаруживать среди прочего такие проблемы безопасности, как:
Обнаруженное событие ИБ может быть передано в виде соответствующего тикета в Slack, Cisco Spark, систему управления инцидентами PagerDuty, а также отдано в различные SIEM, среди которых Splunk или ELK. Резюмируя, можно сказать, что если ваша компания использует мультиоблачную стратегию и не ограничивается каким-то одним облачным провайдером, возможности по мониторингу ИБ, которых описывались выше, то применение Cisco Stealthwatch Cloud является неплохим вариантом получить унифицированный набор возможностей по мониторингу ведущих облачных игроков — Amazon, Microsoft и Google. Самое интересное, что если сравнивать цены на Stealthwatch Cloud с продвинутыми лицензиями на мониторинг ИБ в AWS, Azure или GCP, то может оказаться так, что решение Cisco окажется даже дешевле встроенных возможностей решений Amazon, Microsoft и Google. Парадоксально, но это так. И чем больше облаков и их возможностей вы используете, тем очевиднее будет преимущество консолидированного решения.
Кроме того, Stealthwatch Cloud может мониторить и частные облака, развернутые у вас в организации, например, на базе контейнеров Kubernetes или путем мониторинга потоков Netflow или сетевого трафика, получаемого через зеркалирование в сетевом оборудовании (даже отечественного производства), данных AD или DNS-серверов и т.п. Все эти данные будут обогащаться информацией Threat Intelligence, собираемой подразделением Cisco Talos, являющемся крупнейшей в мире неправительственной группой исследователей угроз ИБ.
Это позволяет вам реализовать единую систему мониторинга как публичных, так и гибридных облаков, которые может использовать ваша компания. Собранная информация затем может быть проанализирована с помощью встроенных возможностей Stealthwatch Cloud или отправлена в ваш SIEM (по умолчанию поддерживаются Splunk, ELK, SumoLogic и ряд других).
На этом мы завершим первую часть статьи, в которой я рассмотрел встроенные и внешние инструменты по мониторингу ИБ IaaS/PaaS-платформ, которые позволяют нам оперативно обнаруживать и реагировать на инциденты, происходящие в облачных средах, которые выбрало наше предприятие. Во второй части мы продолжим тему и рассмотрим варианты мониторинга SaaS-платформ на примере Salesforce и Dropbox, а также попробуем подытожить и собрать все вместе, создав единую систему мониторинга ИБ разных облачных провайдеров.
Допустим, ваша компания перенесла часть своей инфраструктуры в облако… Стоп. Не так. Если инфраструктура перенесена, а вы только сейчас задумываетесь о том, как будете ее мониторить, то вы уже проиграли. Если это не Amazon, Google или Microsoft (и то с оговорками), то вероятно у вас не будет много возможностей по мониторингу ваших данных и приложений. Хорошо, если вам дадут возможность работать с логами. Иногда данные о событиях безопасности будут доступны, но у вас к ним не будет доступа. Например, Office 365. Если у вас самая дешевая лицензия E1, то события безопасности вам вообще недоступны. При наличии лицензии E3 у вас данные хранятся всего за 90 дней и только при наличии E5 — длительность логов доступна в течение года (правда, тут тоже есть свои нюансы, связанные с необходимостью отдельно запрашивать ряд функций по работе с логами у поддержки Microsoft). Кстати, лицензия E3 гораздо слабее в части функций мониторинга, чем корпоративный Exchange. Чтобы добиться того же уровня, вам нужна лицензия E5 или дополнительная лицензия Advanced Compliance, которые могут потребовать дополнительных денег, которые не были учтены в вашей финансовой модели перехода к облачной инфраструктуре. И это только один пример недооценки вопросов, связанных с мониторингом ИБ облаков. В этой статье я, не претендуя на полноту изложения, хочу обратить внимания на некоторые нюансы, которые стоит учесть при выборе облачного провайдера с точки зрения безопасности. А в конце статьи будет дан чеклист, который стоит выполнить, прежде чем считать, что вопрос мониторинга облачной ИБ у вас решен.
Можно выделить несколько типичных проблем, приводящих к инцидентам в облачных средах, реагировать на которые службы ИБ не успевают или вообще не видят их:
- Логи безопасности не существуют. Это достаточно распространенная ситуация, особенно у начинающих игроков рынка облачных решений. Но и ставить крест на них сразу не стоит. Небольшие игроки, особенно отечественные, более чутки к требованиям заказчиков и могут оперативно реализовать какие-то востребованные функции, изменив утвержденный роадмап на свои продукты. Да, это не будет аналогом GuardDuty от Amazon или модулем “Проактивной защиты” от Битрикс, но хоть что-то.
- ИБ не знает, где хранятся логи или к ним нет доступа. Тут необходимо вступать в переговоры с поставщиком облачных услуг — возможно, он и предоставит такую информацию, если посчитает клиента значимым для себя. Но в целом, это не очень хорошо, когда доступ к логам предоставляется “по особому решению”.
- Бывает и так, что логи у облачного провайдера есть, но они обеспечивают ограниченный мониторинг и регистрацию событий, недостаточные для обнаружения всех инцидентов. Например, вам могут отдать только логи изменений на сайте или логи попыток аутентификации пользователей, но иные события, например, о сетевом трафике, не отдавать, что скроет от вас целый пласт событий, характеризующих попытки взлома вашей облачной инфраструктуры.
- Логи есть, но доступ к ним сложно автоматизировать, что заставляет их мониторить не непрерывно, а по расписанию. А если еще загрузить логи нельзя в автоматическом режиме, то выгрузка логов, например, в формате Excel (как у ряда отечественных поставщиков облачных решений), может и вовсем привести к нежеланию возиться с ними со стороны корпоративной службы ИБ.
- Нет мониторинга логов. Это, пожалуй, самая непонятная причина возникновения инцидентов ИБ в облачных средах. Вроде и логи есть, и автоматизировать доступ к ним можно, а никто этого не делает. Почему?
Концепция разделяемой безопасности облака
Переход в облака — это всегда поиск баланса между желанием сохранить контроль над инфраструктурой и передачей ее в более профессиональные руки облачного провайдера, который специализируется на ее поддержании. И в области безопасности облачных сред этот баланс тоже необходимо искать. Тем более, что в зависимости от используемой модели предоставления облачных услуг (IaaS, PaaS, SaaS) этот баланс будет все время разным. При любом раскладе надо помнить, что все облачные провайдеры сегодня следуют так называемой модели разделяемой ответственности и разделяемой ИБ. За что-то отвечает облако, за что-то отвечает клиент, разместивший в облаке свои данные, свои приложения, свои виртуальные машины и иные ресурсы. Необдуманно было бы рассчитывать, что уйдя в облако, мы переложим всю ответственность на провайдера. Но и выстраивать всю безопасность самостоятельно при переходе в облако тоже неразумно. Необходим баланс, который будет зависеть от множества факторов: — стратегии управления рисками, модели угроз, имеющихся у облачного провайдера защитных механизмов, законодательства и пр.
Например, классификация данных, размещаемых в облаке, — это всегда ответственность заказчика. Облачный провайдер или внешний поставщик услуг ему может только помочь с инструментарием, который будет помогать маркировать данные в облаке, выявлять нарушения, удалять нарушающие законодательство данные или маскировать их с помощью того или иного метода. С другой стороны физическая безопасность — это всегда ответственность облачного провайдера, которой он не может поделиться с клиентами. А вот все, что находится между данными и физической инфраструктурой — как раз и является предметом обсуждения данной статьи. Например, доступность облака — это ответственность провайдера, а настройки правил МСЭ или включение шифрования — это уже ответственность клиента. В этой статьей мы попробуем посмотреть, какие механизмы мониторинга ИБ предоставляют сегодня различные популярные в России облачные провайдеры, каковы особенности их применения, и когда стоит посмотреть в сторону внешних наложенных решений (например, Cisco E-mail Security), расширяющие возможности вашего облака в части кибербезопасности. В ряде случаев, особенно в случае следования мультиоблачной стратегии, у вас не останется выбора кроме как использовать внешние решения по мониторингу ИБ сразу в нескольких облачных средах (например, Cisco CloudLock или Cisco Stealthwatch Cloud). Ну а в ряде случаев вы поймете, что выбранный вами (или навязанный вам) облачный провайдер не предлагает вообще никаких возможностей по мониторингу ИБ. Это неприятно, но тоже немало, так как позволяет адекватно оценивать уровень риска, связанный с работой с данным облаком.
Жизненный цикл мониторинга безопасности облака
Чтобы мониторить безопасность используемых вами облаков у вас есть всего три возможности:
- полагаться на инструментарий, предоставляемый вашим облачным провайдером,
- воспользоваться решениями третьих фирм, которые будут мониторить используемые вами IaaS, PaaS или SaaS-платформы,
- строить свою собственную инфраструктуру мониторинга облачных сред (только для IaaS/PaaS-платформ).
Давайте посмотрим, какие особенности у каждого из этих вариантов. Но прежде нам необходимо понять общую схему, которая будет использоваться при мониторинге облачных платформ. Я бы выделил 6 основных компонентов процесса мониторинга ИБ в облаке:
- Подготовка инфраструктуры. Определение необходимых приложений и инфраструктуры для сбора событий, важных для ИБ, в хранилище.
- Сбор. На этом этапе события безопасности агрегируются из различных источников для их последующей передачи для обработки, хранения и анализа.
- Обработка. На этом этапе данные преобразуются и обогащаются для облегчения их последующего анализа.
- Хранение. Этот компонент отвечает за краткосрочное и долгосрочное хранение собранных обработанных и “сырых” данных.
- Анализ. На этом этапе вы имеете возможность обнаруживать инциденты и реагировать на них в автоматическом или ручном режиме.
- Отчетность. Этот этап помогает сформировать для заинтересованных сторон (руководства, аудиторов, облачного провайдера, клиентов и т.п.) ключевые показатели, помогающие нам принимать те или иные решения, например, смена провайдера или усиление ИБ.
Понимание этих компонентов позволит вам в дальнейшем оперативно определиться, что вы можете взять у своего провайдера, а что вам придется делать самому или с привлечением внешних консультантов.
Встроенные возможности облачных сервисов
Выше я уже написал, что очень многие облачные сервисы сегодня не предоставляют никакой возможности по мониторингу ИБ. Вообще, теме ИБ они уделяют не очень большое внимание. Например, один из популярных рооссийских сервисов по отправке в государственные органы отчетности через Интернет (специально не буду упоминать его имя). Весь раздел про безопасность этого сервиса крутится вокруг применения сертифицированных СКЗИ. Раздел по ИБ другого отечественного облачного сервиса по электронному документообороту не в пример больше. В нем говорится о сертификатах открытых ключей, сертифицированной криптографии, устранении web-уязвимостей, защите от DDoS-атак, применении МСЭ, резервном копировании и даже регулярном проведении аудита ИБ. Но о мониторинге ни слова, как и о возможности получения доступа к событиям ИБ, которые могут быть интересны клиентам этого поставщика услуг.
Вообще, по тому, как облачный провайдер описывает у себя на сайте и в документации вопросы ИБ, можно понять, насколько он вообще серьезно относится к этому вопросу. Например, если почитать руководства на продукты “Мой офис”, то там вообще нет ни слова про безопасность, а в документации на отдельный продукт “Мой офис. КС3”, предназначенный для защиты от несанкционированного доступа, есть обычное перечисление пунктов 17-го приказа ФСТЭК, который выполняет “Мой офис.КС3”, но не описано как выполняет и, самое главное, как интегрировать эти механизмы с корпоративной ИБ. Возможно такая документация и есть, но в публичном доступе, на сайте “Мой офис” я ее не нашел. Хотя может у меня просто доступа нет к этой секретной информации?..
У того же Битрикса ситуация на порядок лучше. В документации описаны форматы журналов событий и, что интересно, журнала вторжений, который содержит события, связанные с потенциальными угрозами для облачной платформы. Оттуда вы можете вытащить IP, имя пользователя или гостя, источник события, время, User Agent, тип события и т.п. Правда, работать с этими событиями вы можете либо из панели управления самим облаком, либо выгрузить данные в формате MS Excel. Автоматизировать работу с логами Битрикс сейчас затруднительно и вам придется часть работы выполнять вручную (выгрузка отчета и загрузка его в ваш SIEM). Но если вспомнить, что еще относительно недавно и такой возможности не было, то это большой прогресс. При этом хочу отметить, что и многие зарубежные облачные провайдеры предлагают схожий функционал “для начинающих” — либо смотри логи глазами через панель управления, либо выгружай данные к себе (правда, большинство выгружают данные в формате .csv, а не Excel).
Если не рассматривать вариант с отсутствием логов, то облачные провайдеры обычно предлагают вам три варианта для мониторинга событий безопасности — панели мониторинга, выгрузка данных и доступ к ним по API. Первое вроде как решает многие проблемы за вас, но это не совсем так, — при наличии нескольких журналов приходится переключаться между отображающими их экранами, теряя общую картину. Кроме того, облачный провайдер врядли предоставит вам возможность корреляции событий безопасности и вообще анализа их с точки зрения безопасности (обычно вы имеете дело с сырыми данными, в которых разбираться вам надо самостоятельно). Исключения есть и о них мы поговорим дальше. Наконец, стоит поинтересоваться, а какие события фиксирует ваш облачный провайдер, в каком формате, и насколько они соответствуют вашему процессу мониторинга ИБ? Например, идентификация и аутентификация пользователей и гостей. Тот же Битрикс позволяет вам по данным событиям зафиксировать дату и время данного события, имя пользователя или гостя (при наличии модуля “Веб-аналитика”), объект, к котором осуществлен доступ и другие типичные для web-сайта элементы. Но корпоративным службам ИБ может потребоваться информация о том, с доверенного ли устройства заходил пользователь в облако (например, в корпоративной сети такую задачу реализует Cisco ISE). А такая простая задача, как функция гео-IP, которая поможет определить не украдена ли учетная запись пользователя облачного сервиса? И даже если облачный провайдер вам ее предоставит, то этого мало. Тот же Cisco CloudLock не просто анализирует геолокацию, а использует для этого машинное обучение и анализирует исторические данные по каждому пользователю и отслеживает различные аномалии в попытках идентификации и аутентификации. Схожий функционал есть только у MS Azure (при наличии соответствующей подписки).
Есть еще одна сложность — так как для многих облачных провайдеров мониторинг ИБ — это новая тема, которой они только-только начинают заниматься, то они постоянно что-то меняют в своих решениях. Сегодня у них одна версия API, завтра другая, послезавтра третья. К этому тоже надо быть готовым. Тоже самое и с функциональностью, которая может меняться, что надо учитывать в своей системе мониторинга ИБ. Например, у Amazon сначала были отдельные сервисы мониторинга событий в облаке — AWS CloudTrail и AWS CloudWatch. Потом появился отдельный сервис мониторинга событий именно ИБ — AWS GuardDuty. Спустя какое-то время Amazon запустил новую систему управления Amazon Security Hub, которая включает в себя анализ данных, получаемых от GuardDuty, Amazon Inspector, Amazon Macie и ряда других. Другой пример, — инструмент интеграции логов Azure с SIEM — AzLog. Им активно пользовались многие вендоры SIEM, пока в 2018-м году Microsoft не объявила о прекращении его развития и поддержки, что поставило многих клиентов, пользовавшихся этим инструментом перед проблемой (как она разрешилась, мы поговорим далее).
Поэтому внимательно отслеживайте все функции по мониторингу, которые предлагает вам ваш облачный провайдер. Или доверьтесь внешним поставщикам решений, которые будут выступать в качестве посредников между вашим SOCом и облаком, которое вы хотите мониторить. Да, это будет дороже (хотя не всегда), но зато вы переложите всю ответственность на чужие плечи. Или не всю?.. Вспомним про концепцию разделяемой безопаности и поймем, что ничего переложить мы не сможем — придется самостоятельно разбираться в том, как разные облачные провайдеры обеспечивают мониторинг ИБ ваших данных, приложений, виртуальных машин и иных ресурсов, размещенных в облаке. И начнем мы с того, что предлагает Amazon в этоой части.
Пример: Мониторинг ИБ в IaaS на базе AWS
Да-да, я понимаю, что Amazon — это не самый лучший пример ввиду того, что это сервис американский и его могут блокировать в рамках борьбы с экстремизмом и распространением запрещенной на территории России информацией. Но в данной публикации я бы хотел просто показать, насколько отличаются разные облачные платформы по возможностям мониторинга ИБ и на что стоит обращать внимание при передаче своих ключевых процессов в облака с точки зрения безопасности. Ну а если какие-то из российских разработчиков облачных решений подчерпнут что-нибудь полезное для себя, то это вообще будет отлично.
Сначала надо сказать, что Amazon — это не неприступная крепость. С его клиентами регулярно случаются различные инциденты. Например, у Deep Root Analytics украли имена, адреса, даты рождения, телефоны 198 миллионов избирателей. У израильской компании Nice Systems украли 14 миллионов записей об абонентах Verizon. При этом встроенные возможности AWS позволяют вам обнаруживать широкий спектр инцидентов. Например:
- воздействие на инфраструктуру (DDoS)
- компрометация узла (инжектирование команд)
- компрометация учетной записи и неавторизованный доступ
- неверная конфигурация и уязвимости
- незащищенные интерфейсы и API.
Такое несоответствие связано с тем, что за безопасность данных заказчика, как мы выяснили выше, отвечает сам заказчик. И если он не побеспокоился о включении защитных механизмов и не включил инструменты мониторинга, то об инциденте он узнает только из СМИ или от своих клиентов.
Для выявления инцидентов можно использовать широкий спектр различных сервисов по мониторингу, разработанных Amazon (хотя они часто дополняются внешними инструментами, например, osquery). Так, в AWS отслеживаются все действия пользователей, независимо от того, как они осуществляются — через консоль управления, командную строку, SDK или иные сервисы AWS. Все записи о действиях каждой учетной записи AWS (включая имя пользователя, действие, сервис, параметры активности и ее результат) и использовании API доступны через сервис AWS CloudTrail. Вы можете просматривать эти события (например, вход в консоль AWS IAM) с консоли CloudTrail, анализировать их с помощью Amazon Athena или “отдать” их внешним решениям, например, Splunk, AlienVault и т.п. Сами логи AWS CloudTrail помещаются в вашу корзину AWS S3.
Два других сервиса AWS обеспечивают еще ряд важный возможностей по мониторингу. Во-первых, Amazon CloudWatch — это сервис мониторинга ресурсов и приложений AWS, который позволяет среди прочего выявлять и различные аномалии в вашем облаке. Все встроенные сервисы AWS, такие как Amazon Elastic Compute Cloud (сервера), Amazon Relational Database Service (базы данных), Amazon Elastic MapReduce (анализ данных) и еще 30 других сервисов Amazon, используют Amazon CloudWatch для хранения своих логов. Разработчики могут использовать открытый API от Amazon CloudWatch для добавления функции мониторинга журналов в пользовательские приложения и службы, что позволяет расширить спектр анализируемых событий в контексте ИБ.
Во-вторых, служба VPC Flow Logs позволяет анализировать сетевой трафик, отправляемый или получаемый вашими серверами AWS (снаружи или изнутри), а также между микросервисами. Когда какой-либо из ваших ресурсов AWS VPC взаимодействует с сетью, служба VPC Flow Logs записывает сведения о сетевом трафике, включая сетевой интерфейс источника и назначения, а также IP-адреса, порты, протокол, количество байтов и количество пакетов, которые вы видели. Те, кто имеет опыт работы с локальной сетевой безопасностью, признают это аналогом потоков NetFlow, которые могут создаваться коммутаторами, маршрутизаторами и межсетевыми экранами корпоративного уровня. Эти журналы важны для целей мониторинга ИБ, потому что они в отличие от событий о действиях пользователей и приложений, позволяет не пропускать еще и сетевое взаимодействие в виртуальной частной облачной среде AWS.
Таким образом, эти три службы AWS — AWS CloudTrail, Amazon CloudWatch и VPC Flow Logs — вместе обеспечивают достаточно эффективное представление об использовании вашей учетной записи, поведении пользователей, управлении инфраструктурой, активности приложений и служб, а также сетевой активности. Например, с их помощью можно детектировать следующие аномалии:
- Попытки сканирования сайта, поиска бэкдоров, поиска уязвимостей через всплески “ошибок 404”.
- Injection-атаки (например, SQL injection) через всплески “ошибок 500”.
- Известные инструменты для атак sqlmap, nikto, w3af, nmap и т.п. через анализ поля User Agent.
Amazon Web Services для целей кибербезопасности разработал также и иные сервисы, которые позволяют решать многие иные задачи. Например, в AWS есть встроенный сервис для аудита политик и конфигураций — AWS Config. Этот сервис обеспечивает непрерывный аудит ваших ресурсов AWS и их конфигураций. Рассмотрим простой пример: предположим, что вы хотите убедиться, что пароли пользователей отключены на всех ваших серверах и доступ возможен только на основе сертификатов. AWS Config позволяет легко проверить это для всех ваших серверов. Есть и другие политики, которые могут быть применены к вашим облачным серверам: «Ни один сервер не может использовать порт 22», «Только администраторы могут изменять правила межсетевого экрана» или «Только пользователь Ивашко может создавать новые учетные записи пользователей, и он может делать это только по вторникам». Летом 2016 года сервис AWS Config был расширен для автоматизации обнаружения нарушений разработанных политик. AWS Config Rules — это, по сути, непрерывные запросы конфигурации используемых вами сервисов Amazon, которые генерируют события в случае нарушения соответствующих политик. Например, вместо того, чтобы периодически выполнять запросы AWS Config для проверки того, что все диски виртуального сервера зашифрованы, AWS Config Rules можно использовать для постоянной проверки серверных дисков на предмет выполнения этого условия. И, что самое важное, в контексте данной публикации, любые нарушения генерят события, которые могут быть проанализированы вашей службой ИБ.
Есть в AWS и свои эквиваленты традиционным корпоративным решениям по ИБ, которые также генерят события безопасности, которые вы можете и должны анализировать:
- обнаружение вторжений — AWS GuardDuty
- контроль утечек информации — AWS Macie
- EDR (хотя говорит об оконечных устройствах в облаке немного странновато) — AWS Cloudwatch + решения open source osquery или GRR
- анализ Netflow — AWS Cloudwatch + AWS VPC Flow
- анализ DNS — AWS Cloudwatch + AWS Route53
- AD — AWS Directory Service
- управление учетными записями — AWS IAM
- SSO — AWS SSO
- анализ защищенности — AWS Inspector
- управление конфигурациями — AWS Config
- WAF — AWS WAF.
Я не буду подробно расписывать все сервисы Amazon, которые могут быть полезны в контексте информационной безопасности. Главное, что надо понять, что все они могут генерить события, которые мы можем и должны анализировать в контексте ИБ, привлекая для этого как встроенные возможности самого Amazon, так и внешние решения, например, SIEM, которые могут забирать события безопасности в ваш центр мониторинга и анализировать их там наряду с событиями от других облачных сервисов или от внутренней инфраструктуры, периметра или мобильных устройств.
В любом случае все начинается с источников данных, которые предоставляют вам события ИБ. К таким источникам можно среди прочего отнести:
- CloudTrail — использование API и действия пользователей
- Trusted Advisor — проверка безопасности на соответствие лучшим практикам
- Config — инвентаризация и конфигурация учетных записей и настроек сервисов
- VPC Flow Logs — соединения с виртуальными интерфейсами
- IAM — сервис идентификации и аутентификации
- ELB Access Logs — балансировщика нагрузки
- Inspector — уязвимости в приложениях
- S3 — файловое хранилище
- CloudWatch — активность приложений
- SNS — сервис уведомлений.
Amazon, предлагая такой спектр источников событий и инструментов по их генерации, при этом сильно ограничен в возможностях по анализу собранных данных в контексте ИБ. Вам придется самостоятельно изучать имеющиеся логи, выискивая в них соответствующие индикаторы компрометации. AWS Security Hub, который недавно запустил Amazon, призван решить эту проблему, став этаким облачным SIEM для AWS. Но пока он находится только в начале своего пути и ограничен как числом источников, с которыми он работает, так и иными ограничениями, установленными архитектурой и подписками самого Amazon.
Пример: Мониторинг ИБ в IaaS на базе Azure
Не хочу вступать в долгую полемику, какой из трех облачных провайдеров (Amazon, Microsoft или Google) лучше (тем более, что каждый из них имеет все-таки свою определенную специфику и подходит для решения своих задач); сосредоточимся на возможностях по мониторингу ИБ, которые предоставляют эти игроки. Надо признать, что Amazon AWS был одним из первых в этом сегменте и поэтому продвинулся дальше всех в части своих функций по ИБ (хотя многие признают, что пользоваться ими сложновато). Но это не значит, что мы проигнорируем возможности, которые предоставляют нам Microsoft с Google.
Продукция Microsoft всегда отличалась своей “открытостью” и в Azure ситуация аналогичная. Например, если AWS и GCP всегда исходят из концепции “все, что не разрешено, запрещено”, то у Azure подход прямо противоположный. Например, создавая виртуальную сеть в облаке и виртуальную машину в ней, все порты и протоколы по умолчанию открыты и разрешены. Поэтому, вам придется потратить чуть больше усилий по первоначальной настройке системы разграничения доступа в облаке от Microsoft. И это же накладывает на вас более жесткие требования в части мониторинга активности в облаке Azure.
У AWS есть особенность, связанная с тем, что когда вы мониторите свои виртуальные ресурсы, то если они находятся в разных регионах, то у вас появляются трудности в объединении всех событий и их единого анализа, для устранения которых вам надо прибегать к различным ухищрениям, типа создания собственного кода для AWS Lambda, который будет переносить события между регионами. В Azure такой проблемы нет — его механизм Activity Log отслеживает всю активность в рамках всей организации без ограничений. Тоже самое касается и AWS Security Hub, который был недавно разработан Amazon для консолидации многих функций безопасности в рамках единого центра безопасности, но только в рамках своего региона, что, правда, для России неактуально. В Azure присутствует свой Security Center, который не связан региональными ограничениями, предоставляя доступ ко всем функциям безопасности облачной платформы. Более того, для различных локальных команд он может предоставить свой набор защитных возможностей и, в том числе, управляемых ими осбытий безопасности. AWS Security Hub еще только стремится к тому, чтобы стать похожим на Azure Security Center. Но стоит добавить и ложку дегтя — вы можете выжать из Azure очень многое из того, что было описано ранее в AWS, но наиболее удобно это делается только для Azure AD, Azure Monitor и Azure Security Center. Все остальные защитные механизмы Azure, включая и анализ событий безопасности, управляются пока не самым удобным образом. Отчасти проблему решает API, который пронизывает все сервисы Microsoft Azure, но это потребует от вас дополнительных усилий по интеграции вашего облака с вашим SOC и наличия квалифицированных специалистов (собственно, как и с любым другим. SIEM, работающим с облачными API). Некоторые SIEM, о чем речь пойдет дальше, уже поддерживают Azure и могут автоматизировать задачу его мониторинга, но и с ним есть свои сложности — не все они могут забирать все логи, которые есть у Azure.
Сбор событий и их мониторинг в Azure предоставляется с помощью сервиса Azure Monitor, который является основным инструментом сбора, хранения и анализа данных в облаке Microsoft и его ресурсах — репозитории Git, контейнерах, виртуальных машинах, приложениях и т.п. Все данные, собираемаые Azure Monitor делятся на две категории — метрики, собираемые в реальном времени и описывающие ключевые показатели деятельности облака Azure, и журналы регистрации, содержащие данные, организованные в записи, характеризующие те или иные аспекты деятельности ресурсов и сервисов Azure. Кроме того, с помощью Data Collector API сервис Azure Monitor может собирать данные с любого REST-источника для выстраивания собственных сценариев мониторинга.
Вот несколько источников событий безопасности, которые предлагает вам Azure и к которым вы можете получить доступ через Azure Portal, CLI, PowerShell или REST API (а некоторые только через Azure Monitor / Insight API):
- Activity Logs — данный журнал отвечает на классические вопросы “кто”, “что” и “когда” в отношении любой операции записи (PUT, POST, DELETE) над облачными ресурсами. События, связанные с доступом на чтение (GET) в этот журнал не попадают, как и ряд других.
- Diagnostic Logs — содержит данные по операциям с тем или иным ресурсом, входящим в вашу подписку.
- Azure AD reporting — содержит как пользовательскую активность, так и системную активность, связанную с управлением группами и пользователями.
- Windows Event Log и Linux Syslog — содержит события с виртуальных машин, размещаемых в облаке.
- Metrics — содержит телеметрию о состоянии производительности и “здоровья” ваших облачных сервисов и ресурсов. Измеряются ежеминутно и хранятся. в течение 30 дней.
- Network Security Group Flow Logs — содержит данные по сетевым событиям безопасности, собираемые с помощью сервиса Network Watcher и мониторинга ресурсов на уровне сети.
- Storage Logs — содержит события, связанные с доступом к хранилищам.
Для мониторинга вы можете использовать внешние SIEM или встроенный Azure Monitor и его расширения. Про системы управления событиями ИБ мы еще поговорим, а пока посмотрим, что нам предлагает сам Azure для анализа данных в контексте безопасности. Основным экраном для всего, что связано с безопасностью в Azure Monitor, является Log Analytics Security and Audit Dashboard (бесплатная версия поддерживает хранение ограниченного объема событий всего одну неделю). Эта панель поделена на 5 основных областей, визуализирующих сводную статистику по тому, что происходит в используемой вами облачной среде:
- Security Domains — ключевые количественные показатели, связанные с ИБ — число инцидентов, число скомпрометированных узлов, непропатченные узлы, события сетевой безопасности и т.п.
- Notable Issues — отображает число и важность активных проблем с ИБ
- Detections — отображает шаблоны, использованных против вас атак
- Threat Intelligence — отображает географическую информацию по внешним узлам, которые вас атакуют
- Common security queries — типичные запросы, которые помогут вам лучше мониторить вашу ИБ.
В качестве расширений Azure Monitor можно назвать Azure Key Vault (защита криптографических ключей в облаке), Malware Assessment (анализ защиты от вредоносного кода на виртуальных машинах), Azure Application Gateway Analytics (анализ, среди прочего, логов облачного межсетевого экрана) и т.п. Эти инструменты, обогащенные определенными правилами обработки событий, позволяют визуализировать различные аспекты деятельности облачных сервисов, в том числе и безопасности, и выявлять те или иные отклонения от работы. Но, как это часто бывает, любой дополнительный функционал требует соответствующей платной подписки, что потребует от вас соответствующих финансовых вливаний, которые вам надо планировать заранее.
У Azure есть ряд встроенных возможностей по мониторингу угроз, которые интегрированы в Azure AD, Azure Monitor и Azure Security Center. Среди них, например, обнаружение взаимодействия виртуальных машин с известными вредоносными IP (за счет наличия интеграции с сервисами Threat Intelligence от Microsoft), обнаружение вредоносных программ в облачной инфраструктуре за счет получения сигналов тревоги от виртуальных машин, размещенных в облаке, атаки типа “подбор пароля” на виртуальные машины, уязвимости в конфигурации системы идентификации пользователей, вход в систему с анонимайзеров или зараженных узлов, утечка учетных записей, вход в систему с непривычных местоположений и т.п. Azure сегодня — один из немногих облачных провайдеров, кто предлагает вам встроенные возможности Threat Intelligence для обогащения собранных событий ИБ.
Как уже было сказано выше, защитный функционал и, как следствием, генерируемые им события безопасности, доступен не всем пользователям одинаково, а требует наличия определенной подписки, включающей нужный вам функционал, который и генерит соответствующие события для мониторинга ИБ. Например, часть описанных в предыдущем абзаце функций по мониторингу аномалий в учетных записях доступна только в премиум лицензии P2 для сервиса Azure AD. Без нее вам, как и в случае AWS, придется анализировать собранные события безопасности «вручную». И, также, в зависимости от типа лицензии на Azure AD вам будет доступны не все события для анализа.
На портале Azure вы можете управлять как поисковыми запросами к интересующим вас журналам регистрации, так и настраивать дашборды для визуализации ключевых показателей ИБ. Кроме того, там же вы можете выбирать расширения Azure Monitor, которые позволяют вам расширить функциональность логов Azure Monitor и получить более глубокий анализ событий с точки зрения безопасности.
Если вам нужна не только возможность работы с логами, но всесторонний центр безопасности вашей облачной платформы Azure, включая управление политиками ИБ, то можно говорить о необходимости работы с Azure Security Center, большинство полезных функций которого доступно за отдельные деньги, например, обнаружение угроз, мониторинг вне Azure, оценка соответствия и т.п. (в бесплатной версии вам доступна только оценка безопасности и рекомендации по устранению выявленных проблем). Он консолидирует все вопросы безопасности в одном месте. По сути можно говорить о более высоком уровне ИБ, чем вам предоставляет Azure Monitor, так как в данном случае собранные по всей вашей облачной фабрике данные обогащаются с помощью множества источников, таких как Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) и Microsoft Security Response Center (MSRC), на которые накладываются различные навороченные алгоритмы машинного обучения и поведенческой аналитики, что в итоге должно повысить эффективность обнаружения угроз и реагирования на них.
Есть у Azure и свой SIEM — он появился в начале 2019-года. Это Azure Sentinel, который опирается на данные от Azure Monitor, а также может интегрироваться с. внешними решениями по безопасности (например, NGFW или WAF), список которых постоянно пополняется. Помимо этого, за счет интеграции Microsoft Graph Security API у вас появляется возможность подключать к Sentinel собственные фиды Threat Intelligence, что обогащает возможности по анализу инцидентов в вашем облаке Azure. Можно утверждать, что Azure Sentinel является первым «родным» SIEM, который появился у облачных провайдеров (тот же Splunk или ELK, которые можно разместить в облаке, например, AWS, все-таки разработаны не поставщиками традиционных облачных услуг). Azure Sentinel и Security Center можно было бы назвать SOCом для облака Azure и ими можно было бы и ограничиться (с определенными оговорками), если бы у вас больше не было никакой инфраструктуры и вы все свои вычислительные ресурсы перенесли в облако и это было бы облако Microsoft Azure.
Но так как встроенных возможностей Azure (даже при наличии подписки на Sentinel) часто не хватает для целей мониторинга ИБ и интеграции этого процесса с иными источниками событий безопасности (как облачными, так и внутренними), возникает необходимость в экспорте собранных данных во внешние системы, к числу которых может относиться и SIEM. Делается это как с помощью API, так и с помощью специальных расширений, которые официально имеются в данный момент только у следующих SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight и ELK. Еще недавно, таких SIEM было больше, но с 1-го июня 2019 года Microsoft прекратил поддержку Azure Log Integration Tool (AzLog), который на заре существования Azure и при отсутствии нормальной стандартизации работы с логами (Azure Monitor еще даже не существовало) позволял легко интегрировать внешние SIEM с облаком Microsoft. Сейчас ситуация поменялась и Microsoft рекомендует платформу Azure Event Hub, как основной инструмент интеграции для остальных SIEM. Многие уже осуществили такую интеграцию, но будьте внимательны, — они могут захватывать не все логи Azure, а лишь некоторые (смотрите в документации на вашу SIEM).
Завершая краткий экскурс в Azure, хочу дать общую рекомендацию по этому облачному сервису, — прежде чем что-то утверждать относительно функций мониторинга ИБ в Azure стоит их настроить очень внимательно и протестировать, что они работают так, как написано в документации и как вам рассказали консультанты Microsoft (а у них могут быть разные взгляды на работоспособность функций Azure). При наличии финансовых возможностей из Azure можно выжать очень много полезного в части мониторинга ИБ. Если же ваши ресурсы ограничены, то как и в случае AWS, вам придется рассчитывать только на собственные силы и сырые данные, которые вам предоставляет Azure Monitor. И помните, что многие функции мониторинга стоят денег и с ценовой политикой лучше ознакомиться заранее. Например, бесплатно вы можете хранить данные за 31 день объемом не более 5 Гб на заказчика — превышение этих значений потребует от вас дополнительно раскошелиться (примерно 2+ доллара за хранение каждого дополнительного Гб от заказчика и 0,1 доллара за хранение 1 Гб каждый дополнительный месяц). Работа с телеметрией приложений и метриками также может потребовать дополнительных финансовых средств, как и работа с алертами и уведомлениями (бесплатно доступен определенный лимит, которого может и не хватить для ваших нужд).
Пример: Мониторинг ИБ в IaaS на базе Google Cloud Platform
Google Cloud Platform на фоне AWS и Azure выглядит совсем юнцом, но это отчасти и хорошо. В отличие от AWS, который наращивал свои возможности, в том числе и защитные, постепенно, имея проблемы с централизацией; GCP, как и Azure, гораздо лучше управляется централизовано, что снижает число ошибок и время внедрения на предприятии. С точки зрения безопасности, GCP находится, как ни странно, между AWS и Azure. У него также единая для всей организации регистрация событий, но она неполна. Некоторые функции до сих еще в бета-режиме, но постепенно этот недостаток должен быть устранен и GCP станет более зрелой платформой с точки зрения мониторинга ИБ.
Основным инструментом для регистрации событий в GCP является Stackdriver Logging (аналог Azure Monitor), который позволяет вам собирать события по всей вашей облачной инфраструктуре (а также с AWS). С точки зрения безопасности в GCP каждая организация, проект или папка имеет четыре журнала регистрации:
- Admin Activity — содержит все события, связанные с административным доступом, например, создание виртуальной машины, изменение прав доступа и т.п. Этот журнал пишется всегда, независимо от вашего желания и хранит свои данные в течение 400 дней.
- Data Access — содержит все события, связанные с работой с данными облачными пользователями (создание, изменение, чтение и т.п.). По умолчанию этот журнал не пишется, так как его объем очень быстро распухает. По этой причине срок его хранения составляет всего 30 дней. Кроме того, в этот журнал пишется далеко не все. Например, в него не пишутся события, связанные с публично доступными для всех пользователей ресурсами или которые доступны без входа в GCP.
- System Event — содержит системные события, несвязанные с пользователями, или действия администратора, который изменяет конфигурацию облачных ресурсов. Пишется всегда и хранится в течение 400 дней.
- Access Transparency — это уникальный пример журнала регистрации, который фиксирует все действия сотрудников Google (но пока не для всех сервисов GCP), которые получают доступ к вашей инфраструктуре в рамках выполнения своих служебных обязанностей. Данный журнал хранится 400 дней и доступен не каждому клиенту GCP, а только при соблюдении ряда условий (либо поддержка уровня Gold или Platinum, либо наличие 4-х ролей определенного типа в рамках корпоративной поддержки). Аналогичная функция есть также, например, в Office 365 — Lockbox.
Пример журнала: Access Transparency
{
insertId: "abcdefg12345"
jsonPayload: {
@type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
location: {
principalOfficeCountry: "US"
principalEmployingEntity: "Google LLC"
principalPhysicalLocationCountry: "CA"
}
product: [
0: "Cloud Storage"
]
reason: [
detail: "Case number: bar123"
type: "CUSTOMER_INITIATED_SUPPORT"
]
accesses: [
0: {
methodName: "GoogleInternal.Read"
resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
}
]
}
logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
operation: {
id: "12345xyz"
}
receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
resource: {
labels: {
project_id: "1234567890"
}
type: "project"
}
severity: "NOTICE"
timestamp: "2017-12-18T16:06:24.660001Z"
}Доступ к указанным логам возможен несколькими путями (примерно также как и ранее рассмотренных Azure и AWS) — через интерфейс Log Viewer, через API, через Google Cloud SDK или через страницу Activity вашего проекта, по которому вас интересуют события. Таким же образом их можно и экспортировать во внешние решения для дополнительного анализа. Последнее делается через экспорт логов в хранилище BigQuery или Cloud Pub/Sub.
Помимо Stackdriver Logging платформа GCP предлагает еще функционал Stackdriver Monitoring, который позволяет отслеживать ключевые метрики (производительность, наработка на отказ, общее состояние и т.п.) облачных сервисов и приложений. Обработанные специальным образом и визуализированные данные могут облегчить поиск проблем в вашей облачной инфраструктуре, в том числе и в контексте безопасности. Но надо отметить, что функционал этот будет не очень богат именно в контексте ИБ, так как на сегодняшний день GCP не имеет аналога того же AWS GuardDuty и не может выделять среди всех регистрируемых событий именно плохие (Google разработал Event Threat Detection, но пока он находится в бете и говорить о его полезности рановато). Stackdriver Monitoring можно было бы задействовать как систему обнаружения аномалий, которые затем будут расследоваться для поиска причин их возникновения. Но в условиях нехватки на рынке квалифицированного в области ИБ GCP персонала, это задача на данный момент выглядит непростой.
Также стоит привести список некоторых модулей по ИБ, которые могут быть применены в рамках вашего облака GCP, и которые схожи с тем, что предлагает AWS:
- Cloud Security Command Center — это аналог AWS Security Hub и Azure Security Center.
- Cloud DLP — автоматическое обнаружение и редактирование (например, маскирование) данных, размещенных в облаке, по более чем 90 предустановленным политикам классификации.
- Cloud Scanner — сканер известных уязвимостей (XSS, Flash Injection, непатченные библиотеки и т.п.) в App Engine, Compute Engine и Google Kubernetes.
- Cloud IAM — управление доступом ко всем ресурсам GCP.
- Cloud Identity — управление учетными записями пользователей, устройств и приложений GCP с единой консоли.
- Cloud HSM — защита криптографических ключей.
- Cloud Key Management Service — управление криптографическими ключами в GCP.
- VPC Service Control — создание защищенного периметра вокруг ваших ресурсов GCP для защиты их от утечек.
- Titan Security Key — защита от фишинга.
Многие из этих модулей генерят события безопасности, которые могут быть отправлены в хранилище BigQuery для анализа или экспорта в другие системы, включая и SIEM. Как уже писалось выше, GCP — активно развиваемая платформа и сейчас Google разрабатывает ряд новых модулей по ИБ для своей платформы. Среди них Event Threat Detection (сейчас доступен в бете), которые сканирует логи Stackdriver в поисках следов несанкционированной активности (аналог GuardDuty в AWS), или Policy Intelligence (доступен в альфе), который позволит разрабатывать интеллектуальные политики доступа к ресурсам GCP.
Я сделал небольшой обзор встроенных возможностей по мониторингу в популярных облачных платформах. Но есть ли у вас специалисты, которые способны работать с “сырыми” логами IaaS- провайдера (не все готовы покупать расширенные возможности AWS или Azure или Google)? Кроме того, многим известна пословица “доверяй, но проверяй”, которая в области безопасности верна как никогда. Насколько вы доверяете встроенным возможностям облачного провайдера, которые отдают вам события ИБ? Насколько они вообще фокусируются на ИБ?
Иногда стоит посмотреть в сторону наложенных решений по мониторингу облачных инфраструктур, которые могут дополнить встроенную безопасность облака, а иногда такие решения — единственный вариант получить данные по безопасности ваших данных и приложений, размещенных в облаке. Кроме того, они просто удобнее, так как берут на себя все задачи по анализу нужных логов, генерируемых разными облачными сервисами разных облачных провайдеров. В качестве примера такого наложенного решения можно привести Cisco Stealthwatch Cloud, который сфокусирован на единственной задаче — мониторинг аномалий ИБ в облачных средах, среди которых не только Amazon AWS, Microsoft Azure и Google Cloud Platform, но и частные облака.
Пример: Мониторинг ИБ с помощью Stealthwatch Cloud
AWS предоставляет гибкую платформу для вычислений, но эта гибкость приводит к тому, что компаниями легче совершать ошибки, приводящие к проблемам безопасности. И разделяемая модель ИБ только способствует этому. Запуск в облаке ПО с неизвестными уязвимостями (с известными может бороться, например, AWS Inspector или GCP Cloud Scanner), слабые пароли, некорректные конфигурации, инсайдеры и т.п. И все это отражается на поведении облачных ресурсов, за которыми может наблюдать Cisco Stealthwatch Cloud, являющийся системой мониторинга ИБ и обнаружения атак в. публичных и частных облаках.
Одной из ключевых особенностей Cisco Stealthwatch Cloud является возможность моделирования сущностей. С его помощью можно создать программную модель (то есть имитацию практически в реальном времени) каждого из ваших облачных ресурсов (неважно, будет ли это AWS, Azure, GCP или что-то иное). К ним могут относиться сервера и пользователи, а также типы ресурсов, специфичные для вашей облачной среды, такие как группы безопасности и группы автоматического масштабирования сервисов (auto-scale). Эти модели используют в качестве входных данных структурированные потоки данных, предоставляемые облачными сервисами. Например, для AWS это будут VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda и AWS IAM. Моделирование сущностей автоматически обнаруживает роль и поведение любого из ваших ресурсов (можно говорить о профилировании всей облачной активности). Среди таких ролей — мобильное устройство Android или Apple, сервер Citrix PVS, RDP-сервер, почтовый шлюз, клиент VoIP, терминальный сервер, контроллер домена и т.п. Затем он непрерывно отслеживает их поведение, чтобы определить, когда происходит рискованное или угрожающее безопасности поведение. Вы можете идентифицировать подбор пароля, DDoS-атаки, утечки данных, нелегальный удаленный доступ, действие вредоносного кода, сканирование уязвимостей и другие угрозы. Например, вот как выглядит обнаружение попытки удаленного доступа из нетипичной для вашей организации страны (Южная Корея) к кластеру Kubernetes по SSH:
А вот так выглядит предполагаемая утечка информации из базы данных Postgress в страну, взаимодействие с которой ранее не встречалось:
Наконец, вот так выглядит слишком большое число неудачных попыток доступа по SSH из Китая и Индонезии с внешнего удаленного устройства:
Или, предположим, что экземпляр сервера в VPC, согласно политике, никогда не должен быть точкой назначения для удаленного входа в систему. Предположим далее, что на этом компьютере произошел удаленный вход в систему из-за ошибочного изменения политики правил межсетевого экрана. Функция моделирования сущностей будет обнаруживать и сообщать об этой активности («Необычный удаленный доступ») в почти реальном времени и указывать на конкретный вызов API AWS CloudTrail, Azure Monitor или GCP Stackdriver Logging (включая имя пользователя, дату и время, среди прочих деталей), которые вызвали изменение в правило МСЭ. А затем эта информация может быть отдана в SIEM для анализа.
Аналогичные возможности реализуются для любой облачной среды, поддерживаемой Cisco Stealthwatch Cloud:
Моделирование сущностей — это уникальная форма автоматизации безопасности, которая может обнаружить ранее неизвестную проблему с вашими людьми, процессами или технологиями. Например, она позволяет обнаруживать среди прочего такие проблемы безопасности, как:
- Кто-то обнаружил бэкдор в ПО, которое мы используем?
- Есть ли какое-либо стороннее ПО или устройство в нашем облаке?
- Злоупотребляет ли авторизованный пользователь привилегиями?
- Была ли допущена ошибка конфигурации, обеспечивающая удаленный доступ или другое непреднамеренное использование ресурсов?
- Нет ли утечки данных с наших серверов?
- Не пытался ли кто-то подключиться к нам из нетипичного географического места?
- Не заражено ли наше облако вредоносным кодом?
Обнаруженное событие ИБ может быть передано в виде соответствующего тикета в Slack, Cisco Spark, систему управления инцидентами PagerDuty, а также отдано в различные SIEM, среди которых Splunk или ELK. Резюмируя, можно сказать, что если ваша компания использует мультиоблачную стратегию и не ограничивается каким-то одним облачным провайдером, возможности по мониторингу ИБ, которых описывались выше, то применение Cisco Stealthwatch Cloud является неплохим вариантом получить унифицированный набор возможностей по мониторингу ведущих облачных игроков — Amazon, Microsoft и Google. Самое интересное, что если сравнивать цены на Stealthwatch Cloud с продвинутыми лицензиями на мониторинг ИБ в AWS, Azure или GCP, то может оказаться так, что решение Cisco окажется даже дешевле встроенных возможностей решений Amazon, Microsoft и Google. Парадоксально, но это так. И чем больше облаков и их возможностей вы используете, тем очевиднее будет преимущество консолидированного решения.
Кроме того, Stealthwatch Cloud может мониторить и частные облака, развернутые у вас в организации, например, на базе контейнеров Kubernetes или путем мониторинга потоков Netflow или сетевого трафика, получаемого через зеркалирование в сетевом оборудовании (даже отечественного производства), данных AD или DNS-серверов и т.п. Все эти данные будут обогащаться информацией Threat Intelligence, собираемой подразделением Cisco Talos, являющемся крупнейшей в мире неправительственной группой исследователей угроз ИБ.
Это позволяет вам реализовать единую систему мониторинга как публичных, так и гибридных облаков, которые может использовать ваша компания. Собранная информация затем может быть проанализирована с помощью встроенных возможностей Stealthwatch Cloud или отправлена в ваш SIEM (по умолчанию поддерживаются Splunk, ELK, SumoLogic и ряд других).
На этом мы завершим первую часть статьи, в которой я рассмотрел встроенные и внешние инструменты по мониторингу ИБ IaaS/PaaS-платформ, которые позволяют нам оперативно обнаруживать и реагировать на инциденты, происходящие в облачных средах, которые выбрало наше предприятие. Во второй части мы продолжим тему и рассмотрим варианты мониторинга SaaS-платформ на примере Salesforce и Dropbox, а также попробуем подытожить и собрать все вместе, создав единую систему мониторинга ИБ разных облачных провайдеров.
