セキュリティパターン

強化されたアプリケーション構築のための包括的なセキュリティパターン。各カテゴリは rules/ 内の個別のルールファイルを持ち、オンデマンドで読み込まれます。

クイックリファレンス

カテゴリ	ルール数	影響度	使用場面
認証	3	CRITICAL	JWT トークン、OAuth 2.1/PKCE、RBAC/権限
多層防御	2	CRITICAL	マルチレイヤーセキュリティ、ゼロトラストアーキテクチャ
入力検証	3	HIGH	スキーマ検証 (Zod/Pydantic)、出力エンコーディング、ファイルアップロード
OWASP Top 10	2	CRITICAL	インジェクション防止、認証破壊の修復
LLM セキュリティ	3	HIGH	プロンプトインジェクション防御、出力ガードレール、コンテンツフィルタリング
PII マスキング	2	HIGH	Presidio、Langfuse、LLM Guard による PII 検出/編集
スキャニング	3	HIGH	依存関係監査、SAST (Semgrep/Bandit)、シークレット検出
高度なガードレール	2	CRITICAL	NeMo/Guardrails AI バリデーター、レッドティーム、OWASP LLM

合計: 8 カテゴリ全体で 20 ルール

クイックスタート

# Argon2id パスワードハッシング
from argon2 import PasswordHasher
ph = PasswordHasher()
password_hash = ph.hash(password)
ph.verify(password_hash, password)

# JWT アクセストークン (15分有効期限)
import jwt
from datetime import datetime, timedelta, timezone
payload = {
    'sub': user_id, 'type': 'access',
    'exp': datetime.now(timezone.utc) + timedelta(minutes=15),
}
token = jwt.encode(payload, SECRET_KEY, algorithm='HS256')

// Zod v4 スキーマ検証
import { z } from 'zod';
const UserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(2).max(100),
  role: z.enum(['user', 'admin']).default('user'),
});
const result = UserSchema.safeParse(req.body);

# Langfuse を使用した PII マスキング
import re
from langfuse import Langfuse

def mask_pii(data, **kwargs):
    if isinstance(data, str):
        data = re.sub(r'\b[\w.-]+@[\w.-]+\.\w+\b', '[REDACTED_EMAIL]', data)
        data = re.sub(r'\b\d{3}-\d{2}-\d{4}\b', '[REDACTED_SSN]', data)
    return data

langfuse = Langfuse(mask=mask_pii)

認証

OAuth 2.1、Passkeys/WebAuthn、JWT トークン、ロールベースアクセス制御を用いた安全な認証。

ルール	説明
auth-jwt.md	JWT 作成、検証、有効期限、リフレッシュトークンローテーション
auth-oauth.md	OAuth 2.1 (PKCE、DPoP、Passkeys/WebAuthn)
auth-rbac.md	ロールベースアクセス制御、権限デコレーター、MFA

主要な判断基準: Argon2id > bcrypt | アクセストークン 15 分 | PKCE 必須 | Passkeys > TOTP > SMS

多層防御

単一障害点のない多層セキュリティアーキテクチャ。

ルール	説明
defense-layers.md	8 層セキュリティアーキテクチャ (エッジから可視性まで)
defense-zero-trust.md	イミュータブルリクエストコンテキスト、テナント分離、監査ログ

主要な判断基準: イミュータブル dataclass コンテキスト | クエリレベルテナントフィルタリング | LLM プロンプトに ID を含めない

sandbox.network.deniedDomains (CC 2.1.113+)

Bash/WebFetch 発信前に強制されるネットワークレイヤーの拒否リスト — フック層の DENY_PATTERNS とペアで多層防御として機能します。設定例:

"sandbox": {
  "network": {
    "deniedDomains": ["*.evil.com", "pastebin.com", "transfer.sh"]
  }
}

ワイルドカード対応 (*.example.com、evil.com/*/malicious/*)。プラグインは src/settings/ork.settings.json 内にベースラインリストを付属します。プロジェクト設定でこれを拡張できます。用途: プロンプトインジェクション流出シンク、既知の悪質なレジストリ、監査をバイパスするペーストサービス。

入力検証

Zod v4 と Pydantic を使用したすべての信頼できない入力の検証とサニタイゼーション。

ルール	説明
validation-input.md	Zod v4 と Pydantic を使用したスキーマ検証、型強制
validation-output.md	HTML サニタイゼーション、出力エンコーディング、XSS 防止
validation-schemas.md	判別ユニオン、ファイルアップロード検証、URL ホワイトリスト

主要な判断基準: ブロックリストではなくホワイトリスト | 常にサーバー側で検証 | 拡張子ではなくマジックバイトで検証

OWASP Top 10

最も重大な Web アプリケーションセキュリティリスクに対する防止。

ルール	説明
owasp-injection.md	SQL/コマンドインジェクション、パラメータ化クエリ、SSRF 防止
owasp-broken-auth.md	JWT アルゴリズム混同、CSRF 保護、タイミング攻撃

主要な判断基準: パラメータ化クエリのみ | JWT アルゴリズムをハードコード | SameSite=Strict クッキー

LLM セキュリティ

コンテキスト分離と出力検証を含む LLM 統合のセキュリティパターン。

ルール	説明
llm-prompt-injection.md	コンテキスト分離、プロンプト監査、禁止パターン
llm-guardrails.md	出力検証パイプライン: スキーマ、根拠、安全性、サイズ
llm-content-filtering.md	事前 LLM フィルタリング、事後 LLM 属性付け、3 フェーズパターン

主要な判断基準: ID は LLM を通さず、その周辺を流す | 属性付けは決定的 | すべてのプロンプトを監査

コンテキスト分離 (CRITICAL)

機密 ID とデータは LLM を通さず、その周辺を流します。LLM はコンテンツのみを見て、エンティティへのマッピングはその後決定的に行われます。

# 正: ID は LLM をバイパス
context = {"user_id": user_id, "tenant_id": tenant_id}  # サーバー側で保持
llm_input = f"Summarize this document:\n{doc_text}"       # プロンプトに ID なし
llm_output = call_llm(llm_input)
result = {"summary": llm_output, **context}               # その後 ID を再度添付

出力検証パイプライン

すべての LLM レスポンスはユーザーに到達する前に 4 段階のガードレールパイプラインを通過する必要があります:

def validate_llm_output(raw_output: str, schema, sources: list[str]) -> str:
    # 1. スキーマ — 期待される構造に一致するか？
    parsed = schema.parse(raw_output)
    # 2. 根拠 — クレームは元のドキュメントで支持されているか？
    assert_grounded(parsed, sources)
    # 3. 安全性 — 毒性、PII 漏洩、プロンプト漏洩
    assert_safe(parsed, max_toxicity=0.5)
    # 4. サイズ — トークン爆弾レスポンスを防止
    assert len(parsed.text) < MAX_OUTPUT_CHARS
    return parsed.text

PII マスキング

LLM 可視性パイプラインとログの PII 検出と編集。

ルール	説明
pii-detection.md	Microsoft Presidio、正規表現パターン、LLM Guard Anonymize
pii-redaction.md	Langfuse マスクコールバック、structlog/loguru プロセッサー、Vault の匿名化解除

主要な判断基準: エンタープライズは Presidio | 型トークンで置換 | 初期化時にマスクコールバックを使用

スキャニング

依存関係、コード、シークレットの自動セキュリティスキャニング。

ルール	説明
scanning-dependency.md	npm audit、pip-audit、Trivy コンテナスキャニング、CI ゲーティング
scanning-sast.md	Semgrep と Bandit 静的分析、カスタムルール、プリコミット
scanning-secrets.md	Gitleaks、TruffleHog、ベースライン管理付き detect-secrets

主要な判断基準: プリコミットフックで左シフト | Critical/High でブロック | Gitleaks + detect-secrets ベースライン

高度なガードレール

NeMo Guardrails、Guardrails AI バリデーター、DeepTeam レッドティーミングによる本番 LLM セキュリティ。

ルール	説明
guardrails-nemo.md	NeMo Guardrails、Colang 2.0 フロー、Guardrails AI バリデーター、階層化検証
guardrails-llm-validation.md	DeepTeam レッドティーム (40+ 脆弱性)、OWASP LLM Top 10 準拠

主要な判断基準: フロー用 NeMo、バリデーター用 Guardrails AI | 毒性閾値 0.5 | リリース前のレッドティーム + 四半期ごと

管理フック階層 (CC 2.1.49)

プラグイン設定は 3 層の優先順位に従います:

層	ソース	オーバーライド可能？
1. 管理 (プラグイン settings.json)	プラグイン作成者がデフォルトを配信	はい、ユーザーが可能
2. プロジェクト (.claude/settings.json)	リポジトリ設定	はい、ユーザーが可能
3. ユーザー (~/.claude/settings.json)	個人設定	最終的な権限

OrchestKit が配信するセキュリティフックは管理デフォルトです — ユーザーはそれを無効化できますが警告されます。エンタープライズ管理者は管理プロファイルを介して設定をロックできます。

アンチパターン (禁止)

# 認証
user.password = request.form['password']       # 平文パスワード保存
response_type=token                             # 暗黙的 OAuth グラント (廃止予定)
return "Email not found"                        # 情報開示

# 入力検証
"SELECT * FROM users WHERE name = '" + name + "'"  # SQL インジェクション
if (file.type === 'image/png') {...}               # Content-Type ヘッダーを信頼

# LLM セキュリティ
prompt = f"Analyze for user {user_id}"             # プロンプト内に ID
artifact.user_id = llm_output["user_id"]           # LLM 生成 ID を信頼

# PII
logger.info(f"User email: {user.email}")           # ログ内の生 PII
langfuse.trace(input=raw_prompt)                   # マスク解除された可視性データ

詳細ドキュメント

Read("${CLAUDE_SKILL_DIR}/references/<file>") でオンデマンド読み込み:

ファイル	内容
oauth-2.1-passkeys.md	OAuth 2.1、PKCE、DPoP、Passkeys/WebAuthn
request-context-pattern.md	ID フロー用のイミュータブルリクエストコンテキスト
tenant-isolation.md	テナントスコープリポジトリ、ベクトル/全文検索
audit-logging.md	サニタイズされた構造化ログ、コンプライアンス
zod-v4-api.md	Zod v4 タイプ、強制、変換、改善
vulnerability-demos.md	OWASP の脆弱性対安全なコード例
context-separation.md	LLM コンテキスト分離アーキテクチャ
output-guardrails.md	出力検証パイプライン実装
pre-llm-filtering.md	テナントスコープ検索、コンテンツ抽出
post-llm-attribution.md	決定的な属性付けパターン
prompt-audit.md	プロンプト監査パターン、安全なプロンプトビルダー
presidio-integration.md	Microsoft Presidio セットアップ、カスタム認識器
langfuse-mask-callback.md	Langfuse SDK マスク実装
llm-guard-sanitization.md	LLM Guard Anonymize/Deanonymize with Vault
logging-redaction.md	structlog/loguru プリログ編集

関連スキル

• api-design-framework - API セキュリティパターン
• ork:rag-retrieval - テナントスコープ検索を必要とする RAG パイプラインパターン
• llm-evaluation - 幻覚検出を含む出力品質評価

機能の詳細

authentication

キーワード: password、hashing、JWT、token、OAuth、PKCE、passkey、WebAuthn、RBAC、session 解決する問題:

• モダン標準を使用した安全な認証の実装
• 適切な有効期限を持つ JWT トークン管理
• PKCE フロー付き OAuth 2.1
• Passkeys/WebAuthn 登録とログイン
• ロールベースアクセス制御

defense-in-depth

キーワード: defense in depth、security layers、multi-layer、request context、tenant isolation 解決する問題:

• AI アプリケーションをエンドツーエンドで保護する方法
• 8 層セキュリティアーキテクチャの実装
• イミュータブルリクエストコンテキストの作成
• クエリレベルでのテナント分離の確保

cc-subprocess-hardening (CC 2.1.98)

キーワード: subprocess、sandbox、PID namespace、env scrub、script caps 解決する問題:

• 暴走フックスクリプトの制限: CLAUDE_CODE_SCRIPT_CAPS=100
• サブプロセスから認証情報を削除: CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1
• Linux でのサブプロセスサンドボックス用 PID 名前空間分離
• バックスラッシュエスケープと複合コマンドによる Bash 権限昇格の防止

CC 2.1.128 — SDK ホスト "常に許可" の永続化: SDK ホスト内で Bash 権限プロンプトから "常に許可" を選択したユーザーの場合、付与はセッション終了時に蒸発するのではなく .claude/settings.local.json 経由で永続化するようになりました。.claude/settings.local.json が .gitignore に含まれることを確認するように SDK コンシューマーの設定を監査してください — コミットするとデベロッパー別 Bash 認証付与がリークします。プロジェクトコミット済み .claude/settings.json は変更されません。ユーザー機械ローカルファイルのみが新しいエントリを受け取ります。

input-validation

キーワード: schema、validate、Zod、Pydantic、sanitize、HTML、XSS、file upload 解決する問題:

• スキーマに対する入力検証 (Zod v4、Pydantic)
• ホワイトリストを使用したインジェクション攻撃の防止
• HTML のサニタイゼーションと XSS 防止
• マジックバイトによるファイルアップロード検証

owasp-top-10

キーワード: OWASP、sql injection、broken access control、CSRF、XSS、SSRF 解決する問題:

• OWASP Top 10 脆弱性の修復
• SQL およびコマンドインジェクションの防止
• CSRF 保護の実装
• 認証破壊の修復

llm-safety

キーワード: prompt injection、context separation、guardrails、hallucination、LLM output 解決する問題:

• プロンプトインジェクション攻撃の防止
• コンテキスト分離 (LLM の周辺に ID) の実装
• ガードレールパイプラインによる LLM 出力検証
• 決定的な事後 LLM 属性付け

pii-masking

キーワード: PII、masking、Presidio、Langfuse、redact、GDPR、privacy 解決する問題:

• LLM パイプラインの PII 検出と編集
• Langfuse 可視性への編集の統合
• プリログ編集の実装
• GDPR 準拠データ処理