2017-10-20 8 views
2

単純なWebホストとしてs3バケットを使用しようとしていますが、必要なセキュリティコントロールをレイヤーできるリバースプロキシの背後に配置したいと考えています。AWSリバースプロキシのバケットポリシー

私はリバースプロキシに関連付けられたIPアドレスを持っており、s3 Webアクセスを制限したいと考えています。バケツポリシーにIPベースの制限を適用すると、アカウントの管理上のやり取りをブロックするのが非常に難しいようです。

コンソール/ IAMユーザー/フェデレーションの役割でアカウント内からのアクセスを中断しないでくださいが、リバースプロキシに関連付けられたIPだけのs3サイトへのHTTPアクセスを有効にします。

Webアクセスを有効にするために必要なものに関するAWSのドキュメントには、このポリシーステートメントが必要であることが示されています。

次に、Webトラフィックを特定のIPセットに制限して、このステートメントを追加します。

{ 
    "Id": "S3_Policy", 
    "Statement": [ 
     { 
      "Sid": "AllowWebAccess", 
      "Effect": "Allow", 
      "Principal": "*", 
      "Action": [ 
       "s3:GetObject" 
      ], 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*" 
      ] 
     }, 
     { 
      "Sid": "DenyNonProxyWebAccess", 
      "Effect": "Deny", 
      "Principal": "*", 
      "Action": "s3:*", 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*", 
       "arn:aws:s3:::mybucket" 
       ], 
      "Condition": { 
       "NotIpAddress": { 
        "aws:SourceIp": [ 
         "99.99.99.1/32", 
         "99.99.99.2/32", 
         "99.99.99.3/32", 
         "99.99.99.4/32", 
         "99.99.99.5/32" 
        ] 
       } 
      } 
     } 
    ] 
} 

このポリシーを否定するには、IAMユーザーとアカウントの中からそれにアクセスしたり、連合の役割を仮定するために私の能力を阻止する意図せぬ結果を持っているので、私は、これらのリソースを可能に明示的に追加されました。可能であれば、 "口座"にブランケットを許可するだけです。それは私にこの政策を残し、私はそれをどのようにしたいのかちょうどうまくいかないようです。私はそれをユーザーとして管理したり、プロキシからWebコンテンツにアクセスすることはできません。

{ 
    "Id": "S3_Policy", 
    "Statement": [ 
     { 
      "Sid": "AllowWebAccess", 
      "Effect": "Allow", 
      "Principal": "*", 
      "Action": [ 
       "s3:GetObject" 
      ], 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*" 
      ] 
     }, 
     { 
      "Sid": "DenyNonProxyWebAccess", 
      "Effect": "Deny", 
      "Principal": "*", 
      "Action": "s3:*", 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*", 
       "arn:aws:s3:::mybucket" 
       ], 
      "Condition": { 
       "NotIpAddress": { 
        "aws:SourceIp": [ 
         "99.99.99.1/32", 
         "99.99.99.2/32", 
         "99.99.99.3/32", 
         "99.99.99.4/32", 
         "99.99.99.5/32" 
        ] 
       } 
      } 
     }, 
     { 
      "Sid": "AllowAccountUsersAccess", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": [ 
        "arn:aws:IAM::999999999999:user/[email protected]", 
        "arn:aws:IAM::999999999999:user/[email protected]", 
        "999999999999" 
       ] 
      }, 
      "Action": "s3:*", 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*", 
       "arn:aws:s3:::my bucket" 
      ] 
     } 
    ] 
} 

S3バケットはアカウントからバケット自体を管理する機能を中断することなくIPは、Webアクセスのための範囲のみ選択に制限静的なWebホストである持っている方法はありますか?

答えて

1

のAmazon S3バケット内のリソースに付与することができるアクセスする複数の方法があります。

  • IAM権限
  • バケットポリシー
  • プリ署名URL

がアクセスした場合要求がを満たしている場合、上記のいずれかのにアクセス権が与えられます(ただし、Denyがそれを上書きする可能性があります)。

IAM権限ユーザーまたはグループに権限を割り当てるために使用されています。たとえば、バケットにアクセスする場合は、ポリシーを作成して、をIAMユーザとして割り当てることができます。すべての管理者がバケットにアクセスするようにしたい場合は、IAMグループに入力し、ポリシーをグループに割り当てます。この方法で行われたすべてのアクセスは、AWSクレデンシャル(匿名アクセスなし)で行う必要があります。

バケットポリシーは、通常、匿名アクセス(資格情報は不要)を付与するために使用されますが、IPアドレス範囲、SSLのみ、時刻などの制限が含まれます。これは、要求の一部として資格情報を送信していないため、リバースプロキシへのアクセスを許可する方法です。

事前署名URLは、特定のオブジェクトに一時的なアクセスを許可するアプリケーションによって生成することができます。 URLには、アクセスを認証する計算された署名が含まれています。これは、通常、HTMLページ上のリンクを生成する場合(例えば、プライベート画像にリンクする場合)に使用されます。

あなたの状況

だから、まず、あなたは次のようにポリシー使用して、自分自身と自分の管理者へのアクセスを許可する必要があります。それは何にも適用されるので、何Principalがないこと

{ 
    "Id": "S3_Policy", 
    "Statement": [ 
     { 
      "Sid": "AllowWebAccess", 
      "Effect": "Allow", 
      "Action": [ 
       "s3:GetObject" 
      ], 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*" 
      ] 
     } 
    ] 
} 

注意をユーザー/グループにはこのポリシーが割り当てられています。

次に、逆プロキシへのアクセスを許可したいとします。このポリシーは、指定したバケットに(Allow)アクセスを許可され

{ 
    "Id": "S3_Policy", 
    "Statement": [ 
     { 
      "Sid": "DenyNonProxyWebAccess", 
      "Effect": "Allow", 
      "Principal": "*", 
      "Action": "s3:*", 
      "Resource": [ 
       "arn:aws:s3:::mybucket/*", 
       "arn:aws:s3:::mybucket" 
       ], 
      "Condition": { 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "99.99.99.1/32", 
         "99.99.99.2/32", 
         "99.99.99.3/32", 
         "99.99.99.4/32", 
         "99.99.99.5/32" 
        ] 
       } 
      } 
     } 
    ] 
} 

が、場合にのみ要求が規定されたIPアドレスのいずれかから来ている:これはバケットポリシーを介して行うことができます。

によるアクセスの許可は、常にDenyAllowを上書きするため、アクセスを拒否することよりも優先されます。したがって、一度何かが拒否されると、それは許可されない可能性があります(たとえば、Denyが管理アクセスをブロックする場合、アクセスを許可することはできません)ので、Denyを控えめに使用してください。拒否は、あなたが確かに何かをブロックしたい場所(例えば、悪名の悪い俳優)で使用されます。

VPCエンドポイント

検討する価値最後のオプションは、S3ためVPCエンドポイントを使用することです。これにより、インターネットゲートウェイを経由することなく、VPCとS3間の直接通信が可能になります。これは、プライベートサブネット内のリソースがNATゲートウェイを使用せずにS3と通信したい場合に適しています。

追加のポリシーをVPCエンドポイントに追加して、どのリソースがVPCエンドポイント(たとえば、逆プロキシの範囲)にアクセスできるかを定義できます。バケットポリシーは、具体的にはVPCエンドポイントを参照し、そのアクセスメソッドからの要求を許可することができます。たとえば、特定のVPCからのアクセスのみを許可するバケットポリシーを設定できます。これは、Dev/Test/Prodのバケットへのアクセスを分離する場合に便利です。

すべて逆引きプロキシの外でも、S3トラフィックがVPCエンドポイント経由で送信されるため、指定されたユースケースには適していない可能性があります。これは、あなたのアーキテクチャにとって望ましい動作ではないかもしれません。

ボトムライン: IAMポリシーは、ユーザーへのアクセスを許可します。バケットポリシーは匿名アクセスを許可します。

あなたがリストした最初のポリシーを「必要」することは確かではなく、バケットへの完全なアクセスを許可するため、実際にそのポリシーを使用することはめったにありません。

関連する問題