プロンプトと適用範囲
あるデータレイクのParquetファイル内に公開列と機密列が存在します。チームは、プロジェクション、述語プッシュダウン、圧縮を維持しながら、機密データとメタデータを暗号化したいと考えています。フッターの暗号化、列鍵、鍵の管理・保管、読み取り認可、レガシーリーダーの挙動、ローテーションのリカバリを設計してください。
この質問はParquet Modular Encryption仕様の機能について議論するものであり、すべてのエンジンや言語バインディングが同一の鍵設定をサポートしていることを前提とするものではありません。
面接官がテストしていること
- 暗号化されたフッター、暗号化された列、およびページのみの保護を区別できているか。
- マスターキーをファイル内に保存するのではなく、KEK、DEK、鍵メタデータ、KMS権限が分離されているか。
- 暗号化されたフッターがスキーマ、統計情報、述語プッシュダウン、レガシーリーダーにどのように影響するかを理解しているか。
- ローテーション、失効、書き換え、および観測可能な復号失敗が一貫して設計されているか。
明確化のための質問
- どの列が機密対象であり、スキーマ、行グループ（row group）、統計情報も隠す必要がありますか？
- クエリエンジンにはどの列が必要であり、それらのエンジンは列鍵とフッター復号をサポートしていますか？
- 鍵の管理・保管は中央サービス、クラウドHSM、または呼び出し元から注入される鍵のいずれですか？
- ファイルはアカウント間またはリージョン間で複製されますか。またバックアップはどのように復号権限を取得しますか？
- ローテーションの対象は新規ファイル、履歴データの書き換え、または即時失効のどれですか？
30秒での回答
「Parquet Modular Encryptionはカラムナー機能を維持しながらファイルデータとメタデータを保護できますが、暗号化されたフッターは鍵を持たないリーダーに対してスキーマと行グループ情報を隠します。私ならKMSマスターキーをファイル鍵や列鍵から分離し、列ごとにリーダーを認可します。レガシーリーダーはファイルを破損と呼ぶのではなく、未サポートの暗号化として報告すべきです。ローテーションでは新しくラップされた鍵で新規ファイルを書き込み、履歴を制御しながら書き換え、鍵バージョンと失敗を記録します。また、機能マトリックスを用いてエンジンごとに述語プッシュダウンを検証する必要があります。」
ステップごとの設計
1. 保護範囲の選択
フッター暗号化は行グループや列チャンクを含むFileMetaDataを保護し、列暗号化では機密列ごとに異なる鍵を使用できます。フッターが平文のままであれば、暗号化されたページを読み取れなくてもリーダーがスキーマや統計情報を確認できる場合があります。脅威モデルに基づいて範囲を選択します。
2. 鍵の責務の分離
KMSまたはHSMが鍵暗号化鍵（KEK）を保存します。書き込み処理ではデータ暗号化鍵（DEK）を生成または取得し、保護された鍵メタデータをファイル内に保存します。リーダー認可サービスはメタデータを解決し、許可された鍵のみをアンラップするようKMSに要求します。ファイルには直接使用可能なマスターキーを含めてはなりません。
3. クエリ機能の評価
Apache Parquetのドキュメントには、モジュラー暗号化によってプロジェクション、述語プッシュダウン、エンコーディング、圧縮を維持しながら、データとメタデータを暗号化および認証できると記載されています。ただし、クエリエンジンはまず関連する鍵を必要とします。暗号化されたフッターは、鍵を持たないスキャナーがスキーマや統計情報を読み取るのをブロックする可能性があるため、公開列のみのプロジェクション、機密列のフィルター、混合プロジェクションをテストします。
KMS KEK -> wraps file/column DEK -> protected key metadata
reader authorization -> unwrap allowed DEK -> decrypt footer/pages4. ファイルとレガシーリーダーの識別
暗号化フッターファイルは異なるマジックバイトを使用します。平文ファイルがPAR1を使用するのに対し、Apache ParquetではPAREが文書化されています。レガシーリーダーは暗号化されたファイルを未サポートと分類することがあります。クエリ実行時に曖昧な破損エラーを待つのではなく、レジストリやプローブで機能を明示します。
5. ローテーションと失効の設計
ローテーションはまず新規ファイルに適用する必要があります。新しいDEKは新しいKEKによってラップされ、古いファイルは保持ポリシーに従って書き換えられます。即時失効を行うとKMSはアンラップを拒否し、読み取りは失敗します。プラットフォームには書き換えキュー、鍵バージョン、およびリカバリ手順が必要です。中断によって半分暗号化されたファイルが残らないよう、一時ファイルに書き換えてからアトミックに置換します。
6. レイヤーごとの障害の観測
ファイルID、フッターまたは列の鍵バージョン、プリンシパル、KMSレイテンシ、復号失敗のタイプ、およびクエリ対象の列を記録します。平文の鍵や値をログに出力してはなりません。アラートと修復のために、認可拒否、鍵の欠落、認証タグの失敗、未サポートのレガシーリーダー、ファイル破損を区別します。
質の高い模範解答
「脅威モデルからフッターを隠すかどうかを選択します。モジュラー暗号化はフッター、列、ページを保護でき、フッター暗号化はスキーマと統計情報を隠し、列鍵は機密列へのアクセスを制限します。KMSがKEKを保持し、ファイルまたは列のDEKは保護されたメタデータを介して参照され、リーダーは認可後にのみアンラップします。機能マトリックスで公開プロジェクション、機密フィルター、述語プッシュダウンをテストします。平文のPAR1に対するPAREにより、プラットフォームはレガシーリーダーのリスクを早期に識別できます。ローテーションでは新規ファイル、制御された書き換え、アトミックな置換を使用し、鍵バージョンと失敗クラスを記録します。失効にはKMS拒否とリカバリキューを使用します。」
よくある間違い
- ファイルにKEKを直接書き込む → ファイルを所持しているだけで復号可能になる → 保護された鍵メタデータのみを保存する。
- フッターを評価せずに列を暗号化する → スキーマと統計情報が漏洩する可能性がある → 脅威モデルからフッターモードを選択する。
- すべてのエンジンが列鍵をサポートしていると仮定する → 本番クエリで機能ギャップが露呈する → エンジンとバインディングのマトリックスを維持する。
- ローテーション中にインプレースでファイルを上書きする → 中断により読み取り不能な不完全な出力が残る → 一時出力を書き込んでアトミックに置換する。
- 認証の失敗をファイル破損と呼ぶ → 調査が誤った方向に進む → KMS、認可、タグ、フォーマットのエラーを区別する。
フォローアップ質問と回答
フッターの暗号化によって述語プッシュダウンは無効になりますか？
必ずしもそうではありません。フッターと必要な列鍵を取得した後、フォーマットはカラムナー読み取りと述語プッシュダウンを維持できます。フッター鍵を持たないスキャナーは統計情報を読み取れません。実際の挙動はエンジンの暗号化サポート状況に依存します。
なぜ列レベルの鍵を使用するのですか？
プリンシパルによって異なる列の読み取りが許可される場合があるためです。列鍵は認可の範囲をファイル全体から機密列へと絞り込み、公開列へのアクセスを許可する際のエクスポージャーを低減します。
レガシーリーダーはPAREをどのように処理すべきですか？
モジュラー暗号化がサポートされていないことを明確に報告し、オペレーターに互換性のあるリーダーまたは復号・書き換えパスを案内すべきです。PAREファイルを破損したPAR1ファイルとして暗黙的に扱ってはなりません。