Atlassian Cloud でのユーザー管理の仕組み

Atlassian Cloud でのユーザー管理は、Server または Data Center でのユーザー管理とは異なります。主な違いは、Jira や Confluence といった製品と分離されていることです。Crowd を使用した場合は、それが最も近い比較になります。このページでは、クラウドでのユーザー管理方法に関する主な概念について説明します。


集中型のユーザー管理

クラウドでは、ユーザーは admin.atlassian.com という場所から一元管理され、同じ URL で利用できです。これは、お客様が管理する Atlassian Cloud 製品で共有されるプラットフォームです。例を示します。

  • ユーザーとグループ

  • 製品にアクセスする

  • ユーザー プロビジョニングとシングル サインオン

  • 製品、サブスクリプション、請求

admin.atlassian.com のユーザー ビュー

クラウド製品をデプロイすると、いつでも自分の 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 に移行しました。良い点を挙げるとすれば、少し見やすくなりました。

Jira Data Center のユーザー ビュー

製品アクセス

製品アクセスは最初のアクセス レイヤーであり、ユーザーが特定の製品を開くことができるかどうかを制御します。製品アクセスは、グループまたは個人ユーザーに対して、追加の製品ロール (管理者、ユーザー、顧客) と一緒に admin.atlassian.com から付与します。付与されると、製品アクセスを持つすべてのユーザーがクラウド サブスクリプションにカウントされ始めます。これは、サーバーでのアプリ アクセスと同じように機能します。

グループの製品アクセス設定

製品アクセスはサーバーから移行します。ただし、請求に影響するため、移行後にお客様が確認するまで、グループには適用しません。

クラウドにおける製品アクセス権の詳細についてご確認ください。

製品のアクセス権がない。

製品アクセスを持たないユーザーは引き続き存在し、Atlassian Cloud にログインできます。ただし、そういったユーザーは、自分の設定の変更や、アバターのアップロードは別として、できることはあまりありません。クラウド サブスクリプションにはカウントされません。


権限

権限は 2 番目のアクセス レイヤーであり、製品へのアクセスだけでなく、より細分化された権限をユーザーに付与できます (例: シークレット プロジェクトやスペースを閲覧する権限など)。権限はサーバー内と同じように機能し、admin.atlassian.com からではなく、製品レベルで管理されます。これは、実際にはユーザー管理よりもデータ保護の面を重視しているからです。

Jira Cloud からの権限の割り当て

権限は製品によって異なります (サーバー内など)。Jira では、プロジェクト ロール、権限スキーム、より細分化された権限があります。Confluence では、これはスペース権限であり、ページに追加の制限がかかります。ユーザーがプロジェクトまたはスペースを移行すると、ロール、スキーム、権限、または制限も移行されます (大部分のグローバル権限を除きます)。

ロールと権限の詳細を確認する


Atlassian Access のサブスクリプション

Atlassian Access は別個の製品であるように見えますが、実際には admin.atlassian.com の拡張機能です。次のような機能を有効にする追加サブスクリプションです。

  • SCIM ユーザー プロビジョニング

  • SAML シングル サインオン

  • データ セキュリティ ポリシー

  • 組織監査ログ

Atlassian Access をサブスクライブしても、ユーザーの管理は引き続き admin.atlassian.com から行いますが、表示されるタブ、オプション、機能が増えています。外部ディレクトリ (Google Workspace 以外) のユーザーを同期する際は、多くの場合、Atlassian Access が必要になります。

admin.atlassian.com のページ例を示します。これは、Atlassian Access サブスクリプションでのみ利用可能なページであり、同じアトラシアンの管理者エリアです。

Atlassian Access サブスクリプションで利用可能なサンプル ページ

Atlassian Access について理解する


Atlassian Cloud アカウント

Atlassian Cloud では、ユーザーはメール アドレスによって識別されます。そのため、すべてのメールが有効かつ一意でなければなりません。サーバーでは、ユーザー名によって識別されていました。そのため、メールの見逃しや無効なメールにより、多くの人がユーザー移行に関する問題を抱えています。作成、招待、プロビジョニング、または移行するすべてのユーザーは、メール アドレスに基づいて Atlassian Cloud アカウントを取得します。

複数製品へのアクセス

ユーザーに複数製品へのアクセス権が付与されている場合、そのユーザーは、単一の Atlassian Cloud アカウントを通じて製品にアクセスします。サーバーでは、製品ごとに個別のユーザーが存在します。

複数の製品 (Jira、Confluence) からユーザーを移行する場合、メール アドレスでユーザーを照合し、すべての参照 (メンション、コメントなど) を単一の Atlassian Cloud アカウントにリンクします。

アカウントと管理対象アカウント

個々のユーザーは既定でアカウントを持ちます。製品アクセスは引き続き管理できますが、アカウント自体を変更することはできません。より詳細に管理する必要がある場合は、ドメイン (@atlassian .com) の所有者であることを確認し、このドメインからすべてのアカウントを申請できます。これにより、アカウントの所有権がドメインを検証した組織に譲渡され、アカウントは管理対象アカウントになります。それらは同じアカウントですが、より詳細に管理できます。Atlassian Access 固有の機能は、管理対象アカウントに対してのみ使用できます。

メールでログイン

ユーザーにとってのログイン時の主な違いの 1 つが、サーバーへのログイン時とは異なり、ユーザー名ではなくメール アドレスを使用してログインする点です。

  • クラウドでシングル サインオンを使用している場合、ユーザーはシングル サインオンでログインし、同じパスワードを使用します。

  • シングル サインオンを使用しない場合、ユーザーは「パスワードを忘れた場合」を選択し、新しいパスワードを入力する必要があります。パスワードは移行されません。

  • アバターは移行されないため、ユーザーは新しいアバターをアップロードする必要があります。


ユーザー プロビジョニングと認証

ユーザーを管理したり、外部ディレクトリからクラウドに同期することはできますが、追加要件があります。

クラウド ID プロバイダー

外部ディレクトリを admin.atlassian.com に直接接続することはできません。間にクラウド ID プロバイダーが必要です。持っていない場合は、移行に最適な IdP のリストをこのガイドで見つけてください。また、Okta と提携して、無料アカウントを設定することもできます。

Atlassian Access のサブスクリプション

SCIM ユーザー プロビジョニングと SAML シングル サインオンを有効にするには、Atlassian Access のサブスクリプションが必要です。Google Workspace入れ子グループ用の Azure AD など、ユーザー プロビジョニングを行うための一部の統合は、SCIM を使用しないカスタムビルドの統合であるため、Atlassian Access がなくても機能します。

連携の仕組みは以下のとおりです。

Atlassian Access と ID プロバイダーの連携の仕組みを示した図

ユーザー プロビジョニングや認証はなし

ユーザー プロビジョニングを設定しない場合は、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 に接続します。


Atlassian Cloud へのユーザーの移行を開始する

その他のヘルプ