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

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

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

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

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

Помню, директор 50 РМ, когда мы завершали пилотный проект, записал фразу, которая стала для нас настоящим кредо: «У хорошего шифрования нет лица. Оно или работает, и ты его не замечаешь, или его просто нет». Мы в ITFresh полностью согласны. Если ваш сотрудник, занимаясь своими делами в течение дня, хотя бы раз поймал себя на мысли: «А как там моё шифрование?», значит, мы что-то сделали не так. Это явный звоночек, что система настроена криво, и нам есть, над чем поработать. Шифрование должно быть невидимым, но абсолютно надёжным.

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

Когда мы говорим о шифровании в корпоративной сети, то всегда начинаем с фундамента — с инфраструктуры открытых ключей, или PKI. Для этого клиента, у которого уже был отлично настроен Active Directory на двух 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

После того, как PKI встал на ноги, мы приступаем к настройке шаблонов сертификатов. Это такой наш рабочий 'джентльменский набор', проверенный временем и задачами: * **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

В компании 50 РМ, как и во многих современных бизнесах, немало тех, кто работает удалённо — 12 человек, между прочим! Это и конструкторы, и менеджеры по продажам, и даже директор. Для них мы подняли защищённый IKEv2-туннель. Авторизация, конечно же, по сертификатам, которые выпускает наш Issuing CA из той самой PKI-иерархии. Для корпоративных ноутбуков всё просто: сертификаты раздаются через 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 секунды, а через мобильный интернет (LTE) — 2,5-3,5 секунды. По нашим меркам, это более чем приемлемо для комфортной работы.

Шаг 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-домене (думайте о банках, налоговой, ключевых партнёрах), мы пошли дальше: там работает обязательная opportunistic 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 есть одна загвоздка, которая меня иногда смущает. На обычных, недорогих сетевых картах без аппаратного AES мы видим потери пропускной способности — где-то 8-12%. Это существенно! Но вот у нашего клиента, на рабочих станциях с Intel I225, ситуация оказалась куда лучше: замеры показали всего 4-6%. Да, при работе с огромными CAD-файлами это всё равно выливается в лишний десяток секунд ожидания. Но, знаете, по нашему опыту, это вполне себе приемлемая плата за безопасность.

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

Когда мы говорим о 50 рабочих местах, то сразу видим, что примерно 18 из них — это ноутбуки. И они, конечно, постоянно курсируют между офисом и внешним миром. Что мы сделали? На каждом таком устройстве мы настроили BitLocker, шифруя диск целиком по надёжному алгоритму AES-XTS-256. Это важно. Ключ восстановления? Он никуда не денется, потому что хранится в Active Directory, в специальном атрибуте 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-клиенты, подключенные через симку Билайна, почему-то устанавливали туннель не за привычные полторы секунды, а за целых 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, и при интеграции с уже существующими системами часто доставляют куда больше головной боли. Зачем усложнять? Для типичного бизнеса, скажем, с 50 рабочими местами, AES-256-GCM с лихвой закрывает абсолютно все потребности в безопасности. ГОСТ мы внедряем только в тех случаях, когда заказчик действительно обязан это делать по закону — например, когда речь идёт о 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 ₽/мес. За эти деньги вы получаете уверенность в завтрашнем дне.

Итог

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