GitHub запустил публичное превью proof of presence — механизма, который требует повторной интерактивной аутентификации перед чувствительными действиями в Enterprise Cloud. Проверка должна подтвердить, что операцию в данный момент выполняет авторизованный пользователь, а не тот, кто получил его активную сессию или долгоживущий токен.
Согласно анонсу GitHub, предварительная версия доступна предприятиям с Enterprise Managed Users на github.com и в среде GHEC-DR. Обязательное условие — использование Microsoft Entra ID как поставщика единого входа через SAML или OIDC.
Функция особенно интересна командам, которые используют GitHub для разработки ИИ-продуктов, управления CI/CD и запуска автоматизированных агентов. Она вводит явную границу между действиями, допустимыми в рамках уже открытой сессии, и операциями, для которых необходимо новое подтверждение пользователя.
Почему действующей сессии оказалось недостаточно
GitHub связывает запуск функции с атаками на цепочки поставок, в которых применялись украденные сессионные cookie и долгоживущие учётные данные. Компания не называет конкретные инциденты в анонсе, поэтому связывать обновление с отдельной атакой без дополнительных подтверждений нельзя.
Проблема заключается в том, что корректный токен или активная сессия сами по себе не доказывают, кто инициировал операцию. Если cookie попал к злоумышленнику, сервис может воспринимать его запросы как действия уже вошедшего в систему пользователя.
Proof of presence повышает требования именно в момент чувствительной операции. GitHub перенаправляет пользователя к поставщику идентификации, где тот должен пройти интерактивную переаутентификацию или многофакторную проверку. Администратор может применять к этому запросу политики, настроенные в Entra ID.
Для разработчиков агентных систем здесь есть отдельное практическое следствие: наличие доступа к браузерной сессии ещё не означает, что агент сможет автономно завершить привилегированную операцию. Дополнительный вызов рассчитан на подтверждение со стороны пользователя и может намеренно прерывать полностью автоматический сценарий.
Как устроена повторная проверка
Proof of presence расширяет модель sudo mode в GitHub. В обычном sudo mode GitHub повторно запрашивает подтверждение личности перед некоторыми действиями, даже если пользователь уже вошёл в аккаунт. Корпоративный вариант передаёт проверку внешнему поставщику идентификации.
После успешного вызова пользователь может выполнять защищённые действия в той же браузерной сессии в течение двух часов без нового запроса. Это окно снижает количество повторных проверок, однако его следует учитывать при моделировании угроз: пройденный вызов не закрывает сессию сразу после одной операции.
В анонсе также говорится, что предприятия смогут выбирать требования со стороны Entra ID. В частности, администраторы могут связать повторную аутентификацию с корпоративными политиками доступа. Возможности и ограничения таких правил описаны в документации Microsoft по Conditional Access.
GitHub не приводит в кратком сообщении исчерпывающий перечень защищаемых операций. Компания отдельно сообщает, что поддержка proof of presence перед слиянием pull request появится позднее. Следовательно, считать защиту слияний уже доступной в текущем публичном превью не следует.
Из анонса также нельзя сделать вывод, что механизм распространяется на все действия через API, приложения GitHub или автоматизированные конвейеры. Proof of presence описан через браузерную сессию и интерактивный переход к IdP. Командам, зависящим от API и сервисных учётных записей, необходимо проверять поведение отдельно по актуальной документации и в тестовом enterprise-окружении.
Кому доступно публичное превью
Начальный охват функции заметно ограничен. Она предназначена не для всех организаций GitHub Enterprise Cloud, а только для предприятий с Enterprise Managed Users. В этой модели жизненным циклом корпоративных аккаунтов управляет внешний поставщик идентификации.
На этапе публичного превью поддерживается Microsoft Entra ID. Вход должен быть организован через SAML или OIDC. GitHub не сообщил в анонсе сроков появления других IdP, поэтому владельцам инфраструктуры на Okta, Ping Identity или иных платформах не стоит предполагать совместимость.
Заявленная поддержка GHEC-DR относится к конфигурации GitHub Enterprise Cloud с возможностями аварийного восстановления. Анонс не распространяет функцию на самостоятельно размещаемый GitHub Enterprise Server.
GitHub также указывает на клиентов из регулируемых отраслей, которым требуется свежая аутентификация перед чувствительными операциями. В качестве примера компания приводит требования FDA Part 11. При этом включение одной функции само по себе не подтверждает соответствие организации требованиям 21 CFR Part 11: итог зависит от процессов, журналирования, контроля доступа и других мер.
Что проверить администраторам и разработчикам агентов
Перед пилотным включением proof of presence стоит определить, какие действия GitHub уже относит к высокорисковым в конкретной версии превью. Особенно важно не переносить на текущий релиз обещанную поддержку проверок перед слиянием pull request.
Практический чек-лист для теста:
- подтвердить, что enterprise использует Enterprise Managed Users, а не обычные корпоративные аккаунты с SAML SSO;
- проверить, подключён ли Microsoft Entra ID через поддерживаемый протокол SAML или OIDC;
- создать отдельную тестовую группу и применить к ней требуемую политику Entra ID;
- проверить повторный запрос после истечения двухчасового окна;
- протестировать сценарий с украденной или скопированной браузерной сессией в контролируемой среде;
- выяснить, как вызов влияет на браузерные расширения, RPA-инструменты и агентные системы, которые взаимодействуют с интерфейсом GitHub;
- отдельно проверить API, GitHub Apps, CLI и CI/CD, не предполагая, что браузерный механизм автоматически защищает эти каналы;
- сохранить журналы GitHub и Entra ID, чтобы убедиться, что попытки и результаты повторной проверки доступны команде безопасности.
Proof of presence следует рассматривать как дополнительный барьер для ручных привилегированных операций, а не как замену короткоживущим токенам, защите IdP, контролю приложений и мониторингу сессий. Пока функция находится в публичном превью, её фактический охват и поведение разумнее проверять на пилотной группе, не включая новый режим сразу для всего предприятия.