DevOps

28,65 миллиона секретов утекли в публичные репозитории GitHub за один год. API-ключи, токены доступа, пароли к базам данных — всё в открытом доступе. Рост на 34% год к году, но это лишь видимая часть проблемы.

64% секретов, обнаруженных в 2022 году, всё ещё действуют в 2026-м — спустя четыре года после утечки. Каждый день в публичные репозитории попадает 78 000 новых учётных данных. Большинство останутся действующими годами. Некоторые уже используются атакующими прямо сейчас.

GitGuardian просканировали 1,94 миллиарда коммитов и зафиксировал критическую закономерность: утечки растут быстрее числа участников/разработчиков (+152% против +98% с 2021 года), а новые векторы (ИИ-ассистенты, MCP-конфигурации, внутренние репозитории) генерируют уязвимости со скоростью, которую команды не успевают обрабатывать. Обнаружение перестало работать как мера защиты.

В этом материале — полный разбор отчёта The State of Secrets Sprawl 2026, статистика по типам утечек, реальные кейсы атак и пошаговая стратегия защиты.

Главное

• 28,65 млн новых утечек секретов за год — рост на 34%. Утечки растут быстрее числа разработчиков: +152% против +98% с 2021 года. 64% секретов 2022 года всё ещё действуют в 2026-м — спустя четыре года.
• ИИ-инструменты ускоряют утечки в 5 раз. Утечки секретов ИИ-сервисов выросли на 81,5%. Коммиты с участием Claude Code содержали секреты в два раза чаще обычных (3,2% против 1,5%).
• 24 000 секретов в конфигурациях протокола контекста модели (MCP) — новый вектор утечек. 8,8% действующие. Большая часть официальных гайдов нормализует хардкод секретов в конфигурациях.
• Внутренние репозитории — в 6 раз опаснее публичных. 32,2% внутренних репозиториев содержат секреты против 5,6% публичных. Приватность — не мера защиты.
• 28% утечек происходят вне кода — в Slack, Jira, Confluence. Они на 13% чаще критические (56,7% против 43,7%). Сканирование только репозиториев покрывает ~72% поверхности атаки.
• 80 000 секретов в открытых экземплярах GitLab и Docker, 10 000 действующих. Частота утечек из собственной инфраструктуры в 3–4 раза выше, чем из публичного GitHub.
• Рабочие станции — хранилища секретов. На 6 943 скомпрометированных машинах найдено 33 185 уникальных секретов. Каждый действующий секрет копируется в среднем 8 раз.
• 46% критических секретов пропускаются при подходе «проверяем только то, что можем проверить». Универсальные секреты (пароли, ключи, токены) составляют 35% критических инцидентов, но игнорируются из-за невозможности автопроверки.
• Устранение отстаёт от обнаружения. Секреты остаются действующими годами, потому что ротация — комплексный процесс, который большинство организаций не автоматизировали.

Что такое расползание секретов и почему это критично

Расползание секретов (распространение секретов, secrets sprawl) — неконтролируемое распространение учётных данных (секретов) в кодовой базе, конфигурационных файлах, чатах и других системах организации.

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

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

Масштаб проблемы: в 2025 году GitGuardian обнаружил 28,65 миллиона новых секретов в публичных коммитах GitHub — это утечки за один год, а не накопленный итог. С 2021 года объём вырос с 11 до 29 миллионов, увеличившись в 2,6 раза за пять лет. При этом число активных разработчиков за тот же период выросло лишь вдвое — утечки опережают рост экосистемы на 30%.

Секреты в публичных коммитах GitHub (2021–2025)

Критичность распространения секретов определяется тремя факторами:

1. Скорость роста опережает рост числа участников. С 2021 года утечки секретов выросли на 152%, в то время как число разработчиков увеличилось на 98%. Проблема усугубляется непропорционально.
2. Секреты остаются рабочими годами. 64% секретов, обнаруженных и подтверждённых как валидные в 2022 году, всё ещё не отозваны в 2026-м — спустя четыре года после утечки.
3. Каждый секрет — потенциальная точка входа. Один утёкший API-ключ может предоставить доступ к продуктовой базе данных, CI/CD или облачной инфраструктуре. Для атакующего достаточно одного рабочего секрета.

Главные цифры 2025 года: масштаб проблемы

Данные отчёта GitGuardian за 2025 год показывают устойчивый рост по всем ключевым метрикам:

Рост числа утечек (+33,9%) опережает рост числа разработчиков (+33,2%), но существенно отстаёт от роста объёма кода (+42,7%). Это указывает на то, что объём кода — главный драйвер утечек, а не просто увеличение числа людей, пишущих код.

С 2019 года число активных участников на GitHub утроилось (с 7,6 млн до 22,8 млн), а объём публичных коммитов вырос почти в четыре раза (с 514 млн до 1,94 млрд). При этом количество обнаруженных секретов росло ещё быстрее: с 2021 по 2025 год утечки увеличились на 152%, в то время как активность — на 98%.

Как ИИ ускоряет утечки секретов

2025 год стал переломным для индустрии: ИИ-инструменты для разработки перешли из категории экспериментов в повседневную практику. По данным GitHub Octoverse 2025, 80% новичков начинают использовать GitHub Copilot (ИИ-ассистент для написания кода) в первую же неделю. Это изменило не только скорость написания кода, но и природу утечек секретов.

ИИ-стек как новая поверхность атаки

По данным GitGuardian 1,275 миллиона секретов, связанных с ИИ-сервисами, было обнаружено в 2025 году — рост на 81,5% по сравнению с 2024-м. Это самый быстрорастущий сегмент среди всех типов утечек.

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

Критическая закономерность: инфраструктура вокруг больших языковых моделей LLM (системы контекстного поиска, управление запросами, векторные базы данных, мониторинг) «течёт» в пять раз быстрее, чем ключи от самих моделей (OpenAI, Anthropic, Google AI).

Это объясняется архитектурой современных ИИ-приложений. Одна интеграция с LLM быстро превращается в сеть из десятков сервисов:

• Интерфейсы поиска (Retrieval APIs) для подачи контекста моделям (Brave Search +1 255%, Firecrawl +796%, Perplexity +657%)
• Оркестрация для многошаговых ИИ-процессов (LangChain +108%)
• Мониторинг и эксперименты (Weights & Biases +114%)
• Векторизация и поиск (Jina +334%)
• Базы данных для хранения векторов и состояний (Supabase +992%)

Каждый слой добавляет новые учётные данные. Каждый API-ключ — новый вектор утечки.

Пример: Supabase, популярная база данных для ИИ-проектов, показала рост утечек на 992% год к году и вошла в топ-20 самых «текущих» сервисов с 248 600+ обнаруженными секретами. В 2024 году рост составлял 97% — в 2025-м он ускорился в десять раз.

Claude Code: кейс-стади ИИ-ассистента

Anthropic Claude Code — ИИ-ассистент, который может не только предлагать код, но и напрямую создавать коммиты с атрибуцией через механизм «Co-Authored-By». Это позволило GitGuardian впервые точно измерить влияние конкретного ИИ-инструмента на утечки секретов.

Ключевые данные:

• Рост использования: с 22 коммитов в январе 2025 до 2,16 миллиона в декабре (×98 000)
• Доля в общем объёме: 0,4% всех публичных коммитов
• Доля в утечках: 0,9% всех обнаруженных секретов
• Частота утечек: коммиты с участием Claude Code содержали секрет в 3,2% случаев против 1,5% для обычных коммитов — в два раза чаще

Динамика в течение года: первая половина 2025 года показала наиболее выраженный всплеск. В августе частота утечек достигла пика — 31 секрет на 1 000 коммитов, что в 2,4 раза выше базового уровня. После выхода Claude Sonnet 4.5 в конце сентября показатель начал снижаться и к декабрю достиг 13 секретов на 1 000 коммитов — практически сравнявшись с уровнем обычной разработки.

Это указывает на значительные улучшения в поведении модели или в процессе разработки, который производит коммиты с участием Claude Code.

Размер коммитов: с апреля 2025 года коммиты, созданные с помощью Claude Code, в среднем содержали в два раза больше строк кода, чем обычные коммиты. Большие коммиты означают больше возможностей для утечки секретов в одном review и одном merge. К концу года разница сгладилась, что также указывает на улучшение работы модели.

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

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

MCP-конфигурации: 24 000 секретов в первый год

В начале 2025 года Model Context Protocol (MCP) стал де-факто стандартом интеграции LLM с корпоративными системами. MCP — открытый протокол для подключения больших языковых моделей к внешним инструментам, базам данных и API. По мере того как сторонние сервисы спешили предоставить доступ через этот новый канал, конфигурационные файлы MCP быстро превратились в точку высокой концентрации захардкоженных секретов.

Масштаб проблемы:

• 24 008 уникальных секретов обнаружено в MCP-конфигурациях за 2025 год
• 2 117 из них (8,8%) оставались действующими на момент обнаружения
• Пик утечек пришёлся на август 2025 — 4 209 секретов за месяц

Топ-5 типов валидных секретов в MCP-конфигурациях:

Официальные гайды — часть проблемы: документация популярных MCP-серверов часто нормализует размещение учётных данных непосредственно в конфигурационных файлах. Примеры из руководств по быстрому старту показывают API-ключи, передаваемые как аргументы командной строки внутри конфигурации MCP-сервера (например, --figma-api-key=YOUR-KEY), или хранящиеся в поле env внутри того же JSON-файла, который попадает в систему контроля версий.

Примеры с PostgreSQL включают полные строки подключения вида postgresql://username:password@... под ключом DATABASE_URI. Когда официальная документация трактует захардкоженные секреты как стандартный подход, их бесконтрольное распространение неизбежно.

Риски MCP-секретов:

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

Лучшие практики для MCP-конфигураций:

• Никогда не храните секреты в конфигурационных файлах MCP. Используйте переменные окружения, управляемые через выделенный менеджер секретов, а не встроенные значения в JSON или аргументах командной строки.
• Клиенты, а не серверы, должны владеть секретами. MCP-серверы должны запрашивать учётные данные у клиентов во время выполнения, а не встраивать их в серверную конфигурацию.
• Исключите конфигурационные файлы из системы контроля версий. Добавьте директории с конфигурацией MCP в .gitignore и трактуйте их как конфиденциальные артефакты.
• Используйте MCP-серверы только по защищённым каналам. Убедитесь, что удалённые серверы доступны через TLS.
• Сканируйте перед отправкой в репозиторий. Инструменты вроде ggshield могут обнаруживать секреты в конфигурациях MCP до того, как они попадут в систему контроля версий.
• Обязательное участие человека для критичных действий. Требуйте ручного подтверждения перед любым действием MCP, затрагивающим производственные системы, базы данных или конвейеры развёртывания.

Внутренние системы: слепая зона безопасности

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

Внутренние репозитории: в 6 раз больше утечек, чем в публичных

32,2% внутренних репозиториев содержат хотя бы один захардкоженный секрет против 5,6% публичных.

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

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

Что хранится во внутренних репозиториях

Внутренние репозитории, как правило, содержат самые критичные учётные данные:

• CI/CD-токены для интеграций и развёртывания
• Ключи облачных платформ с широкими привилегиями
• Учётные данные баз данных для продуктовых сред
• Токены внутренних инструментов для мониторинга, журналирования, управления секретами

Это именно те активы, на которые рассчитывают атакующие после получения первоначальной точки входа.

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

Утечки за пределами кода: Slack, Jira, Confluence

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

28% инцидентов в 2025 году произошли полностью вне кода, в том, что GitGuardian называет «Other Data Sources» (другие источники данных, ODS). Большинство инцидентов (68%) по-прежнему приходится на код в системах контроля версий (таких как Git). Однако пересечение секретов, найденных и в системах контроля версий, и в других источниках данных, удивительно мало: всего 4%.

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

Сканирование только кода упустит значимую часть утечек. Секреты из других источников данных (ODS) опаснее: секреты, переданные через Slack, Jira, Confluence и подобные инструменты, чаще получают рейтинг критической или высокой опасности по сравнению с секретами, найденными только в коде.

Распределение по уровню опасности (2025):

Секреты из ODS на 13 процентных пунктов чаще классифицируются как критические (56,7% против 43,7%).

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

GitLab и Docker: 80 000 секретов в открытом доступе

Исследование GitGuardian в 2025 году выявило, что тысячи развёрнутых на собственной инфраструктуре экземпляров GitLab и реестров Docker оставались доступными в интернете без надлежащей аутентификации. Эти непреднамеренно публично открытые ресурсы были проанализированы на предмет секретов, что привело к обнаружению 80 000 учётных данных. 10 000 из них оказались действующими — то есть немедленно пригодными для использования злоумышленниками.

Распределение:

GitLab-репозитории содержали больший общий объём секретов (57 000), но меньший процент валидных (12%). Напротив, Docker-образы содержали меньше секретов в абсолютных числах (23 000), но 15% из них оказались рабочими.

Находки в Docker особенно тревожны, поскольку, в отличие от экземпляров GitLab, образы Docker предназначены для распространения и обычно передаются между множеством кластеров и узлов, что усиливает опасность.

Близость к продуктовой среде = выше вероятность действующего секрета

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

Примеры по типам секретов:

Разрыв особенно широк для секретов систем контроля версий: 40% действующих в контейнерах Docker против всего 2% в GitLab — и для учётных данных хранилищ данных: 32% против 4% соответственно.

Эффект вложенной экспозиции

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

Дополнительные находки

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

• Ссылки на внутренние узлы баз данных и закрытые инфраструктурные шаблоны
• Уведомления о конфиденциальности и защите персональных данных внутри кода
• Значительный объём персональных данных, включая более 300 000 адресов электронной почты, из которых 2 000 имели государственные домены (.gov)

Частота утечек

GitGuardian обнаружили секреты в 12% просканированных GitLab-репозиториев и 18% просканированных Docker-образов. Эти проценты отражают уровень экспозиции на уровне отдельных активов внутри уже обнаруженных экземпляров GitLab и реестров Docker, развёрнутых на собственной инфраструктуре.

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

При объединении с другими находками это показывает, что частота утечек из Docker и GitLab, развёрнутых на собственной инфраструктуре, в 3–4 раза выше по сравнению с публичными хранилищами GitHub. Это означает: захардкоженные секреты в закрытых ресурсах — это недооценённый риск безопасности для слишком многих команд.

64% секретов 2022 года до сих пор действуют

Каждый год GitGuardian анализирует новые данные об утечках, но также повторно проверяет предыдущие находки, чтобы выявить закономерности во времени. В отчёте State of Secrets Sprawl 2025 было показано, что почти 70% учётных данных, подтверждённых как действующие в 2022 году, всё ещё оставались действующими по состоянию на январь 2025 года.

Когда тот же датасет был повторно протестирован в январе 2026 года, уровень валидности остался выше 64%. Это означает, что эти секреты могли быть использованы любым, кто их обнаружит, на протяжении четырёх лет.

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

Почему секреты не ротируются

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

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

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

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

Инфраструктура разработки: новый вектор

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

Кейс Shai-Hulud: атака через компрометацию npm-пакетов

В августе 2025 года злоумышленники внедрили вредоносный код в популярные npm-пакеты. Код выполнялся автоматически при установке и систематически сканировал машины разработчиков:

• Собирал файлы окружения (.env, .bashrc, .zshrc)
• Извлекал конфигурационные файлы приложений
• Сканировал кэши сред разработки и результаты сборок
• Отправлял найденные секреты на управляющий сервер

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

Статистика компрометации

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

Распределение секретов

• 44% скомпрометированных машин содержали более 10 секретов
• 5% машин несли более 100 секретов

Типы обнаруженных учётных данных

Токены GitHub доминировали в проверенном наборе:

• 581 персональный токен доступа
• 386 токен OAuth
• 104 детализированный токен доступа
• 101 токен GitLab

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

CI/CD-агенты как точка концентрации риска

59% скомпрометированных машин оказались CI/CD-агентами, а не личными рабочими станциями. Это означает, что атака затронула не только индивидуальных разработчиков, но и общую инфраструктуру сборки — узлы с повышенными привилегиями и доступом к продуктовым средам.

Реальная плотность секретов выше

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

Что делать: от обнаружения секретов к управлению

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

Данные показывают, что разрыв расширяется:

• Коммиты, созданные совместно с Claude Code, утекают в два раза чаще базового уровня
• Утечки инфраструктуры больших языковых моделей растут в пять раз быстрее, чем у основных поставщиков
• Только конфигурации протокола контекста модели обнажили более 24 000 секретов в первый год

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

1. Какие секреты существуют в вашей среде?
2. Кто ими владеет?
3. К чему они имеют доступ?

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

Путь от распространения секретов к контролю:

1. Централизовать хранение секретов. Единый источник правды. Исключить «самодельные» хранения. Когда команды могут надёжно извлекать секреты из одного источника, они перестают изобретать собственные фрагментированные стратегии хранения — основной драйвер распространения секретов.
2. Автоматизировать ротацию. Сократить окно эксплуатации. Если секрет должен существовать, он не должен жить вечно. Регулярная замена действующих секретов сокращает окно атаки и заставляет команды трактовать учётные данные как актив с жизненным циклом, а не как разовую настройку.
3. Сделать безопасный путь удобнее захардкоженных ключей. Устранить файлы окружения и скопированные токены. Разработчики будут продолжать встраивать секреты в код, потому что это работает и позволяет выпустить функциональность. Единственный устойчивый подход — сделать создание, хранение и вызов действующих секретов проще и привлекательнее, чем захардкодить ключи.
4. Сканировать на рабочей станции (до коммита). Инструменты вроде ggshield и расширения для сред разработки не допускают секрет до репозитория. Раннее сканирование предотвращает инциденты. Современные инструменты помогают командам остановить утечку до того, как секрет попадёт в репозиторий навсегда.
5. Распространить мониторинг за пределы кода. Slack, Jira, Confluence, реестры Docker. 28% инцидентов происходят вне кода, и они на 13% чаще критические. Сканирование только репозиториев покрывает ~72% поверхности.
6. Внедрить приоритизацию на основе рисков. Обогащение контекстом и оценка рисков вместо подхода «только проверка». 46% критических секретов пропускаются при подходе «только проверка». Необходимо понимать, что каждый секрет разблокирует, оценивать привилегии и область действия, обрабатывать длинный хвост и приоритизировать на основе фактического влияния на бизнес.

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

Ключевые выводы

2025 год стал переломным для разработки ПО. ИИ-ассистенты превратили разработку из узкопрофессионального занятия в массовую практику менее чем за 12 месяцев. Стек инструментов ИИ с десятками новых сервисов и токенов стал нормой. Это привело к рекордному числу утечек секретов — 28,65 миллиона на одном только публичном GitHub, рост на 34% год к году.

Пять главных выводов

1. ИИ ускоряет расползание секретов. Рост утечек секретов ИИ на 81,5%, коммиты Claude Code с удвоенной частотой утечек, более 24 000 секретов в конфигурациях — всё это симптомы одной проблемы: команды создают новые токены, ключи и учётные записи сервисов быстрее, чем успевают выстроить процессы управления ими. Модели улучшаются, но ответственность за безопасность остаётся на разработчике и организационных процессах.
2. Внутренние системы — главная зона риска. Внутренние репозитории в шесть раз чаще содержат секреты, чем публичные. 28% инцидентов происходят вне кода и они на 13% чаще критические. Собственные экземпляры GitLab и Docker показывают частоту утечек в 3–4 раза выше, чем публичный GitHub. Приватность — не мера защиты.
3. Устранение отстаёт от обнаружения. 64% секретов 2022 года всё ещё действуют в 2026-м. Обнаружение бесполезно без замкнутого цикла отзыва и ротации. Секреты встроены в системы сборки, переменные непрерывной интеграции, контейнеры. Их ротация — комплексный процесс, который большинство организаций не автоматизировали.
4. Подход «только проверка» — ложная безопасность. 46% критических секретов пропускаются при подходе «только проверка». Универсальные секреты (пароли, приватные ключи, пользовательские токены) составляют 35% критических инцидентов, но массово игнорируются. Необходим переход к приоритизации на основе рисков: обогащение контекстом, оценка рисков и полное покрытие.
5. Переход к управлению машинными идентичностями — стратегическая необходимость. Цель — не только находить утёкшие строки, но непрерывно доказывать, какие машинные идентичности существуют, кто ими владеет и к чему они имеют доступ. Это начинается с централизации секретов, автоматизации ротации, улучшения опыта разработчиков.

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

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

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

Что такое захардкоженные секреты и почему они опасны?

Захардкоженные секреты — это учётные данные (API-ключи, токены, пароли, приватные ключи), встроенные непосредственно в исходный код или конфигурационные файлы. Когда такой код попадает в систему контроля версий, секрет становится частью истории репозитория навсегда — даже после удаления из текущей версии. Один утёкший секрет может открыть доступ к продуктовой базе данных, облачной инфраструктуре или CI/CD.

Почему утечки секретов растут быстрее числа разработчиков?

С 2021 года утечки секретов выросли на 152%, в то время как число разработчиков увеличилось на 98%. Главный драйвер — рост объёма кода (+42,7% за год) и количества интегрируемых сервисов. ИИ-инструменты ускоряют разработку, но каждый новый сервис требует новых токенов и ключей. Команды создают учётные данные быстрее, чем успевают выстроить процессы управления ими.

Как ИИ-ассистенты влияют на утечки секретов?

Коммиты с участием Claude Code содержали секреты в 3,2% случаев против 1,5% для обычных коммитов — в два раза чаще. Утечки секретов ИИ-сервисов выросли на 81,5% за год. Инфраструктура вокруг больших языковых моделей (системы поиска, векторные базы, оркестрация) «течёт» в пять раз быстрее, чем ключи от самих моделей. Проблема не в моделях, а в скорости создания новых интеграций без зрелых практик безопасности.

Почему внутренние репозитории опаснее публичных?

32,2% внутренних репозиториев содержат захардкоженные секреты против 5,6% публичных — в шесть раз больше. Команды менее осторожны внутри закрытого периметра, предполагая, что приватность защищает. Но внутренние репозитории содержат самые критичные учётные данные: CI/CD-токены, ключи облачных платформ с широкими привилегиями, доступы к базам данных. Один утёкший секрет становится быстрым путём для горизонтального перемещения по инфраструктуре.

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

64% секретов, обнаруженных в 2022 году, всё ещё действуют в 2026-м — спустя четыре года. Ротация — не одна кнопка, а комплексный процесс: секреты встроены в системы сборки, скопированы в несколько хранилищ, запечены в образы контейнеров, указаны в переменных непрерывной интеграции, распределены между командами. Большинство организаций не автоматизировали этот процесс. Обнаружение бесполезно без замкнутого цикла отзыва и ротации.

Что такое подход «только проверка» и почему он не работает?

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

Где ещё утекают секреты, кроме кода?

28% инцидентов в 2025 году произошли вне кода — в Slack, Jira, Confluence. Секреты из этих источников на 13% чаще получают рейтинг критической опасности (56,7% против 43,7% для кода). Учётные данные передаются в чатах во время срочного устранения неполадок или реагирования на инциденты. Сканирование только репозиториев покрывает ~72% поверхности атаки — четверть уязвимостей остаётся невидимой.

Что такое управление машинными идентичностями (NHI)?

Машинные идентичности (Non-Human Identities, NHI) — это любые механизмы аутентификации для автоматических систем: API-токены, ключи доступа, учётные записи сервисов, сертификаты. С развитием ИИ-разработки их количество взрывообразно растёт. Управление NHI означает непрерывно доказывать, какие машинные идентичности существуют, кто ими владеет и к чему они имеют доступ. Это начинается с централизации секретов, автоматизации ротации и постепенного перехода к краткосрочным учётным данным на основе идентичности.

Как защитить конфигурации протокола контекста модели (MCP)?

За 2025 год в MCP-конфигурациях обнаружено 24 008 секретов, 8,8% действующих. Лучшие практики: никогда не храните секреты в конфигурационных файлах — используйте переменные окружения через менеджер секретов; клиенты, а не серверы, должны владеть секретами; исключите конфигурационные файлы из системы контроля версий; сканируйте перед отправкой в репозиторий; требуйте ручного подтверждения перед действиями MCP, затрагивающими продуктовые системы.

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

Первый шаг — централизовать хранение секретов в едином защищённом хранилище. Это исключает «самодельные» стратегии хранения — основной драйвер распространения секретов. Затем: автоматизируйте ротацию критичных учётных данных; внедрите сканирование на рабочих станциях до коммита; распространите мониторинг на Slack, Jira, Confluence, Docker-реестры; перейдите от подхода «только проверка» к приоритизации на основе рисков; начните миграцию на аутентификацию на основе идентичности для машинных идентичностей.

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

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

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

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

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

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

Главные киберугрозы апреля 2026: базовые ошибки и миллионы потерь

Взлом Vercel на $2 млн через AI-ассистента, утечка данных Vimeo и Rockstar Games через скомпрометированного подрядчика Anodot, фишинг с официального домена Apple — рассмотрим механику атак через цепочку поставок и покажем, как базовые ошибки в управлении доступом приводят к критическим инцидентам.

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

Новая версия Python-коннектора 0.1.5 расширяет возможности CLI-утилиты. Мы добавили команды, которые решают ключевые задачи DevOps-инженеров и разработчиков — безопасное получение и обновление секретов в автоматизированных пайплайнах.

Почему это важно

Секреты, API-ключи, токены и пароли баз данных нельзя хранить в коде — это риск утечки. Ручное обновление замедляет процессы и провоцирует ошибки. Новые команды get и update в passwork-cli полностью автоматизируют управление секретами. Пассворк становится единым источником истины (SSOT): секреты не попадают в небезопасные места, жизненный цикл полностью автоматизирован.

Как работают команды:

• get — получает данные из Пассворка
• update — обновляет данные в Пассворке

Get: получение данных из записи

Команда get извлекает значение любого поля из записи и подходит для скриптов автоматизации.

Получение конкретного поля

Используйте флаг --field для извлечения логина, URL или значения из любого пользовательского поля.

# Получаем токен для доступа к API из пользовательского поля 'API_TOKEN'
export API_TOKEN=$(passwork-cli get --password-id "..." --field API_TOKEN)

Генерация TOTP-кодов

Если в Пассворке хранятся секреты для двухфакторной аутентификации, passwork-cli генерирует актуальный код прямо в терминале. Используйте флаг --totp-code.

# Получаем TOTP-код для подключения к VPN
VPN_TOTP=$(passwork-cli get --password-id "..." --totp-code "VPN_SECRET")

Update: обновление секретов

Команда update изменяет данные в Пассворке и автоматизирует ротацию секретов.

Обновление пользовательских полей

Флаг --custom-<field_name> обновляет значения в пользовательских полях.

# Обновляем API-ключ в записи
passwork-cli update --password-id "..." --custom-API_KEY "new-generated-key"

Массовое обновление

Теперь можно изменять несколько полей одной командой.

# Одновременно обновляем пароль и теги
passwork-cli update \
  --password-id "..." \
  --password "NewComplexP@ssw0rd" \
  --tags "production,rotated,automated"

Поддержка клиентского шифрования

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

Полезные ссылки

• Документация по get
• Документация по update
• Python-коннектор (GitVerse)
• Примеры использования (GitVerse)

Читайте также

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

Что такое управление секретами Управление секретами (secrets management) — это процесс централизованного хранения, управления и ротации конфиденциальных данных, которые приложения и сервисы используют для доступа к критически важным ресурсам. К таким секретам относятся пароли, SSH-ключи, API-ключи и ключи шифрования, токены доступа, сертификаты и любые другие параметры, обеспечивающие безопасность вашей инфраструктуры. Почему

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

Пассворк и HashiCorp Vault: сравнение решений

Сравниваем подходы и сценарии использования Пассворка и HashiCorp Vault: архитектуру, функции и интеграцию с DevOps.

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

Обновление Пассворк 7.2

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

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

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

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

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

Пассворк: позиционирование и принципы

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

С релизом 7-й версии Пассворк эволюционировал из менеджера паролей в полноценную систему управления секретами и значительно расширил возможности. Основа этой трансформации — открытый REST API и набор нативных DevOps-инструментов.

Теперь это не только платформа для безопасного хранения паролей, но и полноценная система управления секретами:

1. Менеджер паролей — удобный пользовательский интерфейс для безопасного хранения и совместного использования учётных данных внутри команды. Быстрый старт без необходимости обучения.
2. Система управления секретами — программный доступ для разработчиков и администраторов через REST API, Python-коннектор, CLI и Docker-образ. Автоматизация ротации секретов, интеграция с CI/CD, управление доступом на уровне приложений.

Пассворк объединяет все секреты (пароли, API-ключи, сертификаты) в единой экосистеме. Внедрение занимает минимум времени благодаря готовым инструментам и интуитивно понятному интерфейсу.

API-first архитектура

Пассворк построен по принципу API-first: каждая функция интерфейса доступна программно через REST API. Это фундамент для глубокой интеграции с ИТ-инфраструктурой.

Более 300 API-эндпоинтов — полнофункциональное управление паролями, пользователями, сейфами, группами, ролями и системными настройками.

Готовые инструменты для разработчиков:

• Python-коннектор — нативная интеграция с приложениями на Python
• Passwork CLI — управление секретами из терминала и shell-скриптов
• Docker-образ — встраивание в контейнеризованные окружения и CI/CD-пайплайны

Принцип Zero knowledge в действии

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

1. Мастер-ключ формируется из мастер-пароля через алгоритм PBKDF2 с
   использованием случайной соли и большого числа итераций (защита от
   атак перебором).
2. RSA-ключи пользователя (RSA-2048): Для каждого пользователя
   генерируется уникальная пара асимметричных ключей. Закрытый ключ
   шифруется мастер-ключом и хранится на сервере только в зашифрованном виде.
3. Многоуровневая иерархия: Каждая запись пароля шифруется
   собственным AES-256-ключом, который в свою очередь шифруется ключом сейфа, а ключ сейфа — RSA-ключами пользователей с доступом.

Что это означает на практике

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

Преимущества

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

• Быстрое внедрение. Развёртывание и интеграция занимают дни, а не месяцы. Готовые инструменты, документация, техподдержка на всех этапах и интуитивно понятный интерфейс.
• Прозрачное ценообразование. Пассворк предлагает простую и предсказуемую модель лицензирования. Фиксированная стоимость за пользователя без скрытых платежей за API-вызовы, хранилища или дополнительные модули.
• Единое решение. Пароли сотрудников, SSH-ключи, API-токены, сертификаты, конфигурации — всё в одной системе.
• DevOps-ready из коробки. Мощный CLI, Python-коннектор и Docker-образы позволяют быстро интегрировать Пассворк в CI/CD-процессы и автоматизировать рутинные задачи.
• Оперативная техподдержка. Профессиональная русскоязычная техническая поддержка на всех этапах — от внедрения до эксплуатации. Быстрые ответы, понятные решения, без языкового барьера.

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

HashiCorp Vault

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

• Ценообразование. Hashicorp Vault не публикует открытый прайс-лист. Стоимость Vault Enterprise определяется индивидуально — после консультации с отделом продаж. Это нужно учитывать при планировании бюджета, чтобы избежать неожиданных расходов.
• Экспертиза. Решение требует глубоких знаний для настройки и поддержки. Развертывание отказоустойчивых кластеров, управление политиками доступа и интеграция с различными системами — задачи, которые под силу опытным DevOps-инженерам, знакомым с архитектурой Vault. Найти таких специалистов может быть сложнее, чем администраторов типовых систем управления секретами.
• Функции. Vault предлагает большой набор возможностей: от базового хранения секретов до динамической генерации учётных данных и шифрования как услуги. Часть функций доступна только в Enterprise-версии — это стоит учитывать, если вам нужны конкретные возможности с самого начала.
• Иностранное решение. HashiCorp Vault — продукт американской компании. В России нет официальных лицензий, решение отсутствует в Реестре Минцифры. Это ограничивает его использование в госсекторе и компаниях с требованиями к импортозамещению.

Сравнение Hashicorp Vault и Пассворка

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

Архитектура

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

Как работает Hashicorp Vault: сервер может расшифровывать секреты и выполнять операции с ними напрямую. Это позволяет создавать встроенные движки (Database Secrets Engine, PKI Engine и др.), которые работают на стороне сервера.

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

1. Обращаются к Пассворку с токеном доступа и мастер-ключом
2. Расшифровывают секреты на стороне клиента
3. Выполняют действия по интеграции со сторонними системами
4. Записывают или обновляют данные в Пассворке

В чём разница: Vault доверяет серверу и полагается на его защищённость. Пассворк не доверяет никому, кроме конечного пользователя.

Преимущества подхода Пассворка

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

Управление секретами

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

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

• HashiCorp Vault: KV Secrets Engine — гибкое хранилище ключ-значение с версионированием.
• Пассворк: хранение паролей, ключей и файлов с кастомными полями и удобным интерфейсом.

Динамические секреты
Vault — технологический лидер в этой области. Но на практике 90% потребностей в ротации покрывают простые скрипты, интегрированные с Пассворком.

• HashiCorp Vault: встроенные движки генерируют временные учётные данные для баз данных, облаков (AWS, Azure, GCP) и других систем.
• Пассворк: через внешние агенты — Пассворк не имеет встроенного механизма, но позволяет реализовать ротацию через API и скрипты.

Lease management
Lease Management в Vault — это механизм «аренды» секретов. Секрет автоматически истекает по TTL, его можно продлить или принудительно отозвать.

• HashiCorp Vault: автоматическое управление жизненным циклом (TTL, продление, отзыв) для динамических секретов.
• Пассворк: нет встроенного механизма — жизненный цикл управляется внешними системами (например, cron-заданиями).

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

• Оба решения: REST API с полным программным доступом ко всем функциям.

Криптография и PKI

Возможность шифрования «на лету» и управления инфраструктурой открытых ключей (PKI) — сильная сторона Vault. Эти инструменты часто оказываются избыточными для типовых сценариев, но незаменимы при сложных требованиях к безопасности.

PKI/CI

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

Transit Crypto-as-a-service
У Vault это встроенный полнофункциональный движок. Transit — мощная, но нишевая функция. Пассворк фокусируется на своей основной задаче — безопасном хранении секретов.

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

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

• HashiCorp Vault: разнообразные алгоритмы — AES-GCM, ChaCha20, RSA, ECDSA и др. Шифрование на стороне сервера.
• Пассворк: Zero knoweldge и серверное шифрование (OpenSSL) — все данные шифруются на стороне клиента по принципу Zero knowledge.

Интеграция с DevOps-инструментами

Простота и скорость интеграции в существующие процессы — ключевой фактор для DevOps-команд.

CI/CD интеграция
Оба решения эффективно интегрируются с CI/CD. Vault предлагает готовые плагины для популярных систем, Пассворк — универсальный подход через CLI и Docker.

• HashiCorp Vault: множество плагинов для большинства популярных CI/CD-систем (Jenkins, GitLab CI, GitHub Actions).
• Пассворк: CLI и Docker-образы — универсальный подход, который работает с любой CI/CD-системой без необходимости в плагинах.

Python SDK
hvac — зрелая и функциональная библиотека. Коннектор Пассворка проще в освоении и автоматизирует типовые операции.

• HashiCorp Vault: hvac library — популярная и мощная библиотека для взаимодействия с Vault.
• Пассворк: официальный коннектор — простой в использовании SDK, который берёт на себя рутинные задачи, например, автоматическое обновление токенов.

CLI-инструменты
Passwork-cli прост в освоении, имеет понятный синтаксис и удобный режим exec для передачи секретов.

• HashiCorp Vault: Vault CLI — большое количество команд и опций.
• Пассворк: Passwork CLI —утилита с интуитивно понятным синтаксисом и удобным режимом exec, который позволяет передавать секреты в дочерние процессы.

Интеграция с Kubernetes
У Vault есть нативная автоматизация через Injector/CSI, у Пассворка — более простой init/sidecar-паттерн. Итог (секреты на лету) достигается в обоих подходах — различается сложность и глубина автоматизации.

• HashiCorp Vault: Agent Injector + CSI — глубокая и нативная интеграция с Kubernetes через sidecar-контейнеры и CSI-драйвер с аннотациями на Pod-спецификации.
• Пассворк: Init-контейнеры/sidecar — интеграция возможна через стандартные механизмы Kubernetes с использованием CLI, но требует больше ручной настройки.

Корпоративные функции

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

Управление доступом на основе ролей (RBAC)
Пассворк предлагает более простую и быструю в настройке модель RBAC, которая покрывает большинство корпоративных потребностей.

• HashiCorp Vault: Policies + Roles — гибкая система управления доступом на основе политик.
• Пассворк: Роли + Группы — простая и понятная ролевая модель, знакомая большинству администраторов.

Интеграция с AD/LDAP
Оба решения поддерживают AD/LDAP-интеграцию. В Vault это один из множества методов аутентификации, в Пассворке — встроенная функция с простой настройкой.

• HashiCorp Vault: Auth methods — поддерживается как один из множества методов аутентификации.
• Пассворк: встроенная поддержка — интуитивная и быстрая интеграция с Active Directory и другими LDAP-каталогами.

Технология единого входа (SSO)
Оба решения предлагают сопоставимые возможности по SSO.

• HashiCorp Vault: OIDC, SAML — поддержка стандартных протоколов для интеграции с провайдерами идентификации.
• Пассворк: интеграция с популярными SSO-провайдерами.

Аудит
Оба решения предоставляют исчерпывающую информацию для аудита безопасности.

• HashiCorp Vault: возможность логировать каждое действие с секретами.
• Пассворк: детальный журнал всех действий пользователей и API-клиентов.

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

• HashiCorp Vault: интерфейс ориентирован на администраторов и DevOps-инженеров.
• Пассворк: современный и интуитивно понятный интерфейс, рассчитанный на широкий круг пользователей.

Практические сценарии использования

Рассмотрим, как Пассворк и Vault решают типичные DevOps-задачи.

Интеграция в CI/CD

Задача: безопасно передать пароль от базы данных в скрипт развертывания deploy.sh в рамках CI/CD-пайплайна.

Решение HashiCorp Vault: интеграция требует нескольких шагов — настройки аутентификации для CI/CD (например, через JWT или AppRole), создания политик доступа и получения секрета.

deploy:
  script:
    # 1. Аутентификация в Vault
    - export VAULT_TOKEN=$(vault write -field=token auth/jwt/login role=myproject jwt=$CI_JOB_JWT)
    # 2. Чтение секрета (путь и поле зависят от вашей схемы ключей в KV)
    - export DB_PASSWORD=$(vault kv get -field=password secret/myapp/db)
    # 3. Запуск скрипта
    - ./deploy.sh

Решение Пассворка: Пассворк CLI предлагает режим exec, который получает секрет и передает его в дочерний процесс через переменные окружения. Имя переменной формируется из названия кастомного поля записи.

deploy:
  image: passwork/passwork-cli:latest
  variables:
    # Рекомендуется задать эти значения как Masked/Protected переменные 
    # в Settings > CI/CD > Variables
    PASSWORK_HOST: "https://passwork.example.com"
    PASSWORK_TOKEN: "${PW_TOKEN}"
    PASSWORK_MASTER_KEY: "${PW_MASTER_KEY}"
  script:
    # Запуск скрипта с автоматическим получением секрета
    # Секреты будут доступны в ENV только дочернему процессу
    - passwork-cli exec --password-id "ITEM_ID" -- ./deploy.sh

Примечание: deploy.sh использует $DB_PASSWORD из кастомного поля записи в Пассворке.

Управление секретами в Kubernetes

Задача: обеспечить под приложения в Kubernetes доступом к секретам.

Решение HashiCorp Vault: Vault предлагает нативные механизмы: Agent Injector или CSI Provider. Требуется развертывание дополнительных компонентов в кластере и глубокая настройка с аннотациями на Pod-спецификации.

# Аннотации для пода, использующего Agent Injector
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: 'true'
    vault.hashicorp.com/role: 'myapp-role'
    vault.hashicorp.com/agent-inject-secret-database-config.txt: 'secret/data/myapp/db'

Решение Пассворка: подход Пассворка проще и не требует установки дополнительных операторов в кластер. Используется стандартный паттерн init-контейнера, который с помощью passwork-cli получает секреты и записывает их в общую для пода emptyDir-директорию.

Вариант 1 (через API, извлечь только пароль)

# Фрагмент манифеста пода
initContainers:
  - name: passwork-secrets
    image: passwork/passwork-cli:latest
    command:
      - sh
      - -c
      - |
        passwork-cli api \
          --method GET \
          --endpoint "v1/items/ITEM_ID" \
          --field password > /secrets/db_password
    volumeMounts:
      - name: secrets-volume
        mountPath: /secrets

containers:
  - name: my-app
    # ...
    volumeMounts:
      - name: secrets-volume
        mountPath: /secrets
        readOnly: true

Вариант 2 (через exec, записать ENV в файл)

initContainers:
  - name: passwork-secrets
    image: passwork/passwork-cli:latest
    command:
      - sh
      - -c
      - |
        passwork-cli exec --password-id "ITEM_ID" \
          -- sh -lc 'printf "%s" "$DB_PASSWORD" > /secrets/db_password'
    volumeMounts:
      - name: secrets-volume
        mountPath: /secrets

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

Ротация паролей

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

Решение HashiCorp Vault: используется Database Secrets Engine, который автоматически генерирует временные учетные данные с заданным TTL.

Решение Пассворка: задача решается простым скриптом, запускаемым по расписанию (например, в cron или CI/CD), который выполняет три действия:

1. Генерирует новый пароль
2. Применяет его в целевой системе (например, ALTER USER в СУБД)
3. Обновляет пароль в Пассворке через API

#!/usr/bin/env bash
set -Eeuo pipefail

NEW_PASSWORD="$(openssl rand -base64 24)"

# 1) Ротация в БД
PGPASSWORD="$OLD_PASSWORD" psql -h "$DB_HOST" -U "$DB_USER" -d "$DB_NAME" \
  -c "ALTER USER \"$DB_USER\" WITH PASSWORD '$NEW_PASSWORD';"

# 2) Обновление в Пассворке (CSE на клиенте)
python - <<'PY'
import os
from passwork_api import Passwork

pw = Passwork(
    host=os.environ["PASSWORK_HOST"],
    token=os.environ["PASSWORK_TOKEN"],
    master_key=os.environ["PASSWORK_MASTER_KEY"],
)
pw.update_item(item_id=os.environ["PW_ITEM_ID"], 
               password=os.environ["NEW_PASSWORD"])
PY

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

Архитектурные сценарии внедрения

Выбор между Пассворком и Vault не всегда означает полную замену одного на другое. В зависимости от зрелости компании, требований к безопасности и существующей инфраструктуры возможны различные стратегии.

Чистый Пассворк

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

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

Преимущества: Максимальная простота, низкая стоимость, быстрое внедрение. Покрывает большинство потребностей в управлении статическими секретами и их интеграции в CI/CD.

Реализация: локальная установка на серверы компании, интеграция в DevOps-процессы через CLI и API.

Гибридный подход

Этот сценарий признает сильные стороны обоих продуктов и использует их для решения конкретных задач.

Vault используется для нишевых, высокоспециализированных задач:

• PKI Engine — управление собственной инфраструктурой открытых ключей и массовый выпуск короткоживущих сертификатов.
• Transit Engine — централизованный сервис для криптографических операций (шифрование как сервис).

Пассворк используется для всего остального:

• Хранение 99% всех секретов: пароли пользователей, API-ключи, статические ключи доступа, конфигурационные файлы
• Управление доступом для сотрудников и команд
• Простая интеграция в CI/CD для большинства приложений

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

Миграционный подход

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

1. Аудит и идентификация — проанализировать текущее использование Vault. Выделить сценарии, где его функциональность избыточна (например, хранение простых статических ключей).
2. Пилотный проект — внедрить Пассворк для одного или нескольких некритичных проектов. Перенести секреты из Vault в Пассворк и перенастроить CI/CD-пайплайны.
3. Поэтапная миграция — после успешного пилота постепенно переводить другие команды и проекты на Пассворк.
4. Оценка и решение — по итогам миграции принять решение: полностью отказаться от Vault в пользу Пассворка или перейти к гибридной модели, оставив Vault для специфических задач.

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

Заключение: когда выбирать Пассворк?

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

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

Выбирайте Пассворк, если:

• Цените быструю окупаемость (ROI): Пассворк позволяет получить 90% необходимой функциональности за 20% от стоимости и сложности Vault.
• Стремитесь к универсальности: вам нужен единый инструмент для управления паролями сотрудников и секретами для DevOps, с удобным интерфейсом для всех.
• Предпочитаете простоту и предсказуемость: вы хотите избежать сложных настроек, длительного внедрения и непрозрачного ценообразования.
• Ваша команда DevOps перегружена: вы хотите высвободить ресурсы инженеров от поддержки сложной инфраструктуры и направить их на решение бизнес-задач.
• Безопасность для вас приоритет: архитектура Zero knowledge с клиентским шифрованием в Пассворке обеспечивает высочайший уровень защиты данных.

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

Читайте также

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

Содержание * Что такое управление секретами * Пассворк: больше, чем менеджер паролей * API как основа интеграции * Инструменты для разработчиков и DevOps * Шифрование и модель Zero Knowledge * Авторизация и токены * Бизнес-кейсы * Итоги Что такое управление секретами Управление секретами (secrets management) — это процесс централизованного хранения, управления и ротации конфиденциальных данных, которые приложения и сервисы

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

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

Содержание * Что такое типы сейфов? * Как это работает? * Базовые типы сейфов * Преимущества типов сейфов * Управление типами сейфов * Миграция с предыдущих версий * Почему это важно Типы сейфов В Пассворк 7.1 управление доступом стало более гибким благодаря системе типов сейфов. Типы сейфов решают главную проблему администраторов — как контролировать доступ к данным

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

Персональные данные 2025: новые правила для бизнеса

Новые правила 152-ФЗ и изменения 2025. Как бизнесу защитить персональные данные, избежать штрафов и соблюдать требования Роскомнадзора.

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

Что такое управление секретами

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

Почему это важно для бизнеса?

• Безопасное централизованное хранение секретов. Все конфиденциальные данные хранятся в едином защищённом репозитории, что исключает риск их размещения в открытых файлах, скриптах или исходном коде и минимизирует вероятность несанкционированного доступа и утечек.
• Гибкое управление доступом и делегирование прав. Система позволяет детально настраивать права доступа к каждому секрету на уровне пользователей, групп или сервисных аккаунтов, обеспечивая принцип минимальных привилегий (least privilege) и сокращая поверхность атаки за счёт ограничения доступа.
• Аудит и мониторинг обращений к секретам. Все операции с секретами фиксируются: кто, когда и к чему обращался, какие изменения были внесены. Это облегчает соответствие требованиям регуляторов и прозрачность процессов безопасности.
• Автоматизация ротации и обновления секретов. Регулярная автоматическая смена паролей, ключей и других секретов по заданному расписанию или при возникновении событий (например, компрометации) экономит время ИТ-специалистов.
• Интеграция с DevOps-процессами и инфраструктурными компонентами. Секреты доступны через API, CLI, SDK и плагины, что позволяет интегрировать систему управления секретами с CI/CD пайплайнами, облачными сервисами, контейнерными платформами и базами данных.
• Снижение рисков утечки и компрометации данных. Централизованный контроль и автоматизация процессов позволяют оперативно реагировать на инциденты, быстро отзывать и обновлять уязвимые секреты, предотвращая распространение угроз внутри корпоративной среды.

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

Пассворк: больше, чем менеджер паролей

Пассворк давно зарекомендовал себя как корпоративный менеджер паролей, но с выходом 7-й версии его возможности значительно расширились и вышли за рамки привычного «хранения паролей». Благодаря открытому API, Пассворк трансформировался в полноценную систему управления секретами.

Интерфейс API Пассворка обеспечивает программный доступ ко всем функциям веб-платформы: управлению паролями, сейфами, папками, пользователями и ролями, ярлыками, вложенными файлами, а также журналом событий. С помощью API можно автоматизировать процессы выдачи и отзыва прав доступа, обновления паролей, интеграции с CI/CD-процессами, а также экспортировать логи.

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

1. Менеджер паролей — удобный пользовательский интерфейс для безопасного хранения и совместного использования учётных данных внутри команды.
2. Система управления секретами — программный доступ для разработчиков и администраторов через REST-API, Python-коннектор, CLI и Docker-контейнер, позволяющие автоматизировать работу с секретами в скриптах, сервисах и DevOps-процессах.

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

API как основа интеграции

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

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

Инструменты для разработчиков и DevOps

Python-коннектор

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

Ключевые преимущества:

• Простота интеграции. Все базовые операции сведены к методам вроде create_item, get_item, create_vault, что избавляет от ручной работы с HTTP-запросами.
• Безопасность на клиенте. Шифрование, расшифровка и работа с мастер-ключом выполняются в библиотеке, секреты защищены даже при работе с открытым API.
• Управление сессиями. Коннектор автоматически сохраняет и восстанавливает токены, а также обновляет истекший accessToken через refreshToken.
• Гибкость. Универсальный метод call() позволяет обращаться к любым эндпоинтам, даже если они не покрыты стандартными методами коннектора.

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

from passwork_client import PassworkClient

client = PassworkClient(host="https://passwork.example.com")
client.set_tokens("ACCESS_TOKEN", "REFRESH_TOKEN")  # передаём токены
client.set_master_key("MASTER_KEY")  # мастер-ключ для расшифровки

# создание хранилища и пароля
vault_id = client.create_vault(vault_name="DevOps", type_id="vault_id_type")
password_data = {
    "Name": "Database PROD", 
    "vaultId": vault_id,
    "title": "DB prod",
    "login": "admin",
    "password": "secure-password",
    "url": "https://db.example.com"
}
password_id = client.create_item(password_data)

# получение и использование пароля
secret = client.get_item(password_id)
print(secret['password'])

Все криптографические операции выполняются локально, а мастер-ключ никогда не покидает вашу среду.

CLI-утилита

Passwork CLI — командная утилита для получения секретов и работы с API из shell-скриптов и CI/CD.

Режимы работы:

1. exec — извлекает секреты, создаёт для них переменные окружения и запускает указанный процесс. Пароли нигде не сохраняются и доступны только во время выполнения.
2. api — выполняет произвольные методы API и выводит ответ в JSON.

Полезно для:

• Безопасного подключения к базам данных и сервисам — пароль подставляется через переменные окружения и не хранится на диске.
• Автоматизации развёртывания и CI/CD — секреты автоматически подгружаются в пайплайне;
• Администрирования серверов — временные переменные позволяют выполнять задачи от имени сервисных учётных записей;
• Интеграции с DevOps-инструментами — легко сочетается с Ansible, Terraform и другими решениями.

Для аутентификации можно использовать флаги (--host, --token, --master-key) либо переменные окружения PASSWORK_HOST, PASSWORK_TOKEN и PASSWORK_MASTER_KEY.

Пример exec
Резервное копирование PostgreSQL. CLI создаст переменную окружения PGPASSWORD и запустит pg_dump:

export PASSWORK_HOST="https://passwork.example.com"
export PASSWORK_TOKEN="your_access_token"
export PASSWORK_MASTER_KEY="your_master_key"

passwork-cli exec --password-id "5f8a7b6c9d0e1f2a3b4c5d6e" \
  pg_dump -h localhost -U username -d database > backup.sql

Пример multi-secret
Запуск скрипта, которому нужны три секрета:

passwork-cli exec \
  --password-id "db123,api456,storage789" \
  deploy.sh --db-pass=$DATABASE_PASSWORD --api-key=$API_KEY --storage-key=$STORAGE_KEY

Пример api
Получить список сейфов:

passwork-cli api --method GET --endpoint "v1/vaults"

CLI поддерживает фильтрацию по тегам и папкам, работу с пользовательскими полями, обновление токенов, временную деактивацию SSL-проверки (только для тестовой среды с флагом --no-ssl-verify).

Docker-контейнер

Для CI/CD подготовлен Docker-образ passwork/passwork-cli. Он содержит предустановленный CLI и запускается от непривилегированного пользователя.

Укажите переменные окружения и запустите команду:

docker run -it --rm \
  -e PASSWORK_HOST="https://passwork.example.com" \
  -e PASSWORK_TOKEN="your_access_token" \
  -e PASSWORK_MASTER_KEY="your_master_key" \
  passwork-cli exec --password-id "db_password_id" mysql -h db_host -u admin -p $DB_PASSWORD db_name

Образ удобен в пайплайнах Bitbucket или GitLab — достаточно указать переменные окружения и выполнить команду passwork-cli exec. Можно использовать docker-compose и пробрасывать секреты другим контейнерам.

Использование секретов в приложениях

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

Пример:

1. В Пассворке создаётся запись DB_PASSWORD
2. В пайплайне запускается команда:

passwork-cli exec --password-id "<id_секрета>" --cmd "node server.js"

3. CLI создаёт переменную DB_PASSWORD и запускает node server.js. Приложение читает пароль из process.env.DB_PASSWORD.

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

Автоматизация ротации паролей

Регулярная смена паролей снижает риск компрометации. Сценарий автоматизации с Python-коннектором:

1. Получить текущий пароль из Пассворка (get_item)
2. Сгенерировать новый пароль
3. Изменить пароль в базе данных (ALTER USER)
4. Обновить запись в Пассворке (update_item)
5. Уведомить команду о завершении

Псевдокод:

from passwork_client import PassworkClient
import secrets
import psycopg2

def rotate_db_password(passwork_host, accessToken, refreshToken, master_key, password_id, db_params):
    client = PassworkClient(passwork_host)
    client.set_tokens(accessToken, refreshToken)
    client.set_master_key(master_key)
    
    secret = client.get_item(password_id)
    current_password = secret['password']
    new_password = secrets.token_urlsafe(32)
    
    conn = psycopg2.connect(
        dbname=db_params['db'], 
        user=db_params['user'],
        password=current_password, 
        host=db_params['host']
    )
    
    with conn.cursor() as cur:
        cur.execute(f"ALTER USER {db_params['user']} WITH PASSWORD '{new_password}'")
    conn.commit()
    
    client.update_item(password_id, {"password": new_password})
    print("Пароль успешно ротирован и обновлён в Пассворке")

Шифрование и модель Zero Knowledge

Пассворк реализует схему шифрования, соответствующую принципу Zero Knowledge: сервер никогда не видит секреты в открытом виде. Существует два уровня защиты:

1. Серверное шифрование — всё содержимое баз данных шифруется на сервере и защищено даже от администраторов.
2. Клиентское шифрование (client-side encryption, CSE) — можно включить для критичных данных: секреты шифруются на стороне клиента библиотеке клиента, на сервер отправляется только шифротекст. При включённом CSE пользователь вводит мастер-пароль, из него генерируется мастер-ключ, которым расшифровываются ключи сейфов и отдельных записей; благодаря этому даже компрометация сервера не раскрывает содержимое сейфов.

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

Авторизация и токены

API использует пару токенов — accessToken и refreshToken. Access-токен действует ограниченное время, refresh-токен позволяет получить новый access-токен без повторной аутентификации — Python-коннектор делает это автоматически.

Для безопасности рекомендуется:

• Создавать отдельных пользователей для интеграций API и выдавать им только необходимые права (минимальные привилегии)
• Назначать сервисным учёткам роль с доступом только к нужным сейфам и папкам
• Регулярно ротировать токены и ограничивать срок их действия
• Хранить токены в переменных окружения или секрет-хранилищах
• Использовать HTTPS для всех запросов

Бизнес-кейсы

Итоги

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

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

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

Читайте также

Персональные данные 2025: новые правила для бизнеса

Новые правила 152-ФЗ и изменения 2025. Как бизнесу защитить персональные данные, избежать штрафов и соблюдать требования Роскомнадзора.

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

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

Содержание * Что такое типы сейфов? * Как это работает? * Базовые типы сейфов * Преимущества типов сейфов * Управление типами сейфов * Миграция с предыдущих версий * Почему это важно Типы сейфов В Пассворк 7.1 управление доступом стало гибче благодаря системе типов сейфов. Типы сейфов решают главную проблему администраторов — как контролировать доступ к данным и

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

Почему бизнес выбирает расширенную версию Пассворка

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

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