SSO · 통합 인증
Single Sign-On
SSO이란?
- 한 번 로그인으로 여러 서비스
- 편의+중앙 보안 관리
- 2FA와 함께 써야
SSO를 붙이면 로그인 화면 수가 줄어드는 데서 그치지 않고, '이 사람이 누구인가'를 판단하는 권한이 각 서비스에서 하나의 신원공급자(IdP)로 옮겨갑니다. 그룹웨어도 인사시스템도 영업 툴도 더 이상 자기 비밀번호를 검증하지 않고, IdP가 서명해 보낸 인증 토큰을 믿고 문을 열어줍니다. 그래서 실제 프로젝트 작업량은 화면 연동보다 '누구에게 어떤 권한을 줄 것인가'를 한곳에서 정리하는 계정·권한 설계 쪽에 몰립니다.
방식은 용도로 갈립니다. 사내 웹 시스템과 기업용 SaaS는 SAML 2.0, 모바일 앱과 클라우드 API는 OAuth 2.0 기반의 OIDC, 윈도우 AD 도메인 내부는 케르베로스를 씁니다. 구글·카카오 로그인은 소비자용 OIDC 활용 사례일 뿐 기업 SSO와 같은 물건이 아니고, 브라우저 자동 입력이나 패스워드 매니저는 아이디·비밀번호를 대신 넣어줄 뿐 인증 주체가 바뀌지 않으므로 SSO가 아닙니다. 계정 생성·삭제까지 자동으로 흐르게 하려면 SCIM 같은 프로비저닝 규격을 따로 얹어야 합니다.
현장에서 가장 자주 어긋나는 지점은 '퇴사자 계정을 껐으니 끝'이라는 오해입니다. IdP에서 계정을 비활성화해도 이미 발급된 액세스 토큰과 각 서비스의 자체 세션은 살아 있어, 설정에 따라 수십 분에서 수 시간 동안 문서 다운로드가 가능합니다. 로그아웃도 마찬가지라 포털에서 나갔다고 각 서비스가 함께 끊기지 않으며, 단일 로그아웃(SLO)을 별도로 켜야 합니다. IdP는 단일 실패 지점이어서 그쪽이 멈추면 전 직원이 어느 시스템에도 못 들어가고, 2FA 없이 SSO만 붙이면 계정 하나가 뚫렸을 때 피해 범위가 오히려 넓어집니다. SAML을 지원하지 않는 구형 시스템은 끝내 별도 ID로 남는다는 점도 처음부터 계산에 넣는 게 안전합니다.
기업 내 다수 시스템 접근 관리의 필요에서 발전했으며, 클라우드 서비스 확산과 함께 표준 인증 방식이 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 320명 규모의 의료기기 유통사 A사는 최근 3년 사이 쓰는 SaaS가 14개로 늘었습니다. 서비스마다 비밀번호를 따로 쓰다 보니 초기화 문의가 월 68건씩 정보팀으로 몰렸고, 퇴사자 계정이 두 달 넘게 살아 있던 사실이 내부 감사에서 지적됐습니다. 경영진은 3개월 안에 SSO를 도입하라고 지시했습니다.
- 정보보안팀장이 3개월치 헬프데스크 티켓을 뽑아 "비밀번호 초기화가 월 68건, 1건당 평균 12분씩 잡아먹는다"고 경영회의에서 보고하며 과제가 시작됐습니다.
- IT운영 담당자가 14개 SaaS 중 SAML 2.0을 지원하는 9개를 1차 연동 대상으로 잡고, 미지원인 구형 재고관리 시스템 2개는 "이번엔 안 됩니다"라고 범위에서 잘라냈습니다.
- 인사팀 과장과 보안팀이 부서·직급 기준 권한 그룹을 31개에서 11개로 줄이고, 입사 등록만 하면 SCIM으로 계정이 자동 생성되도록 인사시스템을 IdP에 연결했습니다.
- 파일럿 2주 차에 영업팀에서 "포털은 로그아웃했는데 CRM은 그대로 열려 있다"는 제보가 올라와, 단일 로그아웃(SLO)과 30분 세션 만료를 급히 설정에 추가했습니다.
- 전 직원 320명에게 MFA를 의무화하되 사내 IP와 등록 단말에서는 재인증을 12시간 유예해, "하루에 몇 번씩 코드 넣는 건 못 하겠다"던 현장 반발을 가라앉혔습니다.
- 도입 3개월 뒤 비밀번호 초기화 문의는 월 68건에서 9건으로 줄었고, 퇴사자 계정 회수는 평균 6일에서 퇴사 당일 처리로 바뀌었습니다.