Azure의 Access control 보안과 Azure Active Directory의 계정 관리 서비스
Azure의 계정 관리가 다소 혼란스러운 면이 있어서 정리해 봤습니다.
우선, Microsoft 계정이 있습니다. 가령 다음의 계정이 마이크로소프트 계정이라면 각종 서비스(아웃룩, 포럼, ...)에 로그인이 가능합니다.
계정: test@testad.com (마이크로소프트 계정)
마찬가지로 이 계정으로 당연히 "Microsoft Azure" 웹 사이트, 즉
https://portal.azure.com Azure Portal에 로그인할 수 있습니다. 이 단계까지는 auzre portal은 단순히 Azure 서비스를 알려주는 사이트에 불과하며 Azure의 어떠한 서비스도 이용할 수 없습니다. 즉, 가상 머신이나 Web App 등을 생성할 수 없습니다.
이 상태의 test@testad.com 사용자는 다음과 같은 역할을 하게 됩니다.
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
test@testad.com 사용자가 Azure 서비스를 사용하기 위해서는 구독(Subscription)을 해야 합니다. (이 글에서는 "MySub"라는 이름으로 구독했다고 가정하겠습니다.) 일단 구독을 하게 되면 test@testad.com 사용자는 해당 구독의 "Owner" 역할로 자동 등록됩니다. 따라서 이제부터는 test@testad.com 계정은 다음의 3가지 역할을 동시에 갖게 되는 것입니다.
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독(Subscriptions)의 Owner 계정(Access control - IAM)
여기에 더해서, Azure는 구독을 한 경우 자동으로 Azure Active Directory에 test@testad.com 계정을 관리자로 자동 추가합니다. 따라서 실제로는 다음과 같이 4가지 역할을 갖게 됩니다.
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독(Subscriptions)의 Owner 계정(Access control - IAM)
* MySub - Azure Active Directory의 Global administrator Role에 속한 Member
얼핏 보기에 Access Control과 AAD는 관련 없는 듯 보이지만 계정 관리 기반은 AAD에 있습니다. 즉, AAD가 있는 상태에서 그 디렉터리에 등록된 사용자에 대해 Azure 구독의 Access Control 권한을 주는 것입니다.
Azure 구독을 다른 마이크로소프트 계정의 사용자(여기서는 예를 들어 user@my.com)와 함께 관리를 하고 싶다고 가정해 보겠습니다. 그럼, test@testad.com 사용자는 user@my.com 사용자를 Azure 구독(Subscriptions)의 Access control에 등록하게 되지만, 위에서도 언급했듯이 Access control은 AAD 기반 위에 Role을 부여하는 것이기 때문에 Azure는 이런 경우에도 Access control에 등록된 외부 사용자를 AAD에 Guest 계정으로 자동 등록해 줍니다.
그리하여 test@testad.com 계정과 user@my.com 계정은 다음과 같이 권한을 소유한 상태입니다.
test@testad.com
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독의 Owner 계정
* MySub - Azure Active Directory의 Global administrator Role에 속한 Member
user@my.com
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독의 Contributor 계정 (test@testad.com 계정이 Contributor로 등록해 주었다고 가정)
* MySub - Azure Active Directory의 Guest
단순히 Azure 리소스 서비스를 사용하는 경우라면 AAD는 Azure 구독의 Access control을 위한 기반 서비스에 불과합니다. 하지만, AAD는 본연의 계정 관리 서비스를 함께 제공합니다. 즉, Azure 구독의 Access control과의 연계 없이 독자적으로 AAD에 계정을 등록/관리할 수 있습니다. 윈도우 서버 관리자라면, 기존 윈도우 서버에 있던 Active Directory 계정 관리 서비스가 Azure의 클라우드 버전으로 포팅된 것으로 생각해도 무리가 없습니다.
예를 들기 위해 testad.com 회사의 사용자 3명을 AAD에 추가한다고 가정해 보겠습니다.
user@testad.com
coworker@testad.com
cure@testad.com
추가할 때, 다음의 3가지 중 하나에 해당하는 "Directory role"을 설정할 수 있습니다. ("구독의 Access control"과 연관된 Role이 아니고 "Directory 서비스의 Role"입니다.)
- User (Users can access assigned resources but cannot manage most directory resources.)
- Global administrator (Global administrators have full control over all directory resources.)
- Limited administrator (Select the administrative role or roles for this user.)
대체로 기존 Active Directory 개념의 사용자를 등록하는 경우라면 "User"를 할당하겠고, 그 외 함께 Azure Active Directory를 관리할 목적이라면 "Limited administrator"를 주고 다음의 권한들 중 취사선택해서 할당할 수 있습니다.
- Billing administrator
- Compliance administrator
- Conditional access administrator
- Exchange administrator
- Guest inviter
- Password administrator
- Information protection administrator
- Skype for Business administrator
- Privileged role administrator
- Reports reader
- Security administrator
- Security reader
- Service support administrator
- SharePoint administrator
- User administrator
위의 권한 목록을 봐도 알 수 있지만, AAD의 Role들은 Azure 구독에서 제공하는 구체적인 리소스(VM, App Services, Functions, ...) 자체와 크게 상관이 없습니다. 말 그대로 기존 Active Directory의 계정 정보 보안에 해당하는 기능들이 나열된 것뿐입니다. (Billing administrator 같은 Azure 특화된 role도 있긴 합니다.)
여기서 재미있는 것은 마이크로소프트가 AAD에 등록된 사용자 계정을 기본적으로 Azure Portal 사이트에도 로그인이 가능하도록 만들어 준다는 점입니다. 그래서 사용자는 마이크로소프트의 계정은 아니지만 AAD에 등록된 것만으로 자연스럽게 Azure Portal에도 로그인을 할 수 있습니다.
그 외에, 비록 AD에 속한 사용자들이 자신이 속한 Azure 구독의 자원들을 활용할 권한은 없지만 원한다면 스스로의 구독을 생성해 Azure 서비스를 이용할 수는 있습니다. 예를 들어, cure@testad.com 사용자가 자신만의 구독(여기서는 CureSub)을 열었다고 가정해 보겠습니다. 그에 대한 비용은 cure@testad.com 개인이 지불하면 되는, test@testad.com이 생성한 구독과는 아무런 관련이 없습니다.
물론 AAD에 등록된 사용자에게 test@testad.com이 생성한 구독에 대한 권한을 주는 것도 가능하며, 심지어 AAD에 등록되지 않았었던 user@my.com 사용자의 경우 Access control에 등록해 자동으로 AAD에 추가된 경우이기도 합니다. 이 글에서는 coworker@testad.com 계정을 MySub 구독의 Contributor로 추가한 걸로 가정합니다.
여기까지, 등록된 계정들을 다음과 같이 정리할 수 있습니다.
test@testad.com
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독의 Owner 계정
* MySub - Azure Active Directory의 Global administrator Role에 속한 Member
user@my.com
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독의 Contributor 계정
* MySub - Azure Active Directory의 Guest
user@testad.com
* Azure 사이트 로그인 계정
* MySub - Azure Active Directory의 User 계정 (test@testad.com 계정이 설정했다고 가정)
coworker@testad.com
* Azure 사이트 로그인 계정
* MySub 구독의 Contributor 계정
* MySub - Azure Active Directory의 Limited administrator 계정 (test@testad.com 계정이 설정했다고 가정)
cure@testad.com
* Azure 사이트 로그인 계정
* MySub - Azure Active Directory의 User 계정 (test@testad.com 계정이 설정했다고 가정)
* CureSub 구독의 Owner 계정
* CureSub - Azure Active Directory의 Global administrator Role에 속한 Member
당연히 한 사용자가 2개의 구독을 갖는 것도 가능합니다. 예를 들기 위해 독자적인 구독을 열었던 cure@testad.com 사용자에 대해 test@testad.com 사용자의 "MySub" 구독에 대해 Contributor로 추가한 걸로 가정하면 다음과 같이 계정 권한이 바뀝니다.
test@testad.com
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독의 Owner 계정
* MySub - Azure Active Directory의 Global administrator Role에 속한 Member
user@my.com
* 마이크로소프트 계정
* Azure 사이트 로그인 계정
* MySub 구독의 Contributor 계정
* MySub - Azure Active Directory의 Guest
user@testad.com
* Azure 사이트 로그인 계정
* MySub - Azure Active Directory의 User 계정 (test@testad.com 계정이 설정했다고 가정)
coworker@testad.com
* Azure 사이트 로그인 계정
* MySub 구독의 Contributor 계정
* MySub - Azure Active Directory의 Limited administrator 계정 (test@testad.com 계정이 설정했다고 가정)
cure@testad.com
* Azure 사이트 로그인 계정
* MySub 구독의 Contributor 계정
* MySub - Azure Active Directory의 User 계정 (test@testad.com 계정이 설정했다고 가정)
* CureSub 구독의 Owner 계정
* CureSub - Azure Active Directory의 Global administrator Role에 속한 Member
위와 같은 상황에서 cure@testad.com 사용자는 Azure 구독이 2개가 되며 Azure portal에서 우측 상단의 사용자 계정 아이콘을 눌러 펼치면,
원하는 디렉터리 서비스를 선택해 인증 서버를 변경할 수 있습니다.
Azure 구독을 하면, 일종의 리소스에 대한 Folder 개념에 해당하는 "Resource Group"을 생성할 수 있습니다. 재미있는 것은 이 리소스 그룹 자체도 구독(Subscription)과 동일한 형식에 해당하는 자신만의 계정(Access control - IAM)을 가집니다. 사실 리소스 그룹뿐만 아니라, Azure에서 제공되는 모든 서비스들의 항목(Load balancer, App Services, Virtual machines, SQL Server, Blob Storage, ...)들이 자체적인 Access control을 제공하므로 그에 따른 계정을 설정할 수 있습니다.
일례로, test@testad.com 사용자가 다음의 Azure 리소스를 생성했다고 가정해 보겠습니다.
TestGrp [리소스 그룹]
* vm1 [가상 머신]
* vm2 [가상 머신]
기본적으로 Access control의 권한은 상위에서 하위로 상속됩니다. 따라서 MySub 구독에 대해 test@testad.com은 Owner이고, user@my.com, cure@testad.com은 Contributor이기 때문에 TestGrp 및 그 하위의 가상 머신 vm1, vm2에 대해서도 다음과 같은 권한 설정이 됩니다.
TestGrp [리소스 그룹]
- test@testad.com Owner (inherited)
- user@my.com Contributor (inherited)
- cure@testad.com Contributor (inherited)
* vm1 [가상 머신]
- test@testad.com Owner (inherited)
- user@my.com Contributor (inherited)
- cure@testad.com Contributor (inherited)
* vm2 [가상 머신]
- test@testad.com Owner (inherited)
- user@my.com Contributor (inherited)
- cure@testad.com Contributor (inherited)
기억해야 할 점은, 위와 같이 "inherited"로 표시된 권한들은 삭제할 수 없다는 것입니다. 따라서 MySub 구독에 대해 Contributor로 설정되어 있으면 해당 구독에 속한 모든 Azure 자원들에 대해 Contributor 권한을 갖게 됩니다.
이 상태에서 user@testad.com에게 vm1의 Owner 권한을, user@my.com에게 vm2의 Owner 권한을 추가하는 것이 가능합니다.
TestGrp [리소스 그룹]
- test@testad.com Owner (inherited)
- user@my.com Contributor (inherited)
* vm1 [가상 머신]
- test@testad.com Owner (inherited)
- user@my.com Contributor (inherited)
- cure@testad.com Contributor (inherited)
- user@testad.com Owner
* vm2 [가상 머신]
- test@testad.com Owner (inherited)
- user@my.com Contributor (inherited)
- cure@testad.com Contributor (inherited)
- user@my.com Owner
위의 상황에서 vm1의 경우 user@my.com은 Contributor이기 때문에 vm1을 포함해 그 하위 자원들에 대해 계정을 생성할 수 없습니다. 반면 user@testad.com은 Owner 권한이 있기 때문에 임의 계정을 추가하는 것이 가능합니다.
vm2의 경우 user@my.com이 Contributor이면서 Owner입니다. 이럴 때는 결국 Owner 권한이 있는 것이므로 계정 생성까지 자유롭게 할 수 있습니다.
이 정도 시나리오면, Azure의 권한 관리에 대해 대략적인 그림이 그려질 것입니다. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]