IBM i のウンチクを語ろう
～ その85：IBM i ユーザーの疑問に答えてみる
皆さん、こんにちは。イベントやセミナーなどの場で、「何でもQ&Aコーナー」といった類のセッションが設けられると様々な質問が寄せられます。製品戦略に関わるものから目先の技術的なことに至るまで、中には考えたこともないような盲点を突いてくるものまであります。間違った発言はできない中、意図がよくわからなかったり、自身の知識不足に直面したりするケースもあるので、回答者の役割を担うのはかなり緊張します。一方で、新たな視点に感心し、知識を増やすきっかけにもなるので、私自身は冷や汗をかきながらもそれなりに楽しんでおります。
今回は最近参加したイベントにおいて寄せられた質問の中から、「なるほど、そう来たか・・・」と感心したものや、多くの方に当てはまりそうなものをいくつか取り上げて、回答をまとめてみようと思います。
まずは最近の発表の中で、比較的反響が大きかったものについてです。
IBM i 7.5においてQSECURITY=20が設定できなくなったがその理由は何か？
製品機能の強化・更新などの発表には、必ずしも理由や背景などの詳しい補足説明が付いてくるとは限りません。今回のQSECURITY設定値の新たな制約は、バージョン・アップグレードにおける考慮点、場合によっては追加の作業を意味しますので、理由を問われるのは至極当然だとも言えます。漠然とセキュリティ強化と言うだけでは、今一つ説明不足というわけなのでしょう。
念のためにIBM i 7.5における発表内容を簡単に復習しておきましょう。QSECURITYというシステム値、Windowsで言うところのレジストリ変数に相当するものに値を設定することで、システム全体のセキュリティ管理の厳しさ度合いが決まります。これが20であるということは、ユーザーＩＤとパスワードを保持している人は、システム内のあらゆる情報（オブジェクト）に参照・更新・削除などのアクセスができる、というのが基本的な考え方です。言わば全員がアドミニストレータ権限を持つようなものです。危うさを感じますね。
フィッシング詐欺やランサムウェアなど、セキュリティ犯罪の件数や被害金額が増加の一途を辿っている環境下で、オープン化が進み、社外の、もしかしたら正体不明の人がアクセスするかもしれないのが今のシステムです。だからと言って、オープン性を排して社内に閉じ込めてしまうのは非現実的です。アプリケーション開発時に都度対処するから大丈夫、という考え方もあるのかも知れませんが、今後のためにも基本的なセキュリティ設定を低いままにしておくのは避けた方が賢明です。ユーザー毎・オブジェクト毎にアクセス権を管理するために、IBMはQSECURITYに40以上を設定することを推奨しています。なおQSECURITY各レベルの詳細については、IBMのドキュメントを参照いただけると良いと思います。
参考までに、米Fortra社によるIBM i ユーザーのセキュリティ現状調査（State of IBM i Security Study）によると、QSECURITYとして20が設定されているシステムは、昨年は4.3%、今年は3.5%とごく僅かだとされています。これは40をIBM i の出荷時ディフォルト値としてきたことが奏功したからだと言えるでしょう。ここで制約を厳しいものにしても市場はパニックには陥らない、という判断も働いたものと想像しています。
セキュリティ関連が続きますが、次は私にとっては完全に盲点だった質問です。IBMの発表情報を見た時に、前項のような「副作用」もありませんので、機能強化は着々と進んでいるな、といった感想を抱いた程度に留まっており、これを見るまで理由を思い巡らすことはありませんでした。
Power10でメモリ暗号化機能が追加されましたが、その背景は？
この機能強化を理解する上でのキーワードはゼロ・トラストではないでしょうか。例えばインターネットのセキュリティ対策においては、危険地帯と安全地帯を識別し、その中間にDMZ（DeMilitalized Zone: 非武装地帯）を設定する、というのが一般的です。そしてこれらの境界線にファイアウォールを設けるわけです。
これだと内部犯行に対処できないばかりでなく、最近は犯罪者の手練手管も進化しているために、ファイアウォールが突破されるケースも珍しいことではなくなってきました。「防衛ライン」を下げれば良いのかもしれませんが、どこまで下げれば安全だと見極めるのも困難です。いっそのこと安全地帯ではあっても、安全は必ずしも保障されないと想定しておいた方が賢明だ、というのがゼロ・トラストの考え方です。ITは現実世界よりも物騒なのかもしれません。
一方でデータを守るにはいくつかの方策が考えられます。犯罪者がデータに接近したいとは思わないように仕向けるのが最善でしょう。データに触れようと実際に犯行を試みたとしても失敗させるのが次善の策、そして触れたとしても役立たないようにしておくのが最後の手段、というわけです。暗号化はデータを守る最後の手段なのですね。
データ暗号化にゼロ・トラストの考え方を適用したらどうなるでしょうか。究極の姿を追求するとしたら、非暗号データはストレージやメモリなどを含めてどこにも存在しないようにするべき、ということになるでしょう。ただ、データを処理できなくなってしまっては元も子もありませんので、最低限、すなわちプロセッサの内部にのみ非暗号データが存在するようにします。データがプロセッサ内外を行き来する際には、常に暗号化・複合化処理を行うことが前提になります。ご存知のとおり、Power10プロセッサは内部にそのための専用回路を備えているので、パフォーマンスに影響せずにこれを実行することができます。
なかなか徹底した考え方ですが、そこまでやる必要があるのかという疑問が湧くかもしれません。防御する側が留意しておかなくてはならないのは、常に攻撃者の先回りをしておく必要がある、という点ではないでしょうか。攻撃側は任意のタイミングで任意の箇所を攻撃できますが、防御側はそれを事前に察知できないので、あらゆる可能性を排除するべく手を打たなければなりません。例えばストレージへの侵入が技術的に可能ならば、そのような事件の有無とは関わりなくストレージを暗号化しておく、同様にメモリへの侵入の可能性があるならばメモリも暗号化する、というのはシンプルな理屈です。
業務を支えることを目的とするシステムである以上、プログラム言語、特にRPGに関する不安や疑問が尽きることはありません。表現は違っていても、RPGイコールIBM i、RPGの将来はIBM i の将来、そしてFF RPGに将来を託せるのか、というわけです。
RPGはやめるべきという社内の圧力もあるが、今から敢えてRPGで開発する価値はあるのか？ FF RPGは難しいのでは？
まず大前提として、RPGにはRPG/400（RPGⅢ）、ILE RPG（RPGⅣ）、FF RPGの三世代が存在していることはご存知と思います。厳密にはFF RPGはILE RPGの機能強化版なのですが、便宜上ここでは三世代に分類しておきます。そして最新のFF RPGの狙いは、JAVAやPHPなどといった言語との構文親和性を高めることによって、RPGという「ハードル」を越え易くし、オープン系の世界からも数多くの技術者をIBM i に呼び込むことにあります。FF RPGは単なる言語スペックの改善ではなく、IBM i の将来性を担保するための手段、という役割も担っています。
RPGに対する否定的印象の多くは、RPG/400（RPGⅢ）を想定したもののようです。そして将来を考えた時に、RPG/400のプログラム資産を増やすことは望ましいことなのか、と問われたら、前提条件を何も設けなければ「そうは思えない」と回答することになります。言語そのものが強化される見込みは無いばかりでなく、オープン系技術者を呼び込もうとしても親和性は高くありませんので、RPGの「ハードル」は高いままです。もちろんこれはあくまでも一般論であり、個々の事情によって答えが変わる可能性はあります。
プログラム言語の難易度は一概に言えるものではありません。どの言語も何らかの思想やポリシーの元で、わかり易くありながら高い生産性を実現することを目指して設計されます。これが個々のプログラマにうまく受け入れてもらえるか、ではないでしょうか。例外もありますが、私の知る限りにおいて、ベテランの方はFF RPGに馴染み難くRPG/400を好む傾向があるのに対して、若年層の方はFF RPGを好むようです。そして好みに合わない言語を「難しい」と感じるわけです。
IBM i を活かしてDXを推進しようとする時、避けて通れないのが既存アプリケーションとインターネットとの連携です。特にRPGⅢプログラムをどう扱えば良いのか、が気になるところです。
既存のRPGプログラムをWeb API化するには、RPGⅢをILE RPGに変換する必要がありますが、単純変換しCLなどから起動した場合に、プログラムの挙動に変化はありますか？
シンプルな答えは、挙動に変わりはありません、というものです。これはこれで終わりなのですが、質問者の方が前提とされている、RPGⅢからILE RPGへの変換は必ずしも必要ではない、という点を念のために確認しておきたいと思います。
Web API化するためのRPGプログラムは、RPGⅢではなくILE RPGやFF RPGで記述されていなければならない、という理解は正しいものです。既存のRPGⅢプログラムを変換するのも一案ですが、中継用のILE RPGやFF RPGプログラムを新たに開発する方法も考えられます。事例を見る限り、多数派は中継プログラム新規開発のようです。
両者を比較検討した事例を知りませんが、作業負荷の違いがその理由だと思います。機械的に変換する手段があるとは言え、基幹業務アプリケーションの変換は場合によっては網羅的なテストを必要とするのに対して、中継プログラムを新規開発する場合は、連携箇所のみをテストすれば済みます。
既存のRPG/400を活かしてDXに取り組まれているお客様事例を見ると、ベテランがRPG/400の保守を担当する一方で、若手がFF RPGによる新規開発に取り組む、といった組み合わせが一つのパターンになっているようです。複数のテクノロジー世代と複数の人員世代の協業というわけです。
一方で長期的な人員確保を見据えるならば、直ちにではないにしても、FF RPGへのシフトを視野に入れていただきたいと考えております。アプリケーション資産を次世代に託すための準備を、今から徐々に進めようというわけです。変換ツールもありますし、変換サービスの実績も少しずつ増えていると聞いています。
ではまた
