Microsoft Entra ID SSO로 비밀번호 관리자 도입하기: 2026 가이드

SSO를 나중에 붙이는 것보다 처음부터 SSO인 편이 나은 이유

대부분의 보관함은 비밀번호 기반 계정 체계 위에 SSO를 기업 등급 부가 기능으로 덧붙입니다. 그 순서가 그대로 드러납니다. 사용자는 결국 보관함 비밀번호를 따로 갖게 되고, 관리자 관점의 계정 생애주기는 뒷생각이 되며, SSO 등급에는 추가 요금이 붙습니다. 처음부터 SSO로 설계하면 디렉터리에서 출발합니다. 새로 만들 계정도, 나눠 줄 비밀번호도 없고, 입사자는 자동으로 인식되며, 퇴사자는 Entra ID에서 이미 하고 계신 계정 정지 하나로 끊깁니다. 로그인이 곧 디렉터리 그 자체이므로 조건부 액세스와 MFA 정책도 자동으로 적용됩니다.

어려운 질문 하나: 암호화 키는 어디에 있습니까

SSO는 당신이 누구인지에 답합니다. 무엇을 복호화할 수 있는지에는 답해서는 안 됩니다. Entra ID 로그인만으로 보관함 내용을 읽을 수 있다면, 신원 계층을 통제하거나 침해한 쪽도 읽을 수 있고, 공급업체의 제로 지식 주장은 조용히 죽은 것입니다. 정직한 아키텍처는 두 시스템을 분리해 둡니다. 신원은 디렉터리에서 오고, 복호화 키는 구성원 본인의 기기에서 마스터 비밀번호로부터 유도되며 전송되지 않습니다. Keyvaci는 그렇게 동작하고, 이 분리는 보안 아키텍처 페이지에 전부 문서화되어 있습니다. 어떤 제품을 검토하시든 이 질문을 가장 먼저, 그리고 문서로 물으십시오.

설정은 이렇게 되어야 합니다

1. 관리자가 Microsoft 계정으로 로그인합니다. 조직 생성은 테넌트의 실제 전역 관리자에게만 열려야 하고, 그 사실은 Microsoft가 서명한 토큰으로 확인되어야 합니다. 그래야 회사 이름을 업무용 이메일 하나로 아무나 등록할 수 없습니다.
2. 복구 키트는 클라이언트에서 생성됩니다. 브라우저가 조직의 서명 키와 복구 키를 만들어 한 번만 보여 줍니다. 공급업체는 이를 보지 못하며, 그래서 복구 권한이 저희가 아니라 고객의 손에 남습니다.
3. 구성원은 기존 계정으로 로그인합니다. 각자 마스터 비밀번호를 설정하고, 관리자에게 키 서명을 받고, 보관함을 받기 시작합니다. 에이전트 설치도, 디렉터리 스키마 변경도 없이 표준 OIDC와 PKCE를 씁니다.

관리자 확인 절차의 세부 사항과 테넌트 외부 게스트의 처리를 포함한 전체 흐름은 Entra ID 연동 페이지에 있습니다.

실제 도입에서 얻은 팁

• 테넌트 전체 관리자 동의를 한 번 부여하십시오. 그러면 구성원은 동의 화면을 보지 않습니다.
• 사람을 초대하기 전에 보관함 세 개를 먼저 채우십시오. 금융, 클라우드 계정, 공용 SaaS입니다. 필요한 것이 이미 들어 있는 보관함이라야 사람들이 씁니다.
• 복구 키트는 인쇄해서 그것이 실제로 그러한 마스터 키처럼 보관하십시오. 공급업체가 아무것도 초기화해 줄 수 없다는 점은 약관의 함정이 아니라 기능입니다.
• Google Workspace를 쓰고 계십니까? 지금은 이메일 계정으로 이용하실 수 있고 Google 네이티브 SSO는 로드맵에 있습니다.