【AWS】IAMやポリシーについて

どーも！

たかぽんです！

今回はAWSのIAMやポリシーについて調べてみようと思います！

・・・というのも、筆者現在色々と触っていてIAMやポリシーを作成する機会があるのですが、正直いまいち理解できておらず...

この機会にしっかり理解しておきたいなと...!

と、いうわけでみていきます！

IAMって何？

まずはそもそもIAMってなんでしょうか？

調べてみたところ、Identity and Access Managementの略語らしいです。

まずはこの略語から推察してみます。

identityは...

同一であること、同一性、一致、同一人であること、本人であること、正体、身元、独自性、主体性、本性

https://ejje.weblio.jp/content/identity

らしいです。

そしてaccessはなんとなく想像できるかと思います。

それをマネジメントするわけですから...

(なんらかのサービスの)実体やアクセスを管理するもの...

といった感じでしょうか？

では、実際に公式サイトを参考にしてみます。

実際に見てみるのは以下のページです。

一番トップにある説明として...

AWS Identity and Access Management (IAM) では、AWS のサービスやリソースへのアクセスを安全に管理できます。IAM を使用すると、AWS のユーザーとグループを作成および管理し、アクセス権を使用して AWS リソースへのアクセスを許可および拒否できます。

IAM は追加料金なしで AWS アカウントに提供されている機能です。料金は、お客様のユーザーが使用した他の AWS サービスに対してのみ発生します。

とあります。

正直直訳とは少しニュアンス変わりそうですね...w

文章にある通り、AWSのサービスやリソースへのアクセスを管理するもののようですね。

IAMは追加料金も不要なので、いくつ設定しようがコストの面に関しては気にしなくて良さそうですね！

ユースケース

さて、ではさらに詳しく見ていこうと思います。

まずは先程のトップページにあるユースケースから、"AWS リソースへのきめ細かなアクセス制御"を確認してみます。

AWSリソースへのきめ細かなアクセス制御

IAM を使用すると、ユーザーが AWS のサービス API や指定リソースへのアクセスをコントロールできるようになります。また、日時 (ユーザーが AWS を使用する方法の制限)、アクセス元の IP アドレス、SSL を使用しているかどうか、多要素認証デバイスによる認証済みかどうかなど、特定の条件を追加することもできます。

先程お伝えした通り、リソースやサービスへのアクセスコントロールが可能という項目ですね。

ただ、日時やIP、SSLでのアクセス、多要素認証されているかどうか？といった細かい条件でアクセスの管理を行うこともできるようですね。

また、リンクもあるのでそちらものぞいてみます。

まずは先程引用した文章の"ユーザー"を確認します。

リンク先は"Manage IAM users"で、IAM ユーザーの管理についてのようです。（英語のみっぽいです）

You can create users in IAM, assign them individual security credentials (such as access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources.

IAMとしてユーザーの発行を行い、ユーザーごとの認証情報を設定することが可能です(AWSアクセスキーやパスワード、多要素認証デバイス等)。また、AWSのサービスやリソースに対して、一時的なセキュリティ認証情報をリクエストすることも可能です。

といった具合でしょうか。

おそらく大抵のみなさんがAWSへアクセスする際にAWS アクセスキーやAWSシークレットキーといったものを用いていると思います。

もともとAWSアカウントを発行した際、ルートユーザーという、全知全能のアカウント（どんなことでもできるアカウント）があります。

ただ、全員が一つのアカウントを使う....というのはそもそも微妙ですし、漏洩した場合になんでもされてしまうと困ります。

そのため、基本的にそのルートユーザーではなく、適材適所の権限を絞ったアカウントを発行、開発者やそのほか利用者へ共有して利用することが推奨されています。

その際、発行するアカウントとして、IAMユーザーというものを作成し、IAMユーザーごとの権限を設定するわけですね。

みなさんがいつもアクセスしているマネジメントコンソールへアクセスできるのも、このIAMユーザーで許可されているからなんですね。

そして...

IAMユーザーは以下の条件に当てはまる場合、利用すると良さそうです。

1. Privileged administrators who need console access to manage your AWS resources.

2. End users who need access to content in AWS.

3. Systems that need privileges to programmatically access your data in AWS.

ざっくり訳すと...

1. AWSリソースを利用するため、コンソールを使う必要がある管理者特権のある人

2. AWSのコンテンツへアクセスする必要のあるエンドユーザー

3. AWSのデータにアクセスするための特権が必要なシステム

こういったものに対してIAMユーザーを使うべきのようですね。

そのため、人だけでなく、システムに対してIAMユーザーを使用することもあるようですね。

また、それに引き続いて先程ちょっと触れたルートユーザーのお話し、IAM userの正しい作り方...などが解説されていました。

では次に"アクセスをコントロール"部分のリンクをあさってみます。

こちらは日本語がありますね！w

アクセス許可を使用することで AWS リソースへのアクセス権を指定できます。アクセス許可は IAM エンティティ (ユーザー、グループ、およびロール) に対して付与されます。デフォルトではこれらのエンティティにはアクセス許可は設定されません。つまり、IAM エンティティは、ユーザーが特定のアクセス許可を付与するまで AWS では何もできません。エンティティにアクセス許可を付与するには、アクセス権の種類、実行できるアクション、アクションを実行するリソースを指定したポリシーをアタッチします。また、アクセスを許可または拒否するために必要な条件を指定できます。

IAMのアクセス許可は、上記にあるように、IAMエンティティ（ユーザー、グループ, ロール）に対して付与するそうですね。

そして、IAMエンティティを作成しても、アクセス許可の設定がないと何もできないそうですね。

つまり、つくりっぱはダメで、ちゃんと付与しないと何もできないぞ！ってことですね...!

まぁ、デフォルトで何かしらの権限がついてしまうと意図しない権限がついたままになってしまう...といったことへの対処も含んでいるのかなと思います。

ホワイトリスト的に管理すべき内容の一つといえますね。

そして、実際にアクセス権を付与する場合は"アクセス権の種類", "実行できるアクション", "アクションを実行するリソース"を指定してポリシー付与してあげる必要があるようです。

アクセス権の内容が設定されているものを"ポリシー"と呼びます。

アクションとは、例えばS3へファイルを配置したり、S3から情報を取得したり...

AWSのサービスやリソースの操作のことを表します。

そして、"Resources"として、上記のアクションをどのリソースに対して実行できるかどうかを指定します。

リンク先ではもう少し詳しく解説されていますが、ここでは割愛します...!

IAMでアクセス権限を付与する場合は、IAMエンティティに対してポリシーという形で付与してあげるんですね。

では、再度ユースケースの文章に戻り、リンクがもう二つあったのですが...

"多要素認証デバイス”は、みなさんご存知かと思いますがパスワード、IDと、さらにもう一つの要素で認証しましょうねー！ってやつですね。

筆者はgoogle authenticatorというアプリを使っていますが、例えば...

正しいパスワード、IDを入力したあと、そのauthenticatorで表示される認証用の番号を入力する...という工程を追加することができます。

アプリ側で認証用の番号は一定時間ごとに更新される（15秒程度)ため、そのアプリを確認できるユーザーでないとログインができないわけですね。

アプリでない場合は例えばメールアドレスを登録しておき、そのメールアドレスに対してログイン用の認証番号が送信されたり...といったパターンもあるかと思います。

今の時代はやっていて当たり前...になってきているので、設定しておくべきでしょう。

そして、最後の"特定の条件"に関しては先程の"IAMアクセスの許可の管理"ページに飛ばされますね。

おそらくそのポリシーの"Conditions"のことを指しているんでしょう。

例えば、ユーザーが特定の IP 範囲から接続している場合、またはログイン時に多要素認証を使用した場合に、特定の S3 バケットにのみアクセス権を付与できます。

といった感じですね。

IPだったり多要素認証での条件付けができるということですね！

さて、長くなりましたがざっくりまとめると...

非常に権限の高いユーザーに対する Multi-Factor Authentication

さて、次のユースケースは"非常に権限の高いユーザーに対する Multi-Factor Authentication"についてですね。

ただ...これさっき説明した内容やん...w

リンク先も多要素認証のものと一緒です...w

なぜ同じリンクが貼られているのか...ですが、おそらく前述の"アクセス制御"にて語られている多要素認証に関しては、アクセスする側が多要素認証でアクセスしているかどうか？をポリシーで設定して、その条件にてアクセス管理ができる...というところに重点を置いていたのかなと思います。

そして、こちらでの多要素認証に関しては、先程お伝えしてしまいましたが、強い権限が必要になるユーザーに対しては特に多要素認証をつけることで、セキュリティ性を高めましょうね！というところに重点を置いている...んだと思います...たぶん。

リンク先ではIAMユーザーでMFA設定できるよ〜っていうことが書かれています。(詳細は割愛します！）

また、資料でよくMFAという単語が出てきますが、Multi-factor Authenticationの略で複数の要素による認証といった意味合いになります。

多要素認証なんだなって思えば大丈夫かと。

では次のユースケースを見てみましょう！

アクセスを分析する

次は分析についてみてみます！

IAM は、AWS 環境全体のアクセス分析に役立ちます。セキュリティチームや管理者は、ポリシーがリソースへの目的のパブリックアクセスおよびクロスアカウントアクセスだけを提供していることをすばやく検証できます。また、ポリシーを簡単に識別および改良して、使用中のサービスのみにアクセスできるようにすることも可能です。これにより、最小限の権限の原則も守ることができます。

IAMはアクセス分析にも役立つそうです...!w(初耳...!）

リンク先を眺めて、筆者的にかいつまんで見ると..,.

Access Analyzer API を使用して、プログラムでポリシーを検証することもできます。

IAM Access Analyzer APIというものがあり、それを用いることで設定しているポリシーの内容が正しく設定されているか確認することもできそうですね...!(テスト的なものなのかな？）

最小権限の導入を続けると、IAM Access Analyzer は既存のアクセスを確認することができ、外部または未使用の意図しないアクセス許可を識別して削除できるようにします。

また、上記のように最小権限でのアクセス権限の導入を行なっておくことで、意図しないアクセスを識別できるそうですね...!

どうやるのかはあんまりわかんないんですが、既存の設定内容からいい感じで予測してくれるんでしょうか・・・？

IAM Access Analyzer は自動推論を使用して、AWS アカウントの外部からアクセスできるリソースの包括的な結果を生成します。

AWSアカウントの外部からのアクセスに対しては自動推論でアクセス許可を分析できるようです。

"リソースの包括的な結果"が何を表しているのか、ですが、別途リンク先に...

脆弱なデータを潜在的に公開する可能性のある設定ミスのクラス全体を検出できます。

とありました。

そのため、自動推論することで、設定ミスの検知等ができるようです。

先程のテストとは別で、テスト含めて正しく設定できてるように見えるが...その設定だと外部に脆弱なデータを公開してしまう可能性のある場合などを検知できる...といった具合なのかなと思います。

深掘りすると時間が足りなさそうなので、自動推論に関してはいったんリンクの共有だけ...

自動推論とは別かもしれないですが、各IAMエンティティがアクセスした履歴日時を継続的に取得して、その履歴を元に、不要そう（使用頻度が低いアクセス許可設定）な設定を削除したりもできるようです。

未使用のアクセス許可を削除できるように、IAM は、IAM エンティティがサービスまたはアクションを最後に使用した日時を指定するための最終アクセス情報を提供します。

どちらかというと細かいアクセス頻度分析...というより、セキュリティの質をあげるためのアクセス分析といったニュアンスの方が大きそうですね。

社内ディレクトリとの統合

次は社内ディレクトリとの統合ですね....!

IAM では、AWS マネジメントコンソールや AWS サービス API へのフェデレーションアクセス権を、Microsoft Active Directory などの既存のIDシステムを使用して、従業員やアプリケーションに付与できます。SAML 2.0 をサポートする ID 管理ソリューションであれば、どれでも使用できます。 または、Amazon のフェデレーションサンプル (AWS Console SSO や API フェデレーション) をご自由にお使いください。

筆者はこちらの機能使ったことがなく、ちょっと理解が浅いんですが...

他社サービスとのIDの連携...といった意味合いが強そうです...!

フェデレーションアクセス権というのは、短的にお伝えすると、異なるネットワークドメイン間でIDを連携し、管理するためのアクセス権のことです。

一度のログインだけすれば複数のWebアプリケーションへアクセスできるようになったり...といった具合ですね。

本来ならサービスAでログインしてもサービスBでログインが必要ですが...それが不要になるんですね。（一方でログインしておけばもう一方でもログインできている...といった形）

また、"Microsoft Active Directory"だけでなく、"SAML 2.0"をサポートしていれば連携できるようですね。

SAML とは Security Assertion Markup Languageの略語で、異なるインターネットドメイン間でユーザー認証を行うための XML をベースにした標準規格だそうです...!(詳細は割愛します！）

と、色々話してきましたが前述した通り、筆者はここら辺全くの無知です..w

ちょっと想像部分が大きくなってしまいますが、以下の資料も合わせて確認すると理解しやすそうです。

上記記事では、以下のように解説されています。

すでにユーザー ID を AWS の外で管理している場合、AWS アカウントに IAM ユーザーを作成する代わりに、IAM ID プロバイダーを利用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができます。

....

IAM ID プロバイダーを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要がありません。IdP では、これらを行うための環境が用意されています。外部ユーザーは、よく知られた IdP (例: Login with Amazon、Facebook、Google) を使用してサインインします。アカウントの AWS リソースを使用するアクセス許可をこのような外部 ID に付与することができます。

つまり、AWSのリソースへのアクセスが必要なユーザーのIDを、IAMユーザーではなく、外部のIdPで管理している場合、そのIDにアクセス権限を付与できる...といった意味合いになりそうです。

そのうち筆者も試してみたいですね...!

まとめ

さて、今回はIAMについて調べてみました...!

フェデレーション周りとかは僕も初知りな内容が多くて...

まだまだ知らない世界がおおいなと...

ポリシーとかはもうちょっと深掘りして調べたいなと思いますね...!

具体的な設定方法等は今回は解説しませんでしたが、機会があれば是非記事にしたいなと...!(すでにたくさん出回ってそうですが...!）

それでわ！