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

認証セキュリティ

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

ChainStreamはOAuth 2.0ベースの認証メカニズムを使用しています。Client IDとClient Secretを使用してJWT Access Tokenを生成し、API認証を行います。 認証フロー: 認証情報の仕様
項目仕様
Client IDアプリケーション固有識別子
Client Secret64文字のランダム文字列
Access TokenJWT形式、有効期限とスコープを含む
トークン有効期間24時間

アクセストークンの生成

import { AuthenticationClient } from 'auth0';

const auth0Client = new AuthenticationClient({
  domain: 'dex.asia.auth.chainstream.io',
  clientId: process.env.CHAINSTREAM_CLIENT_ID,
  clientSecret: process.env.CHAINSTREAM_CLIENT_SECRET
});

const { data } = await auth0Client.oauth.clientCredentialsGrant({
  audience: 'https://api.dex.chainstream.io'
});

const accessToken = data.access_token;

認証情報のセキュリティ

保管要件
Client SecretはChainStreamサービスにアクセスするための重要な認証情報です。漏洩するとサービスの不正利用や金銭的損失につながる可能性があります。
保管方法セキュリティレベル備考
環境変数✅ 推奨バージョン管理に含めない
シークレット管理サービス✅ 最適AWS Secrets Manager、HashiCorp Vaultなど
設定ファイル⚠️ 注意必ず.gitignoreに追加
ハードコード❌ 禁止漏洩リスクが高い

コード例

// ❌ 危険: 認証情報のハードコード
const clientId = "your_client_id";
const clientSecret = "your_secret";

// ❌ 危険: バージョン管理にコミット
// config.json: { "client_id": "...", "client_secret": "..." }

// ✅ 安全: 環境変数を使用
const clientId = process.env.CHAINSTREAM_CLIENT_ID;
const clientSecret = process.env.CHAINSTREAM_CLIENT_SECRET;

// ✅ 安全: シークレット管理サービスを使用
const credentials = await secretsManager.getSecret('chainstream-credentials');

マルチアプリ管理

異なる環境やサービスごとに個別のアプリを作成することを推奨します:
用途推奨アプリ名説明
本番環境prod-main本番ワークロード
テストtest-dev開発・テスト
CI/CDci-pipeline自動テスト
監視monitoringモニタリングとアラート

通信セキュリティ

TLS要件

項目要件
最低バージョンTLS 1.2
推奨バージョンTLS 1.3
証明書検証有効にする必要あり
非対応HTTP、TLS 1.0/1.1

証明書検証

本番環境では証明書検証を絶対にスキップしないでください。中間者攻撃のリスクにさらされます。
// ❌ 危険: 証明書検証のスキップ
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

// ✅ 安全: 通常の証明書検証(デフォルト動作)
const response = await fetch('https://api.chainstream.io/v1/...');

Webhookセキュリティ

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

署名検証

Webhookメッセージを受信したら、Webhook Secretを使用して署名を検証し、メッセージがChainStreamからのものであり、改ざんされていないことを確認する必要があります。
項目説明
アルゴリズムHMAC-SHA256
キーWebhook Secret(ダッシュボードで設定)
署名ヘッダーX-Webhook-Signature

検証例

const crypto = require('crypto');

function verifyWebhookSignature(payload, signature, secret) {
  const expectedSignature = crypto
    .createHmac('sha256', secret)
    .update(JSON.stringify(payload))
    .digest('hex');
  
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expectedSignature)
  );
}

// Expressミドルウェアの例
app.post('/webhook', (req, res) => {
  const signature = req.headers['x-webhook-signature'];
  const isValid = verifyWebhookSignature(
    req.body,
    signature,
    process.env.WEBHOOK_SECRET
  );
  
  if (!isValid) {
    return res.status(401).send('Invalid signature');
  }
  
  // Webhookメッセージを処理
  console.log('Received webhook:', req.body);
  res.status(200).send('OK');
});

Webhook Secretのローテーション

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

新しいSecretを生成

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

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

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

署名を検証

新しい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以上のみサポート
証明書検証証明書の検証を有効にする必要あり
HSTSHTTPS接続を強制

インジェクション攻撃

攻撃手法: 攻撃者が悪意のある入力データを使用して不正な操作を試みる。 対策:
対策説明
入力バリデーション厳格なパラメータ型チェック
パラメータ化クエリSQL/NoSQLインジェクションの防止
出力エンコーディングXSSの防止

認証情報漏洩時の対応

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

アプリを即座に削除

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

新しいアプリを作成

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

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

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

メトリクスを確認

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

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

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

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

認証関連

エラーコードHTTPステータス説明
UNAUTHORIZED401認証情報が提供されていない
EXPIRED_TOKEN401Access Tokenが期限切れ
INVALID_TOKEN401Access Tokenが無効
INVALID_CREDENTIALS401Client IDまたはSecretが不正

アクセス制御関連

エラーコードHTTPステータス説明
FORBIDDEN403権限がないまたはクォータ超過
RATE_LIMITED429リクエストレート超過
INSUFFICIENT_SCOPE403トークンの権限が不足

Webhook関連

エラーコード説明
INVALID_SIGNATUREWebhook署名検証に失敗
MISSING_SIGNATURE署名ヘッダーがない

エラーレスポンス例

{
  "error": {
    "code": "EXPIRED_TOKEN",
    "message": "Access token has expired",
    "details": {
      "expired_at": "2024-01-15T10:30:00Z"
    }
  }
}

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

基本設定(必須)

  • 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の設定と使用方法