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

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

入れ子グループとは

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

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

  • 親グループ: Atlassian

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

ユーザー ディレクトリの入れ子構造の例

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

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

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

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

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

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

SCIM によって Cloud に同期した後にグループ メンバーシップが失われる

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

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

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

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

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

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

フラット構造でグループ メンバーシップを修正する

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

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

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

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

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

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

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

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

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

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

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

Atlassian Cloud でサポートされている ID プロバイダーが入れ子グループを処理する方法の要約概要は次のとおりです。

アイデンティティ プロバイダー

動作の仕組み

詳細と関連リンク

Okta

  • これらの ID プロバイダーでは、ユーザー ディレクトリから入れ子グループをインポートする際にその入れ子グループをフラット化します。

  • 次に、そのグループのいずれかを SCIM 経由で Atlassian Cloud に接続してフラット構造を同期します。

PingFederate

OneLogin

Microsoft Azure Active Directory (Azure AD)

  • アトラシアンは、Azure AD から Atlassian Cloud (Azure AD Sync) にユーザーを同期するためのカスタム統合を作成しました。

  • 入れ子構造は同期中にフラット化されます。

  • SCIM 経由で Azure AD に接続する際には入れ子グループをフラット化できません。

この機能は、フィードバックを収集する EAP (アーリー アクセス プログラム) として利用できます。EAP にご参加のうえ、機能の改善にご協力ください。

EAP への参加方法をご確認ください。

Google Workspace (G Suite)

  • Google Workspace は入れ子グループをサポートしています

  • Atlassian Cloud に同期時は、同期設定ですべてのグループ (親と入れ子) を個別に選択する必要があります。選択したグループはフラット構造として同期されます。

  • 選択されていないグループは同期されず、ユーザーはそのグループのメンバーシップを失います。

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

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

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

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

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

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

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

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

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

最初にユーザー移行戦略を決定します。ほとんどの場合は次の手順に従います。

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

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

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

詳細情報とサポート

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

その他のヘルプ