0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@power_chan

AWSの権限周りがすべてわかる

0
Posted at

AWSの権限管理の全体像

AWSの認可は大きく以下のような流れで評価されます。

ユーザー/Role
↓
IAM Policy確認（自分が何をできるか）
↓
Resource Base Policy確認（このリソースを誰が利用できるか）
↓
Permission Boundary確認
↓
SCP確認
↓
サービス固有Policy確認(KMS等)
↓
許可

1. Identity-based Policy (IAM Policy)

最も一般的なポリシーです。

自分が何をできるか

を定義します。

付与先

IAM User
IAM Group
IAM Role

例

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "*"
}

意味

このRoleはS3を読み取れる

利用例（下記のリソースのRole内に上記のPolicyがあれば、下記のリソースはS3を読み取る権限を持つ）

Lambda Execution Role
ECS Task Role
EC2 Instance Profile
Step Functions Role

2. Resource-based Policy（Resource Policy）

リソース自身に付与するポリシーです。

誰がこのリソースを使えるか

を定義します。

例

{
  "Effect": "Allow",
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction"
}

意味

API GatewayがこのLambdaを実行できる

例1：API Gateway → Lambda

Lambda側

{
  "Effect": "Allow",
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction"
}

↓

API GatewayからのInvokeを許可

例2：S3 Bucket

Bucket Policy

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:root"
  },
  "Action": "s3:GetObject"
}

↓

指定アカウントからの読み取りを許可

例3：SQS

Queue Policy

{
  "Effect": "Allow",
  "Principal": {
    "Service": "sns.amazonaws.com"
  },
  "Action": "sqs:SendMessage"
}

↓

SNSからSQSへのメッセージ送信を許可

Resource Policy が使える代表サービス

  • Lambda
  • S3
  • SNS
  • SQS
  • KMS
  • Secrets Manager
  • ECR
  • EventBridge
  • API Gateway
  • OpenSearch
  • CloudWatch Logs

など

Policyの優位性

API Gateway側(IAM Policy)

{
  "Effect": "Allow",
  "Action": [
    "lambda:InvokeFunction"
  ],
  "Resource": "*"
}

意味：API GatewayはLambdaを呼んでよい

Lambda側(Resource Policy)

{
  "Effect": "Deny",
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction"
}

意味：API Gatewayからの呼び出しは禁止

なら最終的な結論は「呼べない」

IAMPolicyとResourcePolicyの違い

また、通常APIgatewayの権限にはaws lambda add-permissionを使う
API GatewayはあなたのIAM RoleとしてLambdaを呼んでいるわけではない

  • 例えばEC2がLambdaを呼ぶ場合
EC2
↓
Role
↓
lambda:InvokeFunction
↓
Lambda

API Gatewayの場合

ユーザー
↓
API Gatewayサービス
↓
Lambda

ここで登場するのはapigateway.amazonaws.comというAWS管理サービスです。

API Gatewayは、IAM RoleをAssume→Lambda実行しているわけではありません。

{
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Condition": {
    "ArnLike": {
      "AWS:SourceArn": "arn:aws:execute-api:..."
    }
  }
}

というResource Policyで管理しています

IAM Policy

Roleを持つ主体
↓
何ができるか

例

EC2
Lambda Execution Role
ECS Task
Step Functions Role
Resource Policy

Resource Policy

AWSサービス
↓
リソースを利用する

例

API Gateway → Lambda
S3 → Lambda
EventBridge → Lambda
SNS → SQS

誰からの実行を受け入れるかを制御できるようにするため、API Gateway側のIAM Policyではなく、Lambda側のResource Policyで許可する仕組みになっています。

3. Trust Policy

Role専用の特殊なResource Policyです。

誰がこのRoleを引き受けられるか

IAM Policy
↓
Roleを使った後に何ができるか

Trust Policy
↓
そもそも誰がRoleを使えるか

つまり、Roleの構造は、実際はこうです。

Role
├─ Trust Policy
└─ IAM Policy

例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

意味

Lambdaサービスだけが
このRoleを利用可能

Lambdaの場合

Role

rag-lambda-role

Trust Policy

{
  "Principal": {
    "Service": "lambda.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

意味

Lambdaサービスだけ
Role利用可能

IAM Policy

{
  "Action": [
    "bedrock:InvokeModel"
  ]
}

意味

Role取得後
Bedrock利用可能

実際の流れ

Lambda起動
↓
STS
↓
AssumeRole
↓
一時クレデンシャル取得
↓
Bedrock利用

sts:AssumeRoleとは

Trust Policyで必ず出てくる

{
  "Action": "sts:AssumeRole"
}

は

Roleを借りる

という意味です。

AWS内部では

Role
↓
STS
↓
AccessKey
SecretKey
SessionToken

が発行されます。

Lambdaは実際には

一時クレデンシャル

で動いています。

4. Inline Policy

Role/Userに直接埋め込まれるポリシーです。

作成例

aws iam put-role-policy

特徴

そのRole専用

Role削除
↓
Inline Policyも削除

例

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "*"
}

6. Managed Policy

再利用可能なPolicyです。

AWS管理ポリシー

AdministratorAccess
PowerUserAccess
AmazonS3ReadOnlyAccess
AWSLambdaBasicExecutionRole

自作ポリシー

MyCompanyRAGPolicy

付与

aws iam attach-role-policy

Inline Policy と Managed Policy の違い

Inline Policy

RoleA
↓
専用Policy

1対1

Managed Policy

RoleA
RoleB
RoleC
 ↓
共通Policy

1対多

7. Permission Boundary

権限の上限を定義します。

IAM Policy
↓
与えたい権限

Permission Boundary
↓
与えてよい最大権限

通常

Role
↓
AdministratorAccess

なら全権限

Boundary

{
  "Effect": "Allow",
  "Action": [
    "s3:*"
  ],
  "Resource": "*"
}

を設定

結果

AdministratorAccess
+
Boundary
=
S3のみ

イメージ

IAM Policy　と　Permission Boundary　の共通集合
=
実際の権限

IAM Policy
↓
与えたい権限

Permission Boundary
↓
超えてはいけない上限

実際の権限
↓
両方で許可されたものだけ

IAM Policyで十分なら Permission Boundary は不要では？

その疑問はもっともです。

実際、

IAM Policyをちゃんと最小権限で書くなら
Permission Boundaryは不要では？

という考え方は正しいです。

小規模環境や個人開発では、その通りです。

しかし Permission Boundary は

自分が作るRole

ではなく、

他人が作るRole

を制御するために存在します。

個人開発なら不要

例えばあなたが作る Lambda Role

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "bedrock:InvokeModel",
    "aoss:APIAccessAll"
  ],
  "Resource": "*"
}

なら十分です。

Boundaryを付けても意味はほぼありません。

Boundaryが必要になるケース

例えば会社で

AWS管理者
↓
開発チーム

という構造があるとします。

管理者は

開発者にRole作成権限を与えたい

と思っています。

例えば

{
  "Effect": "Allow",
  "Action": [
    "iam:CreateRole",
    "iam:AttachRolePolicy"
  ]
}

を付与します。

すると開発者は

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

というRoleを作れてしまいます。

結果

開発者
↓
AdministratorAccess Role作成
↓
AWS全権限取得

になります。

Boundaryで防ぐ

管理者は

{
  "Effect": "Allow",
  "Action": [
    "lambda:*",
    "s3:*"
  ],
  "Resource": "*"
}

というBoundaryを作ります。

そして

開発者が作るRoleには
必ずBoundaryを付ける

ようにします。

開発者が

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

を付けても、

実際には

Lambda
S3

までしか使えません。

SCPとの違い

Boundaryとよく混同されます。

Boundary

対象

Role単位

例

RoleA
↓
S3のみ

RoleB
↓
Lambdaのみ

など個別設定できる

SCP

対象

AWSアカウント全体

例

{
  "Effect": "Deny",
  "Action": "ec2:*",
  "Resource": "*"
}

結果

誰であっても
EC2禁止

になります。

AWS管理者がBoundaryを好む理由

例えば

100人の開発者

がいるとします。

管理者は

各Roleの中身

を毎回レビューしたくありません。

そこで

どんなRoleを作っても

Lambda
S3

まで

というBoundaryを付けます。

すると

Roleの中身をミスっても
権限昇格しない

ことが保証されます。

実務での位置付け

覚え方としては、

IAM Policy
=
このRoleに与えたい権限

Permission Boundary
=
このRoleに与えてよい最大権限

です。

そして Boundary が真価を発揮するのは、

他人にRole作成権限を与えるとき

です。

つまり、

自分が作るRole
↓
Boundaryほぼ不要

他人が作るRole
↓
Boundary重要

と考えると分かりやすいです。

8. Service Control Policy (SCP)

AWS Organizationsで利用します。

組織全体の上限

例

{
  "Effect": "Deny",
  "Action": "ec2:*",
  "Resource": "*"
}

結果

AdministratorAccess
↓
SCP
↓
EC2禁止

イメージ

Organization
↓
Account
↓
Role

SCPはAccount全体に効きます。

AWS権限管理の簡潔なまとめ

AWSの権限管理をチーム開発で考えると、役割は次のように分かれます。

SCP
↓
アカウント全体の上限

Permission Boundary
↓
Role/User単位の上限

IAM Policy
↓
実際に付与する権限

実際の権限は、

IAM Policy
∩
Permission Boundary
∩
SCP

で決まります（さらに明示的Denyがあれば優先）。

SCP の役割

AWS Organizationsで利用します。

会社全体のルール

を強制できます。

例

本番環境でRDS削除禁止
CloudTrail停止禁止
IAM User作成禁止

管理者権限を持つユーザーでも回避できません。

Permission Boundary の役割

開発者に

Role作成権限

を与える際の安全装置です。

例

開発者は自由にRoleを作れる
↓
ただしLambda・S3まで

を保証できます。

IAM Policy の役割

実際に利用したい権限を定義します。

例

S3を読む
Bedrockを呼ぶ
OpenSearchへ書く

比較表

項目 SCP Permission Boundary IAM Policy
対象 AWS Account / OU User / Role User / Role
役割 組織全体の上限 Role単位の上限 実際の権限
適用範囲 アカウント全体 個別Role 個別Role
管理者でも回避可能？ 不可 不可 変更可能
主な用途 本番環境保護 権限昇格防止 サービス利用
チーム開発で重要度 ★★★★★ ★★★★☆ ★★★★★
個人開発で必要性 低い 低い 必須

イメージ図

Organization
│
├─ SCP
│   ↓
│   EC2禁止
│
└─ Account
     │
     ├─ Permission Boundary
     │    ↓
     │    S3・Lambdaまで
     │
     └─ IAM Policy
          ↓
          S3・Lambda・Bedrock

覚え方

ポリシー 一言でいうと
SCP 会社の法律
Permission Boundary 部署のルール
IAM Policy 個人に与える権限
Trust Policy 誰がRoleを使えるか
Resource Policy 誰がリソースを使えるか

チーム開発での階層構造

SCP
↓
会社の法律

Permission Boundary
↓
開発者の権限上限

IAM Policy
↓
実際の業務権限

9. Session Policy

AssumeRoleで取得した一時クレデンシャルに対してさらに権限を絞るためのポリシー
重要なのは、権限を増やすことはできない。権限を減らすだけ

例

aws sts assume-role

時に指定

通常

S3 Full Access

Session Policy

S3 ReadOnly

結果

そのセッション中だけ
ReadOnly

具体的な使い方

aws sts assume-role とは

別のRoleになりすます

ためのコマンドです。

AWS STS (Security Token Service) を利用して、

現在のユーザー
↓
別のRole

へ一時的に切り替えます。

何が起きるのか

例えば現在のユーザー

User: noda

が

Role: ProductionAdminRole

を利用したいとします。

実行

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/ProductionAdminRole \
  --role-session-name test

結果

{
  "Credentials": {
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "SessionToken": "..."
  }
}

が返ります。

これを環境変数へ設定すると

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

以降のAWS CLIは

ProductionAdminRole

として動作します。

実務で最も多い用途

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

最もよく使われる用途です。

会社の構成

開発アカウント
111111111111

本番アカウント
222222222222

普段

Developer
↓
開発アカウント

で作業

本番作業時

aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/ProdRole \
  --role-session-name prod

結果

Developer
↓
ProdRole
↓
本番環境操作

になります。

なぜこうするのか

本番アカウントへ直接IAM Userを作ると

権限管理が複雑

になります。

そこで

開発アカウント
↓
AssumeRole
↓
本番アカウント

という構成にします。

メリット

本番用IAM User不要
監査しやすい
一時的な権限

管理者権限を必要なときだけ取得

普段

ReadOnly

の権限しか持たない運用

しかし

Lambda更新
IAM変更

などが必要な場合がある

その時だけ

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AdminRole \
  --role-session-name admin

結果

ReadOnly User
↓
AdminRole
↓
管理者権限

になります。

作業終了後

セッション期限切れ
↓
元のReadOnly権限

へ戻ります。

なぜこうするのか

常時管理者権限を持つと

誤操作
権限濫用

のリスクがあります。

そこで

普段
↓
ReadOnly

必要時
↓
AssumeRole
↓
Admin

という運用を行います。

メリット

最小権限の原則
セキュリティ向上
監査容易

10. Bucket Policy

S3専用のResource Policy

例

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

意味

全世界からダウンロード可能

付与

aws s3api put-bucket-policy

11. Key Policy

Key Policy は KMSの暗号鍵専用の Resource Policy です。

普通のAWSサービス

多くのAWSサービスは、

IAM Policy

だけで利用できます。

例

IAM Policy
↓
S3利用可能

KMSは特殊

KMSでは、

IAM Policy
+
Key Policy

の両方が必要です。

なぜ必要なのか

KMSは暗号鍵を管理するサービスだからです。

そのため、

IAMが許可
↓
さらに鍵自身も許可

という二段階チェックになっています。

イメージ

IAM Policy
↓
私は鍵を使いたい

Key Policy
↓
鍵の所有者が許可する

Resource Policyとの関係

Key Policyは、

KMS専用のResource Policy

です。

覚え方

普通のAWSサービス
↓
IAM Policyだけ

KMS
↓
IAM Policy
+
Key Policy

一言でいうと

IAM Policy
↓
利用者の許可

Key Policy
↓
鍵側の許可

両方OKなら利用可能

12. Endpoint Policy

VPC Endpointを通った通信だけを許可するためのポリシーです。

通常はインターネット経由でもAWSサービスへアクセスできますが、Endpoint Policyを使うと、

「このVPC Endpoint経由の通信だけ許可する」

という制御ができます。

具体例

例えばS3に対して、

〇 VPC Endpoint経由
× インターネット経由

と制限できます。

その結果、

EC2 → VPC Endpoint → S3

は許可されますが、

自宅PC → S3

は拒否できます。

どこに設定する？

以下のVPC Endpointに設定します。

・Gateway Endpoint
  - S3
  - DynamoDB

・Interface Endpoint
  - Bedrock
  - Secrets Manager
  - Systems Manager
  - Textract
  - KMS
  など

一言でいうと

**「そのVPC Endpointを通った通信だけを許可するためのアクセス制御ポリシー」**です。

13. OpenSearch Access Policy

RAG環境では通常、以下の設定が必要になります。

IAM Role

Lambda
↓
IAM Role

Lambda や EC2 が AWS リソースへアクセスする際の実行主体です。

IAM Policy

aoss:APIAccessAll
bedrock:InvokeModel

IAM Role に付与し、OpenSearch Serverless や Bedrock を利用できるようにします。

Data Access Policy

Lambda Role
↓
Collectionアクセス許可

OpenSearch Serverless の Collection や Index に対する読み書き権限を定義します。

Network Policy

Public
または
VPC Endpoint限定

OpenSearch Serverless への接続元を制御します。

Encryption Policy

AWS管理KMS
または
Customer Managed KMS

Collection の保存データを暗号化するための設定です。

まとめ

種類 役割
IAM Policy OpenSearch Serverless自体を管理する権限
Data Access Policy Collection / Index の読み書き権限
Network Policy 接続元の制御
Encryption Policy 保存時暗号化
IAM Role LambdaやEC2の実行主体
KMS Key Policy 独自KMS利用時の権限
Endpoint Policy VPC Endpoint利用時のアクセス制御
Domain Access Policy 従来版OpenSearch Serviceのみ

よくあるハマりポイント

IAM Policyは付いている
↓
でもData Access Policyが無い
↓
403 Forbidden

というケースです。

IAM Policy と Data Access Policy は別物であり、OpenSearch Serverless では 両方が必要 になります。

AWS権限まわりでよく使うCLIコマンド

1. create-role

IAM Roleを作成します。

aws iam create-role \
  --role-name my-lambda-role \
  --assume-role-policy-document file://trust-policy.json

Roleは「誰がこの権限を使えるか」を決めます。

例：Lambda用Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

意味：

Lambda がこの Role を引き受けられる

2. attach-role-policy

AWS管理ポリシーをRoleに付与します。

aws iam attach-role-policy \
  --role-name my-lambda-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

意味：

LambdaがCloudWatch Logsにログを書ける

AWSが用意しているPolicyを使う場合に使います。

3. put-role-policy

Roleにインラインポリシーを直接付けます。

aws iam put-role-policy \
  --role-name my-lambda-role \
  --policy-name bedrock-inline-policy \
  --policy-document file://bedrock-policy.json

例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel"
      ],
      "Resource": "*"
    }
  ]
}

意味：

このRoleにBedrock実行権限を直接付ける

4. create-policy

自作のIAM Policyを作成します。

aws iam create-policy \
  --policy-name my-bedrock-policy \
  --policy-document file://bedrock-policy.json

作成後、ARNが返ります。

arn:aws:iam::123456789012:policy/my-bedrock-policy

そのPolicyをRoleに付けるには：

aws iam attach-role-policy \
  --role-name my-lambda-role \
  --policy-arn arn:aws:iam::123456789012:policy/my-bedrock-policy

5. create-instance-profile

EC2にRoleを付けるための箱を作成します。

aws iam create-instance-profile \
  --instance-profile-name my-ec2-profile

EC2にはRoleを直接付けるのではなく、

EC2
↓
Instance Profile
↓
IAM Role

という形で付けます。

6. add-role-to-instance-profile

Instance ProfileにRoleを入れます。

aws iam add-role-to-instance-profile \
  --instance-profile-name my-ec2-profile \
  --role-name my-ec2-role

この後、EC2作成時に指定します。

aws ec2 run-instances \
  --image-id ami-xxxx \
  --instance-type t3.micro \
  --iam-instance-profile Name=my-ec2-profile

7. detach-role-policy

Roleから管理ポリシーを外します。

aws iam detach-role-policy \
  --role-name my-lambda-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Roleを削除する前によく使います。

8. delete-role

Roleを削除します。

aws iam delete-role \
  --role-name my-lambda-role

ただし、Policyが残っていると削除できません。

よくあるエラー：

DeleteConflict: Cannot delete entity, must delete policies first

その場合は先にPolicyを外します。

よく使う削除順

1. detach-role-policy
2. delete-role-policy
3. remove-role-from-instance-profile
4. delete-instance-profile
5. delete-role

まとめ

コマンド 役割
create-role IAM Roleを作成
attach-role-policy AWS管理Policy / 自作PolicyをRoleに付与
put-role-policy RoleにインラインPolicyを直接付与
create-policy 自作Policyを作成
create-instance-profile EC2用のRole入れ物を作成
add-role-to-instance-profile Instance ProfileにRoleを追加
detach-role-policy RoleからPolicyを外す
delete-role Roleを削除
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?