メタップスアドベントカレンダー10日目の記事です。
はじめに
今回は、AWSソリューションアーキテクトの資格試験に向けて勉強した中で、IAMについて学習したことを書いていきます。
IAMとは？
「Identity and Access Management」の略で、AWSのリソースに安全にアクセスできるように、許可・拒否等の権限を制御することができるサービスです。
以下公式の説明です。
IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。
ルートユーザー
AWSアカウント作成時のアカウントのこと。AWSアカウント内全ての操作が可能で、権限の制御ができないです。そのため、通常は使用を最小限に抑え、IAMユーザーに必要な権限を委譲することが推奨されています。
ルートユーザーは以下のタスクを行います。
- ルートユーザーのメールアドレス・パスワードの変更、MFAの設定
- アカウント名の変更
- 1人目のIAM管理ユーザーの作成、設定
- サポートプランの変更
- S3バケットのMFA Delete設定
- 誰も編集できなくなったS3バケット
- AWSアカウントの解約
IAMユーザー
AWSアカウント内で作成される個別のエンティティであり、AWSのリソースにアクセスできるようにするために使用されます。IAMユーザーは大きく以下3つに分けることができます。
管理者ユーザー
IAM自身の操作権限を持つユーザー。
パワーユーザー
IAM自身の操作権限を持たず、それ以外のリソースへのフルアクセスが可能。
ユーザー
必要な権限のみを付与する。通常使うのはこれ。
IAMグループ
IAMユーザーの集合です。多くのIAMユーザーに対して、個別でポリシーを設定するのは手間がかかるため、同じ権限を持つ複数のIAMユーザーをIAMグループとしてまとめて管理できます。また、IAMユーザーとIAMグループはN対Nであり、複数のIAMグループのメンバーとして設定できます。
IAMロール
IAMロールは呼んで字のごとく、「役割」です。複数のポリシーを一つにまとめるもので、あらかじめIAMロールとして設定しておいた役割を与えることができます。
IAMロールはを使用できるのはIAMユーザーだけではないです。
- 他のAWSアカウントのIAMユーザー
- リソース
- 外部のIDプロバイダー
IAMロールの用途はいくつかあります。
IAMユーザーの一時的な権限切り替え
IAMユーザーはIAMロールを引き受けることにより、IAMロールにアタッチしているポリシーの権限に一時的に切り替えられます。
その際、必要なのは以下の2つです。
-
AssumeRoleアクション - STS(Security Token Service)
IAMユーザーはIAMポリシーによって、sts:AssumeRoleというアクションが許可されている必要があります。これは、IAMロールに対してSTSのAssumeRoleリクエストを実行できます。役割引き受けるよみたいな意味合い。
以下のポリシーの例では、AWS アカウント xxxxxxx の UpdateApp ロールに対して AssumeRole を呼び出すアクセス許可が与えられます。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::xxxxxxx:role/UpdateAPP"
}]
}
STSは認証リクエストを実行するサービスです。
IAMロールはsts:AssumeRoleを受け付けると、一時的な認証情報を発行して返します。
IAMユーザーは帰ってきた認証情報に切り替えることでIAMロールにアタッチされているIAMポリシーで許可されている権限でリソースの操作が可能になります。
クロスアカウントアクセス
クロスアカウントアクセスを実現するには、信頼ポリシーが必要です。信頼ポリシーはIAMロールのリソースベースのポリシーです。リソースベースのポリシーについては後ほど記述しますが、別のAWSアカウントからリクエスト来たらその人を信頼する、みたいなイメージ。
AアカウントからBアカウントへのクロスアカウントアクセスは以下の流れ
- AのIAMユーザーがBにAssumeRoleリクエスト
- BのIAMロールの信頼ポリシーによってAを信頼する
- 一時的な認証情報をAのIAMユーザーに返す
- 許可されたリソースを触れる
このようにして一時的に別のアカウントの許可されたリソースへのアクションが実行できる。いちいちIAMユーザーを作らなくていいのが利点。
リソースへのアタッチ
AWSの各サービスから実行されるアクションやEC2インスタンス、LambdaなどにIAMロールを使用して権限を与えることができます。
直接リソースにアタッチするポリシーをリソースベースのポリシーと言います。
対してIAMユーザー、グループ、ロールにアタッチするポリシーをアイデンティティベースのポリシーと言います。詳しくは後述します。
IAMロールのイラストがヘルメットなのも納得、、
IAMポリシー
先ほどから何回か出てきてはいますが、IAMユーザー、グループ、ロールにアタッチして権限を許可するものです。これにより、最小権限の原則を実現できます。
リソースベースのポリシー
AWSのリソースに対して設定し、リクエストの送信元に対して何を許可・拒否するかを設定するポリシーです。
アイデンティティベースのポリシー
IAMユーザー、グループ、ロールといったリクエストの送信元に設定するポリシーです。
以下3つが設定できます。
AWS管理ポリシー
AWSがあらかじめ用意しているポリシー。標準的なポリシーが用意されており、すぐに使い始められます。
カスタマー管理ポリシー
ユーザーが独自に作成するポリシーです。
上記2つは使いまわすことができます。
インラインポリシー
IAMユーザー、グループ、ロール、リソースに直接組み込むポリシーです。インラインポリシーは他の2つと違って使いまわすことができません。また、リソースベースのポリシーではインラインポリシーのみが有効です。
アクセス許可の境界（IAM Permissions boundary）
アクセス許可の境界は、エンティティのアクセス許可の上限を定めるものです。これは制限をするだけで、実際の権限の付与はできません。例えば、S3のオブジェクトを削除する権限を許可し、アイデンティティベースのポリシーで権限を付与する、といった具合です、
そのため、上記の図のように
- IAMの権限
- 設定したアクセス許可の境界（エンティティ単位での設定）
- SCP（OU単位での設定）
これら全てが許可された権限のみが実行できる権限となります。
アクティビティのモニタリング
以下AWSのベストプラクティス
IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する
IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する
IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する
とあるように、IAM Access Analyzerを使用することが推奨されています。
これはリソースベースのポリシーを確認し、対象のリソースが信頼ゾーンの外からのアクセスが可能な状態になっていないかを確認できます。
信頼ゾーンはAWSアカウント内か、Organizationsです。
また、IAM Access Advisorで特定のIAMユーザーのアクセス可能なリソースや最終ログイン日時などの過去のアクセス履歴を参照することができます。
終わりに
ほぼほぼIAMロールとIAMポリシーが占めたなぁ。記事書くことで学んだことを振り返れるので非常に有意義に感じました。これを機に投稿続けていけるといいな。