翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon S3 アクセスポイントのネットワークアクセスの設定

FSx for ONTAP ボリュームの Amazon S3 アクセスポイントを作成するときは、ネットワーク経由でアクセスポイントにアクセスする方法と、それを使用する権限を持つユーザーを設定します。このセクションでは、環境に適したネットワークとアクセスコントロールの設定を選択するのに役立ちます。

このセクションでは、ネットワークと IAM 認可レイヤーについて説明します。具体的には、アクセスポイントのネットワークオリジン、VPC エンドポイント、アクセスポイントポリシー、VPC エンドポイントポリシー、IAM ID ポリシー、サービスコントロールポリシーです。ファイルシステムレベルの認可 (UNIX および Windows ユーザーアクセス許可) の詳細については、「」を参照してくださいファイルシステムのユーザー ID と認可。

Amazon S3 がアクセスポイントリクエストを評価する方法

FSx for ONTAP ボリュームにアタッチされた Amazon S3 アクセスポイントを介してリクエストが行われる場合、リクエストは次のすべてのレイヤーによって承認される必要があります。

ネットワークオリジンチェックは、ポリシー評価の前に行われます。残りのレイヤーは、標準の IAM 認可決定の一部として一緒に評価されます。つまり、レイヤーオーバーライドの明示的な拒否 他のレイヤーの許可ステートメント。

ネットワークオリジンの選択

Amazon S3 アクセスポイントを作成するときは、アクセスポイントへのアクセス方法を決定するネットワークオリジンを選択します。作成後にネットワークオリジンを変更することはできません。

インターネットオリジン

インターネットネットワークオリジンを持つアクセスポイントは、デフォルトで S3 バケットにアクセスする方法と似ています。すべてのリクエストには有効な IAM 認証情報と認可が必要です。インターネットオリジンは、パブリックアクセスまたは匿名アクセスを意味するものではありません。Amazon S3 は、FSx for ONTAP ボリュームにアタッチされているすべてのアクセスポイントにブロックパブリックアクセスを適用し、この設定を無効にすることはできません。

インターネットオリジンでは、認証されたリクエストは VPCs、オンプレミスネットワーク、他の AWS アカウント、パブリックインターネットなど、どこからでも送信できます。アクセスポイントポリシーと IAM ID ポリシーを使用して、どの認証された発信者を許可するかを制御します。

インターネットオリジンでは、アクセスポイントポリシーと IAM ID ポリシーを使用してアクセスを制御します。同じアカウントの発信者の場合、アクセスポイントポリシーで明示的な拒否ステートメントを使用してアクセスを制限します。発信者の IAM ID ポリシーが個別にアクセスを許可できるため、許可のみのポリシーでは不十分です。クロスアカウント発信者の場合、アクセスポイントポリシーはリクエストを明示的に許可する必要があるため、許可を省略するだけでアクセスをブロックできます。

VPC オリジン

VPC ネットワークオリジンを持つアクセスポイントは、特定の VPC にバインドされ、 aws:SourceVpcがバインドされた VPC と一致しないリクエストを拒否する明示的な拒否ポリシーステートメントとして効果的に動作します。明示的な拒否は常に許可を上書きするため、完全に許可されたアクセスポイントポリシーまたは IAM ID ポリシーであっても、バインドされた VPC の外部からのリクエストへのアクセスを許可することはできません。

バインドされた VPC の VPC エンドポイントを介してトラフィックがルーティングされた場合でも、バインドされた VPC 外の発信者はアクセスポイントにアクセスできます。たとえば、VPC ピアリングや Transit Gateway を介して、バインドされた VPC にデプロイされた Amazon S3 Interface エンドポイントにルーティングされます。

主な違い

VPC オリジンエンフォースメントの仕組み

アクセスポイントに VPC ネットワークオリジンがある場合、 がアクセスポイントの で指定された VPC ID と等しくaws:SourceVpcないすべてのリクエストを拒否する明示的な拒否ポリシーステートメントが存在するかのように効果的に動作しますVpcConfiguration。この拒否は、すべてのプリンシパル、すべての Amazon S3 アクション、およびアクセスポイント内のすべてのリソースに適用されます。

これは明示的な拒否であるため、アクセスポイントポリシー、発信者の IAM ID ポリシー、またはその他のポリシーのいずれであっても、任意の Allow ステートメントを上書きします。

実際には、これは以下を意味します。

これは、拒否されたリクエストのエラーメッセージに「リソースベースのポリシーでの明示的な拒否」と表示されている理由でもあります。

明示的な拒否がある VPC オリジンとインターネットオリジン

VPC オリジンアクセスポイントと、手動で書き込まれたStringNotEquals aws:SourceVpc拒否を持つインターネットオリジンアクセスポイントは、どちらも指定された VPC からのリクエストを拒否します。主な違いは次のとおりです。

Amazon S3 アクセスポイントでの VPC エンドポイントの使用

Amazon S3 アクセスポイントは、Amazon S3 の両方のタイプの VPC エンドポイントで動作します。必要なエンドポイントタイプは、発信者の場所によって異なります。

ゲートウェイエンドポイント

ゲートウェイエンドポイントは無料であり、ルートテーブルベースです。Gateway エンドポイントを作成すると、指定されたルートテーブルにルートが追加され、エンドポイントを介して Amazon S3 トラフィックがルーティングされます。このルートは、VPC 内で発信されるトラフィックにのみ適用されます。

ゲートウェイエンドポイントを以下に使用します。

ゲートウェイエンドポイントは、VPC に入るトラフィックを以下からルーティングしません。

詳細については、Amazon S3のゲートウェイエンドポイント」を参照してください。

インターフェイスエンドポイント

インターフェイスエンドポイントは、サブネットにプライベート IP アドレスを持つ Elastic Network Interface (ENI) を作成します。トラフィックは、エンドポイントの DNS 名またはプライベート IP に明示的に送信する必要があります。

インターフェイスエンドポイントを以下に使用します。

インターフェイスエンドポイントを使用する場合、発信者は次のいずれかを行う必要があります。

インターフェイスエンドポイントには、1 時間あたりの料金と 1 GB あたりの料金があります。詳細については「AWS プライベートリンク の料金」を参照してください。

両方のエンドポイントタイプを一緒に使用する

ゲートウェイエンドポイントとインターフェイスエンドポイントの両方を同じ VPC にデプロイできます。この設定は、VPC 内発信者とオンプレミス発信者の両方がある場合に便利です。

どちらのエンドポイントタイプも aws:SourceVpc 属性に VPC ID を入力するため、どちらも VPC オリジン拒否条件を満たします。

VPC エンドポイントポリシー

VPC エンドポイントポリシーは、エンドポイントを介してアクセスできる Amazon S3 リソースを制御します。デフォルトでは、VPC エンドポイントはすべてのリソースに対するすべての Amazon S3 アクションを許可します。エンドポイントポリシーの範囲を指定して、特定のアクセスポイントのみを許可できます。

{
    "Version": "2012-10-17", 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point",
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
            ]
        }
    ]
}

アクセスポイントポリシー

Amazon S3 アクセスポイントは、リソース、ユーザー、またはその他の条件別にアクセスポイントの使用を制御できる AWS Identity and Access Management (IAM) リソースポリシーをサポートします。クロスアカウントアクセスの場合、アクセスポイントポリシーと発信者の IAM ID ポリシーの両方がリクエストを許可する必要があります。同じアカウントアクセスの場合、アクセスポイントポリシーまたは発信者の IAM ID ポリシーのいずれかが個別にアクセスを許可できます。同じアカウントの発信者を制限するには、アクセスポイントポリシーで明示的な拒否ステートメントを使用します。リクエストが VPC エンドポイントを通過する場合、VPC エンドポイントポリシーもリクエストを許可する必要があります。

アクセスポイントポリシーの詳細については、「Amazon Simple Storage Service ユーザーガイド」の「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。

ネットワークベースのアクセスコントロールの条件キー

IAM には、リクエストのネットワークプロパティに基づいてアクセスを制御するためにアクセスポイントポリシーで使用できるグローバル条件キーが用意されています。これらの条件キーは、次の表に示すように、特定の状況でのみリクエストコンテキストに含まれます。

IAM グローバル条件キーの詳細については、IAM ユーザーガイドのAWS 「 グローバル条件コンテキストキー」を参照してください。

シナリオ例

次のシナリオ例は、FSx for ONTAP ボリュームにアタッチされた Amazon S3 アクセスポイントの一般的な設定を示しています。各シナリオには、推奨されるネットワークオリジン、VPC エンドポイントタイプ、アクセスポイントポリシーが含まれます。

単一 VPC アクセス

ユースケース: 単一の VPC 内の Amazon EC2 インスタンス、Lambda 関数、または Amazon ECS タスクは、アクセスポイントにアクセスします。外部アクセスは必要ありません。

VPC ネットワークオリジンの場合:

VPC オリジン設定は、 aws:SourceVpcがバインドされた VPC と一致しないリクエストを効果的に拒否します。他の VPCs、インターネット、またはオンプレミスネットワークからのリクエストは拒否されます。Gateway または Interface の Amazon S3 VPC エンドポイントを使用できます。

アクセスポイントポリシー (VPC オリジン): VPC オリジンでは、ネットワーク制限が組み込まれています。アクセスポイントポリシーは、必要なアクセス許可を付与するだけで済みます。

{
    "Version": "2012-10-17", 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:role/my-app-role"},
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point",
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
            ]
        }
    ]
}

インターネットネットワークオリジンの場合:

インターネットオリジンでは、アクセスポイントポリシーaws:SourceVpcの条件 (明示的な拒否) を使用して VPC へのアクセスを制限します。がリクエストに入力されるようにaws:SourceVpc、VPC エンドポイントが必要です。

アクセスポイントポリシーの例 (インターネットオリジン): このポリシーには、VPC 条件を持つ許可と、VPC からではないリクエストの拒否の両方が含まれます。

{
    "Version": "2012-10-17", 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:role/my-app-role"},
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point",
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
            ],
            "Condition": {
                "StringEquals": {"aws:SourceVpc": "vpc-1a2b3c4d"}
            }
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point",
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
            ],
            "Condition": {
                "StringNotEquals": {"aws:SourceVpc": "vpc-1a2b3c4d"}
            }
        }
    ]
}

オンプレミスおよび VPC アクセス

ユースケース: オンプレミスユーザー (VPN または Direct Connect 経由) と VPC 内コンピューティングリソースの両方がアクセスポイントにアクセスします。すべてのトラフィックはプライベートのままです。

ゲートウェイエンドポイント (VPC 内トラフィック) とインターフェイスエンドポイント (オンプレミストラフィック) の両方が同じ VPC 内にあるため、どちらも VPC オリジン拒否条件を満たしています。

マルチ VPC アクセス

ユースケース: 複数の VPCsの発信者は、同じアクセスポイントにアクセスする必要があります。例えば、同じアカウント内の別々の VPCs 内のアプリケーションや、VPCs ピアリングまたは Transit Gateway を介して接続されている異なるアカウントの VPC などです。

マルチ VPC アクセスには、ポリシーベースのコントロールを使用するか、VPC オリジンネットワークの適用を使用するかに応じて、2 つのアプローチがあります。

オプション 1: 各 VPC にゲートウェイエンドポイントを持つインターネットオリジン

各 VPC には独自の Amazon S3 Gateway エンドポイントがあります。各 VPC の発信者は、リクエストaws:SourceVpcに入力されるローカルゲートウェイエンドポイントを介してアクセスポイントにアクセスします。アクセスポイントポリシーは、許可された VPC IDs。

このオプションは、各 VPC が独立して動作するため、セットアップが簡単になります。VPC ピアリングや Transit Gateway は必要ありません。VPCs を追加または削除するには、アクセスポイントポリシーを更新します。

オプション 2: 一元化されたインターフェイスエンドポイントを持つ VPC オリジン

1 つの VPC は Amazon S3 インターフェイスエンドポイントをホストし、アクセスポイントはその VPC にバインドされた VPC オリジンで作成されます。他の VPCsVPC ピアリングまたは Transit Gateway を介して Amazon S3 トラフィックをインターフェイスエンドポイントにルーティングします。すべてのリクエストは、バインドされた VPC のエンドポイントを介して到着するため、VPC オリジンの強制を満たします。

このオプションは、VPC オリジン制限をポリシーの変更でバイパスできないため、より強力な適用を提供します。ただし、VPC ピアリングまたは Transit Gateway 接続が必要であり、インターフェイスエンドポイントには時間単位と GB 単位の料金がかかります。インターフェイスエンドポイントの詳細については、AWS 「Amazon Simple Storage Service ユーザーガイド」の「PrivateLink for Amazon S3」を参照してください。

ネットワークアクセスの問題のトラブルシューティング

Amazon S3 アクセスポイントリクエストが失敗した場合、エラーメッセージは多くの場合、リクエストを拒否した認可レイヤーを示しません。一般的な問題を診断するには、次のガイダンスを使用します。

AccessDenied with "explicit deny in a resource-based policy"

このエラーは、複数のソースから発生する可能性があります。次のチェックを順番に実行します。

1. VPC オリジン拒否を確認する (VPC オリジンアクセスポイントのみ)

アクセスポイントに VPC ネットワークオリジンがある場合、 aws:SourceVpcがバインドされた VPC と一致しないリクエストを効果的に拒否します。以下を確認してください。

2。VPC エンドポイントポリシーを確認する

リクエストが VPC エンドポイントを通過する場合、エンドポイントのポリシーはアクセスポイントリソースに対する アクションを許可する必要があります。デフォルトのエンドポイントポリシーでは、すべてのリソースに対するすべてのアクションが許可されます。ポリシーの範囲を設定している場合は、アクセスポイント ARN が含まれていることを確認します。

3. アクセスポイントポリシーを確認する

アクセスポイントポリシーがリクエスト元のプリンシパルを許可していることを確認します。リクエストに一致する可能性のある条件を含む拒否ステートメントを確認します。

4. 発信者の IAM ID ポリシーを確認する

発信者の IAM ロールまたはユーザーには、アクセスポイント ARN で Amazon S3 アクションを実行するアクセス許可が必要です。

5。サービスコントロールポリシー (SCPs

アカウントが AWS Organizations 組織の一部である場合は、アクセスポイントでの Amazon S3 アクションを拒否する SCPs がないことを確認します。

オンプレミスの発信者は AccessDenied を取得しますが、VPC 内の発信者は成功します

これは通常、オンプレミストラフィックが VPC エンドポイント経由でルーティングされていないことを意味します。

アクセスポイントポリシー条件は効果がないように見える