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

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

Принципы построения безопасной сети

Эффективная сетевая защита основана на многоуровневой архитектуре. Сеть разграничивается на зоны с разными уровнями доверия. Демилитаризованная зона (DMZ) предназначена для сервисов, доступных из интернета, например для веб-серверов. В доверенной зоне размещаются чувствительные данные и ключевая бизнес-логика, доступ к которым жестко регулируется. На границе DMZ применяются традиционные средства защиты, такие как анти-DDoS, файрволы (FW) и WAF (Web Application Firewall).

Решения для ИБ

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

• Защита точек доступа. Бесплатная базовая защита от DDoS-атак на уровнях L3/L4 и продвинутые платные решения до L7, WAF, аппаратные и виртуальные межсетевые экраны.

• Приватная связанность. Глобальный роутер связывает продукты и регионы приватной сетью, а Direct Connect приватно связывает облако Selectel с инфраструктурой on-premise или другими облаками.

• Базовые сервисы. IAM, аудит-логи, менеджер секретов, бэкапы.

• Сертификация. соответствие требованиям 152-ФЗ и ГОСТ 57580, сертификат PCI DSS и так далее.

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

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

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Как устроены сети в облаке

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

Физическая сегментация

На нижнем уровне находятся дата-центры. Несколько ДЦ, физически расположенных рядом друг с другом, объединяются в зону доступности. Каждый дата-центр Selectel — это автономный объект, сертифицированный по Tier III.

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

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

Логическая сегментация

Сети аккаунта в облаке Selectel создаются в проекте. Проект — это способ логически сгруппировать ресурсы внутри аккаунта, чтобы отделить их друг от друга. Это бывает полезно при работе разных команд над разными продуктами или для разграничения среды продакшена от среды разработки. Проекты одного аккаунта недоступны для другого. Каждый проект распределен по всем пулам.

Сеть, созданная в рамках проекта, определена в пределах пула и задает L2-домен бродкаста. Адресное пространство в пределах сетей задается подсетями.

Виртуальные машины, PaaS-сервисы (Managed Kubernetes, DBaaS, балансировщик, облако 1С) и сетевые сервисы (облачный роутер, DHCP) при подключении к подсети получают IP-адрес и сетевые настройки. К последним относятся, например, DNS и статический маршрут из подсети.

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

Доступ в интернет

Для настройки доступа в интернет важно выбрать подходящий под задачи механизм. Это может быть прямой доступ инстанса в интернет через публичную сеть — менее безопасный способ, но не требующий NAT. Более предпочтительный с точки зрения безопасности — это размещение ресурсов в серых сетях с доступом в интернет через NAT на облачном роутере.

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

Для гибкости инфраструктуры и расширения возможностей можно использовать публичные подсети различных размеров — от небольших /29 до больших /24. Также подключать собственные блоки IP-адресов клиентов, что предоставляет широкий простор для масштабирования и управления сетью. 

Инструменты для связности проектов и пулов

Мы разобрали как сегментируется сеть в облаке Selectel на физическом уровне и на уровне SDN. Теперь очень кратко рассмотрим инструменты для настройки связности.

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

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

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

Средства фильтрации трафика

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

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

Облачный файрвол (Cloud Firewall)

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

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

Правила фильтрации могут быть разрешающими или запрещающими. Проверяют следующие критерии проходящего трафика:

• направление трафика относительно сети в которую подключен облачный роутер;

• тип протокола: TCP, UDP, ICMP или любой другой;

• Source (источник) и/или Destination (назначение); 

• порты или диапазон портов (порты приложения, не виртуальный интерфейс);

• IP-адреса или подсети (после NAT).

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

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

Группы безопасности 

Группы безопасности — инструмент сетевой безопасности для контроля трафика на уровне сервера или групп серверов. Правила фильтрации трафика применяются на уровне порта (виртуального сетевого интерфейса) виртуальной машины.

Это дает единообразную логику фильтрации трафика независимо от нескольких факторов.

• Нет зависимости от операционной системы инстанса. Фильтрация одинакова для виртуальных машин на Linux и на Windows.

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

Правила фильтрации в группах безопасности только разрешающие и проверяют следующие критерии проходящего трафика:

• направление трафика относительно виртуальной машины;

• тип протокола: TCP, UDP, ICMP или любой;

• свойства трафика удаленной стороны (remote party);

• порты или диапазон портов;

• CIDR сети или ссылка на группу безопасности другой стороны (UUID).

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

Возможность ссылаться на группы безопасности (в том числе на саму себя) при конфигурации позволяет настраивать правила вне адресного пространства L3. Условно, можно создать правило: разреши трафик, если он приходит с сетевых интерфейсов, на которых есть определенная группа безопасности. Удобство такого подхода я покажу ниже.

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

Лимит на число групп безопасности и правил

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

Группа безопасности по умолчанию

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

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

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

Важная деталь. Из-за того что группы безопасности по умолчанию создаются автоматически, с ними сложно работать через Terraform. Тут мы можем только порекомендовать использовать для Terraform явно созданные группы.

Прозрачность контроля трафика группами безопасности

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

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

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

• Фильтрация одинакова в приватных и публичных сетях.

• У правил нет зависимости от операционной системы инстанса.

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

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

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

Доступ на Bastion-сервер разрешен только для WireGuard VPN-туннеля из публичной подсети. В случае проблем с туннелем, в группу безопасности легко добавить правило, открывающее доступ по SSH.

Из схемы сразу видно, что группа безопасности Allow_Bastion открывает SSHдоступ с Bastion на Web- и App-серверы, но не для кластера баз данных. При этом в правилах не требуется задавать IP-адрес Bastion-сервера, проверка делается по наличию группы безопасности Bastion в источнике трафика (параметр --remote_group).

Другой важный способ защиты сегмента сети — использование группы безопасности со ссылкой на саму себя. Например, на схеме группа безопасности DB разрешает трафик PostgreSQL внутри самой себя, без внешнего доступа. Доступ от серверов приложения App до баз данных явно определяется группой Allow_App.

Контроль IP- и MAC-адресов в сети (Allowed Address Pairs)

По умолчанию в группах безопасности запрещена подмена IP- и MAC-адресов (MAC/IP-spoofing). Т. е. разрешены только MAC-адреса виртуальных сетевых интерфейсов инстансов, подключенных к сети и назначенные на них IP-адреса (через SDN). Это сделано для предотвращения атак с маскировкой злоумышленника под легитимный трафик.

Поскольку MAC/IP-spoofing используется и в легитимных сервисах и технологиях, пользователь может задать до 10 пар MAC/IP-адресов на каждый порт (allowed address pairs). Если это допустимо с точки зрения безопасности, можно разрешить все IP-адреса (0.0.0.0/0) для конкретного MAC-адреса, но в целом так делать не рекомендуется.

Для правильного функционирования отдельных сервисов требуется настроить разрешенные пары IP-адресов и портов. В частности, это касается виртуальных приватных сетей, работающих в режиме проброса оригинального IP-адреса (bridging) или использующих виртуальный пул адресов (client address pool). Такие режимы применяются редко и требуют особой настройки, включая статический роутинг. В большинстве же случаев дополнительные настройки не нужны. 

При самостоятельном развертывании кластера Kubernetes с типом CNI Calico требуется дополнительная настройка пар IP- и MAC-адресов для правильной маршрутизации трафика. Аналогичные настройки нужны для прокси-серверов, которые пробрасывают оригинальный IP-адрес трафика в сеть облака, а также для сетей с организацией VRRP — необходимо корректно настроить разрешенные пары IP и портов для стабильной работы.

Однако в Managed Kubernetes Selectel все эти настройки уже выполнены автоматически. Поэтому пользователям не нужно заниматься настройкой таких пар — все работает из коробки.

Использование групп безопасности в PaaS

Поддержка групп безопасности в PaaS-продуктах Selectel зависит от конкретного продукта и на момент написания статьи статус следующий.

Управление группами безопасности и облачным файрволом полностью поддержано в Terraform в провайдере OpenStack. Для быстрого старта мы подготовили примеры для групп безопасности и облачного файрвола.

Финальные мысли

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

Особое внимание уделяйте компрометации удостоверений и внутренним злоупотреблениям, а не атакам на внешние границы. Поэтому стратегия Zero Trust становится неотъемлемой частью любой архитектуры, основанной на глубоких политиках доступа и постоянном мониторинге аномалий поведения.

Необходимый инструментарий для решения задач начинается с базовых средств ИБ, о которых мы говорили, и заканчивается сервисами DDoS, WAF и NGFW. А также инструментами построения распределенных приватных каналов связи Direct Connect и глобальный роутер.

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

А что вы думаете о современных инструментах для построения защищенных облачных сетей? Делитесь мнением в комментариях.