Итак, наш бизнес идет отлично, шляпы продаются, количество сотрудников увеличивается, формируются отдельные подразделения: маркетинг, продажи, логистика. Потребность в своих собственных корпоративных сервисах становится все сильнее. Для них мы арендуем дополнительное помещение, покупаем пару серверов с виртуализацией, чтобы было все как у людей, и получаем небольшого размера центр обработки данных (ЦОД). Соответственно, создаем ядро нашей корпоративной сети на базе стека хороших коммутаторов. Количество сотрудников значительно выросло и для обеспечения стабильной связи мы организуем инфраструктуру Wi-Fi с точками доступа и контроллером для управления.

Случай 2 – Офис среднего размера

ЦОД

Здесь самое главное, что необходимо сделать – выполнить сегментирование сети и логически отделить сегменты сервисов (назовем их сегментами ЦОДа) от сегментов пользователей.

Далее нам требуется каким-либо образом разграничить доступ пользователей к сети ЦОДа и на начальном этапе нам будет достаточно правил контроля доступа (Access Control List, ACL) на уровне L3-L4 (Firewall), которые возможно реализовать либо на уже существующем у нас шлюзе безопасности, либо даже на коммутаторе ядра сети – когда сервисов немного, для экономии средств можно воспользоваться функционалом коммутаторов. Это неудобно и создает дополнительную нагрузку на коммутатор, но экономически может быть оправдано. 

Беспроводная сеть

Необходимо создать, как минимум, две сети – для сотрудников и для гостей. Трафик сотрудников возможно направлять сразу на ядро сети аналогично «проводным» пользователям, гостей необходимо логически поместить в специальный выделенный сегмент на шлюзе безопасности – демилитаризованную зону (ДМЗ). В большинстве случаев гостевым пользователям не требуется доступ к корпоративным ресурсам, а только доступ к сети Интернет, что мы им и предоставляем, ограничивая доступ «внутрь» корпоративной сети при помощи шлюза безопасности. 

Кроме того, с ростом количества пользователей растет и необходимость их корректной аутентификации, например, по доменным учетным записям (в случае интеграции с доменом), в чем нам помогает сервер с функционалом ААА (Authentication, Authorization, Accounting). Беспроводные пользователи отправляют данные аутентификации через точку доступа на контроллер, а контроллер – на сервер AAA, который уже аутентифицирует пользователей либо нет. Также сервер AAA будет очень полезен для централизованной аутентификации и авторизации администраторов при доступе к сетевому оборудованию. Примером сервера ААА может быть Fortinet FortiAuthenticator, Cisco Identity Services Engine или же служба в Active Directory. 

Периметр сети

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

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

Нам нужно закрыть два направления: движение непосредственно почты по протоколу SMTP и удаленный доступ пользователей к своей почте из любой локации. 

Для контроля и проверки SMTP-трафика используются дополнительные средства безопасности, встраиваемые в поток почтового трафика в качестве Mail Relay. Трафик из Интернета при помощи перенаправления MX-записей сперва попадает на Mail Relay, проверяется и только потом отправляется на наш почтовый сервер. 

Такой Mail Relay должен обладать как минимум тремя функциями: антиспам (Anti-Spam) для защиты от нежелательной корреспонденции, и рассмотренные выше антивирус, песочница и обезвреживание файлов. Также можно разнести эти функции на разные средства защиты и тогда у нас будет цепочка Mail Relay’ев. 

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

Удаленный доступ

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

Во-первых, необходимо защитить каналы связи между нашими сервисами и удаленными пользователями стойкой криптографией. Если у нас на периметре стоит шлюз безопасности, то защитить каналы легко – пользователи устанавливают защищенное VPN-соединение со шлюзом безопасности. Для этого обычно используются стандартные клиенты для рабочих станций от того же производителя шлюзов. При этом шлюз безопасности может располагаться на нашей площадке, а может и в облаке как SaaS.

Во-вторых, нам нужно удостовериться, что удаленный пользователь действительно тот, за кого себя выдает. Здесь возможны различные варианты аутентификации – доменные реквизиты, сертификаты и т.д., но важно здесь именно наличие второго фактора аутентификации, который очень сильно снижает вероятность несанкционированного подключения к корпоративным ресурсам. Вторым фактором могут быть аппаратный или программный токен, одноразовые пароли, SMS-сообщения, кому что удобнее. Таких средств много, например Fortinet FortiToken, Cisco DUO, SMS-сервисы операторов связи.

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

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

Отдельно рассмотрим такой класс решений как криптоконтейнеры. Сейчас без преувеличения можно сказать, что все наши сотрудники имеют свои собственные устройства, например, смартфоны и планшеты, которые удобно использовать и в рабочих целях. Но где провести грань между корпоративной и личной информацией? С помощью криптоконтейнеров мы можем создать кусочек корпоративного пространства в личном устройстве сотрудника – это изолированное пространство, откуда вытащить информацию в приемлемом виде невозможно (фото экрана не в счет). Контейнер защищен стойким шифрованием и подключается по защищенным каналам к корпоративным ресурсам. Примерами могут служить такие специализированные решения, как Check Point Capsule Workspace, или же полноценные MDM-системы как VMware AirWatch.

В дополнение темы – сейчас наблюдается рост популярности технологии Zero Trust Network Access (ZTNA), которая весьма хорошо себя показывает и при удаленном доступе. Как вариант, при ZTNA корпоративные приложения при помощи специальных коннекторов публикуются на защищенном портале, где каждому пользователю доступны только те приложения, которые ему действительно нужны. Проверку подлинности пользователя и контроль доступа к приложениям осуществляет средство защиты.

Далее рассмотрим варианты:

Вариант 1 – почтовый сервер и шлюз безопасности внутри периметра, защита почты шлюзом безопасности:

Один из наиболее распространенных в нашей стране случаев. Почтовый сервер располагается в ЦОДе, на периметре шлюз безопасности в качестве Mail Relay. Почтовый трафик из сети Интернет попадает на шлюз, где выполняются всесторонние проверки и фильтрация, далее трафик отправляется на внутренний почтовый сервер. Все бы хорошо, но есть нюанс – по опыту использования шлюзов безопасности функционал антиспама чуть более чем бесполезен ввиду его откровенно плохой реализации, поэтому мы и не включили его в состав UTM. До начала проверки трафика на шлюзе необходимо его отфильтровать, причем на адекватной антиспам-системе, к примеру, Kaspersky Secure Mail Gateway. Логически, трафик из сети интернет предварительно проходит фильтрацию на антиспаме и затем подвергается проверкам на шлюзе как на более дорогом ресурсе. Нет смысла отправлять файл на эмуляцию, которая занимает дорогие ресурсы виртуальных машин, если файл идет вложением в нежелательной почте. 

Вариант 2 – почтовый сервер и шлюз безопасности внутри периметра, защита почты специализированными средствами:

Шлюз безопасности с функционалом UTM – прекрасное решение «все в одном флаконе», с ним легко и просто можно закрыть большинство векторов атак. Но для максимального эффекта не стоит пренебрегать и специализированными узконаправленными средствами. К примеру, по защите электронной почты формата Fortinet FortiMail или того же Kaspersky Secure Mail Gateway (в котором, правда, песочница есть только при интеграции с монструозным Kaspersky Anti Targeted Attack).

В таком случае шлюзу не обязательно проверять почтовый трафик, всю работу (в т.ч. и Mail Relay) на себя берет средство защиты электронной почты.

Вариант 3 – защита почты в облаке:

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

Здесь подойдут SaaS-решения, которые будут проверять почтовый трафик до того, как он достигнет почтового сервера и пользователи получат доступ к сообщениям.

Лично мне нравится вариант 2, на нем и остановимся.

Развитие нашего ЦОДа рассмотрим в следующей части.