Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Atlassian Guard 를 사용하기 위해 도메인 인증을 완료했을 경우 인증된 도메인(예: acme.com, acme.co.uk) 에서 계정을 요청하면 해당 계정은 관리되는 계정이 됩니다. 즉 dev@acme.com 이나 hr_manager@acme.comco.uk 계정은 관리되는 계정이 되지만 dev1@gmail dev1@vendor.com 은 회사에서 인증한 도메인이 아니므로 외부 사용자 계정이 됩니다.

Scroll ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-htmltrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue

https://support.atlassian.com/user-management/docs/verify-a-domain-to-manage-accounts/

Scroll title
title도메인 인증후 관리되는 계정과 외부 사용자 계정

image-20241111-122805.png

관리되는 계정은 Guard 에서 제공하는 인증 정책을 강제화할 수 있으므로 강력한 보안 및 액세스 제어를 제공합니다.

...

Scroll title
title관리되는 계정 목록

image-20241111-061452.png

Guard 의 과금 정책

Scroll ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-htmltrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue

See also

Guard 에 등록된 관리되는 계정(managed accounts) 는 Guard 의 과금 대상에 포함됩니다. 즉 acme.com 도메인을 인증했고 해당 도메인의 이메일을 사용하는 사용자가 1,000 명이 있을 경우 Guard 는 1,000 명에 대해서 과금합니다.

만약 Bitbucket 이나 Trello 를 회사 도메인으로 사용하는 사용자가 있을 경우 이 사용자들도 모두 Guard 의 과금 대상이 됩니다.

아래 그림처럼 Acme 조직내에 5,000 명의 Enterprise plan 사용자(Confluence/Jira 접근 권한 보유)와 3,000 명의 Enterprise 사용자(Confluence/Jira/Trello 접근 건한 보유), 2,000 명의 Trello 사용자가 있다고 가정해 보겠습니다.

요약하면 Confluence/Jira 접근 권한을 보유한 전체 사용수는 8,000명 Trello 는 5,000명이므로 Guard 의 과금 대상자는 전체 unique 사용자인 10,000 에서 Enterprise plan 사용자인 8,000 을 뺀 2,000 명이 과금 대상이 됩니다.

Scroll title
titleGuard 의 과금 모델

image-20241111-102215.png

Info

해당 사용자들에 대해 과금을 원치 않는다면 아래에서 설명할 Non-Billable Policy(청구할 수 없는 정책) 유형의 인증 정책을 생성하고 해당 사용자들을 이 인증 정책으로 옮겨 놓으면 됩니다.

Guard 를 Entra ID나 Okta 같은 IdP 와 연결하고 여기를 통해서 사용자를 프로비저닝했을 경우 해당 사용자들은 모두가 관리되는 계정이 됩니다.

관리되는 계정은 Non-Billable Policy(청구할 수 없는 정책) 으로 전환할 수 없으므로 제품 접근 권한이 없어도 Guard 의 과금 대상이 되지 않을까 우려할 수 있지만 IdP 를 통해 프로비저닝된 사용자들은 관리되는 계정(1) 이면서 제품 접근 권한(2), 이 2가지 조건을 만족해야 과금 대상이 되므로 안심할 수 있습니다.

Tip

사용자가 IdP 를 통해 프로비저닝 됐고 이 계정(예: user@acme.com)으로 조직 외부의 사이트(예: example.com)에 엑세스할 경우 Guard 의 과금 대상이 됩니다.

Access authentication policies(인증 정책) 이란?

...

예로 외부 협력 업체는 ID/Password 기반으로 인증하고 내부 직원중 모바일 앱을 사용하는 민감한 정보를 다루는 직원들은 2 factor 인증, 나머지 지원들은 직원들은 SSO 를 사용하도록 설정할 수 있으며 이럴 경우 3개의 “인증 정책”을 만들고 각각의 사용자를 인증 정책에 할당하면 됩니다.

...

Scroll title
title인증 정책 목록 보기

image-20241111-095015.png

Authentication policy 생성

필요에 따라 다양한 인증 정책을 만들고 사용자별로 다른 정책을 부여할 수 있습니다.

...

1.보안인증 정책정책 추가를 클릭합니다.

...

Scroll title
title인증 정책 추가

image-20241111-095056.png

2. 사용자의 정보를 가져올 디렉터리(1)

...

선택한 후(예: OneLogin) 선택하고

...

정책 이름(2) 에 구분을 위해 의미있는 정책 이름을 입력합니다.

...

Scroll title
title디렉터리 및 인증 정책 설정

image-20241111-095249.png

3. 구체적인 인증 정책을 설정합니다.

Scroll title
title인증 정책 상세 설정

image-20241111-095428.png



2단계 인증(Two-step verification)

...

Scroll title
title2단계 인증

image-20241111-095555.png

 Google AuthenticatorAuthy, or Duo 같은 외부 인증 앱을 사용하여 2단계 인증을 강제화 할지를 설정합니다.

타사 로그인(Third-party login)

...

Scroll title
title타사 로그인 설정

image-20241111-095651.png

구성원이 타사 계정(Google, Microsoft, Apple, Slack)을 통해 Atlassian 제품에 로그인할 수 있는지 설정합니다.

...


비밀번호 요구 사항(Password Requirements)

패스워드의 복잡도를 설정할 수 있습니다.

...

Scroll title
title비밀번호 요구 사항 설정

image-20241111-095807.png


비밀 번호 만료 주기(Password expire)

체크하면 해당 인증 정책에 속한 구성원들은 지정한 기간마다 패스워드를 변경해야 합니다.

...

Scroll title
title만료주기 설정

image-20241111-095837.png

API 토큰(API tokens) 제어

허용하면 구성원은 API 호출시 사용할 인증 토큰을 생성할 수 있습니다.

Scroll title
titleAPI 토큰 제어 설정

image-20241111-095936.png

유휴 세션 기간(Idle session duration)

체크하면 로그아웃 하기전까지는 해당 기간동안 사용자의 세션이 유지됩니다.

...

API 토큰(API tokens)

허용하면 구성원은 API 호출시 사용할 인증 토큰을 생성할 수 있습니다.

...

Scroll title
title유휴 세션 기간 설정

image-20241111-100000.png

Default policy(기본 정책) 설정

인증 정책을 기본 정책(Default policy)으로 만들면 Provisining 된 모든 사용자들에게 적용됩니다.

기본 정책은 Org의 하나만 한 개만 설정 가능합니다.


1. 기본 정책으로 변경하려면 정책 상세 보기 화면에 들어간 후에 우측 상단의 설정(…) 을 클릭하고 메뉴에서 Make default policy 기본 정책 변경선택합니다.

...

Scroll title
title기본 정책 설정

image-20241111-100116.png

2.기본 정책으로 설정하면 정책 목록에서 아래와 같이 “Default policy기본 정책” 뱃지가 붙는 것을 확인할 수 있습니다.

...

Scroll title
title기본 정책 배지

image-20241111-100207.png

Non-billable policy(청구할수 없는 정책) 이란

...

  • Single Sign-On 강제화

  • Two factor 인증 필수

  • 암호 강도 및 변경 주기 강제화

  • API 토큰 생성 차단

Info

2022-08-03 부터 Enterprise plan 사용자들은 nob billable poliyc 를 default policy 로 만들 수 있습니다.

Scroll ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-htmltrue
scroll-epubtrue

https://hello.atlassian.net/wiki/spaces/CW/pages/1597549776/Multiple+identity+providers+for+Cloud+Enterprise+-+Quick+Reference+Guide

Note

Non-billable policy 는 IdP 를 통해 동기화된 사용자 계정에 대해서는 가 연결된 인증 정책에는 설정할 수 없습니다.

Expand
title예시 화면 보기

Nonbillable policy(청구할수 없는 정책) 생성

  1. Security → Authentication policies → Add policy 를 클릭합니다.

  2. 사용자 동기화할 Directory(1) 를 Local 로선택하고 Policy name(2) 에 구분을 위해 의미있는 정책 이름을 입력합니다.


  3. 새로운 정책이 생성되고 편집 화면으로 전환되면 우측 상단의 … 을 클릭한 후에 Make policy nonbillable 을 클릭합니다.

  4. Update 를 클릭하면 nonbillable policy 가 생성됩니다.

  5. Members 탭을 클릭하고 사용자를 추가해 주면 됩니다.

...