ネストされたグループの問題について理解する

このページでは、入れ子グループを Atlassian Cloud に移行する場合に関連する問題と、そうした問題を回避する方法について概説します。要約すると、入れ子グループは Atlassian Cloud ではサポートされていませんが、入れ子構造を外部ユーザー ディレクトリに保持してフラット化されたものを Cloud で使用できます。

入れ子グループとは

入れ子グループは他のグループのサブグループです。通常、こうしたグループは権限の継承や、外部ユーザー ディレクトリにおける会社の構造の再作成に使用されます。

ここでは、外部ユーザー ディレクトリに保持できる入れ子構造の例を示します。

• 親グループ: Atlassian

• 入れ子グループ: Design、Engineering、Grads

入れ子構造の主なメリットは、権限の継承です。入れ子グループのメンバーは、直接のグループからだけでなく親グループからも権限を受け取ります。通常、権限を簡単に付与または取り消す方法として使用されます。このような構造では、ユーザーを各グループに個別に追加する代わりに、ユーザーを単一の入れ子グループに追加 (そして、メンバーシップと権限をすべての親グループから継承させる) ことができます。

入れ子グループが Cloud に同期する仕組み

Atlassian Cloud は入れ子グループをサポートしていません。また、ほとんどの Cloud ID プロバイダーは、入れ子構造をどの SaaS アプリケーションと同期することも許可していません。

フラット化せずにユーザーを Atlassian Cloud に SCIM 経由で同期すると、次のようになります。

• グループ: すべてのグループが同期されますが、入れ子構造は保持されません。複数のグループが同じレベルに存在します。

• グループ メンバーシップ: ユーザーは親グループのメンバーシップを失います。権限の継承は考慮されません。

この問題は主に、フラット化をサポートしていない SCIM を使用して Microsoft Azure AD から同期する場合に発生します。カスタム統合 (入れ子グループ向けの Azure AD) を使用することでこの問題を解決できます。

入れ子グループのフラット化

この問題を解決するために、すべての有効なグループ メンバーシップを維持したままで入れ子グループをフラットな構造に変換できます。

入れ子グループをフラット化すると、次のようになります。

• グループ: すべてのグループが別々のグループになり、同じレベルに存在します。

• グループ メンバーシップ: ユーザーは権限の継承に依存せずに、各グループに個別に追加されます。たとえば、ユーザーが入れ子グループの直接のメンバーであり親グループのメンバーシップを継承した場合は、フラット化後にその両方のグループの直接のメンバーになります。これは継続的なプロセスであり、新しいユーザーやグループにも適用されます。

入れ子グループの移行の仕組み

アシスタントのいずれかを使用して移行すると、入れ子グループがフラット化されます。これは、フラット化をサポートしている ID プロバイダーからの同期と似ています。親グループで間接メンバーだったユーザーは、移行後は直接メンバーになります。

フラット化をサポートする ID プロバイダーを選択する

多くの ID プロバイダーは既定でフラット化をサポートしています。また、アトラシアンでは Google Workspace や 入れ子グループ向け Azure AD といったカスタム統合もご用意しています。これにより、グループをクラウドに同期しながらフラット化することができます。以下のページを開いて、移行に最適な ID プロバイダーのリストを確認してください。

移行に適した ID プロバイダーを選択する方法をご確認ください。

関連ページ

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