IBM i 特権アカウント管理、そして特殊権限の何がそれほど特殊なのか
特権アカウント管理（PAM）は、サイバーセキュリティの要となる部分です。どこを向いても、 PAMはホットな話題です。どのように、そしてなぜ、PAMについて心配する必要があるのでしょうか。サイバー攻撃およびインサイダー脅威からエンドポイントを保護することは極めて重要であると、IBM、Ponemon、Verizonなど、各社が述べています。Verizon社のDBIR（データ漏洩/侵害調査報告書）では、セキュリティ インシデントの80%は外部からの脅威が占めていると述べる一方で、データ侵害につながるインシデントについては、反対に、インサイダー脅威が10対1以上の比率でアウトサイダー脅威を上回ることを示す調査結果について指摘しています。 Verizon社はこのようにまとめています。「このことは、アウトサイダーよりも、特権を持つ内部関係者の方が、組織により多くの被害を与えることができるという法則を裏付ける結果となっています。」
また、 IBM Securityの推定 によれば、インサイダーが関連するインシデントの平均的なコストは1,792万ドルということです。では、どうしてこれがIBM i にとって一大事なのでしょうか。まずは、「 IBM i セキュリティーについて - IBM Documentation」から見て行きましょう。また、少し掘り下げれば、「 機密漏れの防止と検出 - IBM Documentation」という記事も参考になります。さらに、出口プログラムが全体的戦略の一部であることについては、 先月の記事で取り上げた通りです。私は2017年に、IBMビジネス パートナーであるBFB Security社を設立するまで、長年、ロチェスターでシニア セキュリティ アーキテクトを務めていましたが、ロチェスターの優秀な元同僚たちは、私たちが CIS IBM i ベンチマークに組み込んだすべての項目についてレビューを行い、同意してくれています。これには、出口点およびSIEMにとどまらず、人員、プロセス、およびツールも含まれています。
話はPAMに戻りますが、これが特殊権限とどのように関係しているのでしょうか。IBM i の「機密保護解説書」やKnowledge Centerの「 特殊権限」に関する記事をご覧になれば、私たちが皆、最大のリスク項目の1つとして特殊権限を挙げていることがお分かりいただけるでしょう。第1に、*USERクラス ユーザーを作成して、*SPLCTLまたは*JOBCTLを付与すると、そのユーザー クラスと特殊権限の間ですでにミスマッチが生じています。第2に、アプリケーション*USERクラス ユーザーがこれらの2つの権限のいずれかを必要とする理由はまったくありません。さて、どういうことでしょうか。ただし、これらの権限なしではシステムは機能しないとおっしゃる方もいるかもしれません。しかし、それはまったく正しくありません。
待ち行列の設定および権限を変更すると、*SPLCTL/*JOBCTLの問題の99%は修正されます。このような例があります。多くのアプリケーションは一般のユーザーとして出力をスプールします。ここでは、仮に、ユーザーがSPLUSERであるとしましょう。ユーザーがアプリケーションを実行し、スプール出力はSPLUSERによって所有されます。*SPLCTLまたは*JOBCTLを付与していなければ、SPLUSERによって所有されているスプール ファイルをユーザーは表示できないことにお気付きかと思います。いったん終了です。
IBM i の「機密保護解説書」やKnowledge Centerの 待ち行列コマンド に関する記事には、それを行う方法に関する詳細な説明が記されています。表全体に目を通すと時間が掛かるので、以下に要点のみを示します。待ち行列のAUTCHKパラメーターをデフォルト値の*OWNERから*DTAAUTへ変更し、待ち行列に対する*CHANGE権限をユーザーに付与することができます。これで、ユーザーは、自分が所有していない、または、アプリケーション ユーザーによって所有されているスプール ファイルに対して読み取り、削除、およびすべてのアクションを実行することができるようになります。
例: CHGOUTQ OUTQ(QGPL/TEST) AUTCHK(*DTAAUT)これで、おそらく、機密待ち行列に対する*PUBLICおよび専用権限を通じてそれらの待ち行列に対するアクセスの制御も行いながら、*JOBCTLや*SPLCTL特殊権限を除去できるようになるでしょう。*JOBCTLおよび*SPLCTLでは、待ち行列の権限を制御できません。
さらにまた、あらゆるコンプライアンス フレームワークによって、最小特権の原則（PoLP: the Principle of Least Privilege）が求められています。「NIST文書800-53」で、「Least Privilege（最小特権）」を検索してみてください。至るところで言及されているのが分かると思います。セクションAC-6では、次のように記されています。
「設定された組織のタスクを実行するために必要なユーザ（またはユーザに代わって動作するプロセス）に対して認可されたアクセスのみを許可する、最小特権の原則を採用する。
詳解：組織は、特定の職務およびシステムに対して最小特権を採用する。最小特権の原則はシステムプロセスにも適用され、プロセスがシステムにアクセスし、組織のミッションまたは事業機能を達成するために必要なレベル以下の特権レベルで動作することを保証する。」
*JOBCTL特殊権限を例に取りましょう。IBM i の「機密保護解説書」では、*JOBCTLに関連するリスクについて次のように記されています。
「リスク: ユーザーが *JOBCTL 特殊権限を濫用すると、個々のジョブおよび システム・パフォーマンス全般に悪影響が出ます。」
これは、*JOBCTL特殊権限によって、システム ジョブおよびシステム上のすべての他ユーザーのジョブを含む、あらゆるジョブの終了、変更、制御などを行えるようになるためです。
*SPLCTLには、次のようなリスクがあります。「*SPLCTL 特殊権限を持つユーザーは、システムのすべての スプール・ファイルにおいて任意の操作を行うことができます。 機密スプール・ファイルを、*SPLCTL 特殊権限を持つユーザーから保護することはできません。」
その他の6つの特殊権限は、システムの機密性、保全性、および使用可能度の他の側面に影響を及ぼし得る強力な特権を管理者に与えます。ほぼすべてが、待ち行列の権限に対する適切なアクセス制御および変更を通じて修正することができます。残りは、借用およびスワップされた権限を適切に使用することで修正することができます。
そのため、最小以上の特権の原則（PoMMtLP: the Principle of Much More than Least Privilege）をユーザーに適用する場合は、事前に、 NISTのPoLPの要件 を十分に検討し、IBM i Knowledge Centerの特殊権限に関するセクションを参照しておくようにしてください。
アジャイルは、利息を付けて返済しなければならないセキュリティ負債へと転換される技術的負債を生み出します。「アジャイル ソフトウェア開発宣言（Agile Manifesto）」の主要署名者であるRobert C. Martin氏はこう述べています。「アジャイルは、小さなチームが小さなソフトウェア プロジェクトを構築するのに役立つ、原則、慣習、および規制を集めたものである。アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。」
今日のようにセキュリティ侵害が頻発している環境では、大規模なシステムは変化することが求められます。「Fail fast, not twice（早く失敗せよ。ただし同じ失敗は2度してはならない）。」 このことが意味するのは、 DevSecOpsでは、開発者とサイバーセキュリティの専門家を協働させることが必要だということです。
よく分かっていないものを保護することはできません。また、特殊権限や特権があまりにも多く付与されている大規模なIBM i システム内で、どのようなことが起こっているのか把握するのは困難です。特殊権限や特権は、ユーザー、グループ、*PUBLICおよび専用権限を持つプロファイル、借用およびスワップされた権限などを通じて、様々な方法で取得することができます。PAMは、あらゆるシステムで重要視されるようになっており、 ゼロ トラスト はニュー ノーマル（新しい常態）となっています。
リスクに晒されている人にとっては、 今こそが修正を行うべき時です。セキュリティ侵害の被害を受けてしまった人にとっては、 昨日こそが修正を行うべき時だったということです。
