# 構成管理・セキュリティ・データ保全の運用設計

## 構成管理・デプロイ

- 「開発プロセス・規約」を参照

---

## セキュリティ運用

**参照先**
- システム方式設計「セキュリティ仕様・方式」を参照

### パスワード/APIキー管理・ローテーション

**管理方針**
| 対象 | 管理ツール | ローテーション周期 | 責任者 |
|------|-----------|------------------|--------|
| ユーザーパスワード | 認証基盤（Auth0 / Cognito） | 90日ごと | ユーザー本人 |
| 管理者パスワード | パスワードマネージャー（1Password） | 90日ごと | システム管理者 |
| APIキー | シークレット管理（AWS Secrets Manager） | 180日ごと | 開発チーム |
| DBパスワード | シークレット管理（AWS Secrets Manager） | 180日ごと | インフラチーム |
| 証明書 | 証明書管理（ACM / Let's Encrypt） | 自動更新 | インフラチーム |

**ローテーション手順**
```mermaid
graph TD
    A[ローテーション期限30日前] --> B[アラート通知]
    B --> C[新しいキー生成]
    C --> D[新キーを並行稼働]
    D --> E[全システムで新キー確認]
    E --> F{問題なし?}
    F -->|Yes| G[旧キー無効化]
    F -->|No| H[ロールバック]
    G --> I[ローテーション完了記録]
```

**パスワードポリシー**
- 最小文字数: 12文字以上
- 必須要素: 大文字、小文字、数字、記号の組み合わせ
- 過去5世代のパスワード再利用禁止
- 辞書攻撃対策: 一般的な単語の使用禁止

### 権限監査

**監査対象**
- ユーザーアカウントの権限設定
- 管理者権限の付与状況
- APIアクセス権限
- データベースアクセス権限
- クラウドリソースへのアクセス権限

**監査頻度・実施タイミング**
- 定期監査: 四半期ごと（年4回）
- 臨時監査: 組織変更・退職発生時
- 自動監査: 毎日の権限変更ログチェック

**監査チェックリスト**
- [ ] 退職者のアカウントが無効化されているか
- [ ] 過剰な権限が付与されていないか
- [ ] 長期間未使用のアカウントが存在しないか
- [ ] 共有アカウントが使用されていないか
- [ ] 最小権限の原則が守られているか
- [ ] 権限変更の承認記録が残っているか

**権限監査プロセス**
```mermaid
graph TD
    A[監査開始] --> B[現行権限情報取得]
    B --> C[組織情報との照合]
    C --> D[不整合検出]
    D --> E{問題あり?}
    E -->|Yes| F[是正依頼]
    E -->|No| G[監査完了報告]
    F --> H[是正確認]
    H --> G
```

### 脆弱性診断の周期

**診断種別と実施周期**
| 診断種別 | 対象 | 実施周期 | 実施主体 |
|---------|------|---------|---------|
| 自動脆弱性スキャン | アプリケーション | 日次 | CI/CDパイプライン |
| 依存ライブラリチェック | パッケージ依存関係 | 日次 | CI/CDパイプライン |
| 静的解析（SAST） | ソースコード | コミットごと | CI/CDパイプライン |
| 動的解析（DAST） | 稼働中アプリ | 週次 | セキュリティチーム |
| ペネトレーションテスト | システム全体 | 半期ごと | 外部ベンダー |
| インフラ診断 | クラウド設定 | 四半期ごと | インフラチーム |

**診断ツール**
- SAST: SonarQube / Veracode
- DAST: OWASP ZAP / Burp Suite
- 依存関係: Dependabot / Snyk
- インフラ: AWS Security Hub / Prisma Cloud

**脆弱性対応フロー**
```mermaid
graph TD
    A[脆弱性検出] --> B{深刻度判定}
    B -->|Critical| C[即時対応 24時間以内]
    B -->|High| D[優先対応 7日以内]
    B -->|Medium| E[計画対応 30日以内]
    B -->|Low| F[次回リリース時対応]
    C --> G[修正パッチ適用]
    D --> G
    E --> G
    F --> G
    G --> H[検証]
    H --> I[本番反映]
```

### セキュリティログ監査

**監査対象ログ**
- 認証ログ（成功・失敗）
- 権限変更ログ
- データアクセスログ（特に個人情報）
- システム設定変更ログ
- API呼び出しログ
- ファイルアクセスログ

**ログ保管期間**
- アプリケーションログ: 90日
- セキュリティログ: 1年
- 監査ログ: 7年（法令対応）

**監視・アラート条件**
| イベント | アラート条件 | 対応 |
|---------|------------|------|
| ログイン失敗 | 同一IPから5回連続失敗 | アカウントロック |
| 権限昇格 | 管理者権限の付与 | 承認フロー確認 |
| 大量データアクセス | 通常の10倍以上のアクセス | アクセス元調査 |
| 深夜アクセス | 営業時間外の管理画面アクセス | 担当者確認 |
| 設定変更 | 本番環境の設定変更 | 変更記録確認 |

**ログ監査フロー**
```mermaid
graph TD
    A[ログ収集] --> B[異常検知エンジン]
    B --> C{異常あり?}
    C -->|Yes| D[アラート発報]
    C -->|No| E[ログ保管]
    D --> F[セキュリティ担当者へ通知]
    F --> G[調査・分析]
    G --> H{インシデント?}
    H -->|Yes| I[インシデント対応]
    H -->|No| J[記録・経過観察]
```

---

## メンテナンス

### メンテナンスウィンドウ

**定期メンテナンス枠**
- 実施日時: 毎月第2水曜日 02:00～04:00（JST）
- 実施時間: 最大2時間
- 実施内容: OSパッチ適用、ミドルウェア更新、DB最適化

**臨時メンテナンス**
- 実施条件: 緊急セキュリティパッチ適用、重大障害対応
- 事前通知: 原則として3営業日前に通知
- 緊急時: 最短6時間前に通知

### メンテナンスモード

**メンテナンスモードの機能**
- サービス全体またはページ単位で停止可能
- 専用のメンテナンス画面を表示
- APIリクエストは503エラーを返却
- 管理者のみアクセス可能

**メンテナンスモード切替手順**
```mermaid
graph LR
    A[メンテナンス開始] --> B[ユーザー通知]
    B --> C[メンテナンスフラグON]
    C --> D[メンテナンス画面表示]
    D --> E[作業実施]
    E --> F[動作確認]
    F --> G[メンテナンスフラグOFF]
    G --> H[サービス再開通知]
```

### メンテ時のユーザー通知方法

**通知タイミング・手段**
| タイミング | 通知手段 | 内容 |
|-----------|---------|------|
| 2週間前 | システム内お知らせ | メンテナンス予告 |
| 1週間前 | メール | 詳細な実施内容・影響範囲 |
| 前日 | システム内バナー | リマインダー |
| 開始30分前 | システム内ポップアップ | 最終通知 |
| 開始時 | メンテナンス画面 | 実施中の案内 |
| 終了時 | システム内お知らせ | 完了報告 |

**通知テンプレート（例）**
```
【重要】システムメンテナンスのお知らせ

平素より当サービスをご利用いただき、ありがとうございます。

下記の日程でシステムメンテナンスを実施いたします。
メンテナンス中はサービスをご利用いただけません。

■ 日時
2025年12月15日（水）02:00～04:00（予定）

■ 対象サービス
すべてのサービス

■ 作業内容
システム基盤の更新作業

ご不便をおかけいたしますが、ご理解とご協力をお願いいたします。
```

### メンテ明けの確認作業手順

**動作確認チェックリスト**
- [ ] サービスへのアクセス可否
- [ ] ログイン機能
- [ ] 主要機能の動作確認
  - [ ] データ登録
  - [ ] データ更新
  - [ ] データ削除
  - [ ] 検索機能
  - [ ] ファイルアップロード
- [ ] 外部連携API
- [ ] バッチ処理の実行状況
- [ ] エラーログの確認
- [ ] パフォーマンス（応答時間）
- [ ] 監視アラートの確認

**確認手順フロー**
```mermaid
graph TD
    A[メンテナンス作業完了] --> B[ステージング環境確認]
    B --> C{正常?}
    C -->|No| D[問題調査・修正]
    D --> B
    C -->|Yes| E[本番環境リリース]
    E --> F[スモークテスト実施]
    F --> G{正常?}
    G -->|No| H[ロールバック判断]
    G -->|Yes| I[全機能確認]
    I --> J[監視確認 30分間]
    J --> K[サービス再開通知]
```

---

## データ保全

**参照先**
- 外部仕様設計「データ仕様」を参照

### データ異常の検知方法

**監視項目**
| 監視対象 | 検知条件 | アラート |
|---------|---------|---------|
| データ件数 | 前日比で10%以上の増減 | Slack通知 |
| NULL値 | 必須項目にNULL | Slack通知 |
| データ型 | 不正な型のデータ挿入 | エラーログ |
| 外部キー整合性 | 参照先レコード不在 | エラーログ |
| 重複データ | ユニーク制約違反 | エラーログ |
| データ範囲 | 異常値（例:年齢が200歳） | Slack通知 |

**定期チェックバッチ**
- 実施頻度: 日次（深夜バッチ）
- チェック内容:
  - データ整合性チェック（外部キー、制約）
  - 統計情報の異常値検出
  - 孤立レコードの検出
  - データ重複チェック

### データ修正手順

**修正フロー**
```mermaid
graph TD
    A[データ異常検知] --> B[影響範囲調査]
    B --> C[修正方針決定]
    C --> D[修正SQLレビュー]
    D --> E[ステージング環境でテスト]
    E --> F{正常?}
    F -->|No| G[SQL修正]
    G --> D
    F -->|Yes| H[本番環境で実行]
    H --> I[実行結果確認]
    I --> J[監査ログ記録]
```

**修正作業の承認フロー**
| データ種別 | 承認者 | 実行者 |
|-----------|--------|--------|
| マスタデータ | システム管理者 | DBA |
| トランザクションデータ | 部門長 + システム管理者 | DBA |
| 個人情報 | 情報セキュリティ責任者 | DBA |

**SQL実行ルール**
- 本番環境での直接SQL実行は原則禁止
- やむを得ない場合は、必ずトランザクション管理
- 実行前に必ずバックアップ取得
- 実行後は必ず結果確認とログ記録

### 個人情報の取り扱い

**取り扱いルール**
- 個人情報へのアクセスは必要最小限
- アクセスログは全件記録
- 個人情報の出力は暗号化必須
- 個人情報を含むファイルの送付は禁止（必要時は専用ツール使用）

**個人情報アクセス権限**
```mermaid
graph TD
    A[アクセス申請] --> B[上長承認]
    B --> C[セキュリティ担当者承認]
    C --> D[期限付き権限付与]
    D --> E[アクセスログ記録]
    E --> F[作業完了]
    F --> G[権限自動失効]
```

**データマスキング**
- 開発環境・テスト環境では個人情報をマスキング
- マスキング対象: 氏名、メールアドレス、電話番号、住所
- マスキング方式: 擬似データ生成またはハッシュ化

---

## 運用ツール

### 監視ツール

**採用ツール**
| ツール | 用途 | 監視対象 |
|--------|------|---------|
| AWS CloudWatch | インフラ監視 | EC2, RDS, Lambda |
| Datadog | APM・ログ監視 | アプリケーション性能 |
| Zabbix | サーバー監視 | オンプレサーバー |

**アラート通知先**
- Critical: PagerDuty → 当番担当者へ電話通知
- High: Slack #alert チャンネル
- Medium: Slack #monitoring チャンネル
- Low: ダッシュボード表示のみ

### チケット管理

**採用ツール**
- JIRA: 開発タスク、バグ管理
- ServiceNow: インシデント管理、変更管理

**チケット起票ルール**
- 障害対応: すべてインシデントチケット起票
- 機能追加・改善: JIRAでストーリー作成
- 定常作業: タスクテンプレートから起票

### バックアップツール

**バックアップ方式**
- DB: AWS Backup / RDS自動バックアップ
- ファイル: S3バックアップ + Glacier
- 設定ファイル: Git管理

### 運用端末・運用アカウントの管理方法

**運用端末の管理**
- 運用専用端末を用意（個人PCからの本番アクセス禁止）
- セキュリティ対策: フルディスク暗号化、ウイルス対策
- アクセス制御: VPNまたは踏み台サーバー経由

**運用アカウントの管理**
- 個人アカウントと運用アカウントを分離
- 運用アカウントは多要素認証必須
- 共有アカウント禁止（個人を特定可能なアカウントのみ）
- アカウント棚卸し: 四半期ごと