IBM i（AS400）に脆弱性診断は必要？「IBM iだから安全」が危ない5つのリスクと診断の進め方

企業の情報漏洩やランサムウェア被害が相次ぎ、業種や規模を問わずあらゆる組織が標的になる時代です。それでも、長年安定して動いてきたIBM iについては「IBM iだから安全」「これまで問題がなかったから大丈夫」と考えていないでしょうか。IBM iそのものが堅牢でも、ユーザー権限の過剰付与、アクセス制御の不備、セキュリティ設定の見落とし、修正プログラム（PTF）の未適用があれば、そこが不正アクセスの入口になります。こうした設定は日々の運用では目に見えにくく、担当者が気づかないまま何年も残りがちです。

本記事では、IBM iで見落とされやすい5つのリスクと、脆弱性診断で何を調べ、どう進めればよいかを解説します。

IBM iの安全性は適切な設定管理が前提となるため、定期的な診断で現状を可視化し、優先順位をつけて是正を進めることが重要です。

IBM iの脆弱性診断とは？一般的な脆弱性診断との違い

IBM iの脆弱性診断とは、日本アイ・ビー・エム株式会社が提供する基幹系OS「IBM i（旧称AS/400）」の環境において、情報漏洩やデータ改ざんにつながる設定上の不備やセキュリティリスクを洗い出す調査のことです。一般的な脆弱性診断がWindowsやLinuxのサーバー、あるいはWebアプリケーションを対象にネットワークの外部から疑似攻撃を行うのに対し、IBM iの脆弱性診断ではOS内部の固有設定や権限構造を直接調査するという大きな違いがあります。

IBM iは独自のアーキテクチャを持っており、一般的なオープン系システムとはセキュリティの管理モデルが根本から異なります。そのため、一般的な診断手法やツールをそのまま適用しても、IBM iの内部に潜む本当のリスクを正確に把握することはできません。ここでは、一般的な脆弱性診断との違いを整理し、IBM iの診断で具体的にどこを見るのかをわかりやすく解説します。

一般的な脆弱性診断（Web・プラットフォーム診断）がカバーする範囲

一般的な脆弱性診断であるWebアプリケーション診断やプラットフォーム診断がカバーする範囲は、主にネットワークの「外側から見える弱点」です。独立行政法人情報処理推進機構（IPA）が公開している「安全なウェブサイトの作り方」などでも触れられている通り、多くのシステムではOSやミドルウェアの既知のバグ、Webプログラムの不備を突いた外部からの攻撃が脅威となるためです。

具体的には、診断ツールから対象サーバーに対して検査用の通信を送り、不要な通信ポートが開いていないか、古いバージョンのソフトウェアが稼働していないか、SQLインジェクションなどの攻撃手法が成立しないかといった点を検出できます。しかし、この手法をIBM iに対して実行しても、得られる情報はごく一部に限られます。

なぜなら、IBM iの核となるデータベース（Db2 for i）や基幹業務プログラムの多くは、一般的なWebサーバーとは異なる独自の仕組みで保護されており、外部からの通信テストだけでは内部のアクセス制御の状態まで判別できないからです。その結果、一般的なプラットフォーム診断では「問題なし」と判定されても、IBM iの内部には重大な設定不備が残っているというケースが少なくありません。

IBM iの診断は「OS内部の権限と設定」を調べる

これに対し、IBM iの診断は「OS内部の権限と設定」を直接調べる手法をとります。IBM iはオブジェクト指向のアーキテクチャを採用しており、OS自体が高度なセキュリティ機能を標準で備えている反面、その安全性の高さは「管理者が適切な設定を行っていること」に強く依存しているためです。

たとえば、長年の運用や開発の利便性を優先した結果、一般のユーザーアカウントに対してすべてのデータにアクセスできる強力な権限が付与されたままになっていたり、ネットワーク経由のファイル転送が無制限に許可されていたりする状態が挙げられます。これらはOSのプログラム上の欠陥（バグ）ではなく運用上の「設定不備」であるため、外部からバグを探す一般的な診断ツールでは見つけることができません。

そのため、IBM iの脆弱性診断では、システム内部の情報を取得し、IBM i固有の仕組みに照らし合わせて設定の妥当性を評価します。一般的な脆弱性診断とIBM iの脆弱性診断の違いを整理すると、以下のようになります。

このように、IBM iのセキュリティを正しく評価するためには、一般的なネットワーク越しの検査ではなく、OS内部のシステム設定やユーザー権限、データへのアクセス経路を詳細に点検する専用のアプローチが不可欠です。

「IBM iだから安全」は本当？見落とされやすい5つのリスク

「IBM iだから安全」という認識は、現代のシステム環境においては必ずしも当てはまりません。確かにIBM iは、すべてのデータをオブジェクトという単位で管理し、実行ファイルとデータファイルを明確に分離する独自の構造を持っています。そのため、WindowsやLinuxなどの一般的なOSと比べて、OS自体がウイルスに感染しにくいことは事実です。

しかし、OSの構造が堅牢であることと、日々の運用におけるセキュリティ設定が安全であることは別問題です。運用上の利便性を優先した設定や、初期構築時の古い設定が放置されていることで、以下のような5つのリスクが多くの現場で見落とされています。

リスク1　ユーザー権限の過剰付与（特殊権限*ALLOBJなど）

ユーザー権限の過剰付与、特に特殊権限である「*ALLOBJ（全オブジェクト権限）」などの不適切な割り当ては、IBM iのセキュリティを根底から揺るがすリスクです。IBM iには、役割に応じた8つの特殊権限が用意されており、その中でも*ALLOBJはシステム内のあらゆるデータやプログラムに対して無制限にアクセスできる強力な権限です。

本来の運用では、システム管理者以外の一般ユーザーに*ALLOBJを付与すべきではありません。しかし、アプリケーションの開発時やトラブル対応時に「権限エラーが出て業務が止まるのを防ぎたい」という理由から、開発担当者や一般社員のユーザー・プロファイルに*ALLOBJを付与したまま運用を続けているケースが多々あります。

また、初期導入時から存在するデフォルトのユーザー・プロファイル（QSECOFRやQPGMRなど）のパスワードが初期値のままであったり、複数の担当者で共有されたりしている状態も危険です。もし*ALLOBJを持つアカウントのIDとパスワードが外部の攻撃者に窃取された場合、基幹データの全削除や改ざんなど、システム全体を完全に掌握される事態につながります。

リスク2　PUBLIC権限・オブジェクト権限の設定不備

PUBLIC権限・オブジェクト権限の設定不備は、先の特殊権限を持たない一般ユーザーであっても、重要なデータにアクセスできてしまう状態を引き起こします。IBM iでは、ファイルやライブラリなどのオブジェクトごとにアクセス権限（オブジェクト権限）を設定できますが、個別の権限が指定されていないすべてのユーザーに適用される共通の権限が「PUBLIC権限（*PUBLIC）」です。

IBM iの初期設定では、ライブラリやオブジェクトを新規作成した際、PUBLIC権限が「*CHANGE（変更）」や「*ALL（すべて）」になるよう設定されている場合があります。この初期設定を見直さずに運用していると、新たに作られた顧客マスターや売上データに対して、社内の全ユーザーが閲覧・変更できる状態が自動的に作られてしまいます。

業務上そのデータを扱う必要がない部署の社員でも、システムにサインオンさえできれば機密情報を書き換えたり削除したりできるため、内部不正や操作ミスによる情報漏洩・データ破損のリスクが高まります。

リスク3　FTP・ODBCなどネットワーク経由のアクセス制御の抜け道

FTP・ODBCなどネットワーク経由のアクセス制御の抜け道は、IBM iの画面メニューによる制限を完全に無効化してしまう重大なリスクです。多くの企業では、5250エミュレータ（グリーンスクリーン）でサインオンした後の初期メニューを制限し、担当業務以外のプログラムやコマンドを実行できないように制御しています。

しかし、このメニュー制御はあくまで「5250画面から操作した場合」にのみ有効な仕組みです。パソコンからネットワーク経由で直接ファイル転送を行うFTPや、Microsoft CorporationのExcelなどからデータベースへ直接接続できるODBC/JDBCといった通信プロトコルを利用した場合、初期メニューを経由せずにIBM i内部のデータへ直接アクセスできます。

このとき、リスク1やリスク2で挙げたようにユーザー権限やPUBLIC権限が甘いままだと、画面上では操作を制限されているはずの一般ユーザーが、手元のパソコンから基幹データベースの情報を丸ごとダウンロードしたり、直接データを書き換えたりすることが可能になります。ネットワーク経由の通信を監視・制御する仕組み（出口プログラムなど）を導入していない環境では、この抜け道が大きな脅威となります。

リスク4　セキュリティ・レベルやパスワード関連のシステム値の設定

セキュリティ・レベルやパスワード関連のシステム値の設定が古いまま放置されていることも、不正アクセスを許す要因となります。IBM iには、OS全体のセキュリティ基準や動作を定義する「システム値（System Value）」と呼ばれるパラメータ群が存在します。

代表的なものが、システム全体の保護基準を決める「QSECURITY（セキュリティ・レベル）」です。現在、IBM社はレベル40以上での運用を標準としていますが、過去に開発した古いプログラムが動かなくなることを懸念し、アクセス制御や整合性保護が不十分な「レベル20」や「レベル30」のまま稼働しているシステムがいまだに見受けられます。

さらに、パスワードの最小桁数（QPWDMINLEN）や有効期限（QPWDEXPITV）、大文字・小文字の区別、連続してサインオンに失敗した際の行動（QMAXSGNACN）などのシステム値が適切に設定されていないケースも少なくありません。「パスワードは英数字6文字以上、有効期限なし、何回間違えてもIDがロックされない」といった緩い設定のままでは、総当たり攻撃（ブルートフォース攻撃）によって容易に突破されてしまいます。

リスク5　修正プログラム（PTF）の未適用

修正プログラム（PTF）の未適用は、OSや関連ソフトウェアに存在する既知の脆弱性を放置することにつながります。IBM iのOS自体が堅牢であっても、その上で稼働するHTTPサーバーやJava、オープンソース・ソフトウェア、通信プログラムなどには、他の一般的なシステムと同様に保安上の弱点（脆弱性）が発見されることがあります。

独立行政法人情報処理推進機構（IPA）などが運営する脆弱性対策情報データベース「JVN iPedia」でも、IBM iに関連する脆弱性情報は定期的に公開されており、これらを修正するために提供されるのがPTF（Program Temporary Fix）です。

IBM iは24時間365日無停止で基幹業務を支えているケースが多く、「システムを再起動（IPL）する時間が取れない」「PTFを適用して既存プログラムに不具合が出るのを避けたい」という理由から、導入以来一度もPTFを適用していない現場も存在します。しかし、セキュリティ関連のPTFを適用しないままネットワークに接続し続けることは、攻撃者に対して侵入の足がかりを常に提供している状態にほかなりません。

なぜ今、IBM iの脆弱性診断が必要なのか？

なぜ今、IBM iの脆弱性診断が必要なのかという背景には、IBM iを取り巻くシステム環境と運用体制の大きな変化があります。かつてのIBM iは社内ネットワークの閉じた環境で稼働し、専用端末から操作する形態が主流でした。しかし現在は、オープン系システムとの連携やリモートアクセスの普及により、外部から到達可能な経路が大幅に増加しているのが実情です。

当時の運用ルールや初期設定のまま現在のネットワーク環境に接続し続けることは、意図しない情報漏えいやデータ改ざんを招く要因となります。従来の環境と現在の環境における違いは、次のとおりです。

外部連携・API・クラウド接続でアクセス経路が増えている

外部連携やAPI、クラウド接続でアクセス経路が増えていることは、IBM iのセキュリティリスクを高める直接的な要因です。近年のDX（デジタルトランスフォーメーション）推進やモダナイゼーションに伴い、IBM iが保持する基幹データをWebシステムやクラウドサービスからリアルタイムに参照・更新する構成が増えています。

具体的には、REST APIを用いたアプリケーション連携や、ODBC/JDBCなどを利用したデータベースへの直接接続が挙げられます。また、テレワークの普及によってVPN経由で社内ネットワークへ接続する端末も増加しました。このような環境では、5250画面のメニュー制御だけでは通信を制限できず、ネットワーク経由で直接データベースへアクセスされる危険性が生じます。通信経路が多様化した現在、外部からどのポートやインターフェースが利用可能な状態になっているかを診断によって正確に把握する必要があります。

システムを構成する主要なソフトウェアがあらかじめ統合されているため、個別の導入や設定にかかる工数を大幅に削減できます。また、OSのバージョンアップを行うだけでデータベースやミドルウェアも同時に更新されるため、ソフトウェア間のバージョン不整合によるトラブルを防ぎ、運用管理の負担を軽減できます。

担当者の異動や人材不足で、設定が長年見直されていない

担当者の異動や人材不足で、設定が長年見直されていないことも、早急な脆弱性診断が求められる理由です。IBM iは高い安定性を誇るため、数十年前に構築されたシステムが現在も稼働し続けているケースが少なくありません。その一方で、当時の構築担当者やベテラン技術者の定年退職・異動が進み、システムの仕様や権限設計の意図を把握できる人材が不足しています。

運用が長期化する過程では、退職者アカウントの放置や、トラブル対応時に一時的に付与した強い権限の戻し忘れが蓄積しやすくなります。さらに、現行の担当者が「業務システムが停止するかもしれない」と懸念し、過去のシステム値やオブジェクト権限の設定を変更できずに放置してしまうことも珍しくありません。属人化した環境を客観的に可視化し、不要なアカウントや過剰な権限を整理するためにも、第三者視点や専用ツールを用いた診断が不可欠です。

IFSや共有フォルダを経由したランサムウェア被害のリスク

IFS（統合ファイル・システム）や共有フォルダを経由したランサムウェア被害のリスクも、現在強く警戒すべき問題です。IBM iの独自アーキテクチャはWindows向けのウイルスがそのままでは動作しない構造を持っていますが、データを保管する領域まで無条件に保護されるわけではありません。

IBM iには、WindowsやUNIXと同じ階層型ディレクトリ構造でファイルを管理できるIFSが搭載されており、ファイルサーバーとしてPCとフォルダを共有できます。もし業務用のWindows端末がランサムウェアに感染した場合、ネットワークドライブとしてマウントされているIFS上の共有フォルダにまで暗号化被害が及ぶ仕組みです。独立行政法人情報処理推進機構（IPA）が公開している情報セキュリティ10大脅威でも、ランサムウェアによる被害は組織向けの深刻な脅威として毎年継続して挙げられています。IFSの共有設定やアクセス権限が適切に制限されているかを確認することは、事業継続の観点からも極めて重要です。

IBM iの脆弱性診断では何を調べる？主な5つの診断観点

IBM iの脆弱性診断では、OS内部の設定値や権限の割り当て状態を網羅的に調査します。一般的なネットワーク診断のように外部から擬似的な攻撃を行うのではなく、システム内部の設定情報を抽出してセキュリティ上の不備を特定するアプローチをとるのが特徴です。

具体的に何を調べるのかについて、主な5つの診断観点を一覧表に整理しました。

観点1　システム値（SYSVAL）の設定状況

システム値（SYSVAL）の設定状況に関する診断では、IBM i全体のセキュリティレベルやパスワードポリシーが安全に定義されているかを調べます。システム値はOSの動作環境を制御する基本パラメータであり、ここでの設定不備はシステム全体に直接影響を及ぼすためです。

具体的には、以下のようなパラメータの現在値を抽出し、推奨値との乖離を判定できます。

• QSECURITY（セキュリティレベルが40以上に設定されているか）
• QPWDEXPITV（パスワードの有効期限が適切に設定されているか）
• QMAXSIGN（サインオン試行の許容回数が制限されているか）
• QAUTOVRT（仮想装置の自動作成が無制限に許可されていないか）

あわせて、パスワードの最小文字数（QPWDMINLEN）や文字種の組み合わせルールなども確認します。これにより、ブルートフォース攻撃（総当たり攻撃）や不正ログインに対するOSの基礎的な防御力を評価できます。

観点2　ユーザープロファイルと特殊権限の棚卸し

ユーザープロファイルと特殊権限の棚卸しでは、登録されている全アカウントの稼働実態と、付与されている権限の妥当性を調査します。長年の運用によって放置されたアカウントや、業務範囲を超えた過剰な権限は、内部不正やアカウント乗っ取り時の被害を拡大させる要因となるからです。

この観点では、主に次の3つの項目を重点的に確認できます。

• 8つの特殊権限（*ALLOBJ、*SECADM、*JOBCTLなど）を持つユーザーの特定
• ユーザーIDと同一のパスワード（デフォルトパスワード）のまま放置されているアカウントの有無
• 長期間サインオン履歴がない休眠アカウントや退職者アカウントの残存状況

また、QSECOFRなどの初期導入時から存在するシステム標準プロファイルについて、パスワードが初期値から変更されているかも診断対象です。業務上不要な特権を持つユーザーを洗い出し、最小権限の原則に基づいた運用へ見直すための基礎データを取得できます。

観点3　オブジェクト権限とIFS（統合ファイル・システム）の保護状態

オブジェクト権限とIFS（統合ファイル・システム）の保護状態に関する診断では、重要なデータベースやプログラム、共有フォルダに対して適切なアクセス制限がかかっているかを調べます。5250画面のメニュー制御だけでは、別経路から直接データへアクセスされた際に防御できないためです。

診断では、ライブラリやファイルに設定された「*PUBLIC（共通権限）」の値を抽出します。個別の権限設定がないすべてのユーザーに適用される*PUBLICが「*ALL」や「*CHANGE」になっている場合、誰でもデータの書き換えや削除ができる危険な状態と判定できます。

さらに、Windows等のPCとファイル共有を行うIFS領域のディレクトリ権限も重要な調査対象です。PCがマルウェアに感染した際、IFS上の共有フォルダが書き込み可能になっていると、IBM i内のファイルまで暗号化される恐れがあるため、参照・更新権限の範囲を厳密に検査します。

観点4　ネットワークアクセスと出口プログラム（Exit Program）の制御

ネットワークアクセスと出口プログラム（Exit Program）の制御に関する診断では、外部ネットワークからIBM iへ接続する際の通信経路と、その監視・制限の仕組みを調査します。現代のIBM iはオープン系システムやPCと連携することが一般的であり、5250エミュレータ以外の多様なプロトコルが利用されているのが理由です。

具体的には、FTP、ODBC、JDBC、リモートコマンド、NetServerなどの各サーバー機能が起動しているかを確認します。その上で、IBM i標準の監視機構である「出口点（Exit Point）」に対して、アクセスを制御する「出口プログラム（Exit Program）」が組み込まれているかを調べます。

出口プログラムが未設定の場合、オブジェクト権限さえあれば、業務アプリケーションのチェックを迂回してExcel等から直接データを抜き取ることが可能です。どの通信ポートが開放され、どの経路のアクセス制御が手薄になっているかを可視化できます。

観点5　監査ジャーナル（QAUDJRN）の取得設定とPTFの適用状況

監査ジャーナル（QAUDJRN）の取得設定とPTFの適用状況に関する診断では、万が一インシデントが発生した際に追跡調査が可能か、また既知の脆弱性が放置されていないかを調べます。予防策だけでなく、事後対応やシステム自体の脆弱性解消もセキュリティ維持には不可欠だからです。

監査ログの観点では、システム値「QAUDCTL（監査制御）」や「QAUDLVL（監査レベル）」の設定値を調査します。これにより、不正なサインオン試行（*AUTFAIL）や権限変更（*SECURITY）、重要オブジェクトの削除（*DELETE）といった操作証跡が確実に記録される状態にあるかを確認できます。

あわせて、OSの修正プログラムであるPTF（Program Temporary Fix）、特にセキュリティ関連のPTFが最新の状態まで適用されているかを診断します。OSや内蔵Webサーバー等の既知の脆弱性を突かれるリスクを洗い出し、システムを安全な状態に保つための課題を特定できます。

IBM iの脆弱性診断の進め方｜4ステップ

IBM iの脆弱性診断の進め方は、事前準備から診断後の見直しまでを含めた4ステップに分かれます。情報システム部門の担当者が場当たり的に設定を変更すると、稼働中の業務プログラムが停止する恐れがあるため、現状把握から再診断までの手順を段階的に進めることが重要です。

STEP1　現状把握（ユーザー・資産の棚卸し）

現状把握（ユーザー・資産の棚卸し）では、情報システム部門の担当者がIBM i内部に登録されているユーザー・プロフィールや、保護すべき重要データ（資産）の一覧を作成します。診断を実施する前に「本来あるべき姿」を整理しておかなければ、抽出された設定が業務上必要なものか、あるいは放置されたリスクなのかを判断できないのが理由です。

具体的には、以下の3つの項目を中心に台帳やシステム上のリストから情報を収集します。

• 稼働中のユーザー・プロフィールと、退職者・異動者・外部委託先が利用していた不要なアカウントの有無
• 顧客情報や財務データ、基幹業務プログラムが格納されている重要なライブラリーおよびIFS（統合ファイル・システム）内のディレクトリ
• 基幹システムと連携している外部サーバーや、バッチ処理・FTP通信などで使用している通信経路と専用アカウント

これらの情報を事前に整理しておくことで、後のステップで検出された設定不備が「現在の業務仕様として必要な設定」なのか、「管理漏れによる脆弱性」なのかを正確に判別できます。

STEP2　診断の実施（ツールによる診断と専門家による診断）

診断の実施（ツールによる診断と専門家による診断）では、IBM iのOS設定や権限情報を抽出し、セキュリティ上の問題点を洗い出します。主な実施方法には、標準コマンドを用いた自社確認、専用ツールによる自動診断、外部の専門家による診断サービスの3種類があります。

IBM iの標準コマンドでも設定値の出力自体は可能ですが、数百から数千におよぶオブジェクト権限やシステム値の相関関係を人手で分析するには限界があります。そのため、専用ツールによる自動抽出と、IBM iの仕様を熟知した専門家による分析を組み合わせる方法が、見落としを防ぎつつ効率的に診断を進めるうえで有効です。

STEP3　リスク評価と対策の優先順位付け

リスク評価と対策の優先順位付けでは、診断によって判明した脆弱性に対し、「悪用された場合の被害の大きさ」と「設定変更による既存業務への影響度」の2軸から対策の順序を決定します。IBM iは長年稼働しているプログラムが多く、検出されたすべての問題点を一度に変更しようとすると、夜間バッチや外部連携処理がエラーで停止する危険があるためです。

独立行政法人情報処理推進機構（IPA）が公開しているセキュリティ対策の指針でも、保有する資産の重要度と脅威の深刻度に応じたリスク対応が推奨されています。IBM iの環境においては、次の基準で優先度を分類します。

• 優先度「高」（即時対応）　初期パスワードのまま放置されているアカウントの変更、退職者アカウントの無効化、業務で使用していない特殊権限（*ALLOBJなど）の剥奪など、業務影響がなく直ちにリスクを減らせる項目
• 優先度「中」（計画的対応）　パスワード関連のシステム値変更や、本番ライブラリーのPUBLIC権限（共通権限）の制限など、利用者への事前周知やテスト環境での動作検証を要する項目
• 優先度「低」（中長期的対応）　セキュリティ・レベル（QSECURITY）の引き上げや、アプリケーションの設計変更を伴う権限の再構築など、システム全体の改修計画に組み込むべき項目

このように影響範囲を切り分けることで、稼働中の基幹業務を止めずに、実現可能な箇所から着実にセキュリティ水準を引き上げることができます。

STEP4　是正と定期的な再診断

是正と定期的な再診断では、決定した優先順位に従って設定変更（是正措置）を実施し、その後も定期的に診断を繰り返して安全な状態を維持します。設定を変更した直後は安全であっても、法改正に伴うプログラム改修や組織変更による人事異動、新たな外部システムとの連携などが発生するたびに、権限設定や通信環境が変化するのが理由です。

是正作業を行う際は、万が一の業務停止に備えて変更前の設定値を記録し、問題発生時に即時切り戻しができる手順を整えたうえで実行します。また、一時的な調査やトラブル対応のために付与した強い権限がそのまま放置されるケースを防ぐため、年に1回から半年に1回程度の頻度で定期的に再診断を実施する体制を構築することが求められます。定期的な点検を運用サイクルに組み込むことで、設定の形骸化を防ぎ、長期にわたってIBM iの安全性を保つことができます。

診断結果をどう対策につなげる？代表的な対策

診断結果を対策につなげるためには、判明したセキュリティ上の弱点に対して、実業務への影響を抑えつつ代表的な対策を講じる必要があります。OS標準の権限設定やシステム値を急激に変更すると、稼働中の基幹システムが停止する恐れがあるためです。既存のアプリケーションを改修せずにセキュリティを強化できる手法を選ぶことで、安全にシステムを保護できます。

不正ログイン・なりすまし対策（多要素認証）

不正ログイン・なりすまし対策として多要素認証を導入すると、パスワードの使い回しや推測による不正侵入を防止できます。診断によって、初期パスワードの放置や複数人での特権ID（*ALLOBJなどを持つユーザー・プロファイル）の共有が見つかるケースは少なくありません。しかし、業務手順や連携システムの都合から、パスワードの複雑化やIDの統合をすぐには実施できない環境も存在します。

多要素認証ツールを導入すれば、5250エミュレータからのサインオン時やリモートアクセス時に、ワンタイムパスワードなどの追加認証を要求できます。万が一IDとパスワードが外部に漏洩しても、本人以外のサインオンを確実に遮断できるのが強みです。独立行政法人情報処理推進機構（IPA）が公開しているセキュリティガイドラインでも、不正アクセス対策として多要素認証の導入が推奨されています。全ユーザーへの一括適用が難しい場合は、システム管理者や開発者などの強い権限を持つユーザーから段階的に適用できます。

ネットワーク経由のアクセス制御（出口プログラム・ファイアウォール）

ネットワーク経由のアクセス制御には、OS標準の出口点（イグジット・ポイント）を利用した出口プログラムや、専用ファイアウォールの導入が有効です。診断でオブジェクト権限やPUBLIC権限の過剰付与が判明しても、既存のプログラムが動作しなくなるリスクから、権限の絞り込みが困難な場合があります。IBM iでは、5250画面のメニューで操作を制限していても、初期設定のままではFTPやODBC、JDBCなどを利用したネットワーク経由の要求が、オブジェクト権限の範囲内でそのまま実行されてしまいます。

この抜け道を塞ぐため、通信の入り口である出口点に制御用のプログラムや専用ツールを配置します。これにより、オブジェクト自体の権限設定を変更することなく、外部からの不正なデータ抽出や書き換えをブロックできます。具体的には、「特定のIPアドレスからのアクセスのみ許可する」「経理部門のユーザーにはODBC経由でのデータ読み取りのみを許可し、更新や削除は拒否する」といった細かなルールを設定できます。あわせて通信ログを記録できるため、不審なアクセスの早期発見や監査証跡の確保にも活用できます。

ウイルス・ランサムウェア対策（IFSの保護）

ウイルス・ランサムウェア対策では、Windowsサーバーなどと同様に、ストリーム・ファイルを格納できるIFS（統合ファイル・システム）の保護が求められます。IBM iの独自領域（QSYS.LIB）にあるプログラムやデータベースは、構造が異なるためWindows向けのマルウェアが直接実行されることはありません。一方で、パソコンとファイルを共有するために利用されるIFS領域は、ネットワークドライブとして接続している端末がランサムウェアに感染すると、その端末を経由してファイルが暗号化される危険性があります。

このリスクを防ぐには、まず診断結果に基づき、IFS内のディレクトリに対する過剰な共有権限を制限します。さらに、IFS領域に対応したアンチウイルスソフトやランサムウェア対策ツールを導入することで、不審なファイルの書き込み検知や、万が一の感染時における通信の自動遮断を実施できます。取引先や他システムへマルウェアを拡散させる踏み台にならないためにも、IFSの監視と保護は重要な対策です。

三和コムテックのIBM iセキュリティ支援｜評価から対策まで

三和コムテック株式会社のIBM iセキュリティ支援は、現状の脆弱性評価から具体的な対策製品の導入までを一貫してサポートする体制を整えています。IBM i特有のアーキテクチャや権限構造を熟知した専門技術者が関わるため、自社だけでは判断が難しい設定の見直しや優先順位の決定をスムーズに進められます。

まずは現状を知る「IBM iセキュリティ評価サービス」

「IBM iセキュリティ評価サービス」は、現在稼働しているIBM iの内部設定や権限状態を調査し、潜在的なセキュリティリスクを可視化するサービスです。何から対策を始めるべきか迷っている場合、まずはこのサービスから利用することで、自社の現在地を正確に把握できます。

診断にあたっては、本番稼働中のIBM iに特別なソフトウェアをインストールすることなく、システム値やユーザープロファイルなどの設定情報を取得して分析できるのが特徴です。そのため、既存の業務システムやパフォーマンスへ影響を与えずに現状を調査できます。

収集した設定情報は専門のエンジニアが精査し、セキュリティ・レベルや特殊権限の付与状況、ネットワークアクセスの制御状態などを多角的に評価します。診断結果は詳細なレポートとしてまとめられ、単なる設定値の羅列ではなく、どこにどのようなリスクが存在するのかがわかりやすく解説される仕組みです。さらに、報告会を通じて自社の運用環境に合わせた改善策の提案を受けられるため、システム部門だけでなく経営層や監査部門への説明資料としても活用できます。

見つかった課題に必要な機能だけを導入できる「iSecurity」

評価サービスによって明確になったセキュリティ課題を解決するための統合セキュリティ製品が「iSecurity」です。iSecurityは複数の独立したモジュールで構成されており、診断で見つかった弱点や予算に合わせて必要な機能だけを選択して導入できるため、無駄のないセキュリティ投資が可能です。

また、OS標準の機能を個別に設定・プログラミングする場合は多大な開発工数と専門知識が求められますが、iSecurityを活用すればメニューや専用コマンドから直感的にポリシーを設定できます。主要なモジュールと解決できる課題の対応関係は以下のとおりです。

まずは「IBM iセキュリティ評価サービス」で緊急性の高いリスクを特定し、該当する領域のモジュールから段階的に「iSecurity」を導入していくアプローチが、運用負荷とコストを抑えながら安全性を高めるための現実的な選択肢となっているのが理由です。

よくある質問（FAQ）

IBM iはウイルスやランサムウェアに感染しないのですか？

IBM iはウイルスやランサムウェアに感染しないという認識は、現在では正確ではありません。OSの基幹部分であるネイティブ環境（QSYS.LIB）は独自のオブジェクト構造を持つため、WindowsやLinux向けに作られたマルウェアが直接実行されて動作する可能性は低いといえます。

しかし、IBM iにはWindowsなどと同じ階層型のファイル構造を扱えるIFS（統合ファイル・システム）が備わっています。パソコンからネットワークドライブとしてIFSの共有フォルダをマウントしている場合、パソコン側で感染したランサムウェアがネットワーク経由でIFS内のファイルを暗号化する被害が発生します。また、IFSがマルウェアの保管場所となり、社内の他端末へ感染を広げる踏み台にされるリスクも存在するため、適切なアクセス制限が必要です。

一般的な脆弱性診断ツールでIBM iも診断できますか？

一般的な脆弱性診断ツールでIBM iも診断できる範囲は、ネットワークの通信ポートやWebサーバーの表面的な項目に限られます。これは、一般的な診断ツールがWindowsやLinuxなどのオープン系OS、あるいはWebアプリケーションの脆弱性を検出する目的で設計されているためです。

一般的な脆弱性診断ツールとIBM i専用の診断ツールでは、検査できる対象に以下のような違いがあります。

このように、IBM iのセキュリティにおいて重要となるOS内部の権限設定やシステム値の不備は、一般的なツールから把握できません。実効性のある診断を行うには、IBM iのアーキテクチャに対応した専用ツールや専門家の知見を活用する必要があります。

IBM iの脆弱性診断はどのくらいの頻度で行うべきですか？

IBM iの脆弱性診断を行う頻度は、最低でも年に1回、可能であれば半年に1回の定期的な実施が推奨されます。一度設定を見直して安全性を確保したとしても、日々の運用の中でシステム環境やユーザー情報が変化するためです。

また、定期的な診断に加えて、以下のようなシステム環境の変化があったタイミングでも診断を実施すると効果的です。

• OSのバージョンアップやハードウェアのリプレースを行ったとき
• 外部システムとのAPI連携やクラウド接続など、新しい通信経路を追加したとき
• 組織改編や人事異動に伴い、多数のユーザープロファイルや権限を変更したとき

独立行政法人情報処理推進機構（IPA）が公開している情報セキュリティ10大脅威でも、システムの脆弱性や設定不備を突いた攻撃は毎年上位に挙げられています。定期的な診断を運用ルールに組み込むことで、設定の形骸化や権限の放置を防げます。

IBM iにソフトをインストールしなくても、セキュリティ設定を確認できますか？

IBM iにソフトをインストールしなくても、OSの標準コマンドやシステム管理機能を用いてセキュリティ設定を確認できます。たとえば、システム値表示コマンド（DSPSYSVAL）や権限表示コマンド（DSPOBJAUT）を実行したり、設定情報をファイルに出力（OUTFILE）してパソコン側で集計したりする方法があります。

また、外部の専門家に依頼する場合でも、本番環境に専用ソフトウェアを導入せず、コマンドで抽出した設定情報データを提出して分析してもらう形式の診断サービスを利用できます。ただし、手動でのコマンド実行や目視による確認は、対象となるオブジェクトやユーザーの数が膨大になるほど見落としが発生しやすいのが課題です。網羅的かつ短時間で正確に現状を把握したい場合は、診断ツールの活用が適しています。

診断で問題が見つかったら、どこから手を付ければよいですか？

診断で問題が見つかった場合は、「対策による業務システムへの影響が小さく、かつセキュリティリスク低減の効果が高い項目」から優先して着手するのが基本です。すべての設定不備を一度に変更しようとすると、稼働中の基幹業務プログラムがエラーで停止する恐れがあるためです。

具体的には、以下の順序で段階的に対策を進めることで、業務への影響を抑えながら安全性を高められます。

1. 長期間使用されていない休眠ユーザーIDの無効化や削除
2. 初期パスワードのまま放置されているアカウントのパスワード変更
3. 業務上不要であることが明確な特殊権限（*ALLOBJや*SECADMなど）の回収
4. ネットワークアクセスを制御する出口プログラムの導入（最初は通信を遮断せずログ記録のみを行う監視モードで稼働させ、正規の業務通信を把握してから遮断ルールを適用）
5. 共通権限（*PUBLIC）やアプリケーションに関わるオブジェクト権限の引き締め（テスト環境での十分な動作検証を経たうえで本番環境へ適用）

このように、まずはプログラムの動作に直接影響しないアカウント整理から始め、システム内部の権限変更や通信制御については、ログの監視とテスト検証を行いながら慎重に進めることが重要です。

まとめ

IBM i（AS400）は堅牢なOSですが、外部連携の増加や設定の形骸化により、権限の過剰付与やアクセス制御の不備といったリスクが潜んでいます。一般的な診断ツールではOS内部の設定まで把握できないため、IBM i固有の仕様に対応した脆弱性診断が必要です。

システム管理者は、ユーザー権限やシステム値などの現状を診断によって可視化し、優先順位をつけて多要素認証の導入やアクセス制限などの対策を講じることで、不正アクセスやランサムウェアの被害を防ぎ、安全な運用環境を維持できます。