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

個人データ 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 セキュリティサービスとプライバシーサービスを示しています。

Amazon Athena

プライバシー目標を達成するために、データクエリの制限に関するコントロールを検討できます。Amazon Athena は、標準 SQL を使用して Amazon S3 でデータを直接分析するのに役立つ対話型のクエリサービスです。Athena にデータをロードする必要はありません。S3 バケットに保存されているデータと直接連携します。

Athena の一般的なユースケースは、データ分析チームにカスタマイズされたサニタイズされたデータセットを提供することです。データセットに個人データが含まれている場合は、データ分析チームにとってほとんど価値のない個人データの列全体をマスクすることで、データセットをサニタイズできます。詳細については、Amazon Athena によるデータレイク内のデータの匿名化と管理 AWS Lake Formation」および「（AWS ブログ記事）」を参照してください。

データ変換アプローチで Athena でサポートされている関数以外の柔軟性が必要な場合は、ユーザー定義関数 (UDF) と呼ばれるカスタム関数を定義できます。Athena に送信された SQL クエリで UDFs を呼び出して実行できます AWS Lambda。SELECT および FILTER SQLクエリで UDFs を使用し、同じクエリで複数の UDFsを呼び出すことができます。プライバシーのために、列内のすべての値の最後の 4 文字のみを表示するなど、特定のタイプのデータマスキングを実行する UDFs を作成できます。

Amazon Bedrock

Amazon Bedrock は、AI21 Labs、Anthropic、Meta、Mistral AI、Amazon などの主要な AI 企業の基盤モデルへのアクセスを提供するフルマネージドサービスです。これは、組織が生成 AI アプリケーションを構築およびスケールするのに役立ちます。どのプラットフォームが使用されていても、生成 AI を使用すると、組織は個人データの潜在的な漏洩、不正なデータアクセス、その他のコンプライアンス違反などのプライバシーリスクにさらされる可能性があります。

Amazon Bedrock ガードレールは、Amazon Bedrock の生成 AI ワークロード全体にセキュリティとコンプライアンスのベストプラクティスを適用することで、これらのリスクを軽減するように設計されています。AI リソースのデプロイと使用は、必ずしも組織のプライバシー要件とコンプライアンス要件に合致するとは限りません。組織は生成 AI モデルを使用する際にデータプライバシーの維持に苦労する可能性があります。これらのモデルは機密情報を記憶または再現する可能性があるためです。Amazon Bedrock ガードレールは、ユーザー入力とモデルレスポンスを評価することでプライバシーを保護するのに役立ちます。全体として、入力データに個人データが含まれている場合、この情報がモデルの出力で公開されるリスクがあります。

Amazon Bedrock ガードレールは、データ保護ポリシーを適用し、不正なデータ漏洩を防ぐメカニズムを提供します。入力内の個人データを検出してブロックするコンテンツフィルタリング機能、不適切またはリスクのある主題へのアクセスを防ぐためのトピック制限、モデルプロンプトとレスポンスの機密用語をマスクまたは編集する単語フィルターを提供します。これらの機能は、レスポンスのバイアスや顧客の信頼の低下など、プライバシー違反につながる可能性のあるイベントを防ぐのに役立ちます。これらの機能は、個人データが AI モデルによって誤って処理または開示されないようにするのに役立ちます。Amazon Bedrock ガードレールは、Amazon Bedrock 外での入力とレスポンスの評価もサポートしています。詳細については、「Amazon Bedrock ガードレールによるモデルに依存しない安全対策の実装」（AWS ブログ記事) を参照してください。

Amazon Bedrock ガードレールを使用すると、事実のグラウンディングとレスポンスの関連性を評価するコンテキストグラウンディングチェックを使用して、モデルハルシネーションのリスクを制限できます。たとえば、検索拡張生成 (RAG) アプリケーションでサードパーティーのデータソースを使用する生成 AI の顧客向けアプリケーションをデプロイします。コンテキストグラウンディングチェックを使用して、これらのデータソースに対するモデルレスポンスを検証し、不正確なレスポンスを除外できます。 AWS PRA のコンテキストでは、ワークロードアカウント全体に Amazon Bedrock ガードレールを実装できます。これにより、各ワークロードの要件に合わせた特定のプライバシーガードレールが適用されます。

AWS Clean Rooms

組織は、機密性の高いデータセットを交差または重複させる分析を通じて相互にコラボレーションする方法を探しているため、その共有データのセキュリティとプライバシーを維持することが懸念されます。 は、生データ自体を共有せずに結合されたデータセットを分析できる安全で中立的な環境であるデータクリーンルームをデプロイするAWS Clean Roomsのに役立ちます。また、自分のアカウントからデータを移動またはコピーしたり、基盤となるデータセットを公開 AWS したりすることなく、 で他の組織にアクセスできるようにすることで、独自のインサイトを生成できます。すべてのデータはソースの場所に残ります。組み込みの分析ルールは、出力を制限し、SQL クエリを制限します。すべてのクエリがログに記録され、コラボレーションメンバーはデータのクエリ方法を表示できます。

AWS Clean Rooms コラボレーションを作成し、他の AWS 顧客をそのコラボレーションのメンバーに招待できます。メンバーデータセットをクエリする機能を 1 人のメンバーに付与し、追加のメンバーを選択してそれらのクエリの結果を受け取ることができます。複数のメンバーがデータセットをクエリする必要がある場合は、同じデータソースと異なるメンバー設定を使用して追加のコラボレーションを作成できます。各メンバーは、コラボレーションメンバーと共有されているデータをフィルタリングできます。また、カスタム分析ルールを使用して、コラボレーションに提供するデータの分析方法の制限を設定できます。

は、コラボレーションに提示されるデータと他のメンバーによる使用方法を制限するだけでなく、プライバシーの保護に役立つ以下の機能 AWS Clean Rooms を提供します。

AWS PRA では、データアカウントで AWS Clean Rooms コラボレーションを作成することをお勧めします。これらを使用して、暗号化された顧客データをサードパーティーと共有できます。提供されたデータセットに重複がある場合にのみ使用してください。重複を判断する方法の詳細については、 AWS Clean Rooms ドキュメントの「分析ルールを一覧表示する」を参照してください。

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 は、さまざまなセキュリティ、プライバシー、一般的な推奨プラクティスの欠陥を特定できます。 AWS CodeCommit、Bitbucket、GitHub、Amazon S3 など、複数のソースプロバイダーと連携するように設計されています。CodeGuru Reviewer が検出できるプライバシー関連の欠陥には、次のようなものがあります。

CodeGuru Reviewer が検出できるものの完全なリストについては、「Amazon CodeGuru Detector Library」を参照してください。

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 機能を使用すると、アプリケーションログ (AWS ブログ記事）、顧客の E メール、サポートチケットなどの個人データを検出して編集できます。PD アプリケーションアカウントのアーキテクチャ図は、Amazon EC2 のアプリケーションログに対してこの関数を実行する方法を示しています。Amazon Comprehend には 2 つの秘匿化モードがあります。

Amazon Data Firehose

Amazon Data Firehose を使用して、ストリーミングデータをキャプチャ、変換し、Amazon Managed Service for Apache Flink や Amazon S3 などのダウンストリームサービスにロードできます。Firehose は、処理パイプラインをゼロから構築することなく、アプリケーションログなどの大量のストリーミングデータを転送するためによく使用されます。

Lambda 関数を使用して、データがダウンストリームに送信される前に、カスタマイズされた処理または組み込み処理を実行できます。プライバシーのために、この機能はデータ最小化とクロスボーダーデータ転送要件をサポートします。例えば、Lambda と Firehose を使用して、ログアーカイブアカウントに一元化される前にマルチリージョンログデータを変換できます。詳細については、「": Centralized Logging Solution for Multi Accounts」(YouTube 動画) を参照してください。PD アプリケーションアカウントで、Firehose 配信ストリームにログをプッシュ AWS CloudTrail するように Amazon CloudWatch と を設定します。Lambda 関数はログを変換し、ログアーカイブアカウントの中央 S3 バケットに送信します。個人データを含む特定のフィールドをマスクするように Lambda 関数を設定できます。これにより、 間での個人データの転送を防ぐことができます AWS リージョン。このアプローチを使用すると、個人データは転送前と一元化前ではなく、その後にマスクされます。クロスボーダー転送要件の対象ではない管轄区域のアプリケーションの場合、通常、CloudTrail の組織証跡を通じてログを集約すると、運用効率とコスト効率が向上します。詳細については、このガイドAWS CloudTrailの Security OU – Security Tooling アカウントセクションの「」を参照してください。

Amazon DataZone

組織が AWS のサービス などの を通じてデータを共有するアプローチをスケールするにつれて AWS Lake Formation、差分アクセスがデータに最も精通しているユーザー、つまりデータ所有者によって制御されるようにしたいと考えています。ただし、これらのデータ所有者は、同意やクロスボーダーデータ転送に関する考慮事項などのプライバシー要件を認識している可能性があります。Amazon DataZone は、データ所有者とデータガバナンスチームが、データガバナンスポリシーに従って組織全体でデータを共有および消費するのに役立ちます。Amazon DataZone では、事業部門 (LOBs) が独自のデータを管理し、カタログがこの所有権を追跡します。利害関係者は、ビジネスタスクの一環としてデータを見つけてアクセスをリクエストできます。データパブリッシャーによって確立されたポリシーに準拠している限り、データ所有者は、管理者やデータを移動することなく、基盤となるテーブルへのアクセスを許可できます。

プライバシーコンテキストでは、Amazon DataZone は次のユースケースの例で役立ちます。

AWS PRA では、共有 Amazon S3 バケット内のデータをデータプロデューサーとして Amazon DataZone に接続できます。

AWS Glue

個人データを含むデータセットの維持は、Privacy by Design の主要なコンポーネントです。組織のデータは、構造化、半構造化、または非構造化の形式で存在する場合があります。構造のない個人用データセットでは、データ最小化、データサブジェクトリクエストの一部として単一のデータサブジェクトに起因するデータの追跡、一貫したデータ品質の確保、データセットの全体的なセグメンテーションなど、プライバシーを強化するオペレーションを多数実行することが困難になる可能性があります。 AWS Glueはフルマネージドの抽出、変換、ロード (ETL) サービスです。データストアとデータストリーム間でデータを分類、クリーンアップ、強化、移動するのに役立ちます。 AWS Glue 機能は、分析、機械学習、アプリケーション開発用のデータセットを検出、準備、構造化、結合するのに役立ちます。 AWS Glue を使用して、既存のデータセット上に予測可能で共通の構造を作成できます。 AWS Glue Data Catalog、 AWS Glue DataBrew、および AWS Glue Data Quality は、組織のプライバシー要件をサポートするのに役立つ AWS Glue 機能です。

AWS Glue Data Catalog

AWS Glue Data Catalog は、メンテナンス可能なデータセットを確立するのに役立ちます。データカタログには、抽出、変換、ロード (ETL) ジョブのソースおよびターゲットとして使用されるデータへの参照が含まれています AWS Glue。データカタログ内の情報はメタデータテーブルとして保存され、各テーブルは単一のデータストアを指定します。クローラを実行して AWS Glue 、さまざまなデータストアタイプのデータをインベントリします。組み込み分類子とカスタム分類子をクローラに追加すると、これらの分類子は個人データのデータ形式とスキーマを推測します。次に、クローラはメタデータをデータカタログに書き込みます。一元化されたメタデータテーブルを使用すると、 AWS 環境内の個人データのさまざまなソースに構造と予測可能性が追加されるため、データセットリクエスト (消去する権利など) への対応が容易になります。Data Catalog を使用してこれらのリクエストに自動的に応答する方法の包括的な例については、Amazon S3 Find and Forget によるデータレイク内のデータ消去リクエストの処理」（AWS ブログ記事) を参照してください。最後に、組織が AWS Lake Formationを使用してデータベース、テーブル、行、セル間できめ細かなアクセスを管理および提供している場合、Data Catalog は主要なコンポーネントです。Data Catalog はクロスアカウントデータ共有を提供し、タグベースのアクセスコントロールを使用してデータレイクを大規模に管理するのに役立ちます (AWS ブログ記事）。詳細については、このセクションAWS Lake Formationの「」を参照してください。

AWS Glue DataBrew

AWS Glue DataBrew は、データのクリーンアップと正規化に役立ち、個人を特定できる情報の削除やマスキング、データパイプライン内の機密データフィールドの暗号化など、データの変換を実行できます。また、データの系統を視覚的にマッピングして、データが通過したさまざまなデータソースと変換ステップを理解することもできます。この機能は、組織が個人データの出所をよりよく理解して追跡しようとするにつれて、ますます重要になっています。DataBrew は、データの準備中に個人データをマスクするのに役立ちます。データプロファイリングジョブの一部として個人データを検出し、個人データや潜在的なカテゴリを含む可能性のある列の数などの統計を収集できます。その後、置換、ハッシュ、暗号化、復号など、組み込みの可逆的または不可逆的なデータ変換手法を、コードを記述することなく使用できます。その後、クリーンデータセットとマスクデータセットをダウンストリームで分析、レポート、機械学習タスクに使用できます。DataBrew で使用できるデータマスキング手法には、次のようなものがあります。

使用可能な暗号化手法は次のとおりです。

DataBrew で提供される個人データ変換レシピの完全なリストについては、「個人を特定できる情報 (PII) レシピの手順」を参照してください。

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 、次のようなさまざまなプライバシー要件をサポートし、個人データを保護することができます。

デフォルトでは、KMS キーは保存され、作成されたリージョンでのみ使用できます。組織にデータレジデンシーと主権に関する特定の要件がある場合は、マルチリージョン KMS キーがユースケースに適しているかどうかを検討してください。マルチリージョンキーは、異なる の専用 KMS キー AWS リージョン であり、同じ意味で使用できます。マルチリージョンキーを作成するプロセスは、キーマテリアルを内部の AWS リージョン 境界を越えて移動するため AWS KMS、このリージョン分離の欠如は、組織の主権とレジデンシーの目標と互換性がない可能性があります。これを解決する 1 つの方法は、リージョン固有のカスタマーマネージドキーなど、別のタイプの KMS キーを使用することです。

外部キーストア

多くの組織では、 のデフォルト AWS KMS キーストアは、データ主権と一般的な規制要件を満たす AWS クラウド ことができます。ただし、一部の では、暗号化キーがクラウド環境の外部で作成および維持され、独立した認可および監査パスがあることが必要になる場合があります。の外部キーストアを使用すると AWS KMS、組織が の外部で所有および管理するキーマテリアルを使用して個人データを暗号化できます AWS クラウド。通常どおり AWS KMS API とやり取りしますが、 は、指定した外部キーストアプロキシ (XKS プロキシ） ソフトウェアとのみ AWS KMS やり取りします。その後、外部キーストアプロキシは、 AWS KMS と外部キーマネージャーとの間のすべての通信を仲介します。

データ暗号化に外部キーストアを使用する場合は、 でキーを維持する場合と比較して、追加の運用オーバーヘッドを考慮することが重要です AWS KMS。外部キーストアでは、外部キーストアを作成、設定、維持する必要があります。また、XKS プロキシなど、維持する必要がある追加のインフラストラクチャにエラーがあり、接続が失われた場合、ユーザーは一時的にデータを復号してアクセスできない可能性があります。コンプライアンスおよび規制関係者と緊密に連携し、個人データの暗号化に関する法的および契約上の義務と、可用性と回復性に関するサービスレベル契約を理解します。

AWS Lake Formation

構造化メタデータカタログを使用してデータセットをカタログ化および分類する多くの組織は、これらのデータセットを組織全体で共有したいと考えています。 AWS Identity and Access Management (IAM) アクセス許可ポリシーを使用してデータセット全体へのアクセスを制御できますが、さまざまな機密性の個人データを含むデータセットには、より詳細な制御が必要になることがよくあります。例えば、目的仕様と使用制限 (FPC ウェブサイト) は、マーケティングチームが顧客の住所にアクセスする必要があるが、データサイエンスチームはアクセスできないことを示している場合があります。

データレイクには、元の形式で大量の機密データへのアクセスを一元化するプライバシー上の課題もあります。組織のデータの大部分は 1 か所で一元的にアクセスできるため、データセットの論理的な分離、特に個人データを含むデータセットの論理的な分離が最優先事項となります。 AWS Lake Formation は、単一のソースからであっても、データレイクに含まれる多数のソースからであっても、データを共有するときにガバナンスとモニタリングを設定するのに役立ちます。 AWS PRA では、Lake Formation を使用して、データアカウントの共有データバケット内のデータへのきめ細かなアクセスコントロールを提供できます。

Lake Formation でタグベースのアクセスコントロール機能を使用できます。タグベースのアクセスコントロールは、属性に基づいてアクセス許可を定義する認可戦略です。これらの属性は、Lake Formation で LF タグと呼ばれています。LF タグを使用すると、これらのタグを Data Catalog データベース、テーブル、列にアタッチし、IAM プリンシパルに同じタグを付与できます。Lake Formation は、プリンシパルにリソースタグ値に一致するタグ値へのアクセス権が付与されている場合、これらのリソースに対するオペレーションを許可します。次の図は、LF タグとアクセス許可を割り当てて、個人データへの差別化されたアクセスを提供する方法を示しています。

この例では、タグの階層的な性質を使用します。どちらのデータベースにも個人を特定できる情報 (PII:true) が含まれていますが、列レベルのタグは特定の列を異なるチームに制限します。この例では、LF タグを持つ IAM PII:true プリンシパルは、このタグを持つ AWS Glue データベースリソースにアクセスできます。LOB:DataScience LF タグを持つプリンシパルは、このタグを持つ特定の列にアクセスでき、LOB:MarketingLF タグを持つプリンシパルは、このタグを持つ列にのみアクセスできます。マーケティングは、マーケティングユースケースに関連する PII にのみアクセスでき、データサイエンスチームは、そのユースケースに関連する PII にのみアクセスできます。

AWS Local Zones

データレジデンシー要件に準拠する必要がある場合は、これらの要件をサポートするために、特定の に個人データを保存および処理するリソース AWS リージョン をデプロイできます。また、 を使用することもできます。これはAWS Local Zones、コンピューティング、ストレージ、データベース、その他の一部の AWS リソースを大規模な人口や業界の中心の近くに配置するのに役立ちます。Local Zone は、大都市圏 AWS リージョン に地理的に近い の拡張です。Local Zone に対応するリージョンの近くで、特定のタイプのリソースを Local Zone 内に配置できます。ローカルゾーンは、同じ法的管轄区域内でリージョンが利用できない場合に、データレジデンシー要件を満たすのに役立ちます。ローカルゾーンを使用する場合は、組織内にデプロイされているデータレジデンシーコントロールを検討してください。たとえば、特定のローカルゾーンから別のリージョンへのデータ転送を防ぐためのコントロールが必要になる場合があります。SCPs「ランディングゾーンコントロール AWS Local Zones を使用して のデータレジデンシーを管理するためのベストプラクティス」（AWS ブログ記事) を参照してください。

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 エンドポイントポリシーとセキュリティグループを使用して、組織のデータ境界定義に従ってアクセスを制御できます。信頼された組織内の IAM 原則と AWS リソースのみにサービスエンドポイントへのアクセスを許可する VPC エンドポイントポリシーのサンプルについては、このガイド組織メンバーシップに VPC リソースへのアクセスを要求するの「」を参照してください。

AWS Resource Access Manager

AWS Resource Access Manager (AWS RAM） は、 間でリソースを安全に共有 AWS アカウント し、運用オーバーヘッドを削減し、可視性と監査可能性を提供するのに役立ちます。マルチアカウントセグメンテーション戦略を計画する際は、 AWS RAM を使用して、分離された別のアカウントに保存されている個人データストアを共有することを検討してください。処理の目的で、その個人データを他の信頼されたアカウントと共有できます。では AWS RAM、共有リソースに対して実行できるアクションを定義するアクセス許可を管理できます。へのすべての API コール AWS RAM は CloudTrail に記録されます。また、リソース共有に変更が加えられたときなど AWS RAM、 の特定のイベントについて自動的に通知するように Amazon CloudWatch Events を設定できます。

Amazon S3 の IAM またはバケットポリシーでリソースベースのポリシー AWS アカウント を使用することで、さまざまなタイプの AWS リソースを他の と共有できますが、 AWS RAM にはプライバシーに関するいくつかの追加の利点があります。 は AWS アカウント、データ所有者が 間でデータを共有する方法とユーザーについて、次のような追加の可視性 AWS を提供します。

以前にリソースベースのポリシーを使用してリソース共有を管理し、 AWS RAM 代わりに を使用する場合は、PromoteResourceShareCreatedFromPolicy API オペレーションを使用します。

Amazon SageMaker AI

Amazon SageMaker AI は、ML モデルを構築およびトレーニングし、本番環境対応のホスト環境にデプロイするのに役立つマネージド機械学習 (ML) サービスです。SageMaker AI は、トレーニングデータの準備とモデル機能の作成を容易にするように設計されています。

Amazon SageMaker Model Monitor

多くの組織は、ML モデルのトレーニング時にデータドリフトを考慮しています。データドリフトは、本番データと ML モデルのトレーニングに使用されたデータとの間の意味のある変化、または入力データの時間の経過に伴う意味のある変化です。データドリフトは、ML モデル予測の全体的な品質、精度、公平性を低下させる可能性があります。ML モデルが本番環境で受け取るデータの統計的性質が、トレーニングされたベースラインデータの性質からドリフトすると、予測の精度が低下する可能性があります。Amazon SageMaker Model Monitor は、本番環境の Amazon SageMaker AI 機械学習モデルの品質を継続的にモニタリングし、データ品質をモニタリングできます。データドリフトを早期かつプロアクティブに検出することで、モデルの再トレーニング、アップストリームシステムの監査、データ品質の問題の修正などの是正措置を実装できます。Model Monitor を使用すると、モデルを手動でモニタリングしたり、追加のツールを構築したりする必要性を軽減できます。

Amazon SageMaker Clarify

Amazon SageMaker Clarify は、モデルのバイアスと説明可能性に関するインサイトを提供します。SageMaker Clarify は、ML モデルデータの準備と全体的な開発フェーズで一般的に使用されます。開発者は性別や年齢などの対象属性を指定できます。SageMaker Clarify は一連のアルゴリズムを実行して、それらの属性にバイアスが存在するかどうかを検出します。アルゴリズムが実行されると、SageMaker Clarify はソースの説明とバイアスの測定値を含むビジュアルレポートを提供し、バイアスを修正するステップを特定できるようにします。たとえば、ある年齢グループに対するビジネスローンの例が他の年齢グループと比較してわずかしか含まれていない財務データセットでは、SageMaker は不均衡にフラグを立てて、その年齢グループを嫌うモデルを回避できます。予測を確認し、これらの ML モデルにバイアスを継続的にモニタリングすることで、トレーニング済みのモデルにバイアスがないかを確認することもできます。最後に、SageMaker Clarify は Amazon SageMaker AI Experiments と統合され、モデルの全体的な予測プロセスに最も寄与した特徴量を説明するグラフを提供します。この情報は、説明可能性の結果を達成するのに役立ち、特定のモデル入力がモデルの動作全体に与える影響よりも大きいかどうかを判断するのに役立ちます。

Amazon SageMaker モデルカード

Amazon SageMaker Model Card は、ガバナンスとレポート作成の目的で ML モデルに関する重要な詳細を文書化するのに役立ちます。これらの詳細には、モデル所有者、汎用、意図したユースケース、行われた仮定、モデルのリスク評価、トレーニングの詳細とメトリクス、評価結果が含まれます。詳細については、AWS 「人工知能とMachine Learningソリューションによるモデルの説明可能性」（AWS ホワイトペーパー) を参照してください。

Amazon SageMaker Data Wrangler

Amazon SageMaker Data Wrangler は、データ準備と特徴量エンジニアリングプロセスを合理化するのに役立つ機械学習ツールです。データサイエンティストや機械学習エンジニアが、機械学習モデルで使用するデータを迅速かつ簡単に準備して変換するのに役立つビジュアルインターフェイスを提供します。Data Wrangler を使用すると、Amazon S3、Amazon Redshift、Amazon Athena などのさまざまなソースからデータをインポートできます。その後、300 を超える組み込みデータ変換を使用して、コードを記述することなく、機能をクリーンアップ、正規化、結合できます。

Data Wrangler は、 AWS PRA のデータ準備および機能エンジニアリングプロセスの一部として使用できます。を使用して保管中および転送中のデータ暗号化をサポートし AWS KMS、IAM ロールとポリシーを使用してデータとリソースへのアクセスを制御します。 AWS Glue または Amazon SageMaker Feature Store によるデータマスキングをサポートしています。Data Wrangler を と統合すると AWS Lake Formation、きめ細かなデータアクセスコントロールとアクセス許可を適用できます。Amazon Comprehend で Data Wrangler を使用して、より広範な ML Ops ワークフローの一部として表形式データから個人データを自動的に編集することもできます。詳細については、Amazon SageMaker Data Wrangler を使用して機械学習用の PII を自動的に編集する」（AWS ブログ記事) を参照してください。

Data Wrangler の汎用性により、アカウント番号、クレジットカード番号、社会保障番号、患者名、医療記録や軍事記録など、多くの業界の機密データをマスクできます。機密データへのアクセスを制限するか、編集することを選択できます。

AWS データライフサイクルの管理に役立つ 機能

個人データが不要になった場合は、さまざまなデータストアのデータにライフサイクルポリシーとtime-to-liveポリシーを使用できます。データ保持ポリシーを設定するときは、個人データが含まれている可能性がある以下の場所を考慮してください。

以下の AWS のサービス および 機能は、 AWS 環境でデータ保持ポリシーを設定するのに役立ちます。

AWS のサービス データのセグメント化に役立つ および の機能

データセグメンテーションは、データを別々のコンテナに保存するためのプロセスです。これにより、各データセットに差別化されたセキュリティと認証の対策を提供し、データセット全体の露出の影響範囲を減らすことができます。たとえば、すべての顧客データを 1 つの大きなデータベースに保存する代わりに、このデータをより小さく管理しやすいグループにセグメント化できます。

物理的および論理的な分離を使用して、個人データをセグメント化できます。

論理的な分離と物理的な分離を組み合わせることで、アイデンティティベースおよびリソースベースのポリシーを記述する際の柔軟性、シンプルさ、粒度が向上し、職務機能間での差別化されたアクセスをサポートします。たとえば、1 つの S3 バケットで異なるデータ分類を論理的に分離するポリシーを作成することは、運用上複雑な場合があります。各データ分類に専用の S3 バケットを使用すると、ポリシーの設定と管理が簡素化されます。

AWS のサービス データの検出、分類、カタログ化に役立つ および の機能

一部の組織では、抽出、ロード、変換 (ELT) ツールを環境で使用して、データをプロアクティブにカタログ化していません。これらのお客様は、保存および処理するデータと、その構造化 AWS および分類方法をよりよく理解したいという初期のデータ検出段階にいるかもしれません。Amazon Macie を使用して、Amazon S3 の PII データをよりよく理解できます。ただし、Amazon Macie は、Amazon Relational Database Service (Amazon RDS) や Amazon Redshift などの他のデータソースの分析には役立ちません。2 つのアプローチを使用して、大規模なデータマッピング演習の開始時に最初の検出を高速化できます。