メインコンテンツへスキップ
ChainStreamは、APIアクセスを保護するために複数のセキュリティ機構を採用しています。本ドキュメントでは、APIセキュリティのベストプラクティス、一般的な脅威への対策、セキュリティ設定ガイドラインについて説明します。
最終更新: 2026年2月 | バージョン: v2.0

認証セキュリティ

アクセストークンメカニズム

ChainStreamはOAuth 2.0ベースの認証メカニズムを使用しています。Client IDとClient Secretを使用してJWT Access Tokenを生成し、API認証を行います。 認証フロー: 認証情報の仕様

アクセストークンの生成

認証情報のセキュリティ

保管要件
Client SecretはChainStreamサービスにアクセスするための重要な認証情報です。漏洩するとサービスの不正利用や金銭的損失につながる可能性があります。

コード例

マルチアプリ管理

異なる環境やサービスごとに個別のアプリを作成することを推奨します:

通信セキュリティ

TLS要件

証明書検証

本番環境では証明書検証を絶対にスキップしないでください。中間者攻撃のリスクにさらされます。

Webhookセキュリティ

Webhookメッセージは署名メカニズムを使用して、メッセージの送信元の信頼性を確保します。

署名検証

Webhookメッセージを受信したら、Webhook Secretを使用して署名を検証し、メッセージがChainStreamからのものであり、改ざんされていないことを確認する必要があります。

検証例

Webhook Secretのローテーション

Webhook Secretをローテーションするには:
1

新しいSecretを生成

ダッシュボード → Webhooks → エンドポイントを選択 → Secretをローテーション
2

アプリケーション設定を更新

アプリケーションで新しいWebhook Secretに更新
3

署名を検証

新しいSecretで署名が正しく検証されることを確認

使用状況の監視

メトリクスダッシュボード

ダッシュボードのメトリクスパネルで、APIおよびWebSocketの呼び出し統計を確認できます:

チャートデータ

メトリクスパネルでは、複数の時間軸でチャートを提供します:
  • 時間単位 — 過去24時間の呼び出しトレンドを確認
  • 日単位 — 過去30日間の呼び出しトレンドを確認
  • 月単位 — 過去の月次統計を確認
確認パス: ダッシュボード → メトリクス

セキュリティモニタリング

🚧 近日公開 — セキュリティモニタリング機能は開発中で、間もなく利用可能になります。
利用可能になると、以下をサポートします:
  • 異常検知 — 認証失敗の急増、異常な地域からのアクセスなどを自動検知
  • アラート通知 — メールおよびWebhookアラート
  • 自動保護 — 一時的なブロック、レート制限など

IPホワイトリスト

🚧 近日公開 — IPホワイトリスト機能は開発中で、間もなく利用可能になります。
利用可能になると、以下をサポートします:
  • 単一IPの設定(例: 203.0.113.50
  • IP範囲の設定(例: 203.0.113.0/24
  • 複数IP(カンマ区切り)

一般的な攻撃への対策

中間者攻撃

攻撃手法: 攻撃者がクライアントとサーバー間の通信を傍受する。 対策:

インジェクション攻撃

攻撃手法: 攻撃者が悪意のある入力データを使用して不正な操作を試みる。 対策:

認証情報漏洩時の対応

Client Secretが漏洩した疑いがある場合は、直ちに以下の手順を実行してください:
1

アプリを即座に削除

ダッシュボード → アプリ → 対象アプリを選択 → 削除
2

新しいアプリを作成

ダッシュボード → アプリ → 新しいアプリを作成
3

アプリケーション設定を更新

古い認証情報を使用しているすべてのアプリケーションで、新しいClient IDとSecretに更新
4

メトリクスを確認

ダッシュボード → メトリクス → 異常な呼び出しがないかチェック
5

セキュリティプラクティスを見直す

漏洩原因を調査し、セキュリティ対策を改善

セキュリティエラーコード

認証関連

アクセス制御関連

Webhook関連

エラーレスポンス例


セキュリティ設定チェックリスト

基本設定(必須)

  • APIアクセスにHTTPSを使用
  • Client IDとClient Secretを環境変数またはシークレット管理サービスに保管
  • 認証情報をコードリポジトリにコミットしない
  • 本番環境/テスト環境で異なるアプリを使用
  • Webhook署名を適切に検証

上級設定(推奨)

  • シークレット管理サービスの統合(AWS Secrets Manager / HashiCorp Vault)
  • メトリクスダッシュボードで呼び出し統計を定期的に確認
  • 異なるサービスごとに個別のアプリを作成

エンタープライズ設定(任意)

  • SIEMシステムと統合してログ分析
  • セキュリティインシデント対応プロセスの確立

FAQ

直ちにダッシュボードにログインしてそのアプリを削除し、新しいアプリを作成して、すべてのアプリケーション設定を更新してください。認証情報漏洩時の対応を参照してください。
Access Tokenの有効期間は24時間です。推奨事項:
  1. トークンのキャッシュ — 有効期間内は同じトークンを再利用
  2. 早めの更新 — 期限切れの約1時間前にトークンを更新
  3. エラーリトライ — 401エラーを受信したら自動的に新しいトークンを取得
ダッシュボード → メトリクスにログインすると、リクエストIP、ステータスコード、レイテンシー、消費ユニット、時間軸チャートを確認できます。
一般的な原因:
  1. Secretの不一致 — 正しいWebhook Secretを使用しているか確認
  2. ペイロード処理エラー — 署名計算に元のJSON文字列を使用しているか確認
  3. 署名ヘッダーの欠落 — リクエストヘッダーにX-Webhook-Signatureが含まれているか確認
はい。異なる環境(本番/テスト)や異なるサービスごとに個別のアプリを作成することを推奨します。管理やトラブルシューティングが容易になります。

関連ドキュメント

認証

認証と認証情報の管理

データプライバシー

データプライバシーポリシー

エラーコード

完全なエラーコード一覧

Webhookの基礎

Webhookの設定と使用方法