Entra ID에서 서비스 프린시펄을 효과적으로 관리하는 방법

By Mirko Peters · 2026-03-22 · Updated 2026-03-24

Microsoft Entra ID에서 서비스 프린시펄을 보호하여 ID 관리를 강화하세요. 테넌트 내 애플리케이션 및 서비스 프린시펄 개체에 대해 알아봅니다.

Automatically translated with AI from the original post. Read the English original

Entra ID에서 서비스 프린시펄과 앱 등록을 관리하는 것은 보안과 액세스 제어를 유지하는 데 매우 중요합니다. 효과적인 거버넌스는 권한 상승 및 테넌트 침해와 같은 중대한 보안 사고를 예방하는 데 도움이 됩니다. 예를 들어, 공격자는 제대로 관리되지 않은 서비스 프린시펄을 악용하여 관리자 암호를 재설정하고 중요한 시스템에 무단으로 접근할 수 있습니다. 강력한 관리 방식을 적용하면 이러한 위험을 완화하고 환경의 보안을 유지할 수 있습니다. 핵심 단계는 서비스 프린시펄을 이해하고, 적절한 권한을 할당하며, 액세스 정책을 정기적으로 검토하는 것입니다.

Entra ID에서 서비스 프린시펄을 효과적으로 관리하는 방법을 배우고 계시다면, 아래의 잘 알려지지 않은 사실들이 자동화된 ID를 보호하고 운영하는 방식을 바꿔 줄 수 있습니다.

1. 서비스 프린시펄은 앱 개체와 다릅니다: 애플리케이션 개체는 전역 애플리케이션 정의이고, 서비스 프린시펄은 테넌트에 있는 로컬 ID입니다. 하나의 앱 개체에 여러 테넌트의 서비스 프린시펄이 연결될 수 있습니다.
2. 만료되지 않는 자격 증명을 가질 수 있습니다: Entra ID에서는 설계상 또는 잘못된 구성으로 만료되지 않는 클라이언트 암호나 인증서를 만들 수 있으며, 수동으로 교체하지 않으면 장기적인 위험이 커집니다.
3. 관리 ID는 내부적으로 서비스 프린시펄을 사용합니다: 시스템 할당 및 사용자 할당 관리 ID는 모두 디렉터리에서 서비스 프린시펄로 표현되므로, RBAC와 조건부 액세스 정책을 적용할 수 있습니다.
4. 서비스 프린시펄은 조건부 액세스에서 사용될 수 있습니다: 조건부 액세스는 주로 사용자를 대상으로 하지만, 애플리케이션 컨텍스트를 평가할 수 있으며, 특히 애플리케이션 인증 컨텍스트와 결합하면 일부 정책이 서비스 프린시펄에 영향을 줄 수 있습니다.
5. 위임 권한과 애플리케이션 권한을 동시에 지원합니다: 하나의 서비스 프린시펄은 위임 권한(사용자를 대신하여)과 애플리케이션 권한(앱 단독) 을 모두 가질 수 있으며, 이는 최소 권한 원칙을 적용하는 과정을 더 복잡하게 만듭니다.
6. 로그인 로그에는 비대화형 앱 인증이 포함됩니다: Entra ID는 서비스 프린시펄 로그인을 기록하여 비정상적인 앱 활동을 탐지할 수 있게 하지만, 이러한 로그는 사용자 로그인에 비해 간과되기 쉽습니다.
7. 동의 및 권한 부여 관리는 숨겨진 액세스 경로를 남길 수 있습니다: 관리자 동의 또는 권한 부여 관리(entitlement management)를 통해 부여된 엔터프라이즈 애플리케이션과 서비스 프린시펄은 간접적인 액세스 경로를 만들 수 있으며, 철저한 권한 검토 없이는 찾아내기 어렵습니다.

핵심 요약

• Entra ID에서 애플리케이션 등록과 서비스 프린시펄의 차이를 이해하세요.
• 서비스 프린시펄을 관리하기 전에 올바른 권한이 있는지 확인하여 작업이 중단되지 않도록 하세요.
• 필요한 세부 정보를 입력하는 것을 포함하여, Entra ID에서 애플리케이션을 등록하는 명확한 절차를 따르세요.
• 애플리케이션의 보안을 강화하려면 여러 인증 방법을 사용하세요.
• 서비스 프린시펄에 적절한 권한을 할당하려면 역할 기반 액세스 제어(RBAC)를 구현하세요.
• 보안 모범 사례에 맞는지 확인하도록 액세스 정책을 정기적으로 검토하세요.
• 변경 사항을 모니터링하고 무단 액세스나 활동을 탐지하기 위해 감사를 수행하세요.
• 서비스 프린시펄에 꼭 필요한 권한만 부여하여 최소 권한 원칙을 적용하세요.

Entra ID 관리를 위한 사전 요구 사항

서비스 프린시펄 이해하기

Entra ID에서 서비스 프린시펄을 관리하기 전에 몇 가지 기본 개념을 이해해야 합니다. 다음은 이해해야 할 핵심 사항입니다:

• 애플리케이션 등록(App)은 Entra ID에서 애플리케이션을 나타내는 전역적으로 고유한 개체입니다.
• 서비스 프린시펄(SP)은 단일 테넌트 내에 있는 해당 애플리케이션 개체의 특정 인스턴스입니다.
• 앱 등록을 만들면, 같은 테넌트에 서비스 주体가 자동으로 생성됩니다.
• 서비스 주체는 애플리케이션 개체와 별도로 고유한 자격 증명과 권한을 가집니다.
• 사용자 생성처럼 테넌트에서 수행되는 작업은 서비스 주체가 실행합니다.

Entra ID 포털은 헷갈리기 쉽습니다. 서비스 주체는 '엔터프라이즈 애플리케이션' 아래에 표시되며, '서비스 주체'라는 용어는 거의 사용되지 않습니다. 그래서 앱 등록과 서비스 주체의 관계를 잘못 이해하는 경우가 생길 수 있습니다.

필수 권한

서비스 주체를 효과적으로 관리하려면 적절한 권한이 필요합니다. 다음은 필수 사전 요구 사항을 정리한 것입니다.

이러한 권한이 있으면 막힘없이 필요한 작업을 수행할 수 있습니다. 앱 등록이나 역할 할당을 진행하기 전에 계정에 필요한 권한이 있는지 항상 확인하십시오.

이러한 사전 요구 사항을 이해하면 Entra ID에서 서비스 주체를 관리하기 위한 탄탄한 기반을 마련할 수 있습니다. 이 지식은 액세스 관리의 복잡성을 헤쳐 나가고 조직의 보안 태세를 강화하는 데 도움이 됩니다.

Entra ID에서 애플리케이션 등록

애플리케이션 등록 단계

Entra ID에서 애플리케이션을 등록하는 과정은 간단합니다. 아래 단계를 따라 시작하십시오.

1. Entra ID 포털에 로그인: Microsoft Entra 계정을 사용하여 포털에 액세스합니다.
2. 앱 등록으로 이동: 왼쪽 메뉴에서 "앱 등록"을 선택합니다.
3. 새 등록 클릭: 이 옵션으로 새 애플리케이션을 만들 수 있습니다.
4. 애플리케이션 세부 정보 입력:
   • 이름: 애플리케이션의 고유한 이름을 지정합니다.
   • 지원되는 계정 유형: 애플리케이션을 사용할 수 있는 대상을 선택합니다(예: 이 조직 디렉터리의 계정만).
   • 리디렉션 URI: 인증 후 사용자가 리디렉션될 URI를 지정합니다. 웹 애플리케이션에서는 특히 중요합니다.
5. 검토 및 등록: 필요한 정보를 모두 입력한 후 "등록"을 클릭하여 애플리케이션을 만듭니다.

등록이 끝나면 무료 버전에서 단일 테넌트당 Microsoft Entra 리소스를 최대 50,000개까지 만들 수 있습니다. 도메인을 확인하면 이 한도를 300,000개까지 늘릴 수 있습니다. 또한 암호 기반 单一 로그인(SSO)을 사용하여 최대 48개 앱의 자격 증명을 구성할 수 있습니다.

애플리케이션 설정 구성

애플리케이션을 등록한 후에는 최적의 보안과 기능을 위해 설정을 구성해야 합니다. 다음은 따라야 할 몇 가지 모범 사례입니다.

1. 여러 Entra ID 인증 방법 구성: 다단계 인증(MFA)과 암호 없는 인증 등 다양한 인증 방법을 사용하여 보안을 강화합니다.
2. Entra ID 그룹을 활용하여 권한 할당: 사용자 그룹을 만들어 액세스 제어를 효과적으로 관리합니다. 이를 통해 사용자에게 필요한 권한만 부여할 수 있습니다.
3. 조건부 액세스 정책(CAP) 사용: CAP를 구현하여 리소스 액세스 조건을 정의합니다. 세분화된 제어를 통해 보안에 한 겹을 더합니다.

추가로 앱 인벤토리를 작성하는 것도 고려해 보십시오. Entra에 연결된 모든 앱을 식별하고 목록으로 정리하여 효과적으로 관리하십시오. 각 앱에 부여된 권한을 정기적으로 평가하여 보안 전략에 반영하십시오. 사용하지 않는 앱은 등록을 해제하여 공격 표면을 줄이십시오.

이러한 단계와 모범 사례를 따르면 Entra ID 내에서 애플리케이션이 올바르게 구성되고 안전하게 보호되도록 할 수 있습니다.

서비스 주체에 대한 역할 할당

RBAC 개요

역할 기반 액세스 제어(RBAC)는 Entra ID의 핵심 기능입니다. 조직 내에서 누가 어떤 리소스에 액세스할 수 있는지 관리하는 데 도움이 됩니다. RBAC를 사용하면 서비스 주체에 역할을 할당하여, 보안을 훼손하지 않고 필요한 작업을 수행하는 데 적합한 권한을 갖도록 할 수 있습니다.

Entra ID에는 두 가지 유형의 역할 정의가 있습니다.

• 기본 제공 역할: 고정된 권한 집합으로 제공됩니다. 수정할 수는 없지만 일반적인 시나리오를 대부분 다룹니다.
• 사용자 지정 역할: 특정 요구 사항에 맞게 권한을 조정할 수 있습니다. 사용자 지정 역할을 만들려면 역할을 정의한 다음 할당하는 두 단계를 거칩니다.

이러한 역할 유형을 이해하면 애플리케이션에 적합한 방식을 선택하는 데 도움이 됩니다. RBAC에 대한 자세한 내용은 역할 기반 액세스 제어 개요를 참조하십시오.

역할 할당

서비스 주체에 역할을 할당하는 것은 효과적인 관리에 필수적입니다. 다음 단계에 따라 역할을 올바르게 할당하십시오.

1. 역할 할당 만들기: Microsoft Entra 관리 센터, Microsoft Graph PowerShell 또는 Microsoft Graph API를 사용하십시오. 이 작업에는 Azure CLI가 지원되지 않습니다.
2. 애플리케이션 등록: Microsoft Entra 앱을 등록하고 Azure Portal을 통해 서비스 주체를 만들었는지 확인하십시오.
3. 올바른 역할 선택: 사용 가능한 역할을 검토하여 애플리케이션에 필요한 권한을 제공하는 역할을 결정하십시오.

역할 할당 프로세스를 간략히 정리한 참조 표는 다음과 같습니다.

이러한 단계를 따르면 서비스 주체가 해당 기능을 안전하게 수행하는 데 적절한 액세스 권한을 갖도록 할 수 있습니다. 올바른 역할 할당은 보안을 강화할 뿐만 아니라 조직 내 운영을 간소화합니다.

Entra ID 인증 방법

인증 개요

Entra ID에서 서비스 주체를 관리할 때 선택할 수 있는 주요 인증 방법은 두 가지입니다. 클라이언트 암호 인증과 인증서 기반 인증입니다. 각 방법에는 고유한 장점과 사용 사례가 있습니다.

클라이언트 암호 인증

클라이언트 암호 인증은 클라이언트 암호라고 하는 암호와 유사한 문자열을 사용합니다. 이 방법은 간단하며 빠른 설정이 필요한 애플리케이션에 자주 사용됩니다. 다만 클라이언트 암호는 비밀번호와 같이 취급해야 합니다. 보안을 유지하려면 안전하게 저장하고 정기적으로 교체해야 합니다.

• 장점:

  • 구현하기 쉽습니다.
  • 테스트 및 개발 환경에 적합합니다.

• 단점:

  • 인증서 기반 인증보다 보안성이 낮습니다.
  • 제대로 관리하지 않으면 노출될 위험이 있습니다.

인증서 기반 인증

인증서 기반 인증은 디지털 인증서를 사용하여 서비스 주체를 인증합니다. 이 방법은 클라이언트 암호보다 안전하며 프로덕션 환경에 권장됩니다. 최적의 보안을 위해서는 인증 기관(CA)에서 발급한 신뢰할 수 있는 인증서를 사용해야 합니다. 자체 서명 인증서는 테스트에는 사용할 수 있지만 프로덕션 환경에는 권장되지 않습니다.

• 장점:

  • 보안 수준이 더 높습니다.
  • 자격 증명 탈취 위험을 줄여 줍니다.

• 단점:

  • 설정이 더 복잡합니다.
  • 인증서 관리가 필요합니다.

인증 구성하기

Entra ID에서 서비스 주체의 인증을 구성하려면 다음 단계를 따르십시오:

1. Microsoft Entra 관리 센터의 홈 페이지를 엽니다.
2. Entra ID > 앱 등록으로 이동한 다음 해당 애플리케이션을 선택합니다.
3. 앱의 개요 페이지에서 디렉터리(테넌트) ID 값을 복사하여 애플리케이션 코드에 저장합니다.
4. 애플리케이션(클라이언트) ID 값을 복사하여 애플리케이션 코드에 저장합니다.
5. 인증서 기반 인증 또는 클라이언트 비밀 인증 중에서 선택합니다. 인증 기관에서 발급한 신뢰할 수 있는 인증서를 업로드하는 것을 권장합니다.
6. 인증서를 사용하는 경우 Entra ID > 앱 등록 > 인증서 및 비밀 > 인증서 업로드에서 업로드합니다.
7. 클라이언트 비밀을 사용하는 경우 Entra ID > 앱 등록 > 인증서 및 비밀 > 클라이언트 비밀 > 새 클라이언트 비밀에서 만듭니다.

이 단계를 따르면 서비스 주체가 안전하게 인증되어, 필요한 리소스에 접근하면서도 보안 위험을 최소화할 수 있습니다.

Entra ID의 액세스 정책

액세스 정책 이해하기

Entra ID의 액세스 정책은 애플리케이션과 데이터를 보호하는 데 중요한 역할을 합니다. 이 정책은 누가 어떤 리소스에 어떤 조건에서 접근할 수 있는지를 정의합니다. 알아 두어야 할 주요 액세스 정책 유형은 다음과 같습니다:

• 위험한 로그인에 대해 MFA 요구: 로그인이 의심스럽게 보이면 사용자에게 다단계 인증을 완료하도록 요구하는 정책입니다.
• 손상된 계정 차단 또는 修復: 손상된 징후가 보이는 계정에 대한 접근을 자동으로 제한하는 정책입니다.

이러한 액세스 정책을 구현하면 보안 상태가 강화됩니다. 잠재적 위협에 대한 대응을 자동화하여 위험을 효과적으로 관리하는 데 도움이 됩니다. 예를 들어 조건부 액세스 정책은 접근을 허용하기 전에 사용자 ID, 디바이스 규정 준수, 실시간 위험 신호와 같은 요소를 평가합니다. 이러한 선제적 접근 방식은 보안을 개선할 뿐만 아니라 조직 표준 준수도 보장합니다.

액세스 정책 구성하기

Entra ID에서 서비스 주체에 대한 액세스 정책을 구성하는 것은 간단합니다. 다음 단계에 따라 정책을 효과적으로 설정하십시오:

1. Microsoft Entra 관리 센터에 로그인하고 Entra ID » 엔터프라이즈 앱으로 이동합니다.
2. 제한하려는 서비스 주체를 클릭하고 관리 탭에서 속성으로 이동합니다.
3. 사용자가 로그인할 수 있도록 설정됨?을 아니요로 설정하고 저장을 클릭하여 해당 애플리케이션에 대한 사용자 로그인을 비활성화합니다.
4. 조건부 액세스 정책을 만들려면 Microsoft Entra 관리 센터에 로그인하고 Entra ID » 조건부 액세스로 이동합니다.
5. +새 정책 만들기를 클릭하고 정책 이름을 입력합니다.
6. 할당에서 사용자 또는 워크로드 ID로 이동합니다.
7. 이 정책이 적용되는 대상에서 워크로드 ID를 선택합니다. 포함에서 서비스 주체 선택을 클릭하고 목록에서 적절한 서비스 주체를 선택합니다.
8. 대상 리소스 섹션에서 포함으로 이동하여 모든 리소스(이전 '모든 클라우드 앱')를 선택합니다.
9. 조건 섹션에서 정책이 트리거되는 시점을 결정하는 특정 요구 사항을 구성합니다.
10. 액세스 제어에서 '부여'로 이동하여 액세스 차단을 선택하고 '선택'을 클릭합니다.
11. 정책 사용을 켜기로 설정하고 '만들기'를 클릭하여 Microsoft Entra 워크로드 ID에 대한 조건부 액세스 정책을 만듭니다.

이러한 단계를 따르면 서비스 주체가 엄격한 액세스 제어 아래에서 운영되도록 할 수 있습니다. 이는 리소스를 보호할 뿐만 아니라 보안 및 규정 준수를 위한 모범 사례에도 부합합니다.

서비스 주체를 위한 모범 사례

보안 권장 사항

Entra ID에서 서비스 주체를 보호하려면 다음 보안 권장 사항을 따르십시오.

• 클라이언트 암호 대신 클라이언트 인증서를 사용하여 보안을 강화하십시오.
• Azure Key Vault를 활용하여 인증서와 암호를 안전하게 관리하십시오.
• 서비스 주체에 최소 권한 액세스를 적용하십시오. 즉, 작업에 필요한 권한만 부여해야 합니다.
• Microsoft Entra 로그인 로그를 통해 서비스 주체의 로그인을 모니터링하십시오. 이를 통해 비정상적인 활동을 탐지할 수 있습니다.
• 신뢰할 수 없는 위치에서의 액세스를 제한하도록 조건부 액세스를 사용하십시오. 이는 추가적인 보안 계층을 더해 줍니다.
• 적절한 권한 수준을 유지하도록 Tier 0 역할의 멤버십을 정기적으로 검토하십시오. 이를 통해 중요한 리소스에 대한 무단 액세스를 방지할 수 있습니다.

이러한 방식을 채택하면 서비스 주체의 보안을 크게 강화하고 무단 액세스 위험을 줄일 수 있습니다.

정기 감사

서비스 주체의 보안과 무결성을 유지하려면 정기적인 감사를 수행하는 것이 필수적입니다. 구현해야 할 일반적인 감사 방식은 다음과 같습니다.

정기 감사를 통해 서비스 주체의 상태를 지속적으로 파악할 수 있습니다. 무단 변경이나 의심스러운 활동을 조기에 발견하여 환경의 보안을 유지할 수 있습니다.

이러한 모범 사례를 따르면 Entra ID에서 서비스 주체를 효과적으로 관리하고 보안과 규정 준수를 모두 강화할 수 있습니다.

요약하면, Entra ID에서 서비스 주체를 효과적으로 관리하려면 여러 핵심 단계와 모범 사례가 필요합니다. 다음과 같이 진행해야 합니다.

• 애플리케이션을 적절히 등록하고 해당 설정을 구성하십시오.
• 최소 권한 원칙에 따라 역할을 할당하십시오.
• 강력한 인증 방법을 구현하십시오.
• 액세스 정책과 권한을 정기적으로 검토하십시오.

지속적인 관리가 무엇보다 중요합니다. 셀프 서비스의 편의성이 높아질수록 액세스 관리 개선의 필요성도 커집니다. 정기적인 검토는 액세스 권한에 대한 통제를 유지하는 데 도움이 됩니다. 각 게스트 계정에는 지속적인 액세스 사유를 책임지는 내부 소유자가 있어야 합니다. 이러한 전략을 채택하면 보안을 강화하고 서비스 주체를 효과적으로 거버넌스할 수 있습니다.

이 체크리스트는 Entra ID에서 서비스 주체를 효과적으로 관리하기 위한 모범 사례를 구현하는 데 도움이 됩니다.

• 인벤토리 및 검색: 모든 테넌트와 구독에서 서비스 주체를 식별하십시오(주기적 검사 또는 보고서를 생성하십시오).
• 애플리케이션 및 소유자 매핑: 각 서비스 주체를 해당 애플리케이션, 비즈니스 소유자, 지원 담당자와 연결하십시오.
• 액세스 분류 및 목적: 각 서비스 주체의 목적, 환경(프로덕션/개발/테스트), 필요한 권한을 문서화하십시오.
• 최소 권한 원칙: 할당된 역할과 권한을 감사하고, 필요한 최소 수준으로 권한을 제거하거나 축소하십시오.
• 관리 ID 우선 사용: Azure 리소스의 경우 가능한 한 앱 등록/서비스 주체를 관리 ID로 대체하십시오.
• 자격 증명 위생 관리: 수명이 긴 자격 증명을 피하고, 클라이언트 암호보다 인증서를 우선 사용하며, 자격 증명을 정기적으로 교체하십시오.
• 자격 증명 정책 시행: 해당하는 경우 애플리케이션 자격 증명에 대해 조건부 액세스와 Azure AD 암호/비밀 정책을 구현합니다.
• 대화형 사용에 MFA/조건부 액세스 요구: 꼭 필요하고 보호되는 경우가 아니라면 대화형 로그인을 허용하는 자격 증명은 차단하거나 제한합니다.
• JIT(Just-In-Time) 또는 기간 제한 액세스 사용: 가능한 경우 서비스 주체에 높은 권한의 역할을 제한된 기간 동안만 부여합니다.
• 명명 규칙 및 메타데이터: 명확한 명명 표준을 적용하고, 서비스 주체에 환경, 소유자, 만료 메타데이터를 태그로 지정합니다.
• 만료 및 수명 주기 정책: 비밀/인증서에 만료 기간을 설정하고, 수명 주기(프로비저닝, 갱신, 취소, 프로비저닝 해제)를 자동화합니다.
• 사용되지 않는 서비스 주체 비활성화: 소유자 확인을 거쳐 정의된 기간 동안 사용되지 않은 서비스 주체는 비활성화하거나 삭제합니다.
• 로그인 및 위험 사용 모니터링: 비정상적인 로그인, 고위험 활동, 권한 상승에 대한 로깅과 알림을 활성화합니다.
• 중앙 집중식 로깅 및 SIEM 통합: 상관 분석과 보존을 위해 감사 로그, 로그인 이벤트, 프로비저닝 변경 사항을 SIEM으로 스트리밍합니다.
• 액세스 검토 및 정기 감사: 각 서비스 주체의 필요성과 소유자 승인을 확인하기 위해 정기적으로 액세스 검토를 수행합니다.
• API 및 권한 강화: 범위가 엄격하게 정의된 위임 권한 또는 앱 전용 범위를 사용합니다.
• 비밀 저장소 보호: 클라이언트 비밀과 인증서는 Azure Key Vault 또는 이에 상응하는 자격 증명 저장소에 보관하고, 저장소 액세스는 필요한 주체로만 제한합니다.
• 자동화된 보정: 손상되었거나 만료된 서비스 주체를 비활성화하고 자격 증명을 교체하는 자동화된 플레이북을 구현합니다.
• 정책 시행: Azure AD / Entra ID 조건부 액세스, Microsoft Entra 권한 관리, Azure Policy를 사용하여 표준을 시행합니다.
• 문서화 및 런북: 프로비저닝, 긴급 자격 증명 교체, 프로비저닝 해제 절차에 대한 런북을 유지 관리합니다.
• 액세스 및 장애 조치 테스트: 자격 증명 교체나 구성 변경 후에는 비프로덕션 환경에서 애플리케이션 인증 워크플로를 검증합니다.
• 보안 온보딩/오프보딩: 서비스 주체의 프로비저닝 및 프로비저닝 해제를 CI/CD 및 변경 제어 프로세스에 통합합니다.
• 자동화를 위한 최소 권한 서비스 계정: 자동화 작업에는 범위가 엄격하게 제한된 권한과 명확한 소유자가 지정된 전용 서비스 주체를 사용합니다.
• 외부/게스트 액세스 검토: 외부 앱이 만든 서비스 주체를 감사하고, 보안 검토를 거친 후에만 액세스를 허용합니다.
• 규정 준수 증거 유지: 내부 및 외부 요구 사항에 대한 규정 준수를 입증할 수 있도록 승인, 검토, 교체 이벤트를 기록합니다.
• 팀 및 소유자 교육: 애플리케이션 소유자와 개발자에게 Entra ID의 서비스 주체를 효과적으로 관리하는 방법과 안전한 자격 증명 관행을 교육합니다.

자주 묻는 질문: Microsoft Entra ID 서비스 주체 추가 리소스

Microsoft Entra ID 서비스 주체란 무엇이며, 애플리케이션 개체와 어떻게 다른가요?

Microsoft Entra ID 서비스 주체는 테넌트 또는 디렉터리에서 애플리케이션 인스턴스를 로컬로 표현한 것입니다. 애플리케이션이 사용되는 각 테넌트에서 생성되며, 전역적으로 고유한 애플리케이션 개체를 참조합니다(애플리케이션 개체는 홈 테넌트에 있습니다). 애플리케이션 개체는 애플리케이션을 전역적으로 정의하고, 서비스 주체는 특정 테넌트에서의 액세스 정책과 해당 애플리케이션이 수행할 수 있는 작업을 정의합니다.

서비스 주체는 어떻게 만들어지며, 언제 만들어지나요?

서비스 주체는 일반적으로 Microsoft Entra 애플리케이션을 등록하고 테넌트에서 애플리케이션 인스턴스가 사용될 때, 또는 다중 테넌트 앱에 사용자가 권한에 동의할 때 자동으로 만들어집니다. 애플리케이션이 보호된 리소스에 액세스해야 하는 테넌트에 배포될 때 Azure Portal, Microsoft Graph 또는 자동화를 통해 수동으로 만들 수도 있습니다.

Microsoft Entra에서 서비스 주체를 보호하기 위한 모범 사례는 무엇인가요?

최소 권한을 할당하고, 자격 증명(암호 및 인증서)을 교체 및 보호하며, 가능한 경우 관리 ID를 사용하고, 조건부 액세스 정책을 시행하고, 로그인 및 감사 로그를 모니터링하며, 필터 기반 액세스 제어를 통해 고위험 주체를 제외하여 서비스 주체를 보호합니다. 민감한 리소스에 액세스할 때 규정을 준수하는 디바이스나 MFA를 요구하도록 조건부 액세스를 사용하여 서비스 주체를 활용합니다.

서비스 주체의 암호 및 인증서와 같은 자격 증명은 어떻게 관리하나요?

암호와 인증서는 보안 저장소(Key Vault)에 보관하고, 만료 정책을 설정하며, 가능하면 인증서 기반 인증을 사용하십시오. 또한 Microsoft Graph 또는 CI/CD 파이프라인으로 교체를 자동화하십시오. 장기간 사용하는 자격 증명에는 만료 예정 알림을 구현하고, 오래되었거나 안전하지 않은 비밀이 생기지 않도록 스키마와 정책을 강제 적용하십시오.

자동화를 통해 Microsoft Graph로 서비스 주체를 조회하고 관리하려면 어떻게 해야 합니까?

Microsoft Graph API를 사용하면 Microsoft Entra ID의 서비스 주체 개체를 나열, 필터링, 생성, 업데이트, 삭제할 수 있습니다. appId, displayName 또는 소유자 기준 필터를 사용해 서비스 주체를 찾을 수 있으며, 동의된 권한을 관리하고 소유자를 할당할 수 있습니다. 또한 전역 고유 식별자(GUID)를 참조하는 스크립트나 커넥터로 여러 환경 간 서비스 주체 동기화를 자동화할 수 있습니다.

소유자를 할당하는 역할은 무엇이며, 소유권은 어떻게 관리해야 합니까?

소유자를 할당하면 서비스 주체에 대한 위임된 관리 제어권이 생기며, 소유자는 자격 증명과 권한을 관리할 수 있습니다. 비즈니스 연속성을 위해 역할 기반 액세스를 사용하고 여러 소유자를 지정하며, 소유자 변경 내역을 감사하십시오. 장기적인 ID와 연결되지 않은 사용자 계정에는 소유자 권한을 할당하지 않는 것이 좋습니다. 대신 정책으로 제한된 팀 또는 서비스 계정을 사용하십시오.

동기화와 테넌트 또는 디렉터리 고려 사항은 서비스 주체에 어떤 영향을 줍니까?

엔터프라이즈 앱 또는 ID를 여러 테넌트 간에 동기화하는 등의 동기화 시나리오에서는 대상 테넌트에 서비스 주체가 생성될 수 있습니다. 앱이 단일 테넌트인지 다중 테넌트인지, 애플리케이션이 등록된 홈 테넌트가 어디인지, 그리고 해당 테넌트의 사용자가 동의해야 하는지를 확인하십시오. 중복 서비스 주체가 생기지 않도록 동기화를 계획하고, 필터를 사용해 불필요한 개체를 제외하십시오.

생성한 서비스 주체 대신 관리 ID를 사용해야 하는 경우는 언제입니까?

워크로드가 Azure에서 실행되고 플랫폼이 관리하는 ID를 활용해 내장된 자격 증명 없이 토큰을 얻을 수 있다면 관리 ID를 사용하십시오. 관리 ID를 사용하면 암호를 관리할 필요가 줄고 보안 업데이트도 간소화됩니다. 지원되는 Microsoft 시나리오에서 서비스 주체를 보호하려면 관리 ID를 사용하는 것이 권장되는 방법입니다.

서비스 주체로 보호되는 리소스에 대한 액세스를 감사하고 문제를 해결하려면 어떻게 해야 합니까?

Microsoft Entra ID와 Azure AD에서 로그인 로그와 감사 로그를 사용 설정하고 검토하십시오. Microsoft Graph로 이벤트를 조회하고 필터를 적용해 결과를 좁힐 수 있으며, 로그를 SIEM과 통합할 수 있습니다. 기술 지원이 필요하거나 복잡한 문제가 있다면, 지원팀에 문의하기 전에 서비스 주체의 objectId, appId, 타임스탬프, 오류 메시지를 수집하십시오. 조사에는 Microsoft Learn과 추가 자료도 참고하십시오.