関連テンプレ構成
テンプレート
# セキュリティ仕様・方式
## 認証・認可方式
### 認証方式
**採用プロトコル:** 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時間以内に関係者へ報告
- 個人情報漏洩時は法令に従い監督官庁へ報告
--- プレビュー
セキュリティ仕様・方式
認証・認可方式
認証方式
採用プロトコル: OAuth 2.0 + OpenID Connect
認証フロー:
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 ペイロード例:
{
"sub": "user_12345",
"name": "山田太郎",
"email": "yamada@example.com",
"role": "admin",
"iat": 1700000000,
"exp": 1700003600
}
認可方式
ロールベースアクセス制御(RBAC):
| ロール | 権限 | 説明 |
|---|---|---|
| admin | すべての操作 | システム管理者 |
| editor | 読み取り、作成、更新 | コンテンツ編集者 |
| viewer | 読み取りのみ | 閲覧専用ユーザー |
| guest | 公開情報の閲覧のみ | 未認証ユーザー |
権限チェックフロー:
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)設定:
{
"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)の活用
- 入力値のバリデーションとエスケープ処理
// 良い例:プリペアドステートメント
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)
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アドレス、タイムスタンプ)
- 権限変更(変更者、対象ユーザー、変更内容)
- 機密データへのアクセス(アクセス者、対象データ、操作種別)
- システム設定変更(変更者、変更項目、変更前後の値)
ログフォーマット:
{
"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年間
- アクセス制限: 管理者のみ閲覧可能
セキュリティインシデント検知
検知項目:
- 短時間での大量のログイン失敗
- 異常な時間帯のアクセス
- 通常と異なる地域からのアクセス
- 大量のデータダウンロード
アラート通知:
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 パイプラインに脆弱性スキャンを組み込み
- デプロイ前の自動セキュリティチェック
インシデント対応
インシデント対応フロー
graph TD
A["インシデント検知"] --> B["初動対応&<br/>影響範囲の特定"]
B --> C["封じ込め<br/>被害拡大防止"]
C --> D["根絶<br/>脆弱性の修正"]
D --> E["復旧<br/>システム正常化"]
E --> F["事後対応<br/>報告・改善"]
連絡体制:
- セキュリティインシデント対応チーム(CSIRT)の設置
- エスカレーションフローの明確化
- 外部専門家との連携体制
報告要件:
- 重大インシデント発生時は24時間以内に関係者へ報告
- 個人情報漏洩時は法令に従い監督官庁へ報告