# セキュリティモデル
AIエージェントに対してゼロトラスト、ポリシー駆動型保護を確保する包括的なセキュリティアーキテクチャ。
## 目次
---
## 概要
Symbiontは、規制された高保証環境向けに設計されたセキュリティファーストアーキテクチャを実装しています。セキュリティモデルは、包括的なポリシー実行、マルチティアサンドボックス、暗号学的監査可能性を備えたゼロトラスト原則に基づいて構築されています。
### セキュリティ原則
- **ゼロトラスト**: すべてのコンポーネントと通信が検証される
- **多層防御**: 単一障害点のない複数のセキュリティ層
- **ポリシー駆動型**: 実行時に適用される宣言的セキュリティポリシー
- **完全監査可能性**: 暗号学的整合性を持つすべての操作ログ
- **最小権限**: 操作に必要な最小限の権限
---
## マルチティアサンドボックス
ランタイムは、3つのホスト分離ティア（Tier 1 → Tier 3）と、1つのホスト型実行バックエンド（E2B）を提供します。これらのティアは単調増加する分離のはしごを形成しており、E2B はそのはしご上の **対等な存在ではありません** — E2B はサードパーティのインフラ上で実行され、後述で別途説明します。
```mermaid
graph TB
A[Risk Assessment Engine] --> B{Risk Level}
B -->|Low Risk| C[Tier 1: Docker]
B -->|Medium Risk| D[Tier 2: gVisor]
B -->|High Risk| E[Tier 3: Firecracker]
A -.->|Opt-in via DSL| H[Hosted: E2B]
subgraph "Tier 1: Container Isolation"
C1[Container Runtime]
C2[Resource Limits]
C3[Network Isolation]
C4[Read-only Filesystem]
end
subgraph "Tier 2: User-space Kernel"
D1[System Call Interception]
D2[Memory Protection]
D3[I/O Virtualization]
D4[Enhanced Isolation]
end
subgraph "Tier 3: microVM"
E1[KVM Hardware Virtualization]
E2[Dedicated Kernel]
E3[Read-only Rootfs]
E4[Per-execution Lifecycle]
end
subgraph "Hosted: third-party cloud"
H1[No on-host isolation]
H2[Trust assumption: provider]
H3[Quick-start, no setup]
end
C --> C1
D --> D1
E --> E1
H --> H1
```
> **3つのホスト分離ティア — Docker、gVisor、Firecracker — はすべて OSS ランタイムに同梱されています。** 運用者は DSL の `with { sandbox = ... }` ブロックでエージェントごとにティアを選択するか、`symbiont.toml` の `[sandbox] tier = "..."` でプロジェクト全体のデフォルトを設定します。E2B は DSL 経由（`with { sandbox = "e2b" }`）でのみオプトインで利用可能であり、`[sandbox] tier` の値としては意図的に公開していません。
### ティア1：Docker分離
**使用例：**
- 信頼できる開発タスク
- 低感度データ処理
- 内部ツール操作
**セキュリティ機能：**
```yaml
docker_security:
memory_limit: "512MB"
cpu_limit: "0.5"
network_mode: "none"
read_only_root: true
security_opts:
- "no-new-privileges:true"
- "seccomp:default"
capabilities:
drop: ["ALL"]
add: ["SETUID", "SETGID"]
```
**脅威保護：**
- ホストからのプロセス分離
- リソース枯渇防止
- ネットワークアクセス制御
- ファイルシステム保護
### ティア2：gVisor分離
**使用例：**
- 標準本番ワークロード
- 機密データ処理
- 外部ツール統合
**セキュリティ機能：**
- ユーザー空間カーネル実装
- システムコールフィルタリングと変換
- メモリ保護境界
- I/Oリクエスト検証
**設定：**
```yaml
gvisor_security:
runtime: "runsc"
platform: "ptrace"
network: "sandbox"
file_access: "exclusive"
debug: false
strace: false
```
**高度な保護：**
- カーネル脆弱性分離
- システムコール傍受
- メモリ破損防止
- サイドチャネル攻撃緩和
**前提条件：** [`runsc`](https://gvisor.dev/docs/user_guide/install/) をインストールし、`/etc/docker/daemon.json` で Docker ランタイムとして登録します。`symbi doctor` は `runsc` が到達可能かを報告します。
### ティア3：Firecracker microVM
**使用例：**
- 最高レベルの分離が必要なワークロード（信頼されないコード、マルチテナント、規制対象データ）
- syscall フィルタの粒度（gVisor）では不十分で、実際のカーネル境界が必要な場合
- ブラスト半径をより強力に封じ込める実行ごとの VM ライフサイクル
**セキュリティ機能：**
- KVM によるハードウェア仮想化
- 運用者が提供するカーネル + rootfs を用いた実行ごとの microVM
- デフォルトで読み取り専用のルートファイルシステム
- ホストとカーネル表面を共有しない
**設定：** `symbiont.toml` の `[sandbox.firecracker]`：
```toml
[sandbox]
tier = "tier3"
[sandbox.firecracker]
kernel_image_path = "/var/lib/firecracker/vmlinux"
rootfs_path = "/var/lib/firecracker/rootfs.ext4"
vcpus = 1
mem_mib = 512
rootfs_read_only = true
```
**前提条件：** 運用者は (a) Firecracker 互換のカーネルイメージと (b) エージェントペイロードを読み取る init スクリプトを持つルートファイルシステムイメージの両方を用意する必要があります。**ステップバイステップのクイックスタート、VM 内 init コントラクト、ハードニングチェックリストについては [`docs/firecracker-setup.md`](firecracker-setup.md) を参照してください。** `symbi doctor` は `firecracker` バイナリが到達可能かを報告します。
両方の成果物が揃ったら、次のコマンドで tier3 プロジェクトをスキャフォールドできます：
```bash
symbi init --profile assistant --sandbox tier3 \
--firecracker-kernel /var/lib/firecracker/vmlinux \
--firecracker-rootfs /var/lib/firecracker/rootfs.ext4
```
`symbi init` は `symbiont.toml` を書き出す前に両方のファイルが存在することを検証するため、設定ミスは最初のエージェント実行時ではなくスキャフォールド時に表面化します。
### ホスト型実行：E2B
**E2B はホスト型のクラウドサンドボックスバックエンドであり、ホスト分離ティアではありません。** Tier 1 → Tier 3 のはしごの外側に位置し、完全性を保つため本ドキュメントで併記します。
**何をするか：** コードは E2B のインフラ上で HTTPS API 経由で実行され、ランタイム側が同梱しているのは HTTP クライアントのみです。`E2B_API_KEY` を設定し、エージェントごとに `with { sandbox = "e2b" }` で選択します。`symbi init` には `--sandbox e2b` フラグはありません — E2B はオンホストのティアとは異なる信頼モデルを表すため、意図的に DSL 経由でのみオプトインできるようにしています。
**使用例：**
- Docker、gVisor、Firecracker をインストールせずに行うクイックスタートデモや評価。
- 運用者がサンドボックスホストを実行できない開発環境（特権モードのない CI、ロックダウンされたラップトップ、ARM 開発マシンなど）。
**してはいけないこと：**
- オンホスト分離の代替ではありません。コード、プロンプト、ツール出力は E2B のインフラを経由します。プライバシー、データ所在地、コンプライアンス要件のあるワークロードには使用しないでください。
- セキュリティレビューの観点で Tier 1/2/3 と比較できるものではありません。ランタイムは `E2B → SecurityTier::Hosted` にマップし、これは順序付け上 `Tier1` よりも **下** にソートされます — ホスト分離（`tier >= Tier1`）を要求するポリシーはホスト型実行を拒否します。
**設定：** プロジェクトレベルの設定はありません。環境変数 `E2B_API_KEY` を設定し、エージェントごとに `with { sandbox = "e2b" }` を使用します。
---
## ポリシーエンジン
### ポリシーアーキテクチャ
ポリシーエンジンは、実行時適用による宣言的セキュリティ制御を提供します：
```mermaid
graph TB
A[Policy Definition] --> B[Policy Parser]
B --> C[Policy Store]
C --> D[Policy Engine]
D --> E[Enforcement Points]
E --> F[Agent Creation]
E --> G[Resource Access]
E --> H[Message Routing]
E --> I[Tool Invocation]
E --> J[Data Operations]
E --> CPG[Inter-Agent Policy]
K[Audit Logger] --> L[Policy Violations]
E --> K
```
### ポリシータイプ
#### アクセス制御ポリシー
どの条件下で誰がどのリソースにアクセスできるかを定義します：
```rust
policy secure_data_access {
allow: read(sensitive_data) if (
user.clearance >= "secret" &&
user.need_to_know.contains(data.classification) &&
session.mfa_verified == true
)
deny: export(data) if data.contains_pii == true
require: [
user.background_check.current,
session.secure_connection,
audit_trail = "detailed"
]
}
```
#### データフローポリシー
システム内でのデータの移動方法を制御します：
```rust
policy data_flow_control {
allow: transform(data) if (
source.classification <= target.classification &&
user.transform_permissions.contains(operation.type)
)
deny: aggregate(datasets) if (
any(datasets, |d| d.privacy_level > operation.privacy_budget)
)
require: differential_privacy for statistical_operations
}
```
#### リソース使用ポリシー
計算リソース割り当てを管理します：
```rust
policy resource_governance {
allow: allocate(resources) if (
user.resource_quota.remaining >= resources.total &&
operation.priority <= user.max_priority
)
deny: long_running_operations if system.maintenance_mode
require: supervisor_approval for high_memory_operations
}
```
### ポリシー評価エンジン
```rust
pub trait PolicyEngine {
async fn evaluate_policy(
&self,
context: PolicyContext,
action: Action
) -> PolicyDecision;
async fn register_policy(&self, policy: Policy) -> Result<PolicyId>;
async fn update_policy(&self, policy_id: PolicyId, policy: Policy) -> Result<()>;
}
pub enum PolicyDecision {
Allow,
Deny { reason: String },
AllowWithConditions { conditions: Vec<PolicyCondition> },
RequireApproval { approver: String },
}
```
### パフォーマンス最適化
**ポリシーキャッシュ：**
- パフォーマンスのためのコンパイル済みポリシー評価
- 頻繁な決定のためのLRUキャッシュ
- 一括操作のためのバッチ評価
- サブミリ秒評価時間
**増分更新：**
- 再起動なしのリアルタイムポリシー更新
- バージョン管理されたポリシーデプロイメント
- ポリシーエラーのロールバック機能
### Cedarポリシーエンジン（`cedar` feature）
Symbiontは正式認可のために[Cedarポリシー言語](https://www.cedarpolicy.com/)を統合しています。Cedarは、推論ループのポリシーゲートで評価される、きめ細かで監査可能なアクセス制御ポリシーを可能にします。
**v1.14.x 以降デフォルトで有効：** Cedar は `symbi-runtime` のデフォルトフィーチャーセットに含まれており、公開されているすべてのバイナリ（crates.io、Docker、GitHub Release tarball）に同梱されています。`symbi up` および `symbi run` は起動時に `policies/*.cedar` ファイルから `CedarPolicyGate` を自動配線します。少なくとも 1 つのポリシーファイルが存在する場合、ゲートは `deny_by_default()` で構築され、各 `.cedar` ファイルが名前付きポリシーとしてロードされます。ポリシーファイルが存在しない場合、ランタイムはフェイルクローズドな `DefaultPolicyGate::new()` にフォールバックします（これはすべての `ToolCall` および `Delegate` アクションを拒否します）。Cedar を完全に無効化するには — `OpaPolicyGateBridge` やカスタム `ReasoningPolicyGate` をピン留めするビルドのために — `cargo build --no-default-features --features "keychain,vector-lancedb"` でビルドします。
```bash
cargo build --features cedar
```
**主要な機能：**
- **正式検証**: Cedarポリシーは正確性について静的に分析可能
- **きめ細かな認可**: 階層的権限を持つエンティティベースのアクセス制御
- **推論ループ統合**: `CedarPolicyGate` は `ReasoningPolicyGate` トレイトを実装し、実行前にCedarポリシーに対して各提案アクションを評価
- **監査証跡**: すべてのCedarポリシー決定が完全なコンテキストとともにログに記録
```rust
use symbi_runtime::reasoning::cedar_gate::CedarPolicyGate;
// デフォルト拒否のスタンスでCedarポリシーゲートを作成
let cedar_gate = CedarPolicyGate::deny_by_default();
let runner = ReasoningLoopRunner::builder()
.provider(provider)
.executor(executor)
.policy_gate(Arc::new(cedar_gate))
.build();
```
### 推論ループポリシーゲートのデフォルト（v1.13.0 監査後）
`symbi up` および `symbi run` の推論ループはデフォルトで**フェイルクローズ**です。`DefaultPolicyGate::new()` はすべての `ToolCall` および `Delegate` アクションに対して `LoopDecision::Deny` を返し、その理由は `"No policy gate configured (DefaultPolicyGate::new is fail-closed; wire OpaPolicyGateBridge or pass --insecure-allow-all)"` です。`Respond` アクションは引き続き許可されるため、エージェントはテキスト出力を生成できます。
この変更により、本番バイナリが以前は `DefaultPolicyGate::permissive()` をハードコードしてすべてのアクションを暗黙的に許可していたギャップが塞がれます — 監査の経緯は `SECURITY_AUDIT.md` C2 を参照してください。
オペレーターには 2 つの選択肢があります：
1. **実際のポリシーバックエンドを配線する**（推奨）: `CedarPolicyGate`、`OpaPolicyGateBridge`、または `ReasoningPolicyGate` トレイトの独自実装を構築し、ランナーに渡します。
2. **ローカル開発向けに許可モードをオプトインする**: `symbi up` / `symbi run` に `--insecure-allow-all` を渡すか、`SYMBI_INSECURE_ALLOW_ALL=1` を設定します。このモードでランタイムが起動するたびに複数行の stderr バナーが表示され、評価される各アクションで `tracing::warn!` が発火します。
レガシーの `permissive()` コンストラクタは `permissive_for_dev_only()` に名前変更され、本番コードパスでの偶発的な使用を抑制するために `#[doc(hidden)]` がマークされました。
### エージェント間通信ポリシー
`CommunicationPolicyGate` はすべてのエージェント間通信に対する認可ルールを実行します。`ask`、`delegate`、`send_to`、`parallel`、`race` を通じたすべての呼び出しは、実行前にポリシールールに対して評価されます。
**ルール構造：**
- **条件**: `SenderIs(agent)`、`RecipientIs(agent)`、`Always`、複合 `All`/`Any`
- **効果**: `Allow` または `Deny { reason }`
- **優先度**: ルールは優先度の高い順に評価され、最初にマッチしたものが適用
- **デフォルト**: Allow（後方互換性 -- 既存のプロジェクトはそのまま動作）
**ポリシー拒否はハードフェイル** -- 呼び出し元のエージェントはORGAループを通じてエラーを受け取り、それについて推論できます。すべてのエージェント間メッセージはEd25519で暗号署名され、AES-256-GCMで暗号化されます。
ワーカーエージェントが他のエージェントに委任することを禁止するポリシーの例：
```cedar
forbid(
principal == Agent::"worker",
action == Action::"delegate",
resource
);
```
---
## 暗号学的セキュリティ
### デジタル署名
すべてのセキュリティ関連操作は暗号学的に署名されます：
**署名アルゴリズム：** Ed25519（RFC 8032）
- **キーサイズ：** 256ビット秘密鍵、256ビット公開鍵
- **署名サイズ：** 512ビット（64バイト）
- **パフォーマンス：** 70,000+ 署名/秒、25,000+ 検証/秒
```rust
pub struct MessageSignature {
pub signature: Vec<u8>,
pub algorithm: SignatureAlgorithm,
pub public_key: Vec<u8>,
}
impl AuditEvent {
pub fn sign(&mut self, private_key: &PrivateKey) -> Result<()> {
let message = self.serialize_for_signing()?;
self.signature = private_key.sign(&message);
Ok(())
}
pub fn verify(&self, public_key: &PublicKey) -> bool {
let message = self.serialize_for_signing().unwrap();
public_key.verify(&message, &self.signature)
}
}
```
### キー管理
**キー保存：**
- ハードウェアセキュリティモジュール（HSM）統合
- キー保護のためのセキュアエンクレーブサポート
- 設定可能な間隔でのキーローテーション
- 分散キーバックアップと復旧
**キー階層：**
- システム操作のためのルート署名キー
- 操作署名のためのエージェント別キー
- セッション暗号化のための一時キー
- ツール検証のための外部キー
> **計画中の機能** — 以下の `KeyManager` APIはセキュリティロードマップの一部であり、現在のリリースではまだ利用できません。現在の実装は `crypto.rs` の `KeyUtils` を通じてキーユーティリティを提供しています。
```rust
pub struct KeyManager {
hsm: HardwareSecurityModule,
key_store: SecureKeyStore,
rotation_policy: KeyRotationPolicy,
}
impl KeyManager {
pub async fn generate_agent_keys(&self, agent_id: AgentId) -> Result<KeyPair>;
pub async fn rotate_keys(&self, key_id: KeyId) -> Result<KeyPair>;
pub async fn revoke_key(&self, key_id: KeyId) -> Result<()>;
}
```
### 暗号化標準
**対称暗号化：** AES-256-GCM
- 認証付き暗号化を持つ256ビットキー
- 各暗号化操作のユニークナンス
- コンテキストバインディングのための関連データ
**非対称暗号化：** X25519 + ChaCha20-Poly1305
- 楕円曲線キー交換
- 認証付き暗号化を持つストリーム暗号
- 完全前方秘匿性
**メッセージ暗号化：**
```rust
pub fn encrypt_message(
plaintext: &[u8],
recipient_public_key: &PublicKey,
sender_private_key: &PrivateKey
) -> Result<EncryptedMessage> {
let shared_secret = sender_private_key.diffie_hellman(recipient_public_key);
let nonce = generate_random_nonce();
let ciphertext = ChaCha20Poly1305::new(&shared_secret)
.encrypt(&nonce, plaintext)?;
Ok(EncryptedMessage {
nonce,
ciphertext,
sender_public_key: sender_private_key.public_key(),
})
}
```
---
## 監査とコンプライアンス
### 暗号学的監査証跡
すべてのセキュリティ関連操作は不変の監査イベントを生成します：
```rust
pub struct AuditEvent {
pub event_id: Uuid,
pub timestamp: SystemTime,
pub agent_id: AgentId,
pub event_type: AuditEventType,
pub details: serde_json::Value,
pub signature: Ed25519Signature,
pub previous_hash: Hash,
pub event_hash: Hash,
}
```
**監査イベントタイプ：**
- エージェントライフサイクルイベント（作成、終了）
- ポリシー評価決定
- リソース割り当てと使用
- メッセージ送信とルーティング
- 外部ツール呼び出し
- セキュリティ違反とアラート
### ハッシュチェーン
イベントは不変チェーンでリンクされます：
```rust
impl AuditChain {
pub fn append_event(&mut self, mut event: AuditEvent) -> Result<()> {
event.previous_hash = self.last_hash;
event.event_hash = self.calculate_event_hash(&event);
event.sign(&self.signing_key)?;
self.events.push(event.clone());
self.last_hash = event.event_hash;
self.verify_chain_integrity()?;
Ok(())
}
pub fn verify_integrity(&self) -> Result<bool> {
for (i, event) in self.events.iter().enumerate() {
// Verify signature
if !event.verify(&self.public_key) {
return Ok(false);
}
// Verify hash chain
if i > 0 && event.previous_hash != self.events[i-1].event_hash {
return Ok(false);
}
}
Ok(true)
}
}
```
### コンプライアンス機能
**規制サポート：**
**HIPAA（ヘルスケア）：**
- ユーザー識別を含むPHIアクセスログ
- データ最小化適用
- 侵害検出と通知
- 6年間の監査証跡保持
**GDPR（プライバシー）：**
- 個人データ処理ログ
- 同意検証追跡
- データ主体権利適用
- データ保持ポリシーコンプライアンス
**SOX（金融）：**
- 内部統制文書化
- 変更管理追跡
- アクセス制御検証
- 金融データ保護
**カスタムコンプライアンス：**
> **計画中の機能** — 以下の `ComplianceFramework` APIはセキュリティロードマップの一部であり、現在のリリースではまだ利用できません。
```rust
pub struct ComplianceFramework {
pub name: String,
pub audit_requirements: Vec<AuditRequirement>,
pub retention_policy: RetentionPolicy,
pub access_controls: Vec<AccessControl>,
pub data_protection: DataProtectionRules,
}
impl ComplianceFramework {
pub fn validate_compliance(&self, audit_trail: &AuditChain) -> ComplianceReport;
pub fn generate_compliance_report(&self, period: TimePeriod) -> Report;
}
```
---
## 人間承認リレー（`symbi-approval-relay`）
ポリシー決定が `require: approval` を返した場合、アクションは人間のレビュアーが承認または拒否するまでブロックされます。`symbi-approval-relay` は、そうしたリクエストを人間に届け、その決定を返送するクレートであり、両方のホップを監査可能な状態に保ちます。
### デュアルチャネル設計
リレーは設計上**デュアルチャネル**です。すべての承認は2つの独立したパスを経由して往復し、ランタイムがアクションをアンブロックするには両方が一致する必要があります。
- **プライマリチャネル** -- レビュアー向けのインタラクティブな窓口（チャットアダプタ、Web UI、CLIプロンプト）。レビュアーがここでリクエストを読み、判断します。
- **アテステーションチャネル** -- 独立した検証パス（例：署名付きコールバック、第二オペレーター、帯域外確認）。ランタイムはプライマリチャネルの承認だけではアンブロックしません。
この構造は、単一チャネル侵害のケースを無効化します。プライマリチャネルを掌握した攻撃者も、アテステーションチャネルはその信頼を共有しないため、承認を付与することはできません。
### リレーが運ぶもの
進行中の各承認リクエストは以下を保持します：
- エージェントのアイデンティティ（AgentPinアンカー）とリクエストを引き起こしたポリシー決定
- 完全なアクションコンテキスト -- ツール呼び出し、リソース、引数 -- をハッシュ化し、レビュアーがすり替えられたアクションではなく*この*アクションを承認したことを確認できるようにする
- 自動拒否となるデッドライン
- 2つのチャネルの決定を単一のアクションに結び付けるための相関ID
承認と拒否は、他のすべてのランタイム決定と同じ暗号学的に改ざん検出可能な監査チェーンに記録されます。人間が「はい」と言うことはログ内の決定であり、ログの迂回ではありません。
### 利用場所
- `RequireApproval { approver: "..." }` 判定を発行するCedarポリシー
- ToolClad `approval` フックでゲートされる破壊的または高権限のツール呼び出し
- `one_shot = true` と承認ポリシーを組み合わせて設定されたスケジュールジョブ
- `require: <role>_approval` を指定するあらゆるDSLの `policy` ブロック
リレーが設定されていない場合、承認ゲートされたアクションはフェイルクローズします -- 黙って許可されるのではなく拒否されます。
---
## SchemaPinによるツールセキュリティ
### ツール検証プロセス
外部ツールは暗号署名を使用して検証されます：
```mermaid
sequenceDiagram
participant Tool as Tool Provider
participant SP as SchemaPin
participant AI as AI Reviewer
participant Runtime as Symbiont Runtime
participant Agent as Agent
Tool->>SP: Submit Tool Schema
SP->>AI: Security Analysis
AI-->>SP: Analysis Results
SP->>SP: Human Review (if needed)
SP->>SP: Sign Schema
SP-->>Tool: Signed Schema
Agent->>Runtime: Request Tool Use
Runtime->>SP: Verify Tool Schema
SP-->>Runtime: Verification Result
Runtime-->>Agent: Allow/Deny Tool Use
```
### 初回使用時信頼（TOFU）
**キーピニングプロセス：**
1. ツールプロバイダーとの初回接触
2. 外部チャネルを通じてプロバイダーの公開鍵を検証
3. ローカル信頼ストアに公開鍵をピン留め
4. 将来のすべての検証にピン留めされたキーを使用
> **計画中の機能** — 以下の `TOFUKeyStore` APIはセキュリティロードマップの一部であり、現在のリリースではまだ利用できません。
```rust
pub struct TOFUKeyStore {
pinned_keys: HashMap<ProviderId, PinnedKey>,
trust_policies: Vec<TrustPolicy>,
}
impl TOFUKeyStore {
pub async fn pin_key(&mut self, provider: ProviderId, key: PublicKey) -> Result<()> {
if self.pinned_keys.contains_key(&provider) {
return Err("Key already pinned for provider");
}
self.pinned_keys.insert(provider, PinnedKey {
public_key: key,
pinned_at: SystemTime::now(),
trust_level: TrustLevel::Unverified,
});
Ok(())
}
pub fn verify_tool(&self, tool: &MCPTool) -> VerificationResult {
if let Some(pinned_key) = self.pinned_keys.get(&tool.provider_id) {
if pinned_key.public_key.verify(&tool.schema_hash, &tool.signature) {
VerificationResult::Trusted
} else {
VerificationResult::SignatureInvalid
}
} else {
VerificationResult::UnknownProvider
}
}
}
```
### AI駆動ツールレビュー
ツール承認前の自動セキュリティ分析：
**分析コンポーネント：**
- **脆弱性検出**: 既知の脆弱性シグネチャに対するパターンマッチング
- **悪意のあるコード検出**: MLベースの悪意のある動作識別
- **リソース使用分析**: 計算リソース要件の評価
- **プライバシー影響評価**: データ処理とプライバシーへの影響
> **計画中の機能** — 以下の `SecurityAnalyzer` APIはセキュリティロードマップの一部であり、現在のリリースではまだ利用できません。
```rust
pub struct SecurityAnalyzer {
vulnerability_patterns: VulnerabilityDatabase,
ml_detector: MaliciousCodeDetector,
resource_analyzer: ResourceAnalyzer,
privacy_assessor: PrivacyAssessor,
}
impl SecurityAnalyzer {
pub async fn analyze_tool(&self, tool: &MCPTool) -> SecurityAnalysis {
let mut findings = Vec::new();
// Vulnerability pattern matching
findings.extend(self.vulnerability_patterns.scan(&tool.schema));
// ML-based detection
let ml_result = self.ml_detector.analyze(&tool.schema).await?;
findings.extend(ml_result.findings);
// Resource usage analysis
let resource_risk = self.resource_analyzer.assess(&tool.schema);
// Privacy impact assessment
let privacy_impact = self.privacy_assessor.evaluate(&tool.schema);
SecurityAnalysis {
tool_id: tool.id.clone(),
risk_score: calculate_risk_score(&findings),
findings,
resource_requirements: resource_risk,
privacy_impact,
recommendation: self.generate_recommendation(&findings),
}
}
}
```
---
## ClawHavocスキルスキャナー
ClawHavocスキャナーはエージェントスキルのコンテンツレベル防御を提供します。すべてのスキルファイルはロード前に行単位でスキャンされ、CriticalまたはHigh重大度の検出結果はスキルの実行をブロックします。
### 重大度モデル
| レベル | アクション | 説明 |
|--------|----------|------|
| **Critical** | スキャン失敗 | アクティブな悪用パターン（リバースシェル、コードインジェクション） |
| **High** | スキャン失敗 | 認証情報窃取、権限昇格、プロセスインジェクション |
| **Medium** | 警告 | 疑わしいが潜在的に正当（ダウンローダー、シンボリックリンク） |
| **Warning** | 警告 | 低リスク指標（envファイル参照、chmod） |
| **Info** | ログ | 情報的な検出結果 |
### 検出カテゴリ（40ルール）
**オリジナル防御ルール（10）**
- `pipe-to-shell`、`wget-pipe-to-shell` -- パイプされたダウンロードによるリモートコード実行
- `eval-with-fetch`、`fetch-with-eval` -- eval + ネットワークによるコードインジェクション
- `base64-decode-exec` -- base64デコードによる難読化実行
- `soul-md-modification`、`memory-md-modification` -- アイデンティティ改ざん
- `rm-rf-pattern` -- 破壊的ファイルシステム操作
- `env-file-reference`、`chmod-777` -- 機密ファイルアクセス、ワールドライタブル権限
**リバースシェル（7）** -- Critical重大度
- `reverse-shell-bash`、`reverse-shell-nc`、`reverse-shell-ncat`、`reverse-shell-mkfifo`、`reverse-shell-python`、`reverse-shell-perl`、`reverse-shell-ruby`
**認証情報ハーベスティング（6）** -- High重大度
- `credential-ssh-keys`、`credential-aws`、`credential-cloud-config`、`credential-browser-cookies`、`credential-keychain`、`credential-etc-shadow`
**ネットワーク窃取（3）** -- High重大度
- `exfil-dns-tunnel`、`exfil-dev-tcp`、`exfil-nc-outbound`
**プロセスインジェクション（4）** -- Critical重大度
- `injection-ptrace`、`injection-ld-preload`、`injection-proc-mem`、`injection-gdb-attach`
**権限昇格（5）** -- High重大度
- `privesc-sudo`、`privesc-setuid`、`privesc-setcap`、`privesc-chown-root`、`privesc-nsenter`
**シンボリックリンク / パストラバーサル（2）** -- Medium重大度
- `symlink-escape`、`path-traversal-deep`
**ダウンローダーチェーン（3）** -- Medium重大度
- `downloader-curl-save`、`downloader-wget-save`、`downloader-chmod-exec`
### 実行可能ファイルホワイトリスト
`AllowedExecutablesOnly` ルールタイプは、エージェントスキルが呼び出せる実行可能ファイルを制限します：
```rust
// これらの実行可能ファイルのみ許可 -- それ以外はすべてブロック
ScanRule::AllowedExecutablesOnly(vec![
"python3".into(),
"node".into(),
"cargo".into(),
])
```
### カスタムルール
ドメイン固有のパターンをClawHavocデフォルトと並行して追加できます：
```rust
let mut scanner = SkillScanner::new();
scanner.add_custom_rule(
"block-internal-api",
r"internal\.corp\.example\.com",
ScanSeverity::High,
"References to internal API endpoints are not allowed in skills",
);
```
---
## 不可視文字サニタイゼーション (`symbi-invis-strip`)
`symbi-invis-strip` は、ランタイム全体で使用されるゼロ依存のユーティリティクレートで、何もレンダリングされないが意味を変える文字 — プロンプトインジェクションやポリシー回避攻撃の典型的なペイロード — を除去します。
### 削除対象
- ASCII C0（0x00–0x1F）および DEL（0x7F）。ただし `\t` `\n` `\r` を除く
- ASCII C1（0x80–0x9F）
- ゼロ幅文字（ZWSP、ZWNJ、ZWJ）
- 双方向オーバーライド（LRO、RLO、PDF、LRE、RLE、LRI、RLI、FSI、PDI）
- ワードジョイナーおよび不可視演算子ブロック
- バイトオーダーマーク（BOM）
- 異体字セレクター（VS1–VS16 および補助的な VS17–VS256）
- Unicode Tag ブロック内の文字（U+E0000–U+E007F）
### 実行場所
- 受信チャットおよび webhook ペイロード — オーケストレーターに到達する前
- ツール呼び出し引数 — Cedar 評価に到達する前
- スキルおよびエージェント DSL コンテンツ — スキャナーおよびパーサーに到達する前
### オプションのマークアップ除去
オプトインの `sanitize_field_with_markup` バリアントはさらに以下を除去します：
- `<!-- ... -->` HTML コメント
- トリプルバッククォートのフェンス付きコードブロック
マークアップ除去は、レンダラーによって隠されたマークアップに正当な用途がないサーフェス — 例えば、短いポリシー根拠フィールドや表示専用メタデータ — に適しています。マークダウンやコードを正当に含むフィールド（エージェントソース、ポリシー本体、ツール出力など）には適用されません。
---
## Cedar ポリシーリンター
`scripts/lint-cedar-policies.py` は、リポジトリ内のすべての `.cedar` ファイルに対して実行される静的解析パスです。これは、悪意のある（または侵害された）オーサリングフローが、正しく *見える* が、レビューアが期待するものとは異なる認可決定を生成する文字を含むポリシーを書き込む、というクラスの攻撃を捕捉します。
### 検出対象
- **ホモグリフ識別子** — キリル文字 `а`（U+0430）がラテン文字 `a` として、ギリシャ文字 `ο`（U+03BF）がラテン文字 `o` として、および principal/action/resource 名における同様のそっくりさん文字。
- 識別子、文字列リテラル、またはトークン間の **不可視制御文字**。
### 実行場所
- **プリコミットフック** — どちらかのクラスの問題を導入するコミットをブロックします。
- **CI** — 同じチェックが必須のテストジョブとして実行されるため、（`--no-verify` 経由で）フックを回避したコミットも CI で失敗します。
データパス上の `symbi-invis-strip` と組み合わせることで、リンターはオーサリングパスの攻撃ベクトルを閉じます：不可視のトリックはリポジトリに入ることができず、実行時にすり抜けたものはポリシー評価の前に除去されます。
---
## ネットワークセキュリティ
### セキュア通信
**トランスポート層セキュリティ：**
- すべての外部通信にTLS 1.3
- サービス間通信のための相互TLS（mTLS）
- 既知のサービスの証明書ピニング
- 完全前方秘匿性
**メッセージレベルセキュリティ：**
- エージェントメッセージのエンドツーエンド暗号化
- メッセージ認証コード（MAC）
- タイムスタンプによるリプレイ攻撃防止
- メッセージ順序保証
```rust
pub struct SecureChannel {
encryption_key: [u8; 32],
mac_key: [u8; 32],
send_counter: AtomicU64,
recv_counter: AtomicU64,
}
impl SecureChannel {
pub fn encrypt_message(&self, plaintext: &[u8]) -> Result<Vec<u8>> {
let counter = self.send_counter.fetch_add(1, Ordering::SeqCst);
let nonce = self.generate_nonce(counter);
let ciphertext = ChaCha20Poly1305::new(&self.encryption_key)
.encrypt(&nonce, plaintext)?;
let mac = Hmac::<Sha256>::new_from_slice(&self.mac_key)?
.chain_update(&ciphertext)
.chain_update(&counter.to_le_bytes())
.finalize()
.into_bytes();
Ok([ciphertext, mac.to_vec()].concat())
}
}
```
### ネットワーク分離
**サンドボックスネットワーク制御：**
- デフォルトでネットワークアクセスなし
- 外部接続の明示的許可リスト
- トラフィック監視と異常検出
- DNSフィルタリングと検証
**ネットワークポリシー：**
```yaml
network_policy:
default_action: "deny"
allowed_destinations:
- domain: "api.openai.com"
ports: [443]
protocol: "https"
- ip_range: "10.0.0.0/8"
ports: [6333] # Qdrant (only needed if using optional Qdrant backend)
protocol: "http"
monitoring:
log_all_connections: true
detect_anomalies: true
rate_limiting: true
```
---
## インシデント対応
### セキュリティイベント検出
**自動検出：**
- ポリシー違反監視
- 異常行動検出
- リソース使用異常
- 認証失敗追跡
**アラート分類：**
```rust
pub enum ViolationSeverity {
Info, // Normal security events
Warning, // Minor policy violations
Error, // Confirmed security issues
Critical, // Active security breaches
}
pub struct SecurityEvent {
pub id: Uuid,
pub timestamp: SystemTime,
pub severity: ViolationSeverity,
pub category: SecurityEventCategory,
pub description: String,
pub affected_components: Vec<ComponentId>,
pub recommended_actions: Vec<String>,
}
```
### インシデント対応ワークフロー
```mermaid
graph TB
A[Security Event] --> B[Event Classification]
B --> C{Severity Level}
C -->|Info/Low| D[Log Event]
C -->|Medium| E[Alert Security Team]
C -->|High| F[Automatic Mitigation]
C -->|Critical| G[Emergency Response]
F --> H[Isolate Affected Components]
F --> I[Revoke Compromised Credentials]
F --> J[Preserve Evidence]
G --> H
G --> K[Notify Leadership]
G --> L[External Incident Response]
```
### 復旧手順
**自動復旧：**
- クリーンな状態でのエージェント再起動
- 侵害された認証情報のキーローテーション
- 再発防止のためのポリシー更新
- システムヘルス検証
**手動復旧：**
- セキュリティイベントのフォレンジック分析
- 根本原因分析と修復
- セキュリティ制御更新
- インシデント文書化と教訓
---
## セキュリティベストプラクティス
### 開発ガイドライン
1. **デフォルトでセキュア**: すべてのセキュリティ機能をデフォルトで有効化
2. **最小権限の原則**: すべての操作に最小限の権限
3. **多層防御**: 冗長性を持つ複数のセキュリティ層
4. **セキュアな失敗**: セキュリティ失敗はアクセスを許可ではなく拒否すべき
5. **すべてを監査**: セキュリティ関連操作の完全ログ
### デプロイメントセキュリティ
**環境ハードニング：**
```bash
# Disable unnecessary services
systemctl disable cups bluetooth
# Kernel hardening
echo "kernel.dmesg_restrict=1" >> /etc/sysctl.conf
echo "kernel.kptr_restrict=2" >> /etc/sysctl.conf
# File system security
mount -o remount,nodev,nosuid,noexec /tmp
```
**コンテナセキュリティ：**
```dockerfile
# Use minimal base image
FROM scratch
COPY --from=builder /app/symbiont /bin/symbiont
# Run as non-root user
USER 1000:1000
# Set security options
LABEL security.no-new-privileges=true
```
### 運用セキュリティ
**監視チェックリスト：**
- [ ] リアルタイムセキュリティイベント監視
- [ ] ポリシー違反追跡
- [ ] リソース使用異常検出
- [ ] 認証失敗監視
- [ ] 証明書有効期限追跡
**メンテナンス手順：**
- 定期的なセキュリティ更新とパッチ
- スケジュールされたキーローテーション
- ポリシーレビューと更新
- セキュリティ監査と侵入テスト
- インシデント対応計画テスト
---
## セキュリティ設定
### 環境変数
```bash
# Cryptographic settings
export SYMBIONT_CRYPTO_PROVIDER=ring
export SYMBIONT_KEY_STORE_TYPE=hsm
export SYMBIONT_HSM_CONFIG_PATH=/etc/symbiont/hsm.conf
# Audit settings
export SYMBIONT_AUDIT_ENABLED=true
export SYMBIONT_AUDIT_STORAGE=/var/audit/symbiont
export SYMBIONT_AUDIT_RETENTION_DAYS=2555 # 7 years
# Security policies
export SYMBIONT_POLICY_ENFORCEMENT=strict
export SYMBIONT_DEFAULT_SANDBOX_TIER=gvisor
export SYMBIONT_TOFU_ENABLED=true
```
### セキュリティ設定ファイル
```toml
[security]
# Cryptographic settings
crypto_provider = "ring"
signature_algorithm = "ed25519"
encryption_algorithm = "chacha20_poly1305"
# Key management
key_rotation_interval_days = 90
hsm_enabled = true
hsm_config_path = "/etc/symbiont/hsm.conf"
# Audit settings
audit_enabled = true
audit_storage_path = "/var/audit/symbiont"
audit_retention_days = 2555
audit_compression = true
# Sandbox security
default_sandbox_tier = "gvisor"
sandbox_escape_detection = true
resource_limit_enforcement = "strict"
# Network security
tls_min_version = "1.3"
certificate_pinning = true
network_isolation = true
# Policy enforcement
policy_enforcement_mode = "strict"
policy_violation_action = "deny_and_alert"
emergency_override_enabled = false
[tofu]
enabled = true
key_verification_required = true
trust_on_first_use_timeout_hours = 24
automatic_key_pinning = false
```
---
## セキュリティメトリクス
### 主要パフォーマンス指標
**セキュリティ操作：**
- ポリシー評価レイテンシ：平均 <1ms
- 監査イベント生成率：10,000+ イベント/秒
- セキュリティインシデント応答時間：<5分
- 暗号操作スループット：70,000+ 操作/秒
**コンプライアンスメトリクス：**
- ポリシーコンプライアンス率：>99.9%
- 監査証跡整合性：100%
- セキュリティイベント偽陽性率：<1%
- インシデント解決時間：<24時間
**リスク評価：**
- 脆弱性パッチ適用時間：<48時間
- セキュリティ制御有効性：>95%
- 脅威検出精度：>99%
- 復旧時間目標：<1時間
---
## 将来の改良
### 高度な暗号学
**ポスト量子暗号：**
- NIST承認のポスト量子アルゴリズム
- 古典/ポスト量子ハイブリッドスキーム
- 量子脅威の移行計画
**準同型暗号：**
- 暗号化データでのプライバシー保護計算
- 近似算術のためのCKKSスキーム
- 機械学習ワークフローとの統合
**ゼロ知識証明：**
- 計算検証のためのzk-SNARKs
- プライバシー保護認証
- コンプライアンス証明生成
### AI強化セキュリティ
**行動分析：**
- 異常検出のための機械学習
- 予測的セキュリティ分析
- 適応的脅威対応
**自動応答：**
- 自己修復セキュリティ制御
- 動的ポリシー生成
- インテリジェントインシデント分類
---
## 次のステップ
- **[コントリビューション](/contributing)** - セキュリティ開発ガイドライン
- **[ランタイムアーキテクチャ](/runtime-architecture)** - 技術実装詳細
- **[APIリファレンス](/api-reference)** - セキュリティAPIドキュメント
Symbiontセキュリティモデルは、規制産業と高保証環境に適したエンタープライズグレードの保護を提供します。その階層アプローチは、運用効率を維持しながら進化する脅威に対する堅牢な保護を確保します。