Cloud 移行の入れ子グループを準備する

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

入れ子グループとは

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

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

• 親グループ: Atlassian

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

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

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

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

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

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

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

プロバイダーによって同期の方法は多少異なる可能性があるため、これは例としてご参照ください。各プロバイダーの詳細は、この後に出てくる表でご確認ください。

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

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

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

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

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

これは、(外部ユーザー ディレクトリの入れ子構造を削除することによって) 手動でも、一般にフラットナーと呼ばれる自動化プロセスによっても行えます。フラットナーでは、必要なすべてのグループにユーザーを追加することで、フラット構造の入れ子構造からメンバーシップを自動で再作成します。

Cloud への移行時に入れ子グループをフラット化する方法を決定する

入れ子グループをフラット化するには、次の 2 つの方法があります。

• 入れ子構造を自動でフラット化する

• ユーザー ディレクトリの入れ子構造を削除する

いずれかの方法で入れ子構造をフラット化しない場合、ユーザーは同期後にメンバーシップの一部を失います。

入れ子構造を自動でフラット化する

ID プロバイダーまたはそれに対応する同期メソッドによって入れ子構造を自動でフラット化することには、次のメリットがあります。

• 入れ子構造を外部ユーザー ディレクトリに保持できます。そのディレクトリは、ユーザーを管理してグループに追加するのに最適です。

• Atlassian Cloud では、すべての有効なグループ メンバーシップが保持されたフラット構造を使用します。

• ユーザー ディレクトリの入れ子構造に加えたすべての変更は、Cloud のフラット構造に同期されます。これによって入れ子構造で以前と同じように処理できるため、権限の付与と取り消しが容易になります。

さまざまな ID プロバイダーによる入れ子グループの処理方法の要約は次のとおりです。

ID プロバイダーが入れ子グループのフラット化をサポートしていない場合は、サポートしているものに切り替えるか、ユーザー ディレクトリの入れ子構造を削除する必要があります。アトラシアンがサポートする ID プロバイダーをご確認ください。

入れ子グループ構造の削除

入れ子構造を削除するには、入れ子グループを個別のグループに手動で変換する必要があります。その後、必要なグループにすべてのユーザーを個別に追加する必要があります。

次の理由によって、このアプローチを選択することをお勧めします。

• ほとんどの Cloud ID プロバイダーは SaaS アプリケーションへの入れ子構造の同期をサポートしていない。

Atlassian Cloud が入れ子グループをサポートしていたとしてもほとんどの ID プロバイダーではサポートされていないため、外部ディレクトリからそうしたグループを同期できません。独自のカスタム フラットナーを構築していない限り、他のアプリケーションと同期しようとすると同じ問題が発生する可能性があります。

• 入れ子グループは必須ではない。

入れ子グループは特に会社の構造を反映させて適切な権限を付与する場合に役立ちますが、フラット化をサポートするプロバイダーへの切り替えはグループを手動でフラット化するよりも多くの作業が必要になる可能性があります。通常、これは必須ではなく便利だからという理由で入れ子グループを使用している小規模な組織に当てはまります。

移行中に入れ子グループを同期するタイミング

通常は、次の手順に従いますが、選択した移行戦略によって異なる場合があります。

1. 外部ディレクトリを Server または Data Center 製品と同期して、ユーザーを更新します。

2. Migration Assistant によってユーザーとグループを Atlassian Cloud に移行します。

3. 外部ディレクトリを Atlassian Cloud と同期します。外部ディレクトリからのユーザーは、メール アドレスを照合することで移行されたユーザーにマッピングされます。

ユーザー移行戦略の決定方法をご確認ください

詳細情報とサポート

移行をサポートする多数のチャンネルをご用意しています。

• 移行計画の詳細については、Atlassian Migration Program の Web サイトをご参照ください。

• 技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。

• 専門的なアドバイスについては「アトラシアン コミュニティ」をご参照ください。

• 専門家によるサポートが必要な場合は、アトラシアン パートナーにご相談ください。