Понятие as-a-service стало широко употребляться еще в начале нулевых годов. Пандемия и всемирная тенденция к самоизоляции дали мощный скачок в развитии облачных технологий. Весной 2020-го вычислительные мощности корпораций с высоким уровнем развития ИТ за несколько недель выросли на 10-15%. Многие компании перешли на дистанционный режим работы, а облако стало одним из главных помощников в этом вынужденном «переезде», что отрицательно сказалось на информационной безопасности.
На сегодняшний день к основным угрозам безопасности облачных сред относятся:
· Отказ в обслуживании.
· Неконтролируемый доступ к облачным сервисам.
· Отсутствие классификации данных (утечка конфиденциальной информации).
· Эксплуатация уязвимостей API.
· Избыточность входящих сетевых взаимодействий.
· Отсутствие регламентов процедур эксплуатации (Shadow IT).
· Перехват контроля над ресурсами в облаке.
· Отсутствие комплаенса (или неправильно выбранный framework).
· Ошибки конфигурации в DevOps и СI/CD-процессах.
· Потеря контроля над действиями пользователей.
· Отсутствие непрерывного процесса контроля безопасности.
· Внутренние нарушители (в том числе сторонние подрядчики и облачные провайдеры).
В своей статье я расскажу о концепции Zero Trust Architecture (ZTA), реализация которой является краеугольным камнем всей облачной безопасности и помогает в устранении большинства перечисленных угроз безопасности. В августе прошлого года концепция была стандартизована в документе NIST SP 800-207 “Zero Trust Architecture”.
Для начала определимся с терминологией. Zero trust (ZT), или «нулевое доверие», предоставляет собой набор концепций и идей, направленных на принятие точных решений о доступе субъекта к объекту с минимальными привилегиями для каждого запроса доступа. Говоря проще, никакой субъект не считается доверенным (или должен восприниматься как злоумышленник – кому как нравится) без предварительного разрешения, причем неважно, получал ли он его ранее или нет. Таким образом, сам факт подключения к корпоративной сети в классическом понимании не дает субъекту никаких прав по умолчанию.
Zero trust Architecture (ZTA) – это архитектура безопасности, построенная на наборе концепций Zero Trust. Она охватывает взаимосвязи компонентов, процессы (workflow) и политики доступа, может быть реализована в приложении или конкретном сервисе.
Существуют три метода создания ZTA (идеальным вариантом реализации считается их комбинация):
· с использованием строгой идентификации (через IAM платформу);
· с использованием микросегментации;
· c использованием сетевой инфраструктуры.
Zero trust network access (ZTNA) – это комплексный подход применения ZTA.
Как же реализовать концепцию ZTA? В настоящий момент существует два варианта:
· «Чистая ZTA с нуля» для новых инфраструктур. Случай настолько редкий, что, пожалуй, не буду на нем останавливаться.
· Гибридная ZTA, или совместное существование сегментов с реализованной ZTA и классического периметра со старой схемой сегментации. В этом случае миграция чаще всего проводится по одной информационной системе.
Огромным препятствием для внедрения ZTA является “Shadow IT”. Без детальных знаний обо всех активах внедрение может закончиться ступором процесса или всей инфраструктуры целиком.
Стандарт предлагает нам пошаговый алгоритм внедрения ZTA (без привязки к каким-то конкретным производителям и проприетарным технологиям):
1. Определяем все субъекты доступа с обязательным пересмотром полномочий всех административных и сервисных учетных записей.
2. Определяем все объекты доступа и прочие активы: оборудование, цифровые артефакты (учетные записи, сертификаты, сервисы).
3. Параллельно идентифицируем все процессы (workflow) и оцениваем риски.
На этом этапе необходимо провести микросегментацию, желательно (это сэкономит время и нервы) с использованием специализированного ПО, например Cisco Secure Workload (Tetration), предназначенного для целостной защиты рабочих нагрузок для многооблачных центров обработки данных. С помощью сенсоров решение собирает данные, которые потом используются при аналитической обработке сетевых потоков трафика и активных процессов, запущенных в системе контролируемого узла. Благодаря этому платформа позволяет заблаговременно выявлять признаки компрометации и устранять их причины, чтобы свести к минимуму негативные последствия для бизнеса.
Иногда непривычная схема агентской микросегментации вызывает некоторое отторжение у ИТ-департаментов, сражающихся за производительность сервисов. Однако необходимо принять во внимание, что неработоспособный сервис, пораженный вредоносным ПО, которое распространяется через открытые внутри Well-know-порты, для бизнес-процесса намного опаснее по сравнению с невозможностью расширить производительность без уведомления службы ИБ и корректировки политики микросегментации.
4. Приступаем к разработке политики ZTA. Субъекты, объекты, процессы и артефакты делим на:
· входящие потоки данных: например, запросы, взаимодействие с БД, управление;
· исходящие потоки: журналирование, взаимодействие с основными сервисами (LDAP, DNS и т. д.) и активный мониторинг;
· артефакты: сервисные учетные записи, сертификаты и пр.
5. Проверяем, не разрушит ли реализация ZTA сервис или бизнес-процесс. Если имеются обоснованные опасения, необходима корректировка реализации или, в крайнем случае, архитектуры самого сервиса.
6. Применяем политику на средствах микросегментации, защите периметра и системе управления идентификационной информацией.
7. Посистемно (или попроцессно) расширяем ZTA на всю инфраструктуру.
8. Обязательно следим за обратной связью! Не проводя периодических ревизий политики, мы рискуем привести облако в первозданный вид (защищенный не более, чем до внедрения ZTA).
Комментарий Михаила КРЕЧЕТОВА, эксперта по кибербезопасности облачных инфраструктур STEP LOGIC к обзору «Облачный ИБ-периметр»