iSeriesのセキュリティ: よくある5つの誤解｜e-bellnet.com（IBM i （AS/400）ユーザーのための関連技術情報サイト）

IBM i 資料集

IBMｉ海外記事2012.05.23

iSeriesのセキュリティ: よくある5つの誤解

ダン・リール著

よくあるシナリオを通してIBM iのセキュリティがどのように機能するかを明確にする

IBM iのセキュリティ・コンサルタント、教育専門家、執筆者を長く務めてきて、IBM　iの専門家たちがIBM iのセキュリティ機能の仕組みを誤解しているのを私は何度となく目にしました。本稿ではこの誤解について触れ、IBM iのセキュリティがさまざまなシナリオの中でどのように機能するのかに関する誤解に共通した5つの点について明確にできればと思っています。本稿では以下の話題について取り上げます。

ユーザー制限機能(たとえばLMTCPB(*YES))に関する誤解
ユーザー・プロファイルの所有権とそれに対する権限に関する誤解
権限リストを使用する際のオブジェクト権限に関する誤解
「隠れた」セキュリティ構成オプションに関する誤解
ウィルス、ワーム、その他の悪意のあるソフトウェアに対するシステムの脆弱性に関する誤解

誤解その1: ユーザー制限機能

システム・ユーザーは、すべてのIBMメニュー、Work with Spooled Files (WRKSPLF)コマンド表示、Work with User Jobs (WRKUSRJOB)コマンド表示、その他さまざまなコマンドを含むIBMが提供するさまざまな画面を介してコマンド・ラインにアクセスすることができます。

ユーザーにコマンド・ラインへのフル・アクセスを許すのは危険です。たとえばDLTF CUSTOMERといったコマンドは実運用の顧客ファイルを削除するものなのでユーザーに実行してほしくはないでしょう。コマンド・ラインにアクセスができるユーザーは実行権限を持つ任意のCLコマンドを実行することができます。

IBMは、各ユーザー・プロファイルのLMTCPB属性(機能の制限)を使用することで、コマンド・ラインでユーザーが実行できるCLコマンドの機能を制御することができるようにしています。コマンド・ラインの機能の使用を制限されたユーザーを作成するにはCRTUSRPRF... LMTCPB(*YES)コマンドを使用します。

コマンド・ラインの機能の使用を制限されたユーザーに関してよくある誤解は、こうしたユーザーがWRKSPLF コマンドやDLTF CUSTOMERコマンドなどといった特定のCLコマンドも一切実行できないと思ってしまうことです。しかし実際には、機能の使用を制限されたユーザーでも実行権限のある"任意の"CLコマンドを実行することができます。機能の使用を制限されたユーザーは、コマンド・ラインへのアクセスを許可されるとコマンド・ラインから以下のようないくつかのCLコマンドを実行することができます。

Sign Off (SIGNOFF)
Send Message (SNDMSG)
Display Messages (DSPMSG)
Display Job (DSPJOB)
Display Job Log (DSPJOBLOG)
Work with Messages (WRKMSG)
Work with Environment Variables (WRKENVVAR)

IBMはこれらのCLコマンドに対して、機能の使用を制限されたユーザーがコマンドを実行できるということを指定した特別なコマンド属性を付けています。たとえば、DSPCMD DSPMSGコマンドを使用してDSPMSGコマンドについての情報を表示させると、ALWLMTUSR (制限ユーザーに許可)というコマンド属性の1つが*YESという値にセットされていることがお分かりになるでしょう。各CLコマンドにはALWLMTUSR属性がありますが、ほとんどのコマンドでこの属性の値が*NOに設定されていて「制限ユーザーにこのコマンドの実行を許可しない」という意味になっています。システム管理者としては、次のようにCHGCMDコマンドを使用して制限ユーザーがCLコマンドを実行できるように変更することができます。

CHGCMD CMD(WRKSPLF) LWMLMTUSR(*YES)

このコマンドの例は、制限ユーザーがWRKSPLF コマンドをコマンド・ラインで実行できるように設定しています。
新しいCLコマンドをインストールする際に制限ユーザーが実行できるようにしてあるサード・パーティー製のソフトウェアも多々あります。新しくコマンドを作成したときは制限ユーザーがそのコマンドを実行できないようになっていることを確かめておくのが賢明でしょう。

ALWLMTUSR(*YES)が指定されたCLコマンドを実行できることに加えて、ユーザーはIBM i Access for Windows Remote Command機能を使用して実行権限のある任意のCLコマンドを実行することができます。PCのコマンド・プロンプトから、ユーザーはIBM i Access for WindowsにインストールされているRemote Program Callコマンド(rmtcmd.exe)を使用して、実行権限を与えられた任意のCLコマンドを実行することができます。CLコマンド(赤字部分)を入力したときのシステムの応答(もう１つの赤字部分)を図1：IBM i Access for Windowsでrmtcmd.exeを使用してCLコマンドを実行した例に示します。

この例では、機能の使用を制限されたユーザーがCRTLIB (Create Library)コマンドを実行してHackerというライブラリを作成しています。rmtcmd.exeはユーザー・プロファイルにあるLimit capabilities属性を無視して、ユーザーが実行権限を持つ任意のコマンドを実行できるようにします。

またユーザーは、次のようにリモート・プログラム呼び出しを使用してODBC経由でCLコマンドを実行することもできます。

CALL QCMDEXC ('DLTF MYFILE' 11)

ここでも、制限ユーザーはrmtcmd.exeやODBC呼び出しを使用するときは機能を"制限されません"。

重要ポイント:

ユーザー・プロファイルのLimit capabilities属性を使って制限できるのは、ユーザーがどのCLコマンドをコマンド・ラインから実行できるかのみであるということを理解してください。

誤解その2: ユーザー・プロファイルに対する権限

私が今まで見てきたシステムのほとんどでユーザー・プロファイルの所有者は本当に寄せ集めのユーザーとなっていました。典型的な例ではユーザー・プロファイルの所有者がJOE、TERRYS、SECGROUP、ITGROUP、QSECOFRであるというものです。よくある誤解として、ユーザー・プロファイルの所有権とユーザー・プロファイルに対する権限はシステムの安全性に関してはあまり重要ではない、というものがあります。これと関連したもう1つの誤解として、ユーザー・プロファイルに対する*PUBLIC権限を何に設定しても何も変わらないというものがあります。

実際には、ユーザー・プロファイルの所有者を正しく設定し、*PUBLIC権限とプライベート権限を正しく制限することがシステムのセキュリティにとって重要です。ユーザー・プロファイルの所有権と権限が安全に設定されていないと、ユーザー・プロファイルの乗っ取り攻撃にさらされることになります。

管理しているシステム上のユーザー・プロファイルを誰が所有しているか調査したことがありますか。ユーザー・プロファイルを作成すると、あなたもしくはあなたのプライマリ・グループ・プロファイルがその作成したプロファイルの所有者になります。プロファイルの作成者であるあなたはそのプロファイルに対して*ALL権限を持ちます。もしUSERAがUSERB用に作成したプロファイルに対して*USE権限以上の権限を持った場合、USERAはあたかもUSERBが実行したかのようにジョブを実行することができ、その結果、USERBのプロファイルを乗っ取ったことになります。USERAがUSERBを所有している場合、USERAはUSERBに対して＊ALL権限を持つことになり、USERBのプロファイルを乗っ取るのに必要な権限以上の権限を持つことになります。

ユーザー・プロファイルの乗っ取り

ユーザー・プロファイルをいかに簡単に乗っ取れるかの例を示します。USERAがコマンド・ラインから次のコマンドを実行します。

SBMJOB CMD(CALL PAYUPDATE) USER(USERB)

このコマンドはバッチにジョブをサブミットし、そのジョブはあたかもUSERBがサブミットしたかのように実行してUSERBのすべての権限を持ちます。実際、USERAはUSERBに成り代わってジョブをサブミットし、給与支払い名簿の更新プロセスを実行しますが、USERAはこのプロセスの実行権限を持っていないのです。

USERAが使用する機能を制限されていたとしても(つまりコマンド・ラインの使用を制限されていたとしても)、前節で説明した通り、rmtcmd.exeを使用することでそしてODBC経由でQCMDEXECを呼び出すことで、前出の例のSubmit Job (SBMJOB)コマンドを実行することはできます。

あなたのユーザー・プロファイルはセキュリティの危機にさらされている可能性はありませんか。この質問に答えるにはシステム上で*PUBLIC *USEあるいはそれ以上の権限を与えられているユーザー・プロファイルはどれかを割り出す必要があります。そうしたプロファイルのリストを確認するには次のコマンドを実行します。

PRTPUBAUT OBJTYPE(*USRPRF)

このコマンドを実行して得られたリスト中で*PUBLIC AUT(*USE)あるいはそれ以上の権限を持ったユーザーは、システム上の任意のユーザー(*PUBLIC)によってのっとられる可能性があります。

次に、あなたのプロファイルに対して*PUBLICおよびプライベート権限を持ったユーザーのリストを表示するには次のコマンドを実行します。

PRTPVTAUT OBJTYPE(*USRPRF)

このリストの中に、あなたのユーザー・プロファイルに対して*USEまたはそれ以上のプライベート権限を持ったユーザーがあれば、あなたのプロファイルはそのユーザーによって乗っ取られる可能性があります。

こうした問題を簡単に解決する1つの方法は、すべてのユーザー・プロファイルが*PUBLIC AUT(*EXCLUDE)に設定されていてプライベート権限がすべて削除されていることを確認するというものです。ユーザー・プロファイルを所有することでプロファイルを乗っ取ることができるユーザーがいないことを確認してください。非IBMユーザー・プロファイルの所有者をQSECOFRに変更していたほうが良いでしょう。こうすることでプロファイルの所有権がそのユーザー・プロファイルを作成した人あるいはグループへ過剰な権限を与えるようなことがないようにします。たとえば、USERBの所有者をQSECOFRに変更するには次のコマンドを使用します。

CHGOBJOWN OBJ(USERB) OBJTYPE(*USRPRF) NEWOWN(QSECOFR)

このコマンドを実行すると現在の所有者の権限を無効にします。

重要ポイント:

現在のユーザー・プロファイルの所有者のリストを確認して、組織として適切な所有権になるように変更してください。

誤解その3: 権限リストの使用

権限リストを活用すると、個々のオブジェクト内でオブジェクト権限のリストを維持するのではなく、テンプレート・アプローチを使用して同じオブジェクト・レベルの権限を持つさまざまなオブジェクトをセキュアにすることができます。多くの人が権限リストを使用することをためらうのはこのリストの機能を理解していないためだと思います。しかし権限リストを多数のオブジェクトに適用する権限のテンプレートだと単純に考えれば、もう少し納得がいくでしょう。

IBM i上でオブジェクトをセキュアにする最善の方法はグループのプロファイルと権限リストを組み合わせて使用することです。こうすることで保守作業を大幅に軽減することができます。

ここ数年多数のシステムの監査をしてきた中で、権限リストを使用している場合で*PUBLIC権限、プライベート権限、リストでセキュアにしているオブジェクトの所有権の設定に誤りがよくあることに気づきました。権限リスト自体の所有権を不適切に設定していることで引き起こされたエラーもあります。

IBM iの専門家の中で権限リストの使用に関して3つの誤解があることに気付きました。

権限リスト(*AUTL)を使用してオブジェクトをセキュアにする時、権限リストを表示させるだけでそのオブジェクトへのすべての権限を確認できると思っています。実際にはオブジェクト自体の中で設定されている権限を無視することができます。実質的には*AUTLが唯一の権限になります。
また権限リストには*PUBLIC権限用の設定が含まれているので、*PUBLIC権限用のオブジェクト中の設定がどうなっているかにかかわらず、権限リスト中で指定されている*PUBLIC権限がこのリスト中でセキュアにされているすべてのオブジェクトに適用されると思っています。
3つ目の問題は、権限リストの所有者はこのリストによってセキュアにされているオブジェクトに対する権限に何の影響も及ぼさないため、権限リストの所有者のことを無視してしまっているということです。

以上の点を説明する例をいくつかご紹介しましょう。図2a：PRODLIB_O権限リストでは、PRODLIB_O権限リストの所有者はPAYUSERで、PAYUSERに対する権限リストに*ALL権限を提供しています。権限リストに対する*PUBLIC権限は*EXCLUDEに設定されています。プライベート権限はGROUP_IT、GROUP_OPS、およびQPGMRに付与されています。

図2b：物理的なファイルPAYFILE用のオブジェクト権限では物理的なファイルであるPAYFILEが権限リストPRODLIB_Oによってセキュアにされています。この権限リストは*PUBLIC権限が*EXCLUDEであると指定しています。しかしPAYFILEオブジェクト自体は*PUBLIC権限が*CHANGEであると指定しています。

PAYFILEファイルの所有者はBOBTHETECHで、PAYFILEに対してBOBTHETECHに*ALL権限を付与していますが、BOBTHETECHは権限リストには記載されていません。PAYFILEと権限リストがGROUP_IT、GROUP_OPS、およびQPGMRに対して異なる権限を指定しているのです。このように権限リストがバラバラになってしまうとこのファイルに対する実際の権限はどうなるのでしょうか。

図2aおよび図2bの例を使用すると、PAYFILEに対する実際に有効な権限は以下の通りとなります。

BOBTHETECH: AUT(*ALL)
GROUP_IT: AUT(*ALL)
GROUP_OPS: AUT(*CHANGE)
QPGMR: AUT(*ALL)
*PUBLIC: AUT(*CHANGE)
PAYUSER: AUT(*ALL)

したがって、権限リストの指定がたとえ異なっていたとしても、オブジェクト内や権限リスト内に権限の衝突が発生しているときは権限リスト側ではなくオブジェクト側の権限リストが勝ちます。そしてPAYUSERは*AUTLを所有していますから、PAYUSERはこの権限リストでセキュアにされているオブジェクトに対して*ALL権限を持つことになります。

問題の解決方法

まずPAYFILEの所有権を正しいものにします。IT要員は実運用のオブジェクトに対して所有権を持つべきではありませんので、PAYFILEの所有者をPAYUSERに変更しBOBTHETECHの権限を無効にします。次に、GROUP_OPS、GROUP_IT、およびQPGMR用のPAYFILEに対するプライベート権限のうち衝突しているものをすべて削除します。　以上の変更を図3：PAYFILEオブジェクトの所有権の変更に示します。

次に、*PUBLIC権限の問題を解決します。権限リストで指定されている*PUBLIC権限を実際に実装する唯一の方法は、セキュアになっているオブジェクト用の*PUBLIC権限の値を*AUTLとするという方法で、これが権限リストの使用と常に一緒になっていなければなりません。*AUTLは特殊な権限値で、*PUBLIC用のオブジェクト権限としてのみ指定されます。あるオブジェクトがある権限リストによってセキュアにされている場合、その権限リストによってセキュアにされているすべてのオブジェクトに対する*PUBLIC権限は*AUTLと指定されていなければなりません。これによりシステムに対してそのオブジェクトに対する*PUBLICの権限を権限リスト中で探すように指示することになります。*PUBLICに対して何らかの他の値(たとえば*USE、*CHANGE、*ALL)を指定している場合、*PUBLICに対する権限リストの権限は一切チェックされません。一貫性を保ち、権限リストによってセキュアにされているオブジェクトに対してどんな*PUBLIC権限が付与されているのかについて混乱を避けるために、*PUBLIC AUT(*AUTL)を指定することも必要です。

さて、以上の片づけを済ませた後にPAYFILEに対して有効な権限は何になっているでしょうか。これは単に*AUTLを見てみればわかります。PAYFILEの所有者であるPAYUSERに付与された権限を除いてすべてのアクセスは*AUTLによって解決されます。オブジェクトと権限リストはいずれも不要な追加の権限を伝達することはありませんから、両者の所有者を同じにしておくことは良い方法です。

誤解その4: 「隠れた」構成オプション

数々の誤解の元は、知識ベースには記載されていない基本的には隠れているセキュリティの構成オプションのグループです。これらのオプションを知っている人はほとんどおらず、これらを使用するとどんなことができるのかを知っている人はさらに少ないです。この隠れたオプションに関連した誤解をいくつか以下にご紹介します。

強力な(つまり*ALLOBJ)ユーザーのジョブのアクティブなジョブ・ログを表示するには*JOBCTLおよび*ALLOBJという特殊権限が必要である。
通信トレースやその他のサービス・トレースを実行するには*SERVICE特殊権限が必要である。
ユーザーがファイルに対して権限を持っている場合は、そのユーザーがFTP経由でそのファイルをダウンロードできなくするように制限することはできない。

現実はこうです。「機能使用」の隠れたオプションを使用することで上記やその他多数のセキュリティ構成オプションを設定することができます。

Work with Function Usage (WRKFCNUSG)、Change Function Usage (CHGFCNUSG)、Display Function Usage (DSPFCNUSG)などといったCLコマンドはこうした「隠れた」構成オプションに対するコマンド・インタフェースです。 System i NavigatorにはApplication Administrationという名前の素晴らしいGUIがあり、これを介してこれらの構成オプションに対するアクセスが提供されています。

機能使用とは

センシティブなCLコマンドとシステムの操作は通常、オブジェクトの権限(つまりこのコマンドを使用する権限を持っているか)と特殊権限(このコマンドや関数を実行するのに必要な特殊権限、たとえば*SECADM、*JOBCTL、を持っているか)を組み合わせることで一部のユーザーのグループに制限されています。機能使用とは一部のセンシティブな操作に対して課されているもう一つの隠れた層になっています。たとえば、ユーザー・プロファイルを作成するにはユーザーはCreate User Profile (CRTUSRPRF)コマンドを使用する権限が必要で、次にCRTUSRPRFコマンドがそのコマンドを実行しているユーザーがセキュリティ管理者(*SECADM)特殊権限を持っているかを調べます。もしこれらの条件が満たされればプロファイルが作成されます。この場合、追加の隠れた機能使用構成オプションは関係ありません。

しかし*ALLOBJユーザー(たとえばQSECOFR)のアクティブなジョブ・ログが欲しいユーザーがいた場合、そのユーザーはDSPJOBLOGコマンドの権限、Job control (*JOBCTL)特殊権限、*ALLOBJ権限を持っていなければなりません。これらはシステムのデフォルトの規則です。しかし機能使用の隠れた構成オプションを変更することでこの規則を上書きして、*JOBCTL特殊権限を持つ誰もが*ALLOBJユーザーのアクティブなジョブ・ログを表示させることができるようになります。

この構成オプションは機能使用の中に隠れているので、ほとんどの人が操作要員に*ALLOBJ権限を付与することを認めてしまっています。ジョブが失敗した時に*ALLOBJユーザーのアクティブなジョブ・ログを表示させる方法が他にないように見えます。操作要員はアクティブなジョブ・ログを表示することで問題の原因を突き止めることができなければいけません。しかし機能使用を変更することでこの規則を変更することができます。

機能使用の扱い

IBMは機能使用を介して隠れた構成オプションを提供する機能のレジストリを維持しています。その機能の1つは前述した*ALLOBJユーザーのアクティブなジョブ・ログを表示することのできるユーザーを指定する構成です。この機能の登録名はQIBM_ACCESS_ALLOBJ_JOBLOGです。登録された機能用の設定にアクセスするにはWRKFCNUSGコマンド、CHGFCNUSGコマンド、およびDSPFCNUSGコマンドを使用します。(これらのコマンドの詳細についてはIBM i Information Centerのコマンド・リファレンスを参照してください。)

特殊な機能使用構成オプションを持っているのはどの機能か

機能使用コマンドを使用して以下に示すいくつかの機能を制御する構成を設定できます。

*ALLOBJユーザーのアクティブなジョブ・ログにアクセスできるユーザー
通信(サービス)トレースを実行できるユーザー
任意のジョブを監視できるユーザー
IBM i OS FTPクライアントを使用してファイルを送信できるユーザー
FTPサーバーを使用してファイルをダウンロードできるユーザー
自分のPCからシステムに対してrmtcmd.exeを実行できるユーザー

Application Administrationの使用

IBM i NavigatorではApplication Administrationツールへアクセスする方法が提供されています。このツールは実際にはより使いやすいインタフェースであるWRKFCNUSG機能へのGUIインタフェースになっています。このツールにアクセスするには、Navigator上でシステム名かIPアドレスを右クリックしてApplication Administrationを選択します。

誤解その5: IBM iはウィルス、ワーム、悪意を持ったソフトウェアに対して難攻不落である

他のオペレーティング・システムを攻撃するウィルスやその他の悪意を持ったソフトウェアに対してIBM iは完全な免疫力があるという誤解が広まっています。Windowsやその他のOSでの経験から皆様ご存知の通り、悪意を持ったソフトウェアは常に警戒している必要があるので非常に厄介です。ウィルス対策ソフトウェアをデスクトップPCやラップトップPC上で稼動させ、最新のアップデートがインストールされている状態にしておくことが必須です。しかしIBM iについてはどうでしょうか。IBM iも実際には脆弱なのでしょうか。

IBMは、IBM i上のPCウィルスに関する知識をうまく整理して提供してくれています。以下は、IBM技術文書#19541539"ウィルス、オペレーティング・システム、統合ファイル・システム"に記載されている情報の一部です。

「このオペレーティング・システムはPCウィルスの攻撃の影響を受けません。ウィルスは特定のコンピュータ・アーキテクチャを攻撃対象とします。IBM System iのアーキテクチャは、IBM System iに対して攻撃するウィルスを作ることを非常に難しくしています。PCベースのウィルスはこのオペレーティング・システムに伝染しません(あるいは実行できません)。」

これで皆さん本当に安心です。PCウィルスはこのOS上では実行できないのです。やれやれ。
確かにその通りですが、IBM技術文書のまさに次の段落にはもう少し記述があります。

「このオペレーティング・システムはPCウィルスに感染しませんが、このオペレーティング・システム上の統合ファイル・システムがPCファイル用のファイルサーバーとして使用されている場合、統合ファイル・システムに格納されているファイルがウィルスを保菌している可能性があります。PCから統合ファイル・システム上に移動あるいは保存された感染ファイルが他のPCに再配布されるとそのPCにウィルスを伝染することが起こりえます。同様に、ネットワーク・ドライブが統合ファイル・システムにマップされていれば、PC上で実行しているウィルス(しかもネットワーク・ドライブ上のファイルを破壊する能力を持ったウィルス)は統合ファイル・システム上に保存されている任意のファイルを破壊することができます。」

主な危険箇所

ほとんどの人たちはIFSを使用して共有ネットワーク・ドライブのホスティングを可能にしています。文書ファイル、表計算ファイル、スキャンした画像ファイルなどを、任意の共有ネットワーク・ドライブ上に保存するのと同じようにIFS上に保存しています。IFSに共有ドライブを作成してマップするときは、ウィルスやその他の悪意を持ったソフトウェアが、他のネットワーク・ドライブに感染するように、この共有ドライブに感染するかもしれません。

POPメール・サーバーやIBM Lotus DominoをIBM i上で稼働している場合、メールへの添付ファイルがIFS中に保存されています。メールへの添付ファイルを介して送られてくるウィルスについては皆さんもご存じでしょう。したがってこれもまた悪意を持ったソフトウェアがIFS中に持ち込まれるもう1つの道です。

どう危険なのか

こうしたIFS中に生息しているウィルスはIBM i上で実行できるのでしょうか。実行することはできませんが、IFS中にいるウィルスはそのファイルにアクセスした他のシステムに感染する可能性があります。たとえば、IFS上に保存されている表計算ファイルがウィルスに感染しており、そのファイルを(最新のウィルス対策ソフトウェアがなされていないクライアント上で)開くと、あなたのPCがそのウィルスに感染してそこから感染が広がる可能性があります。IFSはウィルスやその他の悪意を持ったソフトウェアの保菌者あるいは倉庫に確かになりえるのです。

IFSのウィルス・スキャン

過去において、IFSの感染を心配して通常のウィルス・スキャンソフトを使って、IFSの主要な部分をマップされたネットワーク・ドライブで定期的にスキャンしていた人がいました。前述のIBM技術文書にはこのタイプのスキャンを実行する際の説明と、このタイプのスキャンで対応しなければならないファイル割り当て上の問題について記載があります。このスキャン方法の問題の1つはリアルタイムのウィルス処理サポートが提供されていないことです。

数年前、IBMのビジネス・パートナーであるBytware社がマップされたネットワーク・ドライブ上ではなく、IBM i上でネイティブに稼働するウィルス保護ソフトウェアを発表しました。BytwareはMcAfee社のウィルス・スキャン・エンジンを採用しました。Raz-Lee Security社はClam AntiVirus (ClamAV)というオープン・ソースをベースとしたネイティブのウィルス・スキャナを開発して市場に出し、米国ではSoftware Engineering of America (SEA)社が販売しています。

こうしたビジネス・パートナーからのIFSをスキャンするウィルス対策ソリューションをサポートするためにIBMは次の2つの新しい出口点を有効にしました。

QIBM_QP0L_SCAN_OPEN: IFS Scan on Open 出口点
QIBM_QP0L_SCAN_CLOSE: IFS Scan on Close 出口点

この2つの出口点を使用すると、IFS上のファイルがアクセスされるたびにカスタム・プロセスを実行することができます。こうした出口点の主な使用方法の1つは、ファイルがアクセスされるときにそのファイルに対してウィルス・スキャン・ソフトウェアがリアルタイムに検査できるようにするというものです。単にIFSを週に1度スキャンするかわりに、この方法でアクセスされたファイルをリアルタイムにスキャンするのです。

さらに、IBMはIFSのスキャン環境を制御するためにQSCANFSおよびQSCANFSCTLという 2つのシステム値を導入しました。この出口点とシステム値により、IFSをネイティブにスキャンしてIFS内でリアルタイムにウィルスにアクセスするソリューションが可能になりました。

スキャンしますか？

IFSを使用して共有ネットワーク・ドライブを提供したりPOPメール・サーバーを使用したりしている場合は、もはやIFSをスキャンするかしないかという問題ではありません。むしろどれくらいの頻度でスキャンすべきか、どうやってスキャンするか、ホスト・マシン上で提供されているリアルタイムのアクセス保護が必要か、感染したファイルにアクセスするすべてのクライアントには最新のウィルス対策がなされていてクライアント側で問題を捕らえることができるようになっているか、という問題なのです。

セキュリティの明確さ

本稿ではIBM iのセキュリティに関する一般的な誤解のうち、セキュリティのコンサルタントであり教育専門家である私の経験上で良く知られたものについて述べました。しかしここにあげた誤解がすべてでないことは確かです。もっと他にもあります。とはいえ、本稿で説明した話題について良く理解しておくことは今よりずっとセキュアなシステムを構築して保守していく際に今後も役立つでしょう。