営業担当が案件を成約させるために制限されたオブジェクトへの一時的なアクセスが必要になり、権限が付与されたものの二度と取り消されない。マネージャーが新しい役に就いたが、以前の役職のアクセス権をそのまま保持している。コンサルタントが導入中に管理者権限を与えられ、そのまま放置される。元の権限セットに何が含まれていたか誰も確認せずに、権限セットが複製される。
個々に見れば、どれも重大な決定には思えません。しかし、これらが積み重なることで、誰も設計しておらず、誰も完全には理解していないアクセス権限の景観が作り出されます。これにより、何か重大な問題が発生するまでめったに表面化しないリスクが生まれるのです。
なぜ「権限の肥大化」が起きるのか
Salesforceのセキュリティモデルは極めて複雑です。プロファイル、権限セット、権限セットグループ、ロール階層、共有ルール、フィールドレベルセキュリティ、オブジェクトアクセス——それぞれの層が相互に作用する仕組みは、経験豊富な管理者にとっても直感的ではない場合があります。立ち上げたばかりの組織であればこの複雑さも管理可能ですが、何十人もの管理者と何百人ものユーザーを抱え、単発の設定変更を繰り返しながら5年〜10年運用されてきた組織では、「誰が何を見ることができ、何を行えるのか」の全体像を把握することはほぼ不可能です。
この問題を慢性化させているのは「手軽さ」です。Salesforce管理者は通常、ビジネスを止めることなくスムーズに進めること（新しいユーザーのオンボーディング、商談サイクルの支援、新しいワークフローの有効化など）に集中しています。権限を「付与」するのは数秒で済みます。しかし、その権限が「まだ存在するべきか」を監査するには、ほとんどのチームが持っていない時間とツールが必要です。結果として、アクセス権は絶え間なく追加され、削除されることはまずないという「一方通行のラチェット構造」が完成します。
また、組織全体のアクセス状況に責任を持つ単一の所有者が存在しないことも珍しくありません。所有者がいなければ、「この人物にこの権限がまだ必要なのか？」という最も重要な問いを投げる人もいなくなります。
「管理者は、特定のレポート作成や連携の課題を解決するために、オブジェクトレベルの『すべて表示／すべて変更』（あるいは組織全体の『すべてのデータの参照／すべてのデータの変更』）を付与し、そのまま元に戻さず放置しがちです。これにより、その権限セットを持つすべてのユーザーに対して、共有ルール、OWD（組織全体の共有設定）、レコードレベルの制限がサイレントに無効化されてしまいます」 Tapas Tripathi（タパス・トリパティ）（Cloud Protection for Salesforce, Salesforce Architect）
なぜ放置されてしまうのか
根本的な問題は「可視性の欠如」です。ほとんどの組織は、Salesforce内で誰が何にアクセスできるのかを示す明確で最新のマップを持っていません。標準のレポート機能でもある程度の情報は抽出できますが、プロファイル、権限セット、共有ルールの相互作用を考慮した「実質的な権限」の有意義な全体像を得るには、膨大な手作業が必要です。ほとんどのチームにとって、トラブルが起きる前にその労力を正当化することは困難です。
さらに「組織的なギャップ」もあります。Active Directoryや基幹インフラにおいてはアクセス権の定期監査が標準的実務となっていますが、Salesforceに同様の厳密さが適用されることは滅多にありません。ITセキュリティ、Salesforce運用管理、コンプライアンスのいずれの部門にも明確に属していないため、エアポケットに落ちてしまいがちなのです。結果として、最小権限の原則に基づく基本監査で落第するような権限設定が、「誰も見ていない」という理由だけで何年も放置されることになります。
「最小権限のプロファイルを一から作成する代わりに、チームは管理者プロファイルを複製してチェックボックスを数個外すだけで済ませてしまいます。元となるプロファイルが非常に強力であるため、ユーザーの管理、すべてのデータの変更、Apexの作成、アプリケーションのカスタマイズといった強力な権限が、クリーンアップ後も気づかれずに残ってしまうのです」 Tapas Tripathi
事態が悪化した際の影響
権限が過剰に付与されたアカウント自体が情報漏洩を引き起こすわけではありません。むしろ、その深刻度を決定づける要因となるのです。標準ユーザーアカウントを標的としたフィッシング攻撃は、単に「不運な一日」に過ぎません。しかし、システム管理者権限、すべてのデータに対する変更権限、あるいは広範なデータエクスポート権限を持つアカウントを標的とした同じ攻撃は、まったく異なるインシデントとなります。パイプラインの全容が丸見えになり、記録を大規模に流出させたり破壊したりする能力が得られ、さらには接続されたシステムへの侵入経路となる可能性さえあります。権限モデルは、単にユーザーが何ができるかを定義するだけではありません。何か問題が発生した際の被害範囲を定義するものでもあるのです。
これは内部者リスクについても同様です。通常の営業担当者のアクセス権限を持つ退職予定の従業員でも、損害を与える可能性があります。長年の勤務を通じて権限が拡大してきた従業員であれば、その被害はさらに甚大になるでしょう。また、権限の拡散は目に見えないため、セキュリティチームは事後になって初めて、その従業員がどのような行動をとることができたのかを知るケースが少なくありません。
設定ミスの影響も無視できません。共有ルールが過度に寛容すぎると、業務上の理由がないユーザーに意図せずレコードが公開されてしまう可能性があります。フィールドレベルのセキュリティ上の脆弱性により、契約金額、個人情報、戦略的顧客の詳細といった機密データが、意図したよりもはるかに多くのユーザーに閲覧されてしまう恐れがあります。
まとめ（今後の対策）
権限ギャップを埋めるための第一歩は、「可視化」を手に入れることです。つまり、組織内のすべてのユーザーの「実質的な権限」を確認できるようにすることを意味します。割り当てられたプロファイルだけでなく、適用されているすべての権限セット、共有ルール、ロール階層の組み合わせによる「最終的なアクセス結果」を把握しなければなりません。
そこから、「定期的な監査サイクル」を構築します。現在の役割を反映していないアクセス権の特定、休眠アカウントの検出、特定の事情で一時的に付与した例外権限が永久化しないようにするための構造化されたプロセスです。これは一回限りのプロジェクトではなく、日常的な運用プロセスであり、誰も実行する時間がないような手作業ではなく、プロセスを持続可能にするための適切なツール選定が必要となります。
「権限ギャップ」の問題は地味で目立たず、華やかさもありませんが、ほぼ確実に防ぐことができる問題です。だからこそ、今すぐに取り組む価値があるのです。