Доступ сторонних приложений к Google: как отозвать разрешения и проверить историю входов

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

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

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

Типы авторизации: вход через Google и доступ к данным

Google использует две модели предоставления прав, и разграничение между ними критично для аудита. Смешивание моделей в голове — типичная ошибка, которая приводит к ложному чувству безопасности: пользователь видит знакомую кнопку «Войти через Google» и решает, что речь всегда только о логине. На практике за одним и тем же интерфейсом могут скрываться разные уровни доступа.

Sign in with Google — вход через аккаунт. Приложение получает идентификатор пользователя и базовый профиль: имя, фото, email. Токен применяется исключительно для аутентификации — подтверждения того, что пользователь действительно владеет этим аккаунтом. Доступа к контенту — письмам, файлам, событиям календаря — такая модель сама по себе не даёт. Риск здесь ограничен идентификационными данными: если сервис скомпрометирован, злоумышленник узнает, что данный email привязан к определённому профилю.

Доступ к данным — Data access. Приложение запрашивает scope, то есть определённую область видимости. Типичные области: Google Диск, Gmail, Календарь, Контакты, YouTube. Токен даёт право на чтение, запись или удаление соответствующих данных — в зависимости от того, что именно запрошено и подтверждено пользователем. Именно эта модель создаёт основной риск компрометации. Приложение с доступом к Gmail может читать входящие письма; с доступом к Диску — просматривать, скачивать или менять файлы; с доступом к Контактам — выгружать адресную книгу целиком.

Различие между моделями определяет последствия отзыва. Прерывание связи Sign in with Google лишает приложение возможности идентифицировать пользователя — тот просто не сможет войти через аккаунт Google. Прерывание data access блокирует новые запросы к данным, но не стирает информацию, уже скопированную на стороне разработчика. Это принципиальный нюанс, к которому мы вернёмся в разделе о безопасности.

Как понять, какая модель используется? В карточке приложения на странице разрешений Google указывает, к каким данным предоставлен доступ. Если там только «Просмотр основной информации профиля» — это вход через Google. Если перечислены конкретные сервисы: Диск, Почта, Календарь, Контакты, — это уже доступ к данным.

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

Ревизия разрешений: точка входа и процедура

Полный реестр подключённых приложений размещён по адресу myaccount.google.com/permissions. Дополнительный путь: аккаунт Google → раздел «Безопасность» → блок «Сторонние приложения и сервисы с доступом к аккаунту». Интерфейс показывает каждое приложение отдельной карточкой с указанием даты подключения и запрошенных разрешений.

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

Алгоритм ревизии:

1. Открыть страницу myaccount.google.com/permissions.

2. Просмотреть список подключений, начиная со старых и незнакомых сервисов.

3. Для каждой записи проверить три параметра: имя приложения, scope — какие данные запрошены, дата выдачи токена.

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

5. Сервисы с избыточным scope — кандидаты на немедленный отзыв. Трекер привычек, запрашивающий доступ к Google Диску, или калькулятор, просящий контакты, — примеры аномальных разрешений.

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

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

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

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

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

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

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

Контроль сессий: устройства и IP-адреса

Ревизия разрешений — это только один слой. Второй — контроль активных сессий: устройств и IP-адресов, с которых выполнен вход в аккаунт. Если сторонние приложения отвечают на вопрос «кому я дал права», то сессии отвечают на другой: «где сейчас открыт мой аккаунт».

Активные сессии отслеживаются на странице myaccount.google.com/device-activity. Интерфейс отображает устройства, на которых выполнен вход за последние 28 дней. Для каждой записи указаны тип устройства, операционная система, браузер, примерное местоположение по IP и время последней активности.

Процедура проверки:

1. Открыть myaccount.google.com/device-activity.

2. Сопоставить список с фактическим парком устройств. Вы точно знаете, какие телефоны, ноутбуки и планшеты используете; всё остальное под подозрением.

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

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

5. Завершить подозрительную сессию кнопкой «Выйти» в карточке устройства. После этого Google может предложить сменить пароль или пройти дополнительную проверку безопасности.

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

Журнал активности Gmail предоставляет дополнительный слой данных. Доступ: веб-интерфейс Gmail → правый нижний угол → ссылка «Подробные сведения» / Details. Журнал содержит:

• до 10 последних IP-адресов, с которых осуществлялся доступ к почте;
• тип доступа: браузер, мобильное приложение, POP3, IMAP;
• временные метки каждого входа;
• признаки подозрительной активности, если Google счёл сессию необычной.

10 IP-адресов — лимит видимости для обычного аккаунта. Администраторы Google Workspace получают расширенные журналы входов через консоль администрирования: там доступны данные об авторизации, IP-адресах и устройствах.

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

Отдельный нюанс: POP3- и IMAP-доступ. Если вы не используете устаревшие почтовые клиенты, но видите POP3- или IMAP-сессии в журнале, кто-то мог настроить выгрузку вашей почты через сторонний клиент. Это одна из самых неприятных форм компрометации: письма уходят молча, без привычных окон входа и без заметного следа в интерфейсе Gmail. Пользователь продолжает читать почту как обычно, а копия переписки уже может забиратьcя в другой ящик или локальный клиент.

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

Нюансы безопасности: что не делает отзыв доступа

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

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

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

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

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

Есть ещё один практический момент. После отзыва доступа приложение может начать снова просить авторизацию при следующем запуске. Это нормальное поведение. Ненормально — если сервис требует права шире, чем раньше, или не объясняет, зачем ему доступ к данным Google. В такой ситуации лучше не нажимать «Разрешить» автоматически. Чем взрослее аккаунт, тем строже должна быть привычка читать экран согласия.

Устаревшие подключения и пароли приложений

Отдельная категория риска — приложения и сервисы, не поддерживающие OAuth 2.0. Для них Google генерирует 16-значные пароли приложений — App Passwords. Механизм применяется для IMAP- и POP-доступа к Gmail из устаревших почтовых клиентов, скриптов, а также для некоторых устройств и сервисов, которые не интегрированы с современными протоколами авторизации Google.

Пароли приложений легко забыть, потому что они живут не там, где обычные OAuth-разрешения. Пользователь может тщательно почистить myaccount.google.com/permissions, убрать десяток старых сервисов — и всё равно оставить активный пароль, созданный когда-то для почтового клиента на старом ноутбуке. С точки зрения поверхности атаки это отдельная дверь.

Управление паролями приложений:

• Список активных паролей расположен в разделе «Безопасность» → «Пароли приложений»; прямой путь — myaccount.google.com/apppasswords.
• Каждый пароль — уникальная 16-значная строка, привязанная к конкретному приложению или устройству.
• Пароль отзывается отдельно от остальных; его удаление не влияет на основной пароль аккаунта и не затрагивает OAuth-подключения.
• Проверять этот список нужно отдельно от списка разрешённых приложений. Если пароль был создан для разового эксперимента или для сервиса, от которого вы отказались, он должен быть удалён.
• После удаления пароля приложение, которое им пользовалось, перестанет подключаться к аккаунту. Если это был легитимный клиент, его придётся настроить заново более современным способом.

Пароли приложений — часто забываемый слой безопасности. В отличие от OAuth-токенов, они не отображаются на странице myaccount.google.com/permissions и требуют отдельной проверки. Компрометация такого пароля даёт злоумышленнику доступ к почте через IMAP или POP3, минуя стандартную интерактивную авторизацию. Для пользователя это выглядит особенно неприятно: основной пароль не менялся, уведомлений может не быть, а почта всё равно читается внешним клиентом.

Дополнительные слои защиты, связанные с историей действий:

• Страница «Мои действия» (myactivity.google.com) содержит подробный журнал активности: поисковые запросы, просмотр видео, использование приложений, данные о перемещениях, если соответствующие настройки включены.
• Для защиты этого журнала можно включить дополнительную проверку при открытии страницы — ввод пароля или подтверждение через второй фактор.
• На общих устройствах стоит ограничить доступ к журналу, чтобы другие пользователи не могли просматривать историю действий.
• После подозрительной активности имеет смысл проверить не только устройства и разрешения, но и параметры восстановления: резервный email, номер телефона, способы входа.

Безопасность аккаунта Google и сторонние сервисы связаны плотнее, чем кажется. Пользователь может думать, что защищает только почту, а фактически защищает доступ к документам, фотографиям, календарю, истории покупок, контактам и десяткам сервисов, где Google используется как единый идентификатор. Поэтому аудит нельзя сводить к одной кнопке «сменить пароль».

Когда аудит не помогает: сценарии за пределами стандартной ревизии

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

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

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

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

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

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

Финальная ошибка — считать аудит разовой аварийной процедурой. Так он работает плохо. Если открывать настройки только после подозрительного входа, часть ущерба уже могла случиться. Нормальный режим — короткая периодическая ревизия: посмотреть список разрешённых приложений Google, убрать лишнее, проверить устройства, заглянуть в журнал Gmail, отдельно пройтись по паролям приложений.

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