직원이 App 을 필요로 할때마다 액세스 요청을 수동으로 관리한다고 상상해 보세요. 이러한 프로세스는 생산성을 크게 저해할 뿐만 아니라 큰 보안 위험(특히 퇴사자)을 초래합니다.
...
사용자에게 원활한 액세스를 보장하는 것은 생산성 측면과, 보안 측면에서 매우 중요합니다. 이 문서는 Atlassian 한국 고객이 어떻게 IdP 를 사용하여 효과적으로 사용자 엑세스 요청을 관리할지에 대한 적절한 가이드를 제공하는 것을 목적으로 합니다.
요약
Atlassian 의 한국 고객 분석에 따르면 한국 고객은 문서와 지식에 대해 좀 더 엄격한 접근 권한 정책을 부여하여 관리하는 것을 선호하는 편입니다. 즉 Confluence 스페이스나 개별 페이지, 또는 Jira 프로젝트나 이슈 필터등은 공개로 사용하는 경우도 많지만 팀이나 본부 단위로 접근 권한을 부여하여 관리하는 경우도 많이 있습니다.
이는 회사의 문화, 업무 프로세스, 보안 정책등에 따라 달라질 수 있으며 딱히 정답이 있는게 아니므로 Atlassian 은 고객사의 이런 문화와 프로세스를 존중하며 이를 최대한 지원할 수 있도록 노력하고 있습니다.
Atlassian Guard 의 제약
Atlassian Guard 는 초기 설계상 특성으로 인해 한국 고객들의 조직 변경 및 컨텐츠 접근 제어를 제대로 반영하지 않은 부분으로 인해 기반이 되는 프로토콜인 SCIM(System for Cross-domain Identity Management) 1.1 표준에 group rename 이 정의되어 있지 않는 문제가 있습니다.
현재 SCIM v1.1 을 구현한 Guard 에서도 group rename 을 지원하지 못하며 이로 인해 다음과 같은 제약이 있습니다.
IdP 를 통해 사용자 그룹을 프로비저닝한 경우 IdP 내의 그룹 명이 변경되도 Atlassian Cloud 에는 반영되지 않음(관련 이슈 - ACCESS-800)
SCIM v2 에서는 group rename 이 정의되어 있으며 현재 Guard 제품팀은 v2 를 지원하도록 개발중입니다. 이를 해결하기 위한 티켓이 ACCESS-800 이며 자세한 진행 상황은 이 티켓을 통해서 업데이트 되고 있습니다.
Tip
group renaming 지원은 Atlassian Cloud SCIM 아키텍처의 큰 수정이 필요하므로 현재 완료 예정일은 25년 말이나 26년입니다. 이 기능을 기다리는 많은 고객들에게는 너무 늦게 전달되는 것일수 있으므로 중간에 workaround 로 API 를 통해서 group renaming 을 지원할 수 있도록 제공할 예정이며 이 기능은 25년 반기에 전달 예정입니다.
이 제약은 한국 고객들이 조직 개편을 수행하여 조직 구성과 조직명이 변경되었을 때 IdP 내에 조직명을 변경해도 Atlassian Cloud 에 반영되지 않는 문제를 낳으며 결과적으로 다음과 같은 심각한 사이드 이펙트를 초래합니다.
Confluence 스페이스 및 페이지별 접근 권한 수정 필요
Confluence 스페이스, 페이지에 그룹명으로 접근 권한을 부여했을 경우 이를 변경된 조직명으로 다시 권한 할당 변경이 필요합니다., 즉 “플랫폼 개발” 팀이 “인프라 개발” 팀으로 조직명이 변경되었을 경우 “플랫폼 개발” 그룹으로 권한 부여된 페이지에 대해 “플랫폼 개발” 그룹을 삭제하고 “인프라 개발” 그룹을 일일이 할당해야 합니다.
Note
현재 접근 제한이 걸려 있는 페이지 전체 목록을 가져올 수 있는 Admin 기능이나 API 가 없으며 스페이스별로 일일이 확인해야 합니다.
Scroll title
title
Confluence 의 페이지 접근 권한 설정 예
...
Tip
이런 Guard 의 제약하에서 조직 개편으로 인한 컨텐츠 접근 권한 재설정을 최소화하기 위해 아래와 같은 프로비저닝 방식을 제안합니다.
