At Rest暗号化

安静時の暗号化

1）なぜ必要なのか、何を正確に守るのか

定義。残りの部分での暗号化は、メディア（ディスク、スナップショット、バックアップ、オブジェクト、ログ、メモリダンプ）に書き込まれたデータの保護であり、物理メディアまたは「raw」ストレージへの不正アクセスがコンテンツを明らかにしないようにします。

• ブロック/ファイルボリューム、オブジェクトストレージ、データベース、キュー/キャベレ、キャッシュダンプ、ログ/トレイル、バックアップ、エクスポート/インポート、VM/コンテナスナップショット、カーネル/プロセスダンプ、スワップ/スワップ。
• マルチリースシナリオ：クライアント/プロジェクト/環境間の分離。

私たちが完全にカバーしていないこと：メモリ内のセッションの盗難、ライブプロセスへの攻撃、アプリケーションの脆弱性、資格情報の侵害。これには、機内暗号化、強力な認証/認可、権利最小化および監視が必要です（関連記事：「認証と認可」、「署名と確認要求」を参照）。

2）脅威モデルと制御目標

• メディアの紛失/盗難（ディスク、テープ、USB、開発者デバイス）。
• バックアップ/スナップショット/ログへの不正アクセス。
• プラットフォーム/ハイパーバイザ/ストレージノードレベルでの権限の乱用。
• 構成エラーのテナントを横断します。
• 「散らばった」一時的なファイルやダンプは、アーティファクトや画像に該当します。

1.媒体のデータの機密性。

2.テナント/環境の暗号化の分離。

3.鍵管理性（作成、保管、回転、失効）。

4.Auditability（誰がキーを使用し、いつ）。

5.インシデント発生時の運用リスクの最小化。

3）アーキテクチャの基礎

デフォルトではすべてを暗号化します。オプトアウトは、リスクレベルで例外なく許可されていません。
キー階層（エンベロープ暗号化）。ルート/KEK→DEK（データ暗号化キー）→データベースオブジェクト/ファイル/ページ。
信頼の源としてのKMS/HSM。KMS/HSMでのKEK生成とストレージ、キーのラッピング/展開操作がそこで行われます。
テナントごと/データセットキー。分離および回転の条件のための粒度。

職務の分離。プラットフォームコマンド≠テナントキー所有者；最小権限（PoLP）

暗号アジリティ。アルゴリズム/キー長を安全に移行する機能。
イベントではなく、プロセスとしての回転。キーとデータは「ローリング」交換をサポートする必要があります。

4）暗号化アルゴリズムとモード

オブジェクト/ファイル/レコードの場合：AES-256-GCMまたはAES-256-SIV（認証付きAEAD）。
ブロックデバイス/ボリュームの場合：AES-XTS-256/512（ブロックの順列に対する保護；AEADではありません-整合性が重要なMACでファイル形式を使用します）。

• TDE （Transparent Data Encryption） движка： Oracle TDE、 SQL Server TDE、 MySQL/InnoDB TDEの詳細。
• フィールド/ライン暗号化（FPE/決定論的暗号化）-暗号化されたフィールドの検索機能/ジョイン；慎重に適用してください。
• キー生成とストレージ：KEK-KMS/HSM；DEK-短命のアプリケーションのメモリで、ストレージ中に-唯一のラップ。

5）主な階層とKMS/HSM

1.ルートキー（法定、HSM/KMS）。HSM/KMSの周囲を離れません。

2.KEK（キー暗号化キー）。プロジェクト/環境/テナント向け。DEKライフサイクルを管理します。

3.DEK（データ暗号化キー）。オブジェクト/ファイル/テーブル/セグメントごと。短命、ノンストップ回転。

• すべてのラッピング/デプロイ操作は、監査を伴うKMS APIを介して行われます。
• 政治家：誰がキーを「制御」できるキー≠を「使用」することができます。
• 主要なジオディストリビューション：pin-to-region+dual-control for inter-region。
• ハイリスクなオペレーションには「2点検」モデル（2オペレータ）が可能です。
• 強力なレベルを分離するには-テナントごとに別々のキーリング。

6）回転、リコールおよび承諾

DEK回転：透明で一定（オブジェクト/ページレベルでの転がり再暗号化）。
KEK回転：周期的（例えば、6-12ヶ月ごと）+侵害された疑いがある場合は即時リコール。
アクセスの取り消し：KMSポリシーを通じて；ブロック、unwrap操作=データの即時の「暗号破壊性」。
監査ログ：who、 when、 what rights with used the keys；別に貯え、また暗号化して下さい。
規制と基準：業界要件（GDPR/PCI許可/ローカルレギュレータなど）に焦点を当て、認定された暗号モジュール（認証レベルの遵守など）を使用しています。

7）貯蔵のタイプによるパターン

7.1ブロック/ファイル・ボリュームとVM/コンテナ

KMSによるフルディスク暗号化（XTS）+キー管理（マウント時のボリューム初期化）

スワップ、クラッシュダンプ、tmpディレクトリ、コンテナオーバーレイレイヤー、/AMIイメージを保護します。
スナップショット/スナップショット-常に別々のDEKで暗号化されます。

7.2オブジェクトストレージ

エンベロープ暗号化：オブジェクトごとに一意のDEK；headers/metadata-PIIリークなし。
テナントと環境によるKMSキーへのアクセスを制御します。
サーバー側の暗号化（独自のKMSを持つSSE）またはクライアント側（CSE）-信頼モデルに従って選択します。

7.3データベース

利用可能なTDEを有効にします。プラグイン/拡張によってKMSにデータベースキーをバインドします。
特に重要なフィールド-データベースに入る前にアプリケーション暗号化（AEAD）。
ログ/トランザクションログ、アーカイブログ、ダンプをやり直す-別々に暗号化、キー-別々に。

7.4ログ/トレイル/メトリック

ログ形式-デフォルトで機密データなし（衛生状態）。
ログアーカイブ-別のキーと短いTTLストレージ。
読み取りログへのアクセス-A&Aと監査によるプロキシサービスを通じて。

7.5バックアップとオフラインメディア

テープ/クラウドに書き込む前に、常にクライアントで暗号化します。
キーは別々に（帯域外）、別の制御のエスクローを貯えて下さい。
緊急の場合は、マスターアクセスを復元するために秘密（例えば、m-of-n）を分割します。

8）マルチテナント

テナントの鍵：KEK-per-tenant+DEK-per-dataset。
ポリシーの分離：KMS名前空間、IAM境界、個々のIDP役割。
クライアントの要求による削除：「crypto-erase」-テナントのKEKを撤回し、DEKを破壊します。
クライアントレポート：コンプライアンスアーティファクト、キーアクセスログ、回転確認。

9）性能および操作

ハードウェアアクセラレーション（AES-NI/x86、 ARMv8 Crypto Extensions）。
ホットパスプロファイリング：I/O境界で暗号化し、不必要に二重暗号化を回避します。
KMSセッションプール、ラップされたDEKをメモリにキャッシュする（TTLおよびダンプ保護付き）。
SLO/メトリクス：待ち時間の解消、「再暗号化」オブジェクトの割合、KMSエラー、バックアップ暗号化の速度。

10）参照のrunbook

ステップ0-データインベントリ。すべてのリポジトリとリークパス（tmp、 dumps、 export、 analytics bucket）をカタログ化します。
ステップ1-キー階層設計。KEK/DEKレベル、粒度、地域、役割を決定します。
ステップ2-モード/ライブラリを選択します。承認されたアルゴリズム、暗号ライブラリ、バージョンポリシー。
ステップ3-KMS/HSMとの統合。生成/ラッピング/監査、IAMポリシー、ジオピニング。
ステップ4-書き込みごとに暗号化。デフォルトでは、バックグラウンドの再暗号化による既存のデータの移行を有効にします。
ステップ5-回転と緊急シナリオ。規制、テスト「鍵の妥協」、「KMSは利用できません」。
ステップ6-監視と監査。ダッシュボード、アラート、定期的なコンプライアンスレポート。
ステップ7-トレーニングと"安全なコーディング。"エンジニアのためのガイド、ログ/ダンプで秘密を表示することの禁止。

11）テストおよび検証

暗号ユニットテスト：AEADの正しさ（タグチェック）、バイトが変更されたときの失敗の検証。
Failure-tests： KMSの無効化、古いキーバージョン、強制的なKEKの失効。
Red/Blueテスト：「raw」ディスク/スナップショット/バックアップを読み取ろうとします。
互換性チェック：アルゴリズム/キー長の移行（crypto-agility）。
ライブラリの証明：検証済みの暗号モジュールのみを使用します。コミットバージョン。

12）頻繁な間違いとそれらを回避する方法

意味のない二重暗号化。余分なレイテンシーと複雑さ。所望の粒度と分離を与えるレイヤーを保持します。
データの横にキーを格納します。キーは常に別々のアクセスモデルの下にあります。
忘れられたアーティファクト。暗号化されていない一時ファイル、CSVエクスポート、サポートダンプ。CI/CDおよびデータ損失防止で監視を有効にします。
回転の欠如。手動ではなく、パイプライン/cronの回転部分を作ります。
機密データを使用したログ。ログフォーマットと自動消毒剤の契約を入力します。

13）ミニレシピ（擬似コード）

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14）チェックリスト

• すべてのストレージ・タイプでデフォルトの暗号化が有効になります。
• キー階層が記述され、実装されます。ロールとIAMポリシーが設定されています。
• KMS/HSM統合、主要業務監査が有効。
• DEK/KEKの回転は自動化されます；妥協のシナリオはうまくいきました。
• バックアップ、スナップショット、ログ、ダンプ-暗号化された；キーは別々に格納されます。
• KMSエラー、AEADタグの偏差、暗号化されていないアーティファクトの割合を設定したアラート。
• KMSの利用不能性および重要な失効テストが合格しました。

• キーの使用とアクセス試行に関する月次レポート。
• 痛みのないアルゴリズム移行のための暗号アジリティ計画とウィンドウ。
• rawメディアからデータを抽出する定期的なRed-team。

15） Q&A （FAQ）

Q：フルディスクの暗号化は十分ですか？
A：物理的なリスク-はい、しかしテナントの分離とDEK-on-object/setを使用した柔軟な回転エンベロープの方が良いです。

Q： KEKが侵害された場合はどうすればいいですか？
A：すぐにKEKをKMSにリコールし、新しいリリースを行い、すべてのDEKを巻き戻し、ログをチェックし、RCAを実行します。

Q：探しているフィールドをどのように暗号化しますか？
A：厳格なリスクアセスメント（パターンレック）でのみ、決定論的スキームまたはFPEを使用します。センシティブなフィールドにインデックス付きオープンビューを必要としないように、クエリを設計することをお勧めします。

Q：キーには別のコマンドが必要ですか？
A： Crypto/KMSオペレーターは、個別の権利と手順を持つ役割として推奨されます。

• 「キー管理とローテーション」
• 「S2S認証」
• 「Sign and Verify Requests」
• 「KernelでOAuth2/OpenIDを接続する」
• 「Webhook配信保証」