z/OSに対するセキュリティシステム監査（RACF-DBとは？）
RACF-DBとは
RACFにはDBがあり、問い合わせに対してRACF-DBの定義情報と照合して回答を行なっているとご説明しました。RACF-DBの定義情報は環境によって違いはありますが、大きいところでは数万から数十万レコードに及ぶことがあります。RACF-DBには、次のような情報が含まれています。
ユーザーIDに関する情報
z/OSのTSO等で使用するIDおよびパスワード、付与されている特権、ログインできるモード（ログインプロシージャー）等の情報が含まれています。また、統計情報として最終ログイン日やログイン回数等も保存されています。
（最終ログイン日はRACF-DBで確認できますが、過去のログイン一覧はSMF等のログを確認する必要があります）
グループに関する情報
z/OSのIDは場合によっては数千単位で定義されることも珍しくありません。そのような場合に個別に権限を設定していたのでは管理が煩雑になることからz/OSでは「グループ」と言う概念が開発されました。
グループとは簡単に言えば権限セットを定めておき、ユーザーIDがそのグループに所属することでグループの権限が適用される概念です。
データセットへのアクセス権限に関する情報
一定範囲のデータセットを指定して同一の権限を設定する総称プロファイルと単一のデータセットのみに対して権限を設定する単体プロファイルを使用する方法があります。RACF-DBには、データセットに対するアクセス権限に関する情報が保管されています。
その他資源へのアクセス権限に関する情報
コマンドの発行権限やミドルウェア等の特定機能を使用できる権限に関する情報が保管されています。
RACF全体の設定情報
ログインパスワードに求めるパスワードルール、アクティブになっているRACF機能などRACF全体に対する設定が保管されています。
RACF-DBの仕様
RACF-DBはどこにあるか？
RACFのシステム監査向けユーティリティ実行結果である「DSMON」の「選択されたデータ・セットの報告書」のRACF PRIMARYおよびRACF BACKUPに記載されているデータセットがRACF-DBとなります。
（DSMONに関する詳しい解説は別記事にて行います）
RACF-DBはプライマリーとバックアップの２つが存在しており、プライマリー側に障害が発生した場合にはバックアップへの切り替えを行います。プライマリーおよびバックアップの両方同時にハードウェア障害等が発生しないように異なる実装置上でかつ、異なるパス（経路）に構築する必要があります。
RACF-DBの暗号化（ハッシュ化）
RACF-DBには、パスワード情報が含まれておりパスワードを保管する場合は、暗号化（ハッシュ化）を行う必要があります。
RACFについてもパスワードを暗号化（ハッシュ化）する方法が存在しており、適切な方法を使用して暗号化（ハッシュ化）を行う必要があります。実装法については、下記にマニュアルの該当箇所を示します。
暗号化方式は、RACF側から提供されている方式（z/OSバージョン等に依存）やEXIT等を使用したユーザー独自の方式もあることから、監査人では簡単に確認することが難しいのが現状です。そのため、セキュリティ担当者にどの方式で暗号化（ハッシュ化）を行なっているかを確認し、ヒアリングに基づいてシステム設定証跡の提出を依頼すると良いでしょう。
その上でパスワードの暗号化（ハッシュ化）の強度が「電子政府推奨暗号リスト」等を参考に必要な強度が保たれているかを確認してください。
RACF-DBの保護要件
RACF-DBには暗号化（ハッシュ化）されているとは言え、パスワード情報が含まれており、またセキュリティ設定の全てが格納されています。
悪意のある第三者に閲覧された場合にセキュリティ等の脆弱性を突かれる可能性があることから一般ユーザーIDのアクセス権限を不可（UACC=NOE）とし、業務上必要なるメンバーにのみ個別に権限を付与する必要があります。
z/OSにおけるRACF-DBを含むシステム系データセットのアクセス権限については下記のマニュアルが参考となります。
（表１内のセキュリティー定義データ・セットに該当します）
また、RACF-DBの暗号化要件の章にも参照権限を付与しない旨、明示的に記載されています。
RACF-DBの切り替え
RACF-DBには全てのセキュリティ情報が含まれており何らかの要因によりRACF-DBの情報が破損した場合にはシステム稼働に影響が発生することからバックアップ等に速やかに切り替えを行う必要があります。そのような状況が発生した場合に備えて、RACF-DBの切り替えコマンドが用意されています。
RACF-DBの切り替えコマンドを悪用した場合には、任意のデータセットを新しいRACF-DBに指定することが可能であり、セキュリティ設定が悪意のある第三者に書き換えられる可能性があることからRACF-DBの切り替えコマンドを制限する必要があります。
悪用を防ぐために、当該コマンド発行時に切り替えようパスワードを要求する設定が用意されています。
（当該設定の確認方法は、別途「SETROPTS」に対する記事にてご説明します）
RACF-DBの共有
金融系のセクターでは、本番系だけで10区画以上のz/OSが稼働が稼働しているのも珍しくありません。区画が増えると運用担当者IDの増減に伴う作業で10区画それぞれのシステムに対して作業を行う必要があるのなど管理を行う上で負荷が大きくなります。
運用負荷等を軽減するために、RACF-DBを複数の区画で共有することが可能であり共有している区画ではRACF側の設定は同一となります。
（AのシステムにIDを追加すれば、共有しているBのシステムにもIDが反映されます）
被監査システムのRACF-DBの共有状況については、被監査システム確定時のイニシャルQAにてシステム担当者に確認することが望ましいです。
監査ポイント
RACF-DBは単一障害点にならないように構成されていますか。
RACF-DBのパスワードは適切な方法で暗号化（ハッシュ化）されていますか。暗号化（ハッシュ化）の強度は適切ですか。
RACF-DBのアクセス設定は必要なメンバーに制限されていますか。
RACF-DBの切り替えは制限されていますか。また、切り替えパスワードは正しく保管されていますか。
RACF-DBを本番環境と開発環境で共有していませんか。
この記事が気に入ったらサポートをしてみませんか？