2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

複雑なS3BucketPolicyの設計

Last updated at Posted at 2020-02-13

概要

ポリシー厳しめのS3バケットを作成したいときに、S3BucketPolicyを設定すると思います。
今回はS3BucketPolicyを設定時に、DenyPolicyかつNot〜を利用すると理解に苦しむほど複雑になるのでまとめました。
また、CloudFormationを利用してBucketPolicyを作成した事例になります。

背景

上記ではポリシー厳しめと書きましたが、具体的にはいくつかのポリシーが必要になりました。

  • セキュアな情報を格納するため、許可ではなく明示的に拒否しセキュリティレベルを高めたい
  • ある特定の操作(Action_B)のみ許可するようにしたい
  • あるユーザー(User_C)のみ操作を許可するようにしたい
  • あるAssumeRole(RoleID_D)にスイッチした場合のみ許可するようにしたい

参考ですが、想像しやすいようにより具体的に例をあげると

  • 個人情報を含むデータを格納するため、セキュリティレベルは高い必要がある
  • 改ざん、閲覧は禁止のなので、PutObjectのみ許可したい、Get、List、Deleteなどは拒否したい
  • 個人情報を配置する専用のユーザー(アクセスキー発行)からのみPutObjectを許可したい
  • メンテンスやテストをするために、例外としてはAssumeRoleにスイッチした場合のみPutObjectを許可したい

今回は概念を説明するために、汎用的な場合で説明します。
ここで要件を満たすためにサンプルテンプレートを作成しました。

s3_bucket_policy.yml

  S3BucketPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: 'Bucket_A'
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: 'Deny'
            NotAction: 'Action_B'
            NotPrincipal: 'User_C'
            Resource: 
              - 'BucketA/'
              - 'BucketA/*'
            Condition:
              StringNotLike: 'RoleID_D'

説明

上記テンプレートを反映させた場合の挙動を説明します。
Bucket_Aに対して、Action_B以外の操作を、User_C以外のユーザーかつ、RoleID_D以外の場合は拒否する
ちょっと良くわからないですね。図にします。

S3BucketPolicy_05.jpg

Action_B以外の操作を、User_Cと、RoleID_Dは許可され(厳密には未定義)、それ以外は拒否されているのがわかると思います。
一つ一つ説明していきます。

初期状態

S3BucketPolicy_01.jpg
初期状態(未定義)ではBucket_Aに対してすべての操作が可能になっています
例:GetObject,ListObject,DeleteObject 等

Effect: 'Deny'

S3BucketPolicy_02.jpg
DenyPolicyにすることですべての操作が拒否されるようになります。
※便宜上、現段階ではAction,Principalは * として説明しています。

NotAction: 'Action_B'

S3BucketPolicy_03.jpg
NotAction: 'Action_B'によって、Action_B以外の操作を拒否するようになりました。
Action_Bについては未定義のため許可となっています。
例えば以下の様に書くと、更新系の拒否(参照系以外の拒否)が可能になります。

NotAction:
 - 's3:Get*'
 - 's3:List*'

NotPrincipal: 'User_C'

S3BucketPolicy_04.jpg
NotPrincipal: 'User_C'によって、Action_B以外かつ、User_C以外の操作は拒否する様になりました。
User_Cについては未定義のため許可となっています。
例えば以下の様に書くと、IAMUserHoge以外の操作は拒否するようになります。(IAMUserHogeは同じテンプレート内で作成)

NotPrincipal:
  "AWS":
    - !GetAtt IAMUserHoge.Arn

Condition: StringNotLike: 'RoleID_D'

S3BucketPolicy_05.jpg

Condition: StringNotLike: 'RoleID_D'によって、RoleID_D以外を利用した操作は拒否する様になりました。
Conditionを利用することで先程まで拒否になっていた操作に例外を作り出すことができます。
例えば以下の様に書くと、IAMRoleFuga以外の操作は拒否するようになります。

Condition:
  StringNotLike:
    aws:userid:
      - !Sub '${IAMRoleFuga.RoleId}:*'

以上で当初の目的であったBucket_Aに対して、Action_B以外の操作を、User_C以外のユーザーかつ、RoleID_D以外の場合は拒否するが実装できました。

追加作業

ここまでだと、Action_Bは誰でも操作できてしまうため、Action_Bも拒否するようにポリシーを追加します。

          - Sid 'DenyAction_B'
          - Effect: 'Deny'
            Action: 'Action_B'
            Principal: '*'
            Resource: 
              - 'BucketA/'
              - 'BucketA/*'

S3BucketPolicy_06.jpg
より実践的なPolicyになったのではないでしょうか。

まとめ

以上の様にして、複雑なS3BucketPolicyを設定することができます。

参考

参考程度ですが、今回僕が実装した最終版のテンプレートを配置しておきます。
要件がより詳細になったことで最終的にはDenyポリシーを5つ使用した大変メンテンスしづらいテンプレートができてしまいました。

  • PutObjectはアクセスキーを発行した、Hogeサーバーのみ許可。社内ネットワークIP制限も実施
  • PutObject以外の更新系は基本拒否
  • 更新系を上記だけに絞るとCFnができなくなるので、例外としてCFn専用のRoleを作成し更新系(Put、Delete、、etc)を許可
  • 参照は専用に作成したAssumeRoleにスイッチできるユーザーのみ許可
  S3BucketPolicy:
    Condition: InDev
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref S3Bucket
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
        # 更新系に関するDeny:特定のRoleをAssumeしたユーザとHogeサーバ以外の更新系禁止
          - Effect: 'Deny'
            NotAction:
              - 's3:Get*'
              - 's3:List*'
            NotPrincipal:
              "AWS":
                - !GetAtt IAMUserHogeServer.Arn # Hogeサーバに置くトークン発行ユーザ
            Resource:
              - !Sub '${S3Bucket.Arn}'
              - !Sub '${S3Bucket.Arn}/*'
            Condition:
              StringNotLike:
                aws:userid:
                  - !Sub '${IAMRoleUser.RoleId}:*'
                  - !Sub '${IAMRoleCFn.RoleId}:*' # CFnで更新ができるように指定
        # 更新系に関するDeny:Hogeサーバ以外のPutObjectを全て禁止
          - Sid: 'DenyPutExceptHogeServer'
            Effect: 'Deny'
            Action:
              - 's3:PutObject'
            NotPrincipal:
              "AWS":
                - !GetAtt IAMUserHogeServer.Arn #Hogeサーバに置くトークン発行ユーザ
            Resource:
              - !Sub '${S3Bucket.Arn}/*'
              - !Sub '${S3Bucket.Arn}'
        # 更新系に関するDeny:HogeサーバのPutObject以外を全て禁止
          - Sid: 'DenyExceptPut'
            Effect: 'Deny'
            NotAction:
              - 's3:PutObject'
            Principal:
              "AWS":
                - !GetAtt IAMUserHogeServer.Arn # Hogeサーバに置くトークン発行ユーザ
            Resource:
              - !Sub '${S3Bucket.Arn}/*'
              - !Sub '${S3Bucketw.Arn}'
        # 更新系に関するDeny:HogeサーバのPutObjectを社内ネットワークに限定
          - Sid: 'DenyPutOutOfServerNetwork'
            Effect: 'Deny'
            Action: 's3:PutObject'
            Principal:
              "AWS":
                - !GetAtt IAMUserHogeServer.Arn # Hogeサーバに置くトークン発行ユーザ
            Resource:
              - !Sub '${S3Bucket.Arn}'
              - !Sub '${S3Bucket.Arn}/*'
            Condition:
              NotIpAddress:
                aws:SourceIp:
                  - 'x.x.x.x' # HogeサーバのIP
        # 参照系に関するDeny:SecureRole以外からの参照系禁止
          - Sid: 'DenyGetListExceptIAMRole'
            Effect: 'Deny'
            Principal: '*'
            Action:
              - "s3:Get*"
              - "s3:List*"
            Resource:
              - !Sub '${S3Bucket.Arn}'
              - !Sub '${S3Bucket.Arn}/*'
            Condition:
              StringNotLike:
                aws:userid:
                - !Sub '${IAMRole.RoleId}:*'

2
3
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
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?