...
Atlassian Guard 를 사용하기 위해 도메인 인증을 완료했을 경우 인증된 도메인(예: acme.com, acme.co.uk) 에서 계정을 요청하면 해당 계정은 관리되는 계정이 됩니다. 즉 dev@acme.com 이나 hr_manager@acme.comco.uk 계정은 관리되는 계정이 되지만 dev1@gmail dev1@vendor.com 은 회사에서 인증한 도메인이 아니므로 외부 사용자 계정이 됩니다.
Scroll ignore | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
https://support.atlassian.com/user-management/docs/verify-a-domain-to-manage-accounts/ |
Scroll title | ||
---|---|---|
| ||
관리되는 계정은 Guard 에서 제공하는 인증 정책을 강제화할 수 있으므로 강력한 보안 및 액세스 제어를 제공합니다.
...
Scroll title | ||
---|---|---|
| ||
Guard 의 과금 정책
Scroll ignore | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
Authentication policy 생성
필요에 따라 다양한 인증 정책을 만들고 사용자별로 다른 정책을 부여할 수 있습니다.
...
1.보안 → 인증 정책 → 정책 추가를 클릭합니다.
...
Scroll title | ||
---|---|---|
| ||
2. 사용자의 정보를 가져올 디렉터리(1) 를
...
선택한 후(예: OneLogin) 선택하고
...
정책 이름(2) 에 구분을 위해 의미있는 정책 이름을 입력합니다.
...
Scroll title | ||
---|---|---|
| ||
3. 구체적인 인증 정책을 설정합니다.
Scroll title | ||
---|---|---|
| ||
2단계 인증(Two-step verification)
...
Scroll title | ||
---|---|---|
| ||
Google Authenticator, Authy, or Duo 같은 외부 인증 앱을 사용하여 2단계 인증을 강제화 할지를 설정합니다.
타사 로그인(Third-party login)
...
Scroll title | ||
---|---|---|
| ||
구성원이 타사 계정(Google, Microsoft, Apple, Slack)을 통해 Atlassian 제품에 로그인할 수 있는지 설정합니다.
...
비밀번호 요구 사항(Password Requirements)
패스워드의 복잡도를 설정할 수 있습니다.
...
Scroll title | ||
---|---|---|
| ||
비밀 번호 만료 주기(Password expire)
체크하면 해당 인증 정책에 속한 구성원들은 지정한 기간마다 패스워드를 변경해야 합니다.
...
Scroll title | ||
---|---|---|
| ||
API 토큰(API tokens) 제어
허용하면 구성원은 API 호출시 사용할 인증 토큰을 생성할 수 있습니다.
Scroll title | ||
---|---|---|
| ||
유휴 세션 기간(Idle session duration)
체크하면 로그아웃 하기전까지는 해당 기간동안 사용자의 세션이 유지됩니다.
...
API 토큰(API tokens)
허용하면 구성원은 API 호출시 사용할 인증 토큰을 생성할 수 있습니다.
...
Scroll title | ||
---|---|---|
| ||
Default policy(기본 정책) 설정
인증 정책을 기본 정책(Default policy)으로 만들면 Provisining 된 모든 사용자들에게 적용됩니다.
기본 정책은 Org의 하나만 한 개만 설정 가능합니다.
1. 기본 정책으로 변경하려면 정책 상세 보기 화면에 들어간 후에 우측 상단의 설정(…) 을 클릭하고 메뉴에서 Make default policy 를 기본 정책 변경을 선택합니다.
...
Scroll title | ||
---|---|---|
| ||
2.기본 정책으로 설정하면 정책 목록에서 아래와 같이 “Default policy기본 정책” 뱃지가 붙는 것을 확인할 수 있습니다.
...
Scroll title | ||
---|---|---|
| ||
Non-billable policy(청구할수 없는 정책) 이란
...
Single Sign-On 강제화
Two factor 인증 필수
암호 강도 및 변경 주기 강제화
API 토큰 생성 차단
Info |
---|
2022-08-03 부터 Enterprise plan 사용자들은 nob billable poliyc 를 default policy 로 만들 수 있습니다. |
Scroll ignore | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
Note |
---|
Non-billable policy 는 IdP 를 통해 동기화된 사용자 계정에 대해서는 가 연결된 인증 정책에는 설정할 수 없습니다. |
Expand | ||
---|---|---|
| ||
Nonbillable policy(청구할수 없는 정책) 생성
Security → Authentication policies → Add policy 를 클릭합니다.
사용자 동기화할 Directory(1) 를 Local 로선택하고 Policy name(2) 에 구분을 위해 의미있는 정책 이름을 입력합니다.
새로운 정책이 생성되고 편집 화면으로 전환되면 우측 상단의 … 을 클릭한 후에 Make policy nonbillable 을 클릭합니다.
Update 를 클릭하면 nonbillable policy 가 생성됩니다.
Members 탭을 클릭하고 사용자를 추가해 주면 됩니다.
...