このページは利便性のために提供された翻訳です。英語版が正本となります。 英語版を読む

規制関連情報

セキュリティと健全性

当行の金融取引のセキュリティと健全性

当行のような銀行は、業務領域ごとに専用のサーバーインフラを使用しています。アーキテクチャ上の要件および金融規制に基づき、主なサーバーの種類は次のとおりです。

1. 勘定系サーバー

これらのサーバーは、お客様の口座、取引、コンプライアンスを管理する中核的な業務基盤を構成しております。

  • 取引処理サーバー:リアルタイムの決済承認、不正検知および決済処理を実行します(例:SWIFT、SEPA)。
  • アカウント管理サーバー:口座のライフサイクルに関わる事象(開設・解約)、利息計算、流動性のモニタリングを処理します。
  • 規制コンプライアンス用サーバー:AML(マネー・ローンダリング防止)チェック、監査証跡、報告(IFRS、GDPRなど)を自動化します。

2. 台帳サーバー

改変不能な財務記録の維持管理を担います。

  • 総勘定元帳サーバー:複式簿記に基づく勘定科目間の取引を記録し、IFRSなどの会計基準への準拠を確保します。
  • 分散型台帳技術(DLT)サーバー:国際送金、KYC確認、および改ざん防止取引ログのためのブロックチェーン型システムです。

3. 外部通信サーバー
外部の関係先との安全なやり取りを可能にします。

  • EBICSサーバー:ドイツ、フランス、スイスで広く利用されている、SEPA決済向けの電子バンキング・インターネット通信標準(EBICS)を管理します。
  • ホスト・ツー・ホスト(H2H)サーバー:大量の法人取引(例:給与一括処理)のための、SFTP/FTPSによる直接接続。
  • APIゲートウェイサーバー:リアルタイムでの支払指図およびアカウント集約のためのRESTfulインターフェースを提供します(OAuth2/mTLSにより保護されています)。
  • Swiftインターフェースサーバー:当行をSwiftネットワークに接続し、銀行間メッセージングを行うためのサーバーです(SCOREは、法人向けアクセスのためのSwiftのクローズド・ユーザー・グループであり、サーバーの種類ではありません)。

4. データベースサーバー
構造化された金融データの中央リポジトリ:

  • 顧客データサーバー:KYC書類、取引履歴および行動分析データを保存します。
  • 商品カタログサーバー:ローン、住宅ローン、預金金利などの商品を管理します。

5. セキュリティおよびインフラストラクチャ用サーバー
システムの健全性と規制遵守を確保します。

  • ハードウェアセキュリティモジュール(HSM)サーバー:電子署名およびSSL/TLS暗号化に用いる暗号鍵を保護します。
  • ファイアウォール/VPNサーバー:ネットワークのセグメンテーションを徹底し、従業員向けのリモートアクセスを保護します。
  • 災害復旧サーバー:障害発生時に事業継続を図るため、バックアップシステムを稼働させます。

現代の銀行は、オンプレミスの基幹サーバーとクラウド型のDLTノードを組み合わせたハイブリッド型のアーキテクチャを採用することが多く、拡張性を確保しています。たとえば、ある銀行がIBMのオンプレミス型基幹系銀行サーバーとAWS上のレジャーサーバーを併用し、リアルタイムの照合を行う場合があります。このモジュール型のアプローチにより、コンプライアンス、性能および革新性のバランスが図られます。

銀行は、効率化のためのサーバー統合と、セキュリティおよびコンプライアンスのための分離維持との均衡を図る必要があります。以下では、技術的制約および業界慣行に基づき、統合可能なサーバーと統合できないサーバーを整理します。
統合可能なサーバー
1. Web/アプリケーションサーバー

  • 組み合わせ方式:仮想化(VMware、KVM)またはコンテナ化(Docker/Kubernetes)
  • 例:複数のバンキングポータル(個人向け、法人向け、モバイル)を、負荷分散機能を備えたハイパーバイザー・クラスター上で運用する場合。

2. データベースサーバー

  • 組み合わせ方式:マルチテナント型クラウドデータベース(AWS RDS、Azure SQL)
  • OracleやMS SQLを用いた勘定系データベースは、ハイブリッドクラウド環境において、PostgreSQLやMongoDBを用いた分析システムと併存させることができます。

3. 外部通信ゲートウェイ

  • 組み合わせ方式:統合APIゲートウェイ(Apigee、MuleSoft)
  • EBICS、SWIFT、SFTPの各サービスは、プロトコル別のマイクロサービスを備えた共有インフラ上で稼働させることができます。

4. 災害復旧用サーバー

  • 組み合わせ方式:アクティブ・アクティブ方式の地理的冗長構成
  • 勘定系システムのレプリカおよびバックアップ用元帳サーバーは、災害復旧(DR)クラスターを共用できます。

5. ミドルウェアサーバー

  • 組合せ方式:エンタープライズ・サービス・バス(ESB)
  • 決済ルーティング、コンプライアンス・チェックおよび通貨交換サービスを、IBM Integration Bus/SAP PI上に集約しております。

隔離を維持すべきサーバー
1. 中核となる取引処理サーバー

  • 理由:物理的な分離または厳格なセグメンテーションによる分離により、PCI DSSおよびSOC 2の統制の適用範囲が縮小されます。
  • 例:CICSトランザクションモニターを稼働させているIBM zSystemsは、他のワークロードとハードウェアを共有することができません。

2. ハードウェア・セキュリティ・モジュール(HSM)サーバー

  • 理由:FIPS 140-2/140-3 レベル3は、専用の耐タンパー性ハードウェアを義務付けているためです
  • 実装:デジタル署名および暗号鍵を扱うThales/GemaltoのHSM(ハードウェア・セキュリティ・モジュール)。

3. リアルタイム台帳システム

  • 理由:複式簿記には原子性(アトミシティ)が求められるため
  • 例:NVMeストレージを直接接続したOracle Financial Servicesの元帳サーバー。

4. 規制当局向け報告サーバー

  • 理由:監査ログは、改ざんから保護し、GDPRおよびAML関連法令が求める期間保管しなければなりません。分離して管理することで、その実証が容易になります。
  • 構成:MiFID II/FATCA報告用に分離されたSQL Serverインスタンスを使用します。

5. ATM/POSのオーソリゼーション・システム

  • 理由:99.999%の稼働率SLAおよびネットワーク分離の要件
  • アーキテクチャ:冗長化されたファイバーチャネルSANを備えたIBM Power Systems。

技術的制約:

  • 大量の取引を処理する基幹銀行システムには、専用の広帯域ネットワーク接続が必要です
  • PCI DSSは、保存されたカード番号(PAN)を判読不能な状態にすること、およびカード会員データ環境を分離することを求めております
  • Swift Customer Security Programme(CSP)は、Swiftのインフラを保護されたセキュアなゾーン内に配置することを求めています

当行は、コア・システム、HSMおよび元帳システムを完全に分離したまま、重要度の低いサーバー(ウェブ/アプリケーション/ミドルウェア)の80%の統合を完了しました。

クラウド上の元帳サーバーを保護するには、金融データの機微性に応じた多層的な保護措置が必要です。AWSのセキュリティに関するベストプラクティスおよび銀行業務に特化した実装に基づく、体系的なアプローチは次のとおりです。

1. 改ざん不能な台帳技術
すべての取引を暗号技術により検証できる、専用設計の台帳データベースを使用します。

  • 暗号学的連鎖:各取引はハッシュ化されて直前の記録と連結され、改ざん不能な監査証跡が形成されます。
  • 組込み型の整合性チェック:データベースが自らの履歴を自動的に検証し、改ざんを防止します。
  • SQL型のクエリ:既存の金融システムとの互換性を維持しつつ、ブロックチェーンに類する安全性を付加します。

2. ネットワークの分離

  • VPCアーキテクチャ:台帳サーバーは、インターネットに公開されないプライベートサブネット内に配置します。
  • セキュリティグループ:受信トラフィックを、事前に承認されたIPアドレス範囲からの特定のポート(例:PostgreSQL/Aurora)に限定します。
  • VPCエンドポイント:AWS PrivateLinkを使用して、元帳サーバーとS3/KMSなどのサービス間で、公衆ウェブに露出させることなく安全に通信します。

3. 暗号化

  • 保存時:Amazon Auroraの台帳データはAWS KMSが管理する鍵で暗号化され、鍵は自動的にローテーションされます。
  • 通信中:クライアント・サーバー間およびサービス間のすべての通信にTLS 1.3を適用します。
  • クライアント側の暗号化:AWS Encryption SDKを使用し、口座残高などの機微な項目を、保存前にあらかじめ暗号化します。

4. アクセス管理

  • IAMロール:きめ細かな権限(例えば、挿入のみを許可するロール)を付与し、データの誤削除や不正な削除を防止します。
  • 一時的な認証情報:保守作業中の時限付きアクセスには AWS STS を使用します。
  • 多要素認証(MFA)の強制:rootおよび管理者アカウントには、ハードウェアトークン(YubiKey)の使用を必須とします。

5. モニタリングと監査

  • リアルタイムアラート:異常な取引パターン(例:100万ユーロ超の送金)に対してアラートが発動されるよう、AWS CloudWatchを設定してください。
  • アクティビティログ:元帳へのすべての変更を、SIEMツールと連携したAWS CloudTrailにより追跡します。
  • 自動監査:毎週AWS Configルールを実行し、暗号化の状況とネットワークポリシーを検証します。

6. コンプライアンスとガバナンス

  • ゾーン別のセグメンテーション:AWS Organizationsを用いて、DEV/TEST/PRODの各台帳環境を分離します。
  • 自動レポート:AWS Audit Managerを通じて、PCI DSSおよびGDPRのコンプライアンスレポートを作成します。
  • 第三者による監査:AWSが承認したパートナーを通じて、年次のペネトレーションテストを実施してください。

7. 災害復旧

  • リージョン間レプリケーション:暗号化された台帳の複製を、AWSのフランクフルトおよびストックホルムの各リージョンに保持します。
  • ポイント・イン・タイム・リカバリー:継続的バックアップを有効にすることで、保存期間内(最長35日間)の任意の時点(秒単位)にデータを復元できます。
  • エアギャップ方式のバックアップ:四半期ごとの台帳スナップショットを、保存期間7年でAWS Backup Vaultに保管します。
セキュリティと健全性 - 金融データの多層的な保護

不正なデータの書き込みが災害復旧(DR)サーバーに波及することを防ぐため、銀行は、バックアップの隔離、厳格なアクセス管理の実施、データ完全性の検証といった多層的なセキュリティ対策を講じています。主要な対策の技術的な内訳は以下のとおりです。
1. WORM(Write-Once-Read-Many:一度書込み・複数回読出し)構成による改変不能なバックアップ

  • 目的:ランサムウェアによるバックアップデータの改ざんや暗号化を阻止すること。

実装方法:AWS S3 Object LockまたはAzure Blob Immutable Storageを使用し、定められた保存期間中の削除・変更を防止します。バックアップファイルには暗号学的ハッシュ(SHA-256)を適用し、改ざんがあればハッシュが無効となって警告が発せられるようにします。
2. エアギャップおよびオフラインでのレプリケーション

  • ネットワークの分離:DRサーバーは、インターネットからのインバウンド通信を許可しない別個のVPC/VLAN内に配置します。AWS Storage GatewayやAzure Site Recoveryなどのツールを用いて、プライマリからDRへの一方向レプリケーションを行い、逆方向の同期を遮断します。
  • 物理的なエアギャップ:重要なシステムについては、テープバックアップまたはオフラインの保管媒体を維持し、予定されたレプリケーションの時間帯にのみ接続するようにします。

3. ゼロトラスト型アクセス制御

  • 認証:すべてのDR管理インターフェース(例:AWS SSO、Azure ADの条件付きアクセス)に対して多要素認証(MFA)を必須としてください。最小権限の原則に基づくIAMロールを割り当ててください(例:`s3:GetObject`のみ)。
  • ネットワークセキュリティ:レプリケーション通信は、IPsec VPNトンネルまたはAWS Direct Connect/Azure ExpressRouteに限定してください。SnortやSuricataなどの侵入検知システム(IDS)を導入し、レプリケーションの経路を監視してください。

4. データ完全性の検証

  • 複製前の検査:複製に先立ち、ClamAVやCrowdStrike Falconなどのツールを用いて、元データにマルウェアが含まれていないか検査します。転送前後のチェックサムを比較し、改ざんを検知します。
  • レプリケーション後の監査:AWS ConfigまたはAzure Policyを用いて、DRサーバーに暗号化およびアクセス管理のポリシーを適用します。スクリプト(例:`sha256sum`による検証)により、日次の完全性チェックを実施してください。

5. 論理的に分離された環境

6. 自動フェイルオーバーのテスト

  • 模擬攻撃:Chaos Monkeyなどのツールを用いてランサムウェア感染を模擬し、災害復旧(DR)サーバーの耐性を検証します。訓練中に、目標復旧時間(RTO)および目標復旧時点(RPO)を計測します。
  • フォレンジック分析:レプリケーションの異常を追跡できるよう、VPCフローログおよびCloudTrailイベントを90日間保存します。

イミュータブル(変更不能)なバックアップの導入は、ランサムウェア、誤削除、コンプライアンス違反からデータを保護するうえで不可欠です。AWS、Veeam、Azureなどの業界標準およびツールに基づく、望ましい実務は次のとおりです。
1. ストレージ層でイミュータビリティを徹底する

  • AWSのS3 Object Lock、Azure Immutable Blob Storage、Veeam Hardened Repositoriesなどのオブジェクトストレージを用い、WORM(Write-Once-Read-Many:一度書込み・複数回読出し)構成を採用してください。
  • 保持ロックを有効にし、管理者による場合を含め、保存期間満了前の削除や変更を防止します。

2. 3-2-1-1方式のバックアップ戦略を採用すること

  • データのコピーを3つ保持(主データ+バックアップ2つ)
  • 2種類の保存媒体(例:ディスク+クラウド)
  • オフサイトコピー1部(地理的に隔離された場所に保管)
  • 不変のコピーを1部(エアギャップ方式またはWORM対応)。

3. 厳格なアクセス管理を実施する

  • ロールベースのアクセス制御(RBAC):IAMロール(例:AWS Backupのボールトアクセスポリシー)を用いて権限を制限します。
  • 多要素認証(MFA):バックアップ管理用インターフェースには必ず適用してください(例:Azure AD の条件付きアクセス)。
  • ネットワークの分離:バックアップは、公衆インターネットに接続されないプライベートサブネットまたはVPC内に保管します。

4. データをエンドツーエンドで暗号化する

  • 保存時:AES-256 または KMS(AWS、Azure)で管理される鍵を使用します。
  • 伝送中:レプリケーション用通信経路にはTLS 1.3を使用。
  • クライアント側暗号化:バックアップ前に機微なフィールドを暗号化します(例:ユーザーが鍵を管理するVeeamのAES-256)。

5. 保存および検証の自動化

  • 保存方針:RPO/RTOを定め、ライフサイクル規則(例:AWS Backup Vaultの7年間保存)を自動化します。
  • チェックサムの検証:複製の前後で完全性を確認します(例:SHA-256によるハッシュ化)。
  • 定期的な監査:AWS ConfigやVeeam SureBackupなどのツールを用いて、リストアのテストを行います。

6. ハイブリッド環境におけるセキュリティの多層化

7. コンプライアンスと取消不能性の確保

  • テスト完了後は、イミュータビリティ(変更不可)設定をロックしてください(例:Azureの「有効かつロック済み」の状態)。
  • 規制への適合:AWS Audit Managerなどのツールを用い、GDPR、HIPAA、SOXに整合させます。
  • 第三者による監査:年次のペネトレーションテストを予定してください(例:AWSが承認したパートナーを利用)。

AWSおよびVeeamを用いたワークフローの例
1. プライマリ・バックアップ:Veeam Backup & Replicationにより、Object Lockを有効にしたS3バケットへバックアップします。
2. レプリケーション:AWS DataSyncにより、第2のリージョン(フランクフルト→ストックホルム)へ複製します。
3. 検証:CloudTrailログを日次で確認し、四半期ごとに復元訓練を実施します。
4. 保存期間:KMS暗号化を施し、90日間の変更不可期間を設けます。

不変性機能、アクセス制御、ハイブリッド冗長構成を組み合わせることで、各組織はコンプライアンス要件を満たしつつ、ランサムウェアに耐性のあるバックアップを実現できます。