Михаил Кречетов: Микросегментация в IaaS — это необходимость

Директор Anti-Malware.ru Илья Шабанов и эксперт по кибербезопасности в облаках STEP LOGIC Михаил Кречетов обсудили особенности информационной безопасности облачной инфраструктуры и её отличия от классической, лучшие практики по переходу в облако и документы, на которых те основаны, микросегментацию в IaaS, разграничение ответственности между заказчиком, провайдером и MSSP при возникновении инцидентов, а также безопасное использование публичных облаков.

Пандемия ускорила процесс миграции в облако. Добавляются ли какие-то новые угрозы и риски именно для облачной инфраструктуры?

М. К.: Многие считают, что облака — это нечто новое и революционное. Но по факту революционным является только ускоренный переход в облачные среды, а вот идея облачных вычислений довольно стара. Понятие «as-a-Service» появилось в широком обиходе ещё в начале-середине нулевых годов.

На мой взгляд, новые угрозы, с которыми мы столкнулись при переходе в облака, можно разделить на несколько групп: во-первых, это ошибки конфигурации при деплое (т. е. незащищённый DevOps); во-вторых, проблема отсутствия регламентов процедур эксплуатации; в-третьих, это наш нелюбимый Shadow IT; и, наконец, то, что мы не можем осуществлять контроль, не разделив правильным образом ответственность между облачным провайдером, пользователем и заказчиком этой услуги — то есть перехват контроля над облачными процессами.

Если открыть матрицу MITRE, то специфические техники для облачных инфраструктур аналогичны классическим. Единственная, наверное, новая техника из группы «Collection» — это извлечение данных из бакета (логической сущности для хранения объектов. — Прим. ред.). Остальные — повышение привилегий, фишинг и прочее — перетекли из классических инфраструктур.

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

С точки зрения бизнеса к чему это может привести? Со стороны кажется, что при классической инфраструктуре, когда у тебя всё это «дома», рисков меньше.

М. К.: Да, безусловно, вы правы. Сейчас самый, наверное, правильный и популярный путь — это гибридное облако, которое является «смесью» инфраструктуры как сервиса (IaaS) в облаке и родного локального (on-premise) ЦОД. Сразу «переезжать» в облака и разворачивать там важные для бизнеса сервисы без реализации модели «нулевого доверия» нельзя — велик риск потерять всё в одну минуту вследствие банальной компрометации учётной записи. Причём она может произойти по вине не только заказчика, но и облачного провайдера, поэтому здесь риски существенно возрастают.

Вернёмся к трём категориям рисков (ошибки конфигурации, Shadow IT, отсутствие регламентов и разграничения ответственности). Как можно их минимизировать? Какие технические средства и подходы можно использовать?

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

Резюмирую сказанное выше: «нулевое доверие», надёжная технически реализованная платформа идентификации (IAM, платформа для управления учётными данными, единая на всю инфраструктуру) и, естественно, регламентирование и документирование всех действий.

По поводу разработки: если мы говорим о резком переносе изменений в «прод» — что и подразумевает парадигма CI / CD, — то нужно понимать, что сразу нести в «прод» малейший патч, как это обычно делается, — неправильно. Может быть, это приносит дополнительные выгоды с точки зрения ускорения бизнес-процесса, но облачная безопасность невозможна без таких средств, как статический или динамический анализ кода, контроль над собственными разработчиками. На этом, на мой взгляд, сейчас должен строиться весь фундамент информационной безопасности: если мы будем правильно разрабатывать и деплоить приложения, то в итоге придётся использовать меньше наложенных средств.

Если рассматривать принцип CI / CD, цикл DevSecOps, то, конечно, там безопасность должна встраиваться как можно раньше и быть на всех этапах цикла. Что вы по своей практике рекомендуете использовать? Наверняка у вас есть проекты по DevSecOps, может быть, есть уже и отработанные практики, что должно внедряться и использоваться в такого рода проектах?

М. К.: Как я и говорил, начинаем с анализа кода. Сейчас большой популярностью пользуется Micro Focus Fortify — это статический и динамический анализ кода, то есть проверка разработчиков. Во-вторых, обязательна градация инфраструктуры на среды: например, среда разработки, тестирования, для серьёзных проектов — некий «предпрод», где функциональность проверяется на ограниченном количестве пользователей, а дальше всё это мигрируем в «прод».

Последние практические рекомендации для безопасной разработки были опубликованы в декабре прошлого года в 5-й версии фундаментального NIST Special Publication 800-53. Отмечу очень важное требование, которое в корне меняет понятие всей разработки, — минимизацию использования реальных продуктивных данных при разработке и тестировании.

Почему это настолько значимо? Критически важная для бизнеса информация, которая может быть обработана, лежит в забытых исходниках, в тестовых базах данных, доступ к которым никто не контролирует, что в итоге является причиной большинства утечек конфиденциальных сведений. Требование включено во фреймворк, и теперь его нужно неукоснительно соблюдать, по крайней мере в США. Надеюсь, что отечественные регуляторы тоже обратят на это внимание и «выкатят» его как обязательное.

Согласно исследованиям, до 80 % многих современных проектов составляет открытый исходный код — а откуда он взят и где используется, компании зачастую не знают. Потом находят какую-нибудь уязвимость (как было, помните, с OpenSSH) и взламывают множество компаний, которые даже не знают, что у них был этот компонент. Мне кажется, что здесь тоже создаются дополнительные большие риски.

М. К.: Да, здесь, наверное, помогает как статический, так и динамический анализ кода. Можно любую ветку Git показать тому же Fortify, и он подскажет, где и что следует исправить.

Если говорить о безопасности разработки, то иногда поступают вопросы о защите кода на открытых площадках. Без «Гита», например, у нас невозможно представить ни одного разработчика. Все в той или иной мере им пользуются. Как же защититься?

Первое, с чего стоит начать, — это аутентификация. Доступ в свой Git должен иметь только реально подтверждённый разработчик. И это — не простая аутентификация, а усиленная, многофакторная. Обязательно используем SAML, в GitHub он есть. Можно применять некую примитивную реализацию Zero Trust для Git: у «Гита» есть возможность настроить правила на файрволе, с каких адресов мы можем обращаться за кусками проекта. Эти базовые меры важно учитывать и уметь их использовать.

Зачастую при разработке (я сам бывший разработчик, поэтому знаю), когда нужно быстро сдать и проверить код, на ум приходит только chmod 755, а потом это забывается, остаётся. Поэтому на развёрнутый проект важно «натравить» не столько анализ кода, сколько полноценную систему управления уязвимостями. Она сэкономит много нервов.

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

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

М. К.: Это возможно, но вопрос надо решать комплексно. Микросегментация в случае инфраструктуры как сервиса (IaaS) — это необходимость, а не желание получить современное средство.

Впрочем, оно на самом деле не современное, о контроле взаимодействия «Запад — Восток» мы говорим уже последние десять лет, потому что эта часть остаётся без внимания вышестоящего файрвола. Мы научились контролировать, ловить приложения, вскрывать SSL, но происходящее на уровне виртуальных машин было неведомым. Потом, когда разработчики (вендоры безопасности) начали туда погружаться, первое время было заметно противодействие со стороны инфраструктурных сервисов.

Когда в классических ЦОД наконец-то дошли до охвата трафика East-West — что случилось в принципе недавно и, не будем преувеличивать, ещё не у всех, — то встал вопрос о том, что делать с сервисом. Когда мы переезжаем в облака, грань инфраструктуры ещё больше размывается. У нас нет полного контроля над физическим «железом», если мы пользуемся платформой как сервисом (PaaS), а при использовании модели SaaS он вообще отсутствует. Как же быть?

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

В качестве инструмента можно использовать специализированное ПО, например Secure Workload (бывший Tetration) от Cisco.

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

Прежде чем переходить в облака, вместе с микросегментацией необходимо провести ревизию всех учётных данных (сервисных, пользовательских), потому что может найтись «богом забытая» и никем не обслуживаемая учётная запись с неограниченным сроком действия (пусть у неё даже пароль в 42 символа — всё равно он статический). Отключаешь — и оказывается, что на ней висит очень важный процесс «бинда» чуть ли не на корневом сервисе. У меня такой опыт недавно был.

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

Задача сложно решаемая. Например, при помощи Cisco Secure Workload это можно сделать?

М. К.: Почему? Первым на ум приходит решение компании Cisco — у них полноценный SAFE, архитектура, которую они презентуют с 2015–2016 года. Например, в состав портфеля с апреля этого года вошла Duo (платформа идентификации). Зачастую это остаётся за скобками у других вендоров: покупая у них продукт по микросегментации, приходится использовать сторонние механизмы интеграции и идентификационную платформу.

По поводу Shadow IT: если говорить о безопасной разработке и DevSecOps, то проблема, я полагаю, ощущается весьма остро. Разработчики — «продвинутые» ребята, у всех есть серьёзные ИТ-навыки и присутствует некое ощущение вседозволенности: взял кусок кода, сам себе скинул куда-то (в какой-нибудь мессенджер или другое место) — а где это потом «всплывёт», зачастую никто не думает. Я уже не говорю про виртуальные диски, почту и тому подобное. Можно ли с этим вообще как-то бороться техническими средствами на уровне организации?

М. К.: Да, с этим можно и нужно бороться. Как вы сказали, все разработчики — «продвинутые», а «продвинутость» и вседозволенность нужно ограничивать, потому что они ведут только к уязвимостям и ни к чему более. Соответственно, если мы говорим о безопасности самого процесса разработки, то здесь хорошо показывают себя решения связанные с анализом сетевых потоков или комплексные — те, что обеспечивают безопасность рабочего процесса. И тут опять-таки мы возвращаемся к Cisco.

Допустим, приложение начинает тянуть сетевые хвосты к неизвестному ресурсу и разработчик этого не документировал (а они такие вещи не документируют практически в 100 % случаев). Если есть «закладка», то нужен сервис, некий внешний «репо». Этот процесс, соответственно, сразу чётко помечается средством анализа сетевых потоков. Можно применять более мягкие средства — связанные не с микросегментацией, а с анализом телеметрии (тот же StealthWatch). Вот на этом этапе и нужно «спустить» разработчику, что приложение обладает недокументированными возможностями. Либо документируйте их и доказывайте, что они нужны, либо они не попадают в «секьюрную» матрицу и мы не разрешим данное сетевое взаимодействие.

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

При этом есть средства, которые нацелены на борьбу с повышенными привилегиями.

Это в первую очередь PAM / PUM — Privileged Account / User Management.

М. К.: Да, их в обязательном порядке надо держать у ключевых разработчиков. Нужно отслеживать, какими «учётками» они пользуются при создании программ. Комбинация из микросегментации, платформы PAM и анализа кода с поиском уязвимостей может помочь создать действительно правильное и безопасное приложение, которое не стыдно выпустить в «прод», и мы будем уверены в том, что оно будет жить.

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

Интересный кейс — про применение PAM к разработчикам и DevSecOps. Когда вспоминаешь о PAM, в первую очередь приходят на ум системные администраторы, аудиторы, айти-департамент. Кажется, что для других задач, а получается всё то же самое. Они имеют тот же доступ, что и разработчики.

М. К.: «Девопсер» по сути дела тоже айтишник. Есть девопсеры, которые не понимают, что такое код; их задача — задеплоить готовое приложение. У них вечно не хватает прав, чтобы развернуть какой-то контейнер. Они чаще всего в открытую пользуются повышенными привилегиями, чтобы процесс пошёл быстрее. Поэтому за такими сотрудниками следить нужно особенно пристально. Если админы у нас худо-бедно уже научились тому, что «если есть PAM, то у меня есть учётка, я никогда под рутом не работаю», то девопсер — это человек творческий: он, может быть, вчерашний разработчик или сам что-то дописывает. Установить chmod 755 или 777 на каком-нибудь исполняемом файле или YAML-манифесте ему вообще ничего не стоит. Он знает, что так содержимое задеплоится без ошибок.

Когда девопсеры выполняют развёртывание с помощью YAML или же используют готовые решения, связанные с Kubernetes (HELM-чарты, например), всё это тоже нужно отслеживать. Если открыть YAML-файл, то можно найти много интересного, например чужие пространства имён или — в особо запущенных случаях — даже учётные записи. И здесь PAM, наверное, нам поможет, потому что учётные записи — в этих же контейнерных средах.

Сами по себе контейнерные среды сложно сегментировать. У нас есть несколько сетевых провайдеров Docker-сетей, например Weave, Calico. Мы только-только начинаем погружаться в то, как контейнеры общаются друг с другом. Не у всех вендоров даже есть подобные решения. Тот же Cisco Secure Workload только приближается к этой парадигме. Общение самих, условно говоря, Docker-хостов (вернее, сервисов в Docker) между собой зачастую остаётся за гранью любого Tetration. Это внутренние сети, куда никого не пускают.

Конечно: мало того что всё это располагается на одном хосте, оно ещё и живёт как одна операционная система. И непонятно, как настраивать правила микросегментации. Я не до конца понимаю, как здесь можно полноценно выстроить Zero Trust, если мы говорим о контейнерной инфраструктуре. Задача выглядит очень сложной.

М. К.: Действительно, такую задачу напрямую решить нельзя. Все средства, связанные с контейнерной безопасностью, пока находятся в зачаточной стадии развития. Через пару лет мы к ним придём. Но первое, о чём нужно не забывать, — сами по себе средства оркестрации контейнеров содержат много встроенных механизмов безопасности разграничения доступа, а это, собственно говоря, задача девопсера. Скажем, контейнер у него задеплоился и туда есть доступ. А почему? Потому что у него полностью открыт NGS. С другой стороны, на любой сервис можно «натравить» систему управления уязвимостями и она точно нам скажет, что может на него повлиять — по крайней мере, с точки зрения внешнего взаимодействия (например, потенциально открытый порт). Зачастую даже SSH держат на контейнерах, чтобы удобнее было что-то туда положить. Или FTP: быстренько кинуть туда скрипт или данные, чтобы контейнер заработал. Средствами самого Kubernetes или его «энтерпрайзных» наследников, таких как OpenShift, всё это делается достаточно просто.

Во-вторых, нужно чётко отслеживать все возможные ошибки конфигурации. Об этом мы говорили ранее.

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

Это, кстати, живые кейсы для будущего SOC: ловить ошибки конфигурации и предотвращать их на этапе тестирования приложения, чтобы в «прод» пошёл сервис, к которому со всех сторон не подкопаться. Пока модель выглядит таким образом. Что будет дальше — посмотрим. Возможно, пойдём на уровень ниже с тем же самым Zero Trust. Не очень понятно, как это делать, но опять-таки новое — это хорошо забытое старое. Что такое наши Docker-контейнеры и сервисы? По факту это — те же Jail, которые были в середине 90-х на FreeBSD. И тогда с этим пытались ужиться банальными заплатками со стороны внешних сервисов.

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

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

Что касается гибридизации: политика должна быть адаптирована к использованию облачных сред. В классической гибридной схеме мы не делаем различия в том, где находится сервис (на то она и гибридная): они могут «жить» как у нас, так и в облаке. И что же, каждый раз по-разному защищать? Растягивание политики микросегментации в сочетании с тем, что уже было наработано в классическом ЦОД — например, с защитой рабочих нагрузок тем же Secure Workload, — можно подвергнуть оркестрации и получить единое управление.

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

С точки зрения подключения пользователя, если, допустим, пять лет назад по умолчанию мы могли условно доверять всем корпоративным устройствам, которые стоят на рабочих местах, то сейчас это невозможно, потому что концепция «принеси своё устройство» — BYOD — захватила мир. Я, например, уже лет 6–7 на корпоративных ноутбуках не работаю. Очень неразумно пускать на ресурсы без предварительной аутентификации, даже если я получал доступ час назад.

Устройство могли просто украсть.

М. К.: Да. Многое могло измениться. И если с точки зрения облака об этом никто не спорит — оно далеко, мы подключаемся к чему-то далёкому и абстрактному, — то совсем по-другому воспринимаются наш ЦОД, который расположен в соседнем корпусе, или арендованные машинные залы рядом. А разницы-то, по сути, никакой. Если инфраструктура гибридная, через 20 минут сервис может переехать на другой Docker-хост, который находится во Франкфурте, а пользователь этого не заметит. Зачем же мы будем применять к этому сервису разные политики?

Какие сквозные технические средства для управления этими политиками можно использовать? Или же не существует универсального инструментария?

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

Честно говоря, если инфраструктура разрозненна, то будет достаточно тяжело её централизовать. Впрочем, всё делать в единой консоли не получится даже в моновендорном продукте. Но у нас есть ядро управления, которое имеет положительную обратную связь, — вендоронезависимый Security Operations Center. Он собирает события, которые в конце концов складываются в целостную картину, позволяющую по кусочкам регламентно отдать различным подразделениям часть инфраструктуры на управление. Естественно, в моновендорном сценарии это удобнее: открываем тот же DNA в Cisco, подгружаем матрицу Secure Workload и смотрим, как по факту ходит трафик и что мы можем в данном случае предпринять.

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

И возвращаемся к Zero Trust. Многие говорят: «Мы выстроили модель “нулевого доверия”. Разграничили — написали политику безопасности — у нас всё хорошо. Мы её соблюдаем. Есть единая платформа идентификации, к ней прикручено Duo, многофакторка, PAM». Но потом при разработке эта политика не соблюдается, потому что зачастую её внедрили и отдали на эксплуатацию — а эксплуатация не имеет обратной связи от SOC, и вся модель «нулевого доверия» рушится. Её нельзя один раз внедрить, нужно поддерживать в таком же состоянии. Это очень важно! И об этом, кстати, тоже говорится в стандарте: постоянные пересмотры политики и выстраивание доверия — вот процессный подход, а не «мы поставили межсетевой экран, научились добавлять правила, новый сервис — новые правила». Не нужно ограничиваться определением потоков, важно наблюдать постоянно. Возможно, в одном из патчей пришло новое сетевое взаимодействие, а по умолчанию мы всё разрешаем, так как не хотим помешать бизнесу. Zero Trust — это перманентная вещь.

Самое время поговорить о разграничении ответственности. Как правильно в рамках процесса управления информационной безопасностью должна разграничиваться ответственность между провайдером, который нам предоставляет облачную инфраструктуру, самим заказчиком и интегратором (тем, кто помогает это всё обслуживать — например, в лице вашей компании)? По моему опыту общения, у заказчика это вызывает наибольшее отторжение, потому что не очень понятно, кто будет нести ответственность.

М. К.: Этот вопрос я поднял ещё в самом начале. Именно на распределении ответственности многие проекты и тормозятся, и горят. На самом деле, парадигму «к каким объектам в различных моделях облачных инфраструктур владелец может получить доступ» можно найти на любом профильном ресурсе; первым её предложил Red Hat. Дальше есть фреймворк, про который в России, к сожалению, мало вспоминают, — Cloud Controls Matrix (разрабатывается весьма старой и уважаемой организацией Cloud Security Alliance). В свежей версии 4.0.2 перечислены, как и в рекомендациях NIST, методы и объекты защиты. Так вот, в этой матрице чаще всего встречается слово «shared», то есть ответственность размыта между различными участниками процесса по обеспечению облачной безопасности.

В отношении ответственности за инфраструктурные сервисы всё более-менее понятно. В IaaS есть облачный провайдер, он управляет «железом», сетями на физическом уровне, кабелями, мы полностью возлагаем на него ответственность. А вот дальше, при подъёме на уровень виртуальных машин, всё становится уже не так прозрачно.

Для устранения недостатков и разночтений существует Managed Security Service Provider. Значение сторонних организаций или прикреплённых служб облачных сервисов растёт сейчас лавинообразно. В самом деле, конечному заказчику нужно просто получить инфраструктуру, платформу и сервис, вообще не углубляясь ни в какие архитектурные тонкости и в то, что там происходит. Ему важен работающий сервис и бизнес-процесс.

Советую ориентироваться именно на Cloud Controls Matrix. Там, на мой взгляд, достаточно правильно, несмотря на обилие размытых (shared) ответственностей, расписано, какой из принципов безопасности кто конкретно и для какой инфраструктуры должен организовывать.

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

Но при перекладывании ответственности за доступность на облачного провайдера зачастую теряется роль бэкапирования. На заре становления такого облачного провайдера, как Yandex.Cloud, у меня было много кейсов связанных со сбоями в работе. Сейчас они вняли лучшим практикам и активно развиваются. На мой взгляд, это довольно перспективный облачный провайдер, в том числе с точки зрения обеспечения безопасности (там достаточно сильная школа).

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

Заказчик формирует политику ИБ под облачные инфраструктуры с учётом выявленных активов, заново оценивает риски. Какие-то из них могут быть нивелированы, например риски доступности, а другие — наоборот, кратно возрасти (та же кража учётных записей). В формировании политики может помочь MSSP, который знает, как системы должны функционировать в облачных инфраструктурах.

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

Если мы говорим о слиянии политики безопасности для ЦОД и облака, то прежде всего необходима надёжная система управления учётными данными с многофакторной аутентификацией. С этого можно начать, параллельно выполнив ревизию УЗ.

Опять-таки, если вернуться чуть назад, рекомендации SP 800-53 теперь содержат много требований к аутентификации (identity proofing). Наша классическая пара «логин / пароль» отжила своё, она уже не считается безопасной. Второй, третий фактор — это теперь данность и необходимость.

Реализовав эти пять шагов, мы внедрим меры. Если в компании развиты службы безопасности, они контролируют инциденты, есть собственный SOC, то в идеальной модели рутину мы можем «перевалить» на MSSP. Крупные заказчики, имеющие в штате целый корпус безопасников, конечно, могут позволить себе взять полное управление.

Возможно ли вообще безопасное использование Amazon, Azure и других публичных облаков?

М. К.: AWS, Azure и Google Cloud исторически являются передовыми платформами, с которых отечественные разработчики берут пример. Что касается безопасности — например, встроенных средств в том же Google Cloud, у них классный триальный период, я им периодически пользуюсь, — то с точки зрения построения безопасных сетей там всё как везде. Это классические вещи, связанные с ограничением входящих подключений, управлением учётными данными — в Google Cloud есть собственная IAM-платформа, такая же, как в AWS и в Azure. Проще всего, наверное, сказать так: они безопаснее, потому что имеют развитый маркетплейс. У заказчиков, которые приходят в облако с новым сервисом, нет желания долго возиться с безопасностью. Развернули быстренько систему сегментации в облаке без сложного внедрения и приступили к работе.

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

Подытожу: с точки зрения «real security» и маркетплейсов публичные облака — это хорошо. Но, с другой стороны, граница данных выходит в чужую юрисдикцию и противоречит нашему законодательству, и это, конечно, плохо. Исправить ситуацию можно средствами анализа неструктурированных данных. То есть по идее при правильной подготовке использовать AWS можно.

Спасибо за интервью! Желаю успехов!