z/OSに対するセキュリティシステム監査(アクセス許可検査の整理)

inukiti

RACFにおけるアクセス許可検査について

RACFにおけるアクセス権限許可検査は下記のマニュアルにて非常に丁寧かつ網羅的に説明がされていますが全てを理解することは難しいことから、監査等で確認すること、理解することが前提となる部分を中心にご説明します。
（かなり簡略化していることから厳密性がないことをご了承ください）

いくつかの例題

次のようなパターンの権限が設定されていた場合にはアクセスが許可されるか、許可されないでしょうか。

  • あるUSERA（所属グループ：GROUPA)が、UACC（NONE）のプロファイルで保護されているデータセットの更新を行おうとした。USERAのPERMITは次のように設定されているが更新は許可されるか。
    　USERA　:READ
    　GROUPA:UPDATE

  • OPERTAION特権を持つADMINA（所属グループ：GROUPB)が、UACC（NONE）のプロファイルで保護されているデータセットの更新を行おうとした。ADMINAのPERMITは次のように設定されているが更新は許可されるか。
    　AMMINA  :READ
    　GRUOPB：UPDATE

実は、上記の２つのパターンについてはアクセス権を許可されません。これにはアクセス許可検査の順番が関与しています。また、今までご説明してきた「グローバルアクセス権限検査」等の許可検査の順番も含めてご説明します。

アクセス許可検査の概要

上記で示したマニュアルから特に関係する部分を抽出すると次のような流れでアクセス許可検査が実施されます。

アクセス許可検査の概要
（概要なので一部不正確な部分があります）

①（STCユーザーID限定）「PRIVILEGED」または「TRUSTED」の確認

STCユーザーIDというシステム稼働において使用するIDに限定した許可検査となります。STCユーザーIDにて該当するシステムタスクが「PRIVILEGED」または「TRUSTED」のどちらかの属性を持つ場合には該当のデータセットへのアクセスを許可し、許可検査を終了します。
（STC関連については別記事に説明します）

②グローバルアクセス権限テーブルの確認

DSMONの「RACF グローバル・アクセス検査表報告書」項目等にてご説明したグローバル・アクセス検査テーブルとなります。該当するテーブルに定義がありアクセス権限が満たされていれば該当のデータセットへのアクセスを許可し、許可検査を終了します。
「SETROPTS LIST」でもご説明した通り、当該項目はCPUやメモリー等が高価であった時代に許可検査の効率化のために設けられた機能です。現代ではCPUやメモリー等の性能が向上したことであまり使用されない機能ですが、詳細な許可検査をバイパスする範囲が適切であるかを確認する必要があります。
（データセットプロファイルが存在していてもグローバルアクセス権限テーブルに定義があれば無視されます）

③データセットプロファイルの確認

該当のデータセットを保護するプロファイルの存在を確認します。プロファイルがあればプロファイル定義詳細での許可検査を実施したします。

プロファイルがない場合には、「SETROPTS LIST」の「PROTECT ALL」の項目でご説明したオプション設定に従い、許可検査を終了します。

PROTECT ALLがアクティブである
　アクセスを許可する。
PROTECT ALLがアクティブでない
　アクセスを拒否する。ただし、OPERATION属性を持つユーザーIDの
　場合は許可する。

④ID個別のPERMITの確認

プロファイルのPERMIT情報にて、ID個別にPERMITが付与されているかを確認する。
PERMITが付与されていない
　⑤のアクセス許可検査に進む
PERMITが付与され権限を満たす（参照時にREAD権限以上がある場合）
　アクセスを許可し、許可検査を終了する。
PERMITが付与され権限を満たさない（更新時にUPDATE権限未満の場合）
　アクセスを不許可し、許可検査を終了する。

⑤グループ個別のPERMITの確認

プロファイルのPERMIT情報にて、グループ個別にPERMITが付与されているかを確認する。
PERMITが付与されていない
　⑥のアクセス許可検査に進む
PERMITが付与され権限を満たす（参照時にREAD権限以上がある場合）
　アクセスを許可し、許可検査を終了する。
PERMITが付与され権限を満たさない（更新時にUPDATE権限未満の場合）
　アクセスを不許可し、許可検査を終了する。

グループでPERMITされ権限が充足していても、個別IDでのPERMITが優先される。

⑥UACC値の確認

プロファイルのデフォルトのアクセス権限レベル（UACC値）を確認する。
UACC値が権限を満たす
　アクセスを許可し、許可検査を終了する
UACC値が権限を満たさない
　⑦の許可審査に進む

⑦オペレーション属性の確認

ユーザIDにオペレーション属性が付与されているかを確認する。
オペレーション属性がある
　アクセスを許可し、許可検査を終了する
オペレーション属性がない
　アクセスを不許可し、許可検査を終了する

オペレーション属性は、データセットに対する無制限アクセスではなくUACC値を無視して許可する設定である。そのため、オペレーション属性のIDに個別にPERMITを行うことで権限を制限することが可能である。オペレーション属性の権限を制限する場合は次のような場合が考えられる。

  • 同一システム内で複数社のデータを処理しており、アクセス権を各社毎に制限する場合

  • ID登録・削除等の自動化バッチジョブ等でパスワード情報を含むデータセットのアクセス権をSPECAIL属性を持つユーザーIDにのみ限定する場合

その他アクセス許可検査での考慮事項

データセットプロファイルのWARNING指定

アクセス権限を新たに制限することはシステム障害等を引き起こす可能性がある変更作業です。変更しなければシステム障害等は発生しませんが、セキュリティ上のリスクが残ります。

このようなジレンマを解決するために使用するのが、「WARNING指定」となります。特定のデータセットプロファイルに「WARNING指定」を行うと、上記の④〜⑥にて権限不足でアクセス不許可となって場合にシステム管理用のコンソールに「WARNINGメッセージ」が出力された上でアクセスが許可されます。
このようなWARNING設定にて一定期間稼働を行い、不足している権限を個別に追加後してWARNING設定を解除することでシステム障害等の発生を低減しつつ安全にアクセス権の変更を行うことができます。年次処理等を考えてもWARNING設定は最長１年程度が通常であることから、WARNING設定が存在する場合には設定時期をシステム担当者へのヒアリングまたは過去の設定変更証跡等で確認する必要があります。

監査のポイント

グローバルアクセス権限テーブルにおいて許可検査がバイパスされる範囲が適切ですか。

OPERATION属性を持つユーザーIDについて、システム特性上アクセスを不許可とすべきデータセットはありませんか。

データセットプロファイルについてWARNING設定は適切ですか。
（１年以上設定されていませんか）

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