AWS Glue を使用した個人情報の検出・マスキング・編集および Amazon OpenSearch Service へのロード

大企業や中小企業を問わず、多くの組織がアマゾン ウェブ サービス(AWS)上で分析ワークロードの移行と近代化に取り組んでいます。AWS への移行にはさまざまな理由がありますが、主な理由の 1 つは、インフラストラクチャのメンテナンス、パッチ適用、モニタリング、バックアップなどに時間を費やす代わりに、フルマネージドサービスを利用できることです。リーダーシップと開発チームは、現在のインフラストラクチャのメンテナンスではなく、現在のソリューションの最適化や新しいユースケースの実験などにより多くの時間を費やすことができます。

AWSを利用することでスピードを上げられる一方で、スケール拡大に伴い受信および処理データに対して責任を持つ必要性が生じます。これらの責任には、データプライバシー法および規制を順守すること、個人を特定できる情報 (PII) や上流のソースからの保護された健康情報 (PHI) などの機密データを非公開のまま保存することが含まれます。

この投稿では、データプライバシーの懸念に対処するために大量の開発時間を費やす必要なく、組織のデータプラットフォームをスケールし続けることができる方法を示す、ハイレベルなアーキテクチャと具体的なユースケースについて説明します。個人を特定できる情報 (PII) データを Amazon OpenSearch Service にロードする前に、AWS Glue を使用して検出、マスキング、編集を行います。

ソリューションの概要

次の図は、高レベルのソリューションアーキテクチャを示しています。 設計のすべてのレイヤーとコンポーネントは、AWS Well-Architected Framework Data Analytics Lens に沿って定義されています。アーキテクチャは、次のコンポーネントで構成されています。

ソースデータ

データは、データベース、ファイル転送、ログ、SaaS(Software as a Service) アプリケーションなど、数十から数百のソースから送られてくる可能性があります。組織は、これらのチャネルを通じて流れ込んできたデータや、ダウンストリームのストレージやアプリケーションに入ったデータを常にコントロールできているとは限りません。

取り込み: データレイクのバッチ、マイクロバッチ、ストリーミング

多くの組織では、バッチ、マイクロバッチ、ストリーミングジョブなど、さまざまな方法でソースデータをデータレイクに取り込んでいます。 例えば、Amazon EMR、AWS Glue、AWS Database Migration Service (AWS DMS) は、Amazon Simple Storage Service (Amazon S3) 上のデータレイクにシンクするバッチおよび/またはストリーミング操作を実行するために使用できます。Amazon AppFlow は、さまざまな SaaS アプリケーションからデータレイクにデータを転送するために使用できます。 AWS DataSync と AWS Transfer Family は、さまざまなプロトコルを介してデータレイクへのファイルの移動を支援できます。 Amazon Kinesis と Amazon MSK にも、Amazon S3 上のデータレイクに直接データをストリーミングする機能があります。

S3 データレイク

データレイクに Amazon S3 を使用することは、モダンなデータ戦略に沿っています。Amazon S3 は、パフォーマンス、信頼性、可用性を犠牲にすることなく、低コストのストレージを提供します。

このアプローチでは、必要に応じてコンピューティングリソースをデータに紐づけ、実行に必要な容量分のみを支払うことができます。このアーキテクチャでは、機密データを含む可能性のある様々なソース(内部および外部)から生データが来ることがあります。

AWS Glue Crawler を使用することで、データを発見およびカタログ化できます。これによりテーブルスキーマが構築され、最終的には AWS Glue ETL と PII 変換を用いたデータレイク内の機密データ検出、マスクおよび編集が容易になります。

ビジネスコンテキストとデータセット

アプローチの価値を示してみましょう。あなたは金融サービス機関のデータエンジニアリングチームのメンバーであるとします。要件は機密データを検出し、組織のクラウド環境に取り込まれる際にマスキングすることです。このデータはダウンストリームの分析プロセスで利用されます。将来的には、内部銀行システムから収集したデータストリームに基づいて、過去の支払い取引を安全に検索できるようになります。運用チーム、顧客、インターフェースアプリケーションからの検索結果は、機密フィールドについてはマスキングする必要があります。

次の表は、このソリューションで使用されるデータ構造を示しています。明確化のために、生の列名を整理された列名にマッピングしています。このスキーマ内の複数のフィールド(名、姓、社会保障番号(SSN)、住所、クレジットカード番号、電話番号、Eメール、IPv4アドレスなど)が機密データと見なされることに注意してください。

ユースケース: OpenSearch Service への読み込み前の個人情報バッチ検出

このアーキテクチャを実装しているお客様は、さまざまな分析を大規模に実行するために、Amazon S3 上にデータレイクを構築しています。このソリューションは、OpenSearch Service へのリアルタイム取り込みが不要で、スケジュールで実行される、またはイベントによってトリガーされるデータインテグレーションツールを使用することを計画しているお客様に適しています。

Amazon S3 にデータレコードが到着する前に、データレイクにすべてのデータストリームを信頼できる形で安全に取り込むための取り込みレイヤーを実装します。 Kinesis Data Streams は、構造化および半構造化データストリームの高速な取り込みのための取り込みレイヤーとして導入されます。これらの例としては、リレーショナルデータベースの変更、アプリケーション、システムログ、クリックストリームなどがあります。変更データキャプチャ (CDC) ユースケースの場合、Kinesis Data Streams を AWS DMS のターゲットとして使用できます。機密データを含むストリームを生成するアプリケーションやシステムは、Amazon Kinesis Agent、AWS SDK for Java、Kinesis Producer ライブラリのいずれかの 3 つのサポートされている方法を介して Kinesis Data Streams に送信されます。最後のステップとして、Amazon Kinesis Data Firehose がリアルタイムに近いバッチデータを高い信頼性で S3 データレイクのデスティネーションにロードするのに役立ちます。

次のスクリーンショットは、データビューアを介してKinesis Data Streams を通過するデータフローと、raw S3 プレフィックスに着地するサンプルデータの取得方法を示しています。このアーキテクチャでは、データレイクの基礎で推奨されている S3 プレフィックスのデータライフサイクルに従いました。

次のスクリーンショットの最初のレコードの詳細からわかるように、JSON ペイロードは前のセクションと同じスキーマに従っています。 Kinesis データストリームに流れ込む改変されていないデータが見えます。これは後の段階で改変されます。

データが Kinesis Data Streams に収集・取り込まれ、Kinesis Data Firehose を使用して S3 バケットに配信された後は、アーキテクチャの処理レイヤーが引き継ぎます。 パイプラインでの機密データの検出とマスキングを自動化するために、AWS Glue PII transform を使用します。 次のワークフロー図に示すように、AWS Glue Studio で変換ジョブを実装するために、コード不要の視覚的 ETL アプローチを採用しました。

まず、pii_data_db データベースから raw のソース Data Catalog テーブルにアクセスします。このテーブルは、前のセクションで提示されたスキーマ構造を持っています。処理済みの raw データを追跡するために、ジョブブックマークを使用しました。

AWS Glue Studio のビジュアル ETL ジョブで AWS Glue DataBrew レシピを使用して、2つの日付属性を OpenSearch で期待されるフォーマットと互換性のある形式に変換します。これにより、完全なノーコード体験が実現できます。

Detect PIIアクションを使用して、機密性の高いカラムを特定します。AWS Glue には、選択したパターン、検出閾値、データセットの行のサンプル部分に基づいてこれを判断させます。この例では、アメリカ合衆国 (SSN など)に特に適用されるパターンを使用しましたが、他の国の機密データは検出されない場合があります。

使用例に適用できる利用可能なカテゴリと場所を確認するか、AWS Glue の正規表現 (regex) を使用して、他の国の機密データの検出エンティティを作成できます。 AWS Glue が提供する適切なサンプリング方法を選択することが重要です。この例では、ストリームから入ってくるデータにはすべての行に機密データが含まれていることがわかっているため、データセット内のすべての行を 100% サンプリングする必要はありません。下流のソースに機密データを一切許可したくない場合は、選択したパターンのデータを 100% サンプリングするか、データセット全体をスキャンして個々のセルに対処し、すべての機密データが検出されるようにすることを検討してください。サンプリングから得られるメリットは、スキャンする必要のあるデータ量が減るため、コストが削減されることです。

Detect PII アクションを使用すると、機密データをマスキングする際にデフォルトの文字列を選択できます。この例では、******** という文字列を使用しています。

apply mapping オペレーションを使用して、ingestion_year、ingestion_month、ingestion_day などの不要なカラムの名前変更や削除を行います。 このステップでは、あるカラム (purchase_value) のデータ型を文字列から整数に変更することもできます。

この時点から、ジョブは OpenSearch Service とAmazon S3 の2つの出力先に分割されます。OpenSearch Service のプロビジョニングされたクラスターは、Glue 用の組み込み OpenSearch コネクタを介して接続されています。書き込み先の OpenSearch インデックスを指定し、コネクタが資格情報、ドメイン、ポート設定を処理します。下のスクリーンショットでは、指定されたインデックス index_os_pii に書き込んでいます。

マスクされたデータセットは、キュレーションされた S3 プレフィックスに格納します。 そこでは、特定のユースケースに対して正規化され、データサイエンティストによる安全な利用やアドホックなレポートのニーズに対応できるようにデータが用意されています。

統一的なガバナンス、アクセスコントロール、監査証跡をすべてのデータセットと Data Catalog テーブルに適用するには、AWS Lake Formation を使用できます。これにより、AWS Glue Data Catalog テーブルと基礎となるデータへのアクセスを、必要なアクセス許可を付与されたユーザーとロールに限定できます。バッチジョブが正常に実行された後、OpenSearch Service を使用して検索クエリやレポートを実行できます。次のスクリーンショットに示すように、パイプラインはコード開発作業なしで自動的に機密フィールドをマスクしました。

バッチジョブが正常に実行された後、OpenSearch Serviceを使用して検索クエリやレポートを実行できます。次のスクリーンショットに示すように、パイプラインはコード開発作業なしで自動的に機密フィールドをマスクしました。

操作データから、前のスクリーンショットのように、クレジットカードプロバイダー別の1日当たりの取引数などのトレンドを特定できます。また、ユーザーが購入を行う場所とドメインも判断できます。transaction_date 属性により、時間の経過とともにこれらのトレンドを確認できます。次のスクリーンショットは、取引情報が適切に編集されたレコードを示しています。

Amazon OpenSearch にデータをロードする他の方法については、Amazon OpenSearch Service へのストリーミングデータをロードする を参照してください。さらに、機密データは他の AWS ソリューションを使用して発見およびマスキングすることもできます。

たとえば、Amazon Macie を使用して S3 バケット内の機密データを検出し、次にAmazon Comprehend を使用して検出された機密データを編集することができます。詳細については、AWSサービスを使用した PHI および PII データの検出の一般的な手法を参照してください。

まとめ

この投稿では、環境内の機密データを扱うことの重要性と、組織のスケールを速くする一方でコンプライアンスを維持するためのさまざまな方法とアーキテクチャについて説明しました。これで、データを検出、マスク、編集してAmazon OpenSearch Service にロードする方法がよく理解できるはずです。

著者について

Michael Hamilton は、AWS 上でのエンタープライズ顧客の分析ワークロードの現代化と簡素化を支援する上級ソリューションアーキテクトです。仕事以外の時間では、マウンテンバイクに乗ったり、妻と3人の子どもたちと過ごすのが楽しみです。

Daniel Rozoは、オランダの顧客を支援する AWS のシニアソリューションアーキテクトです。 彼の情熱は、シンプルなデータとアナリティクスのソリューションのエンジニアリングと、顧客が現代のデータアーキテクチャに移行するのを助けることです。 仕事の外では、テニスをしたり自転車に乗ったりしています。

本投稿はソリューションアーキテクトの榎本が翻訳いたしました。原文はこちらです。