목적
직원이 App 을 필요로 할때마다 액세스 요청을 수동으로 관리한다고 상상해 보세요. 이러한 프로세스는 생산성을 크게 저해할 뿐만 아니라 큰 보안 위험(특히 퇴사자)을 초래합니다.
Atlassian Cloud 관리자가 ID 공급자(IdP; Identity Provider) 를 통해 사용자 프로비저닝을 자동화하면 팀이 불필요한 지연 없이 필요한 도구(Confluence/Jira/Jira Service Management) 에 액세스할 수 있습니다.
사용자에게 원활한 액세스를 보장하는 것은 생산성 측면과, 보안 측면에서 매우 중요합니다. 이 문서는 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 이며 자세한 진행 상황은 이 티켓을 통해서 업데이트 되고 있습니다.
이 제약은 한국 고객들이 조직 개편을 수행하여 조직 구성과 조직명이 변경되었을 때 IdP 내에 조직명을 변경해도 Atlassian Cloud 에 반영되지 않는 문제를 낳으며 결과적으로 다음과 같은 심각한 사이드 이펙트를 초래합니다.
Confluence 스페이스 및 페이지별 접근 권한 수정 필요
Confluence 스페이스, 페이지에 그룹명으로 접근 권한을 부여했을 경우 이를 변경된 조직명으로 다시 권한 할당 변경이 필요합니다., 즉 “플랫폼 개발” 팀이 “인프라 개발” 팀으로 조직명이 변경되었을 경우 “플랫폼 개발” 그룹으로 권한 부여된 페이지에 대해 “플랫폼 개발” 그룹을 삭제하고 “인프라 개발” 그룹을 일일이 할당해야 합니다.
현재 접근 제한이 걸려 있는 페이지 전체 목록을 가져올 수 있는 Admin 기능이나 API 가 없으며 스페이스별로 일일이 확인해야 합니다.
Jira 프로젝트 및 이슈 접근 권한 수정
Jira 는 수많은 권한이 있으므로 Confluence 보다 더 많은 권한 변경 작업이 이루어져야 합니다.
예로 프로젝트 권한, 이슈 필터, 워크 플로우, 로드맵등 다양한 접근 권한을 수정해야 하며 이와 관련된 의존성의 목록은 ID-8092 에서 확인할 수 있습니다.
이런 Guard 의 제약하에서 조직 개편으로 인한 컨텐츠 접근 권한 재설정을 최소화하기 위해 아래와 같은 프로비저닝 방식을 제안합니다.
이 가이드는 ACCESS-800 가 구현될때까지 유효합니다.
DO IdP 를 통해 계정과 접근 권한 그룹을 프로비저닝
IdP 를 사용자의 계정 정보의 단일 진실 공급원 (Single Source Of Truth)으로 사용하며 Atlassian 제품을 사용하는 모든 계정은 IdP 통해서 프로비저닝하고 매뉴얼로 계정을 관리하지 않습니다.
제품 접근을 위한 정보는 그룹 단위로 관리하여 그룹 명명을 위한 규칙을 부여합니다. 예로 제품명-users-instance이름 형식으로 명명할 수 있으며 jira-users-korea-se-demo-1 그룹명은 “korea-se-demo-1” 라는 인스턴스내 Jira 에 접근할 수 있는 사용자들의 그룹을 의미하며 confluence-users-korea-se-demo-1 는“korea-se-demo-1” 라는 인스턴스내 Confluence 사용자들의 그룹을 의미합니다.
그룹 생성을 마쳤으면 해당 그룹 설정에서 접근을 허용할 제품을 설정해 줍니다.
한 조직안에 여러 제품이 있는 경우(예: Enterprise plan 사용)에도 위와 같은 그룹 네이밍 규칙을 적용하면 문제없이 프로비저닝을 할 수 있습니다.
DO 접근 권한과 관련되지 않은 그룹명은 프로비저닝하지 않음
IdP 를 통해서 사용자의 계정 정보의 단일 진실 공급원 (Single Source Of Truth)으로 사용하나 접근 권한과 관련되지 않은 그룹 정보(예: 팀명, 본부명등) 는 프로비저닝하지 않습니다.
그리고 사용자가 속한 조직 정보는 Atlassian Cloud 의 internal(local) directory 에 매뉴얼로 추가하며 사용자의 소속 팀 정보도 IdP 가 아닌 local directory 를 통해 관리합니다.
.png?version=1&modificationDate=1729845919479&cacheVersion=1&api=v2&width=728&height=603)
DO NOT IdP 를 통해 계정과 그룹 모든 접근 요청을 프로비저닝
이는 IdP 를 사용할 때 유용하고 권장되는 방법이지만 컨텐츠의 접근 권한을 많이 사용하는 조직일 경우 위에서 설명한 조직 개편후 수작업으로 컨텐츠 접근 권한을 부여해야 하는 문제가 발생하므로 추천하지 않습니다.
DO 조직 개편시 local group rename 기능을 이용하여 변경 정보 반영
24년 7월부터 조직 관리자(Org admin) 는 local group 에 대해 rename 을 수행할 수 있습니다. (관련 블로그 게시글)
이 기능을 사용하면 조직 개편이 발생해서 팀명이 변경될 경우 Admin Hub 에서 그룹 이름을 변경하면 Confluence 와 Jira 의 접근 권한도 같이 반영이 됩니다. (Jira 의 Assets 등 일부 기능은 수작업 필요)
The Organizations REST API 를 사용하면 그룹 생성/삭제 및 사용자를 그룹에 할당/해제하는 업무를 자동화할 수 있습니다.(현재 그룹 이름 변경은 미지원)
User provisioning REST API 는 IdP 와 연동했을 경우에만 사용 가능하며 local group 관리에는 사용할 수 없습니다.
DO 여러 인스턴스가 있을 경우 ‘User access admin’ 을 통해 그룹 및 인스턴스 접근 권한 관리
Atlassian Cloud 에는 여러 관리자 역할이 있으며 Org admin 은 모든 권한을 갖고 있습니다.
Enterprise plan 을 사용해서 여러 인스턴스가 있을 경우 Org admin 이 사용자 접근 권한 부여나 그룹 생성/변경등을 하는 것은 매우 번거로운 작업이며 거버넌스 측면에서 추천하는 방법이 아닙니다.
대신 인스턴스 관리자가 자율적으로 운영할 수 있도록 책임을 위임하는 것을 권장하며 인스턴스 관리자에게 ‘user access admin’ 권한을 부여하는 것이 좋습니다.
권한 부여 방법
Directory → Users 에서 권한을 부여할 사용자를 선택한 후에 ‘Product roles’ 에서 ‘User access admin’ 을 부여하면 됩니다.
‘user access admin’ 는 admin.atlassian.com 에 접속하여 사용자 초대나 그룹 생성/그룹명 변경을 할수 있으며 개별 프로덕트의 접근 여부를 허용할 수 있으므로 각 인스턴스 관리자가 자율적으로 운영할 수 있습니다.
소개
Atlassian Guard(구 Access) 란
Guard 는 Atlassian Cloud 를 위한 보안 제품으로 dP 와 연동한 사용자 프로비저닝, SSO(Single Sign On), 모바일 앱 정책등 여러 가지 보안 기능을 사용할 수 있습니다.
Guard 에 대한 자세한 정보는 Guard 홈페이지 에서 확인할 수 있습니다.
Atlassian Organization 이란
Atlassian Cloud 에서 조직(Organization)은 Atlassian 관리자가 회사가 사용하는 전자 메일 주소(예: @http://atlassian.com )를 사용하는 모든 Atlassian 계정(예: dev@atlassian.com, user1@atlassian.com, etc…)을 확인하고 제어할 수 있는 기능을 제공하는 관리 계층입니다.
이는 모든 사용자와 콘텐츠를 중앙 집중식으로 관리할 수 있는 아틀라시안 클라우드 계층의 최상위 계층으로 모든 Atlassian 사이트 및 제품은 하나의 조직에 포함됩니다.
관리자는 Atlassian Cloud 의 관리자 허브인 admin.atlassian.com 에서 소속 회사의 조직에 액세스하고 소유한 제품과 사이트 목록을 확인할 수 있습니다.
Domain Claim 이란
조직 관리자는 회사 도메인(예: ACME.com)의 소유를 증명하면 해당 도메인에 기반한 이메일 주소를 사용하는 모든 Atlassian 사용자 계정을 중앙에서 관리할 수 있으며 이 프로세스를 도메인 검증(domain verification) 이라고 부릅니다.
도메인 검증은 HTTPS, DNS 의 TXT 레코드, Google Workspace 등의 방법으로 확인할 수 있습니다.
Guard 의 제약 사항
현재 Guard 의 제약 사항과 임시 해결책에 대해서 설명합니다.
보통 Azure AD 의 제약으로 인한 Nested group 미지원
Atlassian 이 자체 개발한 “Azure AD Sync” 기능을 활용하면 nested group 을 flattening 하므로 대체 가능하지만 이 기능도 마찬가지로 IdP 내 그룹 이름을 변경했을 경우 반영되지 않습니다.
보통다중 Azure AD 연결시 하나의 Azure AD 만 nested group 지원
여러 개의 Entra ID 를 연결할 때 하나의 Entra ID 만 netsted group sync 를 사용할 수 있으며 자세한 내용은 아래 링크에서 확인할 수 있습니다.
중요 IdP 를 통한 group renaming 미지원
현재 IdP 를 통해 provisioning 했을 경우 group rename 을 지원하지 않습니다.
Ref
TSC 팀의 Jarrod 작성 문서
Composable API
New Atlas ticket to provide interim solution for ID-800