3

次のバケット ポリシーを使用すると、期待どおりに PUT アクセスが制限されていることがわかります。ただし、この操作を許可するものがないにもかかわらず、作成されたオブジェクトで GET が許可されています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPut",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<BUCKET>/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "<IP ADDRESS>"
                    ]
                }
            }
        }
    ]
}

次のように、curl を使用して<BUCKET>ファイルを PUT することができます。<IP ADDRESS>

curl https://<BUCKET>.s3-<REGION>.amazonaws.com/ --upload-file test.txt

ファイルが正常にアップロードされ、S3 コンソールに表示されます。何らかの理由で、インターネット上のどこからでもファイルを取得できるようになりました。

curl https://<BUCKET>.s3-<REGION>.amazonaws.com/test.txt -XGET

これは、上記の方法を使用してアップロードされたファイルにのみ適用されます。S3 Web コンソールでファイルをアップロードするときに、curl を使用して GET できません (アクセスが拒否されました)。したがって、これはオブジェクト レベルの権限の問題だと思います。バケット ポリシーがこのアクセスを暗黙的に拒否しない理由はわかりませんが。

コンソールでオブジェクト レベルのアクセス許可を見ると、コンソールからアップロードされたファイル (方法 1) と、許可されたものからアップロードされたファイル (方法 2) の唯一の違いは、<IP ADDRESS>方法 2 のファイルには「所有者」がないことです。 、アクセス許可、またはメタデータ - メソッド 1 ファイルにはこれらすべてが含まれています。

さらに、バケットへのフルアクセス権を持つロールを引き受ける Lambda スクリプト (boto3 download_file()) を使用してオブジェクトを取得しようとすると、方法 2 でアップロードされたオブジェクトでは失敗します。方法 1 でアップロードされたオブジェクトでは成功します。

4

1 に答える 1

3

問題の概要

問題を要約するには：

  • 特定のソース IP アドレスからのオブジェクトの匿名アップロードを許可するポリシーがある
  • これらのオブジェクトは、認証されたユーザー (具体的には、ラムダ関数によって採用された Iam ロール) によって読み取られません。
  • これらのオブジェクトは、認証されていないユーザーが任意の IP から読み取ることができます

その他の観察

  • 認証されていないユーザーはオブジェクトを削除できません

望ましい結果は次のとおりです。

  • オブジェクトは、認証されていないユーザーが既知の IP アドレスからアップロードできます
  • 認証されていないユーザーは、どの IP アドレスからでもオブジェクトをダウンロードできません。
  • 認証された Iam ユーザーがオブジェクトを取得できる

根本的な原因

何が起こっているかは次のとおりです。

  1. 匿名ユーザーがオブジェクトをアップロードします

    1. 匿名ユーザーがオブジェクト所有者になる

    2. オブジェクト acl を取得することで検証可能 (クエリ文字列を使用してオブジェクトに対して GET 要求を実行?acl) - 以下を受け取ります。

      <?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <Owner>
        <ID>65a011a29cdf8ec533ec3d1ccaae921c</ID>
    </Owner>
    <AccessControlList>
        <Grant>
            <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"><ID>65a011a29cdf8ec533ec3d1ccaae921c</ID></Grantee>
            <Permission>FULL_CONTROL</Permission>
        </Grant>
    </AccessControlList>
</AccessControlPolicy>

      所有者 ID は、匿名ユーザーのユニバーサル ID です。AWS フォーラムのディスカッションで同じ ID が参照されているのを見たことがあります。

  2. オブジェクトの所有者になると、次の影響があります。
    1. 匿名ユーザーには FULL_CONTROL があります (上記の acl を参照)
    2. 匿名ユーザーは削除できません - これは変更できない AWS ブランケット ルールのようです - 匿名ユーザーは、FULL_CONTROL を持っていても、何も削除できません
    3. ただし、匿名ユーザーは、FULL_CONTROL の結果として、既存のオブジェクトの上に空のオブジェクトを配置できます。
  3. バケットのアカウントに含まれていないユーザーが所有するオブジェクトがバケットに含まれている場合:
    1. バケットの所有者にはオブジェクトに対する権限がありません (ACL で参照されていません)
    2. バケットの所有者はオブジェクトを読み取ることができません
    3. バケット所有者は、バケット ACL により、バケット リスト操作でオブジェクトを表示できます
    4. バケットの所有者はオブジェクトを削除できます - これは変更できない包括的なルールです - 請求書を支払う人として、あなたは常にオブジェクトを削除する権利を留保します - あなたがそれを読むことができなくても

解像度

希望する結果を達成する方法があります。残念ながら、バケット ACL でオブジェクトを読み取れるようにするには、特定の Iam エンティティ (ユーザー、ロール、グループ) の arn を参照する必要があります。

このソリューションの主な要素は次のとおりです。

  • バケット所有者に完全なアクセス権を付与することを匿名ユーザーに要求する
    • これにより、バケット所有者と所有者アカウントの Iam ユーザーがオブジェクト ACL によってアクセスを拒否されないことが保証されます
  • 指名されたユーザー/役割ではないすべてのユーザーへのすべての非 PUT アクセスを明示的に拒否します
    • これにより、匿名ユーザーがオブジェクトを読み取ることができなくなります

サンプル ポリシー:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "allow-anonymous-put",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<BUCKETNAME>/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "<IPADDRESS>"
                },
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }

        },
        {
            "Sid": "deny-not-my-user-everything-else",
            "Effect": "Deny",
            "NotPrincipal": {
                "AWS": "arn:aws:iam::<ACCOUNTNUMBER>:role/<ROLENAME>"
            },
            "NotAction": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::<BUCKETNAME>/*"
        }
    ]
}

2 番目のステートメントの鍵は、 と の使用NotPrincipalですNotAction。

私はこれをローカルでテストしましたが、通常の Iam ユーザーにのみアクセスを許可し、役割を引き受ける Lamba 関数ではなく、プリンシパルを保持する必要があります。幸運を！

次の記事は、何が起こっているのかを理解するのに役立ちました。それぞれの記事は、類似したシナリオを提示していますが、まったく同じではありませんが、シナリオに取り組むために使用した方法が道を切り開きました。

于 2016-08-22T03:06:44.347 に答える