「Guru: The Finer Points of Exit Points」（出口点の細かな点）記事に関して
Alexさん、こんにちは。
ご健勝のことと存じます。 出口点に関するこちらの記事 を読んでいて、技術的に不正確な点があるように思われました。
ソケット関連ユーザー出口点（出口プログラム）は、次のような処理を行うのに使用することができます。すなわち、出口点を使用して、ブロックするべきすべての不必要なポートをブロックすることができます。この記事の著者が列記した、以下の点についてお話しすることができればと思います。
・すべてのサービスに、利用可能な出口点があるわけではない。
・ユーザー定義のポートには、出口点が関連付けられていない。
よろしくお願いします。
-- Tony Pereraより。（Fresche Solutions社Trinity Guard事業部門プレジデント）
皆さん、こんにちは。
当該記事で述べているように、出口点は、IBM i のサイバーセキュリティの強化に役立つものであり、常にゼロ トラストおよび全体的戦略の不可欠な部分であるべきです。この記事は、出口プログラムまたはソケット関連出口点を 実装しない ことを推奨しているわけでは 決してありません 。
できる限り、私見を述べることは避け、業界の代表的なベンダーによる、裏付けとなりそうな記事からの引用を示しながら、記事の記述を検証してみたいと思います。
「ワークステーションの保護」 - IBM Documentation （出口プログラムは、オブジェクト権限に置き換わるものではありません。オブジェクト権限は、あらゆるソースからの無許可アクセスからオブジェクトを保護するように意図されています。）
「ソケット関連ユーザー出口点」 - IBM Documentation （次のいずれかの理由により、IBM® が開発したすべてのアプリケーションが構成済みのユーザー出口プログラムを呼び出すわけではありません。
・アプリケーションがネットワーク通信にソケット API を使用しない。
・ソケット API が、ユーザー出口プログラムを呼び出せないシステム・タスクから呼び出された。）
上述の太字斜体フォント部分は、それぞれのトピックに関するIBM i ナレッジ ベースのリンク先ページからそのままコピーしたものであり、修正や書き換えは一切行っていません。
IBM i でのセキュリティの実装の際には、出口点およびソケット セキュリティを常に推奨していますが、BFB Security社では包括的な出口点 ソリューションを提供していないため、そうしたソリューションを提供しているベンダーをご紹介することもあります。
しかし、単純に考えて、*IOSYSCFG、*ALLOBJ、および*SECADM特殊権限を持つユーザーが非常に多い場合、多くのユーザーが、出口およびソケットを登録することができるだけでなく、それらを削除することもできることになります。したがって、これらの権限を制限および監査するために、特権アカウント管理（PAM）が極めて重要になります。パスワードを要求しないプロトコルがあり、リモートの開発者およびユーザーがこれらの非認証のルート アカウントを使用することがある場合は、システムを侵害から保護することはできません。開発者が パスワードなし で非認証アクセスを提供する（例: DDMDRDAパスワード要求（*NOまたは*USERID））ことを選ぶのは、出口点またはソケットのせいではありませんし、それは、新品のIBM i の出荷時のデフォルトの 初期設定 でもありません。また、それは、 DevSecOpsのトレーニングを受けたことのない開発者のせいでもありません。
さらに、2021年だけで275件のインサイダー インシデントを確認した「Verizon DBIR」調査などの企業調査を見て見ぬふりをして、特権管理を推奨することはできません。BFB Security社は、Center for Internet Security（CIS）、およびパートナー企業であるIBM、そして特にロチェスターのLab Services（私たちの以前の雇用主）の何千人もの間で合意が得られた推奨事項に準拠しています。
NFSまたはDDM/DRDAなどのソケットおよびサービスのセキュリティ対策を施して、非認証アクセスを防止し、認証情報を用いた認証を要求できるようになったら、出口プログラムは、ネットワークにおけるファイアウォールやアンチウイルスと同じように、セキュリティを強化するための強力なツールになりますが、組織が内部脆弱性に対して注意を払っていなければ、やはりハッカーはこれらを迂回します。
注目すべきことに、ロチェスターのセキュリティ部門（私は2017年に退職）も同じことを述べています。すなわち、街中の誰にでも鍵や暗証番号を渡すというのでないのであれば、ドアや窓には鍵を掛けておくのが安全です。
記事の2ページ目の最初の2つの段落は、これを具体化して示している例です。その例では、出口プログラムは、 確かに セキュリティを強化しています。
誤解しないでください。出口プログラムはシステムの全体的なセキュリティの一部ですが、もう一度、IBMが述べていることをじっくり読み返してみてください。すなわち、「出口プログラムは、オブジェクト権限に置き換わるものではありません。」 しかし、出口プログラムは、次の例のように、既存のネットワーク制御を強化することができます。
SECURELIB/OBJAは、*PUBLIC権限を*EXCLUDEに設定しています。OBJAに対する*CHANGE権限を持つアカウントは、USERAおよびUSERBのみです。これは、有効な強制アクセス制御です。しかし、システムの管理者は、USERAおよびUSERBに、OBJAへODBCアクセスさせたくないため、USERAおよびUSERBに対してODBCアクセスを不許可にすることによってネットワーク制御を強化する出口プログラムを実装します。
これに対して、BFB Security社の診断ツールは、すべての登録済み出口点を収集して、顧客が出口点およびソケットを 実際に 実装する ように推奨事項の提案を行います。また、BFB Security社は、もちろん、ゼロ トラスト モデルに準拠し、PAMおよびリソース セキュリティを実装し、「IBM i機密保護解説書」および「CIS Benchmarks」に記されているすべての推奨事項に準拠しています（それらの推奨事項は、私の元雇用主であるIBMロチェスターによる、レビュー、コメントを経た上で承認されたものです）。
「Controlling Access to SSH on IBM i（IBM iにおけるSSHへのアクセスの制御）」 | IBM i (OS/400, i5/OS) | Security (mcpressonline.com) （注: IBMは、SSHデーモン用の出口点を提供していないため、ソケット関連出口点を介してアクセスを制御しようとしても、あまり実効性があるとは言えません。）
以前の記事をお読みになったことのある方なら、私が最も重要と考えているのが、多層防御の実装であることはご存じかと思います。すなわち、データのセキュリティを確保するために複数のテクノロジーを使用するということです。そうすることにより、1つのテクノロジーが誤って構成されていたり、悪用されたりした場合でも、データを保護するためのテクノロジーが、少なくとも1つは残されていることになります。以前、Steve Pitcher氏が、 SSHに関するいくつかの問題点について記しています。それらの注意事項は、ぜひとも読んでおくことをお勧めします。
ここでも、上述の部分はリンク先の記事からそのまま引用したものであり、修正や書き換えは一切行っていません。
BFB Security社の診断プロセスでも、sshd_configを取り上げて、Carol Woodbury氏が記事の中で示しているのと同じような推奨事項の提案を行っています。このように、BFB Security社では、出口点およびソケット セキュリティの実装を推奨しておりますが、最後に一言、多層防御の実装が必要であることについても付言させていただきたいと思います。
皆様のご無事をお祈りしております。
-- Bruceより。
