暗号化・鍵管理・データ保管

DEEP DIVE

仕組みと効果を、具体例で理解する。

暗号化の名称だけでは、どのリスクを減らせるかは判断できません。住所を保管・利用する例を使い、鍵の役割とデータの行き先を詳しく説明します。

データと暗号鍵を分離する

データ暗号鍵（DEK）で本人情報を暗号化し、鍵暗号鍵（KEK）でDEKを保護するエンベロープ暗号化の構成例です。認証付き暗号を使い、改ざんを検出してからデータを利用します。

DEK / KEK

DB内の暗号文と、KMS等が管理する鍵を同じ権限で取得できないようにする。

nonce / authentication tag

AES-GCMなどの方式ではnonceの重複を避け、認証タグの検証失敗を拒否する。

追加認証データ（AAD）

tenant_id・record_id・schema_versionを暗号文に結び付け、別レコードへの差し替えを検出する。

鍵の更新

KEK更新時のDEK再ラップと、DEK更新時の実データ再暗号化を区別する。

CLOUD KEY MANAGEMENT

鍵の保管には、クラウドの鍵管理サービスを使う。

住所VaultのKEKはAzure Key Vaultで管理します。データ暗号化鍵（DEK）を保護する鍵の利用権限と、DBへのアクセス権を分けます。

Azure

Azure Key Vaultを利用。専用HSM環境が必要な要件ではAzure Managed HSMを選択します。

AWS

現在のDEV製品はAzure上の配送先住所APIです。メール送信、本人確認画像・OCR、AWS KMS連携はこの製品に含まれません。技術説明の汎用例や他クラウドの設計は、購入後すぐ使える機能一覧とは区別してください。保管場所・運用主体・追加連携は導入時に確認します。

OneNymの役割

クラウドの鍵管理と組み合わせ、誰が、どの情報を、何の用途で、いつまで取得できるかを業務単位で制御します。

DBには暗号文とラップ済みDEKを保存し、平文のDEKを永続保存しません。鍵を使う権限が侵害されれば復号され得るため、データ・鍵・管理者の権限分離も必要です。

復号する経路を最小化する

アプリがDBに接続できることと、復号権限を持つことを分けます。認可判定を通った処理だけが必要な項目を復号し、応答・ログ・例外情報に不要な本人情報を含めない設計です。

項目単位の応答

配送では住所など、許可された項目だけを返す。

管理者のアクセス

日常運用と緊急操作を分け、強い認証・時間制限・操作証跡を設ける。

検索の設計

暗号化した項目の検索は別途設計する。検索用ハッシュにも照合・推測のリスクがある。

削除・バックアップ・復旧

保持期間は利用目的ごとに定義し、削除要求は本体・複製・バックアップ・連携先のどこまで反映するかを整理します。復元によって削除済みデータが再出現しないよう、削除履歴を再適用します。

削除の完了条件

論理削除、実データ削除、鍵破棄を区別して記録する。

鍵破棄

対象専用の鍵を、バックアップ等のコピーも含めて復旧不能にできる場合に検討する。共有鍵の破棄は他データにも影響する。

復旧目標

許容できるデータ損失時間（RPO）と復旧時間（RTO）を定め、実際に復旧を検証する。

監査ログ

主体・操作・対象参照・時刻・結果を記録し、実データや生トークンは記録しない。

DATA / INTEGRATION EXAMPLE

データ・連携の具体例

以下は設計を説明するためのサンプルです。フィールド名・値は例示で、実行用のAPIリファレンスではありません。

{
  "operation": "保管レコードのメタデータの設計例",
  "record": {
    "tenant_id": "tenant_a",
    "record_id": "rec_example_01",
    "schema_version": 1,
    "ciphertext": "<encrypted bytes>",
    "wrapped_dek": "<wrapped key>",
    "kek_version": "key-version-2",
    "retention_until": "<agreed retention date>",
    "status": "active"
  }
}

この例は保存構成の説明です。実際のnonce・認証タグ等の保存形式は暗号ライブラリに従います。暗号化だけでは、正規の復号権限を悪用した情報取得は防げません。

関連する技術設計

業務とシステムに合わせた連携設計。

保有する情報、連携先、必要な処理を整理し、情報の露出を減らす方法を検討します。