연합 신원 관리
더 많은 작업
- Federated Identity Management, FIM; 연합 신원 관리(페더레이션)
- 서로 다른 조직이나 보안 도메인이 신뢰 관계를 맺고, 한쪽에서 인증한 신원 정보를 다른 쪽이 받아들여 쓰도록 하는 신원 관리 방식
연합이 없으면 사용자는 협력사 포털, SaaS, 사내 시스템마다 별도 계정을 만들어야 하고, 조직은 퇴사자 계정을 여러 곳에서 일일이 지워야 한다. 연합 신원 관리에서는 사용자가 소속 조직의 신원 제공자(IdP)에서 한 번 인증하면, IdP가 서명한 인증 결과(어서션·토큰)를 서비스 제공자가 믿고 접근을 허용한다. 서비스 쪽은 비밀번호를 보관하지 않아도 되고, 조직은 IdP 한 곳에서 계정을 막으면 연합된 모든 서비스 접근이 함께 끊긴다. NIST 용어집은 연합(federation)을 네트워크로 연결된 여러 시스템 사이에서 신원과 인증 정보를 전달할 수 있게 하는 과정으로 정의한다.
| 역할 | 다른 이름 | 하는 일 |
|---|---|---|
| 신원 제공자(IdP, Identity Provider) | 클레임 제공자, 계정 파트너, OpenID 공급자(OP) | 사용자를 인증하고 신원 속성을 담은 어서션·토큰을 서명해 발급한다. |
| 서비스 제공자(SP, Service Provider) | 신뢰 당사자(RP, Relying Party), 리소스 파트너 | IdP의 어서션을 검증하고 그 내용을 근거로 접근을 허용한다. |
| 사용자(주체) | 가입자 | 브라우저나 앱을 통해 IdP와 SP 사이를 오가며 인증을 받는다. |
| 신뢰 관계(trust) | 메타데이터 교환, 클레임 제공자 신뢰·신뢰 당사자 신뢰 | 서명 인증서, 엔드포인트 주소, 넘겨줄 속성을 미리 합의해 둔다. |
| 구분 | SAML 2.0 | OpenID Connect | OAuth 2.0 | WS-Federation |
|---|---|---|---|---|
| 주 목적 | 인증·속성 전달(웹 SSO) | 인증(신원 확인) | 인가(API 접근 위임) | 인증·속성 전달 |
| 토큰 형식 | XML 어서션 | JWT 형식 ID 토큰 | 액세스 토큰(형식 자유) | 주로 SAML 토큰 |
| 주 사용처 | 기업 웹 SSO, 오래된 SaaS 연동 | 모바일·웹 앱, 소비자 로그인, 최신 SaaS | API·제3자 앱 권한 위임 | 마이크로소프트 계열(AD FS) 웹 앱 |
| 기반 | XML 서명·암호화 | OAuth 2.0 위에 인증 계층 추가 | HTTP, TLS | WS-Security 계열 |
OAuth 2.0은 "이 앱이 내 대신 무엇을 해도 되는가"를 다루는 인가 프레임워크이지 인증 프로토콜이 아니다. 로그인 용도로 쓰려면 그 위에 OpenID Connect를 얹는다. SAML과 OAuth 문서도 함께 본다.
웹 브라우저 기반 SP 시작(SP-initiated) 흐름은 표준과 상관없이 대체로 다음과 같다.
- 사용자가 SP의 보호된 페이지에 접근한다.
- SP는 사용자를 IdP로 리디렉션하면서 인증 요청을 보낸다.
- IdP가 사용자를 인증한다(이미 세션이 있으면 생략).
- IdP는 신원 속성을 담은 어서션·토큰에 서명해 사용자를 거쳐 SP로 돌려보낸다.
- SP는 서명, 발급자, 수신 대상(audience), 유효 시간을 검증한 뒤 자체 세션을 만든다.
NIST SP 800-63C-4는 연합 보증 수준(FAL, Federation Assurance Level)을 세 단계로 둔다. FAL2부터 어서션 주입 공격을 강하게 막아야 하고, FAL3에서는 어서션 외에 사용자가 인증기를 소유하고 있음을 RP가 추가로 확인해야 한다.
CISSP 5.3 항목은 제3자 서비스와 신원을 연합하는 방식을 온프레미스, 클라우드, 하이브리드로 나눈다.
| 방식 | 구성 | 장점 | 단점 |
|---|---|---|---|
| 온프레미스 | 사내 액티브 디렉터리 + AD FS 같은 자체 연합 서버가 IdP 역할을 한다. | 인증 데이터와 정책을 직접 통제한다. | 서버 이중화·인증서 갱신·패치 부담, 외부 공개 서버 공격면 |
| 클라우드 | IDaaS가 IdP이며 디렉터리도 클라우드에 둔다. | 빠른 도입, SaaS 연동 템플릿, 가용성은 공급자가 책임 | 공급자 의존, 데이터 위치·규제 검토 필요 |
| 하이브리드 | 사내 디렉터리를 원본으로 두고 동기화 도구로 클라우드 디렉터리에 계정을 복제한다. 인증은 비밀번호 해시 동기화, 통과 인증(pass-through), 사내 연합 서버 중 하나로 처리한다. | 기존 디렉터리를 유지하며 점진적으로 클라우드로 옮긴다. | 동기화 서버가 고가치 표적이 되고, 구성이 복잡하다. |
AD FS(Active Directory Federation Services)는 조직 간 보안 경계를 넘어 디지털 신원과 권한을 공유하는 윈도우 서버 역할로, SAML·WS-Federation 등을 지원한다. 마이크로소프트의 하이브리드 구성 도구로는 Microsoft Entra Connect와 그 후속인 Entra Cloud Sync가 있다.
IDaaS(Identity as a Service)는 디렉터리, 인증, SSO, 다중 인증, 계정 프로비저닝, 접근 정책을 클라우드 서비스로 제공하는 것이다. 조직은 IdP 서버를 직접 운영하지 않고 구독 형태로 쓰며, 수많은 SaaS와 SAML·OpenID Connect 연동, SCIM 기반 자동 계정 생성·삭제를 미리 만들어 둔 연결기로 처리한다. AWS IAM Identity Center, Microsoft Entra ID 등이 이 범주에 든다.
연합은 신뢰를 한 곳에 모으므로 그곳이 무너지면 피해도 한꺼번에 퍼진다.
- IdP 장애: IdP가 멈추면 연합된 모든 서비스 로그인이 막힌다. 이중화와 IdP에 의존하지 않는 긴급 계정이 필요하다.
- IdP 침해: 공격자가 IdP의 토큰 서명 키를 훔치면 원하는 사용자로 위조 토큰을 만들어 모든 RP에 들어갈 수 있다. 서명 키는 HSM에 보관하고 주기적으로 교체하며, 발급 기록을 감시한다.
- 신뢰 설정 오류: 서명 검증 누락, audience 미확인, 지나치게 넓은 속성 전달은 어서션 위조·재사용으로 이어진다.
- 프라이버시: IdP는 사용자가 어느 서비스에 언제 로그인했는지 모두 알게 된다. 넘겨주는 속성은 최소화한다.
- 인증 정보를 발급하는 쪽이 IdP, 그것을 믿고 접근을 허용하는 쪽이 SP(RP)이다.
- OAuth 2.0은 인가, OpenID Connect와 SAML은 인증이다. "로그인에 OAuth만 쓴다"는 설계는 흔한 오답 함정이다.
- 조직 간 SSO를 구현하라면 연합(SAML·OIDC)을, 한 조직 내부 네트워크 SSO라면 커버로스도 답이 될 수 있다.
- 연합의 가장 큰 위험은 IdP가 단일 실패 지점·단일 침해 지점이 된다는 것이다. 대책은 이중화, 서명 키 보호, 긴급 계정이다.
- 클라우드 IdP 도입 시 경영진 관점의 우선 검토 사항은 계약(SLA, 책임 분담, 데이터 위치)이다.
- NIST SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions – NIST
- AD FS Overview – Microsoft Learn
- Choose the right authentication method for your Microsoft Entra hybrid identity solution – Microsoft Learn
- OpenID Connect Core 1.0 – OpenID Foundation