セキュリティ機能
セキュリティ機能
Section titled “セキュリティ機能”このサーバーは、トレーディング操作と認証情報を保護するために複数のセキュリティレイヤーを実装しています。
1. TLS/SSL 暗号化
Section titled “1. TLS/SSL 暗号化”TRADE および QUOTE FIX セッションの両方が、TCP 上の TLS で暗号化されます。
- TLS はデフォルトで有効です
- 両セッション上の Logon 認証情報を含むすべての FIX メッセージを暗号化します
- 認証情報の傍受およびメッセージの改ざんを防止します
- ブローカーの明示的な承認がある場合のローカルテストでのみ無効化してください
2. 認証情報のリダクション
Section titled “2. 認証情報のリダクション”機密フィールド(ユーザー名、パスワード、および関連認証情報)は、すべてのログとジャーナルエントリで自動的に *REDACTED* に置き換えられます。
認証情報がログ、ジャーナルエントリ、またはエラーメッセージに露出することはありません。
3. 入力サニタイゼーション
Section titled “3. 入力サニタイゼーション”すべての値はブローカーに送信される前にサニタイズされます:
- 文字列入力から制御文字とプロトコル区切り文字が削除されます
- これにより、不正な形式のデータがメッセージを破損したり、追加フィールドを注入したりするのを防ぎます
- 数値は有限性と境界について検証されます
- 銘柄名は厳格な英数字パターンに対して検証されます
4. トレードのシリアル化
Section titled “4. トレードのシリアル化”すべての取引操作は競合状態を防ぐためにシリアル化されます:
- 一度に 1 つの取引操作のみが実行されます
- 各操作は実行前にリスクチェックを通過します
- これにより、並行ツール呼び出しがポジション制限を超えたり、デイリーロス制限を回避したりするのを防ぎます
すべての取引ツール(place_order、modify_order、close_position、cancel_order)は、
実行前にロックを取得します。
5. 監査証跡
Section titled “5. 監査証跡”すべてのアクションは追記専用ジャーナルにログ記録されます:
- サーバーの起動/停止イベント
- FIX 接続/切断
- パラメーター付きのすべてのツール呼び出し
- すべての注文送信、約定、拒否
- リスクチェック失敗
- キルスイッチ起動
- 状態リコンサイリエーションイベント
追記専用フォーマットにより、遡及的な改ざんが防止されます。
6. AI エージェントの安全性(MCP インストラクションとツールアノテーション)
Section titled “6. AI エージェントの安全性(MCP インストラクションとツールアノテーション)”サーバーは AI エージェントの動作を導くために MCP プロトコル機能を使用します:
サーバーインストラクション
Section titled “サーバーインストラクション”instructions フィールドは、MCP 初期化ハンドシェイク中に AI エージェントに送信されます。
MCP クライアントは通常これをモデルのシステムプロンプトに注入します。内容:
- 必須計算ルール(数量は UNITS、ステップバイステップ検証、ユーザー確認)
- 不可逆的な取引操作の安全プロトコル
- 不確実な場合はペーパーモードとより小さなサイズを使用するためのガイダンス
ツールアノテーション
Section titled “ツールアノテーション”各ツールには MCP 仕様に従ったメタデータヒントが付加されます:
- 取引ツール (
place_order、modify_order、close_position、cancel_order):destructiveHint: true、idempotentHint: false— 不可逆的、反復不可能な操作を示します - 読み取り専用ツール (
get_positions、get_quote、get_symbols、get_knowledge):readOnlyHint: true、idempotentHint: true— 自動承認しても安全
MCP クライアントは、破壊的ツールを実行する前に明示的なユーザー承認を要求するためにアノテーションを使用できます。
ツール説明の警告
Section titled “ツール説明の警告”取引ツールの説明には、エージェントに以下を思い出させる明示的な “CALCULATION SAFETY” ブロックが含まれます:
- ステップバイステップで数量を計算: 希望ロット数 × LOT_SIZE = 単位数
- 銘柄カタログから LOT_SIZE を確認
- ゼロの誤配置をクロスチェック
- 送信前にユーザーから確認を取得
制限: これらはガイダンスメカニズムであり、強制ではありません。サーバーは入力を検証しますが (スキーマ、リスクチェック)、エージェントの意図がユーザーの意図と一致するかどうかを検証することはできません。
7. マルチテナントセキュリティ(クラウドモード)
Section titled “7. マルチテナントセキュリティ(クラウドモード)”マルチテナントサーバーとして実行する場合、追加のセキュリティレイヤーが適用されます:
SSRF 保護
Section titled “SSRF 保護”サーバーは接続を開く前にすべての FIX ホストを検証します:
- ホスト許可リスト: 明示的に設定されたブローカーサーバーのみが許可されます
- ポート範囲: 標準 FIX ポートのみが受け入れられます
- プライベート IP ブロッキング: ループバック、プライベートネットワーク、リンクローカルアドレスはすべて拒否されます
検証に失敗したリクエストは 403 Forbidden で拒否されます。
ブルートフォースロックアウト
Section titled “ブルートフォースロックアウト”認証情報セットごと:
- 5 回連続の認証失敗 → 15 分のロックアウト
- ロックアウトは IP ごとではなく認証情報セットごとです
認証情報セキュリティ
Section titled “認証情報セキュリティ”生の FIX 認証情報はセッション作成後に保存されません:
- 認証情報の一方向ハッシュがセッションルーティングとログ記録に使用されます
- 生の認証情報は認証後に破棄されます
- 認証情報はリクエストごとに再検証されます
コアレッシングセキュリティ
Section titled “コアレッシングセキュリティ”同じ認証情報に対する複数の並行リクエストが到着した場合:
- 1 つの FIX ログオンのみが開始されます(コアレッシング)
- すべてのコアレッシングされたリクエストは、返す前にセッションに対して認証情報を再検証します
- 並行初期化リクエストのタイミングを利用したセッションハイジャックを防止します
セッション分離
Section titled “セッション分離”各ユーザーは完全に分離されたランタイムリソースを取得します:
- 別個の FIX 接続、トレーディング状態、ジャーナル、キルスイッチ、レートリミッター、トレードロック
- 1 人のユーザーのトレードは他のユーザーの状態またはリスク制限に影響しません
- ジャーナルエントリはユーザーごとのファイルに書き込まれます
アイドルセッションのクリーンアップ
Section titled “アイドルセッションのクリーンアップ”30 分間非アクティブだったセッションは自動的に:
- FIX Logout がブローカーに送信されます
- セッションリソースが解放されます
- アクティブセッションから削除されます
これにより、放置されたセッションからのリソース枯渇が防止されます。
8. OAuth 2.1 認証(クラウドモード)
Section titled “8. OAuth 2.1 認証(クラウドモード)”OAuth 2.1 はクラウドデプロイメントの主要な認証方法です。FIX 認証情報をブラウザフォーム経由で 入力すると、サーバーが暗号化、トークン管理、セッションライフサイクルを自動的に処理します。
トークンセキュリティ
Section titled “トークンセキュリティ”- 不透明トークン(JWT ではない) — サーバーサイドの取り消しを可能にします
- トークンはハッシュとして保存 — 生のトークンが永続化されることはありません
- アクセストークン TTL: 1 時間
- リフレッシュトークン TTL: 7 日
- 認可コード: 60 秒 TTL、単一使用
認証情報の暗号化
Section titled “認証情報の暗号化”- FIX 認証情報は保存前に暗号化されます
- ユーザーごとの暗号化キーで分離を確保
- 認証情報はリクエストごとに復号され、平文で保存されることはありません
- 認証情報は自動失効を伴うセキュアな永続ストレージに保存されます
- ブラウザベースのクライアントは、認可後にブランド化された認証情報フォームと成功ページを表示します
- マシンクライアント(プログラム的 OAuth)は認可コード付きの 302 リダイレクトを受信します
PKCE(Proof Key for Code Exchange)
Section titled “PKCE(Proof Key for Code Exchange)”- PKCE S256 はすべての認可フローで必須です
- 認可コード傍受攻撃を防止します
トークンの取り消し
Section titled “トークンの取り消し”- 明示的なトークン取り消しエンドポイントが利用可能
- リフレッシュトークンローテーション: 各リフレッシュは新しいペアを発行し、古いリフレッシュトークンは無効化されます
- 認証情報変更時: 既存のトークンは取り消され、再認可が必要です
CSRF 保護
Section titled “CSRF 保護”- 認可フォームには CSRF トークン(ランダム、単一使用)が含まれます
- リダイレクトコールバック時に state パラメーターが検証されます
- フォームはインライン JavaScript なしの POST メソッドを使用します
