IBM i のウンチクを語ろう
～ その79：ファイル転送をセキュアにしよう
皆さん、こんにちは。昨年6月のこのコラム「市場調査レポートにみるIBM i の課題」でもお話しましたとおり、ここ数年のIBM i コミュニティにおける最大の懸念事項はセキュリティのようです（レポート中の棒グラフではサイバーセキュリティとランサムウェア「Cybersecurity and ransomware」と表記されています）。また調査会社のITIC社もそのアンケート結果レポートの中で、セキュリティは最大の脅威であるした回答者は76%に達したと述べています。IBM i は堅牢なシステムだとは言われていますが、それも正しく設定・運用されていればこそであり、最新のあらゆるセキュリティ機能を使いこなせていると断言できる方はどのくらいいらっしゃるでしょうか。かく言う私自身も、もし問われたら自信を持って（?）「No」と答えることになりそうです。
オープン系システムに比べれば滅多に狙われないという幸運に助けられて、私達の多くはIBM i のセキュリティ神話は生きていると思い込んでいるだけなのかも知れません。かつてないほどにシステムがオープンな環境で利用されるようになり、より高度化するハッカーの攻撃を受けるリスクが高まっている中で、防御側も相応に進化しなければなりません。IBMロチェスターの製品開発部門も手をこまねいているだけでなく、最新バージョン7.5においてセキュリティ管理機能を厳格化していることはご存知のとおりです。一例として、海外翻訳記事「
一言セキュリティと言っても様々な観点があります。データを暗号化しようと考える方もいますし、OS標準機能を活かして取得した監査ジャーナルに基づいて、監査レポートを生成しようと考える方もいます。先のレポートによると、最も多くのユーザーが対策を打っているのは「Secure managed file transfer」、言わばセキュアなファイル転送です。48%のユーザーが既に実装済み、さらに15%が実装を計画中となっています。企業の重要なデータが、様々な防護策を講じたサーバーを離れて、インターネットという無防備なネットワーク上を流れることを想像してみれば、これほど危ういことはありません。何らかの対策が必要になることに、異を唱える方はいらっしゃらないでしょう。
話は脇に逸れるのですが、セキュリティ対策は防衛する側にとっては防戦一方、攻撃する側は反撃されるリスクはほぼ無いという、完全に非対称の状況にあります。巷を賑わせている話題ではありませんが、敵基地攻撃能力（？）を備えたアンチウィルス・ソフトのようなものがあっても良いのではないか、などと思ったりしております。攻撃者にリスクを負わせるわけですね。実現可能性はあるのかないのかわからない、単なる個人的妄想に過ぎませんが。閑話休題・・・
業界標準の対策の一つとして挙げられるのは、SFTP（SSH File Transfer Protocol）の実装です。FTPはファイル送受信の手順として多くの方がご存知と思います。この冒頭にSSH（Secure SHell）が付されているのでFTPのバリエーションのようにも見えますが、実はそうではありません。暗号によって保護された通信を行うSSHという手順が先にあって、SFTPとはその中でFTPそのものではないけれども、FTPのように機能するアプリケーションである、と考えるのが妥当なようです。主従関係が逆だったのですね。私自身もこの点は誤解しておりました。そしてFTPの改善版にあたるのは、FTPS（FTP over SSL/TLS）の方です。暗号化通信を確立するためのSSL/TLSという手順があって、それを前提に機能するFTPだというわけです。インターネット・ブラウザを利用する際の、HTTP手順をセキュアにしたHTTPSのような位置付けにあります。ちなみにSSLもTLSも安全な通信を行うためのセキュリティ手順なのですが、TLSはSSLの次世代規格、くらいに考えておくので良さそうです。
SFTPもFTPSもどちらも暗号化されたファイル転送だけでなく、認証すなわち相手先の身元確認を実現するものであり、一概に優劣を決められるものではないようです。ただ、元々はUNIX系OSと共に普及してきた経緯があることや、ファイアウォール構成がシンプルになることから、SFTPを含むSSHの方がFTPSよりも目立っているかもしれません。SSHをオープンソース化した製品である、OpenSSHの普及もこれに貢献しているのでしょう。IBM i にインストールする場合は、無償の製品番号5733-SC1のオプション1「OpenSSH, OpenSSL, zlib functions」を利用します。
両者の違いとして認証のやり方を挙げることができます。FTPSの前提にあるSSL/TLSにおいては、認証局（CA: Certificate Authority）が発行する電子証明書を利用します。認証局という名前はあたかも公的機関が介在しているかのような印象をもたらしますが、必ずしもそうではありません。不特定多数向けの第三者的なパブリック認証局だけでなく、限定的な範囲を想定した私的なプライベート認証局もあります。この点についても、私は誤解しておりました。一方のSFTPのためのSSHにおいては、パスワード認証または公開鍵認証方式が主に利用されています。
パスワード認証方式は極めてシンプルでわかり易い反面、リスクもあります。クライアントからのアクセスを認証するためには、サーバー側でも各クライアントのパスワードを保持しておく必要があります。ここでもしサーバーが乗っ取られたら、多くのクライアントのパスワードが一気に漏洩してしまうかもしれません。自己防護策としてよく言われるのは、万一の被害の範囲を限定するためにパスワードの使い回しをしないことです。管理が面倒になりますが。
公開鍵認証方式においては、クライアントはあらかじめ秘密鍵と公開鍵の二種類を生成し、公開鍵のみをサーバーに送っておきます。文書を送付するに際して、クライアントは秘密鍵で文書に署名し、SSH手順に沿って確立された暗号化通信を経て、サーバーに送ります。サーバーはあらかじめクライアントから受け取っておいた公開鍵で署名を確認して文書を開く、というのが大雑把な手順です。この方式の優位性はいくつかあります。サーバーはクライアント固有の秘密鍵を知ることはできませんので、秘密鍵が漏洩してしまう可能性はありません。また、SSHの暗号化通信が確立された際のセッションIDを、クライアントとサーバーとで共有・利用するので、過去に作成された署名が流用されることもありません。すなわちクライアントが秘密鍵で署名する際にはセッションIDが混ぜ込まれており、サーバーが認証する際には公開鍵だけでなくセッションIDも使います。このように何らかの手段でクライアントから秘密鍵が盗み出されない限り、パスワード認証方式よりも安全性が高いので、同じ秘密鍵を複数サーバー相手に使い回すことも可能とされています。使い易さにも配慮された仕組みだと言えるでしょう。
誤解があったところで実害は無いためでしょうか、今では大分目立たなくなりましたが、従来はそのメカニズムについて誤った情報も発信されていたようです。混乱の根源は「公開鍵認証においては、送信側は秘密鍵で暗号化し、受信側は公開鍵で復号化する」といった、認証と暗号とを混ぜこぜにしたような説明にあります。秘密鍵・公開鍵という用語は、暗号のところにも登場するのが原因だったのかもしれません。SFTPの手順書を参照しながら、技術的裏付けを確認しようとインターネットでSSH関連サイトを読み散らかしているうちに、実は私自身もかなり混乱しました。
このような時は、一次情報すなわちSSHを定義した文書にあたるというのが常套手段なのかもしれませんが、文書リストとその分量を見て、正直言いまして気分が萎えました。SFTP手順書がきっかけになっているとは言え、SSHの専門家になろうなどと野望を抱いているわけではありません。そこで世間に溢れる二次情報の中で、文責が明確なものや、ペンネーム投稿であっても、その後のQ&Aがあったり、適宜記述の調整がなされたりしている良心的と思われるものを選んで目を通してゆく方針に切り換えました。その過程で大方こんなところなのだろう、というレベルに最近ようやくたどり着き、その成果の一部がこのコラムというわけです。
製品や機能の実装を生業とはしていない私が、何故突然SFTP手順書を読み始めたのか。実は現在、ファイル転送をセキュアにするSFTP手順を具体的に示すドキュメントを開発・公開しようとしています。様々な新技術を普及させるためには、必要性を訴求するだけでなく、どなたでもわかる具体的な利用手順を明確に示すことが時に必要になりますが、IBM i が絡むとどうしてもその分量は限られてしまいます。そこで前提知識無く使える文書作成を目指して、弊社SEと共に作業を進めているところです。私の役割はSEの知見を素人目線に合うよう調整すること、誤解を恐れずに言うならば、正確性と実効性を損なうことなく文書の技術レベルを敢えて落とすことにあります。
文書公開日は準備の進捗次第なので現時点ではいつとは申し上げられませんが、このコラムと同じe-BELLNETの中の、「IBM i 資料集」カテゴリの限定コンテンツとして近いうちに公開できればと思っております。皆様がIBM i のセキュリティ神話を超えるためのきっかけになれば幸いです。
ではまた。
