AWSのIAMってなんやねん
自己紹介
どもども、フリーランスエンジニアとして働いている井上弥風です。
ずっとバックエンドメインで仕事をしてきたのですが、インフラ側がヨワヨワ過ぎたので勉強を始めました
IAMってなんやねん、ロールなのかポールなのかロールケーキなのかマンホールなのかよく分からなかったので深掘りします
対戦よろしくお願いします
初めに
記事の内容
当記事では「AWSのIAMとは何か」から始まり、IAMを更生する4つの要素の説明、IAMの重要性やセキュリティ管理の方法を学びます
文章による説明だけではなく、実際にAWSマネジメントコンソールでIAMを利用して学習を深めていくため、IAMの基礎知識をしっかりと学習することができると思います
記事のゴール
記事のゴールは下記の内容をしっかりと理解することです
- IAMとは何か
- IAMで登場する概念の理解(ユーザー、グループ、ロール、ポリシー...)
- 実際にAWSマネジメントコンソールを利用してIAMの使い方
- IAMを他のサービスと連携する方法
- IAMの重要性やセキュリティ管理の方法
ではではスタート～～！！
IAMとは？
まずAWSのIAMとは何でしょうか？
IAMとはIdentity and Access Managementの略で、AWSの各リソースへのアクセス権限を作成・削除・管理し、AWSリソースへのアクセスをセキュリティで保護するためのサービスです
IAMを使うことにより、各AWSユーザーや各AWSリソースが「出来ること」・「出来ないこと」を定義することができます
IAMでは、誰が(AWSユーザーやAWSリソース)AWSの各リソースにアクセスできるか、またアクセスできないかを決めることができます
これにより、「認証(本人確認)」と「認可(アクセス権の付与)」を管理することが可能になります
つまり、IAMとは「誰が(認証)何を(認可)行うことができるのか」を定義したり管理したりすることでセキュリティを向上させることができるサービスなのです
IAMを構成する4つの要素
IAMにはIAMを構成する重要な概念があり、それが下記の4つです
- IAMユーザー
- IAMグループ
- IAMロール
- IAMポリシー
ここで理解すべきなのは、これらがどのように連携してAWSリソースへのアクセス管理とセキュリティを向上させるかです
一つ一つ見ていきましょう😁
①IAMユーザーの前にAWSアカウントの意味を正確に理解する
「AWSアカウント」とはIAMでのみ登場する概念ではなく、AWS自体の概念と言えます
IAMを理解するにあたり、まずはAWSアカウントとは何かを理解することがこの先の学習を楽にするため、まずはAWSアカウントとは何かから見ていきましょう^^
AWSアカウントは一般的なアカウントと意味が違う？
まず一般的な「アカウント」とは何でしょうか？？
- LINEのアカウント
- Twitterのアカウント
- Amazon Prime、Netflixのアカウント...
色々ありますね！
ではアカウントをより具体的に言語化すると、アカウントとはつまり何でしょうか？？
アカウントとは、インターネット上のサービスを利用する際に必要な権利や、個人認証情報です
あまり難しく考えなくて良いのですが、ざっくり言うと「アカウント」とは「ユーザーを識別できるもの」と言ったところです👍
AWSアカウントとは？
「AWSアカウント」と聞くと、普通のアカウント（LINEやTwitterみたいな）と同じような意味合いを持っている単なる「AWSのアカウント」と感じますよね
実際には同じ意味合いを持っており、AWSアカウントは確かにあなたを認証し、サービス利用のための権利を与える「ユーザー識別のためのもの」です
しかし、しかししかし、AWSアカウントの持つ意味はそれだけではないのです🤔
AWSアカウントは、あなた専用のAWSの世界です
まず、AWSサービスが稼働する一番根底にある「基盤」はAWSクラウドです
(グローバルなクラウドコンピューティング環境)
このAWSクラウド上で、我々はS3やEC2、IAMなど、様々なサービスを使うことができます
AWSアカウントは、そのバチクソでかいAWSクラウドの中であなたのための「個人的なスペース」を作ってくれるのです
つまり、AWSアカウントはAWSクラウドの中にある「あなただけの環境」という事です
イメージしやすくするために、AWSクラウドをマンションだと考えてみましょう
このマンション(AWSクラウド)にはたくさんの部屋(AWSアカウント)があります
あなたのAWSアカウント(部屋)は、このマンション(AWSクラウド)の中のあなただけの部屋です
この部屋の中では、あなたが何をしたいか自由自在に決めることができます
１点だけ補足しておくと、AWSアカウント自体は実行環境ではありません
AWSアカウントは、AWSクラウド内で提供されるリソースやサービスへのアクセスを管理するための枠組みに過ぎません
実際のアプリケーションやシステムは、EC2インスタンスやLambda関数などのAWSサービス上に構築されます
要するにAWSアカウントは、
- 認証ツールとして：あなたを特定し、サービス利用のための認証を提供してくれる
- 組織ツールとして：AWSクラウド内であなた専用のスペースを割り当て、管理してくれる
②IAMユーザーの前にルートユーザーの意味を正確に理解する
次に、ルートユーザーとは何かという点を理解していきましょう
(ルートユーザーを理解することでIAMユーザーの理解もしやすくなるはずです👍)
ルートユーザーとは？
前提として、ルートユーザーはAWSアカウントを作成する際に自動的に作成される最初のユーザーアカウントです
ルートユーザーには、AWSアカウント内のすべてのリソースとサービスに対するフルアクセス権限が付与されます
つまり、ルートユーザーは全ての権限を持っている全知全能の神なのです
「やろうと思えば」稼働中のサーバーを削除してしまったり、高額なAWSサービスを使いまくったり、マジでなんでもできる権限を持っているのがルートユーザーです
ルートユーザー = 最強のアカウント
AWSアカウントとルートユーザーの違いがちょいと分からんぞ..
まず、AWSアカウントはAWSのサービスを利用するための環境または容器と言えますが、これを理解する際には明確な区別が必要です
AWSアカウント自体は、先ほど説明した通りEC2インスタンスやLambda関数といった実際にアプリケーションが実行される実行環境を提供ではありません
むしろ、AWSアカウントはこれらの実行環境や他のリソースを管理、課金、セキュリティ設定を適用するための枠組みの範囲として機能します
つまり、AWSアカウントを通じて、AWSクラウド内で使用されるリソースの管理やアクセス制御を行うことができるのです
下記の図で示しているように、AWSアカウント(ピンクの枠)は実行環境ではなく「あなたの環境であることの枠組み・線引き」です
整理すると、
- AWSアカウント
- あなた専用の環境(土地)
- ルートユーザー
- あなた専用の環境で最初に作られる初期ユーザーであり、すべての権限を持っている
IAMユーザー
ではでは、IAMユーザーとは何かを詳しく見ていきましょう
IAMユーザーとは？
AWS Identity and Access Management (IAM) のユーザーとは、AWS で作成したエンティティのことです。IAM ユーザーは、AWS とやり取りするために IAM ユーザーを使用する人間のユーザーまたはワークロードを表します。AWS のユーザーは名前と認証情報で構成されます。
管理者アクセス許可を持つ IAM ユーザーが AWS アカウントのルートユーザー ということではありません。ルートユーザー の詳細については、「AWS アカウントのルートユーザー」を参照してください。
IAM ユーザー
上記はAWSの公式サイトに記載されているIAMユーザーの説明文です
少し前に「AWSアカウントは一般的なアカウントと意味が違う？」セクションで一般的なアカウントとはどういったものかを記載しましたね↓
- LINEのアカウント
- Twitterのアカウント
- Amazon Prime、Netflixのアカウント...
AWSアカウントとは一般的なアカウントと同じ意味を持ちながらそれ以上の意味を持ちますが、IAMユーザーとは「一般的なアカウント」と同じものであると理解してokです
つまりIAMユーザーは一般的なアカウントと同じく下記の意味を持っています
- サービスを利用する際に必要な権利や、個人認証情報であり
- ユーザーを識別できるもの
ルートユーザーも一般的なアカウントと同じって解釈でいい？
「Yes」ですが、少し補足すると一般的なアカウントと同じでありながら「全ての権限を持っている強力なアカウント」という点が重要です
- AWSアカウント
- 一般的なアカウントと同じであるがそれ以上の意味を持つ
- ルートユーザー
- 一般的なアカウントと同じ
- IAMユーザー
- 一般的なアカウントと同じ
しかし、前途したようにルートユーザーはAWSアカウント内のすべてのリソースとサービスに対するフルアクセス権限が付与されているという点を理解することがポイントです
そしてIAMユーザーはルートユーザーと違い「権限に制約をかけられる」という点がIAMユーザーの本質であり重要な点です
より詳しい内容は後述しますね^^
IAMユーザーが必要なのはルートユーザーが危険だから？
復習として、ルートユーザーはAWSアカウントを作成すると自動的に設定されるアカウントであり、AWSリソースへの無制限のアクセス権を持っているんでしたね
この全権限を持つルートユーザーを使用すると、意図せず誤操作やセキュリティリスクの原因となってしまう可能性があるのです
例として、下記のようなヒューマンエラーを起こす可能性があります
- 誤操作により重要なリソースの削除
- 設定変更ミスにより、リソース不足でサーバーがダウン
- AWSリソースの高額オプションに入りまくって高額請求が来る
つまり、ルートユーザーはすべての権限を持っているため、言葉の通り「なんでも出来てしまう」のです
これは強力でありながら危険であるという事を意味しています
ルートユーザーを慎重に利用すればいいんじゃないの？
確かに慎重に使えば「問題は起きにくい」のかもしれませんが、ここで重要なのは「問題は起きにくい」という言葉には「問題を起こす可能性が残っている」という点です
触らなければ爆発しない爆弾が隣にあるとします
この爆弾は確かに「触らなければ」爆発はしないのですが、触ってしまう(触れてしまう)可能性があるという時点で、それは危険でありリスクですよね
つまり、ルートユーザーを慎重に使えば問題を起こしにくいという点は間違いではないのですが、「リスクが常に隣にある」という部分がルートユーザーの危険性そのものなのです
IAMユーザーの必要性
IAMユーザーは、セキュリティのベストプラクティスとして非常に重要であり、IAMユーザーを使用する主な理由は以下の通りです
- 最小権限の原則
- 各IAMユーザーには、そのユーザーが必要とする最小限の権限のみが付与される
- これにより、不必要なリスクを排除することができる
- 責任の明確化
- IAMユーザーを使用することで、誰がどのリソースにアクセスできるかを明確に管理できる
- これにより、監査やトラブルシューティングが容易になる
- セキュリティの強化
- ルートユーザーではなくIAMユーザーを使用することで、不正アクセスや誤操作による被害を最小限に抑えることができる
IAMユーザーは1利用者に対して1つ作成する？毎回作成するのめんどいから使い回そうぜ
IAMユーザーは「1つのIAMユーザーを複数人で使いまわさないこと（IAMユーザーを共有しないこと）」が推奨されています。IAMユーザーを複数人で使いまわすことで、悪意のあるユーザーの不正操作や人為的な操作ミスが発生する可能性があり、セキュリティ上ベストプラクティスではありません。
IAMユーザーを「1利用者につき1 IAMユーザーとする」メリットは、
各ユーザーに適切な権限を付与することができること
なにか問題が発生した際に操作履歴から問題を特定できること
が挙げられます。
AWSでは無料でAWSの操作履歴を保管するサービス「AWS CloudTrail」がデフォルトで設定されています。そのため1利用者につき1 IAMユーザーとしておけば、問題発生時にAWS CloudTrailから操作履歴を確認でき、素早く対応できます。
AWSアカウントを不正利用・攻撃から守るためにやるべき設定のまとめ
上記で記載されている通りですね
IAMユーザーを使い回すと人為的な操作ミスに繋がり兼ねないのと、1利用者につき1IAMユーザーを利用することで各ユーザーに適切な権限を付与(必要ない権限は付与しない)することができるため、操作ミスをした際も被害が最小限に抑えられるのが大きいですね
また、AWS CloudTrailでは各ユーザーの操作履歴を保管することができ、もし複数人でIAMユーザーを使いまわしていると「CloudTrailでは一人のIAMユーザーが色々なことをしている」という現実と操作履歴の差異が出てしまうため、使い回すのには問題があるのです
IAMユーザーの作り方
せっかくだしAWSアカウントから作ってみる ~ AWSアカウントの作成からルートユーザーの確認、IAMユーザーが初期段階では存在しないことの確認
gmailアカウント作成
既に僕が持っているメールアドレスではAWSアカウントを作成済みだったので、新しくgmailアカウントを作成
(メールアドレスはgmailじゃなくても問題ないです👍)
AWSアカウント作成
まずは、AWSアカウント作成ページを開きます
既に持っている or 新しく作成したメールアドレスを入力(AWSアカウント名は任意の名前)して「認証コードをEメールアドレスに送信」をクリック
入力したメールアドレス宛に認証コードが送られてくるので確認して入力する
個人情報の入力画面に飛ぶので、個人情報を入力する
次にクレジットカード情報を入力する
上記が完了すると下記画面が表示されるので、「ぺーシックサポート - 無料」を選択した状態で「サインアップを完了」をクリック
AWSアカウントが作成できました^^
サインイン
「AWSマネジメントコンソールにお進みください」をクリックすると下記画面が表示されます
まず、ルートユーザーはAWSアカウントを作成するのと同時に作成される最初のアカウントであり強力なアカウントですね
そして、IAMユーザーは初期段階では作成されておらず、ルートユーザーまたはIAMユーザーから作成(詳細は後述)する必要があるため、現状はルートユーザーを選択してAWSアカウント作成時に登録したメールアドレスとパスワードを入力してサインインします
サインイン完了でえええす！
まず、新しくAWSアカウントを作成したばかりの段階では下記のようにIAMで検索>ダッシュボードのユーザーを表示しても何も表示されません
(IAMユーザーは自分で臭いする必要があるため)
ではでは画面右上の「ユーザーの作成」を押してIAMユーザーを作成していきます
ユーザー名を入力して「AWS マネジメントコンソールへのユーザーアクセスを提供する - オプション」を選択する
ちょ待てい、「AWS マネジメントコンソールへのユーザーアクセスを提供する - オプション」ってなんやねん
選択すると
オプションを選択すると、そのユーザーはAWSマネジメントコンソールにログインできるようになります
まあ単純にAWSを画面で操作できるようになるよって感じですね
ちなみに、オプションを選択するとAWSマネジメントコンソールにアクセス出来る + API呼び出しもできます👍
選択しないと
オプションを選択しないと、ユーザーはAWSマネジメントコンソールにアクセスできなくなりますが、API呼び出しやCLI（コマンドラインインターフェース）、SDKs（ソフトウェア開発キット）を通じたプログラムによるアクセスは可能です
AWSを画面操作する必要はなく、API呼び出しでのみ利用する場合に選択するって感じですね👍
ちょ待てい、「Identity Centerでユーザーを指定する」と「IAMユーザーを作成します」の違いってなんじゃい
前提: Identity Center(旧称：AWS SSO)とは何か
AWS Identity Center(旧称 AWS Single Sign-On、AWS SSO)は、AWS アカウントとビジネスアプリケーションの両方へのアクセスを一元管理するためのクラウドベースのサービスです
このサービスを使用することで、ユーザーは一つのユーザーID(シングルサインオン)で複数のAWSアカウントやアプリケーションにアクセスできるようになります
管理者は、中央の場所からユーザーのアクセス権を簡単に管理し、セキュリティを強化しながらユーザーのアクセス管理を効率化できます
Identity Centerを選択する場合とそのメリット
- 選択すべき場合
- 複数のAWSアカウントの管理が必要な場合
- 外部アプリケーションやサービスへのアクセスを一元管理したい場合
- ユーザーが複数のサービスやアプリケーションにシングルサインオンでアクセスする必要がある場合
- メリット
- アクセスの一元管理: 複数のAWSアカウントやアプリケーションへのアクセス権を一か所で管理できる
- ユーザーは複数のサービスに対して一つのIDとパスワードでログインできるため、利便性が向上する
- 中央でのアクセス管理により、アクセス権の不適切な付与を防ぐことができる
IAMユーザーを作成する場合とそのメリット
- 選択すべき場合
- 単一のAWSアカウント内でのアクセス管理が主な目的の場合
- アプリケーションやスクリプトがAWSリソースにプログラムによるアクセスを必要とする場合
- 組織内のユーザー数が少ないか、AWSアカウントの管理が比較的シンプルな場合
- メリット
- 各IAMユーザーに対して、AWSリソースへのアクセス権を細かく設定できる
- APIキーを利用して、プログラムからAWSサービスへのアクセスを可能にする
- 特定のユーザーやユースケースに合わせたアクセスポリシーを設定できり
使い分け
複数のAWSアカウントや外部アプリケーションのアクセスを管理する必要がある大規模組織では、Identity Centerが適しています
一元管理により、アクセス制御を簡素化し、ユーザーの利便性を高めることができます
単一のAWSアカウントを使用する小規模な組織や、特定のAWSサービスへのプログラムによるアクセスが必要な場合は、IAMユーザーが適しています
細かなアクセス権の管理や特定のリソースへのアクセスが必要な場合に柔軟に対応できます
下記を設定して「次へ」をクリック
「ポリシーを直接アタッチする」を選択し、「AdministratorAccess」を選択して次へ
登録事項を確認して問題が無ければ作成
作成するとパスワードが表示されます
※もしパスワードを自動で生成されるように設定した場合は、「csvのダウンロード」か、パスワードを表示してパスワードを保存しておいてください
(パスワード情報が確認できる画面はこれっきりのため注意です^^)
Eメールでのサインイン手順を押すと？
Eメールで指定した相手にログイン情報などを送ることができるみたいですね^^
お！！先ほどまではなかったユーザー表示画面に新しいIAMユーザーが登録されているううううううう！！！！！！！！！
IAMユーザーの作成までは完了です！！
では最後に、作成したIAMユーザーで再度ログインしてみましょう
下記の操作を行います
- コンソールサインインURLでアクセス
- ユーザー名を入力
- パスワードを入力
- サインイン
「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります」にクリックをした場合、下記画面のようにパスワードの更新が求められるため、指示に従い更新しましょう
(更新後のパスワードも当然ですが厳重に保管するようにしましょう^^)
入れましたね^^
これでIAMユーザーの作成 + IAMユーザーでログインできるところまで確認できました^^
(先ほどちょこっと出てきた「ポリシー」に関しては後で詳しく説明します👍)
意外とIAMユーザーの作成簡単でしたね^^
IAMグループ
IAMユーザーの作成は完了したので、次はIAMグループについて見ていきます
IAMグループって「IAMユーザーのまとまり・グループ？」ってイメージを持つと思うのですが、その通りです
ただ、１点だけ重要な点があります
それは、特定のIAMグループには特定のルールがあるという事です
例として、各国にはそれぞれの法律があり、その国に住む人々はその法律に従って行動しますよね
これと同様に、IAMグループにも特定のアクセスルールがあり、グループに属するユーザーはこれらのルールに従う必要があるのです
理解をしやすくするためにtest-groupというIAMグループがあるとします
そしてこのグループには以下のようなS3バケット操作に関する権限が割り当てられています
- S3バケットへのファイルアップロードを許可
- S3バケット内のファイル編集を許可
- S3バケットのファイル削除は不許可
この場合、test-groupに属するユーザーは、これらのルール（権限）に基づいてS3バケットを操作することができます
(このグループに属するユーザーはtest-groupのルールに基づくためS3バケットのファイル削除は出来ません👍)
IAMグループを利用することで、特定のルールセットをグループ内の全ユーザーに一括して適用することが可能になり、アクセス権限の管理が効率的かつ一貫性を持って行えるようになります
実際にIAMグループを作成して、それをIAMユーザーに割り当ててみた
まずIAMグループの画面に行き、「グループを作成する」を選択
適当なグループ名を入力
グループにアタッチするポリシーとしてAmazonS3ReadOnlyAccessだけを選択し「グループを作成」をクリック
作成が無事完了ですね^^
作成したIAMグループを見てみると、まだ作成したIAMグループに属するユーザーがいないことが分かりますね
また、許可されているポリシーがAmazonS3ReadOnlyAccessだけというのも分かります
ではでは、IAMユーザーを作り、IAMグループを割り当ててみます
まずは先ほどと同じようにIAMユーザーを作成します
適当なユーザー名などを入力します
許可のオプションで「ユーザーをグループに追加」を選択し、先ほど作成したグループを選択し「次へ」をクリック
ここも問題なければ「ユーザーの作成」をクリック
新しいIAMユーザーが作成されていますね！
新しく作成したIAMユーザーをクリックすると、「許可ポリシー」にAmazonS3ReadOnlyAccessが表示されていますね！
つまり、IAMグループで作成したルールがIAMユーザーにしっかりと割り当てられているという事ですね^^
では最後に、test-groupを見てみましょう
先ほどはtest-groupに属するユーザーが0件だったのに、今はしっかり追加されていますね！！
~ 完全に理解した ~
IAMポリシーとIAMロール
IAMポリシーとIAMロールは別々の概念であるものの、互いが密接に絡み合っているためここでは一緒に話しちゃいます(そちらの方が理解しやすいので👍)
IAMポリシーとは？
IAMポリシーとは「AWSのユーザーがどのリソースに対してどのような操作を許可するのか否か」というルールを定めたものです
例としてAmazonS3ReadOnlyAccessというポリシーがあるのですが、これはS3に対して読み取りだけを許可するポリシーです
つまりこのAmazonS3ReadOnlyAccessポリシーをIAMユーザーWAROTAにアタッチ(適応)すると、IAMユーザーWAROTAに対して下記のルールを定めたことになります
- WAROTAというユーザーが
- S3というリソースに対して
- 読み取りという操作を行うことができる
IAMポリシーとは「AWSのユーザーがどのリソースに対してどのような操作を許可するのか否か」というルールを定めたものです
↑この通りですね^^
IAMポリシーにも3つの種類がある？
IAMポリシーは主に3つのカテゴリーに分類されます
- AWS管理ポリシー
- カスタマー管理ポリシー
- インラインポリシー
それぞれのポリシータイプは、作成者、利用の柔軟性、およびカスタマイズの可否といった違いがあります
詳しく見ていきましょう
AWS管理ポリシー
- 作成者
- AWS
- 概要
- AWSによってあらかじめ定義されたポリシーで、AWSサービスを利用するための標準的な権限セットを提供している
- ポリシー名は通常、「AWSサービス名＋FullAccess」や「AWSサービス名＋ReadOnlyAccess」という形式
- 例として「AmazonS3FullAccess」はS3バケットへの完全アクセス権を与えるAWS管理ポリシー
- 特徴
- AWS管理ポリシーは1000個以上のポリシーが提供されている
- ※ユーザーによる編集は不可能
- AWS管理ポリシーは1000個以上のポリシーが提供されている
まあ単純にAWS側が用意してくれてるポリシーで種類がたくさんある + 編集はできないって感じですね！
カスタマー管理ポリシー
- 作成者
- ユーザー
- 概要
- ユーザー自身が特定のニーズに合わせて作成するポリシー
- AWS管理ポリシーに比べ、より細かい権限の調整が可能で、特定の操作やリソースへのアクセス制御をカスタマイズできる
- 特徴
- これらのポリシーはユーザーによって追加、削除、修正が可能であり、複数のIAMエンティティ（ユーザー、グループ、ロール）での再利用が可能
インラインポリシー
- 作成者
- ユーザー
- 概要
- これもユーザーによって作成されるポリシーであり、特定のIAMユーザー、グループ、またはロールに直接組み込まれる
- カスタマー管理ポリシーと同様にカスタマイズが可能だが、これは特定のエンティティ(特定のユーザーや特定のグループ)に固有であり、他のエンティティと共有することはできない
- 特徴
- ポリシーの管理をエンティティごとに限定したい場合に適しており、ユーザーによる追加、削除、修正が可能
カスタマー管理ポリシーとインラインポリシーの違い
単純に、カスタマー管理ポリシーは再利用可能で柔軟な一方、インラインポリシーは特定のエンティティ専用で、より厳密なアクセス管理が可能になる、って感じですね^^
IAMポリシーを覗いてみた
画面でIAMを開き、ダッシュボードに表示されている「ポリシー」をクリックすると下記のような画面が表示される
これら一つ一つがポリシーなんですね
IAMロールとは？
IAMロールとは、一つのAWSリソースが別のAWSリソースにアクセスするための権限です
例として、Lambda関数がAmazon S3バケット内のファイルを取得する必要がある場合、Lambdaに「S3バケットのファイルにアクセスする権限」を持つIAMロールを割り当てます
こうすることで、Lambdaは指定されたS3バケットにアクセスできるようになります
(LambdaにS3バケットのファイルにアクセスする権限を割り当てたからですね)
IAMロールの割り当て制限とその対応
IAMロールには、一つのAWSリソースに対して一つのロールのみ割り当てることができるという制限があります
つまり、Lambda関数に初めに「S3バケットのファイルを取得する権限」を持つIAMロールを割り当てた後、さらにLambdaからAmazon EC2インスタンスへのアクセス権も必要になった場合、新たにロールを追加することはできません
oh...
このような状況においては、IAMロールへの複数ポリシーの割り当てが解決策となります
- 最初に、LambdaにS3バケットへのアクセス権を持つIAMロールを割り当てる
- 追加でEC2へのアクセス権が必要になった場合、新しいロールを割り当てるのではなく、1で割り当てたIAMロールにEC2アクセスを許可するポリシーを追加アタッチする
- この方法により、Lambdaは既存のIAMロールを通じてS3とEC2の両方にアクセスできるようになり、AWSリソースに一つのIAMロールを割り当てるという制限を回避することができる
上記のようにすることで、IAMロールの制約をうまく避けながらAWSリソースに複数のポリシーをアタッチすることが可能になります
↓下記で実際に設定手順などを紹介しているので気になる方は見てみてください^^
LambdaにS3へのアクセスを許可するIAMロールをアタッチした後、そのIAMロールにIAMポリシーをアタッチしてみた
※IAMロールとIAMポリシーの連携部分を確認したいためLambda関数の作成は適当にやります
まずはIAMロールの画面に行き「ロールを作成」をクリック
AWSのサービスを選択し、ユースケースでLambdaを選択する
作成するIAMロールの許可ポリシーとしてAmazonS3FullAccessを選択して次へ
適当な名前を付ける
AmazonS3FullAccessというポリシーを持ったIAMロールが作成されましたね
次にLambdaの画面に飛び、関数の作成をクリック
適当な関数名を入力し、実行ロールとして「既存のロールを使用する」を選択して、先ほどのIAMロールを指定する
(そのほかはデフォルト)
関数の作成が完了しましたね
上記画面の少し下に行くと、設定タブがあるのでクリック
ロール名という部分に先ほど設定したIAMロールがあるため、IAMロールをクリック
現状はAmazonS3FullAccessしかポリシーがアタッチされていないことが分かりますね
ではでは「許可を追加」をクリックしてみましょう
入力欄で「ec2full」と入力するとAmazonEC2FullAccessが表示されるため、選択して「許可を追加」をクリック
もう一度Lambdaの設定タブからロール名をクリックしてみると
先ほどはAmazonS3FullAccessのポリシーしか追加されていなかったのにAmazonEC2FullAccessが新しく追加されていますね^^
これでIAMロールの「一つしかAWSリソースに割り当てられない」という制約をうまく回避し、LambdaがS3とEC2どちらにもアクセスできるようにできました^^
アクセス管理のベストプラクティス
IAMを利用するうえで重要な考え方やポイントがいくつかあります
ここでは重要な考え方やポイントを具体的に説明していきます
最小権限の原則とその重要性
最小権限の原則とは、ユーザーやシステムが業務を遂行するのに必要最小限の権限のみを持つべきだという考え方です
※「最小権限の原則」という考えはIAMに限ったものではなく、様々な分野・セキュリティ領域で重要な考え方として浸透しています
この原則に従うことで、不正アクセスやデータ漏洩のリスクを軽減し、セキュリティインシデントの影響範囲を最小限に抑えることができます
最小権限の原則を適用するためには、まず各ユーザーやシステムの役割と業務内容を正確に理解し、それに基づいて必要なアクセス権を割り当てる必要があります
さらに、定期的なレビューを通じてアクセス権を更新し、不要な権限を削除することが重要です
まあ単純に「必要ある権限だけ与えましょう・必要ない権限は与えないようにしましょう」って感じですね
IAMはアクセス権限などを中心に扱うサービスなので、「最小権限の原則」をしっかりと理解した上で作業を行って行きましょう^^
マルチファクタ認証（MFA）の設定と、セキュリティを強化するためのその役割
マルチファクタ認証（MFA）とは、パスワードだけでなく、SMSや電子メールによる確認コード、生体認証など、複数の認証手段を組み合わせてセキュリティを強化する方法です
MFAを導入することで、パスワードが漏洩した場合でも、不正アクセスを効果的に防ぐことができます
安全なアクセスキーの管理方法と、アクセスキーのローテーション
アクセスキーは、APIやサービスへのプログラム的なアクセスを提供するために使用される重要な情報です
安全な管理方法には、アクセスキーを安全な場所に保管し、不要になったキーはすぐに無効化することが含まれます
↓こういった大きな事件も過去にあるため、非常に重要ですね
「アクセスキーのローテーション」とは、定期的に新しいキーに交換し、古いキーを無効化するプロセスのことを指します
このプロセスを適用することで、キーが漏洩した場合のリスクを軽減し、セキュリティを強化することができます
ローテーションの頻度は、組織のセキュリティポリシーによって異なりますが、少なくとも年に一度は行うことが推奨されているようです^^
まとめ
IAMってAWSにおいて基礎的な部分でありながら、結構理解する範囲が広いため大変ですよね
しかし一度理解してしまえば意外と簡単だったことに気付くため、今回本記事をまとめたことで私自身IAMをしっかりと理解することができました^^
ここまで読んでいただきありがとうございました^^
おつかれさまでーーえす!!
参考サイト一覧
Discussion