Azure IAM (3) Service Principal와 Managed Identity

이전 글에서 RBAC 설정 시에 주체, 역할, 범위를 정의해야 한다고 했다. 그리고 역할과 범위 설정 시의 Azure RBAC의 특징을 설명했다. 이번 글에서는 주체를 설정할 때 일반적으로 생각할 수 있는 사용자 외의 개념인 Service Principal과 Manged Identity에 대해 설명한다.

Azure에서 애플리케이션이 Azure Storage, Key Vault, SQL Database 등 다른 리소스에 접근하려면 어떻게 해야 할까? 일반적으로 사용자 계정을 사용할 수도 있지만, 애플리케이션이 스스로 인증할 수 있는 방법이 필요할 때도 있다. 이를 위해 Service Principal(서비스 주체)와 Managed Identity(관리형 ID)라는 개념이 존재한다.

Service Principal이란?

Service Principal(서비스 주체)는 애플리케이션이 리소스에 접근할 수 있도록 만들어진 ID(계정) 개념이다. 마치 사람이 Azure AD에 계정을 만들어 로그인하듯, 애플리케이션도 Service Principal을 통해 인증을 받고 Azure 리소스에 접근할 수 있다.

온라인 배달 앱이 창고 관리 시스템과 연동되어 있다고 생각해보자. 배달 앱이 창고 시스템에 접근하려면, 창고 시스템에 로그인 정보(사용자 ID, 비밀번호)가 필요하다. 그러나, 사람이 직접 로그인하는 것이 아니라 배달 앱이 자동으로 창고 시스템과 연결되어야 한다. 이때 필요한 것이 바로 Service Principal이다. 배달 앱은 자신만의 계정(Service Principal)을 생성하고, 창고 시스템의 API에 요청을 보낼 때 Service Principal을 사용해 인증한다.

그래서 Azure 관점에서는 특정 리소스에 대해 접근할 수 있는 주체가 되다 보니 RBAC의 주체 설정 시에 포함되는 것이다. 하지만 일반 사용자처럼 MFA는 설정할 수 없다.

프로그래밍 방식의 로그인 경로라는 것이 어떻게 보면 AWS의 Access Key와 같다고 생각될 수도 있을 것 같다. 둘 다 애플리케이션이나 서비스가 클라우드 리소스에 접근할 수 있도록 하는 인증/권한 부여 메커니즘이지만, 동작 방식과 보안 관리 측면에서 차이가 있다.

비교 항목	Azure Service Principal	AWS Access Key
역할	애플리케이션이 Azure 리소스에 접근할 수 있도록 하는 ID 개념	AWS API 요청을 인증하는 자격 증명
인증 방식	비밀번호(Client Secret) 또는 인증서	Access Key ID + Secret Access Key
권한 부여 방식	Azure AD + RBAC를 사용	IAM Policy를 사용

Managed Identity란?

Managed Identity(관리형 ID)는 사실 아주 다른 개념은 아니고, Service Principal의 일종이다. Azure에서 자동으로 관리해 주는 Service Principal이라고 생각하면된다. Service Principal이 앱-리소스 관계에서의 인증을 위한 것이라면, Managed Identity는 Azure 리소스(VM, Functions, Logic Apps 등) 간의 자체 인증을 위한 것이다.

Service Principal이 사용자가 직접 로그인 정보를 설정해야 하는 시스템이라면, Managed Identity는 자동 출입 시스템과 비슷하다. 회사에서 매일 출근할 때마다 출입증을 갱신(비밀번호 변경)하는 것은 번거롭다. 그래서 회사는 자동 출입 시스템(Managed Identity)을 도입해서, 직원이 출근하면 자동으로 출입증이 생성되고, 문 앞에서 자동 인증되어 출입 가능하도록 한다. 직원은 출입증을 직접 관리할 필요 없이 회사가 알아서 갱신해 준다.

Azure에서도 동일한 원리로 Managed Identity는 Azure가 자동으로 ID를 관리하고, 사용자는 신경 쓰지 않아도 된다.

이 역시 RBAC 설정 시 주체로 포함될 수 있지만 개념이 그렇다 보니 MFA, IP 접근제어 등의 조건부 액세스가 제어되는 범위는 아니다.