Okta를 활용한 Office365 마이그레이션 방안

Microsoft Windows와 Office(특히 Excel과 PowerPoint)는 직장인들이 가장 많이 사용하는 소프트웨어입니다. OS의 경우 개발자자 혹은 일부 외국계 기업 종사자의 경우 Apple Macbook을 사용해 Windows가 아닌 Mac OS를 사용하는 비율이 꽤 되지만 Office는 예외가 없죠. Mac OS에서도 Mac 전용 Office를 사용하는 것이 일반적이거든요. 즉, 우리나라 뿐만이 아닌 전 세계에서 가장 많이 사용되는 소프트웨어는 Microsoft Office라고 해도 과언이 아닐 것입니다.

그런데 이 Office도 최근에는 SaaS형인 Office 365(지금은 Microsoft 365)로 전환되는 비율이 매우 높습니다. 신규 구매는 거진 다 설치형 라이선스나 FPP가 아닌 Office 365와 같은 구독형이 대세가 되었죠. 코로나19 때문에 확산된 원격근무의 영향으로 사무실이 아닌 집과 같은 다른 장소에서도 Microsoft Office를 원활히 사용하기 위해 기존 라이선스를 Office 365로 전환하는 사례도 늘어나고 있죠. Office 365를 구매해도 웹 버전이 아닌 내 PC에 설치해서 기존의 설치형 라이선스와 동일하게 사용할 수 있기 때문에 Microsoft Office의 라이선스 형태는 머지않아 SaaS로 거진 다 전환되지 않을까 싶습니다.

<이미지 출처 : ITSolutions, Microsoft 365 Benefits for Your Business>

그런데 막상 기존의 Office 라이선스를 Office 365로 전환하려면 단순하게 소프트웨어만 새로 구독하는 것으로 끝나지 않습니다. 인원이 적은 기업이라면야 그냥 Office 365 새로 구독해서 계정 만들어 사용하면 되지만 인원이 수십명, 수백명, 수천명 단위의 기업이라면 새롭게 Office 365용 계정을 만드는 것도 매우 큰일입니다. 

그리고 이정도 규모의 기업이라면 이미 Active Directory와 같은 계정관리 솔루션을 통해 사내 그룹웨어를 비롯해 각종 내부 시스템 및 설치형 Office 라이선스 관리까지 하고 있을 확률이 높기 때문에 Office 365로 전환할 경우 기존에 AD로 관리되던 계정을 어떻게 Office 365와 연동시킬 것인지에 대한 고민이 클 수밖에 없죠. 다행이 Microsoft는 이에 대한 옵션을 제공하긴 합니다만, 그렇게 간단하게 처리되지 않기 때문에 Office 365 전환 이후 계정 이관 작업이 IT 담당자 입장에서 꽤나 부담스러운 것이 사실입니다.

<이미지 출처 : GUFF, Password Stress Is Real (And Resulting In More Cybercrime)>

여처저차해서 Microsoft Office 365로 무사히 전환했다고 칩시다. Office 365는 SaaS형이고 한번 SaaS를 맛본 사람들은 이제 더이상 설치형 소프트웨어에 매달리지 않습니다. 기존에 사용하던 업무용 애플리케이션들을 하나 둘 SaaS 형태로 바꿔나가기 시작하죠. 사무실이 아니더라도, 언제 어디서나 웹으로 접근해서 업무를 이어나갈 수 있다는 것은 너무도 큰 장점이니까요. 이렇게 SaaS를 한번 맛 본 사람들, 기업들은 계속 SaaS를 찾게됩니다. 그리고 내부적으로 사용하는 SaaS의 종류가 많아질 수록 사용자들은 또 다른 골치아픈 문제에 직면하게 됩니다. 바로 계정관리입니다.

SaaS가 3~4개라면 기존에 사용하던 이메일주소로 ID를 만들고 비밀번호는 SaaS의 정책에 따라 달리 생성하더라도 쉽게 기억할 수 있습니다. 하지만 이 갯수가 7~8개, 심지어 10개 이상 늘어난다면 이제 비밀번호를 일일이 기억하기란 매우 어렵습니다. 그래서 자신이 사용하는 SaaS의 계정 정보를 PC 어딘가(대부분 바탕화면)에 저장해 두거나, 그룹웨어의 메모장 혹은 휴대폰에 저장해 두고 사용하곤 하죠. 모니터에 포스트잇으로 비밀번호를 적어서 붙여놓지만 않아도 다행입니다. 

하지만 이렇게 비밀번호를 관리하는 것은 사이버 공격에 매우 취약합니다. IT 관리자 입장에서는 이렇게 비밀번호를 관리한다는 것이 불러올 위험이 너무나도 크다는 것을 잘 알고 있지만 이렇게 관리하는 직원들이 한두명이 아니라 수십 수백명이라면, 이제는 강제로라도 IT팀에서 계정을 관리해야만 합니다. 그래서 AD, LDAP을 사용하지만 관리해야 하는 계정의 수, 그리고 사용하는 SaaS의 수가 늘어날수록 IT팀의 계정 관리에 대한 고민은 커져만 갈 수밖에 없습니다.

<이미지 출처 : Okta, Okta의 통합 기능이 제공하는 이점>

그래서 이번 콘텐츠에서는 Office 365를 사용하게 됨으로써 직면하게 되는 기존의 사용자 계정의 클라우드 이관 작업을 어떻게 보다 효율적으로 수행할 수 있는지, Office 365를 시작으로 늘어만가는 SaaS 계정을 보다 보안적으로 안전하게 관리함은 물론, 사용자들이 최신 보안 인증 기술을 통해 소프트웨어에 안심하고 접근할 수 있는 방법은 무엇인지 알아보겠습니다. 주요 아젠다는 아래와 같습니다.

1. Office 365로의 전환을 위해 해결해야 할 문제들

2. 클라우드 기반의 인증과 관리, Okta

3. 성공적인 클라우드로의 전환에 Okta가 필요한 이유

이 콘텐츠는 Okta의 지원으로 제작되었습니다.

1. Office 365로의 전환을 위해 해결해야 할 문제들

 1) IT 관리자가 Office 365로의 마이그레이션 시 직면하게 되는 두 가지 문제 

기존에 Microsoft Active Directory(이하 AD)로 사용자 계정을 그룹으로 묶어 정책으로 관리해온 기업이라면 이미 내부 시스템과 AD는 매우 긴밀하게 연동되어 AD없이는 사내 시스템 운영이 되지 않을 정도로 AD에 대한 의존도가 높을 것입니다. 사내에서 사용하는 Microsoft Office 라이선스 역시 사내 임직원들의 계정 별로 AD와 연동되어 있겠죠. 이런 상황에서 Microsoft Office를 Office 365로 전환할 경우 우선적으로 해결해야 할 것은 무엇일까요?

<이미지 출처 : Okta Blog, Challenges of Identity and Mobility for Office 365>

크게 두 가지 문제를 처리해야 합니다. 먼저 Exchange Server에 저장된 메일 데이터, SharePoint Server의 사내 공유 용 파일 데이터를 Office 365로 옮기는 작업을 수행해야 하는데 Microsoft에서 제공하는 무료 도구를 사용할 경우 시간이 오래 걸리고 과정이 다소 복잡한 편인데, 이를 해결하기 위해서는 별도의 3rd Party 전문 마이그레이션 솔루션 업체의 도움을 받아야 합니다.

그리고 어렵게 데이터 마이그레이션을 끝마쳤다 하더라도 기존에 온프레미스 AD 서버에 저장된 다수의 사용자 계정 정보를 토대로 사용자가 Office 365에 안전하게 접근할 수 있도록 인증 과정을 거쳐야 하며, 대량의 사용자 및 그룹 정보 동기화를 통해 Office 365에서 항상 최신의 사용자 정보를 유지할 수 있어야 합니다. 그리고 신규 사용자 생성 및 기존 직원의 직무 변경 또는 퇴사자 발생 시 이를 즉각 반영할 수 있어야 함은 물론 PC 외 다양한 모바일 기기를 통한 Office 365의 안전한 접근을 위해 MFA(Multi Factor Authentication)와 같은 보안 인증 방법을 구현해야 합니다.

 2) Office 365 마이그레이션을 위해 Microsoft가 제공하는 도구

<이미지 출처 : Microsoft, 자습서: 기본 Active Directory 환경>

많은 기업들은 기존의 온프레미스 환경에서 AD를 활용해 Exchange Server에 인증함으로써 사용자의 PC와 이메일 계정을 하나의 사용자 이름과 비밀번호로 인증하는 형태로 사용해왔습니다. 한번 Windows에 로그인하면 다시 Exchange에 로그인할 필요가 없는 것이죠. 게다가 AD는 Exchange 뿐만 아니라 내부 파일 서버, ERP, HR 애플리케이션과 협업 솔루션까지 다양한 비즈니스용 애플리케이션 인증에도 활용되었습니다. 즉, AD는 사내 중추적인 시스템을 연결하는 중추적인 역할을 해왔던 것으로 온프레미스에서 SSO(Single Sign-On) 환경을 구현했습니다.

하지만 Office 365는 클라우드 기반의 SaaS입니다. 온프레미스 AD에 저장된 사용자 계정과는 별도의, Office 365 인증을 위한 계정 정보가 필요한 것입니다. 하지만 이를 위해 Office 365를 위한 별도의 계정을 생성하는 것은 어렵게 온프레미스에서 AD를 통해 구현해 놓은 SSO 환경을 물거품으로 만드는 겪이죠. 때문에 Microsoft는 기존의 AD에 저장된 정보를 Office 365 에서도 활용할 수 있도록 Azure Active Directory를 마련해두었고, 몇가지 마이그레이션 방법을 제공합니다. 하나씩 간단히 살펴볼까요?

• ■ADFS(Active Directory Federation Services)

ADFS(Active Directory Federation Services, 이하 ADFS)는 사용자가 Office 365의 사용자 인증 요청에 직접 응답하여 사용자가 AD 계정에 접근하여 인증받을 수 있도록 하는 플랫폼입니다. IT 관리자는 최종 사용자단의 퍼블릭 인터넷부터 ADFS 서버까지, 그리고 ADFS에서 AD 도메인 컨트롤러까지 네트워크 경로를 직접 구성하고 관리해야 하며 이 네트워크 구성 단계 중 어느 한 곳에서 장애가 발생하면 인증이 불가능해 사용자는 Office 365에 접근할 수 없게 됩니다. 사용자가 자신의 온프레미스 AD에 저장된 것과 동일한 계정 정보를 토대로 Office 365에 접근할 수 있도록 하기 위해 온프레미스 AD 정보를 별도로 마련된 ADFS 서버 인스턴스로 리다이렉션하고 인증 자체는 온프레미스 AD서버에서 하기 때문입니다.

게다가 기업에서 ADFS를 배포하기 위해서는 기본적으로 온프레미스에 서버 4대, 네트워크 프록시와 로드 밸런서를 구성해야 합니다. 만약 기존에 사용하던 AD 규모가 제법 큰 포리스트 단위이고, 이 포리스트가 여러개일 경우 필요한 하드웨어 수는 급격하게 증가할 것이고 별도의 SQL 서버 클러스터가 필요할 수도 있습니다. 온프레미스의 AD 계정 데이터를 클라우드로 이관하기 위해 온프레미스 데이터 센터를 증설해야 하는 상황이 발생할 수도 있다는 것입니다. 우리는 클라우드를 사용하려고 하는데 온프레미스에 더 투자해야 한다니, 뭔가 아이러니 한 상황이 아닐 수 없습니다.

• ■Azure AD Connect

<이미지 출처 : Microsoft, Azure Active Directory에 애플리케이션 인증 마이그레이션 설명서>

Azure Active Directory(이하 Azure AD)는 클라우드 환경에서 기존의 온프레미스 AD 서버에 저장된 사용자 계정 정보가 Microsoft Office 365를 비롯한 다양한 애플리케이션과 연결될 수 있도록 합니다. 위와 같이 온프레미스 AD에 저장된 데이터는 Azure AD Connect를 통해 Azure AD와 동기화되며, Azure AD는 이 데이터를 기반으로 Office 365와 같은 다양한 클라우드 기반 비즈니스 SaaS와 안전하게 연결하고, SaaS는 사용자 정보를 Azure AD 데이터를 기반으로 인증합니다.

Azure AD Connect를 사용하기 위해서는 별도의 Azure AD Connect를 위한 서버가 필요합니다. 이 서버가 온프레미스 AD 서버와 연결되어 저장된 사용자 계정 정보를 가져와 Azure AD에 저장하게 되고, 이후 Azure AD가 비즈니스 SaaS의 인증 요청을 직접 처리하는 형태입니다. Azure AD Connect가 온프레미스 AD에 저장된 비밀번호 해시값을 Azure AD와 동기화 하는 것으로 이해하시면 됩니다. 덕분에 사용자는 온프레미스 AD에 저장된 계정과 비밀번호를 사용해 Azure AD와 연결된 SaaS에 로그인할 수 있는 것입니다.

하지만 Azure AD Connect에서 사용하는 비밀번호 동기화 옵션은 많은 기업들의 높은 보안 요건을 충족하지 못합니다. 온프레미스에 마련된 Azure AD Connect 서버가 AD서버와 동기화 하는 과정에서 장애가 발생해 Azure AD에 저장하는 사용자 계정 정보에 누락이 발생하더라도 대응할 방안이 없는 것이죠. Azure AD Connect는 단일서버이기 때문입니다. 이를 해결하기 위해서는 별도의 자원을 투자해 Azure AD Connect 서버를 Active-Standby 고가용성 환경으로 구현해야 하는 단점이 있습니다.

• ■통과 인증(Pass-through authentication)

<이미지 출처 : Microsoft, Azure Active Directory 통과 인증으로 사용자 로그인 설명서>

통과 인증은 비밀번호 해시 동기화 옵션의 대안으로서 Microsoft가 제공하는 또 하나의 방법으로 사용자 암호는 온-프레미스 Active Directory 도메인 컨트롤러에 전달되어 유효성이 검사됩니다. 덕분에 사용자는 회사 네트워크 내부에서 회사 PC의 애플리케이션에 접근하기 위해 암호를 입력할 필요가 없습니다. 과정이 다소 복잡하고 대규모 서버 구성 및 배포가 필요한 ADFS에 비해 훨씬 간편하게 SSO 모델을 구현할 수 있습니다.

하지만 통과 인증은 최종 사용자의 자격 증명을 온프레미스 AD의 도메인에서 검증하기 때문에 여러개의 트리로 구성된 AD 포리스트(Forest)는 지원하지 않아 규모가 큰 기업이 요구하는 수준을 충족하지 못할 수 있습니다. 게다가 Azure AD Connect 서버가 정상적으로 실행이 되어야만 통과 인증이 제대로 작동하기 때문에 별도로 마련한 온프레미스의 Azure AD Connect 서버의 안정성이 매우 중요하다고 볼 수 있습니다.

<이미지 출처 : Okta, Active Directory>

이렇게 Microsoft가 제공하는 방법을 사용할 경우 기업 규모가 작은 편이라면 쉽게 해결 될 수도 있지만, 기업 규모가 크고 사용하던 AD의 데이터가 방대할 수록 기존의 데이터 센터 자원을 증설하거나 인증 서버를 고가용성 환경으로 구성하는 등 온프레미스 안정성 확보에 더욱 투자해야 하는 상황이 발생합니다. 그냥 심플하게 온프레미스의 데이터를 클라우드로 손쉽게 이관하고, 이관된 데이터는 클라우드에서 안전하게 보호되어 사용자에게 강력한 보안 인증 수단을 제공할 수 있으면 좋을텐데 방법이 없을까요? 네, 있습니다. 지금부터 소개할 Okta의 솔루션이 이러한, Microsoft가 제공하는 방법들이 가진 한계를 어떻게 극복할 수 있는지 알아보겠습니다.

2. 기업의 아이덴티티 정보를 클라우드 기반으로 안전하게 인증하고 통합 관리하는 Okta

Okta는 앞서 살펴본 Microsoft가 제공하는 ADFS, Azure AD Connect, 통과 인증을 위해 별도의 온프레미스 자원을 증설하지 않고 기존의 AD에 저장된 데이터를 Office 365와 연결합니다. 이 과정에서 네트워크 프록시와 로드밸런서는 필요하지 않고 복잡한 인증을 위한 구성도, 퍼블릭 인터넷에서 AD로 수신되는 트래픽 관리도 필요하지 않으며 자동 장애 조치 및 실시간 사용자 계정의 자격 증명을 통해 대기업의 높은 보안 요건을 충족할 수 있습니다. 이것이 어떻게 가능한 것인지 하나씩 살펴볼까요?

 1) 에이전트를 통한 간편한 마이그레이션 환경 구성

Okta는 온프레미스 AD 서버에 5MB 미만의 매우 가벼운 에이전트를 설치합니다. 에이전트를 사용함으로써 ADFS와는 달리 마이그레이션을 위한 전용 서버를 구성할 필요가 없고 에이전트가 AD 도메인 컨트롤러와 통신하여 사용자 계정 정보 검증 후 Okta에 전달하고, Office 365는 Okta에서 인증 정보를 가져와 사용자를 검증하는 프로세스입니다.

또한 표준 보안 웹 프로토콜(SSL/HTPS)를 통해 에이전트부터 Okta까지의 연결을 계속 유지해 온프레미스 AD 도메인에서 사용자 계정 정보가 변동될 경우 실시간으로 Okta와 동기화됩니다. 게다가 100개가 넘는 AD 도메인을 단일 Okta 테넌트에 연결해도 될 정도로 안정적으로 동작합니다. 

Okta 클라우드 서비스에는 에이전트 풀이 있고, 모든 에이전트가 AD와 연결되어 인증 요청에 대기하고 있습니다. 이 때 사용자가 Office 365에 접근을 시도하면 Okta가 AD 연결을 로드 밸런싱해서 자동으로 적당한 에이전트를 선택하고, 이 인증 요청(자격 증명 요청)이 AD 도메인 컨트롤러로 전송되면 여기서 자격 증명이 검증됩니다. 이 방식을 '위임 인증'이라고 부르며 앞서 언급한 ADFS의 기능을 Okta가 대신하는 셈입니다. 그리고 에이전트가 설치된 서버 중 하나에서 장애가 발생하더라도 하나 이상의 에이전트가 설치되어 있다면 서버를 이중화 구성해 둘 필요 없이 자동으로 에이전트 차원에서 장애에 대응할 수 있습니다.

 2) 사전에 구성된 연결 방법을 사용해 간편하게 Office 365와 연결

앞서 살펴본 ADFS에서는 사용자가 인증서를 직접 설정하고 정책 검토하고 연결해야 했지만 Okta는 사전에 구성된 Office 365 연결 방법을 제공해 손쉽게 AD의 사용자 계정 정보와 Office 365를 연결할 수 있도록 지원합니다. 위와 같이 Okta Integration Network에서 Office 365 앱을 검색해 Okta 조직에 추가하고 Office 365 테넌트 이름과 페더레이션할 도메인, 관리자 이름 및 비밀번호 등 몇 가지 정보를 입력하는 것 만으로 Okta가 전체 페더레이션 설정으로 자동으로 처리합니다. 이후 Okta의 Universal Sync 기능을 통해 AD에 저장된 데이터가 Office 365로 동기화되며 사용자는 온프레미스 AD에 저장된 계정 정보를 그대로 사용해서 Office 365에 로그인할 수 있습니다.

 3) Okta와 Office 365가 결합되어 인증 문제를 손쉽게 해결

Okta는 처음부터 클라우드를 염두에 두고 아키텍처를 설계했기 때문에 온프레미스에서 출발한 Microsoft의 접근 방식과는 다릅니다. 위와 같이 ADFS, Azure AD Connect 사용을 위해 필요한 전용 온프레미스 서버가 필요하지 않고 ADFS, Azure AD Connect를 사용하지 않고도 이 두 방법이 제공하는 모든 효과를 Okta를 통해 누릴 수 있습니다. 예를 들어, AD 비밀번호 해시를 Office 365에 복하살 필요 없이 앞서 언급한 위임 인증을 통해 Okta가 그 역할을 대신합니다.

따라서 Okta는 기존의 Microsoft가 제공하는 ADFS, Azure AD Connect, 통과 인증이 제공하는 기능을 온전히 누리면서 정작 이 도구들은 사용하지 않는, 그래서 별도의 온프레미스 자원에 추가적으로 투자하지 않아도 되는 솔루션이라고 할 수 있겠습니다.

<이미지 출처 : Microsoft, 조직의 Azure AD Multi-Factor Authentication 개요>

그리고 Office 365는 오랫동안 WS-Federation 인증만 지원해 와서 최근들어 늘어난 MFA 수요에 제대로 대응하지 못했습니다. 지금과 같은 하이브리드 업무 환경의 확산과 SaaS 사용의 보편화로 사용자들은 MFA에 매우 익숙하죠. 하지만 Office 365가 그 동안 MFA를 지원하지 않았기 때문에 사용자들은 Office 365가 보안적으로 덜 안전한 것이 아닌가라는 불안감을 가질 수 있었습니다. 

이 문제를 극복하기 위해 Microsoft는 ADAL(Azure Active Directory 인증 라이브러리)를 사용하기 시작했습니다. Microsoft의 전속 소프트웨어 라이브러리 세트인 ADAL은 여전히 널리 사용되는 Microsoft Outlook과 같은 소프트웨어 클라이언트나 iOS, Android 기기를 기반으로 하는 이메일 클라이언트, 즉 씩(Thick) 클라이언트들의 브라우저를 인증 단계에 삽입할 수 있도록 지원함으로써 어떤 클라이언트에서도 Office 365에 연결하기 위한 인증 프로세스를 MFA로 구현할 수 있게 했습니다. 그리고 Okta는 Microsoft Azure AD 페더레이션 호환성 목록에 있는 아이덴티티 공급자로서 ADAL 인증을 완벽히 지원해 Office 365의 MFA를 구현할 수 있습니다.

 4) Active Directory가 고수해온 전통적인 아키텍처의 복잡성 해결

<연도별 Microsoft의 사용자 계정 정보 동기화 도구 목록>

온프레미스 AD서버에 저장된 방대한 데이터를 기반으로 한 Office 365에서의 인증 문제를 해결했다고 끝난것이 아닙니다. 대량의 사용자 계정 뿐만 아니라 Exchange Server에 저장된 이메일 주소와 연락처 등 방대한 데이터들에 대한 접근 권한을 기존 환경에서는 AD로 제어해 왔죠. 따라서 이 데이터까지도 Azure AD로 가져와야 하는 작업이 더 남았습니다. 그리고 마이그레이션이 끝났다 하더라도 이후에 발생하는 온프레미스 AD에서의 사용자 계정 변경(신규 직원 입사, 퇴사자 발생, 기존 직원의 직무 변경 등) 사항이 클라우드의 Azure AD로 동기화 되어 신속하게 반영돼야 합니다.

앞서 여러번 언급한 Azure AD Connect는 Microsoft가 제공하는 디렉터리 동기화 도구입니다. 그런데 Azure AD Connect의 기원은 대용량 아이덴티티 관리 플랫폼인 MIM(Microsoft Identity Manager)을 간소화한 버전으로 Azure AD Connect와 MIM 모두 2003년에 개발된 MIIS(Microsoft identity Integration Server)를 기반으로 합니다. 그리고 이 방식은 오랫동안 IBM, Oracle, CA와 같은 비즈니스 애플리케이션 공급자들이 사용해 왔지만 이는 온프레미스 기반의 환경에서나 통용되는 아키텍처이지 클라우드 기반의 환경에서는 알맞지 않습니다.

<이미지 출처 : Microsoft, 자습서: OKTA 동기화 프로비저닝을 Azure AD Connect 기반 동기화로 마이그레이션>

게다가 기존의 온프레미스 AD 환경이 복잡하다면 마이그레이션 역할을 담당하는 Azure AD Connect의 속도가 느려지기 때문에 더 큰 용량의 MIM으로 업그레이드해야 하나 별도의 비용을 지불해야 하고 배포 기간에 최소 1~2개월이 걸리며 서버 역시 추가로 2~4대까지 필요합니다. 앞서 여러번 언급했던 것처럼 클라우드 기반으로 시스템을 이관하는데 온프레미스 인프라에 더 투자하는 것은 합리적인 결정이 아닙니다. 실제 온프레미스의 AD 데이터의 클라우드 마이그레이션을 위해 ADFS, Azure AD Connect, MIM을 가동하는 데에 18 ~ 24개월의 기간을 투자한 기업들도 있었는데, 이러한 고객들은 Okta를 통해 필요한 모든 요건을 충족하면서 기간을 6배나 단축시킬 수 있었습니다.

Okta를 사용하면 관리자는 AD에서 Okta Universal Directory로 위와 같이 몇 가지 간단한 설정만으로 기존 사용자와 그룹을 가져올 수 있으며 사용자 계정 정보 변경에 신속하게 대응할 수 있을 뿐더러 중앙 관리자 콘솔에서 간편하게 관리할 수 있습니다.  

기업들은 오랫동안 AD를 기업의 모든 이직원 정보를 저장하는 공간으로 사용해 왔습니다. 그리고 온프레미스 환경의 HR 시스템이나 기타 여러가지 비즈니스 애플리케이션을 AD로 연결해서 사용해왔죠. 하지만 이제 기업들은 기존에 온프레미스에서만 사용하던 다양한 유형의 비즈니스 애플리케이션을 클라우드 서비스로 이관하고 있습니다. HR시스템도 Workday와 같은 최신 클라우드 서비스로 이관하고 있으며 고객정보는 Salesforce에, 사용자 전화번호는 RingCentral로 옮기고 있습니다. 하지만 이렇게 서로 다른 서비스에 분산되어 저장되어 있는 데이터를 Office 365로 가져오려면 어떻게 해야 할까요? 이 서비스들의 정보를 AD와 동기화시켜, 이를 다시 Office 365로 보내야 할까요?

Microsoft Azure AD Connect는 Office 365 외에 다른 클라우드 서비스에는 연결하지 않기 때문에 사용할 수 없습니다. Azure AD Connect이 기반 기술인 MIM을 사용하면 해결할 수 있지만 너무도 많은 시간과 비용이 필요합니다. 그래서 Okta가 필요합니다. Okta Universal Directory로 클라우드 서비스에 저장된 데이터가 동기화되고, 이를 다시 Office 365로 배포할 수 있습니다. 즉, Okta가 기업에서 사용되는 모든 아이덴티티 정보를 통합적으로 관리할 수 있다는 것입니다.

 5) Office 365에 Okta를 사용함으로써 얻을 수 있는 추가적인 이점

Okta를 통해 온프레미스 AD에 저장된 데이터를 Office 365 인증에 활용할 수 있고, 어떻게 이것이 가능한지는 이제 충분히 알았습니다. 하지만 이게 다가 아닙니다. Okta는 Office 365에 필요한 아이덴티티 라이프사이클 전체를 관리할 수 있습니다. Office 365에 Okta를 사용함으로써 얻을 수 있는 추가적인 이점은 아래와 같습니다.

• ■그룹 기반의 라이선스 할당

Okta는 에이전트를 활용해 AD 그룹을 Okta로 가져왔기 때문에 일부 사용자 그룹 별로 Office 365에 대한 접근을 허용할 수 있습니다. 그룹 별로 Okta에서 Office 365 앱에 할당함으로써 Office 365에 접근할 수 있는 그룹을 제어할 수 있게 됩니다. 즉, AD에서 그룹을 관리하는 것만으로 Office 365의 접근을 제어할 수 있는 권한이 생기는 것입니다. 이는 사용자 그룹 중 Office 365에 대한 접근이 필요한 그룹과 그렇지 않은 그룹으로 나누어 Office 365 라이선스를 할당할 수 있다는 것을 의미합니다.

• ■라이선스 관리 자동화 및 세분화

Okta는 기업이 보유한 모든 라이선스를 간편하게 할당하고 관리할 수 있는 UI를 제공합니다. 덕분에 IT 관리자는 라이선스를 그룹 별로 할당함은 물론 좀 더 세분화해서 관리할 수 있습니다. 예를 들어, 관리할 사용자 집단을 AD 그룹이 아닌 LDAP 서버, Workday, Box와 같은 다른 시스템에서 가져와 라이선스를 차등 할당할 수 있습니다. 게다가 사내 영업팀에는 Exchange와 Lync만 활성화해서 Microsoft E3 라이선스를 할당할 수 있고, 지원팀에는 SharePoint Online만 활성화해서 E3 라이선스를 할당할 수도 있습니다. 이처럼 기업이 보유한 Office 365 라이선스를 아주 세밀하게 나눠서 관리할 수 있게 됩니다.

• ■최종 사용자를 위한 자동화

Okta를 사용하면 최종 사용자가 사용하려는 기기를 통해 기업의 Office 365에 접근하는 과정이 자동화됩니다. 사용자는 그저 자신의 모바일 기기에서 Office 365 앱을 다운로드 한 다음 Okta에 인증만 하면 됩니다. 사용자 기기가 Office 365에 접근하는데에 필요한 계정 정보 배포와 라이선스 관리가 자동으로 이루어지기 때문에, 관리자는 단지 사용자를 AD에 추가하기만 하면 됩니다. 나머지 과정은 Okta가 자동으로 처리하니까요. 이를 통해 신규 입사자는 복잡한 절차를 거치지 않고 신속하게 자신의 기기를 사용해 사내에서 제공하는 Office 365에 접근할 수 있게 됩니다.

• ■차별화된 MFA

Okta는 사용자의 MFA 인증 활성화를 위해 개별적으로 지정할 필요 없이 그룹 단위로 관리하고 정책을 적용할 수 있게 합니다. IT 관리자는 MFA 적용 시점을 정의하는 정책을 만들어 해당 정책에 그룹을 적용하면 끝입니다. AD에서 신규 사용자가 생성한 후 Okta 도메인 정책에서 'Domain Users'그룹을 사용하면 이 사용자들이 로그인할 때 자동으로 MFA가 요구됩니다. 이 외에 별도로 필요한 작업은 없습니다. 게다가 이 MFA 정책을 애플리케이션 단위로도 관리할 수 있습니다. Office 365에는 MFA를 적용하고, Zendesk와 같은 다른 앱에는 적용하지 않을 수도 있습니다.

게다가 Okta는 다양한 타사 MDF 벤더와 통합되어 보다 유연하게 운영됩니다. Okta는 Office 365에 사용할 MFA 솔루션의 유형을 가리지 않기 때문에 RSA SecurID, Symantec VIP, YubiKey, Duo Security 같은 클라우드 MFA 벤더와 자사의 Office 365와 같은 클라우드 서비스에 MFA를 적용할 수 있습니다. 이미 내부적으로 별도의 MFA 솔루션을 사용하고 있다면, 그것을 걷어내고 반드시 Okta를 사용하는 것이 아닌, Okta를 매개체로 하여 현재 사용하는 MFA 솔루션을 손쉽게 Office 365를 비롯한 다양한 클라우드 서비스에 적용할 수 있다는 것입니다.

3. 성공적인 클라우드로의 전환에 Okta가 필요한 이유

지금까지 기업이 기존의 온프레미스 환경에서 사용하는 대량의 사용자 계정 등 AD에 저장된 아이덴티티 데이터를 어떻게 Office 365로 이관할 수 있고, Microsoft가 제공하는 방법과 비교해 Okta가 어떤 이점이 있는지를 자세히 살펴봤습니다. 앞서 언급했던 것처럼, Microsoft가 제공하는 대표적인 AD의 클라우드 마이그레이션 도구인 Azure AD Connect는 Office 365만 지원하기 때문에 지금과 같이 다양한 SaaS를 사용하는 기업이라면 알맞은 도구가 아니기 때문에 Okta를 사용해야 함을 알았습니다.

MIM에 기반을 두고 있는 Azure AD Connect는 태생이 온프레미스 기반 아키텍처이고 이것을 클라우드에 적요하기 위해 발전시킨 것입니다. 하지만 Okta는 처음부터 클라우드를 염두에 두고 설계된 서비스형 IAM(Identity and Access Management) 솔루션입니다. 온프레미스에 ADFS, Azure AD Connect 사용을 위한 별도의 서버 인프라 증설 없이 몇 배나 더 빨리 Office 365로 데이터를 마이그레이션 함과 동시에 강력한 인증과 간편한 관리 기능으로 기업의 성공적인 Office 365로의 전환 프로젝트를 지원할 수 있습니다.

Okta는 비단 Office 365만을 위한 솔루션이 아닙니다. 게다가 Okta를 사용하기 위해 기존에 온프레미스 환경에서 잘 사용하고 있던 AD 혹은 LDAP을 걷어낼 필요는 더더욱 없습니다. 앞서 살펴봤듯이 Okta는 에이전트를 온프레미스 AD 서버에 설치해서 데이터를 Azure AD와 동기화시키는 것처럼 온프레미스 AD와 함께 사용합니다. 따라서 이미 온프레미스 환경에서 오랫동안 사용해온 레거시 애플리케이션과 연결된 AD를 버릴 필요가 전혀 습니다.

혹자는 클라우드 기반의 Okta를 사용하게 되면 온프레미스의 AD를 버려야 하는 것 아니냐고 오해하기도 합니다. Okta는 기존의 온프레미스 환경을 유지하면서 더 잘 활용할 수 있게, 그리고 비용 효율적으로 사용할 수 있도록 도와주는 솔루션입니다. 게다가 Office 365를 비롯한 다양한 비즈니스용 SaaS와의 연결을 지원하기 때문에 기업이 온프레미스에서 클라우드로의 전환을 돕는 중간 다리 역할을 톡톡히 해낼 수 있는 솔루션이라고 이해하시면 좋겠습니다.

이제 막 비즈니스를 시작하는 단계의 규모가 작은 스타트업이라면 Office 365를 시작으로 다수의 SaaS를 동시에 사용한다 하더라도 계정 관리에 큰 어려움은 없습니다. 서두에서 언급한 보안적으로 다소 취약한 계정 관리 방법도 크게 문제가 되지 않습니다. 하지만 비즈니스가 성장하면서 기업 규모가 커지고, 임직원의 수가 수십명 수백명 단위로 늘어나기 시작하면 종전과 같은 계정 관리 방안으로는 관리 효율성도 매우 떨어지거니와 보안적으로도 취약한 상태가 되버립니다. 

어느 정도 비즈니스가 안정적으로 궤도에 올라 이제 업무 효율성과 보안이라는 두 마리 토끼를 모두 잡아야 하는, 앞으로 쭉 성장 가도를 달릴 기업과 더불어 이미 거대한 규모이지만 조금씩 클라우드로의 이관을 준비하는 대기업이라면 Okta가 클라우드로의 여정에 훌륭한 동반자 역할을 할 수 있음을 이 콘텐츠를 통해 조금이나마 알게 되셨으면 하는 바람을 가져봅니다.

마지막으로 이 콘텐츠의 내용은 'Office 365 마이그레이션을 가로막는 아이덴티티 장벽 제거하기' 백서의 내용을 정리한 것으로, 보다 자세한 내용이 알고 싶으신 분들은 아래의 이벤트에 참여하시어 백서도 다운로드 받고 커피 기프티콘도 받아가시는 행운을 누려보시기 바랍니다.

이 콘텐츠가 사내에서 Office 365 전환 프로젝트를 고민하시는 분들께 조금이나마 도움이 되기를 바랍니다. 끝!