8章 監視
相関ID
- 同じ呼び出しのフローで呼び出された複数のサービス間で共通のIDを設定する
- ログ追跡を可能にするために必要
- イベント駆動アーキテクチャパターンの場合は特に有効
- thin共有クライアントラッパーライブラリの利用が望ましい
- 全員が同じように下流のAPIを適切に呼び出すようにするため
標準化
- ログ出力の形式は標準化する
- メトリックを集約する場合に都合が良い
- 追跡が容易になる
- logstash, collectd, Graphite
まとめ
- サービスを分割したことによって、単一のサービスの場合と異なる課題が出てくる
- ユーザの1アクションに対して収集すべきログが複数箇所に発生するので、追跡可能性を考慮する
- サービス間の標準化を検討する
9章 セキュリティ
サービス間の認証と認可
- 認証のパターン
- 境界内のすべてを許可する
- ネットワーク境界でのセキュリティを保証する
- 攻撃者がネットワークに侵入すると、中間者攻撃に対する防御はない
- リスクを考慮して採用しないと心配
- HTTP(S)ベーシック認証
- ユーザ名とパスワードを安全に送信するためHTTPS上での利用が望ましい
- 複数マシンを管理する場合は、SSL証明書の管理が問題になる
- SSL経由で送信されるトラフィックをリバースプロキシでキャッシュできない
- LBでSSLトラフィックを終端し、背後にキャッシュを配置することで解決できる
- クライアントがユーザ名とパスワードを持っていることしかサーバにはわからない
- ネットワーク上の誰もが送信できる
- SAMLやOpenID Connectの利用
- すべてのネットワーク内トラフィックをゲートウェイ経由にする
- すべてのサービスのアクセス制御を中央のディレクトリサーバに集中させることができる
- クライアントのアカウントを各サービスが持つ必要がある
- アカウントは狭い範囲で使うようにすること
- 認証情報を安全に格納する必要がある
- 認証のコーディングに工数が必要
- クライアント証明書
- 多数の証明書管理が課題になる
- 証明書の取り消しや再発行の難しさ
- インターネット経由で重要な情報の通信の保護の場合などに使う
- HTTP上のHMAC
- HMAC(Hash-based Message Authentication Code)を使ってリクエストを署名する
- リクエストボディと秘密鍵をハッシュ化する
- サーバ側では、ハッシュが一致したらリクエストを許可する
- 欠点
- 秘密鍵を変更する場合
- 優れた既存の実装がない
- リクエスト内容の覗き見は防いでいない
- APIキー
- 公開鍵と秘密鍵のペアを使う方法が一般的
- 鍵を中央で管理する
- ゲートウェイモデルが人気
- システムの正確な実装が多様
- 境界内のすべてを許可する
## 混乱した代理の問題
- 悪意のある者が、代理サービスをだまして実行できてはいけない下流のサービスの呼び出しを実行させること
- ex. 特定のアカウントでECサービスにログインし、別アカウントの顧客情報呼び出しを実行させる、など
- 代理サービスの信頼性の確保の問題があることを認識しておく
- この問題は難しく、簡単な答えはない
暗号化は鍵がすべて
- 解決法
- 別のセキュリティアプライアンスでデータの暗号化と復号を行う
- 鍵が必要なときにアクセスできる別の鍵管理システムを使う(key vault)
- 独自の実装は避け、十分に調査する
セキュリティの組み込み
- OWASPトップ10リスト