最終更新: 2026年2月 | バージョン: v2.0
認証セキュリティ
アクセストークンメカニズム
ChainStreamはOAuth 2.0ベースの認証メカニズムを使用しています。Client IDとClient Secretを使用してJWT Access Tokenを生成し、API認証を行います。 認証フロー: 認証情報の仕様| 項目 | 仕様 |
|---|---|
| Client ID | アプリケーション固有識別子 |
| Client Secret | 64文字のランダム文字列 |
| Access Token | JWT形式、有効期限とスコープを含む |
| トークン有効期間 | 24時間 |
アクセストークンの生成
認証情報のセキュリティ
保管要件| 保管方法 | セキュリティレベル | 備考 |
|---|---|---|
| 環境変数 | ✅ 推奨 | バージョン管理に含めない |
| シークレット管理サービス | ✅ 最適 | AWS Secrets Manager、HashiCorp Vaultなど |
| 設定ファイル | ⚠️ 注意 | 必ず.gitignoreに追加 |
| ハードコード | ❌ 禁止 | 漏洩リスクが高い |
コード例
マルチアプリ管理
異なる環境やサービスごとに個別のアプリを作成することを推奨します:| 用途 | 推奨アプリ名 | 説明 |
|---|---|---|
| 本番環境 | prod-main | 本番ワークロード |
| テスト | test-dev | 開発・テスト |
| CI/CD | ci-pipeline | 自動テスト |
| 監視 | monitoring | モニタリングとアラート |
通信セキュリティ
TLS要件
| 項目 | 要件 |
|---|---|
| 最低バージョン | TLS 1.2 |
| 推奨バージョン | TLS 1.3 |
| 証明書検証 | 有効にする必要あり |
| 非対応 | HTTP、TLS 1.0/1.1 |
証明書検証
Webhookセキュリティ
Webhookメッセージは署名メカニズムを使用して、メッセージの送信元の信頼性を確保します。署名検証
Webhookメッセージを受信したら、Webhook Secretを使用して署名を検証し、メッセージがChainStreamからのものであり、改ざんされていないことを確認する必要があります。| 項目 | 説明 |
|---|---|
| アルゴリズム | HMAC-SHA256 |
| キー | Webhook Secret(ダッシュボードで設定) |
| 署名ヘッダー | X-Webhook-Signature |
検証例
Webhook Secretのローテーション
Webhook Secretをローテーションするには:使用状況の監視
メトリクスダッシュボード
ダッシュボードのメトリクスパネルで、APIおよびWebSocketの呼び出し統計を確認できます:| メトリクス | 説明 |
|---|---|
| リクエストIP | 送信元IPアドレス |
| User Agent | クライアント識別子 |
| ステータスコード | HTTPステータスコード |
| レイテンシー | リクエストの応答時間 |
| 消費ユニット | このリクエストで消費された使用量ユニット |
| 累計使用量 | 累計消費使用量 |
チャートデータ
メトリクスパネルでは、複数の時間軸でチャートを提供します:- 時間単位 — 過去24時間の呼び出しトレンドを確認
- 日単位 — 過去30日間の呼び出しトレンドを確認
- 月単位 — 過去の月次統計を確認
セキュリティモニタリング
🚧 近日公開 — セキュリティモニタリング機能は開発中で、間もなく利用可能になります。
- 異常検知 — 認証失敗の急増、異常な地域からのアクセスなどを自動検知
- アラート通知 — メールおよびWebhookアラート
- 自動保護 — 一時的なブロック、レート制限など
IPホワイトリスト
🚧 近日公開 — IPホワイトリスト機能は開発中で、間もなく利用可能になります。
- 単一IPの設定(例:
203.0.113.50) - IP範囲の設定(例:
203.0.113.0/24) - 複数IP(カンマ区切り)
一般的な攻撃への対策
中間者攻撃
攻撃手法: 攻撃者がクライアントとサーバー間の通信を傍受する。 対策:| 対策 | 説明 |
|---|---|
| HTTPS強制 | TLS 1.2以上のみサポート |
| 証明書検証 | 証明書の検証を有効にする必要あり |
| HSTS | HTTPS接続を強制 |
インジェクション攻撃
攻撃手法: 攻撃者が悪意のある入力データを使用して不正な操作を試みる。 対策:| 対策 | 説明 |
|---|---|
| 入力バリデーション | 厳格なパラメータ型チェック |
| パラメータ化クエリ | SQL/NoSQLインジェクションの防止 |
| 出力エンコーディング | XSSの防止 |
認証情報漏洩時の対応
Client Secretが漏洩した疑いがある場合は、直ちに以下の手順を実行してください:セキュリティエラーコード
認証関連
| エラーコード | HTTPステータス | 説明 |
|---|---|---|
UNAUTHORIZED | 401 | 認証情報が提供されていない |
EXPIRED_TOKEN | 401 | Access Tokenが期限切れ |
INVALID_TOKEN | 401 | Access Tokenが無効 |
INVALID_CREDENTIALS | 401 | Client IDまたはSecretが不正 |
アクセス制御関連
| エラーコード | HTTPステータス | 説明 |
|---|---|---|
FORBIDDEN | 403 | 権限がないまたはクォータ超過 |
RATE_LIMITED | 429 | リクエストレート超過 |
INSUFFICIENT_SCOPE | 403 | トークンの権限が不足 |
Webhook関連
| エラーコード | 説明 |
|---|---|
INVALID_SIGNATURE | Webhook署名検証に失敗 |
MISSING_SIGNATURE | 署名ヘッダーがない |
エラーレスポンス例
セキュリティ設定チェックリスト
基本設定(必須)
- APIアクセスにHTTPSを使用
- Client IDとClient Secretを環境変数またはシークレット管理サービスに保管
- 認証情報をコードリポジトリにコミットしない
- 本番環境/テスト環境で異なるアプリを使用
- Webhook署名を適切に検証
上級設定(推奨)
- シークレット管理サービスの統合(AWS Secrets Manager / HashiCorp Vault)
- メトリクスダッシュボードで呼び出し統計を定期的に確認
- 異なるサービスごとに個別のアプリを作成
エンタープライズ設定(任意)
- SIEMシステムと統合してログ分析
- セキュリティインシデント対応プロセスの確立
FAQ
Client Secretが漏洩した場合はどうすればよいですか?
Client Secretが漏洩した場合はどうすればよいですか?
直ちにダッシュボードにログインしてそのアプリを削除し、新しいアプリを作成して、すべてのアプリケーション設定を更新してください。認証情報漏洩時の対応を参照してください。
Access Tokenが期限切れになった場合は?
Access Tokenが期限切れになった場合は?
Access Tokenの有効期間は24時間です。推奨事項:
- トークンのキャッシュ — 有効期間内は同じトークンを再利用
- 早めの更新 — 期限切れの約1時間前にトークンを更新
- エラーリトライ — 401エラーを受信したら自動的に新しいトークンを取得
API呼び出し統計はどこで確認できますか?
API呼び出し統計はどこで確認できますか?
ダッシュボード → メトリクスにログインすると、リクエストIP、ステータスコード、レイテンシー、消費ユニット、時間軸チャートを確認できます。
Webhook署名検証の失敗をトラブルシューティングするには?
Webhook署名検証の失敗をトラブルシューティングするには?
一般的な原因:
- Secretの不一致 — 正しいWebhook Secretを使用しているか確認
- ペイロード処理エラー — 署名計算に元のJSON文字列を使用しているか確認
- 署名ヘッダーの欠落 — リクエストヘッダーに
X-Webhook-Signatureが含まれているか確認
複数のアプリを作成できますか?
複数のアプリを作成できますか?
はい。異なる環境(本番/テスト)や異なるサービスごとに個別のアプリを作成することを推奨します。管理やトラブルシューティングが容易になります。
関連ドキュメント
認証
認証と認証情報の管理
データプライバシー
データプライバシーポリシー
エラーコード
完全なエラーコード一覧
Webhookの基礎
Webhookの設定と使用方法

