IAMとは
IAMとは、誰がクラウドを使えるか、そしてどこまでできるかを決める仕組みです。英語では Identity and Access Management といいます。かんたんに言うと、クラウドの「身分証」と「入室許可」をまとめて扱うようなものです。
たとえば、会社のクラウドに入るときに、ログインできるだけでは足りません。ファイルを見てよい人、設定を変えてよい人、請求情報まで見てよい人は分ける必要があります。IAMはその分け方を管理します。
この考え方は、AWS、Google Cloud、Azure などのクラウドで共通です。名前や画面は少し違っても、「本人確認」と「権限の確認」を分ける、という基本は同じです。
まず押さえる基本
IAMを理解するときは、次の4つを分けて考えると楽です。
- ユーザー：人やアプリなど、クラウドを使う主体です。
- グループ：似た仕事をする人をまとめる入れ物です。
- ロール：役割ごとの権限セットです。
- ポリシー：何をしてよいか、細かく書いたルールです。
ここで大事なのは、認証と認可を混ぜないことです。認証は「あなたは本当に本人ですか」を確かめること。認可は「その人に、この操作をしてよいですか」を決めることです。
よくある疑問：ログインできれば、もう自由に使っていいんですか？
いいえ。IAMでは「入れるか」と「どこまでできるか」を別に考えます。ログインできても、編集や削除は止めることがあります。
たとえば、クラウドの管理画面に入れたとしても、請求書の確認だけ許されていて、サーバー停止はできない、という設定ができます。これがIAMの基本です。
身近なたとえで考える
IAMは、学校やビルの出入りにたとえるとわかりやすいです。門の前で学生証を見せるのが認証、図書室には入れるけれど職員室には入れない、という決まりが認可です。
もう少し仕事に近づけると、社員証を持っているだけでは何でもできません。経理の人は請求情報を見られるけれど、開発用サーバーの設定変更はできないことがあります。逆に、開発者はコードや環境設定に触れても、支払い情報には触れないようにします。
この分け方がないと、ひとりのアカウントが広すぎる権限を持ってしまいます。すると、操作ミスをしたときの影響が大きくなります。IAMは「便利さ」と「安全さ」の両方を守るための仕組みです。
たとえば、1つの鍵で家じゅうの部屋が全部開いたらこわいですよね。IAMは、玄関、書斎、金庫の鍵を分けるようなものです。必要な場所だけ開けるから、安心して使えます。
実務での使いどころ
会社のクラウドでは、IAMは毎日のように使われます。新しいメンバーが入ったら、まずアカウントを作り、次に必要なロールやグループを付けます。退職や異動があれば、不要な権限を外します。こうしておくと、あとから「誰が何をできるか」を追いやすくなります。
実務で特に大切なのは、最小権限です。これは、仕事に必要な分だけ権限を与える考え方です。たとえば、Webサイトの更新担当なら、公開フォルダだけ編集できれば十分かもしれません。請求管理や他の本番環境まで見られる必要はありません。
アプリ同士がやり取りするときもIAMが活躍します。アプリがクラウドの機能を呼ぶときは、REST API を使うことが多いです。そのとき、APIを呼ぶ側に強い合言葉をベタ書きするより、IAMのロールで短く安全に許可するほうが扱いやすくなります。
設定の細かい内容は、JSON のような形式で表されることもあります。中身は少しむずかしく見えても、考え方は「この操作は許可、この操作は拒否」を書いているだけです。
また、権限が足りないときは、画面やAPIがエラーを返します。Webサービスでは HTTPステータスコード の 403 のように、アクセス拒否を示すことがあります。見た目はただの失敗でも、原因が権限不足なのか、ログイン失敗なのかを分けて見ると、調査が早くなります。
運用の現場では、次のような場面でIAMを見直します。
- 新しいクラウド環境を作るとき
- 外部委託先に一時的な権限を渡すとき
- 本番環境と検証環境の権限を分けるとき
- 障害対応で一時的に強い権限が必要になったとき
特に本番環境では、設定を変えられる人を少なくするのが基本です。IAMがうまく設計されていると、事故を減らしやすくなります。
図解で整理
IAMの流れは、次の順番で見ると整理しやすいです。
- 利用者やアプリがクラウドにアクセスする
- IAMが本人かどうかを確認する
- ロールやポリシーで権限を確認する
- 許可されていれば操作できる
- 許可されていなければ拒否される
ここで大切なのは、本人確認だけでは足りないことです。ログイン成功は、入場券を持っている状態に近いです。でも、その先の部屋に入るかどうかは、別のルールで決まります。
図で見ると、IAMは「入口の守り」と「部屋ごとの鍵」をつないでいるイメージです。会社で言えば、受付で社員証を確認し、その後に会議室やサーバー室へ入る許可を分ける感じです。クラウドでも同じで、誰でも同じ操作ができるようにすると危険です。だからこそ、利用者、グループ、ロール、ポリシーを組み合わせます。
実際の設計では、権限を細かくしすぎると管理が大変になります。反対に、広すぎる権限は危険です。なので、まずは「この人は何の仕事をするか」を先に決め、その仕事に必要な範囲だけを割り当てるのがコツです。これなら、あとから人が増えても整理しやすくなります。
また、クラウドでは自動化と相性がよいので、手作業で毎回権限を変えるより、グループやロールを使ってまとめて管理するほうがミスを減らせます。人が直接操作する場面を減らすことも、IAMをうまく使うポイントです。
3問クイズ
1. IAMが管理する2つの大きな要素は何でしょう。
A. 画面の色と文字サイズ
B. 誰が使うかと、何をしてよいか
C. 回線速度と電波の強さ
D. 端末のメーカー名
答えを見る
答え： B. 誰が使うかと、何をしてよいか
2. 認証と認可の違いとして正しいものはどれでしょう。
A. 認証は本人確認、認可は操作できる範囲の決定
B. 認証は画面デザイン、認可は色の設定
C. 認証と認可はまったく同じ意味
D. 認証は通信速度、認可は保存容量
答えを見る
答え： A. 認証は本人確認、認可は操作できる範囲の決定
3. 最小権限の考え方として、いちばん近いものはどれでしょう。
A. できるだけ多くの権限を最初から与える
B. だれでも全部の機能を使えるようにする
C. 仕事に必要な分だけ権限を与える
D. 権限は考えずに運用する
答えを見る
答え： C. 仕事に必要な分だけ権限を与える
まとめ
IAMとは、クラウドで「誰が」「どこまで」使えるかを管理する仕組みです。ポイントは、本人確認の認証と、操作範囲を決める認可を分けて考えることです。
仕事で使うときは、最小権限で設計し、ユーザー、グループ、ロール、ポリシーを使って整理します。これだけで、ミスや事故をかなり減らしやすくなります。クラウドを安全に使うための土台として、IAMはとても大事です。
