暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第4弾として、暗号化について解説する記事です。

現代システムはat-rest（保存）／in-transit（通信）／in-use（処理）の3層で守るのが基本。本記事では対称鍵・公開鍵暗号、TLS、ハッシュ、KMS、Envelope Encryption、TDEなどの暗号技術を解説し、暗号化の強度は鍵管理の強度と同じという実務の鉄則を示します。

本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』も参考にしてみてください。

そもそも暗号化とは何か

暗号化とは、ざっくり言えば「データを読めない形に変換し、正しい鍵を持つ人だけが元に戻せるようにする技術」です。

手紙の封蝋を想像してください。封蝋（暗号化）を施せば、途中で誰かが覗いても中身は読めません。ただし封蝋を作る印章（鍵）を盗まれたら、誰でも開封・偽造できてしまいます。デジタルの暗号化も同じで、アルゴリズム自体は公開されていても、鍵が安全に管理されている限りデータは守られます。逆に言えば、暗号化の強度は鍵管理の強度と同じです。

漏れた前提で設計する、という逆転の発想

暗号化は「入れたから安全」ではなく、鍵の管理が全てです。鍵が漏れれば暗号化は無意味で、暗号化したつもりで鍵を平文で置いている事故が後を絶ちません。

暗号化の強度は鍵管理の強度と同じ。鍵が漏れた瞬間に全てが無力化します。

なぜ必要か

① 漏洩時の被害を限定する

DBをバックアップごと盗まれても、暗号化されていれば読めません。情報漏洩ニュースのほとんどは平文保存が原因です。

② 規制・法令の要求

GDPR・個人情報保護法・HIPAA・PCI DSS──いずれも個人情報・クレカ情報の暗号化を要求します。違反時は数億〜数十億の制裁金が課されます。

③ インターネット通信の標準要件

現代ブラウザは HTTP を警告表示し、HTTPS 必須です。通信の平文送信は事実上禁止と言えます。

暗号化の3つの場所

暗号化は「どこで守るか」で3種類に分類されます。システムアーキテクチャではこの3層全てで暗号化するのが現代標準です。

処理時暗号化は発展途上で実装が難しいですが、保存時と通信時は既に標準技術として確立しており、現代システムでは必須要件です。

対称鍵暗号と公開鍵暗号

暗号化の2つの根本原理で、使い分けが重要です。どちらか一方では足りず、現代システムは両方を組み合わせて使います。

現代のTLSは両方を併用し、公開鍵暗号で対称鍵を安全に交換し、本体データは高速な対称鍵で暗号化するハイブリッド方式が標準です。

TLS / HTTPS

通信の暗号化のデファクトスタンダードで、HTTPにTLSを乗せたのがHTTPSです。現代ウェブは TLS 1.3 が最新で、TLS 1.0/1.1 は既に廃止、1.2 は最低限、1.3 が推奨です。

TLS証明書は Let’s Encrypt で無料で取得でき、CloudFront・ALB等のマネージドサービスなら自動更新が可能です。有料の EV 証明書はUX向上効果が薄れ、現代ではほぼ不要とされています。

ハッシュ化（一方向関数）

元データから一方向に変換し、元に戻せない関数がハッシュです。パスワード保存・データ改ざん検知・電子署名等に使われます。暗号化と混同されがちですが、復号できないのが根本的な違いです。

パスワードに一般ハッシュ（SHA-256）を使うのは厳禁です。高速すぎて総当たりされます。Argon2 や bcrypt のように「意図的に遅い」ハッシュを使い、「ソルト」（ユーザーごとに違う文字列）を必ず付けます。

鍵管理（KMS）

暗号化の要である鍵を安全に管理する仕組みが KMSです。鍵をアプリ側で平文で持つのは厳禁で、専用のハードウェア（HSM＝Hardware Security Module、暗号鍵を物理的に保護する専用装置）や KMS で管理します。クラウドなら標準サービスとして提供されています。

鍵は定期ローテーション（自動更新）するのが基本で、KMS は透過的にこれを実現します。

Envelope Encryption

Envelope Encryption は、大量データを効率的に暗号化する標準パターンです。データは高速な対称鍵で暗号化し、その鍵自体を KMS の鍵で暗号化する入れ子構造で、安全性と性能を両立します。

データ --- [DEK: データ暗号鍵] ---> 暗号化データ
            │
            └── [KEK: KMS鍵] ───> 暗号化されたDEK

KMS を直接使ってデータを暗号化するとネットワーク往復で遅くなりますが、Envelope 方式なら KMS 呼び出しは最初だけで、以降はローカルで暗号化できます。AWS S3・BigQuery の裏側もこの方式です。

鍵管理はKMSに任せる。アプリ側で鍵を持たないのが鉄則です。

TDE（透過的データ暗号化）

TDE は、DB自体が自動的にデータを暗号化する機能で、アプリ側のコード変更不要で保存時暗号化を実現できます。クラウドDB・エンタープライズDBの標準機能で、有効化するだけで保存時暗号化が完了します。

「暗号化 ＝ TDE」と誤解する人は多いですが、TDEはあくまで保存時暗号化で、アプリ→DB間の通信やアプリ内メモリは別途対策が必要です。

クライアントサイド暗号化

アプリ側で暗号化してからサーバーに送る方式で、サーバー側ですら平文を見られない状態を作れます。LastPass・1Password・Signal・Proton Mail 等の「ゼロ知識設計」がこれです。

クレカ番号・パスワード・機密メモなどは、サーバーで復号の必要がない限り、クライアントサイド暗号化を検討する価値があります。

電子署名と改ざん検知

データの真正性（本物か）と完全性（改ざんされていないか）を保証するのが電子署名です。公開鍵暗号の応用で、送信者が秘密鍵で署名し、受信者が公開鍵で検証します。

特にサプライチェーン攻撃対策として、コンテナイメージの署名（Cosign）が近年急速に普及しています。

判断基準

① 扱うデータの機微度

暗号化の強度はデータの機微度で決まります。公開情報に強い暗号化は過剰で、逆に個人情報に弱い暗号化は犯罪的です。

② クラウド採用度

クラウド各社のマネージド KMS・TDE を使えば、暗号化は標準で有効になります。オンプレミスだと鍵管理を自前で設計する必要があり、難易度が格段に上がります。

ケース別の選び方

一般的なWebサービス・SaaS

TLS 1.3 + マネージドKMS + TDE有効化。CloudFront/ALBでTLS終端、RDS/BigQueryはTDE標準、パスワードはArgon2を使います。これだけで規制対応も含めて8割カバーできます。

クレジットカード情報を扱うEC

PCI DSS準拠 + トークン化。カード番号そのものを自社DBに保存せず、Stripe・Adyen などの「決済代行のトークン」（例：tok_xxx）で扱います。自社DBから漏洩してもカード情報が出ない設計にします。

パスワードマネージャー・秘密メモ系サービス

クライアントサイド暗号化（ゼロ知識）。サーバーは暗号文のみを保管し、復号はユーザー端末で完結させます。サーバー侵害でも平文は守られる代わりに、復旧手順の設計が最難関になります。

金融・医療・政府系の高機密データ

FIPS 140-2 Level 3 HSM + 列単位暗号化 + 鍵の監査ログ。鍵へのアクセス1つ1つを監査ログに残し、職務分掌で鍵管理者を分離します。

暗号化の数値Gate・アルゴリズム選定表

暗号化は「使えばOK」ではなく、アルゴリズムとパラメータを正しく選ぶ必要があります。以下が2026年4月時点の標準値です。

「Argon2id（2015年 Password Hashing Competition 優勝）」が2026年時点のパスワードハッシュの鉄板。bcrypt も継続使用可能ですが、新規は Argon2id が第一候補。「PBKDF2 は反復回数（iteration）が古い設定」のまま使うと突破されるため、最低 600,000回以上（OWASP 2023推奨）必須です。

標準アルゴリズムから一歩も外れないのが鉄則。自作暗号は絶対禁忌です。

やってはいけないこと

暗号化で事故る典型パターンを整理します。どれも暗号化したつもりで漏洩している構造を持ちます。

2013年 Adobe 事件（約1.5億件のパスワードが「暗号化された状態」で流出したが、ECBモード + 共通ヒント欄で実用的に解読）、2022年 LastPass 流出（暗号化ボルトのコピーが奪取、古い PBKDF2反復回数のユーザーが高リスクに）は、「暗号化した」と「守れている」は別物という教訓を突きつけました。

暗号化は「入れる」と「守れる」の間に深い溝がある。鍵管理が全てを決めます。

AI判断軸

1. 3層で暗号化 — 保存時（TDE）・通信時（TLS 1.3）・処理時、全てをマネージドで扱う
2. 鍵はKMSに任せる — アプリ側で鍵を持たず、自動ローテーションを有効化
3. パスワードはArgon2 / bcrypt + ソルト — SHA-256単独は厳禁、意図的に遅いハッシュを採用
4. 暗号コードは専門家レビュー — AI生成をそのまま信じず、標準ライブラリから外れない

AIに暗号化コードを書かせてはいけない理由

AIは暗号化の「使い方」を書けますが、「正しい使い方」かどうかの判断は信用できません。たとえばAES暗号化のコードを生成させた場合、ECBモード（同じ平文ブロックが同じ暗号文になる危険なモード）を使ったり、初期化ベクトル（IV）を固定値にしたりするコードが出てくることがあります。

暗号化に関しては「AIに書かせるのはKMS/SDKの呼び出しコードだけ」が原則です。AWS KMSのencrypt/decrypt呼び出し、TLS証明書の設定、bcryptのハッシュ化呼び出しのような「ラッパーコード」はAIに任せて問題ありません。暗号アルゴリズムの実装や鍵生成ロジックをAIに書かせるのは避けるべきです。

KMSの自動ローテーション設定をIaCで宣言する

AWS KMSの鍵ローテーション設定はTerraformで1行追加するだけですが、この1行がないと鍵が永久に固定されます。AIにTerraformコードを書かせた場合、KMSリソースは作成するがローテーション設定を省略するケースがあります。CIのtfsecルールで「KMS鍵にローテーション設定がない」を検知する仕組みが有効です。

筆者メモ — 「暗号化済み」が実は守れていなかった事例

「暗号化してるから大丈夫」が崩れた事例が、近年の大型漏洩の多くを占めている、という話は業界の定番です。

2013年10月のAdobe情報流出事件では、約1億5千万件のパスワードが「暗号化された状態」で流出しましたが、同じ鍵・ECBモード・共通のパスワードヒント欄という実装上の欠陥が重なり、暗号文のパターン解析で実用的に解読されました。「暗号化した」と「守れている」が別物であることを世界に突きつけた事件として語り草になっています。

もう一つ、2022年のLastPass情報流出事件も重い教訓を残しました。暗号化されたパスワード金庫（Vault）自体が窃取された上、一部ユーザーのイテレーション回数（PBKDF2 の繰り返し回数）が古い設定のままで、総当たり攻撃への耐性が低かったことが後から判明しました。「暗号化している」だけでなく「どれだけ遅いハッシュを使ったか」まで設計に入れなければならない、という教訓が広く共有されるきっかけになりました。

筆者も過去に、検証用のAES鍵を .env.example に残したままGitに push し、半年後にシークレットスキャンで検知されて慌てた経験があります。本番鍵でなかったので被害はゼロでしたが、鍵の寿命・経路・置き場所まで説明できるかが重要だと痛感した出来事でした。どちらも派手な攻撃ではなく「実装の詰めの甘さ」が致命傷で、暗号化は「入れるだけでは不十分」という教訓を突きつけます。

鍵管理の地味なミスは常に起こる。「入れたか」ではなく鍵の寿命と経路を問います。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• 通信暗号化（TLS 1.2/1.3・mTLS要否）
• 保存暗号化（TDE・KMS・列単位）
• 鍵管理（KMS・Vault・HSM）
• パスワードハッシュ（Argon2 / bcrypt + ソルト）
• 鍵ローテーション（頻度・自動化）
• クライアントサイド暗号化（必要性）
• 署名（コード・コンテナ・契約書）

決定理由の残し方

暗号化方式の選定はセキュリティ監査やコンプライアンス対応で必ず問われるため、選定理由を ADRとして明文化しておくことが不可欠です。

ADR はセキュリティポリシー文書と併せて docs/adr/ に保管し、監査時にすぐ参照できる状態にしておくのが理想です。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADR の最大の価値です。

この記事に関連する記事

まとめ

本記事は暗号化について、対称鍵・公開鍵・TLS・ハッシュ・KMS・Envelope Encryption・TDE・実務の鉄則まで含めて解説しました。如何だったでしょうか。

3層で暗号化し、鍵はKMSに任せ、パスワードはArgon2/bcrypt+ソルト、暗号コードは専門家レビューを通す。これが2026年の暗号化設計の現実解です。

次回はネットワークセキュリティ（FW・WAF・IDS/IPS・DDoS対策）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS Key Management Service も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。