「セキュア・バイ・デザイン」補習編２（10章〜最後）

締切を決めて技術書を読破するデッドライン読書会。今回は締切に間に合わなかった💧「セキュア・バイ・デザイン」の補習をしています。10章から最後まで。

近年システムの構築にクラウドを利用するようになり、その利用から見えてきたクラウド的考え方がセキュリティをどう強化するのかを考察。

構成情報の管理方法
- コード上に記述する、構成ファイルに記述する→NG
  - アクセス権限の制御が難しい
  - 暗号化が難しい
  - 監査証跡の取得ができない
- OSの環境変数として持つ→おすすめ
  - 環境に合わせて構成情報を持つのではなく、環境から構成情報を取得する。
- エフェメラルキー（一時的なキー、シークレット）
ログをファイルに残す危険性
- ログ・サービス（loggin as a service）を利用すること。
エンタープライズ・セキュリティの3つのR。
- この3つは耳が痛い…。
- Rotate…シークレットの定期的な変換、変更。数分〜数時間単位。
- Repave…作り直し。数時間単位。
- Repair…修復。パッチ等の高速な適用。できるだけ早く。

事例紹介。銀行・経理・保険の各コンテキストで「支払い」の語の意味を誤解してしまった話を元に。

12章から第三部の応用編となる。第二部ではセキュア・バイ・デザインのテクニック（細部）を紹介していったが、ここからはどのようにレガシーコードを改善するのかを検討する。

ドメイン・プリミティブを使えば、入力値の制御は攻撃者ではなく開発者が行えるようになるからです。
P.445 12.3 ログにおける未検査の文字列

↑これが本書でずっと書かれている肝心なこと。制御を開発者自身が持てるようにどうコードを保護するかという意識の持ち方がとても大事。　

ユーティリティクラスは一時的な利用に留める。
- UtilやCommonみたいなクラス。ヘルパーメソッドとして使うのは実装やリファクタリングの一時的な利用に留める。本質的にはドメイン・プリミティブに作っていくべし。

モノリスをリファクタリングをしてマイクロサービスに分割する際には、異なるコンテキスト間の翻訳の必要性に注意する。
- モノリスの場合では意味境界が曖昧だったものが、マイクロサービスにした途端に明確にする必要がある。
- ドメイン・プリミティブによる実装によって（意味境界を）検証する。
データはコンテキストにより機密情報になったりならなかったりする。
- コンテキストを渡るたびに変化する可能性がある。
- ≒情報はコンテキストによって機密情報かどうかを判定される。
  - 例）道端の車のナンバープレートは機密情報ではないが、ナンバープレートに位置情報と日時がつくと機密情報になるかもしれない。
ログAPIの設計は通常のアプリケーションと同様に行う。
- logger.cancelBooking(bookingId, user);←のようなイメージ。これはやったことない…。
- このようにすることによってログの分類ごとに閲覧するユーザーを制限したり、トレーサビリティをの仕組みを作れたりする。（ログレベルとログの分類を混同させない）。ログを分類して、分類ごとにアクセス制限したいというのはまさにドメイン特有の関心事。

多くのセキュリティに関する問題の原因はバグ
- 設計が良い→バグが減る→セキュリティに関する問題も減る
- 設計をより深く考えることにより、その副作用として、セキュリティが向上する
セキュリティを意識したコード・レビューを実施する
最新のセキュリティに関する情報の把握
侵入テストの実施
- セキュア・バイ・デザインを実践したからといって侵入テストが不要になると勘違い（過信）してはいけない。
- 定期的に侵入テストを実施し、そのフィードバック（学ぶ機会）を受け取ることでシステムを改善する。
- コンテキスト駆動テスト

セキュリティの分野についての学習
- OWASP Top10
セキュリティ・インシデントに対する仕組み
- Wolffの法則、システム理論、アンチフラジャイル（反脆弱性）
- チェックリストの活用。チェックリストってアンチパターンみたいになりがちだけど、紹介されていたこの本を読んでみて冷静に考えてみたい。