API Protection

개발자가 API를 보호하는 경우 권한 부여에 중점을 집니다. 리소스의 API를 호출하려면 애플리케이션이 애플리케이션 권한 부여를 획득해야 합니다. 리소스 자체는 권한 부여를 적용해야 합니다. 이 문서에서는 등록을 통해 API를 보호하고, 사용 권한 및 동의를 정의하고, 제로 트러스트 목표를 달성하기 위해 액세스를 적용하는 모범 사례를 알아봅니다.

보호된 API 등록

Microsoft Entra ID(Microsoft Entra ID)로 API를 보호하려면 먼저 API를 등록한 후 등록된 API를 관리할 수 있습니다. Microsoft Entra ID에서 API는 다른 애플리케이션에 액세스 권한을 부여할 수 있는 리소스 또는 API로 정의하는 특정 앱 등록 설정이 있는 앱입니다. Microsoft Entra 관리 센터에서 microsoft Identity Developer( 앱 등록)는 Microsoft Entra ID가 보호하는 API가 있는 SaaS 공급자의 서비스 또는 기간 업무 API로 테넌트에 있는 API입니다.

등록하는 동안 호출 애플리케이션이 API 및 위임된및 애플리케이션 권한을 참조하는 방법을 정의합니다. 앱 등록은 클라이언트 애플리케이션과 API가 모두 있는 솔루션을 나타낼 수 있습니다. 그러나 이 문서에서는 독립 실행형 리소스가 API를 노출하는 시나리오를 다룹니다.

일반적으로 API는 인증을 수행하거나 직접 권한 부여를 요청하지 않습니다. API는 호출 앱이 제공하는 토큰의 유효성을 검사합니다. API에는 대화형 로그인이 없으므로 리디렉션 URI 또는 애플리케이션 유형과 같은 설정을 등록할 필요가 없습니다. API는 Microsoft Entra ID와 상호 작용하지 않고 해당 API를 호출하는 애플리케이션에서 해당 토큰을 가져옵니다. 웹 API의 경우 권한 부여를 위해 OAuth2 액세스 토큰을 사용합니다. 웹 API는 전달자 토큰의 유효성을 검사하여 호출자에게 권한을 부여합니다. ID 토큰을 사용 권한 증명으로 허용하지 않습니다.

기본적으로 Microsoft Entra ID는 새 앱 등록의 API 권한에 추가됩니다 User.Read . 대부분의 웹 API에 대해 이 권한을 제거합니다. Microsoft Entra ID는 API가 다른 API를 호출하는 경우에만 API 권한이 필요합니다. API가 다른 API를 호출하지 않는 경우 API를 User.Read 등록할 때 사용 권한을 제거합니다.

API에 액세스해야 하는 클라이언트 앱이 API를 호출할 수 있는 권한을 요청하는 API에 대한 고유 식별자(애플리케이션 ID URI라고 함)가 필요합니다. 애플리케이션 ID URI는 모든 Microsoft Entra 테넌트에서 고유해야 합니다. 등록된 API의 애플리케이션 ID는 여기서 <clientId> 사용할 api://<clientId> 수 있습니다(포털의 기본 제안).

API를 호출하는 개발자에게 더 친숙한 이름을 제공하기 위해 API의 주소를 애플리케이션 ID URI로 사용할 수 있습니다. 예를 들어 Microsoft Entra 테넌트에서 구성된 게시자가 해야 하는 기본 사용할 yourdomain.com 수 https://API.yourdomain.com 있습니다. Microsoft는 사용자가 할 일기본 소유권이 있는지 확인하여 API의 고유 식별자로 사용할 수 있도록 합니다. 이 주소에는 코드가 필요하지 않습니다. API는 원하는 위치에 있을 수 있지만 API의 HTTPS 주소를 애플리케이션 ID URI로 사용하는 것이 좋습니다.

최소 권한으로 위임된 권한 정의

사용자가 있는 애플리케이션에서 API를 호출하려는 경우 하나 이상의 위임된 권한을 정의해야 합니다(앱 등록에 대한 범위 추가 API 노출 참조).

조직 데이터 저장소에 대한 액세스를 제공하는 API는 해당 데이터에 액세스하려는 공격자의 관심을 끌 수 있습니다. 위임된 권한이 하나만 있는 대신 최소 권한 액세스의 제로 트러스트 원칙을 염두에 두고 사용 권한을 디자인합니다. 모든 클라이언트 앱이 모든 권한 있는 액세스 권한으로 시작하는 경우 나중에 최소 권한 모델로 전환하기 어려울 수 있습니다.

개발자는 "사용자 권한으로 액세스" 또는 "사용자 가장"과 같은 단일 사용 권한을 사용하는 패턴에 빠지는 경우가 많습니다(기술적으로 정확하지는 않지만 일반적인 구). 이와 같은 단일 권한은 API에 대한 전체 권한 있는 액세스만 허용합니다.

애플리케이션이 손상에 취약하거나 의도하지 않은 작업을 수행하는 데 사용되지 않도록 최소 권한 범위를 선언합니다. API 권한에서 여러 범위를 정의합니다. 예를 들어 데이터를 읽고 업데이트하는 것에서 범위를 분리하고 읽기 전용 권한을 제공하는 것이 좋습니다. "쓰기 액세스"에는 만들기, 업데이트 및 삭제 작업에 대한 권한이 포함됩니다. 클라이언트는 데이터 읽기에만 쓰기 권한을 요구해서는 안 됩니다.

API가 중요한 데이터로 작동하는 경우 "표준" 및 "전체" 액세스 권한을 고려합니다. 표준 사용 권한에서 액세스를 허용하지 않도록 중요한 속성을 제한합니다(예: Resource.Read). 그런 다음 속성 및 중요한 정보를 반환하는 "전체" 액세스 권한(예 Resource.ReadFull: )을 구현합니다.

작업을 완료하기 위해 절대 최소 권한 집합을 검색하도록 요청하는 권한을 항상 평가합니다. 더 높은 권한 권한을 요청하지 않습니다. 대신 각 핵심 시나리오에 대한 개별 권한을 만듭니다. 이 방법의 좋은 예는 Microsoft Graph 권한 참조를 참조 하세요. 요구 사항을 해결하기 위해 적절한 수의 권한만 찾아 사용합니다.

사용자 동의 및 관리자 동의 정의

범위 정의의 일부로 특정 범위 로 수행할 수 있는 작업 범위에 관리자 동의가 필요한지 여부를 결정합니다.

API 디자이너는 사용자 동의만 안전하게 요구할 수 있는 범위에 대한 지침을 제공할 수 있습니다. 그러나 테넌트 관리자는 모든 권한에 관리자 동의가 필요하도록 테넌트를 구성할 수 있습니다. 범위를 관리자 동의가 필요한 것으로 정의하는 경우 사용 권한에는 항상 관리자 동의가 필요합니다.

사용자 또는 관리자 동의를 결정할 때 두 가지 주요 고려 사항이 있습니다.

1. 권한 뒤에 있는 작업 범위가 단일 사용자 이상에 영향을 주는지 여부입니다. 사용 권한을 통해 사용자가 자신의 정보만 액세스할 수 있는 애플리케이션을 선택할 수 있는 경우 사용자 동의가 적절할 수 있습니다. 예를 들어 사용자는 전자 메일에 대해 선호하는 애플리케이션을 선택하는 데 동의할 수 있습니다. 그러나 권한 뒤에 있는 작업에는 둘 이상의 사용자(예: 다른 사용자의 전체 사용자 프로필 보기)가 포함된 경우 해당 권한을 관리자 동의가 필요한 것으로 정의합니다.

2. 권한 뒤에 있는 작업의 범위에 광범위한 범위가 있는지 여부입니다. 예를 들어 광범위한 범위는 앱이 테넌트에서 모든 항목을 변경하거나 되돌릴 수 없는 작업을 수행할 수 있도록 하는 권한입니다. 광범위한 범위는 사용자 동의가 아닌 관리자 동의가 필요하다는 것을 나타냅니다.

보수적 인 쪽에 Err 당신이 의심하는 경우 관리자 동의를 요구합니다. 사용 권한 문자열에서 동의의 결과를 명확하고 간결하게 설명합니다. 설명 문자열을 읽는 개인이 API 또는 제품에 대해 잘 알지 않는다고 가정합니다.

사용 권한의 의미 체계를 변경하는 방식으로 기존 권한에 API를 추가하지 않습니다. 기존 사용 권한을 오버로드하면 클라이언트가 이전에 동의를 부여한 추론이 희석됩니다.

애플리케이션 권한 정의

비사용자 애플리케이션을 빌드하는 경우 사용자 이름 및 암호 또는 MFA(다단계 인증)를 묻는 메시지를 표시할 수 있는 사용자가 없습니다. 사용자가 없는 애플리케이션(예: 워크로드, 서비스 및 디먼)이 API를 호출하는 경우 API에 대한 애플리케이션 권한을 정의해야 합니다. 애플리케이션 권한을 정의할 때 범위를 사용하는 대신 애플리케이션 역할을 사용합니다.

위임된 권한과 마찬가지로 API를 호출하는 워크로드가 최소 권한 액세스를 따르고 제로 트러스트 원칙에 부합할 수 있도록 세분화된 애플리케이션 권한을 제공합니다. 하나의 앱 역할(앱 권한) 및 하나의 범위(위임된 권한)만 게시하거나 모든 작업을 각 클라이언트에 노출하지 마세요.

워크로드는 다음 예제 코드에 설명된 대로 클라이언트 자격 증명을 사용하여 인증하고 범위를 사용하여 .default 토큰을 요청합니다.

// With client credentials flows the scopes is ALWAYS of the shape "resource/.default", as the 
// application permissions need to be set statically (in the portal or by PowerShell), 
// and then granted by a tenant administrator
string[] scopes = new string[] { "https://kkaad.onmicrosoft.com/webapi/.default" };
 
AuthenticationResult result = null;
try
{
  result = await app.AcquireTokenForClient(scopes)
    .ExecuteAsync();
  Console.WriteLine("Token acquired \n");
}
catch (MsalServiceException ex) when (ex.Message.Contains("AADSTS70011"))
{
  // Invalid scope. The scope has to be of the form "https://resourceurl/.default"
  // Mitigation: change the scope to be as expected
  Console.WriteLine("Scope provided is not supported");
}

권한은 앱 앞에 사용자가 없고 애플리케이션 권한이 광범위한 작업을 사용하도록 설정하는 경우 관리자 동의가 필요합니다.

액세스 적용

호출 애플리케이션이 HTTPS 요청의 권한 부여 헤더에서 전달자 토큰으로 제공하는 액세스 토큰의 유효성을 검사하고 해석하여 API가 액세스를 적용하는지 확인합니다. 다음 섹션에 설명된 대로 토큰의 유효성을 검사하고, 메타데이터 새로 고침을 관리하고, 범위 및 역할을 적용하여 액세스를 적용할 수 있습니다.

토큰 유효성 검사

API가 토큰을 받은 후에는 토큰의 유효성을 검사해야 합니다. 유효성 검사를 수행하면 토큰이 적절한 발급자에서 수정되지 않고 수정되지 않은 것으로 제공됩니다. ID 토큰과 마찬가지로 Microsoft Entra ID에서 직접 토큰을 가져오지 않으므로 서명을 확인합니다. API가 네트워크의 신뢰할 수 없는 원본에서 토큰을 받은 후 서명의 유효성을 검사합니다.

JSON 웹 토큰 서명 확인과 관련된 알려진 취약성이 있으므로 잘 기본 관련되고 설정된 표준 토큰 유효성 검사 라이브러리를 사용합니다. 인증 라이브러리(예: Microsoft.Identity.Web)는 적절한 단계를 사용하고 알려진 취약성을 완화합니다.

필요에 따라 토큰 유효성 검사를 확장합니다. 테넌트 ID(tid) 클레임을 사용하여 API가 토큰을 가져올 수 있는 테넌트를 제한합니다. API를 azp 호출할 수 있는 앱을 필터링하려면 해당 및 appid 클레임을 사용합니다. 개체 ID(oid) 클레임을 사용하여 개별 사용자에 대한 액세스 범위를 더욱 좁힐 수 있습니다.

메타데이터 새로 고침 관리

항상 토큰 유효성 검사 라이브러리가 필요한 메타데이터를 효과적으로 관리해야 합니다. 이 경우 메타데이터는 Microsoft Entra 토큰에 서명하는 데 사용하는 공개 키, 개인 키 쌍입니다. 라이브러리가 이러한 토큰의 유효성을 검사하면 잘 알려진 인터넷 주소에서 게시된 공개 서명 키 목록을 가져옵니다. 호스팅 환경에 해당 키를 가져올 적절한 타이밍이 있는지 확인합니다.

예를 들어 이전 라이브러리는 24시간마다 해당 공개 서명 키를 업데이트하기 위해 하드 코딩되는 경우도 있었습니다. Microsoft Entra ID가 해당 키를 빠르게 회전해야 하고 다운로드한 키에 새 회전 키가 포함되지 않은 경우를 고려합니다. API는 메타데이터 새로 고침 주기를 기다리는 동안 하루 동안 오프라인 상태가 될 수 있습니다. 특정 메타데이터 새로 고침 지침을 참조하여 메타데이터를 제대로 가져오는지 확인합니다. 라이브러리를 사용하는 경우 적절한 타이밍 내에 해당 메타데이터를 처리해야 합니다.

범위 및 역할 적용

토큰의 유효성을 검사한 후 API는 토큰의 클레임을 확인하여 작동 방식을 결정합니다.

위임된 권한 토큰의 경우 API가 범위(scp) 클레임을 검사하여 애플리케이션이 수행할 수 있는 작업을 확인하도록 합니다. 개체 ID(oid) 또는 주체 키(sub) 클레임을 검사하여 애플리케이션이 작동하는 사용자를 확인합니다.

그런 다음 API 검사 요청된 작업에 대한 액세스 권한이 있는지 확인합니다. API가 사용자 및 그룹에 할당하기 위한 역할을 정의하는 경우 API가 토큰의 역할 클레임에 대해 검사 적절하게 동작하도록 합니다. 애플리케이션 권한 토큰에는 범위(scp) 클레임이 없습니다. 대신 API가 역할 클레임을 검사하여 워크로드가 받은 애플리케이션 권한을 결정하도록 합니다.

API가 토큰 및 범위의 유효성을 검사하고 개체 ID(), 주체 키(oidsub) 및 역할 클레임을 처리한 후 API는 결과를 반환할 수 있습니다.

다음 단계

• Microsoft ID 동의 프레임워크 로 보호되는 API의 예는 최상의 사용자 환경을 위한 최소 권한 애플리케이션 권한 전략을 설계하는 데 도움이 됩니다.
• 다른 API에서 API를 호출하면 다른 API를 호출하고 사용자를 대신하여 작업할 때 애플리케이션을 안전하게 개발해야 하는 API가 하나 있는 경우 제로 트러스트 수 있습니다.
• 토큰 사용자 지정은 Microsoft Entra 토큰에서 받을 수 있는 정보를 설명합니다. 최소 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 향상시키기 위해 토큰을 사용자 지정하는 방법을 설명합니다.
• 토큰 에서 그룹 클레임 및 앱 역할을 구성하면 앱 역할 정의를 사용하여 앱을 구성하고 앱 역할에 보안 그룹을 할당하는 방법을 보여 줍니다. 이러한 방법은 최소한의 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 개선하는 데 도움이 됩니다.
• 리소스에 액세스하기 위한 권한 부여를 획득하면 애플리케이션에 대한 리소스 액세스 권한을 획득할 때 제로 트러스트 가장 잘 확인하는 방법을 이해하는 데 도움이 됩니다.
• 관리 동의 가 필요한 요청 권한은 애플리케이션 사용 권한에 관리 동의가 필요한 경우 사용 권한 및 동의 환경을 설명합니다.
• 이 빠른 시작: Microsoft ID 플랫폼 사용하여 웹 API를 보호하고 리소스에 대한 액세스를 권한 있는 계정으로만 제한하여 ASP.NET Web API를 보호하는 방법을 알아봅니다.
• 이 자습서 - Azure API Management에서 API 변환 및 보호에서 API의 HTTP 응답에서 기술 스택 정보 또는 원래 URL을 숨기도록 일반적인 정책을 구성하는 방법을 알아봅니다.