暗号化・機密情報管理

暗号化は機密情報を保護する基本的な手段であるが、アルゴリズムの選択・鍵管理・実装方法を誤ると、暗号化している見た目のまま実際には保護されていない状態になる。一般的な原則として、独自の暗号化アルゴリズムを実装せず、十分に検証済みの標準ライブラリのみを使用することが大原則である。暗号化の実装は見た目が正しくても細部の誤り（IVの再利用・パディングオラクル等）で完全に破られる可能性があるためである。

対称鍵暗号（AES-256-GCM）は大量データの暗号化に適しており、GCMモードは暗号化と認証（改ざん検出）を同時に提供する。非対称鍵暗号（RSA・ECDSA）は鍵配送問題を解決するために使われ、実際には対称鍵を非対称鍵で暗号化してから対称鍵で本体を暗号化するハイブリッド方式が一般的である。パスワードのような人間が入力する秘密情報には、通常の暗号化ではなくbcrypt・Argon2・scryptなどの計算コストが高い専用ハッシュ関数を使うことが必須であり、SHA-256やMD5はパスワードハッシュには絶対に使ってはならない。

KMS（Key Management Service）は鍵そのものをセキュアに保管・ローテーションするためのマネージドサービスであり、AWS KMS・GCP Cloud KMSなどが代表的である。アプリケーションは鍵を直接保持せず、KMS経由で暗号化・復号化の操作を委譲することで、鍵の漏洩リスクを低減できる。シークレット（APIキー・データベース接続文字列等）の管理にはHashiCorp Vault・AWS Secrets Managerなどの専用サービスを使い、環境変数への直接埋め込みはプロセスリストやログを通じた漏洩リスクがあるため避けるべきである。

コードレビューで着目するポイント

パスワードのハッシュにbcrypt・Argon2・scryptが使われており、MD5・SHA-1・SHA-256が使われていないか
暗号化に標準ライブラリ（OpenSSL・libsodium等）を使っており、独自実装がないか
AES利用時にECBモードが使われていないか（ECBはブロック単位の同一パターンが露出する）
IVまたはnonceが暗号化ごとに一意のランダム値で生成されているか（再利用されていないか）
APIキーやパスワードがソースコードやgitリポジトリにハードコードされていないか
鍵のローテーション手順と暗号化済みデータの再暗号化フローが設計されているか
シークレットがKMSまたはSecretsManagerで管理されており、環境変数への直接埋め込みではないか

典型的なアンチパターン

MD5・SHA-1によるパスワードハッシュ: 旧来のシステムでMD5でパスワードをハッシュし、Rainbow Table攻撃やブルートフォースに対して無力な状態で保存している。Argon2idへの移行とソルト付きハッシュへの切り替えが必要。

IVの再利用: AES-CBCまたはAES-CTRモードで同一IVを使い回すと、同じ平文が同じ暗号文になり、既知平文攻撃の糸口となる。GCMモードを使い、IVは暗号化ごとにCSPRNGで生成すること。

シークレットのgitコミット: .envファイルやソースコード中にAPIキーを直接書いてgitにコミットしてしまう。gitの履歴は削除が難しく、一度コミットされたシークレットは即座に無効化・ローテーションが必要になる。.gitignoreとgit-secretsなどの事前防止ツールを組み合わせること。

参考リソース

libsodium (https://libsodium.gitbook.io/) — 使いやすくセキュアな暗号化ライブラリ（多言語バインディングあり）
OWASP Cryptographic Storage Cheat Sheet — 暗号化アルゴリズム選択・鍵管理の実践ガイド
AWS KMS Best Practices — AWS KMSを用いた鍵管理の公式ガイドライン
HashiCorp Vault (https://www.vaultproject.io/) — オープンソースのシークレット管理・暗号化サービス
Serious Cryptography (Jean-Philippe Aumasson) — 実践的な暗号理論と実装の落とし穴を解説した書籍