회사 시스템에서 가장 당황스러운 알림은 이것이다.

로그인에는 성공했습니다. 하지만 이 리소스에 접근할 수 없습니다.

사용자는 비밀번호도 맞게 입력했다. MFA도 통과했다. 회사 로그인 화면도 정상적으로 지나왔다. 그런데 데이터베이스는 열리지 않고, 서버 접속은 거절되고, 어떤 메뉴는 보이지 않는다.

이때 회의실에는 대개 세 단어가 등장한다. LDAP, SAML, SCIM.

이름만 들으면 셋이 한 팀처럼 보인다. 하지만 이들은 같은 일을 하지 않는다. 오히려 서로 다른 시간대에 다른 문을 지키는 직원에 가깝다.

이 글은 기업 로그인을 네 개의 질문으로 나눠 본다. 이 순서만 기억해도 “로그인은 되는데 안 돼요”라는 말을 훨씬 빨리 번역할 수 있다.

1. 누구인가?             Identity
2. 정말 그 사람인가?     Authentication
3. 무엇을 할 수 있는가?  Authorization
4. 명부가 최신인가?      Provisioning

1. 첫 번째 문: “누구세요?”

아침 출근길을 생각해 보자. 건물에 들어가기 전, 회사는 먼저 내 이름과 부서, 소속 팀을 알아야 한다.

이 정보를 보관하는 대표적인 곳이 LDAP 같은 디렉터리다.

LDAP를 어렵게 생각할 필요는 없다. 회사 전화번호부를 아주 잘 정리해 둔 시스템이라고 보면 된다. 전화번호부에는 이름만 있는 것이 아니다. 이메일, 부서, 직책, 계정 상태, 그리고 어떤 그룹에 속하는지도 적혀 있다.

이름: Mina Kim
이메일: employee@example.test
부서: Engineering
그룹: Platform-Team

LDAP에서 이 카드 한 장을 entry라고 부른다. 카드가 꽂힌 정확한 주소는 DN, 어느 책장부터 찾을지는 Base DN, 카드를 고르는 조건은 Search Filter라고 부른다.

용어가 길어도 하는 일은 익숙하다.

전화번호부를 연다        → Bind
어느 책장을 볼지 정한다   → Base DN
검색어를 입력한다         → Search Filter
찾은 카드를 읽는다        → Attribute

여기서 자주 생기는 첫 번째 오해가 있다.

OU=Finance 아래에 Mina가 있다고 해서, Mina가 곧바로 Finance-Admins 그룹의 멤버라는 뜻은 아니다.

OU는 주소에 가깝고, Group은 명단에 가깝다. 폴더에 파일이 있다고 해서 자동으로 편집 권한까지 생기지는 않는 것과 같다.

그래서 LDAP 연동에서 “조직도에는 있는데 왜 권한이 없죠?”라는 질문은 종종 사실 다른 질문이다.

이 사용자가 어디에 저장되어 있는가가 아니라, 실제로 어떤 그룹 명단에 들어 있는가?

2. 두 번째 문: “정말 본인이 맞나요?”

사용자 정보를 찾았다고 로그인까지 끝난 것은 아니다. 다음은 본인 확인이다.

이 역할을 기업 환경에서는 Identity Provider, 줄여서 IdP가 자주 맡는다. Microsoft Entra ID, Okta, Google Workspace 같은 서비스가 여기에 해당한다.

SAML은 IdP와 업무 시스템이 본인 확인 결과를 주고받는 약속이다.

비유하면 이렇다.

  • LDAP는 사내 전화번호부다.
  • IdP는 사원증을 확인하는 정문 게이트다.
  • SAML은 게이트가 발급하는 “이 사람은 인증했습니다”라는 확인서다.

사용자가 업무 시스템에서 SSO를 누르면 보통 이런 일이 일어난다.

브라우저 → IdP 로그인 화면
IdP      → 비밀번호·MFA로 사용자 인증
IdP      → 서명된 SAML Assertion 발급
브라우저 → Assertion을 업무 시스템에 전달
업무 시스템 → Assertion과 사용자 정보를 검증

여기서 중요한 장면은 마지막 직전이다. SAML Assertion은 흔히 브라우저가 전달한다. IdP가 인증 결과를 만들고, 브라우저가 그 확인서를 들고 업무 시스템의 문으로 돌아오는 셈이다.

그래서 SAML 설정에서 주소가 중요하다. 업무 시스템이 “확인서는 여기로 보내주세요”라고 등록한 주소와, IdP가 실제로 돌려보내는 주소가 한 글자라도 다르면 문 앞에서 멈출 수 있다.

하지만 SAML이 정상이라면 적어도 두 번째 질문에는 답한 것이다.

네, 이 사람은 회사가 인증한 사용자입니다.

그렇다고 아직 모든 문이 열린 것은 아니다.

3. 세 번째 문: “그래서 어디까지 들어갈 수 있나요?”

기업 로그인에서 가장 중요한 구분은 이것이다.

Authentication ≠ Authorization
본인 확인       ≠ 권한 허용

호텔 프런트에서 신분을 확인하고 객실 키를 받았다고 생각해 보자. 그 키로 모든 객실, 직원 전용 창고, 금고실까지 열 수 있는 것은 아니다.

업무 시스템도 마찬가지다. 로그인에 성공한 뒤에는 Role, Policy, Approval, Network Rule 같은 기준이 한 번 더 작동한다.

로그인 성공
  → 사용자 식별
    → 역할 확인
      → 정책 평가
        → 접근 허용 또는 거부

이 단계는 보안의 귀찮은 추가 절차가 아니다. 최소 권한 원칙을 실제로 지키는 핵심 장치다.

예를 들어 데이터 분석가는 운영 DB를 조회할 수 있어도 삭제 권한까지 필요하지 않을 수 있다. 외부 협력사는 특정 기간에만 프로젝트 서버에 접속할 수 있어야 할 수 있다. 관리자는 민감한 컬럼을 마스킹한 화면으로만 볼 수 있어야 할 수 있다.

이런 요구를 “로그인한 사람이니 다 열어 주자”로 해결하면, 로그인 시스템은 편해져도 조직은 위험해진다.

그래서 접근이 거절됐을 때는 SAML부터 다시 붙잡지 않는 편이 좋다. 먼저 다음을 확인해야 한다.

- 올바른 사용자로 식별됐는가?
- 필요한 역할이 할당됐는가?
- 요청 또는 승인 절차가 끝났는가?
- 네트워크 위치·시간·대상 리소스 조건을 만족하는가?

로그인 성공과 접근 거절이 함께 일어나는 것은 모순이 아니다. 각각 다른 문이 제 역할을 한 결과일 수 있다.

4. 네 번째 문: “명부는 최신인가요?”

여기서 SCIM이 등장한다.

SAML이 오늘 문 앞에 선 사람의 사원증을 확인하는 일이라면, SCIM은 회사의 출입 명부 자체를 최신으로 유지하는 일이다.

입사자가 생기고, 부서가 바뀌고, 퇴사자가 비활성화되는 변화는 하루에 한 번만 일어나지 않는다. 이 변경이 업무 시스템마다 수동으로 복사되면 빠지는 곳이 생긴다.

SCIM은 이런 lifecycle 변화를 전달하기 위한 표준이다.

입사       → 계정 생성
부서 이동  → 속성·그룹 변경
퇴사       → 계정 비활성화 또는 제거

여기서 두 번째 오해가 나온다.

SAML을 연결했으니 신규 직원도 자동으로 생기겠지?

항상 그렇지 않다.

SAML의 중심 책임은 로그인 인증이다. 계정을 언제 만들고, 어떤 그룹을 반영하고, 퇴사자를 언제 막을지는 SCIM이나 별도 동기화 정책이 결정한다.

둘은 경쟁 관계가 아니다. 잘 맞물리면 이렇게 역할을 나눈다.

SAML  = 지금 로그인한 사람이 누구인지 확인
SCIM  = 사용자·그룹 명부를 계속 최신으로 유지

이 구분을 알고 나면 “SSO는 되는데 새 직원이 목록에 없어요”라는 문제도 방향이 바뀐다. 로그인 오류가 아니라 프로비저닝 경로를 살펴봐야 한다는 뜻이다.

5. 장애를 네 문으로 나눠 읽는 법

“접근이 안 된다”는 한 문장에는 너무 많은 가능성이 들어 있다. 하지만 네 개의 문으로 나누면 대화가 짧아진다.

문 먼저 확인할 질문 흔한 원인
Identity 시스템이 기대한 사용자를 찾았나? 이메일·로그인 ID 불일치, LDAP 검색 범위 오류
Authentication 본인 인증이 성공했나? MFA 실패, 인증서·SAML 설정 오류
Authorization 이 행동이 허용됐나? Role/Policy 없음, 승인 미완료, 네트워크 조건 불일치
Provisioning 사용자·그룹 상태가 최신인가? SCIM/동기화 지연, 비활성 계정, 그룹 미반영

이 표의 좋은 점은 누군가를 탓하기 전에 문제의 층을 정할 수 있다는 것이다.

“IdP가 문제예요”도, “권한 시스템이 문제예요”도 너무 이르다. 먼저 어느 문에서 멈췄는지 확인해야 한다.

6. 좋은 로그인 경험은 문을 줄이는 일이 아니다

가끔 보안과 사용자 경험을 반대편에 놓는다. 문이 많으면 불편하니 모두 없애자는 식이다.

하지만 좋은 기업 로그인 경험은 문을 무작정 줄이는 일이 아니다. 각 문이 무엇을 확인하는지 사용자가 이해할 수 있게 만드는 일에 가깝다.

  • SSO로 비밀번호 입력 횟수는 줄인다.
  • 역할 기반 권한으로 필요한 사람에게만 필요한 범위를 연다.
  • 승인과 만료로 임시 권한이 영구 권한이 되는 일을 막는다.
  • 자동 동기화로 퇴사자나 이동한 직원의 권한을 오래 남기지 않는다.

결국 좋은 접근 제어는 “누가 무엇에 접근했는가”만 기록하는 데서 끝나지 않는다.

누가, 왜, 언제까지 접근할 수 있는지와 함께
필요 없는 접근과 민감한 정보 노출을 어떻게 막았는지를 설계하는 일이다.

기억할 한 장

다음에 LDAP, SAML, SCIM이 한 회의에서 동시에 등장하면 이 네 줄만 떠올리면 된다.

LDAP  : 누구인지 찾는 전화번호부
SAML  : 본인 인증 결과를 전하는 전자 사원증
Role  : 무엇을 할 수 있는지 정하는 출입 권한표
SCIM  : 사람과 그룹 명부를 최신으로 유지하는 자동 전달

로그인에 성공했는데 접근이 거절됐다면, 시스템이 이상한 게 아닐 수 있다.

오히려 누가 들어왔는지 확인하고, 본인을 인증하고, 필요한 곳에만 열쇠를 주고, 명부를 최신으로 유지하는 네 개의 문이 각자 제대로 일하고 있는지 살펴볼 순간이다.