Claude нашёл 16 проблем в SAML: расследуем сбои федерации

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

История с Claude показывает другую сторону проблемы. За месяц анализа один исследователь проверяет 16 реализаций SAML. Это не означает, что каждая система содержит подтверждённую уязвимость. Модель помогает искать идеи, но итог требует воспроизводимой проверки.

🔍 Что именно означает «16 проблем»

Число 16 относится к находкам одного исследователя в разных реализациях SAML. Он делит задачи между ИИ-агентами. Результаты попадают в общее хранилище. Задачи получают приоритет и проходят дедупликацию.

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

В публикации отдельно описывается проблема в Authentik. Она позволяет вставить XML-комментарий в значение NameID. При определённых настройках сопоставления система обрезает значение до чужого адреса. Затем атакующий связывает свою учётную запись с учётной записью жертвы.

Подпись при этом остаётся действительной. Уязвимость закрывается в версиях 2026.2.6 и 2026.5.5. Эти версии важны только для Authentik. Их нельзя переносить на другие продукты и называть общей проблемой SAML.

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

📖 Как устроен SAML-обмен

SAML передаёт приложению подписанный XML-документ. Провайдер идентификации, или IdP, формирует документ для приложения. Приложение выступает как SP и создаёт сеанс пользователя.

В документе есть адрес пользователя и другие атрибуты. Криптографическая подпись подтверждает целостность документа. Но подпись сама по себе не отвечает на вопрос, можно ли принимать этот документ в конкретном приложении.

Обмен начинается с формирования запроса. SP направляет пользователя к IdP. Передача использует перенаправление или POST. После входа IdP отправляет ответ обратно на адрес ACS.

ACS — это конечная точка приложения. Она принимает ответ и передаёт его библиотеке SAML. Затем приложение проверяет подпись, условия действия, получателя и назначает локального пользователя.

Проблема возникает, если два компонента читают XML по-разному. Библиотека проверяет подпись одного набора данных. Логика приложения использует другой набор. В таком случае неподписанное значение может выглядеть как подписанное.

Что сделать сейчас: нарисуйте цепочку обмена для одного входа. Отметьте IdP, SP, ACS, обратный прокси и балансировщик. Для каждого узла укажите входные данные и журнал.

🧭 С чего начинается расследование сбоя

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

Соберите идентификатор запроса, если его передают IdP или SP. Запишите, какой маршрут использует пользователь. Один и тот же адрес может проходить через разные прокси и балансировщики.

Затем разделите симптомы на четыре группы. Первая группа связана с отказом аутентификации. Вторая касается сопоставления пользователя и атрибутов. Третья указывает на сеть. Четвёртая связана с подписью, сертификатом или политикой.

Такое разделение экономит время. Ошибка сертификата не исправляется изменением NameID. Сбой маршрута не устраняется добавлением нового атрибута. Сначала нужно подтвердить класс причины.

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

Что сделать сейчас: создайте карточку расследования. В ней должны быть время события, компонент с ошибкой, тип Binding, ACS URL, EntityID и ссылка на записи журналов.

⚙️ Проверка адресов и параметров доверия

Сначала проверьте EntityID, Issuer, ACS URL и Audience. Эти значения связывают запрос, ответ и конкретное приложение. Даже один лишний символ может вызвать отказ.

Issuer показывает источник ответа. EntityID обозначает участника федерации. ACS URL показывает, куда SP принимает ответ. Audience ограничивает приложение, для которого предназначено утверждение.

Сравните значения в трёх местах. Нужны настройки IdP, настройки SP и фактический XML-ответ. Документация может описывать одну среду. Рабочий обмен может использовать другую.

Отдельно проверьте Recipient. Это адрес получателя утверждения. Он должен соответствовать ожидаемой конечной точке. Проверка Audience без проверки Recipient оставляет неполный контроль назначения.

Затем проверьте Binding и HTTP-метод. Для перенаправления и POST действуют разные правила передачи. Прокси может изменить маршрут, схему или заголовок. Из-за этого приложение получает адрес, отличный от настроенного.

Сравните тестовую и рабочую метаданные. В тестовой среде часто остаются старые сертификаты и временные ACS URL. Перенос такой конфигурации создаёт трудно заметный сбой.

Что сделать сейчас: составьте таблицу параметров IdP и SP. Пометьте каждое значение как «совпадает», «отличается» или «не проверяется». Не исправляйте конфигурацию до фиксации исходного состояния.

⏱️ Проверка времени и срока действия

SAML использует временные условия. Утверждение содержит границы действия NotBefore и NotOnOrAfter. Ошибка часов превращает корректный ответ в просроченный или ещё не действующий.

Проверьте время на IdP, SP, прокси и балансировщике. Сравнивайте время в одной временной зоне. Учитывайте допустимое расхождение часов, если его задаёт система.

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

Проверьте срок действия Assertion. Он не должен быть избыточно длинным. Длинное окно увеличивает время, когда украденный ответ может оставаться полезным.

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

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

🔐 Как расследовать подпись и сертификаты

Проверьте, что именно подписывает IdP. В одной схеме подписывается ответ. В другой схеме подписывается утверждение. Иногда политика требует подписывать оба объекта.

Нельзя считать ответ защищённым только из-за наличия сертификата. SP должен проверять подпись того объекта, из которого он читает идентификатор и атрибуты.

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

Ротация часто создаёт переходный период. IdP уже использует новый ключ. SP всё ещё доверяет старому. Или наоборот. В журнале появляется ошибка проверки, хотя обмен и адреса остаются правильными.

Найдите процедуру обновления ключей. Она должна описывать порядок действий, срок совместной поддержки и откат. Ручная замена сертификата без записи результата усложняет расследование.

Отдельно проверьте алгоритмы и настройки библиотеки. Не принимайте неподписанные данные ради совместимости. Временное отключение проверки маскирует проблему и создаёт риск подмены.

Что сделать сейчас: сформируйте реестр ключей IdP и SP. Укажите отпечаток, дату окончания, владельца и дату последней проверки. Проверьте тестовую и рабочую среду отдельно.

👤 Как найти ошибку сопоставления пользователя

После проверки подписи приложение сопоставляет данные SAML с локальной учётной записью. Для этого используют NameID и атрибуты. Ошибка на этом шаге не означает сбой аутентификации.

Проверьте формат NameID. Уточните, какое поле считается главным идентификатором. Сравните регистр, пробелы, домен и правила нормализации.

Одна и та же строка может иметь разный смысл в разных системах. Адрес электронной почты может быть логином. Он может быть только атрибутом профиля. Нельзя менять это правило без анализа влияния.

История Authentik показывает, почему обработка NameID требует отдельного внимания. XML-комментарий менял видимое значение. Подпись оставалась действительной. Проблема проявлялась только при определённых настройках связывания учётных записей.

Проверьте, какие атрибуты имеют право создавать или связывать учётную запись. Избыточные права увеличивают последствия ошибки. Особенно опасно автоматическое связывание по непроверяемому полю.

Сравните утверждение с записью локального каталога. Не выводите персональные данные в общий журнал. Для диагностики используйте маскирование и ограниченный доступ.

Что сделать сейчас: опишите правило сопоставления одним предложением. Затем проверьте его на новом тестовом пользователе и на уже существующей учётной записи.

🌐 Где искать сетевые и транспортные сбои

SAML-ответ проходит несколько узлов. Браузер передаёт запрос или POST. Прокси принимает соединение. Балансировщик выбирает сервер. SP обрабатывает ответ и создаёт сеанс.

Каждый узел может изменить маршрут. Прокси меняет схему HTTP на HTTPS. Балансировщик передаёт другой заголовок Host. ACS получает адрес, который не совпадает с метаданной конфигурацией.

Проверяйте фактический маршрут, а не только настройки приложения. Сравните внешнее имя с внутренним именем сервера. Уточните, где завершается TLS и какой адрес видит SP.

Сетевой сбой обычно не требует анализа XML. Сначала проверьте DNS, доступность ACS, коды ответа и время ожидания. Затем переходите к содержимому SAML-ответа.

Разные Binding требуют разных наблюдений. При перенаправлении важны параметры URL. При POST важны форма, размер запроса и обработка тела. Прокси может обрезать или менять параметры.

Журналы должны покрывать весь путь. Нужны записи IdP, SP, обратного прокси и балансировщика. Время на всех узлах должно позволять связать одну операцию.

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

🧪 Как безопасно использовать Claude в анализе

Claude полезен как помощник для чтения конфигурации и журналов. Он может сгруппировать повторяющиеся ошибки. Он может предложить места для ручной проверки.

Но модель не видит скрытые настройки без явного ввода. Она также может принять подозрение за уязвимость. Поэтому каждый вывод нужно проверять в изолированной среде.

Перед передачей данных удалите адреса пользователей, токены и секреты. Не отправляйте закрытые ключи. Не передавайте полный рабочий SAML-ответ, если для задачи хватает отдельных полей.

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

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

Документируйте запрос к модели. Сохраняйте дату анализа, входные данные и полученный вывод. Иначе повторная проверка не покажет, почему список изменился.

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

📋 Таблица симптомов и корректирующих действий

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

Симптом	Вероятная причина	Проверка	Корректирующее действие
Ответ отклоняется сразу	Issuer или EntityID не совпадает	Сравнить настройки IdP, SP и XML	Исправить одну сторону после сохранения копии
Ошибка ACS URL	Прокси меняет адрес или схему	Сопоставить внешний и внутренний адрес	Синхронизировать URL и заголовки маршрута
Ответ просрочен	Рассинхронизация времени	Сравнить часы всех узлов	Настроить синхронизацию и разумный допуск
Ошибка подписи	Старый или неизвестный сертификат	Проверить отпечаток и срок действия	Обновить доверенную метаданную конфигурацию
Вход успешен, пользователь не найден	Неверное правило NameID	Сравнить формат и локальный идентификатор	Исправить сопоставление на тестовой учётной записи
Права пользователя неверны	Ошибка атрибута или его значения	Сверить атрибут с политикой доступа	Ограничить набор и права атрибутов
Сбой только через прокси	Изменение маршрута или POST	Сравнить прямой и штатный путь	Исправить правило прокси без ослабления проверки

Таблица помогает не смешивать сетевые и логические причины. После каждого исправления повторяйте один и тот же тест. Меняйте только один параметр за раз.

Что сделать сейчас: добавьте в таблицу реальные сообщения из журналов. Укажите владельца каждого исправления и ожидаемый результат.

⚠️ Какие риски нужно отделять от обычных сбоев

Сбой федерации не всегда означает атаку. Но расследование должно проверять типовые риски. В первую очередь ищите повторное использование утверждений и отсутствие контроля уникальности.

Проверьте, отклоняет ли SP старый Assertion. Уточните, как система обрабатывает идентификатор ответа. Посмотрите, учитываются ли временные условия и адрес получателя.

Отдельный риск связан со слабой проверкой подписи. Система может принимать неподписанные данные. Она может проверять один XML-узел, а использовать другой. Такое расхождение требует отдельного теста.

Проверьте обработку XML. Разные компоненты не должны по-разному понимать один документ. Нельзя считать корректной схему, где библиотека проверяет один объект, а приложение читает другой.

Проверьте Audience и Recipient. Отсутствие такой проверки позволяет принять ответ не для этого приложения. Риск особенно важен в среде с несколькими SP и общим IdP.

Оцените права атрибутов. Избыточный набор данных увеличивает ущерб при ошибке сопоставления. Ограничьте автоматическое создание учётных записей и привязку по непроверенным полям.

Не забывайте о журналах. Подробные SAML-ответы могут содержать персональные данные. Их нужно маскировать, ограничивать по доступу и хранить только необходимый срок.

Что сделать сейчас: проведите проверку на тестовом контуре. Отдельно подтвердите защиту от повторного ответа, подмены атрибута и неподписанных данных.

🛡️ Как закрывать подтверждённые находки

Сначала определите продукт и версию. Затем подтвердите уязвимый сценарий на копии конфигурации. Не применяйте исправление только потому, что модель назвала его критичным.

Для Authentik уже есть конкретные версии исправления: 2026.2.6 и 2026.5.5. Это пример точного результата. В нём указаны продукт, механизм проблемы и версии, которые закрывают дефект.

После обновления повторите тест. Проверьте обычный вход, отказ при неверной Audience и обработку изменённого NameID. Сравните журналы до и после исправления.

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

Зафиксируйте остаточный риск. Укажите, какие системы затронуты, какие данные доступны и когда появится постоянное исправление. Это помогает не потерять временное исключение.

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

Что сделать сейчас: оформите для каждой находки карточку с версией, условием воспроизведения, исправлением и результатом повторного теста.

✅ Итоговый чек-лист расследования

Начните с жизненного цикла обмена. Зафиксируйте запрос, перенаправление или POST, ответ IdP, проверку SP и создание сеанса. На каждом этапе сохраняйте время и идентификатор события.

Затем пройдите параметры доверия. Проверьте EntityID, Issuer, ACS URL, Audience и Recipient. Сопоставьте Binding и HTTP-метод. Убедитесь, что тестовая и рабочая конфигурации не расходятся.

После этого проверьте время. Сравните часы всех узлов. Изучите NotBefore и NotOnOrAfter. Не расширяйте допустимое расхождение без измерений.

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

Затем исследуйте идентичность. Проверьте NameID, формат, регистр и правила связывания. Сопоставьте атрибуты с локальной учётной записью. Ограничьте автоматическое создание пользователей и назначение прав.

В конце проверьте защиту от повторного использования и расхождений разбора XML. Уберите секреты и персональные данные из диагностических материалов. Передавайте Claude только обезличенный контекст.

1. Соберите один успешный и один неуспешный обмен.
2. Свяжите журналы IdP, SP, прокси и балансировщика.
3. Разделите сбой, ошибку настройки и уязвимость.
4. Подтвердите каждую гипотезу на тестовом контуре.
5. Исправьте один параметр и повторите сценарий.
6. Зафиксируйте результат, версию и остаточный риск.

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

Что сделать сейчас: возьмите последний сбой SAML и пройдите чек-лист сверху вниз. Начинайте с фактов журнала, а не с предположения о причине.

📚 Читайте также

• Мониторинг облака: почему все проверки OK, а сервис лежит
• Как защитить облачные контейнеры от вредных образов и атак на цепочку поставки
• Что на самом деле подтверждает C2PA: криптография против мифов
• Сертификация ФСТЭК UserGate SIEM: 4-й уровень доверия и требования к СИБ РФ
• Уязвимости инверторов Hoymiles: как дрон может обесточить десятки домов

📖 Термины

IAM (Identity and Access Management) · SIEM · Криптография · Шифрование

🔗 Источники

• Claude вскрыл 16 SAML-проектов за месяц вечеров. Чинить их оказалось некому(2026-08-21 ✓)
• Troubleshooting - Claude Code Docs(2026-08-21 ✓)
• В работе сервисов Claude от Anthropic произошел массовый сбой(2026-08-21 ✓)