Как защитить данные в облаке от посторонних приложений через OAuth scopes

OAuth scopes — это список прав, которые облачный сервис отдаёт стороннему приложению после нажатия кнопки вроде «Войти через Google», «Подключить Microsoft 365» или «Разрешить доступ к Dropbox». Проблема в том, что многие воспринимают это как обычный вход в аккаунт. На деле приложение может получить не только ваше имя и почту, но и доступ к файлам, почте, календарю, контактам или рабочим документам.

Если цель — защитить данные в облаке, начинать нужно не с пароля, а с проверки: какие именно OAuth scopes запросило приложение, зачем они ему нужны и что будет, если оно ими воспользуется не так, как вы ожидали.

Что именно вы разрешаете приложению

OAuth scopes работают как пропуск с ограниченным набором прав. Одно приложение может попросить только показать ваше имя и email. Другое — читать все файлы в облаке. Третье — менять документы, отправлять письма от вашего имени или получать доступ к данным даже тогда, когда вы не открываете приложение.

Типичные права выглядят так:

• openid, profile, email — базовая идентификация: кто вы, какой у вас email и иногда имя или аватар.
• Files.Read, drive.readonly, files.metadata.read — чтение файлов или их метаданных.
• Files.ReadWrite, drive, files.content.write — чтение и изменение файлов.
• Mail.Read, gmail.readonly — чтение почты.
• Mail.Send, gmail.send — отправка писем.
• offline_access — возможность получать новые токены доступа без вашего повторного входа. Это удобно для синхронизации, но опасно, если приложение сомнительное.

Главная мысль: read-only не значит «безопасно». Если приложение может читать ваши файлы, оно может их скопировать. OAuth scopes ограничивают, к чему приложение имеет доступ, но не гарантируют, что оно будет обращаться с данными честно.

Где посмотреть, какие приложения уже имеют доступ

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

• Google: разделы вроде «Безопасность» → «Сторонние приложения с доступом к аккаунту». В Google Workspace дополнительно смотрите настройки API controls и consent screens в админ-консоли.
• Microsoft 365: личный аккаунт — разделы «Конфиденциальность» или «Приложения и службы». В корпоративной среде — Entra admin center, Enterprise applications, Consent and permissions.
• Dropbox: настройки аккаунта → connected apps или connected services.
• GitHub: Settings → Applications → Authorized OAuth Apps.
• Notion, Slack, Box и другие сервисы: ищите разделы integrations, connected apps, authorized apps.

Не ограничивайтесь одним облаком. Если приложение подключено к Google Drive, оно может работать только с Drive. Но если это Zapier, Make, CRM или HR-система, оно может иметь отдельные подключения к почте, календарю, файловому хранилищу и мессенджеру. Проверяйте каждую связку.

Как читать OAuth scopes и не попасться на широкие права

На экране согласия часто показывают понятные фразы вроде «Просмотр файлов» или «Управление почтой». Это удобно, но иногда скрывает слишком широкий доступ. Поэтому лучше смотреть не только на красивое описание, но и на конкретные scope-строки или хотя бы на уровень доступа.

Особое внимание — словам all, full access, read and write, offline access. Они часто означают, что приложение получает не один документ, а всё пространство, доступное вашему аккаунту. В рабочем облаке это может включать не только ваши личные файлы, но и документы из общих папок, SharePoint, Team Drive, клиентские материалы или внутренние регламенты.

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

1. Поймите задачу приложения. Если это инструмент для электронной подписи, ему действительно нужны документы. Если это простой виджет погоды просит доступ к Drive и Gmail — это красный флаг.
2. Проверьте издателя. Смотрите не только название приложения, но и компанию-разработчика. Название «Google Drive Backup» может быть у любого разработчика, не связанного с Google.
3. Сравните функцию и права. Для просмотра одного файла не нужен полный доступ ко всему облаку. Для отправки уведомления не нужно читать всю почту.
4. Проверьте, можно ли ограничить доступ. Некоторые сервисы позволяют выбрать отдельную папку, конкретный почтовый ящик или подключиться только к рабочему пространству.
5. Оцените срок доступа. Если приложение нужно на один раз, например для миграции файлов, отзовите доступ сразу после завершения.
6. Проверьте отзывы и публичную страницу приложения. Для бизнеса смотрите, есть ли политика обработки данных, контакты поддержки, описание хранения данных и возможность удаления информации.
7. Не подключайте приложение из администратора. Лучше использовать обычный пользовательский аккаунт или отдельную сервисную учётную запись с минимальными правами.

Сценарии выбора: как действовать в разных ситуациях

• Если это личное облако и приложение нужно один раз. Лучше не подключать его к основному аккаунту. Скачайте файл и загрузите его вручную или создайте отдельную папку с тестовыми копиями.
• Если это PDF-редактор, конвертер или инструмент подписи. Ищите подключение с доступом к выбранному файлу, а не ко всему Drive или OneDrive. После работы отзовите доступ.
• Если это постоянный сервис: CRM, Helpdesk, BI, автоматизация. Подключайте его через отдельный сервисный аккаунт. Дайте доступ только к нужной папке, почтовому ящику или набору данных.
• Если приложение просит доступ к почте. Соглашайтесь только если почта — часть основной функции: почтовый клиент, архивация, сортировка, юридический поиск. Для уведоманий полный доступ к почте обычно не нужен.
• Если приложение просит права администратора или согласие от имени всей организации. Не подтверждайте из письма или всплывающего окна. Проверьте разработчика, цель подключения, владельца внутри компании и потенциальный ущерб от утечки.
• Если приложение уже подключено, но вы не помните зачем. Сначала отзовите доступ. Нормальный сервис можно подключить заново, если он действительно нужен. Если после отзыва никто не заметил проблем — приложение было лишним.
• Если это корпоративная среда. Не оставляйте решение на отдельных пользователей. Настройте правила согласования приложений, запретите пользовательское согласие для рискованных scopes и ведите журнал подключений.

Частые ошибки при работе с OAuth scopes

• Думать, что «Войти через Google» само по себе безопасно. Безопаснее не вводить пароль на стороннем сайте — да. Но сервис всё равно может получить доступ к вашим данным, если вы одобрили scopes.
• Соглашаться на всё, чтобы быстрее начать пользоваться. Именно так в облако попадают приложения, которым никто потом годами не проверяет права.
• Не различать чтение и изменение. Read-only может выгрузить данные. ReadWrite может ещё и изменить документы, удалить версии или испортить структуру папок.
• Игнорировать offline_access. Такой доступ может сохраняться долго. Если приложение перестало быть нужным, его нужно отозвать вручную.
• Подключать приложение из администратора. После этого оно может получить больше данных, чем обычный пользовательский аккаунт, особенно в корпоративном облаке.
• Считать проверку приложения одноразовой. Разработчик может обновить интеграцию, запросить новые права или передать приложение другой компании.
• Не проверять SaaS-интеграции. В облаке риск часто приходит не от неизвестного сайта, а от привычного инструмента вроде CRM, автоматизации или отчётности, который уже давно подключён к почте и файлам.
• Думать, что отзыв доступа удаляет скопированные данные. Отзыв OAuth-доступа прекращает дальнейший доступ к API, но не гарантирует удаление того, что приложение уже успело сохранить у себя.

Как лучше защитить облако от лишних приложений

Практичная схема выглядит не сложно, но её нужно довести до привычки.

1. Составьте список подключений. Проверьте Google, Microsoft 365, Dropbox, GitHub, Notion, Slack и другие сервисы, где есть файлы или почта.
2. Удалите всё непонятное. Если вы не узнаёте приложение, не помните, зачем оно подключено, или не пользуетесь им больше 3–6 месяцев — отзовите доступ.
3. Для новых подключений используйте правило минимальных прав. Нужен один документ — не давайте весь диск. Нужны уведомления — не давайте чтение всей почты. Нужна синхронизация — проверьте, действительно ли нужен offline_access.
4. Изолируйте данные. Для интеграций создавайте отдельную папку, отдельный почтовый ящик или сервисный аккаунт. Не подключайте CRM или автоматизацию к личному облаку, где лежат все документы.
5. В компании включите контроль согласий. Запретите пользователям самостоятельно подтверждать приложения с широкими scopes. Настройте admin approval для рискованных запросов.
6. Ведите журнал владельцев. У каждой интеграции должен быть ответственный: кто подключил, зачем, какие данные доступны, когда пересматривать.
7. Пересматривайте доступ регулярно. Для личного аккаунта хватит периодической проверки раз в несколько месяцев. Для бизнеса лучше делать это ежемесячно или после крупных изменений в инструментах.

Что делать, если приложение уже получило лишние права

Если вы нашли подозрительное приложение, не пытайтесь «просто быть осторожнее». Сначала остановите доступ.

1. Отозовите OAuth-доступ в настройках облачного сервиса.
2. Проверьте активность. Посмотрите входы в аккаунт, журналы доступа к файлам, необычные скачивания, новые подключённые устройства.
3. Если это рабочий аккаунт — сообщите администратору. Не ждите, что «само рассосётся». Приложение могло читать документы из общих пространств.
4. Смените пароль, если есть признаки компрометации. Сам OAuth-доступ — это не пароль, но если приложение подозрительное, лучше проверить и учётные данные, и сессии.
5. Запросите удаление данных у разработчика. Если приложение уже скачало файлы или письма, отзыв доступа не удаляет копии. Для рабочих данных это лучше оформлять письменно.
6. Найдите замену с более узкими правами. Часто проблему решает не отказ от инструмента, а выбор другого способа подключения: через выбранную папку, отдельный ящик или ручной импорт.

Какое решение выбрать в зависимости от риска

Короткое правило перед нажатием «Разрешить»

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

• Какую одну задачу оно должно решить?
• Какие минимальные данные нужны для этой задачи?
• Что плохого случится, если приложение получит доступ ко всему, что видит мой аккаунт?

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

Итог: что сделать прямо сейчас

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

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