ACSのアクセス管理は、ユーザーの追加だけで完了しません。Admin Consoleでのユーザー管理と、ACSのロール・セキュリティグループ・組織単位を組み合わせて、できる操作と扱えるデータを決めます。送信担当や閲覧担当という業務名を、そのまま既定ロール名と考えないことが出発点です。
ユーザーはAdmin Consoleで管理する
利用者の追加や製品への割り当てはAdmin Console側で行い、ACS側のセキュリティグループとの対応を確認します。独自グループを使う場合は、Admin Consoleの製品プロファイルとACS側のID等を公式手順に沿って対応させます。個人を特定できるアカウントを使い、申請者、承認者、付与した範囲、理由を残すと、異動や退職時にも追跡できます。
操作権限は公式のロール名で確認する
公式一覧にはAdministration、Data model、Generic import、Prepare deliveries、Start deliveries、Workflow等があります。Prepare deliveriesは作成・変更・準備・削除ができても送信はできず、Start deliveriesには送信が含まれます。Workflowロールだけでは、ワークフロー内の配信でも送信できません。Generic importにはWorkflowも必要です。「編集者なら送信も可能」等の推測で担当を割り当てないでください。
既定グループと独自グループを分ける
既定グループにはAdministrators、Delivery supervisors、Standard Users、Workflow supervisorsがあり、用途に応じた権限が設定されています。既定グループ自体の変更を前提にせず、必要に応じて独自のグループを設計します。内部処理用のDeliverabilityやmcExecを、一般の業務担当に割り当てる運用は避けます。管理者数も一律に決めず、交代時や不在時を含めて管理を継続できる体制にします。
複数グループの権限は足し合わされる
グループを追加すると、制限が強まるとは限りません。複数グループのロールは累積し、組織単位の範囲も考慮して最終的なアクセスが決まります。閲覧用グループに加えて広い権限のグループが残っていると、期待した制限になりません。付与時には一つのグループだけを見るのではなく、その人が所属するすべてのグループと有効な権限を確認します。
組織単位でデータの範囲を設計する
組織単位では、自分と配下に読み書き、上位に読み取り、並列の単位にはアクセスできないという階層の考え方を確認します。Allは狭い制限を表しません。プロフィールを組織単位で区分するには、アクセス権管理の項目を含むリソース拡張等の設定が必要になります。組織図を作っただけで、既存の全顧客が自動的に適切な区画へ分かれるとは考えないでください。
許可と拒否の両方を試験する
運用開始前に、担当者相当のアカウントで「必要なデータが見える」「担当外のデータは見えない」「準備できるが送信はできない」等を確認します。異動時は追加だけでなく旧所属の解除、退職時は製品アクセスの削除、連携用資格情報の影響も確認します。利用できる記録の種類や保持範囲は環境ごとに確認し、すべての操作が一つの監査ログへ残ると決めつけずに定期点検します。
導入前の確認事項
- Admin ConsoleとACSのグループが対応しているか
- 送信権限と準備権限を区別したか
- 複数グループを含む最終権限を確認したか
- 組織単位とプロフィール区分を別々に確認したか
- 異動・退職・管理者不在時の手順があるか
公式資料・関連記事
関連記事：Adobe Campaign Standardの全体像と運用手順、ACSのメール配信｜作成から本番確認まで、ACSのWorkflow｜設計・実行と停止時の確認。
運用設計や確認項目の整理は、現在の業務と対象URLを添えて株式会社AOへご相談ください。
公式資料の確認日：2026年11月2日。記入例や手順は編集上の提案で、導入成果を保証するものではありません。
コメント