목적

...

직원이 App 을 필요로 할때마다 액세스 요청을 수동으로 관리한다고 상상해 보세요. 이러한 프로세스는 생산성을 크게 저해할 뿐만 아니라 큰 보안 위험(특히 퇴사자)을 초래합니다.

Atlassian Cloud 관리자가 ID 공급자(IdP; Identity Provider) 를 통해 사용자 프로비저닝을 자동화하면 팀이 불필요한 지연 없이 필요한 도구(Confluence/Jira/Jira Service Management) 에 액세스할 수 있습니다.

사용자에게 원활한 액세스를 보장하는 것은 생산성 측면과, 보안 측면에서 매우 중요합니다. 이 문서는 Atlassian 한국 고객이 어떻게 IdP 를 사용하여 효과적으로 사용자 엑세스 요청을 관리할지에 대한 적절한 가이드를 제공하는 것을 목적으로 합니다.

요약

그간 경험으로 비추어 볼때 한국 고객은 문서와 지식에 대해 좀 더 엄격한 접근 권한 정책을 부여하여 관리하는 것을 선호하는 편입니다. 즉 Confluence 스페이스나 개별 페이지, 또는 Jira 프로젝트나 이슈 필터등은 공개로 사용하는 경우도 많지만 팀이나 본부 단위로 접근 권한을 부여하여 관리하는 경우도 많이 있습니다.

이는 회사의 문화, 업무 프로세스, 보안 정책등에 따라 달라질 수 있으며 딱히 정답이 있는게 아니므로 Atlassian 은 고객사의 이런 문화와 프로세스를 존중하며 이를 최대한 지원할 수 있도록 노력하고 있습니다.

하지만 Atlasisan Cloud 는 초기 설계상 특징으로 인해 한국 고객들만의 조직 문화등이 제대로 반영하지 않은 부분으로 인해 다음과 같은 제약이 있습니다.

• IdP 를 통해 사용자 그룹을 프로비저닝한 경우 IdP 내의 그룹 명이 변경되도 Atlassian Cloud 에는 반영되지 않음(관련 이슈 - ACCESS-800)

이 제약은 한국 고객들이 조직 개편을 수행하여 조직 구성과 조직명이 변경되었을 때 IdP 내에 조직명을 변경해도 Atlassian Cloud 에 반영되지 않는 문제를 낳으며 결과적으로 다음과 같은 사이드 이펙트를 초래합니다.

Confluence 스페이스 및 페이지별 접근 권한 수정

Confluence 스페이스, 페이지에 그룹명으로 접근 권한을 부여했을 경우 이를 변경된 조직명으로 다시 권한 할당 변경이 필요합니다., 즉 “플랫폼 개발” 팀이 “인프라 개발” 팀으로 조직명이 변경되었을 경우 “플랫폼 개발” 그룹으로 권한 부여된 페이지에 대해 “플랫폼 개발” 그룹을 삭제하고 “인프라 개발” 그룹을 일일이 할당해야 합니다.

Scroll title
title Confluence 의 페이지 접근 권한 설정 예

Jira 프로젝트 및 이슈 접근 권한 수정

Jira 는 수많은 권한이 있으므로 Confluence 보다 더 많은 권한 변경 작업이 이루어져야 합니다.

예로 프로젝트 권한, 이슈 필터, 워크 플로우, 로드맵등 다양한 접근 권한을 수정해야 하며 이와 관련된 의존성의 목록은 ID-8092 에서 확인할 수 있습니다.

Status
colour Green title DO

IdP 를 통해 계정과 그룹, 접근 요청을 프로비저닝

Status
colour Red title DO NOT

IdP 를 통해 계정과 그룹, 접근 요청을 프로비저닝

소개

Atlassian Guard(구 Access) 란

...