Microsoft Entra ID의 서비스 주체를 사용한 인증
여러분의 회사에서 직원들은 여러 온-프레미스 애플리케이션을 사용하며 일상 업무를 수행합니다. 최근에 회사에서 엔터프라이즈 수준 보안 감사를 완료했습니다. 감사에서 여러 애플리케이션의 디자인 결함이 부각되었습니다. 감사에서 애플리케이션 소스 코드 또는 관련 구성 파일에 저장된 사용자 이름 및 암호를 찾았습니다.
이 보고서에는 사용자 이름 및 암호를 코드 또는 구성 파일에 저장하는 데 따른 다음과 같은 보안 문제가 지적되어 있습니다.
- 일반 텍스트로 저장된 암호는 누구나 액세스할 수 있습니다.
- 손상된 사용자 자격 증명은 엔터프라이즈의 네트워크 보안을 위협합니다.
- 손상된 사용자 자격 증명이 판매 및 마케팅 데이터와 같은 중요한 리소스에 대한 액세스를 허용합니다.
- 현재 자격 증명 스토리지 접근 방식은 불필요한 오버헤드를 만듭니다. 자격 증명이 만료되면 애플리케이션을 업데이트하고 다시 배포해야 합니다.
- 현재 자격 증명 스토리지 솔루션은 애플리케이션을 온-프레미스로 제한합니다. 애플리케이션은 중요한 변경 없이 클라우드 사용으로 확장할 수 없습니다.
개발자는 이러한 문제를 해결하라는 요청을 받았습니다. 감사 보고서는 애플리케이션 보안을 개선하기 위해 Azure 서비스 사용자를 사용할 것을 제안했습니다.
이 단원에서는 Azure 서비스 사용자에 대해 자세히 살펴봅니다. 기본 개념을 알아보고 Azure 리소스에 액세스하기 위해 이를 구현하는 방법을 배웁니다.
Azure 서비스 사용자란?
Azure 서비스 주체를 앱 또는 서비스를 나타내는 프록시 계정 또는 ID로 간주합니다. Microsoft Entra ID는 이 계정을 관리합니다. 서비스 사용자에게 필요한 Azure 리소스에 대한 액세스 권한을 부여합니다. 자격 증명을 포함하거나 애플리케이션에 대한 더미 계정을 만드는 대신 서비스 사용자를 사용합니다.
서비스 사용자는 Azure의 테넌트 수준에 존재합니다. 이들은 해당 테넌트의 리소스에 대한 액세스 권한을 부여하는 데 사용됩니다.
Azure Portal에서 앱을 나타내는 Microsoft Entra 애플리케이션을 만들 수 있습니다. 그런 다음 이 애플리케이션 개체를 서비스 주체와 연결할 수 있습니다.
모든 리소스가 동일한 테넌트에 있는 경우 하나의 서비스 사용자만 연결해야 합니다. 앱이 다른 테넌트의 Azure 리소스에 액세스해야 하는 경우 각 테넌트마다 서비스 사용자가 필요합니다.
다음 옵션 중 원하는 옵션을 사용하여 서비스 주체를 만들 수 있습니다.
- 포털을 통해
- PowerShell을 사용
- CLI 명령을 통해
- API 호출 사용
애플리케이션에서 Microsoft ID 플랫폼 사용
Microsoft ID 플랫폼은 애플리케이션이 Microsoft Entra ID로 인증하는 방식을 간소화합니다. 앱을 인증하는 통합된 방법을 제공합니다. 애플리케이션이 Microsoft Entra ID로 성공적으로 인증되면 고유한 토큰을 받습니다. 애플리케이션은 API를 호출하거나 서비스에 대한 호출을 만들 때마다 이 토큰을 사용합니다. 애플리케이션을 빌드하려면 MSAL(Microsoft 인증 라이브러리)을 사용하여 Single Sign-On 지원을 제공합니다.
Microsoft ID 플랫폼용 애플리케이션은 여러 가지 방법으로 프로비전할 수 있습니다. 여기서는 포털을 사용하여 Azure에서 애플리케이션을 등록합니다.
Azure Portal에 로그인하고 Microsoft Entra ID를 선택합니다.
앱 등록을 선택합니다.
왼쪽 위에서 새 등록을 선택합니다.
앱의 표시 이름을 입력합니다.
지원되는 계정 유형을 지정합니다. 다음 중 하나를 선택할 수 있습니다.
- 회사의 Microsoft Entra 테넌트 내의 계정입니다.
- 모든 회사의 Microsoft Entra 테넌트에 있는 계정입니다.
- Microsoft 또는 Xbox와 같은 조직 계정 및 개인 계정
(‘선택 사항’) 리디렉션 URI 매개 변수를 선택합니다. 사용 가능한 두 가지 형식은 웹 및 공용 클라이언트입니다. 리디렉션 URI는 웹 링크(HTTPS) 형식을 사용합니다. 공용 클라이언트를 선택하지 않은 한 링크가 유효하지 않아도 됩니다.
모든 단계를 마치면 해당 애플리케이션은 Microsoft Entra ID로 등록됩니다. 또한 서비스 사용자와 연결됩니다.
애플리케이션 역할 할당
Microsoft Entra 애플리케이션에는 다른 서비스와 함께 작동하려면 역할이 할당되어야 합니다. Azure는 RBAC(역할 기반 액세스 제어)를 사용하여 Azure 리소스에 대한 액세스를 엄격하게 관리하고 해당 리소스가 사용되는 방식을 관리합니다. 애플리케이션의 역할에 따라 권한 및 범위가 결정됩니다.
RBAC 권한은 범위 집합의 수준에서 상속됩니다. 예를 들어 리소스 그룹에 대한 reader 역할을 할당하는 경우 해당 그룹 내의 모든 리소스에 읽기 권한이 할당됩니다.
Azure Portal을 사용하여 앱이 키 자격 증명 모음에 액세스하는 데 필요한 역할을 할당합니다.
- 포털에서 키 자격 증명 모음을 선택합니다.
- 왼쪽에서 Access Control(IAM)을 선택합니다.
- 역할 할당 추가를 선택합니다.
- 필요한 역할을 선택합니다.
- 구성원 탭에서 사용자, 그룹 또는 서비스 주체에 대한 기본 액세스 할당 옵션을 적용합니다.
- + 구성원 선택을 선택합니다.
- 애플리케이션을 검색하여 선택합니다.
- 검토 + 할당을 선택합니다.
키 및 권한 관리
서비스 사용자를 사용하여 Azure 리소스에 액세스하려면 다음 두 가지 매개 변수가 필요합니다.
- 디렉터리(테넌트) ID: Microsoft Entra 테넌트를 식별하는 고유 ID입니다.
- 애플리케이션(클라이언트) ID: Microsoft Entra 애플리케이션을 식별하는 고유 ID입니다.
요청을 인증하려면 애플리케이션에 자격 증명이 필요합니다. 자격 증명을 사용하여 애플리케이션 자체를 식별할 수 있습니다. 다음 두 가지 형식의 자격 증명 중에서 선택할 수 있습니다.
- 인증서: 로컬에서 인증서를 생성한 후 .cer, .pem 또는 .crt 파일을 업로드합니다. 인증서는 일반적으로 공개 키라고 합니다.
- 클라이언트 암호: 이 복잡한 비밀 문자열은 Azure에서 생성됩니다. 클라이언트 암호는 애플리케이션 암호라고도 합니다.
클라이언트 암호를 사용하든 또는 인증서를 사용하든 이 자격 증명이 만료되는 시기를 정의해야 합니다. 만기는 조직에 따라 다르지만 1년이나 2년을 선택하는 것이 좋습니다.
참고 항목
인증서가 만료 될 수 있으므로 최상의 보안을 위해 클라이언트 비밀이 만료되도록 설정합니다. 이러한 자격 증명을 관리하는 것이 서비스 사용자를 사용하여 Azure 리소스에 액세스하는 앱의 단점입니다.
서비스 사용자를 사용하는 경우
이제 Microsoft Entra 애플리케이션을 만들고, 서비스 주체를 연결하고, 리소스에 대한 액세스 권한을 부여하는 수동 프로세스를 살펴보았습니다. 다음 두 가지 시나리오에서만 이러한 수동 프로세스를 사용합니다.
- 애플리케이션 또는 서비스가 온-프레미스에서 실행됩니다.
- 액세스해야 하는 리소스 또는 애플리케이션이 관리 ID를 지원하지 않습니다.
Azure 내에서 인증을 처리하는 가장 안전하고 편리한 방법은 관리 ID를 사용하는 것입니다.