Главная / Безопасность / Сетевая безопасность
Network Security

Безопасность сети начинается с отсутствия лишних соединений.

Проектируем корпоративные сети с изоляцией сервисов, строгими правилами доступа и централизованным управлением безопасностью.

  • Isolate
  • Allow what is required
  • Control everything else
Логическая схема сегментированной сети Семь логических зон — Internet, Clients, DMZ, Servers, Infrastructure, MGMT и Backup — соединены только через центральный Security Gateway. Прямых связей между зонами нет. INTERNET untrusted CLIENTS DMZ SERVERS MGMT INFRASTRUCTURE BACKUP SECURITY GATEWAY default: deny
Условная схема. Все межзонные соединения проходят через firewall и разрешаются явными правилами.

Наш подход к построению защищённых сетей

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

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

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

  1. Принцип 01

    Один сервис — один сетевой сегмент

    По умолчанию самостоятельный сервис размещается в отдельном VLAN.

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

  2. Принцип 02

    Запрещено всё, что не разрешено явно

    Отсутствие разрешающего правила означает отсутствие доступа. Это относится к:

    • входящим подключениям
    • исходящим подключениям
    • взаимодействию между внутренними сервисами
    • доступу в Интернет
  3. Принцип 03

    Сеть разделена на функциональные зоны

    Разные категории активов имеют разные модели угроз и политики доступа.

    CLIENTS
    пользовательские устройства и клиентские сети
    SERVERS
    внутренние бизнес-сервисы
    DMZ
    сервисы, принимающие подключения извне
    INFRASTRUCTURE
    AD, DNS, NTP, мониторинг и другие базовые службы
    MGMT
    управление серверами, гипервизорами, firewall и сетевым оборудованием
    BACKUP
    системы резервного копирования и восстановления
  4. Принцип 04

    Серверу не нужен Интернет по умолчанию

    Внутренние серверы не получают прямой неограниченный доступ в Интернет.

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

  5. Принцип 05

    Общая инфраструктура централизована

    Системы получают доступ только к необходимым инфраструктурным службам. Например:

    Active Directory
    аутентификация и доменные службы
    DNS
    разрешение имён
    NTP
    централизованная синхронизация времени
    Update Proxy
    контролируемый доступ к обновлениям
    Monitoring
    контроль состояния инфраструктуры
  6. Принцип 06

    Серверы не доверяют друг другу по умолчанию

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

    • Application Server SQL Serverможет быть разрешено
    • Application Server ALL SERVERSне следует
    • SQL Server ALL SERVERSне следует

    Каждая зависимость определяется отдельно.

  7. Принцип 07

    Административный доступ отделён от пользовательского

    Управление инфраструктурой производится через выделенные административные сети и контролируемые точки входа.

    Пользовательская рабочая станция не должна иметь прямой доступ к management-интерфейсам:

    • firewall
    • switches
    • hypervisors
    • storage
    • backup
    • серверных систем

    Для административного доступа используются отдельные MGMT-сети, административный VPN и другие контролируемые механизмы.

  8. Принцип 08

    Публичные сервисы изолированы

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

    • DMZ LANзапрещено по умолчанию

    Разрешаются только конкретные технологические зависимости.

  9. Принцип 09

    Сетевые взаимодействия должны быть наблюдаемыми

    Безопасность — это не только блокировка соединений. Архитектура должна предусматривать:

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

    Безопасность должна масштабироваться

    Добавление нового сервиса не должно требовать хаотичного изменения firewall. Стандартный процесс подключения сервиса:

    1. определить назначение
    2. создать отдельный сетевой сегмент
    3. определить функциональную зону
    4. описать необходимые входящие соединения
    5. описать необходимые исходящие соединения
    6. создать firewall policy
    7. подключить мониторинг
    8. подключить резервное копирование
    9. документировать зависимости

Логическая модель сегментированной сети

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

SERVERS

Внутренние бизнес-сервисы компании. Каждый самостоятельный сервис размещается в собственном VLAN.

Типовые активы

  • 1С
  • SQL
  • Почтовый сервер
  • Файловое хранилище
  • Прикладные серверы

Может инициировать соединения к

  • INFRASTRUCTURE — AD, DNS, NTP, Update Proxy
  • SERVERS — только явно описанные зависимости (например, приложение → СУБД)

Кто может подключаться к зоне

  • CLIENTS — прикладные протоколы опубликованных сервисов
  • DMZ — только конкретные технологические зависимости
  • MGMT — административные протоколы
  • BACKUP — агенты и задания резервного копирования
  • INFRASTRUCTURE — мониторинг
Базовый принцип

Сервер ≠ доверенный узел. Нет прямого доступа в Интернет, нет свободного доступа к соседним серверам.

Схема иллюстрирует принцип и не является проектом конкретной сети: состав зон и правил определяется по результатам обследования.

Каждый сервис — в собственном сегменте

Между VLAN нет автоматического доверия. Firewall определяет, какие взаимодействия допустимы, — всё остальное запрещено.

Zone: SERVERS
  • VLAN 101ACTIVE DIRECTORY
  • VLAN 102EXCHANGE
  • VLAN 1031C
  • VLAN 104SQL
  • VLAN 105ZABBIX
  • VLAN 106FILE STORAGE
Firewall policy inter-VLAN default: DENY
  • VLAN 103 · 1C VLAN 104 · SQLAllow · порт СУБД
  • VLAN 102 · EXCHANGE VLAN 101 · ADAllow · доменные службы
  • VLAN 105 · ZABBIX VLAN 101–106Allow · протокол мониторинга
  • VLAN 1xx VLAN 1xxDeny · всё остальное

Номера VLAN и набор сервисов условные и приведены для иллюстрации.

Пример сетевой политики

Политика описывает не «кто в какой сети», а какие конкретные соединения нужны. Правила обрабатываются сверху вниз; последнее правило — запрет.

Пример матрицы разрешённых взаимодействий
#ИсточникНазначениеДействиеЧто разрешено
01CLIENTSACTIVE DIRECTORYAllowНеобходимые доменные службы
02CLIENTSEXCHANGEAllowHTTPS
03CLIENTSBUSINESS APPLICATIONAllowПротокол приложения
04SERVERSACTIVE DIRECTORYAllowНеобходимые доменные службы
05SERVERSNTPAllowТолько внутренний NTP
06SERVERSUPDATE PROXYAllowПодключение к proxy
07MGMTMANAGED SYSTEMSAllowНеобходимые протоколы администрирования
08SERVERSINTERNETDeny—
09SERVERSERVERDeny by defaultТолько явно описанные зависимости
10DMZINTERNAL SERVERSDeny by defaultТолько конкретные технологические зависимости
∗ANYANYDenyВсё, что не разрешено выше

Что произойдёт, если один сервер взломают?

Сравните, как распространяется атака в плоской сети и в сегментированной архитектуре.

Traditional flat network

Плоская сеть

  1. COMPROMISED SERVER
  2. OTHER SERVERS
  3. DATABASES
  4. BACKUPS
  5. INFRASTRUCTURE

Нет внутренних границ — каждый следующий шаг доступен с предыдущего.

Segmented WolfNex architecture

Сегментированная сеть

  1. COMPROMISED SERVER
  2. FIREWALL POLICY
  3. ONLY EXPLICITLY PERMITTED CONNECTIONS
Заблокировано политикой
  • Другие серверы
  • Базы данных без явного правила
  • Системы резервного копирования
  • Management-интерфейсы

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

Мы не обещаем, что отдельный компонент инфраструктуры никогда не будет скомпрометирован.

Мы проектируем инфраструктуру так, чтобы компрометация одного компонента не предоставляла автоматически доступ ко всей системе.

  • Мы не доверяем сети только потому, что она внутренняя.
  • Мы не открываем доступ только потому, что так проще.
  • Мы не объединяем сервисы только потому, что они принадлежат одной компании.
  • Мы не предоставляем серверам Интернет, если он не нужен для их работы.

Isolate. Allow what is required. Control everything else.

Как WolfNex строит сети

  1. 01

    Discovery

    Инвентаризация существующей инфраструктуры.
  2. 02

    Classification

    Классификация сервисов, активов и зависимостей.
  3. 03

    Segmentation

    Проектирование VLAN и зон безопасности.
  4. 04

    Traffic matrix

    Формирование матрицы разрешённых взаимодействий.
  5. 05

    Enforcement

    Реализация политики на firewall.
  6. 06

    Observability

    Мониторинг, журналирование и контроль событий.
  7. 07

    Backup

    Защита систем восстановления.
  8. 08

    Documentation

    Документирование архитектуры и зависимостей.
  9. 09

    Testing

    Проверка фактической изоляции сегментов.

Инфраструктура должна быть готова к тому, что один из её компонентов окажется скомпрометирован.

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

Обсудить архитектуру сети

Обсудить архитектуру сети

Расскажите о текущей инфраструктуре и задаче — вернёмся с вопросами в течение рабочего дня.

Телефон +7 962 957-37-37

Оставить заявку

Заполните форму — ответим на почту в течение рабочего дня.