
セルフホスト型脅威インテリジェンスプラットフォーム — フィード集約、AIトリアージ、MITRE ATT&CKカバレッジ、Sentinel統合の検知エンジニアリング。スタンドアロンまたは完全なAzure統合で動作します。
60以上のセキュリティベンダーからのRSSフィードを集約し、AIトリアージを実行し、検出結果をRunZeroの資産インベントリと照合し、ダークモードのWebダッシュボードを通じて実行可能なアラートを表示する、セルフホスト型の脅威インテリジェンスプラットフォームです。
クラウド依存ゼロでスタンドアロンで動作するように構築されており、Azure/Entra/Sentinel環境に完全統合することもできます — お持ちの環境に合ったティアを選択してください。
3つすべてがまったく同じアプリケーションコードを実行します — 変わるのは設定される環境変数のみです。完全なリファレンスについては環境変数を参照してください。```bash
./scripts/setup-basic.sh
./scripts/setup-basic-api.sh
./scripts/setup-azure.ps1
2つのbashスクリプトは、ローカルのPostgresコンテナを起動し、スキーマを適用し、`backend/.env` / `frontend/.env.local` を生成します — その後、アプリを実際に起動するための2つのコマンド(`pip install` + バックエンド実行、`npm install` + フロントエンド開発サーバー実行)を表示します。`setup-azure.ps1` は `infra/provision.ps1` の薄いラッパーであり、実際のAzure Container Appsデプロイ手順書です。
---
## 機能
- **フィード集約** — 60以上のTier 1/2/3セキュリティRSSフィードをスケジュールに従ってポーリングし、重複排除とプロモーションコンテンツのフィルタリングを自動で行います
- **AIトリアージ** — 各エントリを重要度(Critical/High/Medium/Low/Informational)、MITRE ATT&CK TTP、平易な英語の要約で分類します。プロバイダーはモジュール式で、Anthropic API直接またはAzure AI Foundryを、機能を損なうことなく1つの環境変数で切り替え可能です
- **IOC抽出** — 各エントリからIP、ドメイン、URL、ファイルハッシュ、CVEを自動抽出します
- **RunZero統合** — 資産インベントリを同期し、脅威インテリジェンスを稼働中の資産と照合します。CVE、ソフトウェア名、OSバージョン、IPアドレスでマッチングします。`RUNZERO` 配下には3つのサブタブがあります: **Matches**(インベントリと照合されたエントリ。重要度/日付/信頼度/KEVでフィルタ可能)、**Exposure**(組織レベルの確定/可能性のある状態と修復トラッキング)、**Metrics**(取り込みと修復の経時的なトレンド)
- **Your Stack** — 環境内のソフトウェア/OSを定義し、すべてのエントリを関連性で再スコアリングします
- **IOC台帳** — 抽出されたすべてのインジケータの検索可能な台帳。エントリの相互参照とSTIX/CSVエクスポート付き
- **MITRE ATT&CKマトリクス** — 取り込んだ脅威インテリジェンス全体にわたるTTPカバレッジのヒートマップ
- **フィードヘルスダッシュボード** — フィードごとのポーリング状態、連続失敗のトラッキング、7日間の記事ボリューム
- **Detections** — 検出として登録されたすべて(AI生成、独自ファイルからのインポート、稼働中のSentinelワークスペースからの同期)を網羅する9タブのレビュー画面(下記参照)
- **モジュラー認証** — ロールベースアクセスを備えたMicrosoft Entra ID SSO、またはAzure依存ゼロの単一共有ローカルAPIキー。フロントエンドが自動検出します。[認証モード](#auth-modes)を参照
### 検出関連の2つの機能
このリポジトリは、実際には「detections」という傘の下で、関連しつつも独立して使用可能な2つのものを提供しています:
1. **`DETECTIONS` タブ** — 自己完結型のレビュー画面で、9つのサブタブに分かれています:
- **All Detections** — 登録された分析の完全なカタログ。テクニック/ディスポジション/レビュー状態でフィルタ可能で、それぞれを展開すると説明と完全なKQLが表示されます。
- **Defender Custom Detections** — 同じカタログですが、Sentinel分析ルールではなくMicrosoft Defender for Endpointのカスタム検出ルール向けの検出に限定されます。
- **Alignment Reviews** — 検出分析がMITREテクニックに対して登録されるたびに、AIチェックがその実際のカバレッジをMITRE自身のそのテクニックの説明と比較します。乖離している場合、またはテクニックを部分的にしかカバーしていない場合、AIの推論、提案されたKQL修正、およびその修正自体の検証結果(静的ゲート + バックテスト)とともに、人間のレビュー項目としてここに表示されます — 盲目的な提案ではありません。
- **Disposition Alerts** — 腐敗検出キュー: 承認された分析のテレメトリが劣化したり、基盤となるルールがエラーを出し始めたりすると、再レビューのためにここでフラグが立てられます。共有されたMITREテクニックだけでなく、その検出自体の名前で識別されます。
- **Generated Hunts** — 検出はハントにグループ化されます(現在はインポートされたファイルごとに1つ。その統合がリリースされると、元のTI記事/detections.aiプロジェクトごとに1つ)。Microsoft Sentinel自身のHunts機能と一致します。ハントは、`Microsoft.SecurityInsights/hunts` オブジェクトとその構成要素である保存済み検索クエリとして、実際のSentinelワークスペースに同期できます(`SENTINEL_HUNTING_SYNC_ENABLED` と `mode` — off/manual/auto — によって制御され、Settings > API Settingsでチームごとに設定可能。オプトインしない限り、暗黙の自動プッシュは決して行われません)。
- **Sentinel Hunts** — このアプリ自身の同期履歴ではなくARMから直接取得された、SentinelワークスペースのHunting機能に実際にデプロイされているもののライブインベントリ。クエリごとのテスト/チューニング提案が含まれ、その場で適用または却下できます。
- **Sentinel Analytics Rules** — Microsoft SentinelのAnalytics Rules(`Microsoft.SecurityInsights/alertRules`)についての同じ考え方 — Huntingとは異なるSentinelリソースタイプで、これらはスケジュールに従って実際にインシデント/アラートを発火させるものです — 同じチューニング提案の適用/却下ワークフローを備えています。
- **Local Detections** — 下記の[SentinelまたはAIプロバイダーなしでの実行](#running-without-sentinel-or-an-ai-provider-local-detections-import)を参照してください。
- **Audit Log**(管理者専用) — このアプリが実際に実行したすべてのチェックのクロスパイプライン記録: AI生成検出のゲート/コントロールプローブ結果、Sentinelハント同期の試行、Sentinelハントクエリ/分析ルールのテスト実行を、1つのページネーションされたフィルタ可能なリストに統合したもの — 単一のレビュータブでは実現できない範囲を意図的にカバーしています。
レビュー画面自体はメインバックエンド内で完全に動作し、追加のデプロイは不要です。そのAPI設計は完全に自己完結型でありながら、意図的に下記のdetections.aiの規約に従っています。
2. **detections.aiパイプラインオーケストレーター — 近日公開。** detections.aiはAI支援による検出生成のための公開APIを開発中で、このリポジトリにはそれ用に構築された実際の統合(`backend/detection_pipeline/orchestrator.py`)があり、トリアージ済みの脅威インテリジェンスを受け取り、既存の検出カバレッジと照合し、スケジュールジョブとしてSentinelワークスペース用のKQLドラフトを生成します。この統合はAPIが利用可能になり次第それをサポートしますが、この公開リリースにはまだ含まれていません。それまでの間、**Detectionsタブを使用するためにこれは一切必要ありません** — 下記の[Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import)が、AI生成なし・Sentinelなしのセットアップで今日実現できる、同じ「実際の検出をこのアプリに取り込む」という目標をカバーしています。
### SentinelまたはAIプロバイダーなしでの実行: Local Detections Import
アプリの名前と主要な売り文句を考えると、**Basic** ティアのセルフホスターからの最も一般的な質問はおそらく *「SentinelもAIプロバイダーも設定していないのですが、それでもDetections/Huntsタブから何か得られますか?」* でしょう。答えはイエスです: アプリを独自の検出ルールファイルのフォルダ(手書き、実際のSentinel/Defenderテナントからのエクスポート、または公開のSigma/Sentinelルールリポジトリから取得したもの)に向ければ、それらをカタログ化し、MITREタグを付け、静的に検証します — そのいずれにもSentinel接続も `DETECTIONS_AI_API_KEY`/Anthropicキーも不要です。
- **初日からサポートされるフォーマット:** 生の `.kql`/`.txt`/`.yar`/`.spl` または任意の拡張子のファイル。それぞれ任意で `.json`/`.yaml` サイドカー(`{"file": "myrule.kql", "title": "...", "description": "...", "technique_id": "T1059.001"}`)とペアにして、Microsoft自身のエクスポートでは別途宣言する必要のないメタデータを付与できます。YARA、Suricata、Sigma YAML(単一または複数ドキュメント)、Splunk SPL、およびMicrosoft自身のネイティブエクスポートであるAnalytics Rule/Hunting Query JSON(`Scheduled` 種別のルールのみがこのアプリで評価できる生のKQLクエリを持ちます — その他の種別は認識され報告されますが、黙ってスキップされることはありません)。
- **インポートされたファイルで実際に実行されるもの:** KQLコンテンツに対する静的検証(AI生成パスが使用するのと同じ耐久性/検出事項エンジン)。AIプロバイダーを設定して*いれば*MITREアラインメントチェックも実行されます(Sentinelとは独立した軸で、片方のみ、両方、またはどちらもなしが可能)。Sentinel依存のもの(バックテスト、テレメトリプローブ、ディスポジショントラッキング)はすべてスコープ外のままで、誤解を招く空白セルではなく「no Sentinel connection configured」と表示されます。
- **表示される場所:** インポートされたコンテンツは通常のハント/検出行になります — 同じテーブル、同じレビューワークフロー、AIパイプラインが生成するものと同じMITREテクニック表示 — そのため専用タブだけでなく、通常の `ALL DETECTIONS`/`GENERATED HUNTS` ビューにも表示されます。専用の **Local Detections** サブタブ(`DETECTIONS` 配下、インポートのトリガーは管理者専用)は、フォルダを指定してファイルごとの進捗/結果を確認する場所です。
- **セットアップ:** `LOCAL_IMPORT_DIR` をバックエンドのファイルシステム上の絶対パス(コンテナデプロイではマウントされたボリューム)に設定します — インポートされるものはすべてそのルート配下に存在する必要があります。UIではその下のサブパスを選択でき、任意のファイルシステム位置を指定することはできません。[環境変数](#environment-variables)を参照してください。
- **すぐに試す:** `examples/local-detections-samples/` には、すぐにインポートできる小さなフォルダが同梱されています — 2つの有効なKQLルール(1つはその仕組みを示すために `.json` サイドカーとペア)、1つの意図的に無効なルール(invalidフラグ付きバナーを確認するため)、1つの認識されないファイル(インポート失敗バナーを確認するため)。`LOCAL_IMPORT_DIR` をそこに向ければ、ルールを書くことなく、最初のインポートで3つの結果状態すべてを確認できます。
**Local Detections** — 完了したインポート実行: サマリーバナーは、正常にインポートされたファイルと並んで、カタログ化されたものの静的解析によってinvalidとフラグが立てられたファイル(ここでは、単一のハードコードされたハッシュでアラートするルール)を指摘しており、すべてのファイルが下の通常のハント/検出行になります

---
## スクリーンショット
以下のスクリーンショットはすべて、ドキュメント用に生成された合成データ(偽の組織名、RFC 5737の例示用IP、`.example` ドメイン)を使用しています — 実際の脅威インテリジェンスや顧客データは含まれていません。
**Feed** — トリアージ済みの脅威インテリジェンスエントリを、重要度、タグ、IOC、TTPで閲覧・フィルタリング

<br>
**Dashboard** — 重要度の内訳とトップMITRE ATT&CKテクニックを一目で確認

<br>
**MITRE ATT&CK** — 取り込んだインテリジェンス全体にわたるテクニックカバレッジの完全なマトリクスヒートマップ

<br>
**Your Stack** — 環境を定義すると、フィードエントリが関連性で再スコアリングされます

<br>
**IOCs** — 抽出されたすべてのインジケータの検索可能な台帳。STIX/CSVエクスポート付き

<br>
**Integrations** — Sentinel、Defender、RunZeroのコネクタ概要: 設定済み/有効化状態と、それぞれの専用タブへのショートカット

<br>
**RunZero** — 資産相関、組織レベルのエクスポージャートラッキング、修復メトリクス。すべてRunZeroインベントリから取得

<br>
**Exposure** — 脅威マッチ数でランク付けされた組織。任意のカードをクリックするとマッチしたエントリを確認できます

<br>
**Detections** — 登録された分析の完全なカタログ(AI生成とローカルインポートの両方)。それぞれに静的ゲート/バックテスト/レビュー状態とMITREテクニックが付きます

<br>
**Settings** — AIトリアージコントロール、フィードヘルス監視、ソース信頼スコア、ユーザー管理

---
## アーキテクチャ```
┌─────────────────────────────────────────┐
│ Next.js 16 frontend (port 3000) │
│ Tailwind CSS · dark theme │
└──────────────┬──────────────────────────┘
│ REST API (Bearer token)
┌──────────────▼──────────────────────────┐
│ FastAPI backend (port 8000) │
│ APScheduler · slowapi rate limiting │
└──┬──────────┬──────────┬────────────┬───┘
│ │ │ │
Postgres AI provider RunZero API detections.ai
(modular: (asset sync) (coming soon --
Anthropic or see Features below)
Azure AI Foundry)
バックエンド (backend/) — Python 3.12 + FastAPI。すべてのストレージに Postgres を使用(SQLite と Azure Blob Storage は完全に廃止されました)。AI プロバイダーと認証方式はどちらも環境変数で選択され、ハードコードされていません — 以下を参照してください。
フロントエンド (frontend/) — Next.js 16、プレーン JavaScript、Tailwind CSS。読み込み時にバックエンドから認証モードを自動検出します。
インフラ (infra/) — Container Apps、Key Vault、Container Registry 用の Azure Bicep テンプレート(apps.bicep + platform.bicep + app-stack.bicep、provision.ps1 経由でデプロイ)。Azure + API ティアにのみ関連します。
AZURE_AD_TENANT_ID が設定されている → Entra モード: Microsoft Entra ID SSO、ユーザーごとのロール(最初のログインが管理者になり、それ以外はデフォルトで閲覧者)。
AZURE_AD_TENANT_ID が未設定 → ローカルモード: 単一の共有 LOCAL_API_KEY が、それを持つ誰にでも管理者アクセスを付与します。ユーザー管理なし、Azure 依存なし。フロントエンドは読み込み時に GET /api/auth/mode を呼び出し、対応するログイン画面を自動的にレンダリングします — フロントエンド側で設定するものは何もありません。
どちらのモードもその後は同じ種類のアプリ署名付き JWT を発行するため、他のすべてのルート(require_auth/require_admin)は、どちらのモードがトークンを発行したかに関係なく同一に動作します。
scripts/setup-basic.sh または scripts/setup-basic-api.sh を実行してください(デプロイティアを参照) — これらが Postgres と .env の生成を処理します。その後:```bash
cd backend && pip install -r requirements.txt && uvicorn main:app --reload --port 8000
cd frontend && npm install && npm run dev
### 手動セットアップ```bash
cd backend
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
cp env.example .env # fill in required values — see Environment Variables below
uvicorn main:app --reload --port 8000
curl -fsSL https://raw.githubusercontent.com/yourusername/ccswitch/main/install.sh | bash
# リポジトリをクローン
git clone https://github.com/yourusername/ccswitch.git
cd ccswitch
# インストールスクリプトを実行
./install.sh
curl -fsSL https://raw.githubusercontent.com/yourusername/ccswitch/main/uninstall.sh | bash
引数なしで ccswitch を実行するだけで、インタラクティブなTUIが起動します:
ccswitch
# インストール済みツールを一覧表示
ccswitch list
# 特定のツールを設定
ccswitch config claude
# すべてのツールをバックアップ
ccswitch backup
# バックアップから復元
ccswitch restore
# プロファイルを管理
ccswitch profile list
ccswitch profile switch work
# MCPサーバーを管理
ccswitch mcp list
ccswitch mcp add myserver
ccswitch は以下の場所に設定を保存します:
~/.config/ccswitch/config.json%APPDATA%\ccswitch\config.jsonCCSWITCH_CONFIG_DIR: 設定ディレクトリを上書きCCSWITCH_BACKUP_DIR: バックアップディレクトリを上書きCCSWITCH_LOG_LEVEL: ログレベルを設定(debug、info、warn、error)# リポジトリをクローン
git clone https://github.com/yourusername/ccswitch.git
cd ccswitch
# 依存関係をインストール
go mod download
# ビルド
make build
# テストを実行
make test
ccswitch/
├── cmd/ # コマンドラインエントリポイント
├── internal/ # 内部パッケージ
│ ├── config/ # 設定管理
│ ├── tools/ # ツール検出と設定
│ ├── tui/ # ターミナルUI
│ └── backup/ # バックアップと復元
├── pkg/ # 公開パッケージ
└── scripts/ # ビルドとインストールスクリプト
コントリビューションを歓迎します!詳細は CONTRIBUTING.md をご覧ください。
git checkout -b feature/amazing-feature)git commit -m 'Add amazing feature')git push origin feature/amazing-feature)このプロジェクトは MIT ライセンスの下でライセンスされています - 詳細は LICENSE ファイルをご覧ください。
AIコーディングツールを愛する方々によって ❤️ を込めて作られました```bash cd frontend npm install cp env.local.example .env.local # set NEXT_PUBLIC_API_URL=http://localhost:8000 npm run dev
### Docker Compose(両サービス)```bash
cp backend/env.example backend/.env # fill in required values
docker compose up --build
Frontend → http://localhost:3000 Backend API docs → http://localhost:8000/docs
backend/env.example を backend/.env にコピーして値を埋めてください。どのティアで必要になるかによってグループ化しています:
常に必須:
| 変数 | 説明 |
|---|---|
PG_DSN | Postgres 接続文字列 |
JWT_SECRET_KEY | アプリのセッショントークン署名用シークレット (python -c "import secrets; print(secrets.token_hex(32))") |
認証 — いずれか1つのモードを選択:
AI トリアージ — 任意、いずれか1つのプロバイダーを選択 (両方省略するとトリアージ無効で実行):
任意:
フロントエンド (frontend/.env.local または frontend/env.local.example):
| 変数 | 説明 |
|---|---|
NEXT_PUBLIC_API_URL | ブラウザから見たバックエンド URL。ビルド時に JS バンドルへ埋め込まれます。未設定のままにすると、代わりに組み込みの同一オリジンプロキシ () 経由で API 呼び出しがルーティングされます — バックエンドにパブリックなイングレスがない場合 (例: Azure + API ティアの内部専用 Container App) は必須です |
detections.ai オーケストレーター — 近日公開 (まだこの公開リリースには含まれていません。出荷時に備えてここに記載しています。Azure + API ティア、別個のデプロイ対象 — backend/detection_pipeline/orchestrator.py を参照):
Sentinel Hunts 同期 (任意、デフォルト無効 — オン/オフ/手動/自動モードについては Settings > API Settings を参照):
実際の最新の IaC は infra/apps.bicep + infra/platform.bicep + infra/app-stack.bicep で、infra/provision.ps1 (または薄いラッパーである scripts/setup-azure.ps1) 経由でデプロイされます。Container Apps、Key Vault に裏付けられたシークレット、マネージド ID をプロビジョニングします — Postgres 自体はこのリポジトリではプロビジョニングされません。PG_DSN (pg-dsn Key Vault シークレットとして保存) を、到達可能な任意の Postgres サーバーに向けてください。```powershell
./scripts/setup-azure.ps1
cd infra cp migration.psd1.example migration.psd1 # fill in your resource group, apps, etc. ./provision.ps1
`provision.ps1` は冪等です — マニフェストを編集した後に再実行しても安全です。完全なステップバイステップの手順(プラットフォーム → アプリスタック → シークレット → Easy Auth → イメージインポート → アプリ → ポストチェック)については、ファイル先頭のヘッダーコメントを参照してください。
detections.ai オーケストレーター(`migration.psd1` の `Orchestrator` ブロックによって駆動されるスケジュールされた Container Apps Job — その形式については `migration.psd1.example` を参照し、キーは `DETECTIONSAIAPIKEY` Key Vault シークレットとして保存してください)は、まだこの公開リリースには含まれていません — 上記の [Two detections-related features](#two-detections-related-features) を参照してください。
---
## プロジェクト構成```
├── backend/
│ ├── main.py # FastAPI app, all endpoints
│ ├── db.py # Postgres queries
│ ├── pgcompat.py # connection pool + SQLite-style placeholder translation
│ ├── feed_manager.py # RSS polling, AI triage (provider-modular), scheduler
│ ├── enrichment.py # IOC extraction, KEV cache, stack rematch
│ ├── runzero_sync.py # RunZero asset sync and correlation engine
│ ├── dedup.py # CVE deduplication logic
│ ├── auth.py # Entra ID SSO + local API-key auth, app JWT sign/verify
│ ├── ioc_export.py # STIX 2.1 and CSV export
│ ├── stack_presets.py # Pre-built tech stack templates
│ ├── detection_pipeline/ # detections.ai orchestrator, MITRE alignment-check,
│ │ # Sentinel hunts/analytics-rules sync + tuning,
│ │ # audit log, local_import.py (Local Detections Import)
│ └── tests/ # pytest test suite, incl. fixtures/local_import/
├── frontend/
│ ├── pages/
│ │ ├── index.js # Main app shell + tab routing
│ │ └── login.js # Entra ID or local API-key login, auto-detected
│ ├── lib/
│ │ ├── authMode.js # GET /api/auth/mode, cached per page load
│ │ ├── authFetch.js # Bearer auth + 401-retry wrapper
│ │ └── authSession.js # token storage, JWT decode/expiry helpers
│ └── components/
│ ├── layout/ # TopBar, Sidebar, TabBar, TopFilterBar, TimeRangeToggle
│ ├── feed/ # FeedList, FeedCard
│ ├── integrations/ # IntegrationsPanel, ExposurePanel, RunZeroPanel,
│ │ # RunZeroMatchesPanel, RunZeroMetricsPanel
│ ├── detections/ # DetectionsPanel (tab shell) + one component per
│ │ # sub-tab: DetectionsCatalogPanel, AlignmentReviewPanel,
│ │ # DispositionAlertsPanel, HuntsPanel, SentinelHuntsPanel,
│ │ # SentinelAnalyticsRulesPanel, LocalDetectionsPanel,
│ │ # AuditPanel, plus shared TuningSuggestionBadge
│ ├── settings/ # SettingsPanel, CadencePicker, SeverityCards
│ └── mitre/ # MitreMatrix
├── infra/ # Azure Bicep templates + provision.ps1
├── scripts/ # Tiered setup scripts (see Deployment tiers)
└── docker-compose.yml
3つのティアにまたがる63のフィード:
Authorization: Bearer <token> を要求secrets.compare_digest)を使用.env / Azure Key Vault から読み込まれるMIT — LICENSE を参照。
| ティア | スクリプト | AIトリアージ | 認証 | ストレージ | 得られるもの |
|---|
| Basic | scripts/setup-basic.sh | オフ | ローカルAPIキー | ローカルPostgres (Docker) | フィード集約、IOC抽出、MITREマトリックス、ダッシュボード — AIなし、クラウドなし、サインアップ不要 |
| Basic + API | scripts/setup-basic-api.sh | Anthropic (直接) | ローカルAPIキー | ローカルPostgres (Docker) | 上記すべてに加え、AIによる重大度/TTP/サマリーのトリアージ |
| Azure + API | scripts/setup-azure.ps1 | Azure AI Foundry | Microsoft Entra ID SSO | 独自のPostgres (Azure DB for PostgreSQLなど) | Azure Container Appsへの完全デプロイ、ユーザーごとのロールを持つSSO。(detections.aiパイプライン統合は今後のリリースで提供予定 — 以下を参照。) |
| ツール | 設定パス | ステータス |
|---|
| Claude Code | ~/.claude/ | ✅ 完全対応 |
| Cursor | ~/.cursor/ | ✅ 完全対応 |
| Windsurf | ~/.windsurf/ | ✅ 完全対応 |
| Aider | ~/.aider/ | ✅ 完全対応 |
| Codex | ~/.codex/ | ✅ 完全対応 |
| Gemini CLI | ~/.gemini/ | ✅ 完全対応 |
| Qwen Code | ~/.qwen/ | ✅ 完全対応 |
| Opencode | ~/.opencode/ | ✅ 完全対応 |
| Continue | ~/.continue/ | ✅ 完全対応 |
| Amazon Q | ~/.aws/q/ | ✅ 完全対応 |
| 変数 | 説明 |
|---|
LOCAL_API_KEY | ローカルモード: 管理者アクセスを付与する共有キー。AZURE_AD_TENANT_ID を未設定のままにするとこのモードが有効になります |
AZURE_AD_TENANT_ID | Entra モード: SSO 用のテナント ID。これを設定すると Entra モードが有効になります |
AZURE_AD_CLIENT_ID | Entra モード: アプリ登録のクライアント ID |
AZURE_AD_CLIENT_SECRET | Entra モード: アプリ登録のシークレット (フロントエンドのみ) |
NEXTAUTH_SECRET | Entra モード: NextAuth セッション暗号化シークレット (フロントエンドのみ) |
| 変数 | 説明 |
|---|
AI_PROVIDER | anthropic (デフォルト) または azure |
ANTHROPIC_API_KEY | Anthropic API キーを直接指定 |
AZURE_FOUNDRY_ENDPOINT | Azure AI Foundry エンドポイント、例: https://<resource>.services.ai.azure.com/anthropic |
AZURE_FOUNDRY_API_KEY | Azure AI Foundry API キー |
AZURE_FOUNDRY_DEPLOYMENT | Foundry デプロイメント名 (デフォルト claude-haiku-4-5) |
AZURE_FOUNDRY_API_VERSION | Foundry API バージョン (デフォルト 2025-05-01) |
| 変数 | 説明 |
|---|
RUNZERO_API_TOKEN | RunZero のアセット同期と相関を有効化 |
ALLOWED_ORIGINS | カンマ区切りの CORS 許可リスト (デフォルト http://localhost:3000) |
ENABLE_SCHEDULER | false に設定するとバックグラウンドのフィードポーラーを無効化 (デフォルト true) |
ARCHIVE_AFTER_DAYS | 自動アーカイブのしきい値 (日数、デフォルト 90) |
PG_POOL_MIN / PG_POOL_MAX / PG_POOL_TIMEOUT | Postgres 接続プールのチューニング (デフォルト 1 / 10 / 30) |
LOCAL_IMPORT_DIR | ローカル検知のインポート を有効化 — すべてのインポートがこのパス内に制限される、バックエンドのファイルシステム上の絶対パス。未設定にするとこの機能は完全に無効化されます (タブに「未設定」メッセージが表示されます) |
frontend/pages/api/[...proxy].jsBACKEND_URL | Next.js サーバー自身から見たバックエンド URL。NextAuth のログイン交換で使用され、NEXT_PUBLIC_API_URL が未設定の場合は、すべての /api/* ブラウザリクエストをサーバーサイドで転送する同一オリジンプロキシでも使用されます |
| 変数 | 説明 |
|---|
DETECTIONS_AI_API_KEY | オーケストレーターを実行するために必須 |
SENTINEL_WORKSPACE_ID | バックテスト用の Log Analytics ワークスペースのカスタマー ID (GUID)。任意 |
PIPELINE_BATCH_SIZE | 1回の実行あたりのエントリ数 (デフォルト 5) |
PIPELINE_DRY_RUN | true にすると API を呼び出さずにクレームとログのみ実行 |
PIPELINE_LANGUAGE | 検知クエリ言語 (デフォルト kql) |
| 変数 | 説明 |
|---|
SENTINEL_HUNTING_SYNC_ENABLED | true にするとハント同期の試行を一切許可します。未設定/false は完全な no-op — ARM 呼び出しはゼロ |
AZURE_SUBSCRIPTION_ID | Sentinel ワークスペースを含むサブスクリプション |
AZURE_RESOURCE_GROUP | Sentinel ワークスペースを含むリソースグループ |
SENTINEL_WORKSPACE_NAME | ワークスペースの 名前 であり、カスタマー ID ではありません — 上記の SENTINEL_WORKSPACE_ID とは異なる値で、こちらはバックテストのデータプレーンクライアントが代わりに使用します |