Учебник: Внедрение стандартов для секретов и сертификатов с помощью политик управления приложениями

В этом руководстве вы узнаете, как внедрять стандарты секретов и сертификатов, используя политики управления приложениями в Microsoft Entra ID.

Обеспечение того, чтобы приложения в вашей организации использовали безопасную проверку подлинности, крайне важны для защиты конфиденциальных данных и обеспечения целостности систем. Идентификатор Microsoft Entra позволяет применять ограничения секретов и сертификатов с помощью политик управления приложениями. Эта функция поможет вам управлять тем, какие типы секретов и ключей могут использоваться, и убедиться, что они регулярно обновляются. Политики управления приложениями можно обновлять только с помощью Microsoft Graph PowerShell или API Microsoft Graph. Дополнительные сведения об этой функции см. в обзоре API политик управления приложениями Microsoft Entra.

Политики можно применять ко всем приложениям в организации или к определенным приложениям. Из этого руководства вы узнаете:

Предпосылки

• Учетная запись пользователя. Если у вас еще нет учетной записи, вы можете создать учетную запись бесплатно.
• По крайней мере роль администратора облачных приложений или администратора приложений .
• Клиент API, например Обозреватель GraphИЛИ
• Установленный модуль Microsoft Graph PowerShell. См. раздел "Установка модуля Microsoft Graph PowerShell".

Рекомендации по секретам и сертификатам

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

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

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

• Ограничение времени существования асимметричного ключа (сертификата) до 180 дней: сертификаты обеспечивают более безопасный способ проверки подлинности приложений, чем секреты клиента. Однако они по-прежнему могут быть скомпрометированы, если они не управляются должным образом. Ограничив время существования сертификатов, вы можете снизить риск использования долгосрочных сертификатов злоумышленниками. Сертификаты следует регулярно поворачивать, чтобы гарантировать, что они не скомпрометированы. Рекомендуемое максимальное время существования сертификатов — 180 дней. Это означает, что следует сменить сертификаты по крайней мере каждые 180 дней. Настройка более короткого времени существования для приложений с высокой степенью конфиденциальности может снизить риск компрометации. Мы также рекомендуем настроить автоматическую смену сертификатов с помощью Azure Key Vault. Дополнительные сведения см. в статье Автоматизации смены секрета для ресурсов, использующих один набор учетных данных проверки подлинности.

Дополнительные сведения о рекомендуемых методиках безопасности для клиентов Microsoft Entra см. в статье "Настройка Microsoft Entra" для повышения безопасности.

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

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

Пример

В следующем примере считывается политика управления приложениями по умолчанию для клиента. В ответе показаны текущие параметры политики.

Connect-MgGraph -Scopes 'Policy.Read.All'
# Get the default application management policy
Get-MgPolicyDefaultAppManagementPolicy | format-list

ApplicationRestrictions      : Microsoft.Graph.PowerShell.Models.MicrosoftGraphAppManagementApplicationConfiguration
DeletedDateTime              :
Description                  : Default tenant policy that enforces app management restrictions on applications and service principals. To apply policy to targeted resources, create a new policy under appManagementPolicies collection.
DisplayName                  : Default app management tenant policy
Id                           : 00000000-0000-0000-0000-000000000000
IsEnabled                    : false
ServicePrincipalRestrictions : Microsoft.Graph.PowerShell.Models.MicrosoftGraphAppManagementServicePrincipalConfiguration
AdditionalProperties         : {[@odata.context, https://graph.microsoft.com/v1.0/$metadata#policies/defaultAppManagementPolicy/$entity]}

GET https://graph.microsoft.com/v1.0/policies/defaultAppManagementPolicy

HTTP/1.1 200 OK
Content-type: application/json

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#policies/defaultAppManagementPolicy/$entity",
    "@odata.id": "https://graph.microsoft.com/v2/927c6607-8060-4f4a-a5f8-34964ac78d70/defaultAppManagementPolicy/00000000-0000-0000-0000-000000000000",
    "id": "00000000-0000-0000-0000-000000000000",
    "displayName": "Default app management tenant policy",
    "description": "Default tenant policy that enforces app management restrictions on applications and service principals. To apply policy to targeted resources, create a new policy under appManagementPolicies collection.",
    "isEnabled": false,
    "applicationRestrictions": {
        "passwordCredentials": [],
        "keyCredentials":[]
    },
    "servicePrincipalRestrictions": {
        "passwordCredentials": [],
        "keyCredentials":[]
    }
}

Обновление политики управления приложениями

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

• passwordCredentials: позволяет задать политики, чтобы ограничить атрибуты секретов клиента и симметричные ключи. Это может быть опущено, если вы не хотите задать политику, чтобы ограничить эти типы учетных данных.

  • Параметр restrictionType позволяет задать тип ограничения, которое необходимо применить. В этом случае вы ограничиваете passwordAddition, customPasswordAdditionи symmetricKeyAddition. Эти параметры ограничивают создание секретов клиента, пользовательских паролей и симметричные ключи.

  • Параметр state позволяет включить или отключить ограничение. Если задано значение enabled, ограничение будет применено. Если задано значение disabled, ограничение не будет применено.

  • Параметр maxLifetime позволяет задать максимальное время существования секрета. Для passwordCredentials параметра задано значение null. Установка значения null означает, что максимальное время существования не ограничено. Это связано с тем, что вы полностью отключите создание секретов клиента и симметричные ключи. Если вы хотите задать максимальное время существования секретов клиента, можно задать это значение в формате ISO 8601. Пример этого вы найдете в следующем разделе. Дополнительные сведения о форматировании длительности см. в статье ISO 8601.

  • Параметр restrictForAppsCreatedAfterDateTime позволяет задать дату, с которой политика вступит в силу для новых приложений. Все приложения, созданные до этой даты, не будут затронуты политикой. В этом случае вы применяете ограничения для приложений, созданных после 20 февраля 2025 года. Убедитесь, что вы обновляете эту дату в соответствии с вашими потребностями. Если вы хотите задать различные ограничения для приложений, созданных до или после определенной даты, можно задать несколько политик с различными restrictForAppsCreatedAfterDateTime значениями.

• keyCredentials: позволяет задать параметры для сертификатов. В этом случае вы ограничиваете срок действия сертификатов приложений до 180 дней.

  • Параметр restrictionType позволяет задать тип ограничения, которое необходимо применить. В этом случае вы ограничиваете asymmetricKeyLifetime. Это приведет к ограничению времени существования сертификатов приложения на определяемое пользователем значение.

  • Параметр state позволяет включить или отключить ограничение. Если задано значение enabled, ограничение будет применено. Если задано значение disabled, ограничение не будет применено.

  • Параметр maxLifetime позволяет задать максимальное время существования сертификата. В этом случае вы ограничиваете время существования сертификатов до 180 дней. Это делается с помощью формата длительности ISO 8601. Префикс P указывает, что значение равно периоду времени и 180D указывает, что период составляет 180 дней. Вы можете изменить число с 180 на другое значение, чтобы оно соответствовало вашим конкретным потребностям. Дополнительные сведения о форматировании длительности см. в iso 8601.

  • Параметр restrictForAppsCreatedAfterDateTime позволяет задать дату, с которой политика вступит в силу для новых приложений. Все приложения, созданные до этой даты, не будут затронуты политикой. В этом случае вы применяете ограничения для приложений, созданных после 20 февраля 2025 года. Убедитесь, что вы обновляете эту дату в соответствии с вашими потребностями. Если вы хотите задать различные ограничения для приложений, созданных до или после определенной даты, можно задать несколько политик с различными restrictForAppsCreatedAfterDateTime значениями.

Пример

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

Connect-MgGraph -Scopes 'Policy.ReadWrite.All'
Import-Module Microsoft.Graph.Identity.SignIns
# Define the parameters for the application management policy
$params = @{
isEnabled = $true
applicationRestrictions = @{
    passwordCredentials = @(
        @{
            restrictionType = "passwordAddition"
            state = "enabled"
            maxLifetime = $null
            restrictForAppsCreatedAfterDateTime = [System.DateTime]::Parse("2025-02-20T10:37:00Z")
        }
        @{
            restrictionType = "customPasswordAddition"
            state = "enabled"
            maxLifetime = $null
            restrictForAppsCreatedAfterDateTime = [System.DateTime]::Parse("2025-05-20T10:37:00Z")
        }
        @{
            restrictionType = "symmetricKeyAddition"
            state = "enabled"
            maxLifetime = $null
            restrictForAppsCreatedAfterDateTime = [System.DateTime]::Parse("2025-02-20T10:37:00Z")
        }
    )
    keyCredentials = @(
        @{
            restrictionType = "asymmetricKeyLifetime"
            maxLifetime = "P180D"
            restrictForAppsCreatedAfterDateTime = [System.DateTime]::Parse("2025-02-20T10:37:00Z")
        }
    )
}
}
# Update the default application management policy
Update-MgPolicyDefaultAppManagementPolicy -BodyParameter $params

PATCH https://graph.microsoft.com/v1.0/policies/defaultAppManagementPolicy
Content-Type: application/json

{
    "isEnabled": true,
    "applicationRestrictions": {
        "passwordCredentials": [
            {
                "restrictionType": "passwordAddition",
                "state": "enabled",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2025-02-20T10:37:00Z"
            },
            {
                "restrictionType": "customPasswordAddition",
                "state": "enabled",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2025-05-20T10:37:00Z"
            },
            {
                "restrictionType": "symmetricKeyAddition",
                "state": "enabled",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2025-02-20T10:37:00Z"
            },
        ],
        "keyCredentials": [
            {
                "restrictionType": "asymmetricKeyLifetime",
                "state": "enabled",
                "maxLifetime": "P180D",
                "restrictForAppsCreatedAfterDateTime": "2025-02-20T10:37:00Z"
            }
        ]
    },
}

    HTTP/1.1 204 No Content

Подтверждение применения политики

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

Если вы впервые применяете политику управления приложениями, поле id должно было измениться с 00000000-0000-0000-0000-000000000000 на новый GUID. Это изменение свидетельствует о создании политики.

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

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

• Сведения о других способах реализации этой политики см. в статье "Настройка ограничений на настройку приложений"
• Чтобы узнать, как автоматизировать смену секретов, см. раздел "Автоматизация смены секрета" для ресурсов, использующих один набор учетных данных проверки подлинности.
• Дополнительные сведения о доступных ограничениях и параметрах политики см. в обзоре API политик управления приложениями Microsoft Entra
• Дополнительные сведения о рекомендациях по обеспечению безопасности для вашей организации см. в статье"Настройка Microsoft Entra" для повышения безопасности.
• Дополнительные сведения о альтернативах проверке подлинности с помощью секретов см. в статье "Миграция приложений от проверки подлинности на основе секретов"