[AWS]初心者でも分かるIAMのキホン

インフラSEの宮本(@miyamon_ky)です。前回はDockerの基礎についてブログしました。

Dockerの基礎知識とNginxコンテナを動かしてみた

今回はAWSのIAMリソースをTerraformでコード管理しようとした時に、IAMの理解が足りていないと思ったところあったので復習もかねて記事にしました。セキュリティのアーキテクトを考えるうえで一番大事なリソースですので、こちらを参考にしていただけますと幸いです。

IAMとは

「Identity and Access Management」の略で、IDとアクセス権を管理する機能です。IAMを使用すれば、誰がどのサービスにアクセスできるのか、許可、拒否することができます。
ここで言う「誰が」とは、利用ユーザー(人)だけでなく、AWSのリソースに対しても同じで、例えば「特定のEC2インスタンス」が「特定のS3」へのデータを利用する事を許可することなど制御したい時に利用できます。

AWSとしてはセキュアなアーキテクトを考える上で、必要最低限の権限のみを付与することが推奨されています。構築する際、必要なアクションが許可されていない事が原因で通信の処理が失敗することなどありますが、仕組みを理解して何を許可するのかしっかり整理が必要です。

特にIAMを理解するには、3つの主体「IAMユーザー」「IAMポリシー」「IAMロール」を押さえておく必要があると思いますので、次の項から順番に説明していきます。

IAMユーザー

AWSアカウントを利用する「人」や「サービス」に対して与えられるIDです。この「IAMユーザー」に対しては、マネジメントコンソールへのアクセスを提供することが可能で、ここで作成した時に生成するパスワードを利用してログインすることができます。また、S3やDBのスクリプトで認証を利用したい場合、アクセスキーを発行して認証する方法もあります。

そして複数のユーザーを纏めて管理したい場合は「ユーザーグループ」を利用する事も可能です。例えばプロパーとパートナーで権限を分けたい場合などに利用できて、プロパーグループには強い管理権限を、パートナーグループには特定のリソース操作のみを許可するなどといった管理ができます。

IAMポリシー

IAMポリシーは、JSON形式で記述されるアクセス制御ルールで、これをユーザーやグループ、ロールに割り当てることでAWSリソースへのアクセス権限を管理できます。例えば特定のS3バケットへのファイルアップロードを許可したい場合は以下のように書きます。

IAMポリシーの要素を解説すると

• Vesion

ポリシー構文のバージョンをしてします。
どのバージョンが最新かは公式ドキュメントを確認した方が良いのですが、このブログを記載している現時点では[2012-10-17]が最新バージョンでした。

• Statement

ポリシーのルールを定義するメインの部分です。
この中に[Effect][Action][Resource]を記載していきます。

• Effect

このポリシーで指定するActionを許可（Allow）または拒否（Deny）するするのか指定する部分です。

• Action

許可または拒否するAWSの操作を指定する部分です。
例えばs3:PutObjectの場合、AWSのストレージリソースである[S3]へのファイルアップロード[PutObject]するActionを指定していることになります。

• Resource

操作対象となるAWSリソースをarn形式で指定して利用する部分です。S3の場合であれば、オブジェクトパスをより具体的に書くことでActionが可能な対象の制限を絞ることが可能です。

（例）
バケット全体に対して制限：arn:aws:s3:::example-bucket/*
特定のフォルダに限定して制限：arn:aws:s3:::example-bucket/uploads/*

IAMロール

IAMロールとは、AWSリソースへのアクセス権限を特定のエンティティへ一時的に付与するための役割です。ロールの中にIAMポリシーを定義し、それをエンティティへアタッチすることで初めて機能します。エンティティとはAWSのIAM周りでよく使われる言葉ですが、例えば以下のものを指します。

• IAMユーザー
• AWSリソース、サービス（EC2、Lambda関数などAWSで構築できるもの全般）
• 外部IDプロバイダー（Active directoryなど）

これらのものにIAMポリシーが書かれたIAMロールをアタッチしてアクセス許可/拒否を制御するということです。

IAMユーザとIAMロールの違い

この２つ複数のIAMポリシーをアタッチ出来るという面で少し似ているような気がしたのですが、異なる役割をしています。IAMロール自体には固定の認証情報（パスワードやアクセスキー）がありません。その代わりに一時的な認証情報を付与するのがIAMロールの役割となります。

	IAMユーザ	IAMロール
定義	AWSアカウントに関連付けられた個別のエンティティ 特定の個人やアプリケーションを表す	AWSリソースや外部エンティティに一時的なアクセス権限を付与するための役割
認証情報	パスワードまたはアクセスキーを持つ	固定の認証情報は持たない。必要に応じて一時的な認証情報（STSトークン）が発行される
アクセス対象	主に個人や特定のアプリケーション	他のAWSリソース、外部サービス、または別のAWSアカウントのエンティティ
引き受け	引き受けの概念はなく 常に固定のアクセス権限を持つ	IAMロールはエンティティに引き受けられて 引き受けたエンティティがアクセス権限を一時的に得る
使用例	AWS管理者がAWSリソースを操作 固定のアプリケーションがAWSにアクセス	EC2インスタンスやLambda関数がAWSリソースを操作

一般的な作成フロー

ここまでIAMで特に重要な3つの要素を説明しましたので、利用の流れを図にしました。まずはIAMポリシーを作成し、そのポリシーを何にアタッチするのかを要件に合わせて選ぶのが良いと考えています。

セキュリティを考えたIAMベストプラクティス

最後にAWSで公開されているベストプラクティスで特に重要だと思うものを抜粋します。

1. 最小権限の原則
   とにかく動作確認を見たい場合はどのActionも許可するポリシーを作成しがちですが、どのインスタンスが何のActionをするためにあるのかを把握して、必要最小限の権限を服すポリシーを作成しましょう。
2. ポリシーの再利用
   同じ権限を複数のユーザーやロールで共有する場合は、管理用のポリシーを利用して余分なポリシーは利用しないようにしましょう。
3. コンソール管理用IAMユーザーのMFA適用
   ユーザーIDとパスワードを使用してのログインは楽ですが、近年不正ログインの問題も発生しており、MFAを有効化するだけでもMicrosoftが言うにはアカウントが侵害されるリスクは 99% 以上低下することが可能というデータがあります。
4. リソースの明示的な指定
   リソースを*で指定するのではなく、なるべく特定のリソースのarnを書いて制限するようにしましょう。
5. モニタリングとレビュー
   定期的にIAMポリシー、ロール、ユーザを確認し、利用しなくなったエンティティ用に作成したものは削除しましょう。

参照：IAMベストプラクティス

以上、ありがとうございました。