2.5.2 사용자 식별

1. ISMS 원본

인증기준

정보시스템에 접근하는 모든 사용자에게 유일한 식별자(ID) 를 부여하고, 행위 추적이 가능하도록 한다.

개요·사례

• 적용 범위: ERP·HR·DB·OS·네트워크 장비·SaaS 등 사용자 ID가 부여되는 모든 정보시스템
• 대표 통제 활동:
  • 1인 1ID 원칙 (자연인 사용자)
  • 공용 ID 사용 제한, 불가피 시 추적 가능한 보완통제
  • 식별자 명명 규칙 (사번 기반, 일관성)
  • 시스템 default ID (root, Administrator, sa, sys, oracle 등) 별도 관리
  • 서비스 계정·시스템 간 통신 계정 별도 분류·관리
• 빈출 결함 패턴:
  • 동일 인물에게 복수 ID 발급, 추적 불가
  • 공용 ID로 다수가 접속, 로그상 actor 식별 불가
  • default ID 비밀번호 미변경 (admin/admin 등)
  • 서비스 계정으로 사람이 대화형 접속

2. ITGC 매핑

3. IT감사에서는 이렇게

3-A. 한국 비금융 ITGC 실무 표준 (실제 검증 범위)

사용자 식별 = 로그 추적성의 전제. ITGC 검증 = 1인 1ID + default·공용·서비스 계정 별도 통제 표준.

3-B. ISMS-P가 추가로 요구하지만 ITGC 실무 범위 밖

4. Q&A

Q1. 동일 사번에 일반 ID + 관리자 ID 분리는 1인 1ID 위반인가?

A. 위반 X. 오히려 권장 패턴.

• 왜: 일상 업무는 일반 ID로, 관리 작업은 관리자 ID로 분리하면 권한 최소화 + 사용 로그 명확. PCI-DSS·ISO 27002에서도 권장
• 어떻게: 사용자 마스터에서 동일 인물 복수 ID 발견 시 → 권한 분리 목적인지(일반 vs 관리자), 단순 중복 발급인지 구분
• 결함 판단:
  • 권한 분리 목적 + 명명 규칙 일관(예: yanghoeg / yanghoeg-adm) + 일반 ID에 관리자 권한 부여 X → OK
  • 단순 중복 발급 (회수 누락) → 결함

Q2. 서비스 계정·시스템 계정도 1인 1ID 적용?

A. 자연인 사용자만 1인 1ID. 서비스 계정은 별도 통제.

• 왜: 서비스 계정은 시스템 간 자동화·연계 목적. 사람이 쓰는 게 아니라 ID 단위 추적성 개념이 다름
• 어떻게: 서비스 계정 list 별도 관리 + 사용 시스템·인터페이스 명시 + 비대화형(non-interactive) 강제 + 비밀번호 별도 정책(주기 변경·길이)
• 어디까지:
  • 서비스 계정에 대화형 로그인(SSH/RDP) 차단 설정 검증
  • 사용 IP·시스템 화이트리스트 적용
  • 서비스 계정 비밀번호 vault 관리 (Hashicorp Vault·CyberArk 등)
• 결함 판단:
  • 서비스 계정으로 사람이 대화형 접속한 로그 발견 → 결함
  • 서비스 계정 list 관리 X → 결함
  • 서비스 계정 비밀번호가 source code에 hard-coded → 즉시 결함 (가장 심각)

Q3. Default 계정(root/Administrator/sa) 회수해도 되나?

A. 회수 X — 비활성화·Rename·강력 비밀번호·접근 차단.

• 왜: 시스템 부팅·복구·긴급 상황에 default 계정 필요. 회수 시 시스템 장애 위험. 표준 권고 = 사용 차단·로그 + 보존
• 어떻게:
  • 비밀번호 정기 변경 + 길이·복잡도 강화 + vault 보관
  • 일반 로그인 차단 (콘솔 only 또는 jump server 경유)
  • 사용 시 사유·승인·로그 기록
  • Windows Administrator → rename (예: Local-Admin-XYZ)
• 결함 판단:
  • default 비밀번호 그대로 (admin/admin, sa/공백 등) → 즉시 결함
  • 사용 로그 X → 결함
  • 평소 일반 로그인으로 사용 (별도 사유 없이) → 결함

Q4. SaaS·SSO 환경에서 1인 1ID 어떻게 보나?

A. IdP(Identity Provider) 기준으로 1인 1ID + SaaS 측 Provisioning 검증.

• 왜: SSO는 IdP가 master. 각 SaaS의 사용자는 IdP에서 provisioning. 1인 1ID는 IdP 단계에서 검증
• 어떻게:
  • IdP (Azure AD/Okta/Google Workspace) 사용자 마스터에서 동일 인물 복수 계정 식별
  • SaaS 측 사용자 = IdP에서 SCIM/JIT provisioning된 계정만 존재하는지 (수동 생성 계정 식별)
  • SaaS 측 local 계정(SSO 우회) 존재 여부 검증
• 결함 판단:
  • SaaS에 IdP 외 local 계정 존재 (SSO 우회) → 결함
  • IdP에 동일 인물 복수 계정 → 결함
  • 퇴직자 IdP에서 비활성화했는데 SaaS local 계정으로 접속 가능 → 결함

Q5. ID가 개인에게 소속됨을 어떻게 확신? ID·비번 남이 쓸 수도 있는데?

A. ID 자체는 본인 사용 보장 X. 추적성 ≠ 본인 사용 인증. 다층 통제로 보장.

• 왜: 사용자 식별(2.5.2)은 "ID로 행위 추적" 가능하게 하는 통제일 뿐. "ID 사용자 = 본인" 보장은 사용자 인증(2.5.3)·비밀번호 통제·MFA·인적 보안(2.2)·정책 준수가 함께 작동해야 가능. 2.5.2 단독으로는 본인 사용 보장 X
• 본인 사용 보장 통제 (다층):
  • 2.5.3 사용자 인증 — 비밀번호·MFA·생체 (본인만 아는/가진/인 것)
  • 2.5.4 비밀번호 관리 — 복잡도·주기·공유 금지
  • 2.2.3 보안 서약 — 비밀번호 공유 금지 명시 (위반 시 인사 조치 근거)
  • 2.2.4 인식제고 교육 — 비밀번호 공유의 보안 위험
  • 2.2.6 보안 위반 시 조치 — 위반 발견 시 인사 조치 절차
  • 화면 잠금 정책 (자리 비움 시) — 무인 ID 사용 차단
  • 동시 다중 로그인 차단 또는 모니터링 — 한 ID 동시 사용 탐지
• ITGC 검증 포인트:
  • 비밀번호 공유 금지 정책 + 보안 서약서 작성 (entity-level)
  • MFA 적용 여부 (특히 외부 접속·특수권한)
  • 비밀번호 정기 변경 + 복잡도 강제 (시스템 설정)
  • 화면 잠금 정책 (자동 잠금 시간) + GPO/AD 강제 적용
  • 동시 다중 로그인 차단 설정 또는 로그 모니터링
  • 위반 시 조치 절차 + 적용 사례 (인사 기록)
• 결함 판단:
  • 비밀번호 공유 정황 발견 (메신저·sticky note·인터뷰 진술) → 즉시 결함
  • MFA 미적용 (필수 영역인데) → 결함
  • 동시 다중 로그인 무제한 + 로그 모니터링 X → 결함
  • 화면 잠금 정책 X 또는 임의 해제 가능 → 결함
  • 보안 서약서 미작성 → entity-level 결함
• 현실 한계: 비밀번호 공유는 실무에서 가장 많이 발생하는데 ITGC로 100% 탐지 불가능. 정책 + 교육 + 기술통제 다층 + 의심 정황 시 추가 조사가 최선. 100% 보장 통제는 PKI 인증서 + 본인 생체 MFA 결합 정도. ITGC 결함보고 시 "비밀번호 공유 가능성"은 본질적 한계로 인정되며, 통제 layer 누락 자체가 결함

관련 인증기준

• 2.5.1 사용자 계정 관리 (계정 라이프사이클)
• 2.5.5 특수 계정 및 권한 관리 (default·서비스 계정과 연결)
• 2.9.4 로그 및 접속기록 관리 (식별자 → 로그 추적성)

관련 회계감사기준서 / 글로벌 표준

• 회계감사기준서 315 (IT 위험 이해)
• COBIT DSS05 (Manage Security Services)
• NIST SP 800-63 (Digital Identity Guidelines) — IdP·federated identity 기준