274-AWS SAP AWS 「理論・実践・一問道場」署名付きURL

type

status

date

slug

summary

理論

署名付きURL（pre-signed URL）は、AWSリソースへのアクセスを提供するために、特定のユーザーまたはサービスが発行します。基本的には、署名付きURLを発行するのはそのリソースへのアクセス権限を持っているAWSアカウントまたはサービスです。

誰が署名付きURLを発行するか？

署名付きURLを発行するのはAWSアカウントのユーザーまたはサービス:

署名付きURLは、リソースにアクセスする権限を持つAWSユーザーまたはサービスが発行します。

例えば、S3バケットのオブジェクトにアクセスする権限を持つIAMロールやIAMユーザー、またはその権限を持つAWSサービス（例えば、AWS Lambdaなど）が署名付きURLを発行します。

署名付きURLを発行するプロセス:

AWSアカウントがAWS SDKやAWS CLIを使用して、署名付きURLを生成するためのAPIリクエストをS3に送信します。

S3は署名付きURLを発行するのではなく、リクエストに基づいて署名付きURLを生成するために必要な情報を提供します。つまり、署名付きURLの「署名部分」を作成するためには、アクセス権限を持つIAMユーザーまたはサービスが署名を行い、それに基づいて一時的なURLが生成されます。

発行者:

実際に署名付きURLを発行するのは、権限を持ったIAMユーザーやサービス（例：AWS Lambda）が行います。これにより、指定されたオブジェクトへのアクセスを制御し、制限された期間内でそのオブジェクトにアクセスすることが可能になります。

署名付きURL発行の流れ（具体的な例）

IAMユーザーやサービスがリクエスト：

署名付きURLを発行したいIAMユーザーまたはサービス（例えば、AWS Lambda）が、get_object 操作をS3バケットの対象オブジェクトに対してリクエストします。

署名の生成：

このリクエストは、IAMユーザーまたはサービスがAWS SDKやCLIを使って行い、そのリクエストに基づいて署名が生成されます。署名は、そのユーザーまたはサービスが対象のリソースへのアクセス権限を持っていることを確認するものです。

署名付きURLの発行：

最終的に、署名付きURLが作成され、そのURLを利用することで、指定されたオブジェクトにアクセスできるようになります。署名付きURLには、リクエストが有効な期間や操作の種類（GETやPUT）が含まれています。

結論

署名付きURLを発行するのは、リソース（例：S3オブジェクト）に対するアクセス権限を持つIAMユーザーやサービスです。そのユーザーやサービスが署名を行い、署名付きURLを生成します。S3自体は署名付きURLを発行しませんが、署名付きURLがアクセスを可能にするために必要な情報を提供します。

実践

略

一問道場

会社は、レポートを生成し、それらをAmazon S3バケットに保存するアプリケーションを持っています。ユーザーがレポートにアクセスすると、アプリケーションは署名付きURLを生成して、ユーザーがレポートをダウンロードできるようにします。会社のセキュリティチームは、ファイルが公開されており、誰でも認証なしでダウンロードできることを発見しました。会社は、新しいレポートの生成を停止し、問題が解決されるまでそのままにしています。

このセキュリティの問題をアプリケーションの通常のワークフローに影響を与えることなく、即座に修正するためのアクションのセットはどれですか？

A. 認証されていないユーザーに対してすべてを拒否するポリシーを適用するAWS Lambda関数を作成します。そのLambda関数を実行するスケジュールイベントを設定します。

B. AWS Trusted Advisorのバケット権限チェックを確認し、推奨されるアクションを実施します。

C. スクリプトを実行して、バケット内のすべてのオブジェクトにプライベートACLを設定します。

D. Amazon S3の「ブロックパブリックアクセス」機能を使用して、バケットの「IgnorePublicAcls」オプションをTRUEに設定します。

解説

この問題の解決策は、S3バケット内のオブジェクトが公開されないように設定を変更することです。各選択肢について解説します。

A. AWS Lambda関数を作成し、認証されていないユーザーに対してすべてを拒否するポリシーを適用する

Lambda関数でポリシーを適用する方法は、問題の根本的な解決策としては適切ですが、この方法は複雑であり、すぐに実行可能ではありません。Lambda関数の実装やスケジュールイベントの設定に時間がかかるため、即時の修正には向いていません。

B. AWS Trusted Advisorのバケット権限チェックを確認し、推奨されるアクションを実施する

Trusted Advisorを使ってバケット権限を確認するのは有効ですが、具体的な修正手段が明示されていないため、この方法だけでは即座に問題を解決することは難しいです。

C. スクリプトを実行して、バケット内のすべてのオブジェクトにプライベートACLを設定する

プライベートACLを設定することで、S3バケット内のオブジェクトへのアクセスを制限できますが、これは一時的な対応であり、継続的に管理する方法としては適切ではないかもしれません。手動でスクリプトを実行しなければならず、管理が複雑になる可能性があります。

D. Amazon S3の「ブロックパブリックアクセス」機能を使用して、バケットの「IgnorePublicAcls」オプションをTRUEに設定する

最適な解決策です。 S3の「ブロックパブリックアクセス」機能を使用すると、バケットやオブジェクトに対する公開アクセスを一時的かつ即座にブロックできます。IgnorePublicAclsオプションをTRUEに設定することで、バケット内の既存の公開設定も無効化され、セキュリティが強化されます。アプリケーションの正常な動作に影響を与えることなく、すぐに問題を修正できます。

結論：

Dは、即座にセキュリティ問題を解決し、アプリケーションの正常なワークフローを維持できる最も簡単で効果的な方法です。