セキュリティ

ITとそれを取り巻く環境の進化はシステムのセキュリティ強化に役立つ一方で、犯罪者が使えるテクニックの強化にも「貢献」しているのが実情です。イタチごっこが繰り広げられる今日において、セキュリティ脅威と言えば世間を騒がせているフィッシングだとかランサムウェアなど最先端の話題を思い浮かべがちですが、ここでは原点に立ち返ってIBM i アーキテクチャの中に組み込まれているセキュリティについて考えてみます。

セキュリティとは要するに何が実現できれば良いのでしょうか。暗号化とか権限管理など様々な対策が思い浮かびますが、突き詰めてゆくと「情報セキュリティの3要素」、または英語頭文字を取ってCIAという言葉で一般に説明されています。個人が触れることができる情報の範囲が制限されており（Confidentiality）、その情報が信頼でき（Integrity）、必要な時にいつでもその情報に触れることができる（Availability）、というものです。テクノロジーの進化に伴って表面上の事象や対策は変化してゆきますが、これらはセキュリティの原点であり土台でもあります。セキュリティの脅威はこれらのうちのいずれかまたは複数の要素を担保できなくするような何らかのアプローチであり、特に業務用途であるならばシステムには強固な耐性が求められます。なお、3要素の中でAvailabilityはその名のとおりアベイラビリティまたは可用性という言葉で、独立したシステム要件として語られることが多いので、ここでは切り離して狭義のセキュリティ、すなわち触れることができる情報の範囲（C）とその信頼性（I）を念頭に筆を進めてゆきたいと思います。

さて、実装するべきセキュリティ対策を検討するにあたって、闇雲にあらゆる手段を講じようとするのではなく、事前に対象となるサーバーの位置付けやその利用特性を整理しておきたいと思います。例えばかつてマイクロコンピュータと呼ばれていた原始的なPCは、趣味の世界の代物であり守るべきデータもプログラムもありませんでしたので、セキュリティという発想は不要でした。今日の個人用PCにおいては、個人情報が蓄えられていたとしても、他のユーザーの存在を気にかける必要性はありません。企業で使うサーバーになると複数のユーザーが同時に利用することが前提になりますが、安定的に運用するために、サーバーあたり稼働するアプリケーションを一つに限定するケースも多々見られます。これに対してIBM i はビジネス用途の統合型サーバーとして、数多くのユーザーによる、数多くのアプリケーションを同時にサポートする、というのが典型的な利用の姿です。このような利用特性は、先代のAS/400、さらにはその先代にあたるSystem 38が設計される際の前提とされておりました。

複数ユーザーと複数アプリケーションを想定するのであれば、ユーザーが触れることができるデータや、アプリケーションが処理を行うデータは適正な範囲内に制限されており、その正確性は担保されていなくてはなりません。そしてIBM i を統合型サーバーとして位置付けるならば、セキュリティ機能は最初からシステムの中核を成している必要があります。ところがIBM i を含め、コンピュータと呼ばれるマシンにおいては、そもそもセキュリティという概念は存在しないという現実があります。一体どういうことなのでしょうか。

例えば販売管理アプリケーションが扱うデータに、「12345678」という数値があったとします。人やアプリケーションはこれを、商品コードだと判別するかもしれませんし、何かの商品の価格と見るかもしれません。もしかしたらこの数値で表現される、プロセッサに対する命令コードなのかもしれません。これに対してマシンはこの数値が何を意味するのかを関知することはありません。あるあらゆるデータは単なる0と1の並び、すなわちビット列に過ぎないので、マシンはそれなりの命令を受け取れば、その意義を考慮することなく実行します。やろうと思えば商品コードを1.1倍にするような演算を実行することも可能ですし、この8桁の値をプロセッサに対する命令として扱うことも可能です。こうなると結果を予測することはできないばかりでなく、システムの暴走を招くかもしれません。

「12345678」に価格とか商品コードとか命令コードと意味付けしているのは、人やアプリケーションの都合によるものです。データの意味を理解しているので、マシンが実行することの妥当性を判断できます。価格情報だとわかっていれば、1.1倍するのはあり得ることだと考え、消費税込みの金額を算出しようとしているのだろうと推測することができます。演算対象が商品コードであれば、何かの間違いであることがわかります。

同様にマシンが持つ記憶域の中で、商品マスターを蓄えておくべき領域も、人やアプリケーションが設定しているに過ぎません。マシンは取引先情報を蓄えておくべき領域内（取引先マスター）に商品情報を書き出すように命じられたら、そのまま実行することができます。商品マスターと取引先マスターの間に、記憶域の「境界線」のようなものは存在しないのです。

マシンのこのような不都合な振舞いは、悪意を持ったハッカーが故意に発生させるかも知れませんし、善意によるものではあってもスキルや経験が不足しているプログラマが引き起こしてしまうかも知れません。いずれにせよ「何でもあり」状態の、セキュリティの概念が無いままに放置していては、マシンを安心して業務用途に利用することはできません。ビット列を取り込んで何らかの作業を行い、新たなビット列を生成して結果を書き出すだけのマシンに対して、これ以上を求めるのは無理がありそうです。そこでセキュリティ・ツールと言われる専用のアプリケーションを利用して、マシンの振舞いを管理することにします。セキュリティはマシンの中核部分ではなく、その上で稼働するツールが担っているというわけです。

一方IBM i においてはマシンの概念が通常とは異なっています。ハードウェアの観点から見れば、IBM i も他のマシンも変わるところはありません。ところが前章「2-1．アプリケーション資産継承」の中で述べたとおり、IBM i におけるマシンはTIMIと呼ばれる、ソフトウェア的に作られた仮想的なものです。あらゆるデータは単なるビット列だけではなく、これを前提とするオブジェクトを形成しています。

オブジェクト指向アーキテクチャという言葉を聞かれたことのある方も多数いらっしゃるものと思います。JAVAプログラミングにおいては必ず登場する概念で、手続き中心ではなくデータ中心、処理を実行する側ではなく処理される側に着目したシステム開発の考え方です。データを中心として実行可能な処理内容、すなわちメソッドをあらかじめ定義することでオブジェクトとし、マシンのあらゆる動作を定義済みメソッドの範囲内に限定することでセキュリティを担保します。

IBM i においては、データに付された機能は「タグ」という言葉で説明されていることが多いようです。例えばデータ「12345678」についてタグが示すものは、アクセスできるのは誰であり、商品の価格の場合には算術演算が可能、命令コードならば実行が可能、といった具合です。そして指定された以外のユーザーによる、指定された以外の演算を実行することはできない、という制約を仮想マシンに適用しています。

タグの書き換えはセキュリティ破りになりかねませんので、IBM i においては許容されていません。IBM i のオブジェクトはTIMIと呼ばれる仮想マシン上に存在するのですが、OSが提供するサービスを経由して、その下層にあるSLICというマイクロコードによってのみ生成することができます。もし定められた手続きによらずにタグを書き換えようとしたら、SLICに直接アクセスしなければならないのですが、IBM i はその手段を封じています。IBM i の歴史において、OSとTIMIを迂回する試みが成功した例は、私の知る限り一度もありません。

Windowsにおいてはファイル拡張子がタグに近い機能を担っていると言えるでしょう。これはファイルの属性を認識するための仕組みであり、ファイル名とピリオドに続く3-4文字の英数字です。例えばファイル拡張子が「txt」になっていたら、そのファイルは実行プログラムではなくテキストだと想定されます。極めてシンプルな仕組みなのですが、IBM i のタグと違って偽装することも後から書き換えることもできる、という問題を抱えています。すなわち見た目はテキストであったとしても、実際の中身は実行ファイルなのでウィルスプログラムを起動してしまうというリスクを免れません。

マシンがセキュリティを「知っている」かそうでないか、仕組みの違いはセキュリティの脆弱性報告件数の差となって表れています。メーカーや製品を横断的に見るCVE Detailsという脆弱性報告のデータベースによると、2023年5月7日時点で、IBM i の全報告件数は15に留まるのに対して、例えばWindows Server 2019では2,458件に達しています。

IBM i の原点にあたるSystem 38が開発された1970年代当時は、「オブジェクト指向」といった用語は存在せず、開発者達はせいぜい「データ中心の」といった言葉でこの先進的な概念を表現していました。マーケティングの観点から見ると、ちょっともったいなかったですね。ちなみにIBM i 産みの親と言われているF.ソルティス博士はその著書の中で、いくつかあるIBM i の特徴の中で最も重要なものをどれか一つ挙げるとしたら、このオブジェクト・アーキテクチャを選ぶと述べています。

極めて似た用語ではあるのですが、IBM i の「オブジェクト・アーキテクチャ」は、「オブジェクト指向アーキテクチャ」とは厳密には区別されています。データを中心にして実行可能な演算が定義されているという点は共通なのですが、IBM i においてはオブジェクト指向アーキテクチャの「継承」（インヘリタンス）がサポートされていません。巷にあるドキュメント類を見ると混用されているケースもあるようですが、言葉遣いや細かな定義の違いにこだわるよりは、大雑把には両者は同じようなものだと捉えるのでも差し支えないと思っております。

セキュリティに絶対は無い、100%完璧な対策は存在しないと言われています。IBM i のセキュリティは、データとそれに付されたタグのみによって守られているわけではありません。ネットワーク・ポートを監視したり、バックアップ時の暗号化を行ったりと、他のシステムにも実装されているのと同様の機能も備えています。さらにフィッシングに引っ掛からないための社員教育を行うとか、システム管理を行うためのコンソールは誰もがアクセスできる場所には設置しない、といったことも広義のセキュリティです。様々な観点がある中で、ビジネスのための統合型サーバーという位置付けを念頭に、IBM i の設計者達はそのごく中核部分にユニークで現在においてもきわめて頑強なセキュリティの仕組みを埋め込んでいたわけです。