COBOLは、ATM取引の約95%、店頭POS取引の約80%、そして世界中の主要銀行、保険会社、政府機関のコア処理ロジックを依然として担っています。これらのコードを実行する組織は、GDPR、DORA、HIPAA、PCI-DSS、バーゼルIII、FCA、OCC、APRA、その他数十の国家機関が施行する業界固有の規制など、技術分野で最も厳しい規制枠組みにも従わなければなりません。これらの組織がワークロードをクラウドに移行することを検討する際、問題は技術的なものだけではありません。法的、契約上の問題であり、外部監査人に対して特定の期限内に証明できるものでなければなりません。
COBOL を実行する規制対象組織にとって、一部のワークロードをオンプレミスに残しつつ、他のワークロードをクラウド インフラストラクチャに移行するハイブリッド クラウドは妥協案ではなく、多くの場合、アーキテクチャ的に正しい解決策となります。GDPR およびその各国版に基づくデータ所在地の要件により、特定のデータが特定の管轄区域外に持ち出されることが法的に禁止される場合があります。DORA に基づく運用回復力の要件では、重要な財務機能がクラウド プロバイダーの障害に耐えられることを証明する必要があります。バーゼル III に基づく規制資本の計算の完全性要件では、特定の計算が再現可能、監査可能、改ざん防止可能であることが求められますが、これらの特性は、組織が管理するインフラストラクチャ上で計算が行われる場合に証明しやすくなります。
移行開始前にコンプライアンス上のギャップを特定する
SMART TS XL COBOLソースコードにハードコードされた認証情報、欠落した監査証跡、および規制されたデータパターンが明らかになる。
詳細情報課題は、規制対象のCOBOL向けハイブリッドクラウドアーキテクチャは、一般的なハイブリッドクラウドガイダンスが認めているよりも制約が多いという点です。貴社のハイブリッドクラウド統合戦略は、メインフレームからクラウドへの移行において、イノベーションと安定性の重要なバランスを提供します。このバランスは原則として正しいと言えます。しかし、規制当局の要件を満たし、運用継続性を維持し、恒久的な分離ではなく移行パスを構築するために、オンプレミスとクラウドの境界を明確に定めるために必要な具体的な技術およびコンプライアンスアーキテクチャが、この戦略には含まれていません。
このガイドでは、主要な規制枠組みがハイブリッド境界の決定にどのように影響を与えるか、規制対象のCOBOL環境で有効な4つのアーキテクチャパターン、ハイブリッドアーキテクチャが適切に設計されていない場合に発生するコンプライアンス違反モード、および監査人がハイブリッドCOBOL環境をレビューする際に実際に何を調査するかについて説明します。
規制がハイブリッド境界をどのように形成するか
規制対象組織にとって、ハイブリッドクラウドアーキテクチャにおいて最も重要な決定は、どのクラウドプロバイダーを利用するか、どのワークロードを最初に移行するかではありません。それは、コンプライアンスの境界線をどこに引くか、つまり、どのデータと処理をオンプレミスに残し、どのデータを規制違反を招くことなくクラウドインフラストラクチャに移行できるかを判断することです。
主要な枠組みはそれぞれ、その境界に対して異なる要件を課している。
| 規制 | 管轄 | プライマリーハイブリッド制約 | 敷地内に保管しなければならないもの |
|---|---|---|---|
| GDPR / nFADP | EU、スイス | EU/EEA居住者の個人データのデータ所在地 | 対象クラウドリージョンに対する十分性決定なしにEUの個人データを処理するCOBOLシステム |
| DORA | EU金融サービス | 運用上の回復力、ICTプロバイダー向けサードパーティリスク管理 | 重要または不可欠な機能には出口戦略が必要であり、集中リスク制限が適用される。 |
| HIPAA | 米国のヘルスケア | PHIはBAAなしではクラウドプロバイダーによって処理できません。暗号化要件 | クラウド上のあらゆる経路で転送中および保存中の電子保護医療情報（ePHI）には、文書化された管理策が必要です。 |
| PCI DSS v4.0 | グローバル（カード決済） | カード所有者データ環境はネットワークから分離されている必要がある | CHD処理システム、暗号化キー管理 |
| バーゼルIII/IV | グローバル（銀行） | 規制資本の計算は再現可能かつ監査可能でなければならない。 | インフラストラクチャ制御によって監査可能性が実証されている計算エンジン |
| FCA / PRA（英国） | 英国の金融サービス | 運用上の回復力；重要なビジネスサービスは、影響許容範囲を満たす必要がある。 | SLAの実証可能性によります。クラウドは除外されませんが、実証が必要です。 |
| OCC（米国銀行協会） | 米国の国立銀行 | ベンダーリスク管理、第三者デューデリジェンス | 全面的な禁止ではないが、集中リスクと出口戦略が求められる。 |
COBOLワークロードに対する実際的な影響：
EUの顧客口座データを処理するCOBOLバッチプログラムは、クラウドプロバイダーの管轄区域が十分性認定を受けているか、適切な保護措置（標準契約条項）が講じられていない限り、EU/EEA域外のクラウドリージョンにプラットフォームを移行することはできません。一方、内部運用データのみを処理する同じプログラムであれば、はるかに柔軟性があります。
ハイブリッド境界を設定する前に、規制対象となるすべての組織は、 COBOLポートフォリオに対してデータ分類を実施する必要があります。どのプログラムが個人データ、カード会員データ、保護医療情報（PHI）、および規制資本計算に関与しているかを特定します。この分類により、技術的な好みに関わらず、どのプログラムが自由に移行でき、どのプログラムがコンプライアンス境界内に留まらなければならないかが決定されます。
誰も言及しないCOBOLのコンプライアンス問題
COBOLプログラムは、その言語と時代特有のコンプライアンスリスクを伴い、一般的なクラウドコンプライアンスガイドラインでは対処できません。これらのリスクは現在オンプレミス環境にも存在し、監査人が境界の両側にわたる統制を確認することを期待するハイブリッド環境では、可視性の問題となります。
監査証跡の欠陥。COBOLプログラムは通常、ネイティブなトランザクションログ機能を使用せずにファイルやデータベースに書き込みます。COBOLのVSAM KSDS更新では、デフォルトでは、誰が、いつ、どの値からどの値に変更したかを示す不変の記録が生成されません。規制環境においては、これはコンプライアンス上の欠陥であり、このような欠陥のあるプログラムを、クラウド側で最新の監査ログ機能を備えたハイブリッド環境に移行すると、欠陥が目立たなくなるどころか、より顕著になります。
ハードコードされた認証情報と暗号化キー。従来の COBOL アプリケーションは、ロールベースのアクセス制御、リアルタイム監視、暗号化プロトコルといった最新の機能が欠けていることが多く、高度なサイバー脅威に対して脆弱です。COBOL プログラムの静的解析では、ハードコードされたキー、WORKING-STORAGE 内のパスワード、ソースコードに埋め込まれた接続文字列などが頻繁に検出されます。PCI-DSS のキー管理要件や HIPAA の暗号化制御を満たす必要があるハイブリッド環境では、これらのパターンは移行後ではなく、移行前に修正する必要があります。
計算の再現性。COBOLのパック10進数演算（COMP-3）には、特定の精度と丸め特性があります。z/OS上で正しく動作する規制資本計算でも、コンパイラの10進数処理の違いにより、Linux上では異なる結果になる場合があります。その差は、トランザクションあたり数セント程度の場合もあれば、資本比率に大きな影響を与える場合もあります。計算コンポーネントを複数のプラットフォームに分割するハイブリッド環境では、数値の等価性を明示的に検証する必要があります。
規制対象COBOLのための4つのハイブリッドアーキテクチャパターン
規制対象となるワークロードの種類によって、必要なハイブリッドアーキテクチャは異なります。普遍的なパターンはありませんが、以下の4つは、ほとんどの規制対象組織が直面する状況を網羅しています。
パターン1：コンプライアンス境界APIゲートウェイ
最適な対象：規制上の理由からCOBOLのビジネスロジックをオンプレミスに維持する必要があるが、最新のアプリケーション、分析、顧客向けサービスはクラウドに移行できる組織。
COBOLプログラムはメインフレーム上に残ります。通常、クラウドに隣接するインフラストラクチャ上、または組織のプライベートネットワーク内で動作する薄いAPIレイヤーが、COBOLの機能をRESTまたはgRPCエンドポイントとして公開します。クラウドベースのアプリケーションはこれらのエンドポイントを呼び出します。COBOLプログラム自体は移動しませんが、そのインターフェースは移動します。
Cloud Region (permitted) Compliance Boundary On-Premises (required)
┌─────────────────────┐ │ ┌──────────────────────────┐
│ New cloud-native │ │ │ COBOL programs │
│ applications │──── API ─────┤──────────────│ (regulated processing) │
│ │ call │ │ │
│ Analytics │ │ │ VSAM files (PHI/CHD) │
│ platforms │ │ │ │
│ │ │ │ Audit logs │
└─────────────────────┘ │ └──────────────────────────┘コンプライアンス上の利点：規制対象データは境界を越えることはありません。APIゲートウェイが境界で認証、認可、ログ記録を処理するため、COBOLプログラム自体では生成されない監査証跡が網羅されます。クラウドは規制対象データを直接処理することはありません。
運用要件： APIレイヤーは、COBOLの同期型リクエスト/レスポンスモデルに対応できるように設計する必要があります。長時間実行されるCOBOLバッチジョブでは、タイムアウトする同期型API呼び出しではなく、コールバックまたはポーリング機構を用いた非同期パターンが必要です。
パターン2：規制上の機密性に基づくデータ階層化
最適な用途：規制対象データと非規制対象データの両方を同じCOBOL環境で管理し、規制対象データを運用データから分離できる組織。
規制要件に該当するトランザクションデータ、個人データ、カード会員データ、PHI（保護対象医療情報）はオンプレミスに保持されます。規制上の制限に該当しない集計データ、匿名化データ、または運用データは、クラウドストレージおよびクラウド処理に移行されます。規制対象となる出力を生成するCOBOLプログラムは、引き続きメインフレーム上で実行されます。集計データを利用するレポート作成プログラムは、クラウド上で実行されます。
重要な実装要件：集計および匿名化のステップは監査可能でなければなりません。規制対象データをクラウド送信用に非規制対象データに変換するプロセス自体が、ログ記録、テストされ、独自の制御の対象となる必要があります。特定の入力条件下で匿名化プロセスが失敗すると、意図せず個人を再識別してしまうクラウドデータが生成される可能性があります。これは、本来GDPR違反を防ぐために設計されたアーキテクチャが原因で発生する違反です。
パターン3：デュアルラン検証
最適な用途：規制対象の計算を実行するCOBOLワークロードを移行する組織で、切り替え前に旧システムと新システムの機能的同等性を規制当局に証明する必要がある場合。
元のCOBOLプログラムはメインフレーム上で引き続き稼働し、リアルタイムデータを処理します。プラットフォームを再構築または再設計した並行実装が、クラウドインフラストラクチャ上で同時に稼働し、同じ入力データを処理します。出力はリアルタイムで比較されます。不一致が検出された場合は、クラウド実装が正式なシステムとして認定される前に、フラグが立てられ、調査および解決されます。
コンプライアンス上の利点：デュアルランは、規制計算を実行するシステムの変更に対して規制当局が課す、実証可能な同等性要件を満たします。組織は、Nか月間の並行運用記録、差異に適用された調整プロセス、および新しいシステムがすべてのテスト済み入力条件下で実質的に同一の出力を生成するという証拠を監査人に示すことができます。
運用コスト： 2つのシステムを並行して運用するにはコストがかかります。デュアルランは移行メカニズムであり、恒久的なアーキテクチャではありません。検証と切り替えの完了までのスケジュールはプロジェクト計画に明記し、事前承認が必要な場合（DORAで重要な機能の変更に適用されるのと同様）、関係規制当局と合意する必要があります。
パターン4：コンプライアンス境界を持つ絞め殺しイチジク
最適な対象：クラウド上で新たな機能を構築しつつ、規制対象のCOBOLワークロードを長期的にオンプレミスで維持し、認証取得に応じて各ワークロードの移行パスを明確に定義している組織。
新機能や顧客向け機能は、最初からクラウドネイティブサービスとして構築されます。規制対象となるCOBOLワークロードはオンプレミスに残り、APIゲートウェイパターンを介してアクセスされます。個々のCOBOLプログラムは、時間の経過とともにクラウド展開の認証を受け、デュアルラン検証を完了し、必要に応じて規制当局の事前承認を得て、境界のクラウド側に移行します。各プログラムがコンプライアンス認証を完了するにつれて、メインフレームは徐々に縮小していきます。
規制対象組織にとってこれが有効な理由：規制対象外のワークロードについては近代化のスピードを上げつつ、規制対象のワークロードには適切な厳格さを適用できます。コンプライアンスの境界は明確で監査可能であり、一方向に進みます。組織は、クラウド側のすべてのワークロードが定義された認証プロセスを経ており、オンプレミス側のすべてのワークロードには認証ロードマップがあることを規制当局に証明できます。
監査人がハイブリッドCOBOL環境について実際に尋ねること
コンプライアンスとは状態ではなく、実証可能なプロセスです。問題は、ハイブリッドアーキテクチャがコンプライアンスに準拠しているかどうかではなく、問題点を見つけることを仕事とする人にそれを証明できるかどうかです。
主要な規制機関の監査担当者がハイブリッドCOBOL環境に関して尋ねる質問と、それぞれの質問に対する回答として必要な証拠は以下のとおりです。
「このデータはどこに保存され、どの管轄区域にあるのか？」必須：管轄区域、分類、および適用されている制御を含む、すべてのデータストア、VSAMファイル、DB2テーブル、クラウドオブジェクトストレージを示す最新のデータマップ。データセットに書き込むCOBOLプログラムは、出力が分類された状態でこのマップに表示される必要があります。
「このトランザクションの監査証跡を表示してください。」必須要件：トランザクションの開始から、データに触れたすべてのシステム（データを処理したCOBOLプログラムを含む）までのエンドツーエンドのトレース。COBOLプログラムが独自の監査記録を生成しない場合、周辺インフラストラクチャがそれを補う必要があります。この機能は明示的に設計に組み込まれていなければならず、想定されるべきではありません。
「クラウドプロバイダーに障害が発生した場合、重要な機能はどうなりますか？」必須事項（DORA）：文書化された運用回復シナリオ、重要な機能のテスト済みRPOおよびRTO、組織の回復ポリシーで指定された期間、オンプレミスシステムがクラウドへの依存から独立して動作できるという証拠。
「移行後のシステムが元のシステムと同じ結果を生成することをどのように確認しますか？」必要な情報：デュアルラン調整記録、テストケースのカバレッジ、および計算に敏感なワークロードの場合は数値等価性分析。
「クラウド側で規制対象データにアクセスできるのは誰で、そのアクセスを管理する承認はどのようなものか？」必須事項：IAMポリシー文書、特権アクセス管理記録、およびクラウド側のアクセス制御がオンプレミス側のアクセス制御と同等以上の制限があることを示す証拠。
ハイブリッド境界を設定するための意思決定フレームワーク
すべてのCOBOLプログラムがハイブリッド境界の同じ側に属するとは限りません。このチェックリストは、各ワークロードの配置を決定します。
規制上の制約を受けずにクラウドへ移行する：
- 本プログラムは、GDPR/nFADP管轄区域内の個人の個人データを処理しません。
- 本プログラムはカード所有者データを処理しません（PCI-DSSの適用範囲除外が確認されています）。
- 本プログラムは個人健康情報（PHI）を処理しません（HIPAAの適用範囲除外が確認されています）。
- このプログラムは、規制資本比率の算出に必要な計算は行いません。
- プログラムのソースコードには、認証情報や暗号化キーはハードコードされていません。
- 本プログラムの出力は、いかなる法域においてもデータ所在地の要件の対象とはなりません。
クラウド移行前にコンプライアンス設計が必要です。
- プログラムが個人データを生成または処理する場合、データ影響評価を完了する。
- 本プログラムはPCI-DSSの適用範囲内であり、クラウド環境向けのSAQ/ROCを完了する必要があります。
- プログラムは規制資本の計算と完全な数値等価性分析を実行します
- プログラムには監査証跡生成機能が欠けており、移行前に補償制御を設計する必要がある。
- プログラムにはハードコードされたキーが含まれているため、クラウドネットワークパスに公開する前に修正してください。
規制当局の事前承認が得られるまで、施設内に留まらなければなりません。
- このプログラムはDORAの下で重要または重要な機能として分類されています。
- 本プログラムは、重要なビジネスサービスとして、FCA/PRAの運用回復力要件の対象となります。
- 規制当局は、システム変更（コアバンキングでは一般的）について、通知または事前承認を明確に要求している。
認定条件 SMART TS XL 規制対象COBOLのハイブリッドアーキテクチャ計画をサポート
このガイドで説明する、コンプライアンス境界をどこに設定するか、規制対象データを処理するプログラム、セキュリティ対策要件を含むプログラム、等価性検証が必要な計算関数を実行するプログラムなどを決定するには、COBOLポートフォリオ内のすべてのプログラムに関する正確な構造知識が必要です。この知識はドキュメントから推測できるものではありません。規制対象のCOBOL環境では、既存のドキュメントは通常、その後数十回も変更されたシステム向けに作成されたものであり、それに対応するドキュメントの更新は行われていません。
SMART TS XLさん 静的コード分析 COBOLソースコード内のセキュリティおよびコンプライアンスパターンを明らかにし、各プログラムがハイブリッド境界のどちら側に属するかを決定します。具体的には、WORKING-STORAGEにハードコードされた認証情報、暗号化キーの処理、監査ログの生成（またはその欠如）、および規制資本に影響を与える計算パターンなどが含まれます。これらの知見は、規制対象ワークロードのハイブリッド境界配置に先立って実施する必要のあるコンプライアンス設計作業を支援します。
アプリケーション依存関係マッピングは、どのプログラムが他のどのプログラムとデータを共有しているか、つまり、あるプログラムをクラウドに配置することで、予期せぬ境界を越えた規制されたデータフローが発生するかどうかを判断する、プログラム間のデータセットアクセスパターンを示します。運用データのみを処理するように見えるCOBOLプログラムが、別のプログラムによって書き込まれた個人データも含むVSAMファイルからデータを読み取る場合があります。依存関係マップは、ハイブリッド境界が描画される前に、これらのデータ共有関係を可視化します。
影響分析機能により、境界変更の監査が可能になります。プログラムがオンプレミスからクラウドに移行すると、影響分析によって、その移行によって影響を受ける他のすべてのプログラム、呼び出し元、データセットの利用者、JCLジョブストリームが列挙され、規制当局への証拠として、また同等性テストプログラムの基礎として、変更の範囲が提供されます。
エンタープライズ検索機能により、ハイブリッドプログラム全体でコンプライアンスインベントリをクエリ可能になります。特定のデータ型を処理するすべてのプログラム、特定のVSAMクラスタにアクセスするすべてのプログラム、特定のパターンを含むすべてのCOBOLソースファイルを、数百万行にわたって数秒で検索できます。規制対象組織が監査人に対し、対象となるすべてのプログラムが特定され評価済みであることを証明する場合、このクエリ可能なインベントリは、手動による証明に代わる証拠となります。
規制当局はあなたの移行スケジュールを気にしていません
COBOLを運用する規制対象組織にとって、ハイブリッドクラウドは一時的な状態ではありません。多くの組織にとって、ハイブリッドクラウドは恒久的な運用モデルとなっています。これは技術的な制約によるものではなく、データと機能を規制する枠組みによって、特定のワークロードに対するオンプレミスでの制御が永続的に求められるためです。問うべきは「メインフレームからどのように移行するか」ではなく、「どのワークロードをクラウドに移行できるか、どのようなコンプライアンスアーキテクチャの下で、境界が適切に制御されていることを示す証拠は何か」なのです。
ハイブリッド構成により、組織はオンプレミスの既存コンポーネントを維持しながらクラウド統合を実現できる柔軟性を得られます。規制対象業界においては、この柔軟性はオプションではなく、特定のワークロードカテゴリにおいては必須となります。ハイブリッドCOBOLアーキテクチャで成功を収める組織は、コンプライアンス境界を明確に設計し、最初から監査可能性を考慮した対策を講じ、規制証拠の作成を後付けの文書化ではなく、アーキテクチャ上の要件として捉えている組織です。
