IBM i の*USRPRFのセキュリティ
IBM i は、長年にわたって、業界でも最もセキュアにすることができるアプリケーション サーバーの1つとして知られてきました。IBM i のオブジェクト カプセル化またはオブジェクト指向アーキテクチャーは、QSECURITYが40または50に設定されている限り、Unix、Linux、およびWindowsなどのファイルベースのシステムでは見られないレベルのテクノロジー整合性を実現します。
しかし、こうした先進的なテクノロジーであっても、開発チームが「DevSecOps」（nist.gov CSRC）および「Zero Trust Architecture」（NIST）を実践していなければ、セキュリティ リスクからIBM iが除外されることはありません。
「アジャイル ソフトウェア開発宣言（Agile Manifesto）」の主要署名者の1人であるRobert Martin氏は、著書の『 Clean Agile: Back to Basics（Clean Agile 基本に立ち戻れ）』でこう述べています。「アジャイルとは、小さなことをしている小さなプログラミング チームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミング チームの大きな問題を扱う大きなアイデアではない。」
IBM i における最大の脆弱性のうちの2つは、特権昇格と適切なアクセス制御の欠如です。まずは、認証と許可について確認しておきましょう。認証は、資格情報またはトークン（一般にはパスワード）を通じてユーザーを識別および検証するプロセスです。許可は、データベース、ユーザー プロファイル、その他の機密オブジェクトなどの、リソースに対するアクセス制御を通じて認証が行われた後で行われるものです。セキュリティの脅威という点から言えば、機密オブジェクトへの排他的アクセスはサイバーセキュリティの基本であり、排他的でないアクセスは企業にとってのリスクとなります。
「iSeries Profile Hijacking」や、「iSeries Profile Hacking」で検索してみるだけでも、どうして*USRPRFのセキュリティが極めて重要なのかについて解説する記事や用例が数多くヒットすることと思われます（それぞれ「Stealing User Profiles!（ユーザー プロファイルを盗み取る）」、「Hacking an IBM i （linkedin.com） （IBM i をハッキングする）」の記事がヒット）。
IBM i では、ユーザー プロファイルは、「王国の鍵」です。ユーザー プロファイルなしでは、誰も認証できません。CRTUSRPRFコマンドには、PASSWORD（14文字以上の安全性の高いパスフレーズにするべき）のような、セキュリティ関連のパラメーターが多数あります。また、USRCLSは*USERにするべきであり、SPCAUTは*NONEにするべきであり、AUTは必ず*EXCLUDEにするべきです。
以下は、セキュアな*USRPRFの権限の標準的な設定例です。
Object . . . . . . . : XXXXXX Owner . . . . . . . : QSECOFR
Library . . . . . : QSYS Primary group . . . : *NONE
Object type . . . . : *USRPRF ASP device . . . . . : *SYSBAS
Object
User Group Authority
*PUBLIC *EXCLUDE
QSECOFR *ALL
XXXXXX USER DEFさらに、QSECOFRは、すべてのユーザー プロファイルの所有者である必要があり、QIBM_QSY_CRT_PROFILE出口点に登録された出口プログラム（ユーザー プロファイル作成出口プログラム）を通じて管理することができます。*USRPRFは、自身に対する権限を持つ必要があり、*PUBLICは*EXCLUDEである必要があります。他にはどの権限も存在するべきではありません。
アプリケーションを開発する際に、多くのWebサービスおよび他のプロセスが、別のプロファイルの下で稼働するジョブを必要とする場合があります。これは、最小特権の原則（PoLP: Principle of Least Privilege）を使用していて、かつ、*USRPRFオブジェクトに*PUBLICまたは専用権限を設定しているのでない限り、問題はありません。セキュアなプロファイル スワップを実行し、プロファイルのセキュリティおよび所有権を保持するには、プログラム スワップ（DevSecOps）は、*USRPRFオブジェクトへのアクセスをプログラム的にカプセル化して、プログラム内にスワップを制限し、設計されたプログラム アーキテクチャーの外部からの*USRPRFオブジェクトへのアドホックなアクセスを行えなくする必要があります。
セキュアなスワップ プロセスの外部からの*USRPRFオブジェクトへのアクセスを許可すると、悪意あるアクティビティにつながる可能性のある、設計されたプロセスの外部からの*USRPRFオブジェクトへのアドホックなアクセスが可能になります。以下は、*USRPRFに対する権限が、どのようにリモート コマンド プロンプトから悪意を持って使用されるかを示す1つの例です。
rmtcmd /SYSTEM=systema /CMD="SBMJOB CMD(CRTUSRPRF USRPRF(QSECOPR) PASSWORD(passw0rd) USRCLS(*SECOFR)) USER(xxxxxx)".この例では、認証は必要とされず、許可のみであることに注目してください。
Windows CMDシェルまたはDB2接続などの他のソースから実行されるリモート コマンドは、8つの特殊権限すべてを持つプロファイル、QSECOPR（実際のインシデントであるため、スペルを伏せています）を作成することができ、これはXXXXXXによって所有されます。脆弱なシステムには、特殊権限を持つ、専用および*PUBLIC権限が設定されたプロファイルが多数あるというケースがよくあります。1つの*ALLOBJを持つプロファイルで、他のいずれかのプロファイルへのアクセスを取得して、*SECOFRの権限を取得することができることに注意してください。
また、リモート コマンドは、機能制限を回避する場合もあり、Windows CMDプロンプト、LinuxまたはUNIXのリモート シェル、ODBC、SSH、およびその他の多くのリモート ロケーションから、または別のIBM i から実行することもできます。また、SSHのように、一部のリモート プロトコルは、関連付けられている出口点を持たない場合もあります。機能制限（LMTCPB）と出口プログラムのみを頼りにするのでは、十分とは言えません。
さらに、SIEM管理者が検知できるのは、彼らが知っていることだけであり、プロファイルのセキュリティ上の弱点を検知するたびに、どうしてそれらが許可されてきたのか知っている人を見つけられることはまずありません。サイバーセキュリティでは知られている通りです（『 SecurityWeek』の「 You Can't Defend What You Can't See: Why Visibility is Critical for Improving Cyber Defense （守れるのは見えるものだけ: サイバー ディフェンスの強化に可視性が重要である理由）」を参照）。
専用または*PUBLIC権限が設定されたプロファイルのアドホックなセキュリティ露出を防ぐには、セキュアなプログラムによるスワップを使用し、*ALLOBJおよび*SECADM特殊権限を借用している別個のサービス プログラムにスワップAPIを移動して、メイン プログラム内でこのサービス プログラムを呼び出して、プロファイルに対するAUTの必要なくスワップを実行します。以下がその例です。
/* Call QSYGETPH to get a profile handle for a user. */
/* NOTE: Change XXX to the user who you want to swap to. */
CALL QSYS/QSYGETPH ('XXX' '*NOPWDCHK' &HNDL)
/* Call QWTSETP to swap to the profile. */
CALL QSYS/QWTSETP &HNDL個別の要件によっては、修正や、とりわけ追加のコードおよび変数が必要となる場合がありますが、メイン アプリケーション コードを、スワップを実行するサービス プログラムに入れないように注意してください。
考慮すべき重要な点がいくつかあります。
- 現行のプロファイルの権限および所有権はどのようになっているか。
- 最小特権の原則（規制要件）を常に使用する。
- スワップは、認可されている機能およびデータ セットのみに制限されるようにする。
1つの例: 「PCI DSS 8.7 - データベースへの直接アクセスまたはクエリはデータベース管理者のみに制限される。」
コンプライアンス要件を把握してそれに従い、ここで説明した脆弱性や他の多くの脆弱性を見つけて修正するガイドをしてもらえる、ツール（BFB Security）とナレッジを備えたSME（対象分野の専門家）を見つけることです。守れるのは自分が知っているものだけです。リスクに晒されている人にとっては、今こそが修正を行うべき時です。セキュリティ侵害の被害を受けてしまった人にとっては、昨日こそが修正を行うべき時だったということです。
