사람들은 누구나 편리한 서비스를 누리고 싶어 하고, 이를 위해서 큰 비용을 지불하고 있습니다. 그리고 이러한 편의성을 누릴 수 있도록 하는 많은 아이디어가 쏟아져 나오고 있죠. 일부 보안 솔루션 역시 이와 동일한 방향성을 가지고 움직이고 있는데요. 보안 솔루션은 보안성을 기반으로 편의성을 최대화하기 위해 노력하는 솔루션과 편의성을 기반으로 보안 문제가 없도록 고민하는 솔루션의 두 종류로 나뉩니다.

오늘 소개할 IAM은 후자의 대표적인 사례라고 할 수 있습니다. 개념이 생성되고 표준이 정의되기 시작한 후, 벌써 20년도 더 된 내용인데요. 사용자(혹은 관리자)의 편의성에서 출발한 이 개념은 사회의 변화에 따라 최근에도 편의성을 지원하는 새로운 표준을 만들어가며 수명을 유지하고 있습니다.

IAM은 Identity Access Management의 약자로 계정의 생성과 생성된 계정을 통한 인증, 권한 관리를 포함하는 개념입니다. 보안솔루션을 기준으로 설명하자면 IM(계정관리)과 EAM(권한 관리), 그리고 SSO(단일인증)를 더한 개념으로, 대부분의 IT 프로젝트에 있어 사용자 접점의 최전선에 있죠. 주된 관심사는 사용자 계정 생성의 편의성(IM), 권한 부여/회수 등의 권한 관리 측면에서의 편의성(EAM), 다양한 시스템 인증(SSO)에 대한 편의성인데요. 이렇듯 새로 생성되는 개념들과 조화를 이루며 솔루션이 발전하고 있습니다.

이번 글에서는 IAM을 이루는 각각의 기능 중 SSO, EAM에 관해 자세히 알아보고, 다음 콘텐츠에서 IM을 소개하도록 하겠습니다.

SSO (Single Sign On)

SSO는 어떤 시스템에 접근하는 과정에서 한 번의 인증을 통해 해당 시스템과 연계된 모든 시스템을 추가 인증 없이 접근하도록 하는 개념인데요. 사용자들이 시스템별 비밀번호를 관리하는 불편함을 해소하고자 만들어진 솔루션으로, 최초 인증된 시점에 인증토큰을 발급하고 연계된 시스템에 접근 시 해당 인증토큰을 참조해 인증하도록 합니다.

초기에는 사용자 정보를 암호화해 GET, POST 방식으로 주고받는 parameter 방식으로 진행됐는데요. 이후 사용자 PC에 인증정보를 저장하는 Tray 방식을 거쳐 별도의 인증서버를 두는 현재의 방식으로 넘어오게 됐습니다. SSO 관련 표준은 인증서버를 두는 것을 기준으로 제정됐으며, 주요 내용은 사용자 인증과 인증토큰의 관리입니다. OAuth1.0부터는 인증 부분은 분리해 인증토큰을 관리하는 것을 위주로 표준이 생성됐으며, 분리된 인증 부분은 OIDC 표준을 통해 지원하고 있습니다.

적용 시점에서 일반적인 SSO 이슈로는 인증을 처리하는 방식의 선택과 연계 대상 시스템 간 사용 가능한 표준 프로토콜이 상이하다는 문제가 있을 수 있습니다.

1. 인증처리 방식

SSO는 일반적으로 인증서버에서 인증을 담당하는 통합형 인증을 지원하고 있는데요. 인증서버가 다운되거나 네트워크 단절되는 경우 모든 시스템의 인증이 멈춰버리는 문제가 발생하기에, 각 시스템에서 인증을 진행하고 SSO에서는 인증토큰만을 관리하는 독립형 인증에 대한 기능도 지원합니다.

후자의 경우 최근에는 일반화 되어있는 NAVER, KAKAO, Google 등의 시스템 인증정보를 통한 SSO 발생을 생각하면 이해가 쉽습니다. 인증은 신뢰할 수 있는 다른 시스템을 통해 진행하고 해당 시스템에서 넘겨받은 사용자 정보를 통해 인증토큰을 관리하는 방식이죠. 내부 시스템에서는 포털이나 그룹웨어에서 인증을 담당하고 인증서버를 통해 인증토큰을 발행해 SSO를 발생시킵니다.

다만, 이 경우 인증을 담당하는 모든 시스템에서 사용자의 패스워드를 관리하고 동기화해야 하는 이슈가 발생할 수 있으므로 인증을 어디서 담당할 것인가는 해당 프로젝트의 특성을 분석해 설계해야 합니다.

2. SSO 표준 프로토콜

SSO 적용이 필요한 경우, SSO 대상 시스템에 SSO Agent(server side)의 설치를 인증서버(SSO Server)와 통신을 통해 인증토큰을 받아와서 해당 시스템을 인증하게 됩니다. 이 과정에서 소스 수정이 필요하게 되는데요. 일부 솔루션(대부분 외산 솔루션)의 경우, 소스 수정이 불가해 SSO 표준 프로토콜을 통해 SSO를 발생시켜야 하는 경우가 있습니다.

다만, 대부분의 표준이 그렇듯 SSO 표준 역시 소스 레벨까지 정확한 표준을 정의하고 있지 않은 것이 문제입니다. SSO 솔루션과 ERP, GW, Portal 등의 SW들이 해석하는 프로토콜이 조금씩 다른 경우, 해당 부분을 맞춰가는 과정에서 많은 시간이 소요되는데요. 그렇기 때문에 사업 시작 전에 SSO 대상 시스템 중 소스 수정이 불가능한 SW를 선별하고 도입하는 SSO 솔루션이 해당 SW들과 SSO 연계를 해보았는지 혹은 개발을 통해 프로토콜을 맞춰줄 수 있는지를 미리 확인해야 합니다.

EAM (Enterprise / Extranet Access Management)

회사에서는 다양한 사업을 통해 많은 기능을 가진 업무 시스템을 만들고 있습니다. 이러한 업무시스템은 모든 직원들이 본인에게 가장 편한 형태로 업무를 할 수 있도록 개인화 과정을 지원하고 있는데요. UI 측면에서 포틀릿을 통한 메뉴 배치나 본인의 업무에 필요한 메뉴만 노출되도록 세팅하는 것은 이미 일반적입니다.

이 중 전자의 경우, 사용자가 직접 설정하면 되지만 후자의 경우 관리자가 보안적인 측면을 고려해 각 사용자에게 맞는 권한을 부여하게 됩니다. 이 과정에서 모든 사용자의 업무를 분석해 초기 권한을 세팅하고, 일정 기간 TF 형태의 협업을 통해 특정 메뉴에 대한 권한을 가지거나 인사이동 등으로 인해 권한이 변경되는 경우 관리자에게 엄청난 업무량이 쏟아지게 됩니다.

이러한 관리자의 업무를 도와주는 솔루션이 바로 EAM(권한 관리)입니다. EAM은 초기에는 소스상에 하드코딩으로 권한이 관리됐는데요. 권한 관리 모델이 정립된 후로 UACL을 거쳐 현재의 RBAC 형태로 넘어오게 됐습니다. 권한 관리 대상인 자원(메뉴, 버튼, 탭 등)에 대해 사용자를 직접 매핑했던 UACL과 달리 RBAC는 역할(Role)이라는 개념을 도입해 사용자에게 역할을 부여하고 역할을 자원에 매핑함으로써 권한을 관리합니다.

UACL로 관리되는 경우, 홍길동이 경영지원팀에서 보안팀으로 부서를 이동하면 관리자는 홍길동의 기존 권한을 모두 회수하고 보안 관련된 메뉴들을 확인 후 홍길동에 매핑해줘야 합니다. 하지만 RBAC로 관리되는 경우라면 관리자는 역할만 바꿔주면 되죠.

한발 더 나아가 아래의 그림처럼 부서 자체를 역할에 매핑하는 경우라면 관리자는 아무것도 하지 않아도 됩니다. 홍길동이 경영지원팀에서 보안팀으로 부서 이동되는 경우 보안팀의 역할을 자연스럽게 승계 받을 수 있기 때문입니다.

그래서 EAM의 경우 솔루션의 적용보다는 얼마나 많은 부분을 자동화 처리될 수 있도록 컨설팅 해주느냐가 관건이라고 할 수 있는데요. 이러한 컨설팅을 위해서는 EAM 구축 담당자와 고객 실무담당자, 응용개발 PL 등의 주요 담당자들의 역할이 중요합니다.

적용 시점에서 일반적인 EAM 이슈로는 메뉴관리의 문제와 각 대상 시스템별 권한 관리 적용 가능 범위의 문제가 있습니다.

1. 메뉴관리의 문제

일반적으로 EAM의 관리 화면은 관리의 편의성을 위해 각 시스템별 메뉴를 트리구조로 관리자에게 보여주게 됩니다. 관리자는 이 트리구조를 통해 현재 운영되는 시스템들의 메뉴 순서를 확인하고 어떤 버튼들이 포함됐는지 알 수 있죠. 그런데 이러한 메뉴 구성은 여러 시스템의 관리 화면에도 동일하게 존재하며, 고객은 자연스레 각 시스템별 관리 화면을 통합하는 것을 고려하게 됩니다.

이 경우 구축 담당자는 메뉴관리 통합이 가능한지 확인하는 절차를 진행하게 되는데요. 결론부터 얘기하자면 인하우스 형태로 개발 및 구축을 진행하는 포털, 그룹웨어들은 DB Table 상에 필요한 column 정보만 충족된다면 EAM의 메뉴관리와 호환이 가능합니다. 다만, 설계 초기에 반영돼야 하는 부분으로 EAM 도입 예정이라면 해당 부분에 대하여 미리 분석하고 반영하는 것이 중요합니다.

2. 권한 관리 적용 범위

권한 관리를 적용하는 각 시스템들은 EAM으로 사용자 ID를 보내 접속 가능한 자원(메뉴, 버튼, 탭)들의 정보를 회신 받고 해당 정보를 참조해 화면을 구성합니다. 이 과정에서 소스 수정이 불가능한 솔루션과의 연동이 필요한 경우, 어떤 인터페이스를 통해 권한을 전달할 것인지 미리 고려해야 합니다. 경우에 따라서는 해당 시스템의 DB에 직접 업데이트하거나 역할은 EAM에서 관리하고 세부 권한은 해당 시스템에서 관리하는 등의 적용 방식도 고려해 볼 수 있습니다.

다음 글에서는 IM에 대해 자세히 알아보도록 하겠습니다.

[참고]

OASIS : https://www.oasis-open.org/specs/index.php
RFC 기술정의 : https://datatracker.ietf.org/doc/html/rfc6750
AWS IAM : https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/intro-structure.html

글 ㅣ LG CNS 사이버시큐리티팀 권해경 책임