システムの悪用を企てる攻撃者の大きな目標の 1 つは、任意のプログラム コードをリモートで実行できるようにすることです。この点に関して、アプリケーション サーバーである Enterprise Server は、まさにそれを行うように、つまりプログラムのリモート実行を可能にすることを前提に設計されています。したがって、実行できるプログラム、およびそれらのプログラムへのアクセスを制限することは、Enterprise Server のセキュリティを強化するうえで重要な要素となります。
Enterprise Server で (ユーザーが用意した) 任意のプログラムが実行される主な状況には、次の 2 つがあります。
- エンタープライズ サーバー リージョンを使用して COBOL サービス指向アーキテクチャをサポートする場合、従来の COBOL アプリケーションが Web サービスおよび Enterprise JavaBeans (EJB) として公開されることがあります。
- Mainframe Subsystem Support (MSS) 機能では、COBOL、PL/I、メインフレーム アセンブラー、REXX で記述されたプログラム、および JCL で記述されたスクリプトを Enterprise Server の CICS、JES、IMS サブシステムで実行できます。
どちらの状況でも、悪意のあるプログラムのリモート実行には、次の 3 つの主な経路があります。
- Enterprise Server にアプリケーションをディプロイする承認済みプロセスを通じ、正当なアプリケーションの一部として悪意のあるコードがディプロイされる。これは、組織の従業員 (開発者など) によって行われるか、アプリケーションのソース コードやビルド パイプラインまたはディプロイ
パイプラインへのアクセスを攻撃者が取得するサプライ チェーン攻撃を通じて行われる可能性があります。本ドキュメントでは、この種の脅威自体については詳しく説明しませんが、いくつかの注意事項を以下に示します。
- 既存の正当なアプリケーションが悪用される。これは、アプリケーションのセキュリティを強化し (これも本ドキュメントの範囲外です)、アプリケーションへの不正なアクセスを制限することで軽減できます。
- 攻撃者は悪意のあるアプリケーションをエンタープライズ サーバー リージョンにディプロイできる。これは、攻撃者が正当なアプリケーションを侵害するのではなく、まったく新しいアプリケーションをディプロイするという点で、従来のサプライ チェーン攻撃とは異なります。組織の承認済みディプロイ メカニズムが利用される場合もあれば、別のメカニズムが利用される場合もあります。
コードのリモート実行を防ぐためのアプリケーション セキュリティの強化
アプリケーションのセキュリティにより、多くの側面に対応できますが、次の潜在的な脆弱性については、特に注意して対処する必要があります。
- CALL "SYSTEM"、ファイル入出力を含むパイプ構文などを使用した外部プログラムの実行。
- CALL 文を使用したプログラム オブジェクトの動的ロード。これは、プログラムの名前またはパス情報が攻撃者によって制御される可能性がある場合に発生します。プログラム名のリテラルではなくデータ項目を使用する CALL 文に注意してください。エントリ
ポイント名のマッピングも潜在的なベクターとなります。CICS プログラムの場合、EXEC CICS LINK および EXEC CICS XCTL の危険な使用に注意してください。
既存のアプリケーションおよびプログラムへのアクセスの制限
エンタープライズ サーバー インスタンスでホストされているアプリケーションへのアクセスを制御する方法は、次のとおりです。
- アプリケーションのセキュリティ機能。ユーザーにサイン オンするよう要求したり、承認済みアクセスを内部的に適用したりします。これは本書の対象外となります。
- セキュリティ構成のリソース アクセス制御ルール。これに該当するのは、MSS アプリケーションのみです。COBOL Web サービスおよび EJB では、現在、外部セキュリティを使用していません。これに該当するリソース クラスには、CICS の
TCICSTRN クラスおよび MCICSPCT クラスや、IMS の TIMS クラスがあります。JES には同等のリソース チェックはありませんが、JESINPUT クラスを使用してジョブのサブミットに対するアクセスを制御できます。
- 通信セキュリティ。プログラムのリモート実行にはネットワーク通信が必要なため、攻撃者がリージョンに接続する方法を制限することで、脆弱性を部分的に軽減できます。これには、リスナーが使用するインターフェイスの制限、対話のフィルター処理、クライアント認証での
TLS の使用が含まれます。TN3270 経由での接続後にサイン オンを要求するなど、接続の確立後に通信を保護することもできます。
JES エンジンへのジョブのサブミットは、JES が有効になっているエンタープライズ サーバー リージョンでは特に危険な脆弱性となります。問題は、ジョブのサブミットを許可されたユーザーであれば、リージョンのプログラム パス上にあり、Enterprise Server の実行に使用されているシステム アカウントに対する適切な権限を持つ、任意のプログラムを実行できるということです。このようなプログラムでは、PCDSN 構文を使用して、そのアカウントの権限でシステム上の任意のファイルにアクセスできます。
JCL のサブミットに対するアクセスを制限する機能は、必ずしも十分ではありません。Micro Focus では、次のことをお勧めします。
- 環境変数 CASRDO44_NEWSUB=OFF を設定します。これにより、ESCWA または ESMAC を介したローカル JCL のサブミットが防止されます。これらの Web インターフェイスでは、参照による JCL のサブミットしかできなくなります。つまり、サーバー システム上にすでに存在する JCL に限定されます。これにより、任意の
JCL をサブミットする 1 つの方法が防止されます。cassub などを使用して任意の JCL をリモートでサブミットするのを防ぐ実用的な方法はありません。
- JESJOBS クラスで SUBMIT.リージョン.ジョブ名.ユーザー ID という形式のルールを使用して、どのユーザーがどのジョブをサブミットできるかを制限します。
- JESINPUT または TSUINRDR を使用してジョブのサブミットを単一のユーザー ID のみに制限してから、そのユーザー ID を使用するように MFBSI を構成できます。これにより、追加のチェックを実行できるスケジューラーを介してすべてのジョブのサブミットが行われるようになります。
- 考えられるもう 1 つの方法として、JESINPUT または TSUINRDR を使用して直接的なサブミットを完全に禁止し、CICS または IMS (STCINRDR によって制御) およびその他の JCL ジョブ (INTRDR) を介してのみ
JCL をサブミットするようにします。その後、CICS または IMS アプリケーションによってジョブのサブミットに対するアクセスを制御できます。
CICS の場合は、前のセクションで説明したように、管理ユーザー インターフェイスまたは CICS システム API を使用して、承認されていないユーザーによる CICS リソース定義の追加を防止します。これにより、既存のプログラムについて CICS
トランザクションを作成して、またはキュー トリガー プログラムとして指定して実行する攻撃を軽減できます。
任意のプログラムを実行する CRUN CICS トランザクションへのアクセスを無効化または制限します。
悪意のあるアプリケーションのディプロイの防止
この脆弱性は Enterprise Server の COBOL Web サービスおよび EJB 機能に主に該当し、特にリモート ディプロイ機能でリスクが高くなります。リモート ディプロイは開発者にとっては便利ですが、本番環境では常に無効にする必要があります。(有効になっている場合) デフォルトの構成で、誰でも任意のプログラムをエンタープライズ サーバー リージョンにインストールできるため、これは非常に危険な脆弱性です。
ディプロイが有効になっている場合は、追加のセキュリティ対策を構成できます。詳細については、製品ヘルプの「サービス インターフェイスのディプロイのセキュリティ考慮事項」を参照してください。