강력한 SSO, 하지만 위험도 크다?
SSO(Single Sign-On)는 정말 편리한 기술입니다. 하지만 이 편리함은 보안이 제대로 설정되지 않으면 오히려 **전사적 보안의 단일 실패 지점(Single Point of Failure)**이 되기도 합니다.
"한 번 뚫리면, 다 뚫린다."
특히 SAML 기반의 SSO는 XML 서명과 리디렉션 흐름을 기반으로 하기 때문에, 아는 사람에겐 익숙하지만, 모르는 사람에겐 취약한 구조가 되기 쉽습니다.
1. SAML Assertion 위조 공격
공격 시나리오:
공격자가 SP로 전달되는 **SAML Assertion(XML)**을 위조해 자신이 인증된 사용자처럼 속이는 시도.
- <NameID>admin@example.com</NameID>로 바꾸는 식.
- XML 구조는 유지하지만, 서명을 일부만 감싸도록 조작할 수도 있음.
방어 전략:
- 전체 Assertion에 디지털 서명 적용
- SP에서 서명 검증 철저히 수행 (XML Signature 검증)
- XML Wrapping 공격 방어를 위해 정확한 XPath 경로 지정
2. Replay 공격 (재전송 공격)
공격 시나리오:
공격자가 이전에 정상 인증된 사용자의 SAML Assertion을 가로채 저장하고, 이후 다시 재전송해 로그인 시도.
방어 전략:
- Assertion의 <Conditions> 태그에 NotBefore / NotOnOrAfter 시간 제한 설정
- SP는 이 시간을 엄격하게 확인해야 함
- Assertion마다 고유 ID (Assertion ID)를 부여하고, 사용 여부 기록
- IdP와 SP 간에 One-Time-Use 조건 적용
3. 중간자 공격 (MITM, Man-in-the-Middle)
공격 시나리오:
사용자가 IdP나 SP에 로그인할 때, HTTPS 연결이 없거나 약한 환경에서 트래픽을 가로채 로그인 정보를 탈취
방어 전략:
- 모든 로그인 흐름에 HTTPS 필수 적용
- 인증서 유효성 검사 (브라우저 신뢰체계)
- HTTP Strict Transport Security(HSTS) 활성화
- 클라이언트-서버 간 통신 시 TLS 1.2 이상 강제 적용
4. IdP 설정 오용 및 피싱
공격 시나리오:
- SP가 누구나 사용하는 임의의 IdP를 받아들이도록 설정됨
- 공격자가 자신이 만든 가짜 IdP로 리디렉션을 유도
- 인증 후 Assertion을 SP에 전달 → 인증된 것처럼 보이게 함
방어 전략:
- SP는 허용된 IdP 목록만 명시적으로 설정
- Issuer와 Metadata URL을 화이트리스트 방식으로 고정
- Assertion 수신 시, 발행자 검증(issuer check) 필수
5. 로그아웃 처리 미흡 (SLO 문제)
시나리오:
사용자가 A 서비스에서 로그아웃했지만,
다른 서비스(B, C)는 여전히 로그인된 상태 → SSO 상태가 유지
방어 전략:
- Single Logout(SLO) 기능 구현
- IdP가 SP들에게 로그아웃 요청 전파
- SP는 로그아웃 요청에 따라 세션 삭제
- 브라우저에 남은 쿠키 삭제
※ 단, 완전한 SLO 구현은 어렵고, 사용자 교육과 세션 타임아웃 설정이 병행되어야 함
6. 세션 하이재킹 (Session Hijacking)
시나리오:
로그인 완료 후 발급된 SP의 세션 쿠키를 탈취해 공격자가 사용
방어 전략:
- 쿠키에 Secure, HttpOnly, SameSite 속성 적용
- 사용자별 디바이스 식별 → 의심스러운 접근 차단
- 세션마다 접속 IP, User-Agent 매칭 확인
보안을 위한 종합 체크리스트
| 항목 | 권장 조치 |
| SAML Assertion 위조 방지 | 전체 XML 서명, 서명 검증 |
| Assertion 재사용 방지 | 시간 조건, Assertion ID 중복 검사 |
| HTTPS 강제 | HSTS, TLS 1.2 이상 |
| IdP 허용 목록 제한 | 정해진 Issuer만 수락 |
| 쿠키 보안 | Secure, HttpOnly, SameSite 설정 |
| 세션 관리 | 세션 타임아웃, 기기/위치 인식 |
마무리 요약
SAML 기반 SSO는 편리하지만 설계와 설정이 허술할 경우 전체 시스템의 약점이 될 수 있습니다.
특히 SAML Assertion은 사용자의 신원을 대리하는 문서이기 때문에, 이를 철저히 검증하지 않으면 가짜 사용자에게 문을 열어주는 꼴이 됩니다.
SSO는 단순히 연동만 하면 끝이 아니라, 어떻게 안전하게 설계했는가, 어떤 보안 정책을 병행했는가가 중요합니다.
다음 예고 (시리즈 마지막 편)
다음 10편에서는 이 시리즈의 모든 내용을 요약하고, 어떻게 공부하면 실무에서 SSO 설계, 구현, 문제 분석까지 할 수 있는 준전문가 수준이 되는지를 안내합니다. 또한 IT 취업 준비생이 이 흐름을 기반으로 어떻게 공부를 확장해나가야 하는지도 조언해 드릴 예정입니다.
'호주 IT 취업' 카테고리의 다른 글
| 호주의 정치 시스템 (2) | 2025.06.27 |
|---|---|
| [SSO 로그인 흐름 10편] 시리즈 요약과 IT 취업 준비 로드맵 (6) | 2025.06.24 |
| 2025년 7월부터 인상되는 호주 최저임금, 얼마나 오르나? (1) | 2025.06.22 |
| [SSO 로그인 흐름 8편] 직접 들여다보자! DevTools로 SSO 흐름 추적하기 (0) | 2025.06.22 |
| [SSO 로그인 흐름 7편] Azure AD, Okta, OneLogin은 어떻게 다를까? – 실전 사례로 보는 SSO 흐름 (4) | 2025.06.21 |