Шляпы для собак становятся трендом и выгуливать собак без шляп становится «дурным тоном». А наш бизнес продолжает расти.

Растет и количество сервисов, и, соответственно, размеры ЦОДа. Как ни странно, внимание к нашей компании со стороны регуляторов тоже увеличивается, но обо всем по порядку.

Мы, разумеется, находимся на пике технологий, и наш ультрасовременный ЦОД изобилует разного рода SDN (software-defined networking) и прочими оверлейными прелестями, но для логики обеспечения безопасности не столь важно, на каком уровне виртуализации находится сеть, поэтому мы не будем подробно на этом останавливаться. Просто будем иметь ввиду, что сказанное ниже так же относится и к сетям на базе SDN. 

Прежде всего мы обзавелись специально обученными быстрыми коммутаторами, таким образом у нас появилось отдельное ядро сети ЦОДа, и теперь наша сеть делится на, собственно, сеть ЦОДа и на ЛВС для всего остального.

Для полного разделения сегментов ЦОДа даже на уровне маршрутизации мы создаем несколько VRF (Virtual Routing and Forwarding). 

Случай 3 – Крупный ЦОД

ЦОД

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

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

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

Защита персональных данных

Практически каждая организация в своей деятельности использует персональные данные (ПДн), защита которых прописана на законодательном уровне (Федеральный закон 152-ФЗ). Первое, что нужно сделать для соответствия требованиям регуляторов в части ПДн, это определить информационные системы ПДн (ИСПДн) и как можно сильнее сузить зону этих самых ИСПДн, чтобы требования к их защите были применимы только к ограниченной инфраструктуре. Проще говоря, собрать все ИСПДн вместе и организовать для них выделенные сетевые сегменты. Далее эти сегменты необходимо защитить при помощи сертифицированных межсетевых экранов. По сути, это самый обычный межсетевой экран шлюза безопасности, но имеющий соответствующий сертификат Федеральной службы по техническому и экспортному контролю (ФСТЭК). ФСТЭК проверяет, что шлюз действительно выполняет свои функции межсетевого экранирования корректно, после чего и выдает свой сертификат.

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

• во время проведения процедуры сертификации фиксируется строго определенная версия ПО шлюза безопасности, поэтому обновление софта на шлюзе практически невозможно (за исключением случаев, когда дистрибутив обновления тоже будет сертифицирован);

  

• сертифицированный шлюз по требованиям ФСТЭК может иметь только ограниченный функционал: межсетевое экранирование, IPS и контроль сетевых приложений. Антивирус при сертификации по 6 классу, теоретически, тоже есть, но он практически бесполезен без SSL-инспекции, которая недоступна ввиду «выпиленной» на сертифицированном шлюзе стойкой криптографии. Весь остальной функционал заблокирован. Кстати, регулярно обновляемые сигнатуры IPS также должны быть сертифицированы, поэтому они обычно скачиваются с ресурса сертификационной организации-заявителя и вручную «подсовываются» на шлюз.

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

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

В принципе, можно и весь шлюз безопасности ЦОД сделать сертифицированным, но нужно держать в голове потенциальные проблемы с обновлением софта и сигнатур IPS:

Конечно, бывают случаи, когда вся сеть организации является сетью ИСПДн, тогда сертифицированный шлюз должен стоять на периметре сети, но и здесь есть небольшой лайфхак как и соответствовать требованиям регуляторов, и использовать полный функционал UTM – мы ставим сертифицированный шлюз между ЛВС и периметральным шлюзом. Периметральный шлюз дает нам функционал UTM, а сертифицированный шлюз «прикрывает» ЛВС и позволяет соответствовать требованиям регуляторов:

Защита веб-серверов

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

И задались вопросом – куда же поставить новый веб-сервер в нашей сети? Разумеется, все ресурсы, к которым предоставляется доступ из сети Интернет, должны быть в ДМЗ периметрального шлюза для контроля трафика между сетью Интернет и ресурсом, а также между ресурсом и ЛВС. Кроме того, трафик из сети Интернет должен очень глубоко проверяться, т.к. веб-серверы – весьма уязвимое место. В этом нам может помочь функционал Web Application Firewall (WAF). WAF специализируется на предотвращении атак именно на веб-приложения и в этом сейчас ему лучшую альтернативу найти не просто. Многие шлюзы безопасности имеют встроенный функционал WAF, он защитит от ряда атак, но полноценной защиты обеспечить не сможет. Все-таки специализированное средство, такое как Fortinet FortiWAF или PT Application Firewall, здесь, несомненно, выигрывает. 

Итак, мы расположим веб-сервер в одной из наших ДМЗ и логически перед ним поставим WAF:

Если наш веб-сервер находится в облаке, то и WAF мы также помещаем в облако аналогично защите электронной почты.

Но защита веб-серверов на это не заканчивается.

Разумеется, мы помним о наших конкурентах, которые в борьбе за четвероногую аудиторию готовы на все. Они способны даже на такое «грязное» дело, как организация DDoS-атаки на наш интернет-магазин чтобы дискредитировать наше доброе имя и лишить нас клиентов.

DDoS-атака (Distributed Denial of Service, распределённая атака типа «отказ в обслуживании») характеризуется тем, что большое количество зараженных машин пытаются получить доступ к целевому серверу обычным для пользователей способом, но при этом либо сервер не выдерживает такой нагрузки, либо канал не справляется с таким потоком. 

Как же нам выявить и разделить трафик легитимных пользователей и зомби-машин? Здесь следует внимательно изучать трафик на предмет аномалий и с этим IPS шлюза безопасности нам не поможет – у каждого веб-сервера свой «нормальный» профиль трафика, который нужно изучить и от которого будет отталкиваться выявление аномалий и очистка трафика. Кроме того, сам шлюз является stateful, т.е. он отслеживает все устанавливаемые сессии, и, если их будет очень много, может и сам «прилечь» от нагрузки. 

Поэтому подходящим решением вопроса является специализированная система, которая будет строить защиту на основании обучения и профилирования трафика, а также будет stateless, т.е. не будет хранить информацию об установленных соединениях. Как вариант, это может быть Netscout Arbor DDoS, Fortinet FortiDDoS, отечественный БИФИТ Митигатор, сервис оператора связи или же облачный Kaspersky DDoS Protection. 

Защита от DDoS актуальна на Интернет-каналах, поэтому и располагать ее будем именно там. Но прежде рассмотрим варианты, которые предлагает нам рынок:

Вариант 1 – защита от DDoS собственными средствами

Средство защиты от DDoS устанавливается на все Интернет-каналы «в разрыв» между периметральным шлюзом и сетью Интернет:

Вариант 2 – защита от DDoS как сервис оператора связи

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

Вариант 3 – облачная защита от DDoS

Ситуация похожа на вариант с оператором связи, где фильтрация трафика предоставляется как сервис, но с существенным отличием – теперь этим занимается сторонняя организация и нужно каким-либо образом перенаправить трафик на нее. Штатным вариантом является перенаправление на сетевом уровне через анонсирование сторонней организацией наших BGP-префиксов, а от нас до организации строится, например, GRE-туннель:

Давайте в этот раз выберем вариант 1.

В следующей части мы рассмотрим безопасность филиальной сети.