IAM（Identity and Access Management）の設計は、クラウドセキュリティにおいて非常に重要な要素です。しかし実務では、「設計はしたが抜け漏れがあった」「気づかないうちにリスクが蓄積していた」といったケースが少なくありません。
その理由はシンプルで、IAMは設計しただけでは安全にならないからです。アカウント管理、認証、認可、ログ、ライフサイクルなど、複数の観点が絡み合うため、一部でも見落とすとそこがセキュリティホールになります。特にクラウド環境では仕様変更のスピードが速く、運用の中で設計が崩れていくことも珍しくありません。
セキュリティホール 設計や設定の不備により、不正アクセスなどのリスクが生じる状態。
実際のインシデントでも「過剰な権限が放置されていた」「退職者のアカウントが削除されていなかった」といった基本的な管理の抜け漏れが原因となるケースが多く見られます。問題は高度な攻撃よりも”基本が守られていないこと”にあるのです。
本記事では、IAM設計において押さえておくべきチェックポイントを体系的に整理しています。すべてを一度に完璧にする必要はありませんが、まずは「確認できる状態」を作ることが重要です。自身の環境と照らし合わせながら読み進めてください。
IAMの基本（認証と認可の違い）については「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」を参照してください。
IAM設計で抜け漏れが発生する理由とチェックリストの使い方
IAM設計では「権限を付与してMFAを有効化すればOK」というわけではありません。現場で抜け漏れが発生する理由は主に3つです。
運用と設計の乖離：設計上は最小権限やロール管理を徹底していても、実際の運用では例外処理や特別対応が増え、設計から逸脱してしまいます。急ぎの作業で一時的に管理者権限を付与したまま放置するケースなどが典型です。
「取ってあるだけ」で満足してしまう：ログやMFA、条件付きアクセスなどの機能が実装されていても、定期的な確認や運用ルールがなければ意味がありません。「設定したから安心」と思い込み、実際には異常が見逃されることがあります。
権限やアカウントの変化に追従できていない：入社・異動・退職などに伴うアカウントや権限の変更が、設計の想定通りに反映されていない場合があります。結果として不要な権限が放置され、セキュリティリスクが積み重なります。
このチェックリストの使い方：
チェックリストは「完璧を目指すための手順書」ではなく、設計や運用の抜け漏れを防ぐためのガイドマップです。確認観点は6つ（アカウント管理・認証・認可・ログ・ライフサイクル・責任共有）あります。
活用のポイントは3つです。まずリスクが高い部分（管理者アカウント・放置アカウント・MFA）から優先してチェックします。次に入社・異動・退職やサービス変更のタイミングで定期的に見直します。最後に「すべてを完璧にする必要はない」という前提で、まずは改善の方向性を可視化することから始めます。
アカウント管理・認証・認可のチェックポイント
アカウント管理
アカウント管理はIAMの最も基本的な領域でありながら、見落とされやすい部分です。ここが崩れていると、その上にどれだけ厳格な認証や認可を設計しても意味がなくなります。
□ 不要なアカウントが放置されていないか
退職者や異動者のアカウントが残ったままになっていないかを確認します。使われていないアカウントは管理の目が届かず、不正利用のリスクが高まります。「不要になったら無効化（Disable）し、一定期間後に削除」までがセットです。
□ 共有アカウントが使われていないか
複数人で同じアカウントを使い回す運用は、誰が何をしたのか追跡できなくなるため、監査性が大きく損なわれます。原則としてアカウントは個人単位で管理するべきです（アカウントは個人単位、権限は役割単位という点に注意）。
□ アカウントの命名規則は統一されているか
アカウント名にルールがないと「これは誰のアカウントか」「用途は何か」が分からなくなります。特に運用が長くなるほど管理が煩雑になり、不要アカウントの見逃しにもつながります。
□ 管理者アカウントが適切に分離されているか
日常業務で使用するアカウントと、管理者権限を持つアカウントが分離されているかを確認します。常に高い権限で作業を行う運用は、誤操作や侵害時の影響を大きくします。
認証（Authentication）
認証は「そのユーザーが本当に本人か」を確認する、セキュリティの入口です。ここが突破されると、その後の認可やログの仕組みがどれだけ整っていても意味がなくなります。
□ MFA（多要素認証）は有効化されているか
パスワードだけに依存した認証は、漏洩や推測によって簡単に突破されるリスクがあります。重要なアカウントだけでなく、原則すべてのユーザーに適用されているかを確認しましょう。
MFA（多要素認証） パスワードに加え、スマートフォンや生体認証など複数の要素で本人確認を行う仕組み。NISTのSP 800-63Bでもパスワード単体への依存リスクが指摘されている。
□ 例外アカウントは適切に管理されているか
MFAを適用できないアカウントが放置されていないかを確認します。例外アカウントはリスクが高いため、用途を限定し利用状況を監視するなど、通常よりも厳格に管理する必要があります。
□ パスワードポリシーは適切に設定されているか
MFAが前提とはいえ、パスワードの強度も依然として重要です。推測されにくい長さや複雑さ、使い回しの防止など、基本的なポリシーが適用されているかを確認しましょう。
□ 条件付きアクセスでリスクに応じた制御ができているか
条件付きアクセス ユーザーの場所・デバイス・リスク状況などに応じてアクセス制御を行う仕組み。「社外からのアクセスにはMFAを必須にする」といった制御が可能。
ユーザーの場所やデバイス、リスクレベルに応じてアクセスを制御することで、不正アクセスの可能性をさらに低減できます。単純な認証だけでなく、状況に応じた制御ができているかが重要です。
認可（Authorization）
認可は「認証されたユーザーに、何をどこまで許可するか」を制御する領域です。ここが適切に設計されていないと、たとえ認証が強固でも、侵害時の被害が一気に拡大します。
□ 権限は最小権限の原則に従っているか
ユーザーには業務に必要な最小限の権限だけを付与するべきです。「とりあえず広く付与する」運用になっていないかを見直し、本当に必要な権限かどうかを常に問い直すことが重要です。
詳しくは「最小権限の原則とは？実務での考え方と設計例」を参照してください。
□ 個人ではなくロール単位で管理されているか
ユーザーごとに個別で権限を設定していると管理が煩雑になり、統制が効かなくなります。役割（ロール）ごとに必要な権限を定義し、それをユーザーに割り当てることで一貫性のある管理が可能になります。
□ 権限のスコープは適切に制限されているか
同じ権限でも、適用範囲（スコープ）が広すぎるとリスクが高まります。特定のリソースに限定すべき権限が、サブスクリプション全体に付与されていないかを確認します。
スコープ 権限が適用される範囲。特定リソース・リソースグループ・サブスクリプションなどの単位がある。必要な範囲に絞ることで影響範囲を最小化できる。
□ 過剰な管理者権限が付与されていないか
管理者権限は最もリスクの高い権限です。日常的に管理者権限を使う運用になっていないかを確認し、必要なときだけ昇格する仕組み（JIT）を検討することが重要です。
RBACの基本については「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」を、設計でよくある失敗については「Azure RBAC設計でよくある失敗6選と対策」をあわせてご覧ください。
ログ・ライフサイクル・責任共有のチェックポイント
ログ・監査
ログと監査は「何が起きたのか」を後から説明できる状態を作るための仕組みです。セキュリティは「防ぐ」だけでなく、**「追える」**ことも同じくらい重要です。
□ 操作ログは取得されているか
誰が・いつ・何をしたのかが分かるログが取得されているかを確認しましょう。特に権限変更や重要な設定変更のログは必須です。
□ 誰が何をしたか追跡できる状態か
ログが存在していても、ユーザーと操作が紐づいていなければ意味がありません。共有アカウントの利用や識別できないログ形式では追跡性が大きく損なわれます。
□ ログの保存期間は十分か
ログの保存期間が短すぎると、問題発生時に必要な情報が残っていない可能性があります。監査やインシデント対応を想定し、十分な期間ログを保持しているかを確認しましょう。
□ ログは定期的に確認されているか
ログは「取得しているだけ」では意味がありません。異常な操作や不審な挙動を検知するためには、定期的な確認や監視が必要です。アラートの設定やレビューの仕組みが整っているかを見直しましょう。
IDライフサイクル管理
IAMは一度設計して終わりではなく、ユーザーの状態に合わせて継続的に見直すことが前提です。入社・異動・退職といったライフサイクルに応じてアカウントや権限を適切に管理できていないと、知らないうちにリスクが蓄積していきます。
□ 入社時のアカウント作成フローは定義されているか
新規ユーザーに対して、どの手順でアカウントを作成しどの権限を付与するかが明確になっているかを確認します。属人的な対応になっていると、過剰な権限付与や設定漏れが発生しやすくなります。
□ 異動・役割変更時に権限が見直されているか
部署異動や役割変更があっても、過去の権限がそのまま残っていないかを確認します。権限の追加はされても削除がされない運用は、過剰権限の温床になります。
□ 退職者のアカウントが確実に削除されているか
退職者のアカウントが残っている状態は大きなセキュリティリスクです。退職手続きと連動して確実にアカウントが無効化・削除される仕組みが整っているかを確認しましょう。
□ 定期的な権限棚卸しが実施されているか
日々の運用の中で権限は少しずつ増えていきがちです。定期的に権限の見直し（棚卸し）を行い、不要な権限を削除することが重要です。
ライフサイクル管理の各フェーズ（Joiner / Mover / Leaver / Reviewer）の具体的な対応手順については「IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法」で詳しく解説しています。
責任共有モデル
クラウド環境では、セキュリティの責任はすべてクラウド事業者が担うわけではありません。サービスごとに「どこまでが提供者の責任で、どこからが利用者の責任か」が明確に分かれており、これを誤解していると重要な設定が放置されるリスクがあります。
□ クラウドと利用者の責任範囲を理解しているか
インフラの物理的な保護や基盤のセキュリティはクラウド事業者が担いますが、アカウント管理やアクセス制御（IAM）は利用者側の責任です。この前提を正しく理解できているかを確認しましょう。
□ IAM設定が利用者責任であることを認識しているか
「クラウドだから安全」という認識のままでは、IAM設定が不十分な状態でも見過ごされてしまいます。誰にどの権限を与えるかは完全に利用者側の責任であり、設計と運用の両面で継続的に管理していく必要があります。
（参考：AWS 共有責任モデル / Microsoft Azure の責任共有 / Google Cloud における責任共有）
よくある抜け漏れ4パターン
ここまでチェックリストを見て「一応やっている」と感じた方も多いかもしれません。しかし実務では、”やっているつもり”と”実際に機能している”の間に大きなギャップがあるケースがよく見られます。
MFAはあるが例外管理が崩壊している：MFA自体は有効化されていても「一部のアカウントは例外」として除外され、そのまま放置されていないでしょうか。管理されていない例外がリスクになります。
ログは取得しているが活用されていない：ログは取っているものの実際には誰も確認していない、という状態はよくあります。ログは”取得すること”ではなく、“異常を検知するために使うこと”が目的です。監視やアラートの仕組みがあるかを見直しましょう。
権限が見直されず放置されている：一度付与された権限が長期間見直されていないケースも多く見られます。「今の業務に本当に必要か」を定期的に確認することが重要です。
アカウント削除漏れによるリスク：退職者のアカウントが削除されていない、あるいは無効化が遅れているといったケースも典型的なリスクです。アカウントは”作ること”よりも**”確実に消すこと”の方が重要**です。
IAMにおける典型的な失敗パターンについては「クラウドIAM設計でよくある失敗5選と対策」で詳しく解説しています。
まとめ：IAM設計は「確認できる状態」を作ることが重要
IAM設計において重要なのは、単に仕組みを作ることではなく、「それが正しく機能しているかを確認できる状態」を維持することです。このチェックリストはそのためのスタート地点にすぎません。実際のセキュリティは、設計だけでなく運用・見直し・監査といった継続的な取り組みによって成り立ちます。
特にアカウントや権限は時間とともに変化し、放置すれば確実にリスクが蓄積していきます。だからこそ定期的にチェックし、必要に応じて修正していくことが重要です。
IAMは設計・運用・監査の3点をセットで回すことで、初めて設計が現実のセキュリティにつながります。このチェックリストをきっかけに**「継続的に改善する仕組み」**に進んでいきましょう。
あわせてご覧ください：
コメント