暗号化の仕組みと、
守れる範囲。

「暗号化済み」でも、守る場所が違う。

配送先の住所を保存する場面で考えます。通信、ディスク、データの各層を保護する理由は異なります。

通信の暗号化 / TLS

ブラウザーからサーバーまでの通信を保護します。受信したサーバーでは住所を処理できるため、DBの中身やアプリの侵害まで自動的に守るものではありません。

保存領域の暗号化

ディスクやバックアップ媒体の盗難に備えます。DBが通常の読み取りに対して復号する構成では、SQLの閲覧権限を持つ人には元の住所が見えます。

データを保存する前の暗号化

住所そのものをアプリ側で暗号化し、DBには暗号文を保存します。DBからの読み取りと鍵の利用権限を分離することで、DBだけを取得された場合にも読めない境界を作ります。

OneNymの保管設計では、これらの保護層と用途ごとの認可を組み合わせます。暗号化方式の強度に加え、復号できる経路の少なさが重要です。

現行実装は住所レコード全体をメモリー内で復号し、許可された項目だけを応答へ取り出します。項目別暗号化ではありません。取得後の平文と、登録前に通過する顧客システムのログ・保管は別途管理が必要です。 使い方・導入ガイド

データを守る鍵を、別の鍵で保護する。

DEKは住所を暗号化するための鍵、KEKはそのDEKを保護するための鍵です。この役割分担をエンベロープ暗号化と呼びます。住所ごとに専用のDEKを使う構成例では、次のように処理します。

1. 暗号学的に安全な乱数でDEKを生成し、住所を認証付き暗号で暗号化する。
2. 鍵管理サービス（KMS）が管理するKEKでDEKをラップする。ラップは鍵を暗号化して保護する操作。
3. DBには暗号文、ラップ済みDEK、鍵バージョン、復号に必要なメタデータを保存する。平文のDEKをDBに保存しない。
4. 住所が必要になったら、テナント・用途・対象レコード・要求項目を認可する。
5. 認可された処理がKMSでDEKをアンラップし、住所を復号して、許可された項目だけを返す。

DB                         鍵管理サービス（KMS）
住所の暗号文               KEK：DEKを保護する鍵
ラップ済みDEK              鍵の利用権限・利用記録
nonce / tag / 鍵バージョン
           ↓ 認可された処理だけが両方にアクセス
        必要な住所を一時的に復号 → 配送処理

KEKを取り出せない構成でも、その鍵を使う権限を奪われれば復号につながります。DBとKMSの権限を分け、広い管理権限、緊急操作、サービスの認証情報を別々に管理します。復号中のメモリや鍵キャッシュも保護対象です。

KEKの保管・利用は、クラウドの鍵管理サービスで。

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

クラウド側は鍵の管理と暗号処理へのアクセスを制御します。OneNym側は、その前段でテナント・対象・項目・用途を認可します。業務アプリには保管庫APIの限定された操作を許可し、KEKを直接利用する権限は与えません。

鍵の更新は2種類ある。

KEKを更新するときはDEKを新しいKEKで再ラップします。実データの暗号文はそのままにできます。DEK自体が漏れた場合は新しいDEKで実データを再暗号化します。鍵更新で、すでに盗まれた平文や旧鍵と暗号文のコピーを取り戻すことはできません。

読めなくするだけでなく、差し替えを検出する。

AES-GCMなどの認証付き暗号は、暗号文の変更を認証タグで検出します。検証に失敗したデータは使用しません。AES-GCMでは同じ鍵でnonce（暗号化ごとの値）を再利用しないことが必須です。再試行や複数サーバーでの処理も含め、重複を防ぐ方式を設計します。

さらに、追加認証データ（AAD）としてテナントID・レコードID・スキーマのバージョンを結び付けます。例えば企業Aの住所の暗号文を企業Bの行にコピーしても、復号側が期待する企業BのIDで検証すれば失敗します。

AADは暗号化されません。秘密の住所などを入れる場所ではありません。また、期待するIDは認証済みの要求と信頼できるレコード情報から決めます。差し替えられた暗号文と一緒に渡されたIDをそのまま信じると、境界の保護になりません。

何が漏れたとき、どこまで守れるか。

DBのコピーだけが漏洩

平文の鍵や別経路の平文が含まれておらず、暗号が正しく実装されていれば、住所の内容を保護できます。件数、ID、時刻、サイズなどのメタデータは別途露出を評価します。

DBと復号権限が同時に侵害

暗号化だけでは防げません。対象・用途を絞る認可、利用量の制限、異常検知、失効手段で影響を抑えます。

配送処理のサーバーが侵害

正規の処理で復号した住所は取得され得ます。配送に不要な情報を返さない設計で、露出する情報を絞ります。

すでに連携先へ渡した住所

元の保管庫で鍵を失効しても、渡した平文は消えません。連携先の保存期間と削除方法まで含めて管理します。

導入を評価するときに確認すること。

「AESを使っているか」に加えて、DB担当者が鍵を使えるか、復号対象を絞れるか、鍵の利用記録を追えるか、失効がキャッシュに反映されるまで何秒か、鍵を失った場合に復旧できるかを確認します。守る範囲と運用の証跡が、設計の価値を判断する材料になります。

技術の参考資料

暗号方式と鍵管理の一般的な原則は、OWASPの暗号化ストレージガイド、鍵の階層構造はMicrosoftの保存時暗号化の解説を参照できます。ここではOneNymの保護設計を説明し、レコード単位の鍵構成は具体例として示しています。