Atlassian Access の準備と設定

Atlassian Access は組織単位のサブスクリプションで、ユーザーを管理するための次のような追加機能を提供します。

• SCIM を使用したユーザー プロビジョニング

• SAML を使用したシングル サインオン

• セキュリティ ポリシー (2 段階認証の強制など)

ほとんどの場合、これらの機能を使用するには Atlassian Access が必要です。いくつかの例外があり、Google Workspace や入れ子グループ向けの Azure AD などのカスタム統合では、Atlassian Access がなくても一部のユーザー プロビジョニングとシングル サインオン機能を利用できます。

Atlassian Access を使用すべきかどうかを確認するには、次のページを参照してください。

Atlassian Access とクラウド IdP が必要かどうかを確認する

はじめる前に

始める前に、次の情報を確認してください。

サブスクリプション費用を見積もり、請求対象外のポリシーが必要かどうかを確認する

Atlassian Access の請求モデルは、アトラシアンの他のクラウド製品とは異なります。Atlassian Access では組織単位で請求が発生します。つまり、組織内の管理対象アカウントごとの支払いは 1 回のみです。

ユーザー数を確認する

クラウド組織にすでに存在しているユーザー アカウントの数を確認してから、移行するユーザー アカウントの数を評価することをお勧めします。そうすることで、サブスクリプションの費用を見積もることができます。

請求対象外のポリシー

Atlassian Access の請求に含まれるべきではないユーザーがいる場合は、そのユーザーを請求対象外の認証ポリシーに追加できます。追加されたユーザーは、2 段階認証の強制など、認証ポリシーに定義されているセキュリティ要件の対象になりません。

認証ポリシーの詳細を確認

自分でアカウントを作成できる新規ユーザー

手動で招待した、または自分でサインアップした新規ユーザーを Atlassian Access サブスクリプションにカウントしたくない場合は、既定のポリシーを請求対象外にすることができます。

請求対象外の既定ポリシーを設定する方法をご確認ください。

ドメインを認証して管理対象アカウントを要求する

ユーザーの Atlassian Access 機能をロック解除するには、ドメインを認証してそのドメインのユーザー アカウントを要求する必要があります。同期中にドメインを認証する Google Workspace や入れ子グループ向けの Azure AD といったカスタム統合を使用する場合を除き、次のページを参照してください。

ドメインを認証して管理対象アカウントを要求する方法をご確認ください。

組織に対して Atlassian Access を有効化する

Atlassian Access では 30 日間のトライアルを利用できます。さらに時間が必要な場合は、サポート チームに連絡して、トライアルを延長することもできます。

Atlassian Access の利用開始方法についてご確認ください。

次のステップ

準備ができたら、ID プロバイダーを設定します。移行のために ID プロバイダーを設定する方法をご確認ください。