클라우드 시대(Cloud-Age)에 빠뜨리기 쉬운 보안 고려 사항에는 무엇이 있을까요?

바로 Identity(계정)입니다!

다양한 클라우드 기반의 서비스들이 쏟아지면서, 기업이나 조직은 클라우드 기반의 서비스를 필요에 의해 사용하려는 추세를 보이고 있습니다. 기업은 꽤 오래전부터 SSO(Single Sign On : 하나의 계정(Identity)을 사용하여 인프라에 접근하는) 방식의 인증을 선호하고 있고.. 이를 위해 다양한 솔루션들이나 방법론을 사용하고 있죠.

Microsoft 플랫폼의 Identity(계정)는 Active Directory(AD) 기반의 계정을 사용하는 것을 기본적으로 생각합니다. Microsoft의 다양한 백오피스 제품뿐만 아니라, Windows 인증을 사용할 수 있는 응용 프로그램은 사용자가 AD를 통해 인증받고, 생성한 보안 토큰을 이용하여 사용자를 인증하게 되죠.

클라우드로 이야기가 발전하면서 이야기는 조금 색달라지게 됩니다. 클라우드 이야기를 꺼내기전에, DMZ 구간에 배치된 기간망 응용 프로그램을 한번 생각해볼까요?

사내에 AD를 사용하여 인증을 받는 경우, 이 인증을 그대로 DMZ에 배치된 웹 서버에서 사용할 수 있을까요? 물론 기술적으로는 가능합니다만, DMZ와 내부 구간 사이의 방화벽의 포트 관리적인 측면이나, 웹 서버에 보안 문제가 발생했을 때, 유출될 수 있는 데이터의 범위를 생각해보면, 사용할 수 없는 방법이었습니다.

그렇다고, DMZ에 별도의 인증 서버를 구축하면 또다른 문제가 발생합니다. 위의 그림은 AD를 DMZ에 하나 더 구축한 것이라고 일단 생각하시면, 내부의 인증 서버와 외부의 인증 서버가 분리된 결과를 초래하게 되고, 결론적으로 Identity는 2개가 되어버린 셈이 됩니다. 그렇다고 각 AD 도메인간 트러스트(Trust)를 엮자니, 역시 앞서 생각한 문제처럼 방화벽의 포트 관리나 보안 이슈가 걸림돌이 됩니다.

그래서 보통들 사용했던 솔루션이 바로 Identity를 복제해주는 솔루션입니다. Microsoft에서는 이를 MIIS(Microsoft Identity Integration Server) 2003, ILM(Identity Lifecycle Manager) 2007, 최신 버전으로는 FIM(Forefront Identity Manager) 2010이 여기에 해당됩니다. 물론 우리나라에선 필요한 계정 저장소만을 복제해주는 솔루션들을 SI 프로젝트성으로 많이 개발해사용하셨죠. 살짝만 언급드리면, MIIS, ILM, FIM은 다양한 Identity 저장소간의 복제나 오케스트레이션(Orchestration)을 담당해주는 제품군으로, AD에서 계정이 지워지면, DMZ의 SQL, 원거리의 다양한 데이터베이스에서 데이터를 삭제해주고, 거꾸로 특정 데이터 속성이 업데이트되면, 이를 다양한 데이터베이스 및 Identity 저장소에 업데이트해주는 일을 주로 하게 됩니다.

가운데에 누군가가 끼어서, 이를 열심히 복제해주는 솔루션은 복제 대상이 되는 저장소가 많아질수록 복잡해집니다. 한쪽에서 복제가 똑바로 일어나지 않으면, Identity의 문제로 발전하게 되고, 이는 고스란히 정보의 유출이나 사내 공격과 같은 보안 사고로 이어지겠죠. 이해를 돕기 위해 DMZ의 예를 들었지만, 요새 유행하고 있는 클라우드 시대에도 동일한 Identity 이슈가 발생할 수 있습니다.

사내에 배치된 주요한 시스템과 클라우드에서 이용하는 서비스간의 Identity 고려가 바로 클라우드 시대에 놓치기 쉬운 보안의 기본 사항입니다. 그럼 어떻게 이를 손쉽게 해결할 수 있을까요?

매우 간단합니다. 생각을 약간만 전환해주면, 우리의 일상에 비슷한 예제가 있습니다. 일단 결론은 계정은 계정을 가진 곳에서만 관리하고, 서비스를 제공하는 자원 제공자는 자원만 제공해주는 일을 하자는 것이죠. 복잡하게 나눠서 둘을 관리해주는 이중화를 하지 말고요.

먼저 일상의 예를 들어볼까요? 여러분께서 외국을 나가실 때, 필요한 필수 아이템은 무엇인가요? 바로 여권(Passport)입니다. 지금은 무비자가 되었지만, 몇년전만해도 미국을 가려고 하면 비자를 받아야 합니다. 이때 미국에 들어가기 위한 별도의 신분증을 만드나요? 아닙니다. 여권에 하나의 스티커를 붙여주고, 이를 미국 입국시 제시하여 입국을 하게 됩니다.

이러한 형태는 유료 행사에도 동일하게 사용됩니다. 신분증(Identity)를 제시하고, 행사에서 착용하고 다닐 명찰을 받게 됩니다. 해당 명찰은 스피커용, 일반 참석용, VIP용등을 표시하는 다양한 색깔(?) 및 표식(Token)을 가지고 있습니다. 역시나 최초 등록시 제시하는 신분증은 바뀌지 않습니다. 신분증에 붙어다니는 표식이 그사람의 권한을 보여주는 것이죠.

기업에서 사용하는 Identity를 외부와 어렵지 않게, 그리고 안전하게 연결해주고, Identity가 가진 사용 범위에 따라 클라우드 서비스 제공자는 서비스를 제공해주는 것이 이미 2003년도부터 Microsoft 기술에서는 제공되고 있었습니다. 이를 Microsoft Active Directory Federation Service(ADFS)라고 불렀습니다.

ADFS는 표준 방식인 WS-*의 페더레이션 사양인 WS-Federation을 지원합니다. WS의 의미는 웹 서비스이므로, Identity 영역과 자원(클라우드 서비스) 영역간에는 Federated Trust(위 그림)이 맺어지게 되고, 이는 HTTPS를 사용하여 방화벽 이슈를 막아줌과 동시에 안전성을 확보합니다.

<클라우드 서비스 제공자의 ADFS>

<계정을 가진 조직의 ADFS>

위 그림 ContosoSRV02는 SharePoint 서비스를 제공하는 곳입니다. 그림내 아리 FabrikamSRV02는 클라이언트입니다. 지금까지 Fabrikam내 사용자가 Contoso내 SharePoint를 사용하려면, Contoso에서 계정을 제공받아야 했습니다만, WS-Federation 기반에서는 이야기가 틀려집니다. Contoso와 Fabrikam은 Federation Trust가 맺어져 있기 때문입니다. Fabrikam의 사용자가 ContosoSRV02에 접근하면, ContosoSRV02는 서비스의 인증을 제공해주는 ContosoSRV01(DC)로 이를 전송하게 되고, ContosoSRV01에 설치된 ADFS 모듈이 해당 사용자가 Federated Trust가 맺어진 Fabrikam내 사용자임을 인지할 수 있습니다. 인증에 대한 처리로 Fabrikam으로 해당 인증 요청을 전송하게 되고(HTTPS), 이를 확인한 FabrikamSRV01(DC)는 인증을 처리해주고, 해당 사용자가 ContosoSRV02를 사용할 수 있다는 토큰(Token)을 Identity에 붙여주게 됩니다. 이를 Security Token Services(STS)라고 부릅니다. 밑의 그림을 보시면 조금 더 쉽게 이해하실 수 있을 것으로 생각됩니다.

클라우드 서비스 제공자 입장에서는 서비스 만료가 되면, 계정을 삭제하는 것이 아니라, 단순하게 Federation Trust만 삭제하면 됩니다. 어떤 계정이 어떻게 접근할지는 서비스 제공자 입장에선 관심이 없다는 것이죠. 거꾸로 기업에서는 직원의 퇴사나, 업무 범위가 변경되면, 계정에 대한 작업만 변경해주면(Token) 해당 사용자는 더이상 클라우드 서비스를 이용할 수 없게 되겠죠. 이제서야 클라우드 서비스 제공자는 서비스에만 집중하고, 이를 이용하는 조직은 계정에만 신경을 쓸 수 있는 구조가 됩니다. 네트워크적으로도 HTTPS를 사용하니 방화벽 관리도 편리해졌고요.

이러한 STS를 사용하는 Identity를 Claim-based Identity라고 표현하고, 이를 사용하는 응용 프로그램을 Claim-based Application(CBA)라고 부릅니다. SharePoint의 경우 2007, 2010이 모두 이를 지원합니다.

Microsoft Windows 플랫폼에서 ADFS는 Windows Server 2003 R2에서부터 제공되어 왔습니다. 2003년도에는 이런식의 클라우드의 발전이 아닌, 본, 지사간, 파트너간과 같은 B2B 시나리오를 다루기 위해서 였지만, 이번달 말에 RTM이 될 ADFS 2.0은 클라우드 시대에 맞춰, Windows Live ID Server나 Windows Azure, 그리고 타 WS-Federation 표준 사양을 지원하는 Identity와 웹 페더레이션 연결이 가능하도록 만들어져 있습니다. ADFS 2.0의 Codename이 Geneva였고, 이 Geneva를 통해 Identity에 대한 방향성이 확실해졌죠.("Geneva" team blog, "Geneva" Whitepapers, "Geneva" home page 참고)

Identity에 대한 관리는 항상 중요하면서도 기본적입니다. 사내 Identity.. 그리고 서비스 시대에 맞춘 서비스에 대한 Identity.. 이 모든 것을 중앙에서 효율적으로 관리할 수 있어야 한다는 것이 Microsoft의 생각이며, 이러한 형태에서 정리한 프레임워크가 Windows Identity Framework가 이에 해당됩니다.

클라우드 및 서비스 시대에 놓치기 쉬운 보안의 가장 기본, 바로 Identity적인 측면이며, Identity는 항상 많은 생각을 해보시는 것이 어떨까 싶습니다.