Безопасность сети начинается с отсутствия лишних соединений.
Проектируем корпоративные сети с изоляцией сервисов, строгими правилами доступа и централизованным управлением безопасностью.
- Isolate
- Allow what is required
- Control everything else
Наш подход к построению защищённых сетей
Мы исходим из того, что любая рабочая станция, сервер или приложение потенциально могут быть скомпрометированы.
Поэтому безопасность инфраструктуры не должна зависеть исключительно от защиты внешнего периметра.
Сеть проектируется так, чтобы каждый её компонент имел только те возможности взаимодействия, которые действительно необходимы для выполнения его задачи.
-
Принцип 01
Один сервис — один сетевой сегмент
По умолчанию самостоятельный сервис размещается в отдельном VLAN.
Сервисы не объединяются в одну сеть только потому, что они принадлежат одной компании. Сетевые границы определяются технологическими зависимостями.
-
Принцип 02
Запрещено всё, что не разрешено явно
Отсутствие разрешающего правила означает отсутствие доступа. Это относится к:
- входящим подключениям
- исходящим подключениям
- взаимодействию между внутренними сервисами
- доступу в Интернет
-
Принцип 03
Сеть разделена на функциональные зоны
Разные категории активов имеют разные модели угроз и политики доступа.
- CLIENTS
- пользовательские устройства и клиентские сети
- SERVERS
- внутренние бизнес-сервисы
- DMZ
- сервисы, принимающие подключения извне
- INFRASTRUCTURE
- AD, DNS, NTP, мониторинг и другие базовые службы
- MGMT
- управление серверами, гипервизорами, firewall и сетевым оборудованием
- BACKUP
- системы резервного копирования и восстановления
-
Принцип 04
Серверу не нужен Интернет по умолчанию
Внутренние серверы не получают прямой неограниченный доступ в Интернет.
Если серверу необходимо получать обновления, они выполняются через контролируемый proxy. Иные внешние соединения разрешаются только при наличии документированной технической необходимости.
-
Принцип 05
Общая инфраструктура централизована
Системы получают доступ только к необходимым инфраструктурным службам. Например:
- Active Directory
- аутентификация и доменные службы
- DNS
- разрешение имён
- NTP
- централизованная синхронизация времени
- Update Proxy
- контролируемый доступ к обновлениям
- Monitoring
- контроль состояния инфраструктуры
-
Принцип 06
Серверы не доверяют друг другу по умолчанию
Принадлежность двух серверов одной компании не является основанием для свободного сетевого взаимодействия.
- Application Server SQL Serverможет быть разрешено
- Application Server ALL SERVERSне следует
- SQL Server ALL SERVERSне следует
Каждая зависимость определяется отдельно.
-
Принцип 07
Административный доступ отделён от пользовательского
Управление инфраструктурой производится через выделенные административные сети и контролируемые точки входа.
Пользовательская рабочая станция не должна иметь прямой доступ к management-интерфейсам:
- firewall
- switches
- hypervisors
- storage
- backup
- серверных систем
Для административного доступа используются отдельные MGMT-сети, административный VPN и другие контролируемые механизмы.
-
Принцип 08
Публичные сервисы изолированы
Системы, принимающие подключения из Интернета, рассматриваются как активы с повышенной вероятностью атаки. Публичный сервис не получает свободного доступа к внутренней инфраструктуре.
- DMZ LANзапрещено по умолчанию
Разрешаются только конкретные технологические зависимости.
-
Принцип 09
Сетевые взаимодействия должны быть наблюдаемыми
Безопасность — это не только блокировка соединений. Архитектура должна предусматривать:
- мониторинг;
- централизованные журналы;
- контроль состояния оборудования;
- уведомления об инцидентах;
- резервное копирование конфигураций;
- документирование сетевых зависимостей.
-
Принцип 10
Безопасность должна масштабироваться
Добавление нового сервиса не должно требовать хаотичного изменения firewall. Стандартный процесс подключения сервиса:
- определить назначение
- создать отдельный сетевой сегмент
- определить функциональную зону
- описать необходимые входящие соединения
- описать необходимые исходящие соединения
- создать firewall policy
- подключить мониторинг
- подключить резервное копирование
- документировать зависимости
Логическая модель сегментированной сети
Выберите зону, чтобы увидеть её назначение, типовые активы и допустимые направления соединений. Все межзонные потоки проходят через Security Gateway.
SERVERS
Внутренние бизнес-сервисы компании. Каждый самостоятельный сервис размещается в собственном VLAN.
Типовые активы
Может инициировать соединения к
- INFRASTRUCTURE — AD, DNS, NTP, Update Proxy
- SERVERS — только явно описанные зависимости (например, приложение → СУБД)
Кто может подключаться к зоне
- CLIENTS — прикладные протоколы опубликованных сервисов
- DMZ — только конкретные технологические зависимости
- MGMT — административные протоколы
- BACKUP — агенты и задания резервного копирования
- INFRASTRUCTURE — мониторинг
Сервер ≠ доверенный узел. Нет прямого доступа в Интернет, нет свободного доступа к соседним серверам.
Схема иллюстрирует принцип и не является проектом конкретной сети: состав зон и правил определяется по результатам обследования.
Каждый сервис — в собственном сегменте
Между VLAN нет автоматического доверия. Firewall определяет, какие взаимодействия допустимы, — всё остальное запрещено.
- VLAN 101ACTIVE DIRECTORY
- VLAN 102EXCHANGE
- VLAN 1031C
- VLAN 104SQL
- VLAN 105ZABBIX
- VLAN 106FILE STORAGE
- VLAN 103 · 1C VLAN 104 · SQLAllow · порт СУБД
- VLAN 102 · EXCHANGE VLAN 101 · ADAllow · доменные службы
- VLAN 105 · ZABBIX VLAN 101–106Allow · протокол мониторинга
- VLAN 1xx VLAN 1xxDeny · всё остальное
Номера VLAN и набор сервисов условные и приведены для иллюстрации.
Пример сетевой политики
Политика описывает не «кто в какой сети», а какие конкретные соединения нужны. Правила обрабатываются сверху вниз; последнее правило — запрет.
| # | Источник | Назначение | Действие | Что разрешено |
|---|---|---|---|---|
| 01 | CLIENTS | ACTIVE DIRECTORY | Allow | Необходимые доменные службы |
| 02 | CLIENTS | EXCHANGE | Allow | HTTPS |
| 03 | CLIENTS | BUSINESS APPLICATION | Allow | Протокол приложения |
| 04 | SERVERS | ACTIVE DIRECTORY | Allow | Необходимые доменные службы |
| 05 | SERVERS | NTP | Allow | Только внутренний NTP |
| 06 | SERVERS | UPDATE PROXY | Allow | Подключение к proxy |
| 07 | MGMT | MANAGED SYSTEMS | Allow | Необходимые протоколы администрирования |
| 08 | SERVERS | INTERNET | Deny | — |
| 09 | SERVER | SERVER | Deny by default | Только явно описанные зависимости |
| 10 | DMZ | INTERNAL SERVERS | Deny by default | Только конкретные технологические зависимости |
| ∗ | ANY | ANY | Deny | Всё, что не разрешено выше |
Что произойдёт, если один сервер взломают?
Сравните, как распространяется атака в плоской сети и в сегментированной архитектуре.
Плоская сеть
- COMPROMISED SERVER
- OTHER SERVERS
- DATABASES
- BACKUPS
- INFRASTRUCTURE
Нет внутренних границ — каждый следующий шаг доступен с предыдущего.
Сегментированная сеть
- COMPROMISED SERVER
- FIREWALL POLICY
- ONLY EXPLICITLY PERMITTED CONNECTIONS
- Другие серверы
- Базы данных без явного правила
- Системы резервного копирования
- Management-интерфейсы
Разрешённые соединения тоже остаются поверхностью атаки — поэтому они минимальны, задокументированы и наблюдаемы.
Мы не обещаем, что отдельный компонент инфраструктуры никогда не будет скомпрометирован.
Мы проектируем инфраструктуру так, чтобы компрометация одного компонента не предоставляла автоматически доступ ко всей системе.
- Мы не доверяем сети только потому, что она внутренняя.
- Мы не открываем доступ только потому, что так проще.
- Мы не объединяем сервисы только потому, что они принадлежат одной компании.
- Мы не предоставляем серверам Интернет, если он не нужен для их работы.
Isolate. Allow what is required. Control everything else.
Как WolfNex строит сети
- 01
Discovery
Инвентаризация существующей инфраструктуры. - 02
Classification
Классификация сервисов, активов и зависимостей. - 03
Segmentation
Проектирование VLAN и зон безопасности. - 04
Traffic matrix
Формирование матрицы разрешённых взаимодействий. - 05
Enforcement
Реализация политики на firewall. - 06
Observability
Мониторинг, журналирование и контроль событий. - 07
Backup
Защита систем восстановления. - 08
Documentation
Документирование архитектуры и зависимостей. - 09
Testing
Проверка фактической изоляции сегментов.
Инфраструктура должна быть готова к тому, что один из её компонентов окажется скомпрометирован.
Мы проектируем сети так, чтобы последствия отдельного инцидента оставались ограниченными, а критические бизнес-сервисы продолжали работать.
Обсудить архитектуру сетиОбсудить архитектуру сети
Расскажите о текущей инфраструктуре и задаче — вернёмся с вопросами в течение рабочего дня.