APD 1-direct

2.5.4 비밀번호 관리

1. ISMS 원본

인증기준

법적 요구사항, 외부 위협요인 등을 고려하여 정보시스템 사용자 및 고객, 회원 등 정보주체(이용자) 가 사용하는 비밀번호 관리절차를 수립·이행하여야 한다.

주요 확인사항 (KISA 안내서)

  1. 정보시스템에 대한 안전한 사용자 비밀번호 관리절차 및 작성규칙을 수립·이행하고 있는가?
  2. 정보주체(이용자)가 안전한 비밀번호를 이용할 수 있도록 비밀번호 작성규칙을 수립·이행하고 있는가?
  3. 개인정보취급자 또는 정보주체의 인증수단을 안전하게 적용하고 관리하고 있는가?

관련 법규

비밀번호 작성규칙 (KISA 안내서, 시스템적 강제화 권고)

구분 내용
조합 규칙 영문·숫자·특수문자 중 2종류 이상 조합 + 최소 8자리 / 문자만 구성 시 최소 10자리 (숫자만 구성 X)
변경주기 유효기간 설정 + 주기 변경. 단, 주기적 변경 여부·변경주기는 위험평가 결과로 자체 결정
추측 쉬운 비밀번호 제한 동일 문자 반복, 키보드 나란히 문자열, 일련번호·연속 숫자, 생일·전화번호 등 개인정보, ID와 비슷한 비밀번호 사용 제한
재사용 제한 변경 시 이전 비밀번호 재사용 제한

비밀번호 관리절차 (KISA 안내서 예시)

비밀번호 외 인증수단 (제5조제5항)

결함사례 (KISA 안내서)

2. ITGC 매핑

항목
분류 직접 (1-direct)
ITGC 영역 APD (Access to Programs and Data)
부영역
보조 영역 ELC/policy (비밀번호 정책 수립 — entity-level)

3. IT감사에서는 이렇게

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

비밀번호 정책은 2.5.3 영역(실패횟수·세션 타임아웃)과 한 화면에 같이 나오므로 보통 하나의 자동통제 캡처로 동시 검증한다.

ISMS 요구 ITGC 테스트 절차 모집단 샘플
1. 비밀번호 작성규칙 시스템 설정값 캡처 (길이·복잡도·금지 패턴) 전 시스템 자동통제 1건 샘플
2. 비밀번호 변경주기 시스템 설정값 캡처 (유효기간 일수, 회사 정책과 일치) 전 시스템 자동통제 1건 샘플
3. 재사용 제한 시스템 설정값 캡처 (최근 N개 비밀번호 재사용 차단) 전 시스템 자동통제 1건 샘플
4. 임시 비밀번호 강제 변경 신규 계정·재설정 계정에 첫 로그인 시 비밀번호 변경 강제 전 시스템 자동통제 1건 샘플
5. 정책 문서 회사 비밀번호 정책 문서 (entity-level) 정책 1건 정책 1건 walkthrough

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

ISMS 요구 절차 어디 영역
정보주체(이용자) 비밀번호 작성규칙 web 회원가입 화면의 비밀번호 정책 검증 ISMS-P 인증심사 (B2C 서비스 한정)
비밀번호 마스킹 처리 입력·변경 화면 캡처 ISMS-P 인증심사
종이·파일·모바일 기록 제한 보안 정책 + 인터뷰 + 책상 점검 보안 영역 (sticky note 점검은 보안 진단)
분실 재설정 시 본인확인 재설정 절차 walkthrough + 사례 1건 ISMS-P 인증심사
비밀번호 외 인증수단 보호 (인증서·생체) 인증수단별 보호대책 ISMS-P 인증심사

4. Q&A

Q1. 비밀번호 변경주기 90일·분기 무조건 강제인가? 비금융에도?

A. 비금융 회사에 분기·90일 변경 강제하는 한국 법령 없음. 강제는 금융권 전자금융감독규정시행세칙 제32조 한 곳뿐.

한국 법령·표준별 변경주기 강제 여부:

법령/표준 변경주기 강제
개인정보의 안전성 확보조치 기준 제5조 숫자 X. "주기적 변경" + "위험평가 결과로 자체 결정" (자율화)
KISA ISMS-P 인증기준 안내서 (2023.11) 자율화. 90일·분기 강제 X
개인정보보호법·시행령 변경주기 자체 강제 X
개인정보보호위원회 (2024.10) "6개월 주기 비밀번호 변경 의무" 삭제
정보통신망법·시행령 비밀번호 주기 강제 X
행정안전부 정보시스템 보안 가이드 공공기관 한정 권고 (강제 X)
전자금융감독규정시행세칙 제32조 분기별 1회 이상 강제 (금융회사·전자금융업자 한정)

즉 비금융 회사에 "분기 변경 안 됨 = 결함" 주장은 근거 없음. 자주 보이는 거품 사례 = ① 금융권 시행세칙을 비금융에 잘못 적용 ② 옛날 KISA 가이드(2019년 이전) 인용 — 이미 폐기됨

KISA 안내서 원문 (2023.11): "비밀번호 유효기간을 설정하여 주기적으로 변경(단, 주기적 변경 여부 및 변경주기는 위험평가 결과 등을 고려하여 자체적으로 결정)"

배경: NIST SP 800-63B (2017~) 권고 반영. 잦은 비밀번호 변경 강제가 오히려 약한 비밀번호·sticky note 기록 유발한다는 보안 연구 결과. 한국도 2019년 KISA 가이드 변경주기 삭제, 2024년 개인정보보호위원회 6개월 의무 삭제로 점진 완화.

ITGC 결함 판단 기준 (회사 정책 + 일관성):

회사 정책 시스템 설정 결함 판단
"분기 변경" 명시 분기 변경 적용 OK
"분기 변경" 명시 무제한 결함 (정책-실제 불일치)
"위험평가 결과 자율" 변경주기 X + 보완통제 (긴 비밀번호·MFA·로그 모니터링) OK
정책 자체 부재 변경주기 X + 보완통제 X 결함 (entity-level 정책 부재)

핵심: 분기·90일 자체가 강제 X (비금융). 회사 정책 vs 시스템 설정 일치성이 결함 판단의 본질. 양획 본업 시각 + KISA 자율화 추세 일관.

Q2. 정책상 8자리인데 시스템은 6자리 — 결함?

A. 결함. 통제 목적 달성 X (KISA 결함사례 1번 그대로). 단 미세 차이는 영향 평가.

Q3. 임시 비밀번호 강제 변경 — 어디까지 검증?

A. KISA 결함사례 2번 명시 영역. 신규·재설정 계정 1건 walkthrough로 검증.

Q4. sticky note·메신저 비밀번호 공유 — ITGC 결함?

A. ITGC 영역 X. 보안 진단·인사 영역. 다만 다른 통제와 묶여서 결함 가능.

Q5. 한국 비금융 ITGC 실무, 2.5.4 어디까지 봐야 함?

A. §3-A의 5개 (작성규칙·변경주기·재사용 제한·임시 비밀번호 강제 변경·정책 문서). 2.5.3과 한 캡처로 동시 검증.

관련 인증기준

관련 법규 / 표준

GitHub에서 보기 →