В 02:54 ночи никто не следит за логами аутентификации. Скрипт на арендованном облачном инстансе отправляет тысячный запрос в форму входа корпоративной почты. В 03:14 приходит ответ, непохожий на предыдущие: «доступ подтверждён». Никакого вредоносного ПО, инсайдера и социальной инженерии. Только слабый пароль, время и брешь в мониторинге.

В первом квартале 2025 года сеть ханипотов (ловушек) ГК «Солар» зафиксировала 570 тысяч брутфорс-атак на российские организации — в 2,7 раза больше, чем кварталом ранее, 94% от всех зафиксированных событий. Топливо для этого роста — базы утёкших учётных данных. По данным Positive Technologies, логины и пароли похищались в каждом пятом успешном инциденте 2025 года — наравне с коммерческой тайной и персональными данными, и их доля в инцидентах растёт: с 13% в 2022-м до 19% в 2025-м. Похищенное немедленно попадает в оборот через брокеров первоначального доступа на теневых платформах и становится готовым материалом для прицельного перебора.

Базовая механика брутфорс-атак всё та же: перебирать комбинации до первого совпадения. Изменился инструментарий, масштаб и приоритеты:

• Скорость — GPU-кластеры перебирают миллиарды хешей в секунду.
• Точность — ИИ анализирует массивы утечек и строит словари под конкретную жертву.
• Незаметность — распределённые ботнеты и обратный перебор разбивают атаку на тысячи запросов с разных адресов.
• Охват — одна утечка становится материалом для атак на сотни сервисов, где пользователь мог применять тот же пароль или логин.

В результате атака, которая раньше была шумной и медленной, стала точечной, быстрой и трудноуловимой для большинства стандартных средств защиты.

Главное

• Брутфорс — это атака на предсказуемость, не на криптографию. Злоумышленник перебирает комбинации до совпадения. Атака работает, потому что люди выбирают пароли по одним и тем же паттернам: словарные фразы, даты, корпоративные шаблоны.
• Масштаб угрозы растёт быстро. В первом квартале 2025 года сеть ханипотов ГК «Солар» зафиксировала 570 тысяч брутфорс-атак на российские организации — в 2,7 раза больше, чем кварталом ранее. Глобально доля брутфорса в атаках на веб-приложения выросла с ~20% до 60%.
• Современный брутфорс — точечный и трудноуловимый. GPU-кластеры перебирают сотни миллиардов хешей в секунду, ИИ-модели строят словари под конкретную жертву, ботнеты разбивают атаку на тысячи запросов с разных адресов. То, что раньше было шумной массовой кампанией, стало незаметной точечной операцией.
• Брутфорс — семейство техник, каждая эксплуатирует свою слабость. Простой перебор бьёт по коротким паролям, словарные атаки — по предсказуемым, подстановка учётных данных — по повторно используемым, распыление паролей — по отсутствию мониторинга аномалий. Понимание механики каждого метода определяет выбор защитных мер.
• Защита строится на нескольких независимых уровнях. Длинные случайные пароли, уникальные для каждого сервиса, многофакторная аутентификация, правильное хеширование с солением, ограничение попыток входа и поведенческий мониторинг — каждый уровень закрывает свой вектор.
• Корневая причина большинства инцидентов — человеческий фактор. Политика запрещает слабые пароли, но не делает правильное поведение удобным. Корпоративный менеджер паролей устраняет эту проблему на уровне процесса: генерирует случайные строки, исключает ручной ввод, выявляет слабые и устаревшие учётные данные централизованно.

Что такое брутфорс (Brute Force)

Брутфорс (от англ. brute force — «грубая сила», атака полным перебором) — метод получения несанкционированного доступа к системе путём автоматизированного перебора возможных комбинаций учётных данных: паролей, токенов или ключей шифрования.

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

Брутфорс остаётся эффективным по одной причине: люди выбирают предсказуемые комбинации. Задача атакующего — сократить время перебора до практически приемлемого. Фермы GPU и ИИ-генерация словарей решают эту задачу с каждым годом всё быстрее.

Ключевые цифры: брутфорс и кража учётных данных (2024–2026)

Как работает брутфорс

Технически брутфорс — это автоматизация: скрипт или специализированный инструмент последовательно отправляет комбинации учётных данных на точку аутентификации, фиксирует совпадения и продолжает перебор. Точка аутентификации может быть любой: форма входа, SSH и RDP-сервисы, API-шлюзы, административные панели. Если система принимает логин и пароль, она становится потенциальной мишенью.

Онлайн- и офлайн-атаки

Брутфорс реализуется в двух принципиально разных контекстах, и это различие определяет как скорость атаки, так и методы защиты.

• Онлайн-атака — попытки в реальном времени против живой системы: форма входа на сайте или SSH-сервис. Скорость ограничена сетевыми задержками и защитными механизмами: ограничением частоты запросов, CAPTCHA, блокировки по IP-адресу.
• Офлайн-атака — атакующий уже получил хеши паролей, например из утечки баз данных, и перебирает их локально на собственном железе. Никаких ограничений со стороны жертвы или задержек сети.

Это разграничение важно для понимания защитных мер: ограничение попыток входа эффективно против онлайн-атак, но бесполезно, если хеши уже утекли. Надёжное хеширование паролей на стороне сервера — единственная защита от офлайн-перебора.

Инструменты атакующих и пентестеров

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

Офлайн-перебор:

• Hashcat — наиболее производительный инструмент для взлома хешей без подключения к сети, поддерживает GPU-ускорение и сотни алгоритмов хеширования.
• John the Ripper — универсальный инструмент восстановления паролей, поддерживает хеши Unix, Windows, баз данных и документов.

Онлайн-перебор:

• THC Hydra — перебор учётных данных по сети против SSH, RDP, FTP, HTTP-форм и десятков других протоколов.
• Medusa — параллельный перебор на большом числе целей одновременно, ориентирован на скорость при массовых проверках.
• Ncrack — инструмент от команды Nmap, разработан для высокоскоростного перебора сетевых служб, отличается гибкой настройкой нагрузки на цель.
• Burp Suite (Intruder) — перебор в веб-приложениях: формы входа, параметры запросов, токены сессий.

Анализ беспроводных сетей:

• Aircrack-ng — набор инструментов для анализа безопасности Wi-Fi-сетей, включая перебор ключей WPA/WPA2.

Как изменились брутфорс-атаки в 2025–2026 годах

Перебор паролей перестал быть атакой грубой силы. Машинное обучение, доступное GPU-железо и распределённые ботнеты сделали его точечным, масштабируемым и трудноотличимым от легитимного трафика. Четыре сдвига определяют текущий ландшафт угроз.

Нейросети как генераторы словарей

Алгоритмы машинного обучения анализируют миллиарды утёкших паролей и выявляют поведенческие паттерны: типичные замены символов (@ вместо а, 0 вместо о), способы добавления цифр и спецсимволов, предсказуемые структуры. Итог — словари, которые проверяют не все комбинации, а наиболее вероятные.

В тестах на датасете RockYou ИИ-модель PassGAN взломала 51% популярных паролей менее чем за минуту, 71% — менее чем за день, 81% — менее чем за месяц (SecurityLab.ru, 2023).

Мощность современного железа

Видеокарты становятся мощнее с каждым годом. RTX 4090 перебирала MD5-хэши со скоростью до 164 млрд в секунду. RTX 5090 делает то же самое на 34% быстрее — 220 млрд хэшей в секунду. При этом дорогостоящее железо — не обязательное условие: облачная аренда GPU обходится от нескольких десятков до нескольких сотен рублей в час.

Исследование Лаборатории Касперского, охватившее 231 млн уникальных паролей из утечек даркнета за 2023–2026 годы, показало: 48% паролей взламываются менее чем за минуту, 60% — менее чем за час. Для сравнения: в аналогичном исследовании 2024 года этот показатель составлял 59%.

Ботнеты и распределённые атаки

Ботнет — это сеть скомпрометированных устройств (серверов, маршрутизаторов, IoT-оборудования, домашних компьютеров). Каждый узел действует независимо, но скоординированно: отправляет запросы, зондирует системы, подбирает учётные данные. Масштаб — миллионы машин одновременно.

Главное преимущество такой архитектуры — обход IP-фильтрации. Попытки входа распределяются по тысячам адресов из разных стран, и каждая из них выглядит как обычный пользовательский запрос.

Квантовые вычисления: горизонт угрозы

Квантовые компьютеры пока не существуют в промышленном масштабе, но меняют логику долгосрочного планирования. Современная асимметричная криптография (в частности, RSA) основана на вычислительной сложности, которая для квантовых машин принципиально иная. Исследования показывают: по мере роста возможностей квантовых систем временной горизонт до практического взлома актуальных ключей продолжает сокращаться.

Зачем атакуют: мотивы за брутфорсом

Брутфорс — инструмент первичного доступа. Далее взломанные учётные данные открывают путь к тому, что действительно нужно атакующему.

Виды брутфорс-атак в 2026 году

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

Простой брутфорс (Brute Force)

Простой брутфорс (полный перебор, Brute Force) — метод взлома пароля путём последовательного перебора всех возможных комбинаций символов в заданном пространстве поиска: aaaa, aaab, aaac. Атака не использует никаких предположений о структуре пароля. Метод гарантирует результат при достаточных вычислительных ресурсах и времени, но масштабируется плохо: сложность растёт экспоненциально с длиной пароля.

Эффективен против коротких паролей — до 6–8 символов. Против 12-символьных без специализированного железа практически бесполезен. Шестисимвольный пароль из строчных букв даёт 26⁶ ≈ 308 миллионов комбинаций — современное железо проходит их мгновенно. Двенадцатисимвольный пароль из букв, цифр и символов даёт порядка 500 секстиллионов вариантов.

Где встречается: атаки на SSH-сервисы с короткими или дефолтными паролями, взлом ПИН-кодов, офлайн-перебор хешей из утечек.

Атака по словарю (Dictionary Attack)

Атака по словарю (Dictionary Attack) — метод взлома пароля, при котором перебор ведётся не по всему пространству комбинаций, а по заранее подготовленному списку вероятных кандидатов: реальных паролей из утечек, распространённых слов и предсказуемых последовательностей (например, словарь rockyou.txt содержит 14 миллионов записей). Алгоритм проверяет не aaaa0001, а p@rol12, qwerty, admin123 — то, что люди действительно используют.

Скорость выше, чем у простого брутфорса, в десятки и сотни раз: словарь из миллиона записей проверяется за секунды. Эффективность определяется качеством словаря — чем свежее и полнее база утечек, тем выше вероятность попадания. ИИ-инструменты вроде PassGAN выводят этот метод на новый уровень. Модель обучается на реальных паролях и генерирует статистически вероятные кандидаты, которых нет ни в одном статическом словаре.

Где встречается: атаки на веб-формы, SSH, RDP, офлайн-взлом хешей из утечек баз данных.

Подстановка учётных данных (Credential Stuffing)

Подстановка учётных данных (Credential Stuffing) — автоматизированная атака, при которой злоумышленник использует готовые пары логин/пароль из ранее утёкших баз данных для получения доступа к другим сервисам. Взлом пароля не требуется: ставка делается на повторное использование одних и тех же учётных данных на разных платформах.

Масштаб проблемы огромен: по данным Have I Been Pwned, к середине 2026 года накоплено более 17 миллиардов записей скомпрометированных аккаунтов — цифра включает повторения из разных утечек, но даже с поправкой на дубли объём уникальных учётных данных исчисляется миллиардами. Этого достаточно, чтобы обеспечить атакующих материалом на годы вперёд.

В первом полугодии 2025 года около половины всех веб-атак на российский госсектор приходилось на перебор и большую их часть составляла именно подстановка учётных данных (Anti-Malware.ru, июль 2025).

Метод масштабируется через ботнеты: тысячи IP-адресов отправляют по одному запросу, имитируя обычный пользовательский трафик.

Распыление паролей (Password Spraying)

Распыление паролей (Password Spraying) — метод атаки на аутентификацию, при котором один пароль последовательно проверяется против большого числа учётных записей. Логика обратная классическому брутфорсу: не множество паролей против одного аккаунта, а один пароль против тысяч аккаунтов.

Атакующий берёт самые популярные пароли (123456789, kompania2026!, Qwerty123) и последовательно проверяет их на всей базе пользователей организации.

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

Эффективность определяется предсказуемостью паролей в целевой организации. Атакующий использует закономерности: корпоративные шаблоны вида Компания+год, типовые временные пароли для новых сотрудников, которые те не меняют вовремя. Чем крупнее организация, тем выше вероятность, что хотя бы один сотрудник из тысячи использует типовой пароль.

Где встречается: атаки на Active Directory, корпоративные VPN-порталы.

Гибридная атака (Hybrid Attack)

Гибридная атака (Hybrid Attack) — метод взлома паролей, сочетающий словарный перебор с автоматическими мутациями базовых слов. Алгоритм не перебирает все возможные комбинации, а воспроизводит предсказуемые человеческие шаблоны: добавляет цифры в конец (admin2026), заменяет буквы символами (@dmin), вставляет спецсимволы (Admin!), меняет регистр (ADMIN, Admin).

Именно этот метод взламывает пароли, которые формально соответствуют политике сложности. Admin2026! содержит заглавную букву, цифры и спецсимвол — и при этом вскрывается за секунды: структура шаблонная, и гибридные алгоритмы знают её наизусть. Требование «добавить спецсимвол» без требования случайности создаёт ложное ощущение защиты.

ИИ-модели усиливают атаку: PassGAN и аналогичные инструменты обучаются на миллионах реальных паролей и генерируют мутации, которые не входят ни в один статический словарь. Вместо перебора всех вариантов подряд модель предсказывает, какой именно пароль мог создать конкретный человек и начинает с наиболее вероятных.

Где встречается: офлайн-взлом хешей из утечек баз данных, атаки на корпоративные системы с формальными требованиями к сложности паролей.

Атака по радужным таблицам (Rainbow Table Attack)

Атака по радужным таблицам (Rainbow Table Attack) — офлайн-метод взлома хешей, основанный на предвычислении. Вместо того чтобы хешировать каждый кандидат в момент атаки, атакующий заранее строит таблицу соответствий «пароль → хеш» для множества вариантов. При получении хеша из утечки он просто ищет совпадение в готовой таблице.

Радужная таблица — предвычисленная структура данных для офлайн-атаки на хеши паролей. Хеш — результат математического преобразования (напимер, пароль qwerty система может сохранять в виде хеша d8578edf...).

При аутентификации введённый пароль пользователя хешируется и сравнивается с сохранённым значением. Атакующий, получив базу хешей из утечки, решает обратную задачу: перебирает кандидатов, хеширует каждый и ищет совпадение.

Контрмера — соление хешей (salting). К каждому паролю перед хешированием добавляется уникальная случайная строка (соль), хранящаяся отдельно. Даже если два пользователя используют одинаковый пароль, их хеши будут разными. Для каждого потребовалась бы отдельная радужная таблица — это полностью нивелирует преимущество метода.

Где встречается: офлайн-атаки на базы данных с устаревшим хешированием (MD5, SHA-1 без соли).

Распределённый брутфорс через ботнет

Распределённый брутфорс через ботнет — метод перебора учётных данных, при котором атака распределяется между тысячами скомпрометированных устройств под управлением единого командного сервера (коодринатора). Каждый узел ботнета отправляет минимальное число запросов — достаточно малое, чтобы не вызвать блокировку, но в совокупности обеспечивающее высокую скорость перебора.

Главная проблема онлайн-атак — видимость. Классический брутфорс с одного IP мгновенно попадает под блокировку. Распределённая схема снимает это ограничение: тысячи домашних роутеров, IoT-оборудования и корпоративных серверов, включённых в ботнет без ведома владельцев, генерируют трафик, неотличимый от легитимного.

Обнаружение таких атак требует поведенческого анализа. Релевантные метрики: число уникальных неудачных попыток на один аккаунт за период и географическое разнообразие источников трафика. Аномальный разброс по странам при стабильном числе ошибок аутентификации — характерный признак ботнет-кампании.

Где встречается: атаки на VPN-порталы, корпоративные почтовые серверы, публично доступные административные панели.

ИИ-брутфорс (AI-Assisted Brute Force)

ИИ-брутфорс (AI-Assisted Brute Force) — применение моделей машинного обучения для приоритизации кандидатов при переборе паролей. Вместо последовательного перебора всех комбинаций модель, обученная на миллиардах реальных паролей из утечек, предсказывает наиболее вероятные варианты для конкретного пользователя или организации и начинает атаку с них.

Традиционный словарь — статичный список. ИИ-модель — генератор, который строит кандидатов на основе выявленных паттернов: как люди трансформируют слова, какие замены используют, как добавляют цифры и символы в зависимости от контекста (корпоративная среда, страна, отрасль).

Второй вектор — предсказание путей атаки. Модели анализируют структуру корпоративной сети и паттерны именования учётных записей (имя.фамилия@компания.ru), выбирая точки входа с наибольшей вероятностью успеха. Брутфорс превращается из массовой кампании в точечную операцию.

Пароль, созданный по человеческому паттерну, уязвим: ИИ знает эти паттерны лучше, чем их осознаёт сам пользователь. Единственный надёжный ответ — криптографически случайная строка достаточной длины, сгенерированная менеджером паролей.

Где встречается: целевые атаки на корпоративные системы идентификации, Active Directory, привилегированные учётные записи.

Сравнительная таблица: виды брутфорс-атак и способы защиты

Большинство атак из этой таблицы (от словарного перебора до ИИ-брутфорса) становятся неэффективными, если каждый сотрудник использует уникальный случайный пароль. Пассворк генерирует и хранит такие пароли централизованно, поддерживает MFA и ключи доступа (passkeys), разграничивает доступ по ролям и ведёт журнал действий. Протестировать можно бесплатно — локально на вашем сервере или в облаке.

Как защититься от брутфорса

Защита от брутфорса строится на нескольких независимых уровнях. Компрометация одного не означает компрометацию остальных.

Парольная политика

Минимальная длина — 12–16 символов. Длина важнее набора спецсимволов: пароль Financi2026! требует на несколько порядков больше вычислительных ресурсов — атака становится нецелесообразной.

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

Словарные фразы, имена, даты рождения и названия компании — под запретом. Эти паттерны первыми попадают в словари атакующих.

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

Многофакторная аутентификация (MFA)

MFA блокирует подавляющее большинство атак с использованием украденных паролей: даже корректная пара логин/пароль не даёт доступа без второго фактора.

Приоритет — аппаратные ключи FIDO2/WebAuthn и приложения-аутентификаторы (TOTP). SMS-коды уязвимы к SIM-свопингу — злоумышленник переоформляет номер на подконтрольную SIM-карту и перехватывает одноразовые коды. Тем не менее SMS лучше, чем отсутствие второго фактора.

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

Технические ограничения на стороне сервера

Брутфорс работает за счёт скорости — серверные ограничения эту скорость убивают. После каждой неудачной попытки входа система увеличивает паузу перед следующей: сначала несколько секунд, затем минуты, затем — полная блокировка аккаунта. Важно: блокировка должна распространяться на учётную запись, а не только на IP — распределённые атаки через ботнеты меняют адреса при каждой попытке.

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

Геоблокировка и поведенческий анализ в связке с SIEM (система управления событиями безопасности) эффективны против распределённых атак: вход из нетипичной географии или в нетипичное время — повод для дополнительной верификации, а не автоматического пропуска.

Хранение паролей: хеширование и соление

Алгоритмы MD5 и SHA-1 взламываются за секунды на современном GPU — они не предназначались для хеширования паролей. Современные bcrypt, Argon2 и scrypt спроектированы намеренно медленными: каждая попытка перебора стоит вычислительных ресурсов, что делает офлайн-атаку на украденную базу хешей бессмысленной.

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

Мониторинг и реагирование

Брутфорс оставляет характерные следы: серии неудачных попыток входа, множество IP-адресов против одной учётной записи, нетипичное время активности, географические аномалии. Эти паттерны должны автоматически триггерить алерты — ручной просмотр логов их не поймает вовремя.

Отдельная угроза — брутфорс как дымовая завеса. Пока SIEM перегружен тысячами неудачных попыток, параллельно может идти тихая целенаправленная атака: медленное распыление паролей, эксплуатация уязвимости в смежной системе или фишинг конкретного сотрудника. Высокий брутфорс-трафик — повод проверить не только журнал аутентификации, но и всю картину активности в сети.

Управление учётными записями

Аккаунты уволенных сотрудников, технические учётные записи подрядчиков, сервисные пользователи с паролями по умолчанию — активные векторы атаки. Атакующий не ищет слабое место в защищённой системе, если рядом есть забытая учётная запись с паролем admin123, которую никто не трогал два года.

Регулярный аудит активных учётных записей и немедленное удаление неиспользуемых закрывает этот вектор системно. Интеграция с AD/LDAP позволяет автоматизировать отзыв доступа при увольнении.

Корпоративный менеджер паролей как системное решение

Технические меры защищают периметр, но не устраняют корневую причину большинства инцидентов — человеческий фактор. Сотрудники создают слабые пароли, повторно используют их на разных сервисах, хранят в таблицах и передают через мессенджеры. Политика запрещает это, но не делает правильное поведение удобным.

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

Пассворк: управление паролями как элемент защиты от брутфорса

Пассворк — корпоративный менеджер паролей, доступный в двух вариантах развёртывания:

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

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

Разберём, какие векторы брутфорса закрывает Пассворк и за счёт каких механизмов.

Проблема: слабые и предсказуемые пароли

Сотрудники создают пароли по шаблонам — именно такие пароли взламывают первыми.

Решение: встроенный генератор создаёт криптографически случайные пароли заданной длины по правилам, установленным пользоваетелем. Сотрудник не придумывает пароль — он получает случайную строку, которую не нужно запоминать. Человеческий фактор при создании учётных данных исключён.

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

Проблема: ручной ввод пароля

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

Решение: браузерное расширение Пассворка автоматически заполняет учётные данные на сайтах и в веб-приложениях. Сотрудник не видит пароль в открытом виде — расширение подставляет его напрямую в форму.

Проблема: отсутствие второго фактора

Скомпрометированный пароль без многофакторной аутентификации даёт злоумышленнику немедленный доступ.

Решение: Пассворк поддерживает многофакторную аутентификацию (MFA) в нескольких форматах:

• Приложение-аутентификатор — Пассворк включает собственное встроенное приложение для генерации одноразовых кодов (TOTP), не требующее сторонних сервисов.
• Биометрия — вход по отпечатку пальца или Face ID на поддерживаемых устройствах.
• Ключи доступа (passkeys) — беспарольная аутентификация на основе стандарта WebAuthn/FIDO2.
• Физические ключи безопасности — поддержка аппаратных токенов YubiKey, Рутокен и аналогов через FIDO2.

Проблема: брутфорс формы входа

Автоматизированные атаки перебирают тысячи комбинаций через форму аутентификации, пока не найдут рабочую.

Решение: политики блокировки локальной аутентификации ограничивают число неудачных попыток входа за установленный период. Например: 7 попыток за 180 секунд — аккаунт блокируется на 60 секунд.

Параметры настраиваются администратором под требования организации. Это делает перебор экономически невыгодным: скорость атаки падает до нескольких попыток в минуту.

Проблема: активные аккаунты уволенных сотрудников

Учётные данные бывших сотрудников — один из наиболее распространённых векторов атак.

Решение: ролевая модель и интеграция с Active Directory и LDAP. При увольнении администратор удаляет учётную запись один раз — доступ отзывается из всех хранилищ автоматически.

Новый сотрудник получает ровно те учётные данные, которые нужны для его работы, — не больше.

Проблема: атаки остаются незамеченными

Среднее время обнаружения компрометации учётных данных — 292 дня (IBM Cost of a Data Breach Report 2025). За это время злоумышленник действует внутри инфраструктуры незаметно.

Решение: журнал аудита фиксирует все события аутентификации — успешные входы, неудачные попытки, время и источник запроса. Администратор видит аномалии (серии неудачных попыток, входы в нетипичное время, активность с незнакомых устройств) и реагирует до того, как атака достигает цели.

Для организаций с выстроенным процессом мониторинга Пассворк интегрируется с SIEM-системами через syslog и API: события из журнала аудита поступают в единую консоль вместе с данными из других источников. Это позволяет коррелировать подозрительную активность в менеджере паролей с событиями на сетевом периметре и конечных устройствах.

Заключение

Брутфорс эффективен ровно настолько, насколько предсказуемы пароли в атакуемой организации. Нейросети и GPU-кластеры лишь ускорили то, что всегда было слабым местом: человек выбирает пароли, которые легко запомнить, — а значит, легко угадать. Комбинация надёжной парольной политики, МФА, правильного хеширования и централизованного управления учётными данными закрывает этот вектор атаки системно.

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

Пассворк закрывает большинство векторов брутфорса — от генерации случайных паролей до блокировки аутентификации и обязательного МФА. Доступна бесплатная пробная версия: коробочная для развёртывания на своих серверах или облачная — без затрат на инфраструктуру.

Часто задаваемые вопросы о брутфорсе

Что такое брутфорс-атака?

Брутфорс — метод получения несанкционированного доступа путём автоматизированного перебора комбинаций учётных данных. Программа последовательно проверяет варианты до первого совпадения. Современные GPU-кластеры перебирают сотни миллиардов хешей в секунду — скорость атаки определяется длиной и предсказуемостью пароля, а не сложностью системы защиты.

В чём разница между онлайн- и офлайн-брутфорсом?

Онлайн-брутфорс атакует живую систему в реальном времени: форму входа, SSH, VPN. Скорость ограничена сетевыми задержками и защитными механизмами — блокировкой по IP, CAPTCHA, лимитами попыток. Офлайн-брутфорс — перебор хешей из утечки базы данных на собственном железе атакующего, без каких-либо ограничений со стороны жертвы. Именно офлайн-атаки достигают скорости в сотни миллиардов попыток в секунду. Ограничение числа попыток входа защищает только от онлайн-сценария и бесполезно, если хеши уже утекли.

Как долго занимает взлом пароля брутфорсом?

По данным «Лаборатории Касперского» (2026), 48% реальных паролей взламываются менее чем за минуту. Восьмисимвольный пароль из букв и цифр при скорости RTX 5090 (220 млрд операций в секунду) взламывается за минуты. Пароль из 16 случайных символов при той же скорости потребует миллионов лет перебора. Длина — главный фактор стойкости, не набор спецсимволов.

Чем отличается брутфорс от атаки по словарю и подстановки учётных данных?

Простой брутфорс перебирает все возможные комбинации символов подряд. Атака по словарю работает по заранее составленному списку вероятных паролей (популярных слов, фраз, утёкших данных из прошлых взломов). Подстановка учётных данных (Credential Stuffing) не взламывает пароли вовсе: она использует готовые пары логин/пароль из утечек и проверяет их на других сервисах, рассчитывая на повторное использование.

Что такое распыление паролей и почему его сложно обнаружить?

Распыление паролей (Password Spraying) — атака, при которой один популярный пароль проверяется против тысяч учётных записей. Логика обратная классическому брутфорсу: не множество паролей против одного аккаунта, а один пароль против всех. Стандартные системы защиты реагируют на серии неудачных попыток по одному аккаунту — при распылении этот порог не достигается никогда. Атака может длиться неделями без единого алерта.

Что такое атака по радужным таблицам и как от неё защититься?

Атака по радужным таблицам — офлайн-метод взлома хешей с помощью предвычисленных таблиц соответствий «пароль → хеш». Вместо того чтобы хешировать кандидатов на лету, атакующий ищет совпадение в готовой структуре — это несравнимо быстрее прямого перебора. Единственная надёжная защита — соление хешей: уникальная случайная строка, добавляемая к каждому паролю перед хешированием, делает любую предвычисленную таблицу бесполезной. Алгоритмы MD5 и SHA-1 без соли взламываются за секунды — bcrypt и Argon2 с солением остаются стойкими.

Защищает ли многофакторная аутентификация от брутфорса?

МФА блокирует подавляющее большинство атак: даже подобранный пароль не даёт доступа без второго фактора. По оценке Microsoft, МФА предотвращает более 99% атак с использованием скомпрометированных учётных данных. Наиболее надёжны аппаратные ключи стандарта FIDO2/WebAuthn — они не уязвимы к фишингу и перехвату кода. SMS-коды защищают хуже из-за уязвимости к SIM-свопингу, но лучше, чем отсутствие второго фактора.

Как ИИ изменил брутфорс-атаки?

Модели машинного обучения, обученные на миллиардах реальных паролей из утечек, генерируют статистически вероятные кандидаты — не случайные комбинации, а те, которые люди действительно создают. PassGAN взломала 51% паролей из датасета RockYou менее чем за минуту. ИИ знает типичные замены символов, корпоративные шаблоны, региональные паттерны. Любой пароль, созданный по человеческой логике, уязвим. Единственный надёжный ответ — криптографически случайная строка из менеджера паролей.

Как корпоративный менеджер паролей снижает риск брутфорса?

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

Что делать, если организация обнаружила признаки брутфорс-атаки?

При выявлении серий неудачных попыток входа или нетипичной активности в журналах аутентификации — последовательность действий следующая: заблокировать атакующие IP-адреса и диапазоны, принудительно сменить пароли на атакованных системах, включить или усилить МФА на всех затронутых аккаунтах, провести аудит учётных записей на предмет компрометации, проверить журналы на признаки успешного входа до момента обнаружения. Высокий брутфорс-трафик может быть дымовой завесой — параллельно стоит проверить другие векторы активности в сети.

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

Блог ПассворкаАнастасия Лебедева

22 июня 2026 года Президент США Дональд Трамп подписал указ «О защите страны от продвинутых криптографических атак» — первый в американской истории документ с жёсткими, юридически обязывающими дедлайнами перехода на постквантовую криптографию.

Первый абзац указа формулирует угрозу без дипломатических оговорок:

«Появление крупномасштабных квантовых компьютеров, особенно в руках противников, создаст значительную угрозу широко используемым криптографическим системам защиты. Продолжающаяся киберактивность против нашей страны создаёт риск того, что противники собирают информацию США сейчас и расшифруют её позже, как только крупномасштабные квантовые компьютеры станут реальностью».

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

Подобная стратегия называется Собирай сейчас, расшифруй потом (Harvest Now, Decrypt Later, HNDL), и именно она стала главным обоснованием для указа.

Российские регуляторы — ФСБ, Минцифры, ФСТЭК, Росстандарт и ТК 26 движутся в том же направлении, хотя и по собственной траектории. Россия не адаптирует зарубежные алгоритмы, а разрабатывает собственные: «Шиповник», «Гиперикум» и «Кодиеум» проходят открытый криптоанализ в рамках ТК 26. Параллельно страна уже эксплуатирует одну из крупнейших в мире квантовых коммуникационных сетей (магистральную сеть РЖД) и запускает промышленные пилоты QKD в финансовом секторе, телекоммуникациях и ТЭК.

Главное

• Атака идёт уже сейчас. Стратегия HNDL не требует квантового компьютера: злоумышленники перехватывают и архивируют зашифрованный трафик сегодня, чтобы расшифровать его после Q-Day. Данные с долгим сроком конфиденциальности под угрозой прямо сейчас.
• Q-Day ближе, чем казалось. Ещё в 2023 году эксперты называли горизонт 2035–2040 годов. Исследование Google в марте 2026 года сократило оценку необходимых ресурсов в 20 раз. Google, IBM и Cloudflare сошлись на 2029 годе как внутреннем дедлайне перехода.
• Под угрозой — асимметричная криптография. Алгоритм Шора взломает RSA, ECDSA и ГОСТ Р 34.10-2012 за минуты. Симметричные шифры (AES-256, Кузнечик, Магма) сохраняют достаточный уровень защиты: алгоритм Гровера лишь снижает стойкость вдвое.
• Регуляторы установили жёсткие дедлайны. Указ Трампа от 22 июня 2026 года обязывает федеральные системы США и их подрядчиков перейти на стандарты NIST к 2030–2031 годам. ЕС, Великобритания и Германия установили аналогичные сроки. Через требования к подрядчикам дедлайны распространяются на глобальный ИТ-рынок.
• Россия строит суверенный постквантовый стек. ТК 26 разрабатывает три алгоритма-кандидата — «Шиповник», «Гиперикум» и «Кодиеум». Принятие национальных стандартов прогнозируется в ближайшие годы. Россия входит в тройку стран с действующими квантовыми вычислителями на всех четырёх основных платформах.
• Практика опережает стандарты. Пилоты QKD уже запущены в финансовом секторе (ВТБ, Газпромбанк, НСПК), телекоммуникациях (Билайн) и ТЭК (НОВАТЭК). Магистральная сеть РЖД длиной 7 858 км служит базовой инфраструктурой для новых корпоративных подключений.
• Первый шаг — аудит, не замена алгоритмов. Постквантовый переход начинается с аудита: инвентаризации всех криптографических алгоритмов, ключей и сертификатов в инфраструктуре. Без этого невозможно оценить масштаб задачи и расставить приоритеты миграции.

Что такое постквантовая криптография?

Постквантовая криптография (PQC, Post-Quantum Cryptography) — класс криптографических алгоритмов, устойчивых к атакам квантовых компьютеров. Она защищает те же каналы и данные, что и классическая криптография, но строится на математических задачах, для которых не существует эффективного квантового алгоритма: решётки, коды с исправлением ошибок, хеш-функции.

Важно не путать два термина:

• Постквантовая криптография (PQC) — новые математические алгоритмы шифрования, устойчивые к атакам квантовых компьютеров.
• Квантовая криптография (QKD, квантовое распределение ключей) — метод защищённой передачи криптографических ключей, основанный не на математике, а на законах физики. Ключ кодируется в квантовых частицах — фотонах. Если третья сторона попытается перехватить передачу, квантовое состояние фотонов изменится, и обе стороны немедленно обнаружат факт прослушивания.

Проще говоря: PQC защищает сами алгоритмы шифрования, QKD защищает канал передачи ключей. В долгосрочной перспективе их совместное применение формирует полноценную квантово-устойчивую архитектуру.

Что такое Q-Day?

Квантовый день (Q-Day, День Q) — условное название момента, когда криптоаналитически релевантный квантовый компьютер (CRQC) достигнет достаточной мощности для взлома современных алгоритмов шифрования. Точная дата неизвестна, но атаки, рассчитанные на этот момент, идут уже сейчас.

Математическую основу угрозы заложил Питер Шор в 1994 году. Его алгоритм показал: задачи факторизации больших чисел и дискретного логарифмирования, на которых держатся все широко используемые асимметричные алгоритмы (RSA, ECC, Диффи-Хеллман), принципиально разрешимы на квантовом компьютере за практически приемлемое время.

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

Это означает, что под угрозой оказывается вся инфраструктура, которая опирается на асимметричную криптографию: TLS, SSH, PKI, электронные подписи, блокчейн.

Для симметричных алгоритмов (AES-256, Кузнечик) угроза иная и менее критичная. Алгоритм Гровера снижает эффективную длину ключа вдвое: AES-256 и ГОСТ Р 34.12-2015 («Кузнечик») становятся эквивалентом 128-битной защиты. Этот уровень стойкости ФСБ России и Национальный институт стандартов и технологий США (NIST) признают достаточным на обозримую перспективу.

Насколько близок Q-Day?

Ещё в 2023 году большинство экспертов называли Q-Day горизонтом 2035–2040 годов. Сейчас прогнозы сжались. Большинство мировых и российских аналитиков ориентируются на 2028–2030 годы. При этом они подчёркивают: ключевой риск начинается раньше квантового дня — именно через HNDL-атаки.

В марте 2026 года Google опубликовал исследование, которое резко сдвинуло оценки. Команда Райана Баббуша и Хартмута Невена показала: для взлома 256-битной эллиптической криптографии (основы блокчейнов, цифровых подписей и большинства протоколов аутентификации) достаточно менее 500 000 физических кубитов. Это в 20 раз меньше предыдущих оценок. Алгоритм Шора на такой машине решит задачу за считанные минуты.

Ещё раньше, 25 марта 2026 года, Google объявил внутренний дедлайн перехода на постквантовую криптографию к 2029 году и призвал другие команды последовать примеру. Android 17 уже интегрирует постквантовые цифровые подписи на основе ML-DSA, а Chrome поддерживает PQC-шифрование.

IBM и Cloudflare называют тот же горизонт. В июне 2025 года IBM анонсировала план создания первого крупномасштабного отказоустойчивого квантового компьютера к 2029 году. В апреле 2026 года Cloudflare сдвинул собственный целевой срок полной постквантовой защиты на тот же год — после исследовательских прорывов Google и Oratomic в области квантовых алгоритмов. Три крупнейших технологических игрока независимо друг от друга сошлись на одной дате.

Что такое Harvest Now, Decrypt Later?

Собирай сейчас, расшифруй потом (Harvest Now, Decrypt Later, HNDL) — это стратегия, при которой злоумышленник перехватывает и архивирует зашифрованные данные сегодня, не имея возможности их прочитать, с расчётом расшифровать после появления криптоаналитически релевантного квантового компьютера. Атака не требует квантового компьютера прямо сейчас — она требует терпения и дискового пространства.

«Ждать появления угрозы, чтобы начать действовать, — путь к катастрофе. Во-первых, существует угроза «собирай сейчас, расшифруй потом». Уже сегодня злоумышленники могут накапливать зашифрованный трафик: переписку, финансовые документы, медицинские данные. Когда появится квантовый компьютер, они смогут расшифровать всё, что собирали годы. Если ваша информация должна оставаться тайной 10−30 лет, сегодняшние методы её не спасут», — Иван Чижов, заместитель руководителя лаборатории криптографии по научной работе компании «Криптонит» (Криптонит, 2026)

Как работает HNDL

Собирай сейчас, расшифруй потом разделяет атаку на три этапа, разнесённых во времени:

1. Перехват. Злоумышленники собирают большие объёмы зашифрованного трафика и конфиденциальных данных.
2. Хранение. Перехваченные данные складируются на неопределённый срок: расшифровать их сейчас невозможно.
3. Расшифровка. После появления квантовых компьютеров весь накопленный архив расшифровывается.

Перехват не требует взлома — достаточно скопировать трафик. Это делает атаку практически незаметной: жертва не получает никаких сигналов о компрометации и узнаёт о ней только тогда, когда данные уже раскрыты.

Кого это касается в первую очередь

HNDL-атака бьёт прежде всего по данным с долгим сроком актуальности — тем, которые останутся чувствительными через 5, 10 или 20 лет. Чем дольше данные сохраняют ценность, тем выше риск.

Общий знаменатель — время. Злоумышленнику не нужно взламывать шифрование прямо сейчас. Достаточно собрать данные и подождать.

Глобальная регуляторика

Международная реакция на квантовую угрозу перешла из научной плоскости в нормативную. Ключевые юрисдикции уже установили обязывающие сроки или активно готовят стандарты — независимо от того, приняли ли они алгоритмы Национальный институт стандартов и технологий США (NIST) или разрабатывают собственные.

США

В августе 2024 года NIST утвердил три постквантовых стандарта:

• FIPS 203 (ML-KEM) — механизм инкапсуляции ключей, основан на алгоритме CRYSTALS-Kyber. Предназначен для защиты каналов связи от HNDL-атак.
• FIPS 204 (ML-DSA) — алгоритм цифровой подписи, основан на CRYSTALS-Dilithium. Заменяет ECDSA и RSA-подписи.
• FIPS 205 (SLH-DSA) — алгоритм цифровой подписи на основе хеш-функций (SPHINCS+). Альтернатива ML-DSA с иной математической базой.

Все три алгоритма уже реализованы в основных криптографических библиотеках (OpenSSL 3.x, BoringSSL, libsodium) и доступны для внедрения.

Указ от 22 июня 2026 года «О защите страны от продвинутых криптографических атак» перевёл рекомендации в жёсткие дедлайны. До 31 декабря 2030 года все федеральные системы будут обязаны перейти на постквантовые алгоритмы защиты каналов связи. До 31 декабря 2031 года — завершить замену алгоритмов цифровой подписи, которые удостоверяют подлинность документов, кода и сертификатов.

Раздел 6(c) указа — самый острый инструмент давления на рынок: Федеральный совет по регулированию закупок США обязан опубликовать правило, требующее от всех подрядчиков федерального правительства соответствия стандартам NIST FIPS, включая алгоритмы постквантовой криптографии, к 31 декабря 2030 года.

Это создаёт цепную реакцию. Microsoft, AWS, Google, SAP и тысячи других вендоров, работающих с федеральными заказчиками, обязаны обеспечить совместимость своих продуктов с постквантовыми стандартами к 2030 году или потерять выход на крупный рынок.

Одновременно подписан сопутствующий указ о квантовых инновациях — программа по созданию правительственного квантового компьютера для ускорения научных открытий.

«Америка находится на пороге квантовой революции. Квантовая информатика и технологии откроют трансформационные возможности, которые будут двигать американские инновации, обеспечивать экономический рост, создавать высокооплачиваемые рабочие места и укреплять национальную безопасность. Поскольку другие страны стремительно бросают вызов американскому лидерству, США должны применить согласованный, общенациональный подход к ускорению внедрения и коммерциализации квантовых вычислений, квантового зондирования и квантовых сетей».

Риторика указов подчёркивает: для США постквантовый переход — вопрос технологического лидерства. Дедлайны 2030–2031 годов обязательны для всего федерального сектора США и через требования к подрядчикам будут распространяться на глобальный ИТ-рынок.

Китай

Управление государственной коммерческой криптографии (OSCCA) в феврале 2025 года запустило программу разработки алгоритмов следующего поколения. Национальные постквантовые стандарты ожидаются к 2028–2029 годам.

Действующая криптографическая база Китая (алгоритмы семейства ShangMi — SM2, SM3, SM4), уязвима перед квантовыми компьютерами. Параллельно Китай развивает крупнейшую в мире инфраструктуру квантового распределения ключей (QKD) — технология позволяет передавать криптографические ключи с абсолютной защитой от перехвата, используя законы квантовой механики. Квантовые технологии включены в число главных приоритетов 15-го пятилетнего плана развития Китая.

Европейский союз

В апреле 2024 года Европейская комиссия выпустила официальную рекомендацию по переходу на постквантовое шифрование (документ № 2024/1101). В развитие этой инициативы в июне 2025 года была представлена «Скоординированная дорожная карта внедрения постквантового шифрования». Финальный срок перехода установлен на декабрь 2030 года.

План миграции разделен на три этапа:

1. Инвентаризация (до конца 2025 года) — аудит текущих ИТ-систем и поиск уязвимых алгоритмов шифрования.
2. Гибридные пилотные проекты (2026–2027 годы) — тестирование новых алгоритмов совместно с классическими методами защиты.
3. Полный переход (до конца 2030 года) — окончательный отказ от устаревшего шифрования и внедрение постквантовых стандартов.

Каждые полгода участники процесса отчитываются о результатах перед Агентством Европейского союза по кибербезопасности (ENISA).

Великобритания

В марте 2025 года Национальный центр кибербезопасности Великобритании (NCSC) опубликовал трёхэтапную дорожную карту перехода на новые стандарты безопасности.

План миграции включает следующие шаги:

1. Инвентаризация и аудит (до 2028 года). Организациям необходимо полностью проверить свои ИТ-системы и составить подробную спецификацию криптографических материалов (Cryptographic Bill of Materials, CBOM). Этот реестр покажет, какие именно алгоритмы, ключи и сертификаты используются в инфраструктуре.
2. Защита критических систем (до 2031 года). На этом этапе планируется перевести наиболее важные государственные и корпоративные системы на гибридную криптографию — комбинацию классических и новых алгоритмов шифрования.
3. Полный отказ от устаревших алгоритмов (до 2035 года). К этому моменту организации должны полностью прекратить использование уязвимых криптографических алгоритмов (таких как RSA, ECDH и ECDSA) и перейти на постквантовые стандарты.

Для операторов критической инфраструктуры эти требования фактически обязательны. Государственные регуляторы будут проверять британские компании на соответствие правилам сетевой и информационной безопасности именно по этой дорожной карте.

Германия

Федеральное ведомство по информационной безопасности Германии (BSI) последовательно публикует требования по переходу на новые стандарты защиты с 2021 года. Актуальная версия технического руководства ведомства (документ BSI TR-02102 за 2024 год) содержит следующие положения:

• Гибридный режим. Ведомство рекомендует использовать новые алгоритмы постквантового шифрования ML-KEM (для защиты каналов связи и обмена ключами) и ML-DSA (для создания цифровой подписи) только совместно с классическими методами защиты.
• Сроки перехода. Полную миграцию ИТ-систем на новые стандарты безопасности планируется завершить до 2030 года.
• Гибкость в выборе стандартов. В отличие от многих других стран, Германия разрешает компаниям использовать альтернативные криптографические алгоритмы, даже если они не входят в стандарты американского Национального института стандартов и технологий (NIST). Главное условие — математически доказанная надежность этих алгоритмов.

Южная Корея

Южная Корея стала единственной страной, которая разработала собственный набор алгоритмов постквантового шифрования и закрепила его в национальной дорожной карте. Для этого Корея провела национальный конкурс KpqC, по итогам которого были выбраны криптографические стандарты:

• Для создания цифровых подписей утверждены алгоритмы AIMer и HAETAE.
• Для безопасного обмена ключами шифрования выбраны алгоритмы SMAUG-T и NTRU+.

В феврале 2025 года Министерство науки, информационно-коммуникационных технологий и планирования Южной Кореи (MSIT) опубликовало национальную дорожную карту перехода. План миграции разделен на два ключевых этапа:

1. Пилотное внедрение (2025–2028 годы). Тестирование южнокорейских алгоритмов в реальных инфраструктурах и запуск первых тестовых проектов.
2. Полная миграция (до 2035 года). Окончательный переход государственных ведомств и бизнеса на новые стандарты безопасности.

Сравнительная таблица: регуляторика постквантовой криптографии

Российские реалии

Россия идёт к постквантовым стандартам собственным путём. Рабочая группа «Постквантовые криптографические механизмы» в составе ТК-26 создана ещё в 2019 году. По состоянию на середину 2026 года страна перешла из стадии исследований в стадию стандартизации — национальный стандарт постквантовых алгоритмов ещё не принят, его утверждение Росстандартом прогнозируется в ближайшие годы.

Отставание от американского графика объяснимо: Россия разрабатывает собственные алгоритмы, а не адаптирует зарубежные. Такой подход обеспечивает технологический суверенитет, но требует времени на полный цикл криптоанализа и стандартизации.

«Как и в любой наукоёмкой отрасли, в криптографии всегда всё начинается с фундамента и дальше прорастает во всё более и более прикладные области. И когда мы говорим про текущее состояние дел, мы понимаем, что у нас есть фундамент — свой, надёжный, суверенный. На нём мы строим российскую криптографию и создаём решения, которые не отстают от зарубежных аналогов, а в ряде направлений опережают мировые разработки», — Станислав Смышляев, генеральный директор компании «КриптоПро» (CNews, июнь 2026)

Суверенный статус российских квантовых разработок подтверждают и данные «Росатома». Директор по квантовым технологиям госкорпорации Екатерина Солнцева на конференции ЦИПР-2026 (Нижний Новгород, май 2026) сообщила:

«В зарождающейся квантовой индустрии известно приблизительно 100 типов квантовых алгоритмов, из которых примерно 20 воспринимаются как основные и 80 являются модификациями. У нас есть российские версии всех основных квантовых алгоритмов и порядка тридцати модификаций. То есть стек квантового программного обеспечения покрыт у нас уже достаточно хорошо. И сейчас мы приходим к тому, чтобы научиться использовать имеющиеся наработки для практических задач».

Российские эксперты сходятся в оценке приоритетов. Главный риск — не коллапс в день появления квантового компьютера, а сценарий Собирай сейчас, расшифруй потом (HNDL, Harvest Now, Decrypt Later).

Алексей Лукацкий, бизнес-консультант по информационной безопасности Positive Technologies, уточняет приоритеты по типам данных: для информации с долгим сроком секретности — государственная тайна, критическая инфраструктура, отдельные категории персональных данных, банковская и корпоративная тайна — менять системы шифрования нужно уже сейчас. Сама замена алгоритмов во всей инфраструктуре может занять годы, и этот срок нужно закладывать в планирование (Ведомости, июнь 2026).

На ПМЭФ-2026 (сессия «После гонки кубитов: кто строит квантовое будущее», 4 июня) участники зафиксировали смену фазы: российский рынок переходит от доказательства работоспособности технологии к её масштабированию в корпоративном секторе. «Иннопрактика» выделила три сценария квантовой трансформации для крупных компаний: пилоты на действующей ИТ-инфраструктуре, новые коммерческие сервисы для операторов ЦОД и долгосрочные стратегии перехода на квантово-защищённые каналы связи.

В России уже существует серийно выпускаемое оборудование и накоплен опыт промышленной эксплуатации — магистральная квантовая сеть РЖД используется как базовая инфраструктура для подключения новых корпоративных заказчиков.

Симметричная криптография: что уже защищено

Российские симметричные алгоритмы Кузнечик (ГОСТ Р 34.12-2015) и Магма (ГОСТ Р 34.12-2015) устойчивы к квантовым атакам в своём нынешнем виде. Алгоритм Гровера снижает эффективную стойкость симметричного ключа вдвое: 256 бит → 128 бит эффективной стойкости. 128-битный уровень безопасности считается достаточным по современным криптографическим стандартам. Хеш-функция Стрибог (ГОСТ Р 34.11-2012) также устойчива к известным квантовым атакам.

Это означает, что инфраструктура, уже использующая ГОСТ-шифрование для защиты данных «в покое» (at rest), не требует срочной замены симметричной части. Приоритет перехода — асимметричная криптография: ГОСТ Р 34.10-2012 (электронная подпись на эллиптических кривых) будет взломан алгоритмом Шора так же, как RSA и ECDSA.

Алгоритмы-кандидаты

Технический комитет ТК 26 («Криптографическая защита информации») с 2019 года ведёт разработку постквантовых стандартов через рабочую группу «Постквантовые криптографические механизмы». Три алгоритма-кандидата:

• Шиповник — российский кандидат на постквантовую схему электронной цифровой подписи, основанный на кодах с исправлением ошибок (аналог семейства BIKE/HQC в конкурсе NIST). Компания Криптонит опубликовала открытую реализацию алгоритма. При успешном завершении криптоанализа Шиповник может стать первым российским постквантовым стандартом ЭЦП.
• Гиперикум — кандидат на постквантовую схему подписи на основе хеш-функций. Использует российский стандарт хеширования Стрибог-256 (ГОСТ Р 34.11-2012) как криптографическое основание — аналогично тому, как западный SLH-DSA (FIPS 205) строится на SHA-3. Разработка ведётся сотрудниками QApp в рамках деятельности подгруппы ТК 26.
• Кодиеум — постквантовый механизм инкапсуляции ключей (KEM), разработанный Криптонитом в 2024 году. Функционально является постквантовым аналогом протокола Диффи-Хеллмана: защищает передачу ключей шифрования при установке защищённого соединения. Как и Шиповник, основан на математической задаче декодирования случайного кода с исправлением ошибок. Проходит процедуру разработки методических рекомендаций по стандартизации в ТК 26.

Все три алгоритма проходят открытый криптоанализ — обязательный этап перед стандартизацией.

Практика внедрения: российские пилоты 2025–2026

Россия не ждёт принятия стандартов, чтобы начать практическую работу. Несколько крупных проектов уже перешли от концепции к реальной эксплуатации.

Финансовый сектор

QApp и Газпромбанк — компания QApp завершила пять пилотных проектов с Газпромбанком в области постквантовой защиты финансовых коммуникаций.

QApp и НСПК (Национальная система платёжных карт, оператор «Мир») — два пилотных проекта:

• Защита электронного документооборота — НСПК интегрировала решение Qtunnel компании QApp в систему электронного документооборота. Постквантовые алгоритмы шифрования заменили асимметричные схемы, уязвимые к атакам квантовых компьютеров. Проект реализован совместно с Российским квантовым центром (РКЦ).
• PQC PAY — разработка и тестирование квантово-устойчивых платёжных транзакций по протоколу BLE (Bluetooth Low Energy). Проект направлен на защиту бесконтактных платежей от будущих квантовых атак.

ВТБ — в мае 2026 года банк завершил пилотное тестирование защищённого канала связи на основе квантового распределения ключей (QKD). Между двумя московскими ЦОД банка проложена специализированная оптоволоконная линия: оборудование компании «Инфотекс» генерирует и автоматически распределяет симметричные ключи шифрования со скоростью до одного ключа в минуту без физических носителей и участия сотрудников в процессе доставки. Любое внешнее воздействие на канал мгновенно фиксируется через изменение фазы или амплитуды фотона. Партнёрами проекта выступили РЖД и «Иннопрактика». Результаты представлены на ПМЭФ-2026.

Топливно-энергетический комплекс

НОВАТЭК — в апреле 2026 года на объектах ПАО «НОВАТЭК» впервые в российском ТЭК протестировано оборудование квантового распределения ключей. Использовалось решение ViPNet QTS производства «ИнфоТеКС» — система для построения квантовой криптографической сети произвольной топологии.

Организационную поддержку оказали «Иннопрактика» и АНО «Центр развития квантовых технологий» (ЦРКТ). По итогам пилота зафиксирована положительная оценка технологической готовности решения. Предприятия ТЭК относятся к объектам критической информационной инфраструктуры (КИИ), что делает этот пилот прецедентным для всей отрасли.

Телекоммуникации

Билайн и РЖД — в апреле 2026 года ПАО «ВымпелКом» и РЖД совместно с «ИнфоТеКС» провели пилотные испытания QKD на реальной корпоративной сети. Московские офисы Билайна и РЖД подключили к узлу магистральной квантовой сети РЖД с помощью оборудования ViPNet.

В программу испытаний вошли генерация и распределение ключей шифрования, организация IP-связности, передача данных, VoIP-звонки и видеоконференцсвязь по защищённому каналу. Использовались программно-аппаратные комплексы «ИнфоТеКС»: ViPNet РУКС, шифратор канального уровня ViPNet L2Q-10G и криптошлюз ViPNet Coordinator HW 1000. Все тесты прошли успешно.

Инфраструктура

Квантовая сеть РЖД — магистральная квантовая сеть протяжённостью 7 858 км, охватывающая 27 регионов России. Это одна из крупнейших квантовых коммуникационных сетей в мире. Сеть использует технологию QKD для защиты критических железнодорожных коммуникаций.

Первый квантово-устойчивый TLS-шлюз — совместная разработка QApp и компании «С-Терра» обеспечивает постквантовую защиту HTTPS-трафика на уровне сетевого шлюза. Это позволяет организациям внедрять PQC без замены всей клиентской инфраструктуры.

Наука и государство

НТУ «Сириус» разработал два программных комплекта (SDK):

• SDK «Сириус-Q. Решатель QUBO» — инструмент для квантовых оптимизационных задач.
• SDK «Сириус-Q. КНАА-2-ЭЦП» — реализация квантово-устойчивой электронной цифровой подписи.

В марте 2026 года оба SDK одобрены Минцифры России для защиты национальных блокчейн-экосистем. Это первый официальный государственный акт признания конкретных постквантовых инструментов в России.

Заключение

Указ Трампа от 22 июня 2026 года — признание того, что атака HNDL уже идёт. HNDL-перехват не требует квантового компьютера сегодня, а всего лишь терпения. Данные, зашифрованные прямо сейчас, могут быть скомпрометированы в момент наибольшей чувствительности через пять, десять или пятнадцать лет.

Россия движется по собственной траектории: суверенные алгоритмы-кандидаты проходят криптоанализ, пилоты QKD запущены в финансовом секторе, ТЭК и телекоммуникациях, стандарты ожидаются в 2026–2027 годах. Направление совпадает с глобальным — сроки и инструменты отличаются.

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

Корпоративные учётные данные — критический элемент криптографической инфраструктуры. Пассворк разворачивается на вашем сервере или в облаке, хранит пароли и секреты в зашифрованном виде и даёт администраторам полный контроль над доступом. Это первый шаг к управляемой криптографической среде. Протестировать можно бесплатно

Часто задаваемые вопросы о постквантовой криптографии

Что такое постквантовая криптография?

Постквантовая криптография (PQC) — это класс криптографических алгоритмов, устойчивых к атакам как классических, так и квантовых компьютеров. В отличие от квантовой криптографии (QKD), PQC работает на обычном «классическом» оборудовании и не требует квантовых каналов связи. Стандарты PQC основаны на математических задачах, для которых не существует эффективного квантового алгоритма: решётки, коды с исправлением ошибок, хеш-функции.

Что такое атака Harvest Now, Decrypt Later (HNDL)?

Собирай сейчас, расшифруй потом (HNDL) — стратегия, при которой злоумышленники перехватывают и сохраняют зашифрованные данные сегодня, рассчитывая расшифровать его позже с помощью квантового компьютера. Угроза актуальна для любых данных с долгим сроком конфиденциальности: государственные секреты, медицинские записи, финансовые сделки, интеллектуальная собственность. Перехват может происходить прямо сейчас — без каких-либо признаков атаки.

Когда появится криптографически значимый квантовый компьютер (Q-Day)?

Точной даты не знает никто, но консенсус экспертного сообщества сместился к 2028–2030 годам. Google, IBM и Cloudflare независимо друг от друга назвали 2029 год внутренним дедлайном перехода. Ключевое препятствие — коррекция квантовых ошибок: современные процессоры содержат тысячи физических кубитов, тогда как для взлома RSA-2048 алгоритмом Шора потребуются миллионы логических стабильных кубитов. Темп решения этой инженерной проблемы и определит реальный срок Q-Day.

Какие российские постквантовые алгоритмы разрабатываются?

ТК 26 («Криптографическая защита информации») продвигает три алгоритма-кандидата: «Шиповник» (схема ЭЦП на кодах с исправлением ошибок), «Гиперикум» (схема подписи на основе хеш-функции «Стрибог-256») и «Кодиеум» (механизм инкапсуляции ключей, постквантовый аналог протокола Диффи-Хеллмана). Все три проходят открытый криптоанализ. Принятие национальных стандартов прогнозируется в 2026–2027 годах.

Устойчивы ли российские ГОСТы к квантовым атакам?

Зависит от типа алгоритма. Симметричные шифры «Кузнечик» и «Магма» с ключами 256 бит сохраняют квантовую устойчивость — алгоритм Гровера снижает стойкость лишь вдвое. Хеш-функция «Стрибог» также устойчива. Уязвим ГОСТ Р 34.10-2012 (электронная подпись на эллиптических кривых) — алгоритм Шора взломает его так же, как RSA и ECDSA.

Чем QKD отличается от постквантовой криптографии?

QKD (квантовое распределение ключей) и PQC решают одну задачу — защиту от квантовых атак — принципиально разными методами. QKD использует законы квантовой механики для физически защищённой передачи ключей: любой перехват изменяет состояние фотонов и мгновенно обнаруживается. PQC — это математические алгоритмы, работающие на классическом оборудовании. QKD требует специальной оптоволоконной инфраструктуры и подходит для защиты каналов между конкретными точками. PQC масштабируется на любую существующую сеть без замены оборудования.

ГОСТ-шифрование для разработчиков: алгоритмы, СКЗИ и интеграция 2026

ГОСТ-стек хорошо специфицирован — сложность в интеграции. Разбираем четыре актуальных стандарта с OID-ами, механику шифрования изнутри, типичные точки отказа в nginx, Docker и браузерах, классы СКЗИ и границы лицензирования ФСБ и ФСТЭК.

Блог ПассворкаИлья Шелыгин

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

Блог ПассворкаИлья Шелыгин

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

Большинство разрушительных атак с использованием шифровальщиков и программ уничтожения данных заканчиваются успехом по ряду причин: ошибки в проектировании сети, небезопасное хранение учётных данных, доступность резервных копий из основной инфраструктуры и возможность беспрепятственной разведки внутри сети. Атакующий, попав внутрь, без труда находит всё необходимое для финального удара.

По данным ежегодного отчёта F6 «Аналитика и прогнозы 2025–2026», количество атак шифровальщиков в 2025 году выросло на 15%, а каждый седьмой инцидент в среднем и крупном бизнесе завершился не выкупом, а уничтожением инфраструктуры — вдвое чаще, чем годом ранее. Рекордный запрошенный выкуп достиг 500 млн рублей. За этими цифрами стоят типовые архитектурные просчёты: открытые пути к резервным копиям, пароли в общем доступе, домен без сегментации.

Эксперты F6 и специалисты Пассворка проанализировали реальные инциденты и сформировали технические и архитектурные рекомендации на основе того, что фактически позволило атакующим достичь цели. Каждая рекомендация в этой статье закрывает конкретный вектор — тот, который в зафиксированных случаях оказался решающим.

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

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

Критический сегмент ИТ-инфраструктуры с позиции информационной безопасности — это совокупность систем, компрометация которых делает невозможным восстановление после инцидента или открывает атакующему полный контроль над организацией. Конкретный состав зависит от инфраструктуры, но в большинстве организаций в него входят:

• Средства защиты информации — межсетевые экраны, системы обнаружения и предотвращения вторжений, анализа сетевого трафика, консоли управления endpoint-защитой, SIEM-системы.
• Хранилища секретов и аутентификационных данных — корпоративные менеджеры паролей, системы управления привилегированным доступом (PAM), центры сертификации, системы многофакторной аутентификации (MFA).
• Системы резервного копирования — серверы резервных копий, хранилища снимков виртуальных машин, офлайн-архивы.
• Инфраструктура виртуализации — гипервизоры, на которых размещены системы критического сегмента, и их интерфейсы управления.

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

Архитектурные принципы защиты

Рекомендации в статье охватывают каждый уровень: от сетевой архитектуры до конфигурации отдельных сервисов. Все они строятся на нескольких архитектурных принципах — без них технические меры не работают как система.

• Физическая и логическая изоляция. Системы критического сегмента не должны входить в домен Active Directory (AD). Это исключает целый класс атак на доменные службы.
• Выделенная административная станция. Управление критическими системами осуществляется только с отдельной рабочей станции, не входящей в домен и не используемой в повседневной работе.
• Отсутствие учётных данных в операционной инфраструктуре. Аутентификационные данные от систем критического сегмента не хранятся и не передаются через основную доменную инфраструктуру.

Эти три принципа взаимосвязаны: изоляция теряет смысл, если администратор заходит на защищённый сервер с рабочей станции из домена. Выделенная станция бесполезна, если учётные данные от нее хранятся на системах доменной инфраструктуры.

Почему защиты периметра недостаточно

Передовые средства обнаружения и реагирования — необходимое условие, но не достаточное. Чтобы эффективно противодействовать угрозам, попавшим внутрь сети, необходимо придерживаться принципов безопасного проектирования инфраструктуры.

Типичная цепочка продвижения атакующего внутри сети выглядит так:

1. Первоначальный доступ — через фишинг, уязвимость на периметре или, например, скомпрометированного подрядчика.
2. Разведка внутри сети — поиск критически важных сервисов компании, таких как контроллеры доменов, сервера приложений и баз данных, файловых хранилищ, систем резервного копирования, хранилищ паролей и иной конфиденциальной информации.
3. Повышение привилегий и компрометация аутентификационных данных  — извлечение учётных данных из памяти систем, браузеров и т.п.
4. Горизонтальное перемещение — с использованием легитимных сетевых протоколов и украденных учётных данных, а также с помощью техник атак на доменную инфраструктуру.
5. Компрометация критических систем — получение доступа к контроллерам доменов, серверам автоматизации, гипервизорам, серверам резервного копирования, хранилищам секретов и т.п.
6. Деструктивное воздействие — шифрование или уничтожение данных, включая резервные копии.

Цель харденинга критического сегмента — сделать продвижение атакующего максимально дорогостоящим по времени и ресурсам: он должен тратить на каждый следующий шаг больше времени, чем службе безопасности нужно для его обнаружения.

Рекомендации по безопасной конфигурации ИТ-инфрастуктуры критического сегмента

Рекомендации сгруппированы по направлениям. Каждая мера закрывает конкретный вектор атаки на основе техник, которые применялись в зафиксированных инцидентах.

Изоляция от доменной инфраструктуры

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

Рекомендация

Не размещайте сервисы управления средствами защиты информации (СЗИ), резервным копированием, хранилища секретов и аутентификационных данных (корпоративные менеджеры паролей, системы аутентификации) и их базы данных на серверах, входящих в домен Active Directory.

Почему это работает

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

Управление учётными данными

Повторное использование злоумышленниками паролей между сегментами — один из самых распространённых способов горизонтального перемещения. Если учётные данные от критических систем хранятся в основной инфраструктуре, компрометация домена автоматически означает компрометацию критического сегмента.

Рекомендация

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

Почему это работает

Если учётных данных от критических систем нет в домене — компрометация домена не даёт атакующему точки опоры для следующего шага. Дамп учётных данных из доменной инфраструктуры окажется бесполезным: войти в критические системы с его помощью не получится.

Сетевая изоляция и протоколы

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

Рекомендация

Отключите устаревшие сетевые протоколы и алгоритмы шифрования. Минимизируйте количество открытых портов. Ограничьте взаимодействие с публичными сетями.

Почему это работает

Закрытые порты и запрет устаревших протоколов устраняют downgrade-атаки и сокращают возможности нелегитимного взаимодействия с системами, уменьшая  поверхность атаки на них. Ограничение исходящего трафика блокирует установку C2-каналов (command-and-control) и эксфильтрацию данных, даже если злоумышленник уже получил доступ к хосту.

Принцип минимальных привилегий

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

Рекомендация

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

Почему это работает

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

Аутентификация: блокировка и MFA

Брутфорс, подстановка скомпрометированных учётных данных из утечек (credential stuffing), целенаправленные атаки на конкретные учётные записи — базовые техники, которые применяются против любых доступных интерфейсов аутентификации. Блокировка учётных записей и многофакторная аутентификация (MFA) создают барьеры, которые делают эти атаки нерентабельными.

Рекомендация

Настройте блокировку учётных записей после нескольких неудачных попыток входа. Внедрите MFA для доступа ко всем системам критического сегмента и размещённым на них сервисам.

Почему это работает

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

Шифрование дисков

Физический доступ к серверу или кража файлов виртуальных машин — реальные векторы атаки, особенно в средах с виртуализацией. Шифрование дисков защищает данные даже при полной потере контроля над носителем.

Рекомендация

Зашифруйте диски всех систем критического сегмента. Обеспечьте надёжное хранение ключевой информации.

Почему это работает

Зашифрованный диск, извлечённый из сервера или скопированный как файл ВМ, бесполезен без ключа. Это закрывает вектор физического доступа и кражи носителей.

Виртуализация: обособленный гипервизор

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

Рекомендация

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

Почему это работает

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

Обновления и встроенные механизмы безопасности

Уязвимости в ПО — постоянный источник точек входа и повышения привилегий. Критический сегмент должен быть в приоритете процесса управления обновлениями, а не исключением из него.

Рекомендация

Регулярно обновляйте операционные системы и компоненты сервисов критического сегмента. Включите все встроенные механизмы безопасности, реализованные в размещённых сервисах.

Почему это работает

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

Мониторинг и SIEM

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

Рекомендация

Настройте централизованный сбор и анализ событий безопасности критического сегмента в SIEM-системе.

Почему это работает

Злоумышленник, действующий в критическом сегменте, неизбежно оставляет следы. Централизованный мониторинг сокращает время обнаружения и даёт защитникам возможность среагировать до того, как атака достигла цели.

Защита критически важных устройств ИТ-инфраструктуры

Харденинг как стратегия сдерживания

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

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

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

Часто задаваемые вопросы

Что такое харденинг ИТ-инфраструктуры?

Харденинг — это процесс целенаправленного снижения поверхности атаки на компоненты ИТ-инфраструктуры: отключение неиспользуемых протоколов и сервисов, ограничение привилегий, настройка аутентификации и шифрования. Цель: сделать каждый компонент максимально устойчивым к компрометации, даже если периметр уже преодолён.

Какие системы являются критически важным сегментом инфраструктуры?

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

Что защищать в критическом сегменте?

Приоритет определяется ролью системы в финальной фазе атаки: резервные копии уничтожают, чтобы лишить организацию возможности восстановиться, хранилища секретов — чтобы эскалировать привилегии, гипервизоры дают доступ ко всем гостевым ВМ разом, средства защиты отключают, чтобы действовать незаметно. Active Directory — не часть критического сегмента, а инфраструктура, от которой он должен быть изолирован.

Как настроить харденинг критического сегмента без простоя?

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

Нужно ли выводить критические системы из домена Active Directory?

Да. Сервер в домене AD наследует всю его поверхность атаки. При полной компрометации домена злоумышленник получает инструменты для продвижения к любому доменному хосту через общие механизмы аутентификации. Вывод критических систем за пределы домена разрывает эту цепочку на архитектурном уровне.

Как проверить настройки перед внедрением в рабочую среду?

Изменения конфигурации критического сегмента стоит проверять на тестовом стенде, воспроизводящем целевую среду. Для оценки защищённости используют сканеры конфигураций, ручной аудит прав и сетевых правил, а также контролируемые тесты на проникновение с фиксацией результатов до и после изменений.

Какие ошибки чаще всего допускают при харденинге инфраструктуры?

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

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

Блог ПассворкаИлья Шелыгин

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

Блог ПассворкаАнастасия Лебедева

В 2025 году ФСТЭК проверила более 700 значимых объектов КИИ и выявила свыше 1 200 нарушений в части обеспечения информационной безопасности. Направлено более 2 000 требований об устранении недочётов и составлено 603 протокола об административных правонарушениях.

Показательна и другая цифра: по данным, озвученным начальником управления ФСТЭК Еленой Торбенко на «Инфофоруме 2026», лишь 35% проверенных объектов КИИ соответствуют минимальному базовому уровню безопасности. Там же она сообщила, что в этом году ФСТЭК увеличит количество проверок.

Государство намерено сделать процесс перехода на российское ПО неизбежным. В том числе через финансовое принуждение:

«Ключевой вызов этого года — сформировать базу для придания этому процессу неизбежности. Тогда, если компания не хочет переходить на российское ПО и ПАКи на КИИ-объектах, пусть пополняет бюджет, из которого мы будем стимулировать дальше этот процесс. В нашем понимании единственный механизм принуждения — это всё-таки какие-то серьёзные штрафы финансовые на те компании, которые нарушают сроки», — Максут Шадаев, министр цифрового развития РФ (Интерфакс, 2026)

В то же время регулирование стало сложнее. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования, проект постановления Минцифры со сроками 2028–2036 годов — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ (средства защиты информации) или ПАК (программно-аппаратный комплекс). Часть запретов уже действует с 2025 года.

Главное

• Часть запретов уже действует. С 01.01.2025 иностранные СЗИ запрещены на всех ЗОКИИ, иностранное ПО — на ЗОКИИ госорганов и госкомпаний. Это действующие нормы.
• Проектируемый базовый дедлайн — 01.01.2028. К этой дате доля российского ПО на всех ЗОКИИ должна составить 100%. Срок содержится в проекте постановления, находящемся в Правительстве, и пока не утверждён окончательно.
• Специальные сроки 2031 и 2036 годов — не массовая отсрочка. Они обсуждаются только для участников особо значимых проектов и отдельных категорий ЗОКИИ. Рассчитывать на них без документальных оснований не следует.
• Штрафы за нарушение сроков готовятся. В июне 2026 года Минцифры подтвердило намерение сформировать нормативную базу для серьёзных финансовых санкций. Действующей нормой они пока не являются, но при планировании этот риск уже нужно учитывать.
• Регулирование усложнилось. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ или ПАК.
• 2026 год — время подготовки, а не ожидания. Лишь 35% проверенных объектов КИИ соответствуют базовому уровню безопасности. ФСТЭК увеличивает число проверок. Компании, которые начнут аудит и ревизию категорирования сейчас, к дедлайну подойдут с готовым планом.

Что изменилось в импортозамещении КИИ к 2026 году

Регулирование критической информационной инфраструктуры (КИИ) менялось поэтапно, каждый этап добавлял новые обязанности для субъектов.

До 2025 года основу составляли Указы Президента № 166 и № 250. Первый ограничивал закупки иностранного ПО для значимых объектов КИИ (ЗОКИИ) без согласования и запрещал его использование на объектах госорганов и госкомпаний с 01.01.2025. Второй обязал всех владельцев ЗОКИИ перейти на российские средства защиты информации (СЗИ) — также с 01.01.2025. Оба указа касались конкретных категорий субъектов и не создавали единой системы управления переходом.

С 1 сентября 2025 вступил в силу 58-ФЗ и изменил архитектуру регулирования. Он существенно расширил полномочия Правительства РФ и создал нормативную основу для системного перехода на российское ПО и программно-аппаратные комплексы (ПАК) на значимых объектах КИИ. Правительство получило право устанавливать:

• перечни типовых отраслевых объектов КИИ;
• отраслевые особенности категорирования;
• порядок и сроки перехода на российское ПО и ПАК;
• требования к ПАК для ЗОКИИ;
• порядок мониторинга исполнения этих обязанностей.

В 2026 году появились первые подзаконные акты, реализующие 58-ФЗ. Постановление Правительства № 402 от 13.04.2026 установило отраслевые особенности категорирования объектов КИИ в сфере связи — они вступают в силу с 01.09.2026.

В мае 2026 года Минцифры представило проект постановления о сроках перехода ЗОКИИ на российское ПО с диапазоном 2028–2036 годов. По состоянию на июнь 2026 года проект находится в Правительстве и не утверждён окончательно.

2026 год — не период ожидания дедлайна 2028 года. Уже сейчас нужно уточнить состав объектов КИИ, провести аудит иностранного ПО и СЗИ, проверить наличие российских аналогов и подготовить согласованные дорожные карты перехода.

Кого касаются требования: субъект КИИ, объект КИИ, ЗОКИИ и типовые отраслевые объекты

Субъект КИИ — государственный орган, государственное учреждение или российское юридическое лицо, которому принадлежат информационные системы (ИС), информационно-телекоммуникационные сети (ИТКС) или автоматизированные системы управления (АСУ ТП) в критически важных сферах. После принятия 58-ФЗ индивидуальные предприниматели исключены из этого перечня.

Объект КИИ — конкретная ИС, ИТКС или АСУ ТП, принадлежащая субъекту. Не каждый объект автоматически становится значимым: статус присваивается только по результатам категорирования. Значимый объект КИИ (ЗОКИИ) — тот, которому присвоена одна из трёх категорий значимости. Именно к ЗОКИИ применяются требования по импортозамещению ПО, СЗИ и ПАК.

Отдельный инструмент — типовые отраслевые объекты КИИ: перечни типов ИС, ИТКС и АСУ, утверждаемые Правительством РФ по отраслям. Они служат ориентиром для выявления объектов, подлежащих категорированию, — первый такой перечень утверждён распоряжением № 360-р от 26.02.2026.

Отрасли, на которые распространяется 187-ФЗ

Согласно Федеральному закону от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», к субъектам КИИ относятся организации в сферах:

• здравоохранения, науки, транспорта, связи, энергетики;
• банковской и иной финансовой деятельности;
• топливно-энергетического комплекса;
• атомной, оборонной, ракетно-космической промышленности;
• горнодобывающей, металлургической и химической промышленности;
• государственной регистрации прав на недвижимость.

Три категории значимости

Три категории значимости (первая, вторая и третья) определяют объём требований к системе обеспечения информационной безопасности (СОИБ). Первая категория соответствует наиболее критичным объектам и предполагает максимально жёсткие требования; третья — минимальные. Если объект КИИ не соответствует ни одному из критериев значимости, категория ему не присваивается.

Категорию объекту присваивают сами субъекты КИИ на основании оценки по пяти критериям, закреплённым в ст. 7 № 187-ФЗ:

Результаты категорирования субъект КИИ направляет в ФСТЭК России в течение 10 дней после принятия решения. Регулятор в течение 30 дней проверяет правильность присвоения категории.

Сроки перехода на российское ПО, СЗИ и ПАК

Проектируемый базовый срок перехода значимых объектов КИИ на российское ПО — 1 января 2028 года. По состоянию на июнь 2026 года этот срок содержится в проекте постановления, находящемся в Правительстве, и должен применяться после утверждения соответствующего акта. К этой дате доля российского программного обеспечения на ЗОКИИ должна составлять 100%.

Для отдельных сценариев в публикациях о проекте фигурируют специальные сроки — 1 января 2031 года и 1 января 2036 года. Обсуждаются следующие сценарии: участие в особо значимых проектах (ОЗП) с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. До утверждения постановления эти условия следует считать проектируемыми и проверять по финальной редакции акта.

Матрица сроков: от 2022 до 2036 года (актуально на июнь 2026)

Ответственность за нарушение сроков: что известно на июнь 2026 года

Действующие административные составы за нарушения требований безопасности КИИ сохраняются. Отдельные штрафы именно за несоблюдение сроков перехода ЗОКИИ на российское ПО на дату публикации находятся в стадии подготовки: Минцифры заявило, что в 2026 году намерено сформировать нормативную базу для серьёзных финансовых санкций (Интерфакс, 2026). При планировании перехода штрафной риск уже нужно учитывать, но описывать его как действующую норму преждевременно.

Сроки по видам активов

Нормативная база: какие документы учитывать

Нормативная карта импортозамещения КИИ включает несколько уровней: базовый закон, президентские указы, правительственные акты и ведомственные приказы. Для практической работы важно понимать, какой документ регулирует какой аспект.

Карта нормативных актов

• 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» — базовый закон. Вводит понятия субъекта КИИ, объекта КИИ, значимого объекта КИИ, устанавливает требования к безопасности и взаимодействию с ГосСОПКА (государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации).
• 58-ФЗ от 07.04.2025 — поправки к 187-ФЗ, вступившие в силу 01.09.2025. Расширяют полномочия Правительства: устанавливать типовые отраслевые объекты, отраслевые особенности категорирования, порядок и сроки перехода на российское ПО и ПАК, требования к ПАК, порядок мониторинга. Исключают ИП из числа субъектов КИИ. Обязывают субъектов КИИ использовать на ЗОКИИ ПО из реестра российского ПО Минцифры.
• Указ Президента РФ № 166 от 30.03.2022 (в ред. от 07.04.2025) — ограничивает закупки иностранного ПО для ЗОКИИ без согласования. С 01.01.2025 устанавливает запрет использования иностранного ПО на ЗОКИИ, принадлежащих госорганам и государственным организациям.
• Указ Президента РФ № 250 — обязывает всех владельцев ЗОКИИ перейти на российские СЗИ. С 01.01.2025 использование иностранных СЗИ на ЗОКИИ запрещено.
• Постановление Правительства РФ № 402 от 13.04.2026 — утверждает отраслевые особенности категорирования объектов КИИ в сфере связи. Вступает в силу 01.09.2026. Первый отраслевой акт, реализующий полномочия Правительства по 58-ФЗ.
• Приказ ФСТЭК России № 117 — с 01.03.2026 обновляет требования защиты информации для государственных информационных систем (ГИС) и иных систем государственных органов, ГУПов и учреждений. Актуален для организаций, у которых объекты КИИ одновременно являются ГИС.
• Приказ ФСТЭК России № 247 от 11.07.2025 — обновляет форму направления сведений о результатах категорирования объектов КИИ. С 01.09.2025 форма дополнена полем о наименовании типового отраслевого объекта КИИ, доменным именем и внешним сетевым адресом.
• Постановление Правительства РФ № 127 — устанавливает показатели критериев значимости объектов КИИ и порядок категорирования.
• Постановление Правительства РФ № 1478 — определяет требования к системам безопасности значимых объектов КИИ.
• Распоряжение Правительства РФ № 360-р от 26.02.2026 — утверждает перечень типовых отраслевых объектов КИИ. Триггер для ревизии состава объектов у субъектов КИИ.

Как категорирование связано с импортозамещением

Категорирование — отправная точка всего проекта импортозамещения. Объём обязательств по переходу на российское ПО, СЗИ и ПАК напрямую зависит от того, какие объекты признаны значимыми и какую категорию они получили.

58-ФЗ добавил новый инструмент — типовые отраслевые объекты КИИ. Это перечни типов ИС, ИТКС и АСУ, утверждаемые Правительством РФ по отраслям. Они служат ориентиром для выявления объектов, подлежащих категорированию, и позволяют регулятору унифицировать подход к разным субъектам одной отрасли.

Распоряжение Правительства № 360-р от 26.02.2026 утвердило первый такой перечень. Для субъектов КИИ это означает необходимость сверить собственный реестр объектов с типовым перечнем: не исключено, что часть систем, ранее не признававшихся объектами КИИ, теперь попадает в периметр регулирования.

Почему актуализация категорирования критична в 2026 году

Форма направления сведений о результатах категорирования обновлена Приказом ФСТЭК № 247: с 01.09.2025 она включает поле о наименовании типового отраслевого объекта КИИ. Если организация не сверила свои объекты с новыми перечнями и не актуализировала сведения — она рискует направить во ФСТЭК неполные данные.

Реестр ЗОКИИ также получил новый формат регистрационного номера: XXXXXX/Х/XX/Х, где зашифрованы порядковый номер, федеральный округ, сфера деятельности и тип объекта (ИС, АСУ или ИТКС). Сведения из реестра ежемесячно передаются государственным органам, уполномоченным на реализацию государственной политики в соответствующей сфере.

Отраслевые особенности категорирования

Первый отраслевой акт (Постановление Правительства № 402 от 13.04.2026 для сферы связи) вступает в силу 01.09.2026. Он определяет отраслевые признаки значимости и порядок расчёта показателей критериев значимости с учётом специфики телекоммуникационных объектов.

Аналогичные постановления для других отраслей (энергетика, финансы, транспорт, здравоохранение) ожидаются в 2026–2027 годах по мере реализации полномочий Правительства по 58-ФЗ. Субъектам КИИ из этих отраслей стоит отслеживать появление отраслевых актов и закладывать время на ревизию категорирования.

Что именно нужно заменить: ПО, СЗИ, ПАК и управление доступом

Импортозамещение КИИ охватывает три разных класса активов с разными требованиями, сроками и порядком подтверждения соответствия.

Три класса активов и логика их замены

• Российское ПО — программный продукт, включённый в единый реестр российского программного обеспечения Минцифры России. Включение в реестр подтверждает российское происхождение, но не означает автоматического соответствия требованиям безопасности для ЗОКИИ. Для ПО, используемого в качестве СЗИ, дополнительно требуется сертификат ФСТЭК или ФСБ.
• Средства защиты информации (СЗИ) — отдельный класс продуктов: антивирусные средства, межсетевые экраны, системы обнаружения вторжений, средства криптографической защиты, системы управления доступом и аутентификации. Для ЗОКИИ с 01.01.2025 действует запрет использования иностранных СЗИ (Указ № 250). Российское происхождение СЗИ подтверждается реестром Минцифры, а соответствие требованиям безопасности — сертификатом ФСТЭК или ФСБ в зависимости от класса продукта.
• Доверенные программно-аппаратные комплексы (ПАК) — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности. Требования к ПАК для ЗОКИИ устанавливаются Правительством РФ по 58-ФЗ. Базовый ориентир перехода на доверенные ПАК — 01.01.2030. Сроки и порядок перехода на ПАК отличаются от сроков перехода на ПО: их нельзя смешивать при планировании.

Реестр российского ПО: как проверять

Единый реестр российского ПО ведёт Минцифры России. При проверке продукта важно убедиться:

• что продукт включён в реестр и запись актуальна;
• что класс ПО в реестре соответствует функции, для которой оно применяется на ЗОКИИ;
• что для СЗИ дополнительно получен действующий сертификат ФСТЭК или ФСБ;
• что продукт функционально совместим с существующей инфраструктурой объекта.

План действий на 2026 год

В 2026 году компании должны провести ревизию объектов, уточнить категорирование, определить состав иностранного ПО/СЗИ/ПАК, проверить наличие российских аналогов и подготовить согласованный план перехода. Это минимальный набор действий, без которого старт миграции в 2027 году окажется неуправляемым. Ниже — Дорожная карта импортозамещения КИИ:

Этап 1

1. Ревизия объектов КИИ. Сверьте реестр объектов организации с распоряжением Правительства № 360-р (перечень типовых отраслевых объектов КИИ). Проверьте, не появились ли системы, которые теперь подпадают под определение типового отраслевого объекта КИИ, но ранее не были включены в реестр.
2. Актуализация сведений о категорировании. Обновите форму направления сведений во ФСТЭК с учётом Приказа № 247: добавьте наименование типового отраслевого объекта, доменные имена и внешние сетевые адреса. Если категорирование проводилось до 01.09.2025 — проверьте, нужен ли пересмотр категорирования и актуализация сведений во ФСТЭК.
3. Инвентаризация иностранного ПО, СЗИ и ПАК. Составьте полный реестр иностранного программного обеспечения, средств защиты и программно-аппаратных комплексов на каждом ЗОКИИ. Зафиксируйте: вендор, версия, функция, наличие или отсутствие поддержки, наличие российского аналога.
4. Назначение ответственных. Определите должностное лицо, ответственное за организацию перехода. Для федеральных органов власти и госкорпораций это требование закреплено в предложениях Минцифры: ответственный — не ниже заместителя руководителя.

Этап 2

1. Анализ покрытия и матрица аналогов. Для каждой позиции реестра иностранного ПО/СЗИ/ПАК определите российский аналог: проверьте наличие в реестре Минцифры, наличие сертификата ФСТЭК/ФСБ (для СЗИ), функциональную совместимость с инфраструктурой объекта.
2. Оценка рисков миграции. Оцените технические риски для каждого объекта: несовместимость с другими компонентами, деградация производительности, отсутствие функциональных аналогов, зависимость от иностранного оборудования. Для объектов без российского аналога — зафиксируйте основания для возможного продления срока.
3. Запуск пилотов. Проведите пилотное тестирование приоритетных российских решений в среде, максимально приближённой к промышленной.

Этап 3

1. Подготовка и согласование дорожной карты. Сформируйте документированный план перехода: объекты, решения, сроки, ответственные, контрольные точки. Для федеральных органов и госкорпораций — отраслевой план до 01.09.2026 (согласно предложениям Минцифры).
2. Контроль подрядчиков. Опишите права доступа, обязанности и ответственность внешних подрядчиков, участвующих в проекте миграции. Проверьте, используют ли подрядчики иностранные инструменты для удалённого доступа к ЗОКИИ.
3. Подготовка плана отката. Для каждого этапа миграции разработайте план возврата к предыдущему состоянию. Миграция без плана отката — один из главных технических рисков проекта.

Импортозамещение КИИ — это управляемый проект

Переход на российское ПО, СЗИ и ПАК на значимых объектах КИИ — многоэтапная программа, которая требует корректного определения объектов, инвентаризации активов, проверки аналогов и поэтапной миграции с контролем доступа и документированным планом отката.

Компании, которые начнут с ревизии категорирования и аудита иностранного ПО в 2026 году, к дедлайну 2028 года подойдут с готовым планом.

Практический первый шаг — зафиксировать, какое иностранное ПО, СЗИ и ПАК используется на каждом ЗОКИИ, кто имеет к ним доступ и есть ли российские аналоги с необходимыми сертификатами. Результаты этой инвентаризации станут основой дорожной карты и аргументом при взаимодействии с ФСТЭК.

Управление учётными данными подрядчиков и сотрудников — отдельное требование при проверке ФСТЭК. Менеджера паролей и секретов Пассворк сертифицирован ФСТЭК и включён в реестр российского ПО Минцифры. Протестировать можно бесплатно

Часто задаваемые вопросы

Кого касается импортозамещение КИИ в 2026 году?

Требования распространяются на субъекты критической информационной инфраструктуры (КИИ) — организации из 13 отраслей, перечисленных в Федеральном законе № 187-ФЗ: энергетика, здравоохранение, транспорт, финансы, связь, оборонная промышленность и другие. Обязательства касаются тех, кто владеет значимыми объектами КИИ (ЗОКИИ) первой, второй или третьей категории.

До какого срока нужно перейти на российское ПО на значимых объектах КИИ?

Базовый срок — 1 января 2028 года: к этой дате доля российского ПО на ЗОКИИ должна составлять 100%. Для отдельных сценариев Минцифры предложило сроки 1 января 2031 года и 1 января 2036 года. По состоянию на июнь 2026 года эти сроки содержатся в проекте постановления Правительства и не являются окончательно утверждёнными нормами. Рассчитывать на них без документально подтверждённых оснований не следует.

Чем отличается субъект КИИ от значимого объекта КИИ?

Субъект КИИ — организация, которой принадлежат ИС, ИТКС или АСУ ТП в критически важных сферах. Значимый объект КИИ — конкретная система или сеть, которой присвоена категория значимости (первая, вторая или третья) по результатам категорирования. Не вся инфраструктура субъекта автоматически является значимым объектом: статус присваивается только после прохождения процедуры категорирования и направления сведений во ФСТЭК.

Что такое типовые отраслевые объекты КИИ и зачем они нужны?

Типовые отраслевые объекты КИИ — перечни типов ИС, ИТКС и АСУ по отраслям, утверждаемые Правительством РФ на основании 58-ФЗ. Они служат ориентиром для выявления объектов, подлежащих категорированию, и унифицируют подход к субъектам одной отрасли. Первый перечень утверждён распоряжением № 360-р от 26.02.2026. Субъектам КИИ необходимо сверить свой реестр объектов с этим перечнем.

Достаточно ли включения продукта в реестр российского ПО для использования на ЗОКИИ?

Для подтверждения российского происхождения ПО реестр Минцифры необходим. Но для средств защиты информации этого недостаточно: нужен действующий сертификат ФСТЭК или ФСБ в зависимости от класса продукта. Кроме того, нужно проверить функциональную совместимость с инфраструктурой конкретного объекта и соответствие классу защищаемой системы.

Чем доверенный ПАК отличается от российского ПО?

Российское ПО — программный продукт, соответствующий критериям отечественного происхождения и включённый в реестр Минцифры. Доверенный ПАК — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности, которые устанавливает Правительство РФ по 58-ФЗ. Сроки и порядок перехода на ПО и ПАК различаются: проектируемый базовый ориентир для ПАК — 01.01.2030, для ПО — 01.01.2028. Оба срока содержатся в проектируемых актах и подлежат уточнению после их утверждения.

Что нужно сделать субъекту КИИ в 2026 году?

Провести ревизию реестра объектов с учётом типовых отраслевых перечней, актуализировать сведения о категорировании во ФСТЭК, составить реестр иностранного ПО/СЗИ/ПАК, проверить российские аналоги и их совместимость, запустить пилоты, подготовить дорожную карту, назначить ответственного и описать права доступа подрядчиков.

Как связаны импортозамещение и управление доступом?

Импортозамещение меняет состав ПО и СЗИ, но не устраняет угрозы, связанные со слабыми паролями, общими учётными записями и неуправляемым привилегированным доступом. По данным проверок ФСТЭК (2025), при проверке более 700 ЗОКИИ выявлено свыше 1 200 нарушений в части информационной безопасности. Контроль идентификации, аутентификации и прав доступа должен быть частью проекта миграции, а не отдельной задачей.

Можно ли отложить импортозамещение КИИ?

В публикациях о проекте обсуждаются специальные сроки для нескольких сценариев: участие в особо значимых проектах с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. Окончательный перечень условий зависит от утверждённой редакции постановления. Ни один из этих сценариев не действует автоматически.

Какие ошибки чаще всего допускают при импортозамещении КИИ?

Считать срок 2028 года дальним, не актуализировать категорирование после появления типовых перечней, менять решения без проверки сертификатов, проводить пилот только на изолированном стенде, не контролировать доступы подрядчиков, не готовить план отката и не синхронизировать изменения ПО с обновлением документации ФСТЭК.

Первый менеджер паролей с сертификацией ФСТЭК России

30 апреля 2026 года Пассворк получил сертификат ФСТЭК России № 5063 по 4-му уровню доверия — наивысшему для коммерческих средств защиты информации. Пассворк стал первым российским менеджером паролей, который может применяться в ГИС, ИСПДн, КИИ и АСУ ТП 1 класса защищённости.

Блог ПассворкаИлья Шелыгин

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

Блог ПассворкаАнастасия Лебедева

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

Компания Пассворк и российский разработчик высокотехнологичных enterprise-решений Nexign («Нэксайн») подписали официальный сертификат совместимости менеджера паролей Пассворк и СУБД Nexign Nord.

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

Интеграция позволяет развернуть хранилище паролей и журнал аудита в едином защищенном контуре, задействовать корпоративные механизмы резервного копирования, отказоустойчивости и мониторинга, а также обеспечить централизованный контроль доступа к ИТ-инфраструктуре и соответствие требованиям ИБ и регуляторов.

Nexign Nord: СУБД для высоконагруженных систем

Nexign Nord — российская высокопроизводительная СУБД корпоративного класса, разработанная компанией Nexign для высоконагруженных систем с повышенными требованиями к надежности, масштабируемости и стабильности работы.

Решение создано на базе PostgreSQL, содержит доработки для повышения безопасности и совместимости приложений, работающих на Oracle. Дополнительные модули в составе СУБД обеспечивают высокий уровень отказоустойчивости и гибкое администрирование при минимальных затратах на эксплуатацию.

СУБД Nexign Nord обеспечивает импортозамещение Oracle Database, Microsoft SQL Server и предоставляется с технической поддержкой различных уровней. Продукт включён в Единый реестр российского программного обеспечения (реестровая запись №14734) и сертифицирован ФСТЭК России по 4-му уровню доверия.

Пассворк: менеджер паролей и секретов для бизнеса

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

Продукт поддерживает ролевую модель доступа, полный аудит действий, интеграцию со службами каталогов и системами мониторинга безопасности. Пассворк включён в Единый реестр российского программного обеспечения (реестровая запись № 6147) и сертифицирован ФСТЭК России по 4-му уровню доверия.

Подтверждённая совместимость как основа для развития

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

«Сертификат совместимости с Nexign Nord — важный шаг для Пассворка. Nexign входит в число ведущих российских разработчиков enterprise-решений, и подтверждённая совместимость говорит о том, что наш продукт отвечает высоким корпоративным стандартам надёжности и безопасности», — Андрей Пьянков, генеральный директор ООО «Пассворк»

«Совместимость Nexign Nord с Пассворк позволяет повысить безопасность, надежность и отказоустойчивость ИТ-инфраструктуры, расширить возможности пользователей. Для клиентов Пассворка это также означает перспективу миграции на более экономически выгодную СУБД: Nexign Nord позволяет сократить затраты в несколько раз по сравнению с аналогами, сохраняя при этом высокий уровень производительности, надёжности и управляемости», — Максим Нартов, директор по развитию бизнеса Nexign

Компании продолжают сотрудничество для развития интеграционных возможностей и обеспечения максимальной безопасности российской корпоративной ИТ-инфраструктуры.

Пассворк регулярно тестирует совместимость с отечественными ИТ-продуктами и операционными системами. Посмотреть все актуальные сертификаты совместимости можно на этой странице.

О компании Nexign

Nexign — российская компания с 34-летним опытом разработки высокотехнологичных enterprise-решений для различных отраслей экономики. Готовые продукты и решения Nexign обеспечивают быструю ИТ-трансформацию клиентов, чтобы крупный бизнес мог решать задачи в кратчайшие сроки с уверенностью в результате.

О компании Пассворк

Пассворк — российский разработчик в сфере информационной безопасности с 11-летним опытом работы на рынке. Компания имеет действующие лицензии ФСТЭК России на деятельность по технической защите конфиденциальной информации (ТЗКИ) и созданию средств защиты информации (СЗКИ), а также лицензию ФСБ России на работу с криптографическими средствами.

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

Блог ПассворкаАнастасия Лебедева

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

ГОСТ-шифрование для разработчиков: алгоритмы, СКЗИ и интеграция 2026

ГОСТ-стек хорошо специфицирован — сложность в интеграции. Разбираем четыре актуальных стандарта с OID-ами, механику шифрования изнутри, типичные точки отказа в nginx, Docker и браузерах, классы СКЗИ и границы лицензирования ФСБ и ФСТЭК.

Блог ПассворкаИлья Шелыгин

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

Вместо того чтобы придумывать комбинацию самостоятельно (и неосознанно тяготеть к именам, датам и предсказуемым шаблонам) вы получаете готовый случайный пароль за секунду. Именно случайность отличает сгенерированный пароль — алгоритм не знает ни вашего имени, ни любимого года, ни привычки заменять а на @.

Главное

• Длина важнее состава. Надёжный пароль — длинный, случайный и уникальный для каждого сервиса. 16 случайных символов надёжнее, чем 8 с @ в конце.
• Онлайн-генератор безопасен только при локальной генерации. Пароль должен создаваться в браузере и не передаваться на сервер. Случайные сайты без информации о владельце — риск.
• Языковые модели не подходят для генерации паролей. Они предсказывают вероятные последовательности, а не создают криптографически случайные данные.
• Сильный пароль нужно проверять по базам утечек. Он мог быть скомпрометирован раньше, чем вы его придумали.
• Генератор создаёт, менеджер паролей хранит. Без хранилища сгенерированная комбинация окажется в заметках или таблице, что сводит на нет её преимущества.

Что такое генератор паролей

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

Генератор может быть встроен в менеджер паролей, браузер, корпоративную систему управления доступом или работать как отдельный онлайн-инструмент. Разница между этими вариантами принципиальна не только с точки зрения удобства, но и безопасности — об этом подробнее в разделе про онлайн-генераторы.

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

Как работает генератор паролей

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

1. Пользователь задаёт параметры. Длина пароля, типы символов (буквы, цифры, спецсимволы), исключения (например, символы 0, O, l, 1, которые легко перепутать).
2. Генератор обращается к источнику случайности. Надёжные реализации используют CSPRNG (криптографически стойкий генератор псевдослучайных чисел). Он опирается на энтропию операционной системы: случайные события — движение мыши, сетевые пакеты, прерывания процессора. Слабые реализации используют обычный PRNG (генератор псевдослучайных чисел), который инициализируется предсказуемым значением — например, временем запуска.
3. Алгоритм собирает комбинацию. Случайные значения отображаются на допустимые символы из выбранного набора. Если задано условие «обязательное наличие цифр и спецсимволов», алгоритм гарантирует их наличие.
4. Инструмент показывает пароль пользователю. Готовая комбинация отображается на экране. Пользователь может скопировать её или сразу использовать — в зависимости от того, куда встроен генератор.
5. Пользователь сохраняет пароль. Сгенерированный пароль нужно немедленно сохранить в менеджере паролей. Хранение в буфере обмена, заметках или таблицах сводит на нет преимущества сильной комбинации.

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

Какой пароль считается надёжным

Надёжность пароля определяется не только наличием спецсимволов. Символ @ в конце слова не делает пароль сложным — он лишь добавляет предсказуемый паттерн, который атакующие учитывают при словарных атаках.

Три реальных критерия надёжности:

• Длина. Каждый дополнительный символ экспоненциально увеличивает число возможных комбинаций. Пароль из 16 случайных символов перебрать значительно сложнее, чем из 8, даже если оба содержат спецсимволы.
• Случайность. Пароль не должен содержать словарных слов, имён, дат и шаблонов вида P@r0l. Такие комбинации первыми проверяются при атаках подстановкой (credential stuffing) и распылением паролей (password spraying).
• Уникальность. Один пароль — один сервис. Повторное использование превращает утечку одного ресурса в компрометацию всех остальных.

Дополнительный критерий — отсутствие в базах утечек. Даже длинный случайный пароль может оказаться скомпрометированным, если он уже фигурировал в утечках данных. Сервис Have I Been Pwned позволяет проверить пароль по базе известных утечек без передачи самого пароля в открытом виде.

Минимальная рекомендуемая длина для большинства сервисов — 12–16 символов. Для мастер-пароля менеджера паролей или доступа к критичным системам — от 20 символов.

Генератор и проверка надёжности

Введите пароль вручную или нажмите Сгенерировать — инструмент создаст 16-символьную комбинацию с заглавными и строчными буквами, цифрами и спецсимволами. Анализ покажет уровень надёжности, энтропию, состав символов и расчётное время брутфорса такого пароля.

Кнопка Проверить сверяет пароль с базой известных утечек Have I Been Pwned: браузер отправляет только первые пять символов SHA-1-хеша — пароль в открытом виде никуда не передаётся, не сохраняется и не покидает ваш браузер.

Почему нельзя генерировать пароли с помощью ИИ

Языковые модели (LLM) не подходят как инструмент генерации паролей. Причина в природе самих моделей: они обучены предсказывать вероятные последовательности токенов, а не создавать криптографически случайные данные.

Это не теоретическое предположение. В 2025 году Kaspersky провёл тест популярных LLM на качество генерируемых паролей. Результат: 88% паролей DeepSeek, 87% паролей Llama и 33% паролей ChatGPT оказались недостаточно надёжными. В части паролей отсутствовали спецсимволы или цифры, несмотря на явные инструкции их включить.

Проблема структурная: модель воспроизводит паттерны из обучающих данных. Пароли, которые она генерирует, статистически смещены в сторону «типичных» комбинаций — именно тех, которые атакующие проверяют в первую очередь.

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

Где используются генераторы паролей

Генераторы паролей встроены в большинство инструментов, которые так или иначе связаны с управлением учётными данными. Контекст использования определяет требования к реализации: корпоративный сценарий отличается от личного не только масштабом, но и уровнем контроля над тем, где и как хранится результат.

• Менеджеры паролей — основной и наиболее безопасный контекст. Генератор встроен в хранилище: пароль создаётся и сразу сохраняется в зашифрованном виде, не проходя через буфер обмена или заметки.
• Браузеры — Chrome, Firefox, Safari предлагают встроенную генерацию при заполнении форм регистрации. Удобно для личного использования, но в корпоративном сценарии создаёт проблему: пароли хранятся в браузерном хранилище без централизованного контроля и аудита.
• Корпоративные системы управления доступом — PAM-решения (privileged access management) и системы управления идентификацией генерируют пароли для привилегированных учётных записей, сервисных аккаунтов и технических пользователей. Здесь генерация часто автоматизирована и не требует участия человека.
• Онлайн-генераторы — отдельные веб-инструменты без привязки к хранилищу. Подходят для разовых задач при условии, что генерация происходит локально в браузере. Главный риск — неизвестно, логирует ли сервис созданные комбинации.
• Инструменты разработчика и DevOps — CLI-утилиты, скрипты и менеджеры секретов генерируют пароли, токены и ключи API в автоматизированных пайплайнах.

Как безопасно пользоваться генератором паролей

Алгоритм «Безопасное использование генератора паролей» (8 шагов):

1. Выберите доверенный генератор. Встроенный в менеджер паролей, корпоративное решение или инструмент известного вендора с открытым кодом. Избегайте случайных сайтов без информации о владельце.
2. Установите длину от 16 символов и выше. Если сервис ограничивает длину, используйте максимально допустимую. Для критичных систем — от 20 символов.
3. Включите разные категории символов. Строчные и заглавные буквы, цифры, спецсимволы, если сервис поддерживает. Если совместимость ограничена, приоритет — длина, а не состав.
4. Создавайте отдельный пароль для каждого сервиса. Один пароль — один ресурс. Без исключений для «неважных» аккаунтов: именно они чаще всего становятся точкой входа.
5. Сразу сохраняйте пароль в менеджере паролей. Не копируйте в заметки, не отправляйте в мессенджер, не записывайте в таблицу. Менеджер паролей — единственное место хранения.
6. Включайте MFA для критичных учётных записей. Двухфакторная аутентификация (2FA) снижает риск компрометации, даже если пароль утёк.
7. Проверяйте старые пароли через механизмы аудита. Сервис Have I Been Pwned позволяет проверить пароль по базе утечек без передачи его в открытом виде. Корпоративные менеджеры паролей делают это автоматически для всего хранилища.
8. Меняйте пароль после инцидента или подозрения на компрометацию. Плановая смена паролей по расписанию без признаков компрометации — менее приоритетная мера, чем уникальность и длина. Приоритет — реакция на конкретный инцидент или сигнал из базы утечек.

Частые ошибки при создании паролей

Большинство слабых паролей появляются из-за отсутствия удобного инструмента. Когда создать надёжный пароль сложнее, чем написать Qwerty123, люди выбирают простоту.

Пароль создан. Что дальше?

Сгенерированная комбинация из 20 символов не защищает учётную запись, если она хранится в общем чате, используется на двух сервисах одновременно или не подкреплена вторым фактором аутентификации. Генератор решает одну задачу — создать пароль. Хранение, контроль доступа и аудит — отдельные задачи.

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

В Пассворке генерация паролей встроена в единый контур: настраиваемый генератор, зашифрованное хранилище, аудит, 2FA, SSO и интеграции с AD/LDAP. Протестируйте Пассворк бесплатно

Часто задаваемые вопросы

Что такое генератор паролей простыми словами?

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

Для чего нужен генератор паролей?

Генератор решает главную проблему ручного придумывания паролей — предсказуемость. Люди неосознанно используют имена, даты и шаблоны, которые атакующие проверяют в первую очередь. Генератор создаёт уникальную случайную комбинацию для каждого сервиса, снижая риск угадывания, перебора и повторного использования учётных данных.

Как работает генератор паролей?

Генератор получает случайные значения из криптографически стойкого источника (CSPRNG), отображает их на допустимые символы из выбранного набора и собирает комбинацию нужной длины. Надёжные реализации выполняют генерацию на стороне клиента — в браузере или локальном приложении — без передачи результата на сервер.

Безопасно ли использовать онлайн-генератор паролей?

Это зависит от реализации. Безопаснее использовать генератор, который создаёт пароль локально в браузере и не передаёт комбинацию на сервер. Риск возникает при использовании случайных сайтов: такие инструменты могут логировать сгенерированные пароли или собирать технические данные о пользователе.

Чем генератор паролей отличается от менеджера паролей?

Генератор создаёт пароль, а менеджер паролей хранит, заполняет, организует и помогает контролировать пароли. Генератор без хранилища оставляет вопрос «куда сохранить пароль» открытым. В корпоративном сценарии эти функции должны быть объединены: генератор встроен в менеджер паролей.

Что лучше: пароль или парольная фраза?

Для паролей, которые хранит менеджер паролей и подставляет автоматически, оптимальны длинные случайные комбинации символов. Для случаев, где секрет нужно вводить вручную или запоминать (например, мастер-пароль менеджера паролей) удобнее случайная парольная фраза из нескольких слов. Главное условие в обоих случаях — случайность.

Можно ли использовать ИИ для генерации паролей?

Не стоит использовать языковую модель как основной инструмент генерации секретов. По данным Kaspersky (2025), значительная доля паролей, созданных популярными LLM в тесте — 88% у DeepSeek, 87% у Llama и 33% у ChatGPT — оказалась недостаточно надёжной. Языковые модели предсказывают вероятные последовательности, а не создают криптографически случайные данные.

Где хранить сгенерированные пароли?

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

Блог ПассворкаАнастасия Лебедева

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин

ВкусВилл — розничная сеть натуральных продуктов, основанная в 2009 году. Сегодня это порядка 2200 магазинов в 156 городах России, 9,3 млн покупателей и свыше 4200 наименований под собственным брендом. В основе подхода компании — тесная работа с локальными поставщиками, быстрое обновление ассортимента и постоянные эксперименты с форматами. ВкусВилл одним из первых в российском ритейле начал внедрять искусственный интеллект и кассы самообслуживания собственной разработки.

Ключевые ИТ-системы компании развивает и поддерживает команда платформенных решений ТехВилл (ИТ-компания ВкусВилла). Подразделение отвечает за развёртывание и сопровождение внешних и внутренних сервисов, а также развивает онлайн-направление ВкусВилла. В работе команда опирается на современные фреймворки и инженерные практики, чтобы решения оставались производительными, безопасными и готовыми к росту нагрузки.

Задача: сделать доступы управляемыми

С ростом инфраструктуры управление паролями и секретами становилось всё сложнее: количество сервисов, сотрудников и точек доступа росло, а вместе с ним и риски. В ТехВилле решили выстроить централизованную систему хранения и сформулировали конкретные требования:

• интеграция с LDAP с автоматическим отзывом доступов при изменениях в кадрах
• быстрый доступ к данным (в штатном режиме и при инциденте)
• исключение потери паролей и секретов
• обязательное резервное копирование

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

«Нужно было централизовать хранение и обмен паролями и секретами. Самое главное — исключить возможность потери. Утрата каких-то секретов для нас была важна. В Пассворке у нас есть возможность и базу бэкапить, и централизованно всё хранить в защищённом виде», — Евгений Ананьев, инженер в команде платформенных решений ВкусВилла

Выбор: тестирование и аргументы

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

«Решение действительно понравилось: у Пассворка понятный интерфейс и высокая надёжность. Отдельный плюс — это российская система с качественной русификацией. В случае инцидента счёт идёт на минуты, и особенно важно быстро находить нужные доступы — Пассворк хорошо справляется с задачей»

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

Внедрение: защищённый периметр

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

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

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

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

Как устроена работа с Пассворком

Компания использует Пассворк с 2023 года: ТехВилл и ВкусВилл централизованно хранят секреты команд. В карточку каждого секрета и пароля можно добавить ссылку, файлы и комментарии. Учётные записи синхронизируются с корпоративным каталогом автоматически — ручное управление доступом не нужно. Для передачи данных без выдачи постоянного доступа используются одноразовые ссылки.

«Ограниченное количество пользователей имеет доступ к сейфам и отдельным областям внутри них. Сотрудники группируют пароли по тегам для большего удобства поиска, также используют автозаполнение с помощью браузерного расширения. Тем, кто не пользуется Пассворком постоянно, мы выдаём одноразовые ссылки»

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

Результат: безопасность и контроль

Структура и удобство

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

«Мы сейчас не боимся потерять пароль к сервису, который человек когда-то сделал, записал, а потом ушёл из компании. Это очень сильно выручает»

Безопасная командная работа

Пассворк позволяет передавать пароли конкретному пользователю внутри системы — без открытия доступа ко всему сейфу. Одноразовые ссылки решают задачу быстро и точечно: поделиться доступом можно с тем, кому постоянный аккаунт не нужен.

«Пассворк полностью закрывает текущие задачи команды как инструмент хранения и оперативного использования секретов. Удобно, что есть обзорность, сколько у нас паролей, какие, и где конкретно они хранятся»

Надёжность решения

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

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

«Потерянный пароль — это часто потеря данных. Потеря данных в 80% случаев ведёт к исчезновению компании. С Пассворком у нас есть возможность делать бэкапы и централизованно хранить нужные данные в защищённом виде»

ВкусВилл решил задачу централизованного хранения секретов и автоматического управления доступами — без потери данных и ручной работы с правами. Если перед вашей командой стоят похожие вызовы, попробуйте Пассворк: наши специалисты и поддержка помогут с установкой и настройкой. Протестировать можно бесплатно

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

Блог ПассворкаИлья Шелыгин

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева

ГОСТ-шифрование для разработчиков: алгоритмы, СКЗИ и интеграция 2026

ГОСТ-стек хорошо специфицирован — сложность в интеграции. Разбираем четыре актуальных стандарта с OID-ами, механику шифрования изнутри, типичные точки отказа в nginx, Docker и браузерах, классы СКЗИ и границы лицензирования ФСБ и ФСТЭК.

Блог ПассворкаИлья Шелыгин

У ИБ-отдела особый класс секретов: доступы к SIEM, EDR, SOAR, аварийные учётные записи, SSH-ключи критичной инфраструктуры. Их чувствительность определяется не только содержимым, но и тем, что они раскрывают — архитектуру защиты и внутреннюю структуру безопасности.

Хранить такие секреты можно двумя способами:

• Для большинства компаний достаточно логической изоляции: одна инсталляция Пассворка с типами сейфов, ролями, MFA, LDAP/SSO и аудитом. Секреты разделены по назначению и владельцам, доступ разграничен через права и группы.
• Физическая изоляция (отдельный экземпляр Пассворка для ИБ-контура) нужна там, где данные должны быть скрыты от администраторов общего контура не только на уровне прав, но и на уровне самого факта существования: названий сейфов, структуры папок и журналов активности.

Физическая изоляция наиболее полно реализует принцип нулевого доверия (Zero Trust) через разделение полномочий. В этой модели ИТ-администраторы полностью исключаются из цепочки доверия, а управление системой переходит исключительно к ИБ-администраторам.

Логическая изоляция, в свою очередь, опирается на принцип наименьших привилегий внутри единой системы, где ИТ- и ИБ-контуры делят общую платформу.

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

Какие секреты хранит ИБ-отдел и почему их нельзя смешивать с обычными доступами

ИБ-секреты отличаются от доступов кадрового отдела, финансов или проектных команд не только уровнем критичности, но и характером чувствительности. Компрометация пароля от корпоративного SaaS — это инцидент. Компрометация доступа к SIEM или EDR — это потенциальная потеря контроля над всей защитной инфраструктурой.

Важно понимать: чувствительными могут быть не только сами пароли, но и метаданные. Названия сейфов, папок, систем и групп, а также характер активности в журнале — всё это раскрывает внутреннюю архитектуру защиты. Злоумышленник, получивший доступ к структуре ИБ-сейфов, уже знает, какие инструменты используются и как организовано реагирование.

Какие секреты требуют особого режима хранения

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

Один экземпляр Пассворка с типами сейфов: когда этого достаточно

Одна инсталляция Пассворка с правильно спроектированными типами сейфов, ролями, группами, MFA и LDAP/SSO обеспечивает логическую сегментацию данных и подходит большинству компаний. Администраторы платформы входят в доверенный контур, секреты разделены по назначению и владельцам, а журнал действий фиксирует все события.

Одна инсталляция — рациональный стандарт по умолчанию. Она проще в эксплуатации: одно обновление, один процесс резервного копирования, одна интеграция с LDAP/AD и SAML SSO, один регламент. При этом уровень контроля над доступом может быть весьма детальным.

Модель типов сейфов

Типы сейфов в Пассворке — основной инструмент логической сегментации. Это не просто группировка папок: для каждого типа задаются администраторы, права создателя, группы и роли участников, ограничения на создание новых сейфов.

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

Пример настройки политик и прав для типов сейфов

Роли и группы позволяют разграничить доступ подразделений без ручной настройки каждого пользователя. Интеграция с AD/LDAP упрощает добавление новых пользователей и отзыв доступов: сотрудник уходит — доступ отзывается через синхронизацию с каталогом. SAML SSO снижает трение при ежедневной работе. MFA и журнал действий обеспечивают контроль.

Если этих ограничений достаточно, одна инсталляция закрывает задачу. Если нет, следующий шаг — физическая изоляция.

Два независимых экземпляра Пассворка: когда нужна физическая изоляция

Две независимые инсталляции Пассворка оправданы, когда ИБ-секреты должны быть изолированы не только на уровне прав доступа, но и на уровне отдельного экземпляра: с независимыми администраторами, отдельными политиками безопасности, закрытыми метаданными и чистыми журналами только по действиям ИБ-команды.

Два контура дают физическую изоляцию данных — именно то, что нужно, когда требования к безопасности ИБ-контура выходят за рамки логической сегментации. Важно учитывать, что вместе с этим появляются два жизненных цикла, два процесса резервного копирования, два регламента. Это осознанный архитектурный выбор, к которому стоит подойти с чёткими требованиями.

Что даёт физическая изоляция

• Устойчивость к ошибкам. Ошибка в правах доступа в общем корпоративном контуре не раскрывает ИБ-секреты. Контуры физически разделены: некорректная настройка в одном не затрагивает другой.
• Закрытые метаданные. Администраторы общего контура не видят структуру ИБ-сейфов: ни названий, ни папок, ни активности. ИТ-администратор бизнес-экземпляра Пассворка не знает, какие системы и инструменты находятся под управлением ИБ-команды.
• Независимые администраторы. ИБ управляет своим экземпляром самостоятельно без пересечения с ИТ-администраторами общего контура. Каждая команда настраивает свой экземпляр независимо и не имеет прав в чужом контуре.
• Независимые политики. ИБ применяет собственные настройки: более жёсткие требования к MFA, короткий таймаут сессии, запрет офлайн-доступа, ограничения на экспорт, отдельные правила API-доступа — без компромиссов с требованиями бизнес-подразделений.
• Чистый журнал. ИБ-инсталляция фиксирует только события ИБ-команды без фонового шума от финансов, продаж и подрядчиков. Это упрощает расследования и сокращает время на анализ.
• Прозрачность для аудита. Контур проще описывать в документах модели угроз, при прохождении сертификации и внешних аудитов — в том числе по требованиям ФСТЭК и для объектов КИИ. Разделение контуров часто является требованием регулятора.

Когда ИБ-контур требует закрытой сети

Ряд организаций предъявляет требования, которые выходят за рамки настроек доступа: размещение в изолированном сегменте сети без выхода в интернет, запрет на любые входящие соединения извне, доступ только с рабочих станций ИБ-команды.

Это актуально для компаний, где модель угроз предполагает атаку через административный интерфейс, а также для организаций, проходящих аттестацию по требованиям ФСТЭК или работающих с объектами критической информационной инфраструктуры (КИИ). В таких случаях физическая изоляция — не архитектурное предпочтение, а требование регулятора или внутренней политики безопасности.

Пассворк разворачивается на собственных серверах организации, что позволяет разместить ИБ-экземпляр в любом сетевом сегменте, включая полностью закрытый контур без внешних зависимостей.

Сравнение двух моделей

Локальный ИБ-инстанс и облако для бизнеса

Вариант «ИБ локально, сотрудники в облаке» — два независимых инстанса разного типа поставки. Между ними нет общего пространства данных, общих администраторов или синхронизации секретов. Локальный экземпляр обслуживает чувствительные ИБ- и инфраструктурные секреты, облачный — массовые бизнес-доступы, если политика классификации данных разрешает такой контур.

Такое разделение имеет смысл, когда компания хочет снизить эксплуатационную нагрузку на бизнес-команды (облако проще в управлении), сохранив строгий контроль над критичными секретами на собственной инфраструктуре.

Разделение доступов

Облако Пассворка можно рассматривать как отдельный облачный экземпляр для бизнес-команд при условии, что политика классификации данных организации допускает хранение соответствующих категорий секретов в облаке.

Отдельный DevOps/SRE-контур: чем он отличается от ИБ-контура

DevOps-контур изолируется по другим причинам, чем ИБ-контур. ИБ-секреты требуют изоляции из-за конфиденциальности, независимого администрирования и требований к аудиту расследований. DevOps-секреты — из-за автоматизации, высокой частоты ротации, машинного потребления через API, CLI и SDK, а также большого числа интеграций с CI/CD-пайплайнами.

В одном инстансе можно создать тип сейфов «DevOps/CI-CD» и назначить команду разработчиков его администраторами. Отдельная DevOps-инсталляция оправдана при большом объёме машинных секретов, высокой частоте ротации и независимой команде разработки, которая должна управлять своим контуром без зависимости от общих администраторов.

Пассворк поддерживает API-first подход, CLI и SDK для работы с секретами, включая сценарии миграции, аудита и CI/CD-интеграций. Подробнее — в разделе документации «Пассворк как менеджер секретов».

Сравнение сценариев

Как выбрать архитектуру: один или два контура

Выбор архитектуры сводится к вопросу: достаточно ли логической сегментации или данные требуют физической изоляции. Ответ зависит от размера компании, характера секретов, требований к администрированию и регуляторного контекста.

Критерии выбора архитектуры хранения секретов

Если сомнения остаются, начните с одной инсталляции и строгой модели типов сейфов. Заранее задайте триггеры перехода ко второй: рост критичных секретов, запрет на видимость метаданных, независимый аудит, отдельные администраторы, требования регулятора или усложнение DevOps-сценариев.

Как внедрить выбранную модель

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

1. Классифицировать секреты. Разделить данные на категории: обычные, ИБ-критичные, инфраструктурные, DevOps, аварийные. После этого понятно, какие данные требуют какого уровня изоляции.
2. Определить владельцев. Назначить ответственного бизнес- или технического владельца для каждого типа. У каждой категории секретов появляется ответственный.
3. Оценить чувствительность метаданных. Проверить, где опасны даже названия систем, папок и сейфов. Это покажет, где логической изоляции недостаточно.
4. Определить допустимых администраторов. Решить, кто может управлять контуром и кто не должен иметь технической видимости. Результат: понятная модель доверия и границы администрирования.
5. Выбрать модель. Одна инсталляция, две локальные, локальный ИБ-контур плюс облачный бизнес-контур или отдельный контур разработки. Архитектурное решение принято и обосновано.
6. Спроектировать типы сейфов. Создать целевую структуру сейфов, ролей, групп и правил создания. Итог: схема, которую можно реализовать и задокументировать.
7. Настроить интеграции. LDAP/SSO, MFA, API/CLI/SDK, SIEM, резервное копирование и мониторинг. Каждая интеграция получает чёткие границы и ответственного.
8. Ввести регулярную проверку прав. Проверять права, администраторов, журналы и структуру сейфов после изменений в командах и инфраструктуре.

Правильная архитектура начинается с классификации

Число инсталляций — следствие требований к изоляции. Одна инсталляция с продуманной моделью типов сейфов, ролями, LDAP/SSO, MFA и журналом действий закрывает потребности большинства компаний. Две инсталляции нужны там, где физическая изоляция данных, независимые администраторы и отдельный аудит — это обоснованное требование.

Практический первый шаг — провести классификацию секретов: какие данные компания хранит, кто ими владеет, какие метаданные чувствительны и кто допустим как администратор каждого контура. Ответы на эти вопросы определят архитектуру.

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

Если вы проектируете архитектуру хранения секретов и хотите проверить, как выбранная модель работает на практике — протестируйте Пассворк бесплатно в своей инфраструктуре или в облаке и оцените его на реальных задачах. При покупке дополнительных инстансов расширенной версии действует скидка 10%.

Часто задаваемые вопросы

Нужна ли ИБ-отделу отдельная инсталляция Пассворка?

Отдельный инстанс необходим, если ИБ-отдел хранит секреты, которые не должны быть видны администраторам общего контура даже на уровне структуры: доступы к SIEM, EDR, SOAR, сканерам, аварийные доступы, SSH-ключи, API-токены и сервисные пароли. Если таких требований нет, достаточно одной инсталляции с типами сейфов, ролями, MFA и аудитом.

Когда достаточно одной инсталляции Пассворка?

Одной инсталляции достаточно, когда секреты можно разделить логически через типы сейфов, роли, группы, LDAP/SSO и права доступа, а администраторы платформы входят в доверенный контур. Это проще в эксплуатации и подходит большинству подразделений.

Чем физическое разделение лучше настройки прав доступа?

Физическое разделение снижает риск ошибок при распределении прав и скрывает ИБ-данные из общего контура на уровне отдельного экземпляра. Оно необходимо, когда критично защитить не только пароли, но и метаданные: названия сейфов, систем, папок и журналы активности ИБ-команды.

Что такое типы сейфов в Пассворке?

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

Может ли администратор общего инстанса видеть ИБ-сейфы?

Это зависит от модели ролей и прав, настроенных в системе. В Пассворке администратор может видеть список всех сейфов в системе, включая их названия и состав пользователей, если ему выданы полные права. Если сам факт существования ИБ-сейфов, их структура или названия не должны быть видны общему администрированию, нужно перенастроить систему ролей или рассмотреть отдельный ИБ-контур.

Как разделить личные, командные и инфраструктурные пароли?

Начните с классификации секретов, определите владельцев и создайте типы сейфов: личные, командные, ИТ, ИБ, DevOps, проектные и сервисные аккаунты. Для каждого типа задайте администраторов, права, MFA, аудит и даты аудита.

Как организовать аудит действий ИБ-команды?

При работе ИБ в общей инсталляции события фильтруются в общем журнале по ролям, сейфам и типам действий. Если требуется полностью чистый журнал только по ИБ-активности (без фонового шума от бизнес-подразделений), физически выделенный ИБ-контур Пассворка обеспечит изолированное логирование.

Какие секреты нельзя хранить в общих сейфах?

В общих сейфах не стоит хранить аварийные учётные записи, root/admin-доступы, токены EDR/SIEM/SOAR, SSH-ключи критичной инфраструктуры, API-ключи облаков и секреты, раскрытие метаданных которых может навредить безопасности.

Как понять, что компании пора переходить от одной инсталляции к двум?

Триггеры перехода: апрет на видимость ИБ-метаданных ИТ-администраторами, требование независимого аудита ИБ-действий, регуляторные требования (ФСТЭК, КИИ), необходимость применения более жестких политик безопасности (MFA, сессии, экспорт) или выделение изолированного DevOps/SRE-контура.

Пассворк 7.1: типы сейфов

Типы сейфов В Пассворк 7.1 управление доступом стало более гибким благодаря системе типов сейфов. Типы сейфов решают главную проблему администраторов — как контролировать доступ к данным и делегировать управление сейфами в большой компании. Ранее выбор был ограничен двумя типами. Теперь можно создавать собственные типы сейфов под любые задачи и структуру

Блог ПассворкаИлья Шелыгин

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева

Импортозамещение ИБ-решений (СЗИ): переход на российское ПО

Переход на российские решения в сфере защиты информации — юридическая обязанность. В статье: сроки, штрафы, пошаговый план миграции и таблицы отечественных аналогов по всем ключевым классам защитных решений.

Блог ПассворкаАнастасия Лебедева

20 мая 2026 года исследователи из PhishU описали технику, которую назвали VaultJacking. Один перехваченный шестизначный ПИН-код и злоумышленник получает доступ ко всему синхронизированному хранилищу менеджера паролей Google: учётным данным, ключам доступа (passkey), сохранённым паролям от банков, почты, корпоративных систем. Ко всем сразу.

Для бизнеса это означает следующее: если сотрудник хранит рабочие пароли в Google-аккаунте — это готовая потенциальная точка входа в вашу корпоративную инфраструктуру.

Что такое VaultJacking простыми словами

VaultJacking (от англ. vault — хранилище, сейф и jacking/hijacking — угон, захват) — фишинговая техника, при которой злоумышленник перехватывает ПИН-код от менеджера паролей Google и использует его для доступа к синхронизированному хранилищу паролей и ключам доступа (passkeys). Атака реализована исследователями PhishU в формате PoC (proof-of-concept, демонстрация и проверка концепции) — полная цепочка атаки воспроизведена и задокументирована.

Перехватив ПИН во время AiTM-фишинга (атака типа «злоумышленник посередине»), атакующий получает возможность подключить собственное устройство к «домену безопасности» аккаунта Google и расшифровать всё хранилище целиком.

Ключевые факты

• Атака нацелена не на отдельный сайт, а на слой синхронизации Google Password Manager, то есть на всё хранилище сразу.
• Один перехваченный PIN-код открывает доступ ко всем паролям и ключам доступа (passkey, стандарт WebAuthn), сохранённым в аккаунте Google.
• Ключи доступа защищают вход на конкретный сайт, но не закрывают риск компрометации самого хранилища — это разные уровни модели угроз.
• Рабочие пароли в личном браузерном профиле сотрудника — неуправляемый актив: компания не видит их, не контролирует и не может отозвать.
• Меры защиты существуют и применимы без специальных технических знаний.

Принципиальное отличие от классического фишинга — в масштабе: обычный фишинг нацелен на пароль от одного сервиса, VaultJacking — на слой синхронизации, где хранится всё сразу.

Как работает атака на менеджер паролей Google

Чтобы понять, почему VaultJacking работает, нужно разобраться в архитектуре Google Password Manager. Каждый аккаунт Google имеет «домен безопасности» (security domain). Устройства, присоединившиеся к этому домену, получают доступ ко всем синхронизированным паролям и ключам доступа. Ключ к расшифровке хранилища называется Security Domain Secret (SDS) — облачный сервис Google выдаёт его любому устройству, которое корректно прошло процедуру присоединения к домену. Эта процедура требует двух вещей: входа в Google-аккаунт и ввода ПИН-кода от менеджера паролей Google.

Важно понимать масштаб: пакет синхронизации (sync-payload) включает не только пароли, но и приватные байты ключей доступа. Начиная с Chrome 359, они записываются в локальную базу данных SQLite и синхронизируются вместе со всем хранилищем, включая ключи, изначально созданные на аппаратном устройстве. VaultJacking восстанавливает их в том числе.

VaultJacking принципиально отличается от смежной техники Browser Syncjacking — атаки на тот же слой синхронизации через вредоносное расширение браузера, установленное на устройстве жертвы. VaultJacking не требует никакого присутствия на устройстве: ни расширения, ни вредоноса, ни предварительного доступа. Атака полностью реализуется через стандартный AiTM-фишинг.

Цепочка атаки: модель четырёх шагов VaultJacking

VaultJacking реализуется за четыре шага: от фишинговой страницы до полной расшифровки хранилища. Каждый шаг опирается на результат предыдущего: перехваченные куки открывают доступ к ПИН-коду, ПИН-код — к домену безопасности, домен безопасности — ко всем сохранённым секретам сразу.

Шаг 1. Фишинговая страница

Пользователь попадает на поддельную страницу входа в Google, внешне неотличимую от оригинала. AiTM-прокси (прозрачный посредник между жертвой и настоящим сервером Google) работает в режиме реального времени: пользователь видит подлинный интерфейс Google, вводит логин и пароль, проходит многофакторную аутентификацию, и всё это время трафик проходит через инфраструктуру атакующего.

Шаг 2. Перехват ПИН-кода и регистрация скрытого ключа

Сразу после ввода пароля пользователю показывают модальное окно с запросом ПИН-кода от Google Password Manager. Окно стилизовано под стандартный интерфейс Google.

Пока модальное окно активно, поле ввода пароля заблокировано — пользователь не может продолжить, не введя ПИН. Большинство вводят его без подозрений: этот экран знаком по легитимным сценариям Google — настройке нового устройства или восстановлению доступа.

Параллельно атакующий немедленно регистрирует в аккаунте жертвы собственный скрытый ключ доступа (backdoor-passkey). Этот ключ выполняет две функции: обеспечивает долгосрочный доступ к аккаунту даже после смены пароля жертвой и используется на следующем шаге для обхода повторной аутентификации Google.

Шаг 3. Присоединение к домену безопасности

Атакующий использует перехваченные сессионные куки и ПИН-код для присоединения собственного устройства к домену безопасности (security domain) аккаунта Google.

К этому моменту исходные куки могут уже истечь — Google проверяет свежесть сессии при добавлении нового устройства. Атакующий обходит эту проверку с помощью скрытого ключа доступа, зарегистрированного на шаге 2: виртуальный аутентификатор автоматически отвечает на запрос повторной аутентификации (reauth), и Google принимает это как легитимный вход.

После успешной аутентификации атакующий вводит перехваченный ПИН-код — облачный сервис Google выдаёт Security Domain Secret (SDS, секретный ключ домена безопасности). Единственный сигнал для жертвы — письмо на почту «новый вход на Windows», идентичное тому, что Google отправляет при любом новом входе в Chrome. Никаких пуш-уведомлений на мобильные устройства, никаких запросов на других запущенных копиях браузера. Если атакующий перехватил почтовый ящик в ходе той же AiTM-сессии — письмо подавляется прежде, чем пользователь его увидит.

Шаг 4. Расшифровка хранилища

Получив SDS, устройство атакующего расшифровывает всё синхронизированное хранилище целиком: пароли, ключи доступа (passkeys), сохранённые данные форм. Никаких дополнительных запросов к пользователю, никаких ограничений по количеству попыток (rate limit).

Пакет синхронизации (sync-payload) включает приватные байты всех ключей доступа — в том числе тех, что изначально создавались на аппаратных аутентификаторах. Начиная с Chrome 359, эти байты записываются в локальную базу данных SQLite браузера и передаются вместе с остальными данными синхронизации. Аппаратная защита работает на уровне создания ключа, но не на уровне синхронизации хранилища.

Результат: каскадная компрометация

Расшифрованное хранилище — не конечная точка атаки. Злоумышленник получает готовый список учётных данных от всех сервисов, которые жертва когда-либо сохраняла в Google Password Manager. Каждая запись в хранилище — потенциальная точка входа в отдельную систему.

Для бизнеса это означает каскадный эффект: компрометация одного личного профиля последовательно открывает доступ к корпоративным ресурсам, к которым у сотрудника были права. Смена пароля Google-аккаунта останавливает дальнейшую синхронизацию, но не отменяет уже полученный доступ к сторонним сервисам.

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

Почему ПИН может стать проблемой

ПИН-код от аккаунта Google воспринимается большинством пользователей как вспомогательный элемент — что-то вроде кода разблокировки экрана, а не как ключ к хранилищу. Это восприятие расходится с реальной архитектурой системы.

С точки зрения модели безопасности Google, ПИН-код — это единственный короткий секрет, который управляет доступом к Security Domain Secret. Именно он позволяет новому устройству расшифровать всё синхронизированный хранилище. Шесть цифр защищают всё, что пользователь когда-либо сохранил в Google Password Manager.

Проблема усугубляется тремя факторами:

• Доверие к интерфейсу. Пользователи привыкли вводить ПИН в легитимных сценариях Google: при настройке нового устройства или восстановлении доступа. Поддельный запрос ПИН-кода выглядит знакомо.
• Низкая осознанность. ПИН-код не воспринимается как «пароль от всего» — пользователь не понимает, что именно он защищает.
• Синхронизация как множитель ущерба. Чем больше паролей сохранено в менеджере паролей Google, тем выше потенциальный ущерб от компрометации ПИН-кода.

Если ваши сотрудники хранят рабочие пароли в браузерах, VaultJacking — наглядный пример того, чем это заканчивается. Пассворк централизует корпоративные пароли и секреты, разграничивает доступ по ролям и позволяет настроить обязательное использование MFA для всей команды. Протестировать можно бесплатно

Защищают ли ключи доступа от VaultJacking

Ключи доступа (passkey) защищают от VaultJacking лишь частично — и важно понимать, где именно проходит граница этой защиты. Ключи доступа реализованы по стандарту WebAuthn и привязаны к конкретному домену сайта. При входе на легитимный сайт ключ доступа не передаётся на поддельный домен — это одна из ключевых защитных свойств технологии.

Однако VaultJacking атакует другой уровень: не вход на конкретный сайт, а синхронизацию хранилища, где ключи доступа хранятся и управляются. Если атакующий получил доступ к Security Domain Secret, он получает и все синхронизированные ключи.

Вывод: Ключи доступа и VaultJacking существуют на разных уровнях модели угроз. Ключи решают проблему фишинга на уровне входа в конкретный сервис. VaultJacking работает на уровне синхронизации хранилища: там, где ключи доступа уже сохранены и управляются через аккаунт.

Чем VaultJacking опасен для бизнеса

Когда сотрудник хранит в Google Password Manager пароли от корпоративной почты, админок, облачной инфраструктуры, репозиториев или административных панелей — его личный аккаунт в браузере становится точкой входа в корпоративный периметр. Компрометация этого профиля через VaultJacking превращается из личного инцидента в потенциальное нарушение безопасности всей организации.

Российские данные подтверждают масштаб угрозы. По данным Лаборатории Касперского, в 2025 году система «Антифишинг» предотвратила 554 002 207 попыток перехода по фишинговым ссылкам. По данным Yandex B2B Tech, 54% кибератак в 2025 году начинались с использования слитых или скомпрометированных паролей, а в облачных инфраструктурах было зафиксировано 25 тысяч попыток взлома (Anti-Malware.ru, 2025). ГК «Солар» в отчёте Solar JSOC за 2025 год зафиксировала более 1,16 млн событий ИБ и свыше 33 тысяч подтверждённых инцидентов — среди которых кража учётных данных выделена как отдельная подкатегория несанкционированного доступа.

Особую роль здесь играет феномен «теневого ИТ» (Shadow IT) в управлении паролями: сотрудники используют личные браузерные профили для рабочих задач не из злого умысла, а из удобства. У компании при этом нет ни видимости, ни контроля над тем, какие рабочие секреты там хранятся.

Матрица корпоративных рисков браузерного хранилища

Как защититься пользователю

Практический план для тех, кто использует Google Password Manager в личных или рабочих целях.

Превентивные меры

• Проверяйте домен и контекст перед вводом ПИН-кода. Запрос ПИН-кода от менеджера паролей Google на сторонних сайтах — тревожный сигнал.
• Никогда не вводите ПИН на страницах, открытых по ссылке из письма или мессенджера.
• Включите двухфакторную аутентификацию (2FA) для аккаунта Google с аппаратным ключом или приложением-аутентификатором, не по SMS.
• Регулярно проверяйте список устройств в настройках Google-аккаунта: раздел Безопасность → Ваши устройства. Незнакомое устройство — повод немедленно отозвать доступ.
• Включите уведомления о новых входах в аккаунт.

Разграничение личного и рабочего

• Не сохраняйте рабочие пароли в личном браузерном профиле.
• Используйте отдельные профили браузера для личного и рабочего использования.
• Для рабочих учётных данных — только корпоративный менеджер паролей с централизованным управлением и журналом действий.

Что делать, если ПИН уже введён на подозрительном сайте

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

Что должны сделать компании

Обучение сотрудников «не вводить ПИН-код на подозрительных страницах» — необходимая, но недостаточная мера. Человеческий фактор остаётся самым слабым звеном: именно поэтому VaultJacking работает через социальную инженерию, а не через уязвимость в коде. Системный ответ — управлять местом хранения рабочих секретов, а не только поведением сотрудников.

Корпоративная модель защиты от рисков браузерных хранилищ

• Политика хранения рабочих паролей. Запрет хранения рабочих учётных данных в личных браузерных профилях фиксируется в регламенте ИБ.
• Корпоративный менеджер паролей. Рабочие секреты отделяются от личного браузерного профиля и хранятся в управляемой инфраструктуре.
• Ролевая модель доступа. Сотрудник видит только те секреты, которые нужны для работы — принцип минимальных привилегий.
• Журналирование и аудит. ИБ-команда получает полную видимость действий с паролями: кто, когда, что изменил или скопировал.
• Интеграция с AD/LDAP и SSO. Упрощается управление жизненным циклом учётных записей: приём, перевод, увольнение.
• Отзыв доступа при увольнении. Администратор удаляет учётную запись один раз — доступ отзывается из всех хранилищ автоматически.
• Интеграция с SIEM (система управления событиями безопасности). События по паролям становятся частью мониторинга ИБ и коррелируются с другими инцидентами.

Нормативный контекст

Для организаций в регулируемых отраслях хранение рабочих учётных данных в личных браузерных профилях — потенциальное нарушение требований регуляторов.

Статья 19 Федерального закона № 152-ФЗ «О персональных данных» обязывает оператора применять организационные и технические меры защиты. Приказ ФСТЭК России № 21 определяет требования к идентификации и аутентификации, включая управление учётными записями и парольную политику. Инцидент, связанный с компрометацией учётных данных через личный браузерный профиль сотрудника, может квалифицироваться как нарушение обоих документов.

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

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

Браузерный менеджер паролей решает задачу личного удобства: автозаполнение, синхронизация между устройствами, хранение без усилий. Для индивидуального пользователя это разумный выбор. Для корпоративной среды та же простота становится структурной проблемой.

Пассворк — корпоративная альтернатива личным браузерным хранилищам. Браузерное расширение Пассворка работает так же, как встроенный менеджер браузера: автозаполняет логины и пароли на сайтах, предлагает сохранить новые учётные данные — но при этом хранит их в защищённом корпоративном хранилище, а не в личном профиле браузера.

Пассворк поддерживает хранение данных на сервере заказчика, шифрование по AES-256, интеграцию с Active Directory / LDAP, авторизацию через SSO, ролевую модель, журнал действий, интеграцию с SIEM-системами, API и CLI для DevOps-задач.

Итог: управление секретами как ответ на атаки нового поколения

VaultJacking наглядно показывает, как меняется логика атак: цель смещается с отдельных учётных записей на инфраструктуру доверия — синхронизацию, хранилища, слои управления доступом. Один перехваченный ПИН-код ценнее десяти перехваченных паролей от отдельных сайтов.

Для компаний практический вывод однозначен: рабочие секреты не должны находиться там, где у ИБ-команды нет ни видимости, ни контроля. Первый шаг — провести инвентаризацию: где сейчас хранятся корпоративные пароли, сколько сотрудников использует личные браузерные профили для рабочих задач и что произойдёт, если один из этих профилей будет скомпрометирован.

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

Рабочие пароли вашей команды сейчас в браузере — значит, один скомпрометированный ПИН-код открывает всё сразу. Пассворк разворачивается на вашем сервере или в облаке, изолирует корпоративные секреты от личных профилей и даёт ИБ-команде полную видимость. Протестировать можно бесплатно

Часто задаваемые вопросы

Что такое VaultJacking?

VaultJacking — фишинговая техника, при которой злоумышленник перехватывает ПИН-код от Google Password Manager в ходе AiTM-атаки и использует его для присоединения собственного устройства к домену безопасности аккаунта Google. После этого атакующий получает доступ ко всему синхронизированному хранилищу: паролям и ключам доступа.

Правда ли, что можно украсть все пароли из Google Password Manager за одну атаку?

Исследователя продемонстрировали такой сценарий как концепт: при успешной цепочке атаки перехваченный ПИН-код позволяет расшифровать всё синхронизированное хранилище. Массовая эксплуатация этой техники на момент публикации не подтверждена независимыми источниками. Риск реален, но требует успешного проведения AiTM-фишинга и ввода ПИН-кода пользователем.

VaultJacking — это уязвимость Google или фишинговая техника?

VaultJacking — фишинговая техника, эксплуатирующая архитектурное решение Google: добавление нового устройства в домен безопасности требует только ПИН-код, без подтверждения с существующих устройств. Google не публиковал официального заявления об уязвимости. Корректнее описывать это как модель риска, а не как CVE-уязвимость.

Почему ключи доступа (passkey) не решают проблему полностью?

Ключи доступа защищают вход на конкретный сайт: WebAuthn-привязка к домену не позволяет передать учётные данные на поддельный сайт. Однако VaultJacking атакует уровень синхронизации хранилища, где ключи доступа хранятся и управляются. Компрометация Security Domain Secret даёт доступ к самим ключам.

Нужно ли исключить использование менеджера паролей Google?

Для личного использования — нет, но нужно усилить защиту аккаунта: включить 2ФА с аппаратным ключом, регулярно проверять список устройств, не вводить ПИН-код по запросам из писем и ссылок. Для бизнеса важнее другое: запретить хранение рабочих секретов в личных браузерных профилях и перейти на корпоративный менеджер паролей с ролями, аудитом и централизованным управлением.

Что делать, если я ввёл ПИН-код на подозрительном сайте?

Действуйте немедленно: смените пароль Google-аккаунта, проверьте и удалите незнакомые устройства и ключи доступа в настройках безопасности, отзовите активные сессии, смените пароли от критичных сервисов. Если в хранилище были рабочие учётные данные — уведомите ИБ-команду.

Как компания может снизить риск VaultJacking?

Системный ответ — управлять местом хранения рабочих секретов. Конкретные меры: политика запрета хранения рабочих паролей в личных браузерных профилях, корпоративный менеджер паролей с ролевым доступом и аудитом, интеграция с AD/LDAP и SSO, централизованный отзыв доступа при увольнении, интеграция событий с SIEM.

Как Пассворк защищает от VaultJacking?

Пассворк решает задачу, которую VaultJacking делает видимой: рабочие пароли не должны храниться в личных браузерных профилях сотрудников. Пассворк — корпоративный менеджер паролей с хранением данных на сервере компании или в облаке, ролевой моделью, журналом действий, интеграцией с AD/LDAP, SSO и SIEM.

Зачем нужен менеджер паролей для бизнеса, если есть KeePass?

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

Блог ПассворкаИлья Шелыгин

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин

Атака на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

Блог ПассворкаИлья Шелыгин

Для компаний с государственными контрактами, организаций под надзором ФСТЭК и субъектов критической информационной инфраструктуры (КИИ) ГОСТ-криптография — это рабочая необходимость.

Федеральный закон № 149-ФЗ «Об информации», приказы ФСТЭК и требования по импортозамещению последовательно сужают пространство для западных алгоритмов в государственных и критических системах. Это затрагивает ИТ, телекоммуникации, энергетику и финансовый сектор.

Проблема не в самих алгоритмах. ГОСТ-стек хорошо специфицирован и охватывает все необходимые примитивы: шифрование, хеширование, электронную подпись, согласование ключей. Сложность в интеграции: ГОСТ затрагивает весь стек сразу, от TLS-профиля и форматов сертификатов до хранения ключей и клиентских приложений. Большинство неожиданностей возникают не при изучении стандарта, а при столкновении с конкретной реализацией.

Разбираем весь стек: стандарты и OID-ы, механику шифрования, точки отказа при интеграции, нормативные требования с конкретными ссылками.

Главное

• Актуальный ГОСТ-стек — четыре стандарта. «Кузнечик» и «Магма» — шифрование, «Стрибог» — хеширование, ГОСТ Р 34.10-2012 — подпись и согласование ключей, ГОСТ Р 34.13-2015 — режимы работы включая CTR-ACPKM. Всё остальное — устаревшие версии или режимы этих четырёх.
• Асимметричная криптография в ГОСТ данные не шифрует. ГОСТ Р 34.10-2012 формирует подпись и вырабатывает общий ключ по VKO. Шифрование данных — всегда симметричное, «Кузнечиком».
• «Магма» — не для шифрования данных. 64-битный блок создаёт риск атаки SWEET32 при объёме ~32 ГБ на ключ. Область применения — имитовставка и Key Wrap внутри CMS.
• openssl-gost-engine и КриптоПро — для разных задач. openssl-gost-engine не является сертифицированным СКЗИ. Для аттестованных систем и работы с КЭП нужен сертифицированный стек.
• Класс СКЗИ определяет модель угроз, а не администратор. Установить ПО с сертификатом КС2 без выполнения организационных требований этого класса — значит классу не соответствовать.
• Лицензия ФСБ нужна при работе с клиентами. Использовать КриптоПро для внутренних нужд можно без лицензии. Встроить СКЗИ в продукт для клиентов или обслуживать СКЗИ у клиентов — лицензируемая деятельность по ПП РФ № 313.
• ГОСТ затрагивает весь стек. Меняются TLS-профиль, форматы сертификатов, хранение ключей, клиентские приложения. Жизненный цикл КЭП требует отдельных процессов — сертификат действует год.
• Постквантовая миграция потребует переработки крипто-слоя. Российские постквантовые стандарты ожидаются в 2026–2027 годах. Проектируйте крипто-слой с абстракцией над алгоритмом — иначе миграция затронет всю кодовую базу.

Что такое ГОСТ-алгоритмы

ГОСТ-алгоритмы — серия криптографических стандартов, утверждённых Федеральным агентством по техническому регулированию и метрологии (Росстандарт). Каждый стандарт определяет математическую конструкцию алгоритма, параметры и допустимые режимы работы — так, чтобы реализации от разных производителей давали идентичный результат и могли взаимодействовать без потери безопасности.

В отличие от международных стандартов NIST (AES, SHA) и RSA, ГОСТ-алгоритмы построены на независимых математических основаниях и прошли отдельный криптоанализ. Для государственных информационных систем, объектов критической инфраструктуры и организаций под надзором ФСБ и ФСТЭК применение ГОСТ-криптографии является нормативным требованием.

Ключевые отличия от западных стандартов

Как устроены ГОСТ-алгоритмы: четыре стандарта и их OID-ы

OID (Object Identifier) — числовой идентификатор вида 1.2.643.7.1.1.5.2, который криптобиблиотеки и сертификаты используют для обозначения алгоритма. Когда OpenSSL встречает в сертификате незнакомый OID, он не может его обработать — отсюда unknown signature algorithm при вызове openssl verify без ГОСТ-движка. OID-ы нужно знать, когда разбираешь совместимость или отлаживаешь парсинг.

Весь актуальный ГОСТ-стек строится на четырёх стандартах — остальное либо устаревшие версии, либо режимы работы этих четырёх.

ГОСТ Р 34.12-2015: «Кузнечик» и «Магма»

ГОСТ Р 34.12-2015 — национальный стандарт Российской Федерации, устанавливающий алгоритмы двух блочных симметричных шифров: «Кузнечик» с размером блока 128 бит и «Магма» с размером блока 64 бита. Стандарт фиксирует математические конструкции, параметры и допустимые режимы работы, чтобы реализации от разных производителей СКЗИ давали идентичный результат и могли взаимодействовать без потери криптографической стойкости.

Кузнечик (RFC 7801, OID 1.2.643.7.1.1.5.2) — основной шифр для защиты данных. 128-битный блок, 256-битный ключ, SP-сеть (Substitution-Permutation) с 10 раундами.

Архитектура та же, что у AES: нелинейная замена байт плюс линейное перемешивание на каждом раунде. Принципиальное отличие от AES — отсутствие аппаратного ускорения на массовых процессорах. AES-NI встроен в каждый Intel/AMD с 2010 года, для «Кузнечика» аналог есть только в специализированных СКЗИ. На больших объёмах данных разрыв в производительности становится заметным.

Магма (RFC 8891, OID 1.2.643.7.1.1.5.1) — ГГОСТ 28147-89 с зафиксированными таблицами подстановок. 64-битный блок, 256-битный ключ, 32 раунда.

Размер блока определяет границу безопасного применения. При шифровании порядка 2³² блоков одним ключом (~32 ГБ) вероятность того, что два разных блока открытого текста дадут одинаковый шифртекст, становится статистически значимой (парадокс дней рождений и атака «дней рождений»). Наблюдатель, накапливающий зашифрованный трафик, может использовать эти совпадения для восстановления данных (атака SWEET32).

Поэтому «Магма» не шифрует данные. Её область применения — операции с заведомо малыми объёмами: имитовставка (выработка кода аутентификации сообщения, который подтверждает целостность и подлинность данных) и упаковка ключа (Key Wrap, шифрование одного ключа другим) внутри CMS.

ГОСТ Р 34.11-2012 «Стрибог»: хеширование

ГОСТ Р 34.11-2012 «Стрибог» (RFC 6986) — хеш-функция. OID 256-битного варианта — 1.2.643.7.1.1.2.2, 512-битного — 1.2.643.7.1.1.2.3. В 2018 году «Стрибог» вошёл в ISO/IEC 10118-3 — это единственный российский криптографический алгоритм с международной стандартизацией на уровне ISO.

256-битный вариант закрывает большинство задач. 512-битный применяется там, где данные должны оставаться защищёнными через 15–20 лет: долгосрочные архивы, юридически значимые документы.

ГОСТ Р 34.10-2012: электронная подпись и выработка ключа

ГОСТ Р 34.10-2012 (RFC 7091) — алгоритм электронной подписи на эллиптических кривых, используемый во всех российских криптографических профилях. OID 256-битного варианта — 1.2.643.7.1.1.1.1, 512-битного — 1.2.643.7.1.1.1.2.

Алгоритм на эллиптических кривых, используемый во всех российских криптографических профилях. По классу — родственник ECDSA, но с другими параметрами кривых, стандартом и кодированием. Приравнивать их напрямую нельзя.

Ключевое архитектурное отличие от RSA: асимметричная криптография в российской модели данные не шифрует. Она решает две задачи — формирование подписи и выработка общего ключа по протоколу VKO (Выработка Ключа Общего). VKO — российский аналог Diffie-Hellman: обе стороны обмениваются открытыми частями и независимо вычисляют один и тот же секрет, не передавая его по каналу. Шифрование данных всегда симметричное — «Кузнечиком».

CTR-ACPKM: механизм без западного аналога

ГОСТ Р 34.13-2015 вводит режим CTR-ACPKM (OID 1.2.643.7.1.1.4.2 для «Кузнечика», 1.2.643.7.1.1.4.3 для «Магмы»). Он решает проблему, которую стандартный CTR не решает.

CTR шифрует последовательный счётчик и накладывает результат на данные по XOR. Чем дольше работает один ключ, тем больше статистики накапливает наблюдатель — и тем выше риск атаки. ACPKM (Acyclic Pseudo-random Key Modification) периодически перегенерирует внутренние раундовые ключи прямо в процессе шифрования. Для прикладного кода это невидимо: ключ в API не меняется, поведение интерфейса не меняется. Меняется только внутреннее состояние шифра.

Прямого аналога в западных стандартах нет. Конкретные лимиты данных на ключ и обязательность ACPKM определяет профиль протокола: PKCS#5/PBES2 — RFC 9337, TLS 1.2 — RFC 9189, TLS 1.3 — RFC 9367.

Как работает ГОСТ-шифрование изнутри

ГОСТ использует гибридную схему. Стороны вырабатывают общий симметричный ключ по открытому каналу через протокол VKO — российский аналог Diffie-Hellman на эллиптических кривых. Данные шифруются этим симметричным ключом («Кузнечиком»), но не напрямую: сначала симметричный ключ упаковывается в отдельный зашифрованный контейнер — Key Wrap. Получатель сначала распаковывает ключ, затем расшифровывает данные.

Всё это происходит внутри формата CMS (Cryptographic Message Syntax) — стандартной ASN.1-структуры для зашифрованных и подписанных сообщений (RFC 5652). CMS — это то, что СКЗИ фактически передаёт при шифровании файлов и почты: не просто шифртекст, а контейнер, в котором упакованы зашифрованный ключ, параметры алгоритма и сами данные.

Схема шифрования в формате ГОСТ

Отправитель:

1. Генерирует эфемерную пару ключей (ec_ephemeral_priv, ec_ephemeral_pub). «Эфемерная» — одноразовая: создаётся для одного сообщения и уничтожается после использования. При реальном уничтожении это даёт прямую секретность (forward secrecy): если завтра утечёт основной ключ, вчерашние сообщения расшифровать не получится.
2. Генерирует случайный CEK (Content Encryption Key, 256 бит) — симметричный ключ для шифрования данных.
3. Генерирует UKM (User Keying Material, 8 байт) — случайная соль, которая делает каждое соединение уникальным даже при одинаковых ключах.
4. Вырабатывает общий секрет по протоколу VKO: Z = VKO(ec_ephemeral_priv, recipient_pub_key, UKM). Обе стороны независимо вычисляют одну и ту же точку на эллиптической кривой, не передавая секрет по каналу.
5. Выводит ключ шифрования ключа через KDF: KEK = HKDF-Стрибог(Z, UKM, ...) KDF (функция выработки ключа) превращает сырой общий секрет Z в ключ нужной длины. KEK (Key Encryption Key) используется для шифрования CEK.
6. Упаковывает CEK: WrappedCEK = Магма-CBC-MAC(CEK) + Магма-ECB(CEK) на KEK CEK шифруется на KEK алгоритмом «Магма» с добавлением имитовставки для контроля целостности.
7. Шифрует данные: CipherText = Кузнечик-CTR(CEK, IV, plaintext)
8. Формирует и отправляет CMS EnvelopedData: {ec_ephemeral_pub, UKM, WrappedCEK, IV, CipherText}
9. ec_ephemeral_priv уничтожается.

Получатель:

1. Вычисляет тот же общий секрет: Z = VKO(recipient_priv_key, ec_ephemeral_pub, UKM)
2. Выводит тот же KEK через KDF.
3. Распаковывает CEK (Key Unwrap): проверяет имитовставку, расшифровывает CEK на KEK.
4. Расшифровывает данные на CEK.

Три момента, которые часто упускают

• VKO — это не просто ECDH. В стандартном ECDH стороны перемножают ключи. В VKO дополнительно учитываются UKM и идентификатор алгоритма — это влияет на итоговый общий секрет. КриптоПро и ViPNet исторически интерпретировали некоторые детали по-разному, отсюда проблемы совместимости при межсистемном взаимодействии.
• Key Wrap через «Магму» обязателен по стандарту — даже если основные данные шифруются «Кузнечиком». Старый ГОСТ Key Wrap описан в RFC 4357; для сценариев с PBES2/PBKDF2 — RFC 9337.
• UKM должен быть настоящим случайным материалом из ГПСЧ СКЗИ (аппаратный или программный генератор псевдослучайных чисел, сертифицированный ФСБ). Детерминированное значение или нули в UKM — схема формально работает, но теряет часть защитных свойств.

openssl-gost-engine: что работает, что нет

Для разработки и несертифицированных сценариев подходит openssl-gost-engine. Но здесь есть контекст, который обычно упускают в инструкциях.

ENGINE API устарел

OpenSSL поддерживает два способа подключить сторонние алгоритмы:

• Engine API — динамически загружаемый .so-файл, регистрирующий реализации через устаревший внутренний интерфейс
• Provider API — более изолированная архитектура, представленная в OpenSSL 3.0

OpenSSL 3.0 пометил Engine API как deprecated. gost-engine по-прежнему использует именно его — миграция на Provider API идёт (issue #496), но неспешно. В OpenSSL 4.0 ENGINE API уберут. Пока работает, но это нужно учитывать при планировании.

Поддержка по дистрибутивам

Сборка (Debian 12 / Ubuntu 24.04)

# CMake >= 3.18 обязателен для OpenSSL 3.x
sudo apt install cmake libssl-dev git

git clone https://github.com/gost-engine/engine gost-engine
cd gost-engine
git submodule update --init
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build . --config Release
sudo cmake --install .

Путь к .so непредсказуем — всегда проверяйте:

find /usr /lib /usr/local -name "gost.so" 2>/dev/null

Настройка openssl.cnf

Добавьте в начало файла:

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/gost.so
default_algorithms = ALL

CRYPT_PARAMS, встречающийся в старых инструкциях — устаревший параметр для ГОСТ 28147-89, сейчас не нужен.

# Проверка что движок живой
openssl engine -t gost

# Актуальные имена cipher suites (они менялись между версиями движка)
openssl ciphers | tr ':' '\n' | grep -i gost
# GOST2012-KUZNYECHIK-KUZNYECHIKOMAC, GOST2012-MAGMA-MAGMAOMAC, ...

Ключи и подпись

# paramset:A — параметры эллиптической кривой (конкретная кривая из стандарта).
# ГОСТ определяет несколько предопределённых наборов (A, B, C и ещё несколько),
# paramset:A — стандартный выбор для большинства задач.
openssl genpkey -algorithm gost2012_256 \
  -pkeyopt paramset:A \
  -out gost_private.pem

# Самоподписанный сертификат для тестов
openssl req -x509 -newkey gost2012_256 \
  -pkeyopt paramset:A \
  -nodes -keyout key.pem -out cert.pem \
  -md_gost12_256 \
  -subj "/C=RU/CN=test"

# Подпись и проверка
openssl dgst -md_gost12_256 -sign gost_private.pem \
  -out signature.bin document.pdf

openssl dgst -md_gost12_256 -verify gost_public.pem \
  -signature signature.bin document.pdf

Python: PyGOST

from pygost.gost3412_2015 import GOST3412Grasshopper
from pygost.gost34112012 import GOST34112012256

h = GOST34112012256(b"hello, gost")
print(h.hexdigest())

key = bytes(range(32))
cipher = GOST3412Grasshopper(key)
encrypted = cipher.encrypt(bytes(16))

API менялся между версиями 6.x и 7.x — проверяйте документацию при обновлении.

КриптоПро и сертифицированный стек

Когда нужна сертификация ФСБ — openssl-gost-engine не подходит. Нужны коммерческие средства криптографической защиты информации (СКЗИ): сертифицированные криптобиблиотеки и HSM-устройства.

КриптоПро CSP 5.0 — стандарт. Под Windows работает через CryptoAPI, под Linux — через собственный демон cprocspd. Есть версии для Astra Linux, Альт, РЕД ОС.

Конфигурация OpenSSL для КриптоПро:

[openssl_init]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /opt/cprocsp/lib/amd64/cp_gost.so
default_algorithms = ALL

Хранение ключей

Ключи хранятся в /var/opt/cprocsp/keys/<username>/. Ключевой контейнер — это директория из шести файлов, а не один файл:

container_name.000/
├── header.key
├── masks.key
├── masks2.key
├── name.key
├── primary.key
└── primary2.key

ViPNet CSP — альтернатива от ИнфоТеКС. На уровне PKCS#11 и CryptoAPI совместим с КриптоПро, но детали VKO реализованы немного иначе. При межсистемном взаимодействии (КриптоПро на одной стороне, ViPNet на другой) — проверяйте матрицу совместимости на tc26.ru перед выбором архитектуры. Там публикуются протоколы испытаний. Известен случай, когда Континент TLS Client 2 не распознавал КриптоПро CSP 5 как провайдера.

Где ломается интеграция

nginx и ГОСТ TLS

Долгое время ГОСТ-криптография в TLS была ограничена версией 1.2: RFC 9189 определяет наборы шифров (cipher suites) и механизмы согласования ключей именно для этого протокола. В 2022 году вышел RFC 9367, распространивший поддержку ГОСТ на TLS 1.3.

На практике разрыв между стандартом и реализацией остаётся значительным. Большинство сертифицированных СКЗИ по состоянию на 2026 год работают с TLS 1.2 — фактическая поддержка TLS 1.3 зависит от конкретного стека, версии криптобиблиотеки и браузера. Актуальный статус уточняйте у поставщика СКЗИ.

КриптоПро CSP 5.0 R2 поставляет патченный nginx (cpnginx):

ssl_certificate     /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;

ssl_protocols TLSv1.2;
ssl_ciphers GOST2012-KUZNYECHIK-KUZNYECHIKOMAC:GOST2012-MAGMA-MAGMAOMAC:LEGACY-GOST2012-GOST8912-GOST8912;
ssl_prefer_server_ciphers on;

Проблема с кешем сессий. Общий кеш TLS-сессий между воркерами не работает. Каждый воркер держит свой кеш — при балансировке между ними происходит полный handshake. Директива ssl_session_cache shared:SSL:10m; работает не так, как ожидается. Решения: включить ssl_session_tickets on; или вынести TLS-терминацию на выделенный шлюз (NGate, С-Терра, Континент TLS).

Второй вариант — поставить ГОСТ-шлюз перед обычным nginx. Он терминирует ГОСТ TLS, дальше идёт обычный HTTPS. Заодно решает проблему с session cache и убирает из nginx зависимость от СКЗИ.

Браузеры

Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам нужен Яндекс Браузер или Chromium-GOST — open-source форк, есть Linux-сборки.

Важно разделять две разные задачи: ГОСТ TLS (защита соединения) и подпись документов в браузере. Для второго нужно расширение КриптоПро ЭЦП Browser Plugin — отдельный компонент, никак не связанный с TLS.

Docker

КриптоПро в контейнере требует конкретных флагов, без которых cprocspd не стартует:

docker run -d \
  --privileged \
  --security-opt seccomp=unconfined \
  --tmpfs /run \
  --tmpfs /run/lock \
  -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  my-cryptopro-image

--tmpfs /run и --tmpfs /run/lock обязательны — без них cprocspd не создаёт lock-файлы. Ключи монтируются через volume:

volumes:
  - /var/opt/cprocsp/keys:/var/opt/cprocsp/keys:ro

Лицензия привязана к физическому хосту, а не к контейнеру. Пересоздание контейнера повторной активации не требует — смена хоста требует. Тестовая лицензия активируется автоматически на 3 месяца.

Если сертификация не нужна, проще использовать openssl-gost-engine в контейнере — без лицензионных ограничений. В репозитории gost-engine есть готовые Dockerfile для Debian и Alpine.

Сертификаты

ГОСТ-сертификаты формально являются X.509, но без ГОСТ-движка их не прочитать:

Signature Algorithm: GOST R 34.11-2012 with GOST R 34.10-2012 (256 bit)
  OID: 1.2.643.7.1.1.3.2
Public Key Algorithm: GOST R 34.10-2012 (256 bit)
  OID: 1.2.643.7.1.1.1.1
  Parameters: GOST R 34.10-2012 256-bit ParamSet A
    OID: 1.2.643.7.1.2.1.1.1

openssl verify без движка выдаст unknown signature algorithm. Это ошибка среды, не сертификата.

Классы СКЗИ: КС1, КС2, КС3

ФСБ устанавливает шесть классов защиты СКЗИ — КС1, КС2, КС3, КВ1, КВ2, КА1. Шкала идёт от минимальных программных требований до защиты от атак спецслужб с физическим доступом к оборудованию. Для большинства коммерческих задач актуальны первые три.

Требуемый класс определяется моделью угроз — документом, который составляется при аттестации системы и описывает актуальные векторы атак. Именно модель угроз диктует минимально допустимый класс СКЗИ, а не выбор администратора.

КЭП и форматы подписей

Квалифицированная электронная подпись (КЭП) по Федеральному закону № 63-ФЗ «Об электронной подписи» — строго регламентированная конструкция: алгоритм ГОСТ Р 34.10-2012, сертифицированное СКЗИ, сертификат от аккредитованного удостоверяющего центра (УЦ). С 2022 года КЭП юридических лиц выдаёт УЦ ФНС России.

Форматы подписей:

• CAdES (Advanced Electronic Signatures поверх CMS) — основной стандарт для государственных систем, СМЭВ, ФНС и большинства регуляторных интеграций.
• XAdES — то же самое для XML-документов.
• PAdES — подпись встраивается непосредственно в PDF-файл, без отдельного файла подписи.

Реализовывать эти форматы с нуля не нужно — существуют готовые решения. КриптоПро PDF и Office Signature закрывают задачи подписания документов. КриптоПро CAdES BES/T используется для интеграции со СМЭВ. КриптоПро DSS обеспечивает серверную подпись через REST API — актуально для систем, где подписание происходит на стороне сервера без участия пользователя.

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

Постквантовый горизонт

ГОСТ Р 34.10-2012 уязвим к алгоритму Шора — как RSA и ECDSA. Квантовый компьютер достаточной мощности появится не раньше 2030–2035 годов по оптимистичным оценкам. Однако уже сейчас актуальна стратегия «harvest now, decrypt later»: противник перехватывает и сохраняет зашифрованный трафик сегодня, чтобы расшифровать его после появления нужных вычислительных мощностей. Для данных с горизонтом конфиденциальности 15+ лет это риск, который требует проработки уже на этапе проектирования.

Симметричные алгоритмы устойчивее. Алгоритм Гровера снижает стойкость симметричных шифров вдвое по экспоненте: 256-битный ключ «Кузнечика» деградирует до ~128-битной эффективной стойкости — уровня, который по-прежнему считается достаточным.

В российском контуре постквантовую стандартизацию ведёт технический комитет ТК 26. Компания «Криптонит» опубликовала реализацию постквантовой схемы «Шиповник» на основе кодовой криптографии. Выход российских стандартов ожидается в 2026–2027 годах.

Практический вывод для архитектора: проектируйте криптографический слой с абстракцией над алгоритмом. Захардкоженный вызов VKO с конкретными параметрами кривой в нескольких местах кодовой базы превращает будущую миграцию на постквантовые алгоритмы в болезненный рефакторинг.

Что ломается первым: пять системных проблем

1. ГОСТ затрагивает весь стек, а не один компонент. Хранение ключей, форматы сертификатов, TLS-профиль, форматы подписей, клиентские приложения, reverse proxy — всё это меняется. Большинство систем мониторинга не понимают ГОСТ TLS и просто не видят соединения.
2. интетические бенчмарки вводят в заблуждение. Реальная производительность складывается из TLS handshake + десериализация CMS + VKO + Key Unwrap + расшифровка. На бенчмарке вы измеряете только расшифровку.
3. Жизненный цикл ключей остаётся без внимания. Сертификат КЭП действует год. У ключевых носителей тоже есть срок. Нужны процессы: кто инициирует перевыпуск, кто едет в УЦ, как обновляется в системе, что происходит в переходный период.
4. openssl-gost-engine берут там, где нужна сертификация. Он технически корректен, но не является сертифицированным СКЗИ — это разные требования, и их нельзя смешивать.
5. Придумывают собственную схему поверх стандарта. «Мы берём Кузнечик, но упаковку ключей сделали по-своему» — ломает безопасность (нестандартные схемы не проходили криптоанализ), совместимость и юридическую легитимность.

Лицензии ФСБ и ФСТЭК

Граница лицензирования неочевидна — не потому что её прячут, а потому что она действительно нетривиальна.

Основной документ — Постановление Правительства РФ № 313 от 16.04.2012 (редакция от 28.08.2023). В приложении — 28 видов лицензируемой деятельности: разработка СКЗИ, производство, распространение, монтаж и настройка на объектах клиентов, техническое обслуживание для третьих лиц, услуги в области шифрования.

ПП № 313 прямо исключает из лицензирования техническое обслуживание СКЗИ для обеспечения собственных нужд юридического лица. Использовать КриптоПро для собственного ЭДО, VPN между офисами, внутреннего инструмента — можно без лицензии. Как только вы начинаете делать это для клиентов — устанавливать, настраивать, обслуживать, продавать встроенную защищённую систему — нужна лицензия.

Если вы разрабатываете приложение, интегрируете в него КриптоПро CSP через API и передаёте это приложение клиентам — вы распространяете «защищённую с использованием шифровальных средств информационную систему» по смыслу п. 2 Постановления Правительства № 313. Это требует лицензии ФСБ на разработку и распространение СКЗИ — даже если само СКЗИ клиент приобретает напрямую у КриптоПро.

Разграничение регуляторов

ФСБ регулирует криптографию: шифрование, электронную подпись, управление ключами. ФСТЭК — техническую защиту информации без криптографии: межсетевые экраны, контроль доступа, DLP, аттестацию информационных систем.

Два основных вида лицензий ФСТЭК:

• ТЗКИ — для организаций, оказывающих услуги по аттестации и монтажу средств защиты информации.
• СЗКИ — для разработчиков средств защиты информации (СЗИ) без криптографии. Если вы планируете получить сертификат ФСТЭК на собственный продукт, лицензия СЗКИ нужна как условие подачи заявки.

Требования к получению обеих лицензий:

• не менее 3 штатных сотрудников с профильным образованием в области информационной безопасности;
• аттестованное помещение;
• аттестованные автоматизированные рабочие места (АРМ) разработчиков;
• выездная проверка ФСТЭК.

Ответственность

• Ст. 13.13 КоАП («Незаконная деятельность в области защиты информации»): граждане — 500–1 000 руб., должностные лица — 4 000–5 000 руб., юрлица — 30 000–40 000 руб. с возможной конфискацией средств защиты информации. Суммы по ч. 1 выглядят небольшими, но конфискация СКЗИ и оборудования означает остановку деятельности.
• Ст. 14.1 КоАП: ч. 2 (деятельность без лицензии) — штраф для юрлиц 40 000–50 000 руб.; ч. 3 (грубое нарушение лицензионных требований при наличии лицензии) — штраф до 200 000 руб. или административное приостановление деятельности до 90 суток.
• Ст. 171 УК наступает при совокупности условий: предпринимательская деятельность без лицензии и либо причинение крупного ущерба (от 2 250 000 руб.), либо извлечение дохода в крупном размере (от 2 250 000 руб.). Ч. 1 — штраф до 300 000 руб. или арест до 6 месяцев. Ч. 2 (организованная группа или особо крупный размер — от 9 000 000 руб.) — до 5 лет лишения свободы.

Заключение

Корпоративные системы в российском правовом поле сталкиваются с ГОСТ-криптографией на каждом уровне стека: выбор СКЗИ, модель угроз, жизненный цикл ключей, лицензионные требования, совместимость компонентов. Большинство проблем возникают из-за архитектурных решений, принятых до того, как стало понятно, что именно потребует регулятор.

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

Пассворк включён в реестр отечественного ПО, сертифицирован ФСТЭК России и имеет лицензии ФСТЭК (ТЗКИ и СЗКИ) и ФСБ на работу с криптографией. Разворачивается на серверах организации или в облаке, поддерживает ролевое управление доступом и ведёт журнал аудита всех операций. Протестировать можно бесплатно

Часто задаваемые вопросы

Чем openssl-gost-engine отличается от КриптоПро CSP?

openssl-gost-engine — открытая реализация ГОСТ-алгоритмов для OpenSSL, подходящая для разработки и тестирования. КриптоПро CSP — коммерческое СКЗИ с сертификатом ФСБ. Для систем, требующих аттестации или работы с квалифицированной электронной подписью, openssl-gost-engine не подходит: наличие корректной реализации алгоритма и наличие сертификата — разные требования.

Почему «Магму» нельзя использовать для шифрования больших объёмов данных?

64-битный блок «Магмы» создаёт birthday bound: при шифровании ~32 ГБ одним ключом вероятность коллизии двух блоков становится статистически значимой. Это основа атаки SWEET32. «Магма» предназначена для операций с заведомо малыми объёмами — имитовставки и Key Wrap внутри CMS. Для шифрования данных используется «Кузнечик» с 128-битным блоком.

Нужна ли лицензия ФСБ, если КриптоПро встроен в продукт для клиентов?

Да. Встраивая СКЗИ в продукт и передавая его клиентам, вы распространяете «защищённую с использованием шифровальных средств информационную систему» по смыслу п. 2 Постановления Правительства РФ № 313 от 16.04.2012. Лицензия требуется даже если клиент приобретает СКЗИ у КриптоПро напрямую — факт встраивания и распространения уже образует лицензируемую деятельность.

Как правильно перенести ключевой контейнер КриптоПро?

Ключевой контейнер КриптоПро — это директория из шести файлов (header.key, masks.key, masks2.key, name.key, primary.key, primary2.key), а не один файл. При переносе копируется вся директория целиком из /var/opt/cprocsp/keys/<username>/. Перенос отдельных файлов не работает — контейнер станет нечитаемым.

Что такое forward secrecy в контексте ГОСТ CMS и зачем уничтожать эфемерный ключ?

При шифровании в формате ГОСТ CMS отправитель генерирует одноразовую эфемерную пару ключей для каждого сообщения и уничтожает приватную часть после отправки. Если в будущем утечёт основной ключ, расшифровать прошлые сообщения не получится — эфемерного ключа уже не существует. Forward secrecy работает только при условии, что реализация действительно уничтожает ключ, а не сохраняет его в памяти или логах.

Что изменится при переходе на постквантовые стандарты?

ГОСТ Р 34.10-2012 уязвим к алгоритму Шора — как RSA и ECDSA. Российские постквантовые стандарты ожидаются в 2026–2027 годах. «Кузнечик» с 256-битным ключом под алгоритмом Гровера деградирует до ~128-битной стойкости — этого по-прежнему достаточно. Главный практический вывод: проектируйте крипто-слой с абстракцией над алгоритмом — захардкоженные вызовы VKO с конкретными параметрами кривой превратят миграцию в болезненный рефакторинг всей кодовой базы.

Как работает ГОСТ TLS и какие браузеры его поддерживают?

ГОСТ TLS 1.2 стандартизирован в RFC 9189, TLS 1.3 — в RFC 9367 (2022). На практике большинство сертифицированных СКЗИ в 2026 году работают с TLS 1.2. Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам подходят Яндекс Браузер или Chromium-GOST. Подпись документов в браузере — отдельная задача, требующая КриптоПро ЭЦП Browser Plugin, не связанного с TLS.

Чем ТЗКИ отличается от СЗКИ и когда нужна каждая лицензия ФСТЭК?

ТЗКИ (техническая защита конфиденциальной информации) — лицензия для организаций, оказывающих услуги по аттестации и монтажу средств защиты информации у клиентов. СЗКИ (средства защиты конфиденциальной информации) — лицензия для разработчиков СЗИ без криптографии; она обязательна как условие подачи заявки на сертификацию собственного продукта во ФСТЭК. Обе лицензии требуют минимум трёх штатных сотрудников с профильным образованием, аттестованного помещения и прохождения выездной проверки.

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

Блог ПассворкаИлья Шелыгин

Постквантовая криптография: угрозы и стандарты — 2026

Квантовые компьютеры ещё не взломали ни одного шифра, но атаки уже идут. Разбираем HNDL-угрозу, глобальные дедлайны регуляторов, российские алгоритмы-кандидаты и первые промышленные пилоты QKD в России.

Блог ПассворкаИлья Шелыгин

Nexign: как Пассворк упростил управление паролями

Введение АО «Нэксайн» (Nexign) — российская компания с 33-летним опытом разработки высокотехнологичных enterprise-решений для различных отраслей экономики. Готовые продукты и решения Nexign обеспечивают быструю ИТ-трансформацию клиентов, чтобы крупный бизнес мог решать задачи в кратчайшие сроки с уверенностью в результате. В портфеле компании более 150 успешно выполненных проектов в 12 странах мира.

Блог ПассворкаАнастасия Лебедева