ISMS-P란 무엇인가
- ISMS-P는 기업·기관이 정보보호와 개인정보보호를 위해 갖춰야 할 관리적·기술적·물리적 보호조치를 체계적으로 수립·운영하고 있는지를 한국인터넷진흥원(KISA) 또는 인증기관이 심사하여 인증하는 제도다.
법적 근거와 운영 체계
- 법적 근거: 정보통신망 이용촉진 및 정보보호 등에 관한 법률(정보통신망법), 개인정보 보호법
- 정책기관: 과학기술정보통신부, 개인정보보호위원회
- 인증기관/심사기관: 한국인터넷진흥원(KISA) 및 지정된 심사기관
- 일정 규모 이상의 정보통신서비스 제공자 등은 정보통신망법에 따라 ISMS 또는 ISMS-P 인증을 의무적으로 취득해야 한다.
ISMS와 ISMS-P의 차이
구분 | ISMS | ISMS-P |
정식 명칭 | 정보보호 관리체계 인증 | 정보보호 및 개인정보보호 관리체계 인증 |
인증기준 영역 | 1. 관리체계 수립 및 운영
2. 보호대책 요구사항 | 1. 관리체계 수립 및 운영
2. 보호대책 요구사항
3. 개인정보 처리단계별 요구사항 |
인증기준 개수 | 80개 | 102개 |
초점 | 정보보호 전반 | 정보보호 + 개인정보 생명주기(수집~파기) 전반 |
즉 ISMS-P는 ISMS에 개인정보 처리단계별 요구사항(수집 → 보유·이용 → 제공 → 파기, 정보주체 권리보호)이 추가된, 더 넓은 범위의 인증기준이다.
인증기준 구조 (3영역 / 102개 기준)
1. 관리체계 수립 및 운영 (16개 기준) ㄴ 관리체계 기반 마련 / 위험 관리 / 관리체계 운영 / 관리체계 점검 및 개선 2. 보호대책 요구사항 (64개 기준) ㄴ 접근통제, 암호화 적용, 시스템 및 서비스 보안관리, 사고 예방 및 대응, 재해복구 등 12개 분야 3. 개인정보 처리단계별 요구사항 (22개 기준) ㄴ 수집 시 보호조치 / 보유·이용 시 보호조치 / 제공 시 보호조치 / 파기 시 보호조치 / 정보주체 권리보호
우리가 이번에 다룬 접근권한 관리(2.6), 암호화 적용(2.7), 사고 예방 및 대응(2.11) 같은 항목들은 모두 '2. 보호대책 요구사항' 영역에 속하고, 개인정보의 파기(3.4) 같은 항목은 '3. 개인정보 처리단계별 요구사항' 영역에 속한다.
왜 하필 ISMS-P였을까
다른 프레임워크(예: AWS Well-Architected Security Pillar, CIS Benchmark, ISO 27001)도 있었지만, 우리는 다음과 같은 이유로 ISMS-P를 메인 기준으로 선택했다.
1. 우리 시나리오는 '국내법상 개인정보 유출 사고'였다
시나리오 01은 AWS 인프라(EC2, IAM, S3)에서 발생한 데이터 유출이다. 만약 유출된 데이터가 개인정보였다면, 우리 회사는 개인정보 보호법 제29조(안전조치의무), 제34조(유출 통지·신고) 를 지켰는지 평가받는다. ISMS-P는 이 국내 법령들과 조항 단위로 직접 연결되어 있어서, "이 공격 단계가 어떤 법적 의무 위반으로 이어지는가"를 가장 명확하게 추적할 수 있는 기준이었다.
2. 기술적 취약점과 통제항목이 1:1로 매핑된다
시나리오의 공격 단계와 ISMS-P 통제항목은 거의 그대로 대응된다.
시나리오 공격 단계 (MITRE ATT&CK) | 연결되는 ISMS-P 통제 영역 |
Credential Access (하드코딩된 키 탈취) | 2.5 인증 및 권한관리, 2.6 접근통제 |
Discovery (계정/EC2 정보 탐색) | 2.6 접근통제, 2.9 로그 및 접속기록 관리 |
Credential Access (IMDS를 통한 IAM Role 탈취) | 2.6 접근통제, 2.10 시스템 및 서비스 보안관리 |
Exfiltration (S3 데이터 유출) | 2.6 접근통제, 2.7 암호화 적용, 3.4 개인정보의 파기 |
사고 전체 흐름 | 2.11 사고 예방 및 대응 |
즉 "공격이 이 단계까지 성공했다"는 사실이 곧 "이 통제항목이 미흡했다"는 근거로 자연스럽게 이어진다. 다른 프레임워크(예: CIS Benchmark)는 설정값 위주의 체크리스트라 기술 점검에는 강하지만, 법적 책임·신고 의무 같은 절차적 요구사항까지는 다루지 않는다는 한계가 있었다.
3. 국가 공인 인증제도이기 때문에 '증적'의 의미가 있다
ISMS-P는 KISA가 관장하는 법정 인증제도이기 때문에, 우리가 정리하는 점검결과·근거·검증방법 문서가 실제 인증심사에서 요구되는 문서 양식과 유사한 구조를 갖는다. 단순히 "우리끼리 정한 체크리스트"가 아니라, 실무에서 실제로 쓰이는 언어와 근거(조항 번호, 법령)로 결과를 정리할 수 있다는 점이 프로젝트의 실무 적합성을 높여준다고 판단했다.
4. 팀 전체가 배우고 있는 내용과 맞닿아 있다
우리 학과·과정에서 개인정보보호법, 정보보호 관리체계 관련 내용을 이미 학습하고 있었고, ISMS-P는 이 지식을 실제 AWS 인프라 점검에 적용해볼 수 있는 가장 접근성 좋은 다리 역할을 했다.
통제항목은 어떻게 선정했나
영역 배분
프로젝트 전체를 6개 영역으로 나누고 담당자를 배분했다.
- IAM / Logging / Detection — 혜민
- S3/Data / Incident Response — 병은
이렇게 나눈 기준은 시나리오의 공격 흐름을 "침입 경로(IAM·Logging·Detection)" 와 "침입 이후 피해·대응(S3/Data·Incident Response)" 두 축으로 구분한 것이다.
항목별 5~6개 선정 기준
각 영역마다 ISMS-P 인증기준 전체(102개)를 다 다루는 대신, 시나리오와 직접 연결되는 항목만 5~6개씩 선별했다. 예를 들어 S3/Data 영역은 다음 기준으로 골랐다.
- 시나리오에서 실제로 공격 대상이 된 리소스(S3 버킷)와 직접 관련이 있는가
- ISMS-P 인증기준 + 관련 법령(개인정보 보호법, 안전성 확보조치 기준)이 명확히 연결되는가
- AWS 콘솔에서 실제로 검증 가능한 항목인가 (문서로만 확인 가능한 항목은 최소화)
이 기준에 따라 최종적으로 S3 퍼블릭 액세스 차단, 저장/전송 데이터 암호화, 최소권한 원칙, 백업·버전관리, 보유기간 경과 데이터 파기 6개 항목을 선정했고, Incident Response 영역은 사고 대응체계 수립, 취약점 점검, 이상행위 탐지, 모의훈련, 사고 대응·복구, 유출 통지·신고 6개 항목을 선정했다.
각 항목마다 다음 5가지를 함께 정리했다.
- 요구사항 — 무엇을 해야 하는가
- 근거 — ISMS-P 조항 번호 + 관련 법령
- AWS 구현방법 — 어떤 서비스·설정이 이 요구사항에 해당하는가
- 검증방법 — 어떻게 확인하는가 (콘솔 경로, 명령어 등)
- 중요도 — 상(필수·법적요건) / 중(권고) / 하(개선)
다음 글 예고
다음 글에서는 이렇게 선정한 통제항목들을 실제로 AWS 콘솔에서 하나씩 점검한 과정과 결과를 정리한다. 스포일러를 하자면 — S3/Data, 사고대응 파트에서는 계정 권한 미비와 사고 대응 체계 자체의 미구축이라는 두 가지 원인으로, 대부분의 항목이 '미준수' 또는 '확인 불가'로 나왔다. 이 갭을 어떻게 메워나갈지에 대한 계획도 함께 다룰 예정이다.
