안녕하세요. 스푼라디오 정보보안팀의 Cloud Security 담당자 Evan입니다. 스푼에서는 업무목적으로 사용하는 모든 시스템과 솔루션의 통합 인증(Authentication) 및 인가(Authorization) 지원을 위해 Okta를 도입하여 사용하고 있는데요.
서비스 이용자 정보보호와 법률적 보안 요구사항 준수 뿐만 아니라 내부 직원의 시스템 접근 및 권한부여 또한 안전하고 효율적으로 관리하기 위해서 많은 노력을 하고 있습니다. 이를 위해 권한 부여 시 “별도의 승인 절차”를 구성하여 계정 관리 절차를 운영하고 있었지만 초기 버전의 Okta에서 구현했던 프로세스로 문제점들을 가지고 있었습니다.
이번 블로그에서는 기존 권한신청 프로세스 구현 및 알림을 위해 사용하던 Self-service와 Workflow 조합의 문제점들을 Okta Identity Governance(이하OIG)의 도입 및 변경으로 한층 더 개선한 경험을 소개하려고 합니다.
기존 문제점
1) 리소스 과다 생성 및 관리
기존에 사용자의 Application 권한 신청 및 승인 프로세스를 구현하고 자동화하여 적절하게 사용하기 위해서는 아래의 리소스들에 대한 생성과 관리가 반드시 필요한 구조였고, 많은 App을 연동하면서 이에따라 생성해야하는 아래 리소스들이 급증하게 되었습니다. 특히 App 별 세부 권한제어를 위해 사용한 Profile Attribute가 기하급수적으로 늘어나면서 각 User가 가지게 되는 Profile의 항목들이 너무 많아져 관리에 어려움이 있었습니다.
- Group 및 Group Rule
- User / App Profile
- Self-service
- Workflow
2) 세부 권한 부여에 대한 완전자동화의 어려움(Profile)
- 승인자는 신청자가 작성한 코멘트에 따라 User Profile 내 권한속성을 수동으로 지정해주어야 했습니다.
3) 이력 확인의 어려움(Self-Service)
- 로그가 남기는 하지만 권한 신청/승인에 대한 이력만을 정확하게 Audit하는 데에는 어려움이 있었습니다.
4) 신청/승인 프로세스의 커스텀 불가(Self-Service)
- 신청화면 및 입력할 수 있는 정보가 매우 제한되어 있어 다양한 Application 별로 권한 신청/승인 프로세스를 구현하는데 어려움이 있었습니다.
개선을 위해 도입
1) OIG 란?
Okta에서는 OIG를 아래와 같이 정의하고 있습니다.
“기업이 보안 상태를 개선하고, 최신 리스크를 완화하며, 효율성을 개선할 수 있도록 지원하는 SaaS 기반의 통합 ID 및 액세스 관리(IAM) 및 거버넌스 솔루션”
위 다이어그램에서 Access Governance 영역이 OIG를 통한 권한관리의 특장점으로 볼 수 있으며 아래와 같이 정의되어 있습니다.
Access Governance는 아래 네 가지 주요 기능을 통해 솔루션의 중심 역할을 하며, 액세스 관리 작업을 간소화하고 관리자가 필요할 때 적절한 사람들이 적절한 리소스에 액세스할 수 있도록 합니다.
- Access Request: App 및 리소스에 대한 액세스 요청 프로세스를 간소화 및 자동화 합니다.
- Access Certification: 중요한 리소스에 대한 사용자 액세스를 주기적으로 검토합니다.
- Entitlement Management: 세분화된 App 권한을 단일 플랫폼에서 검색, 관리, 할당 할 수 있습니다.
- Out-of-the-Box Reporting capabilities: 감사 및 규정준수 요구사항을 충족할 수 있도록 감사보고서를 제공합니다.
이를 통해, 다음의 문제점을 개선할 수 있다고 소개하고 있습니다.
- 복잡하고 경직된 워크플로
- 단절된 최종 사용자 경험
- 인적 오류의 위험성
- IT 생산성 저하
2) OIG 구성요소 및 기능
OIG의 Access Request를 구현하기위해 필요한 구성요소와 기능은 다음과 같습니다.
Request Type 표면: Name / Team / Audience
- Name: 신청자에게 노출 될 신청양식(request type)의 이름
- Team: 해당 request type 요청에 대한 승인 관리를 위한 관리자
- Audience: 해당 request type을 사용할 수 있는 대상
Request Type 내부로직: Question & Task(Approval, Action) & Timer
- Question: 텍스트 입력, 드롭다운, 날짜 선택기 를 통해 신청자로부터 정보수집하는 영역
- Task: 크게 Approval과 Action으로 구성되며, 신청자가 입력한 정보에 따른 실제 내부 프로세스를 정의하는 영역
- Timer: 권한부여 기간 및 승인에 대한 기한 등에 대한 스케줄 설정이 필요할 경우 사용하는 기능
진행내용
자 그럼 문제점과 OIG에 대한 기능파악이 어느정도 이루어 졌으니 실제로 이를 이용하여 어떻게 개선하였는지 그 여정을 간략히 소개하겠습니다.
1) 현황검토
Okta에 연동되어 있는 전체 Application에 대해 아래의 현황을 확인합니다.
- Self-service 존재 여부
- 연동방식(SAML/OIDC/SWA)
- 단일 or 다중 App 연동
- 권한 분리 여부
- Provisioning 여부
- 전용 Group 존재 여부
- 승인자 및 다중승인 필요 여부
OIG로 프로세스 신규생성 및 대체를 하기위해 반드시 확인이 필요한 항목들로 연동방식 및 Provisioning 등에 따라 구현가능 범위가 달라질 수 있고, 권한분리 등을 위해 동일한 목적을 가진 App이 다중 연동되어 있는지, Group은 별도 생성되어 있는지, 다른 App에도 사용중인 Group이 할당되어있지 않은지, N차 승인 구현이 필요한지 등의 여부에 따라 할여되는 리소스가 다르기 때문에 면밀한 사전 현황검토가 필요합니다.
2) 진행방향
전체 Application에 대해 어떠한 기준과 우선순위를 가지고 진행할지 결정합니다. 연동되어 있는 App이 200여개로 많은 상태였기 때문에 어떠한 우선순위와 기준을 가지고 진행해야 할지 결정한 뒤 계획에 따라 진행해야 했습니다.
- 연동 method 및 sign-on 구조 별로 categorization 한다.
- OIG 이관 시 개선 효율성이 높은 기준으로 우선순위를 정한다.
- 순차이관 진행하며 SAML, OIDC 로 연동 된 Application을 우선 작업한다.
3) App Admin 과의 긴밀한 논의
Application 별로 권한구조가 다르기 때문에 OIG로 프로세스 구현하려는 App Admin 과의 긴밀한 논의가 필요합니다.
- 신청자로 부터 입력받을 정보(Questions)
- 권한 만료기간의 설정(Action & Timer)
- 승인권자 지정(Approval & Task & Action)
- Flow내 각 object의 Sequence/Inheritance Logic
가장 중요한 부분이라고 생각합니다. App Admin 과의 논의 및 합의가 이루어 지지않고 생성된 프로세스는 무의미하거나 이후 유지보수에 더 많은 리소스가 소모될 수 있기 때문입니다.
4) 관련 리소스 생성
OIG & Slack을 통해 권한 신청/승인 프로세스 구성 시 반드시 필요한 리소스를 생성합니다.
- Okta Group: 권한분리 및 신청자의 App 할당을 위해 필요합니다.
- OIG Teams: 대상 App의 OIG관리자 및 승인권자로 구성합니다.
- OIG Configuration lists: 승인 절차내 세분화된 권한셋을 정의하는 객체입니다.
- Request Type: App 관리자 요구사항 및 Okta 관리자의 기준을 반영하여 실제 대상 App에 권한 신청/승인 절차를 생성합니다.
5) 기존 리소스 및 프로세스 제거
기존 프로세스를 위해 생성되었던 모든 리소스를 제거합니다.
- Group Rule 제거
- Profile 제거
- Application 제거
개선결과
1) 관리 리소스의 감소
생성해야하는 리소스 및 지속 관리해야하는 권한 부여목적의 Profile Attribute를 모두 삭제함으로써, 과다 존재하던 전체 사용자의 profile이 깨끗하게 정리되었습니다. 이를통해 가시성도 확보되고 관리에 소모되던 리소스를 제거할 수 있었습니다.
2) 사용자 편의성 향상
사내 메신저(Slack)를 통해 App 별로 커스터마이징 된 간단한 권한신청 절차를 진행하고, 이에따른 진행상황을 확인할 수 있으며, 승인완료에 대한 알림을 Slack에서 받고 이와 동시에 권한부여가 완료되는 형태로 진행되기 때문에 신청자/승인자 모두의 편의성이 크게 향상 되었습니다.
3) Audit 가시성 증대
기존에 권한 신청/승인 이력확인을 위해 사용자별, App별 시스템 로그를 확인해야하는 불편한 프로세스가 아닌 OIG 내 별도 로그가 상세저장되므로 Audit의 가기성을 확보할 수 있게되었습니다.
4) 결과예시
OIG와 Slack을 통한 권한 신청 및 승인 절차 개선결과 예시로 아래의 AWS SSO App을 통해 소개드리려고 합니다. 신청자와 승인자 Side에서의 Action, OIG관리자의 Audit 까지 App 접근 및 권한을 할당받는 하나의 전체 cycle을 기술하였습니다.
(1) Slack 내 Okta App을 통해 권한 신청할 App을 선택
(2) 해당 App의 필요한 권한부여를 위해 Question에 대한 정보 입력
(3) Slack에서 승인절차 진행(신청자Side /승인자Side /승인완료)
(4) OIG 관리자 페이지에서 신청/승인 프로세스 전체에 대한 이력확인
마치며
지금까지 어플리케이션 권한신청 프로세스의 개선을 위해 Okta Identity Governance를 도입하여 적용한 사례를 소개드렸습니다.
OIG 를 도입하고 사용해보며 느낀 종합적인 생각은 ‘기존에도 고도의 Workflow 작업으로 비슷하게 구현은 가능하였으나, 권한의 신청-승인 프로세스 생성과 관리함에 있어서 훨씬 간결하고 관리자 친화적이며, 사용자 편의성과 보안관리의 효율을 극대화 할 수 있다.’ 였습니다.
스푼에서는 이러한 OIG의 장점을 이용하여, 이후로도 필요한 모든 Application에 대한 승인프로세스를 OIG로 생성하는 것을 목표로 지속 적용해 나갈 예정입니다. 다음에는 OIG 에 대해 보다 더 깊은설명과 Okta의 또다른 서비스에 대해 사례를 소개드릴 수 있는 글로 찾아뵙겠습니다.
긴 글 읽어주셔서 감사합니다!
