セキュリティ
セキュリティへの取り組み
Velarは、企業のAI利用ログ・コスト情報・承認履歴を安全に扱うため、暗号化・権限管理・監査ログ・レート制限を組み合わせて設計されています。このページでは現時点の設計方針と、今後の強化予定を正直に開示します。
✓設計済み・実装済み△準備中・将来対応予定
1. データ保護
✓
通信の暗号化 — すべての通信はHTTPS（TLS 1.2以上）で保護されています
✓
生データ非送信設計（CLI） — CLIはファイル内容・プロンプト本文をそもそも受信しません。ダッシュボードに保管されるのはIngest Tokenのハッシュ・判定結果メタデータのみです（詳細はTrust Center）
✓
秘密情報の非公開 — Secretや認証情報をクライアント側に表示しない設計です
✓
環境変数の分離 —
NEXT_PUBLIC_* にSecretを置かない設計です✓
データ保管地 — データベース（Neon/Supabase）は東京リージョンに保管されており、監査ログ等のアプリケーションデータもそこに保存されます。ただしホスティング（Vercel）や一部の委託先（Stripe、Anthropic等）は米国拠点のため、処理の一部は海外で行われます。委託先の全リストはプライバシーポリシーをご覧ください
2. APIキーの扱い
✓
Ingest TokenとProvider API Keyは別物 — Velarが発行するIngest Tokenは、CLIが判定結果メタデータを報告するための専用トークンです。Anthropic・OpenAI等のLLMプロバイダーAPIキーとは無関係で、CLIの動作にProviderのAPIキーは一切関与しません
△
Provider APIキー保管機能（ベータ中は無効） — ダッシュボードには、CLIの操作判定・承認フローとは独立した、コスト集計用のProvider APIキー登録機能（AES-256-GCM暗号化保管）のコードが存在しますが、Feature Flagでデフォルト無効化されており、登録画面・APIともに「利用不可」を返します。Preview/Enterprise向けの将来機能として計画されており、現時点でVelarがProvider APIキーを保管することはありません
✓
SHA-256ハッシュ保管 — Ingest Tokenは発行時に一度だけ平文表示され、以降はSHA-256ハッシュのみを保存します。平文は再表示されません
✓
削除・再発行 — Ingest Tokenはいつでも失効・再発行できます
3. 権限管理
✓
RBAC（ロールベースアクセス制御） — 管理者・メンバー・閲覧者などの権限分離を設計済みです
✓
管理者権限の要求 — 重要操作（プロジェクト削除・メンバー削除・課金変更等）は管理者権限を要求します
✓
セッション管理 — 認証セッションは安全なCookieで管理し、ログアウト時に無効化します
△
SSO / SAML / SCIM — Enterprise導入時に個別対応予定です
△
IPアドレス制限 — Enterprise向けに将来的に対応予定です
4. 監査ログ
✓
操作記録 — 重要操作（ログイン・設定変更・承認・拒否・削除等）を監査ログとして記録しています
✓
追跡性 — 誰が・いつ・何をしたかをログから確認できます
△
Enterprise長期保管 — 監査ログの長期保存機能はまだ実装しておらず、Enterpriseプランでの個別対応を予定しています
△
改ざん検知 — ハッシュチェーン・HMACによる改ざん検知は設計準備中です
△
SIEM連携 — 外部SIEMへのログ転送は将来的に対応予定です
5. レート制限・攻撃対策
✓
主要APIのレート制限 — ログイン・イベント送信など主要なAPIエンドポイントにレート制限を設定しています
✓
ログイン試行制限 — ブルートフォース攻撃に対してログイン試行回数を制限しています
✓
CSRF対策 — クロスサイトリクエストフォージェリ（CSRF）への対策を実装済みです
✓
XSS対策 — ユーザー入力のサニタイズとコンテンツセキュリティポリシー（CSP）を設定しています
✓
セキュリティヘッダー — HSTS・X-Frame-Options・X-Content-Type-Options等のセキュリティヘッダーを設定しています
✓
入力値バリデーション — APIリクエストはZodスキーマで入力値を検証しています
△
WAF（Webアプリケーションファイアウォール） — 将来的に対応予定です
6. AIエージェントの重要操作
✓
実行前承認 — critical判定の操作（本物の.env読み書き・本番DB操作・破壊的コマンド・デプロイ・外部送信・CI設定改変等、39ルールで判定）は、実行前にターミナルまたはSlackでの承認が必要です
✓
承認・拒否履歴の記録 — 承認・拒否・タイムアウトの操作者・日時・ルールIDを監査ログに保存します
✓
fail-closed設計 — 端末がない・Slackが応答しない・120秒応答がない、いずれの場合もブロック側に倒します（詳細はTrust Center）
△
組織ごとのSlack連携 — Slack承認は現在デプロイ単位の単一チャンネルにのみ投稿されており、他組織の操作内容が別組織のチャンネルに投稿されるのを避けるため、オーナー自身の組織でのみ有効化しています。それ以外の組織は自動的に端末（ターミナル）での承認にフォールバックします
△
緊急停止（Kill Switch相当） — 未実装です。将来のRoadmap候補として検討中です
6b. Webhook・外部リクエスト・署名検証
△
Stripe Webhook署名検証 — 課金Webhookのコード自体はHMAC-SHA256署名を検証し未署名・不一致のリクエストを拒否する実装になっていますが、オープンベータ期間中はStripe未接続のため（詳細は料金ページ）、このエンドポイントは実際の課金トラフィックをまだ処理していません
✓
Slack署名検証 — Slackからの承認ボタン操作（Interactions）はSlackの署名（v0 HMAC-SHA256、300秒の時刻窓）を検証し、不一致のリクエストを拒否します
✓
Webhook受信のべき等処理 — 重複イベントによる二重課金・二重処理を防ぐべき等キー管理を設計済みです
△
SSRF（サーバーサイドリクエストフォージェリ）対策 — 外部URLを受け取るエンドポイントへのSSRF対策強化を準備中です
△
監査ログへのHMACチェーン — ログエントリに前のログのHMACを連鎖させる改ざん検知設計を準備中です
7. インシデント対応
障害・セキュリティイベントが発生した場合、以下のフローで対応します。
- 障害の検知・初動確認
- 影響範囲の確認
- 一時対応（サービス停止・アクセス遮断等）
- サービスの復旧
- 原因分析
- 再発防止策の策定・実施
- 必要に応じた顧客通知（個人情報漏洩時は個人情報保護委員会への報告含む）
障害情報は /status で確認できます。
8. 認証・準拠状況
△
SOC 2 Type II — 現在未取得。将来的な対応を検討中です
△
ISO 27001 — 現在未取得。将来的な対応を検討中です
△
セキュリティレビュー対応 — Enterprise導入時はセキュリティレビュー・質問票への個別対応予定です
※ 認証取得状況は変更になる場合があります。詳細はTrust Centerまたはご意見箱よりご連絡ください。