監視、セキュリティ

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リスト