現在、IBM i セキュリティを脅かしているもの
サイバーセキュリティの脅威の本質は絶えず変化しています。そのため、セキュリティの重要性に重きを置く人々による不断の警戒が求められています。IBM i は、脅威に晒されているのは、地球上の他のどのネットワーク オペレーティング システムとも同じですが、いくつかの点でユニークでもあり、実のところ、そのことによって、セキュリティがより困難なものになっています。2026年第1四半期現在で、これらの動向がどのように相互に関連し合っているかについて実情を知るべく、高名なKisco社のIBM i セキュリティ エキスパート、Carol Woodbury氏に話を伺いました。
先日、Woodbury氏は、 Kisco 社のオーナーで、ビジネス開発を率いるJustin Loeber氏と、「 IBM i Threat Landscape 2026：A Fireside Chat with Carol Woodbury （IBM i 脅威の展望2026：Carol Woodburyとの炉辺談話）」と題するウェビナーを開催しました。炉辺談話と言っても実際に暖炉はなかったようですが、攻撃者、ずさんな管理者、ソーシャル エクスプロイト、そして今ではどうやらAIによってもたらされる猛攻撃が絶え間なく続く中、IBM i サーバーをセキュアに保ちたいと思っている誰もが共有すべき有益な情報が紹介されているようです。
以下は、Woodbury氏とLoeber氏のプレゼンテーションの概要です。 こちらで視聴することもできます。
ソフトウェア脆弱性
脆弱なコードは、マルウェアやハッカーがソフトウェアを攻撃する取っ掛かりとなる穴を開けます。長年、 Microsoft 社は、同社のプラットフォームおよびアプリケーション コードの脆弱性に必死になって対応しては、影響を軽減する方策を講じてきたようです。 IBM および同社のIBM i サーバーは、信頼性の高いビジネス ソフトウェアの構築や稼働でより高い評判を得ていますが、脆弱性の影響をまったく受けないコードはありません。そして、今日、IBM i 上で稼働しているオープンソース ソフトウェアの量を考えると、実際のところ、どうやってもIBMの手に負えるものではありません。
「IBM i も、オープンソース ソフトウェアや、さらにはIBM i オペレーティング システムそのものに影響を及ぼす脆弱性を免れないとお考えなら、こちらのWebサイト（https://www.cve.org/）を訪れて、「IBM i」と入力して検索してみることです。これまでに登録されたすべての脆弱性を確認することができます。併せて、それらの修正プログラムへのリンクも示されています」とWoodbury氏は述べています。「きちんと記録されているのです。」
また、Loeber氏は、IBM i 管理者に、セキュリティ アラートを受け取れるようにIBMに登録しておくことも推奨しています。なお、小誌『 IT Jungle 』でも、Doug Bidwell氏による「 IBM i PTF Guide」が 隔週で公開 されています。
つまり、知らなかったでは済まなくなっているということです。
従来のIBM i 権限の迂回策
強力なユーザー プロファイルによってもたらされるリスクは、目新しいものではありません。これは、 Fortra社による「State of IBM i Security（IBM i セキュリティの現状調査）」レポートで、毎年取り上げられているものです。このレポートでは、IBM i のショップの大多数が、そうしたリスクを最小限に抑えるためのベスト プラクティスに 準拠していない ことが明らかにされています。そして、IBM i のショップが、5250スクリーンからのユーザー アクセスを制限することによってシステムをロック ダウンしていると思っていたとしても、それを迂回する方法はあるのです。
「多くの人が理解していないことの1つは、「SQLスクリプトの実行」からSQLコマンドを実行できるということです」とWoodbury氏は述べています。「そして、IBMから数多くのSQLの用例が提供されているので、それらを自分で使用して、様々なセキュリティ設定や数多くの他の様々な種類の設定を確認することができます。」
Woodbury氏はウェビナーで、「SQLスクリプトの実行」を使用して、共通権限が*EXCLUDEに設定されておらず、ファイルの修正を行えるライブラリーを探す方法を紹介しています。適切に構成されていないシステムでは、特殊権限を何も持たないユーザーが、実際に、かなりのパワーを手にすることができるという実例です。
侵入テストを実施する際には、Woodbury氏は、PUBLIC *EXCLUDEに設定されていないユーザー プロファイルを探すことが多いということです。残念ながら、実際には、IBM i サーバーに、ロック ダウンされておらず、攻撃者によって勝手に使われる可能性がある強力なユーザー プロファイルがあるというケースはかなりよくあることです。
「こちらを見てください」と彼女は述べます。「これは、すべての特殊権限を持っているが、PUBLIC *EXCLUDEではないユーザー プロファイルです。これがめったにないことであればよいのですが、そうではありません。」
ユーザー プロファイルを乗っ取る
Woodbury氏は、特殊権限を何も持たない非力なユーザー プロファイルが、「SQLスクリプトの実行」を使用することによって、どのようにして強力な権限を持つ別のユーザー プロファイルを見つけることができるかをデモで示しました。次いで、いくつかの簡単なコマンドを実行して、そうした強力なユーザーを本質的に乗っ取ってシステムへのフル アクセスを獲得する方法を紹介しています。,/p>
「これで、コマンド ライン アクセスが可能になり、実行したいものは何でも実行できるようになりました」と彼女は述べています。「システム内のすべてのユーザー プロファイルを見ることができますし、それらを修正したり、削除したりすることもできます。システム上のどのオブジェクトの処理も行えます。私は、やりたいことを何でもやることができます。繰り返しになりますが、これは、すべての特殊権限を持っているからです。やはり、これも極端な例であったらよいのですが、セキュリティ診断および侵入テストを実施すると、このようなタイプの構成が見つかることの方が多くなりがちです。」
IBM i は、明らかにこうした種類の攻撃に脆弱だとLoeber氏は述べています。「IBM i は、攻撃に脆弱であるというだけではなく、皆さんの環境内にある他のシステムと比べても、より脆弱であるかもしれません。というのも、権限を持たない一般のユーザーが、システムを乗っ取って、意図されていない権限で侵入する経路を生み出す、このような隠れた構成があるからです。」
隠ぺいによるセキュリティ（Security Through Obscurity）
Woodbury氏がデモで示した乗っ取りシナリオを成功させるには、ある程度のIBM i に関する知識が必要となることも事実です。コマンド ラインを迂回し、SQLの途方もないパワーを使用して、保護されていないユーザー プロファイルを探し出し、そのユーザー プロファイルを通じてコマンドを実行するという方法は、誰でも知っているわけではありません。しかし、AIのパワーのおかげで、そうした知識は、キーボードを何回か叩くだけで得ることができます。
「Googleで検索するだけです」とWoodbury氏は述べています。「このケースでは私はGemini AIを使用していますが、どのようなSQLがIBM i 内のすべてのライブラリーをリストアップするのか検索しただけです。そして、このような結果が表示されました。そのため、IBM i それ自体からでも、簡単な検索を通じてでも、IBM i についてさらに多くの情報を見つけるのは非常に簡単です。」
Geminiは（一般にアクセスできるものであれば、他のどの大規模言語モデルでも同じですが）、IBM i におけるソフトウェア脆弱性をリストアップするのにも使用することができます（そして、Woodbury氏は口にしていませんが、尋ね方を工夫すれば、おそらく、AIモデルにエクスプロイト コードを生成させることもできるでしょう）。「Microsoft Copilotでさえも、IBM i に関する情報を見つけて提示することができます」とWoodbury氏は述べています。「隠ぺいによって守られている気になったままではいられないのです。」
隠ぺいによるセキュリティは、決して頼りにしたいと思うようなものではありませんでした。しかし、IBM i およびSystem Zメインフレームのような、いわゆるレガシー システムは、外の世界からはブラック ボックスとして見られていました。隠ぺいによるセキュリティによってもたらされていたどのような保護も、AIによって完全に壊されたとLoeber氏は述べています。
「誤解のないように言っておくと、私たちはIBM i をレガシー テクノロジーとして見なしているわけではありません。しかし、今日でもまだ、10年～20年前のセキュリティ構成で稼働しているのです」とLoeber氏は述べます。「私たちが目にしたそうしたリスクのいくつかについては、それらに対する共通権限を持つユーザー プロファイルやそのようなものと同様に、そうしたものがシステムに潜んでいることに気付いていないのかもしれません。したがって、それこそが、Kisco Systems社のセキュリティ診断および侵入テスト サービスの対象となるべきユース ケースだと言えるでしょう。」
エージェント型AI
世界中が、エージェント型AIにがむしゃらに突き進んでいます。エージェント型AIは、骨の折れる単調な仕事というくびきを振り落として、私たちが浜辺でトロピカル ドリンクを手に持って、まばゆい至福の中で暮らせるようにする夢のテクノロジーだと思われています。
しかし、現実の世界では、エージェント型AIは、すでにかなり長くなっているセキュリティ リスクのリストに追加するべき、もうひとつのセキュリティ リスクとなっています。
「エージェントというのは、私たちのブレーンになり、私たちがどのような作業を行っているかを理解して、私たちに代わってそうした作業を行ってくれるものだと認識してます。これは素晴らしいことです」とWoodbury氏は述べています。「しかし、組織内の他の部門と対話を行うため、それら以外のことを行うことも想定されます。また、率直に言えば、暴走する可能性もあります。」
人間による監視が一切なしで、AIエージェントを組織内で自由にさせることができると考える人は、頭の中を検査してもらった方が良いのかもしれません。Woodbury氏は、もっと如才ない言い回しをしています。「彼らは、誰かが真ん中にいてエージェントの監視を行う必要などないと主張します。しかし、エージェントが指示に従順であり、行うとされていることを実際に行っており、さらには暴走していないということを確認するために、常に誰かがフローを監視している必要があると言えるのではないでしょうか」と彼女は述べます。
AIエージェントは、ユーザー プロファイルを持つ、IBM i システム上の他のユーザーのようなものです。したがって、可能な限り権限を少なくするように構成するべきです。また、Woodbury氏はIBM i のショップに、AIエージェント間での接続も最小限にするよう推奨しています。
MCPのセキュリティ
Loeber氏は、ユーザー グループ イベントで行われた、Model Context Protocol（MCP：モデル コンテキスト プロトコル）をテーマとする、IBMによるAIに関するデモ セッションに参加したということです。MCPは、2024年末に Anthropic 社によって開発された、エージェントが互いに対話し合って、データ ソースにアクセスすることを可能にするプロトコルです。MCPはすぐに標準となり、IBMでも現在、IBM i 向け MCPサーバーの開発に取り組んでいます 。
「非常に興味深かったのですが、MCPのセキュリティに関する情報は極めて少なかったようです」とLoeber氏はIBMのデモについて述べています。
実際のところ、MCPは強力ですが、まだまったく目新しいものだということです。最初のリリースではMCPに組み込まれたセキュリティ機能はありませんでした。そして、OAuth 2.1認証の追加や認証モデルの改善など、2025年にMCPのセキュリティを改善する方策が講じられましたが、セキュリティの面からすると、それはまだ、まったく未熟なものでした。
このことは、エージェント型AI向けにMCPを採用したいと考えているIBM i のショップは、MCPをセキュアでないものとして扱う必要があり、したがって、その周りの至る所でセキュリティを構築する必要があることを意味します。
「IBM i に関して言えば、覚えておくべき、または考慮に入れるべき本当に重要なことは、すべてのエージェントの背後にクエリーがあるということです」とLoeber氏は述べています。「エージェント型AIに関するガバナンスは、他のシステムの場合と同様に、データ アクセスに関するガバナンスと大いに関連しています。」
IBMは、IBMの 新たなMapepireデータベース クライアント を、AIおよびMCP接続向けの主力クライアントとして位置付けています。内部的には、Mapepireは実質的にODBCであるため、IBM i のショップがODBC接続のロック ダウンに関連して講じるセキュリティ対策はすべて、AI向けのIBM i Mapepireの接続にも適用されるとLoeber氏は述べます。
「こうしたODBCセキュリティ上の懸念について繰り返し言えば、これらすべての直接のデータベースへの接続は、メニュー セキュリティのようなものに関しては、すべてのアプリケーション セキュリティを迂回します」と彼は述べます。「これらの接続は、エージェントを含めて、これらのタイプの接続を通じて入って来るユーザーが、セキュリティ対策が施されていないどのファイル オブジェクトにもアクセスするのを可能にし、CLコマンドを実行することさえできます。」
可視性の欠如
Kisco社は、顧客と協働してエージェント型AIプロジェクトに取り組んでおり、課題の1つに、エージェントをロック ダウンすることと同様に、エージェントが行っているすべての処理に対する可視性を高めることがあるということです。
「SQLサーバーの出口点および他の出口点を使用して、それらのエージェントのユーザー プロファイル関連のアクティビティを追跡することができました。それから、セキュリティ監査ジャーナルには多くの情報があります。そして、私たちはいくつかのアウトバウンドのSKジャーナル項目に注目してきました。これは、基本的にエージェント プログラムがいつ外部APIに接続するかを識別するためのソケットまたはIPトラフィックです」とLoeber氏は述べています。
IBM i は監査ジャーナルを通じて包括的なロギング機能を提供していますが、企業の全体的なセキュリティ露出の実際の状況を把握するためには、他のシステムからのアクティビティのコンテキストの中で利用する必要があります。多くの場合、それには、サードパーティーのセキュリティ情報およびイベント管理（SIEM）ツールにIBM i ジャーナル データを移動して、単一の場所で複数のサーバー、システム、およびネットワークからのデータを組み合わせて、分析することが必要となります。
「私たちの視野は、サイロ化されていることが多いです」とWoodbury氏は述べています。「組織のうちIBM i 以外の部分と、IBM i の部分があります。そして、IBM i に目を向けるのはIBM i のユーザーだけです。しかし、これではまだ、全体像は分かりません。全体像を把握し、本当に組織の現状が分かるのは、2つを合わせてからのことです。」
ソーシャル エンジニアリング
パスワードのリセットのような処理のためにヘルプ デスクに問い合わせできるようにすることは、IT部門の運用で欠かせない部分です。しかし、ヘルプ デスクは、ソーシャル エンジニアリング攻撃に脆弱であるため、セキュリティ スキームの弱点となっています。
「率直に言って、これはセキュリティ侵害を目的とした組織への侵入地点となることが多いようです」とWoodbury氏は述べています。「ヘルプ デスクは、有用であるのが当たり前とされていますが、時折、有用過ぎることもあります。攻撃者がそうした情報を使用して、組織内へのアクセスを獲得する手法が数多くあります。」
ソーシャル エンジニアリングに対する一番の防護策は、従業員に対策プログラムを提供することです。企業は、緊急性を匂わす電話、テキスト、またはメールを受け取った場合、それは詐欺である可能性が高いと理解するように従業員を訓練しておかなければならないとWoodbury氏は述べています。「それが問題となることを頭に叩き込む必要があります」と彼女は述べます。「それから、ディープ フェイクもあります。」
AIの性能が非常に向上しているため、社内のエグゼクティブの信ぴょう性のある偽の映像を生成するのは非常に簡単です。また、こうしたディープ フェイクには、AI生成のマルウェアを含めることもできため、顧客が知らずにそれをラップトップ上にロードしてしまう可能性もあるとWoodbury氏は述べています。不適切なセキュリティ構成、アクティブでないユーザー プロファイル、保護されていないファイル、および監視の不足が組み合わさると、攻撃者が望みのものを手に入れるための梃子として働くこともあります。
インサイダー脅威
外部のハッカーがサーバーを乗っ取るというイメージは、セキュリティ管理者の夢の中には何度も出て来るかもしれませんが、より大きな脅威は、本社のオフィスを囲む4面の壁の内側に潜んでいるのかもしれません。増大するインサイダー（内部関係者）の脅威に立ち向かうべき時だとWoodbury氏は述べています。
「誰も認めたがらないことですが、従業員が悪事を働くケースは増加しています」と彼女は述べます。「以前、この問題を切り出してみたところ、返ってきた反応はこうでした。「でも、私たちは私たちの従業員を信用しています。全面的に信用できないのなら、彼らは従業員とは言えないでしょう」 しかし、実際のところ、人々の生活の中では、普通なら行わないことや、雇用されたばかりの頃には行わなかったようなことを行うに至らしめる事情が生じているのです。そして、誰にでも起こるというわけではありませんが、起こり得るということは認めざるを得ません。」
私たちは、データがハッキングされたり、失われたりすることを想定していないかもしれませんが、それでも、不正なデータ アクセスやデータ損失を防ぐために基本的な予防措置を講じています。同じことは、インサイダー（特にIBM i システムへの昇格アクセスを持つ内部関係者）にも適用されるべきです。AIの脅威とソーシャル エンジニアリングの脅威は1つに収斂するため、この点は特に重要だとWoodbury氏は述べています。
「誰かがソーシャル エンジニアリング攻撃に脆弱であるとしたら、その1人のユーザーの認証情報を使用して、エージェント型AIが組織内に入り込んでいることが予想されます」と彼女は述べます。「繰り返しになりますが、ユーザーがジョブを行うのに必要なだけの権限しか持たないようにし、MFAを実装することで、そうした攻撃を遮断できるようにすることです。」
