RACFクリーンアップ
不要なRACF定義がいつまでも残存してセキュリティリスクを放置していませんか？
例えば、ユーザーIDやGROUPを単純に削除しても、そのユーザーIDやGROUPがプロファイルのオーナーとなっている場合、そのプロファイル情報はRACFのデータベースに残ったままとなります。すると、新規でユーザーIDを作成した時に、プロファイルに定義されていた削除したユーザーIDと同名だった時に意図せずプロファイル定義も引き継いでしまうことになります。
これを防ぐためには、ユーザーIDやGROUPを削除する時は、それに紐づくプロファイル定義も確実に削除する必要がありますが、その手順は複雑で手間がかかります。また、既にRACFデータベースに不要なユーザーIDやGROUPが残っている場合は、セキュリティリスクを放置してしまっていることになるため、対策が必要です。
不要な定義が多くあると
RACFのオーバーヘッドが余計にかかります
パフォーマンス低下
素早いチェック
パフォーマンスUP
不要な定義が存在している ⇒ セキュリティリスクに直結
- beta accessを使えば、これらの課題を手間や時間をかけずに解決できます。
RACFデータベースのクリーンアップ機能
- 存在しないユーザーID、GROUPに対して与えられているPERMITを洗い出し、一括削除する（PERMITの一括削除）
- 存在しないユーザーID、GROUPがUser notifiesに指定されているものを洗い出し、一括削除する（User notifiesの一括削除）
- プロファイルのオーナーが存在しないものを洗い出し、適切なオーナーに変更する（プロファイル情報の変更）
ユーザーID、GROUP削除時に、関連するものを全て同時に削除する機能
- 不要なRACF定義がクリーンアップされることで、CPUパフォーマンスも向上します
実機検証
不要定義を大量に含むRACF DBとCLEAN状態のRACF DBでJOBの処理時間がどれくらい異なるか検証を行いました。RACF DBの99%が不要定義という極端なケースから不要定義なしのクリーンなRACF DBのケースまで同じテストプログラムを実行しています。
不要定義99%の場合
ユーザー数：10万
データセットプロファイル数：100万件
RACF DB Size: 550 CYLs
不要定義0%の場合
ユーザー数：100
データセットプロファイル数：200件
RACF DB Size: 550 CYLs
テストプログラム
- RARACROUTE REQUEST=AUTHを繰り返し発行するプログラムで検証しました。
- SMF Record Type 30でテストJOBのELAPS/CPU/EXCP Timeを計測しました。
- 不要定義率が10%づつのケースでテストしました。最高は99%
環境情報
- Native LPAR 1CP/8GB
- CPU：IBM z15 8562-T02 (12MSU)
- Disk：IBM DS8910F 5334-993
検証結果
今まで、RACF DBの不要定義を削除すれば、システムのパフォーマンスは向上するのではないかと長年思っていましたが、お客様にご提案できるまでのテスト検証を行うことができませんでした。z15実機を社内に設置したことでこの結果を得ることができ、不要定義率にほぼ比例してシステムパフォーマンスが向上するという結果を得ることができました
ELAPS時間比較
CPU時間比較
EXCP時間比較
