IBM i のセキュリティに関する神話トップ10
10個の神話の正体を明らかにすることでよりセキュアな環境を構築するために必要な知識が得られます
本稿の目的は、IBM i のセキュリティに関する誤解やよく起こしがちな間違いを紹介することです。コンサルタントである私としては、こうした誤解や間違いに関する疑問に個別に答えて誤解を解いてきましたが、より多くの人に知っていただくことは価値があるだろうと考えたのです。
神話その1：ユーザー・クラス
最初の話題は、ユーザー・プロファイルのユーザー・クラス属性です。権限をチェックするためにユーザー・クラスが使用されることはありません。誰かが私に質問しにきて、「そのユーザーは*SECOFRユーザー・クラスに属しているのですが、」と状況を説明するたびに1ドルもらえたらと思います。ユーザーがあるオブジェクトになぜアクセスできないのか、アクセスできるべきではないのになぜアクセスできてしまうのか、を調べるときはユーザー・クラス属性のことは忘れてください。アクセス権限は、ユーザー・クラスが何であるかには関係がないのです。権限をチェックするアルゴリズムはこの属性を全く見ないのです。ユーザーは、ユーザー・クラス*USERに属していてもすべての特殊権限を有することができます。また、*SECOFRユーザー・クラスに割り当てられていても特殊権限を持たないこともあります。したがって、ユーザー・クラスを見ることは、事実ではないかもしれない前提を置いてしまうことになりかねません。ユーザー・クラスはプロファイルが作成される時だけに使用され、ユーザーの特殊権限のデフォルト値を決め、そのユーザーがIBM iメニューのどのオプションを選択することができ、システムがIPL中にセキュリティ・レベル20とそれ以上のセキュリティ・レベルとの間で特殊権限を調整する必要があるか否かを判断します。
神話その2：借用権限
プログラムの属性を設定することで借用権限を有効にできる、ということはほとんどの人がご存じでしょう。問題は、間違った属性を見ている人が多いということです。借用権限は、Use Adopted Authority (USEADPAUT) とUser Profile (USRPRF)の2つのプログラム属性が制御しています。この用語の使い方から考えると、プログラムが権限を借用するかどうかを制御するのは、USEADPAUTパラメータであると考えてしまう人が多いのもうなずけますが、プログラムが権限を借用するかどうかを制御するのは、USEADPAUTパラメータではありません。プログラムが権限を借用するかどうかを制御するのはUSRPRF属性なのです。USRPRF属性をデフォルトの*USERに設定すると、プログラムは権限を借用しません。USRPRF属性を*OWNERに設定すると、プログラムを呼び出しているユーザーが十分な権限を有していない場合、そのプログラムはプログラムのオーナーの権限を使用します。
では、USEADPAUT属性は何を制御しているのでしょう。まず、プログラムが権限を借用したら(つまりUSRPRFが*OWNERに設定されている場合)、借用権限はそれ以後順次呼び出されるすべてのプログラムに渡されます。 USEADPAUTパラメータは、プログラム呼び出しスタックの上位にあるプログラムから渡された借用権限を、そのプログラムが消費または使用するのかを制御します。借用権限を使用できないようにするにはこの方法しかなく、権限を借用したプログラム中では借用権限の流れを制御することはできません。
神話その3：借用権限とダイナミックSQL
借用権限と言えば、ユーザー・プロファイルのプログラム属性を一旦*OWNERに設定すると、そのプログラム中で起こることはすべて権限を借用するとお思いではないでしょうか。ところが必ずしもそうではないのです。そのプログラム中にダイナミックSQLがあると、ダイナミックSQL文はそのプログラムからの借用権限へアクセスできません。ダイナミックSQL文が権限を借用できるようにするには、プログラムをコンパイルする際にDynamic User Profile属性を*OWNERに設定しなければなりません。ここで、プログラムをコンパイルする際に、と言った点に注意してください。プログラムの借用権限属性は、プログラムをコンパイルする際かChange Program (CHGPGM)コマンドを実行することで設定できます。残念ながら、プログラムをコンパイルした後でDynamic User Profile属性を変更するためのインタフェースはありません。この属性の値を変更するには、プログラムを再コンパイルする必要があります。
神話その4：*ALLOBJ特殊権限
次の神話は*ALLOBJ特殊権限に関するものです。ユーザーのグループ・プロファイルに*ALLOBJを割り当て、さまざまなファイルやコマンドに対して私用権限の*EXCLUDEを付与することで、ユーザーのアクションを制御できると考えている組織を何度か目にしました。 (ユーザーに対して直接*ALLOBJを割り当てると、IBM iの権限チェック・アルゴリズムは常にそのユーザーの*ALLOBJを認識し、そのユーザーがファイルや他のオブジェクトから排他されているかどうかをチェックしなくなります。) 残念ながら、ユーザーのグループ・プロファイルに*ALLOBJを割り当てると、セキュリティに対する誤った認識を持つことになります。排他されているオブジェクトにユーザーが直接アクセスしようとすると、もちろんそのユーザーは「オブジェクトxxxへのアクセス件がありません」というメッセージを受け取ります。問題なのは、この障害物を避けるには、オブジェクトから排他されていないプロファイルとしてジョブの実行をサブミットするだけでよいことなのです。しかもこの障害物を回避する方法はこれだけではありません。そうしたいろいろなアクセス方法をすべてカバーしてユーザーからのアクセスを除外するには、オブジェクトの数があまりに多すぎます。すべてをカバーできていると確証が持てることはないでしょう。しかも、システムがアップグレードされるたびに、その新しいリリースに新しいメソッドが導入されていないかどうかを毎回調べなければなりません。ユーザーに特殊権限*ALLOBJを付与する際は、それがユーザー・レベルであってもグループ・レベルであっても、そのユーザーがシステム上のすべてのオブジェクトにアクセスが可能となる、という事実を受け入れなければなりません。
神話その5：セキュリティ･レベル20
セキュリティ･レベル20では、権限のチェックがないと誤解している人が多いようです。確かにそのように見えるのですが、実際はセキュリティ･レベル20の時でも、セキュリティ･レベル50の時と同じ権限チェック・アルゴリズムが実行されます。セキュリティのチェックが行われていないように見えるのは、デフォルトではすべてのプロファイルが特殊権限*ALLOBJで作成されているからなのです。したがってデフォルトでは、すべてのユーザーがシステム上のすべてのオブジェクトにアクセスすることができます。同じ権限チェック・アルゴリズムがすべてのレベルで使用されますから、プロファイルを一旦作成したら、そのプロファイルの特殊権限*ALLOBJを削除し、より高いセキュリティ・レベルにする前にセキュリティの構成をテストしてみると良いかもしれません。
神話その6：パスワードの有効期間
セキュリティ評価を実行した時に出力されるレポートの1つに、パスワードの有効期間が*NOMAXに設定されているプロファイルのリストがあります。そのようなプロファイルを調べると、パスワードが設定されていないプロファイルを見つけることもあります。パスワードがないプロファイル(つまりPASSWORD属性を*NONEに設定)に対して、パスワード有効期間を*NOMAXに設定している管理者もいます。システムがプロファイルをチェックするか、あるいはプロファイルのパスワードを変更するように要求してくるであろうと誤って思い込んでいるからです。しかしこれは事実と異なります。プロファイルにパスワードが設定されていない場合、パスワード有効期間属性はまったく考慮されません。したがって、パスワード有効期間をデフォルトの*SYSVALのままにしておき、パスワードが全く変更されていないプロファイルが存在していると監査人(およびわれわれ自身)がレポートすることにならないようにしておくのが安全でしょう。
神話その7：QAUDLVL2
監査ジャーナル・レシーバーをきちんとしていない組織がほとんどであることがわかりました。実際のところ、監査ジャーナル・レシーバーを全く保存することなくシステムから削除している組織さえありました。法令順守の観点からいえば、監査ジャーナル・レシーバーを保存しないことは、法令を順守していないことに相当する可能性があります。たとえばPayment Card Industry (PCI)では、監査情報を90日間オンラインまたはアクセスが容易な状態に保ち、すべての監査情報を最低1年は保持しておくことを要求しています。監査ジャーナル・レシーバーの保存方法が、1) イベントについて調査する必要が生じたときにどのレシーバーを復元しなければならないかが容易にわかる方法を提供していること、2) 組織の法令順守要件を考慮していること、を確認してください。
神話その8：オブジェクトの監査
せっかく監査の話題になりましたので、もう一つこれに関連するのがQAUDCTLシステム値です(このシステム値は監査機能をONにしたりOFFにしたりします)。QAUDCTLシステム値に*OBJAUDを指定していないと、個々のオブジェクトに対しては監査機能が働きません。もう少し説明しましょう。システムには、アクション監査とオブジェクト監査という2つのタイプの監査機能があります。アクション監査はオブジェクトの作成や削除、十分な権限を有しないユーザーからのアクセス(権限不足)などといったイベントを、ログとして記録します。オブジェクト監査は個々のオブジェクトを読み込んで更新します。オブジェクトが更新されたのになぜ監査のエントリがないのか教えてほしいと頼まれたことが何度かあります。そうした人たちは、監査をオブジェクト・コマンド(Change Object Auditing-CHGOBJAUDコマンド)を使用して構成していますが、QAUDCTLシステム値に*OBJAUDを追加し忘れているのです。
注：オブジェクトの監査エントリが出てこないもう一つの理由は、そのオブジェクトに対して実行したアクションが監査エントリを生成するように指定されていないからです。どのアクションが特定のオブジェクトに対するオブジェクトの監査エントリを生成するのかを調べるには、付録Eのセキュリティ参照マニュアルを参照してください。
神話その9：監査ジャーナル･エントリ
監査に関するもう一つの神話は、監査機能を有効にすると、生成されたすべての監査ジャーナル･エントリを精査しなければならない、というものです。どうしてこう考えられるようになったのかはよくわかりませんが、とにかくこれは事実ではありません。実際のところ、監査ジャーナルから定期的にレポートを作成している人でも、監査ジャーナル･エントリをすべて見ているわけではありません。すべてのエントリを精査している例を一度だけ見たことがありますが、その組織では、精査のために専任の社員を雇っていました。その社員がどれほど退屈だったであろうか、私には想像できません。監査機能を有効にしておくことをお勧めしますし、もちろんいくつかのレポートについては定期的に作成することもお勧めします。しかしレポートを作成しないとしても監査機能は有効にしておいて、万が一の際に何が起こったのかを調べるのに必要な情報を取得できるようにしておくことをお勧めします。監査ジャーナル･レシーバーを保存しておくことで、9か月前に発生したイベントについて調べることになった時に、倉庫からどのメディアを取り出せばよいのかが分かるようにしておいてください。
神話その10：非アクティブ・プロファイル
ご紹介したい最後の神話は非アクティブ・プロファイルの発見です。非アクティブ・プロファイルを削除したり、そのステータスを*DISABLEDに設定したりするのをためらう人が多いように思います。プロファイルがアクティブな状態にある時に削除されたという話も聞いたことがあります。いつも問題となるのは、誤った日付について精査されるということです。アクティブ・プロファイルが誤って削除された時にその理由を調べてみたら、最後にサイン・オンした日付を見ていたということでした。最後にサイン・オンした日付ではなく、最後に使用された日付を見るべきなのです。最後に使用された日付は、FTP経由なのか、ODBCなのか、ジョブをサブミットした結果なのか、システムにサイン・オンしたのかなど、そのプロファイルがどのように使用されたかには関係なく更新されます。ですから最後にサイン・オンした日付を見るのは止めて、最後に使用された日付を見てシステムをクリーン・アップしてください。
周りの人にも伝えてください
本稿をお読みいただいたことで、IBM i のセキュリティに関して皆さんが経験した神話のいくつかでも整理できたのではないかと思います。さて、ここでお読みになったことを他の人にも伝えていただき、みんながよりセキュアになれるようにしてください。
