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

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

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

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

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

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

S3 オブジェクト所有権は、Amazon S3 バケットレベルの設定で、バケットにアップロードされたオブジェクトの所有権を制御し、ACL を無効または有効にするのに使用できます。デフォルトでは、オブジェクト所有権は[バケット所有者の強制] 設定に設定され、すべての ACL は無効になっています。ACL が無効になっている場合、バケット所有者はバケット内のすべてのオブジェクトを所有し、アクセス管理ポリシーのみを使用してデータへのアクセスを管理します。

Amazon S3 の最近のユースケースの大部分ではアクセスコントロールリスト (ACL) を使用する必要がなくなりました。オブジェクトごとに個別に制御する必要があるまれな状況を除き、ACL を無効にすることをお勧めします。バケットのすべてのオブジェクトの ACL を無効にして、所有権を取得するには、S3 オブジェクト所有権のバケット所有者の強制設定を適用します。ACL を無効にすると、別の AWS アカウント によってアップロードされたオブジェクトを含むバケットを簡単に維持できます。

ACL が無効になっている場合、データのアクセスコントロールは次のようなポリシーに基づきます。

  • AWS Identity and Access Management IAM ユーザーポリシー

  • S3 バケットポリシー

  • 仮想プライベートクラウド (VPC) エンドポイントポリシー

  • AWS Organizations サービスコントロールポリシー (SCP)

  • AWS Organizations リソースコントロールポリシー (RCP)

ACL の無効化により、アクセス許可の管理と監査が簡素化されます。デフォルトでは、ACL は無効になっています。既存のバケットに対して ACL を無効にすることもできます。既存のバケットに既にオブジェクトが含まれている場合、ACL を無効にすると、オブジェクトとバケット ACL はアクセス評価プロセスの一部ではなくなります。この場合、アクセスはポリシーに基づいて許可または拒否されます。

ACL を無効にする前に、次のことを確認してください。

  • バケットポリシーを確認して、アカウント外のバケットへのアクセス権を付与するすべての方法をカバーすることを確認します。

  • バケット ACL をデフォルト (バケット所有者にフルコントロール) にリセットします。

ACL を無効にすると、以下の動作が発生します。

  • バケットは、ACL を指定しない PUT リクエスト、またはバケット所有者のフルコントロール ACL を含む PUT リクエストのみを受け付けます。これらの ACL には、bucket-owner-full-control 既定 ACL または XML で表現された ACL と同等の形式が含まれます。

  • バケット所有者の完全制御 ACL をサポートする既存のアプリケーションには影響はありません。

  • 他の ACL (例えば、特定 AWS アカウント のへのカスタム許可) を含む PUT 要求は失敗し、AccessControlListNotSupported エラーコードとともに HTTPHTTP ステータスコード 400 (Bad Request) を返します。

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

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

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

  • S3 パブリックアクセスのブロックを使用します。S3 パブリックアクセスブロックでは、Amazon S3 リソースへのパブリックアクセスを制限する一元管理を簡単に設定することができます。これらの一元管理は、リソースの作成方法に関係なく適用されます。詳細については、「Amazon S3 ストレージへのパブリックアクセスのブロック」を参照してください。

  • "Principal": "*" (事実上「誰でも」という意味) などのワイルドカード ID を許可する 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 ルール を使用して、継続的な検出コントロールを実施することを検討します。

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

最小特権アクセスの実装

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

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

上記のメカニズムを採用する場合に何を考慮すべきかに関するガイダンスについては、Amazon S3 用 Identity and Access Management を参照してください。

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 バケットにはデフォルトで暗号化が設定されており、S3 バケットにアップロードされたすべての新しいオブジェクトは保存時に自動的に暗号化されます。Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) は、Amazon S3 のすべてのバケットでのデフォルトの暗号化設定です。別のタイプの暗号化を使用するには、S3 PUT リクエストで使用するサーバー側の暗号化のタイプを指定するか、宛先バケットにデフォルトの暗号化設定を設定できます。

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

    • AWS Key Management Service (AWS KMS) キー (SSE-KMS) によるサーバー側の暗号化

    • AWS Key Management Service (AWS KMS) キーによる二層式サーバー側の暗号化 (DSSE-KMS)

    • 顧客提供のキーを用いたサーバー側の暗号化 (SSE-C)。

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

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

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

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

HTTPS (TLS) を使用すると、潜在的な攻撃者が中間者攻撃または同様の攻撃を使用してネットワークトラフィックを盗聴または操作することを防止できます。Amazon S3 バケットのポリシーで aws:SecureTransport 条件を使用して、HTTPS (TLS) 経由での暗号化された接続のみを許可することをお勧めします。詳細については、S3 バケットポリシーの例「HTTP または HTTPS リクエストに基づくアクセス管理」を参照してください。HTTP リクエストを拒否するだけでなく、Amazon CloudWatch アラームを tlsDetails.tlsVersion NOT EXISTS に設定して、コンテンツに HTTP アクセスが試行された場合に警告することをお勧めします。Amazon CloudWatch アラームの設定方法の詳細については、「AWS CloudTrail User Guide」の「Creating CloudWatch alarms for CloudTrail events: examples」と「CloudTrail record contents」を参照してください。

重要

AWS はパブリックに信頼された証明書の固定をサポートしていないため、アプリケーションでは Amazon S3 TLS 証明書を固定しないことをお勧めします。S3 は証明書を自動的に更新し、更新は証明書の有効期限が切れる前に行われます。証明書の更新では、新しいパブリックキーとプライベートキーのペアが生成されます。新しいパブリックキーで最近更新された S3 証明書を固定する場合、アプリケーションが新しい証明書を使用するまで S3 に接続できません。

また、s3-bucket-ssl-requests-only マネージド AWS Config ルールを使用した継続的な検出コントロールの実装を検討してください。

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

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

詳細については、「S3 Object Lock を使用したオブジェクトのロック」を参照してください。

S3 バージョニングの有効化

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

また、s3-bucket-versioning-enabled マネージド AWS Config ルールを使用した継続的な検出コントロールの実装を検討してください。

詳細については、「S3 バージョニングによる複数のバージョンのオブジェクトの保持」を参照してください。

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

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

注記

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

また、s3-bucket-replication-enabled マネージド AWS Config ルールを使用した継続的な検出コントロールの実装を検討してください。

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

Amazon S3 の 仮想プライベートクラウド (VPC) エンドポイントは、Amazon S3 への接続のみを許可する VPC 内の論理エンティティです。VPC エンドポイントは、トラフィックがオープンインターネットを通過するのを防ぐのに役立ちます。

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

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

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

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

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

マネージド AWS セキュリティサービスを使用したデータセキュリティの監視

いくつかのマネージド AWS セキュリティサービスは、Amazon S3 データのセキュリティとコンプライアンスのリスクを特定、評価、監視するのに役立ちます。これらのサービスは、こうしたリスクからデータを保護するのにも役立ちます。これらのサービスには、単一の AWS アカウント Amazon S3 リソースから数千のアカウントにまたがる組織向けのリソースに拡張できるように設計された、自動検知、モニタリング、保護機能が含まれます。

詳細については、「マネージド AWS セキュリティサービスによるデータセキュリティのモニタリング」を参照してください。

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

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

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

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

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

  • S3 インベントリを使用して、ビジネス、コンプライアンス、および規制上のニーズに応じて、オブジェクトのレプリケーションと暗号化のステータスを監査し、レポートします。詳細については、「S3 インベントリを使用したデータのカタログ化と分析」を参照してください。

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

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

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

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

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

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

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

AWS CloudTrail の使用

AWS CloudTrail は、Amazon S3 のユーザー、ロール、または AWS のサービス によって実行されたアクションのレコードを提供します。CloudTrail によって収集されたデータを使用して、以下の情報を判断できます。

  • Amazon S3 に対して行われたリクエスト

  • リクエストが行われた IP アドレス

  • リクエストを行ったユーザー

  • リクエストが行われた時間

  • リクエストに関するその他の詳細

例えば、データアクセスに影響する PUT アクション (特に PutBucketAcl、PutObjectAcl、PutBucketPolicy および PutBucketWebsite) の CloudTrail エントリを特定できます。

AWS アカウントをセットアップすると、CloudTrail はデフォルトで有効になっています。CloudTrail コンソールで最近のイベントを確認できます。Amazon S3 バケットのアクティビティとイベントの継続的なレコードを作成するには、CloudTrail コンソールで証跡を作成できます。詳細については、「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 を参照してください。

AWS Config の有効化

このトピックに示すベストプラクティスのいくつかでは、AWS Config ルールの作成を提案しています。AWS Config では、AWS リソースの設定を評価、監査、診断するのに役立ちます。AWS Config では、リソースの設定をモニタリングし、目的とする安全な設定に対して、記録された設定を評価できます。AWS Config では、次のことを実行できます。

  • 設定の変更と AWS リソース間の関係を確認します。

  • 詳細なリソース設定履歴の調査

  • 内部ガイドラインに指定されている設定に対して全体的なコンプライアンスを決定します。

AWS Config を使用すると、コンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを簡素化できます。詳細については、AWS Config デベロッパーガイドのコンソールを使用した AWS Config の設定 を参照してください。記録するリソースタイプを指定するときは、必ず Amazon S3 リソースを含めてください。

重要

AWS Config マネージドルールは Amazon S3 リソースを評価する際に汎用バケットのみをサポートします。AWS Config ディレクトリバケットの設定変更は記録されません。詳細については、「AWS Config デベロッパーガイド」の「AWS Config マネージドルール」と「AWS Config マネージドルールリスト」を参照してください。

AWS Config を使用する方法の例については、「AWS セキュリティブログ」の「パブリックアクセスを許可する Amazon S3 バケットを AWS Config でモニタリングおよび応答する方法」を参照してください。

S3 ストレージレンズの使用

S3 ストレージレンズは、オブジェクトストレージの使用状況とアクティビティを組織全体で可視化するために使用できるクラウドストレージ分析機能です。また、S3 Storage Lens は、メトリクスを分析して、ストレージコストを最適化し、データ保護に関するベストプラクティスを適用するために使用できるコンテキストに応じた推奨事項を提供します。

S3 Storage Lens で、組織全体でどれだけのストレージがあるか、または最も急速に成長しているバケットとプレフィックスは何かなどの、要約されたインサイトを生成できます。S3 Storage Lens メトリクスを使用して、コスト最適化の機会を特定し、データ保護とアクセス管理のベストプラクティスを実装し、アプリケーションワークロードのパフォーマンスを向上させることができます。

例えば、S3 ライフサイクルルールがないバケットを特定して、7 日以上経過した不完全なマルチパートアップロードを中止できます。また、S3 レプリケーションや S3 バージョニングの使用など、データ保護のベストプラクティスに従っていないバケットを特定することもできます。詳細については、「Amazon S3 ストレージレンズについて」を参照してください。

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

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

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

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

マネージド AWS セキュリティサービスによるデータセキュリティのモニタリング

いくつかのマネージド AWS セキュリティサービスは、Amazon S3 データのセキュリティとコンプライアンスのリスクを特定、評価、監視するのに役立ちます。また、こうしたリスクからデータを保護するのにも役立ちます。これらのサービスには、単一の AWS アカウント から数千の AWS アカウント にまたがる組織向けのリソースに拡張できるように設計された、自動検知、モニタリング、保護機能が含まれます。

AWS 検出および対応サービスを使うと、潜在的なセキュリティ設定ミス、脅威、または予期しない動作を特定できるため、環境内の不正または悪意のある可能性があるアクティビティに対して迅速に対応できます。AWS データ保護サービスは、データ、アカウント、ワークロードをモニタリングし、不正アクセスから保護するのに役立ちます。また、Amazon S3 のデータ資産内で個人を特定できる情報 (PII) などの機密データを発見するのにも役立ちます。

データセキュリティとコンプライアンスのリスクを特定して評価するのをサポートするため、マネージド AWS セキュリティサービスでは、検出結果を生成して、Amazon S3 データに関する潜在的なセキュリティイベントや問題を通知します。検出結果には関連する詳細は、インシデント対応のワークフローとポリシーに従ってこれらのリスクを調査、評価、対処するために使用できます。各サービスを使用して、検出結果データに直接アクセスできます。また、セキュリティインシデントやイベント管理システム (SIEM) など、他のアプリケーション、サービス、システムにデータを送信することもできます。

Amazon S3 データのセキュリティをモニタリングするには、これらのマネージド AWS セキュリティサービスの使用を検討してください。

Amazon GuardDuty

Amazon GuardDuty は、悪意のあるアクティビティがないか継続的に AWS アカウント をモニタリングし、詳細なセキュリティ検出結果を提供する脅威検知サービスです。

GuardDuty の S3 保護機能を使用すると、Amazon S3 リソースの AWS CloudTrail 管理イベントとデータイベントを分析するように GuardDuty を設定できます。それにより、GuardDuty は、悪意のあるアクティビティや疑わしいアクティビティについてこれらのイベントをモニタリングします。分析を行い、潜在的なセキュリティリスクを特定するため、GuardDuty は脅威インテリジェンスフィードと機械学習を使用しています。

GuardDuty では、Amazon S3 リソースについてさまざまな種類のアクティビティをモニタリングできます。例えば、Amazon S3 の CloudTrail 管理イベントには、ListBuckets、DeleteBucket、PutBucketReplication など、バケットレベルのオペレーションが含まれます。Amazon S3 のデータイベントには、GetObject、ListObjects、PutObject などのオブジェクトレベルのオペレーションが含まれます。GuardDuty が異常なアクティビティや潜在的に悪意のあるアクティビティを検出すると、検出結果を生成してユーザーに通知します。

詳細については、「Amazon GuardDuty ユーザーガイド」の「Amazon GuardDuty での Amazon S3 の保護」を参照してください。

Amazon Detective

Amazon Detective は調査プロセスを簡素化し、セキュリティ調査をより迅速かつ効果的に実施できるようにします。Detective が提供する事前に作成されたデータ集計、要約、およびコンテキストは、考えられるセキュリティ問題の性質と範囲を迅速に分析および評価するのに役立ちます。

Detective は、AWS CloudTrail からの API 呼び出しや AWS の Amazon VPC フローログなど、時間ベースのイベントを自動的に抽出します。また、Amazon GuardDuty によって生成された検出結果も取り込みます。次に Detective は、機械学習、統計分析、グラフ理論を使用して、セキュリティ調査をより迅速かつ効率的に行うのに役立つビジュアライゼーションを生成します。

これらのビジュアライゼーションは、リソースの動作と時間の経過に伴うそれらのインタラクションに関するインタラクティブな統合ビューを提供します。この動作グラフを詳しく確認すると、失敗したログオン試行や疑わしい API コールなど、さまざまなアクションを調べることができます。また、これらのアクションが S3 バケットやオブジェクトなどのリソースにどのように影響するかを確認できます。

詳細については、「Amazon Detective 管理ガイド」を参照してください。

IAM Access Analyzer

AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) は、外部エンティティと共有されているリソースを識別するのに役立ちます。また、IAM Access Analyzer を使用して IAM ポリシーをポリシー文法やベストプラクティスに照らして検証し、AWS CloudTrail ログのアクセスアクティビティに基づいて IAM ポリシーを生成することもできます。

IAM Access Analyzer は、ロジックベースの推論を使用して、バケットポリシーなど、AWS 環境内のリソースポリシーを分析します。IAM Access Analyzer for S3 は、インターネットの任意のユーザーや他の AWS アカウント (組織外のアカウントを含む) にアクセスを許可するように S3 バケットが設定された場合、警告します。例えば、IAM Access Analyzer for S3 は、バケットのアクセスコントロールリスト (ACL)、バケットポリシー、マルチリージョンアクセスポイントポリシー、またはアクセスポイントポリシーを通じて、バケットに読み取りまたは書き込みのアクセス権が提供されていることを報告する場合があります。パブリックバケットまたは共有バケットごとに、パブリックアクセスや共有アクセスのソースとレベルを示す検出結果が送信されます。この情報を用いて、迅速で正確な是正処置を講じ、バケットへのアクセスを意図したとおりに復元できます。

詳細については、「IAM Access Analyzer for S3 を使用したバケットアクセスの確認」を参照してください。

Amazon Macie

Amazon Macie は、機械学習とパターンマッチングを使用して機密データを発見するセキュリティサービスです。Macie はデータセキュリティリスクを可視化し、それらのリスクに対する自動保護を可能にします。Macie を使用すると、Amazon S3 データアセット内の機密データの検出とレポートを自動化して、組織が Amazon S3 に保存しているデータを詳細に把握できます。

Macie を使用して機密データを検出するには、多くの国または地域の機密データタイプの大規模かつ増加しているリストを検出するように設計された組み込み型の基準と手法を使用できます。これらの機密データタイプには、複数の種類の個人を特定できる情報 (PII)、財務データ、認証情報データが含まれます。一致するテキストパターンを定義する正規表現を使用したり、オプションで結果を絞り込む文字シーケンスや近接ルールなど、自分で定義したカスタム基準を使用することもできます。

Macie が S3 オブジェクト内の機密データを検出すると、Macie はセキュリティ上の検出結果を生成して通知します。この検出結果により、影響を受けたオブジェクト、Macie が見つけた機密データの種類と出現回数、および影響を受けた S3 バケットとオブジェクトの調査に役立つ追加情報が得られます。詳細については、「Amazon Macie ユーザーガイド」を参照してください。

AWS Security Hub

AWS Security Hub は、セキュリティのベストプラクティスをチェックし、複数のソースからのアラートと検出結果を 1 つの形式に集約し、自動修復を可能にするセキュリティ体制管理サービスです。

Security Hub は、Amazon Detective、Amazon GuardDuty、IAM Access Analyzer、Amazon Macie などの統合 AWS Partner Network セキュリティソリューションおよび AWS のサービス からセキュリティ検出結果データを収集して提供します。また、AWS ベストプラクティスとサポートされている業界標準に基づいて、継続的な自動セキュリティチェックを実行することによって、独自の検出結果を生成します。

Security Hub はその後、プロバイダー間で結果を関連づけて統合し、最も重要な検出結果を優先化し、処理できるようにします。また、カスタムアクションもサポートされています。カスタムアクションを使用して、特定クラスの検出結果に対する応答または修復アクションを呼び出すことができます。

Security Hub を使用すると、Amazon S3 リソースのセキュリティとコンプライアンスのステータスを評価できます。これは、個々の AWS リージョン と複数のリージョンで、組織のセキュリティ体制に対するより広範な分析の一部として行うことができます。これには、セキュリティの傾向分析や最も優先度の高いセキュリティ問題の特定が含まれます。また、複数の AWS リージョン からの検出結果を集約したり、1 つのリージョンから集計した検出結果データをモニタリングおよび処理することもできます。

詳細については、「AWS Security Hub ユーザーガイド」の「Amazon Simple Storage Service コントロール」を参照してください。