IAMとは?権限を管理する仕組みをやさしく解説

IAMは「誰が何をしていいか」を決める仕組み

IAM は Identity and Access Management の略で、日本語にすると「アイデンティティ(身元)とアクセス権の管理」です。要するに、誰(あるいはどのプログラム)が、どのリソースに対して、何をしてよいかを定義して管理する仕組みのことを指します。

クラウドサービスやシステムの管理画面でよく出てくる言葉で、AWSなどのクラウドでは「IAMユーザー」「IAMロール」「IAMポリシー」といった形で日常的に使われます。初めて見ると身構えてしまいますが、やっていること自体はとてもシンプルです。

会社のオフィスのカードキーで考える

イメージしやすいのは、オフィスの入館カードです。

社員一人ひとりにカードが配られます。このカードが「誰であるか」を証明するもの、つまりアイデンティティにあたります。そしてカードには、入れる部屋の情報が紐づいています。一般社員のカードは執務室と会議室だけ開く、経理部のカードは金庫室も開く、清掃スタッフのカードは夜間だけ使える……といった具合です。この「どのドアを開けてよいか」の設定がアクセス権です。

IAM がやっているのは、まさにこのカードキーシステムのデジタル版です。ログインした人が本人かを確認し(認証)、その人がやろうとしている操作を許可するかどうかを判断する(認可)。この2つを合わせて管理するのが IAM の役割です。

認証と認可はセットだけど別物

IAM を理解するうえで、この2つの区別がいちばん大事です。混同されがちですが、役割がはっきり違います。

ログインには成功しているのに「権限がありません」と怒られるのは、認証は通ったが認可で弾かれた、という状態です。エラーメッセージを読むとき、このどちらで失敗しているのかを見分けられると原因を絞り込みやすくなります。

人だけでなく、プログラムにも権限を与える

IAM が扱うのは人間のユーザーだけではありません。サーバー上で動くプログラムや、自動実行されるスクリプトにも「このプログラムはこのデータだけ読める」といった権限を割り当てます。むしろ実務では、こちらの方が扱う機会が多いくらいです。

たとえばファイルを保存するストレージに対して、あるプログラムには「読み取りだけ許可、削除は不可」と設定しておけば、そのプログラムにバグがあったとしてもデータを消してしまう事故は起きません。権限を絞ることは、悪意ある攻撃への対策であると同時に、うっかりミスへの保険でもあります。

最小権限の原則

IAM の設計で繰り返し語られる考え方が「最小権限の原則」です。必要な操作に必要な分だけの権限を与え、それ以上は与えないという方針を指します。

全員に管理者権限を配ってしまえば、確かに「権限がなくて動きません」というトラブルは起きなくなります。ただしその代わり、誰か一人のアカウントが乗っ取られただけでシステム全体が危険にさらされます。オフィスの例でいえば、全社員にマスターキーを配るようなものです。

面倒でも、必要になったタイミングで必要な権限だけを足していく。この積み上げ方が結果的に安全で、後から「なぜこの権限があるのか」を説明しやすい構成になります。

つまずきやすいポイント

実際に触りはじめると、たいてい最初にハマるのが権限エラーです。設定したつもりなのに動かない、という状況は珍しくありません。

よくある原因は、権限を与えた対象を間違えているケース。自分のアカウントに権限を付けたつもりが、実際に操作しているのはサーバー上のプログラム側だった、というパターンです。誰(何)が操作を実行しているのかを正確に把握するのが、IAM のトラブルシューティングの第一歩になります。

もうひとつは、権限の反映に時間がかかったり、キャッシュされた古い認証情報が使われ続けたりする場合。設定を変えたのに挙動が変わらないときは、一度接続や認証情報をリセットしてみると解決することがあります。

覚えておきたいこと

IAM は、システムの安全性を支える土台です。派手な機能ではないので後回しにされがちですが、ここが雑だと、他をどれだけ固めても意味がなくなってしまいます。最初のうちは「認証と認可の違い」と「最小権限の原則」の2つだけ頭に入れておけば、個別の設定項目に出会ったときも迷子になりにくいはずです。