Шифрование в корпсети 50 РМ под условиями ТСПУ: наша рабочая конфигурация

К нам обратилась производственная компания 50 РМ из подмосковного Видного — сборка оборудования для энергетики, конструкторский отдел, бухгалтерия, отдел продаж. После того как у соседнего по индустриальному парку клиента в марте 2026 произошла утечка чертежей через скомпрометированный почтовый канал, директор позвонил нашим инженерам с одной просьбой: «Семён Евгеньевич, посмотрите наш периметр и шифрование. Я хочу, чтобы между моим конструктором и моим облаком никто не подсмотрел». Это материал — пошаговое описание конфигурации, которую мы развернули за две рабочих недели и которая до сих пор работает без жалоб. Ниже — все команды, версии, сертификаты, цифры стоимости и пара историй, как мы спотыкались об особенности ТСПУ российских провайдеров.

Что вообще означает «защитить трафик» в 2026 году

Я считаю это перегибом, когда заказчик начинает разговор с фразы «нам нужен ГОСТ-шифр» — потому что он прочитал статью на РБК. Перегиб в том, что ГОСТ не даёт безопасности больше, чем AES-256-GCM, и не уменьшает риски. Безопасность даёт правильно построенная архитектура: где сертификаты, как раздаются, кто что подписывает, как меняются ключи, что делается при увольнении сотрудника. Шифр — последний по порядку, не первый по важности.

По моему опыту, корпоративная сеть 50 РМ должна шифровать трафик в пяти точках. Первое — внешний периметр (трафик от рабочих станций в интернет, к 1С-Облаку, к банк-клиентам). Второе — между офисом и сервером в дата-центре, если он есть. Третье — почта (S/MIME для конфиденциальных писем, обязательное TLS до получателя). Четвёртое — внутренние сетевые шары через SMB Encryption. Пятое — диски на ноутбуках через BitLocker. Это пять разных задач с пятью разными решениями.

Главную фразу, которую директор записал в конце пилота, я цитирую: «У хорошего шифрования нет лица — оно либо есть, либо его нет, и пользователь этого не замечает». Если ваш сотрудник вообще задумался о шифровании в течение рабочего дня — что-то спроектировано не так.

Шаг 1. Внутренний центр сертификации (PKI)

Шифрование в корпсети начинается с PKI. У клиента уже был AD на двух Windows Server 2022, поэтому мы развернули двухуровневую иерархию: оффлайн-Root CA на изолированной виртуалке, которую запускают раз в год для подписи нового Issuing CA, и онлайн-Issuing CA, интегрированный в AD как Enterprise Subordinate CA.

# Root CA — устанавливаем на изолированной VM (не в домене)
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority `
    -CAType StandaloneRootCA `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA384 `
    -CACommonName "ITfresh-Client-RootCA" `
    -ValidityPeriod Years -ValidityPeriodUnits 20

# Issuing CA — на DC02, в домене как Enterprise Subordinate
Install-WindowsFeature ADCS-Cert-Authority,ADCS-Web-Enrollment `
    -IncludeManagementTools

Install-AdcsCertificationAuthority `
    -CAType EnterpriseSubordinateCA `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA384 `
    -CACommonName "ITfresh-Client-IssuingCA" `
    -ValidityPeriod Years -ValidityPeriodUnits 10

Дальше — настраиваем шаблоны сертификатов. У нас стандартный набор: Computer (для всех ПК через autoenrollment), User S/MIME (для почты), Web Server (для внутренних веб-сервисов), VPN (для IKEv2-клиентов), CodeSigning (для подписи внутренних PowerShell-скриптов).

# Включить autoenrollment в GPO
# Computer Configuration → Windows Settings → Security Settings →
# Public Key Policies → Certificate Services Client - Auto-Enrollment

Set-CertificateAutoEnrollmentPolicy -Context Machine `
    -PolicyState Enabled `
    -EnableTemplateCheck `
    -ExpirationPercentage 10 `
    -EnableUserNotification

# Раздача шаблона Computer
$template = Get-CATemplate | Where-Object Name -eq "Computer"
Add-CATemplate -Name "Computer" -Force

Шаг 2. Шифрование внешнего трафика — TLS 1.3 как минимум

На каждой рабочей станции через GPO я выставляю минимально допустимую версию TLS — 1.2, рекомендованную — 1.3. Cipher suites — только современные AEAD-наборы. Это не про «защититься от ТСПУ» — это про защиту от MITM-атак внутри корпсети, и от случайной установки сотрудником программы со старым TLS-стеком.

# Реестр Windows: запретить TLS 1.0 и 1.1, разрешить только 1.2 и 1.3
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"

# Отключаем TLS 1.0
New-Item -Path "$path\TLS 1.0\Server" -Force
New-ItemProperty -Path "$path\TLS 1.0\Server" -Name "Enabled" -Value 0 -PropertyType DWord -Force
New-ItemProperty -Path "$path\TLS 1.0\Server" -Name "DisabledByDefault" -Value 1 -PropertyType DWord -Force
New-Item -Path "$path\TLS 1.0\Client" -Force
New-ItemProperty -Path "$path\TLS 1.0\Client" -Name "Enabled" -Value 0 -PropertyType DWord -Force

# Отключаем TLS 1.1 — аналогично
# Включаем TLS 1.2 — DisabledByDefault = 0, Enabled = 1
# Включаем TLS 1.3 — то же

# Запрет слабых cipher suites через GPO
# Computer Configuration → Administrative Templates →
# Network → SSL Configuration Settings → SSL Cipher Suite Order
$cipherList = @(
    "TLS_AES_256_GCM_SHA384",
    "TLS_AES_128_GCM_SHA256",
    "TLS_CHACHA20_POLY1305_SHA256",
    "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
) -join ","

New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002" `
    -Name "Functions" -Value $cipherList -PropertyType String -Force

Отдельный момент про ТСПУ — экспериментальные TLS-расширения. ECH (Encrypted Client Hello) ТСПУ режет в 2026 году с вероятностью около 90%: handshake начинается, потом RST на третий-четвёртый пакет. Для корпсети мы ECH принципиально не включаем — слишком хрупко.

Шаг 3. IPSec-туннель между офисом и облачным сервером

У клиента в Я.Облаке стоит сервер для удалённого доступа конструкторов и резервный 1С — оба критичные. Я поставил между офисом и облаком IPSec-туннель site-to-site на двух strongSwan-инстансах. Конфигурация подобрана под российский DPI: фрагментация, MOBIKE, агрессивный rekeying.

# strongSwan на офисном MikroTik (RouterOS 7.x)
/ip ipsec profile
add name=corp-cloud dh-group=ecp384 enc-algorithm=aes-256-gcm \
    hash-algorithm=sha384 lifetime=8h prf-algorithm=sha384

/ip ipsec proposal
add name=corp-cloud auth-algorithms=null enc-algorithms=aes-256-gcm \
    pfs-group=ecp384 lifetime=1h

/ip ipsec peer
add name=cloud-yandex address=51.250.42.17 profile=corp-cloud \
    exchange-mode=ike2 send-initial-contact=yes

/ip ipsec identity
add peer=cloud-yandex auth-method=digital-signature \
    certificate=corp-mt-cert remote-certificate=cloud-yandex-cert \
    generate-policy=port-strict

/ip ipsec policy
add peer=cloud-yandex tunnel=yes \
    src-address=192.168.10.0/24 dst-address=10.10.10.0/24 \
    proposal=corp-cloud level=require

На стороне Я.Облака — strongSwan 5.9 на Ubuntu 22.04 LTS:

# /etc/swanctl/conf.d/corp.conf
connections {
    corp-office {
        version = 2
        local_addrs = 51.250.42.17
        remote_addrs = %any

        proposals = aes256gcm16-prfsha384-ecp384

        local {
            auth = pubkey
            certs = cloud-yandex-cert.pem
            id = cloud.company.ru
        }
        remote {
            auth = pubkey
            cacerts = ITfreshClientRootCA.pem
            id = office-mt.corp.company.ru
        }
        children {
            corp-tunnel {
                local_ts  = 10.10.10.0/24
                remote_ts = 192.168.10.0/24
                esp_proposals = aes256gcm16-ecp384
                rekey_time = 1h
                rekey_bytes = 1G
                dpd_action = restart
                start_action = trap
            }
        }
    }
}

Шаг 4. Удалённый доступ конструкторов через IKEv2

В компании 12 человек регулярно работают дистанционно — конструкторы, менеджеры по продажам, директор. Для них настроил IKEv2-туннель с авторизацией по сертификатам, выпускаемым Issuing CA. Сертификаты раздаются через autoenrollment на корпоративные ноутбуки, на личных Mac/iPhone — через .mobileconfig-профили.

# PowerShell: настройка VPN-профиля через Always-On VPN
# (для корпоративных Windows 11 ноутбуков)

$VpnConfig = @"
<VPNProfile>
  <NativeProfile>
    <Servers>vpn.company.ru</Servers>
    <NativeProtocolType>IKEv2</NativeProtocolType>
    <Authentication>
      <UserMethod>Certificate</UserMethod>
      <MachineMethod>Certificate</MachineMethod>
    </Authentication>
    <RoutingPolicyType>SplitTunnel</RoutingPolicyType>
    <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
    <CryptographySuite>
      <AuthenticationTransformConstants>GCMAES256</AuthenticationTransformConstants>
      <CipherTransformConstants>GCMAES256</CipherTransformConstants>
      <EncryptionMethod>AES256</EncryptionMethod>
      <IntegrityCheckMethod>SHA384</IntegrityCheckMethod>
      <DHGroup>ECP384</DHGroup>
      <PfsGroup>ECP384</PfsGroup>
    </CryptographySuite>
  </NativeProfile>
  <Route>
    <Address>192.168.10.0</Address>
    <PrefixSize>24</PrefixSize>
  </Route>
  <AlwaysOn>true</AlwaysOn>
  <DeviceTunnel>false</DeviceTunnel>
</VPNProfile>
"@

# Развернуть через WMI
$NamespaceName = "root\cimv2\mdm\dmmap"
$ClassName = "MDM_VPNv2_01"

$instance = New-CimInstance -Namespace $NamespaceName -ClassName $ClassName `
    -Property @{
        ParentID = "./Vendor/MSFT/VPNv2"
        InstanceID = "Corp"
        ProfileXML = $VpnConfig
    }

Always-On VPN означает, что туннель поднимается автоматически при наличии интернета — пользователь не делает ничего. На замерах handshake занимает 1,2-1,8 секунды на оптике, 2,5-3,5 на LTE. Это приемлемо.

Шаг 5. S/MIME для критичных писем конструкторского отдела

Чертежи и спецификации — это то, что у клиента нельзя выпускать в открытом виде. Конструкторский отдел получил отдельные User S/MIME-сертификаты с Key Usage = Digital Signature, Key Encipherment. Раздача — через autoenrollment, в Outlook и Thunderbird сертификаты подхватываются автоматически из Personal-хранилища.

# Шаблон сертификата User S/MIME
# Через certtmpl.msc копируем шаблон User → задаём имя UserSMIME

# Параметры:
# Subject Name: Build from AD information, E-mail name + UPN
# Extensions: Application Policies = Secure Email, Client Authentication
# Extensions: Key Usage = Digital signature, Key encipherment
# Cryptography: RSA 3072 bits minimum
# Issuance Requirements: CA certificate manager approval = false
# Security: Authenticated Users = Read+Enroll+Autoenroll

# Активируем шаблон на Issuing CA
$template = Get-CATemplate | Where-Object Name -eq "UserSMIME"
Add-CATemplate -Name "UserSMIME" -Force

# Через GPO применяем autoenrollment к OU=KonstruktorskyOtdel
# Это всё, что нужно — Outlook сам найдёт сертификат и предложит использовать

Дополнительная политика на почтовом шлюзе (у клиента — Postfix на Debian 12 в офисе): принудительный TLS 1.2+ с любым внешним получателем, для контрагентов в whitelist-домене (банки, налоговая, партнёры) — обязательное опportunistic DANE-валидация TLSA-записей.

Шаг 6. Шифрование SMB и файловых шар

Файловый сервер у клиента — Windows Server 2022 с DFSN-namespace. Шары для конструкторов содержат CAD-файлы по 200-800 МБ, для бухгалтерии — рабочие книги 1С и сканы документов. Включил SMB Encryption на каждой шаре отдельно — сквозное шифрование AES-256-GCM поверх SMBv3.

# Включить шифрование на конкретной шаре
Set-SmbShare -Name "Konstruktora" -EncryptData $true -Force
Set-SmbShare -Name "Buhgalteria" -EncryptData $true -Force

# Глобально на сервере: запретить незашифрованный SMB к чувствительным шарам
Set-SmbServerConfiguration -EncryptData $true -Force
Set-SmbServerConfiguration -RejectUnencryptedAccess $true -Force

# На клиентах через GPO: требовать шифрование при подключении
# Computer Configuration → Administrative Templates →
# Network → Lanman Workstation → Require encryption

Здесь мне здесь не нравится один нюанс: SMB Encryption даёт около 8-12% потерь по пропускной способности на дешёвых сетевых картах без аппаратного AES. У клиента карты Intel I225 в рабочих станциях — потери на замерах 4-6%, для CAD-файлов это десяток секунд на загрузке большого чертежа. Считаю это приемлемой ценой.

Шаг 7. BitLocker на ноутбуках с TPM и сетевой разблокировкой

50 РМ — это около 18 ноутбуков, которые регулярно покидают офис. На каждом — BitLocker с шифрованием полного диска AES-XTS-256, ключ восстановления хранится в AD на атрибуте msFVE-RecoveryInformation, разблокировка по TPM 2.0 + сетевая разблокировка в офисе (BDE Network Unlock).

# Включить BitLocker на C: с TPM
Enable-BitLocker -MountPoint "C:" `
    -EncryptionMethod XtsAes256 `
    -UsedSpaceOnly `
    -TpmProtector

# Добавить пин-код на старте (для ноутбуков, выходящих из офиса)
Add-BitLockerKeyProtector -MountPoint "C:" `
    -TpmAndPinProtector `
    -Pin (Read-Host -AsSecureString "BitLocker PIN")

# Backup ключа в AD
Backup-BitLockerKeyProtector -MountPoint "C:" `
    -KeyProtectorId (Get-BitLockerVolume "C:").KeyProtector[1].KeyProtectorId

# Сетевая разблокировка — настраивается через WDS-сервер с сертификатом
# При подключении к корпсети ноут разблокируется без PIN
# Вне офиса — требует PIN

Грабли, на которые мы наступили

Грабля #1: ОЧЕНЬ длинный handshake IKEv2 на LTE Билайн

На пилоте VPN-клиенты с симкой Билайна устанавливали туннель не за 1,5 секунды, а за 18-22. Логи показывали повторные попытки фрагментации. Помогло только включение fragmentation=force в strongSwan и снижение MTU внутри туннеля до 1280. После этого — 2,1 секунды на LTE, что приемлемо.

Грабля #2: Outlook Web Access ругался на новый сертификат

Issuing CA выпустил сертификат на mail.company.ru, но без SAN-расширения. Современные браузеры это игнорируют, OWA в Outlook 2019 — ругалась. Перевыпустили с SAN, проблема ушла.

Грабля #3: Конструкторы не могли расшифровать письма от партнёров

Партнёр-контрагент работал с другим CA, и Outlook у конструкторов не мог построить цепочку доверия. Решилось добавлением Root CA партнёра в Trusted Root Certification Authorities через GPO — но я перед этим долго думал, не открывает ли это окно для атак. В итоге добавил с отдельной политикой допустимых EKU (только Secure Email и Client Authentication, без Code Signing).

Цифры проекта

Внедрение заняло 12 рабочих дней инженера: 4 дня на проектирование PKI и пилот, 5 дней на основное развёртывание, 3 дня на финишную доводку и обучение администратора заказчика. По нашему тарифу — 168 000 ₽ за разовую работу. Дальше клиент перешёл на сопровождение 18 000 ₽/мес (включает мониторинг сертификатов, продление, разбор инцидентов).

На замерах после внедрения — все критичные сценарии работают. 1С-Облако открывается за 0,8-1,2 секунды, удалённый доступ к конструкторскому серверу — 1,5-2,1 секунды, передача 200 МБ-чертежа по корпоративной шаре — 11-13 секунд (по гигабиту). За три месяца ноль инцидентов утечки данных, ноль жалоб от пользователей на «у меня не работает почта» или «не подключается VPN».

FAQ: что чаще всего спрашивают клиенты

Зачем шифровать корпоративный трафик, если у нас белые списки?

Белые списки решают, кто куда ходит. Шифрование — что внутри пакетов. Это разные слои защиты. Без шифрования любой инсайдер с доступом к коммутатору или провайдер видит логины, пароли, файлы 1С, банковские реквизиты. Слои дополняют друг друга: белый список — внешняя дисциплина, шифрование — внутренняя гарантия.

Что такое ТСПУ и как он влияет на шифрование?

ТСПУ — это технические средства противодействия угрозам, государственное оборудование DPI, устанавливаемое на крупных провайдерах. Современные алгоритмы шифрования (TLS 1.3, IPSec) ТСПУ в основном пропускает, но активно дропает экспериментальные расширения: ECH, ESNI, нестандартные cipher suites. Поэтому в корпсети нужно использовать «скучный» канонический набор шифров — он стабильнее всех.

Использовать ли отечественные шифры (ГОСТ) в корпсети?

Если у вас нет требования закона работать с КИИ или гостайной — нет смысла. ГОСТ-шифры медленнее, поддерживаются только в отечественных продуктах (КриптоПро, ViPNet), вызывают больше проблем при интеграции. AES-256-GCM покрывает всё, что нужно бизнесу 50 РМ. ГОСТ ставим только тогда, когда заказчик обязан по 187-ФЗ или 152-ФЗ.

Что делать, если TLS 1.3 на каком-то старом сервисе не работает?

Откатываемся к TLS 1.2 — но строго с заданными cipher suites: ECDHE-ECDSA-AES256-GCM-SHA384 и ECDHE-RSA-AES256-GCM-SHA384. Запрещаем CBC, RC4, 3DES, экспортные шифры. На периметре ставим reverse-proxy (nginx или HAProxy), который терминирует современный TLS снаружи и говорит со старым сервисом по локальной сети.

Сколько стоит проект под ключ для 50 РМ?

Внедрение комплексной системы шифрования на 50 РМ — это 28-35 рабочих часов инженера, 140-180 тысяч рублей. Сюда входит: внутренний CA, развёртывание сертификатов на устройства, настройка S/MIME для почты, IPSec-туннель в облако, BitLocker на ноутбуки, журналирование. Дальше — сопровождение от 15 000 ₽/мес.

Итог

Шифрование в корпсети — это не один продукт, который купил и поставил. Это набор слоёв: PKI, TLS на каналах, IPSec на туннелях, S/MIME на почте, SMB Encryption на шарах, BitLocker на дисках. Каждый слой делает свой кусок работы; вместе они дают то, что директор нашего клиента назвал «нормальной взрослой инфраструктурой». На производстве 50 РМ это окупилось бюджетом 168 000 ₽ единовременно и 18 000 ₽ ежемесячно — сравнимо со стоимостью одного среднего сотрудника, но с эффектом, который простой сотрудник никогда не даст.