SSO(Single Sign-On)
요즘 엔터프라이즈 환경에서 기본 중 기본이다. 한 번의 로그인으로 동일한 세션 중에 여러 애플리케이션/서비스에 접근할 수 있게 해주는 인증 체계이다. 사용자는 하나의 사용자 이름과 비밀번호로 여러 서비스에 접속할 수 있으며, 반복적인 로그인 절차를 생략하여 사용자 편의성을 높이고, 중앙 집중식 계정 관리로 보안성을 향상할 수 있다. (개인이 개별 애플리케이션 로그인 인증정보를 기억할 필요가 없어짐 → 사이버 보안에 필요한 관리 작업이 줄어듦)
예시
Google 계정 로그인 한 번으로 Gmail, Google Drive 등 구글의 여러 서비스에 접속하는 것
① 위임(Delegation) 방식
각 서비스가 직접 사용자 인증을 하지 않고, SSO Agent가 사용자의 인증 요청을 중앙의 IdP(인증 제공자)에 전달하고, IdP의 응답을 서비스에 대신 전달하는 방식이다.
- 대상 애플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용
- 사용자가 서비스 접근 시, 서비스는 토큰을 직접 검증하지 않고 중앙 IdP에 확인을 위임
- IdP가 인증을 완료하면, 서명된 토큰이나 인증 결과를 SSO Agent가 받아 서비스로 전달하여 사용자가 접근할 수 있게 함
예시
사용자가 회사 인트라넷에서 사내 게시판 애플리케이션에 접속하려고 한다.
게시판 애플리케이션은 자체적으로 사용자의 로그인 정보를 확인하지 않고, “이 사용자가 인증된 적 있는지?”를 SSO Agent에게 묻는다.
SSO Agent는 해당 요청을 받아 중앙 IdP(Identity Provider)에 전달한다.
IdP는 사용자의 자격 증명(아이디/비밀번호, MFA 등)을 검증한다.
- 사용자가 이미 로그인해 세션이 있으면, 그 결과를 재사용한다.
- 로그인하지 않았다면, 로그인 화면으로 리다이렉트한다.
IdP가 인증을 완료하면, “이 사용자는 인증됨”이라는 결과를 SSO Agent에게 보낸다.
SSO Agent는 이 인증 결과를 받아서 게시판 애플리케이션에 전달한다.
게시판 애플리케이션은 IdP가 보증한 인증 결과를 신뢰하고, 사용자가 정상적으로 접근할 수 있도록 한다.
② 전파(Propagation) 방식
SSO 시스템과 신뢰 관계를 토대로 사용자를 인증한 사실을 전달 받아 SSO를 구현하는 방식이다.
- 기반 기술: 커버로스
- 통합 인증을 수행하는 곳에서 인증을 받아, 대상 애플리케이션으로 전달할 토큰을 발급받고, 대상 애플리케이션에 사용자가 접근할 때 토큰을 자동으로 전달하여 대상 애플리케이션이 사용자를 확인할 수 있도록 하는 방식
- 사용자가 토큰을 직접 들고 다니면서 각 서비스에 제시
- 웹 환경에서는 쿠키라는 기술을 이용해 토큰을 자동으로 대상 어플리케이션에 전달 가능
- 웹 환경에서의 SSO는 대부분 이 모델을 채택하고 있음
예시
사용자가 서비스 제공업체 중 하나 또는 중앙 포털(예: 회사 인트라넷 또는 대학생 포털)에 SSO 로그인 자격 증명을 사용하여 로그인한다.
사용자가 성공적으로 인증되면 SSO 솔루션은 사용자 ID에 대한 특정 정보(사용자 이름, 이메일 주소 등)가 포함된 세션 인증 토큰을 생성한다. 이 토큰은 사용자의 웹 브라우저 또는 SSO 시스템에 저장된다.
사용자가 다른 신뢰할 수 있는 서비스 제공업체에 액세스하려고 하면 애플리케이션은 SSO 시스템을 통해 사용자가 세션에 대해 이미 인증되었는지 확인한다. 사용자가 인증을 받은 경우 SSO 솔루션은 디지털 인증서로 인증 토큰에 서명하여 사용자를 검증하고 사용자에게 애플리케이션에 대한 액세스 권한을 부여한다. 그렇지 않은 경우에는 사용자에게 로그인 자격 증명을 다시 입력하라는 메시지가 표시된다.
SSO가 왜 보안에 도움이 되지? 하나의 계정으로 여러 서비스에 접속이 가능하다면 오히려 더 취약한 거 아냐? 🤔
1. SSO가 보안에 도움이 되는 이유
- 비밀번호 피로도 감소 → 강력한 비밀번호 사용 가능
- 사용자가 수십 개의 서비스에 각각 다른 비밀번호를 쓰면 결국 기억하기 힘들어서 재사용(“123456”, 같은 패턴 등)을 하게 된다.
- 그런데 SSO를 쓰면 한 번만 기억하면 되기 때문에(사용자가 관리해야 할 비밀번호 수 감소) 복잡하고 긴 비밀번호 + MFA를 걸어도 부담이 줄어든다.
- 중앙 집중식 관리 가능
- 보안팀이 직원 계정을 관리하기 쉬워진다.
- (ex) 직원이 퇴사했을 때 SSO 계정만 비활성화하면 모든 서비스 접근이 동시에 차단된다. (퇴사자 보안리스크 해결)
- 중앙 통합 관리로 IT 관리 비용 감소
- 개별 애플리케이션마다 MFA를 붙이는 대신, SSO 진입점에서만 MFA를 강제하면 모든 서비스가 MFA 보호를 받기 때문에 효율적이면서 강력한 보호가 가능하다.
2. SSO의 보안 Risk
- Single Point of Failure
- SSO 계정이 털리면 연결된 모든 서비스가 동시에 뚫릴 수 있다.
→ 그래서 보통 MFA + 위협 탐지를 반드시 붙인다.
- SSO 계정이 털리면 연결된 모든 서비스가 동시에 뚫릴 수 있다.
- SSO 제공자의 취약점
- SSO 서버 자체가 공격당하면, 조직 전체가 위험해진다.
→ 따라서 제로 트러스트 접근 제어, 세션 모니터링이 필요하다.
- SSO 서버 자체가 공격당하면, 조직 전체가 위험해진다.
- 피싱 위험
- 사용자가 무심코 가짜 SSO 로그인 페이지에 정보를 입력하면 공격자가 전체 접근 권한을 가져갈 수 있다.
- 각각의 사이트마다 보안 수준이 다르면 보안에 문제가 생길 수 있다.
출처
https://www.ibm.com/kr-ko/think/topics/single-sign-on
https://itwiki.kr/w/SSO
https://co-no.tistory.com/entry/%EC%84%9C%EB%B2%84-%EA%B3%B5%ED%86%B5-SSOSingle-Sign-On-%EC%9D%B4%EB%9E%80
