ある大手銀行の内部で、エンジニアチームが200万行のCOBOLをJavaに変換する作業をつい先日完了した。この移行には14ヶ月を要し、すべてのテストスイートに合格し、予定通り本番稼働したが、最初の1週間以内にセキュリティチームが重大な問題を発見した。クレジットカード番号、社会保障番号、口座残高が、APIエンドポイント、Kafkaパイプライン、および元のメインフレームアーキテクチャでは決して外部に露出することのなかったアナリティクスデータレイクを通じて、無防備な状態で流れていたのだ。
モダナイゼーション自体は成功したが、データ保護は失敗に終わった。このシナリオは、多くの企業が認めたがる以上に頻繁に発生している。
メインフレームのモダナイゼーションへの投資は加速しているが、議論の大半はコード変換、クラウドインフラ、コスト削減に集中したままだ。一方、データセキュリティ——モダナイゼーションプロジェクトがリスクを生むか解消するかを左右する唯一の要素——は、何か問題が起きるまで、その重要性に見合った注目を集めることがほとんどない。
モダナイゼーションが生み出すペリメーター問題
レガシーメインフレームは現代的な意味でセキュアに設計されたものではなく、到達不能であるように設計されていた。IBM z/OS環境は、機密データを保護するために物理的な隔離、RACFアクセス制御、そしてアーキテクチャの難読性に依存しており、何十年もの間、データはペリメーター内に留まっていた。なぜなら、他に行き場がなかったからだ。
モダナイゼーションはこの構図を根本的に変える。なぜなら、組織がCOBOLアプリケーションをクラウドに移植したり、DB2テーブルをデータウェアハウスにレプリケートした瞬間、機密データはこれまで存在しなかったトラスト境界を越え始めるからだ。そして、APIコール、データパイプライン、ダウンストリームのアナリティクスプラットフォームなど、新しい統合ポイントのひとつひとつが、元のセキュリティモデルが保護するように設計されていなかった攻撃対象領域となる。
この課題は、これらのシステムの老朽化によってさらに複雑になる。COBOLコードは誰も完全にドキュメント化していないビジネスロジックと密結合しており、それを書いた開発者たちは退職しつつある。そして、メインフレームを運用するほぼすべての企業が同じポリシーを共有している。エージェントをインストールしない、本番コードを修正しない、ミッションクリティカルなトランザクションを処理するワークロードを中断するリスクを冒さない、というものだ。
コード変換だけでは不十分な理由
AIを活用したコード変換ツールは移行プロセスを加速させ、かつて数年かかっていたものが今では数ヶ月で達成できるようになった。しかし、COBOLをJavaやPythonに変換しても、データがメインフレーム内に存在している間それを保護していたセキュリティ制御は変換されない。典型的なz/OSの展開では、暗号化は専用の暗号処理プロセッサを通じてハードウェアレベルで処理され、アクセス制御はRACFまたはACF2によって強制され、データは厳密に管理されたバッチプロセスを通過することなく外部に出ることはない。
しかし、同じデータがクラウドネイティブ環境に移行すると、保護モデルは一変する。データは複数のサービス、リージョン、プロバイダーにわたって分散され、PCI DSS、HIPAA、GDPRのもとでのコンプライアンス範囲は、z/OSを離れた後に機密データに触れるすべてのシステムにまで拡大する。移行開始前にデータ保護戦略を設計しなければ、組織はセキュリティをモダナイゼーションしたというよりも、リスクを移行したにすぎないと気づくことになるだろう。
メインフレームに手を加えずにデータを保護する
モダナイゼーションの最中およびその後にデータを保護するための最も実践的なアプローチは、アプリケーション層ではなくネットワーク層で機能する。この違いが重要なのは、レガシーCOBOLアプリケーションの修正はほとんど現実的ではなく、本番メインフレームへのエージェントインストールは許容できない運用リスクをもたらすからだ。エージェントレスのデータ保護ソリューションは、メインフレームとダウンストリームシステムの間を流れるデータをインターセプトし、メインフレームのコード、データベーススキーマ、既存のワークフローを変更することなく、機密フィールドをリアルタイムでトークン化、マスキング、または暗号化する。そして、優れたメインフレームのアップグレード・モダナイゼーションソリューションは今や、このようなインラインセキュリティを後付けではなく中核コンポーネントとして統合している。
特にトークン化は、メインフレーム環境で運用する企業にとって好まれる手法として台頭してきた。フォーマット保存型トークンは、レガシーの検証チェックが期待するデータ構造——クレジットカード番号のLuhn検証など——を維持しながら、トークンと元の値との数学的な関係を排除する。これにより、トークンはクラウドパイプライン、アナリティクスプラットフォーム、サードパーティ統合を通じて流れることができ、機密データを露出させることなく、一貫したフォーマットに依存するダウンストリームシステムを壊すこともない。
移行前に企業が評価すべきこと
メインフレームのモダナイゼーション計画を立てている組織は、最初のワークロードが移行される前に、データセキュリティの状況を評価すべきだ。具体的には、メインフレームのデータベースとアプリケーションデータストア全体において機密データがどこに存在するか、どの移行パスがそのデータを新しい環境に露出させるか、そしてデータがクラウドに到達した後も保護がどのように維持されるかを確認する必要がある。モダナイゼーションを正しく実施する企業は、データセキュリティを最初から設計上の制約として扱い、後付けのコンプライアンスチェックボックスとは見なさない。一方、失敗する企業は、自分たちがすでに持っていたものの、より速く、より安く、そしてはるかに脆弱なバージョンを構築してしまったことに——しばしば手遅れになって——気づく傾向がある。
