GDPR：GDPRとは何か、なぜ重要なのか、組織が順守するためにSnowflakeがどのように役立つのか

注：本記事は(2022年4月27日)に公開された(GDPR: What It Is, Why It Matters, and How Snowflake Enables Your Organization to Stay Compliant)を翻訳して公開したものです。

EU一般データ保護規則（GDPR）は、他の要件の中でも特に、個人データの収集、処理、消去の方法を規定しています。今回は、GDPRの概要、Snowflakeが支援する一般的な「忘れられる権利」オプション、一般的なリファレンスアーキテクチャパターンのほか、組織内のGDPRコンプライアンス順守義務をサポートするのに役立つアーキテクチャをSnowflakeのパワフルで使いやすい機能を使用して実装する際のベストプラクティスを紹介します。

GDPRは、欧州の個人データの保護と処理を管理するEUの規制です。GDPRは、個人データの保護、データの処理方法の規制方法、データを処理するエンティティの監視に重点を置いており、常にデータ主体の権利を重視しています。

ただし、これらの規制に従う必要があるのは欧州諸国だけではありません。EU市民に商品やサービスを提供したり、インテントベースのマーケティング戦術を追跡したり、データシェアリングやその他のデータ処理を行ったりするなどして、ビジネスがEUのデータに何らかの形で触れる場合は、GDPRの要件を満たすことが法的に義務付けられる可能性が高くなります。企業がこれに従わない場合、最大2,000万ユーロの罰金、または前年の世界の年間収益の4%など、高額の罰金が科される可能性があります。

GDPRは、EU内の自然人（つまり、エンティティではなく個人）を保護します。GDPRは、直接的または間接的を問わず、個人の特定に使用される可能性のある個人データまたは情報を対象としています。仮名化は元に戻すことができるため、匿名データ（トークン化または暗号化）も個人データとみなされます。

EU圏外に居住するEU市民も、GDPRの対象として保護されます。

データ主体：企業、組織、またはサービスプロバイダーが個人データを保持しているEUまたは英国に居住する識別可能な自然人

処理者：管理者の指示のもと、データを処理するエンティティ（例：Snowflake）

管理者：個人データ処理の目的と方法を決定するエンティティ（例：Snowflakeの顧客）

組織は、GDPRを補足としてではなく、リファレンスアーキテクチャの設計プロセスの一部としてみなす必要があります。Snowflakeは、処理者として組織がGDPRに準拠する上で役立つ機能をいくつか提供していますが、最終的にGDPRの順守義務をサポートするアーキテクチャを設計するのは、管理者である組織の責任になります。

Snowflakeの顧客は、Snowflakeとは関係なくGDPRに準拠する責任があります。Snowflakeは、個人データを取得、修正、削除、または制限するために導入できるいくつかのコントロールを顧客に提供しています。これらは、Snowflakeのデータに関してデータ主体または該当するデータ保護当局からの要求に対応する義務を含む、顧客のGDPR内のコンプライアンス順守義務の遂行に役立てることができます。技術的機能に加えて、顧客とSnowflakeは、GDPR下の各当事者の義務の概要を示すデータ保護条件にも同意します。これには、処理者としてのSnowflakeのデータ使用における制限、セキュリティ義務、インシデント対応、サービスのサブ処理者のリスト、そのリストの更新、データ主体の要求を完了するためのサポートが含まれます。

GDPRコンプライアンスを強化するために一般的に使用されるSnowflake機能には、タイムトラベル、クローン作成、データ分類、スワップ、行アクセスポリシー、動的マスキングポリシー、安全なビュー、匿名化テクニック、エンタープライズSIEM統合などがあります。

これらの個々の機能を構成要素として考えて、組織の要件に応じて、これらのうちの1つまたは複数を使用して必要なソリューションを構築できます。

特に「消去される権利（忘れられる権利）」を処理する際は、綿密に作成されたデータベースアーキテクチャがなければ、GDPRコンプライアンスは非常に難しいものとなります。個人データを要求した後、一般的に組織は30日、場合によっては90日後には個人データをデータベースから削除する必要があります。

組織は、データをどのように忘れるか、フラグを立てるか、匿名化するか、削除するかを決定する必要があり、データ監査のための明確なガイドラインを用意する必要があります。

準備作業は、機密データ、非機密データ、個人データなど、すべてのデータにタグを付けることから始めるのが基本です。Snowflakeのオブジェクトのタグ付けとデータ分類機能は、重要なデータを容易に判断し、それに応じてタグ付けするのに役立ちます。複数のデータレイクにまたがる大量のデータを持つ大規模な組織では、特定の状況が発生したときに個人データを簡単に識別できる効果的なカタログ戦略が必要です。

どのデータアーキテクチャでも、個人データを簡単に識別できる必要があります。それには複数の方法がありますが、最も一般的なアプローチは、個人データを個別のアカウント、データベース、スキーマ、またはテーブルレベルで整理することです。

例えば、Snowflakeの顧客のテーブルに300個の列があり、そのうちの50個に顧客が個人データとして識別したデータが含まれている場合、顧客は2つの異なるテーブル（Customer_personal_dataとCustomer_Non_personal_data）を作成し、非インテリジェントキーを使用してそれらをリンクできます。この処理により、Customer_Non_personal_dataを危険にさらすことなく、Customer_personal_dataテーブルをドロップして、すべての個人データを削除することができます。これらのパラメータを事前に設定することで、包括的なデータテーブルの更新コストが削減されます。

このデータモデリングの全体像については今回のブログ投稿では取り上げません。この概要は、あくまで可能性のある技術のアイデアを提供するものであり、主にグリーンフィールドの実装に適用されるものとなっています。

データの削除は、ETLプロセス中にオンラインテーブルからデータウェアハウスのレコードを削除することを要求する法解釈です。要件に応じて、テーブルレベルでタイムトラベル/データ保持時間の設定を設定し、GDPRの義務を果たす時間枠でデータを削除することでこれを遂行します。

Snowflakeの3つのタイプのテーブル：

• Permanentテーブル：データ保持期間を32時間（プラス7日間のフェールセーフ）に設定
• Transientテーブル：データ保持期間を1日（フェールセーフなし）に設定
• Temporaryテーブル：データ保持期間を1日（フェールセーフなし）に設定

削除する必要があるデータをマークする監査データを活用して、月1回バッチ削除を実行することを検討します。

ETLプロセス中にデータウェアハウスからレコードを削除すると同時に、監査目的で「忘れられた」データの別バージョンを維持する、というデータ削除メソッドがあります。

• Transientテーブル（cust_phi_cloneなど）を作成し、個人データを含む本番テーブル（customer_phiなど）を複製します。ゼロタイムトラベルに設定できます。
• 保持する必要のあるデータのコピーを作成します（Snowflake内外問わず）。
• 調査中のデータを両方のテーブルから削除します。このデータは残りません。この方法により、データのタイムトラベルも取り除くことができます。このデータを復元できるのは、監査目的でバックアップのスナップショップから復元する場合のみです。
• 両方のテーブルをスワップします。基本的に、スワッピングすると本番テーブルからタイムトラベルが削除されます。
• cust_phi_cloneへのアクセス許可を管理者のみに制限します。

安全なビューと行アクセスポリシーを使用して、論理的な削除パターンまたは患者のオプトアウトに対処します。患者が自身の情報の共有をオプトアウトする場合、処方者が情報を公開したくない場合、または18歳未満の患者の情報を共有できない場合は、この方法で処理できます。

規制対象となり得る個人データの匿名化要件を満たすには、ユーザーログインの役割に基づいて特定の行へのアクセスを制限する行アクセスポリシーを実装できます。例えば、マーケティング部門の従業員が販売データを閲覧できないようにするケースがこれに該当します。

加えて、動的データマスキングポリシーはオプションとなります。ユーザーがログインしている役割に応じて、データをマスキングまたは編集できます。例えば、人事部の従業員には、給与の詳細のみの閲覧を許可します。

データ主体の要求（誰が、いつ、どのデータを削除したか、ロールバックしたかなど）を追跡する監査制御フレームワークを維持することもできます。これは、監査要求や、偶発的なロールバックが起きた場合に個人データを削除する際にも役立ちます。Snowflakeの新機能であるアクセス履歴では、誰がいつどのデータにアクセスしたか（おおまかなデータ系統を使用）を簡単に判断できます。この機能によって、組織は迅速に自信を持って監査要求に応えることができます。

監査目的のデータのバックアップを保持したい場合などは、例えば主要顧客のデータのタイムトラベルを32日間維持するといったことが考えられます。

スケジュールされたタスクを使用して、次のように月次バックアップを作成します。

• バックアップデータベースへのアクセス許可を、一部の管理者のみに制限します。
• （組織のポリシー/GDPR制限に基づいて）古いデータベースを削除する自動プロセスを開発します。

注：これらの例の一部では、ユーザーのデータは削除（物理的に削除）されません。むしろ、監査や「忘れられない」情報を可能にするため論理的な削除が使用されています。各企業の法務チームは、対象となる法的要件および規制要件を考慮して、それらに十分対応できているかを判断する必要があります。

安全なデータシェアリングができれば、ビジネスエコシステムのアカウント間でデータをコピーしたり転送したりしてアクセスを許可する必要がなくなり、誰もが厳密に管理されたライブのデータセットにアクセスできるようになります。

安全なデータシェアリングを使用すれば、国内外のデータセットにアクセスできます。「このサブジェクトエリアデータは国外に持ち出せない」などのシナリオに対処するアーキテクチャもあります。

リージョンデータシェアリング - クロスリージョンのデータシェアリング

上記のパターンは、顧客がGDPRに準拠するためにSnowflakeが提供しているオプションです。これは法的なアドバイスではありません。ここに記載されている内容は、GDPRを含め、特定の方法が規制に準拠することを証明または保証することを意図したものではありません。各顧客は、該当するプライバシー要件を確認し、社内のプライバシーチームと法務チームによる確認に基づいて、許容可能なデータソリューションを決定する必要があります。Snowflakeは、契約前、契約中、契約後のいずれにおいても、特定のソリューションが適用される法的要件または規制要件のコンプライアンスを満たしていることを保証いたしません。