Microsoft Entra ID의 서비스 주체 보호
Microsoft Entra 서비스 주체는 테넌트 또는 디렉터리에 있는 애플리케이션 개체의 로컬 표현입니다. 애플리케이션 인스턴스의 ID입니다. 서비스 주체는 애플리케이션 액세스 및 애플리케이션이 액세스하는 리소스를 정의합니다. 서비스 주체는 애플리케이션이 사용되는 각 테넌트에 생성되고 전역적으로 고유한 애플리케이션 개체를 참조합니다. 테넌트는 서비스 주체의 로그인 및 리소스에 대한 액세스를 보호합니다.
자세히 알아보기: Microsoft Entra ID의 애플리케이션 및 서비스 주체 개체
테넌트-서비스 주체 관계
단일 테넌트 애플리케이션에는 해당 홈 테넌트에 서비스 주체만 있습니다. 다중 테넌트 웹 애플리케이션 또는 API에는 각 테넌트의 서비스 주체가 있어야 합니다. 해당 테넌트의 사용자가 애플리케이션 또는 API 사용에 동의하면 서비스 주체가 만들어집니다. 이 동의는 다중 테넌트 애플리케이션과 연결된 서비스 주체 간에 일 대 다 관계를 만듭니다.
다중 테넌트 애플리케이션은 테넌트에 있으며 다른 테넌트에 인스턴스가 있습니다. 대부분의 SaaS(Software-as-a-Service) 애플리케이션은 다중 테넌트를 수용합니다. 서비스 주체를 사용하여 단일 및 다중 테넌트 시나리오에서 애플리케이션과 해당 사용자에 필요한 보안 태세를 보장합니다.
ApplicationID 및 ObjectID
애플리케이션 인스턴스에는 ApplicationID(또는 ClientID)와 ObjectID라는 두 가지 속성이 있습니다.
참고 항목
인증 작업에서 애플리케이션을 언급할 때 애플리케이션 및 서비스 주체라는 용어는 같은 의미로 사용됩니다. 그러나 Microsoft Entra ID에는 두 가지 애플리케이션 표현이 있습니다.
ApplicationID는 전역 애플리케이션을 나타내며, 테넌트의 애플리케이션 인스턴스에 대해 동일합니다. ObjectID는 애플리케이션 개체에 대한 고유한 값입니다. 사용자, 그룹 및 기타 리소스와 마찬가지로 ObjectID는 Microsoft Entra ID에서 애플리케이션 인스턴스를 식별하는 데 도움이 됩니다.
자세한 내용은 Microsoft Entra ID의 애플리케이션 및 서비스 주체 관계를 참조하세요.
애플리케이션 및 해당 서비스 주체 개체 만들기
다음을 사용하여 테넌트에서 애플리케이션 및 해당 서비스 주체 개체(ObjectID)를 만들 수 있습니다.
- Azure PowerShell
- Microsoft Graph PowerShell
- Azure CLI(Azure 명령줄 인터페이스)
- Microsoft Graph API
- Azure Portal
- 기타 도구
서비스 주체 인증
서비스 주체를 사용하는 인증에는 클라이언트 인증서와 클라이언트 암호라는 두 가지 메커니즘이 있습니다.
인증서는 더 안전하기 때문에 가능하면 인증서를 사용하는 것이 좋습니다. 클라이언트 암호와 달리 클라이언트 인증서는 실수로 코드에 포함할 수 없습니다. 가능한 경우 인증서 및 비밀 관리에 Azure Key Vault를 사용하여 하드웨어 보안 모듈로 보호되는 키로 자산을 암호화합니다.
- 인증 키
- Storage 계정 키
- 데이터 암호화 키
- .pfx 파일
- 암호
Azure Key Vault에 대한 자세한 내용과 이를 인증서 및 비밀 관리에 사용하는 방법은 다음을 참조하세요.
과제 및 해결 방법
서비스 주체를 사용할 때 다음 표를 사용하여 챌린지와 완화를 일치시킵니다.
| 과제 | 완화 방법 |
|---|---|
| 권한 있는 역할에 할당된 서비스 주체에 대한 액세스 검토 | 이 기능은 미리 보기 상태입니다. |
| 서비스 주체 액세스 검토 | Azure Portal를 사용하여 리소스의 액세스 제어 목록 수동 확인 |
| 권한이 과다하게 부여된 서비스 주체 | 자동화 서비스 계정 또는 서비스 주체를 만들 때 작업에 대한 권한을 부여합니다. 서비스 주체를 평가하여 권한을 줄입니다. |
| 서비스 주체의 자격 증명 또는 인증 방법에 대한 수정 사항 식별 | - 중요한 작업 보고서 통합 문서 참조 - Solorigate 위험을 평가하는 데 도움이 되는 기술 커뮤니티 블로그 게시물, Microsoft Entra 통합 문서를 참조하세요. |
서비스 주체를 사용하여 계정 찾기
계정을 찾으려면 Azure CLI 또는 PowerShell에서 서비스 주체를 사용하여 다음 명령을 실행합니다.
- Azure CLI -
az ad sp list - PowerShell -
Get-MgServicePrincipal -All:$true
자세한 내용은 Get-MgServicePrincipal을 참조하세요.
서비스 주체 보안 평가
보안을 평가하려면 권한 및 자격 증명 스토리지를 평가합니다. 다음 표를 사용하여 문제를 완화합니다.
| 과제 | 완화 방법 |
|---|---|
| 다중 테넌트 앱에 동의한 사용자를 검색하고 다중 테넌트 앱에 대한 불법 승인 부여를 검색 | - 다음 PowerShell을 실행하여 다중 테넌트 앱을 찾습니다. Get-MgServicePrincipal -All:$true | ? {$_.Tags -eq "WindowsAzureActiveDirectoryIntegratedApp"}- 사용자 동의 사용하지 않도록 설정 - 선택한 권한에 대해 확인된 게시자의 사용자 동의 허용(권장) - 사용자 컨텍스트에서 구성 - 토큰을 사용하여 서비스 주체 트리거 |
| 서비스 주체를 사용하는 스크립트에서 하드 코드된 공유 암호 사용 | 인증서 사용 |
| 누가 인증서 또는 비밀을 사용하는지 추적 | Microsoft Entra 로그인 로그를 사용하여 서비스 주체 로그인 모니터링 |
| 조건부 액세스로 서비스 주체 로그인을 관리할 수 없습니다. | Microsoft Entra 로그인 로그를 사용하여 로그인 모니터링 |
| 기여자는 기본 Azure RBAC(Azure 역할 기반 액세스 제어) 역할입니다. | 요구 사항을 평가하고 가능한 최소한의 권한을 적용합니다. |
자세히 알아보기: 조건부 액세스란?
사용자 계정에서 서비스 주체로 이동
Azure 사용자 계정을 서비스 주체로 사용하는 경우 관리 ID 또는 서비스 주체로 이동할 수 있는지 평가합니다. 관리 ID를 사용할 수 없는 경우 필요한 작업을 실행할 수 있는 충분한 권한과 범위를 서비스 주체에 부여합니다. 애플리케이션을 등록하거나 PowerShell을 사용하여 서비스 주체를 만들 수 있습니다.
Microsoft Graph를 사용하는 경우 API 설명서를 확인합니다. 애플리케이션에 대한 권한 유형이 지원되는지 확인합니다.
servicePrincipal 만들기를 참조하세요.
자세히 보기:
- App Service 및 Azure Functions에 대한 관리 ID를 사용하는 방법
- 리소스에 액세스할 수 있는 Microsoft Entra 애플리케이션 및 서비스 주체 만들기
- Azure PowerShell을 사용하여 인증서로 서비스 주체 만들기
다음 단계
서비스 주체에 관한 자세한 정보:
서비스 계정 보호:
조건부 액세스:
조건부 액세스를 사용하여 신뢰할 수 없는 위치의 서비스 주체를 차단하세요.
위치 기반 조건부 액세스 정책 만들기를 참조하세요.