[번역] 기존의 on-premise Active Directory를 클라우드와 연동해 클라우드 계정 로그인 연동, 각종 웹 어플리케이션 SSO를 하는 방법

이번 포스팅에서는 온프레미스에 존재하는 AD를 이용해 AWS 계정 로그인 연동, 윈도우 EC2 인스턴스를 AD 도메인에 조인시키는 방법,

각종 web application을 AD 계정을 이용한 SSO 연동에 대한 방법에 대해 소개하고자 합니다.

 

https://aws.amazon.com/ko/blogs/security/build-a-strong-identity-foundation-that-uses-your-existing-on-premises-active-directory/  해당 글을 번역 및 해석하고자 합니다. 앞서 단순히 번역하기보다는 주요한 부분만 요약 및 해석하고자 합니다.  

 

 

우선 AD란 무엇인가에 대해 간단히 언급하고자 합니다. 기업에서 AD를 쓰는 이유는 몇 가지 있습니다. 

1. 인사관리 
2. 그룹 정책을 통한 윈도우 자원 관리
3. DNS 서버 기능

 

인사관리

처음 입사를 하고 부여받는 사번이 바로 AD의 계정입니다. 일반적으로 이 계정을 통해 사내 PC에 로그인해 컴퓨터를 사용합니다. 인사 데이터를 관리하는 직원은 새로운 직원들의 입사/퇴사/부서이동에 대해 적절히 조치를 취하면서 권한을 부여/회수함으로써 인사관리가 가능합니다.

 

그룹 정책을 통한 윈도우 자원 관리

윈도우 서버의 경우 AD(Active Directory)에 조인이 가능합니다. AD에 조인됨으로써 AD가 설정해 놓은 그룹 정책에 영향을 받게 됩니다. 이렇게 AD에 조인된 윈도우 자산들의 보안 컴플라이언스을 일괄 중앙적으로 관리할 수 있는 장점이 있습니다. 

 

DNS 서버 기능

AD는 DNS 서버 기능을 할 수 있습니다. 덕분에 AD를 사용하는 기업들은 따로 DNS 서버를 두지 않고 AD로 대체 가능합니다. 윈도우 자산이 AD에 조인하기 위해서는 AD 서버의 아이피 주소를 나타내는 A 레코드뿐 아니라 다앙한 SRV 레코드 정보를 DNS 서버에 등록해야 합니다. 하지만 AD를 DNS 서버로 설정함으로써 이와 같은 수고를 덜 수 있습니다. 게다가 고가용성을 보장하게 구성되어야 하는 AD 특성 상 DNS 까지 곁다리로 고가용성이 보장된다는 장점이 있습니다. 

 

---

이번에는 왜 온프레미스에 존재하는 AD를 클라우드 환경에 확장시켜 클라우드 계정 로그인 연동, 윈도우 EC2 인스턴스를 AD에 조인, 각종 Web Application SSO 연동해야 하는 이유에 대해 언급하고자 합니다. 

 

1. 계정관리의 용이성
2. 권한 관리의 용이성
3. 클라우드 자원에 동일한 보안 컴플라이언스 보장 및 AD 중앙 관리

 

계정관리의 용이성

 직원의 입장에서 본인이 관리해야 하는 계정입니다. 누군가에게 패스워드를 함부로 알려주어선 안됩니다. 그런데 요즘 각종 devops 툴(Gitlab, Jenkins, 클라우드 계정 등)과 Saas 형태로 제공되는 솔루션(웹 형태로 제공되는 보안 솔루션 등)들이 많아짐으로써 직원이 해당 솔루션에 접근하기 위한 계정이 한두 개가 아닙니다.  

 

그렇다면 모든 직원에게 각 계정을 생성해 제공해야 할까요? 직원이 한둘이 아니고 일일이 계정을 생성하고 삭제하는 일은 언제 하나요? 아니면 하나의 계정을 생성해 공유해 써야 할까요? 계정을 관리하는 측면에서는 편해졌지만 누가 이 계정에 로그인했는지 알기 어렵게 될 것입니다. 

 

경우 1.  모든 직원에게 따로 계정을 제공하는 경우 발생할 수 있는 보안 취약점

1. 모든 계정의 아이디/패스워드를 동일하게 설정한다.
2. 패스워드가 오랜 기간 동안 변경되지 않은 채 방치된다.
3. 아이디/패스워드가 평문 형태로 메일/문서로 저장된다. 
4. 아이디/패스워드를 관리하는 직원에게 심각한 작업 부하가 발생한다. 

경우 2. 하나의 계정을 모든 직원이 공유해서 사용할 경우 발생할 수 있는 보안 취약점

1. 누가 로그인해 작업했는지 추적이 어렵다.
2. 아무도 이 계정의 패스워드를 관리하지 않는다. 
3. 아이디/패스워드가 평문 형태로 메일/문서로 저장된다.

---

왜 AD를 이용해 클라우드 계정 로그인 연동해야 하는 하는가?

AD를 이용해 클라우드 계정 로그인에 연동함으로써 계정관리가 매우 용이해집니다. 직원은 본인의 사번, AD 계정만 관리하면 되기 때문입니다. 클라우드에 로그인하던, Gitlab, Jenkins, 등등 어디에 로그인하던지 본인의 AD계정으로 로그인하면 됩니다. 즉 하나의 계정만 본인이 잘 관리하기 용이하기 때문에 위에서 언급된 보안의 취약점들을 해소할 수 있으며 보안팀 또는 운영팀에서도 계정관리라는 사소하지만 번거로운 작업에 시간을 낭비하지 않아도 됩니다. 

 

예를 들어 devops 업무를 맡은 A 직원이 새로 입사한 경우 A 직원의 계정을 devops라는 그룹에 포함시키기만 하면 필요한 접근권한을 획득하게 됩니다. 그리고 퇴사/부서이동을 할 경우 devops 라는 그룹에서 제외하기만 하면 로그인이 가능했던 웹 애플리케이션에 접근이 불가능하게 됩니다. 

 

권한 관리의 용이성

클라우드 계정과 AD의 SSO 연동, 각종 웹 애플리케이션과의 SAML 2.0을 이용한 SSO 연동은 계정 단위뿐 아니라 이 계정이 속한 그룹을 대상으로도 연동이 가능합니다. AWS SSO 기능을 살펴보게 되면 계정 또는 그룹 단위에 IAM 역할을 할당할 수 있습니다.

 

예를 들어 "관리", "일반"이라는 두개의 AD 그룹이 있습니다. "관리" 그룹에는 Administrator 라는 관리자 권한을 가진 IAM 역할을 할당, "일반" 이라는 그룹에는 Read-only라는 IAM 읽기 전용 역할을 할당하겠습니다. 각 사용자들 계정이 "관리", "일반"의 AD 그룹에 포함됨으로써 매칭 되어 있는 역할을 가지게 됩니다. 

 

그리고 웹 애플리케이션과 SAML 2.0을 이용한 SSO 연동 과정을 살펴보겠습니다. 우선 AWS SSO 서비스가 AD와 연동함으로써 AD 계정을 통해 웹 애플리케이션에 로그인이 가능해집니다. SAML 2.0 연동에서는 계정이 가진 특성(Attribute)을 이용해 계정 매핑 과정을 거치게 되는데 계정이 소속된 그룹 정보 역시 가지고 올 수 있습니다. 이 계정의 그룹 정보에서 만약 "관리"라는 그룹에 속해있다면 웹 애플리케이션의 관리자 역할에 매칭 되며 "일반"이라는 그룹에 속해 있을 경우 일반 권한 역할에 매칭 되어 로그인이 허용될 것입니다.

 

만약 이런 과정이 없더라면 웹 애플리케이션 또는 AWS 계정의 관리자는 사용자의 계정을 직접 생성하고 적절한 역할을 할당시켜줘야 합니다. 뿐만 아니라 퇴사/부서이동을 할 경우, 다시 계정을 삭제 또는 역할을 회수하는 작업이 따로 필요합니다. 이 과정 중 미처 깜빡하고 삭제/권한 회수하지 못한 계정들이 존재하게 되며 이 계정들은 관리되지 못한 채 방치되어 해킹의 취약점이 될 것입니다. 

---

클라우드 자원에 동일한 보안 컴플라이언스 보장 및 AD 중앙관리  

기업들은 윈도 자원을 관리하기 위한 목적으로 AD의 그룹 정책(Group Policy)을 사용합니다. 온프레미스 자원뿐 아니라 클라우드 자원 역시 동일한 그룹 정책을 적용하고 싶을 것입니다. 온프레미스 내 AD를 클라우드로 확장함으로써 일관성 있게 클라우드내 자원 역시 관리가 가능하게 될것입니다. 마찬가지로 온프레미스내 사용자들은 그대로 클라우드 자원에 접근이 가능할 것입니다. 

 

어느 한 기업이 하이브리드 클라우드를 도입하면서 온프레미스 AD를 클라우드로 확장하지 못하고 새로 AD를 클라우드에서 생성한 뒤 매일 새벽 온프레미스 AD를 관리하는 인사관리 솔루션으로 부터 인사 데이터만 내려받는 식으로 AD를 이원화해서 관리했던 케이스가 있습니다.  이 경우 이 포스팅에서 언급하는 AD 연동과 유사해 보이지만 실제로는 두 개의 AD가 따로 독립적으로 존재하는 경우입니다.

 

사용자의 경우에는 같아 보이는 자신의 계정이 실제로 별개이며 온프레미스용, 클라우드용 따로 관리해야 합니다. AD 관리자의 경우에도 온프레미스 AD, 클라우드 AD 2개를 따로 관리해야 하는 수고가 생깁니다. 

---

온프레미스 AD AWS 클라우드 내 확장 아키텍처 

온프레미스 네트워크와 AWS 클라우드 간 네트워크 연결에 대해 알아보겠습니다. 요약하자면 온프레미스 네트워크와  AWS 클라우드 내 네트워크 간의 연결을 위한 AWS Direct Connect와 각 프라이빗 네트워크 영역 간 연결을 위한 AWS Transit Gateway가 필요합니다. 

 

 

AWS Direct Connect

사이트 간 퍼블릭 인터넷을 우회하지 않고 프라이빗하게 암호화 통신이 가능한 최단 경로를 제공해주는 기능입니다. 실제 물리적 랜선 연결을 통해 이뤄지게 됩니다. 주로 하이브리드 클라우드 구성 또는 대규모 데이터의 신속하고 안정성 있는 전송을 위해 사용됩니다. 

AWS Transit Gateway

각 프라이빗 네트워크 간 연결 구성을 간소화할 수 있습니다. 온프레미스 <-> AWS Direct Connect <-> AWS Transit Gateway <-> VPC 간 네트워크 사이에는 실제로 게이트웨이, 라우팅 테이블을 각각 구성해야 합니다. 하지만 AWS Transit Gateway는 이런 수고를 간소화해주는 기능을 가지고 있습니다. 

Network Account, Shared Services Account 

AWS Ogranization 내 기능별로 계정을 분리해 두었습니다. 네트워크 관련 서비스는 Network Account에 배포에 필요한 서비스는 Shared Services Account에 구성합니다. 대규모 클라우드 구성에 있어 관리에 용이성을 가지기 위한 하나의 예제입니다. 

---

 

위 구성요소는 온프레미스 네트워크와 AWS 클라우드 간 연결을 위한 최소 요건입니다. 아직 DNS 서버 구성이 남아있습니다.  AD서버와 통신하기 위해서는 도메인 주소를 나타내는 A레코드뿐 아니라 각종 서비스(LDAP, Kerberos)등을 위한 SRV 레코드도 알아야 합니다. 보통 AD 서버 자체가 DNS 기능을 가지고 있기에 DNS 서버를 AD 서버로 지정해 이를 해결하지만 AWS 클라우드에 제공하는 VM 들은 기본적으로 DNS 서버가 Route 53으로 지정되어 있습니다. 

 

이번에는 Shared Services Account 내 VPC 안에 존재하는 EC2 인스턴스가 온프레미스 내 AD와 통신하기 위한 DNS 설정에 대해 알아보겠습니다.  

 

 

1. Shared Services Account 내 존재하는 EC2 인스턴스가 온프레미스 내 AD ad.example.com에 통신을 시도하기 위해 Route 53 Resolver에 ad.example.com에 대해 질의를 시도한다.
2. Route 53 Resolver는 Network Account 내  Outbound interface에 이 질의를 포워딩한다.
3. OutBound interface는 정의된 규칙에 따라 이 질의는 온프레미스 내 AD의 IP 주소로 전달해야 함을 AWS Transit Gateway로 전달한다.
4. 온프레미스의 AD의 DNS 서버는 이 질의를 수신하고 응답한다.  

---

AD와의 통신을 위한 네트워크 구성에 대해 알아보았습니다. 그런데 이 아키텍처에는 여러 가지 단점이 있습니다. 

• 만약 AD와의 통신이 단절되거나, AD에 장애가 생기면, 사용자들은  AWS 계정, Web application, 윈도 자원에 접근이 불가능해진다. 
• Shared Services Account 내 VPC에 존재하는 자원들이 온프레미스 AD와 통신하기 위한 경로가 복잡하다. 

이 두 가지를 해결하기 위해 Shared Service Account 내 VPC에 AD의 도메인 컨트롤러를 구성해 온프레미스와 클라우드 내 AD를 이중으로 구성하는 것입니다. 

 

 

AD의 이중화 방식은 다수의 도메인 컨트롤러를 구성하는 것입니다. 사용자는 그중 하나의 도메인 컨트롤러와 통신하게 됩니다. 각 도메인 컨트롤러들은 서로 싱크를 맞추며 이중화를 지원합니다. 

 

예를 들어 AD의 도메인 주소는 example.com이며 온프레미스 내 AD ad1.example.com 10.0.0.1과 ad2.example.com 10.0.0.2입니다. Shared Services Account 내 VPC에 도메인 컨트롤러를 구성하겠습니다. ad3.example.com 172.16.0.3과 ad4.example.com 172.32.0.3을 구성했습니다. 

 

만약 온프레미스 내 AD에 장애가 생기더라도 사용자 인증을 위해서는 ad3, ad4를 통해 가능하게 됩니다. EC2 인스턴스가 AD와 통신하기 위해서는 더 이상 건너 건너 온프레미스 네트워크까지 갈 필요 없이 ad3, ad4와 통신하면 됩니다. 

---

HA 구성에는 끝이 없는 걸까요? AWS는 이에 만족하지 않고 온프레미스형 AD에 부족한 HA를 보완하기 위해 온프레미스 AD 뿐 아니라 클라우드 내 AD에 장애가 올 경우를 대비해 AWS Managed AD를 구성해 온프레미스 AD와 트러스트 관계를 형성하고자 합니다. 이제 온프레미스 AD와의 의존성을 최소화시키고자 합니다. 

 

Shared Services Account 내 VPC에 AWS Managed AD를 구축합니다. AWS에서 제공하는 관리형 AD로서 온프레미스 AD와 비교해 가용성 측면에서 장점이 있지만 이를 구축한 주된 이유는 AWS에서 제공하는 서비스들 (AWS Single Sign-On, Amazon Chime, Amazon Connect, Amazon QuickSight, Amazon WorkSpaces, and AWS Transfer Family) 등에 필요한 윈도우 기반 인증과 연동을 위해서 Managed AD가 필요합니다.

 

이후에 언급할 AWS SSO 필요한 AD연동에는 온프레미스형 AD로는 불가능합니다. AWS Managed AD만 연동이 가능합니다. AWS Managed AD를 구성하기 위해서는 2가지 방법이 있습니다. 

 

1. AWS AD connect 
2. AWS Managed AD 

AWS AD connect의 경우에는 온프레미스 AD를 그대로 확장시켜 AWS 관리형 AD가 되는 것입니다. 이미 온프레미스 내 2개, 클라우드 내 2개의 도메인 컨트롤러를 가지고 있지만 이 AD connect를 하게 되면 온프레미스가 가진 정보 그대로 AWS 관리형 AD가 됩니다. 

 

AWS Managed AD는 새로운 도메인을 AWS 관리형 AD로 구축하는 것입니다. 우리가 여태 언급했던 AD example.com 과는 별개의 AD입니다. 그렇기에 트러스트 관계를 형성해 example.com 이 가진 계정 인증정보를 그대로 이어받아 사용 가능합니다. 

---

이제 AWS SSO를 위한 모든 구성요소를 구축했습니다. AWS SSO를 이제 구성하겠습니다. 

1. AWS Managed AD <-> AWS SSO
2. AWS Managed AD <-> AWS SSO <-> Web application 

AWS 계정에 로그인하기 위해서는 IAM에서 직접 계정을 생성할 수 있지만 AD 연동을 통해 이를 대신할 수 있습니다. AD 계정/그룹을 지정해 IAM 역할에 매칭 시켜줄 수 있습니다. 

 

예를 들어 AD 그룹 "클라우드 관리자"에 "Administrator" 역할을 매칭 시켜 줍니다. 이제 AD 그룹 "클라우드 관리자"에 포함되는 AD 계정은 클라우드 관리자 권한을 가질 수 있습니다. 반대로 AD 그룹에서 제외되는 순간 권한이 회수됩니다.

 

AD계정으로 AWS에 로그인했듯이 Web application에도 로그인 가능합니다. 마찬가지로 그룹으로 역할을 할당해 관리자, 일반 사용자를 구분해 권한을 부여할 수 있습니다. 

 

1. 온프레미스 내 AD의 도메인 컨트롤러를 클라우드 내부에 구축한 후 AWS Managed AD와 트러스트 관계를 형성합니다. 
2. 온프레미스의 AD의 계정으로 AWS 로그인이 가능합니다. 
3. 클라우드 내 윈도우 자원은 생성할 시 AD 도메인에 조인이 가능합니다 
4. AD 계정을 통해 윈도우 자원에 접근이 가능합니다. 
5. 윈도우 자원들은 AD에서 정의된 그룹 정책에 적용을 받습니다. 
6. 각종 Web application(Gitlab, Spinnaker, Jenkins 등)에 AD 계정으로 로그인이 가능합니다. 

---

마지막으로 AD 계정으로 AWS 계정 로그인, Web application 로그인 절차에 대해 한번 알아보겠습니다. 

 

 

 

1. AWS에 로그인하기 위해 포털에 접근해 AD계정의 아이디/패스워드를 입력한다.
2. AWS 로그인 인증을 위해서 AWS Managed AD와 연동되어 있고 Managed AD는 온프레미스에서 확장된 AD와의 트러스트 관계를 통해 계정 진위 여부를 판단한다.
3. 로그인 성공 후 접속 가능한 AWS 계정, 애플리케이션이 나타난다. 애플리케이션은 AWS SSO와 SAML 2.0 연동이 되어 있다.
4. 사용자가 애플리케이션을 클릭한 경우, 어플리케이션 http 주소로 리디렉션 된다. 
5. 사용자는 AWS SSO 콘솔을 통해 AWS, 어플리케이션 접속이 이뤄진다. 

---

이번 포스팅에서는 온프레미스 AD와 클라우드 간 통신, 확장 방안, SSO 연동 방안에 대해 알아봤습니다. 온프레미스내 AD를 클라우드로 확장시켜 AWS 계정, 각종 웹 애플리케이션  계정을 관리하는 방안은 보안적으로 참 유용하다고 생각합니다. 

 

 

 

해당 포스팅은 https://aws.amazon.com/ko/blogs/security/build-a-strong-identity-foundation-that-uses-your-existing-on-premises-active-directory/ 을 참조했습니다.