[ISMS-P] 멀티 클라우드 환경 중견기업의 인증 및 권한 관리 (2.5.1 ~ 2.5.6)
멀티 클라우드 환경에서 가장 강력하고도 위험한 보안 경계는 더 이상 물리적인 네트워크 방화벽이 아닙니다. 바로 아이덴티티(Identity)입니다. AWS, Azure, GCP 등 다양한 CSP(클라우드 서비스 제공자)를 혼용하는 환경에서는 계정과 권한의 복잡도가 기하급수적으로 증가하며, 단 하나의 계정 유출만으로도 클라우드 인프라 전체가 장악될 수 있는 위험을 안고 있습니다.
이번 글에서는 ISMS-P 인증기준 2.5 (인증 및 권한 관리)의 6개 세부 항목을 멀티 클라우드 환경의 중견기업 관점에서 알아보고, 인증심사원 시험에 대비할 수 있는 실전 시나리오와 핵심 퀴즈를 정리해보겠습니다.
1. 2.5.1 사용자 계정 관리
📌 인증기준 개요
정보시스템과 개인정보처리기시스템에 대한 사용자 계정의 등록, 변경, 해지 시 공식적인 절차를 수립·이행하고, 불필요한 계정(휴면 계정, 퇴사자 계정 등)은 적시에 삭제하거나 잠금 조치해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 인사 시스템과 클라우드 IAM 연동: 퇴사자나 직무 변경자 발생 시, 사내 HR 시스템과 멀티 클라우드 계정 관리(IdP - OKTA, Entra ID 등)를 연동하여 자격 증명이 자동으로 비활성화되도록 연계해야 합니다.
- 휴면 계정 자동 잠금: 90일 이상 클라우드 콘솔에 로그인하지 않은 콘솔 계정 및 사용되지 않은 API 액세스 키(Access Key)를 자동으로 식별하여 비활성화하는 정책을 구현해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 A기업의 멀티 클라우드 계정 관리 프로세스를 확인 중이다.
- 심사원: “지난달 퇴사한 인프라팀 홍길동 대리의 퇴사 처리 현황을 확인하고 싶습니다. 사내 메일이나 그룹웨어 계정은 잘 정리되었나요?”
- 담당자: “인사팀에서 통보받은 즉시 그룹웨어와 사내 AD 계정을 영구 정지했습니다.”
- 심사원: “그렇다면 홍길동 대리가 AWS와 GCP 콘솔 관리용으로 사용하던 IAM 계정들도 모두 정리되었는지 확인해주시겠어요?”
- 담당자: (AWS 콘솔 확인 후) “아… 사내 AD 계정은 지웠는데, AWS IAM 개별 계정 및 GCP에 등록된 게스트 계정은 깜빡하고 비활성화 조치를 취하지 않았습니다.”
Q. 위 상황에서 지적될 수 있는 ISMS-P 결함 항목으로 가장 적절한 것은?
- 2.5.2 사용자 식별 - 퇴사자의 이전 ID를 다른 직원에게 재할당함
- 2.5.1 사용자 계정 관리 - 퇴사자 발생 시 클라우드 서비스(AWS, GCP)의 계정을 적시에 삭제하거나 회수(비활성화)하지 않음 (정답)
- 2.5.6 접근권한 검토 - 퇴사자 명단에 대한 정기 결재를 득하지 않음
- 2.2.3 인적 보안 이행 - 퇴사 시 보안서약서를 징구하지 않음
해설: 인사 변동에 따른 계정 해지 시, 사내 시스템뿐만 아니라 외부에 구성된 클라우드(PaaS, SaaS, IaaS 등) 인프라의 모든 IAM 계정과 크레덴셜도 예외 없이 즉시 잠금 또는 삭제되어야 합니다. 그렇지 않은 것은 2.5.1 사용자 계정 관리의 명확한 결함입니다.
2. 2.5.2 사용자 식별
📌 인증기준 개요
사용자는 사용자 계정(ID)을 통해 고유하게 식별되어야 하며, 동일한 사용자 계정을 여러 사람이 공유하여 사용하지 않도록 통제해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 공용 관리자 계정 제한: AWS의
AdministratorAccess권한을 부여한 공용 IAM User를 생성하여 팀원 전체가 패스워드를 공유해 로그인하는 구조는 심각한 결함입니다. 모든 사용자는 고유한 개인 ID(예:gildong.hong@company.com)로 식별되어야 합니다. - SSO(Single Sign-On) 기반의 식별: 역할 기반 접근 제어(RBAC)를 통해 클라우드에 로그인하더라도 로그인 시점의 실제 사용자가 누구인지 감사 로그(CloudTrail, Activity Log 등)에서 개별 이메일 주소나 사번으로 추적할 수 있어야 합니다.
📝 실전 시험 대비 (기출 복원 시나리오)
[상황] 심사원이 B기업의 클라우드 장애 조치 로그를 검토 중이다.
- 심사원: “지난주 토요일에 GCP 상의 방화벽 룰이 변경되면서 서비스가 잠시 중단되었던 기록이 있네요. 이 작업을 수행한 담당자가 누구인지 식별할 수 있나요?”
- 담당자: “저희 GCP 운영 로그를 보면
gcp-ops-admin계정이 방화벽 규칙을 수정한 것으로 나옵니다.” - 심사원: “그렇다면
gcp-ops-admin계정은 구체적으로 누구의 계정인가요?” - 담당자: “아, 그 계정은 저희 DevOps팀원 4명이 장애 대응을 위해 패스워드를 공유하여 공용으로 사용하는 마스터 계정입니다. 토요일에 누가 접속해서 수정했는지는 로그만으로는 정확히 알 수 없습니다.”
Q. 위 상황에서 발생하는 핵심 컴플라이언스 결함 사유는?
- 장애 조치 시 사전 기안 문서를 작성하지 않음
- 2.5.2 사용자 식별 - 중요 자원에 접근하는 계정을 다수의 운영자가 공유하여 사용함으로써 개별 식별 및 사후 추적이 불가능함 (정답)
- 2.6.4 데이터베이스 접근 - GCP 로그의 백업본이 안전하게 암호화되지 않음
- 2.9.2 성능 및 장애관리 - 장애 등급 분류가 미흡함
해설: 동일한 계정을 여러 사용자가 공유하는 것은 책임 추적성을 완전히 상실시키므로 2.5.2 사용자 식별 위반입니다. 장애 대응이나 비상 시라 하더라도 개별 식별되는 계정을 활용하거나, 대행 로그인 시 실제 사용자를 파악할 수 있는 별도의 보완책이 마련되어야 합니다.
3. 2.5.3 사용자 인증
📌 인증기준 개요
정보시스템 및 개인정보처리시스템에 접근하는 사용자의 정당성을 확인하기 위해 강력한 인증 수단을 적용해야 하며, 특히 외부망을 통한 접근 시에는 다중요소 인증(MFA, Multi-Factor Authentication)을 필수적으로 적용해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 인터넷 노출 콘솔에 대한 MFA 필수화: 클라우드 콘솔은 전 세계 어디서나 인터넷을 통해 접근 가능하므로, 모든 IAM 사용자 계정에 OTP, 하드웨어 토큰, FIDO 등의 MFA를 기본적으로 강제 적용해야 합니다.
- 클라우드 API 접근에 대한 인증: 개발자 및 운영자의 로컬 터미널에서 AWS CLI, Terraform 등을 사용할 때 쓰이는 액세스 키(Access Key) 관리 시에도 정기적인 키 교체 및 만료 정책을 적용해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 C기업의 클라우드 접근 통제 구성을 확인 중이다.
- 심사원: “운영자분들이 재택근무를 하거나 사외에서 클라우드(AWS, Azure) 콘솔에 로그인할 때 다중요소 인증(MFA)을 필수로 요구하고 있나요?”
- 담당자: “네, 저희는 VPN을 먼저 연결하도록 하고 있으며, VPN 접속 시에 사내 OTP 인증을 통과해야 합니다. 따라서 클라우드 콘솔 자체에는 패스워드만 입력하고 들어갑니다.”
- 심사원: “그렇다면 사외가 아닌 사내망에서 클라우드 콘솔에 다이렉트로 접속할 때는 MFA를 요구하나요?”
- 담당자: “사내망은 안전한 내부 신뢰 네트워크이므로 ID와 패스워드만으로 로그인합니다.”
Q. 위 상황에서 심사원이 도출할 수 있는 결함으로 가장 적절한 것은?
- VPN 접속 시 MFA를 적용한 것은 잘못된 구성임
- 2.6.6 원격접근 통제 - 사외 접근 시 클라우드 웹 콘솔의 포트를 차단하지 않음
- 2.5.3 사용자 인증 - 외부망(인터넷)을 통해 직접 노출되는 클라우드 관리 콘솔 및 개인정보처리시스템 로그인 시 콘솔 계정 자체에 대한 MFA(다중요소 인증)를 강제하지 않음 (정답)
- 2.5.4 비밀번호 관리 - 비밀번호 복잡성 설정이 결여됨
해설: 클라우드 관리 콘솔은 사내망에서 접근하든 사외망에서 접근하든 원천적으로 인터넷 상에 공개되어 있는 시스템입니다. 따라서 접속하는 소스 IP의 위치와 관계없이 클라우드 콘솔 로그인 자체에 MFA를 강제 적용하지 않으면 2.5.3 사용자 인증의 결함으로 지적될 수 있습니다.
4. 2.5.4 비밀번호 관리
📌 인증기준 개요
사용자 비밀번호는 안전한 생성 규칙(복잡성, 길이 등)을 수립하여 적용하고, 정기적으로 변경하도록 통제하며, 시스템 내에 저장 시 일방향 암호화(해시)하여 보관해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 클라우드 계정 패스워드 정책(Password Policy) 설정: AWS IAM Account Password Policy, Azure Active Directory(Entra ID) 암호 정책 등에서 최소 10자 이상, 영문 대소문자/숫자/특수문자 조합, 최근 사용한 암호 재사용 금지(5회 이상), 90일 주기 변경 등을 활성화해야 합니다.
- SSO 연동 시 AD 패스워드 통제: 개별 CSP 계정을 쓰지 않고 AD 연동 SSO를 사용한다면, AD 서버의 GPO(그룹 정책) 상 비밀번호 설정이 컴플라이언스 요건을 충족하는지 검토해야 합니다.
📝 실전 시험 대비 (기출 복원 유형)
Q. 다음 중 2.5.4 비밀번호 관리 결함에 해당하지 않는 상황은 무엇인가?
- 클라우드 DB 인스턴스의 마스터 계정(sa, root 등)의 패스워드가 대소문자 구분 없이 영문자 및 숫자로만 구성되어 있고 8자리로 설정되어 있다.
- 사용자가 패스워드를 1년 동안 한 번도 변경하지 않았으나, 클라우드 콘솔 로그인 및 비밀번호 만료 정책이 활성화되어 있지 않아 계속 사용 가능하다.
- 개발자 노트북의 운영체제(OS) 로그인 패스워드가 6자리 단순 숫자로 구성되어 있으나, 해당 노트북은 항상 화면이 잠겨 있다. (정답)
- 시스템 내 사용자 비밀번호 데이터베이스를 확인해 보니, 비밀번호가 복호화 가능한 양방향 암호화 알고리즘(AES-256)으로 저장되어 있다.
해설:
- 1, 2번은 비밀번호 복잡성 정책 미비 및 정기 변경 미시행으로 결함입니다.
- 4번은 비밀번호를 해시 함수(SHA-256 등)로 일방향 암호화하지 않고 양방향 암호화하여 저장하였으므로 명백한 결함입니다.
- 3번의 경우 단말기 자체의 OS 로그인 암호 역시 안전하게 통제되어야 하지만, ISMS-P 2.5.4의 비밀번호 관리 통제 범위는 주로 정보시스템 및 개인정보처리시스템 자체의 사용자 비밀번호를 지칭합니다. (노트북 단말 보안은 2.10.6 업무용 단말기기 보안 등에 가깝습니다.)
5. 2.5.5 특수 계정 및 권한관리
📌 인증기준 개요
관리자, 루트(Root), 시스템 계정 등 특수 권한을 가진 계정의 목록을 정의하여 최소한의 인원에게만 할당하고, 부여된 권한의 오남용을 방지하기 위한 통제 조치를 수립해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 클라우드 루트(Root) 계정 보호: AWS Root User, Azure Subscription Owner 등 최상위 계정은 일상적인 개발 및 운영 업무에 절대 사용해서는 안 됩니다. 루트 계정은 금고 또는 보안 캐비닛에 ID/PW를 밀봉 보관하고, 승인된 비상시에만 사용해야 합니다.
- 최소 권한의 원칙(Least Privilege) 구현: 개발자에게 과도한 마스터 권한(
*:*또는AdministratorAccess)을 상시 부여하는 것을 지양하고, 필요한 리소스만 제어할 수 있는 세분화된 IAM 정책(Policy)을 작성하여 적용해야 합니다. - 임시 권한 부여(Just-In-Time) 체계: 필요 시 임시로 관리자 권한을 획득하고 작업 완료 후 자동으로 권한이 회수되는 AWS IAM Identity Center나 Azure PIM(Privileged Identity Management) 등의 솔루션 도입을 검토해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 B기업의 AWS 클라우드 권한 목록을 확인하고 있다.
- 심사원: “클라우드 서비스 배포 및 운영을 담당하는 외주 협력업체 개발자들의 권한은 어떻게 통제되나요?”
- 담당자: “저희가 신속한 배포 지원을 위해 협력업체 개발자 3명에게 AWS 콘솔 접근용 IAM 계정을 발급해주었습니다.”
- 심사원: “부여된 권한을 보니 ‘AdministratorAccess’ 정책이 상시 연결되어 있네요. 이들에게 최상위 관리자 권한을 부여한 사유가 무엇인가요?”
- 담당자: “협력사 개발팀에서 수시로 S3 버킷을 새로 만들고 EC2 인스턴스를 추가/삭제해야 하는데, 그때마다 권한 요청을 승인해주기엔 리소스가 부족하여 편의상 관리자 권한을 상시 열어주었습니다.”
Q. 위 상황에서 발생한 가장 심각한 결함 요인은?
- 외주 개발자가 AWS 콘솔을 웹 브라우저로 접속한 행위
- 2.5.5 특수 계정 및 권한관리 - 외부 협력업체 직원에게 정당한 직무 범위를 초과하여 최상위 권한(AdministratorAccess)을 제한 없이 상시 부여함 (정답)
- 2.5.1 사용자 계정 관리 - 외주 개발자의 계약서가 보안 부서에 보관되지 않음
- 2.6.1 네트워크 접근 - 협력사 개발자의 소스 IP가 보안 정책에 등록되지 않음
해설: 특수 권한이나 관리자 권한은 업무상 반드시 필요한 최소한의 범위 내에서만 인가된 인원에게 한시적으로 부여해야 합니다. 편의를 이유로 무제한의 관리자 권한을 외주 인력에게 상시 부여하는 것은 2.5.5의 전형적인 주요 결함 사례입니다.
6. 2.5.6 접근권한 검토
📌 인증기준 개요
정보시스템 및 개인정보처리시스템에 등록된 사용자 권한이 적절하게 부여되어 운영되고 있는지 정기적으로(반기 1회 이상 권장) 검토하고, 권한 오남용이나 불필요한 권한은 즉시 회수·조정해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- IAM 정책 정기 감사: 클라우드 계정에 부여된 IAM Role 및 Policy가 최신 업무 요건과 부합하는지 주기적으로 대조해야 합니다.
- 과다 권한(Over-privileged) 축소: AWS IAM Access Analyzer 등을 활용하여 최근 90일간 전혀 사용되지 않은 API 액션 권한을 탐지하고, 이를 계정의 권한에서 자동으로 소거하는 정리 작업을 정기 점검 이력(증적)으로 남겨야 합니다.
📝 실전 시험 대비 (기출 복원 시나리오)
[상황] 심사원이 F기업의 보안 정기 점검 현황을 검토하고 있다.
- 심사원: “사내 정보시스템과 데이터베이스, 그리고 AWS/GCP의 접근 권한이 적절한 상태인지 정기적으로 검토하고 계신가요?”
- 담당자: “네, 매년 연말에 전사 보안 내부 감사를 통해 전 직원의 시스템 권한 현황을 모니터링하고 미비점을 보완하고 있습니다.”
- 심사원: “그렇다면 관련해서 정기 권한 검토를 수행하고 보고한 결재 문서나 회의록 등의 이력을 보여주실 수 있나요?”
- 담당자: “따로 공식 보고서나 이력 문서를 작성해두진 않았고, 저희 보안팀 내에서 엑셀 파일을 보며 불필요한 사람들을 구두로 체크하여 삭제 조치했습니다.”
Q. 위 상황에 대해 심사원이 내릴 결함 조치로 가장 올바른 것은?
- 2.1.2 조직의 유지관리 - 보안팀 내부의 감사 권한이 인사 규정에 반영되지 않음
- 2.5.6 접근권한 검토 - 접근권한 검토의 주기(연 1회)가 미흡하거나, 검토를 수행한 공식적인 승인 및 수행 이력(보고서, 결재선 등)이 확인되지 않음 (정답)
- 2.3.3 외부자 보안 이행 관리 - 외주 직원의 권한 회수 절차가 계약서에 없음
- 2.5.1 사용자 계정 관리 - 엑셀에 퇴사자 이름이 존재함
해설: 권한 검토는 사후 추적과 이행 보증을 위해 공식적인 결재(CISO 승인 등)를 동반한 기록을 남겨야 합니다. 구두나 비공식적인 정리 방식은 인정되지 않으며, 개인정보처리시스템의 경우 최소 반기 1회 이상 검토 주기를 수립하여 실행하지 않으면 2.5.6의 결함 사항이 됩니다.
💡 요약 및 결론
멀티 클라우드 환경의 핵심 키워드는 ‘중앙화된 통제(Centralized Governance)’와 ‘최소 권한(Least Privilege)’입니다. 2.5 인증 및 권한 관리의 각 항목을 요약해 보겠습니다.
| 항목 | 핵심 키워드 | 클라우드 환경 핵심 체크리스트 |
|---|---|---|
| 2.5.1 사용자 계정 관리 | 등록/해지 프로세스 | 퇴사/인사이동 시 IAM 계정 즉시 회수, 휴면 API 키 비활성화 |
| 2.5.2 사용자 식별 | 1인 1계정, 추적성 | 공용 IAM User 사용 금지, SSO/역할 전환 로그 개별 식별 확보 |
| 2.5.3 사용자 인증 | MFA, 추가인증 | 콘솔 로그인 시 소스 IP 관계없이 전원 MFA 적용 필수 |
| 2.5.4 비밀번호 관리 | 복잡성, 단방향 해시 | IAM 암호 정책 활성화, 클라우드 DB 마스터 PW 규칙 준수 |
| 2.5.5 특수 계정 관리 | Root 차단, 최소 권한 | Root 계정 밀봉 보관, 과도한 관리자 권한(*) 제한 |
| 2.5.6 접근권한 검토 | 정기 권한 회수, 이력 관리 | 반기 1회 이상 IAM 및 DB 접근권한 공식 검토 보고서 확보 |
인증 및 권한 관리가 무너지면 그 어떤 훌륭한 네트워크 방화벽이나 침입 탐지 솔루션도 무력화됩니다. 클라우드의 경계선이 된 IAM 영역을 체계적이고 철저하게 관리하는 것이 ISMS-P 합격 및 안전한 서비스 운영의 기초석입니다.