#azure #azure-active-directory
#azure #azure-active-directory
Вопрос:
Мы используем поток учетных данных клиента в Azure AD для проверки подлинности наших API, когда вызывающий объект является каким-либо демоническим процессом. Согласно нашим политикам безопасности, нам необходимо проводить аудит при неудачных попытках доступа. По большей части нам удалось удовлетворить большинство требований отделов безопасности, за исключением случаев, когда запрос get token завершается неудачно. Это может быть вызвано рядом причин, таких как недопустимый идентификатор клиента, секрет или сертификат. Конечная точка, которую мы используем для запроса токена, https://login.microsoftonline.com /{арендатор}/oauth2/v2.0/токен.
Я попробовал несколько примеров, демонстрирующих передачу недопустимых параметров в запрос маркера доступа. Затем я проверил разделы мониторинга журналов аудита и входа в систему нашего клиента Azure AD, ожидая увидеть сообщение об отказе в авторизации определенного типа. К моему удивлению, ничего не было.
Я пытался выполнить поиск в аудите потока учетных данных клиента в документах Microsoft docs и в Google, но мне не удалось найти что-либо в отношении аудита неудачных запросов маркеров доступа.
Есть ли где-нибудь на портале, который мы можем просмотреть, когда запрос токена доступа не возвращает токен-носитель?
Ответ №1:
AFAIK, Azure AD не помещает запросы маркеров доступа в журналы. Вы можете добавить содержимое запросов маркеров доступа при вызове конечной точки в свой код.
Журналы аудита: отчет о действиях журналов аудита предоставляет вам доступ к истории каждой задачи, выполняемой в вашем клиенте. Примеры журналов аудита включают изменения, внесенные в любые ресурсы в Azure AD, такие как добавление или удаление пользователей, приложений, групп, ролей и политик.
Журналы входа: с помощью отчета об активности входа можно определить, кто выполнял задачи, о которых сообщается в журналах аудита.
Комментарии:
1. Спасибо за ответ. У нас есть ведение журнала вокруг конечной точки. Мы ищем способ просмотра запросов маркеров доступа. С точки зрения выставления счетов им нужен способ определить, генерирует ли что-то слишком много токенов доступа. С точки зрения безопасности это будет означать, что что-то пытается выполнить какой-либо тип атаки методом перебора против запроса get token. Благодаря имеющемуся у нас журналированию мы можем видеть, кто попадает в наши конечные точки, но если злоумышленник попадает только в запрос токена, а не в конечную точку, мы никогда не узнаем, что происходит что-то нечестивое.
Ответ №2:
Я нашел ответ. Если кому-либо это понадобится в будущем, Azure регистрирует успешные и неудачные запросы маркеров доступа в разделе «Вход в систему по принципу обслуживания». Нажмите здесь, чтобы увидеть заголовок экрана расположения журнала