Cloud 移行を計画する
Atlassian Server または Data Center 製品の移行準備に役立つドキュメント。
Atlassian Cloud でのユーザー管理の仕組み
Atlassian Cloud でのユーザー管理は、Server または Data Center でのユーザー管理とは異なります。主な違いは、Jira や Confluence といった製品と分離されていることです。Crowd を使用した場合は、それが最も近い比較になります。このページでは、クラウドでのユーザー管理方法に関する主な概念について説明します。
集中型のユーザー管理
クラウドでは、ユーザーは admin.atlassian.com という場所から一元管理され、同じ URL で利用できです。これは、お客様が管理する Atlassian Cloud 製品で共有されるプラットフォームです。例を示します。
ユーザーとグループ
製品にアクセスする
ユーザー プロビジョニングとシングル サインオン
製品、サブスクリプション、請求
クラウド製品をデプロイすると、いつでも自分の admin.atlassian.com にアクセスできます。Jira 管理者または Confluence 管理者よりもランクが高い組織管理者のみがアクセスできますが、実際にはタイプが異なるだけです。システム管理者と考えてください (ただし、システム管理はクラウドには存在しません)。
組織
admin.atlassian.com プラットフォームは組織に分割されます。その数は 1 つでも構いませんし、細かく分ける必要がある場合は複数でも構いません。個々の製品アクセス、ユーザー プロビジョニングの設定など、すべての組織に個別のユーザー ベースがあります。プラットフォームにアクセスするときは、表示する組織を必ず選択してください。
組織はさらに、Jira や Confluence といった製品を扱うサイトに分割されます。1 つの組織内のすべてのサイト (および製品) は、同じユーザー ベースと設定を共有します。1 つの組織内で多くのサイト、および多くの製品を持つことができます。
Server または Data Center のユーザー管理エリア
Server や Data Center にあるユーザー管理エリアは、クラウドには存在しません。サーバーでは、組み込み Crowd (Jira と Confluence に組み込んだ一連のライブラリ) に基づいてユーザーを管理します。クラウドでは利用できません。また、このエリアにアクセスすることはできません。すべてを admin.atlassian.com に移行しました。良い点を挙げるとすれば、少し見やすくなりました。
製品アクセス
製品アクセスは最初のアクセス レイヤーであり、ユーザーが特定の製品を開くことができるかどうかを制御します。製品アクセスは、グループまたは個人ユーザーに対して、追加の製品ロール (管理者、ユーザー、顧客) と一緒に admin.atlassian.com から付与します。付与されると、製品アクセスを持つすべてのユーザーがクラウド サブスクリプションにカウントされ始めます。これは、サーバーでのアプリ アクセスと同じように機能します。
製品アクセスはサーバーから移行します。ただし、請求に影響するため、移行後にお客様が確認するまで、グループには適用しません。
クラウドにおける製品アクセス権の詳細についてご確認ください。
製品のアクセス権がない。
製品アクセスを持たないユーザーは引き続き存在し、Atlassian Cloud にログインできます。ただし、そういったユーザーは、自分の設定の変更や、アバターのアップロードは別として、できることはあまりありません。クラウド サブスクリプションにはカウントされません。
権限
権限は 2 番目のアクセス レイヤーであり、製品へのアクセスだけでなく、より細分化された権限をユーザーに付与できます (例: シークレット プロジェクトやスペースを閲覧する権限など)。権限はサーバー内と同じように機能し、admin.atlassian.com からではなく、製品レベルで管理されます。これは、実際にはユーザー管理よりもデータ保護の面を重視しているからです。
権限は製品によって異なります (サーバー内など)。Jira では、プロジェクト ロール、権限スキーム、より細分化された権限があります。Confluence では、これはスペース権限であり、ページに追加の制限がかかります。ユーザーがプロジェクトまたはスペースを移行すると、ロール、スキーム、権限、または制限も移行されます (大部分のグローバル権限を除きます)。
Atlassian Guard Standard のサブスクリプション
Atlassian Guard Standard は別個の製品であるように見えますが、実際には admin.atlassian.com の拡張機能です。次のような機能を有効にする追加サブスクリプションです。
SCIM ユーザー プロビジョニング
SAML シングル サインオン
データ セキュリティ ポリシー
組織監査ログ
Atlassian Guard Standard をサブスクライブしても、ユーザーの管理は引き続き admin.atlassian.com から行いますが、表示されるタブ、オプション、機能が増えています。外部ディレクトリ (Google Workspace 以外) のユーザーを同期する際は、多くの場合、Atlassian Guard Standard が必要になります。
admin.atlassian.com のページ例を示します。これは、Atlassian Guard Standard サブスクリプションでのみ利用可能なページであり、同じアトラシアンの管理エリアです。
Atlassian Cloud アカウント
Atlassian Cloud では、ユーザーはメール アドレスによって識別されます。そのため、すべてのメールが有効かつ一意でなければなりません。サーバーでは、ユーザー名によって識別されていました。そのため、メールの見逃しや無効なメールにより、多くの人がユーザー移行に関する問題を抱えています。作成、招待、プロビジョニング、または移行するすべてのユーザーは、メール アドレスに基づいて Atlassian Cloud アカウントを取得します。
複数製品へのアクセス
ユーザーに複数製品へのアクセス権が付与されている場合、そのユーザーは、単一の Atlassian Cloud アカウントを通じて製品にアクセスします。サーバーでは、製品ごとに個別のユーザーが存在します。
複数の製品 (Jira、Confluence) からユーザーを移行する場合、メール アドレスでユーザーを照合し、すべての参照 (メンション、コメントなど) を単一の Atlassian Cloud アカウントにリンクします。
アカウントと管理対象アカウント
個々のユーザーは既定でアカウントを持ちます。製品アクセスは引き続き管理できますが、アカウント自体を変更することはできません。より詳細に管理する必要がある場合は、ドメイン (@atlassian.com) の所有者であることを認証し、このドメインのすべてのアカウントの所有権を取得します。これにより、アカウントの所有権がドメインを認証した組織に譲渡され、アカウントは管理対象アカウントになります。それらは同じアカウントですが、より詳細に管理できます。Atlassian Guard Standard 固有の機能は、管理対象アカウントに対してのみ使用できます。
メールでログイン
ユーザーにとってのログイン時の主な違いの 1 つが、サーバーへのログイン時とは異なり、ユーザー名ではなくメール アドレスを使用してログインする点です。
クラウドでシングル サインオンを使用している場合、ユーザーはシングル サインオンでログインし、同じパスワードを使用します。
シングル サインオンを使用しない場合、ユーザーは「パスワードを忘れた場合」を選択し、新しいパスワードを入力する必要があります。パスワードは移行されません。
アバターは移行されないため、ユーザーは新しいアバターをアップロードする必要があります。
ユーザー プロビジョニングと認証
ユーザーを管理したり、外部ディレクトリからクラウドに同期することはできますが、追加要件があります。
クラウド ID プロバイダー
外部ディレクトリを admin.atlassian.com に直接接続することはできません。間にクラウド ID プロバイダーが必要です。持っていない場合は、移行に最適な IdP のリストをこのガイドで見つけてください。また、Okta と提携して、無料アカウントを設定することもできます。
Atlassian Guard Standard のサブスクリプション
SCIM ユーザー プロビジョニングと SAML シングル サインオンを有効にするには、Atlassian Guard Standard のサブスクリプションが必要です。Google Workspace や入れ子グループ用の Azure AD など、ユーザー プロビジョニングを行うための一部の統合は、SCIM を使用しないカスタムビルドの統合であるため、Atlassian Guard Standard がなくても機能します。
連携の仕組みは以下のとおりです。
ユーザー プロビジョニングや認証はなし
ユーザー プロビジョニングを設定しない場合は、Jira や Confluence の内部ディレクトリのように、admin.atlassian.com でユーザーを作成およびアップデートできます。シングル サインオンを設定しない場合、ユーザーはメール アドレスとパスワードを使用してログインします。パスワードは移行されないため、移行後にリセットする必要があります。
ユーザー管理に関するその他の相違点
他にもいくつかの相違点や知っておくべき情報があります。
入れ子グループ
Atlassian Cloud は入れ子グループをサポートしません。引き続き外部ディレクトリ内で入れ子グループを持つことはできますが、クラウドと同期するときに入れ子グループをフラット化する必要があります。admin.atlassian.com では、それらは常に同じレベルに表示されます。ほとんどのクラウド ID プロバイダーはフラット化をサポートしています。当社はさらに、Google Workspace や Microsoft Azure AD から同期するときにグループをフラット化するカスタム統合も構築しました。
重複するグループ名
すべてのグループが 1 つの場所で管理されるため、同じ名前のグループを複数持つことはできません。コピーがすでに存在するグループを移行しようとすると、そのユーザーは移行されますが、グループ自体は移行されません。これは、Jira と Confluence の両方から移行しようとする場合に重要です。これらの各製品に異なるユーザー セットを持つグループ管理者がいる場合、移行後、これらすべてのユーザーは 1 つの管理者グループに属し、最初に移行されたグループからの製品アクセス権を持ちます。究極の権限エスカレーションです。このガイドでは、こうした移行について詳しく説明します。
Crowd Server または Data Center
admin.atlassian.com は同じように機能しますが、Crowd には同等のクラウド製品はありません。Crowd でのユーザー管理を続ける場合は、クラウド ID プロバイダーに接続し、そのプロバイダーを admin.atlassian.com に接続します。
関連ページ
この内容はお役に立ちましたか?
さらにヘルプが必要ですか?
アトラシアン コミュニティをご利用ください。