Используйте личные токены доступа

Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Личный маркер доступа (PAT) выступает в качестве альтернативного пароля для проверки подлинности в Azure DevOps. Этот PAT идентифицирует вас и определяет вашу доступность и область доступа. Обратитесь к PATs с тем же уровнем осторожности, что и пароли.

При использовании средств Майкрософт учетная запись Майкрософт или Microsoft Entra ID распознается и поддерживается. Если вы используете средства, не поддерживающие учетные записи Microsoft Entra, или если вы предпочитаете не предоставлять общий доступ к основным учетным данным, рассмотрите возможность использования PATs в качестве альтернативного метода проверки подлинности.

Предварительные условия

Создайте личный маркер доступа

Вы можете использовать PAT в любом месте, где учетные данные пользователя необходимы для проверки подлинности в Azure DevOps. Запомните:

• Обратитесь к PAT с той же осторожностью, что и пароль, и оставьте его конфиденциальным. Не делитесь персональными токенами доступа.
• Для организаций, поддерживаемых Microsoft Entra ID, войдите с помощью нового PAT в течение 90 дней, иначе он станет неактивным. Дополнительные сведения см. в разделе "Частота входа пользователя" для условного доступа.

Уведомления

В течение срока существования PAT пользователи получают два уведомления: один при создании PAT, а другой до истечения срока действия.

После создания PAT может появиться уведомление, аналогичное следующему примеру. Это уведомление служит подтверждением успешного добавления PAT в вашу организацию.

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

Непредвиденное уведомление

Если вы получаете неожиданное уведомление PAT, это может означать, что администратор или средство создали для вас PAT. Ниже приведены некоторые примеры.

• Маркер с именем git: https://dev.azure.com/{yourorganization} on YourMachine создается при подключении к репозиторию Git Azure DevOps через git.exe.
• Токен с именем Service Hooks: Служба приложений Azure: Deploy web app создается, когда вы или администратор настраиваете развертывание веб-приложения Служба приложений Azure.
• Токен с именем WebAppLoadTestCDIntToken создается, когда веб-нагрузочное тестирование настраивается в рамках конвейера вами или администратором.
• Маркер с именем Microsoft Teams Integration создается при настройке расширения для обмена сообщениями интеграции с Microsoft Teams.

Если вы считаете, что ситуация серьезна:

• Отмените PAT (и измените пароль), если вы подозреваете, что он был создан по ошибке.
• Проверьте у администратора, если вы являетесь пользователем Microsoft Entra, был ли доступ к вашей организации с неизвестного источника или местоположения.
• Просмотрите часто задаваемые вопросы по случайной отправке PAT (личного токена доступа) в общедоступные репозитории GitHub.

Использование PAT

ВАШ PAT служит вашим цифровым удостоверением, так же как и пароль. Используйте персональные маркеры доступа (PAT) как быстрый способ выполнять разовые запросы или локально создавать прототип приложения. Используйте PAT в коде для проверки подлинности запросов REST API и автоматизации рабочих процессов, включая PAT в заголовок авторизации запроса.

После того, как код вашего приложения работает, переключитесь на Microsoft Entra OAuth для получения токенов для пользователей приложения или служебного принципала или управляемого удостоверения для получения токенов в качестве приложения. Не продолжайте работать с приложениями или скриптами с помощью PATs в долгосрочной перспективе. Вы можете использовать токены Microsoft Entra в любом месте, где используется PAT.

Рассмотрите возможность получения токена Microsoft Entra через Azure CLI для незапланированных запросов.

Authorization: Basic BASE64_USERNAME_PAT_STRING

curl -u :{PAT} https://dev.azure.com/{organization}/_apis/build-release/builds

Измените ПАТ

Чтобы изменить PAT, выполните следующие действия.

• Повторно создайте маркер PAT и отмените предыдущий маркер.
• Продлите срок действия PAT для увеличения его продолжительности.
• Измените область ПАТ, чтобы изменить ее разрешения.

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

2. Выберите маркер, который требуется изменить, и нажмите кнопку "Изменить".

   

3. Измените имя маркера, срок действия маркера или область доступа, связанную с маркером, а затем нажмите кнопку "Сохранить".

   

Отзыв персонального токена доступа (ПАТ)

Отмените PAT в любое время по следующим и другим причинам:

• Нарушение безопасности: немедленно отмените PAT, если вы подозреваете, что он был скомпрометирован, утекает или отображается в журналах или общедоступных репозиториях.
• Больше не требуется: отменять PAT при завершении проекта, службы или интеграции, для которой она создана.
• Соответствие политик. Отмените ПАТ для применения политик безопасности, требований к соответствию требованиям или расписаниям смены маркеров организации.
• Изменения пользователей. Отмена PAT, когда член команды покидает организацию или изменяет роли и больше не нуждается в доступе.
• Сокращение области. Отмена и повторное создание PAT с ограниченными разрешениями, если необходимо ограничить возможности доступа.
• Регулярное обслуживание: отмена PAT в рамках обычной гигиены безопасности и управления жизненным циклом маркеров.

Чтобы отозвать PAT, выполните следующие действия.

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

2. В разделе "Безопасность" выберите личные маркеры доступа. Выберите маркер, для которого требуется отозвать доступ, а затем нажмите кнопку "Отозвать".

   

3. В диалоговом окне подтверждения нажмите кнопку "Отозвать".

   

Что происходит при истечении срока действия или отмене действия PAT

Когда срок действия PAT истекает или отменяется, любая служба или средство, использующее этот PAT, немедленно теряет проверку подлинности для Azure DevOps. Понимание влияния помогает планировать смену и предотвращать нарушения работы служб.

Влияние на работу службы в зависимости от сценария

Временная шкала влияния

1. По истечении срока действия (указанная дата):

   • PAT автоматически становится неактивным
   • Удаление всех активных подключений
   • Сбой новых попыток проверки подлинности

2. Через несколько часов после истечения срока действия:

   • Запланированные задания (конвейеры, развертывания) завершаются сбоем при следующем выполнении
   • Интерактивные пользователи могут не заметить, пока они не попытаются выполнить следующую операцию

3. После отзыва (немедленно):

   • Все активные сеансы завершаются
   • Все новые запросы, использующие этот PAT, отклоняются

Стратегии упреждающего предотвращения

Чтобы избежать сбоев в работе служб, выполните следующие действия.

• Повторно создайте новый PAT по крайней мере через 7 дней до истечения срока действия, а затем протестируйте и обновите все интеграции до истечения срока действия старого.
• Автоматизация мониторинга. Используйте API управления жизненным циклом PAT для программной проверки дат окончания срока действия.
• Разнесите сроки действия PAT: не позволяйте всем вашим PAT истекать в один и тот же день. Меняйте их местами ежеквартально по разным графикам.
• Задокументируйте использование PAT: храните список мест, где используется каждый PAT (конвейер, скрипт, интеграция), чтобы можно было обновить их при ротации.

Если срок действия PAT истекает неожиданно

Если возникают сбои проверки подлинности, вот как восстановить:

1. Определите проблему: проверьте, истек ли срок действия PAT, просмотрите страницу маркеров личного доступа в параметрах пользователя или попросите администратора проверить журнал аудита.
2. Создайте замену: создайте новый PAT, если разрешения разрешены (см. раздел "Создание PAT").
3. Обновите все интеграции: замените старый PAT новым в:
   • Файлы конфигурации Git (.git/config)
   • YAML-файлы конвейера
   • Агенты сборки
   • Скрипты и интеграции
   • Переменные среды
4. Проверка подключения: выполните тестовую операцию (например, git cloneвызов API), чтобы проверить новые работы PAT.
5. Отмените старый PAT: удалите его из учетной записи, чтобы снизить риск безопасности.

Для локальных сценариев

В Azure DevOps Server поведение срока действия PAT такое же, но его последствия ограничиваются вашим сервером и подключенными службами.

Стратегия ротации и обновления PAT

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

Зачем поворачивать PATS?

• Снижение последствий компрометации: если PAT раскрыт, скомпрометирован или украден, ограничение срока его действия сокращает период риска.
• Соответствие. Для многих стандартов безопасности (SOC 2, ISO 27001, HIPAA) требуется регулярное смена учетных данных.
• Гигиена: удаляет неиспользуемые или устаревшие токены в вашей организации.
• Аудируемость: Частая ротация обеспечивает четкий аудиторский след изменений учетных данных.

Рекомендуемая частота поворота

Применяйте краткосрочные PAT и устанавливайте стратегию смены на основе типа и профиля риска PAT:

• Персональные PAT: Меняйте каждые 90 дней (как минимум ежеквартально).
• PAT-токены служебной учетной записи: Меняйте их каждые 90 дней с автоматическим продлением, где это возможно, чтобы предотвратить сбои в работе службы.
• Привилегированные или высокоуровневые PAT (например, используемые для критической инфраструктуры): смена каждые 30 дней для повышения безопасности.
• Вывод сотрудника из команды: Немедленно отзывайте PAT-токены при любом из следующих изменений статуса участника команды:
  • Завершение или отъезд
  • Передача в другую команду или организацию
  • Отпуск
  • Изменение роли или смена ответственности

Долгосрочная стратегия. Переход с PATs на более надежную проверку подлинности

Microsoft рекомендует сократить использование PAT в пользу более надежных, более аудитируемых методов проверки подлинности. По возможности выполните миграцию в:

• Токены Microsoft Entra — с ограниченным сроком действия, с возможностью обновления, с возможностью аудита через Entra ID
• Управляемые удостоверения— для служб, размещенных Azure (служба приложений, функции, контейнерные приложения)
• Субъекты-службы — для межтенантных сценариев или сценариев вне Azure
• OAuth 2.0 с Microsoft Entra — Для браузерных интеграций и сторонних приложений

Преимущества миграции:

• Уменьшенная область атаки: устраняет длительные статические учетные данные
• Улучшена возможность аудита: собственные журналы аудита Entra ID отслеживают каждую проверку подлинности.
• Автоматический жизненный цикл: срок действия маркеров истекает по умолчанию; не требуется смена вручную
• Поддержка условного доступа. Применение политик безопасности на уровне организации

Дополнительные сведения об альтернативах аутентификации см. в разделах Аутентификация Microsoft Entra и Субъекты-службы и управляемые удостоверения.

Процесс ротации

Выполните следующие действия, чтобы заменить PAT без прерывания работы служб:

Шаг 1. Создание нового PAT

1. На домашней странице откройте параметры пользователя и выберите личные маркеры доступа.
2. Выберите +Создать маркер.
3. Введите то же имя , что и старый маркер (для простого отслеживания).
4. Установите срок действия до 90 дней с сегодняшнего дня.
5. Выберите те же области , что и старый маркер.
6. Нажмите кнопку "Создать " и скопируйте новый маркер немедленно (он не будет отображаться снова).

Шаг 2. Тестирование нового PAT

Прежде чем вывести старый PAT из эксплуатации, убедитесь, что новый PAT работает:

# For Git (replace with your URL and new PAT)
git clone https://<user>:<new-pat>@dev.azure.com/<org>/<project>/_git/<repo>

# For REST API
curl -u :<new-pat> https://dev.azure.com/<org>/_apis/projects

Шаг 3. Обновление всех интеграции

Для каждой службы или инструмента, использующих старый PAT:

Пример. Обновление переменной конвейера

# Before
- script: npm install
  env:
    NPM_TOKEN: $(old-pat-variable)

# After
- script: npm install
  env:
    NPM_TOKEN: $(new-pat-variable)

Шаг 4. Проверка функциональности

После обновления каждой интеграции проверьте его:

• Запустите конвейерное задание.
• Выполнение скрипта вручную.
• Попробуйте выполнить операцию Git.
• Проверьте вызовы API.

Шаг 5. Отзыв старого PAT

После обновления и тестирования всех интеграции отмените старый PAT:

1. На домашней странице откройте параметры пользователя и выберите личные маркеры доступа.
2. Выберите старый PAT.
3. Выберите "Отменить " и "Подтвердить".

Сценарий ротации: вывод сотрудника из команды

Когда член команды покидает команду:

1. Немедленное действие (день отъезда):

   • Администратор отзывает все PAT из Параметры организации > Безопасность > Токены персонального доступа
   • Администратор проверяет журнал аудита для всех PATS, созданных этим пользователем
   • Любая служба, использующая их PAT, немедленно перестает работать (как и ожидалось)

2. В течение 1 недели:

   • Командам, использующим PAT этого человека, следует перейти на общую служебную учетную запись или новый PAT
   • Обновление всех скриптов, конвейеров и интеграции

3. Продолжающаяся:

   • Еженедельно проверяйте журналы аудита на наличие непривязанных PAT

Автоматизация поворота с помощью API управления жизненным циклом PAT

Для крупномасштабных развертываний измените PATs программным способом:

import requests
from datetime import datetime, timedelta

# 1. Get PAT metadata (using Entra token)
org_url = "https://dev.azure.com/myorg"
entra_token = "YOUR_ENTRA_TOKEN"

response = requests.get(
    f"{org_url}/_apis/tokens/pats",
    headers={"Authorization": f"Bearer {entra_token}"},
    params={"api-version": "7.1-preview.1"}
)
pats = response.json()["value"]

# 2. Find PATs expiring in 7 days
expiring_soon = [
    pat for pat in pats 
    if (datetime.fromisoformat(pat["expiresOn"].replace("Z", "+00:00")) 
        - datetime.now().astimezone()).days <= 7
]

# 3. Create new PATs for expiring ones
for old_pat in expiring_soon:
    new_pat_payload = {
        "displayName": old_pat["displayName"],
        "scope": old_pat["scope"],
        "targetAccounts": old_pat["targetAccounts"],
        "validFrom": datetime.now().isoformat(),
        "validTo": (datetime.now() + timedelta(days=90)).isoformat(),
    }
    
    # Create new PAT
    new_response = requests.post(
        f"{org_url}/_apis/tokens/pats",
        json=new_pat_payload,
        headers={"Authorization": f"Bearer {entra_token}"},
        params={"api-version": "7.1-preview.1"}
    )
    new_pat = new_response.json()
    print(f"Created new PAT: {new_pat['patToken']} (save securely)")
    
    # TODO: Update integrations with new PAT
    # TODO: Test new PAT
    # TODO: Revoke old PAT after verification

print(f"\nRotated {len(expiring_soon)} PATs")

Журнал аудита: отслеживание создания и отзыва PAT

Администраторы организации и группы безопасности должны отслеживать действия PAT для соответствия требованиям, устранения неполадок и обнаружения угроз.

Где найти журналы аудита PAT

Фильтрация событий PAT

В журнале аудита отфильтруйте действия, связанные с PAT:

Чтение записей журнала аудита

Каждая запись журнала аудита содержит следующее:

• Метка времени: когда произошло действие
• Пользователь: кто выполнил действие (или "Система" для автоматического отзыва)
• Событие: тип действия PAT
• Сведения: затронутый идентификатор PAT, область, организация (если она доступна)
• IP-адрес: источник действия (для исследования угроз)

Хранение журнала аудита

• службы Azure DevOps: журналы аудита, сохраненные в течение 90 дней по умолчанию (администраторы могут настроить этот параметр)
• Azure DevOps Server. Политика хранения зависит от конфигурации SQL Server (обычно 1–2 года)

Пример: Расследование осиротевшего PAT

Предположим, вы обнаружили старый PAT, который по-прежнему активен, хотя не должен быть активным:

1. Запишите идентификатор PAT из списка активных маркеров.
2. Выполните поиск в журнале аудита для PatCreated событий с помощью этого идентификатора.
3. Просмотрите запись создания: кто создал ее, когда, в какой организации.
4. Проверка использования: если PatModified или PatRegenerated события существуют, маркер был активным.
5. Проверка отзыва: если событие PatRevoked отсутствует, PAT по-прежнему действителен.
6. Выполните действие: отмените PAT, если он больше не нужен, или уведомите владельца, чтобы повернуть его.

Рекомендации по мониторингу аудита

• Просмотрите события PAT ежемесячно: определите потерянные или подозрительные маркеры.
• Настройте оповещения: если ваша организация использует Azure Monitor, настройте оповещения о событиях PatCreated или PatRevoked.
• Соблюдайте политики хранения: экспортируйте и архивируйте журналы аудита в соответствии с вашими требованиями к соответствию.
• Отслеживание по пользователю: отслеживайте, какие пользователи создают большинство PAT (могут указывать на рискованные методики).
• Изучение аномалий:
  • Непредвиденные PatCreated события за пределами рабочих часов.
  • Несколько PatRevoked событий для одного пользователя (возможное нарушение учетной записи).
  • PatCreated с необычных IP-адресов.

Программный доступ к журналам аудита (REST API)

Администраторы могут запрашивать журнал аудита с помощью REST API:

# List recent audit log events (last 10)
curl -u :<entra-token> \
  "https://dev.azure.com/<org>/_apis/audit/auditlog?api-version=7.1-preview.1" \
  | jq '.value[] | select(.eventType | contains("Pat"))'

Политики истечения срока действия ПАТ организации

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

Дополнительные сведения см. в статье Управление PAT с помощью политик для администраторов.

API управления жизненным циклом PAT

API управления жизненным циклом PAT могут помочь, когда управление большим количеством токенов через пользовательский интерфейс становится нецелесообразным. Управление заменой PAT программным образом также открывает возможность регулярно менять PAT и сократить их срок действия по умолчанию. Вы можете настроить sample Python приложение с помощью клиента Microsoft Entra и организации Azure DevOps.

Некоторые сведения об этих API:

• Microsoft Entra токены доступа требуются для доступа к этому API. Используйте более надежную форму аутентификации при выпуске новых токенов.
• Только пользователи или приложения, использующие поток "от имени пользователя", могут создавать PATs. Приложения, использующие потоки "от имени приложения" или потоки проверки подлинности, которые не выдают маркеры доступа Microsoft Entra недопустимы для использования с этим API. Таким образом, субъекты службы или управляемые удостоверения не могут создавать или управлять PATs.
• Ранее API управления жизненным циклом PAT поддерживали только user_impersonation область, но теперь vso.pats область доступна и является рекомендуемой областью для использования с этими API. Ограничьте все приложения, которые ранее зависели от user_impersonation для вызова этих API.

Использование Azure CLI для управления PAT

Интерфейс az devops командной строки предоставляет команды для управления PATs без написания пользовательских скриптов. Полный справочник по ИНТЕРФЕЙСу командной строки см. в разделе Azure DevOps CLI и вход с помощью PAT.

# List all your PATs
az devops user list

# Create a new PAT with limited scope
az devops token list \
  --organization https://dev.azure.com/myorg \
  --user <user-id>

# Example: Using az devops commands in a rotation script
# Sign in with Entra token (recommended)
az login --use-device-code

# List organization members (for bulk admin operations)
az devops security group membership list \
  --organization https://dev.azure.com/myorg \
  --group-id <admin-group-id>

Использование REST API для автоматической смены

Для крупномасштабного управления PAT используйте конечные точки REST API.

# List all PATs for a user (requires Entra token)
curl -X GET \
  -H "Authorization: Bearer <entra-token>" \
  "https://dev.azure.com/<org>/_apis/tokens/pats?api-version=7.1-preview.1"

# Create a new PAT
curl -X POST \
  -H "Authorization: Bearer <entra-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "displayName": "CI/CD PAT",
    "scope": "vso.build vso.release_manage vso.code_write",
    "validTo": "2026-10-07T00:00:00.000Z"
  }' \
  "https://dev.azure.com/<org>/_apis/tokens/pats?api-version=7.1-preview.1"

# Revoke a PAT by ID
curl -X DELETE \
  -H "Authorization: Bearer <entra-token>" \
  "https://dev.azure.com/<org>/_apis/tokens/pats/<pat-id>?api-version=7.1-preview.1"

Формат PAT

Строки PAT используют определенный формат, предназначенный для улучшения обнаружения секретов в утеченных инструментах обнаружения PAT и предложениях партнеров. Формат включает идентифицируемые биты, которые повышают скорость обнаружения ложноположительных результатов и обеспечивают более быстрое устранение обнаруженных утечек.

• Маркеры имеют длину 84 символов, при этом 52 символа являются случайными данными, что повышает общую энтропию. Токены устойчивы к атакам подбора.
• Маркеры, выданные Azure DevOps, включают фиксированную AZDO сигнатуру в позициях 76-80.

Если вы интегрируете с персональными токенами доступа (PATs) и имеете встроенную проверку PAT, убедитесь, что ваш код проверки соответствовал длине токена в 84 символа.

Рекомендации по использованию PAT

Рассмотрим альтернативные варианты

• Получите токен Microsoft Entra через Azure CLI для незапланированных запросов вместо создания более длительно действующего личного токена доступа (PAT).
• Используйте диспетчеры учетных данных, такие как Git Credential Manager или Azure Artifacts Credential Manager для упрощения управления учетными данными с проверкой подлинности oauth или маркерами Microsoft Entra.

Создание PATov

• Не включайте персональные данные в имя PAT. Не переименовывайте имя PAT так, чтобы в нём фигурировал некоторый или весь фактический токен PAT.
• Избегайте создания глобальных PAT, если это не требуется во всех организациях.
• Используйте другой маркер для каждого потока или варианта использования.
• Выберите только минимальные области, необходимые для каждого PAT. Предоставьте минимальные привилегии, необходимые для конкретной задачи. Создайте отдельные PATs с ограниченными областями для разных рабочих процессов вместо использования одного широкомасштабного токена. Если вашему PAT требуются разрешения только для чтения, не предоставьте разрешения на запись до тех пор, пока не потребуется.
• Держите срок жизни PAT коротким.

Управление персональными токенами доступа (PATs)

• Не делитесь своими PAT!
• Храните свои PAT в безопасном решении для управления ключами, например Azure Key Vault.
• Регулярно обновляйте или регенерируйте ваши PAT через пользовательский интерфейс или с помощью API управления жизненным циклом PAT.
• Аннулируйте PATs, когда они больше не нужны.

Для администраторов

• Администраторы арендатора должны настроить политики, ограничивающие:
  • Создание глобального PAT (требуются токены с областью действия организации)
  • Создание PAT с полным набором областей действия (требуются ограниченные области действия)
  • PAT с длительным сроком действия (принудительное ограничение максимального срока действия до 30–90 дней)
• Администраторы арендатора могут отозвать ПАТ для пользователей организации, если ПАТ скомпрометирован.
• Администраторы организации должны ограничить создание PAT в организации и, по возможности, перенести службы на Microsoft Entra проверку подлинности вместо PAT.

Пошаговое руководство по администраторскому аудиту: управление всеми PAT в вашей организации

Администраторы организации могут проводить аудит и управлять всеми личными маркерами доступа (PAT) во всей организации для обеспечения соблюдения политик безопасности и выявления токенов, представляющих риск.

Шаг 1. Доступ к странице управления PAT организации

Шаг 2. Фильтрация и определение маркеров высокого риска

Найдите:

• Долгосрочные токены (срок действия > 90 дней): кандидаты на ротацию или отзыв
• Токены с полным охватом (область действия = все): высокий риск безопасности; необходимо применять политики ограничения
• Глобальные маркеры (доступ к нескольким организациям): избегайте этих маркеров; рассмотрите альтернативные варианты с областью действия организации
• Неактивные токены (без недавней активности): можно безопасно отозвать
• Токены, созданные в нерабочее время: возможный инцидент безопасности

Шаг 3. Просмотр журнала аудита для событий PAT

1. Перейдите в Настройки организации>Журнал аудита
2. Фильтрация по типу события:
   • PatCreated — найти, когда токены были выданы
   • PatRevoked — Отслеживайте, когда токены были отключены
   • PatRegenerated — мониторинг активности поворота
3. Экспорт журналов аудита для отчетов о соответствии (90-дневное хранение)

Шаг 4: Отзыв скомпрометированных или неиспользуемых токенов

Если вы обнаружили скомпрометированный или ненужный PAT:

1. Перейдите в Параметры организации>Безопасность>Токены личного доступа
2. Выберите все PAT
3. Выберите PAT, который вы хотите отозвать
4. Выберите "Отменить " и подтвердите
5. При необходимости уведомите владельца токена о необходимости создать новый PAT на замену

Шаг 5. Применение политик организации

1. Перейдите в Настройки организации>Политики
2. Настроить:
   • Ограничить создание PAT с полным доступом — Требовать токены с ограниченной областью действия
   • Ограничить создание глобальных PAT — требовать токены с областью действия на уровне организации
   • Задать максимальный срок действия PAT — Пример: срок действия токена не может превышать 90 дней
3. Документируйте политику в руководстве по безопасности или вики-сайте

Пример: массовый отзыв при увольнении

Когда пользователь уходит, отзовите все его PAT:

1. Перейдите в Настройки организации>Безопасность>Токены личного доступа>Все PAT
2. Фильтрация по имени или электронной почте отступающего пользователя
3. Выберите все их PAT
4. Выберите "Отменить " (массовое действие) и подтвердите

Все их PAT-ы немедленно отзываются, что не позволяет какой-либо службе использовать эти учетные данные.

Вопросы и ответы

Q. Почему не удается изменить или повторно создать область PAT, ограниченную одной организацией?

А. Войдите в организацию, в которой определен диапазон действия вашего PAT. Вы можете просматривать Ваши персональные токены доступа (PATs), войдя в любую организацию с тем же Microsoft Entra ID и изменив фильтр Access scope. Войдя в конкретную организацию, можно изменять только токены, привязанные к этой организации.

Q. Что происходит с PAT, если учетная запись пользователя отключена?

А. Когда пользователь удаляется из Azure DevOps, его персональный токен доступа становится недействительным в течение часа. Если ваша организация подключена к Microsoft Entra ID, ПАТ также является недействительным в Microsoft Entra ID поскольку он принадлежит пользователю. Переименуйте токен личного доступа (PAT) на другого пользователя или на учетную запись службы, чтобы обеспечить продолжение работы служб.

Q. Можно ли использовать PATs со всеми Azure DevOps REST API?

А. Нет. Вы можете использовать PATs с большинством REST API Azure DevOps, но организации и профили и API жизненного цикла управления PAT поддерживают только токены Microsoft Entra.

Q. Что произойдет, если случайно проверить свой PAT в общедоступном репозитории на GitHub?

А. Azure DevOps проверяет утечку PAT в общедоступных репозиториях GitHub. При обнаружении Azure DevOps уведомляет владельца токена и регистрирует событие в журнале audit. Если не отключено, утекшие PAT автоматически аннулируются. Дополнительные сведения см. в статье "Автоматическое отзыв утекших персональных токенов доступа (PAT)".

Q. Можно ли использовать личный маркер доступа в качестве ключа API для публикации пакетов NuGet в веб-канале Azure Artifacts с помощью командной строки dotnet/nuget.exe?

А. Нет. Azure Artifacts не поддерживает передачу PAT в качестве ключа API. При использовании локальной среды разработки установите Azure Artifacts Credential Provider для аутентификации в Azure Artifacts. Дополнительные сведения см. в следующих примерах: dotnet и NuGet.exe. Если вы хотите опубликовать свои пакеты, используя Azure Pipelines, используйте задачу NuGet Authenticate для аутентификации с вашим фидом. Дополнительные сведения см. в разделе Публикация пакетов NuGet с использованием Azure Pipelines (YAML/Classic).

Q. Почему мой PAT перестал работать?

А. Проверка подлинности PAT требует регулярного входа в Azure DevOps с помощью полного потока проверки подлинности. Достаточно выполнять вход раз в 30 дней для многих пользователей, но в зависимости от конфигурации Microsoft Entra может понадобиться чаще входить в систему. Если ваш PAT перестает работать, сначала попробуйте войти в свою организацию и выполнить полный запрос проверки подлинности. Если ваш PAT по-прежнему не работает, проверьте, истек ли срок действия.

Для Azure DevOps Server включение IIS базовой проверки подлинности делает использование PAT недействительным. Держите базовую проверку подлинности IIS отключенной.

Q. Как создать маркеры доступа, которые не привязаны к конкретному пользователю?

А. PaTs всегда связаны с удостоверением пользователя, создавшего их. Чтобы использовать маркеры, не привязанные к конкретному пользователю, используйте маркеры Microsoft Entra, выданные прикладным служебным принципалом или управляемым удостоверением. Для конвейеров используйте подключения службы для проверки подлинности без учетных данных пользователя. Дополнительные сведения о редукции использования PAT в Azure DevOps.

Q. Как пересоздать или ротировать PAT с помощью API? Я видел этот параметр в пользовательском интерфейсе, но в API не отображается аналогичный метод.

А. Функция повторного создания в пользовательском интерфейсе фактически выполняет несколько действий, которые можно реплицировать через API.

Чтобы повернуть PAT, выполните следующие действия.

1. Получение метаданных PAT с помощью вызова GET .
2. Создайте новый PAT с помощью вызова POST с старым идентификатором PAT.
3. Отмените старый PAT с помощью вызова DELETE .

Q. Сколько времени истекшие, аннулированные или неактивные токены PAT остаются видимыми в списке токенов Azure DevOps?

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

Q. Почему при попытке использовать приложение Microsoft Entra для вызова API управления жизненным циклом PAT отображается сообщение "Требуется утверждение администратора"?

А. Политики безопасности клиента требуют согласия администратора, прежде чем приложения смогут получить доступ к ресурсам организации. Обратитесь к администратору клиента.

Использование ИИ для управления личными маркерами доступа

Если вы настроите Azure DevOps MCP Server, вы можете использовать помощники по искусственному интеллекту для управления и проверки личных маркеров доступа с помощью запросов на естественном языке. Сервер MCP предоставляет помощнику по искусственному интеллекту безопасный доступ к данным Azure DevOps, чтобы вы могли перечислять маркеры, проверять даты окончания срока действия и просматривать области маркеров без перехода по веб-интерфейсу.

Примеры подсказок для управления личными токенами доступа

Связанный контент

• Доступ к Azure DevOps с помощью идентификатора Microsoft Entra для рабочей нагрузки
• Отмена пользовательских PATS (для администраторов)
• Аутентифицируйтесь с помощью токенов Microsoft Entra