Microsoft.Identity.Web을 사용하여 인증서 없는 인증을 구성합니다.

이 문서에서는 인증서 또는 클라이언트 비밀을 관리하지 않고 애플리케이션이 Microsoft Entra ID 인증하도록 인증서 없는 인증을 구성하는 방법을 보여 줍니다. 앱은 Azure 관리 ID에서 지원되는 페더레이션 ID 자격 증명(FIC)을 사용하여 토큰을 얻습니다. 이 토큰은 자격 증명 회전을 제거하고 비밀 스프롤을 줄이며 Azure 배포를 간소화합니다.

Microsoft. Identity.Web은 버전 2.12.0 이상에서 사용할 수 있는 SignedAssertionFromManagedIdentity 자격 증명 원본 유형을 통해 인증서 없는 인증을 지원합니다.

인증서 없는 인증 이해

이 섹션에서는 인증서 없는 인증의 작동 방식과 사용 시기에 대해 설명합니다.

일반적으로 기밀 클라이언트 애플리케이션은 클라이언트 암호 또는 인증서를 제시하여 Microsoft Entra ID 자신의 ID를 증명합니다. 두 방법 모두 만료되기 전에 비밀을 회전하고 인증서를 갱신하며 안전하게 저장하는 자격 증명 수명 주기를 관리해야 합니다.

FIC(페더레이션 ID 자격 증명)가 이 모델을 변경합니다. FIC를 사용하면 앱 등록과 관리 ID 간에 트러스트 관계를 구성합니다. 애플리케이션이 인증해야 하는 경우:

  1. Microsoft. Identity.Web은 Azure 호스트의 관리 ID 엔드포인트에서 토큰을 요청합니다.
  2. 라이브러리는 관리 ID 토큰을 서명된 어설션으로 사용하여 Microsoft Entra ID 인증합니다.
  3. Microsoft Entra ID 앱 등록에서 페더레이션 자격 증명 구성에 대해 서명된 어설션의 유효성을 검사합니다.
  4. Microsoft Entra ID 요청된 리소스에 대한 액세스 토큰을 발급합니다.

그 결과 구성, 코드 또는 환경 변수에 비밀이나 인증서가 없는 완전 자격 증명이 없는 배포가 생성됩니다.

올바른 인증 방법 선택

다음 표에서는 인증서 없는 인증이 적합한 시기를 결정하는 데 도움이 됩니다.

시나리오 권장 방법
앱은 Azure에서 실행되며 자격 증명 관리가 필요하지 않습니다. FIC를 사용하여 인증서가 필요 없는
앱은 Azure 실행되지만 온-프레미스 대체를 지원해야 합니다. FIC를 기본으로 사용하는 인증서 기반 자격 증명
앱은 Azure 외부에서 실행됩니다(온-프레미스, 기타 클라우드) 인증서 또는 클라이언트 비밀
로컬 컴퓨터에서 개발 및 테스트 로컬 저장소의 클라이언트 비밀 또는 인증서

사전 요구 사항

시작하기 전에 다음 리소스 및 도구가 있는지 확인합니다.

  • Azure 구독. 아직 없는 경우 무료 계정을 만들 수 있습니다.
  • 시나리오에 필요한 API 권한이 있는 Microsoft Entra ID app 등록.
  • Azure에서 관리 ID는 컴퓨팅 리소스에 시스템이 할당한 관리 ID이거나 독립 사용자 할당 관리 ID일 수 있습니다.
  • Microsoft. Identity.Web 버전 2.12.0 이상이 프로젝트에 설치되어 있습니다.
  • Azure App Service, AKS(Azure Kubernetes Service), Azure Container Apps 또는 Azure Virtual Machines 같은 관리 ID를 지원하는 Azure 컴퓨팅 리소스입니다.

1단계: 관리 ID 만들기 또는 식별

시스템 할당 또는 사용자 할당 관리 ID를 사용할 수 있습니다. 아직 만들지 않은 경우 시나리오에 대한 지침을 따르세요.

옵션 A: 시스템 할당 관리 ID 사용

시스템 할당 관리 ID는 Azure 리소스의 수명 주기에 연결됩니다. App Service와 같은 리소스에서 시스템 할당 ID를 사용하도록 설정하면 Azure 자동으로 ID를 만듭니다.

  1. Azure 포털 컴퓨팅 리소스(예: App Service)로 이동합니다.
  2. 왼쪽 탐색 메뉴에서 ID 를 선택합니다.
  3. 시스템 할당 탭에서 상태를 켜짐으로 설정합니다.
  4. 저장을 선택하고 작업을 확인합니다.
  5. ID를 생성한 후 개체(보안 주체) ID를 복사합니다. 페더레이션 자격 증명을 구성할 때 이 값이 필요합니다.

옵션 B: 사용자 할당 관리 ID 만들기

사용자 할당 관리 ID는 하나 이상의 컴퓨팅 리소스에 할당할 수 있는 독립 실행형 Azure 리소스입니다.

  1. Azure 포털에서 관리 ID 검색하여 선택합니다.
  2. 선택하고생성합니다.
  3. 구독, 리소스 그룹, 지역을 선택하고 ID의 이름을 입력합니다.
  4. 검토 + 만들기를 선택한 다음, 만들기를 선택합니다.
  5. 배포가 완료되면 새 관리 ID 리소스를 엽니다.
  6. 개요 페이지에서 클라이언트 ID를 복사합니다. 애플리케이션 구성에 이 값이 필요합니다.

2단계: Azure 포털에서 페더레이션 ID 자격 증명 구성

페더레이션 ID 자격 증명은 앱 등록과 관리 ID 간에 트러스트 관계를 설정합니다. 다음 단계에 따라 하나를 만듭니다.

  1. Azure 포털Microsoft Entra ID>앱 등록로 이동합니다.

  2. 애플리케이션에서 사용하는 앱 등록을 선택합니다.

  3. 왼쪽 탐색 메뉴에서 인증서 및 비밀을 선택합니다.

  4. 페더레이션 증명 탭을 선택합니다.

  5. 자격 증명 추가를 선택합니다.

  6. 페더레이션 자격 증명 시나리오에서 고객 관리형 키 또는 기타 발급자를 선택합니다(사용 가능한 옵션은 포털 버전에 따라 다름).

  7. 다음 필드를 구성하세요.

    분야 가치
    발급자 https://login.microsoftonline.com/{tenant-id}/v2.0 — {tenant-id} Microsoft Entra 테넌트 ID로 대체합니다.
    주체 식별자 관리 ID의 개체(보안 주체) ID 입니다. 시스템 할당의 경우 리소스의 ID 페이지에서 이 항목을 찾습니다. 사용자 할당의 경우 관리된 ID의 개요 페이지에서 주체 ID 아래에서 이 ID를 찾습니다.
    이름 설명용 이름, 예를 들어 fic-managed-identity-prod.
    청중 api://AzureADTokenExchange (기본값).

  8. 추가를 선택합니다.

중요합니다

주체 식별자는 관리 ID의 개체(주체) ID와 정확히 일치해야 합니다. 불일치로 인해 오류가 발생하여 인증이 실패합니다 AADSTS70021 .

Azure CLI 사용하여 페더레이션 ID 자격 증명 구성

또는 Azure CLI 사용하여 페더레이션 자격 증명을 만듭니다. 다음 명령은 앱 등록에 자격 증명을 만듭니다.

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

Azure 서비스별 발급자 URL

페더레이션 자격 증명의 발급자 URL은 애플리케이션을 호스트하는 Azure 서비스에 따라 달라집니다.

Azure 서비스 발급자 URL
Azure App Service/Azure Functions https://login.microsoftonline.com/{tenant-id}/v2.0
Azure Container Apps https://login.microsoftonline.com/{tenant-id}/v2.0
AKS(Azure Kubernetes Service) 클러스터의 OIDC 발급자 URL(명령을 통해 가져오기 az aks show --query oidcIssuerProfile.issuerUrl)
Azure Virtual Machines https://login.microsoftonline.com/{tenant-id}/v2.0

주체 식별자 형식

주체 식별자의 형식은 관리 ID 유형에 따라 달라집니다.

시스템 할당 관리 ID — 리소스의 ID 페이지에서 개체(주체) ID를 사용합니다. 예를 들어 a1b2c3d4-e5f6-7890-abcd-ef1234567890GUID 값입니다.

사용자가 할당한 관리 ID — 관리 ID 리소스의 개요 페이지에서 주체 ID(개체 ID라고도 함)를 사용하십시오. GUID 값이기도 합니다.

메모

워크로드 ID가 있는 AKS의 경우 주체 식별자는 다른 형식 system:serviceaccount:{namespace}:{service-account-name}을 사용합니다. 이 값은 Pod에서 사용하는 Kubernetes 서비스 계정과 일치해야 합니다.

3단계: 애플리케이션 구성

업데이트 appsettings.json

ClientCredentials 섹션을 AzureAd 구성에 추가합니다. SourceType을(를) SignedAssertionFromManagedIdentity으로 설정합니다.

사용자 할당 관리 ID의 경우

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

다음 자리 표시자를 바꿉니다.

Placeholder 설명
YOUR_TENANT_ID 당신의 Microsoft Entra 테넌트 ID입니다.
YOUR_CLIENT_ID 앱 등록의 애플리케이션(클라이언트) ID입니다.
USER_ASSIGNED_MSI_CLIENT_ID 사용자가 할당한 관리 ID의 클라이언트 ID(ID 개요 페이지)입니다.

시스템 할당 관리 ID의 경우

시스템 할당 관리 ID를 사용하는 경우 속성을 생략합니다 ManagedIdentityClientId . Microsoft. Identity.Web은 자동으로 호스트의 시스템 할당 ID를 사용합니다.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Program.cs 서비스 등록

시작 구성에는 특별한 코드 변경이 필요하지 않습니다. 표준 Microsoft. Identity.Web 등록 메서드는 ClientCredentials 섹션을 자동으로 읽습니다.

다음 예제에서는 사용자를 로그인하고 다운스트림 API를 호출하는 웹앱에 대한 인증을 등록합니다.

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

다음 예제에서는 다운스트림 API를 호출하는 웹 API에 대한 인증을 등록합니다.

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

다음 예제에서는 사용자 상호 작용 없이 디먼 애플리케이션에 대한 인증을 등록합니다.

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web은 SignedAssertionFromManagedIdentity 소스 형식을 검색하고 토큰 교환을 투명하게 처리합니다.

시스템 할당 및 사용자 할당 관리 ID 비교

아키텍처에 가장 적합한 관리 ID 유형을 선택합니다. 다음 섹션에서는 장단분에 대해 간략하게 설명합니다.

시스템 할당 관리 ID

시스템 할당 ID는 속한 Azure 리소스를 사용하여 자동으로 만들어지고 삭제됩니다.

장점:

  • 관리할 별도의 리소스가 없습니다. ID 수명 주기는 컴퓨팅 리소스와 일치합니다.
  • 단일 리소스 배포를 위한 더 간단한 설정입니다.
  • 구성에 ManagedIdentityClientId 이/가 필요하지 않습니다.

Considerations:

  • 여러 리소스에서 ID를 공유할 수 없습니다.
  • 리소스를 삭제하고 다시 만드는 경우 ID가 변경됩니다. 페더레이션 ID 자격 증명을 업데이트해야 합니다.

최적 대상: 하나의 컴퓨팅 리소스가 하나의 앱 등록에 매핑되는 단일 인스턴스 배포입니다.

사용자가 할당한 관리 ID

사용자 할당 ID는 자체 수명 주기가 있는 독립 실행형 Azure 리소스입니다.

장점:

  • 여러 컴퓨팅 리소스(예: 다른 지역의 여러 App Service 인스턴스)에서 단일 ID를 공유합니다.
  • ID는 컴퓨팅 리소스 수명 주기와 독립적으로 유지됩니다.
  • 컴퓨팅 리소스를 배포하기 전에 미리 만들고 미리 구성합니다.

Considerations:

  • 관리할 추가 Azure 리소스입니다.
  • 구성을 ManagedIdentityClientId에 지정해야 합니다.

최적 대상: 다중 인스턴스 또는 다중 지역 배포, 청록색 배포 패턴 및 컴퓨팅 리소스가 자주 다시 만들어지는 시나리오.

Azure 컴퓨팅 서비스에 배포

애플리케이션을 구성한 후 관리 ID를 지원하는 Azure 컴퓨팅 서비스에 배포합니다.

Azure App Service

  1. App Service에서 관리 ID를 사용하도록 설정합니다( 1단계 참조).

  2. 원하는 방법(Visual Studio, Azure CLI, GitHub Actions)을 사용하여 App Service에 애플리케이션을 배포합니다.

  3. 배포된 구성의 AzureAd 섹션이 3단계의 설정과 일치하는지 확인합니다.

  4. 사용자가 할당한 관리 ID를 사용하는 경우 App Service에 할당합니다.

    az webapp identity assign \
  --resource-group <resource-group> \
  --name <app-service-name> \
  --identities <managed-identity-resource-id>

  5. App Service를 다시 시작하여 ID 할당을 선택합니다.

AKS(Kubernetes 서비스) Azure

AKS의 경우 워크로드 ID를 사용하여 Kubernetes 서비스 계정을 관리 ID와 연결합니다. 다음 단계를 완료합니다.

  1. AKS 클러스터에서 워크로드 ID 기능을 사용하도록 설정합니다.

    az aks update \
  --resource-group <resource-group> \
  --name <aks-cluster-name> \
  --enable-oidc-issuer \
  --enable-workload-identity

  2. 관리 ID 클라이언트 ID로 주석이 추가된 Kubernetes 서비스 계정을 만듭니다.

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"

  3. AKS OIDC 발급자를 관리 ID에 연결하는 페더레이션 자격 증명을 만듭니다.

  4. 서비스 계정을 사용하도록 Pod를 구성합니다.

    apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: default
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: my-app
      image: <your-container-image>

  5. Pod를 배포합니다. 워크로드 ID 웹후크는 관리 ID 토큰 엔드포인트에 필요한 환경 변수를 삽입합니다.

Azure Container Apps

  1. 관리 ID를 사용하여 컨테이너 앱을 만들거나 업데이트합니다.

    az containerapp identity assign \
  --resource-group <resource-group> \
  --name <container-app-name> \
  --user-assigned <managed-identity-resource-id>

  2. 적절한 AzureAd 구성으로 컨테이너 이미지를 배포합니다.

  3. 관리 ID 토큰 엔드포인트는 컨테이너 내에서 자동으로 사용할 수 있습니다.

인증서에서 인증서 없는 인증으로 마이그레이션

애플리케이션에서 현재 인증서 기반 인증을 사용하는 경우 최소한의 구성 변경으로 인증서 없는 인증으로 마이그레이션할 수 있습니다.

마이그레이션 단계 완료

  1. Azure 컴퓨팅 리소스에 대한 관리 ID 만들기(Step 1 참조).

  2. 앱 등록에 페더레이션 ID 자격 증명을 추가합니다(2단계 참조).

  3. 자격 증명을 추가하도록 구성을 SignedAssertionFromManagedIdentity 업데이트합니다. 마이그레이션 중에 기존 인증서 자격 증명을 대체로 유지할 수 있습니다.

    {
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      },
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

    Microsoft. Identity.Web은 자격 증명 원본을 순서대로 시도합니다. Azure 실행하면 첫 번째 자격 증명(SignedAssertionFromManagedIdentity)이 성공합니다. 실패하는 경우(예: 로컬 개발 중) 라이브러리는 인증서로 대체됩니다.

  4. 프로덕션 환경에 적용하기 전에 스테이징 환경에서 배포하고 유효성을 검사합니다.

  5. 인증서 없는 인증이 프로덕션 환경에서 작동하는지 확인한 후 구성에서 인증서 자격 증명을 제거합니다.

  6. 더 이상 필요하지 않은 경우 Azure Key Vault 및 앱 등록에서 인증서를 삭제합니다.

구성 전후 비교

다음 예제에서는 인증서 기반 인증에서 인증서 없는 인증으로 구성 변경을 보여 줍니다.

이전(인증서 기반):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

이후(인증서 없는 경우):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

일반적인 오류 해결 방법

다음 지침을 사용하여 인증서 없는 인증 문제를 진단하고 해결합니다.

AADSTS70021: 일치하는 페더레이션 ID 레코드를 찾을 수 없음

원인: 페더레이션 ID 자격 증명의 주체 식별자가 관리 ID의 개체(보안 주체) ID와 일치하지 않습니다.

해결 방법:

  1. Azure 포털에서 관리 ID 리소스로 이동하고 Principal ID(개체 ID라고도 함)를 Overview 페이지에서 복사합니다.
  2. 앱 등록 >인증서 및 비밀>페더레이션 자격 증명으로 이동합니다.
  3. 주체 식별자 필드가 주체 ID와 정확히 일치하는지 확인합니다.
  4. 값이 일치하지 않는 경우 자격 증명을 삭제하고 올바른 주체 식별자를 사용하여 다시 만듭니다.

AADSTS700024: 클라이언트 어설션이 유효한 시간 범위 내에 있지 않습니다.

원인: 서명된 어설션으로 사용되는 관리 ID 토큰이 만료되었거나 시스템 클록이 왜곡되었습니다.

해결 방법:

  • Azure 리소스의 시스템 시계가 정확한지 확인합니다.
  • 애플리케이션을 다시 시작하여 새 관리 ID 토큰 요청을 강제로 적용합니다.
  • 컨테이너에서 실행하는 경우 컨테이너의 시계가 호스트와 동기화되었는지 확인합니다.

ManagedIdentityException: 관리 ID 엔드포인트를 사용할 수 없음

Cause: 애플리케이션이 AZURE IMDS(인스턴스 메타데이터 서비스) 또는 관리 ID 토큰 엔드포인트에 연결할 수 없습니다.

해결 방법:

  • 애플리케이션이 관리 ID를 지원하는 Azure 컴퓨팅 리소스에서 실행되고 있는지 확인합니다.
  • 관리 ID가 사용하도록 설정되고 컴퓨팅 리소스에 할당되었는지 확인합니다.
  • AKS의 경우, 워크로드 아이덴티티 웹훅이 실행 중이고 Pod에 올바른 서비스 계정 주석이 있는지 확인하십시오.
  • 로컬 개발 시에는 이 오류가 예상됩니다. 대체 자격 증명 원본을 사용합니다( 마이그레이션 단계 참조).

AADSTS700016: 디렉터리에서 애플리케이션을 찾을 수 없음

원인:ClientId 구성에서 지정된 테넌트의 유효한 앱 등록과 일치하지 않습니다.

해결 방법:

  • 앱 등록의 ClientId애플리케이션(클라이언트) ID 와 일치하는지 확인합니다.
  • 앱이 등록된 테넌트와 TenantId가 일치하는지 확인합니다.

디버그 로깅 활성화

원인: 자격 증명 원본 순서 또는 구성이 일치하지 않을 경우 라이브러리가 FIC 자격 증명을 건너뛸 수 있습니다.

해결 방법:

  1. Microsoft 로깅을 사용하도록 설정합니다. 자세한 토큰 획득 단계를 보려면 Identity.Web을 참조하세요. 다음 코드는 ID 라이브러리에 대한 디버그 수준 로깅을 구성합니다.

    builder.Services.AddLogging(logging =>
{
    logging.AddConsole();
    logging.SetMinimumLevel(LogLevel.Debug);
    logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
});

  2. 라이브러리가 시도한 자격 증명 원본 및 반환된 오류에 대한 메시지에 대한 로그를 검토합니다.

사용자 할당 관리 ID가 인식되지 않음

원인: 여러 사용자가 할당한 관리 ID를 컴퓨팅 리소스에 할당하는 경우 라이브러리가 지정되지 않은 경우 ManagedIdentityClientId 잘못된 ID를 사용할 수 있습니다.

해결 방법:

  • 사용자가 할당한 ManagedIdentityClientId 관리 ID를 사용하는 경우 항상 속성을 지정합니다.
  • 클라이언트 ID가 페더레이션 ID 자격 증명을 구성한 ID와 일치하는지 확인합니다.

보안 혜택 검토

FIC를 사용한 인증서 없는 인증은 기존 자격 증명 기반 접근 방식에 비해 상당한 보안 이점을 제공합니다.

누출 비밀 없음

구성 또는 배포 아티팩트에서 인증서 파일, PFX 암호 또는 클라이언트 비밀이 없으므로 공격자가 추출할 항목이 없습니다. 공격자가 구성 파일에 대한 읽기 액세스 권한을 얻더라도 Azure 외부에서 애플리케이션을 가장할 수 없습니다.

자격 증명 갱신 불가

관리 ID 토큰은 수명이 짧고 Azure 플랫폼에서 자동으로 새로 고쳐집니다. 배포에서 회전 일정을 구현하거나, 만료 날짜를 모니터링하거나, 자격 증명 업데이트를 조정할 필요가 없습니다.

공격 노출 영역 감소

관리 ID 토큰 엔드포인트는 ID가 할당된 특정 Azure 리소스에서만 액세스할 수 있습니다. 공격자는 다른 호스트, 네트워크 또는 클라우드 환경의 자격 증명을 사용할 수 없습니다.

규정 준수 간소화

수명이 긴 자격 증명이 없으면 다음과 같은 여러 범주의 규정 준수 문제를 제거할 수 있습니다.

  • 소스 제어, 환경 변수 또는 구성 파일에 저장된 비밀이 없습니다.
  • 감사하거나 교체하거나 폐기할 키 자료가 없습니다.
  • 유지 관리할 인증서 인프라(CA, 갱신 프로세스)가 없습니다.

심층 방어

계층화된 보호를 위해 인증서 없는 인증을 다른 Azure 보안 기능과 결합합니다.

  • Azure RBAC: 리소스에 액세스할 수 있는 ID를 제어합니다.
  • 조건부 액세스: ID 위험, 위치 및 디바이스 상태에 따라 정책을 적용합니다.
  • 프라이빗 엔드포인트: Azure 리소스에 대한 네트워크 액세스를 제한합니다.
  • 클라우드용 Microsoft Defender: 의심스러운 인증 패턴을 모니터링합니다.

관련 콘텐츠

  • Last updated on