Amazon S3 のセキュリティのベストプラクティス - Amazon Simple Storage Service
Amazon S3 のセキュリティベストプラクティスAmazon S3 のモニタリングと監査のベストプラクティス

Amazon S3 のセキュリティのベストプラクティス

Amazon S3 には、独自のセキュリティポリシーを策定および実装する際に考慮すべきさまざまなセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションに相当するものではありません。これらのベストプラクティスは顧客の環境に必ずしも適切または十分でない可能性があるので、処方箋ではなく、あくまで有用な検討事項とお考えください。

Amazon S3 のセキュリティベストプラクティス

以下は、セキュリティ問題の防止に役立つ Amazon S3 でのベストプラクティスです。

アクセスコントロールリスト (ACL) の無効化

Amazon S3 の最新のユースケースの大部分では、アクセスコントロールリスト (ACL) を使用する必要がなくなっています。そのため、オブジェクトごとに個別にアクセスを制御する必要がある特殊な状況を除き、ACL を無効にすることをお勧めします。バケットのすべてのオブジェクトの ACL を無効にして、所有権を取得するには、S3 オブジェクト所有権のバケット所有者の強制設定を適用します。ACL を無効にすると、別の AWS アカウント によってアップロードされたオブジェクトを含むバケットを簡単に維持できます。データのアクセスコントロールは、IAM ポリシー、S3 バケットポリシー、仮想プライベートクラウド (VPC) エンドポイントポリシー、AWS Organizations サービスコントロールポリシー (SCP) などのポリシーに基づいています。

ACL の無効化により、アクセス許可の管理と監査が簡素化されます。新しく作成されたバケットと既存のバケットの両方で ACL を無効にすることができます。既存のバケットに既にオブジェクトが含まれている場合、ACL を無効にすると、オブジェクトとバケット ACL はアクセス評価に含まれなくなり、ポリシーに基づいてアクセスが許可または拒否されます。

ACL を無効にする前に、バケットポリシーを確認して、アカウント外のバケットへのアクセス権を付与するすべての方法をカバーすることを確認することをお勧めします。バケット ACL をデフォルト (バケット所有者に完全制御) にリセットする必要があります。ACL を無効にすると、バケットは ACL を指定しない PUT リクエスト、またはバケット所有者のフルコントロール ACL (bucket-owner-full-control 既定の ACL またはこの ACL と同等の XML で表される形式など) を持つ PUT リクエストのみを受け入れます。バケット所有者のフルコントロール ACL をサポートする既存のアプリケーションには影響はありません。他の ACL (特定の AWS アカウント へのカスタム許可など) を含む PUT リクエストは失敗し、AccessControlListNotSupported エラーコードを含む 400 エラーを返します。

詳細については、「オブジェクトの所有権の制御とバケットの ACL の無効化。」を参照してください。

Amazon S3 バケットに正しいポリシーが使用され、バケットが公開されていないことを確認する

インターネット上のだれもがお客様の S3 バケットを読み書きできるように明示的にリクエストしない限り、S3 バケットが非公開であることを確認する必要があります。以下に示しているのは、実行できるいくつかのステップです。

  • Amazon S3 のパブリックアクセスのブロックを使用します。Amazon S3 パブリックアクセスブロックを使用すると、アカウント管理者とバケット所有者は、リソースの作成方法に関係なく、Amazon S3 リソースへのパブリックアクセスを制限するための一元管理を簡単に設定できます。詳細については、Amazon S3 ストレージへのパブリックアクセスのブロック を参照してください。

  • プリンシパル「*」(つまり任意のユーザー) などのワイルドカードアイデンティティを許可する、またはワイルドカードアクション「*」を許可する (つまり、任意のユーザーが Amazon S3 バケットで任意のアクションを実行できる) Amazon S3 バケットポリシーを特定します。

  • 同様に、「全員」または「任意の認証済み AWS ユーザー」への読み取り、書き込み、またはフルアクセスを許可する Amazon S3 バケットアクセスコントロールリスト (ACL) に留意します。

  • ListBuckets API を使用して、すべての Amazon S3 バケットをスキャンします。その後、GetBucketAcl、GetBucketWebsite、GetBucketPolicy を使用して、アクセスコントロールと設定がコンプライアンス要件を満たしているかどうかを判断します。

  • AWS Trusted Advisor を使用して、Amazon S3 の実装を検査します。

  • s3-bucket-public-read-prohibited および s3-bucket-public-write-prohibited マネージド AWS Config Rules を使用する継続的な発見的統制の実装を検討してください。

詳細については、Amazon S3 での Identity and Access Management を参照してください。

最小特権アクセスの実装

アクセス許可を付与する場合、どのユーザーにどの Amazon S3 リソースに対するアクセス許可を付与するかは、ユーザーが決定します。つまり、該当リソースに対して許可する特定のアクションを有効にするということです。このため、タスクの実行に必要なアクセス許可のみを付与する必要があります。最小限の特権アクセスの実装は、セキュリティリスクはもちろん、エラーや悪意ある行動によってもたらされる可能性のある影響を減らす上での基本となります。

以下のツールは、最小限の特権アクセスを実装するために使用できます。

上記のメカニズムを採用する場合に何を考慮すべきかに関するガイダンスについては、アクセスポリシーのガイドライン を参照してください。

Amazon S3 アクセスを必要とするアプリケーションと AWS のサービスに IAM ロールを使用する

Amazon EC2 または他の AWS のサービス上のアプリケーションが Amazon S3 リソースにアクセスするためには、AWS API リクエストに有効な AWS 認証情報が含まれている必要があります。AWS 認証情報を、アプリケーションまたは Amazon EC2 インスタンスに直接保存しないでください。これらは自動的にローテーションされない長期的な認証情報であり、漏洩するとビジネスに大きな影響が及ぶ場合があります。

代わりに、IAM ロールを使用して、Amazon S3 にアクセスする必要があるアプリケーションまたはサービスの一時的な認証情報を管理することをおすすめします。ロールを使用する場合は、Amazon EC2 インスタンスまたは AWS のサービス (AWS Lambda など) に長期の認証情報 (ユーザー名とパスワード、アクセスキーなど) を配布する必要はありません。ロールは、アプリケーションが他の AWS リソースの呼び出しを行うときに使用できる一時的な許可を付与します。

詳細については、IAM ユーザーガイドにある下記のトピックを参照してください。

保管時のデータ暗号化の検討

Amazon S3 で保管時のデータを保護するには、次のようなオプションがあります。

  • サーバー側の暗号化を使用する – オブジェクトをデータセンター内のディスクに保存する前に暗号化し、オブジェクトをダウンロードするときに復号するように Amazon S3 にリクエストします。サーバー側の暗号化は、データ自体を保存するメカニズムとは異なるメカニズムで保存されているキーを使用してデータを暗号化することで、データへのリスクを軽減するのに役立ちます。

    Amazon S3 には、次のサーバー側の暗号化オプションがあります。

    • Amazon S3 が管理するキーによるサーバー側の暗号化 (SSE-S3)

    • AWS Key Management Service に保存されている KMS キーによるサーバー側の暗号化 (SSE-KMS)。

    • お客様が指定したキーによるサーバー側の暗号化 (SSE-C)。

    詳細については、サーバー側の暗号化を使用したデータの保護 を参照してください。

  • クライアント側の暗号化 – クライアント側でデータを暗号化し、暗号化したデータを Amazon S3 にアップロードします。この場合、暗号化プロセス、暗号化キー、関連ツールはお客様が管理してください。サーバー側の暗号化と同様に、クライアント側の暗号化は、データ自体を保存するメカニズムとは異なるメカニズムで保存されているキーを使用してデータを暗号化することで、リスクを軽減するのに役立ちます。

    Amazon S3 は複数のクライアント側の暗号化オプションを提供します。詳細については、クライアント側の暗号化を使用したデータの保護 を参照してください。

送信時のデータの暗号化を強制する

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。Amazon S3 バケットポリシーで aws:SecureTransport 条件を使用して、HTTPS (TLS) を介した暗号化接続のみを許可してください。

また、s3-bucket-ssl-requests-only マネージド AWS Config ルールを使用する継続的な発見的統制の実装を検討してください。

S3 オブジェクトロックの検討

S3 オブジェクトロックの使用 では、"Write Once Read Many" (WORM) モデルを使用してオブジェクトを保存できます。S3 オブジェクトロックは、データの誤った削除や不適切な削除を防ぐのに役立ちます。例えば、AWS CloudTrail ログを保護するために S3 オブジェクトロックを使用できます。

バージョニングの有効化

バージョニングとは、同じバケット内でオブジェクトの複数のバリアントを保持する手段です。バージョニングを使用して、Amazon S3 バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを、格納、取得、復元することができます。バージョニングを使用すれば、意図しないユーザーアクションからもアプリケーション障害からも、簡単に復旧できます。

また、s3-bucket-versioning-enabled マネージド AWS Config ルールを使用する継続的な発見的統制の実装を検討してください。

詳細については、S3 バケットでのバージョニングの使用 を参照してください。

Amazon S3 クロスリージョンレプリケーションの検討

Amazon S3 はデフォルトで地理的に異なる複数のアベイラビリティーゾーンにデータを保存しますが、コンプライアンス要件によっては、さらに離れた場所にデータを保存することが要求される場合があります。クロスリージョンレプリケーション (CRR) は、データを遠く離れた AWS リージョンにレプリケートできるため、そのような要件を満たすのに役立ちます。CRR では、異なる AWS リージョンのバケット間でオブジェクトを自動的に非同期コピーできます。詳細については、オブジェクトのレプリケーション を参照してください。

注記

CRR では、ソースとターゲットの両方の S3 バケットでバージョニングが有効になっている必要があります。

また、s3-bucket-replication-enabled マネージド AWS Config ルールを使用する継続的な発見的統制の実装を検討してください。

Amazon S3 アクセス用の VPC エンドポイントの検討

Amazon S3 の VPC エンドポイントは、Amazon S3 への接続のみを許可する Virtual Private Cloud (VPC) 内の論理エンティティです。Amazon S3 バケットポリシーを使用して、特定の VPC エンドポイントまたは特定の VPC からバケットへのアクセスを制御できます。VPC エンドポイントは、トラフィックが潜在的にオープンインターネットを通過してオープンインターネット環境にさらされるのを防ぐのに役立ちます。

Amazon S3 の VPC エンドポイントは、Amazon S3 データへのアクセスを制御するいくつかの方法を提供します。

  • 特定の VPC エンドポイントを通じて許可されるリクエスト、ユーザー、またはグループを管理できます。

  • S3 バケットポリシーを使用して、S3 バケットへのアクセスが可能な VPC または VPC エンドポイントをコントロールできます。

  • インターネットゲートウェイのない VPC を使用すると、データの流出を防ぐのに役立ちます。

詳細については、「バケットポリシーを使用した VPC エンドポイントからのアクセスコントロール」を参照してください。

マネージド AWS のサービスを利用して、実行可能な調査結果を AWS アカウント で取得する

マネージド AWS のサービスを有効にして、複数のアカウントで統合できます。調査結果を受け取ったら、インシデント対応ポリシーに従ってアクションを実行してください。結果ごとに、必要な対応アクションを決定します。

ご使用の AWS アカウント で実用的な調査結果を得るには、次のマネージド AWS のサービスのいずれかを有効にします。

  • AWS Security Hub。複数の AWS アカウント にわたるセキュリティとコンプライアンスのステータスを集約して可視化します。Security Hub を使用すると、セキュリティのベストプラクティスチェックを実行したり、アラートを集約したり、修復を自動化したりできます。カスタムアクションを作成できます。これにより、お客様は特定の結果に対して特定の対応または修復アクションを手動で呼び出すことができます。その後、カスタムアクションを特定のイベントパターンとして Amazon CloudWatch Events に送信できます。これにより、これらのアクションをリッスンして Lambda 関数や Amazon SQSqueue などのターゲットサービスに送信する CloudWatch イベントルールを作成できます。その後、調査結果を Amazon S3 バケットにエクスポートし、AWS のサービス間における複数のユースケースに合わせて標準化された形式で共有できます。

  • Amazon GuardDuty。S3 バケット内のデータの潜在的なセキュリティリスクを特定するために、オブジェクトレベルの API オペレーションをモニタリングします。Amazon GuardDuty は、CloudTrail 管理イベントと CloudTrail Amazon S3 データイベントを分析して、Amazon S3 リソースに対する脅威をモニタリングします。これらのデータソースは、さまざまな種類のアクティビティをモニタリングします。例えば、Amazon S3 のデータイベントには、GetObject、ListObjects、PutObject などのオブジェクトレベルの API オペレーションが含まれます。詳細については、「Amazon GuardDuty ユーザーガイド」の「Amazon GuardDuty での Amazon S3 の保護」を参照してください。

  • AWS Identity and Access Management アクセスアナライザー。社内 AWS リソースへのアクセスを確認し、AWS アカウント 以外のどこでアクセスを共有しているかを検証します。Access Analyzer for Amazon S3 は、インターネットの任意のユーザーや他の AWS アカウント (組織外のアカウントを含む) にアクセスを許可するようにバケットが設定された場合、警告します。パブリックバケットまたは共有バケットごとに、パブリックアクセスや共有アクセスのソースとレベルを示す調査結果が送信されます。例えば、Access Analyzer for Amazon S3 は、バケットのアクセスコントロールリスト (ACL)、バケットポリシー、マルチリージョンアクセスポイントポリシー、またはアクセスポイントポリシーを通じて、バケットに読み取りまたは書き込みのアクセス権が提供されていることを示す場合があります。この情報を用いて、迅速で正確な是正処置を講じ、バケットへのアクセスを意図したとおりに復元できます。詳細については、「Amazon S3 のアクセスアナライザーを使用したバケットアクセスの確認」を参照してください。

Amazon S3 のモニタリングと監査のベストプラクティス

以下は、潜在的なセキュリティ上の弱点とインシデントを検出するために役立つ Amazon S3 でのベストプラクティスです。

すべての Amazon S3 バケットを特定して監査する

IT アセットの特定はガバナンスとセキュリティの重要な側面です。セキュリティの状態を評価し、潜在的な弱点に対処するには、すべての Amazon S3 リソースが見えていなければなりません。

タグエディターを使用してセキュリティまたは監査で注意を要するリソースを識別してから、それらのタグを、リソースを検索する必要があるときに使用します。詳細については、タグ付けするリソースの検索 を参照してください。

Amazon S3 インベントリを使用して、ビジネス、コンプライアンス、規制上のニーズに関するオブジェクトのレプリケーションと暗号化状況を監査、報告します。詳細については、Amazon S3 インベントリ を参照してください。

Amazon S3 リソースのリソースグループを作成します。詳細については、AWS Resource Groups とは を参照してください。

AWS モニタリングツールによるモニタリングの実装

モニタリングは、Amazon S3 および AWS ソリューションの信頼性、セキュリティ、可用性、パフォーマンスを維持する上で重要なエレメントです。AWS では、Amazon S3 およびその他の AWS のサービスをモニタリングするのに役立つツールとサービスを提供しています。例えば、Amazon S3 の CloudWatch メトリクス (特に、PutRequests、GetRequests、4xxErrors、DeleteRequests) をモニタリングできます 。詳細については、Amazon CloudWatch によるメトリクスのモニタリング および Amazon S3 のモニタリング を参照してください。

別の例については、例: Amazon S3 バケットのアクティビティ を参照してください。この例では、バケットのポリシー、バケットのライフサイクル、またはバケットのレプリケーションの PUT または DELETE に対して、あるいはバケット ACL の PUT に対して Amazon S3 API コールが行われたときにトリガーされる Amazon CloudWatch アラームを作成する方法について説明します。

Amazon S3 サーバーアクセスログを有効にする

サーバーアクセスのログには、バケットに対するリクエストの詳細が記録されます。サーバーアクセスログは、セキュリティやアクセス監査の参考になることがあり、顧客基盤について知り、Amazon S3 の請求を理解するのに役立ちます。サーバーアクセスログ記録を有効にする手順については、サーバーアクセスログを使用したリクエストのログ記録 を参照してください。

また、s3-bucket-logging-enabled マネージド AWS Config ルールを使用する継続的な発見的統制の実装を検討してください。

使用AWS CloudTrail

AWS CloudTrail は、Amazon S3 のユーザー、ロール、または AWS のサービスによって実行されたアクションのレコードを提供します。CloudTrail で収集された情報を使用して、Amazon S3 に対するリクエスト、リクエスト元の IP アドレス、リクエストの実行者、リクエスト日時などの詳細を把握できます。例えば、データアクセスに影響する PUT アクションの CloudTrail エントリ、特に PutBucketAcl、PutObjectAcl、PutBucketPolicy、PutBucketWebsite を識別できます。AWS アカウントをセットアップすると、CloudTrail はデフォルトで有効になっています。CloudTrail コンソールで最近のイベントを確認できます。Amazon S3 バケットのアクティビティとイベントの継続的なレコードを作成するには、CloudTrail コンソールで証跡を作成できます。詳細については、https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html ユーザーガイドのAWS CloudTrail証跡へのデータイベントのログ記録 を参照してください。

証跡を作成する際に、データイベントをログ記録するように CloudTrail を設定できます。データイベントは、リソース上またはリソース内で実行されたリソースオペレーションのレコードです。Amazon S3 では、データイベントは、個々のバケットのオブジェクトレベルの API アクティビティを記録します。CloudTrail は、GetObject、DeleteObject、PutObject などの Amazon S3 オブジェクトレベルの API オペレーションのサブセットをサポートしています。CloudTrail と Amazon S3 との連携の詳細については、AWS CloudTrail を使用した Amazon S3 API コールのログ記録 を参照してください。Amazon S3 コンソールでは、S3 バケットとオブジェクトの CloudTrail イベントログ記録の有効化 に S3 バケットを設定することもできます。

AWS Config に用意されている管理ルール (cloudtrail-s3-dataevents-enabled) を使用すると、少なくとも 1 つの CloudTrail 証跡が S3 バケットのデータイベントのログに記録していることを確認できます。詳細については、cloudtrail-s3-dataevents-enabled デベロッパーガイドのAWS Config を参照してください。

Enable AWS Config (Gems の有効化)

このトピックに示しているベストプラクティスのいくつかでは、AWS Config ルールを作成することを提案しています。AWS Config では、AWS リソースの設定を評価、監査、診断できます。AWS Config では、リソースの設定をモニタリングし、目的とする安全な設定に対して、記録された設定を評価できます。AWS Config を使用すると、AWS リソース間の設定や関連性の変更を確認し、詳細なリソース設定履歴を調べ、社内ガイドラインで指定された設定に対して、全体的なコンプライアンスを確認できます。これにより、コンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを簡素化できます。詳細については、AWS Config デベロッパーガイドのコンソールを使用した AWS Config の設定 を参照してください。記録するリソースタイプを指定するときは、必ず Amazon S3 リソースを含めてください。

パブリックアクセスを許可する Amazon S3 バケットを AWS Config でモニタリングおよび応答する方法の例については、AWS セキュリティブログの How to Use AWS Config to Monitor for and Respond to Amazon S3 Buckets Allowing Public Access を参照してください。

Amazon S3 で Amazon Macie の使用を検討する

Amazon Macie は、データセキュリティおよびデータプライバシーサービスであり、機械学習とパターンマッチングを使用して、AWS 環境内の機密データを検出、モニタリング、保護するのに役立ちます。Macie は、組織が Simple Storage Service (Amazon S3) に保存している個人を特定できる情報 (PII) や財務データなどの機密データを詳細に把握できるよう、そのようなデータの検出を自動化します。

Macie は S3 バケットのインベントリも提供し、セキュリティとアクセスコントロールのためにそれらのバケットを自動的に評価およびモニタリングします。Macie は、ユーザーのデータのセキュリティまたはプライバシーに関する機密データまたは潜在的な問題を検出した場合、必要に応じて確認および修正するための詳細な調査結果を作成します。詳細については、「Amazon Macie とは」を参照してください。

AWS セキュリティアドバイザリをモニタリングする

AWS アカウント について Trusted Advisor に投稿されたセキュリティ勧告を定期的に確認してください。特に、「オープンアクセス許可」のある Amazon S3 バケットに関する警告に注意してください。これは、describe-trusted-advisor-checks を使用してプログラムにより行うことができます。

さらに、各 AWS アカウント に登録されているメインの E メールアドレスを注意してモニタリングしてください。AWS は、この E メールアドレスを使用して、お客様に影響を与える可能性のあるセキュリティ問題が新たに発生した場合に連絡します。

広範な影響を与える AWS の運用上の問題は AWS Service Health Dashboard に投稿されます。運用上の問題は Personal Health Dashboard を介して個々のアカウントにも投稿されます。詳細については、AWS Health のドキュメント を参照してください。