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

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

Представьте себе запасной ключ. Вы передали его подрядчику полгода назад, чтобы он починил вашу систему отопления, вентиляции и кондиционирования. Работа выполнена. Подрядчик ушёл. Но ключ всё ещё работает, и вы его не забирали. Примерно то же самое происходит каждый раз, когда кто-то в вашей компании подключает стороннее приложение к Google Workspace или Microsoft 365 с помощью OAuth. Цифровые ключи создаются вашими сотрудниками. Они не истекают, и в большинстве организаций никто их не отслеживает, не проверяет и не удаляет, когда они больше не нужны!

OAuth Это система, стоящая за кнопками «Подключиться к Google» и «Разрешить доступ», которые ваша команда нажимает каждый день. Она позволяет приложениям считывать ваш календарь, отправлять электронные письма от вашего имени или извлекать данные из вашего облачного хранилища, и все это без раскрытия вашего фактического пароля. Звучит здорово. Подвох в том, что созданный ею токен доступа сохраняется еще долго после того, как вы забудете о существовании приложения. Он не аннулируется при увольнении сотрудника. Он не сбрасывается при смене пароля. Ваша многофакторная аутентификация никак не помешает злоумышленнику, у которого уже есть действительный токен.

Многие организации не знают об этой проблеме. Еще меньше тех, кто занимается ее решением.

Исследования, проведенные Материальная безопасность Исследование показало, что 80% руководителей служб безопасности считают неуправляемые разрешения OAuth критическим или значительным риском. Этот показатель остается высоким уже много лет. Однако осведомленность, возможно, не является главной проблемой в данном случае, поскольку смягчение этой угрозы может быть не столь важным. is.

45% Многие организации ничего не делают для мониторинга предоставления прав через OAuth в больших масштабах.

33% полагаться на ручной учет, например, с помощью электронных таблиц, и на внеплановые проверки

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

Реальное нападение, которое уже произошло.

В 2024 и 2025 годах злоумышленник, известный как UNC6395 (отслеживаемый подразделением 42 компании Palo Alto), использовал украденные токены обновления OAuth с платформы Drift, предназначенной для взаимодействия с клиентами, чтобы получить доступ к средам Salesforce более чем 700 организаций. Drift имел легитимные OAuth-соединения с этими учетными записями Salesforce. Злоумышленник завладел этими токенами, вероятно, в результате более ранних фишинговых атак, и проник в систему напрямую.

Что сделало эту атаку настолько эффективной?
Ничего подозрительного не обнаружилось. Токены были действительны. Приложению доверяли. Вход в систему так и не состоялся, потому что злоумышленник вообще не входил. Он предъявил существующий токен, на использование которого Drift уже получил разрешение. Многофакторная аутентификация не использовалась, поскольку пароль не был введен. После входа в систему UNC6395 извлек данные и выполнил поиск учетных данных, таких как ключи AWS, токены Snowflake и пароли. В результате пострадали Cloudflare, PagerDuty и десятки других компаний.

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

Почему большинство инструментов безопасности упускают это из виду

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

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

Что на самом деле включает в себя качественный мониторинг OAuth

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

OAuth был создан для более простых времен.

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

По мере того, как инструменты ИИ становятся стандартом на рабочем месте, количество подключений OAuth в вашей среде будет расти. Полная блокировка доступа сотрудников к инструментам ИИ нереалистична, и это в любом случае не остановило бы атаку Drift, поскольку она началась с доверенной, одобренной интеграции.

Что вы можете сделать прямо сейчас

Начните с составления списка всех приложений OAuth, подключенных к вашей среде Google Workspace или Microsoft 365. Обе платформы позволяют администраторам сделать это без использования сторонних инструментов. Найдите приложения, которые вам незнакомы, приложения, подключенные к учетным записям уволившихся сотрудников, и приложения с очень широкими правами доступа, такими как «чтение всей почты» или «доступ ко всем файлам». Это ваши первоочередные задачи для проверки и отзыва прав.

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

Шаг действий в CyberHoot
На этой неделе войдите в свою консоль администратора Google или портал Microsoft Entra и получите список подключенных сторонних приложений. Подсчитайте их. Вы, вероятно, удивитесь. Выберите пять наименее знакомых приложений и проверьте, к чему они имеют доступ. Отмените все ненужные доступы. Это единственное действие сделает вашу организацию значительно безопаснее уже сегодня. Вперед!

---

Справка Google и Microsoft:

Токены административной консоли Google Workspace:

admin.google.com → Users → [User] → Security → Connected Applications

Обзор разрешений Microsoft Entra:

learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-application-permissions

---

источники:

• Hacker News: Бэкдор, о котором знают злоумышленники, — и который большинство групп безопасности до сих пор не закрыли.
• Пошаговое руководство по атаке OAuth на цепочку поставок Red Canary (Отличное практическое руководство по охоте, октябрь 2025 г.)

---

Защитите свой бизнес с CyberHoot сегодня!