Workatoの活用が広がり、レシピが組織の中核的なシステム連携を担うようになると「誰が、どのレシピやコネクションにアクセスできるか」の厳格な管理（ガバナンス）が必須となります。
本記事では、Workatoのロール管理機能（Role-Based Access Control：RBAC）を用いたセキュリティ戦略と、より詳細な新たなアクセス制御モデルについても解説します。
1. Workatoにおけるセキュリティとリスク：なぜ権限管理が重要なのか？
iPaaSであるWorkatoは、Salesforce、ERP、人事システムなど、企業の機密データが集まるシステム群を繋いでいます。
リスクシナリオ：権限の過剰付与
1. セキュリティガバナンスリスク： フル権限を有したシステムのコネクションを、誤ってレシピ作成者によって連携してしまい、本来閲覧権限のない機密データ（例：給与情報や顧客の個人情報など）が、レシピを通じて意図しない外部システムへ流出したり、不特定多数のユーザーに公開されてしまう。
2. オペレーションミス（操作ミス）リスク： 開発環境でのテスト中に、誤って本番環境のレシピを停止・削除してしまう。
これらのリスクを防ぐため、システム開発における基本原則である最小権限の原則（Principle of Least Privilege 以下PoLP）Workato環境に適用する必要があります。
2. Workatoの標準ロールとPoLPの適用
Workatoには、ユーザーの役割に応じて複数の標準ロールが用意されていますが、PoLPを徹底するためには、これらの組み合わせやカスタムロールの設計が重要です。
ロール管理については、新しい体系がお客様によっては適用されています。
詳細は「3.2. New Role-Based Access Control Model」に記載しておりますので、併せてご覧ください。
PoLP適用については、会社様ごとのセキュリティレベルによっても変化すると思います。そのため、以下で記載している内容は参考としてお考え下さい。
| ロール | 主な権限 | PoLP適用の視点 |
|---|---|---|
| Admin | 全ての操作（ユーザー管理、アカウント設定、全てのレシピ/コネクションの編集・削除） | 極力付与しない 最終的なガバナンス責任者に限定 |
| Analyst | レシピの閲覧、ジョブ履歴の確認、利用状況の分析 | レシピの作成・修正やカスタムコネクタを構築およびテストするレシピビルダーに付与 |
| Operator | レシピの実行、開始/停止、ジョブの再試行（リトライ） | 本番レシピの監視・運用担当者に限定。レシピの作成・削除は不可 |
参考ドキュメント
カスタムロールによる権限の分離
標準ロールでは対応できない場合、カスタムロールを作成し、より細かく権限を定義します。特に、レシピの編集権限と、それを実行・監視する権限を分離することが重要です。
・開発者ロール: レシピの作成・編集は許可
ただし、本番環境のコネクションにはRead-only、またはアクセス不可とする
・運用エンジニアロール: 本番レシピの実行と停止、ジョブのリトライは許可
レシピの編集は禁止
3. ガバナンスを効かせるための鍵：リソースアクセス制御
Workatoにおいて、ガバナンスの要となるリソースは「コネクション」と「プロジェクト」です。
3.1. コネクションの分離とアクセス制御
コネクションはAPIキーなどの機密情報を含むため、アクセスを厳格に管理する必要があります。
推奨される設計:
・開発（Dev）環境と本番（Prod）環境でコネクションを完全に分離する。
・本番コネクションには、Adminおよび特定の運用エンジニアのみが編集できる権限を設定する。
・一般的なレシピ開発者は、本番コネクションの資格情報を参照できないようにする
3.2. New Role-Based Access Control Model
従来のWorkatoでは、レシピのアクセス制御はアカウント全体に及びがちでした。しかし、新機能である環境ごと・プロジェクトごとのアクセス制御を導入することで、環境単位およびプロジェクト単位で、そこに属するレシピやコネクションに対し、ユーザーのロールとは別にアクセス権限を設定できるようになるため、より柔軟かつ厳格なガバナンスが可能になります。
3.2.1 環境ロール (Environment Roles)
ワークスペース（環境）全体の設定や、どのプロジェクトにアクセスできるかを制御するロールです。
| ロール | 主な権限 | できること | PoLP適用の視点 |
|---|---|---|---|
| Environment Admin | 最強権限 | 全プロジェクトへのアクセス、ユーザー招待、セキュリティ設定、監査ログの閲覧など、環境内のすべての操作が可能 | ワークスペース全体で数名に限定 SSOや監査ログの設定が必要な人以外には付与しない |
| Environment Manager | 環境の保守担当 | プロジェクトの新規作成や、共通ツールの管理が可能だが、ユーザー管理やワークスペース全体のセキュリティ設定は制限 | 「基盤担当者」に付与 プロジェクトの中身は見えないため、セキュリティを保てる |
| Member | 一般利用者 | 基本的にプラットフォーム全体の管理権限は持たず、個別に割り当てられた「プロジェクト」内でのみ作業を実施 | その他の方を原則全員 環境の設定変更はさせず、「プロジェクト」単位でのみ権限を付与 |
参考ドキュメント
3.2.2. プロジェクトロール (Project Roles)
特定のプロジェクト（フォルダやレシピのまとまり）内で「何ができるか」を定義するロールです。
| ロール | 主な権限 | できること | PoLP適用の視点 |
|---|---|---|---|
| Project Admin | プロジェクトの管理 | プロジェクト内のレシピ・コネクションの作成、編集、削除に加え、他ユーザーのプロジェクトへの追加・権限割り当てが可能 | 各プロジェクトに1～数名配 そのプロジェクト内のメンバー追加や削除を対応 |
| Advanced Builder | 高度な開発者 | レシピの開発・テストに加え、本番環境へのデプロイが可能 | 「デプロイ」が必要な人にのみ付与 |
| Builder | 開発者 | レシピの作成、編集、テストが可能だが、他の環境へのデプロイ権限は持たない | 勝手に本番環境へ反映できないように制限 |
| Project Operator | 運用担当 | レシピの内容確認（閲覧）と、レシピの開始・停止、ジョブ履歴の確認のみが可能で、編集は不可 | 「レシピが動いているか」を確認するだけの人に付与 レシピの書き換えは一切禁止し、事故を防ぐ |
参考ドキュメント
従来モデルとの大きな違い
・プロジェクト単位のアクセス制御: 以前はプロジェクト単位で制限を細かに分けることが不可であったが、「人事プロジェクトでは編集権限があるが、経理プロジェクトは閲覧のみ」という制限をかけられる
・コラボレーターグループ: ユーザー個人ではなく「開発チーム」「運用チーム」といったグループに対してロールを割り当てられるようになり、人事異動時の権限変更を容易に
この機能により、組織は「環境」「プロジェクト」という実務単位でアクセス権限を閉じ込めることができ、PoLPをより詳細に実現できるようになります。
4. 運用と監査による継続的なガバナンス
ロール設定は一度やったら終わりではありません。適切な運用と監査を通じて、ガバナンスの有効性を維持する必要があります。
1.定期的なロールレビュー : ユーザーの異動や退職に合わせて、付与されているロールが現在も適切であるかの定期的な見直し
2.監査ログの活用 : Workatoの監査ログ（Audit Log）機能を利用し、「誰が」「いつ」「どのコネクションの認証情報を変更したか」「どのレシピを削除したか」といった操作の追跡
→これにより、問題発生時の原因特定や、不正アクセスの有無を確認できます。（Audit Logはご契約プランによってご利用いただけるか異なります）
まとめ
Workatoのロール管理は、単にユーザーを分類するだけでなく、組織のガバナンスとセキュリティ体制を支えるための戦略的な機能です。カスタムロールや新機能のプロジェクトベースのアクセス制御を積極的に活用することで、最小権限の原則を徹底し、信頼性の高い統合プラットフォームを維持できます