AWS IAM のユーザーとロールとポリシーを整理してみた

皆さん、こんにちは。技術開発グループのn-ozawanです。
鹿の角は春先なると自然と抜け落ち、1年かけて生え替わります。

本題です。
AWSでサービスへのアクセス制御を一元管理するサービスとして「AWS IAM」があります。システムのセキュリティ確保のために大変重要なサービスであり、AWSで環境を構築するにあたって知っておくべきサービスと言えます。そのため、IAMは仕組みが複雑で使いこなすのが非常に難しいです。今回は要点だけでも簡単に整理したいと思います。

AWS IAM

AWS IAMって何なの？

AWS IAMの正式名称はAWS Identity and Access Managementです。AWS IAMのHPには以下の画像が貼られています。つまりAWS IAMとは、Who (誰)が、What (AWSのサービスやリソース)に、Can Access (どういう条件でアクセス出来る)のかを一元管理するサービスです。

ユーザー

Who (誰) は、そのAWSのサービスやリソースにアクセスする人、もしくは、AWSのサービスです。AWSではこのWho (誰)をプリンシパルと呼びます。

IAMユーザーは、「人」が、そのAWSのサービスやリソースにアクセスする場合に定義します。IAMユーザーはAWSコンソールへログインするユーザーもあれば、ログインせずにAWS CLIでサービスやリソースにアクセスするユーザーもいます。

AWSアカウントを作成直後はルートユーザーがいますが、ルートユーザーの利用は推奨されていません。AWSアカウントの作成直後はAWSコンソールへログイン可能なIAMユーザーを作成するのが良いでしょう。

ロール

IAMロールは、「AWSのサービス」が、別のAWSのサービスやリソースにアクセスする場合に定義します。例えば、Lambdaの処理内容をログとしてCloudWatchに出力したい場合、Who (誰) はLambdaであり、What (AWSのサービスやリソース) はCloudWatchログとなります。Lambda関数を作成する際、必ずIAMロールをLambda関数に付与します。

AWSサービスは作成した直後なんの権限も持ちません。先ほどのLambdaの例で言うと、作成したばかりのLambdaは何の権限も持っていませんので、CloudWatchログを出力することも出来ません。なので必ずロールを付与してあげる必要があります。

ポリシー

IAMポリシーは、What (AWSのサービスやリソース)とCan Access (どういう条件でアクセス)をJSON形式で記述します。IAMポリシーは、IAMユーザーもしくはIAMロールに対してアタッチして使用します。AWSでは1000を超えるIAMポリシーが用意されており、基本的にはこれらのIAMポリシーをIAMユーザーもしくはIAMロールにアタッチすればよいでしょう。ただ、より詳細にIAMポリシーを定義したい場合はIAMポリシーを作成する必要があります。

マルチアカウント

IAMユーザーをAWSアカウント毎に作成すると管理が煩雑になります。AWS OrganizationsとIAM Identity Centerを連携することで、AWSコンソールにログインするIAMユーザーを一元管理することが出来るようになります。

また、AWS STSにより、異なるAWSアカウントに対してIAMロールを一時的に付与することも可能であり、これにより異なるクラウド環境間でAWSのリソースを利用することが出来ます。

おわりに

今回はAWS IAMについて簡単にまとめてみました。これ以外にも色々とあり、例えばロールを付与するやり方としてPassRoleとAssumeRoleがあったり、ポリシーに関してはリソースポリシーや信頼ポリシーなどがあります。これらを知らないと、正しくポリシーを設定したと思っても、想定通りに動作しないばかりか、セキュリティに問題が生じることがあります。

AWS IAMはクラウド環境構築に重要なサービスです。検索すればより詳しく解説しているサイトが見つかると思いますので、興味ある方は探してみてください。

ではまた。