第4章 · アプリ配備とセキュリティ·v1.0.0·更新 2026/7/20·読了目安 約17分
変更要約: 初版
4.3アプリセキュリティ
この節の要点
認証情報を安全に扱うsecret管理（環境変数/シークレットストア・平文コミット禁止）と暗号化（保存時と転送時）、そしてファイアウォール・DNS・ロードバランサ・リバースプロキシの役割、さらにOWASPの代表的脅威（XSS・SQLi・CSRF）を、「この扱いは何を守り、どこが穴か」という診断として学びます。
アプリのセキュリティは「機能を追加する」より「穴を作らない」ことが本質です。API キーをソースに直書きして git に push すれば、コードを見た誰もが本番を触れてしまいます。暗号化も「掛ければ安全」ではなく、保存時と転送時のどちらを守っているのかを区別できないと守れません。この節では、secret の扱い・暗号化・境界のインフラ部品（ファイアウォール/DNS/LB/リバースプロキシ）・OWASP の代表脅威を、「この扱いは何を守り、どこが穴か」を診断する視点で学びます。
4.3.1secret管理とデータ暗号化
- secret（機密情報）＝API キー・パスワード・トークン・秘密鍵など。ソースコードに直書きして版管理へコミットするのは禁忌（履歴に残り、公開/漏洩すると即悪用される）。正しくは環境変数や専用のシークレットストア/vaultから実行時に読み込み、リポジトリには置かない（
.gitignoreで.envを除外する）。 - 暗号化は守る対象で2種類に分ける：保存時の暗号化（at rest）はディスク/DB 上のデータを暗号化し、媒体の盗難や不正コピーから守る。転送時の暗号化（in transit）は TLS/HTTPS で通信経路を暗号化し、盗聴/改ざんから守る。両方が必要で、「HTTPS だから DB も安全」のように片方でもう片方を代替できない。
- データの取り扱いでは、必要以上に集めない/持たない（最小化）、扱う分類（個人情報/機密）に応じた保護、ログや通知にsecret や個人情報を漏らさない（トークンをそのままログ出力しない）といった原則を守る。漏洩の多くは高度な攻撃ではなく平文の置き忘れから起きる。