新しいアクセス制御モデルへの移行 ​

Workatoの新しいアクセス制御モデルは、コラボレーターロールをEnvironmentロールおよびプロジェクトロールに置き換えます。 この分離により、柔軟性、明確性、プロジェクト固有のアクセス制御が向上します。

一括移行ツールの使用は、2段階のプロセスに従います。 このツールはまず、個々のコラボレーターのレベルでステージングされたレポートを生成し、各ユーザーに付与される新しいEnvironmentロール、参加するコラボレーターグループ、および各プロジェクトで保持するプロジェクトロールを一覧表示します。 レポートを確認した後、完全な移行を実行できます。

移行ウィザードは、すべてのレガシーコラボレーターロールを分析し、その権限を新しいEnvironmentロールおよびプロジェクトロールに統合し、既存のアクセスパターンを反映するコラボレーターグループを作成します。 一括移行をサポートし、サマリーレポートを生成し、ワークスペース全体で同等のアクセスレベルを維持します。

すべてのコラボレーターロールを一括移行する ​

開始する前に、ワークスペース管理者アクセス権があることを確認してください。

すべてのロールを一括で移行するには、次の手順を実行します:

移行が完了すると、確認メッセージが表示されます。 新しいコラボレーターグループはPeople > Collaborator groupsに表示されます。

移行後の変更点 ​

移行により、レガシーコラボレーターロールがEnvironmentロールおよびプロジェクトロールに置き換えられます。 移行を完了すると、次の動作が変更されます。

AHQモデレーターの割り当て ​

新しいAutomation HQモデレーターを作成するときは、Environmentロールとプロジェクトロールの両方を選択する必要があります。 EnvironmentロールはすべてのEnvironmentに適用され、プロジェクトロールは管理対象ワークスペース内のすべてのプロジェクトに適用されます。 これは、単一のコラボレーターロールがすべてのアクセスを制御していた以前のワークフローを置き換えます。

詳細については、AHQモデレーターおよびOEMカスタマーマネージャーセクションを参照してください。

プロジェクトアクセス管理 ​

コラボレーターは、コラボレーターロールを通じてプロジェクトアクセスを受け取らなくなります。 Project settings > Project accessページで、直接のプロジェクトロール割り当てまたはコラボレーターグループメンバーシップを通じてプロジェクトアクセスを管理します。

コラボレーターグループ ​

移行ウィザードは、共有されたアクセスパターンに基づいてコラボレーターグループを自動的に作成します。 これらのグループはプロジェクトレベルの権限を一元化します。 移行後に、チームの組織構造に合わせてグループの名前変更、変更、または追加作成を行うことができます。

移行後 ​

移行後、更新されたロールとコラボレーターグループを確認し、ワークスペースが明確で整理された状態を維持していることを確認します。 重複するロール名や類似したアクセスパターンを持つコラボレーターグループの名前を変更して、混乱を減らし、継続的なアクセス管理を改善します。

IDプロバイダー属性の更新 ​

組織でSCIMまたはSAMLロール同期を使用している場合は、IDプロバイダーを更新します。 新しいアクセス制御モデルでは、次のSAML属性を変更する必要があります:

• workato_role: デフォルトEnvironmentの新しいEnvironmentロール名を参照するように、この属性を更新します。 値は、ワークスペース内の既存のEnvironmentロールと一致している必要があります。
• workato_role_test: 該当する場合、テストEnvironmentのEnvironmentロール名を参照するように、この属性を更新します。
• workato_role_prod: 該当する場合、プロダクションEnvironmentのEnvironmentロール名を参照するように、この属性を更新します。
• workato_user_groups: コラボレーターをWorkatoのコラボレーターグループにマッピングするために、この属性を追加します。 値は、グループ名のカンマ区切り文字列である必要があります。 Workatoは、各ログインまたはプロビジョニングイベント中に、ユーザーのグループメンバーシップをこの属性に一覧表示されたものに置き換えます。

SAMLアプリケーションがこれらの更新済み属性を渡し、値がWorkatoワークスペース内のロール名およびグループ名と一致していることを確認します。 詳細な設定手順については、IDプロバイダー固有のガイドを参照してください:

• Okta
• Microsoft Entra ID
• OneLogin

Automation HQの継承可能なロール ​

組織でAutomation HQを通じて作成および共有された継承可能なロールを使用している場合は、それらのロールをAutomation HQワークスペースで移行する必要があります。 移行は、そのロールが割り当てられているすべてのダウンストリームワークスペースに適用されます。 ダウンストリームのコラボレーター割り当ては、新しいアクセス制御モデルに合わせて自動的に更新されます。

移行ウィザードが新しいロールとグループを割り当てる方法 ​

Workatoの移行ウィザードは、既存のコラボレーターロール、権限、およびプロジェクトアクセスパターンを自動的に分析します。 このデータを使用して、権限を同等に保ちながら、レガシーアクセスモデルを新しいEnvironmentおよびプロジェクト構造に変換します。

Environmentロール ​

ウィザードはワークスペース全体で各コラボレーターの権限を比較し、新しいEnvironmentロールのいずれかを割り当てます:

カスタムロールまたは複製されたロールは、同じ権限範囲を持つ同等のカスタムEnvironmentロールとして保持されます。

プロジェクトロール ​

ウィザードは、各プロジェクトでコラボレーターが実行できた操作を分析します（たとえば、レシピの編集、フォルダの管理、ジョブの実行）。 これらの権限は、同等のアクセスを表すプロジェクトレベルのロールに変換されます:

各コラボレーターグループは、プロジェクトごとに1つ以上のプロジェクトロールを受け取ります。 コラボレーターはグループメンバーシップを通じてこれらの権限を自動的に継承し、移行後も同等のアクセスを保持できます。

コラボレーターグループ ​

ウィザードは、プロジェクト全体で同じアクセスパターンを共有するコラボレーターを分析して、コラボレーターグループを自動的に作成します。 これらのグループはプロジェクトレベルの権限を一元化し、継続的なメンテナンスを削減します。

グループの名前は、そのグループに割り当てられた新しいプロジェクトロールと、アクセス可能なプロジェクトに基づいて付けられます。 次の構文を使用してグループの名前を変更することをお勧めします:

{{Project}} | {{Project role}} | {{Environment}}

例: Reusable Assets | Viewers | DEV TEST

ウィザードは、複数のレガシーロールが同一の権限レベルを共有しているものの、プロジェクトスコープのアクセスが異なる場合に、Project admin (2) などの番号付きバリアントを作成します。

Workatoは、移行中にグループがどのように形成されたかに基づいて、各グループの説明を自動生成します。 例: Created during migration privilege group: DevOps Viewer.

各グループのメンバーシップは、以前に同じプロジェクトレベルのアクセスを共有していたコラボレーターを反映し、移行後も同等の権限を保持できるようにします。

ベストプラクティス ​

レガシーロールから新しいアクセス制御モデルに移行する際は、次のベストプラクティスを検討してください。

低リスクの変更から開始する ​

機密性が高いロールや複雑なロールを移行する前に、影響の少ないロールまたは内部ロールから始めます。 このアプローチにより、重要なプロジェクトを中断することなく、ロールのマッピングとアクセスの動作を検証できます。

変更を適用する前に確認する ​

更新を適用する前に、移行ウィザードのプレビュー手順を使用して、ロールの割り当てとプロジェクトアクセスを確認します。

DEVを通じてワークスペースレベルのアクセスを管理する ​

DEVEnvironmentでワークスペースレベルの管理者権限を割り当てます。 これらの権限は、TESTまたはPRODでのみ割り当てられた場合は適用されません。 DEVをグローバル管理のプライマリEnvironmentとして扱います。

移行後にクリーンアップして検証する ​

移行後にすべてのEnvironmentロールとプロジェクトロールを確認し、重複を統合し、監査ログを使用してコラボレーターアクセスを検証します。