メインコンテンツまでスキップ

セキュリティ

Bazbiiシステムのセキュリティ要件と実装について説明します。

セキュリティ概要

Bazbiiシステムは、多層防御(Defense in Depth)の原則に基づいてセキュリティを実装しています。エッジからアプリケーション層まで、複数の防御層を配置しています。

防御層の構成

認証・認可

JWT認証

Bazbiiシステムは**JWT(JSON Web Token)**を使用した認証を実装しています。

トークンの種類

  • Access Token: 短期有効(有効期限あり)
    • APIアクセス時に使用
    • Bearer形式で送信: Authorization: Bearer <token>
  • Refresh Token: 長期有効(有効期限あり)
    • Access Tokenの更新に使用
    • 安全に保管・管理が必要

認証フロー

  1. ユーザープロビジョニング: 匿名ユーザーの生成(初回アクセス時)
  2. トークン発行: Access TokenとRefresh Tokenを発行
  3. トークン検証: GatewayでJWT署名・有効期限・クレームを検証
  4. 認証情報注入: ActorIDとDeviceIDをcontextに注入
  5. 認可チェック: API Serverでリソースアクセス権限を確認

実装詳細

  • アルゴリズム: 非対称鍵署名方式を使用
  • 秘密鍵管理: 環境変数で管理、適切な形式でエンコード
  • 検証場所: Gatewayミドルウェアで実装
  • 実装場所: プラットフォーム層の認証モジュールで実装

認可モデル

  • ActorIDベース: トークンから抽出したActorIDを基に認可を判定
  • リソース所有権: ユーザーは自分のリソースのみアクセス可能
  • 役割ベース: 将来的にパートナー・管理者ロールを追加予定

防御層

Cloudflare Edge

役割: エッジ層での防御

  • WAF (Web Application Firewall): SQLインジェクション、XSS等の攻撃を防御
  • DDoS防御: 分散サービス拒否攻撃の緩和
  • ボット対策: 自動化された不正アクセスを検知・ブロック
  • レート制限: IP/ASNベースの一次絞り込み
  • SSL/TLS終端: HTTPS通信の暗号化

Gateway

役割: アプリケーション層の入口防御

  • JWT検証: トークンの署名・有効期限・クレーム(iss/aud/sub等)を検証
  • レート制限: ユーザー/デバイス単位の精密制御
  • プロトコル変換: HTTP/JSON ↔ gRPC変換時のセキュリティ検証
  • サービス間信頼: API ServerとのmTLS通信

API Server

役割: ビジネスロジック層での認可

  • 認可チェック: リソースアクセス権限の検証
  • 入力バリデーション: ビジネスルールに基づく検証
  • データ永続化: セキュアなデータベース操作

データ保護

通信の暗号化

  • HTTPS: エンドツーエンドのTLS暗号化
  • mTLS: Gateway ↔ API Server間の相互TLS認証
  • プロトコル: TLS 1.2以上を推奨

保存時の暗号化

  • データベース: データベースの暗号化機能を利用(将来実装)
  • 秘密鍵管理: 環境変数での管理、将来的に鍵管理サービス導入を検討
  • 個人情報: 最小化原則に基づき、必要最小限の情報のみ保存

アクセス制御

  • データベースアクセス: アプリケーション層からのみアクセス可能
  • ネットワーク分離: コンポーネント間の通信を制限
  • 最小権限の原則: 必要な権限のみ付与

レート制限

2層レート制限

  1. Cloudflare: IP/ASNベースの一次絞り込み

    • DDoS攻撃やボットの大量リクエストをブロック
    • エッジ層での高速処理
  2. Gateway: ユーザー/デバイス単位の精密制御

    • 認証済みユーザーに対する細かい制御
    • ビジネスロジックに基づく制限

実装方針

  • レート制限の閾値は環境変数で設定可能
  • 将来的にRedis等の分散キャッシュで実装予定
  • 制限超過時はRESOURCE_EXHAUSTEDエラーを返却

セキュリティ監視

ログとアラート

  • 認証失敗ログ: 不正な認証試行を記録
  • レート制限ログ: 制限超過の発生を記録
  • エラーログ: セキュリティ関連のエラーを監視

監視対象

  • 認証失敗率の異常な上昇
  • レート制限超過の増加
  • 不正なAPIアクセスのパターン

詳細は監視非機能要件を参照してください。

セキュリティベストプラクティス

開発時の注意事項

  1. 秘密鍵の管理: 秘密鍵をコードに直接記述しない
  2. 入力バリデーション: すべての外部入力を検証
  3. エラーメッセージ: 詳細なエラー情報をクライアントに返さない
  4. 依存関係: セキュリティパッチを定期的に適用

運用時の注意事項

  1. トークン管理: Refresh Tokenの適切な管理
  2. ログ管理: 個人情報を含むログの取り扱いに注意
  3. 監視: セキュリティイベントの定期的な確認
  4. アップデート: セキュリティパッチの迅速な適用

関連ドキュメント