BETA

AWSのポリシーを理解する

投稿日:2019-12-24
最終更新:2019-12-24

ポリシーとは

  • IAMアイデンティティ・AWSリソースに関連付けてアクセス許可を定義したもの
    • JSONポリシードキュメントで設定
    • ポリシードキュメントは1つ以上のStatementブロックで構成

ポリシーのタイプ

  • アイデンティティベースポリシー
    • 後述
  • リソースベースポリシー
    • インラインポリシーをリソースにアタッチする。
      • AWS IAMロールの信頼ポリシー
      • Amazon S3のバケットポリシー
      • Amazon SNSのトピックのアクセス許可
      • Amazon SQSキューのアクセス許可
  • パーミッションバウンダリ
    • 管理ポリシーを利用してアイデンティティベースポリシーがIAMエンティティに付与できるアクセス許可の上限を設定
      • AWS IAMアクセス許可の境界
  • AWS Organizationsサービスコントロールポリシー(SCP)
    • 組織・組織単位のメンバーアカウントのアクセス許可上限を定義
  • アクセスコントロールポリシー
    • Amazon S3のバケットACL
    • Amazon VPCのサブネットのACL
  • セッションポリシー
    • ロールまたはフェデレーティッドユーザを引き受ける場合、アイデンティティベースのポリシーでセッションに付与する
      アクセス許可を制限。
    • AssumeRoleなどの際に、セッションポリシーがユーザに付与
    • 当該ユーザはリソースベースポリシーとアイデンティティベースポリシーとセッションポリシーのすべてにおいて許可されているリソースにアクセスできる。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html

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

  • 管理ポリシー
    • 複数のIAMユーザ・IAMグループ・IAMロールに関連付けできる
      • 最大10個まで関連付け可能
    • 再利用可能
    • 変更管理一元化
    • バージョニング・ロールバック可能
    • 以下の2種類
      • AWS管理ポリシー
        • AWSにより事前定義された管理ポリシー
      • ユーザによる編集不可
      • すべてのAWSアカウントで利用可能
      • AWSにより更新される可能性がある
      • カスタム管理ポリシー
        • AWSアカウント内で管理できるカスタムポリシー
      • AWS管理ポリシーで要件を満たせない場合適用
  • インラインポリシー
    • 単一のIAMユーザ・IAMグループ・IAMロールに直接埋めこまれるポリシー
    • 直接IAMエンティティに埋め込まれるため、IAMエンティティを削除すると削除される。
    • IAMエンティティとポリシーを厳密な1対1の関係を維持する場合に利用

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

通常はインラインポリシーではなく管理ポリシーの利用が推奨される
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline

ポリシードキュメント

要素

  • Version
    • ポリシー言語のバージョン
    • 2012-10-17が現行バージョン
    • Virsion要素を含めないとポリシー変数は文字列として扱われることになる。
  • Statement
    • アクセス許可を設定するためのブロック
    • 複数並列で並べることが可能
  • Effect
    • AllowまたはDeny
    • Statementの結果を許可または明示的拒否設定を行う
  • Principal
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_principal.html
    • リソースベースのポリシーで利用
    • リソースへのアクセス許可または拒否するIAMエンティティをARNで指定
      • IAMユーザ
      • フェデレーテッドユーザ
      • IAMロール
      • 引き受けたロールユーザ(assumed-role user)
      • AWSサービス
        例)Principalの指定
        • 特定のAWSアカウント
          “Principal”: { “AWS”: "arn:aws:iam::111111111111:root"}  
          “Principal”: { “AWS”: "111111111111"}  
        • 個別のIAMユーザ
          “Principal”: { “AWS”: arn:aws:iam::111111111111:/user/Karin}  
        • IAMロール
          “Principal”: { “AWS”: arn:aws:iam::222222222222:/[ロール名]}  
        • 特定のロールを引き受けたセッション
          “Principal”: { “AWS”: arn:aws:sts::333333333333:assumed-role/<ロール名>/<ロールセッション名>"}  
          【注意点】
          • IAMグループの指定不可
          • 大文字・小文字は区別される
          • ユーザを指定する際に「すべてのユーザ」の意味でワイルドカード(*)を利用することはできない
            • ただし、匿名ユーザ(パブリック)とする場合、アスタリスク(*)を利用できる
      • 匿名ユーザ
        -“Principal”: "*" → 〇  
        -“Principal”: {"AWS": "*"} → 〇  
      • ユーザ指定
        -“Principal”: { “AWS”: arn:aws:iam::111111111111:/user/*} → ×  
  • Action
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_action.html
    • Effect要素で許可または拒否する対象となるアクションを記述
    • StatementにはAction/NotActionが必須
    • AWSサービスを識別する名前空間(例:iam,ec2,s3など)でサポートされるアクションを記載
      • 名前空間ごとにサポlトされているアクションが定義されている
      • 形式
        • "Action": <サービスの名前空間>:<アクション名>
      • 記述例
        “Action”: "ec2:StartInstances"  
        “Action": ["sqs:SendMessage","sqs:ReceiveMessage"]  
        • 複数のアクッションを指定可能
        • ワイルドカードを指定可能
        • 大文字・小文字の区別なし
  • Resurce
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_resource.html
    • Actionの対象となる特定のリソースをARNで記述
    • StatementにはResource/NotResourceが必須
    • 指定したアクションによっては、個々のリソースが指定できない場合があり、その場合は*(ワイルドカード)を指定する
      • 記述例
        "Resource”: "arn:aws:sqs:ap-northeast-1:111111111111:queue1  
        "Resource”: "arn:aws:iam::111111111111:user/accounting/*"  
        "Resource”: [   
          "arn:aws:dynamodb:ap-northeast-1:111111111111:<table-name> ",  
          "arn:aws:dynamodb:ap-northeast-1:111111111111:<table-name> "  
        ]  
        "Resource” : "arn:aws:dynamodb:ap-northeast-1:111111111111:table/${aws:username}"  
        • 複数のリソースを指定可能
        • ワイルドカードの指定可能
        • JSONポリシー変数の指定可能
  • Condition
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_condition.html
    • Conditionの記述はオプション
      • なくてもいい
    • ポリシーを実行する条件を指定
    • 形式
      • ”Condition” : { 条件演算子 >:{ <条件キー>: <条件値> }}
    • 条件演算子
      • 条件比較のタイプ(文字列条件、数値条件、IPアドレス条件等)を指定
      • 条件キーごとに使用できる条件演算子の種類が決まっている
    • 条件キー
      • AWS グローバル条件コンテキストキー(aws:で始まる)
        • 全てのサービスで使用可能なキー、一部のサービスでのみ使用可能なキーがある
      • AWSサービス固有のキー(そのサービス固有の名前(“S3:"等)で始まる)
      • IAM の条件コンテキストキー
    • 記述例
      “Condition”: {"StringEquals”:{"aws:username”:"Karin"}  
      “Condition": {"IpAddress":{"aws:SourceIP":["192.0.2.0/24","200.0.200.0/24"]}}  
      "Condition": {"StringEquals":{"s3:prefix": "projects"}}  
      • 条件キーは大文字小文字区別なし
      • 条件値の大文字小文字区別は使用する条件演算子により異なる

リファレンス

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements.html

Conditionの条件評価

  • 複数の条件がある場合はAND条件

    “Condition”: {  
        "StringEquals”:{"aws:username”:"Karin"}, → 条件a  
        "StringEquals":{"s3:prefix": "projects"}, → 条件b  
        "IpAddress":{"aws:SourceIP":["192.0.2.0/24","200.0.200.0/24"]} → 条件c  
    }  

    条件aと条件bと条件cはAND

  • 演算子内の条件はOR条件

    “Condition": {"IpAddress":{"aws:SourceIP":["192.0.2.0/24","200.0.200.0/24"]}}  
                                                     ↓              ↓  
                                                    条件d           条件e  

    条件dと条件eはOR条件

アクセス可否の評価ロジック

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#AccessPolicyLanguage_Interplay

  • 暗黙的なDeny < 明示的なAllow < 明示的なDeny
  • すべてのアクセスはデフォルトでは拒否設定(暗黙的なDeny)
    • 何も設定しなければ拒否設定になる。
  • アクセス権限にAllowの条件があればアクセス許可される。
  • ただし、アクセス権限に1つでもDenyの条件があればアクセス拒否(明示的なDeny)
    • IAMグループのポリシーのStatementにAllow条件がある + IAMユーザのポリシーのStatementには何も設定されていない(暗黙的Deny)
      Allow
    • IAMグループのポリシーのStatementにDeny条件がある + IAMユーザのポリシーのStatementにAllow条件がある
      Deny(明示的Denyがあるため)

NOT条件の場合

  • 条件A以外の場合許可するという設定の場合、条件Aは暗黙的なDenyという扱いになる。
    1. リソースベースポリシーでユーザA以外のアクセスを許可
      • NotPrincipal : ユーザA
      • Effect : Allow
    2. ユーザAのアイデンティティベースポリシーでアクセスが許可されているケース

      → ユーザAはAllowとなる。
      1のポリシーでは、暗黙的Denyとなり、2のポリシーでは明示的Allowとなるため

      なお、上記の例のようにNotPrincipalでAllowを使うケースは推奨されていない
      https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_notprincipal.html

      NotPrincipal は、"Effect": "Allow" と同じポリシーステートメント内で使用しないことを強くお勧めします。これにより、NotPrincipal 要素で指定されたプリンシパル以外のすべてのプリンシパルが許可されます。ポリシーステートメントで指定されたアクセス許可は、指定されたものを除いてすべてのプリンシパルに付与されるため、これはお勧めしません。この操作を行うと、匿名の (承認されていない) ユーザーにアクセス許可が付与される可能性があります。

アクセス権の決定ロジック

同一アカウントの場合

Organizationsサービスコントロールポリシー(SCP) AND ((アイデンティティベースポリシー AND パーミッションバウンダリ) OR リソースベースポリシー)

  • アイデンティティベースポリシー内
    • 管理ポリシーとインラインポリシーのそれぞれに許可されているものが有効(OR条件)
  • アイデンティティベースポリシーとパーミッションバウンダリ
    • パーミッションバウンダリとアイデンティティベースポリシーの両方で許可されているものが有効(AND条件)
    • パーミッションバウンダリで許可されていない場合、アイデンティティベースポリシーで許可されていてもアクセス権は付与されない
  • SCPとアイデンティティベースポリシー
    • SCPとアイデンティティベースポリシーの両方で許可されているものが有効(AND条件)
    • SCPにより制限されている場合は、アイデンティティベースポリシーで許可されていてもアクセス権は付与されない
  • アイデンティティベースポリシーとリソースベースポリシー
    • 同一アカウントの場合、アイデンティティベースポリシーとリソースベースポリシーのそれぞれで許可されているものが有効(OR条件)
    • どちらかで許可されていればアクセス権が付与

クロスアカウントの場合

Organizationsサービスコントロールポリシー(SCP) AND ((アイデンティティベースポリシー AND パーミッションバウンダリ) AND リソースベースポリシー)

  • アイデンティティベースポリシーとリソースベースポリシー
    • クロスアカウントの場合、アイデンティティベースポリシーとリソースベースポリシーの両方で許可されているものが有効(AND条件)
    • 同一アカウントのユーザアクセスと異なる。
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

自分用お勉強メモです。間違っているところなどあるかもしれませんが、ご了承ください。

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう