【AWS】IAMを正しく理解・運用できていますか？設計で迷わないためのポリシーガイド

私のような「なんとなく」IAMを使っている人におすすめの記事です。

IAMについて深く学習する前までは、「ユーザにポリシーを貼って最小権限を実現するやつ」みたいな認識でした。危険ですね！

現場では何気なくアクセスキーを発行して運用していたりしますが、AWSのセキュリティ責任者が公式に「長期的な鍵は、もはや負債でしかない」と語っているのを知っていましたか？

今回の記事ではIAMの基本的な使い方から、最近使用されている運用体制までをとりあげて解説したいと思っています。

実務でIAMを触っている方には特におすすめの記事になります！

そもそもIAMとは？

一言でいうと、AWSリソースに対して、「誰が」「どのような操作をできるか」を安全に管理するための仕組みです。

IAMの2つの役割

IAMを理解するうえで最も重要なのが「認証」と「認可」の違いです。

• ▸認証：「あなたは誰ですか？」→ユーザ名とパスワード、MFAなどを使って、本人であることを確認します
• ▸認可：「あなたは何ができますか？」→ログインした人が「S3のファイルを読み取れるか」「EC2サーバーを停止できるか」といった権限をチェックします

IAMを構成する4つの要素

IAMには、以下の4つの要素を組み合わせて設定します

IAMポリシー

IAMポリシーには、大きく分けて2つのタイプがあります。

• ▸管理ポリシー

・AWS管理：AWSが用意したテンプレート。「管理者用」「閲覧のみ」などの汎用的なものが多く、選ぶだけで使えます。

・カスタマー管理：自分で作成して保存するポリシー。複数のユーザやロールに使いまわせるので、実務ではこれが推奨される。

• ▸インラインポリシー：特定のユーザやロールに直接書き込むポリシー。その人にしか適用されない「特例」のような扱いです。正直あまり使わないです。

カスタマー管理ポリシー

実際に見てみましょう！

以下は「S3バケット内のファイルを読み取るだけ」のポリシー例です

{  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

詳しく見ていきましょうか。

①Effect：AllowかDenyを記載して許可／拒否を選択します

②Action：「何をするか」。s3:ListBucket（一覧表示）や ec2:RunInstances（起動）など

③Resource：「対象はどれか」。ARNという専用の住所形式で指定します

④Condition：任意で条件を追加します。「特定のIPアドレスからのみ許可」「MFAを使っているときのみ許可」といった細かい条件を付けられます

AWS管理ポリシー

AWSの管理しているポリシーには、下記の2種類があります。

①職務用ポリシー

特定の役割に必要な権限を、サービスを横断してセットにしたもの。

安全な状態ですぐに使用できるのは便利ですね！

②サービス固有のポリシー

特定のAWSサービスに特化したポリシーです、通常、以下の3段階の強さが用意されています。

• ▸FullAccess: そのサービスに関するすべての操作が可能。
  • ▸AmazonS3FullAccess（バケット作成から削除まで全部）
• ▸ReadOnlyAccess: そのサービスの設定やデータを閲覧するだけ。
  • ▸AmazonRDSReadOnlyAccess（DBの設定は見れるが、変更は不可）
• ▸ServiceRole: AWSのサービス同士が連携するための特殊な権限。
  • ▸AmazonEC2RoleforSSM（EC2をブラウザから操作するために必要）

それでは、実際に

AdministratorAccess

を許可するIAMユーザを作ってみましう！

まずは、ユーザ名を決めます。

何でもよいので、わかりやすい名前にしましょう。 マネジメントコンソールへのユーザアクセスは許可してあげてください。

次に許可の設定です。

「ポリシーを直接アタッチする」を選択し、

AdministratorAccess

ポリシーを選択します。

あとは「ユーザーの作成」をクリックすれば完成です！簡単ですね。

アクセスキーとは？

マネジメントコンソールにアクセスキーというコンポーネントがありますね。

これは、AWS CLIなどのプログラムやツールにアクセスする際に使用します。マネジメントコンソールのように「人間用のログイン画面」がない時に使用するってことですね。

アクセスキーを作成すると、必ず以下の2つがペアで発行されます。

• ▸アクセスキーID：いわゆる「ユーザ名」のようなもの
• ▸シークレットアクセスキー：要は「パスワード」ですね。作成時に一度しか表示されません。

※アクセスキーは、AWS運用のなかでも特に情報漏洩が起きやすいポイントです。

下記には気を付けてください・・。

• ▸GitHubにアップしない：公開設定のGitHubにアクセスキーを乗せたコードを乗せると、数分以内にボットに盗まれてしまいます。本当に危険です。
• ▸メールやチャットで送らない：平文で送ること自体が危険です。
• ▸ルートユーザのアクセスキーはそもそも作らない：漏れたらアカウントが一発で死亡です。

いやあぶな！使わない方が良いじゃん！

そうです。使わない方が良いです。 冒頭でもお話ししましたが、AWS側でも「可能な限りアクセスキーは使わない」設定を推奨しています。

例えば、AWS上で動くプログラムであれば「IAMロール」を使用して、アクセスキーなしで通信するようにしたり、自分のPCから操作するのであれば、IAM Identity Centerを使用して一時的な短い期限の鍵だけを発行して操作できます。

---

ここまでで、IAMの大まかな使い方、運用方法は理解できたのではないでしょうか。 おそらくIAMに触れたことのある方であれば、「そんなの知ってるわ！」という内容ばかりだったと思います。

ここからはIAMの理解をさらに深めるサービスを紹介します。

決してニッチな運用方法ではなく、しっかり理解すればすぐにでも活用できる内容になっています。 また、インシデントの事例も紹介いたします。肝に銘じておきたいところです。

IAM Identity Center

上記のように、IAMユーザにはいろいろな危険性があったんですね。そのおかげで生まれたのがIAM Identity Centerです。もともとはAWS SSOという名前でした。

AWSが今最も激アツだと言っているログイン方法の仕組みのことですね。

IAM Identity Centerはなにが凄いの？

これまでのIAMユーザだと、一度作ると「パスワード」や「アクセスキー」がずっと有効でした。そのため、鍵を盗まれたときのリスクが非常に高かったんです。

一方で、IAM Identity Centerを使用すると、以下のようなメリットがあります。

• ▸一時的な鍵の発行：自分のPCで使用する「アクセスキー」が、数時間で自動的に無効になる一時的なものになります。万が一漏洩しても、すぐに使えなくなるので安全です。
• ▸1つのIDで複数のアカウントへ：会社などで「開発用」「本番用」と複数のAWSアカウントを持っているとき、1回のログインでどのアカウントにも切り替えてはいれるようになります。
• ▸外部サービスとの連携：Google WorkspaceやMicrosoft Entra IDのログイン情報をそのまま使ってAWSにログインできます。

認証認可を行うことができるぜ！

うお！IAMアクセスキーが漏洩してしまった！

わりとあるある。具体的な手順を紹介します。

①漏洩したキーを無効化

まずは、IAMアクセスキーを「無効化」します。影響範囲を特定したいので、削除はしない方が良いです。

※IAMロールを持つEC2などのリソースは、一度認証されると、一時的な認証情報を利用してAWSサービスにアクセスできてしまいます。セッションを削除する必要がありますね。

②新しいアクセスキーを発行

システムが止まらないように、新しいアクセスキーペアを作成します。動作確認が終わったら、元のキーを削除しましょう。

③不正利用の形跡を調査

漏洩したアクセスキーIDで検索をかけて、CloudTrailで確認する IAM Access Adviserを使用するのも良い

特定リージョン以外のAWSサービス操作を拒否するIAMポリシー

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*","Condition":{"StringNotEquals":{"aws:RequestedRegion":"us-east-1"}}}]}

IAM パーミッションバウンダリー

そのユーザやロールが「絶対に超えてはいけない」権限の上限値を決める機能のこと。 →IAMポリシーで許可されていても、パーミッションバウンダリーで拒否されていたら実行できない

IAMロールのクロスアカウントアクセス

クロスアカウントアクセスを実現するためには、以下の手順が必要：

1. ▸監査対象アカウント（AWS アカウント A）で IAM ロールを作成
   • ▸sts:AssumeRole を許可するポリシーを設定
   • ▸External ID を使用する場合、その値を指定
2. ▸監査人（AWS アカウント B）の IAM ユーザーに権限を付与
   • ▸sts:AssumeRole を許可する IAM ポリシーを設定
3. ▸監査人が AWS STS を使用して IAM ロールを AssumeRole
   • ▸aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/AuditRole" --role-session-name "AuditSession"

ExternalIDとは？

ロールを引き受けるための「合言葉」のようなもの

SAMLベースのSSO信頼関係

①新しい証明書でSAMLレスポンスに署名 ②IAM：登録されている「IDプロバイダエンティティ」内のメタデータを使って署名を検証する ③メタデータが古いと、検証に失敗してエラーになる。

※そもそもSAML認証は、IdPが発行するSAML応答にデジタル署名が付与されて、AWSはこの署名を検証することで認証することができる 　→この署名にIdPの公開鍵が必要

メタデータファイルって何やねん！

「IdPとAWSがお互いを認識するための鍵の証明書」 →IAMの中にある「IDプロバイダー」という設定項目に読み込ませるもの

中身

• ▸発行者の情報：「私はこういうIDプロバイダーです」という名前
• ▸ログインURL：ユーザが認証に行くべき場所
• ▸公開鍵：IdPが署名したデータが「本物かどうか」をAWSが検証するためのデジタル証明書

→このメタデータに書いてあるIdPからのログイン要求なら信じていいよ。署名の検証はこの公開鍵を使ってね。という意味

IAM Roles Anywhere

AWS外にあるサーバーに、IAMロールを安全に渡すためのサービスのこと 今までは、IAMユーザのアクセスキーを発行してサーバーに保存するのが一般的だった →アクセスキーを使わずに、一時的なIAMロールを外のサーバーで使えるようになる

IAM Access Analyzer

「外から見られちゃってない？？」をチェックする人。 S3やIAMロールなどが、外部からアクセス可能になっていないかを自動で分析してくれます。

最近では「未使用のアクセス権」を見つける機能や、CloudTrailの履歴から「実際に使った権限だけのポリシー」を自動生成する機能も追加されている→自動生成すごない？

アクセスアナライザを有効にすると、AWS Organization内のすべてのアカウントのIAMポリシーやS3バケットポリシーを分析し、外部のAWSプリンシパルに対するアクセス権を特定できる ※ポリシー検証機能により、IAMポリシーやSCPの文法的な誤りを検出可能

→過去の特定のAPI呼び出しの履歴を調査するなどの用途には適していない。

IAM Access Advisor

「この権限、最後に使ったのはいつ？」を教えてくれる人。 IAMユーザやロールの画面にあるタブで、「どのサービスにいつ最後にアクセスしたか」を表示します。「フルアクセス権限を付けてるけど、実際はS3しか使ってないやん」ということが一目でわかるので、権限を絞り込むときに使えそうですね！

認証情報レポート（Credential Report）

「全ユーザの健康診断結果」を出してくれる人。 アカウント内の全ユーザのリストと、パスワード変更日、アクセスキーの使用状況、MFAが有効かどうかをまとめたCSVレポートを作成します。定期的な監査や、「MFAを付けていない不届き者はいないか？」をチェックするのに使います。

---

いかがでしたか？

毎日当たり前のように触っているIAMですが、実は「知れば知るほど奥が深い」ということを、私自身も再確認しました。

セキュリティの根幹だからこそ、完璧を目指そうとすると少し気が重くなりますが、まずは「不要なアクセスキーを消す」といった一歩からで大丈夫だと思います。私もまだまだ勉強中の身ですので、皆さんと一緒に安全でセキュアなAWSライフ（実務では触っていませんが）を目指して、学習を続けていきたいと思います！

おわり