Zero Trust: пошаговое внедрение в корпоративной сети

Традиционная модель безопасности «замок и ров» предполагает, что всё внутри корпоративной сети — доверенное. Файрвол защищает периметр, а внутренний трафик не контролируется. Эта модель перестала работать: VPN-доступ размывает периметр, атаки через фишинг обходят файрвол, а латеральное движение злоумышленника внутри сети не блокируется.

Zero Trust — модель, в которой доверие не предоставляется ни одному пользователю, устройству или сети по умолчанию. Каждый запрос на доступ проверяется, независимо от источника.

Три ключевых принципа:

• Verify explicitly — проверяйте каждый запрос по всем доступным сигналам: пользователь, устройство, местоположение, время, классификация данных
• Use least privilege access — предоставляйте минимально необходимый доступ, ограниченный по времени (JIT/JEA)
• Assume breach — проектируйте систему в предположении, что злоумышленник уже внутри. Минимизируйте радиус поражения через сегментацию

Невозможно защитить то, о чём вы не знаете. Первый этап — полная инвентаризация активов, данных и потоков трафика.

# Сканирование сети для обнаружения всех устройств
nmap -sn 10.0.0.0/16 -oX network_scan.xml

# Идентификация ОС и сервисов
nmap -sV -O -T4 10.0.0.0/24 -oX detailed_scan.xml

# Анализ потоков трафика через NetFlow на маршрутизаторе MikroTik
/ip traffic-flow
set enabled=yes interfaces=all
/ip traffic-flow target
add dst-address=10.0.1.50 port=2055 version=9

Документируйте:

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

Результат этапа — карта зависимостей (dependency map), показывающая все легитимные потоки трафика. Всё, что не в карте — потенциально опасно.

Identity — краеугольный камень Zero Trust. Без надёжной аутентификации остальные меры бессмысленны.

Обязательные шаги:

• Внедрение MFA для всех учётных записей без исключений
• Отказ от паролей в пользу FIDO2/WebAuthn (аппаратные ключи YubiKey)
• Conditional Access — контекстные правила доступа
• SSO (Single Sign-On) для унификации точки аутентификации

# Пример Conditional Access Policy (Azure AD / Entra ID)
# Через Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
  displayName = "Require MFA for all users"
  state = "enabled"
  conditions = @{
    users = @{ includeUsers = @("All") }
    applications = @{ includeApplications = @("All") }
    locations = @{
      includeLocations = @("All")
      excludeLocations = @("AllTrusted")  # MFA не требуется из офиса
    }
  }
  grantControls = @{
    operator = "OR"
    builtInControls = @("mfa")
  }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Для on-premise инфраструктуры без Azure AD используйте RADIUS с поддержкой MFA (FreeRADIUS + Google Authenticator или privacyIDEA).

Микросегментация — разделение сети на мелкие зоны с контролем трафика между ними. Вместо одного большого VLAN с сотнями устройств — десятки мелких сегментов, где каждый поток трафика явно разрешён.

# Пример сегментации на MikroTik
# VLAN-ы:
# 10 — Управление
# 20 — Серверы (DMZ)
# 30 — Бухгалтерия
# 40 — Разработчики
# 50 — VoIP
# 60 — Wi-Fi гости

# Правила: бухгалтерия → только 1С и файловый сервер
/ip firewall filter
add chain=forward src-address=10.0.30.0/24 dst-address=10.0.20.10 \
    dst-port=1541,1560-1591 protocol=tcp action=accept \
    comment="Accounting -> 1C Server"
add chain=forward src-address=10.0.30.0/24 dst-address=10.0.20.11 \
    dst-port=445 protocol=tcp action=accept \
    comment="Accounting -> File Server SMB"
add chain=forward src-address=10.0.30.0/24 dst-address=10.0.20.0/24 \
    action=drop comment="Accounting -> Servers DENY ALL OTHER"

# Разработчики → серверы разработки, Git, CI/CD
add chain=forward src-address=10.0.40.0/24 dst-address=10.0.20.20 \
    dst-port=22,80,443,3000,8080 protocol=tcp action=accept \
    comment="Dev -> Dev servers"
add chain=forward src-address=10.0.40.0/24 dst-address=10.0.20.0/24 \
    action=drop comment="Dev -> Servers DENY ALL OTHER"

# Запрет трафика между пользовательскими сегментами
add chain=forward src-address=10.0.30.0/24 dst-address=10.0.40.0/24 \
    action=drop comment="Accounting -X-> Dev"
add chain=forward src-address=10.0.40.0/24 dst-address=10.0.30.0/24 \
    action=drop comment="Dev -X-> Accounting"

Принцип: default deny. Всё, что явно не разрешено — запрещено. Начинайте с режима мониторинга (action=log), анализируйте трафик неделю, затем переключайте на drop.

Zero Trust требует проверки не только пользователя, но и устройства. Network Access Control (NAC) допускает в сеть только устройства, соответствующие политикам безопасности.

Что проверять:

• Устройство введено в домен или зарегистрировано в MDM
• ОС обновлена (последние security-патчи)
• Антивирус установлен и базы актуальны
• Шифрование диска включено (BitLocker/FileVault)
• Файрвол ОС активен

# PacketFence — open-source NAC
# /usr/local/pf/conf/authentication.conf
[AD_Auth]
  type=AD
  host=10.0.20.5
  basedn=DC=domain,DC=local
  binddn=CN=pf-service,OU=Service,DC=domain,DC=local
  password=SecurePass123
  scope=sub
  usernameattribute=sAMAccountName
  stripped_user_name=yes

# Правило: некомплаентное устройство → карантинный VLAN
# /usr/local/pf/conf/profiles.conf
[compliant]
  filter=connection_type
  value=Ethernet-EAP
  vlan=production
  
[non_compliant]
  filter=connection_type
  value=Ethernet-EAP
  vlan=quarantine
  registration=enabled

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

В модели Zero Trust сеть считается враждебной. Весь трафик должен быть зашифрован, даже внутри корпоративной LAN.

Протоколы шифрования по уровням:

• Сетевой уровень: IPSec между серверами и сегментами. WireGuard для site-to-site
• Транспортный уровень: TLS 1.3 для всех веб-сервисов. mTLS для межсервисного взаимодействия
• Прикладной уровень: SSH вместо Telnet, HTTPS вместо HTTP, LDAPS вместо LDAP

# Настройка IPSec между серверами (strongSwan)
# /etc/ipsec.conf
conn server-to-server
    type=transport
    authby=psk
    left=10.0.20.10
    right=10.0.20.11
    auto=start
    esp=aes256gcm16-sha384-prfsha384-ecp384!
    ike=aes256gcm16-sha384-prfsha384-ecp384!

# Включение mTLS на nginx
server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;
    ssl_protocols TLSv1.3;
}

Для внутренних сервисов разверните корпоративный PKI (ADCS или step-ca) для автоматической выдачи и ротации сертификатов.

Zero Trust требует постоянной проверки: каждый сеанс, каждый запрос анализируется на аномалии. Настройте централизованный сбор логов и автоматическое реагирование.

# Wazuh — open-source SIEM для Zero Trust мониторинга
# /var/ossec/etc/ossec.conf на агенте
<ossec_config>
  <syscheck>
    <directories check_all="yes" realtime="yes">/etc</directories>
    <directories check_all="yes" realtime="yes">/usr/bin</directories>
  </syscheck>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
</ossec_config>

# Правило: алерт при входе T0-аккаунта с нового устройства
# /var/ossec/etc/rules/local_rules.xml
<rule id="100100" level="12">
  <if_sid>5501</if_sid>
  <user>t0-</user>
  <description>Tier 0 admin logon detected — verify source</description>
</rule>

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

Внедрение Zero Trust — не проект на неделю, а непрерывный процесс. Рекомендуемый план:

Месяц 1-2: Фундамент

• Инвентаризация активов и потоков трафика
• Внедрение MFA для всех пользователей
• Включение логирования на всех серверах и сетевых устройствах

Месяц 3-4: Сегментация

• Разделение сети на VLAN по функциональным группам
• Настройка правил межсегментного доступа (default deny)
• Развёртывание NAC в режиме мониторинга

Месяц 5-6: Контроль устройств

• Включение NAC в режиме enforcement
• Проверка комплаентности устройств
• Шифрование критичных потоков трафика

Месяц 7-12: Зрелость

• SIEM с автоматическим реагированием
• Just-in-Time доступ к критичным ресурсам
• Регулярные пентесты для проверки модели
• Документация и обучение персонала