Слепые зоны логирования аутентификации в облаке

Команда безопасности из TrustedSec недавно раскрыла третий и четвёртый способы обхода логирования входа в Azure. Итого четыре независимых техники аутентификации в облачных сервисах Microsoft, при которых сам вход не попадает в логи, на которые опираются команды безопасности. Вход произошёл. Логи его не записали. Тот, кто мониторил эти логи на предмет подозрительной активности, ничего не увидел.

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

Почему в логах аутентификации есть пробелы

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

Azure Active Directory (теперь Entra ID) обеспечивает аутентификацию для Microsoft 365, ресурсов Azure, сторонних приложений через SAML/OIDC, локальных legacy-приложений через App Proxy, service principal, managed identity и многого другого. У каждого из этих путей свой бэкенд, свой конвейер логирования и свои крайние случаи. Логи входов генерирует сервис аутентификации, но некоторые потоки обходят стандартный сервис или используют устаревшие пути, которые появились раньше текущей инфраструктуры логирования.

Пробелы в legacy-протоколах

Microsoft поддерживает обратную совместимость с протоколами аутентификации начала 2000-х, которые появились раньше современной инфраструктуры логирования. Некоторые пути аутентификации SMTP, IMAP и POP3 используют потоки «Basic Auth», которые аутентифицируют на транспортном уровне почты, а не через стандартный токен-эндпоинт Azure AD. Такие аутентификации могут не создавать тех же записей о входе, что современные потоки OAuth/OIDC.

Microsoft уже много лет устаревляет Basic Auth, но в корпоративной среде отказ от устаревших механизмов идёт медленно. В организациях со старыми почтовыми клиентами, сканерами, которые отправляют документы по почте, или старыми бизнес-приложениями Basic Auth может оставаться включённым. Каждый legacy-путь — потенциальный пробел в логировании.

Аутентификация service principal

Service principal, то есть не-человеческие идентичности, которые используют приложения и автоматизация, аутентифицируются иначе, чем пользователи. Их события входа попадают в отдельный поток логов: входы service principal, интерактивные входы и неинтерактивные входы. Команды безопасности, которые мониторят только лог интерактивных входов, полностью пропускают активность service principal.

Это важно, потому что скомпрометированные service principal — частый вектор атаки. Злоумышленник, получивший учётные данные или сертификат service principal, может аутентифицироваться как это приложение и получить доступ ко всем ресурсам, на которые у него есть права. Если команда безопасности смотрит только на входы пользователей, она этого никогда не увидит.

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

Не каждый доступ требует новой аутентификации. Refresh-токены OAuth позволяют продолжать работу без повторного входа. Если злоумышленник украдёт действующий refresh-токен (через скомпрометированное устройство, перехваченный трафик или малварь), он сможет обменять его на новые access-токены, не вызвав тех записей о входе, которые создал бы вход по паролю. Первоначальный вход был записан, но последующие обновления токенов могут выглядеть как неинтерактивные входы, а многие правила обнаружения их не отслеживают.

Проблема detection engineering

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

Стандартная архитектура безопасности для облачных сред выглядит так: облачные сервисы генерируют логи → логи поступают в SIEM (систему управления информацией и событиями безопасности) → правила обнаружения анализируют логи на предмет подозрительных паттернов → оповещения запускают расследование. Это работает только если логи фиксируют всю значимую активность. Если нет, ваш SIEM становится очень дорогим способом наблюдать за неполной картиной.

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

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

Устранить пробелы в логировании облачного провайдера вы не можете, это задача Microsoft (или AWS, или Google). Но можно строить стратегии обнаружения, которые не зависят исключительно от полноты логов аутентификации.

Мониторинг нескольких источников логов

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

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Отключите legacy-аутентификацию

Если вы не используете legacy-протоколы (Basic Auth для SMTP, IMAP, POP3), отключите их. Это устраняет целые категории пробелов в логировании, потому что пути аутентификации, обходящие современное логирование, просто нельзя будет использовать. Политики условного доступа Azure (Conditional Access) могут блокировать legacy-аутентификацию для отдельных пользователей, групп или всего тенанта.

Перед отключением проверьте текущее использование. Логи входов Azure (как ни иронично) всё же показывают некоторые попытки legacy-аутентификации, а workbook Entra ID для legacy-аутентификации помогает найти приложения, которые всё ещё используют старые протоколы. Сначала исправьте эти приложения, а потом блокируйте legacy-аутентификацию.

Мониторинг активности токенов

Внедрите Continuous Access Evaluation (CAE), если ваша среда это поддерживает. CAE позволяет Azure AD отзывать токены почти в реальном времени, когда условия меняются: пользователь отключён, обнаружен вход с высоким риском, сменилась IP-геолокация. Без CAE украденный access-токен действует до истечения срока, обычно час, независимо от того, что делает команда безопасности.

Также отслеживайте время жизни токенов и паттерны обновления. Использование refresh-токена с нового IP-адреса, с нового устройства или в необычное время стоит помечать, ведь часто это единственный сигнал кражи токена.

Тестируйте собственное логирование

Самое полезное, что можно сделать, это регулярно проверять, действительно ли логирование фиксирует то, что вы думаете. Выполните вход каждым способом, который поддерживает ваша среда (интерактивным, неинтерактивным, через service principal, legacy-протокол), и убедитесь, что каждый создаёт ожидаемые записи. Если нет, вы нашли пробел раньше, чем его найдёт злоумышленник.

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

Главный урок

Обходы логов Azure sign-in не уникальны для Microsoft. У каждого облачного провайдера есть пути аутентификации с неполным логированием. У AWS CloudTrail есть свои известные пробелы: некоторые операции плоскости управления в отдельных регионах, определённые случаи принятия service-linked ролей и цепочки ролей между аккаунтами, которые могут скрыть исходную идентичность. У журналов аудита Google Cloud есть похожие крайние случаи.

Урок не в том, что «логирование Azure сломано». Он в том, что любое логирование неполно, и архитектуры безопасности, которые этого не учитывают, будут давать сбой. Эшелонированная защита — это не просто несколько средств контроля, а несколько независимых источников видимости. Если ваше обнаружение целиком зависит от полноты одного источника логов, у вашей системы безопасности есть единая точка отказа.

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