[시큐리티 아카데미] SSPM 진단 프레임워크 - ISMS-P 기반 SaaS 보안 자동 진단
🌾 수확 완료
ISMS-P 인증 기준을 SaaS 설정 수준으로 풀어 Okta·GitHub·Cloudflare·1Password를 API로 자동 판정하고, 결과를 대시보드와 진단 보고서로 산출한 컨설팅 트랙 팀 프로젝트
- ISMS-P
- Okta
- SSO/MFA
- Python
- FastAPI
- 멀티 에이전트
- Splunk SIEM
- SaaS 보안
개요
시큐리티아카데미 7기 컨설팅 트랙에서 3인 팀으로 진행한 프로젝트다. 가상 기업의 SaaS 업무 환경을 직접 구축하고, ISMS-P 인증 기준을 각 SaaS의 설정값과 로그 수준으로 풀어서 API로 자동 판정하는 진단 체계를 만들었다. 진단 결과는 웹 대시보드와 자동 생성 보고서(Security Posture Report)로 나오고, Splunk SIEM으로 이상징후 탐지까지 이어진다.
“진단 기준 수립 → 자동 진단 → 보고서 → 조치 권고 → 마스터플랜”이라는 컨설팅 한 사이클을 축소판이지만 처음부터 끝까지 직접 돌려본 경험이다.
문제
기업의 SaaS 도입은 빠르게 늘고 있는데, 서비스마다 흩어진 권한·설정이 기준에 맞는지 체계적으로 점검하는 수단은 부족하다. 팀이 조사한 자료(AppOmni, The 2025 State of SaaS Security Report)에서는 파편화된 권한·설정 오류가 SaaS 보안 사고의 70%를 차지한다고 했다.
이 문제를 다루는 상용 SSPM(SaaS Security Posture Management) 솔루션은 이미 있다. 다만 Adaptive Shield, AppOmni, Obsidian 같은 제품들은 ISO 27001·NIST·SOC 2 등 글로벌 기준 중심이라, 국내 기업은 결과를 ISMS-P 기준으로 다시 해석해야 한다. ISMS-P와 SaaS 설정을 직접 연결하는 진단 도구가 없어서, 이걸 직접 설계하기로 했다.
진행 과정
1. 가상 기업 SaaS 환경 구축
진단할 대상이 있어야 하니 가상 기업을 먼저 세웠다. Okta를 IdP로 두고 나머지 SaaS를 SSO·MFA로 묶었고, 사용자 그룹을 만들어 그룹 단위로 앱 접근 권한을 관리했다. 실제 기업과 같은 구조가 아니면 진단 결과가 의미를 갖지 못하기 때문이다.
| SaaS | 역할 |
|---|---|
| Okta | 인증 관문 (IdP / SSO / MFA) |
| GitHub | 소스코드와 공급망 |
| Cloudflare | 외부 노출 접점 (WAF / DNS) |
| 1Password | 비밀번호·시크릿 관리 |
| Splunk | 감사 로그 수집과 SIEM |
2. ISMS-P 진단 기준 수립
ISMS-P 보호대책 요구사항 64개를 놓고 “SaaS 설정·정책·로그로 증빙할 수 있는가”, “자동화·반복 점검이 가능한가”, “정량 기준이 있는가”를 기준으로 걸렀다. 정책·계약·교육 같은 관리적 항목은 제외했다.
- 64개 검토 → SaaS 환경에 적용 가능한 42개 선별
- 그중 정적 설정으로 판정할 수 없는 11개(직무 분리, 로그 점검 주기, 이상행위 모니터링 등)는 SIEM 행위 모니터링으로 이관
- 최종 API 자동 진단 대상 31개 통제항목 확정 → SaaS별 O/X 판별식·API 판정 조건 84건 매핑 → 데모 진단에서 4개 SaaS 44개 항목 판정
항목마다 아래 형식으로 판별식을 세웠다. 이 표가 프로젝트의 뼈대다.
[ISMS-P 2.2.1 주요 직무자 지정 및 관리 · Okta]
· 판별식 : 최고 관리자(Super Admin) 계정 수가 임계치(3명 이하)를 넘지 않는가?
· 지표 : 최고 관리자 권한 계정 수 · 90일 이상 미접속 관리자 수
· 수집 : GET /api/v1/iam/roles 및 role assignments
· 판정 : O = Super Admin 3명 이하, 소유자 불명·미접속 관리자 0건정량 지표(API 값을 임계치와 비교해 기계적으로 O/X)와 정성 지표(정책·지침 존재와 이행 여부를 문서로 검토)를 나눈 것도 이 단계다. ISMS-P의 본질은 관리체계와 이행이라서 정량 판정만으로는 부족하다는 결론이었다.
3. API 자동 진단 엔진과 대시보드
Python 수집기 → O/X 판정 엔진 → FastAPI 백엔드 → 웹 대시보드 흐름이다.
각 SaaS API에서 설정값과 활동 기록을 가져오고, 항목별 임계값과 비교 연산자를 정의해
O / X / N·A를 자동으로 판별한다. 대시보드는 진단 대상 설정과 원클릭 진단, Executive
Summary(항목 수·보안 점수·상태별 건수), 상세 보고서, 조치 권고, 마스터플랜 화면으로 구성했다.
4. Splunk SIEM 모니터링
4개 SaaS의 감사 로그를 Splunk에 적재하고, API 진단으로 잡히지 않는 동적 항목을 탐지 룰로 봤다. 예를 들어 MFA는 “정책이 켜져 있는가”와 “실제로 MFA 없이 통과한 로그인이 있는가”를 양면에서 확인해야 한다.
index=main sourcetype="OktaIM2:log"
(eventType="user.authentication.auth_via_mfa"
OR eventType="policy.evaluate_sign_on")
| stats count by eventType outcome.resultpolicy.evaluate_sign_on의 결과가 ALLOW면 MFA 없이 통과한 것이고, auth_via_mfa의
FAILURE·ABANDONED는 재등록 대상 또는 우회 시도다. 이 집계가 그대로 2.5.3 사용자 인증
항목의 증적이 된다.
내가 한 일
세 명이 나눠 했고, 포트폴리오에 적은 내 기여도는 설계 30% / 개발 50% / 최적화 50%다.
- SaaS 설정값 수집과 O/X 판정 룰 정의 - 각 SaaS API에서 보안 설정값을 수집하고, 항목별 임계값과 비교 연산자를 정의해 O / X / N·A를 자동 판별하는 판정 엔진을 구현했다.
- 가상 기업 환경 구축과 SaaS 직접 연동 - Okta를 IdP로 설정하고 GitHub·Cloudflare·1Password를 SSO·MFA로 연동해 실제 기업형 인증 아키텍처를 만들었다.
- 진단 결과 대시보드 시각화 - 판정 결과를 웹 대시보드에서 실시간으로 확인할 수 있게 구성했다.
결과
최종 산출물은 ISMS-P × SaaS 통합 매핑표(84건), SaaS 보안 상태 진단 보고서, 이상징후 모니터링 보고서, 그리고 웹 대시보드다. 상용 SSPM의 진단 방식을 벤치마킹한 뒤 국내 ISMS-P 기준에 맞는 자체 진단 체계를 완성했고, Splunk SIEM 연동으로 통합 보안 모니터링까지 확장 설계했다.
2026년 5월 가상 기업 테넌트(Okta·GitHub·Cloudflare·1Password)를 대상으로 진단을 돌린 결과는 44개 항목에 대해 아래와 같이 나왔다.
| 판정 | 건수 | 비율 |
|---|---|---|
| ✔ 적합 | 16 | 36% |
| ✘ 부적합 (High) | 15 | 34% |
| ◎ 수집완료 (팀 판단 필요) | 10 | 23% |
| ◐ 수동확인 (UI 확인) | 3 | 7% |
| 합계 | 44 | 100% |
SaaS별로는 Cloudflare가 13개 중 9개 부적합으로 가장 취약했고, GitHub가 12개 중 6개 적합으로 가장 양호했다.
| SaaS | 진단 | 적합 | 부적합 | 수집완료 | 수동확인 |
|---|---|---|---|---|---|
| Okta | 10 | 3 | 4 | 3 | 0 |
| GitHub | 12 | 6 | 2 | 4 | 0 |
| Cloudflare | 13 | 3 | 9 | 1 | 0 |
| 1Password | 9 | 4 | 0 | 2 | 3 |
부적합 중 High 위험은 즉시 조치(D+0~7)로 마스터플랜 상단에 올렸다. 대표 항목은 Okta MFA 미활성(INACTIVE), Okta·GitHub·Cloudflare 공통의 외부 SIEM 로그 전송 미설정(2.9.4), Cloudflare WAF 차단 규칙·Access 접근통제 부재다. 보고서는 “진단 요약 → 위험도 기반 우선순위 → 증거 기반 상세 분석 → 개선 조치 계획(담당자·목표일정)” 순서로 흐르고, 항목마다 실제 측정값(API 응답값· 로그 건수)과 조치 경로(콘솔 메뉴 단위)가 붙는다.
대시보드는 브라우저에서 바로 시연할 수 있다: SSPM Console 대시보드
이 프로젝트로 2026 시큐리티아카데미 7기 컨설팅 트랙에서 과학기술정보통신부 장관상을 받았다.
배운 것
- 기준을 설정 수준으로 번역하는 일이 컨설팅의 핵심이었다. “2.5.3 사용자 인증”이라는 한 줄을 Okta의 Sign-on Policy, MFA Authenticator, Password Policy, System Log의 로그인 실패 이벤트로 구체화해야 비로소 판정할 수 있다. 이 번역표를 만드는 데 시간의 절반이 들었다.
- 자동화에는 경계가 있다. 직무 분리나 로그 점검 주기처럼 “관리자가 주기적으로 하는 행위”는 정적 설정 O/X로 잡히지 않는다. 이런 항목을 억지로 자동화하지 않고 SIEM 행위 모니터링으로 넘긴 판단이 결과의 신뢰도를 지켰다.
- 컨설턴트의 역할은 기능 설명이 아니다. 권한·인증·설정이 수많은 서비스에 흩어져 있으면 고객은 자기 보안 수준을 한눈에 파악하는 것부터 막힌다. 위험도를 정량화하고 우선순위를 붙여 “무엇부터 고칠지” 스스로 판단할 기준을 주는 것이 일이라는 걸 체감했다.
이 경험이 지금 진행 중인 리눅스 네트워크 보안 학습 랩의 진단 카드 형식(발견 → 근거 → 위험도 → 기준 → 권고 → 검증)으로 이어졌다.
한계
- 가상 기업이라 실제 조직의 정책 문서와 운영 이력이 없다. 정성 지표 검토는 형식을 세우는 데서 그쳤다.
- 부분충족 8건 중 다수가 “API 추가 확인 필요”였다. 로그만으로 판정하지 못한 항목은 정책 API를 더 붙여야 완전한 O/X가 나온다.
- 대상이 4개 SaaS다. 매핑 체계는 신규 SaaS로 확장 가능하게 만들었지만, 실제로 확장해 검증하지는 못했다.