エンタープライズシステム: セキュリティ・コンプライアンス・可用性の技術選定

はじめに

エンタープライズシステムは、大企業の業務を支える基幹システムです。数百〜数万人のユーザーが日常的に利用し、システム停止は直接的な業務影響や金銭的損失に繋がります。そのため、セキュリティ、コンプライアンス、可用性が最優先の技術選定基準となります。

身近な例えで理解するエンタープライズシステム

エンタープライズシステムは「大病院」のようなものです。

• セキュリティ = 患者の個人情報を守るための厳重な管理体制
• コンプライアンス = 医療法に基づく各種規制への対応
• 可用性 = 24時間365日、救急対応ができる体制
• スケーラビリティ = 患者数が増えても対応できるベッド数と医師の確保

スタートアップとの最大の違い:

• スタートアップ = 「速さ」が最優先。壊れても直せば良い
• エンタープライズ = 「安全性と信頼性」が最優先。壊れてはいけない

全体アーキテクチャ

推奨構成: Java/Spring Boot + Oracle/PostgreSQL + AWS

                    +-------------------+
                    |   AWS WAF         |
                    |   (DDoS防御)      |
                    +--------+----------+
                             |
                    +--------v----------+
                    |   CloudFront      |
                    |   (CDN)           |
                    +--------+----------+
                             |
              +--------------+--------------+
              |                             |
      +-------v-------+           +--------v--------+
      |Next.js        |           |API Gateway      |
      |(管理画面/     |           |(外部API)        |
      | ダッシュボード)|           +--------+--------+
      +-------+-------+                    |
              |                     +-------v-------+
              |                     |NLB/ALB        |
              |                     +-------+-------+
              |                             |
              +-------------+---------------+
                            |
         +------------------+------------------+
         |                  |                  |
  +------v------+   +------v------+   +-------v------+
  |Spring Boot  |   |Spring Boot  |   |Spring Boot   |
  |API Server   |   |Batch Server |   |Auth Server   |
  |(ECS/Fargate)|   |(ECS/EC2)    |   |(ECS/Fargate) |
  +------+------+   +------+------+   +-------+------+
         |                  |                  |
  +------v------+   +------v------+   +-------v------+
  |Aurora       |   |Aurora       |   |Cognito /     |
  |PostgreSQL   |   |PostgreSQL   |   |Active        |
  |(Primary)    |   |(Read Replica)|  |Directory     |
  +------+------+   +-------------+   +--------------+
         |
  +------v------+
  |Aurora       |
  |(Standby -   |
  | Multi-AZ)   |
  +-------------+

  +-------------------------------------------+
  |  セキュリティ/運用                         |
  |  - AWS Config: 構成管理/コンプライアンス    |
  |  - CloudTrail: API操作の監査ログ            |
  |  - GuardDuty: 脅威検出                     |
  |  - SecurityHub: セキュリティ統合管理        |
  |  - Systems Manager: パッチ管理              |
  |  - KMS: 暗号鍵管理                         |
  |  - Secrets Manager: 秘匿情報管理           |
  +-------------------------------------------+

技術選定の詳細

バックエンド: Java (Spring Boot)

Java/Spring Bootを選ぶ理由:

• 20年以上のエンタープライズ実績
• Spring Securityによる堅牢な認証・認可
• Spring Batchによる大量バッチ処理
• 大量のJavaエンジニアが市場にいる
• LTS（Long Term Support）により長期のサポートが保証される

データベース: PostgreSQL (Aurora) or Oracle

推奨: Aurora PostgreSQL

新規開発であれば、コストとスケーラビリティの観点からAurora PostgreSQLを推奨。既存のOracle環境がある場合は、段階的にPostgreSQLに移行するか、Oracle on RDSを利用。

認証: AWS Cognito + Active Directory

セキュリティ設計

多層防御（Defense in Depth）

[外部ネットワーク]
    |
    v
[Layer 1: Edge] -- AWS WAF, CloudFront, Shield
    |
    v
[Layer 2: Network] -- VPC, Security Group, NACL
    |
    v
[Layer 3: Application] -- ALB, API Gateway (認証/認可)
    |
    v
[Layer 4: Service] -- Spring Security, RBAC
    |
    v
[Layer 5: Data] -- 暗号化（KMS）, RLS, 監査ログ

AWSセキュリティサービスの活用

データ暗号化

コンプライアンス対応

主要なコンプライアンス要件

監査ログの設計

可用性設計

可用性のレベル

99.99%を実現するアーキテクチャ

[リージョン: ap-northeast-1]
    |
    +-- [AZ-a]
    |   ├── ECS Task x 2
    |   ├── Aurora Primary
    |   └── ElastiCache Primary
    |
    +-- [AZ-c]
    |   ├── ECS Task x 2
    |   ├── Aurora Replica
    |   └── ElastiCache Replica
    |
    +-- [AZ-d]
        ├── ECS Task x 2
        ├── Aurora Replica
        └── ElastiCache Replica

[DR: ap-northeast-3 (大阪)]
    ├── Aurora Global Database (非同期レプリケーション)
    ├── S3 Cross-Region Replication
    └── Route 53 Health Check + フェイルオーバー

障害対応

※ RTO: Recovery Time Objective（復旧目標時間） ※ RPO: Recovery Point Objective（復旧目標地点、データ損失許容量）

バッチ処理設計

バッチ処理の分類

Spring Batchの活用

[月次バッチ処理の例]

EventBridge (毎月1日 AM 2:00)
    |
    v
ECS RunTask (Spring Boot + Spring Batch)
    |
    +-- Step 1: データ抽出（Aurora → CSV）
    +-- Step 2: データ加工（集計処理）
    +-- Step 3: レポート生成（PDF）
    +-- Step 4: 通知（SES/SNS）
    |
    v
S3（レポート保存）

チーム規模と開発スケジュール

エンタープライズプロジェクト体制

開発フェーズ

コスト見積り

本番環境（99.9% SLA）

DR環境（大阪リージョン）追加

オンプレミスからの移行

移行方式の比較

推奨: リプラットフォーム

既存のJavaアプリケーションをコンテナ化し、ECS/Fargateで実行。データベースはDMS（Database Migration Service）でAuroraに移行。

まとめ

推奨技術スタック

エンタープライズの技術選定で最も重要なこと

1. 実績のある技術を選ぶ: 最新の技術より、実績のある技術が安全
2. 人材の確保: その技術のエンジニアが市場にいるか
3. 長期サポート: 5年以上のサポートが保証されているか
4. セキュリティ: 設計段階からセキュリティを組み込む（Security by Design）
5. コンプライアンス: 業界の規制要件を満たせるか

参考リンク

• Spring Boot公式ドキュメント
• AWS Well-Architected Framework
• AWS Security Best Practices
• Amazon Aurora公式ドキュメント
• IPA セキュリティ実装ガイド