IAM は、誰がシステムを使えるかを決め、その人やプログラムに何を許可するかを管理するための仕組みです。Identity and Access Management の略で、認証と認可をまとめて扱う考え方として使われます。クラウド、社内システム、API 利用のどれでも重要で、権限の付け方を誤ると、必要以上に広い操作ができてしまいます。
認証と認可を分けて考える
IAM を理解するときは、まず 認証 と 認可 を分けて考えると整理しやすいです。認証は「その主体が誰かを確かめること」、認可は「その主体に何をさせるかを決めること」です。たとえば、パスワードや多要素認証でログインできるかを確かめるのが認証、ログイン後に閲覧だけ許すのか編集まで許すのかを決めるのが認可です。
実務では、この2つが同じ画面や同じ設定項目に見えても、内部の役割は別です。認証が通っても、必要な権限がなければ操作はできません。逆に、権限だけあっても本人確認ができなければ利用は開始できません。
主体の種類をどう分けるか
IAM では、権限を与える相手を「主体」として扱います。主体には、人間のユーザーだけでなく、プログラムや自動処理も含まれます。クラウドでは、アプリケーションやバッチ処理がログインの代わりに使う サービスアカウント がよく使われます。
主体の種類を分ける目的は、運用と監査をしやすくするためです。人の操作と機械の操作を同じ権限で扱うと、誰が何をしたか追いにくくなります。たとえば、開発者は管理画面を使えても、定期実行のプログラムには必要最小限の API 呼び出しだけを許す、という分け方が基本です。
ロールとポリシーの組み立て方
IAM の権限管理は、一般に ロール と ポリシー を組み合わせて設計します。ロールは「閲覧者」「編集者」「管理者」のような権限のまとまり、ポリシーは「どの主体に、どの操作を、どの対象へ許すか」を定義するルールです。
設計の考え方としては、個別の人やプログラムにばらばらな権限を直接与えるより、役割ごとのロールを作って割り当てるほうが保守しやすくなります。人事異動や担当変更があっても、ロールの付け替えで対応しやすいからです。特に運用人数が増えるほど、個別付与よりロールベースの管理が重要になります。
| 観点 | 個別付与 | ロールベース |
|---|---|---|
| 変更作業 | その都度細かい | まとめて調整しやすい |
| 監査 | 追跡しにくい | 権限意図を説明しやすい |
| 拡張性 | 増えるほど複雑 | 人数増加に対応しやすい |
API 利用での権限付与
API を使うシステムでは、IAM は「誰がどの API を呼んでよいか」を決める役割を持ちます。外部のアプリや自動処理が API にアクセスするときは、認証情報を使って主体を示し、その後に IAM が権限を確認します。
Google Cloud などのクラウド環境では、ユーザーの操作だけでなく、サービス間通信でも IAM が中心になります。たとえば、ある処理がストレージの読み取りだけ必要なのに、書き込みや削除まで許してしまうと、障害や事故の影響が大きくなります。したがって、API 単位、リソース単位、操作単位で最小限に絞る発想が大切です。
サービスアカウントと鍵の扱い
機械向けの IAM で特に重要なのが、サービスアカウント とその認証情報です。サービスアカウントは、人ではなくプログラム用の主体で、バッチ処理、CI/CD、外部連携などで使われます。人間のアカウントと違い、用途を限定して作るのが基本です。
ここで注意したいのは、サービスアカウントの鍵を「ログインできるただ一つの手段」として扱わないことです。鍵ファイルは漏えいすると、その主体になりすまされる危険があります。そのため、不要な共有を避け、保存場所や権限を厳しく制限します。可能なら、長期固定の鍵よりも、短時間だけ有効な認証方式を優先します。
設計でよく使う最小権限の考え方
IAM の設計原則として、最小権限の原則 がよく使われます。これは、必要な仕事をするのに足りる最小限の権限だけを与える考え方です。便利さを優先して広い権限を与えると、誤操作や侵害の影響範囲が大きくなります。
例えば、読み取りだけ行う監視ツールに削除権限は不要ですし、帳票生成だけの処理に管理者権限は必要ありません。権限が広すぎると、1 つの認証情報の漏えいが全体事故につながります。IAM は便利に見えて、実際には「使えるようにする」だけでなく「使いすぎないようにする」ための仕組みでもあります。
OAuth 2.0 との役割の違い
IAM と似た文脈で OAuth 2.0 が出てきますが、両者は同じものではありません。OAuth 2.0 は、別サービスへのアクセスを安全に委任するための仕組みで、特定のアプリにどの範囲のアクセスを許すかを扱います。IAM は、組織やシステム全体で主体と権限を管理する、より広い考え方です。
| 用語 | 主な役割 | 見る対象 |
|---|---|---|
| IAM | 認証と権限管理の全体設計 | 人、サービス、リソース |
| OAuth 2.0 | アクセスの委任 | アプリ間の許可範囲 |
| サービスアカウント | 機械用の主体 | プログラムや自動処理 |
実際の運用では、OAuth 2.0 で得た許可を IAM の権限管理と組み合わせて使うことがあります。そのため、片方だけを見て「認証済みだから安全」「トークンがあるから権限がある」と考えないことが重要です。認証できることと、何ができることかは別の問題です。
IAM は、利用者やプログラムを正しく識別し、必要な範囲だけ操作させるための土台です。クラウドや API を使う場面が増えるほど、設定のわずかな差が運用の安全性を大きく左右します。
