データエンジニアリングの設計パターン

第7章. データ・セキュリティ・デザイン・パターン

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

間違いなく、 、データバリューとデータフローデザインパターンを使ってこれまで作成してきた、アクセスしやすく価値のあるデータセットは、重要なビジネス資産である。また、悪意のあるものも含め、他の市場関係者にとっては羨望のオブジェクトでもある。

その結果、データエンジニアリングはデータ処理の仕事を書くだけでは済まなくなった。今日では、データ・エンジニアはセキュリティの側面についても考える必要がある。ここ数年、大きな注目を集めているのがコンプライアンスだ。欧州の一般データ保護規則（GDPR） や米国のカリフォルニア州消費者プライバシー法（CCPA） のようなデータプライバシー法は、あなた（データ提供者）と顧客（データ消費者）の境界を正確に定義している。

もうひとつ重要なのは、アクセス・コントロールだ。データセットを組織内でオープンにしていて、別のチームが誤って上書きしてしまったとしよう。その結果、あなたや下流のコンシューマに甚大な影響が及ぶ可能性がある。

データ保護も重要なセキュリティの一つである。テーブルやファイルシステム内のパスなど、データセットの場所に誤ってアクセス権を与えてしまったとしても、ユーザがデータを読み取れるようになるわけではない。暗号化のような特別な保護レイヤーを使った場合、コンシューマがデータセットにアクセスするには復号化キーも必要になる。

最後に、データ・セキュリティは接続にも関係する。人間であれアプリケーション・ユーザであれ、仕事の結果を読み書きするためにはデータストアに接続する必要がある。Gitリポジトリに資格情報を保存することは、データ漏洩のリスクを高めることになり、最善のアイデアではないことは明らかだ。その代わりに、外部の安全な場所に保管すべきだ。

怖いと思うかもしれないが、心配はいらない。この章で紹介するデザインパターンは、紹介した問題に対処し、実際のアプリケーションのユースケースを与えてくれる。この章ではまず、データセットにおけるユーザの忘れられる権利を遵守する方法を示す、データ削除パターンから始める。次に、テーブルとクラウドリソースに対するきめ細かなアクセスパターンを発見する。その次は、暗号化と匿名化のテクニックでデータセットを保護するデータ保護パターンだ。最後に、接続性の問題に対処する2つのアプローチを紹介する。ひとつは実際の資格情報の代わりに参照を使用するもので、もうひとつはIDベースのアクセスに依存するものだ。

うまくいけば、最初のカテゴリーであるデータ削除を探求し始める準備ができたと感じられるだろう！

データ削除

個人情報保護法（Privacy ）やGDPRなどの規制では、いくつかの重要なコンプライアンス要件が定義されている。これらの重要な要件の1つは、個人データの削除要求に焦点を当てたもので、ユーザから削除要求を受けた場合、ユーザのデータを削除しなければならない。この最初のセクションでは、この問題に対処する2つの実装アプローチを紹介する。

パターンバーチカル・パーティショナー

スマートなデータ整理やワークフローの分離は、最も困難な問題でも解決できることが多い。この規則は最初のデータ削除パターンに適用される。

問題

あなたは最近、、新しい個人データ除去パイプラインの最初の設計ドキュメントを発表した。あなたの点は非常に熱狂的だったが、何人かは重要なストレージのオーバーヘッドを指摘した。あなたのデータセットのいくつかの列は不変性である。別の言い方をすれば、それらは決して変化しないが、同時に各レコードに存在する。このような属性の例としては、誕生日や個人ID番号がある。 ...