Atlassian Access の準備

Atlassian Access は、アトラシアンのクラウド製品を ID プロバイダーに接続する組織全体のサブスクリプションです。エンタープライズ グレードの認証と追加のセキュリティ オプションを提供し、企業ドメイン全体を監視します。

シングル サインオンを提供したり、外部ディレクトリからユーザーをプロビジョニングしたりする場合は、Atlassian Access が必要です。ご自身の組織に Atlassian Access が必要かどうかをご確認ください。

Atlassian Access の使用を考えている場合は、ユーザーとグループを移行する前に、次のいくつかのことを行う必要があります。

• ID プロバイダーをまだセットアップしてない場合は、設定します。

• グループ名の重複を確認します。

• 入れ子グループを確認します。

• 既存のクラウド アカウントを特定して確認します。

• ユーザーをどのようにプロビジョニングするかを決めます。

• Atlassian Access サブスクリプションの費用を見積もります。

• クラウド組織に Atlassian Access をセットアップします。

ID プロバイダーと外部ディレクトリをご自身で管理できない場合、これらの手順の一部を完了するには、他のチームや部門に相談する必要があるかもしれません。これを全体的な移行計画に織り込む必要があります。

ID プロバイダーのセットアップ

Atlassian Access では、サードパーティの ID プロバイダーに接続する必要があります。任意の ID プロバイダーを使用できますが、一部の機能は特定の ID プロバイダーでのみ使用できます。アトラシアンがサポートする ID プロバイダーをご確認ください。

ID プロバイダーをまだ利用していない場合は、ID プロバイダーを選ぶときに考慮すべき点がいくつかあります。

• SAML 2.0 互換
  シングル サインオンを有効にするには、ID プロバイダーが SAML 2.0 を実装する必要があります。現在、Atlassian Cloud でのシングル サインオンに OpenID Connect はサポートされていません。

• SCIM プロビジョニングに対応
  ID プロバイダーからユーザーをプロビジョニングして管理するには、SCIM プロビジョニングをサポートしている ID プロバイダーを使用する必要があります。

• 入れ子グループのフラット化
  既存の外部ディレクトリに入れ子グループが含まれている場合は、移行後の製品アクセスや権限の問題を防ぐために、グループをフラット化できる ID プロバイダーを選択することをお勧めします。クラウド移行に向けて入れ子グループを準備する方法をご確認ください。

ID プロバイダーをお持ちでない場合、アトラシアンでは Okta とのパートナーシップによって無料アカウントを提供しています。組織の Okta アカウントの作成方法をご確認ください

グループ名の重複を確認する

ユーザーとグループは Atlassian Cloud で一元管理されています。つまり、同じ名前が付いた複数グループのメンバーは、移行時にその名前が付いた 1 つのグループのメンバーになります。移行前の Jira と Confluence でこうしたグループのメンバーが異なると、問題が発生する可能性があります。

例を見てみましょう。Acme には、Jira と Confluence でメンバーが異なる team-leads という名前のグループがあります。移行後、これらのユーザーはすべて同じ team-leads という 1 つのグループのメンバーになり、Jira と Confluence の両方で同じ製品アクセスと権限を取得します。

この場合、予想以上に多くのユーザーに製品アクセス権を付与している可能性があるため、ユーザーが表示したり実行したりできることや、請求書にも影響を与える可能性があります。

Atlassian Access を使用する予定があるかどうかにかかわらず、移行前にグループ名の重複を解決する必要があります。Jira や Confluence ではグループの名前を直接変更できないため、グループを監査して再作成 (または名前変更) する時間と労力はかなり大きくなる可能性があります。このことを移行計画に組み込むことをお勧めします。

グループと権限の移行方法の詳細をご確認ください。

入れ子グループを確認する

Atlassian Cloud は入れ子グループをサポートしていません。移行すると、グループ直下のメンバーだけがクラウド内のそのグループに追加されます。つまり、一部のユーザーは移行後に重要なグループ メンバーシップを失う可能性があるということです。

移行前に、入れ子グループがあるかどうか (グループが別のグループのメンバーになっているか) を確認し、フラット化の方法を決定する必要があります。その方法は、ID プロバイダーによって異なります。

Cloud 移行に向けて入れ子グループを準備する方法をご確認ください。

既存のクラウド アカウントを特定して確認する

ご自身の組織にいるユーザーは、すでに Atlassian アカウントを持っている可能性があります。これは通常、チームによって管理されていない製品を含め、そうしたユーザーがすでに Atlassian Cloud 製品にアクセスできるためです。組織が Cloud サブスクリプションをまだ承認していないからといって、既存のアカウントを持っているユーザーがいないと考えないでください。

管理対象アカウントのリストを確認して、重複や不一致をなくすことができるように、今すぐドメインを認証し、ドメインのユーザー アカウントを申請することをお勧めします。

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

次に該当するか確認することをお勧めします。

• 申請されたアカウントのメール アドレスが、Server または Data Center サイト、および ID プロバイダー (利用している場合) のメール アドレスと一致します。一致しない場合は、変更の必要があるかもしれません。

• Atlassian Access の請求予定額が、クラウド製品にアクセスできると想定されるユーザー数と一致します。

一致しないメール アドレスを更新する

移行プロセスでは、ユーザーを識別する方法としてメール アドレスを使用します。各ユーザーの Server または Data Center 製品アカウント、Atlassian アカウント、ID プロバイダーのプライマリ メール (およびその他の関連するメール属性) のメール アドレスが一致していることを確認する必要があります。

メール アドレスが一致しない場合、Atlassian アカウントが重複する結果につながる可能性があります。つまり、誰かがログインするときに使用するアカウントは、そのユーザーのコンテンツや権限に関連付けられているアカウントと異なる可能性があります。これは解決が難しいことがあるので、移行前にメール アドレスを変更するのが最良の対応です。

移行アシスタントを使用して、重複している無効なメール アドレスを特定し、移行中に自動的に修正することもできます。ユーザーを評価して移行に備える方法をご確認ください。

ユーザーをどのようにプロビジョニングするかを決める

新しいユーザーに製品へのアクセス権を提供する方法はいくつかあります。以下はその例です。

• 承認済みドメイン。ドメインが承認されると、ユーザーはログインの試行時に自動的に既定の製品アクセス権が付与され、そのユーザーの Atlassian アカウントには承認済みドメインに一致するメール アドレスが提供されます。ユーザーがサイト アクセス権をどのように取得するか指定する方法をご確認ください

• SAML のジャスト イン タイム プロビジョニング。ドメインを ID プロバイダーのディレクトリにリンクし、SAML シングル サインオンを強制すると、新しいユーザーがシングル サインオンでログインしたときに、自動的にアカウントが作成され、そのユーザーに規定の製品アクセス権が付与されます。この方法では、グループや権限を細かく制御できません。SAML によるジャスト イン タイム プロビジョニングの詳細をご確認ください。

• SCIM ユーザー プロビジョニング。大規模な組織では、SCIM ユーザー プロビジョニングを使用して、ID プロバイダーからユーザーとグループのメンバーシップを同期するのが一般的です。SCIM ユーザー プロビジョニングの詳細をご確認ください。

SCIM ユーザー プロビジョニングをセットアップするプロセスは、移行する製品と使用するデータ移行方法によって異なります。推奨事項をチェックして、移行の計画を立てる必要があります。Atlassian Access による SCIM プロビジョニングに関する推奨事項をご確認ください。

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

Atlassian Accessは、アトラシアンの他のクラウド製品とは異なる請求モデルを使用する、組織全体のサブスクリプションです。Atlassian Access では組織単位で請求が発生します。つまり、組織内の管理対象アカウントごとに 1 回だけ請求されます。

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

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

手動で招待されたり、自分でサイン アップしたりした新規ユーザーを Atlassian Access サブスクリプションにカウントさせたくない場合は、既定のポリシーを請求対象外にするという選択ができます。請求対象外の既定ポリシーを設定する方法をご確認ください。

クラウド組織に Atlassian Access をセットアップする

ユーザーやグループを移行する前に、クラウド組織で多数の Atlassian Access 機能をセットアップする必要があります。

ドメインを認証してアカウントを申請

これをまだ行っていない場合は、ドメインを検証してそのドメインのユーザー アカウントを申請する必要があります。すべてのアカウントの申請も、そのドメインのユーザー アカウントのサブセットのみの申請も可能です。これは、Atlassian Access の機能をアンロックするために不可欠です。

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

請求対象外のポリシーを設定する

請求対象外のポリシーが必要だと判断した場合は、ユーザーとコンテンツを移行する前に、即座に設定できます。

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