移行関連の監査・セキュリティ対策

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

移行関連の監査・セキュリティ対策

システム移行におけるセキュリティリスクを最小化し、監査要件を満たすための具体的な対策とプロセスを定義します。

🎯 概要


  • 目的: システム移行に伴う情報漏えい・誤操作・権限乱用を防止し、監査要件(内部統制・ISMS・顧客監査など)を満たすためのセキュリティ・監査対策を明確にする
  • スコープ: 移行作業におけるアクセス管理、データ取り扱いルール、操作ログ取得、監査証跡の管理方法をカバーする。開発環境でのセキュリティ対策は対象外
  • 推奨する実施タイミング: 移行計画策定時、移行手順書作成前に実施する
  • 関連するステークホルダー: プロジェクトマネージャー、セキュリティ担当者、監査担当者、システム管理者、顧客担当者

📥 重要な前提知識・インプット


  • 前提知識: 情報セキュリティポリシー、ISMS・Pマーク等の認証要件、内部統制(J-SOX)、アクセス管理の基本原則
  • インプット: 組織の情報セキュリティポリシー、秘密保持契約(NDA)、監査要件(内部統制・ISMS)、移行計画書、本番環境のアクセス制御ルール

📄 成果物の定義


✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
要件の網羅性 適用すべきセキュリティ・監査要件がすべて特定されているか
アクセス管理の妥当性 最小権限の原則に基づき、必要な権限のみが付与されているか
証跡の十分性 監査に必要な証跡がすべて取得・保管される設計になっているか
職務分掌の適切性 作業者と承認者が分離され、内部不正を防止できるか

👁️‍🗨️ レビュー観点:

  • 法令・規格準拠性: 情報セキュリティポリシー、ISMS、内部統制などの要件が満たされているか
  • 実効性: 定義したルールが実際の移行作業で遵守可能か、現実的な運用かどうか
  • 監査対応力: 監査時に必要な証跡が適切に提示できる設計になっているか
  • インシデント対応: セキュリティインシデント発生時の対応フローが明確か
🧪成果物のサンプル
# 移行関連の監査・セキュリティ対策

## セキュリティ・監査の目的

移行作業におけるセキュリティ・監査対策の目的は以下の通りである。

- 移行作業に伴う情報漏えい・誤操作・権限乱用を防止する
- 監査要件(内部統制・ISMS・顧客監査など)を満たすため
- 本番データ・個人情報を扱う作業に関して責任範囲を明確化する

---

## 適用されるセキュリティ・監査要件の整理

移行作業に適用すべき基準・ルールを以下に記載する。

**適用要件:**
- 情報セキュリティポリシー: [組織の情報セキュリティポリシー名]
- 双方の契約条件: 秘密保持契約、アクセス制御、データ取り扱い規定
- ISMSPマーク等のルール: [適用される認証規格]
- 顧客の内部統制: J-SOX、内部監査要件
- 監査ログ取得要件: [監査基準に基づくログ保管要件]

※すべて詳細に書く必要はなく「何が適用対象か」を明示するレベルでよい。

**記載例:**
```
本プロジェクトでは、以下のセキュリティ・監査要件を適用する。
- 情報セキュリティポリシー: 株式会社○○ 情報セキュリティポリシー v2.0
- 秘密保持契約: 2025年4月締結のNDA
- ISMS認証: ISO27001:2013(認証番号:ISMS-12345)
- 内部統制: J-SOX対応として、アクセスログ3年間保管
- 監査ログ: 全ての本番環境操作ログを記録・保管
```

---

## 移行作業に関するアクセス管理

### アクセス権限の管理方針

移行作業における本番環境・本番データへのアクセスは、以下の方針で管理する。

**アクセス許可対象者:**

| 役割 | アクセス範囲 | 権限レベル | 承認者 |
|------|------------|-----------|--------|
| プロジェクトマネージャー | 本番環境(参照のみ) | 読み取り | 事業責任者 |
| システム管理者 | 本番環境(全権限) | 読み書き・設定変更 | PM・顧客担当者 |
| データ移行担当者 | 本番DB(移行作業時のみ) | データ投入・更新 | PM・システム管理者 |
| 開発者 | 本番環境アクセス不可 | - | - |

**アクセス権限の付与・削除:**
- 権限付与: 作業開始7営業日前までに申請、承認プロセスを経て付与
- 一時権限: 移行作業当日のみ有効、作業終了後24時間以内に削除
- 権限削除: 移行作業完了後、速やかに(原則48時間以内)削除
- 記録: すべての権限変更履歴を監査ログとして保管

**作業中の権限エスカレーション:**
- 原則として、作業中の追加権限付与は禁止
- やむを得ない場合は、PM承認+顧客立会いの下でのみ実施
- エスカレーション理由と実施内容を記録

**立会者の要否:**
- 本番データの投入・変更作業: 顧客担当者の立会い必須
- システム設定変更作業: PM立会い必須
- 参照のみの作業: 立会い不要(ログ記録は必須)

---

## データ取り扱いルール

移行期間中に扱うデータ(本番データ・バックアップ・抽出データ)に関する取り扱いルールを以下に定める。

### データ持ち出しルール

**原則:**
- 本番データの持ち出しは原則禁止
- 作業は指定された作業環境内でのみ実施

**例外ケース:**
- リモート作業が必要な場合: VPN接続+暗号化通信のみ許可
- テストデータ作成: 個人情報をマスキング後、PM承認を得た場合のみ可

### データ保存・管理

**一時ファイルの取り扱い:**
- 保存場所: プロジェクト専用の暗号化ストレージ
- 暗号化: AES-256以上の暗号化を必須
- アクセス制御: 作業担当者のみアクセス可能
- 命名規則: `[日付]_[作業名]_[担当者]_[バージョン].ext`

**データコピー・抽出の制限:**
- データ抽出: PM承認が必要、抽出理由・範囲を記録
- コピー回数: 必要最小限に制限、コピー先・用途を台帳管理
- 二次利用禁止: 移行作業以外の目的での使用を禁止
- 個人端末禁止: 作業者個人のPC・スマートフォンでの取り扱い厳禁

### 作業後のデータ削除ルール

**削除対象:**
- 一時的に作成したデータファイル
- 作業用のバックアップデータ
- テスト用に抽出したデータ

**削除タイミング:**
- 移行完了後1週間以内に削除(承認が得られ次第)
- 監査証跡として必要なログは保管(削除対象外)

**削除方法:**
- 物理削除: 上書き削除ツールを使用
- 削除証明: 削除完了報告書を作成、PM承認

**記載例:**
```
移行作業で使用した以下のデータは、2025年7月15日までに削除する。
- 旧システムから抽出したCSVファイル(顧客マスタ)
- 移行用の中間データ(staging環境)
- テストデータ(個人情報マスキング済み)

削除は、SecureDelete v3.2 を使用し、3回上書き方式で実施。
削除完了後、システム管理者が削除完了報告書を作成し、PMが確認する。
```

---

## 作業手順に対するセキュリティ確保策

### 操作ログ取得

**ログ取得対象:**
- 本番環境へのすべてのアクセス(ログイン・ログアウト)
- データベース操作(SELECT/INSERT/UPDATE/DELETE- システム設定変更
- ファイル操作(アップロード・ダウンロード・削除)

**ログ取得方法:**
- サーバーログ: syslog、アプリケーションログ
- コマンドログ: bash履歴、PowerShellログ
- 画面録画: 重要作業時はセッション録画を実施

### 権限分離による内部不正防止

```mermaid
graph LR
    A[作業者] -->|作業実施| B[作業内容]
    C[承認者] -->|事前承認| B
    D[監視者] -->|ログ確認| B
    E[PM] -->|最終承認| B
    
    style A fill:#e1f5ff
    style C fill:#fff4e1
    style D fill:#ffe1e1
    style E fill:#e1ffe1
```

**権限分離の原則:**
- 作業者と承認者を分離: 同一人物が実施・承認を兼ねない
- 二者確認: 重要な作業は必ず2名以上で実施
- 職務分掌: データ投入者とデータ検証者を分離

### 手順書の事前レビュー

**レビュープロセス:**
1. 作業担当者が手順書を作成
2. セキュリティ担当者がセキュリティ観点でレビュー
3. PMが全体承認
4. 顧客担当者が最終確認

**セキュリティレビュー観点:**
- 不要な権限を要求していないか
- データ持ち出しが発生していないか
- ロールバック手順が明確か
- エラー時の対応が適切か

### 重大作業のダブルチェック体制

**ダブルチェック対象作業:**
- 本番データの削除
- 本番データベースのスキーマ変更
- 本番システムの設定変更
- バックアップからのリストア

**ダブルチェック方法:**
- 作業者: 手順に従い作業を実施
- チェッカー: 作業内容を確認、結果を検証
- 両者が作業記録にサイン(電子署名)

---

## 監査証跡(Evidence)の取得・保管

### 証跡として残すべき項目

何を証跡として残すか、あらかじめ整理する。

**取得する証跡:**

| 証跡種別 | 内容 | 保管形式 | 保管期間 |
|---------|------|---------|---------|
| 移行作業ログ | サーバー操作ログ、DBクエリログ | テキスト/CSV | 3|
| データ移行結果 | 移行前後のレコード件数、整合性チェック結果 | Excel/PDF | 3|
| スクリーンショット | 主要作業の実施画面キャプチャ | PNG/PDF | 1|
| 承認記録 | メール、ワークフロー承認履歴 | PDF | 3|
| ロールバック記録 | 切り戻し手順の実行ログ | テキスト/PDF | 3|
| セキュリティチェック | 脆弱性スキャン結果、権限監査結果 | PDF | 3|

**記載例:**
```
【証跡取得例】
■ 移行作業ログ
- ファイル名: migration_log_20250630_01.txt
- 内容: 2025年6月30日実施の顧客マスタ移行作業のサーバーログ
- 保管場所: /audit/2025/migration/
- アクセス制限: PM、監査担当者のみ

■ データ移行結果
- ファイル名: migration_result_customer_20250630.xlsx
- 内容: 移行前10,523件 → 移行後10,523件(一致確認済み)
- 保管場所: SharePoint > 監査証跡フォルダ
- アクセス制限: プロジェクトメンバー全員

■ 承認記録
- 件名: 【承認依頼】本番移行実施承認(顧客マスタ)
- 承認者: 事業責任者 山田太郎
- 承認日時: 2025年6月29日 15:30
- 保管場所: ワークフローシステム(承認ID: WF-2025-0629-001)
```

### 保管場所・アクセス制限

**保管場所:**
- プロジェクト専用の監査証跡フォルダ(暗号化ストレージ)
- バックアップは別ロケーションに自動保存

**アクセス制限:**
- 参照権限: PM、監査担当者、顧客担当者
- 編集権限: なし(読み取り専用)
- 削除権限: システム管理者のみ(PM承認必要)

---

## 監査対応の体制

### 監査窓口

**顧客側窓口:**
- 担当部署: [部署名]
- 担当者: [氏名]
- 連絡先: [メールアドレス・電話番号]

**ベンダー側窓口:**
- 担当部署: [部署名]
- 担当者: PM [氏名]
- 連絡先: [メールアドレス・電話番号]

### 監査時に提示できる資料

- 移行計画書
- 移行手順書
- 作業実施記録(ログ、スクリーンショット)
- 承認記録
- セキュリティチェック結果
- インシデント報告書(発生時)

### 本番作業後の報告書作成

**報告書作成責任者:**
- 作成: 移行作業リーダー
- レビュー: PM
- 承認: 事業責任者

**報告書に含める内容:**
- 作業実施日時・担当者
- 作業内容・結果
- 発生した問題と対処
- セキュリティインシデントの有無
- 監査証跡の保管場所

### 外部監査対応

**想定される監査:**
- 顧客監査:1回程度
- 内部監査: 半期ごと
- 外部監査法人: 年次決算時

**監査対応方法:**
1. 監査通知を受領(監査実施の2週間前)
2. 必要資料を準備(監査窓口が一元管理)
3. 監査当日: 監査窓口が対応、必要に応じてPM・担当者が同席
4. 監査指摘事項への対応計画を作成(1週間以内)
5. 改善実施・完了報告

---

## 監査・セキュリティ上のリスクと対策方針

基本設計段階では、詳細までは不要で、以下のレベルで十分。

### リスクと対策の整理

| リスク | 対策方針 | 実施内容 |
|--------|---------|---------|
| 本番データの漏えい | 暗号化/操作ログ取得 | データ暗号化(AES-256)、全操作ログ記録 |
| 権限乱用 | 一時権限付与+立会 | 作業時のみ権限付与、顧客立会い必須 |
| 手順の逸脱 | 事前レビュー+当日のログ監視 | 手順書の多段階レビュー、リアルタイムログ監視 |
| 作業証跡不足 | 作業ログ・承認記録を必須化 | すべての作業で証跡取得を義務化 |
| 不正アクセス | 多要素認証・IP制限 | MFA必須、アクセス元IPをホワイトリスト化 |
| データ破損・削除 | バックアップ+ロールバック手順 | 作業前バックアップ必須、切り戻し手順の準備 |

### セキュリティインシデント発生時の対応

```mermaid
graph TD
    A[インシデント発生] --> B{重大度判定}
    B -->|高| C[即時作業停止]
    B -->|中| D[影響範囲確認]
    B -->|低| E[記録して作業継続]
    
    C --> F[PM・顧客へ緊急連絡]
    D --> F
    
    F --> G[原因調査]
    G --> H[対策実施]
    H --> I[再発防止策]
    I --> J[インシデント報告書作成]
```

**インシデント対応フロー:**
1. インシデント検知・発生報告
2. 重大度判定(高//低)
3. 必要に応じて作業停止
4. PM・顧客担当者へ連絡
5. 原因調査・影響範囲特定
6. 対策実施
7. インシデント報告書作成
8. 再発防止策の検討・実施

---

## 移行作業におけるセキュリティチェックリスト

移行作業前・作業中・作業後に実施するセキュリティチェック項目を以下に示す。

### 作業前チェック

- [ ] 作業担当者の本人確認完了
- [ ] 必要な権限が正しく付与されている
- [ ] 作業手順書がレビュー・承認済み
- [ ] バックアップが取得されている
- [ ] ロールバック手順が準備されている
- [ ] 監査証跡の取得方法が確認されている
- [ ] 立会者が配置されている(必要な場合)

### 作業中チェック

- [ ] 操作ログが正しく記録されている
- [ ] 手順書通りに作業が進行している
- [ ] 異常が発生していない
- [ ] データの整合性が保たれている
- [ ] 不要な権限使用が発生していない

### 作業後チェック

- [ ] すべての作業が完了している
- [ ] データ移行結果が検証されている
- [ ] 一時権限が削除されている
- [ ] 作業ログが保管されている
- [ ] 作業報告書が作成されている
- [ ] 一時ファイルが削除されている
- [ ] セキュリティインシデントが発生していない

---

🔄 設計の進め方・プロセス


🏗️ プロセス1: 適用されるセキュリティ・監査要件の整理

設計対象:

移行作業に適用すべきセキュリティ・監査の基準とルールを特定し、整理する。

具体例:

  • 組織の情報セキュリティポリシー
  • 秘密保持契約(NDA)における取り扱い規定
  • ISMS・Pマーク等の認証要件
  • 内部統制(J-SOX)における統制要件
  • 顧客の監査要件

設計原則:

  • 要件の網羅性: すべての適用要件を漏れなく特定し、文書化する
  • 優先度の明確化: 法令要件、契約要件、社内規定の優先順位を明確にする
  • 実効性の確保: 形骸化しないよう、実際に遵守可能な要件として整理する

文書化の推奨表現:

  • 適用要件一覧: 適用されるポリシー・規格・契約を一覧化し、参照先を明記する
  • 要件の具体化: 各要件が移行作業にどう影響するかを具体的に記載する
🏗️ プロセス2: アクセス権限管理方針の策定

設計対象:

本番環境・本番データへのアクセス権限の付与・管理方法を定義する。

具体例:

  • どの役割(PM、システム管理者、開発者など)に、どのアクセス権限を付与するか
  • 権限付与・削除のタイミングと承認フロー
  • 一時権限の扱い(作業当日のみ有効など)
  • 立会者の要否

設計原則:

  • 最小権限の原則: 作業に必要な最小限の権限のみを付与する
  • 職務分掌: 作業者と承認者を分離し、内部不正を防止する
  • 時限性の確保: 一時的な権限は作業終了後速やかに削除する

文書化の推奨表現:

  • 権限マトリクス: 役割ごとのアクセス範囲と権限レベルを表で整理する
  • 承認フロー図: 権限付与・削除の承認プロセスを図示する
  • 立会ルール: どの作業に立会者が必要かを明記する
🏗️ プロセス3: データ取り扱いルールの定義

設計対象:

本番データ・個人情報の取り扱い方法を定義する。

具体例:

  • データ持ち出しの可否と条件
  • 一時ファイルの保存場所・暗号化方式
  • データコピー・抽出の制限
  • 作業後のデータ削除ルール

設計原則:

  • データ最小化: 必要最小限のデータのみを扱う
  • 暗号化の徹底: 一時ファイルは必ず暗号化する
  • 追跡可能性: データの移動・コピーをすべて記録する

文書化の推奨表現:

  • 取り扱いルール一覧: 持ち出し、保存、削除の各ルールを箇条書きで整理する
  • 暗号化基準: 使用する暗号化方式(AES-256など)を明記する
  • 削除手順: データ削除の方法とタイミングを具体的に記載する
🏗️ プロセス4: 監査証跡の取得・保管方針の策定

設計対象:

監査に必要な証跡の種類、取得方法、保管場所を定義する。

具体例:

  • 操作ログ(サーバーログ、DBクエリログ)
  • 作業記録(スクリーンショット、作業報告書)
  • 承認記録(メール、ワークフロー)
  • セキュリティチェック結果

設計原則:

  • 証跡の十分性: 監査要件を満たすために必要な証跡をすべて取得する
  • 改ざん防止: 証跡を読み取り専用で保管し、改ざんを防止する
  • 保管期間の遵守: 法令・規格で定められた保管期間を守る

文書化の推奨表現:

  • 証跡一覧表: 証跡の種別、内容、保管形式、保管期間を表で整理する
  • アクセス制御: 証跡の参照・編集・削除権限を明記する
🏗️ プロセス5: セキュリティチェックリストの作成

設計対象:

移行作業前・作業中・作業後に実施するセキュリティチェック項目を定義する。

具体例:

  • 作業前: 権限付与の確認、バックアップ取得の確認
  • 作業中: 手順書の遵守確認、異常の有無確認
  • 作業後: 一時権限の削除確認、証跡の保管確認

設計原則:

  • 抜け漏れ防止: チェックリスト形式で確実に実施する
  • 記録の徹底: すべてのチェック結果を記録する

文書化の推奨表現:

  • チェックリスト: 作業前・中・後の各チェック項目をチェックボックス形式で記載する

🚨 よくある失敗と予防策 


🚧 実例収集後、追記予定

📚 参考資料・関連リンク


  • 参考文献: ISO/IEC 27001(情報セキュリティマネジメントシステム)、J-SOX(内部統制)ガイドライン
  • 関連する他のガイド: データ移行設計ガイド、運用設計ガイド、リリース計画ガイド
  • ツール・テンプレート: 監査証跡管理表テンプレート、セキュリティチェックリストテンプレート


テンプレートサイト: 📄Arrow icon of a page linkテンプレート集