セキュリティ概要
secretctl はセキュリティを基本原則として設計されています。このガイドでは、セキュリティアーキテクチャ、脅威モデル、シークレットを保護するための対策について説明します。
コアセキュリティ原則
1. 標準ライブラリのみ使用
secretctl は暗号化操作に Go 標準ライブラリと golang.org/x/crypto のみを使用します:
- カスタム暗号化なし - すべての暗号化は実績のある実装を使用
- 最小限の依存関係 - サプライチェーン攻撃のリスクを軽減
- 監査可能なコードベース - セキュリティレビューが容易
2. AI 連携のための AI安全設計
secretctl の AI セキュリティモデルの基盤:
AI エージェントは平文のシークレットを受け取ることがありません。
| アクセス方法 | 平文アクセス | 用途 |
|---|---|---|
| CLI | あり | 人間オペレーター |
| デスクトップアプリ | あり | 人間オペレーター |
| MCP サーバー | なし | AI エージェント |
これは 1Password の「Access Without Exposure」 の哲学に沿っています。
3. ローカルファーストアーキテクチャ
シークレットはマシンから出ることはありません:
- クラウド依存なし - 完全にオフラインで動作
- アカウント不要 - 外部認証なし
- ネットワーク露出なし - MCP は stdio トランスポートを使用（Phase 0-2）
- 完全なデータ所有権 - Vault ファイルを自分で制御
4. 保存時の暗号化
すべてのシークレットは業界標準のアルゴリズムで暗号化:
- AES-256-GCM - シークレット用の認証付き暗号化
- Argon2id - メモリハードな鍵導出関数
- OWASP パラメータ - 2025年のベストプラクティスに準拠
セキュリティ機能サマリー
暗号化
| 機能 | 実装 |
|---|---|
| 対称暗号 | AES-256-GCM |
| 鍵導出 | Argon2id (64MB, 3イテレーション, 4スレッド) |
| Nonce | 暗号化ごとに96ビットランダム |
| Salt | Vault ごとに128ビット |
アクセス制御
| 機能 | 説明 |
|---|---|
| マスターパスワード | Vault の復号に必要 |
| ファイル権限 | 機密ファイルは 0600 |
| MCP ポリシー | 許可/拒否キーを設定可能 |
| 出力サニタイズ | コマンド出力でのシークレット自動編集 |
監査とコンプライアンス
| 機能 | 説明 |
|---|---|
| 監査ログ | すべての操作を記録 |
| HMAC チェーン | 改ざん検出可能なログ整合性 |
| エクスポートオプション | コンプライアンス用 JSON, CSV |
| 検証 | secretctl audit verify コマンド |
脅威モデル
secretctl が保護するもの
- 保存時の暗号化されたシークレットの機密性
- Vault データと監査ログの整合性
- MCP 操作のアクセス制御（AI に平文を渡さない）
- すべてのシークレットアクセスの監査証跡
対象外（業界標準の除外事項）
Vault、Infisical、1Password と同様に、secretctl は以下を除外します:
- ルートレベルの侵害 - 攻撃者が root を持っていれば、ゲームオーバー
- メモリダンプ攻撃 - Go ランタイムの制限（下記参照）
- 弱いマスターパスワード - ユーザーの責任
- 無制限のストレージアクセス - 物理アクセスは信頼されると仮定
メモリ保護の制限
Go のガベージコレクターがメモリを管理するため、確実なゼロ化は困難です。これは Vault や Infisical と共有される業界標準の除外事項です。secretctl はシークレットがメモリに存在する時間を最小化します。
攻撃レベル
| レベル | 攻撃者 | 能力 | 保護? |
|---|---|---|---|
| L1 | ネットワーク観察者 | ネットワーク傍受 | はい（localhost のみ） |
| L2 | 悪意のあるアプリ | ファイルシステム読み取り | はい（暗号化） |
| L3 | Root 攻撃者 | フルシステムアクセス | いいえ（除外） |
代替製品との比較
| 製品 | MCP サポート | AI 平文アクセス | ローカルファースト | OSS |
|---|---|---|---|---|
| HashiCorp Vault | あり（実験的） | あり (read_secret) | いいえ（サーバー必要） | BSL |
| Infisical | あり | あり (get-secret) | いいえ（サーバー必要） | あり |
| 1Password | なし（MCP 拒否） | なし（ポリシー） | いいえ（サブスクリプション） | なし |
| secretctl | あり | なし (AI安全設計) | あり | あり |
ユニークなポジション: secretctl は MCP サポート + AI に平文なし + 完全ローカル + オープンソースを兼ね備えた唯一のソリューションです。
1Password のセキュリティ原則
secretctl は 1Password の AI へのアプローチを導くのと同じ原則に従います:
| 原則 | 1Password | secretctl |
|---|---|---|
| シークレットは秘密のまま | ゼロ知識暗号化 | AES-256-GCM + Argon2id |
| 決定論的認可 | LLM が認可決定をしない | ポリシーエンジンがアクセスを制御 |
| LLM に生の認証情報を渡さない | プロンプトにシークレットを含めない | AI安全設計が平文を禁止 |
| 監査可能性 | アクセスとアクションを記録 | 完全な監査ログ |
| 透明性 | AI が見るものを開示 | マスクされた値のみ返却 |
| 最小権限 | 必要最小限のアクセス | ポリシーベースのキー制限 |
| セキュリティは組み込み | 後付けでない | CLI/MCP/UI が一貫した設計を共有 |
AI エージェントがシークレットを見るべきでない理由
1Password は AI にシークレットを渡すことを避ける 4つの主要な理由 を特定しました:
| リスク | 説明 | secretctl の軽減策 |
|---|---|---|
| 非決定性 | AI の振る舞いは予測不可能 | 決定論的制御のポリシーエンジン |
| プロンプトインジェクション | 悪意のあるプロンプトがシークレットを抽出可能 | シークレットは AI コンテキストに到達しない |
| 取り消し不可能性 | LLM コンテキストでシークレットを見なかったことにはできない | 露出していなければ取り消す必要なし |
| キャッシュ/共有 | AI が下流に保存または共有する可能性 | 共有するシークレット値が存在しない |
クイックリンク
- 脅威モデル - ビジュアル脅威モデルと攻撃レベル
- セキュリティ設計 - 包括的なセキュリティアーキテクチャ
- 仕組み - 技術的な実装詳細
- 暗号化詳細 - 暗号仕様
- MCP ツールリファレンス - AI 連携セキュリティ
- 監査ログ - アクティビティ監視
セキュリティ報告
セキュリティの問題を見つけましたか？責任を持って報告してください:
- 公開の GitHub Issue を開かないでください
- セキュリティの懸念はメンテナーにメール
- 開示前に修正のための適切な時間を与える
私たちはセキュリティを真剣に受け止め、責任ある開示に感謝します。