Okta 도입 전 Identity 검토 사항
Okta를 도입 이전에 귀사의 Identity가 어떻게 관리되고 있는지 검토하는 체크리스트입니다.
고객사 환경에서 다양한 Identity의 고려 사항을 체크하실 수 있도록 도움을 드리기 위한 가이드입니다.
아래의 각 항목별 체크리스트를 참고하시어 필요한 검증 사항을 정리하실 수 있습니다.
아래의 체크리스트는 Identity를 전반적으로 체크하는 선택형 항목으로 고객사 환경과 요건에 따라 대상 항목이 다를 수 있습니다.
1. 사용자
귀사의 사용자(임직원/계약직/파트너 등)는 현재 어디에서 어떻게 관리되고 운영하고 있나요?
사용자의 정보가 여러 시스템에 분산 되어 있나? (예: HR, AD, LDAP, DB, 스프레드시트, 수기 관리 등 비정형 관리 여부)
시스템 간 사용자 정보가 중복으로 관리되고 있는가?
사용자의 정보를 동기화하는 시스템은 무엇이며 어떤 흐름으로 업데이트 되는가? (예: HR → AD → Okta → SaaS)
효율적인 관리와 운영을 위한 사용자 통합 구성이 중요 고려 사항인가?
Identity를 통합할 사용자 범위는 어느 정도로 정의하고 있나요?
전사 적용
기존 조직 시스템에 프로비저닝 오류 및 Sync 충돌이 발생할 사항은 없는가?
모든 사용자 Source에 대하여 Master를 기존 유지 or 변경할 경우, 어떻게 우선순위 지정할 것인가?
임직원 (계약/파트너 등 외부 직원 제외)
사용자 Source에 계약직/외부 협력사가 모두 포함되어 있는가?
제외 대상에 대해서는 별도 인증 및 보안 관리가 필요하지 않은가?
팀/프로젝트 인원 (특정 사용자)
특정 인원으로만 통합하는 근본적인 이유는 무엇인가?
특정 인원을 선별하고 제한하는 기준은 무엇인가?
귀사의 사용자 속성 정보는 어떻게 정의되고 관리하고 있으신가요?
우리 회사에서 사용하고 있는 사용자 Attribute(예: 사번, 조직, 직급, 이메일, 계정상태 등)의 목록은 표준화되어 있는가?
동일한 의미를 가진 필드가 시스템마다 이름/형식이 다르게 구성되어 있지 않은가? (예: empId vs employee_id vs staffNo)
동일 사용자가 여러 시스템에서 다른 정보로 관리되고 있지 않은가? (A시스템: email prefix, B시스템: 사번, C시스템: 공용계정)
"필수 Attribute"와 "선택 Attribute"에 대한 내부 기준이 존재하는가?
귀사의 사용자 LifeCycle은 어떻게 관리하고 있나요?
신규 직원/협력사의 사용자 계정은 어떻게 온보딩 프로세스가 정의되어 있는가?
우리 회사에서 시스템에 사용자 계정을 생성하고 접속 및 사용이 가능한 시간(Lead Time)까지는 얼마나 소요되는가?
사용자의 조직/직무 변경 시 권한과 라이선스가 자동으로 업데이트 되고 지속적인 감사 평가를 수행하고 있는가?
휴직자와 퇴사자의 프로세스는 어떻게 정의 되어 있는가?
복직/재입사 시 계정 재활성화 기준은 정의되어 있는가?
2. Applications
귀사에서는 어떠한 Application을 사용하고 있으신가요?
우리 회사에서 현재 사용 중인 전체 Application 목록이 정의되어 있는가?
Application 목록이 정기적으로 업데이트 및 관리되고 있는가?
각 Application의 도입 목적, 기능, 사용 부서 등이 명확히 정리되어 있는가?
각 Application의 담당자 및 계약 정보는 체계적으로 관리되고 있나요?
각 Application의 라이선스 등급, 계약 수량, 만료일, 과금 구조가 문서화되어 있는가?
Application 별 접근 권한에 따른 라이선스 할당 절차가 지정되어 있는가?
Application 담당자가 퇴사/부서 이동/휴직 시, 이를 대체할 담당자 전환 프로세스가 정의되어 있는가?
Application은 어떤 인증 방식을 지원하고 있나요?
Application 별로 표준 인증 방식(SAML / OIDC)을 지원하는지 검토 하였는가?
표준 인증 방식을 지원하지 않는 Application에 대하여 현재 인증은 어떻게 구성되어 있는가?
인증 절차가 없는 Application에 대하여 IDP를 통한 인증 구성을 고려하는가?
Application의 계정은 어떻게 관리되고 있나요?
Application 계정 생성/삭제가 자동화(SCIM, API, HR 연동) 되어 있는가?
Application 내 권한(Role/Permission)이 어떻게 정의되어있고 부여하고 있는가?
미사용/미접속 계정에 대한 정기 점검 또는 자동 비활성화 정책이 있는가?
부서 이동/직책 변경 등의 사용자 정보를 반영하여 Application 권한도 함께 업데이트되는가?
3. 정책
현재 귀사에 적용된 Application 인증 방식은 무엇인가요?
애플리케이션 별로 요구하는 인증 방식((ID/PW, MFA, Social)이 정의 되어 있는가?
중요도/위험도에 따라 인증 강도(Level of Assurance) 가 차등 적용되고 있는가?
비즈니스 크리티컬 애플리케이션은 추가 인증(MFA Step-up) 정책이 존재하는가?
사용자에게 어떤 인증 수단을 허용/요구하고 있으신가요?
회사에서 공식적으로 허용하는 인증 수단 목록이 있는가? (예: Passkey, TOTP, Push, FIDO2, SMS, 이메일, 보안키 등)
초기 인증 수단은 어떤 프로세스에서 사용자가 등록하는가? (예: 온보딩, 계정 생성, 보안교육 등)
BYOD 디바이스를 통해 사용자가 인증을 시도하는 경우, 높은 보안의 인증 수단을 요구하고 있는가?
귀사에서는 Passwordless 인증 정책 전환을 고려하고 계신가요?
Passwordless 정책을 적용할 애플리케이션을 선정했는가?
Passwordless 적용을 위한 인증 수단(소유/생체)이 사용자 디바이스에서 모두 지원하는가?
현재 귀사에 비밀번호(Password) 정책은 어떻게 운영하고 계신가요?
회사 비밀번호 정책(복잡성·길이·만료·잠금·History 등)이 정의되어 있는가?
패스워드 노출 및 보안 위협에 대해 주기적인 패스워드 변경(예: 90일) 프로세스를 운영하고 있는가?
계정 잠금 정책(예: 5회 실패 후 30분 Lock)에 대하여 복구/해제에 대한 프로세스가 정의되어 있는가?
애플리케이션별 비밀번호 정책이 상이한 경우, 통합 계획이 있는가?
4. 관리자
Identity 담당할 관리자는 어떻게 지정할 것인가?
Identity를 총괄 운영할 최고 관리자는 누구에게 지정할 것인가?
보조 관리자는 최소 1명 이상 배정이 가능한가?
Identity 관리자의 R&R(Role & Responsibility)이 정의되어 있는가? (예: 사용자 운영 담당 / 정책(MFA, Lifecycle) 담당 / 애플리케이션 담당 등)
최고 관리자가 퇴사/휴직하는 경우, 최고 관리자 권한 변경의 보안 프로세스가 정의되어 있는가?
관리자가 퇴사/휴직하는 경우, 운영 문서/가이드의 인수인계 절차가 정의되어 있는가?
5. 로그
Last updated