【AWS】「IAM」、「ポリシー」、「ロール」

IAMとは？

AWS IAM自体は無料です。

AWSのサービスを利用するユーザー権限を管理

ユーザーやグループへの制御ポリシー適用

ロールを用いた権限の管理

社内や外部のディレクトリとの統合（IDフェデレーション）

AWSリソースをセキュアに操作するために認証・認可

サービスへのアクセス制御

コンピューティング、ストレージ、データベース

リソースへのアクセス制御

インスタンス、ファイル

登場の背景

基本的にIAMがやってること自体は従来からの物と変わらないです。しかし、AWSを使っていく上では非常に便利なサービスになります。

ポリシー設定手間の削減

オンプレの場合のアクセス制御は初期構築で設定してしまえばそれでよかったがクラウド時代だとサーバーが増減したりするのでいちいち一手を介してやっていると手間がかかりすぎる。

サービスからサービスへアクセスする。

人だけでなくサービスからサービスを呼んだりしている。（CloudWatchなど）

IAMの要素

Identities(誰）

ユーザーやグループのこと。

API Actions（どんなことを）

どんなことを行いどんな結果になるのか。

Resources（どれに）

API Actionsの対象となるリソース

Conditions

条件を設定できる。（特定のアクセス元IPからのみなど）

ポリシー

アクセス許可（権限）の定義です。「対象のAWSサービス」、「どのリソースの」、「どんな操作を」、「許可するか」を定義します。JSONで記述します。

後述する「ユーザー単位」、「グループ単位」、「ロール単位」どの単位にも割り当てることが可能です。

ポリシーの種類

AWS管理ポリシー

AWSがあらかじめ用意したポリシーのこと。

カスタマー管理ポリシー

「AWS管理ポリシー」よりもより細かく設定することができます。GUIからも作成することができます。

ベースでのポリシーの種類

Identity-Based Policies

アイデンティティベースの種類、IAMユーザーに適用するなどリソース主体を指定します。

Resouce-Based Policies

リソースベースのポリシー、操作される側（S3やSNS等）に指定します。

ポリシーの詳細

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": ""
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
    "Action": [
      "s3:PutObject",
      "s3:PutObjectAcl"
    ],
    "Condition": {
      "StringEquals": {
        "aws:SourceIp": "12,34,56,12"
      }
    }
    "Resource": "arn:aws:s3:::example-bucket/*"
  }
}

{

"Version": "2012-10-17",

"Statement": {

"Sid": ""

"Effect": "Allow",

"Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},

"Action": [

"s3:PutObject",

"s3:PutObjectAcl"

"Condition": {

"StringEquals": {

"aws:SourceIp": "12,34,56,12"

}

"Resource": "arn:aws:s3:::example-bucket/*"

}

Version

バージョン情報を記載します。

Sid

IDです。

Effect

Allow

許可するポリシーの場合に付けます。

Deny（デナイ）

拒否するポリシーの場合に付けます。

Principal

アイディンティティベースのポリシーでは利用させたいアカウントが明確なので指定しません。

全てのアカウントに適用

“Principal”:”AWS”:”*.*”

1	“Principal”:”AWS”:”.”

特定のIAMアカウントを指定する。

"Principal": {"AWS": "arn:aws:iam::777788889999:user/username”}

1	"Principal": {"AWS": "arn:aws:iam::777788889999:user/username”}

Federatedユーザーを指定する。

"Principal": {“Federated”: “www.amazon.com”}

1	"Principal": {“Federated”: “www.amazon.com”}

ロールを指定する。

"Principal": {"AWS": "arn:aws:iam::777788889999:role/rolename”}

1	"Principal": {"AWS": "arn:aws:iam::777788889999:role/rolename”}

サービスを指定する。

"Principal": {“Service”: “ec2.amazonaws.com”}

1	"Principal": {“Service”: “ec2.amazonaws.com”}

StaAction

何のサービスのどのような操作かを指定する。

EC2のインスタンスをスタートする指示

"Action":"ec2:StartInstances"

1	"Action":"ec2:StartInstances"

カンマ区切りで複数操作を指定できます。

“Action: [“sqs:SendMessage”,”sqs:ReceiveMessage”]”

1	“Action: [“sqs:SendMessage”,”sqs:ReceiveMessage”]”

ワイルドカードでも操作を指定できます。

“Action: “iam:*AccessKey*”

1	“Action: “iam:AccessKey”

Resources

どのリソースに対してのポリシーを指定する。

"Resource": "arn:aws:s3:::example-bucket/*"

1	"Resource": "arn:aws:s3:::example-bucket/*"

Condition

ポリシーの詳細を指定します。

指定できる項目

IPアドレスの接続元を指定する。
〜時〜時まではこのポリシーを指定する。

ユーザー

個々のアカウントユーザー、アクセス権限を付与することができます。

グループ

IAMユーザーの集合で、同一の役割を持つある程度まとまったユーザーに権限を付与する作業を簡素化できます。ユーザーと同様にアクセス権限を付与することが可能です。また、IAMユーザーは複数のグループに所属させることも可能です。

グループ化のメリット

IAMユーザーに直接権限を付与する場合に比べて権限の付与忘れや過剰付与を防げます。まとめてポリシーを付与できるので手間もかからないです。

グループの命名規則

下記のような命名規則で名前を付けます。グループなので最後にsを付けるかもしくは最後に「group」をつける形が多いです。

「Admins」 or 「admin-group」（管理者ユーザー）
「Operators」 or 「operator-group」（一般操作ユーザー）

ロール

IAMユーザーはAWSを利用する上で必須の機能ですが、ロールに関しては必須ではないです。ただし、正しく使うことによって安全性も利便性も上がります。（使わずに過ごす人も多いです。）一時的（一時的なアクセスキーみたいなのが割り当てられるだけなのでセキュリティが高い）にアクセスを許可したアカウントに発行できます。AWSの権限を与える仕組みです。EC2に対してIAMロールを与えることでアクセスキーやシークレットキーを割り当てることなくAWSの権限が設定された状態で利用することが可能です。ポリシーを複数アタッチして権限をひとまとめします。

用途

一時的な認証情報として使用する。

ポリシーを複数アタッチして権限をひとまとめにする。

IAM Policy(AmazonS3ReadOnlyAccess、S3Policy、AmazonEC2FullAccess)を複数まとめることが可能です。

クロスアカウントアクセス

あるアカウントのユーザーを別のアカウントのユーザーに紐付ける機能です。一般的に別アカウントにアクセスするために現場でもよく使われている機能です。

例

開発アカウントのユーザーが本番アカウントにロールを一時的に委任してもらうことによって一時的に開発アカウントユーザーが本番アカウントにアクセスすることができるようになります。

Switch Role

別アカウントでログインし直す必要もなく、別アカウントのリソース操作ができる。クリック一つで環境を切り替えることができるようになります。

必要な設定

スイッチ先にロールを作る。その際にorganizationという項目があり、スイッチ元のアカウントのIDを割り当てる。
スイッチ元のアカウントにポリシーを作る。AssumeRoleでスイッチ先にアクセスできるようなポリシーを記述する。

パーミッション・バウンダリー

2018年7月に登場した。IAMユーザーまたはIAMロールに対するアクセス制限として動作する。付与した権限とBoundaryで許可した権限が重なり合う部分のみが有効な権限になります。

パーミッション・バウンダリーで設定していない権限についてはIAMユーザーやロールでどのように権限を付与しても一切使用することができなくなります。

用途

組織外の他者に権限を付与したい場合（元々設定したIAMユーザーを渡すが必要な用途しか利用できなくなります。）

IAMの設計方針

個々のIAMユーザーを作成する。

ルートユーザーはなんでもできてしまいますし誰が操作したかわからなくなるので普段からルートユーザーを使用してAWSにはアクセスしないようにしましょう。また、共用のIAMユーザーなどは作成しないようにしましょう。また、ユーザーだけでなくプログラムやシステムごとにもIAMユーザーを分けるようにしましょう。

ユーザーをグループに所属させ、グループに権限を割り当てる。

一括で権限を変更することが可能です。ユーザーの役割に応じて任意のグループに所属させるというのが良い。AWSからもそれが推奨されています。

権限は最小にする。

必要になった際に最小の権限で発行する方針が良いです。

EC2インスタンスから実行するアプリにはロールを使用する。

一時的にキーを発行するだけなので安全です。

定期的に不要な認証情報を削除する。

アクセスキーやシークレットキーをアクセスするために発行し、アクセスが完了したら破棄をするためキー漏洩リスクがなく安全です。例えば、退職者のIAMユーザーは削除するようにするなど。