...
Atlassian Guard 를 사용하기 위해 도메인 인증을 완료했을 경우 인증된 도메인(예: acme.com, acme.co.uk) 에서 계정을 요청하면 해당 계정은 관리되는 계정이 됩니다. 즉 dev@acme.com 이나 hr_manager@acme.co.comuk 계정은 관리되는 계정이 되지만 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 의 과금 대상이 됩니다. 사용자들도 모두 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 의 과금 대상이 됩니다. |
...