Security Architect

セキュリティアーキテクト

概要

セキュリティアーキテクトは、脅威モデリング、セキュアな設計原則、セキュアコーディングの実践、規制コンプライアンスに至るまで、セキュリティのライフサイクル全体を網羅する統合スキルです。セキュリティを後付けするのではなく、最初から組み込むことを徹底します。

以下を統合しています：

• threat-modeling - STRIDE による脅威分析とリスク評価
• security-first-design - セキュリティ原則とセキュアな設計パターン
• secure-coding-review - OWASP Top 10 と脆弱性の検出
• compliance-validator - GDPR、HIPAA、SOC2、PCI-DSS への準拠

このスキルを使用するタイミング

以下の場合にセキュリティアーキテクトを使用します：

• 新しいプロジェクトを開始するとき（設計フェーズ）
• セキュリティアーキテクチャのレビューを実施するとき
• コードのセキュリティ脆弱性をレビューするとき
• 規制コンプライアンスを確保するとき
• セキュリティインシデントに対応するとき
• セキュリティ認証（SOC2、ISO 27001）を計画するとき
• 認証および認可システムを設計するとき

主な機能

脅威モデリング（threat-modeling より）

• 脅威の特定に STRIDE 手法を適用する
• リスクレベル（可能性 × 影響度）を評価する
• 脅威モデルと緩和計画を作成する
• 攻撃対象領域と信頼境界を特定する

セキュリティ設計（security-first-design より）

• セキュリティ原則（多層防御、最小権限、ゼロトラスト）を適用する
• セキュアな認証および認可を設計する
• 暗号化と鍵管理を実装する
• セキュアな API とデータ保護を設計する

セキュアコーディング（secure-coding-review より）

• OWASP Top 10 に照らしてコードをレビューする
• インジェクションの脆弱性（SQL、XSS、コマンド）を検出する
• 認証とアクセス制御の不備を特定する
• セキュアなデータ処理と検証を徹底する

コンプライアンス（compliance-validator より）

• GDPR、HIPAA、CCPA、SOC2、PCI-DSS への準拠を確保する
• データ主体の権利（アクセス、消去、ポータビリティ）を実装する
• 監査ログと保持ポリシーを設計する
• 暗号化とアクセス制御を設定する

ワークフロー

パート 1：脅威モデリング（STRIDE）

STRIDE フレームワーク

S - なりすまし（認証）

• **脅威：**攻撃者がユーザーまたはシステムになりすまします
• 例：
  • 認証情報の窃取
  • セッションハイジャック
  • 認証が弱い、または認証がない
• 緩和策：
  • 多要素認証（MFA）
  • 強力なパスワードポリシー
  • 有効期限の短い JWT
  • 安全なセッション管理

T - 改ざん（完全性）

• **脅威：**攻撃者がデータまたはコードを変更します
• 例：
  • SQL インジェクション
  • 中間者攻撃
  • パラメーターの操作
  • コードインジェクション
• 緩和策：
  • 入力の検証とサニタイズ
  • あらゆる通信で HTTPS/TLS を使用
  • 署名付きトークン（JWT）
  • 完全性チェック（ハッシュ化）

R - 否認（説明責任）

• **脅威：**ユーザーが操作の実行を否認します
• 例：
  • 監査ログがない
  • 署名のないトランザクション
  • 匿名での操作
• 緩和策：
  • 包括的な監査ログの記録
  • トランザクションへのデジタル署名
  • 改ざん不可能なログストレージ
  • ユーザー操作の追跡

I - 情報漏えい（機密性）

• **脅威：**機密データが権限のない第三者に漏えいします
• 例：
  • API キーの漏えい
  • データベースダンプ
  • 詳細すぎるエラーメッセージ
  • 不十分なアクセス制御
• 緩和策：
  • 保存時および転送時の暗号化
  • 最小権限の原則
  • セキュアなシークレット管理（AWS Secrets Manager、Vault）
  • ロールベースアクセス制御（RBAC）

D - サービス拒否（可用性）

• **脅威：**正当なユーザーがシステムを利用できなくなります
• 例：
  • DDoS 攻撃
  • リソースの枯渇
  • 未処理の例外
• 緩和策：
  • レート制限とスロットリング
  • 入力の検証（巨大なペイロードを拒否）
  • インフラストラクチャの自動スケーリング
  • CDN と DDoS 対策（Cloudflare）

E - 権限昇格（認可）

• **脅威：**ユーザーが権限のない、より高い権限を取得します
• 例：
  • アクセス制御の不備
  • 安全でない直接オブジェクト参照（IDOR）
  • 認可チェックの欠落
• 緩和策：
  • すべてのリクエストで認可チェックを実施
  • 最小権限の原則
  • 属性ベースアクセス制御（ABAC）
  • 定期的な権限監査

---

脅威モデリングのプロセス

ステップ 1：資産を特定する

• ユーザーデータ（PII、パスワード、財務情報）
• ビジネスデータ（IP、顧客リスト、トランザクション）
• システム認証情報（API キー、証明書）
• インフラストラクチャ（サーバー、データベース、API）

ステップ 2：信頼境界を特定する

• ユーザー ↔ Web アプリ
• Web アプリ ↔ API
• API ↔ データベース
• 内部サービス ↔ 外部 API
• 管理者 ↔ 本番システム

ステップ 3：各境界に STRIDE を適用する 各境界について、次の点を確認します。

• **S：**攻撃者は身元を偽装できますか？
• **T：**データは改ざんされる可能性がありますか？
• **R：**操作を否認できますか？
• **I：**情報が漏えいする可能性はありますか？
• **D：**サービスを妨害される可能性はありますか？
• **E：**権限が昇格される可能性はありますか？

ステップ 4：リスクを評価する

Risk = Likelihood × Impact

Likelihood:
- High (likely to occur)
- Medium (may occur)
- Low (unlikely to occur)

Impact:
- Critical (data breach, financial loss, legal liability)
- High (significant damage, downtime)
- Medium (limited damage, temporary disruption)
- Low (minimal impact)

Risk Level:
- Critical: Immediate action required
- High: Address before launch
- Medium: Address post-launch
- Low: Monitor, may accept risk

ステップ 5：緩和策を定める 各脅威について、次の項目を記録します。

• 緩和策
• 実装の労力（低、中、高）
• 緩和後の残存リスク
• 担当者とスケジュール

---

パート 2：セキュリティを最優先した設計

セキュリティの原則

1. 多層防御 複数のセキュリティ制御層を設けます。1つの層が機能しなくても、ほかの層が保護します。

例：

• 第1層：ファイアウォール
• 第2層：認証
• 第3層：認可
• 第4層：暗号化
• 第5層：監査ログ

2. 最小権限 ユーザーやシステムには、必要最小限の権限のみを付与します。

例：

• レポートサービスには読み取り専用のデータベース認証情報を使用する
• ユーザーには自分のデータのみを表示する
• 管理者アクセスには MFA と有効期限付きトークンを要求する

3. ゼロトラスト 信頼せず、常に検証します。内部ネットワークも信頼しません。

例：

• すべてのリクエストを認証・認可する
• 「信頼された」内部ネットワークを設けない
• 内部トラフィックを暗号化する
• 侵害されていることを前提とする

4. デフォルトで安全 デフォルトの構成を安全にします。安全性の低い設定を使う場合は、ユーザーが明示的に選択する必要があります。

例：

• デフォルトで HTTPS を強制する
• デフォルトで厳格なパスワードポリシーを適用する
• サインアップ時に MFA を推奨する
• セキュア Cookie（HttpOnly、Secure、SameSite）を使用する

5. 安全にフェイルする エラーが発生した場合、セキュリティを損なわない形で失敗させます。

例：

• エラー時はアクセスを許可せず、拒否する
• エラーを記録するが、詳細をユーザーに公開しない
• 内部情報を公開せず、適切に機能を縮退させる

---

セキュアな設計パターン

認証：

• パターン： OAuth 2.0 + OpenID Connect（OIDC）
• 実装：
  • Auth0、AWS Cognito、または Okta を使用する（独自に構築しない）
  • 有効期限の短い JWT トークン（アクセストークンは 15 分、リフレッシュトークンは 7 日）
  • トークンを安全に保存する（HttpOnly Cookie またはセキュアなローカルストレージ）
  • 機密性の高い操作には MFA を使用する

認可：

• パターン： ロールベースアクセス制御（RBAC）または属性ベースアクセス制御（ABAC）
• 実装：
  • ロールを定義する：admin、user、viewer
  • すべての API リクエストで認可を確認する
  • ミドルウェアを使用する：@requireRole('admin')
  • IDOR 対策を実装する（所有者であることを確認する）

データ保護：

• パターン： 保存時と転送時の暗号化
• 実装：
  • すべての外部トラフィックに TLS 1.3 を使用する
  • 保存データに AES-256 を使用する
  • キー管理サービスを使用する（AWS KMS、Google Cloud KMS）
  • PII フィールド（メールアドレス、SSN、クレジットカード）を暗号化する

API セキュリティ：

• パターン： レート制限 + 認証 + 入力検証
• 実装：
  • レート制限：ユーザーあたり毎分 100 リクエスト
  • サーバー間通信には API キーを使用する
  • ユーザーとサーバー間の通信には OAuth トークンを使用する
  • すべての入力を検証する（型、長さ、形式）
  • 許可する値をホワイトリストに登録する

シークレット管理：

• パターン： シークレットをコミットせず、シークレットマネージャーを使用する
• 実装：
  • AWS Secrets Manager または HashiCorp Vault を使用する
  • 構成には環境変数を使用する（コードには含めない）
  • シークレットを定期的にローテーションする（90 日ごと）
  • IAM ロールを使用する（長期間有効な認証情報は使用しない）

---

パート 3：セキュアコーディングレビュー（OWASP Top 10）

OWASP Top 10（2021）

A01：アクセス制御の不備

• リスク： ユーザーが本来アクセスできないデータや機能にアクセスします
• 例：
  • URL の改ざん：/user/123 → /user/456
  • 認可チェックの欠如
  • 安全でない直接オブジェクト参照（IDOR）

検出方法：

// BAD: No authorization check
app.get('/api/users/:id', (req, res) => {
  const user = db.users.findById(req.params.id)
  res.json(user) // Anyone can see any user!
})

// GOOD: Check ownership
app.get('/api/users/:id', authMiddleware, (req, res) => {
  const requestedId = req.params.id
  const currentUserId = req.user.id

  if (requestedId !== currentUserId && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' })
  }

  const user = db.users.findById(requestedId)
  res.json(user)
})

---

A02：暗号化の不備

• リスク： 暗号化が弱い、または実装されていないため、機密データが漏えいします
• 例：
  • データベース内の平文パスワード
  • HTTPS ではなく HTTP を使用
  • 脆弱なハッシュ化（MD5、SHA1）

検出方法：

// BAD: Plaintext password
const user = { email, password: req.body.password }
db.users.create(user)

// GOOD: Hash with bcrypt
const bcrypt = require('bcrypt')
const hashedPassword = await bcrypt.hash(req.body.password, 10)
const user = { email, password: hashedPassword }
db.users.create(user)

---

A03：インジェクション

• リスク： 攻撃者が悪意のあるコード（SQL、XSS、コマンド）を注入します
• 例：
  • SQL インジェクション
  • クロスサイトスクリプティング（XSS）
  • コマンドインジェクション

検出方法：

// BAD: SQL Injection
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`
db.query(query) // Attacker can send: ' OR '1'='1

// GOOD: Parameterized query
const query = 'SELECT * FROM users WHERE email = ?'
db.query(query, [req.body.email])

// BAD: XSS
;<div dangerouslySetInnerHTML={{ __html: userInput }} />

// GOOD: Escape user input
import DOMPurify from 'dompurify'
const sanitized = DOMPurify.sanitize(userInput)
;<div dangerouslySetInnerHTML={{ __html: sanitized }} />

---

A04：安全でない設計

• リスク： アーキテクチャに欠陥がある、またはセキュリティ制御が不足しています
• 例：
  • レート制限がない
  • 脅威モデリングが行われていない
  • セキュリティ要件がない

検出方法：

• アーキテクチャ図を確認する
• レート制限、認証、認可を確認する
• 脅威モデルが存在することを検証する

---

A05：セキュリティ設定の不備

• リスク： デフォルト設定、詳細すぎるエラー、不必要な機能の有効化
• 例：
  • デフォルトの管理者パスワード
  • ディレクトリ一覧表示が有効
  • 本番環境でのスタックトレース表示

検出方法：

// BAD: Exposes stack trace
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack })
})

// GOOD: Generic error message
app.use((err, req, res, next) => {
  logger.error(err)
  res.status(500).json({ error: 'Internal server error' })
})

---

A06〜A10：その他の重大な問題

• A06： 脆弱で古くなったコンポーネント（npm audit、Dependabot を使用）
• A07： 識別と認証の失敗（脆弱なパスワード、多要素認証なし）
• A08： ソフトウェアとデータの完全性の不備（サプライチェーン攻撃）
• A09： セキュリティログと監視の不備（監査ログなし）
• A10： サーバーサイドリクエストフォージェリ（SSRF）（URL を検証する）

---

パート 4：コンプライアンスの検証

規制の枠組み

GDPR（一般データ保護規則）

• 適用範囲： EU のデータ主体
• 主な要件：
  • 処理の適法な根拠（同意、契約、正当な利益）
  • データ主体の権利（アクセス、訂正、消去、データポータビリティ）
  • プライバシー・バイ・デザインおよびデフォルト設定
  • データ侵害の通知（72 時間以内）
  • リスクの高い処理に対するデータ保護影響評価（DPIA）

実装チェックリスト：

• データ収集のための同意取得の仕組み
• データ主体からのアクセス要求（DSAR）への対応プロセス
• 消去権（「忘れられる権利」）の実装
• データポータビリティのためのエクスポート（JSON/CSV）
• プライバシーポリシーと Cookie バナー
• ベンダーとのデータ処理契約（DPA）
• 侵害通知プロセス

---

HIPAA（医療保険の相互運用性と説明責任に関する法律）

• 適用範囲： 米国の医療データ
• 主な要件：
  • 保護対象保健情報（PHI）の暗号化
  • アクセス制御と監査ログ
  • 業務提携者契約（BAA）
  • 侵害通知

実装チェックリスト：

• 保存時（AES-256）および転送時（TLS 1.3）に PHI を暗号化
• PHI に対するロールベースのアクセス制御
• すべての PHI アクセスに関する監査ログ
• クラウドプロバイダー（AWS、Azure）との BAA
• 侵害通知プロセス
• 定期的なセキュリティリスク評価

---

SOC 2（サービス組織統制 2）

• 適用範囲： 顧客データを取り扱う SaaS 企業
• 主な要件：
  • 信頼性サービス基準（セキュリティ、可用性、機密性）
  • アクセス制御と監視
  • 変更管理
  • インシデント対応

実装チェックリスト：

• セキュリティポリシーの文書化
• 従業員の身元調査
• 多要素認証（MFA）の必須化
• 保存時および転送時の暗号化
• 監査ログの記録と監視
• インシデント対応計画
• ベンダー管理プログラム
• 定期的なセキュリティ研修

---

PCI-DSS（ペイメントカード業界データセキュリティ基準）

• 適用範囲： クレジットカードデータを取り扱う組織
• 主な要件：
  • CVV/CVC コードを決して保存しない
  • カード会員データを暗号化する
  • システムを定期的に更新し、パッチを適用する
  • カード会員データへのアクセスを制限する

実装チェックリスト：

• 決済プロセッサ（Stripe、Braintree）を使用する — カードを自社で保存しないこと
• カードを保存する場合は、トークン化を使用する
• PCI 準拠のホスティング（レベル 1 認定）
• ネットワークのセグメンテーション（カード会員データを分離）
• 脆弱性スキャンと侵入テスト
• 強固なアクセス制御

---

例

例 1：SaaS アプリケーションの脅威モデル

アプリケーション： プロジェクト管理 SaaS

資産：

• ユーザー認証情報（メールアドレス、パスワード）
• プロジェクトデータ（ドキュメント、タスク、コメント）
• 決済情報（Stripe 経由）
• 連携用 API キー

信頼境界：

1. ユーザーのブラウザー ↔ Web アプリ（HTTPS）
2. Web アプリ ↔ API サーバー（内部 TLS）
3. API サーバー ↔ データベース（暗号化された接続）
4. API サーバー ↔ Stripe API（HTTPS）

境界 1（ユーザー ↔ Web アプリ）の STRIDE 分析：

脅威	リスク	対策
S： 認証情報の窃取	高	MFA、パスワードのハッシュ化（bcrypt）
T： セッションハイジャック	中	HttpOnly Cookie、SameSite、CSRF トークン
R： 操作の否認	低	すべてのユーザー操作に関する監査ログ
I： XSS によるデータ漏えい	高	コンテンツセキュリティポリシー、入力のサニタイズ
D： ブルートフォースログイン	中	レート制限（1 分あたり 5 回まで）
E： アカウントの乗っ取り	高	メール認証、MFA

優先度の高い対策：

1. MFA を導入する（高リスク、高インパクト）
2. レート制限を追加する（中リスク、簡単に修正可能）
3. CSP ヘッダーを有効にする（高リスク、簡単に修正可能）

---

例 2：セキュアコードレビューの指摘事項

コードレビュー： ユーザー認証エンドポイント

指摘事項：

重大：SQL インジェクション（A03）

// Current code (VULNERABLE):
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`

// Recommended fix:
const query = 'SELECT * FROM users WHERE email = ? AND password_hash = ?'
const hashedPassword = bcrypt.hashSync(password, user.salt)
db.query(query, [email, hashedPassword])

高：平文パスワード（A02）

// Current code (VULNERABLE):
db.users.create({ email, password })

// Recommended fix:
const hashedPassword = await bcrypt.hash(password, 10)
db.users.create({ email, password: hashedPassword })

中：レート制限なし（A04）

// Recommended fix:
const rateLimit = require('express-rate-limit')
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5 // 5 attempts
})
app.post('/login', loginLimiter, loginHandler)

対応： デプロイ前に重大および高の問題を修正します。中の問題はリリース後に対応します。

---

例 3：GDPR 準拠の実装

要件： データ主体の権利を実装する

実装：

1. アクセス権（DSAR）

app.get('/api/user/data-export', authMiddleware, async (req, res) => {
  const userId = req.user.id

  const userData = {
    profile: await db.users.findById(userId),
    projects: await db.projects.findByUser(userId),
    comments: await db.comments.findByUser(userId),
    activity: await db.activityLog.findByUser(userId)
  }

  res.setHeader('Content-Type', 'application/json')
  res.setHeader('Content-Disposition', 'attachment; filename=my-data.json')
  res.json(userData)
})

2. 消去権

app.delete('/api/user/account', authMiddleware, async (req, res) => {
  const userId = req.user.id

  // Anonymize instead of delete (retain for legal compliance)
  await db.users.update(userId, {
    email: `deleted-${userId}@example.com`,
    name: 'Deleted User',
    deleted_at: new Date()
  })

  // Delete PII
  await db.sessions.deleteByUser(userId)
  await db.notifications.deleteByUser(userId)

  res.json({ message: 'Account deleted successfully' })
})

3. 同意管理

const user = {
  email,
  marketing_consent: req.body.marketingConsent || false,
  analytics_consent: req.body.analyticsConsent || false,
  consent_date: new Date()
}

---

ベストプラクティス

脅威モデリング

1. 早期にモデル化する - 開発後ではなく、設計段階で行います
2. 定期的に更新する - アーキテクチャが変更されたときに更新します
3. リスクの高い脅威に注力する - 100％の網羅を目指す必要はありません
4. 緩和策を文書化する - 脅威だけでなく、緩和策も記録します

セキュリティ設計

1. 実績のあるソリューションを使用する - 暗号を独自に実装しないでください
2. 多層防御を行う - 複数のセキュリティ層を設けます
3. デフォルトでセキュアにする - セキュリティの低い設定はオプトインにし、オプトアウトにはしません
4. 侵害を前提とする - 「もし」ではなく「いつ」侵害されるかを前提に設計します

セキュアコーディング

1. セキュリティスキャンを自動化する - CI/CD に SAST、DAST、SCA を導入します
2. すべての入力を検証する - ユーザーからの入力を信頼しないでください
3. セキュリティライブラリを使用する - OWASP、helmet.js、DOMPurify
4. 依存関係を最新の状態に保つ - Dependabot で監視します

コンプライアンス

1. 適用範囲を把握する - どの規制が適用されるかを確認します
2. すべてを文書化する - ポリシー、手順、決定事項を記録します
3. 定期的に監査する - 内部および外部のレビューを実施します
4. 法務担当者と連携する - 規制を独自に解釈しないでください

---

よくある落とし穴

1. セキュリティを後回しにする

アンチパターン： まず構築し、後からセキュリティ対策を行う 結果： 後付けに費用がかかり、本番環境に脆弱性が残ります

改善策： 設計段階からセキュリティを組み込みます

2. クライアント側の検証を信頼する

アンチパターン： フロントエンドだけで検証する 結果： 攻撃者が curl で回避できます

改善策： 常にバックエンドで検証します

3. 暗号を独自に実装する

アンチパターン： 独自の暗号化またはハッシュ化を行う 結果： 暗号が弱くなり、脆弱性が生じます

改善策： 実績のあるライブラリ（bcrypt、libsodium）を使用します

4. コンプライアンスに過度に依存する

アンチパターン： 「コンプライアンスに準拠しているから、安全です」 結果： 準拠していても、安全とは限りません

改善策： コンプライアンスは最低基準です。セキュリティ対策は継続的に行います

5. リスクの低い脅威を無視する

アンチパターン： 重大な問題だけを修正する 結果： 小さな問題が積み重なり、大きな損害につながります

改善策： すべての重大度に対して体系的に対処します

---

関連スキル

• quality-assurance - セキュリティテストと検証ゲート
• api-designer - API セキュリティパターン
• deployment-advisor - インフラストラクチャのセキュリティ
• framework-orchestrator - フェーズゲートにおけるセキュリティ
• data-engineer - データセキュリティとプライバシー

---

成果物

Security Architect の使用時に、以下を作成します。

1. 脅威モデル

   • 資産インベントリ
   • 信頼境界
   • STRIDE 分析
   • リスク評価
   • 緩和計画

2. セキュリティアーキテクチャ文書

   • 認証／認可の設計
   • 暗号化戦略
   • シークレット管理
   • セキュリティ制御を含むネットワーク図

3. セキュアコードレビューレポート

   • OWASP Top 10 の指摘事項
   • 重大度の評価
   • 修正の推奨事項
   • 再テストの結果

4. コンプライアンスチェックリスト

   • 適用される規制
   • 実装状況
   • ギャップ分析
   • 修正計画

---

成功指標

以下を達成できている場合、Security Architect は効果的です。

• 開発前に脅威モデルが作成されている
• 本番環境の重大な脆弱性がゼロである
• セキュリティインシデントが年 1 件未満である
• コンプライアンス監査に合格している
• CI/CD でセキュリティゲートが適用されている
• チームがセキュアコーディングのプラクティスに従っている
• セキュリティ研修が定期的に実施されている

---

忘れないでください： セキュリティは機能ではなく、基盤です。最初から組み込んでください。