2026 ISMS-P 대개편 완전 정복 — 101개에서 120개로, 강화 인증 대상 기업이 지금 당장 준비할 것
정보보호 인증은 '취득'보다 '유지'가 어려운 제도입니다. 2026년 ISMS-P 개편은 이 원칙을 제도 차원에서 명확히 한 변화로, 인증 기준·심사 방식·사후관리 전반이 달라집니다. 이 글에서는 개편의 배경과 핵심 내용, 그리고 조직이 준비해야 할 사항을 차례로 정리합니다.
안녕하세요, ICT리더 리치입니다. ISMS-P(정보보호 및 개인정보보호 관리체계 인증)는 조직이 정보자산과 개인정보를 보호하기 위해 관리체계를 수립하고, 보호대책을 이행하며, 개인정보를 처리 단계별로 안전하게 다루고 있는지를 종합적으로 평가하는 국내 대표 인증제도입니다. 정보통신망법과 개인정보보호법을 근거로 과학기술정보통신부와 개인정보보호위원회가 공동 운영하고 있습니다.
일반적으로 관리체계 인증은 ISO/IEC 27001과 같은 국제표준과 마찬가지로 '계획–실행–점검–개선(PDCA)'의 순환 구조를 전제로 합니다. 즉 인증은 특정 시점의 합격 판정이 아니라, 보안 수준을 지속적으로 유지·개선하고 있다는 것을 보여주는 장치여야 합니다.
그러나 현실에서는 인증이 심사 기간의 서류와 샘플 점검에 크게 의존해 왔고, 인증 이후의 운영 수준과 실제 보안 수준 사이에 차이가 생길 수 있다는 지적이 꾸준히 제기되어 왔습니다. 최근 인증 보유 기업에서 보안 사고가 잇따르면서 이 문제는 제도 개선 논의로 이어졌고, 정부는 2026년 4월 인증제 실효성 강화방안을 발표했습니다.
이번 개편의 핵심은 위험 수준에 따른 인증 차등화, 기술 중심의 현장 검증 심사, 그리고 인증 취소를 포함한 사후관리 강화입니다. 이 글에서는 개편 배경과 주요 사례, 3단계 인증 체계와 강화 기준, 심사·사후관리 변화, 준비 로드맵, 그리고 자체 점검에 활용할 수 있는 실전 코드까지 순서대로 살펴보겠습니다.
📌 바로가기 목차
 |
| 자산 식별부터 계정 관리와 운영 증적까지, 우리 회사의 보안 준비 포인트를 살펴봅니다. |
1. 왜 지금 ISMS-P 대개편인가 — 숫자로 본 인증제의 민낯
먼저 기본부터 짚고 가겠습니다. ISMS-P는 2018년 ISMS(정보보호 관리체계)와 PIMS(개인정보보호 관리체계)를 통합한 제도로, 관리체계 수립·운영 16개, 보호대책 64개, 개인정보 처리단계별 요구사항 21개를 합쳐 총 101개 기준으로 심사합니다. ISMS는 정보통신망법에 따라 일정 규모 이상 기업에 의무이고, ISMS-P는 지금까지 개인정보보호법에 근거한 자율 인증이었습니다.
문제는 이 인증이 '심사 기간 일주일 남짓의 스냅샷'이라는 점이었습니다. 공격자는 365일 24시간 빈틈을 노리는데, 인증은 특정 시점의 서류와 샘플 점검으로 부여됐죠.
숫자를 보면 더 뚜렷합니다. 2025년 12월 국회 정무위원회에서는 ISMS-P 인증 기업 263곳 가운데 27곳에서 33건의 개인정보 유출 사고가 있었다는 지적이 나왔습니다. 정부 스스로도 2026년 4월 발표에서 최근 3년간 ISMS·ISMS-P 인증 기업 179곳에서 침해 사고가 발생했다고 밝혔습니다. 그런데도 법에 인증 취소 요건이 있음에도 실제로 취소된 사례는 한 건도 없었다는 비판이 이어졌습니다.
| 지표 | 수치 | 현장에서 읽는 의미 |
|---|---|---|
| ISMS-P 인증 기업 수 | 263곳 (2025.12 기준) | ISMS 단독 인증 약 500여 곳 대비 절반 수준 |
| 인증 기업 개인정보 유출 | 27곳 · 33건 | 인증 기업 10곳 중 1곳꼴로 사고 경험 |
| 최근 3년 인증 기업 침해 사고 | 179곳 | '인증 = 안전' 등식이 깨졌다는 정부 공식 인정 |
| 인증 취소 사례 | 사실상 0건 (개편 전) | 사후관리가 형식에 그쳤다는 방증 |
| 개편 후 강화 인증 기준 | 101개 + 20개 ≈ 120여 개 | 대형 통신·플랫폼·인프라 기업에 우선 적용 |
여러분 회사의 인증서는 지금 '방패'입니까, 아니면 '마케팅 배지'입니까? 이 질문에 자신 있게 답하기 어렵다면, 다음 섹션의 실제 사례들이 꽤 아프게 다가올 겁니다.
2. 인증 받고도 뚫렸다 — 실전 사고 사례 4건 해부
2025년에 개인정보 유출 사고를 겪은 SK텔레콤, KT, 롯데카드, 예스24, 넷마블, 쿠팡은 모두 ISMS-P 인증 보유 기업이었습니다. 저는 이 사고들을 볼 때 '누가 잘못했나'보다 '어떤 인증 기준이 서류로만 존재했나'를 먼저 봅니다. 그 관점으로 대표 사례 4건을 해부해 보겠습니다.
※ 아래 원인 분석 중 일부는 언론 보도·조사 과정에서 거론된 내용을 바탕으로 한 것이며, 최종 조사 결과에 따라 달라질 수 있습니다.
- 사례 ① 롯데카드 — 인증 획득 이틀 만의 해킹: 2025년 8월 12일 금융보안원에서 ISMS-P를 받았는데, 불과 이틀 뒤인 14일 첫 공격이 들어왔습니다. 더 뼈아픈 건 회사가 이를 인지해 신고하기까지 최초 공격 후 18일이 걸렸다는 점입니다. 오래된 미들웨어 취약점 미패치가 원인으로 지목되면서 패치관리(2.10.8)와 이상행위 모니터링(2.11.3)이 서류와 현실 사이에서 따로 놀았다는 비판을 받았습니다.
- 사례 ② KT — 무단 소액결제와 뒤늦은 서버 침해 신고: 불법 초소형 기지국을 이용한 무단 소액결제 피해가 터진 뒤, 사고를 수습하던 KT는 4개월간 진행한 보안 점검 결과를 확인하고 서버 침해 정황 6건을 KISA에 신고했습니다. 네트워크 접근통제(2.6.1)와 사고 대응(2.11.5)이 '인지 → 신고'까지 얼마나 빨리 돌아가는지가 인증의 실체라는 걸 보여준 사례입니다.
- 사례 ③ 쿠팡 — 인증 두 번, 반복된 유출: 쿠팡은 2021년과 2024년 두 차례 ISMS-P를 받았지만 2025년 11월 대규모 계정 정보 유출이 드러났고, 국회에서는 인증 이후 반복된 유출을 문제 삼았습니다. 조사 과정에서 퇴사자와 관련된 인증 정보가 제때 폐기되지 않았을 가능성이 거론되면서, 퇴직 관리(2.2.5)와 계정·인증정보 생명주기 관리가 핵심 쟁점으로 떠올랐습니다. 강화 인증 기준에 '액세스 토큰·API 키 관리'가 명시된 배경이 바로 여기에 있습니다.
- 사례 ④ SK텔레콤 — 가입자 인증 핵심 서버 침해: 2025년 봄, 가입자 인증에 쓰이는 핵심 서버가 악성코드에 감염되면서 유심 관련 정보가 유출됐고 전국적인 유심 교체 사태로 번졌습니다. 장기간 잠복한 악성코드를 탐지하지 못했다는 점에서 악성코드 통제(2.10.9)와 중요 시스템 무결성 검증의 공백이 드러났습니다. 이번 개편에서 '무결성 검증'이 강화 기준으로 따로 들어간 이유를 생각해 보게 되는 대목입니다.
| 사례 | 드러난 공백 | 관련 인증기준 | 개편 후 대응 장치 |
|---|---|---|---|
| 롯데카드 | 패치 공백 · 탐지 지연 | 2.10.8 / 2.11.3 | 패치 미적용 시 인증 취소 사유 |
| KT | 외부 접점 통제 · 신고 지연 | 2.6.1 / 2.11.5 | 네트워크 접근 강화 · 외부 자산 인증 범위 포함 |
| 쿠팡 | 인증정보 생명주기 관리 | 2.2.5 / 2.5.1 | 자동화된 계정 관리 · 토큰·API 키 관리 |
| SK텔레콤 | 장기 잠복 악성코드 미탐지 | 2.10.9 / 2.11.3 | 무결성 검증 · 모의침투 투입 |
⚠️ 주의: 네 사례의 공통점은 '정책서에는 다 있었다'는 것입니다. 패치 정책, 퇴직자 계정 회수 절차, 로그 모니터링 지침 모두 문서로는 존재했을 가능성이 큽니다. 개편된 심사는 바로 이 '문서와 실제 시스템의 차이'를 겨냥합니다.
3. 간편·표준·강화 3단계 인증 체계 비교
이번 개편의 뼈대는 '모두에게 같은 잣대'를 버렸다는 점입니다. 기존의 표준 인증과 영세·중소기업용 간편 인증에 더해 '강화 인증'이 새로 생기면서 3단계 차등 체계가 됩니다. 강화 인증은 ISMS-P 표준 101개 기준 위에 20개 기준을 얹는 방식입니다.
대상은 매출 1조 원 이상인 주요 인터넷 서비스 제공자(ISP)와 데이터센터(IDC) 사업자, 매출 3조 원 이상인 정보통신서비스 제공자입니다. 언론 보도에서는 이동통신 3사, 삼성SDS·LG CNS 같은 인프라 사업자, 네이버·카카오·쿠팡 같은 대형 플랫폼이 대상군으로 거론됐습니다.
| 구분 | 간편 인증 | 표준 인증 | 강화 인증 (신설) |
|---|---|---|---|
| 대상 | 영세·중소기업 | 일반 의무·자율 인증 기업 | 대형 ISP·IDC·정보통신서비스 제공자 |
| 기준 수 (ISMS-P) | 축소 적용 | 101개 | 101개 + 20개 |
| 심사 방식 | 서면·현장 병행 | 예비심사 후 본심사 | 예비심사 + 취약점 점검·모의침투 + 본심사 |
| 투입 인력 | 인증 심사원 | 인증 심사원 | 심사원 + 취약점 점검 전문인력 |
| 인증 범위 | 핵심 서비스 | 서비스 관련 자산 단계적 확대 | 외부 인터넷 접점 디지털 자산까지 포함 |
💡 실전 팁: 강화 인증 대상이 아니더라도 안심하긴 이릅니다. 대형 고객사·원청이 협력사에 동일 수준의 보안 요구사항을 계약서로 내려보내는 흐름이 이미 시작됐습니다. 강화 기준 20개는 '우리 회사 보안 수준의 다음 목표치'로 보시는 게 현실적입니다.
 |
| 현황 파악, 기술 점검, 결함 개선, 증적 정리 순서로 실무 점검을 진행하세요. |
4. 강화 인증 기준 20개 — 7대 핵심 영역 해설
정부가 공개한 강화 기준안은 7개 영역으로 묶입니다. 제가 읽으면서 느낀 건 하나입니다. "이건 체크리스트가 아니라 엔지니어링 과제다." 사람이 엑셀로 관리하던 것을 도구와 자동화로 증명하라는 요구가 곳곳에 깔려 있습니다.
아래 해설은 공개된 기준안의 방향을 실무 관점에서 풀어낸 것이며, 세부 문구와 판단 기준은 향후 고시·안내서 개정으로 확정될 예정입니다.
- ① 최고책임자 지정: CISO·CPO를 CEO 직속 임원으로 두고 실질적 통제권을 주는 방향입니다. '겸직 CISO', '결재권 없는 CPO'는 앞으로 설명하기 어려워집니다.
- ② 정보자산 식별 강화: 자동화 도구로 자산을 식별하라는 요구입니다. 엑셀 자산대장과 실제 클라우드·온프레미스 자산이 어긋나는 순간이 곧 결함입니다.
- ③ 무결성 검증: 중요 시스템 파일·설정·로그가 변조되지 않았음을 도구로 검증해야 합니다. 장기 잠복 악성코드 대응의 핵심 축입니다.
- ④ 자동화된 계정 관리: 입사·전보·퇴사에 따라 계정이 자동으로 생성·변경·회수되는 계정 생명주기 자동화입니다. HR 시스템과 IAM 연동이 사실상 필수가 됩니다.
- ⑤ 사용자 인증 강화: 중요 시스템 접근 시 강화된 인증 수단과 위험 기반 적응형 인증을 적용하는 방향입니다. 단순 ID/PW + SMS OTP 조합은 재검토 대상입니다.
- ⑥ 인증정보 관리: 액세스 토큰·API 키의 발급부터 폐기까지 전체 생명주기를 관리해야 합니다. 소스코드 하드코딩, 만료 없는 토큰, 퇴사자 키 잔존이 대표적인 결함 포인트입니다.
- ⑦ 네트워크 접근 강화: 외부 인터넷 접점을 최소화하고 중요망을 분리하는 방향입니다. 잊혀진 테스트 서버, 열려 있는 관리 포트가 가장 먼저 걸립니다.
눈치채셨나요? ④·⑤·⑥은 앞서 본 쿠팡 사례와, ③은 SK텔레콤 사례와, ⑦은 KT 사례와 정확히 맞물립니다. 강화 기준은 책상 위에서 만든 게 아니라 실제 사고의 교훈을 역산해서 만든 기준입니다. 뒤쪽 7번 섹션의 실전 코드도 이 영역들을 겨냥해 준비했습니다.
5. 심사 방식·사후관리·인증 취소, 이렇게 바뀐다
심사 현장의 풍경이 완전히 달라집니다. 가장 먼저 체감될 변화는 '예비심사 컷오프'입니다. 본심사 전에 CISO의 정책 관리 권한, 개인정보처리시스템의 비밀번호·암호화 적용 같은 핵심 항목을 먼저 보고, 미흡하면 본심사로 넘어가지 못하게 됩니다.
강화 인증 대상에는 심사원과 함께 취약점 점검 전문인력이 들어와 스캐너, 스크립트, 소스코드 진단 도구로 실제 모의침투를 수행합니다. "증적 보여주세요"에서 "직접 확인하겠습니다"로 바뀌는 겁니다.
사고를 낸 기업은 사후 심사 강도가 두 배로 올라갑니다. 정부가 든 예시를 보면, 기존 사후심사가 5명이 5일간 보는 구조였다면 사고 기업에는 10명이 10일간 투입돼 사고 원인과 조치 현황을 집중적으로 파고듭니다. 심사 준비 부담만 네 배 가까이 늘어나는 셈이죠.
| 인증 취소 사유 유형 | 구체적 행위 | 실무 대비 포인트 |
|---|---|---|
| 사후관리 거부·방해 | 사후관리 포기 제출, 사후심사 미신청, 예비인증 후 본인증 미실시 | 연간 심사 일정을 경영계획에 고정 반영 |
| 중대 결함 미보완 | 보안 패치 미적용, 로그 미보관 | 패치 SLA와 로그 보존을 자동 점검 (실전 코드 ① 참고) |
| 중대한 법 위반 | 정보통신망법·개인정보보호법상 매우 중대한 위반 | 법무·CPO 합동 컴플라이언스 정기 점검 |
⚠️ 주의 — 일정 체크: 정부 발표 기준으로 상시 점검 강화와 인증 취소 등 사후관리 관련 사항은 2026년 하반기부터, ISMS-P 의무화·인증 차등 적용·강화 기준 적용은 2027년 시행을 목표로 추진됩니다. 시행령·고시·안내서 개정 일정에 따라 세부 시점은 달라질 수 있으니 KISA 공지를 반드시 확인하세요.
심사하는 쪽도 달라집니다. 심사 품질이 떨어지는 심사기관은 업무 정지나 지정 취소까지 받을 수 있는 법적 근거가 마련되고, AI·클라우드 등 분야별 전문 심사원 관리와 심사원 처우 현실화도 함께 추진됩니다. 쉽게 말해 '대충 봐주는 심사'가 설 자리가 없어집니다.
6. 강화 인증 대상 기업 준비 로드맵
"그래서 뭐부터 하면 되나요?" 요즘 제게 가장 많이 들어오는 질문입니다. 제 답은 늘 같습니다. 심사원이 모의침투로 찾아낼 것을 우리가 먼저 찾아내면 됩니다. 남은 시간을 고려해 분기 단위 로드맵으로 정리했습니다.
- ☑ 1단계 (즉시) — 인증 취소 사유부터 제거: 패치 미적용 자산 목록, 로그 보존 누락 구간을 전수 점검합니다. 하반기부터 적용되는 취소 사유와 직결되는 영역이라 가장 급합니다.
- ☑ 2단계 (1분기 내) — 거버넌스 정비: CISO·CPO의 보고 라인과 결재 권한을 문서와 조직도로 정리합니다. 예비심사 컷오프 항목이기도 합니다.
- ☑ 3단계 (2분기 내) — 계정·인증정보 자동화: HR-IAM 연동으로 퇴사자 계정 자동 회수, 시크릿 매니저 도입으로 하드코딩 키 제거, 장기 미사용 키 폐기 정책을 수립합니다.
- ☑ 4단계 (3분기 내) — 공격 표면 관리: 외부 노출 자산을 자동 탐색해 인증 범위에 편입하고, 불필요한 인터넷 접점을 닫습니다. 자산 식별 자동화 도구(ASM) 도입을 검토하세요.
- ☑ 5단계 (심사 3개월 전) — 자체 모의침투 리허설: 외부 전문기관이나 내부 레드팀으로 실제 심사와 같은 방식의 모의침투를 먼저 받아보고, 발견 사항을 조치 이력과 함께 증적으로 남깁니다.
💡 실전 팁: 경영진 보고 때는 "기준이 20개 늘었다"보다 "사고 나면 심사 인력·기간이 두 배, 패치 하나 놓치면 인증 취소"라고 말하는 편이 예산 확보에 훨씬 효과적입니다. 리스크를 비용 언어로 번역하는 게 CISO의 일입니다.
 |
| 자산·계정·인증정보·운영 증적을 연결해 조직의 보안 준비 상태를 점검하세요. |
7. 실전 코드 3종 — 심사 전 셀프 점검 자동화
개편된 심사는 결국 "도구로 증명하라"는 요구입니다. 그래서 인증 취소 사유(로그 미보관)와 강화 기준(인증정보 관리·계정 생명주기)을 직접 겨냥한 점검 코드 3종을 준비했습니다. 모두 Python 3.9 이상에서 동작하며, 결과를 파일로 남기면 그대로 심사 증적으로 활용할 수 있습니다.
▶ 실전 코드 ① — 접속기록 보존기간·누락일·무결성 자동 점검기
로그 미보관은 개편 후 인증 취소 사유로 명시된 중대 결함입니다. 이 스크립트는 로그 디렉터리의 파일명에서 날짜를 추출해 요구 보존기간(1년 또는 2년) 충족 여부와 중간 누락일을 찾아내고, SHA-256 해시 목록을 만들어 이후 변조 여부까지 검증합니다. 2.9.4 로그 및 접속기록 관리와 강화 기준의 무결성 검증을 동시에 겨냥한 구조입니다.
#!/usr/bin/env python3
# [ISMS-P 2.9.4] 접속기록 보존기간 · 누락일 · 무결성 점검기
# 사용 예:
# python log_audit.py --dir /var/log/app --years 2 --manifest build
# python log_audit.py --dir /var/log/app --years 2 --manifest verify
import argparse
import hashlib
import json
import re
import sys
from datetime import date, timedelta
from pathlib import Path
# 파일명 속 날짜 패턴 (2026-09-28, 20260928, 2026_09_28 모두 인식)
DATE_RE = re.compile(r"(20\d{2})[-_]?(0[1-9]|1[0-2])[-_]?(0[1-9]|[12]\d|3[01])")
MANIFEST = "log_manifest.json"
def extract_date(name):
m = DATE_RE.search(name)
if not m:
return None
try:
return date(int(m.group(1)), int(m.group(2)), int(m.group(3)))
except ValueError:
return None
def sha256_of(path):
h = hashlib.sha256()
with open(path, "rb") as f:
for chunk in iter(lambda: f.read(1024 * 1024), b""):
h.update(chunk)
return h.hexdigest()
def collect(log_dir, pattern):
files = {}
for p in Path(log_dir).rglob(pattern):
if p.is_file():
d = extract_date(p.name)
if d:
files.setdefault(d, []).append(p)
return files
def check_retention(files, years):
today = date.today()
required_from = today - timedelta(days=365 * years)
if not files:
return False, ["로그 파일을 한 건도 찾지 못했습니다."]
oldest = min(files)
issues = []
# 보존기간 충족 여부: 가장 오래된 로그가 요구 시작일 이전이어야 함
if oldest > required_from:
issues.append(f"보존기간 미달: 가장 오래된 로그 {oldest}, 요구 시작일 {required_from}")
# 요구 구간 내 누락일 탐지 (당일 제외)
cur = max(oldest, required_from)
missing = []
while cur < today:
if cur not in files:
missing.append(cur.isoformat())
cur += timedelta(days=1)
if missing:
issues.append(f"누락일 {len(missing)}일: {', '.join(missing[:10])}"
+ (" ..." if len(missing) > 10 else ""))
return not issues, issues
def build_manifest(files, out):
data = {str(p): sha256_of(p) for plist in files.values() for p in plist}
Path(out).write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")
print(f"[+] 해시 목록 {len(data)}건 저장 → {out} (WORM/별도 서버 보관 권장)")
def verify_manifest(out):
data = json.loads(Path(out).read_text(encoding="utf-8"))
tampered, removed = [], []
for path, digest in data.items():
p = Path(path)
if not p.exists():
removed.append(path)
elif sha256_of(p) != digest:
tampered.append(path)
for t in tampered:
print(f"[!] 변조 의심: {t}")
for r in removed:
print(f"[!] 삭제됨: {r}")
return not (tampered or removed)
def main():
ap = argparse.ArgumentParser(description="ISMS-P 접속기록 점검")
ap.add_argument("--dir", required=True, help="로그 디렉터리")
ap.add_argument("--glob", default="*.log*", help="파일 패턴")
ap.add_argument("--years", type=int, default=1, choices=[1, 2],
help="요구 보존연수 (대규모·민감정보 처리 시 2년)")
ap.add_argument("--manifest", choices=["build", "verify"])
args = ap.parse_args()
files = collect(args.dir, args.glob)
ok, issues = check_retention(files, args.years)
print(f"[*] 대상 일수: {len(files)}일 / 요구 보존: {args.years}년")
for i in issues:
print(f"[!] {i}")
if args.manifest == "build":
build_manifest(files, MANIFEST)
elif args.manifest == "verify":
ok = verify_manifest(MANIFEST) and ok
print("[결과] 적합" if ok else "[결과] 결함 — 조치 필요")
sys.exit(0 if ok else 1) # CI/스케줄러 알림 연동용 종료코드
if __name__ == "__main__":
main()
💡 실전 팁: 해시 목록(log_manifest.json)을 로그와 같은 서버에 두면 공격자가 둘 다 고칠 수 있습니다. 반드시 WORM 스토리지나 별도 권한의 저장소에 보관하고, cron으로 매일 verify를 돌려 종료코드 1이면 SIEM 알림이 가도록 연결하세요. 보존연수는 개인정보의 안전성 확보조치 기준에 따라 처리 규모·정보 유형별로 달라지니 법무팀과 먼저 확정하시기 바랍니다.
▶ 실전 코드 ② — 소스코드 내 하드코딩 API 키·토큰 탐지기
강화 기준 '인증정보 관리'에서 가장 먼저 걸리는 게 소스코드와 설정 파일에 박힌 키입니다. 개편 심사에서는 소스코드 진단 도구가 투입되므로, 심사원보다 먼저 찾아내는 게 핵심입니다. 이 스캐너는 주요 클라우드·SaaS 키 패턴을 탐지하고 결과를 마스킹해서 출력하며, CI 파이프라인에서 실패 처리할 수 있도록 종료코드를 돌려줍니다.
#!/usr/bin/env python3
# [ISMS-P 강화기준 · 인증정보 관리] 하드코딩 시크릿 탐지기
# 사용 예: python secret_scan.py ./src (CI에서 exit 1 이면 빌드 실패 처리)
import re
import sys
from pathlib import Path
RULES = {
"AWS Access Key": re.compile(r"\b(AKIA|ASIA)[0-9A-Z]{16}\b"),
"GitHub Token": re.compile(r"\bgh[pousr]_[A-Za-z0-9]{36,}\b"),
"Slack Token": re.compile(r"\bxox[abprs]-[A-Za-z0-9-]{10,}\b"),
"Google API Key": re.compile(r"\bAIza[0-9A-Za-z_\-]{35}\b"),
"Private Key": re.compile(r"-----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----"),
"JWT": re.compile(r"\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b"),
"Generic Secret": re.compile(
r"(?i)(api[_-]?key|secret|passwd|password|token)\s*[:=]\s*['\"]([^'\"\s]{12,})['\"]"
),
}
SKIP_DIRS = {".git", "node_modules", "venv", ".venv", "dist", "build", "__pycache__"}
SKIP_EXT = {".png", ".jpg", ".gif", ".zip", ".jar", ".pdf", ".ico", ".woff", ".lock"}
MAX_SIZE = 2 * 1024 * 1024 # 2MB 초과 파일은 제외
def mask(value):
# 증적 보고서에 원문 키가 남지 않도록 앞 4자리만 노출
return value[:4] + "*" * max(len(value) - 4, 4)
def scan_file(path):
findings = []
try:
text = path.read_text(encoding="utf-8", errors="ignore")
except OSError:
return findings
for lineno, line in enumerate(text.splitlines(), 1):
if "secret-scan:ignore" in line: # 검토 완료된 예외 표시
continue
for name, rule in RULES.items():
for m in rule.finditer(line):
hit = m.group(m.lastindex) if name == "Generic Secret" else m.group(0)
findings.append((path, lineno, name, mask(hit)))
return findings
def iter_files(root):
for p in Path(root).rglob("*"):
if any(part in SKIP_DIRS for part in p.parts):
continue
if p.is_file() and p.suffix.lower() not in SKIP_EXT and p.stat().st_size <= MAX_SIZE:
yield p
def main():
root = sys.argv[1] if len(sys.argv) > 1 else "."
results = []
for f in iter_files(root):
results.extend(scan_file(f))
for path, lineno, name, masked in results:
print(f"[!] {path}:{lineno} {name} {masked}")
print(f"\n[결과] 탐지 {len(results)}건")
if results:
print("→ 즉시 키 폐기·재발급 후 Secrets Manager / Vault 로 이관하세요.")
print("→ Git 이력에도 남아 있으므로 커밋 삭제만으로는 해결되지 않습니다.")
sys.exit(1 if results else 0)
if __name__ == "__main__":
main()
💡 실전 팁: 이 스크립트는 '현재 파일'만 봅니다. 이미 커밋 이력에 들어간 키까지 찾으려면 gitleaks나 trufflehog 같은 전용 도구로 전체 히스토리를 한 번 스캔하고, pre-commit 훅에 이 스크립트를 걸어 신규 유입을 막는 2단 구성을 권합니다.
⚠️ 주의: 탐지된 키를 코드에서 지우는 것만으로는 조치가 끝나지 않습니다. 노출된 키는 이미 유출된 것으로 간주하고 반드시 폐기·재발급해야 하며, 폐기 일시와 담당자를 기록해 둬야 심사에서 '조치 완료'로 인정받을 수 있습니다.
▶ 실전 코드 ③ — AWS IAM 계정·액세스 키 생명주기 & MFA 감사
쿠팡 사례에서 거론된 '회수되지 않은 인증정보' 문제를 클라우드 환경에서 점검하는 코드입니다. 모든 IAM 사용자를 순회하며 90일 넘은 액세스 키, 90일 넘게 쓰지 않은 키, MFA 없이 콘솔 로그인이 가능한 계정을 찾아 CSV로 남깁니다. 강화 기준의 자동화된 계정 관리·사용자 인증 강화·인증정보 관리를 한 번에 점검할 수 있습니다.
#!/usr/bin/env python3
# [ISMS-P 2.5.x · 강화기준] IAM 계정·액세스 키 생명주기 & MFA 감사
# 필요 권한(읽기 전용): iam:ListUsers, iam:ListAccessKeys,
# iam:GetAccessKeyLastUsed, iam:ListMFADevices, iam:GetLoginProfile
# 설치: pip install boto3
import csv
from datetime import datetime, timezone
import boto3
from botocore.exceptions import ClientError
MAX_KEY_AGE = 90 # 키 교체 주기(일) — 내부 정책에 맞게 조정
MAX_IDLE_DAYS = 90 # 미사용 허용 기간(일)
iam = boto3.client("iam")
now = datetime.now(timezone.utc)
def has_console_login(user):
try:
iam.get_login_profile(UserName=user)
return True
except ClientError as e:
if e.response["Error"]["Code"] == "NoSuchEntity":
return False
raise
def audit():
rows = []
for page in iam.get_paginator("list_users").paginate():
for u in page["Users"]:
name = u["UserName"]
console = has_console_login(name)
mfa = bool(iam.list_mfa_devices(UserName=name)["MFADevices"])
# 1) 콘솔 로그인 가능 + MFA 미설정 → 사용자 인증 강화 위반
if console and not mfa:
rows.append([name, "-", "콘솔 MFA 미설정", "HIGH"])
for k in iam.list_access_keys(UserName=name)["AccessKeyMetadata"]:
if k["Status"] != "Active":
continue
key_id = k["AccessKeyId"]
age = (now - k["CreateDate"]).days
last = iam.get_access_key_last_used(AccessKeyId=key_id)["AccessKeyLastUsed"]
last_date = last.get("LastUsedDate")
idle = (now - last_date).days if last_date else age
# 2) 교체 주기 초과 키
if age > MAX_KEY_AGE:
rows.append([name, key_id[:8] + "****", f"생성 {age}일 경과", "MEDIUM"])
# 3) 장기 미사용 키 → 퇴사자·방치 계정 의심, 우선 폐기 대상
if idle > MAX_IDLE_DAYS:
rows.append([name, key_id[:8] + "****", f"미사용 {idle}일", "HIGH"])
return rows
def main():
rows = audit()
out = f"iam_audit_{now:%Y%m%d}.csv"
with open(out, "w", newline="", encoding="utf-8-sig") as f:
w = csv.writer(f)
w.writerow(["사용자", "액세스키", "결함 내용", "위험도"])
w.writerows(rows)
high = sum(1 for r in rows if r[3] == "HIGH")
print(f"[결과] 결함 {len(rows)}건 (HIGH {high}건) → {out}")
print("→ HR 퇴사자 명단과 대조해 미회수 계정을 즉시 비활성화하세요.")
if __name__ == "__main__":
main()
💡 실전 팁: 이 감사 스크립트는 반드시 읽기 전용 권한의 전용 역할로 실행하고, 결과 CSV를 HR 퇴사자 명단과 주간 단위로 자동 대조하세요. 궁극적으로는 IAM 사용자 키 자체를 없애고 SSO + 임시 자격증명(IAM Identity Center, 역할 기반 접근)으로 전환하는 것이 강화 기준의 취지에 가장 부합합니다.
 |
| 인증 준비는 실제 시스템의 보호조치와 운영 상태를 확인하는 데서 시작합니다. |
8. 자주 묻는 질문 (FAQ)
정부 계획상 ISMS-P 의무화 대상은 주요 공공시스템 운영기관, 이동통신사업자, 본인확인기관, 대규모 개인정보처리자입니다. 대규모 개인정보처리자의 구체적인 매출·처리 규모 기준은 시행령 개정으로 확정될 예정이므로, 개인정보 처리 규모가 큰 기업이라면 지금부터 개인정보 처리단계별 요구사항 21개를 미리 점검해 두시는 게 안전합니다.
네. 예비심사 컷오프, 기술 중심 현장 심사, 인증 취소 사유 구체화는 표준 인증에도 영향을 줍니다. 특히 패치 미적용과 로그 미보관은 규모와 관계없이 취소 사유가 될 수 있으니, 7번 실전 코드 ①부터 돌려보시길 권합니다.
세부 수행 방식은 기술심사 가이드로 정해질 예정이지만, 통상 모의침투는 사전 합의된 범위·시간·방법 안에서 진행됩니다. 실무적으로는 점검 대상 목록, 허용 시간대, 긴급 중단 연락 체계를 미리 문서화해 두는 게 좋습니다. 무엇보다 심사 전에 자체 모의침투로 리허설을 해두면 당일 리스크가 크게 줄어듭니다.
사고 기업은 사후심사에 인력과 기간이 대폭 늘어나고 사고 원인과 조치 현황을 집중적으로 봅니다. 사고 원인 분석 보고서, 재발 방지 대책, 대책별 이행 증적(설정 변경 이력, 패치 로그, 교육 기록)을 한 묶음으로 정리해 두세요. '무엇을 했는지'보다 '다시 일어나지 않는다는 걸 어떻게 증명하는지'가 핵심입니다.
인증 기준, 안내서, 고시 개정 소식은 KISA의 ISMS-P 인증 포털에서 가장 먼저 공지됩니다. 과기정통부·개인정보보호위원회 보도자료도 함께 챙겨 보시고, 더 궁금한 점은 댓글로 남겨주세요!
9. 마무리 요약
✅ ISMS-P, 이제 '받는 인증'이 아니라 '유지하는 인증'입니다
2025년 롯데카드·KT·쿠팡·SK텔레콤 사고는 인증서가 안전을 보장하지 않는다는 사실을 드러냈고, 정부는 간편·표준·강화 3단계 체계와 101개 + 20개 강화 기준, 모의침투 투입, 인증 취소 구체화로 답했습니다. 강화 기준의 7대 영역은 모두 실제 사고에서 역산된 것이며, 공통 키워드는 '자동화로 증명하라'입니다.
지금 당장은 인증 취소 사유(패치·로그)부터 제거하고, 이어서 계정·인증정보 생명주기 자동화와 외부 접점 정리로 넘어가세요. 오늘 소개한 실전 코드 3종이 그 첫걸음이 될 수 있습니다.
오늘 딱 한 가지만 해보세요 — 실전 코드 ①로 우리 회사 접속기록이 요구 기간만큼 빠짐없이 남아 있는지 확인하는 것. 10분이면 끝나지만, 결과를 보고 놀라는 분이 생각보다 많습니다. 여러분 조직은 이번 개편에서 어느 영역이 가장 걱정되시나요? 댓글로 남겨주시면 현장 경험을 바탕으로 같이 고민해 보겠습니다.
다음 포스팅에서는 강화 기준 '계정 생명주기 자동화' — HR 시스템과 IAM 연동 실전 설계를 코드와 함께 다룰 예정이니 기대해 주세요!
댓글
댓글 쓰기