Open1

EC2インスタンスプロファイルについて

AWS
y_romuy_romu

今回は、EC2のインスタンスプロファイルとIAMロールについて個人的にメモをまとめます。

EC2を作成する時によく登場するコチラ

・インスタンスプロファイルとは？

EC2インスタンスにIAMロールをアタッチするための入れ物。

IAMロール単体ではEC2に直接アタッチできないため、インスタンスプロファイルという入れ物にロールを格納して、それをEC2にアタッチする。

インスタンスプロファイルには1つのロールしか格納できないため、ロールに複数のポリシーをアタッチしてアクセス権限を管理していく。
※ただし、IAMロールにアタッチできるポリシーの上限は10個まで

IAMロールには2種類のポリシーが存在する。

  1. 信頼ポリシー
    誰がこのロールを引き受ける（sts:AssumeRoleする）ことを許可されているかを定義
  2. 権限ポリシー
    このロールを引き受けた「人やサービス」が、何の操作をできるかを定義（S3の読み書きなど）

sts:AssumeRoleについて

sts:AssumeRoleとは、一時的に別のIAMロールの権限を引き受けるためのアクションで、内部的にはSTSのエンドポイントに対してAPIリクエストを投げている。

AWS Security Token Service（以下STS）に対して、一時的な認証情報を要求するアクションとなる。

内部の流れ：

  1. 認証主体がSTSに対してAssumeRoleを呼び出す。
  2. STSがロールの信頼ポリシーを確認して、呼び出し元がPrincipalとして許可されているか確認する。
  3. 条件が一致すれば、一時的な認証情報を発行する。

この認証情報とは、有効期限付きのアクセスキーIDとシークレットアクセスキー。（あとセッショントークンも）

AssumeRoleでも、内部的にはアクセスキーを使っている。
アクセスキーは避けるべきだけど、AssumeRoleでは同じ構造となっている。

例えばAWSのベストプラクティスでは、アクセスキーによる長期的な認証情報は避けるべきとされている。

これは万が一アクセスキーが流出すると、不正に入手したアクセスキーを使う事で、そのIAMユーザーに割り当てられている権限での操作が全てできてしまう。

しかしユーザーが発行する長期的なアクセスキーとIAMロールが扱うアクセスキーとでは、セキュリティモデルが大きく異なる。

  1. 信頼された認証主体に限定される
    　ロールの信頼ポリシーに記載されたプリンシパル（認証主体）にしかsts:AssumeRoleは許可されない。これにより、第三者や不正ユーザーがロールを引き受けることは原則不可能

  2. 一時的な認証情報である
    　AssumeRoleによって発行されるクレデンシャルは最大12時間の有効期限がついているため、万が一漏洩しても時間経過でリスクが自然消滅する。

  3. 権限の範囲が限定されている
    　操作できるのは、ロールにアタッチされたIAMポリシーの範囲内のみ。例え不正に一時的な認証情報が入手されたとしても、そのロールに許可されていない操作は実行できない。

信頼ポリシーについて

Principal句では、このロールを引き受ける主体を記述する。

1.AWSサービスがロールを引き受ける場合
"Principal": {
  "Service": "ec2.amazonaws.com"
}

まず、プリンシパル句にはEC2やLambdaなどAWSのサービスを設定できる。
この場合は、このロールをEC2が引き受けた場合のみ、このロールにアタッチされている権限ポリシーの操作ができる。

AWSアカウントがロールを引き受ける場合
"Principal": {
  "AWS": "arn:aws:iam::123456789012:root"
}

これはクロスアカウントアクセス、つまり他のAWSアカウントがロールを引き受ける際の書き方となる。

しかし認証主体をrootアカウントとしてしまうと、このアカウント配下の全てのIAMユーザー/IAMロールがこのロールを引き受ける事が可能となり、非常に広い範囲にアクセス権を許可してしまうことになる。

そのアカウント内のどのIAMユーザーでもロールを引き受ける事ができ、最小権限の原則に反することとなる。

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/HogeUser"
}

そのためクロスアカウントアクセスの際にはこちらのように、他アカウント配下の特定のIAMユーザーに限定する方が望ましい。

IAMロールが引き受ける場合
"Principal": {
  "AWS": "arn:aws:iam::123456789012:role/SecurityAdministratorRole"
}

認証主体にロールを指定することもできるらしい。

特定のロールを持つユーザーだけ、このロールを引き受ける事ができるという場面。

例えば「セキュリティ担当者」のロールを持つIAMユーザーだけが、このロールを引き受ける事ができますよ、といったような。