IBM i 7.5「セキュリティレベル20」廃止のインパクトと対処法　～旧態への決別を示す新OSの機能拡張と画期的なNVMeを、JBCC 藤原俊成氏が解説

藤原氏は第2部で、❶IBM i 7.5の新機能、❷セキュリティレベル20の廃止、❸新しいストレージ環境「NVMe」、の3点に絞って解説を行った。　第1部の豊村洋二氏（JBCC PFS事業部プラットフォーム推進）の講演が、オンプレミスのIBM iをPower Virtual Serverへ移行する際のポイントの解説であったのに対して、藤原氏の講演は、オンプレミスで利用中のユーザーに向けてIBM i 7.5やNVMeをどう捉え、今後どのように対処していくべきかを示したものであった。

クラウドとオンプレミスという好対照の第1部と第2部だったが、“現場”での経験を踏まえた実践的な考え方や対処法の解説という点が共通していた。その意味で、セミナータイトルの“ガチンコ”は、クラウドvsオンプレミスの“ガチンコ”に加えて、ベテランの経験と知見がぶつかり合う“ガチンコ”でもあった。

IBM i 7.5のセキュリティ機能

藤原氏は、❶「IBM i 7.5の新機能」の中で、セキュリティ機能の強化について時間を割いて解説した。以下のような内容である。

（1）新しいパスワードレベル・システム値（QPWDLVL）レベル4の新設（2）システム提供オブジェクトに対するデフォルトのPUBLIC権限の変更
（3）パスワードがパスワード・ルールに合っているかチェックする（QSYCHKPR）APIの提供
（4）パスワード認証メッセージとリターンコードの表示方式の変更
（5）セキュリティレベル20の廃止

そして❷は、上記（5）の詳細解説で、セキュリティレベル20の廃止の意味と対処法について説明した。つまり藤原氏は、第2部の2／3をIBM iのセキュリティに割いて解説したということである。　

その理由について藤原氏は、「IBM iは内向きの閉じられた環境で運用されてきたために、特別なセキュリティ対策を講じなくても安全に利用できていました。しかし最近のように、IBM iをデータベースマシンとして外部から利用したり外部システムとの連携が増えると、さまざまな局面でセキュリティ対策が必要になっています」と指摘したうえで、「IBM i 7.5ではこうした状況を踏まえてセキュリティを大幅に強化しています。IBM iは従来、『セキュリティが強固なシステム』と言われてきましたが、むしろ『セキュリティを強固にできるシステム』と言うべきで、IBM iが備える高度なセキュリティ機能を正しく設定しないと、OS本来がもつセキュリティ機能を十分に活用できません」と説明する。　

本稿では上記（1）～（5）のうち、（1）と（5）および❷について藤原氏の解説をレポートする。

新しいパスワードレベル・システム値　
（QPWDLVL）レベル4の新設

IBM iのパスワードレベルは、IBM i7.4まではレベル0〜3が提供されてきた。レベル3では最大128文字までのパスワードが設定可能で、大小の英文字、数字、記号、特殊文字を使って、SHA-1などで暗号化できた。ただしSHA-1は攻撃手法が発見されて危険性が高まっているため、それへの対処としてSHA-1後継のSHA-2を導入して暗号化できるようにした。それが今回の「レベル4」の新設である。　

これについて藤原氏は、「IBM iへのログインで10文字以上のパスワードを使用しているお客様は、私の経験ではほとんどいません。レベル『0』か『1』が大半で、それゆえに、今回のレベル4の新設は多くのIBM iユーザーにとって現実味のない拡張だろうと思います」と話す。そして、「そうした状況のお客様に10文字以上のパスワードを推奨し、パスワードレベルを上げることをお勧めするのも現実的とは言えません」と付け加える。

とはいえ、セキュリティの脅威が高まりつつある中で、レベルの低いパスワードを使い続けるのは危険である。　　

藤原氏はそれへの対処として、セキュリティレベルを「40」へ上げることを推奨している。これは（5）と❷の解説へ続く話である。藤原氏によると、「日本のIBM iユーザーの約6割はセキュリティレベル20で運用中で、“隠れ20”（後述）を含めると、約8割のお客様がレベル20で運用していると推定されます」という。　セキュリティレベルの内容は、次のとおりである。

・レベル10：セキュリティなし
・レベル20：IDとパスワード認証
・レベル30：レベル20＋オブジェクト認証
・レベル40：レベル30＋経路チェック
・レベル50：レベル40＋個々の権限付与式認証

藤原氏は、このセキュリティレベルを20から40へ上げることが、10文字以下のパスワードを使い続けることの「安全性の担保になる」という。

「レベル20は、IDとパスワードが一致しさえすればすべてのシステムリソースにアクセスできるという“万能の”セキュリティルールでしたが、レベル40にすると個々のオブジェクトに対して誰がアクセス可能かを設定する必要があり、さらにIBM iへのアクセス経路の設定・管理も必要になります。オブジェクトへの認証とアクセス経路の管理ができれば、パスワードが10文字以下であっても、少なくとも外部からの攻撃には強いシステムとすることができます」と、説明する。

セキュリティレベル20廃止の意味と対処法

今回のIBM i 7.5では、セキュリティレベル20が廃止になった。今回のハイライトの1つと言える機能強化で、今後、IBM i 7.5上でアプリケーションを新規に稼働させる場合は、レベル30以上の設定が必要になる（IBM i7.4以前の環境をIBM i 7.5に移行する場合は、レベル20のまま利用可能）。　
この「セキュリティレベル20の廃止」の意味について藤原氏は、「IBM iのセキュリティレベルは2006年のV5R4（IBM i5.4）からレベル40がデフォルトになっていますが、ユーザーの多くはレベル20に落として運用してきたのが実態です。しかしID・パスワードだけですべてのリソースにアクセスできるのは、さすがに今の時代にはそぐわないとIBMは考え、重い腰を上げたのだろうと見ています。たとえば、最近増えているオープン系のIFSゾーンを狙ったサイバー攻撃には、ユーザープロファイルでアクセス制限を行わない限り、完全なプロテクトは困難です」と説明する。

ただし、IBM iのセキュリティレベルを20から40へ上げるには「いくつかの対処が必要です」と、藤原氏は語る。その対処を行わずにレベル40へ上げると、「アプリケーションの作動中に異常終了したり、必要なデータにアクセスできないなどの事態に直面します」と注意を促す。　

藤原氏が推奨するレベル40への切り替え時の対処項目は、以下の6つである。

①組織全体のセキュリティポリシーの策定
②部門や業務単位を代表する代表ユーザーの決定（グループプロファイルの決定）
③一般ユーザーのグループ分け（グループ別にリストアップ）
④外部からSQLやFTPなどで接続してくる時の特定ユーザーの決定
⑤ファイルやプログラム、ライブラリなどの個々のオブジェクトに対する権限のリストアップ
⑥バックアップなどのシステム全体の運用にかかわる特殊権限の割り当てユーザーの特定

藤原氏はこの中の「①組織全体のセキュリティポリシーの策定」が「最も重要」と強調する。「というのも、セキュリティポリシーを整備し実践している企業はきわめて少数だからです。セキュリティポリシーを策定すれば自ずから部門・業務を代表するユーザーが決まり、個々のオブジェクトを利用できるユーザーも決まってきます。これらが決ればセキュリティレベル40への対応は容易です」（藤原氏）　

藤原氏はこれら①～⑥の作業に、「最低でも3カ月はかかります」と話す。ユーザーやオブジェクトの調査と権限関係の調整が必要になるからだ。そのため「時間に余裕をもって計画的に作業を進める必要があります」という。　

藤原氏は、①〜⑥の作業に時間を割けないユーザーに対して、「セキュリティレベル40もどき法」（以下、もどき法）という暫定的な対処法を説いている。前述の“隠れ20”がこれにあたる。　　

もどき法とは、①セキュリティポリシーの策定をスキップして、②代表ユーザーを先に決め、その代表ユーザーに＊ALLOBJなどの特殊権限を付与して、さらに一般のユーザー（子ユーザー）が代表ユーザーになりすましてシステムを利用するという方法である。　

オブジェクトへのアクセスを特定のユーザー（＝代表ユーザー）に制限しているので形式的にレベル40に対応していることになり、「システム監査を通すことも可能になります」と、藤原氏は話す。　　

ただし、もどき法はオブジェクト個々に対する特定権限を設定していないため、「内部からの異常なアクセスやセキュリティホールを突く攻撃には、まったく無力。IBM i 7.5でセキュリティレベル20が廃止になったのを機に、レベル40への切り替えに本腰を入れて取り組む時期にきています」と、藤原氏は述べる。　藤原氏は講演で、もどき法から「セキュリティレベル40本気法」（以下、本気法）への移行も解説した。次のような手順になる（図表1）。

①ファイル、プログラム、ライブラリなどの個々のオブジェクトに対して権限リストを使って特定権限を設計
②業務運用に必要に応じて代表ユーザー（グループプロファイル）を権限リストに登録
③ゲストユーザー（＊PUBLIC）には、＊EXCLUDE（拒絶）指定を行い、登録以外のユーザーからのアクセスを排除
④権限リストを対象となるオブジェクトに適用（GRTOBJAUTなど）
⑤代表ユーザー（グループプロファイル）に与えていた＊ALLOBJなどの特殊権限を必要に応じて段階的に剥奪
⑥テスト環境でパイロットテストを実施して、順次切り替え確認を実施。