z/OSに対するセキュリティシステム監査(ID関連各種)

inukiti

IDにおいて特権以外に考慮すべき事項を記載いたします。

初期導入IDについて

RACFを導入する場合にデフォルトで作成されるIDがいくつか存在します。

IBMUSERについて

RACFを導入し、各種セットアップを実施するためにIBMUSERがデフォルトで作成されています。

初期導入IDには、SPECIAL 属性および OPERATIONS 属性が付与されており当該IDを使用してRACFの各種設定を実施いたします。また、下記のマニュアルに記載されている通りIBMUSERを使用して他の管理IDを作成して、IBMUSERについてはREVOKE設定としてください。
（初期導入IDは、広くどのシステムにも存在しているユーザーIDであることから不正なアクセス試行のターゲットとなることから使用することは望ましくありません）

RACF上に存在するダミーID

RACFがシステム稼働を行うために導入時から導入されており変更・削除等ををシステム的に制限されているIDが存在しています。対象のIDは、irrcerta、irrmultiおよび irrsitecです。

https://www.ibm.com/docs/ja/zos/2.3.0?topic=certificates-irrcerta-irrmulti-irrsitec-user-ids

代理ジョブ実行依頼の許可

通常JCLを実行する場合には、JCLの最初のステートメントにIDを指定する必要があります。TSO等のシステムにログインしてJCLを実行した場合、ログインIDとJCLで指定されたIDが同一であればパスワードを指定しなくてもJOBは正常に実行されます。

一方でログインしたID以外でJCLを実行する場合にはIDに加えて、パスワードを最初のステートメントに指定する必要があります。パスワードが指定されていないまたは誤っている場合にはJOBは正常に実行されません。

しかし、JCLにIDおよびパスワードを記載するのはパスワード漏洩リスクがあることがあり、そのような対応を防ぐために代理ジョブ実行権限を付与する場合があります。

具体例
「ID：USER01」に「ID:ADMIN01」の代理ジョブ実行権限を許可し、「USER01」でログイン後に、JCLの最初のステートメントに実行IDとして「ADMIN01」を指定します。パスワードを未記載ででJOBを実行しても「ADMIN01」の権限にて実行されます。

代理ジョブ実行権限の問題点は、「ADMIN01」に「OPERATIONS」属性のような特権が付与されていた場合、「USER01」のIDには間接的に「OPERATIONS」属性のような特権が付与されるが、ユーザーIDそのものの権限だけを見ているだけでは特権が伝播していることが把握されない点があります。また、直接「ADMIN01」のユーザーIDを使用していないことから代理ジョブ実行のログを把握していなければ真の実行者を把握できない点にあります。

代理ジョブ実行権限は、一般資源クラスである「SURROGAT」を使用して制御されます。定義方法（確認方法）の概要は次のとおりです。

1.SETROPTSの「ACTIVE CLASSES」に「SURROGAT」に追加する。
2.「SURROGAT」クラスに次のプロファイル名を作成し、該当プロファイルに対して「USER01」に対してREAD権限を付与する。
　 プロファイル名：ADMIN01.SUBMIT
（SURROGATクラスがアクティブであり該当ユーザーIDを指定したプロファイルにREADが付与されているユーザー全てに代理実行権限が許可されます）

他のIDに代理ジョブ実行権限を認めるIDは、代理ジョブ実行専用として作成を行うことも１つの方法です。
その場合には、代理ジョブ実行を認めるIDを「保護ユーザーID」指定としてください。保護ユーザーID指定として場合には、該当IDのパスワードが存在しなくなることから、システムへのログインやJCLへのID・パスワード記載による実行が不可能となります。
（STCユーザーIDまたは代理ジョブ実行のみで使用可能となります）


監査のポイント

初期導入ユーザーID(IBMUSER)を使用不可能な設定としていますか。

代理ジョブ実行権限について必要性を確認していますか。ログ等を使用して代理ジョブ実行者を特定できる運用はありますか。

この記事が気に入ったらサポートをしてみませんか？