[テンプレ]インフラ システム環境・エコロジー設計書

関連テンプレ構成
テンプレート
# システム環境・エコロジー(System Environment & Ecology)

## システム環境・エコロジーの基本方針

システムが稼働する環境に関する制約、特性、および環境負荷への配慮を明確にし、持続可能で効率的なインフラ運用を実現するための戦略を以下に示す。

### 環境制約・前提条件方針
- **法令・規制遵守**: 適用される全ての法令、業界ガイドライン、社内規程を遵守したインフラ構築・運用を行う
- **既存環境との整合性**: 既存のインフラ環境や運用プロセスとの整合性を確保し、スムーズな導入・運用を目指す

### システム特性への対応方針
- **地域分散と冗長性**: ユーザーの地域的広がりや拠点数に応じて、適切な地域分散と冗長構成を設計
- **特定の製品・技術への対応**: ユーザー指定の製品や技術がある場合は、その特性を理解し、サポート体制や互換性を考慮したインフラ設計を行う

### 適合規格への対応方針
- **製品安全・環境規格の確認**: 使用するハードウェアやミドルウェアが、必要な製品安全規格や環境保護規格に適合していることを確認
- **クラウドプロバイダーの認証活用**: クラウドサービスを利用する場合は、クラウドプロバイダーが取得している各種認証(ISO27001SOCなど)を活用し、要件を満たす

### 機材設置環境条件方針
- **データセンター選定基準**: 物理的な設置環境が必要な場合は、耐震性、セキュリティ、電源供給などの条件を満たすデータセンターを選定
- **リソース効率化**: 仮想化技術やクラウドサービスを最大限活用し、物理リソースの利用効率を高め、省電力化を推進

---

## システム環境・エコロジー要件の実現方式

### F1. システム制約/前提条件 (System Constraints/Prerequisites)

#### F1.1 構築時の制約条件 (Construction Constraints)

##### F1.1.1 構築時の制約条件
- **要件**: 以下の社内基準、法令、ガイドラインに準拠したインフラ構築を行うこと
  - 社内情報セキュリティポリシー
  - ISO/IEC 27001 (ISMS) 認証取得
  - クラウドセキュリティガイドライン (NIST SP 800-145)
  - 特定の地域(例: EU)におけるデータ主権要件
- **実現方式・仕様**:
  - クラウド環境のリージョン選定は、データ主権要件を満たす地域(例: 日本国内)に限定
  - IaC(Infrastructure as Code)で定義されたインフラ構成は、社内セキュリティポリシーに準拠していることを自動チェック
  - 構築作業は、ISO/IEC 27001に準拠した変更管理プロセスを経て実施

#### F1.2 運用時の制約条件 (Operational Constraints)

##### F1.2.1 運用時の制約条件
- **要件**: 以下の社内基準、法令、ガイドラインを遵守した運用を行うこと
  - J-SOX法におけるIT統制要件
  - 個人情報保護法
  - リモートからの運用は、社内セキュリティポリシーで許可された範囲に限定
- **実現方式・仕様**:
  - 運用担当者のアクセス権限は最小限に制限し、J-SOX法に準拠したアクセスログを記録
  - 個人情報を含むデータの取り扱いは、暗号化、アクセス制御、監査ログ取得を徹底
  - リモート運用は、VPN接続と多要素認証を必須とし、許可されたIPアドレスからのみアクセス可能とする

### F2. システム特性 (System Characteristics)

#### F2.1 ユーザー数 (Number of Users)

##### F2.1.1 ユーザー数
- **要件**: 最大アクティブユーザー数 50,000- **実現方式・仕様**:
  - 認証基盤として、50,000ユーザー規模に対応可能なIDaaS(Identity as a Service)を選定
  - ロードバランサー、Web/APサーバーは、このユーザー数に対応できるキャパシティプランニングに基づき設計

#### F2.2 クライアント数 (Number of Clients)

##### F2.2.1 クライアント数
- **要件**: 最大同時接続クライアント数 15,000
- **実現方式・仕様**:
  - ロードバランサーの最大同時接続数を15,000以上で設定
  - データベースのコネクションプール設定は、最大同時接続数に対応できるよう最適化

#### F2.3 拠点数 (Number of Sites)

##### F2.3.1 拠点数
- **要件**: 国内3拠点(東京、大阪、福岡)からのアクセスに対応
- **実現方式・仕様**:
  - クラウドの複数アベイラビリティゾーン(AZ)または複数リージョン(例: 東京リージョン、大阪リージョン)にシステムを分散配置
  - 各拠点からのアクセスは、CDNDNSルーティングにより最適なサーバーに誘導

#### F2.4 地域的広がり (Geographical Scope)

##### F2.4.1 地域的広がり
- **要件**: 国内全域からのアクセスに対応し、海外からのアクセスは制限する
- **実現方式・仕様**:
  - WAFやファイアウォールを用いて、海外からのアクセスをIPアドレスベースで制限
  - CDNのエッジロケーションは国内に限定し、国内ユーザーへの高速なコンテンツ配信を優先

#### F2.5 特定製品指定 (Specific Product Designation)

##### F2.5.1 特定製品の採用有無
- **要件**: データベースにはPostgreSQL、メッセージキューにはApache Kafkaを使用すること
- **実現方式・仕様**:
  - データベースは、クラウドプロバイダーが提供するマネージドPostgreSQLサービス(例: AWS RDS for PostgreSQL)を利用
  - メッセージキューは、クラウドプロバイダーが提供するマネージドKafkaサービス(例: Amazon MSK)または自社で管理するApache Kafkaクラスタを構築
  - これらの製品のサポート体制、バージョンアップ計画、セキュリティパッチ適用方法を事前に確認し、運用計画に組み込む

### F3. 適合規格 (Applicable Standards)

#### F3.1 製品安全規格 (Product Safety Standards)

##### F3.1.1 規格取得の有無
- **要件**: 使用する全てのハードウェア(物理サーバー、ネットワーク機器)は、UL60950または同等の製品安全規格を取得していること
- **実現方式・仕様**:
  - データセンター提供の物理機器については、データセンター事業者が取得している安全規格の証明書を確認
  - クラウドサービス利用の場合、クラウドプロバイダーが準拠しているデータセンターの安全基準を確認(例: SOC 2 Type IIレポート)

#### F3.2 環境保護 (Environmental Protection)

##### F3.2.1 規格取得の有無
- **要件**: 使用する全てのハードウェアは、RoHS指令に準拠していること
- **実現方式・仕様**:
  - データセンター提供の物理機器については、データセンター事業者が調達する機器のRoHS指令準拠を確認
  - クラウドサービス利用の場合、クラウドプロバイダーの環境保護に関するポリシーやレポート(例: サステナビリティレポート)を確認

### F4. 機材設置環境条件 (Equipment Installation Environment Conditions)

#### F4.1 耐震/免震 (Earthquake Resistance/Isolation)

##### F4.1.1 耐震震度
- **要件**: 物理的な設置場所は、実効震度6強に耐えうる耐震構造であること
- **実現方式・仕様**:
  - システムを設置するデータセンターは、耐震構造(例: 免震構造)を有し、震度6強以上の地震に耐えられる施設を選定
  - ラックマウント機器は、耐震ラックに固定し、転倒防止対策を徹底

#### F4.2 スペース (Space)

##### F4.2.1 設置スペース制限(マシンルーム)
- **要件**: マシンルームへの設置は、最大10ラック(W600mm x D1000mm)に収まること
- **実現方式・仕様**:
  - 物理サーバー、ネットワーク機器の選定は、高密度実装が可能なモデルを優先
  - 将来的な拡張を考慮し、初期段階では7ラックに収め、3ラック分の予備スペースを確保

##### F4.2.2 設置スペース制限(事務所設置)
- **要件**: 事務所内へのサーバー設置は行わないこと
- **実現方式・仕様**:
  - 全てのシステムコンポーネントは、データセンターまたはクラウド環境に配置
  - 開発・テスト用の機器も、仮想環境またはクラウドサービスを利用し、物理的な事務所設置を回避

---

## テスト計画(システム環境・エコロジー関連)

### 環境適合性確認
- **実施時期**: 構築フェーズ初期、および環境変更時
- **テスト項目**:
  - 選択したクラウドリージョンがデータ主権要件を満たしているか
  - ファイアウォール設定が地域的アクセス制限要件を満たしているか
  - 特定製品(PostgreSQL, Kafka)が指定バージョンで正しく動作するか
- **合格基準**: 全ての環境制約・前提条件が満たされていること

### 物理環境監査(オンプレミスの場合)
- **実施時期**: データセンター選定時、および定期監査(年1回)
- **テスト項目**:
  - データセンターの耐震構造、電源供給、空調設備が要件を満たしているか
  - 設置スペースが計画通り確保されているか
  - 使用機器の安全規格・環境保護規格の証明書確認
- **合格基準**: 物理環境が全ての設置条件を満たしていること

### リソース効率性評価
- **実施時期**: 性能テストと並行して実施、および定期的な見直し(四半期ごと)
- **テスト項目**:
  - 仮想化環境におけるCPU、メモリ、ディスクの利用効率
  - クラウドサービスのインスタンスタイプがワークロードに対して最適か
  - 消費電力(物理環境の場合)
- **合格基準**: リソース利用率が目標値(例: CPU平均利用率50%以上)を達成し、無駄なリソース消費がないこと

---

## リスクと対策

| No | リスク | 影響 | 発生確率 | 対策 |
|----|--------|------|---------|------|
| 1 | 法令・規制違反 | 罰金、事業停止、企業イメージ失墜 || 法務部門との連携強化、定期的な法令遵守チェック、クラウドプロバイダーのコンプライアンスレポート確認 |
| 2 | 特定製品のEOL/サポート終了 | システムの脆弱性、運用コスト増大、リプレース費用発生 || 製品のライフサイクル管理、EOL情報の早期収集、代替製品の検討と評価 |
| 3 | 物理環境の災害(地震など) | システム停止、データ損失 || 耐震・免震構造のデータセンター選定、複数リージョンへのシステム分散、DR計画の策定 |
| 4 | 地域的アクセスの誤設定 | サービス提供範囲外からのアクセス許可、または必要なアクセスが遮断される || ファイアウォール、WAFCDNの地理的フィルタリング設定の厳密なレビューとテスト |
| 5 | リソースの過剰消費 | 運用コスト増大、環境負荷増大 || 定期的なリソース利用状況の監視と最適化、オートスケーリングの適切な設定、省電力型機器の選定 |
| 6 | 既存システムとの互換性問題 | 移行失敗、運用非効率化 || 既存システムとのインターフェース仕様の明確化、互換性テストの徹底、段階的移行計画 |

---
プレビュー

システム環境・エコロジー(System Environment & Ecology)

システム環境・エコロジーの基本方針

システムが稼働する環境に関する制約、特性、および環境負荷への配慮を明確にし、持続可能で効率的なインフラ運用を実現するための戦略を以下に示す。

環境制約・前提条件方針
  • 法令・規制遵守: 適用される全ての法令、業界ガイドライン、社内規程を遵守したインフラ構築・運用を行う
  • 既存環境との整合性: 既存のインフラ環境や運用プロセスとの整合性を確保し、スムーズな導入・運用を目指す
システム特性への対応方針
  • 地域分散と冗長性: ユーザーの地域的広がりや拠点数に応じて、適切な地域分散と冗長構成を設計
  • 特定の製品・技術への対応: ユーザー指定の製品や技術がある場合は、その特性を理解し、サポート体制や互換性を考慮したインフラ設計を行う
適合規格への対応方針
  • 製品安全・環境規格の確認: 使用するハードウェアやミドルウェアが、必要な製品安全規格や環境保護規格に適合していることを確認
  • クラウドプロバイダーの認証活用: クラウドサービスを利用する場合は、クラウドプロバイダーが取得している各種認証(ISO27001、SOCなど)を活用し、要件を満たす
機材設置環境条件方針
  • データセンター選定基準: 物理的な設置環境が必要な場合は、耐震性、セキュリティ、電源供給などの条件を満たすデータセンターを選定
  • リソース効率化: 仮想化技術やクラウドサービスを最大限活用し、物理リソースの利用効率を高め、省電力化を推進

システム環境・エコロジー要件の実現方式

F1. システム制約/前提条件 (System Constraints/Prerequisites)
F1.1 構築時の制約条件 (Construction Constraints)
F1.1.1 構築時の制約条件
  • 要件: 以下の社内基準、法令、ガイドラインに準拠したインフラ構築を行うこと
    • 社内情報セキュリティポリシー
    • ISO/IEC 27001 (ISMS) 認証取得
    • クラウドセキュリティガイドライン (NIST SP 800-145)
    • 特定の地域(例: EU)におけるデータ主権要件
  • 実現方式・仕様:
    • クラウド環境のリージョン選定は、データ主権要件を満たす地域(例: 日本国内)に限定
    • IaC(Infrastructure as Code)で定義されたインフラ構成は、社内セキュリティポリシーに準拠していることを自動チェック
    • 構築作業は、ISO/IEC 27001に準拠した変更管理プロセスを経て実施
F1.2 運用時の制約条件 (Operational Constraints)
F1.2.1 運用時の制約条件
  • 要件: 以下の社内基準、法令、ガイドラインを遵守した運用を行うこと
    • J-SOX法におけるIT統制要件
    • 個人情報保護法
    • リモートからの運用は、社内セキュリティポリシーで許可された範囲に限定
  • 実現方式・仕様:
    • 運用担当者のアクセス権限は最小限に制限し、J-SOX法に準拠したアクセスログを記録
    • 個人情報を含むデータの取り扱いは、暗号化、アクセス制御、監査ログ取得を徹底
    • リモート運用は、VPN接続と多要素認証を必須とし、許可されたIPアドレスからのみアクセス可能とする
F2. システム特性 (System Characteristics)
F2.1 ユーザー数 (Number of Users)
F2.1.1 ユーザー数
  • 要件: 最大アクティブユーザー数 50,000人
  • 実現方式・仕様:
    • 認証基盤として、50,000ユーザー規模に対応可能なIDaaS(Identity as a Service)を選定
    • ロードバランサー、Web/APサーバーは、このユーザー数に対応できるキャパシティプランニングに基づき設計
F2.2 クライアント数 (Number of Clients)
F2.2.1 クライアント数
  • 要件: 最大同時接続クライアント数 15,000
  • 実現方式・仕様:
    • ロードバランサーの最大同時接続数を15,000以上で設定
    • データベースのコネクションプール設定は、最大同時接続数に対応できるよう最適化
F2.3 拠点数 (Number of Sites)
F2.3.1 拠点数
  • 要件: 国内3拠点(東京、大阪、福岡)からのアクセスに対応
  • 実現方式・仕様:
    • クラウドの複数アベイラビリティゾーン(AZ)または複数リージョン(例: 東京リージョン、大阪リージョン)にシステムを分散配置
    • 各拠点からのアクセスは、CDNやDNSルーティングにより最適なサーバーに誘導
F2.4 地域的広がり (Geographical Scope)
F2.4.1 地域的広がり
  • 要件: 国内全域からのアクセスに対応し、海外からのアクセスは制限する
  • 実現方式・仕様:
    • WAFやファイアウォールを用いて、海外からのアクセスをIPアドレスベースで制限
    • CDNのエッジロケーションは国内に限定し、国内ユーザーへの高速なコンテンツ配信を優先
F2.5 特定製品指定 (Specific Product Designation)
F2.5.1 特定製品の採用有無
  • 要件: データベースにはPostgreSQL、メッセージキューにはApache Kafkaを使用すること
  • 実現方式・仕様:
    • データベースは、クラウドプロバイダーが提供するマネージドPostgreSQLサービス(例: AWS RDS for PostgreSQL)を利用
    • メッセージキューは、クラウドプロバイダーが提供するマネージドKafkaサービス(例: Amazon MSK)または自社で管理するApache Kafkaクラスタを構築
    • これらの製品のサポート体制、バージョンアップ計画、セキュリティパッチ適用方法を事前に確認し、運用計画に組み込む
F3. 適合規格 (Applicable Standards)
F3.1 製品安全規格 (Product Safety Standards)
F3.1.1 規格取得の有無
  • 要件: 使用する全てのハードウェア(物理サーバー、ネットワーク機器)は、UL60950または同等の製品安全規格を取得していること
  • 実現方式・仕様:
    • データセンター提供の物理機器については、データセンター事業者が取得している安全規格の証明書を確認
    • クラウドサービス利用の場合、クラウドプロバイダーが準拠しているデータセンターの安全基準を確認(例: SOC 2 Type IIレポート)
F3.2 環境保護 (Environmental Protection)
F3.2.1 規格取得の有無
  • 要件: 使用する全てのハードウェアは、RoHS指令に準拠していること
  • 実現方式・仕様:
    • データセンター提供の物理機器については、データセンター事業者が調達する機器のRoHS指令準拠を確認
    • クラウドサービス利用の場合、クラウドプロバイダーの環境保護に関するポリシーやレポート(例: サステナビリティレポート)を確認
F4. 機材設置環境条件 (Equipment Installation Environment Conditions)
F4.1 耐震/免震 (Earthquake Resistance/Isolation)
F4.1.1 耐震震度
  • 要件: 物理的な設置場所は、実効震度6強に耐えうる耐震構造であること
  • 実現方式・仕様:
    • システムを設置するデータセンターは、耐震構造(例: 免震構造)を有し、震度6強以上の地震に耐えられる施設を選定
    • ラックマウント機器は、耐震ラックに固定し、転倒防止対策を徹底
F4.2 スペース (Space)
F4.2.1 設置スペース制限(マシンルーム)
  • 要件: マシンルームへの設置は、最大10ラック(W600mm x D1000mm)に収まること
  • 実現方式・仕様:
    • 物理サーバー、ネットワーク機器の選定は、高密度実装が可能なモデルを優先
    • 将来的な拡張を考慮し、初期段階では7ラックに収め、3ラック分の予備スペースを確保
F4.2.2 設置スペース制限(事務所設置)
  • 要件: 事務所内へのサーバー設置は行わないこと
  • 実現方式・仕様:
    • 全てのシステムコンポーネントは、データセンターまたはクラウド環境に配置
    • 開発・テスト用の機器も、仮想環境またはクラウドサービスを利用し、物理的な事務所設置を回避

テスト計画(システム環境・エコロジー関連)

環境適合性確認
  • 実施時期: 構築フェーズ初期、および環境変更時
  • テスト項目:
    • 選択したクラウドリージョンがデータ主権要件を満たしているか
    • ファイアウォール設定が地域的アクセス制限要件を満たしているか
    • 特定製品(PostgreSQL, Kafka)が指定バージョンで正しく動作するか
  • 合格基準: 全ての環境制約・前提条件が満たされていること
物理環境監査(オンプレミスの場合)
  • 実施時期: データセンター選定時、および定期監査(年1回)
  • テスト項目:
    • データセンターの耐震構造、電源供給、空調設備が要件を満たしているか
    • 設置スペースが計画通り確保されているか
    • 使用機器の安全規格・環境保護規格の証明書確認
  • 合格基準: 物理環境が全ての設置条件を満たしていること
リソース効率性評価
  • 実施時期: 性能テストと並行して実施、および定期的な見直し(四半期ごと)
  • テスト項目:
    • 仮想化環境におけるCPU、メモリ、ディスクの利用効率
    • クラウドサービスのインスタンスタイプがワークロードに対して最適か
    • 消費電力(物理環境の場合)
  • 合格基準: リソース利用率が目標値(例: CPU平均利用率50%以上)を達成し、無駄なリソース消費がないこと

リスクと対策

No リスク 影響 発生確率 対策
1 法令・規制違反 罰金、事業停止、企業イメージ失墜 法務部門との連携強化、定期的な法令遵守チェック、クラウドプロバイダーのコンプライアンスレポート確認
2 特定製品のEOL/サポート終了 システムの脆弱性、運用コスト増大、リプレース費用発生 製品のライフサイクル管理、EOL情報の早期収集、代替製品の検討と評価
3 物理環境の災害(地震など) システム停止、データ損失 耐震・免震構造のデータセンター選定、複数リージョンへのシステム分散、DR計画の策定
4 地域的アクセスの誤設定 サービス提供範囲外からのアクセス許可、または必要なアクセスが遮断される ファイアウォール、WAF、CDNの地理的フィルタリング設定の厳密なレビューとテスト
5 リソースの過剰消費 運用コスト増大、環境負荷増大 定期的なリソース利用状況の監視と最適化、オートスケーリングの適切な設定、省電力型機器の選定
6 既存システムとの互換性問題 移行失敗、運用非効率化 既存システムとのインターフェース仕様の明確化、互換性テストの徹底、段階的移行計画