자동 관리

사용자가 SAML SSO를 통해 로그인하면 엔터프라이즈 지식이 메타데이터 속성을 평가하여 팀에 자동으로 할당하고, 선택적으로 해당 팀의 모든 프로젝트에 적절한 역할과 함께 할당할 수 있습니다.

참고

자동 관리와 접근 제어는 독립적인 기능이지만 일반적으로 함께 사용됩니다. 동반 가이드는 SAML 접근 제어를 참조하세요.

전제 조건

자동 관리를 활성화하기 전에:

• SAML SSO가 구성되어 로그인 시 메타데이터 속성을 전송하고 있어야 합니다
• SAML assertion에는 일치시킬 안정적인 속성이 포함되어 있어야 합니다
• 대상 팀이 이미 EK에 존재해야 합니다. 팀 만들기에 대한 지침은 팀 관리를 참조하세요

팁

자동화를 활성화하기 전에 성공적인 SSO 로그인 몇 건에서 속성 이름과 값을 확인하세요. 슈퍼 관리자 사용자 뷰는 각 SSO 사용자에 대해 저장된 SAML 메타데이터를 보여줍니다 — 규칙을 작성할 때 이 사실을 출처로 사용하세요.

규칙 구조

슈퍼 관리자 → 사용자 및 워크스페이스 → 팀 → 자동 관리로 이동하여 규칙을 구성합니다. 각 규칙에는 다음이 포함됩니다:

필드	필수	설명
SAML 속성 이름	예	SAML assertion의 속성 키
속성 값(s)	예	하나 이상의 쉼표 구분 토큰 — 나열된 모든 토큰이 일치해야 함(AND 로직)
대상 팀	예	사용자를 할당할 팀
기본 팀 멤버십 역할	선택 사항	구성원(기본값) 또는 관리자
팀 프로젝트에 자동 추가	선택 사항	팀의 모든 비기본 프로젝트에 사용자 추가
기본 프로젝트 역할	선택 사항	관리자, 편집자 또는 보기 전용
강제 연속 팀 재할당	선택 사항	첫 로그인이 아닌 매 로그인 시 사용자 이동

규칙은 또한 다음을 포함할 수 있습니다:

• 조건부 팀 역할 재정의 — 추가 SAML 속성에 따라 팀 멤버십 역할 변경
• 조건부 프로젝트 역할 재정의 — 추가 SAML 속성에 따라 프로젝트 역할 변경(자동 추가가 켜져 있을 때만 적용)

규칙 일치 작동 방식

속성 일치는 접근 제어와 동일한 엔진을 사용합니다. 규칙과 사용자 속성은 모두 토큰 집합으로 처리되고 부분 집합 의미로 비교됩니다 — 규칙의 필수 토큰이 사용자의 토큰의 부분 집합일 때 규칙이 일치합니다.

• 속성 값(s)의 쉼표는 토큰 구분자입니다. Accounting, US는 사용자가 둘 다 토큰을 갖기를 요구합니다(하나의 규칙 내 AND 로직).
• 특이성은 규칙이 요구하는 토큰 수와 같습니다. 여러 규칙이 일치하면 가장 특이적인(가장 많은 토큰) 것이 우선합니다.

경고

동일한 특이성의 규칙 간에 타이 브레이커가 없습니다. 두 규칙이 동률이면 EK는 가장 먼저 생성된 것을 선택하고 동률 규칙 ID를 나열하는 WARNING 로그를 생성합니다. 이를 구성 오류로 처리하고 규칙을 재구성하여 겹침을 제거하세요.

다양한 SAML 전송 형태 처리

SAML 속성은 두 가지 형태로 올 수 있으며 각 규칙은 이를 처리하는 토글을 노출합니다:

네이티브 다중 값 — IdP가 여러 <AttributeValue> 요소를 보냅니다. EK는 이를 항상 자동으로 집합으로 처리합니다.

CSV 패킹 단일 값 — IdP가 값을 하나의 쉼표 구분 문자열로 패킹합니다. 규칙별 토글을 사용합니다:

토글: "IdP가 다중 값을 하나의 문자열로 패킹"	동작
꺼짐 (기본값)	사용자의 문자열은 하나의 리터럴 토큰으로 처리됨
케짐	사용자의 문자열이 쉼표로 분할되고 집합으로 일치됨

전체 참고 테이블은 SAML 접근 제어 — 일치 동작 매트릭스를 참조하세요.

팀 할당 동작

각 SSO 로그인 시 EK는 사용자의 SAML 메타데이터에 대해 구성된 규칙을 평가하고 가장 특이적인 일치 규칙을 선택합니다.

사용자 상태	결과
팀이 아직 없음	대상 팀에 할당
이미 대상 팀에 있음	변경 없음
다른 팀에 있음	강제 연속 팀 재할당이 활성화된 경우에만 이동
다중 구성원 팀의 소유자	강제 이동 안 됨(고아 소유권 방지)
팀의 유일한 구성원/소유자	이동됨; 이제 빈 팀은 삭제됨

참고

첫 SSO 온보딩의 경우 올바른 배치를 확립하기 위해 재할당이 항상 강제됩니다.

팀 멤버십 역할

사용자가 팀에 추가되는 역할은 다음 순서로 해결됩니다:

1. 조건부 팀 역할 재정의 — 사용자의 토큰 부분 집합 일치를 갖는 일치 규칙의 가장 특이적인 재정의
2. 기본 팀 멤버십 역할 — 규칙에 구성된 구성원 또는 관리자(레거시 기본값: 구성원)

정보

팀 역할은 추가 시에만 적용됩니다. 사용자가 이미 대상 팀에 있는 경우 기존 역할이 유지됩니다 — 후속 로그인은 이를 변경하지 않습니다. 기존 구성원의 승진이나 강등은 명시적인 관리자 작업이 필요합니다.

조건부 팀 역할 재정의

각 재정의는 속성 이름, 속성 값(s), 선택적 is_csv_value 토글 및 팀 역할(구성원 또는 관리자)을 지정합니다. 가장 특이적인 일치 재정의가 우선합니다; 동률은 경고를 로깅합니다.

프로젝트에 자동 추가

규칙에서 팀 프로젝트에 자동 추가가 활성화되면 EK는 대상 팀의 비기본 프로젝트에 사용자를 추가합니다. 사용자는 이미 멤버인 프로젝트에만 추가됩니다.

역할 할당 우선순위:

1. 일치하는 조건부 프로젝트 역할 재정의 (가장 특이적인 일치)
2. 팀 규칙에 정의된 기본 프로젝트 역할

참고

프로젝트 할당은 비동기적으로 실행됩니다. 팀 멤버십이 모든 프로젝트 멤버십 완료 전에 나타날 수 있습니다.

정보

프로젝트 역할은 추가 시에만 적용됩니다. 기존 프로젝트 멤버십은 후속 로그인에서 다시 평가되거나 변경되지 않습니다.

조건부 프로젝트 역할 재정의

역할 재정의를 통해 추가 SAML 속성에 따라 다른 프로젝트 역할을 할당할 수 있습니다.

예시:

• 팀 규칙: department = engineering, 기본 역할 → 보기 전용
• 역할 재정의: level = manager → 관리자

결과:

• 모든 engineering 사용자가 팀에 추가됨
• level = manager를 갖는 사용자는 자동 추가된 프로젝트에서 관리자를 받음
• 관리자가 아닌 사용자는 보기 전용 유지

참고

여러 조건부 역할 재정의가 동일한 사용자와 일치할 수 있는 경우 가장 특이적인(가장 많은 토큰) 것이 우선합니다. 동률은 경고를 로깅하고 가장 먼저 생성된 재정의로 대체됩니다 — 동률을 피하기 위해 재정의를 재구성하세요.

팀 재할당 제한

슈퍼 관리자 → 팀 → 자동 관리 → 팀 재할당 제한에서 찾을 수 있는 이 설정은 사용자가 팀 간에 이동할 때 프로젝트 멤버십에 무슨 일이 일어나는지를 제어합니다. 세 설정 모두 기본적으로 꺼짐(비파괴적)입니다.

설정	설명
1. 이전 팀의 프로젝트에서 사용자 제거	마스터 스위치. 재할당 시 이전 프로젝트 멤버십을 제거합니다.
2. 사용자가 소유한 프로젝트가 따라감	설정 1에 의존. 소유 프로젝트가 새 팀으로 이동합니다.
3. 따라가는 프로젝트에서 이전 팀 구성원 제거	설정 1과 2에 의존. 이동된 프로젝트에서 이전 팀 접근을 정리합니다.

실제로:

• 설정 1만 — 사용자가 이전 팀의 프로젝트에서 제거됨; 소유 프로젝트는 이전 팀에 남고 소유권은 이전 팀의 소유자에게 양도됨
• 설정 1 + 2 — 사용자가 소유한 프로젝트가 새 팀으로 이동; 해당 프로젝트의 기존 구성원은 유지됨
• 설정 1 + 2 + 3 — 이전 팀 구성원도 소유자와 함께 이동된 프로젝트에서 제거됨

경고

재할당 중 소유권을 안전하게 양도할 수 없는 경우 EK는 깨진 소유권 상태를 방지하기 위해 안전장치를 적용합니다.

자동 관리 규칙 구성

1. 자동 관리 열기

   슈퍼 관리자 → 사용자 및 워크스페이스 → 팀 → 자동 관리로 이동하여 규칙 추가를 클릭합니다.

2. SAML 일치 기준 입력

   SAML 속성 이름, 속성 값(s) 및 대상 팀을 제공합니다.

   다중 토큰 규칙의 경우 각 토큰을 입력하고 쉼표를 눌러 칩을 만듭니다(예: accounting + us로 둘 다 요구). 필요한 경우 IdP가 다중 값을 하나의 문자열로 패킹을 토글합니다.

   

3. 팀 멤버십 역할 설정

   기본 팀 멤버십 역할(구성원 또는 관리자)을 선택하고 추가 속성에 따라 다른 팀 역할을 받아야 하는 사용자를 위한 조건부 팀 역할 재정의를 선택적으로 추가합니다.

4. 선택적 설정 구성

   팀 프로젝트에 자동 추가 및/또는 강제 연속 팀 재할당을 활성화할지 결정합니다.

5. 프로젝트 역할 설정(자동 추가가 활성화된 경우)

   기본 프로젝트 역할을 선택하고 선택적으로 조건부 프로젝트 역할 재정의를 추가합니다.

6. 저장 및 재할당 제한 구성

   규칙을 저장한 다음 선택적으로 팀 재할당 제한을 구성하여 사용자가 팀을 변경할 때의 동작을 정의합니다.

7. 테스트

   프로덕션에서 활성화하기 전에 각 예상 메타데이터 패턴을 나타내는 실제 SSO 사용자로 테스트합니다.

규칙 설계 모범 사례

• 안정적인 ID 제공자 속성을 사용 — 불안정하거나 자주 변경되는 값을 피합니다
• 속성 이름을 정확한 SAML 클레임 이름과 일관되게 유지합니다(일부 IdP에서 클레임 수준에서 대소문자 구분)
• IdP가 지원하는 경우 네이티브 다중 값 SAML 속성을 선호합니다 — 모호하지 않으며 is_csv_value 토글이 필요하지 않습니다
• 동일한 특이성에서 겹치는 규칙을 피합니다 — "모호한 일치" 경고가 보이면 더 많은 토큰을 추가하여 엄격하게 더 특이적으로 만듭니다
• 최소 권한(구성원 팀 역할, 보기 전용 프로젝트 역할)으로 시작하고 조건부 재정의를 통해 필요한 곳에서만 상승합니다
• 규칙 소유권을 문서화하고 정기적인 검토를 예약합니다

테스트 체크리스트

구성 후 각 시나리오를 확인합니다:

• 허용된 사용자가 올바른 팀 역할과 함께 올바른 팀에 배치되는지
• 조건부 팀 역할 재정의가 올바른 사용자에게 적용되는지
• 프로젝트 자동 추가가 올바른 역할로 완료되는지(비동기 처리에 몇 초 허용)
• 조건부 프로젝트 역할 재정의가 올바른 사용자에게 적용되는지
• 강제 재할당이 예상대로 작동하는지(활성화된 경우)
• 팀 이동 중 재할당 제한 설정이 올바르게 작동하는지

문제 해결

사용자가 로그인했지만 예상 팀에 할당되지 않음

• 일치하는 팀 할당 규칙이 존재하는지 확인
• 대상 팀이 여전히 존재하는지 확인
• 규칙의 속성/값 토큰이 사용자의 실제 SAML 메타데이터의 부분 집합인지 확인(슈퍼 관리자 사용자 뷰에서 확인)
• 사용자가 이미 다른 팀에 속해 있고 이동해야 하는 경우 강제 연속 팀 재할당을 활성화
• 사용자가 다중 구성원 팀의 소유자인 경우 자동으로 이동되지 않습니다 — 이는 의도적인 설계입니다
• 로그에 모호한 일치 경고가 있으면 두 규칙이 동일한 특이성에서 동률; 규칙을 재구성하여 겹침을 제거

사용자가 팀에 할당되었지만 잘못된 팀 역할

• 조건부 팀 역할 재정의가 존재하고 사용자와 일치하는지 확인
• 팀 역할은 추가 시에만 적용됩니다 — 사용자가 재정의가 추가되기 전에 이미 팀에 있었으면 기존 역할이 유지됩니다; 수동으로 승진 또는 강등하세요
• 재정의 간 동률의 경우 로그를 확인하고 의도된 재정의에 더 많은 토큰을 추가하여 엄격하게 더 특이적으로 만드세요

사용자가 팀에 할당되었지만 프로젝트에 없음

• 일치하는 규칙에서 팀 프로젝트에 자동 추가가 활성화되어 있는지 확인
• 팀에 비기본 프로젝트가 있는지 확인
• 유효한 프로젝트 역할(관리자, 편집자 또는 보기 전용)이 설정되어 있는지 확인
• 비동기 백그라운드 처리를 위해 짧은 지연을 허용하세요

역할 재정의가 적용되지 않음

• 역할 재정의가 올바른 팀 할당 규칙에 첨부되어 있는지 확인
• 추가 속성/값이 사용자의 SAML 메타데이터에 실제로 존재하는지 확인
• 기본 역할이 적용되고 있으면 조건부 재정의가 일치하지 않은 것입니다
• 속성이 CSV 패킹 단일 문자열로 오는 경우 재정의에서 IdP가 다중 값을 하나의 문자열로 패킹이 활성화되어 있는지 확인

로그에 '모호한 일치' 경고

동일한 특이성의 두 개 이상의 규칙(또는 재정의)이 동일한 사용자와 일치했습니다. EK는 결정론적으로 가장 먼저 생성된 것을 선택했지만 구성은 취약합니다.

로그 줄에 동률 규칙 ID가 나열됩니다. 하나를 편집하여 더 많은 필수 토큰을 추가하여 엄격하게 더 특이적으로 만들거나 겹침을 완전히 제거하세요.

운영 가이드

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