最小権限の原則に関連する、名称が似た機能です。
IAM 権限について、使用状況を確認できます。
Viewing last accessed information for IAM
アカウントまたは組織の外部に共有されているリソースを調査できます。CloudTrail ログから policy を生成したり、IAM Policy の文法エラーをチェックする機能も提供します。
Effect: Deny
に指定した Action を、後から Allow し直すことはできません。
このような場合は、Effect: Allow
と NotAction
を組み合わせます。まず、NotAction に指定されていない Action すべてに Allow が適用されます。次に、Effect: Allow
と Action
を指定することで、NotAction に含まれる Action の一部に Allow を適用できます。
注意: iam:*
以外の Action も Allow されています。
aws:TagKeys
で tag の存在確認。aws:RequestTag
で tag の値を確認。IAM role または IAM user に設定します。IAM group には設定できません。
IAM role または IAM user が持つことができる権限に制限を設けるための仕組みです。
Permissions boundaries for IAM entities
AdministratorAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Permissions boundary として、mytest20220710 IAM policy を設定してみます。S3 の API 以外を Allow しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"s3:*"
],
"Resource": "*"
}
]
}
S3 API は Access Denied で失敗します。
vagrant@debian11:~$ aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
vagrant@debian11:~$ aws s3 ls s3://mytest20220710
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
ただし Resource Based policy を設定すると、一部の API は成功するようになります。
S3 バケットポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123412341234:user/test20220710"
},
"Action": "*",
"Resource": [
"arn:aws:s3:::mytest20220710",
"arn:aws:s3:::mytest20220710/*"
]
}
]
}
実行例
vagrant@debian11:~$ aws s3 ls s3://mytest20220710 && echo ok
ok
上記ベン図は、以下の評価ルールが適用された結果です。
注意: 別の AWS アカウントからのアクセスが Allow されるためには、別の AWS アカウント側でも Allow 判定となる必要があります。Cross-account policy evaluation logic
https://sts.amazonaws.com
得られた情報は以下のように利用できます。
export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of session token>
IAM user の session を作成します。主な用途は、AWS API 実行時に MFA が必須となる場合です。session 発行時に MFA の情報を与えることで、MFA 認証が完了した session を作成できます。
aws sts get-session-token \
--serial-number "YourMFADeviceSerialNumber" \
--token-code 123456
MFA が完了していないと sts:GetSessionToken
以外すべて Deny される policy を IAM user に設定する例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"NotAction": [
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false",
"aws:ViaAWSService": "false"
}
}
}
]
}
IAM role の session を作成します。session 発行時に MFA の情報を与えることで、MFA 認証が完了した session を作成できます。
MFA が完了していないと Assume できない Trust relationships を持つ role を作成する例です。
また、AssumeRole の合言葉のように機能する sts:ExternalId
を設定する例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123412341234:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "testtest"
},
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
注意: 上記 root は authenticated and authorized principals in the account を意味します。
AssumeRole で STS トークンを発行する例
aws sts assume-role \
--role-arn arn:aws:iam::123412341234:role/myrole20220712 \
--role-session-name mysession \
--external-id testtest \
--serial-number arn:aws:iam::123412341234:mfa/myuser \
--token-code 123456
STS トークンを利用する例
AWS_ACCESS_KEY_ID="ASIA3JUBRISFQ67ZBL5Y" \
AWS_SECRET_ACCESS_KEY="lV6JbMYBGqb3PFnbWmrh+GV1P5QkK4k9fWtBifC1" \
AWS_SESSION_TOKEN="xxxxxx" \
aws sts get-caller-identity
{
"UserId": "AROA3JUBRISFXZSIQ7UZB:mysession",
"Account": "123412341234",
"Arn": "arn:aws:sts::123412341234:assumed-role/myrole20220712/mysession"
}
AWS Organizations terminology and concepts
organizations:LeaveOrganization
Action を Deny する SCP を設定できます。Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment
OrganizationAccountAccessRole
は AWS Organizations で member account を新規作成した際に自動で作成されるロールです。
SCP を含め、Organization 内の policy は CLI または以下のコンソール画面から設定します。
2022/7/26 頃から、AWS SSO の正式名称が AWS IAM Identity Center に変更されました。基本的な機能に変更はありません。
AWS Single Sign-On (AWS SSO) is now AWS IAM Identity Center
例: Google Cloud Identity は SAML に対応した IdP の一つです。STS の AssumeRoleWithSAML
API を利用した認証が可能です。
How to set up IAM federation using Google Workspace
例: Google Cloud Identity は SAML に対応した IdP の一つです。SSO User ポータルを登場させることで、AssumeRoleWithSAML API の処理を AWS 内に隠蔽することができます。可能な限り、AssumeRoleWithSAML ではなく、後継の AWS SSO を利用します。
How to use G Suite as an external identity provider for AWS SSO
AWS SSO は Organization と併用する必要があり、management account で有効化します。
リージョンは一つだけ選択できます。
OpenID Connect (OIDC) は Security Assertion Markup Language (SAML) と似た仕組みですが、OAuth2.0 を拡張しており、ユーザ自身が自分でユーザ登録が可能な、Web ベースの IdP で利用されているプロトコルです。AssumeRoleWithSAML は組織内の従業員が利用するのに対して、AssumeRoleWithWebIdentity は不特定多数の利用者がインターネット経由で利用することを想定します。
accounts.google.com:sub
といった変数を IAM policy で利用できます。IAM and AWS STS condition context keys
例: AWS IAM Role を GCP から STS 認証で利用する設定例
OIDC と SAML の両方に対応しており、可能な限り、AssumeRoleWithWebIdentity ではなく、後継の Cognito を利用するようにします。Amazon Cognito は、不特定多数のユーザに対する Web 認証機能を実装するためのマネージドサービスです。Google Cloud における Identity Platform に対応します。
cognito-identity.amazonaws.com:sub
といった変数を IAM policy で利用できます。IAM and AWS STS condition context keys
SAML に対応していない、オンプレミス上の ID 基盤を利用する際に利用します。STS GetFederationToken API を直接実行する custom identity broker を用意します。