Zマイスターとの新たな価値探求 Tivoli

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、

最新化がもたらす価値

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、最新化がもたらす価値

Syかがemｚは IBM メインフレームの 45 年以上の歴史において、多くのお客様の基幹シ

ステムを支えるインフラとして採用され、現在も最新のビジネス・ニーズに対応すべく、ハー

ドウェア、ソフトウェア共に進化し続けているプラットフォームです。技術の進化、移り変

わりの激しいＩＴ業界の歴史においても、これだけ長く、継続してお客様に価値を認めて

いただいているプラットフォームは、他に例が無いでしょう。

そのことを裏付ける事実として、全世界の市場を見てみると2010 年から2012 年にかけ

て、Syかがem ｚのビジネスは飛躍的な伸びを示しています。一方で、日本の市場におい

ては、日本国産ベンダーのメインフレームのイメージを元に、メインフレームに対するネガ

ティブなイメージが散見されています。そのイメージを払拭するために、進化・発展してき

た IBM Syかがem ｚが提供する機能とそれによって得られるメリットをより分かり易い形に

整理し、お伝えできるように取り組みを進めています。

本コラムでは、最新のバージョンに移行して頂いた暁に、活用頂ける最新のソフトウェア

の機能と、最新化がもたらす価値について、主要なミドルウェアの切り口から、お届けい

たします。

先輩：

IT部門のシニアな社員。

豊富なメインフレーム経験を持つ。

自称“zマイスター”

後輩：

IT部門若手社員。

メインフレームが主担当だが

オープン系も一部担当する。

登場人物

【第4章】 Tivoli ① 操作の自動化から管理の自動化へー Tivoli Syかがem Aきがomaがion foお z/OSによる運用自動化ソリューションー

6261

第4章

Tivoli

近年、ビジネス及び社会におけるIT システムへの期待値は益々高まり、IT をより効率的に活用

するためのシステム運用の役割は一層重要度を増しています。IBM は 1964 年のメインフレーム

発表以来、早くからシステム管理の必要性に着目し、多くのお客様の運用業務の効率運用ソリュー

ションをベスト・プラクティスとして整理し、製品化してきました。IBM Seおvice Managemenが

Cenがeお on Syかがem z では、広く業界で認知されている運用メソドロジーをベースに、運用業務を

補完する各種ツールを提供しています。さらに複数のツール間の連携機能を利用して運用の統合

を図ることで、より柔軟性の高い、高信頼性・高可用性を実現した高品質な運用インフラストラク

チャーが構築できるように設計されています。

IBM Seおvice Managemenが Cenがeお on Syかがem z を支えるTivoli 製品群は、プラットフォームに

拠らない同一の設計思想を持つことで、その接続性と拡張性を高めています。運用管理レベル

の向上に併せ、さまざまなツールを自由に組み合わせてより広範囲・高品質な運用を実現できます。

1操作の自動化から管理の自動化へー Tivoli System Automation for z/OS による運用自動化ソリューションー

後輩：あーまいった。グループ・リーダーになった途端にアプリケーションの ABEND なんて…。

先輩：おいおい、何をぶつぶつ言っているのかね？　何かやらかしたのかい（笑）

後輩：マイスター先輩ー！　聞いてくださいよ！　ボクが指導した新人の作ったアプリが本番稼働開

始した途端に ABENDしちゃって、原因究明に時間がかかるわ、周りから散々怒られるわで、

今日はホントについてない…。

先輩：いやいや、ついてないんじゃなくて、原因があっての結果だろ？　で、ABEND の原因は

なんだったんだい？

後輩：実は DB 更新かけるアプリケーションだったんですけど、アプリを稼働させるユーザー ID

に RACF のアクセス権限が足りてなかったんです。

先輩：足りてなかったんじゃなくて、新しいユーザー ID を作ったのにアクセス権限の付与申請を間

違えた君たちの責任てことだろ？

後輩：わー、マイスター先輩まで言わないでくださいよー、滅茶苦茶反省してるんですから！　

その上、ABENDしたことをすぐに気づかないで放置したとか、ABEND の原因をすぐに

報告できなかったとか、今日は朝からもう怒られまくり…。

先輩：せめてそのアプリの ABEND のメッセージが自動監視対象になっていれば、君んとこに電

話がかかってくるから放置せずに済んだのにね。

後輩：えっそういうユーザー・アプリも自動監視できるんですか？　うちのシステムの自動化とい

えば、OS の IPL の一連の操作は自動化しているってのは聞いていたけど。

先輩：勿論！　そもそも、うちの OS の IPL 自動化ってのは、OS コンソールで順番に開始コマン

ド叩いてっていう操作を自動化しているわけでないんだよ。

後輩：えっそうなんですか？

先輩： IPL 処理の中で出力するメッセージの監視や障害時の処理、進捗状況の確認も自動化して、

イレギュラーな状況にも自動対応していかないと、っ管理の自動化、にならないからねえ。

後輩：そりゃそうか…。


63


64

　メッセージ監視と通知処理の自動化

先輩：自動化の基幹製品で、Tivoli NeがVieく foおげ/OSっていう製品は知っているかな？

後輩：はあ、名前は…。

先輩： NeがVieくの原型は 1980 年初頭からあるネットワーク管理製品なんだ。その後 NeがVieく

という名前になった 1986 年までには、ネットワーク・イベントだけではなく、WTO メッセー

ジとして出力するメッセージは全て監視・自動化対象に出来るようになり、NeがVieく自動

化タスクというプロセスで、コマンドや CLIST と呼ばれるプログラムを自動起動することが

可能になったんだ。（図 1）

図 1：NeがVieく foおげ/OS　メッセージ & イベント監視と自動化の仕組み

後輩：これまた、昔からある製品なんですねえ。

先輩： IT 技術の拡大に伴い、監視対象のイベントやメッセージ種も増加し、自動化の範囲も単純

な時間起動やメッセージ・トリガーのコマンド発行処理だけではなく、分散サーバーとのイ

ベント送受信も可能になっているんだ。（図 2）

図 2：NeがVieく foおげ/OS イベント・オートメーション・サービス機能によるエンドツーエンド管理

後輩：監視メッセージはどうやって定義するんですか？

先輩：メッセージ・テーブルという定義体があってね、そこに登録したメッセージが WTO メッセー

ジとして出力したら、全てトラッキング対象と出来るんだ。メッセージ登録は汎用指定も

可能だから、今回のケースでは、特定重要アプリの ABEND ではなく、全てのアプリの

ABEND をも管理コンソールに通知するようにしておけばよかったんだな。

後輩：なるほど。そうすれば ABENDした途端にボクに連絡が来たはずだったんですね。でも、

今回のケースみたいに監視メッセージ登録に漏れがあったら、自動監視ツールとしてはちょっ

と不完全ってことになってしまうんじゃないですか？

先輩：おっ、いいところに気がついたねえ。うちの運用部は最初、過去のログを分析して監

視メッセージを決定したんだが、最近はより完全性を高めるために、Tivoli Sけかがem

Aきがomaがion foおげ/OS の自動化テンプレートで提供されるメッセージ・テーブルのサンプ

ルも使っているよ。最近はげ/OS だけではなく、IMS や DB2、WAS の監視必須メッセー

ジもサンプル提供されているしね。バージョン・アップ等で追加された重要メッセージは、

運用部がミドルウェアの非互換項目をひとつひとつチェックするまでもなく、Tivoli Sけかがem

Aきがomaがion foおげ/OS の製品の修正情報（APAR）として提供されるんだ、なかなか便

利だよ。


65


66

　ポリシーベースの自動化

後輩： Tivoli Sけかがem Aきがomaがion foおげ/OS、ですか？

先輩：そう。略して TSA foおげ/OS。NeがVieく foおげ/OS の自動化機能を利用して、げ/OS 資

源や DB2、IMS 等のミドルウェアやアプリケーションの起動・停止・リカバリー処理を行う

んだ。

後輩： NeがVieく foおげ/OS だけとはどう違うんですか？

先輩： NeがVieく foおげ/OS では、まず監視メッセージを登録して、メッセージ処理する自動化タ

スクのアサイン方法を決めて、自動化する処理をメッセージに紐付けて、という定義が自動

化処理ごとにひとつずつ必要になる。自動化処理が複雑なら、複雑なプログラム開発が必

要になる。対して TSA foおげ/OS では、どの資源を自動化対象として、どのメッセージを

監視するか、どんなコマンドを実行するか、の自動化方法を自動化ポリシー DB に登録して

管理する。対象となるのは複数の OS だから、OS を跨るアプリケーションの資源の連携自

動化も簡単に定義できる。さらに、げ/OS や IBM 製品の自動化に関しては自動化ポリシー

のテンプレートを提供していて、ユーザー環境のサブシステム名をパラメーターとして DB

に登録すれば、そのまま自動化システムが構築できるようになっているんだよ。

後輩：なるほど、自分で自動化対象資源の精査をしたり、直接 NeがVieく foおげ/OS にメッセージ

登録したり、CLIST 等自動化プログラムを開発したりの必要がなくなるってことですね。

先輩：その通り。また、自動化タスクのアサインとかメッセージ待ちとかオペレーター通知処理とか、

複数の NeがVieく CLIST で重複して利用するようなプロセスは、TSA foおげ/OS では共

通ルーチンとして汎用化してモジュール化し、プロセス処理の単純化とパフォーマンス向上

を図っている。また、監視資源が活動中か自動化中か、といった状況をっステータス、とし

て管理することで、自動化処理の前にいちいち確認コマンドを叩いて…という煩雑なことも

しないですむようになっているんだ。（図 3）

後輩：ほー、データの一元管理とプロセスの統合で、運用の SOA 化実現って感じですね。

先輩：うまいこというねえ。さらに、VTAM 開始確認後 TSO を開始するとか、JES 停止前にプ

リンターやネットワークを非活動化する必要があるだろう、そういう資源の関連性は依存関

係定義としてあらかじめ定義されているんだ。また、アプリケーション単位に関連資源をグ

ルーピングして、グループ制御させることも出来るんだよ。（図 4）

後輩：あ、以前 LPAR1 で障害発生した時、直後に LPAR2 でオンラインが稼働開始したのって、

この機能を利用していたんですか？

図 3：NeがVieく foおげ/OS と Tivoli Sけかがem Aきがomaがion 利用時の自動化プロセスの比較

図 4：Tivoli Sけかがem Aきがomaがion の自動化ポリシー定義例


67


68

先輩：そうだよ。Sけかpleぐ環境の自動化処理もお手の物だ。迅速かつ確実なリカバリー、あれは

まさに自動化ソリューションの本領発揮だったな。

後輩：そういえば、先輩は最初「自動化の進捗管理」って言われましたけど、どこまで自動化処

理が進んだ、というのは一目でわかるようになっているんですか？

先輩：勿論。TSA foおげ/OS では、管理資源全てのステータスがリストできるし、各資源が最後

に出力したメッセージも確認できるパネルが用意されている。業務別とかシステム別に資源

をまとめて表示するように、パネルのカストマイズもできるんだ。うちでも統合コンソール

は TSA foおげ/OS のカストマイズ機能をフル活用して独自カストマイズしているけど、見た

ことないかな？

後輩：あ、あの運用ルームのど真ん中にあるやつですね？

先輩：そうそう。

　運用業務の統合

後輩：ところで、自動化のトリガーになるのは、ネットワーク・イベントと WTO メッセージだけな

んですか？　メッセージが何も出てないけどアプリケーションのレスポンスが悪くなってい

るってこと、ありますよね？　そういうのは監視できないんでしょうか？

先輩：パフォーマンス監視のツールは知っているかな？

後輩：うちでは OMEGAMON シリーズを使っていますよね？

先輩：そう、TSA foお　げ/OS は OMEGAMON と直接データやコマンドをやりとりするための

API を標準搭載している。OMEGAMON のパフォーマンス・データが閾値を超えた時に、

TSA foおげ/OS へ即時アラートする機能があるんだよ。

後輩：なるほど！　それをアプリのパフォーマンス悪化として自動通知する仕組みが作れるんで

すね？

先輩：その通り。さらに、TSA foおげ/OS は OMEGAMON に直接コマンドを発行することも出

来る。TSA foおげ/OS からタイマー・コマンドを発行することで、OMEGAMON が収集し

たパフォーマンス・データを定期的にチェックすることも可能だよ。（図 5）

図 5：Tivoli Sけかがem Aきがomaがion と OMEGAMON との自動化連携

後輩：ほかにもTSA foおげ/OS と直接連携できる運用ツールはあるんですか？

先輩：バッチ・ジョブ運用管理の Tivoli Woおkload Schedきleお foおげ/OS （TWS foおげ/OS）

との連携機能もあるよ。バッチ・ジョブの遅延やエラーの TSA foおげ/OS への通知のほか、

バッチ・ジョブ終了後にオンラインを立ち上げるとか、TWS 管理のジョブとして TSA foお

げ/OS の処理を起動する等、密接な双方向連携機能が用意されているんだ。

後輩： TSA foおげ/OS はまさにメインフレームの自動化インフラストラクチャーの中枢製品なんで

すね。

　最新機器への対応

先輩：最新の TSA foおげ/OS ではげEnがeおpおiかe の自動化も出来るんだよ。

後輩：え？　げEnがeおpおiかe 上で動くげ/OS だけじゃなくて、プロセッサーの自動化ということで

すか？

先輩：そう。元々 TSA foおげ/OS は S/370 時代からプロセッサーのハードウェア・コンソール

とコンソール API コードを導入した PC 経由で接続し、メッセージ受信やコマンド送信を

行う機能を持っていたんだ。Haおdくaおe Managemenが Conかole （HMC）が提供され

る CMOS プロセッサー以降では、コンソール API がプロセッサー側に標準搭載される

ようになったんだけど、TSA foおげ/OS はその API を利用してパワー・オン・リセットや

OSロードの処理のほか、CP追加やCBU操作のようなハードウェア構成変更やハードウェ

ア・イベントの収集も出来るんだよ。


69


70

後輩：じゃ、同じようにプロセッサーの API 経由でげEnがeおpおiかe とも接続できるということです

ね。でも、げEnがeおpおiかe って AIX とかブレードが稼働するげEnがeおpおiかe BladeCenがeお

Eぐがenかion（げBX）部分がありますよね？

先輩：その通り。げEnがeおpおiかe ではげBX を含むパフォーマンスや構成、操作の統合管理のため

に Uniでed Reかoきおce Manageお（URM）という機構が新しく搭載されるようになっただろ

う？　最新版 V3.4 の TSA foおげ/OS は URM の API と連携する機能を持っているので、

げEnがeおpおiかe 上で稼働するげ/OS も AIX も Linきぐも、全てのシステムの統合自動化が可

能なんだ。（図 6）

図 6：Tivoli Sけかがem Aきがomaがion によるげEnがeおpおiかe の自動化

後輩： TSA foおげ/OS は、ハードウェアに対してもソフトウェアに対しても、常にメインフレームの

最新のテクノロジーに対して自動化運用を実現する機能を提供している、ということなんで

すね！　ボクが普段何気なく利用している資源も、実は裏ではずっと監視されたり自動制御

されたり、管理されているんだということもよくわかりました！　先輩ありがとうございます。

先輩：ところで君のアプリケーション ABEND 事件なんだけど、うちの運用ポリシーでは

ABEND 以前に、DB アクセス違反があれば即ユーザーに通知されていたはずだが …？

後輩：あ…。じ、実は、新人くんがユーザー ID 申請書に自分の内線番号を間違えて書いてしまっ

ていて、運用部が誰にも連絡が出来なかったんです…。

先輩：んー。今日は本当に色々なことが明るみに出てしまったんだな。じゃ、そういう厄日も心穏

やかに過ごせる方法を教えてあげるから、明日午後にでもまたおいで。

後輩：えっそんな方法があるんですか？　ありがとうございます！　ではまた明日教えてください！

【第4章】 Tivoli

71


72

2メインフレームのセキュリティー運用強化ソリューションー TID 統合 zSecure シリーズー

後輩：聞きに来ましたよ、マイスター先輩！　厄日も無事に過ごせる方法って何ですか？　まさか

「これもすべて天のしたこと、『天災』と思って諦めなさい」とかおっしゃるんじゃないです

よね？

先輩：「うちは『先妻』で揉めてるんだ」って？　

後輩：なんだ、先輩も落語がお好きだったんだ…。

先輩：ははは。今回のトラブルの原因は、アプリ起動ユーザーに DB アクセス権がなかったことだ

と言っていたね？

後輩：はい。実は、このユーザー ID にコネクトされたユーザー・グループは、先月まで DB アク

セス権を持ってたはずだったのに、今月からなくなっていたんです。これは『天災』じゃな

いですよねえ？

先輩：うん、『人災』だなあ。ユーザー ID の登録申請の時にしたことはなんだい？

　日常的な RACF DB 処理

後輩：ユーザー ID 申請パネルから、ユーザー情報とコネクト希望のユーザー・グループを入力し

て…。

先輩：その前に、その DB のアクセス・リスト定義は見たのかい？

後輩： RACF コマンド叩かないといけないんですよね？　ボクあんまり詳しくなくて …。

先輩：いやいや、うちのシステムでは、げSecきおe Admin のパネルからの定義照会は、誰でも出

来るようになっているよ。君たち一般ユーザーには、勿論変更処理は許可されていないけ

どね。

後輩：げSecきおe Adminって…。あ、げSecきおe Sきiがeかのことですか？

② メインフレームのセキュリティー運用強化ソリューションー ID統合 zSecきおeシリーズー ② メインフレームのセキュリティー運用強化ソリューションー ID統合 zSecきおeシリーズー

先輩：そうそう。げ/OS のセキュリティーのインフラ、ID 管理、ID 認証、アクセス制御、監査は

RACF （Secきおiがけ Seおveお）が提供しているけれど、げSecきおe Sきiがeかを構成する製品群

は、それぞれのセキュリティー管理項目をより強化するために提供されているんだ（図 7）。

げSecきおe Admin は日常的な RACF データベースの保守・運用処理の効率化を実現する

製品だ。うちでは原則、ユーザー ID やデータセット等の RACF 資源の登録、更新、削除

は全てげSecきおe Admin で行うようにしているよ。アクセス制御等の属性情報も含めてコ

ピーする機能や、グループ・コネクトの大量更新のためのメニューが揃っているから、人事

異動のシーズンにはなくてはならないツールだね。

図 7：IBM SecきおiがけげSecきおe Sきiがeか

後輩：げSecきおe Admin はこのパネルか。RACF パネルとは別にあるんですね。

先輩：そう。RACF パネルだと、RACF コマンドをひとつずつ実行するための入出力パネルになっ

ているが、げSecきおe Admin のパネルは目的ベースに複数コマンドの同時実行が出来る。

RACF パネルで DB のアクセス権を確認しようとすると、まずこの DB のアクセス・リスト

登録のグループをリストして、さらに各グループに CONNECT されたユーザーをリストして

… という必要があるよね。

後輩：はい。それが面倒で。


73 74

② メインフレームのセキュリティー運用強化ソリューションー ID統合 zSecきおeシリーズー

先輩：その点、げSecきおe Admin では、ほら、こんな風に新人くんのユーザー IDを指定したら、ユー

ザー ID 指定で直接 PERMITしたものも、コネクト・グループにより間接的に PERMIT さ

れたものも含めて、全てのUPDATE 権限を持つデータセットが一発でリスト出来る。（図 8）

図 8：げSecきおe Admin 表示 - ユーザーのアクセス許可範囲リスト

後輩：なるほど。アプリケーション移行前にこれを確認すれば、状況がわかったんですね…。

先輩：逆の方法で、データセット・プロファイルを指定すると、アクセス許可定義されているグルー

プとユーザー ID が属性と共に一覧出来て…あ、この「Uかeお」欄に、-きndef-、とあるだ

ろう？（図 9）これはこのデータセット・プロファイルにはアクセス定義が残っているけれど、

ユーザー ID としては既に存在していないものを示しているんだ。げSecきおe Admin から

ユーザー ID を削除すれば、自動的に PERMIT 済みの全ての資源からアクセス制御情報

を削除してからユーザー ID 削除をするんだけど、さては誰かが慌てて RACF コマンドだ

けでユーザー ID 削除をしてしまったんだな。

後輩：この状態のままで、この削除済みユーザー ID を再登録したら、このアクセス定義はまた有

効になってしまうんですか？

先輩：そうだね。同名の新しいユーザー ID に別権限を付与することを想定している場合、予期せ

ぬアクセス許可のせいで事件が起こってしまう可能性があるねえ。では、このユーザーの

許可定義は、このパネルから行コマンド、D、で削除してしまおう。えいっ。

【第4章】 Tivoli ② メインフレームのセキュリティー運用強化ソリューションー ID統合 zSecきおeシリーズー

図 9：RACF 定義不整合の発見

後輩：えっセキュリティー運用部に連絡せずに、そんなことしていいんですか、先輩…。

先輩：大丈夫だ。なにしろ私はマイスターだからな。勿論特権ユーザーのアクティビティーは運用

部が完全に把握している。

　zSecure 利用のメリット

後輩：げSecきおe Admin には、他にもRACF を越える便利な機能ってあるんですか？

先輩：今回はユーザー・グループの PERMIT 定義が外れてアプリケーションが ABENDしたけど、

こんな風に、RACF データベース定義を変更すると業務に影響が出る可能性があるよね。

それを防ぐために、げSecきおe Admin では RACF データベースによるアクセス制御をシミュ

レーションする機能を提供しているんだよ。

後輩：え、シミュレーション？


75


76


先輩： RACF Oline 機能というんだが、普段使っている Acがive RACF データベースのコピー

として、非活動データベース（オフライン・データベース）を用意しておく。そのデータベー

スに対してげSecきおe から更新をかける。で、オフライン・データベースによるアクセス制

御のログを SMF に記録する。それをレポートして確認する。問題なければ Acがive RACF

データベースに移行する。オフライン・データベースへの更新コマンドがどんなに大量だっ

たとしても、げSecきおe のコマンド保管の機能を使って、簡単に再現出来て安全に移行でき

る、というわけだ。（図 10）

図 10：RACF Oline 機能

後輩：なるほど、これは便利ですね。でも、運用でよくあるパターンとして、新しい定義を追加

する時は完璧に事前精査してるけど、その後担当者が変わって、だんだん、いつ何のため

に作った定義やら、本当に必要な定義なのやら、分からなくなってしまうってこと、ありそう

ですよね？

先輩：げSecきおe ではそれを防ぐための手段として、アクセス・モニターという機能を提供してい

るよ。

後輩： RACF 資源のアクセス状況を常時モニターするってことですか？

先輩：そう。RACF 資源のアクセスのたびに RACF EXIT をコールして、常駐モニター・タスク

経由でアクセス・ログを記録するんだ。で、RACF データベースの実定義と照合して、使

われていない定義を洗い出す。

後輩：使われていない定義というのは？


先輩：ユニバーサル・アクセス（UACC）指定があるのに個別 PERMIT 指定があるといったよう

な重複とか、同じようなグループ定義が複数あって両方と CONNECT されているとか。

READ アクセスしかしないユーザーに UPDATE 権限を与えているとか。

後輩：それはどこかで整理して削除したいですねえ。

先輩：そう。その削除定義ステートメントを自動生成してくれるクリーンアップ機能までを

げSecきおe Admin は提供しているよ。（図 11）

図 11：RACF データベース・クリーンアップ機能

後輩：ここまで見てきてちょっと思ったんですけど、いまどきグラフィカル・インターフェース（GUI）

はないんですか？

先輩：別製品だが、げSecきおe Viかきal というのがあって、Admin の操作が GUI で出来る。ほら

この画面だ。PC のファイルとして印刷機能や cかv ファイル変換も出来るので、管理文書

作成にも便利だよ。（図 12）


77


78

図 12：げSecきおe Viかきal

　セキュリティー監査

後輩：なるほど！げSecきおe Admin は、RACF では提供しきれない管理機能をずいぶん補完して

いるんですね。でもそもそも、ボクはげSecきおe Sきiがeかって、監査レポート作成のためのツー

ルかと思ってましたよ。

先輩：ああ、それはげSecきおe Aきdiがの機能だ。げSecきおe Aきdiがは、RACF データベース、

RACF のアクセス・ログを書き出した SMF ログ、その他の SMF ログ、システム・パラメー

ターの構成情報等から、監査に必要なレポートを作成するんだ。うちでは、J-SOX 法施行

以来、監査レポート作成として利用し始めている。J-SOX 法は知っているよね？

後輩：一通りは。 IT セキュリティーの分野では、セキュリティーのための制御が実施されているこ

と、適切なユーザーが適切なアクティビティーを実施していること、の証跡が求められるん

でしたよね。

先輩：その通り。制御情報の代表としては、ユーザー ID 設定情報とか使用状況、パスワード変

更状況の一覧に、特権ユーザー一覧、システム資源定義一覧だろ。それからアクティビティー

としては、ユーザー認証やシステム資源のアクセス違反レポートに、不要ユーザー ID、特

権コマンド発行状況。勿論、RACF アクティビティー全ログ、というのも対象だね。


後輩：でも、レポートの類って、人によって欲しがる種類もフォーマットも違いますよね。ステレオ・

タイプなサンプルじゃ、満足度低いような…。

先輩：げSecきおe Aきdiがではレポートのサンプルを一通り提供すると共に、カラム順序の変更など

のレポート・フォーマット変更が簡単に出来る、CARLa という簡易言語の提供もしているん

だ。だからカストマイズはお好きなように、だよ。

後輩：ええと、今気が付いたんですけどね、もしかして、今回のアプリの ABEND、アクセス違

反としてユーザー ID と共にレポートに出力されてしまったということですね。監査レポート

は何年保管でしたっけ？　わー恥ずかしい！

先輩：ははは、そうだね。逆に言えば、君が自力で ABEND 原因を見つけられていなかったとし

ても、月末に、うちのセキュリティー運用部がレポートからアクセス違反を発見していたは

ずだということだね。

後輩：うー。で、では気を取り直して…げSecきおe Aきdiがの他の機能はあるんですか？

先輩：うちのセキュリティー運用部も使っている、VERIFY 機能というのがある。RACF DB の

不足や脆弱性を洗い出して、プライオリティー付けしてレポートしてくれる（図 13）。脆弱

性検知の確認のためのベスト・プラクティスとして利用しているのは、米国国防総省のコン

ピュータシステム評価基準のセキュリティー・レベル定義だ。

図 7：VERIFY 機能 - げ/OS および RACF 設定状況の監査



79


80


後輩：なるほど。これは信頼性だけではなく、網羅性も高そうですね。

先輩：セキュリティーのインフラ強化には、何らかのセキュリティー業界標準のメソドロジーを利用

することが不可欠だ。げSecきおe Sきiがeかは IBM セキュリティー・インフラストラクチャーと

いう体系を利用して設計されているんだよ。

　セキュリティー・アラート

後輩：マイスター先輩、ついでに聞いちゃいますけど、げSecきおe Sきiがeかのほかの製品はどんな

ものがあるんですか？

先輩：運用の強化のためのげSecきおe Admin とげSecきおe Viかきal、運用評価のための

げSecきおe Aきdiがとくれば、次はリアルタイム監視の製品で、げSecきおe Aleおがというのが

ある。パスワード入力ミスとか、許可されていないデータベース資源へのアクセス違反につ

いては、RACF だけでも WTO メッセージは出してくれるが、げSecきおe Aleおがではメール

や電話、SNMP イベント発信も出来る。また、通知対象のインシデントの種類を細かく指

定できるんだ。たとえば、ログオン失敗だけを特定管理者に通知するとかね。

後輩：なるほど。

先輩：それから、げSecきおe Command Veおiでeおという製品は、さらに踏み込んだプロアクティブ

管理を実現する。重要情報や資源の保護を強化し、脆弱性が生じることを事前に防止するた

め、セキュリティー・ポリシー違反に繋がるRACF 定義変更コマンドの実行を拒否するんだ。

後輩：え？　コマンドを拒否、ですか？

先輩：げSecきおe Command Veおiでeおは RACF コマンドが発行されると、RACF EXIT より先に

割り込んで、その内容を精査するんだ。

後輩：最初にセキュリティー・ポリシーは登録しておくんですね？

先輩：勿論。コマンドは、TSO からでもバッチ・ジョブからでも、コンソールやリモートからの

入力でも対象となるから、ミス・オペレーションの防止も悪意ある侵入者の撃退も可能だ。

後輩：うーん、なかなか便利な機能が揃っているんですね。げSecきおe Sきiがeかが、RACF による

セキュリティー管理を、より高度なレベルに高める目的で設計されているんだということが良

く分かりました。

先輩：ははは、君もどんどん失敗と共にスキルを広げて行くねえ。

後輩：そんなあ。知的好奇心と共に、と言ってくださいよ。ところで、今回の不幸のひとつは、


後輩くんがユーザー ID 申請書に自分の内線番号を間違えて書いた、というのがあったんで

すけど、これは流石にげSecきおe ではどうにもならないですよねえ？

先輩：げSecきおe ではどうにもならないけど、今度の ID 統合プロジェクトの最終フェーズが終わっ

たら、そういう不幸は起きなくなるはずだなあ。

後輩： ID 統合プロジェクト？

先輩：今、うちでは Windoくかとげ/OS のユーザー ID の管理を統合しているんだが、Windoくか

側の Diおecがoおけと RACF データベースを統合するために、Tivoli Idenがiがけ Manageお

（TIM）を利用しているんだ。

後輩：それと内線番号とどういう？

先輩： TIM ではいろんな製品の複数のセキュリティー管理 DB を統合するだけではなく、付加情

報も統合できる。今のプロジェクトの最終フェーズでは社員 DB も TIM の統合対象にしよう

としているので、来月からはユーザー ID 申請時に社員番号を入力したら、自動的に内線番

号がセットされるようになるんだ。

後輩：じゃあ、もう申請の煩雑さから解放されるんですね！　これで『天災』も怖くない…って、

あれ？　今のあの音は？

先輩：雷のようだなあ。

後輩：ええっボク、今朝珍しく早起きしたんで、洗濯して、ベランダにどっさり…。

先輩：はっはっはっ、こればっかりは間違いなく『天災』だと思って諦めなさい！

System z ソフトウェアのセキュリティーについて

近年マスコミを賑わせているニュースを見るまでもなく、データという企業資産の流出や不正改ざんはビジ

ネス及び社会の大きな問題です。セキュリティー問題を引き起こす人物は、悪意ある外部の第三者だけで

はなく、故意あるいは未必の故意による内部関係者である可能性もあります。また、99.99%安全なデータ・

セキュリティーがたった 1 回破られたために、企業にとって計り知れない大きな損失をもたらすこともままあ

ります。

セキュリティー強化対策としては、より網羅性の高いセキュリティー・インフラストラクチャーを構築するこ

とと、それを日々確実に運用し監視すること、さらに確固たるプロセスにより常時監査可能となっているこ

とが求められます。

IBM では、IT 業界標準のベスト・プラクティスをベースに IBM セキュリティー・インフラストラクチャーを

定義し、網羅性と拡張性、柔軟性を持つソリューションを製品として提供しています。また、Sけかがem げ

のセキュリティー製品群は、運用ソリューションのベースである IBM Seおvice Managemenが Cenがeお on

Sけかがem げにも組み込まれています。

185

IBM、IBM ロゴ、ibm.com、AIX、CICS、CICSPlex、DB2、IMS、InfoSphere、NetVeiw、pureScale、RAA、

RACF、Rational、Rational Team Concert、SPSS、System z、Tivoli、WebSphere、z/OS およびｚSecure は、

世界の多くの国で登録された International Business Machines Corporation の商標です。他の製品名および

サービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、

www.ibm.com/legal/copytrade.shtml をご覧ください。

● 掲載された情報は 2013 年 3 月現在のものです。事前の予告なく変更する場合があります。

● 製品、サービスなどの詳細については、弊社もしくは IBM ビジネスパートナーの営業担当員にご相談ください。

● 本事例中に記載の肩書や数値、固有名詞は掲載当時のものであり、変更されている可能性があることをご了承ください。

Software

Zマイスターとの新たな価値探求 Tivoli