Google менеджер паролей: как устроен и чем опасен для бизнеса

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

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

Этот пробел важен: учётные данные остаются одной из главных целей кибератак. По данным Positive Technologies за первое полугодие 2025 года, вредоносное ПО применялось в 63% успешных атак на российские организации, социальную инженерию — в 50%. Оба вектора часто приводят к краже паролей: стилер выгружает базу браузера, фишинг вытягивает логин напрямую у человека. В статье разберём, что сервис защищает, что остаётся без контроля и чем его заменить в команде.

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

Менеджер паролей Google (Google Password Manager) — штатный менеджер паролей экосистемы Google. Он сохраняет логины и пароли пользователя и синхронизирует их между устройствами через учётную запись Google. Работает в двух средах:

• Chrome — кроссплатформенный браузер компании Google на движке Chromium. Устанавливается на Windows, macOS, Linux, Android и iOS. Менеджер паролей встроен в него и предлагает сохранить учётные данные при входе на сайт.
• Android — мобильная операционная система Google на базе ядра Linux. Менеджер паролей входит в сервисы Google и служит системным сервисом автозаполнения для приложений и сайтов.

Записями можно управлять в браузере, в настройках смартфона и на веб-странице passwords.google.com — устанавливать отдельное приложение не нужно.

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

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

Что умеет менеджер паролей Google

• Автозаполнение — сохраняет логин и пароль при первом входе на сайт или в приложение и подставляет их при следующем.
• Генерация паролей — при регистрации Chrome предлагает случайный пароль и сразу сохраняет его в менеджер.
• Ключи доступа — хранит ключи для входа без пароля по стандарту FIDO2/WebAuthn. Вместо секрета, который можно подсмотреть или перехватить, сайт получает криптографическое подтверждение с устройства пользователя.
• Проверка на утечки — сверяет сохранённые пароли с базами известных утечек и показывает слабые и повторяющиеся.
• Синхронизация — переносит записи между Android, Windows, macOS, Linux и iOS, где установлен Chrome с входом в тот же аккаунт.

Что это значит для личного и корпоративного использования

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

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

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

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

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

Шифрование at rest: ключ у провайдера

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

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

Риски шифрования в состоянии покоя (at rest):

1. Доступ через аккаунт — при схеме at rest вход в аккаунт: единственный барьер между атакующим и паролями. Ключ шифрования хранится у Google, поэтому сервис сам расшифровывает записи для любого, кто прошёл аутентификацию.
2. Взлом инфраструктуры провайдера — если злоумышленник получит доступ и к данным, и к ключам, шифрование перестанет быть преградой.
3. Действия сотрудников провайдера — технически доступ к ключу открывает возможность прочитать данные. Провайдеры ограничивают его внутренними процедурами, но защита держится на политике, не на криптографии.
4. Запрос иностранного органа — серверы Google и юрисдикция находятся за пределами России. Американский закон CLOUD Act позволяет правоохранительным органам США требовать данные у американских провайдеров, даже если они хранятся за рубежом. При схеме at rest ключ у Google, поэтому компания технически может расшифровать записи и передать их по такому требованию.

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

Шифрование на устройстве: ключ у пользователя

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

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

Парольная фраза синхронизации (sync passphrase)

Третий способ — парольная фраза синхронизации Chrome (sync passphrase). Вы задаёте собственную фразу в настройках синхронизации. Данные шифруются на устройстве до отправки, и Google не может их прочитать. Фраза действует на все синхронизируемые данные, а не только на пароли.

Если вы забыли парольную фразу, придётся сбросить синхронизацию и потерять синхронизированные данные. Копии на устройствах при этом остаются.

Нулевое знание: есть ли оно у Google Менеджера паролей

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

1. Ключ создаётся на устройстве пользователя.
2. Ключ не передаётся на сервер.
3. Провайдер хранит только зашифрованные данные.

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

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

Сравнение моделей шифрования: at rest и zero-knowledge

Плюсы Google менеджера паролей

Для личного использования у менеджера паролей Google есть реальные сильные стороны. Они объясняют, почему сотрудники могут использовать его по умолчанию, даже когда в компании уже развёрнуто корпоративное решение.

• Нулевой порог входа — Google менеджер паролей работает и доступен в Chrome и на Android сразу без установки, регистрации и отдельной подписки.
• Синхронизация — пароли доступны на любом устройстве, где выполнен вход в тот же аккаунт Google.
• Автозаполнение и генератор паролей — помогают не повторять пароли и не придумывать слабые для личных сервисов.
• Проверка паролей — инструмент сверяет сохранённые пароли с базами известных утечек и предупреждает о совпадениях.
• Ключи доступа — снижают риск фишинга на сервисах, которые их поддерживают.

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

Минусы и риски Google менеджера паролей для бизнеса

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

Google-аккаунт как единая точка отказа

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

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

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

Инфостилеры и браузерное хранилище

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

По данным Positive Technologies, более 70% успешных кибератак на российские компании в 2025 году реализовывались с использованием вредоносного ПО.

Синхронизация ключей доступа: атака «Pass-ta-key»

Ключи доступа (passkeys) задумывались как защита от фишинга, но синхронизация между устройствами добавляет собственную поверхность атаки. В 2026 году исследователи Unit 42 (Palo Alto Networks) описали атаку «Pass-ta-key»: вредоносное ПО на устройстве может перехватывать синхронизируемые ключи доступа Google без участия биометрии владельца. Переход на «беспарольный» вход не снимает риск компрометации устройства, а переносит его.

Чего не хватает для работы команды

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

• Нет безопасной передачи пароля коллеге — встроенный обмен паролями рассчитан на семейную группу, а не на рабочую команду.
• Пароль принадлежит человеку, а не команде — если сотрудник в отпуске, на больничном или недоступен, коллеги не получат доступ к сервису.
• Нет типов записей для технических секретов — для API-ключей, токенов, сертификатов и строк подключения к базам нет специальных полей.
• Нет интеграции с корпоративной инфраструктурой — нет связи с AD/LDAP и корпоративным SSO, нет API для автоматизации. Секреты для CI/CD и сервисных учётных записей хранить негде. Автозаполнение лучше всего работает в Chrome, а в других браузерах и на других платформах зависит от версии и расширений.

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

Чего не хватает администратору

В Google менеджере паролей нет ролевой модели доступа (RBAC), журнала аудита и процесса пересмотра доступа сотрудников в привычном для бизнеса виде. Администратор не видит, где лежат рабочие пароли, и не может ими управлять.

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

Юридический риск для российских компаний

Пароли хранятся на серверах Google за пределами России. Если в записях есть персональные данные или доступы к ИСПДн, оператору нужно оценить это по ст. 18 (ч. 5) и ст. 12 Федерального закона № 152-ФЗ «О персональных данных». Требования к локализации и трансграничной передаче зависят от состава данных. К этому добавляется риск недоступности сервисов Google или блокировки аккаунта по причинам вне контроля компании.

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

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

Браузерный менеджер паролей и менеджер паролей для бизнеса: таблица-сравнение

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

Управление и контроль

Данные и инфраструктура

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

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

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

Привычный для пользователя сценарий: автозаполнение и приложения

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

Браузерное расширение Пассворка работает во всех популярных браузерах, включая Chrome, Firefox, Edge, Яндекс Браузер и Safari: подставляет логин и пароль на странице, ищет записи и генерирует пароли по политике организации. Доступ к расширению можно закрыть ПИН-кодом.

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

Переход занимает три шага:

1. Сотрудник устанавливает расширение и входит в Пассворк.
2. Администратор выдаёт доступ к сейфам через группы.
3. Рабочие пароли переносятся из личного Google-аккаунта в корпоративный сейф.

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

Размещение данных

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

Шифрование на устройстве

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

Контроль доступа и совместная работа

Права выдаются группам и ролям, а не отдельным людям. Новый сотрудник попадает в группу «Бухгалтерия» и получает сейфы отдела, а сотрудник из другого отдела их не видит. Иерархия «сейф → папка → запись» позволяет задать права на нужном уровне. Через LDAP/AD состав групп берётся из каталога, а SSO убирает отдельный вход.

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

Аудит

Журнал фиксирует, кто и когда открывал, менял или передавал записи. При инциденте служба ИБ восстанавливает цепочку действий. События экспортируются в SIEM через Syslog, CEF или API. У личного Google-аккаунта сотрудника такого журнала нет.

Офбординг

Если отключить учётную запись пользователя в LDAP/AD или в Пассворке, доступ к сейфам отзывается. Но человек мог уже видеть пароль, поэтому пароли от критичных систем после увольнения меняют. Менеджер паролей показывает, к каким записям у сотрудника был доступ, и задаёт список для смены.

Панель безопасности паролей

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

Два решения в одном: пароли людей и секреты машин

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

Регуляторика

Пассворк — российский менеджер паролей и средство защиты информации. Есть сертификат ФСТЭК России № 5063 (4-й уровень доверия) и запись в реестре российского ПО.

Заключение: личный менеджер паролей не заменяет корпоративный контроль

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

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

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

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

Почему опасно хранить пароли в браузере: риски, статистика и защита

Инфостилерам не нужно взламывать браузер — ключ шифрования и база паролей лежат в одной папке. В 2025 году так украли 3,3 млрд учётных записей. Разбираем архитектуру уязвимости в Chrome, Firefox, Safari и Edge, а также рабочую альтернативу для бизнеса.

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

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

Разбираем, как выбрать корпоративный менеджер паролей, почему локальное развёртывание безопаснее облака и как ИТ-отделу взять под контроль все доступы компании всего за 1–2 дня.

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

Кража данных компании: при чём здесь пароль сотрудника

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

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