トップ > AWS IAM > 【更新】AWSにおけるアクセスポリシーの評価ロジック

【更新】AWSにおけるアクセスポリシーの評価ロジック

AWS IAM IAM Policy SCP AWS Organizations
記事タイトルとURLをコピーする

CI2部の山﨑です。

IAMドキュメントの更新履歴を見る機会があり、そこでアクセスポリシーの評価ロジックが更新されていましたので、その点について簡単にご紹介させて頂きます。

はじめに

2021年9月にAWSにおけるアクセスポリシーの評価ロジックについて以下のブログを掲載させて頂きました。

blog.serverworks.co.jp

このブログでご紹介させて頂いた評価ロジックが2021年11月に変更されていましたので以降、この点について簡単に変更点をご紹介します。

Document history for IAM

変更点

変更点は以下の通りです、

  • IAM Permissions boundaries とセッションポリシーの評価順序がアイデンティティベースのポリシーよりも後ろになった

基本的にOrganizations SCP、リソースベースのポリシー、アイデンティティベースのポリシー の3つがメインだと思うので、個人的には評価順序がポリシー利用の実態に近づいたような印象を受けました。IAM Permissions boundaries と セッションポリシーをフル活用しているあるいはフル活用する予定がある方はこの評価ロジックの変更には目を通しておくと良いかと思います。

更新前後の比較

参考までに更新前後にAWSドキュメントに掲載されていた評価ロジックの画像を貼り付けておきます。

更新前

更新前

更新後

更新後

各種アクセスポリシーについて

評価ロジックの図に掲載されている各種アクセスポリシーについて、以下改めて整理しておきます。

拒否の評価（明示的な拒否）

まずAWSの仕様では全てのリクエストは拒否の扱いになります。これは暗黙的な拒否と呼ばれます。AWSでは暗黙的な拒否としてリクエストを処理する前にイメージ図のOrganizations SCP以降のポリシーを全てチェックします。チェックする中でポリシーでDenyされている権限があればその権限を制限します。このようにポリシー内で明示的にDenyすることを明示的な拒否と呼びます。明示的な拒否がなければ、次のポリシー評価に移ります。

Organizations SCP

SCPとはマルチアカウント管理でとても便利なサービスとして知られるAWS Organizations で利用可能なService Control Policy を示しています。SCPではOrganizations配下のOU（Organizational Unit）、AWSアカウントに対する権限を規定します。これによりOUやAWSアカウントはSCPで規定した権限以上のことは何もできなくなります。AWSのIAMのベストプラクティス （最小権限の許可）にしたがって細かい制御を行うのは運用負荷が高いので、SCPでは許可したいことではなく、拒否させたいことを規定する方が良いと思います。

SCPについては以下のブログをご参照ください

blog.serverworks.co.jp

Organizations については以下のブログをご参照ください

blog.serverworks.co.jp

注意点としては、SCPの有効範囲はIAM UserとIAM Roleのみであるという点です。評価ロジックに記載されているリソースベースのポリシー等をSCPで制御することはできず、アイデンティティベースのポリシーのみ制御ができます。

※参考：サービスコントロールポリシー (SCPs) - AWS Organizations

つまりSCPを適用している場合は、「SCPで明示的な許可」かつ「アイデンティティベースのポリシーで明示的な許可」をしている操作のみが最終的な許可される権限になります。

※参考: Policy evaluation logic - AWS Identity and Access Management

AWSドキュメントより抜粋

リソースベースのポリシー

次はリソースベースのポリシーの評価です。これはAWSリソースに対して直接規定するポリシーで例えば以下のAWSサービスにポリシーを適用することができます。

S3を例に挙げます。S3ではリソースベースのポリシーはバケットポリシーと呼ばれます。バケットポリシーでは例えばどのようなPrincipalに対して、どういった操作を許可/拒否するのかを規定することができます。

以下の図ではIAMユーザー（yamasaki）に対してProductionというS3バケットにおけるGetObject/PutObjectの操作を許可しています。

バケットポリシーの例

リソースベースのポリシー動作については以下のAWSドキュメントに整理されていますので、合わせてご覧ください。

docs.aws.amazon.com

アイデンティティベースのポリシー

そして最後にアイデンティティベースのポリシーを評価します。これはリソースベースのポリシーとは異なりIAMユーザーやIAMグループ、IAMロールといったいわゆるIAMアイデンティティと呼ばれるエンティティに記述するポリシーです。これが皆さんがよく聞き馴染みのあるIAMポリシーと呼ばれるものです。

IAM ポリシーの見方や書き方については以下のブログをご参照ください

blog.serverworks.co.jp

blog.serverworks.co.jp

IAM Permissions Boundary

次はIAM Permissions Boundaryの評価です。IAM Permissions Boundary はアイデンティティベースのポリシーで規定可能な権限の範囲を設定します。これによりアイデンティティベースのポリシーでIAM Permissions Boundaryで規定した権限範囲を逸脱した操作を許可したとしてもその操作はできなくなります。つまり、IAM Permissions Boundary と アイデンティティベースのポリシー で双方に許可されている権限のみが操作可能になります。

docs.aws.amazon.com

IAM Permissions Boundary のイメージ

セッションポリシー

次はセッションポリシーの評価です。セッションポリシーは、AssumeRole の操作中にオプションで渡すことができるアクセス許可ポリシーです。これにより、そのセッションに対するロールの権限にさらに制限を加えることができます。これだけだとちょっとよく分からないのでSwitch Roleをユースケースとして用いて説明したいと思います。以降ご紹介するサンプルリクエスト等はAWSドキュメントを参考にしています。

docs.aws.amazon.com

ユースケース：クロスアカウントのSwitch Role

Switch Roleのイメージ

①AssumeRole API Request

まずはAWS Security Token Service (AWS STS) に対してAssumeRole API Requestを行います。AssumeRole API Request を実行するためにはIAM Roleのメニュータブ中にある「信頼関係」のメニューの中にある「信頼されたエンティティ」の設定でAccount AのAccount IDを指定する必要があります。 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:root"
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

信頼されたエンティティはリソースベースのポリシーに分類されるポリシーで、AssumeRole API Request の実施を許可するPrincipalを指定するポリシーです。今回はリクエスト主体がIAM Userですが、EC2に対してAssumeRole API Request の実施を許可することでEC2から別のリソースを操作したい場合は以下のような信頼されたエンティティを記述します。

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

話が少し脱線してしまいましたが、AssumeRole API Requestの実際のサンプルリクエストは以下をご確認ください

https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=testAR
&RoleArn=arn:aws:iam::123456789012:role/demo
&PolicyArns.member.1.arn=arn:aws:iam::123456789012:policy/demopolicy1
&PolicyArns.member.2.arn=arn:aws:iam::123456789012:policy/demopolicy2
&Policy={"Version":"2012-10-17","Statement":[{"Sid":"Stmt1",
"Effect":"Allow","Action":"s3:","Resource":""}]}
&DurationSeconds=3600
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Team
&Tags.member.2.Value=Engineering
&Tags.member.3.Key=Cost-Center
&Tags.member.3.Value=12345
&TransitiveTagKeys.member.1=Project
&TransitiveTagKeys.member.2=Cost-Center
&ExternalId=123ABC
&SourceIdentity=Alice
&AUTHPARAMS

サンプルリクエスト中に記載されているRoleArnがSwitch Roleで利用するためにAccount Bで作成したIAM Roleです。

またPolicyArns.member.1.arn / PolicyArns.member.2.arn / Policy と記載されているポリシーがありますが、これがセッションポリシーです。しかし、明示的にセッションポリシーを指定するケースは稀ですのであまり気にしなくて良いと思います。

②temporary security credentials

AssumeRole API Request のレスポンスは以下のような形式で帰ってきます。

<AssumeRoleResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
  <AssumeRoleResult>
  <SourceIdentity>Alice</SourceIdentity>
    <AssumedRoleUser>
      <Arn>arn:aws:sts::123456789012:assumed-role/demo/TestAR</Arn>
      <AssumedRoleId>ARO123EXAMPLE123:TestAR</AssumedRoleId>
    </AssumedRoleUser>
    <Credentials>
      <AccessKeyId>ASIAIOSFODNN7EXAMPLE</AccessKeyId>
      <SecretAccessKey>wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY</SecretAccessKey>
      <SessionToken>
       AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
       LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
       QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
       9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
       +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
      </SessionToken>
      <Expiration>2019-11-09T13:34:41Z</Expiration>
    </Credentials>
    <PackedPolicySize>6</PackedPolicySize>
  </AssumeRoleResult>
  <ResponseMetadata>
    <RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
  </ResponseMetadata>
</AssumeRoleResponse>

レスポンス中に記載されているCredentialsが一時的な認証情報と呼ばれているものです。

このCredentialsで許可されている権限はSwitch Role用のIAM Roleで許可している権限と同じです。

③IAM Roleの権限でSwitch Role

②で取得したCredentialsを使ってAccount AからAccount BにSwitch Roleします。Switch Role後にAccount Bで操作した場合、CloudTrailのイベントログを確認するとuserIdentityのarnはIAMユーザーではなくSTSになっています。またSTS自体はグローバルサービスであるためawsRegionはus-east-1（バージニア北部）になっています。

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAZY5ZLIUT4BYFZ5SMS:yamasaki@example.com",
        "arn": "arn:aws:sts::123456789123:assumed-role/SwitchRoleRO/yamasaki@example.com",
        "accountId": "123456789123"
    },
    "eventTime": "2021-08-18T07:01:02Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "SwitchRole",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "122.xx.xx.xxx",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36",
    "requestParameters": null,
    "responseElements": {
        "SwitchRole": "Success"
    },
    "additionalEventData": {
        "SwitchFrom": "arn:aws:iam::111122223333:user/yamasaki@example.com",
        "RedirectTo": "https://console.aws.amazon.com/organizations/v2/home?region=ap-northeast-1#"
    },
    "eventID": "323c2383-09e0-4146-bf44-c0f1cc99b10b",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "

まとめ

今回はたまたま IAMドキュメントの更新履歴を見る機会があり、そこでアクセスポリシーの評価ロジックが更新されていることを発見しました。

以下のAWSの最新情報ページで随時最新のアップデートは掲載されていきますが、一部紹介されずにAWS公式ドキュメントでは更新されているケースがあります。

ですので、普段よく利用しているAWSサービスについては最新情報のページだけでなく、ドキュメントの更新履歴もチェックするようにしましょう！

aws.amazon.com

山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ

カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers

【AWS re:Invent 2024 開催中】

【AWS re:Invent 2024 をエンジニアブログで振り返ろう】

2024年12月2日 - 12月6日 | ラスベガス（米国）
世界最大の AWS カンファレンス・AWS re:Invent 2024の感動をエンジニアブログで振り返りましょう！

AWS re:Invent 2024のブログ記事を読む