結論
権限ロールが「管理者（フルアクセス）」と「一般（閲覧のみ）」の2つしかないSaaSでは、システムの中だけで職務分掌（特権IDの分離）は作れません。私は複数の事業会社でこの壁に当たり、最終的に「アカウントの分離を土台に、事前統制を外に出し、事後統制で補う」形に落ち着きました。監査には、予防的コントロールが組めない事実をそのまま認めたうえで、発見的コントロールで補っていると説明しています。
この記事は、その「できなかったこと」と「代わりにやったこと」と「監査での言い方」を、順に書いたものです。
1. 破れていた形
情シスや運用メンバーが数人で、admin@company.com のような共通の管理者アカウントを使い回している。設定を変えたのも、それを承認したのも、同じアカウント。ログに残るのは「admin が変更した」だけで、誰が操作し、誰が承認したのかは、あとから誰にも分かりません。
もう一つの形は、日常の閲覧・操作に使うアカウントに管理者権限が付いたままになっていることです。悪意がなくても、手が滑れば設定が変わります。
職務分掌の目的は「1人で完結させない」ことですが、どちらの形も、1人どころか「誰だったか」すら残らない状態でした。
2. なぜ製品側で解けないのか
このSaaSの権限ロールは2つだけです。
- 管理者：すべての操作ができる
- 一般：閲覧だけ
「設定変更はできないが承認はできる」といった中間のロールは作れません。これは製品の仕様で、良し悪しの話ではありません。ただ、職務分掌を考える側からすると、分離の道具がシステムの中に無い、ということになります。
3. 分離しようとして、できなかったこと
ここが、いちばん書いておきたい部分です。
特定の操作だけを絞ることができない。 「ユーザーの追加はさせたい。しかし全データのCSVエクスポートは防ぎたい」。この設定は、権限仕様上できませんでした。ユーザー追加をさせるには管理者権限を渡すしかなく、管理者権限を渡すということは、エクスポートを含む全権限を渡すということでした。
システムの中に「もう1人の承認」を挟めない。 重要な設定変更に対して、別の人が承認してから反映される仕組み（セカンド承認）は、この製品にはありません。管理者1人の操作が、その場で本番に反映されます。
この2つが「できない」と分かった時点で、システムの中で予防的に止める設計は諦めました。諦めたうえで、何で補うかを考えるのが次です。
4. 代替の設計
土台と、その上に乗せる2層で考えました。
| 層 | 統制の種類 | 中身 |
|---|---|---|
| 上 | 事後統制（発見的） | ④ 管理者ログイン・重要な設定の変更を即時に通知し、第三者が日常的に見る |
| 中 | 事前統制（予防的・ただしSaaSの外） | ② 申請と上長承認を、SaaSの外のワークフローで ③ 承認が通った時間帯だけ、管理者グループに入れる |
| 土台 | アカウントの分離 | ① 1人2アカウント（日常用＝一般／作業用＝管理者） |
① アカウントの分離（土台）
1人に2つのアカウントを持たせます。日常の閲覧・操作は一般権限のアカウントで、管理作業だけ管理者権限のアカウントで行う。共通アカウントは廃止します。
これだけで「誰が操作したか」は残るようになります。ただし「誰が承認したか」はまだ残りません。
② 申請フローの外部化（事前統制）
SaaSの中に承認が組めないので、承認をSaaSの外に出します。管理作業をするときは、先に社内のワークフローで申請し、上長の承認を得てから、管理者アカウントでログインして作業する。この順番を運用ルールにしました。
特定のツールは要りません。チケット、申請フォーム、チャットの承認スレッドでも成立します。要るのは「申請と承認の記録が、作業より前の時刻で残る」ことだけです。
③ 時限付き権限付与（事前統制）
通常時は全員を一般権限のグループに置き、申請が承認された時間帯だけ、IdP側（またはSaaS側のグループ機能）で管理者グループに一時的に入れます。作業が終わればグループから外す。
これで、管理者権限が「常時付いている」状態を無くせます。②の承認記録と、③の付与・解除の記録を突き合わせると、「承認された時間の外で管理者権限が使われたか」も確かめられます。
④ ログ監視通知（事後統制）
管理者アカウントのログインと、重要な設定の変更が起きた瞬間に、専用の監視チャンネルへ通知を飛ばします。見るのは作業者本人ではなく、第三者です。日常的に流れてくるので、「承認の無い管理者ログイン」があればその日のうちに気づけます。
①〜③で防ぎきれないものを、④で見つける。この関係を崩さないことが、設計の要でした。
5. 監査での言い方
監査で「このSaaSは職務分掌が組めていませんね」と指摘されたとき、私はこう説明しています。
当該SaaSの仕様上、システム内での権限分離（予防的コントロール）は不可能です。そのため、事前申請の別ツール化と、事後ログの即時通知・第三者チェック（発見的コントロール）を組み合わせることで、特権乱用リスクを許容可能な水準まで低減・担保しています。
ポイントは、「できません」で終わらせないことです。できない事実は隠さずに言う。そのうえで「だからこう補っている」まで言う。監査対話は、この変換ができるかどうかで変わります。
一般形にすると、こうなります。
- 予防的コントロールが組めない場所を、仕様の事実として特定する
- 組めない理由を、製品の良し悪しではなく仕様として書く
- 代わりに置いた統制を「事前（システムの外）」と「事後（発見）」に分けて示す
- 2つの統制の記録が突き合わせ可能であることを示す（承認の時刻と、権限付与・操作の時刻）
- 残るリスクを「低減」と言い、「無くなった」とは言わない
この形にしておくと、製品が変わっても、監査人が変わっても、同じ説明が使えます。NIST CSF 2.0 や ITGC の観点でも、「アクセス管理」と「監視」の両方で証跡が出せる状態になります。
最後に
この記事で書いたのは、製品仕様の限界を運用と周辺ツールでどう補い、それを監査にどう説明したか、です。「予防が無理なら発見で補う」は、権限が2種類しかないSaaSに限らず、統制を設計する場面の多くで使える考え方だと思っています。
私は SecuROI で、こうした統制の現在地を同じ物差しで測り続ける仕組みを作っています。