先週の金曜日は「CSPM で設定ミスを自動検知する」という話をしました。
でも、CSPM が全部を救うわけではありません。

一番危険な設定ミスは、**「人間に関する設定」**だからです。
具体的には：

  • 「退職者のアカウントがまだ生きている」
  • 「開発チームが全員『管理者権限』を持っている」
  • 「『一時的に強い権限をあげた』が、そのまま放置」

これらはツールで“検知”できても、根本的な解決には「誰に、何の権限を与えるか」という設計思想の転換が必要です。
それが今週のテーマ、「IAM（Identity and Access Management）」です。

目次 [ close ]
  1. IAM = 「誰が、どこに、何ができるか」の台帳
  2. 「最小権限の原則」という武器
  3. 「退職者アカウント」が生きているリスク
  4. IAM導入の「段階的進め方」
  5. Phase 1（今月）：棚卸し
  6. Phase 2（来月）：MFA強制
  7. Phase 3（3ヶ月目）：「最小権限」への再設計
  8. Phase 4（6ヶ月目）：IDaaS導入
  9. 今週、現場がやるべきこと（1時間でできる）
  10. 火曜日との繋がり
  11. 問いかけ
  12. 参考（リンク）

IAM = 「誰が、どこに、何ができるか」の台帳

難しく聞こえますが、IAM は要は「会社の権限管理」を、クラウド時代に合わせた形にしたものです。

昔の会社では：

  • 「この人は営業部だから、営業向けシステムにログインしてOK」
  • 「このファイルサーバーへのアクセス権は、管理者が判子を押した」
  • 「退職したから、全部のアクセス権を手作業で削除」

これを手作業でやっていたのが、クラウド時代には膨大になりました。
SaaS が 100個あれば、100個全部でアカウント作成・権限付与・削除をする必要があります。
手作業ではまず無理です。

IAM は、この「権限管理」を中央集約して、自動化するための仕組みです。

「最小権限の原則」という武器

セキュリティ界隈では、「最小権限の原則（Least Privilege）」という鉄則があります。
要は：「その人が仕事をするのに必要な権限は何か」を最小限に絞る、ということです。

例えば：

  • 営業担当者が CRM（Salesforce）を使う → 「自分の案件データを見て、編集できる」権限だけ（全社の売上データを見る権限は不要）
  • 新入社員が初日に「全システムアクセス権あります」 → これは「最小権限」の逆で、実質「最大権限の原則」です。
  • テスト環境で「一時的に全権限を付与」→ 本番に昇格した時に権限削除を忘れる → テスト環境の悪癖が本番に持ち込まれます。

金融機関では、この「最小権限」がものすごく徹底されています（与信権限は部長クラスだけ、上限額つき、など）。
民間企業も、クラウド時代にはこの思想を採用すべきです。

「退職者アカウント」が生きているリスク

現場で見かける、ぞっとするケース。

  • 「Aさんが3年前に退職したんですが、まだSlack に『アクティブユーザー』として登録されていました」
  • 「AWS のクレジットカード情報アクセス権が、去年辞めた人のアカウントのまま」

これは単なる「管理ミス」では済みません。
悪意ある人間が、会社の機密にアクセスし続けることができる状態だからです。

だからこそ、（金融の文脈では特に）アクセス権レビューやアクセス管理の適切性が重要論点になります。

IAM導入の「段階的進め方」

いきなり「完璧な IAM を入れよう」と言うと、億単位の予算が必要です。
段階的に進める方法を示します。

Phase 1（今月）：棚卸し

全クラウドサービス（AWS、Azure、Salesforce、Slack など）で「誰が何の権限を持ってるか」をスプレッドシートに書き出す。
「あれ、この人もう辞めてる」「この権限は何に使ってるの？」という発見が出ます。

Phase 2（来月）：MFA強制

「管理者権限を持つ全員に MFA（多要素認証）を強制」する。
“パスワードだけ”の管理者は、いずれ事故ります。

Phase 3（3ヶ月目）：「最小権限」への再設計

「本当にこの人にこの権限は必要か」を1つずつ問い直す。
特に「過去に一時的に与えた権限」を洗い出す。

Phase 4（6ヶ月目）：IDaaS導入

Okta、Azure AD（Microsoft Entra ID）などを検討し、「入社・異動・退職」に合わせてアカウント発行/剥奪が自動化される状態を目指す。

今週、現場がやるべきこと（1時間でできる）

経営が決めるのは「IAM の重要性」ですが、現場がやるべきは「今の状況を見える化」です。

  • 退職者のアカウント確認：Slack、Salesforce、AWS などで「去年以降に退職した人」を洗い出し、まだアクティブなら即無効化する。
  • 管理者権限の確認：AWS の IAM で Administrator 相当の権限が付いている人は誰か？本当に必要か？を確認する。
  • MFA設定の確認：管理者権限を持つのにパスワードだけ、という人がいないか確認し、MFAを必須化する。
  • 「一時的」権限の探索：「テスト用だからroot相当を付与した」などの“暫定措置”が残っていないか洗い出し、即削除する。

火曜日との繋がり

火曜日に「規制が攻めるためのガイドライン」という話をしました。
金融庁のITガバナンスの文脈でも、アクセス管理の適切性は重要テーマとして扱われています。

つまり、IAM をちゃんとやることは：

  • セキュリティリスクを下げるだけでなく
  • 監査に強い証跡を作り
  • その上で「新しい技術に安心して投資できる環境」を作る

ということです。

問いかけ

退職者のアカウント、確認したことありますか？
「ずっと放置」だとしたら、その人が“会社の裏鍵を持ったまま”という状態です。​
来週の火曜日は「DX 担当が兼務で死んでる問題」を、組織設計の視点で切り込みます。

参考（リンク）

必要なら、この回のアイキャッチ画像も「退職者アカウント＝裏鍵」「最小権限＝細い鍵束」みたいな比喩で、シリーズのトンマナ（ネイビー基調）に合わせて作れます。