ロールベースのアクセス制御FAQ ​

新しい権限モデルにより、次の機能が有効になります：

• プロジェクトレベルのアクセス制御：同じEnvironment内のプロジェクトごとに異なるロールを割り当てます。 コラボレーターは、各自のEnvironment内のすべてのプロジェクトで同じ権限を共有する必要がなくなります。
• ユーザーグループベースの権限：コラボレーターグループにプロジェクトアクセス権を付与します。 メンバーはアクセス権を自動的に継承するため、権限管理を拡張可能かつ一貫したものにできます。
• 強化されたロールライフサイクル管理：APIおよびSAML/SCIMを使用して、ロールと割り当てをプログラムで管理します。

権限モデルでは、コラボレーターの権限を次の2種類に分離します：

• Environmentロール：Environmentごとに権限を定義します。 これらのロールは、プラットフォーム設定、管理機能、およびAHQコンソールアクセスを制御します。 管理機能またはAHQにアクセスするには、DevEnvironmentで必要な権限を割り当てます。 テストまたはProdの権限は、ワークスペースレベルには適用されません。
• プロジェクトロール：個々のプロジェクト内で権限を定義します。 これには、フォルダ、コネクション、レシピ、デプロイメントへのアクセス、および管理者権限が含まれます。

Workatoは4つのデフォルトプロジェクトロールを提供します：

• プロジェクトオペレーター：レシピの実行および停止機能を含む表示専用アクセス。
• ビルダー：レシピを作成できますが、デプロイはできません。
• 高度なビルダー：レシピを作成およびデプロイします。
• プロジェクト管理者：すべてのプロジェクトアセットと設定へのフルアクセス。

調整された権限を持つカスタムロールを無制限に作成することもできます。

モデルを有効化する前に、Home Assets（ルート）フォルダを空にする必要があります。 アクセス制御システムの要件を満たすには、すべてのアセットを専用プロジェクト内に保存する必要があります。

アセットをプロジェクトに移行する必要があります。 Workatoは、次のアクションを実行する移行スクリプトを提供します：

• 各EnvironmentでHome Assetsを標準プロジェクトに変換します。
• 同じfolder_idとproject_idを保持します。
• ユーザーがルートに新しいアセットを追加できないように検証を適用します。

準備状況を確認するには、Workato担当者にお問い合わせください。 確認後、その担当者が移行スクリプトを実行します。 権限モデルを有効化する前に、この手順を完了してください。

プラットフォームは、ユーザーが新しいコラボレーターロールを作成できないようにします。 割り当てられたメンバーがいないロールはUIで非表示になりますが、すべてのロールにAPI経由でアクセスできる状態は維持されます。 そのロールを持つユーザーがSAMLまたはSCIM経由でログインすると、プラットフォームがロールを割り当て、UIに再度表示します。

はい。 APIは、レガシーロールを含むすべてのロールへのフルアクセスを提供します。 APIエンドポイントを使用して、完全なリストを取得し、レガシーロールをコラボレーターに割り当てることができます。 コラボレーターが割り当てられていないロールはUIで非表示になります。

権限モデルを有効化する前に、すべてのコラボレーターロールの完全な記録を作成します。 スクリーンショットを撮るか、APIを使用してリストをエクスポートします。 一部のロールは、移行後にUIから消える場合があります。

はい。 プラットフォームは両方のモデルを同時にサポートします。 一部のコラボレーターはレガシーロールを使用し、他のコラボレーターはEnvironmentロールとプロジェクトロールを使用できます。 各コラボレーターは、Environmentごとに1つのモデルを使用する必要があります。 プラットフォームでは、単一のEnvironment内でレガシーロールと新しいロールを混在させることはできません。

移行時に、新しいEnvironmentロールとプロジェクトロールの名前を指定するよう求められます。 Environmentロールとプロジェクトロールは、デフォルトでレガシーコラボレーターロールの名前を使用します。

次のいずれかを選択できます：

• Manage projects権限をEnvironmentロールに追加します。
• Control project access権限をプロジェクトロールに追加します。

移行の開始前に、システムがHTMLサマリーレポートを生成します。 これには次の情報が含まれます：

• ロールに割り当てられたコラボレーター数
• 新しい権限のリスト
• 現在の権限と更新後の権限の並列比較
• 影響を受けるコラボレーターのリスト

その後、プロセスは新しいロールを作成し、コラボレーターを自動的に再割り当てします。 既存のプロジェクトアクセス権と権限はすべて変更されません。

はい。 システムは、移行前にすべての変更を表示する、ダウンロード可能なサマリーレポートを提供します。 これにより、変更を適用せずに更新内容を確認できます。

システムは、これらのコラボレーターを新しいプロジェクトロールに自動的に再割り当てします。 コラボレーターは同じプロジェクトアクセス権を保持し、同等の権限を受け取ります。

はい。 移行プロセスはロール単位で実行されます。 段階的な移行とテストをサポートするために、ロールを移行を個別に実行できます。

いいえ。 システムはロールを1つずつ移行します。 EmbeddedまたはDeveloper APIを使用してロールを移行し、他のロールでプロセスを繰り返すレシピを作成できます。

Automation HQは、継承可能なEnvironmentロールとプロジェクトロールをサポートします：

• 親ワークスペースの管理者は、会社のセキュリティポリシーに基づいてロールを作成します。
• 子ワークスペースはこれらのロールを継承します。 子ワークスペースのコラボレーターはこれらのロールを使用できますが、変更することはできません。
• 親ワークスペースの管理者は、子ワークスペースからCustom roles権限を除外することで、カスタムロールの作成を防止します。

コラボレーターグループは、プロジェクトロールを単位として受け取るコラボレーターの集合です。 個人ではなくグループ全体にプロジェクトアクセス権を付与するには、先にグループを作成してメンバーを割り当てる必要があります。

プラットフォームは、グループからのすべての権限を統合します。 コラボレーターは、いずれかのグループによって付与された最上位のアクセス権を受け取ります。 権限はグループメンバーシップが追加されると常に増加し、競合したり相互に取り消したりすることはありません。

グループの変更は、ページの更新後すぐに適用されます。 コラボレーターがログアウトし、その後SAMLまたはSCIM経由で再度ログインすると、IDプロバイダーはグループメンバーシップを再表明し、暫定的な更新を上書きします。

このEnvironmentレベルの権限により、管理者は次のアクションを実行できます：

• 直接アクセスできない場合でも、Environment内のすべてのプロジェクトの名前を表示します。
• ロールを選択して、任意のプロジェクトに自分自身を追加します。
• ワークスペース全体のプロジェクトアクセス権を監督します。

このプロジェクトレベルの権限により、コラボレーターは特定のプロジェクトのアクセス制御を管理できます。 この権限を持つすべてのコラボレーターは同等の特権を持ち、プロジェクト内で互いのアクセス権を変更できます。

この権限は、委任されたプロジェクトレベルの管理をサポートします。 この権限では、新しいコラボレーターの招待、コラボレーターグループの作成、または新しいロールの定義はできません。 アクセス制御は、プロジェクト内の既存のユーザー、グループ、およびロールに制限されます。

権限モデルでは、明示的なアクセス追跡が導入され、制御が向上します：

• 旧モデル：管理者はすべてのプロジェクトに対するデフォルトの読み取り専用アクセス権を持っていました。 アクセスがいつどこで発生したかを記録するログはありませんでした。
• 新モデル：管理者はすべてのプロジェクト名を表示できますが、アクセスするには明示的にプロジェクトに参加する必要があります。 プラットフォームは、このアクションを監査ログに記録します。

この変更により可視性が向上し、財務データやHRデータなどの機密コンテンツへのサイレントアクセスが制限されます。

プラットフォームは4つのデフォルトEnvironmentロールを提供します：

• アクセスなし：Environmentへのすべてのアクセスをブロックします。
• メンバー：プラットフォームツール権限または管理者特権なしで最小限のアクセス権を付与します。
• Environmentマネージャー：プラットフォームツールへのフルアクセスを付与しますが、ワークスペース管理者特権は除外します。
• Environment管理者：Environment内のすべての権限へのフルアクセスを付与します。

プラットフォームは4つのデフォルトプロジェクトロールを提供します：

• プロジェクトオペレーター：読み取り専用アクセス権と、レシピを実行および停止する機能を付与します。
• ビルダー：ユーザーがフォルダ、レシピ、Workatoアプリ、およびData tablesを変更できるようにします。 このロールではテスト自動化も可能ですが、デプロイメントはできません。
• 高度なビルダー：すべてのビルダー権限に加えて、プロジェクトを承認し、他のEnvironmentにデプロイする機能が含まれます。
• プロジェクト管理者：削除機能を含め、プロジェクトに対する完全な制御を付与します。

お客様は、特定のアクセスニーズを満たすカスタムプロジェクトロールを無制限に作成できます。

すべてのプロジェクトは、デフォルトですべてのコラボレーターグループのアクセスを拒否します。 プロジェクト管理者はこの設定を変更して、Environmentアクセス権を持つすべてのコラボレーターにベースラインアクセスを割り当てることができます。 この設定は、一般的な読み取りアクセスが必要な共有プロジェクトに適しています。

全員にベースラインアクセスを適用するには、すべてのコラボレーターグループを使用します。 チームごとに異なるアクセスが必要な場合は、特定のグループを使用します。 次のガイドラインを検討してください：

• すべてのコラボレーター：共有リソースへの読み取りアクセスなど、ワークスペース内のすべてのユーザーが持つべき権限を割り当てます。
• グループ割り当て：専門的なロールまたは責任が必要なチームにアクセス権を割り当てます。

SAML/SCIMパラメーターはworkato_user_groupsです。 これは、次の既存の属性を補完します：

• workato_role
• workato_role_test
• workato_role_prod

ログイン時にworkato_user_groupsパラメーターが検出されると、プラットフォームはEnvironmentロールとプロジェクトロールを使用して権限モデルを適用します。 パラメーターがない場合、システムはデフォルトでレガシーロール割り当てロジックを使用します。

例:

workato_role: "WorkspaceAdmin"
workato_role_test: "TestEnvAdmin"
workato_role_prod: "ProdEnvAdmin"
workato_user_groups: "HR developers, Marketing Admin"

プラットフォームは、コラボレーターにレガシーロールを割り当てます。 SAMLは、ロール割り当ての信頼できる情報源として引き続き機能します。 workato_user_groups parameterがない場合、システムは次の動作を適用します：

• ログイン時にコラボレーターにレガシーロールを割り当てます。
• 新しいEnvironmentロールとプロジェクトロールを管理者に表示したままにします。
• SAML移行が完了するまで、両方のロールモデルをシステムに表示します。

プラットフォームの動作は、workato_user_groupsパラメーターの有無によって異なります。 次のロジックが適用されます：

• 存在しない場合：指定されたロールが存在しない場合、システムはレガシーモデルを使用し、デフォルトのOperatorロールを割り当てます。
• 存在する場合：指定されたロールが定義済みロールのいずれにも一致しない場合、システムは権限モデルを使用し、アクセスなしロールを割り当てます。

この動作により、入力ミスによる過剰な権限を防ぎ、管理者が設定エラーを早期に検出しやすくなります。

workato_user_groupsが空の場合、プラットフォームはコラボレーターにプロジェクトアクセス権を割り当てません。 これらのユーザーには、アクセス可能なプロジェクトがない空のワークスペースが表示されます。

管理者は、新しいユーザーに可視性を確保するために、すべてのコラボレーターシステムグループにデフォルトのプロジェクトアクセス権を設定できます。

workato_user_groups属性の値を区切るにはカンマを使用します。 例:

HR developer, Marketing Admin

グループ名は大文字と小文字が区別されます。

SSOログイン時に不一致またはコンテキスト不足が検出された場合、プラットフォームはデフォルトでメンバーロールを使用します。 workato_role属性を使用してEnvironment管理者ロールを割り当てる場合は、workato_user_groupsパラメーターも含める必要があります。

workato_user_groupsがない場合、プラットフォームはworkato_roleをカスタムロールとして扱います。 workato_roleが定義済みロールのいずれにも一致しない場合、システムはデフォルトのメンバーロールにフォールバックします。

次の手順で権限モデルを使用できます：

必要なプロジェクトにのみ、デプロイメント権限を持つプロジェクトロールを割り当てることができます。 この設定により、チームは次のことができます：

• ITの介入なしに独自のレシピをデプロイします。
• 各自のプロジェクトからデプロイするレシピを選択します。
• 他のチームのプロジェクトや共有サービスの変更を回避します。
• チームの範囲内でデプロイメント制御を維持します。

ビジネスユニット用のコラボレーターグループを作成し、必要なプロジェクトにカスタム読み取り専用プロジェクトロールを割り当てます。 この設定により、特定のコンテンツへのアクセスが制限され、他のプロジェクトや不要な権限への露出を防止できます。

コラボレーターを複数のグループに割り当てます。 プラットフォームはすべての権限を集約し、いずれかのグループから最上位のアクセス権を付与します。 例:

• マーケティングチームのメンバー：Marketingプロジェクトのプロジェクトオペレーターロールを割り当てられています。
• 高度な開発者のメンバー：Marketingプロジェクトの高度なビルダーロールを割り当てられています。

この場合、コラボレーターはMarketingプロジェクトに対して両方のロールから統合された権限を受け取ります。

すべてのコラボレーターグループを使用して、ベースラインアクセスを割り当てます。 次の設定を適用します：

Project administration - Access control権限を使用して、プロジェクトレベルのアクセス管理を委任します。 プロジェクトオーナーは、割り当てられたプロジェクトへのアクセスのみを管理できます。 新しいコラボレーターの招待、ロールの作成、または新しいグループの定義はできません。 プロジェクトオーナーは、既存のロールとグループのみを割り当てることができます。 プラットフォームは変更を監査ログに記録します。

Environment間のアクセスを管理するために、2つのカスタムプロジェクトロールを作成します。 有効になっている場合はレビューを含め、デプロイ権限とともにプロジェクトへのフルアクセスを付与するPower Userロールを定義します。 デプロイ権限付きの読み取り専用アクセスを付与するCI/CD Operatorロールを定義します。

最小限のプラットフォームアクセスを提供するために、すべてのEnvironmentでメンバーなどの基本Environmentロールを割り当てます。

Environmentごとにプロジェクトロールを適用します：

• Dev：Power Userロールを割り当てます。
• テスト：CI/CD Operatorロールを割り当てます。
• Prod：CI/CD Operatorロールを割り当てます。

この設定により、コラボレーターにはDevでフルアクセスが付与され、テストとProdの両方でデプロイ権限付きの読み取り専用アクセスが付与されます。

プロジェクトが存在しない場合、プラットフォームはプロジェクトを自動的に作成します。これにより、セキュリティリスクが生じる可能性があります：

• コラボレーターは、EnvironmentロールでCreate projects権限を持っている必要があります。
• デプロイメントによって新しいプロジェクトが作成されると、コラボレーターはデフォルトでプロジェクト管理者アクセスを受け取ります。

これにより、意図した制限が上書きされ、プロジェクトレベルの完全な権限が付与されます。

最初のデプロイメント前に、Create projects権限を持つ管理者がテストとProdに空のプロジェクトを作成し、CI/CD Operatorなどの適切なプロジェクトロールを割り当てることをお勧めします。

デプロイメント権限は、ソースEnvironmentとターゲットEnvironmentの両方のプロジェクトロールに依存します。 デプロイメントを完了するには、コラボレーターに次の権限が必要です：

• ソースEnvironment（Dev）でのデプロイ権限。
• テストやProdなど、ターゲットEnvironmentでのデプロイ権限。
• 初回デプロイメント中にプロジェクトを初期化するための、ターゲットEnvironmentでのCreate projects権限。

この設定は、Environment間で異なるデプロイメントロールをサポートし、より厳格なアクセス制御を可能にします。

APIキーはEnvironment固有です。 権限は個々のEnvironmentに関連付けられているため、プロジェクトアクセス権を管理するにはEnvironment（Dev、テスト、Prod）ごとに別のAPIキーを使用する必要があります。

プラットフォームは、アクセス対象に応じてAPIエンドポイントを異なる方法で処理します：

• コラボレーターおよびレガシーコラボレーターロールのエンドポイントは、後方互換性のためDevEnvironmentでのみ機能します。
• コラボレーターグループおよびEnvironment/プロジェクトロールのエンドポイントは、Environmentに関係なく同じレスポンスを返します。

はい。 Embedded APIまたはDeveloper APIをWorkatoアプリと併用して、権限管理を簡素化するツールを構築できます。 たとえば、ソースプロジェクトを選択し、そのプロジェクトアクセスマトリックスを複数のターゲットプロジェクトにコピーできます。 詳細については、次のAPIドキュメントを参照してください：

Developer API：

• レガシーロール：古い権限モデルを使用するロールを管理します。
• ロール移行：古い権限モデルから新しいモデルにロールを移行します。
• Environmentロール：Environmentレベルでアクセスを制御するロールを管理します。
• プロジェクトロール：プロジェクトレベルでアクセスを制御するロールを管理します。
• コラボレーターグループ：グループを使用して、複数のコラボレーターの権限を一度に標準化および管理します。
• プロジェクト許可：プロジェクトロールの割り当てを管理します。
• ワークスペースコラボレーター：コラボレーターとその特権を管理します。

Embedded API：

• レガシーロール：古い権限モデルを使用するロールを管理します。
• ロール移行：古い権限モデルから新しいモデルにロールを移行します。
• Environmentロール：Environmentレベルでアクセスを制御するロールを管理します。
• プロジェクトロール：プロジェクトレベルでアクセスを制御するロールを管理します。
• コラボレーターグループ：グループを使用して、複数のコラボレーターの権限を一度に標準化および管理します。
• プロジェクト許可：プロジェクトロールの割り当てを管理します。
• 顧客ワークスペースコラボレーター：顧客ワークスペースにコラボレーターを招待します。
• 顧客の管理：顧客とそのワークスペースコラボレーターを管理します。

次の項目を順番に確認してください：

• SAML設定には、workato_user_groupsパラメーターが含まれます。
• グループ名が完全に一致していること。 これらの値では大文字と小文字が区別されます。
• workato_role、workato_role_test、およびworkato_role_prodパラメーターのEnvironmentロール名が正しいこと。
• 設定変更後、コラボレーターがSSO経由で再度ログインしていること。