Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
セキュリティ仕様・方式
システムのセキュリティ要件を技術仕様へ落とし込み、認証・認可、通信保護、データ暗号化、脆弱性対策、監査ログ設計を通じて情報資産を守る実装指針を策定します。
🎯 概要
- 目的: システムのセキュリティ要件を具体的な技術仕様と実装方式に落とし込み、情報資産を保護し、セキュリティリスクを低減する
- スコープ: 認証・認可、通信セキュリティ、データ保護、脆弱性対策、監査ログ、コンプライアンス対応をカバーする。個別の実装コードレベルの詳細は対象外
- 推奨する実施タイミング: 通常、システムアーキテクチャ検討後、非機能要件の実現方式を検討するタイミングで実施する
- 関連するステークホルダー: セキュリティチーム、システムアーキテクト、プロジェクトマネージャー、インフラチーム、法務・コンプライアンス担当
📥 重要な前提知識・インプット
- 前提知識: セキュリティの基本原則(CIA:機密性・完全性・可用性)、認証・認可の仕組み、暗号化技術、OWASP Top 10、関連法規(個人情報保護法など)
- インプット: セキュリティ要件一覧、システムアーキテクチャ設計書、保護対象の情報資産一覧、コンプライアンス要件、既存システムのセキュリティ設計
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]セキュリティ仕様・方式
- 必須要素: 認証・認可方式、通信セキュリティ設定、データ保護方式(暗号化)、脆弱性対策一覧、監査ログ設計、セキュリティインシデント対応フロー
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 要件網羅性 | 全てのセキュリティ要件に対して実現方式が定義されている |
| 多層防御 | ネットワーク層、アプリケーション層、データ層で適切な対策が実施されている |
| 暗号化の適切性 | 機密データの保存時・通信時の暗号化が適切に設計されている |
| 脆弱性対策 | OWASP Top 10などの一般的な脆弱性への対策が実施されている |
| 監査証跡 | セキュリティイベントの記録と監視の仕組みが整備されている |
👁️🗨️ レビュー観点:
- 要件との整合性: セキュリティ要件が漏れなく実現方式に反映されているか
- 技術的妥当性: 選択したセキュリティ技術が業界標準に準拠し、適切か
- 実装可能性: チームのスキルで実装可能か、必要な技術習得は現実的か
- 運用負荷: セキュリティ運用(監視、インシデント対応、パッチ適用など)が現実的に実施可能か
- コンプライアンス: 関連法規(個人情報保護法など)への対応が適切か
🧪成果物のサンプル
# セキュリティ仕様・方式
## 認証・認可方式
### 認証方式
**採用プロトコル:** OAuth 2.0 + OpenID Connect
**認証フロー:**
```mermaid
sequenceDiagram
participant User as ユーザー
participant Client as クライアント
participant Auth as 認証サーバー
participant API as APIサーバー
User->>Client: ログイン要求
Client->>Auth: 認証リクエスト
Auth->>User: ログイン画面表示
User->>Auth: 認証情報入力
Auth->>Auth: 認証情報検証
Auth->>Client: 認可コード発行
Client->>Auth: トークン要求
Auth->>Client: アクセストークン + IDトークン
Client->>API: APIリクエスト(トークン付与)
API->>API: トークン検証
API->>Client: レスポンス
```
**トークン仕様:**
- **アクセストークン**: JWT形式、有効期限1時間
- **リフレッシュトークン**: 有効期限30日、HTTPOnly Cookie で保存
- **IDトークン**: ユーザー情報を含む JWT
**JWT ペイロード例:**
```json
{
"sub": "user_12345",
"name": "山田太郎",
"email": "yamada@example.com",
"role": "admin",
"iat": 1700000000,
"exp": 1700003600
}
```
### 認可方式
**ロールベースアクセス制御(RBAC):**
| ロール | 権限 | 説明 |
|--------|------|------|
| admin | すべての操作 | システム管理者 |
| editor | 読み取り、作成、更新 | コンテンツ編集者 |
| viewer | 読み取りのみ | 閲覧専用ユーザー |
| guest | 公開情報の閲覧のみ | 未認証ユーザー |
**権限チェックフロー:**
```mermaid
graph TD
A["APIリクエスト"] --> B{"トークン<br/>有効?"}
B -->|No| C["401 Unauthorized"]
B -->|Yes| D{"ロール<br/>確認"}
D --> E{"必要な権限<br/>あり?"}
E -->|No| F["403 Forbidden"]
E -->|Yes| G["処理実行"]
G --> H["200 OK"]
```
**実装方針:**
- API エンドポイントごとに必要な権限を定義
- ミドルウェアで自動的に権限チェック実施
- 権限不足時は適切なHTTPステータスコードを返却
---
## 通信セキュリティ
### TLS/SSL 設定
**プロトコルバージョン:**
- TLS 1.3 を優先使用
- TLS 1.2 を最低サポートバージョンとして許可
- TLS 1.1 以下は無効化
**暗号スイート:**
```
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
```
**証明書管理:**
- 証明書発行: Let's Encrypt または AWS Certificate Manager
- 自動更新設定により期限切れを防止
- ワイルドカード証明書の使用(*.example.com)
### API 通信セキュリティ
**HTTPS 強制:**
- すべての HTTP リクエストを HTTPS にリダイレクト
- HSTS(HTTP Strict Transport Security)ヘッダーの設定
**CORS(Cross-Origin Resource Sharing)設定:**
```javascript
{
"allowedOrigins": [
"https://example.com",
"https://app.example.com"
],
"allowedMethods": ["GET", "POST", "PUT", "DELETE"],
"allowedHeaders": ["Content-Type", "Authorization"],
"maxAge": 86400
}
```
---
## データ保護
### 保存時の暗号化
**データベース暗号化:**
- 暗号化方式: AES-256
- 暗号化範囲: データベース全体(Transparent Data Encryption)
- キー管理: AWS KMS(Key Management Service)
**ファイルストレージ暗号化:**
- S3 バケットのサーバーサイド暗号化(SSE-S3 または SSE-KMS)
- アップロード時に自動的に暗号化
**機密データの暗号化:**
| データ種別 | 暗号化方式 | 備考 |
|------------|------------|------|
| パスワード | bcrypt(コスト係数12) | ソルト付きハッシュ化 |
| クレジットカード情報 | AES-256-GCM | 外部決済サービス利用推奨 |
| 個人識別情報(PII) | AES-256-CBC | アプリケーション層で暗号化 |
| APIキー・シークレット | AES-256-GCM | 環境変数または AWS Secrets Manager |
### 通信時の暗号化
**内部通信:**
- サービス間通信も TLS で暗号化
- VPC 内の通信でもセキュリティグループで制限
**データマスキング:**
- ログ出力時に機密情報を自動マスキング
- マスキング対象: パスワード、トークン、クレジットカード番号、メールアドレス
---
## 脆弱性対策
### インジェクション対策
**SQL インジェクション:**
- プリペアドステートメントの使用を必須化
- ORM(Object-Relational Mapping)の活用
- 入力値のバリデーションとエスケープ処理
```javascript
// 良い例:プリペアドステートメント
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userEmail]);
// 悪い例:文字列結合(使用禁止)
const query = `SELECT * FROM users WHERE email = '${userEmail}'`;
```
**XSS(Cross-Site Scripting)対策:**
- 出力時の HTML エスケープ処理
- Content Security Policy(CSP)ヘッダーの設定
- HTTPOnly、Secure フラグ付き Cookie の使用
**CSP ヘッダー例:**
```
Content-Security-Policy:
default-src 'self';
script-src 'self' 'unsafe-inline' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
```
### CSRF(Cross-Site Request Forgery)対策
**実装方式:**
- CSRF トークンの生成と検証
- SameSite Cookie 属性の設定(SameSite=Strict)
- カスタムヘッダーの要求(X-Requested-With)
```mermaid
sequenceDiagram
participant User as ユーザー
participant Browser as ブラウザ
participant Server as サーバー
User->>Browser: ページ表示要求
Browser->>Server: GET /form
Server->>Server: CSRF トークン生成
Server->>Browser: フォーム + CSRF トークン
User->>Browser: フォーム送信
Browser->>Server: POST /submit (トークン付き)
Server->>Server: トークン検証
alt トークン有効
Server->>Browser: 処理成功
else トークン無効
Server->>Browser: 403 Forbidden
end
```
### その他のセキュリティ対策
**依存ライブラリの脆弱性管理:**
- 定期的な脆弱性スキャン(npm audit、Snyk)
- 脆弱性検知時の迅速なアップデート
- 自動化された依存関係更新(Dependabot)
**レート制限:**
- API エンドポイントごとのレート制限設定
- IP アドレスベースの制限(例: 1分間に100リクエスト)
- ログイン試行の制限(アカウントロック機能)
**セキュリティヘッダー:**
```
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
```
---
## 監査・ログ
### セキュリティ監査ログ
**記録対象:**
- 認証成功/失敗(ユーザーID、IPアドレス、タイムスタンプ)
- 権限変更(変更者、対象ユーザー、変更内容)
- 機密データへのアクセス(アクセス者、対象データ、操作種別)
- システム設定変更(変更者、変更項目、変更前後の値)
**ログフォーマット:**
```json
{
"timestamp": "2025-11-20T14:30:00Z",
"event_type": "authentication",
"user_id": "user_12345",
"ip_address": "192.168.1.100",
"action": "login_success",
"details": {
"method": "password",
"user_agent": "Mozilla/5.0..."
}
}
```
**保管要件:**
- 保存先: 改ざん防止機能付きストレージ(S3 Object Lock)
- 保持期間: 3年間
- アクセス制限: 管理者のみ閲覧可能
### セキュリティインシデント検知
**検知項目:**
- 短時間での大量のログイン失敗
- 異常な時間帯のアクセス
- 通常と異なる地域からのアクセス
- 大量のデータダウンロード
**アラート通知:**
```mermaid
graph LR
A["ログ収集"] --> B["異常検知<br/>AI/ルールベース"]
B --> C{"重要度判定"}
C -->|Critical| D["即時通知<br/>電話 + メール"]
C -->|High| E["メール通知"]
C -->|Medium| F["Slack 通知"]
C -->|Low| G["ダッシュボード<br/>記録のみ"]
```
---
## コンプライアンス
### 個人情報保護
**対応法規:**
- 個人情報保護法
- GDPR(該当する場合)
**実施事項:**
- プライバシーポリシーの明示
- 同意取得の記録
- データ削除要求への対応(Right to be Forgotten)
- データポータビリティ対応
### セキュリティ監査
**実施内容:**
- 年1回の外部セキュリティ監査
- 四半期ごとの脆弱性診断
- ペネトレーションテスト(年1回)
**監査項目:**
- アクセス制御の妥当性
- 暗号化の実装状況
- ログ管理の適切性
- インシデント対応体制
---
## セキュリティ開発ライフサイクル
### セキュアコーディング
**コーディング規約:**
- OWASP Top 10 への対応を必須化
- コードレビュー時のセキュリティチェック
- 静的コード解析ツールの導入(SonarQube、Checkmarx)
### セキュリティテスト
**テスト項目:**
- 認証・認可機能のテスト
- 入力値検証のテスト
- セッション管理のテスト
- エラーハンドリングのテスト
**自動化:**
- CI/CD パイプラインに脆弱性スキャンを組み込み
- デプロイ前の自動セキュリティチェック
---
## インシデント対応
### インシデント対応フロー
```mermaid
graph TD
A["インシデント検知"] --> B["初動対応&<br/>影響範囲の特定"]
B --> C["封じ込め<br/>被害拡大防止"]
C --> D["根絶<br/>脆弱性の修正"]
D --> E["復旧<br/>システム正常化"]
E --> F["事後対応<br/>報告・改善"]
```
**連絡体制:**
- セキュリティインシデント対応チーム(CSIRT)の設置
- エスカレーションフローの明確化
- 外部専門家との連携体制
**報告要件:**
- 重大インシデント発生時は24時間以内に関係者へ報告
- 個人情報漏洩時は法令に従い監督官庁へ報告
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: 認証・認可方式の設計
設計対象:
システムのユーザー認証と認可の仕組みを設計し、誰がどのリソースにアクセスできるかを制御する。
具体例:
- 認証方式(パスワード認証、多要素認証、SSO、OAuth/OpenID Connect)をどうするか
- 認可方式(ロールベースアクセス制御、属性ベースアクセス制御)をどうするか
- トークン管理(JWT、セッション、リフレッシュトークン)をどうするか
- シングルサインオン(SSO)を導入するか
- アカウントロック、パスワードポリシーをどう設定するか
設計原則:
- 多要素認証の検討: 重要なシステムでは、パスワードに加えてSMSやTOTPなどの多要素認証を導入する
- 最小権限の原則: ユーザーには必要最小限の権限のみを付与し、不要な権限は与えない
- トークンの適切な管理: JWTなどのトークンは有効期限を設定し、セキュアに保存する(HTTPOnly Cookie、Secure属性)
- 認証情報の安全な保管: パスワードは必ずハッシュ化(bcrypt、Argon2など)し、平文で保存しない
- SSOの活用: 複数システムを利用する場合、SSOを導入してユーザー体験を向上させる
文書化の推奨表現:
- 認証フロー図の作成: ログインから認証、トークン発行、APIアクセスまでのフローを図示する
- ロール・権限マトリクス: 各ロールがどのリソースにアクセスできるかを一覧表で明確にする
- トークン仕様の明記: JWT のペイロード、有効期限、保存方法を具体的に記載する
- パスワードポリシーの定義: 最小文字数、複雑性要件、有効期限、ロック条件を明確にする
🏗️ プロセス2: 通信セキュリティの設計
設計対象:
ネットワーク通信を暗号化し、盗聴や改ざんから保護する仕組みを設計する。
具体例:
- TLS/SSL のバージョン、暗号スイートをどうするか
- すべての通信をHTTPSで行うか
- 証明書の管理方法(Let's Encrypt、AWS Certificate Manager)をどうするか
- API通信のセキュリティ(CORS設定、セキュリティヘッダー)をどうするか
- 内部サービス間通信も暗号化するか
設計原則:
- TLS 1.3の使用: 可能な限り最新のTLS 1.3を使用し、TLS 1.1以下は無効化する
- 強力な暗号スイート: AES-256-GCMなどの強力な暗号スイートを優先的に使用する
- HTTPS 強制: すべてのHTTP通信をHTTPSにリダイレクトし、HSTS ヘッダーを設定する
- 証明書の自動更新: Let's Encrypt などを使用し、証明書の期限切れを防止する自動更新を設定する
- 内部通信も暗号化: マイクロサービス間など内部通信も可能な限りTLSで暗号化する
文書化の推奨表現:
- TLS設定の明記: 使用するTLSバージョン、暗号スイート、証明書の種類を具体的に記載する
- CORS設定の定義: 許可するオリジン、HTTPメソッド、ヘッダーを明確にする
- セキュリティヘッダー一覧: HSTS、CSP、X-Frame-Optionsなどのヘッダー設定を一覧化する
- 証明書管理手順: 証明書の発行、更新、失効の手順を文書化する
🏗️ プロセス3: データ保護方式の設計
設計対象:
データベース、ファイル、ログなどの機密データを暗号化し、不正アクセスから保護する。
具体例:
- データベースの暗号化(Transparent Data Encryption)をどうするか
- ファイルストレージの暗号化(S3 SSE、ディスク暗号化)をどうするか
- パスワード、個人情報、クレジットカード情報の暗号化方式をどうするか
- 暗号鍵の管理(AWS KMS、HashiCorp Vault)をどうするか
- ログ出力時の機密情報マスキングをどうするか
設計原則:
- 保存時の暗号化: データベースやファイルは保存時(at rest)に暗号化する
- 通信時の暗号化: データの送受信時(in transit)はTLS/SSLで暗号化する
- 適切な暗号化方式: パスワードはbcrypt、機密データはAES-256などの強力な暗号化を使用する
- 鍵管理の分離: 暗号鍵はアプリケーションコードとは別に管理し、KMSなどの専用サービスを使用する
- ログのマスキング: パスワード、トークン、クレジットカード番号などはログ出力時に自動マスキングする
文書化の推奨表現:
- 暗号化対象一覧: どのデータをどの暗号化方式で保護するかを表形式で整理する
- 鍵管理方式: 暗号鍵の生成、保存、ローテーション、廃棄の方法を明確にする
- マスキングルール: ログ出力時にマスキングする情報のパターンとルールを定義する
- 暗号化実装例: 具体的な暗号化・復号化のコード例を示す
🏗️ プロセス4: 脆弱性対策の設計
設計対象:
SQLインジェクション、XSS、CSRFなどの一般的な脆弱性への対策を設計する。
具体例:
- SQLインジェクション対策(プリペアドステートメント、ORM)をどうするか
- XSS対策(HTMLエスケープ、CSP)をどうするか
- CSRF対策(トークン検証、SameSite Cookie)をどうするか
- 依存ライブラリの脆弱性管理(npm audit、Snyk)をどうするか
- レート制限、アカウントロックをどう実装するか
設計原則:
- OWASP Top 10への対応: OWASP Top 10に記載された一般的な脆弱性への対策を必須化する
- 入力値検証: すべての外部入力に対してバリデーションとサニタイゼーションを実施する
- 出力エスケープ: HTMLやSQLに出力する際は適切にエスケープ処理を行う
- セキュアなライブラリ: 既知の脆弱性がない、信頼できるライブラリのみを使用する
- レート制限: API呼び出しやログイン試行に対してレート制限を設け、DoS攻撃を防ぐ
文書化の推奨表現:
- 脆弱性対策一覧: OWASP Top 10の各項目に対する具体的な対策方法を一覧化する
- コーディング規約: セキュアコーディングのルール(プリペアドステートメント必須など)を明記する
- ライブラリ管理方針: 脆弱性スキャンの頻度、アップデート基準を定義する
- レート制限設定: APIエンドポイントごとの制限値(例: 1分間に100リクエスト)を明記する
🏗️ プロセス5: 監査ログとインシデント対応の設計
設計対象:
セキュリティイベントを記録し、不正アクセスや異常動作を検知・対応する仕組みを設計する。
具体例:
- 監査ログに記録する項目(認証成功/失敗、権限変更、データアクセスなど)をどうするか
- ログの保存先、保存期間、アクセス制御をどうするか
- セキュリティインシデントの検知方法(大量ログイン失敗、異常なアクセスパターン)をどうするか
- インシデント発生時の対応フロー(検知→封じ込め→根絶→復旧→報告)をどうするか
- セキュリティインシデント対応チーム(CSIRT)の体制をどうするか
設計原則:
- 重要イベントの記録: 認証、認可、データアクセス、設定変更などのセキュリティイベントを漏れなく記録する
- 改ざん防止: ログは改ざん防止機能付きのストレージ(S3 Object Lockなど)に保存する
- 適切な保持期間: 法令要件や社内規定に従い、適切な期間ログを保持する
- リアルタイム検知: 異常なアクセスパターンをリアルタイムで検知し、アラートを発出する
- 迅速な対応: インシデント発生時は迅速に対応できるよう、事前に対応フローと体制を整備する
文書化の推奨表現:
- 監査ログ設計: 記録する項目、ログフォーマット、保存先、保持期間を明確にする
- インシデント検知ルール: どのようなパターンを異常と判定するか、検知ルールを定義する
- インシデント対応フロー: 検知から報告までの対応手順をフローチャートで図示する
- 連絡体制: インシデント発生時の連絡先、エスカレーションフローを明記する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: OWASP Top 10、『体系的に学ぶ 安全なWebアプリケーションの作り方』、『セキュア・バイ・デザイン』、NIST Cybersecurity Framework
- 関連する他のガイド: 非機能要件の実現方式ガイド、システムアーキテクチャ設計ガイド、運用設計ガイド
- ツール・テンプレート: OWASP ZAP、Burp Suite、セキュリティチェックリストテンプレート
テンプレートサイト: 📄テンプレート集