翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
個人データ OU – PD アプリケーションアカウント
ご意見をお寄せください。簡単なアンケート |
個人データ (PD) アプリケーションアカウントは、組織が個人データを収集および処理するサービスをホストする場所です。具体的には、個人データとして定義したものをこのアカウントに保存できます。 AWS PRA は、多層サーバーレスウェブアーキテクチャによるプライバシー設定の例をいくつか示しています。 AWS ランディングゾーン間でワークロードを運用する場合、プライバシー設定をone-size-fits-allソリューションと見なすべきではありません。例えば、基礎となる概念、プライバシーを強化する方法、組織が特定のユースケースやアーキテクチャにソリューションをどのように適用できるかを理解することが目標である場合があります。
個人データを収集、保存、または処理する組織 AWS アカウント 内の では、 AWS Organizations と を使用して、基本ガードレールと反復可能なガードレール AWS Control Tower をデプロイできます。これらのアカウント専用の組織単位 (OU) を確立することが重要です。たとえば、データレジデンシーが設計上の考慮事項であるアカウントのサブセットにのみデータレジデンシーガードレールを適用できます。多くの組織では、これらは個人データを保存および処理するアカウントです。
組織は、個人用データセットの信頼できるソースを保存する専用のデータアカウントをサポートしている場合があります。信頼できるデータソースは、データのプライマリバージョンを保存する場所であり、データの最も信頼性が高く正確なバージョンと見なされる可能性があります。例えば、信頼できるデータソースから、PD アプリケーションアカウントの Amazon Simple Storage Service (Amazon S3) バケットなど、トレーニングデータ、顧客データのサブセット、秘匿化されたデータの保存に使用される他の場所にデータをコピーできます。このマルチアカウントアプローチを使用して、データアカウントの完全で決定的な個人データセットを PD アプリケーションアカウントのダウンストリームコンシューマーワークロードから分離することで、アカウントへの不正アクセスが発生した場合の影響範囲を減らすことができます。
次の図は、PD アプリケーションアカウントとデータアカウントで設定されている AWS セキュリティサービスとプライバシーサービスを示しています。
このセクションでは、これらのアカウントで使用される以下 AWS のサービス に関する詳細情報を提供します。
Amazon Athena
また、プライバシーの目標を達成するために、データクエリの制限に関するコントロールを検討することもできます。Amazon Athena は、標準 SQL を使用して Amazon S3 でデータを直接分析するのに役立つ対話型のクエリサービスです。Athena にデータをロードする必要はありません。S3 バケットに保存されているデータに直接使用できます。
Athena の一般的なユースケースは、データ分析チームにカスタマイズされたサニタイズされたデータセットを提供することです。データセットに個人データが含まれている場合は、データ分析チームにほとんど価値のない個人データの列全体をマスクすることで、データセットをサニタイズできます。詳細については、Amazon Athena によるデータレイク内のデータの匿名化と管理 AWS Lake Formation
データ変換アプローチで Athena でサポートされている関数以外の柔軟性が必要な場合は、ユーザー定義関数 (UDF) と呼ばれるカスタム関数を定義できます。Athena に送信された SQL クエリで UDFs を呼び出すことができ、それらが実行されます AWS Lambda。UDF は SELECTおよび FILTER SQLクエリで使用でき、同じクエリで複数の UDFs呼び出すことができます。プライバシーのために、列内のすべての値の最後の 4 文字のみを表示するなど、特定のタイプのデータマスキングを実行する UDFs を作成できます。
Amazon CloudWatch Logs
Amazon CloudWatch Logs は、すべてのシステム、アプリケーション、 AWS のサービス からのログを一元化するのに役立ちます。一元化により、ログを監視して安全にアーカイブできます。CloudWatch Logs では、新規または既存のロググループにデータ保護ポリシーを使用して、個人データの開示リスクを最小限に抑えることができます。データ保護ポリシーは、ログ内の個人データなどの機密データを検出できます。データ保護ポリシーは、ユーザーが を介してログにアクセスするときに、そのデータをマスクできます AWS Management Console。ワークロードの全体的な目的仕様に従って、ユーザーが個人データに直接アクセスする必要がある場合は、それらのユーザーにアクセスlogs:Unmask許可を割り当てることができます。また、アカウント全体のデータ保護ポリシーを作成し、このポリシーを組織内のすべてのアカウントに一貫して適用することもできます。これにより、CloudWatch Logs の現在および将来のすべてのロググループに対してデフォルトでマスキングが設定されます。また、監査レポートを有効にして、別のロググループ、Amazon S3 バケット、または Amazon Data Firehose に送信することをお勧めします。これらのレポートには、各ロググループ全体のデータ保護結果の詳細な記録が含まれています。
Amazon CodeGuru Reviewer
プライバシーとセキュリティの両方において、多くの組織にとって、デプロイフェーズとデプロイ後のフェーズの両方で継続的なコンプライアンスをサポートすることが重要です。PRA AWS には、個人データを処理するアプリケーションのデプロイパイプラインにプロアクティブコントロールが含まれています。Amazon CodeGuru Reviewer は、Java、JavaScript、および Python コードで個人データを公開する可能性がある潜在的な欠陥を検出できます。コードの改善に関する提案をデベロッパーに提供します。CodeGuru Reviewer は、さまざまなセキュリティ、プライバシー、一般的なベストプラクティスの欠陥を特定できます。詳細については、「Amazon CodeGuru Detector Library」を参照してください。Bitbucket、GitHub AWS CodeCommit、Amazon S3 など、複数のソースプロバイダーと連携するように設計されています。CodeGuru Reviewer が検出できるプライバシー関連の欠陥には、次のようなものがあります。
-
SQL インジェクション
-
セキュリティで保護されていない Cookie
-
認可がありません
-
クライアント側の AWS KMS 再暗号化
Amazon Comprehend
Amazon Comprehend は自然言語処理 (NLP) サービスで、機械学習を使用して英語のテキストドキュメントで貴重なインサイトと接続を発見します。Amazon Comprehend は、構造化、半構造化、または非構造化テキストドキュメント内の個人データを検出して編集できます。詳細については、Amazon Comprehend ドキュメントの「個人を特定できる情報 (PII)」を参照してください。
AWS SDKs と Amazon Comprehend API を使用して、Amazon Comprehend を多くのアプリケーションと統合できます。例えば、Amazon Comprehend を使用してAmazon S3 Object Lambda で個人データを検出して編集します。組織は S3 Object Lambda を使用して Amazon S3 GET リクエストにカスタムコードを追加して、アプリケーションに返されるデータを変更および処理できます。S3 Object Lambda は、行のフィルタリング、イメージの動的なサイズ変更、個人データの編集などを行うことができます。 AWS Lambda 関数を搭載したコードは、 によって完全に管理されているインフラストラクチャで実行されるため AWS、データの派生コピーを作成して保存したり、プロキシを実行したりする必要がありません。S3 Object Lambda でオブジェクトを変換するためにアプリケーションを変更する必要はありません。で ComprehendPiiRedactionS3Object Lambda 関数を使用して、個人データ AWS Serverless Application Repository を編集できます。この関数は Amazon Comprehend を使用して個人データエンティティを検出し、アスタリスクに置き換えてそれらのエンティティを編集します。詳細については、Amazon S3 ドキュメントの「S3 Object Lambda と Amazon Comprehend を使用した PII データの検出と編集」を参照してください。 Amazon S3
Amazon Comprehend には AWS SDKs を介したアプリケーション統合のための多くのオプションがあるため、Amazon Comprehend を使用して、データを収集、保存、処理するさまざまな場所で個人データを識別できます。Amazon Comprehend ML 機能を使用して、アプリケーションログ
-
REPLACE_WITH_PII_ENTITY_TYPEは、各 PII エンティティをそのタイプに置き換えます。例えば、Jane Doe は NAME に置き換えられます。 -
MASKは、PII エンティティの文字を任意の文字 (!、#、$、%、&、、または @) に置き換えます。例えば、Jane Doe を **** *** に置き換えることができます。
Amazon Data Firehose
Amazon Data Firehose を使用して、ストリーミングデータをキャプチャ、変換し、Amazon Managed Service for Apache Flink や Amazon S3 などのダウンストリームサービスにロードできます。Firehose は、処理パイプラインをゼロから構築することなく、アプリケーションログなどの大量のストリーミングデータを転送するためによく使用されます。
Lambda 関数を使用して、データがダウンストリームに送信される前に、カスタマイズされた処理または組み込み処理を実行できます。プライバシー保護のため、この機能はデータ最小化とクロスボーダーデータ転送要件をサポートします。例えば、Lambda と Firehose を使用して、マルチリージョンのログデータを変換してから、ログアーカイブアカウントに一元化できます。詳細については、「"": Centralized Logging Solution for Multi Accounts
AWS Glue
個人データを含むデータセットの維持は、Privacy by Design
AWS Glue Data Catalog
AWS Glue Data Catalog は、保守可能なデータセットを確立するのに役立ちます。データカタログには、抽出、変換、ロード (ETL) ジョブのソースおよびターゲットとして使用されるデータへの参照が含まれています AWS Glue。データカタログ内の情報はメタデータテーブルとして保存され、各テーブルは単一のデータストアを指定します。クローラを実行して AWS Glue 、さまざまなデータストアタイプのデータをインベントリします。組み込み分類子とカスタム分類子をクローラに追加し、これらの分類子は個人データのデータ形式とスキーマを推測します。次に、クローラーはメタデータをデータカタログに書き込みます。一元化されたメタデータテーブルを使用すると、 AWS 環境内の個人データのさまざまなソースに構造と予測可能性が追加されるため、データの件名のリクエスト (消去する権利など) に簡単に対応できます。Data Catalog を使用してこれらのリクエストに自動的に応答する方法の包括的な例については、Amazon S3 Find and Forget によるデータレイク内のデータ消去リクエストの処理
AWS Glue DataBrew
AWS Glue DataBrew は、データのクリーニングと正規化に役立ちます。また、個人を特定できる情報の削除やマスキング、データパイプライン内の機密データフィールドの暗号化など、データの変換を実行できます。また、データの系統を視覚的にマッピングして、データが通過したさまざまなデータソースと変換ステップを理解することもできます。この機能は、組織が個人データの出所をよりよく理解して追跡する作業を行うにつれて、ますます重要になっています。DataBrew は、データの準備中に個人データをマスクするのに役立ちます。データプロファイリングジョブの一部として個人データを検出し、個人データを含む可能性のある列の数や潜在的なカテゴリなどの統計を収集できます。その後、置換、ハッシュ、暗号化、復号化など、組み込みの元に戻すまたは元に戻すことができないデータ変換手法を、コードを記述することなく使用できます。その後、分析、レポート、機械学習タスクのために、クリーンアップされたデータセットとマスクされたデータセットをダウンストリームで使用できます。DataBrew で利用できるデータマスキング手法には、次のようなものがあります。
-
ハッシュ — ハッシュ関数を列の値に適用します。
-
置換 — 個人データを他の正規表現の値に置き換えます。
-
Nulling out または削除 – 特定のフィールドを null 値に置き換えるか、列を削除します。
-
マスクアウト – キャラクタースクラブを使用するか、列内の特定の部分をマスクします。
使用可能な暗号化手法は次のとおりです。
-
決定的暗号化 – 列値に決定的暗号化アルゴリズムを適用します。確定的暗号化では、値に対して常に同じ暗号文が生成されます。
-
確率的暗号化 – 確率的暗号化アルゴリズムを列値に適用します。確率的暗号化は、適用されるたびに異なる暗号文を生成します。
DataBrew で提供される個人データ変換レシピの完全なリストについては、「個人を特定できる情報 (PII) recipe steps」を参照してください。
AWS Glue データ品質
AWS Glue Data Quality は、データパイプラインがデータコンシューマーに配信される前に、データパイプライン間で高品質のデータの配信をプロアクティブに自動化および運用するのに役立ちます。 AWS Glue Data Quality は、データパイプライン全体のデータ品質問題の統計分析を提供し、Amazon EventBridge でアラートをトリガーし、修復のための品質ルールのレコメンデーションを行うことができます。 AWS Glue Data Quality は、カスタムデータ品質ルールを作成できるように、ドメイン固有の言語でのルール作成もサポートしています。
AWS Key Management Service
AWS Key Management Service （AWS KMS） は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。 は、ハードウェアセキュリティモジュール AWS KMS を使用して、FIPS 140-2 暗号化モジュール検証プログラム AWS KMS keys で保護と検証を行います。このサービスがセキュリティコンテキストでどのように使用されるかの詳細については、AWS 「 セキュリティリファレンスアーキテクチャ」を参照してください。
AWS KMS は、暗号化 AWS のサービス を提供するほとんどの と統合されており、個人データを処理して保存するアプリケーションで KMS キーを使用できます。を使用すると AWS KMS 、次のようなさまざまなプライバシー要件をサポートし、個人データを保護できます。
-
カスタマーマネージドキーを使用して、強度、ローテーション、有効期限、その他のオプションをより細かく制御できます。
-
専用のカスタマーマネージドキーを使用して、個人データと、個人データへのアクセスを許可するシークレットを保護します。
-
データ分類レベルを定義し、レベルごとに少なくとも 1 つの専用カスタマーマネージドキーを指定します。例えば、運用データを暗号化するためのキーと、個人データを暗号化するためのキーがあるとします。
-
KMS キーへの意図しないクロスアカウントアクセスの防止。
-
暗号化するリソース AWS アカウント と同じ 内に KMS キーを保存する。
-
KMS キーの管理と使用の職務分離を実装します。詳細については、「How to use KMS and IAM to enable independent security controls for encrypted data in S3
」（AWS ブログ記事) を参照してください。 -
予防ガードレールと事後対応ガードレールによる自動キーローテーションの適用。
デフォルトでは、KMS キーは保存され、作成されたリージョンでのみ使用できます。組織にデータレジデンシーと主権に関する特定の要件がある場合は、マルチリージョン KMS キーがユースケースに適しているかどうかを検討してください。マルチリージョンキーは、異なる の特殊用途の KMS キー AWS リージョン で、同じ意味で使用できます。マルチリージョンキーを作成するプロセスは、キーマテリアルを内部の AWS リージョン 境界を越えて移動するため AWS KMS、このリージョン分離の欠如は組織のコンプライアンス目標と互換性がない可能性があります。これを解決する 1 つの方法は、リージョン固有のカスタマーマネージドキーなど、別のタイプの KMS キーを使用することです。
AWS ローカルゾーン
データレジデンシー要件に準拠する必要がある場合は、これらの要件をサポートするために、特定の に個人データを保存および処理するリソース AWS リージョン をデプロイできます。AWS Local Zones を使用することもできます。これにより、コンピューティング、ストレージ、データベース、その他の一部の AWS リソースを大規模な人口や業界の中心の近くに配置することができます。ローカルゾーンは、大都市圏 AWS リージョン に地理的に近い の拡張です。特定のタイプのリソースは、ローカルゾーンが対応するリージョンの近くにあるローカルゾーン内に配置できます。Local Zones は、同じ法管轄区域内でリージョンが利用できない場合に、データレジデンシー要件を満たすのに役立ちます。Local Zones を使用する場合は、組織内にデプロイされているデータレジデンシーコントロールを検討してください。例えば、特定のローカルゾーンから別のリージョンへのデータ転送を防ぐためのコントロールが必要になる場合があります。SCPs を使用してクロスボーダーデータ転送ガードレールを維持する方法の詳細については、「Best Practices for managing data residency in AWS Local Zones using landing zone controls
AWS Nitro Enclaves
Amazon Elastic Compute Cloud (Amazon EC2) などのコンピューティングサービスを使用して個人データを処理するなど、処理の観点からデータセグメンテーション戦略を検討してください。大規模なアーキテクチャ戦略の一環としての機密コンピューティングは、隔離され、保護され、信頼できる CPU エンクレーブで個人データ処理を分離するのに役立ちます。エンクレーブは、分離され、強化され、制約の厳しい仮想マシンです。AWS Nitro Enclaves は、これらの分離されたコンピューティング環境の作成に役立つ Amazon EC2 機能です。詳細については、「The Security Design of the AWS Nitro System」（AWS ホワイトペーパー) を参照してください。
Nitro Enclaves は、親インスタンスのカーネルから分離されたカーネルをデプロイします。親インスタンスのカーネルはエンクレーブにアクセスできません。ユーザーは、エンクレーブ内のデータとアプリケーションに SSH またはリモートでアクセスすることはできません。個人データを処理するアプリケーションはエンクレーブに埋め込んで、エンクレーブの Vsock を使用するように設定できます。これは、エンクレーブと親インスタンス間の通信を容易にするソケットです。
Nitro Enclaves が役立つユースケースの 1 つは、別々の 2 つのデータプロセッサ間のジョイント処理 AWS リージョン であり、相互に信頼しない可能性があります。次の図は、エンクレーブを中央処理に使用する方法、エンクレーブに送信される前に個人データを暗号化するための KMS キー、および復号をリクエストするエンクレーブにアテステーションドキュメント内の一意の測定値があることを検証する AWS KMS key ポリシーを示しています。詳細と手順については、「 での暗号化アテステーションの使用 AWS KMS」を参照してください。サンプルキーポリシーについては、このガイドキーを使用するには AWS KMS 認証が必要ですの「」を参照してください。
この実装では、それぞれのデータ処理者と基盤となるエンクレーブのみがプレーンテキストの個人データにアクセスできます。データが公開される場所は、それぞれのデータ処理者の環境外のみで、エンクレーブ自体にあります。エンクレーブ自体は、アクセスや改ざんを防ぐように設計されています。
AWS PrivateLink
多くの組織は、信頼できないネットワークへの個人データの公開を制限したいと考えています。例えば、アプリケーションアーキテクチャ設計全体のプライバシーを強化する場合は、データの機密性に基づいてネットワークをセグメント化できます (データのセグメント化に役立つ AWS のサービスと機能「」セクションで説明されているデータセットの論理的および物理的な分離に似ています）。 AWS PrivateLinkは、仮想プライベートクラウド (VPCs) から VPC 外のサービスへの単方向のプライベート接続を作成するのに役立ちます。を使用すると AWS PrivateLink、 環境で個人データを保存または処理するサービスへの専用プライベート接続を設定できます。パブリックエンドポイントに接続して、信頼できないパブリックネットワーク経由でこのデータを転送する必要はありません。対象範囲内 AWS PrivateLink のサービスのサービスエンドポイントを有効にすると、通信にインターネットゲートウェイ、NAT デバイス、パブリック IP アドレス、 AWS Direct Connect 接続、または AWS Site-to-Site VPN 接続は必要ありません。 AWS PrivateLink を使用して、個人データへのアクセスを提供するサービスに接続する場合、VPC エンドポイントポリシーとセキュリティグループを使用して、組織のデータ境界
AWS Resource Access Manager
AWS Resource Access Manager (AWS RAM） は、 間でリソースを安全に共有 AWS アカウント し、運用上のオーバーヘッドを削減し、可視性と監査可能性を提供するのに役立ちます。マルチアカウントセグメンテーション戦略を計画する際には、 AWS RAM を使用して、分離された別のアカウントに保存している個人データストアを共有することを検討してください。処理の目的で、その個人データを他の信頼されたアカウントと共有できます。では AWS RAM、共有リソースに対して実行できるアクションを定義するアクセス許可を管理できます。へのすべての API コール AWS RAM は CloudTrail に記録されます。また、Amazon CloudWatch Events を設定して、リソース共有に変更が加えられたときなど AWS RAM、 の特定のイベントを自動的に通知するようにすることもできます。
Amazon S3 の IAM またはバケットポリシーでリソースベースのポリシー AWS アカウント を使用することで、さまざまなタイプの AWS リソースを他の と共有できますが、 AWS RAM にはプライバシーに関するいくつかの追加の利点があります。 AWS は AWS アカウント、データ所有者が 間でデータを共有する方法とユーザーについて、さらに可視化します。
-
アカウント IDs のリストを手動で更新するのではなく、OU 全体とリソースを共有できる
-
コンシューマーアカウントが組織の一部でない場合の共有開始の招待プロセスの実施
-
特定の IAM プリンシパルが個々のリソースにアクセスできる可視性
以前にリソースベースのポリシーを使用してリソース共有を管理し、 AWS RAM 代わりに を使用する場合は、PromoteResourceShareCreatedFromPolicy API オペレーションを使用します。
Amazon SageMaker AI
Amazon SageMaker AI は、ML モデルを構築してトレーニングし、本番環境に対応したホスト環境にデプロイするのに役立つマネージド機械学習 (ML) サービスです。SageMaker AI は、トレーニングデータの準備とモデル機能の作成を容易にするように設計されています。
Amazon SageMaker AI Model Monitor
多くの組織は、ML モデルをトレーニングする際にデータドリフトを考慮しています。データドリフトは、本番データと ML モデルのトレーニングに使用されたデータとの間の意味のあるバリエーション、または時間の経過に伴う入力データの意味のある変化です。データドリフトは、ML モデル予測の全体的な品質、精度、公平性を低下させる可能性があります。ML モデルが本番環境で受け取るデータの統計的性質が、トレーニングされたベースラインデータの性質から逸脱すると、予測の精度が低下する可能性があります。Amazon SageMaker AI Model Monitor は、本番環境の Amazon SageMaker AI 機械学習モデルの品質を継続的にモニタリングし、データ品質をモニタリングできます。データドリフトを早期かつプロアクティブに検出することで、モデルの再トレーニング、アップストリームシステムの監査、データ品質の問題の修正などの是正措置を実装できます。Model Monitor を使用すると、モデルを手動でモニタリングしたり、追加のツールを構築したりする必要性を軽減できます。
Amazon SageMaker AI Clarify
Amazon SageMaker AI Clarify は、モデルのバイアスと説明可能性に関するインサイトを提供します。SageMaker AI Clarify は、ML モデルデータの準備中および全体的な開発フェーズで一般的に使用されます。開発者は性別や年齢などの関心のある属性を指定できます。SageMaker AI Clarify は一連のアルゴリズムを実行して、それらの属性にバイアスが存在するかどうかを検出します。アルゴリズムが実行されると、SageMaker AI Clarify はバイアスのソースと測定値の説明を含むビジュアルレポートを提供し、バイアスを修正するステップを特定できるようにします。例えば、ある年齢グループに対するビジネスローンの例が他の年齢グループと比較してわずかしか含まれていない財務データセットでは、SageMaker は不均衡にフラグを立てて、その年齢グループを不利にするモデルを回避できます。また、予測を確認し、これらの ML モデルにバイアスを継続的にモニタリングすることで、トレーニング済みのモデルにバイアスがないかを確認することもできます。最後に、SageMaker AI Clarify は Amazon SageMaker AI Experiments と統合され、モデルの全体的な予測作成プロセスに最も寄与した特徴量を説明するグラフを提供します。この情報は、説明可能性の結果を達成するのに役立ち、特定のモデル入力がモデルの動作全体に与えるよりも大きな影響を与えるかどうかを判断するのに役立ちます。
Amazon SageMaker モデルカード
Amazon SageMaker Model Card は、ガバナンスとレポート作成の目的で ML モデルに関する重要な詳細を文書化するのに役立ちます。これらの詳細には、モデル所有者、汎用、意図したユースケース、行われた仮定、モデルのリスク評価、トレーニングの詳細とメトリクス、評価結果が含まれます。詳細については、AWS 「人工知能とMachine Learningソリューションによるモデルの説明可能性」（AWS ホワイトペーパー) を参照してください。
AWS データライフサイクルの管理に役立つ の機能
個人データが不要になった場合は、さまざまなデータストアのデータにライフサイクルポリシーとtime-to-liveポリシーを使用できます。データ保持ポリシーを設定するときは、個人データが含まれている可能性がある以下の場所を考慮してください。
-
Amazon DynamoDB や Amazon Relational Database Service (Amazon RDS) などのデータベース
-
Amazon S3 バケット
-
CloudWatch と CloudTrail からのログ
-
AWS Database Migration Service （AWS DMS) および AWS Glue DataBrew プロジェクトの移行からのキャッシュされたデータ
-
バックアップとスナップショット
以下の AWS のサービス および 機能は、 AWS 環境でのデータ保持ポリシーの設定に役立ちます。
-
Amazon S3 ライフサイクル – Amazon S3 がオブジェクトのグループに適用するアクションを定義する一連のルール。Amazon S3 ライフサイクル設定では、ユーザーに代わって Amazon S3 が期限切れオブジェクトを削除するタイミングを定義する有効期限アクションを作成できます。詳細については、「Managing your storage lifecycle」を参照してください。
-
Amazon Data Lifecycle Manager – Amazon EC2 で、Amazon Elastic Block Store (Amazon EBS) スナップショットと EBS-backed Amazon マシンイメージ (AMIs) の作成、保持、削除を自動化するポリシーを作成します。
-
DynamoDB 有効期限 (TTL) – 項目ごとのタイムスタンプを定義して、項目が不要になったタイミングを決定します。指定されたタイムスタンプの日時の直後に、DynamoDB はテーブルから項目を削除します。
-
CloudWatch Logs のログ保持設定 – 各ロググループの保持ポリシーを 1 日から 10 年の値に調整できます。
-
AWS Backup – データ保護ポリシーを一元的にデプロイして、S3 バケット、RDS データベースインスタンス、DynamoDB テーブル、EBS ボリュームなど、さまざまな AWS リソース間でバックアップアクティビティを設定、管理、管理します。リソースタイプを指定するか、既存の AWS リソースタグに基づいて を適用して、追加の詳細度を提供することで、バックアップポリシーをリソースに適用します。一元化されたコンソールからバックアップアクティビティを監査して報告し、バックアップコンプライアンス要件を満たすのに役立ちます。
データのセグメント化に役立つ AWS のサービスと機能
データセグメンテーションは、データを別々のコンテナに保存するためのプロセスです。これにより、各データセットに差別化されたセキュリティと認証の対策を提供し、データセット全体の露出の影響範囲を減らすことができます。例えば、すべての顧客データを 1 つの大きなデータベースに保存する代わりに、このデータをより小さく管理しやすいグループにセグメント化できます。
物理的および論理的な分離を使用して、個人データをセグメント化できます。
-
物理的な分離 – データを別々のデータストアに保存するか、データを別々の AWS リソースに分散する行為。データは物理的に分離されていますが、両方のリソースに同じプリンシパルからアクセスできる可能性があります。そのため、物理的な分離と論理的な分離を組み合わせることをお勧めします。
-
論理的な分離 – アクセスコントロールを使用してデータを分離する行為。職務機能ごとに、個人データのサブセットへの異なるレベルのアクセスが必要です。論理的な分離を実装するサンプルポリシーについては、このガイド特定の Amazon DynamoDB 属性へのアクセスを許可するの「」を参照してください。
論理的な分離と物理的な分離を組み合わせることで、アイデンティティベースポリシーとリソースベースのポリシーを記述する際の柔軟性、シンプルさ、粒度を提供し、職務機能間の差別化されたアクセスをサポートします。例えば、1 つの S3 バケットで異なるデータ分類を論理的に分離するポリシーを作成するのは、運用上複雑な場合があります。各データ分類に専用の S3 バケットを使用すると、ポリシーの設定と管理が簡素化されます。
