메인 콘텐츠로 건너뛰기
사용자가 SAML SSO를 통해 로그인하면 EK는 SAML 메타데이터 속성(예: department, group 또는 role)을 받습니다. 접근 제어 기능은 이러한 속성을 사용하여 사용자가 애플리케이션에 접근할 수 있는지 여부를 결정합니다.
접근 제어와 자동 팀 관리는 독립적인 기능이지만 일반적으로 함께 사용됩니다. 동반 가이드는 자동 팀 및 프로젝트 할당을 참조하세요.

​
전제 조건

접근 제어를 활성화하기 전에:
  • SAML SSO가 구성되어 로그인 시 메타데이터 속성이 전송되고 있어야 합니다
  • SAML assertion에는 일치시킬 안정적인 속성이 포함되어 있어야 합니다
제한을 활성화하기 전에 성공적인 SSO 로그인 몇 건에서 속성 이름과 값을 확인하세요. 슈퍼 관리자 사용자 뷰는 각 SAML 사용자에 대해 저장된 SAML 메타데이터를 보여줍니다 — 규칙을 작성할 때 이 사실을 출처로 사용하세요.

​
접근 모드

슈퍼 관리자 → 보안 및 접근 → 접근 제어로 이동하여 모드를 선택합니다. 접근 모드 선택
모드동작
모든 새 사용자 허용기본값. 이메일/비밀번호, Google OAuth, SSO 가입이 모두 허용됩니다.
SAML 메타데이터로 제한SAML 속성이 하나 이상의 구성된 규칙과 일치하는 SSO 사용자만 허용됩니다.

​
규칙 일치 작동 방식

규칙은 속성 이름과 하나 이상의 속성 값으로 정의됩니다. SAML 접근 규칙

​
개념 모델: 모든 것은 집합

규칙과 들어오는 사용자 속성은 모두 토큰 집합으로 축소되고 부분 집합 의미로 비교됩니다:
  • 규칙의 필수 토큰이 사용자의 토큰의 부분 집합일 때 규칙이 일치
  • 규칙 간 로직은 OR — 단일 규칙 일치만으로도 접근이 부여됨
  • 모든 비교는 대소문자 구분 없음이며 앞뒤 공백을 무시

​
다중 토큰 규칙(규칙 내 AND)

속성 값(s) 필드의 쉼표는 토큰 구분자입니다. UI는 각 쉼표로 구분된 항목을 칩으로 승격합니다; 규칙은 나열된 모든 토큰이 존재할 것을 요구합니다.
  • engineering — 하나의 토큰이 필요: 사용자의 속성에 engineering이 포함되어야 합니다
  • Accounting, US — 두 개의 토큰이 필요: 사용자의 속성에 accounting과 us가 모두 포함되어야 합니다

​
다양한 SAML 전송 형태 처리

SAML 속성은 두 가지 형태로 올 수 있습니다: 네이티브 다중 값 — IdP가 하나의 <Attribute> 안에 여러 <AttributeValue> 요소를 보냅니다: 
<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>
EK는 이를 항상 집합으로 처리합니다. 추가 구성이 필요 없습니다. 이는 선호되는 형태입니다. CSV 패킹 단일 값 — IdP가 쉼표로 구분된 토큰을 포함하는 하나의 <AttributeValue>를 보냅니다: 
<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>
이는 모호합니다(두 그룹인가, 아니면 쉼표를 포함하는 리터럴 값인가?). 규칙별 토글을 사용하여 해결합니다:
토글: “IdP가 다중 값을 하나의 문자열로 패킹”동작
꺼짐 (기본값)사용자의 문자열은 하나의 리터럴 토큰으로 처리됨
켜짐사용자의 문자열이 쉼표로 분할되고 집합으로 일치됨
이 토글은 사용자의 속성이 어떻게 해석되는지에만 영향을 미칩니다. 규칙 측의 쉼표는 관계없이 항상 토큰 구분자입니다.

​
일치 동작 매트릭스

사용자 속성(전송 형태)토글규칙 값일치?
네이티브 ["A","B","C"]꺼짐A✓
네이티브 ["A","B","C"]꺼짐A, B✓
단일 "A,B,C"꺼짐A✗
단일 "A,B,C"꺼짐A, B✗
단일 "A,B,C"켜짐A✓
단일 "A,B,C"켜짐A, B✓
단일 "A"꺼짐A✓

​
제한 모드 활성화 시 동작

  • 새 이메일/비밀번호 등록
  • 새 Google OAuth 등록
  • SAML 속성이 어떤 규칙과도 일치하지 않는 새 SSO 사용자
  • 하나 이상의 규칙과 일치하는 기존 SSO 사용자(매 로그인 시 다시 확인)
  • 기존 계정에 로그인하는 기존 로컬 사용자
  • 일치하는 규칙이 없더라도 SSO를 통한 슈퍼 관리자 계정(의도적인 비상 접근)
  • 슈퍼 관리자가 소유하거나 연결된 사용자 행이 없는 프로젝트 수준 API 키
SAML 바인딩 사용자의 API 키 요청도 제한 모드에서 게이팅됩니다. EK는 API 접근을 허용하기 전에 사용자의 마지막 SSO 로그인에서 가져온 저장된 SAML 메타데이터를 접근 규칙과 확인합니다.
열린 상태 동작: 제한 모드가 켜져 있지만 SAML 접근 규칙이 없으면 EK는 모든 SSO 사용자를 허용합니다. 이는 우발적인 잠금을 방지하지만, 엄격한 거버넌스를 활성화하기 전에 적어도 하나의 규칙을 정의해야 합니다.

​
접근 제어 구성

1

접근 제어 열기

슈퍼 관리자 → 보안 및 접근 → 접근 제어로 이동합니다.
2

제한 모드 선택

SAML 메타데이터로 제한을 선택합니다.
3

SAML 접근 규칙 추가

SAML 접근 규칙 아래에 하나 이상의 규칙을 추가합니다. 예:
department = engineering
memberOf = ekb-users
memberOf = ekb-users, us   (둘 다 필요)
사용자 측 속성이 단일 쉼표 구분 문자열로 오는 경우 IdP가 다중 값을 하나의 문자열로 패킹 토글을 켭니다.
4

저장 및 확인

규칙을 저장하고 대규모 배포 전에 대표적인 SSO 계정으로 테스트합니다.

​
권장 배포 접근 방식

  1. 모드가 모든 새 사용자 허용으로 설정된 상태에서 규칙을 만듭니다
  2. 슈퍼 관리자 사용자 뷰에서 파일럿 SSO 계정의 저장된 SAML 메타데이터를 확인하여 검증합니다
  3. SAML 메타데이터로 제한으로 전환합니다
  4. 로그인 및 접근 거부 결과를 모니터링합니다

​
테스트 체크리스트

구성 후 각 시나리오를 확인합니다:
  • 허용되어야 하는 SSO 사용자가 로그인할 수 있는지
  • 허용되지 말아야 하는 SSO 사용자가 접근 거부 화면으로 리다이렉션되는지
  • 거부된 사용자가 예상된 접근 거부 경험을 보이는지
  • 정책 이탈을 방지하기 위해 적어도 하나의 유효한 규칙이 활성화되어 있는지

​
문제 해결

  • 접근 모드가 의도하지 않게 제한으로 설정되어 있지 않은지 확인
  • 규칙이 올바른 속성 이름과 정확히 예상되는 값을 사용하는지 확인
  • IdP가 해당 사용자에 대해 해당 속성을 전송하고 있는지 확인
  • 다중 토큰 규칙의 경우 나열된 모든 토큰이 사용자 속성에 포함되어 있어야 합니다 — 슈퍼 관리자 사용자 뷰에서 저장된 SAML 메타데이터를 확인하세요
  • 속성이 CSV 패킹 단일 문자열로 오는 경우 규칙에서 IdP가 다중 값을 하나의 문자열로 패킹이 활성화되어 있는지 확인
  • 제한 모드가 활성화된 상태에서 사용자가 이메일/비밀번호 또는 Google OAuth 로그인을 시도하고 있는지 확인
슈퍼 관리자 계정은 일치하는 규칙이 없더라도 SSO를 통해 항상 허용됩니다. 잠긴 경우 슈퍼 관리자 계정을 사용하여 SSO로 로그인하여 접근을 회복하세요.

​
운영 가이드

  • 접근 규칙을 보안 민감한 구성으로 취급
  • 프로덕션 업데이트에 변경 관리 프로세스 사용
  • IdP 클레임 변경 후 재테스트(예: CSV 패킹에서 네이티브 다중 값으로 전환하거나 클레임 이름 변경)
  • 정기적으로 규칙을 검토하고 오래된 매핑을 제거
  • 새로운 규칙을 작성하기 전에 슈퍼 관리자 사용자 뷰에서 저장된 SAML 메타데이터를 확인