Atlassian Guard(Access) 인증 정책 설정 및 Non billable policy 적용하기
- Kwang Seob Jeong
- 정광섭
managed accounts(관리되는 계정) 란?
Atlassian Guard 를 사용하기 위해 도메인 인증을 완료했을 경우 인증된 도메인(예: acme.com, acme.co.uk) 에서 계정을 요청하면 해당 계정은 관리되는 계정이 됩니다. 즉 dev@acme.com 이나 hr_manager@acme.co.uk 계정은 관리되는 계정이 되지만 dev1@vendor.com 은 회사에서 인증한 도메인이 아니므로 외부 사용자 계정이 됩니다.
관리되는 계정은 Guard 에서 제공하는 인증 정책을 강제화할 수 있으므로 강력한 보안 및 액세스 제어를 제공합니다.
조직의 모든 관리되는 계정을 보려면 다음 절차를 거치면 됩니다.
관리자 허브인 admin.atlassian.com 으로 이동합니다. 조직이 둘 이상인 경우 해당 조직을 선택합니다.
디렉터리 → 관리되는 계정을 선택합니다.
현재 등록된 전체 관리되는 계정 목록을 확인할 수 있습니다.
Guard 의 과금 정책
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 명이 과금 대상이 됩니다.
해당 사용자들에 대해 과금을 원치 않는다면 아래에서 설명할 Non-Billable Policy(청구할 수 없는 정책) 유형의 인증 정책을 생성하고 해당 사용자들을 이 인증 정책으로 옮겨 놓으면 됩니다.
Guard 를 Entra ID나 Okta 같은 IdP 와 연결하고 여기를 통해서 사용자를 프로비저닝했을 경우 해당 사용자들은 모두가 관리되는 계정이 됩니다.
관리되는 계정은 Non-Billable Policy(청구할 수 없는 정책) 으로 전환할 수 없으므로 제품 접근 권한이 없어도 Guard 의 과금 대상이 되지 않을까 우려할 수 있지만 IdP 를 통해 프로비저닝된 사용자들은 관리되는 계정(1) 이면서 제품 접근 권한(2), 이 2가지 조건을 만족해야 과금 대상이 되므로 안심할 수 있습니다.
사용자가 IdP 를 통해 프로비저닝 됐고 이 계정(예: user@acme.com)으로 조직 외부의 사이트(예: example.com)에 엑세스할 경우 Guard 의 과금 대상이 됩니다.
Access authentication policies(인증 정책) 이란?
Atlassian Access 를 사용할 경우 사용자나 그룹에 필요한 보안 수준에 맞게 여러 가지 인증 정책을 만들고 사용자에게 적용해서 관리를 더 용이하게 할 수 있습니다.
예로 특정 그룹 직원은 2 factor 인증 또는 SSO(Single Sign On)를 거쳐야 사용할 수 있도록 설정할 수 있습니다.
이런 다양한 요구에 맞게 여러 인증 옵션을 묶은 것을 인증 정책이라고 하며 사용자에 따라서 별도의 인증 정책을 적용할 수 있습니다.
예로 외부 협력 업체는 ID/Password 기반으로 인증하고 내부 직원중 민감한 정보를 다루는 직원들은 2 factor 인증, 나머지 직원들은 SSO 를 사용하도록 설정할 수 있으며 이럴 경우 3개의 “인증 정책”을 만들고 각각의 사용자를 인증 정책에 할당하면 됩니다.
Authentication policy 생성
필요에 따라 다양한 인증 정책을 만들고 사용자별로 다른 정책을 부여할 수 있습니다.
1.보안 → 인증 정책 → 정책 추가를 클릭합니다.
2. 사용자의 정보를 가져올 디렉터리(1) 를 선택한 후(예: OneLogin) 선택하고 정책 이름(2) 에 구분을 위해 의미있는 정책 이름을 입력합니다.
3. 구체적인 인증 정책을 설정합니다.
2단계 인증(Two-step verification)
Google Authenticator, Authy, or Duo 같은 외부 인증 앱을 사용하여 2단계 인증을 강제화 할지를 설정합니다.
타사 로그인(Third-party login)
구성원이 타사 계정(Google, Microsoft, Apple, Slack)을 통해 Atlassian 제품에 로그인할 수 있는지 설정합니다.
SSO 를 활성화했을 경우 타사 로그인 가능 여부는 사용하는 IdP 에서 설정해야 합니다.
비밀번호 요구 사항(Password Requirements)
패스워드의 복잡도를 설정할 수 있습니다.
비밀 번호 만료 주기(Password expire)
체크하면 해당 인증 정책에 속한 구성원들은 지정한 기간마다 패스워드를 변경해야 합니다.
API 토큰(API tokens) 제어
허용하면 구성원은 API 호출시 사용할 인증 토큰을 생성할 수 있습니다.
유휴 세션 기간(Idle session duration)
체크하면 로그아웃 하기전까지는 해당 기간동안 사용자의 세션이 유지됩니다.
Default policy(기본 정책) 설정
인증 정책을 기본 정책(Default policy)으로 만들면 Provisining 된 모든 사용자들에게 적용됩니다.
1. 기본 정책으로 변경하려면 정책 상세 보기 화면에 들어간 후에 우측 상단의 설정(…) 을 클릭하고 메뉴에서 기본 정책 변경을 선택합니다.
2.기본 정책으로 설정하면 정책 목록에서 아래와 같이 “기본 정책” 뱃지가 붙는 것을 확인할 수 있습니다.
Non-billable policy(청구할수 없는 정책) 이란
특정 사용자들을 “청구할수 없는 정책” 그룹에 포함시키면 이 사용자들은 Guard 과금에서 제외되지만 Guard 에서 제공되는 다음과 같은 보호 기능들을 강제화할 수 없습니다.
Nonbillable policy(청구할수 없는 정책) 생성
Security → Authentication policies → Add policy 를 클릭합니다.
사용자 동기화할 Directory(1) 를 Local 로선택하고 Policy name(2) 에 구분을 위해 의미있는 정책 이름을 입력합니다.
새로운 정책이 생성되고 편집 화면으로 전환되면 우측 상단의 … 을 클릭한 후에 Make policy nonbillable 을 클릭합니다.
Update 를 클릭하면 nonbillable policy 가 생성됩니다.
Members 탭을 클릭하고 사용자를 추가해 주면 됩니다.
