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 — на слой синхронизации, где хранится всё сразу.
| Параметр | Обычный фишинг | VaultJacking |
|---|---|---|
| Цель атаки | Пароль от одного сайта или сервиса | Доступ к синхронизированному хранилищу паролей |
| Масштаб ущерба | Обычно один аккаунт | Все пароли и ключи доступа, сохранённые в менеджере паролей Google |
| Роль MFA | Часто существенно снижает риск входа | Защита зависит от защиты хранилища и устройств |
| Что нужно атакующему | Пароль + обход MFA конкретного сервиса | ПИН от аккаунта Google |
| Реагирование | Сменить пароль, отозвать сессии одного сервиса | Сменить пароль Google-аккаунта, проверить все устройства, ключи доступа и критичные сервисы |
Что такое фишинг?
Фишинг — вид социальной инженерии и кибератаки, при которой злоумышленник выдаёт себя за доверенное лицо или организацию (банк, сервис, компания) для получения конфиденциальной информации. Обычно осуществляется через поддельные письма, SMS, звонки или веб-сайты, которые выглядят как оригинальные. Цель — кража паролей, данных банковских карт, учётных данных или других персональных данных. Фишинг остаётся одним из наиболее распространённых методов кибератак благодаря простоте исполнения и высокой эффективности.
Что такое атака «злоумышленник посередине» (AiTM-фишинг)?
Атака «злоумышленник посередине» (AiTM, Adversary-in-the-Middle) — продвинутая форма фишинга, при которой злоумышленник перехватывает коммуникацию между пользователем и сервисом в реальном времени. Атакующий создаёт поддельный сервис, который одновременно взаимодействует с настоящим сервером, перенаправляя запросы туда и обратно. Это позволяет ему перехватить пароли, двухфакторные коды, токены сессий и другие учётные данные. AiTM-фишинг особенно опасен, так как обходит двухфакторную аутентификацию (2FA) и требует от пользователя повышенной бдительности. Защита включает использование ключей доступа (passkeys), проверку URL и сертификатов, а также мониторинг аномальной активности.
Что такое ключи доступа (passkeys)?
Ключи доступа (Passkeys) — современный метод аутентификации на основе криптографии с открытым ключом, который заменяет пароли. Пользователь создаёт пару ключей: приватный ключ хранится локально на устройстве (защищён биометрией или PIN), а открытый ключ передаётся серверу. При входе устройство подписывает вызов сервера приватным ключом, доказывая подлинность без передачи секретов. Passkeys устойчивы к фишингу, так как не могут быть перехвачены, и удобнее паролей благодаря биометрической аутентификации. Поддерживаются FIDO2, WebAuthn и используются в iOS, Android, Windows и веб-браузерах.
Как работает атака на менеджер паролей 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, он получает и все синхронизированные ключи.
| Вопрос | Ответ |
|---|---|
| Ключи доступа защищают от ввода пароля на фишинговом сайте? | Да, WebAuthn-привязка к домену не позволяет передать учётные данные на поддельный сайт |
| Ключи доступа полностью исключают риск компрометации хранилища? | Нет, хранилище и синхронизация представляют собой отдельный уровень риска, не зависящий от защиты на уровне конкретного сайта. |
| Нужно ли отказываться от ключей доступа? | Нет, ключи снижают риск классического фишинга и остаются более безопасной альтернативой паролям для входа на сайты. |
| Что важно для компании? | Управлять тем, где хранятся рабочие секреты, кто имеет к ним доступ и как отслеживаются действия — независимо от типа учётных данных |
Вывод: Ключи доступа и 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) в управлении паролями: сотрудники используют личные браузерные профили для рабочих задач не из злого умысла, а из удобства. У компании при этом нет ни видимости, ни контроля над тем, какие рабочие секреты там хранятся.
Матрица корпоративных рисков браузерного хранилища
| Риск | Почему браузерный менеджер его не закрывает |
|---|---|
| Сотрудник уволился, но пароли остались в его аккаунте | Нет централизованного отзыва доступа |
| Неизвестно, какие рабочие пароли сохранены в личном профиле | Нет инвентаризации и аудита |
| Нет разграничения: кто видит какие пароли | Нет ролевой модели |
| Инцидент с личным аккаунтом = инцидент с рабочими данными | Нет изоляции личного и корпоративного |
| Невозможно интегрировать с SIEM и отслеживать события | Нет журнала действий |
Как защититься пользователю
Практический план для тех, кто использует Google Password Manager в личных или рабочих целях.
Превентивные меры
- Проверяйте домен и контекст перед вводом ПИН-кода. Запрос ПИН-кода от менеджера паролей Google на сторонних сайтах — тревожный сигнал.
- Никогда не вводите ПИН на страницах, открытых по ссылке из письма или мессенджера.
- Включите двухфакторную аутентификацию (2FA) для аккаунта Google с аппаратным ключом или приложением-аутентификатором, не по SMS.
- Регулярно проверяйте список устройств в настройках Google-аккаунта: раздел Безопасность → Ваши устройства. Незнакомое устройство — повод немедленно отозвать доступ.
- Включите уведомления о новых входах в аккаунт.
Разграничение личного и рабочего
- Не сохраняйте рабочие пароли в личном браузерном профиле.
- Используйте отдельные профили браузера для личного и рабочего использования.
- Для рабочих учётных данных — только корпоративный менеджер паролей с централизованным управлением и журналом действий.
Что делать, если ПИН уже введён на подозрительном сайте
Если вы подозреваете, что ввели ПИн-код на поддельной странице, действуйте по алгоритму. Скорость реагирования критична: у атакующего есть временное окно до того, как он завершит присоединение своего устройства к домену безопасности.
| Приоритет | Действие | Зачем это нужно |
|---|---|---|
| 🔴 Критично | Сменить пароль Google-аккаунта и проверить данные для восстановления (телефон, резервная почта) | Снизить риск повторного входа атакующего |
| 🔴 Критично | Открыть настройки Google → «Безопасность» → «Ваши устройства», удалить все незнакомые устройства | Отозвать доступ к Security Domain |
| 🔴 Критично | Проверить раздел «Ключи доступа» (passkey) в настройках аккаунта, удалить незнакомые записи | Удалить ключи доступа, добавленные злоумышленником без вашего ведома |
| 🟠 Важно | Сменить пароли от критичных сервисов, сохранённых в Google Password Manager | Снизить ущерб от потенциального доступа к хранилищу |
| 🟠 Важно | Проверить почту, банки, облака, корпоративные сервисы и репозитории на признаки несанкционированного доступа | Найти следы дальнейшей компрометации |
| 🟡 Плановое | Сообщить ИБ-команде, если в хранилище были рабочие учётные данные | Перевести личный инцидент в управляемый корпоративный процесс |
| 🟡 Плановое | Сменить ПИН-кода менеджера паролей Google | Исключить повторное использование перехваченного ПИН-кода |
Что должны сделать компании
Обучение сотрудников «не вводить ПИН-код на подозрительных страницах» — необходимая, но недостаточная мера. Человеческий фактор остаётся самым слабым звеном: именно поэтому VaultJacking работает через социальную инженерию, а не через уязвимость в коде. Системный ответ — управлять местом хранения рабочих секретов, а не только поведением сотрудников.
Корпоративная модель защиты от рисков браузерных хранилищ
- Политика хранения рабочих паролей. Запрет хранения рабочих учётных данных в личных браузерных профилях фиксируется в регламенте ИБ.
- Корпоративный менеджер паролей. Рабочие секреты отделяются от личного браузерного профиля и хранятся в управляемой инфраструктуре.
- Ролевая модель доступа. Сотрудник видит только те секреты, которые нужны для работы — принцип минимальных привилегий.
- Журналирование и аудит. ИБ-команда получает полную видимость действий с паролями: кто, когда, что изменил или скопировал.
- Интеграция с AD/LDAP и SSO. Упрощается управление жизненным циклом учётных записей: приём, перевод, увольнение.
- Отзыв доступа при увольнении. Администратор удаляет учётную запись один раз — доступ отзывается из всех хранилищ автоматически.
- Интеграция с SIEM (система управления событиями безопасности). События по паролям становятся частью мониторинга ИБ и коррелируются с другими инцидентами.
Нормативный контекст
Для организаций в регулируемых отраслях хранение рабочих учётных данных в личных браузерных профилях — потенциальное нарушение требований регуляторов.
Статья 19 Федерального закона № 152-ФЗ «О персональных данных» обязывает оператора применять организационные и технические меры защиты. Приказ ФСТЭК России № 21 определяет требования к идентификации и аутентификации, включая управление учётными записями и парольную политику. Инцидент, связанный с компрометацией учётных данных через личный браузерный профиль сотрудника, может квалифицироваться как нарушение обоих документов.
Если инцидент затронул рабочие учётные данные — это сигнал для пересмотра политики хранения паролей в компании. Пассворк позволяет централизованно управлять корпоративными секретами, разграничивать доступ по ролям и отслеживать все действия в журнале аудита. Подробнее
Почему корпоративный менеджер паролей безопаснее браузерного для рабочих данных
Браузерный менеджер паролей решает задачу личного удобства: автозаполнение, синхронизация между устройствами, хранение без усилий. Для индивидуального пользователя это разумный выбор. Для корпоративной среды та же простота становится структурной проблемой.
Пассворк — корпоративная альтернатива личным браузерным хранилищам. Браузерное расширение Пассворка работает так же, как встроенный менеджер браузера: автозаполняет логины и пароли на сайтах, предлагает сохранить новые учётные данные — но при этом хранит их в защищённом корпоративном хранилище, а не в личном профиле браузера.
Пассворк поддерживает хранение данных на сервере заказчика, шифрование по AES-256, интеграцию с Active Directory / LDAP, авторизацию через SSO, ролевую модель, журнал действий, интеграцию с SIEM-системами, API и CLI для DevOps-задач.
| Критерий | Браузер | Пассворк |
|---|---|---|
| Где хранятся данные | В облаке провайдера браузера | На сервере компании |
| Шифрование | Управляется провайдером, ключи у него же | AES-256, ключи шифрования у компании |
| Автозаполнение | Есть | Есть в браузерном расширении — интерфейс не отличается от встроенного |
| Разграничение доступа | Нет — все видят всё, к чему есть ссылка | Роли и группы: сотрудник видит только свои секреты |
| Общие пароли команды | Передаются вручную — в чатах, почте, стикерах | Хранятся в общих сейфах и папках с контролем доступа |
| Журнал действий | Нет | Полный аудит: кто, когда, что изменил или скопировал |
| Видимость для ИБ-команды | Нет — личный профиль вне контроля компании | Полная: все сейфы, права, события |
| Интеграция с инфраструктурой | Нет | AD/LDAP, SSO, SIEM, API, CLI |
| Защита от VaultJacking | Уязвим: ПИН синхронизирует всё хранилище | Хранилище изолировано от браузерного профиля и личного аккаунта |
| Соответствие требованиям регуляторов | Не подтверждено | Подтверждено лицензиями и сертификатами |
Итог: управление секретами как ответ на атаки нового поколения
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.
Илья Шелыгин
Илья Шелыгин
Илья Шелыгин