IBM i 7.1 暗号化ツールを使用して、今日のデータ・セキュリティーの課題に対処する
保存されているデータと移動中のデータを暗号化するツールの現状を把握する
IBM i OS のあらゆるリリースで、IBM は私たちの機密データを保護するため、新しく、さらに優れたツールを私たちに届けてくれました。リリース 6.1 と 7.1 も例外ではありませんでした。そして一番大きな宝物は最新の 7.1 アップデートに入っています。この記事では、7.1 にアップグレードする際に出くわすかもしれない昔からの障壁についてお話しし、暗号化を取り巻くアーキテクチャーについて説明し、保存されているデータと移動中のデータの暗号化に役立つ 7.1 機能について説明します。また、今すぐ 7.1 に移行した方がいい理由についてもお話しします。
OS のアップグレードが遅いのはなぜか
苦痛を避けるのが上手いのが人間です。私たちの多くは、明らかに対処すべきバグが残っているのに、新しいバージョンの OS にアップグレードすれば、どれだけの痛みを伴うか確実に学習してきました。あなたが私と同じなら、そのサイクルの中で OSのアップグレードを急ぎすぎたおかげで、火消しに何時間、あるいは何日も失うことになるでしょう。この痛みは IBM i プラットフォームだけのものではありません。Microsoft Windows でもこうした経験をしています。私たちは皆、新しいリリースが発表された後、OS のアップグレードを急ぐときは注意しないといけないと学びました。この点で言えば、できるだけゆっくりとアップグレードするのが最も安全なコースのように思われます。私が知るところでは、多くの IBM i ショップは、IBM がその OS のサポートを停止することになった時にだけ、その OS をアップグレードします。
これは、大変よく理解できますね。私の個人的な OS アップグレードの災難は 1980 年代初頭に起こりました。ある金曜日の夜に、オーダー処理と在庫管理に MAPIC を動作していた IBM S/36 をアップグレードしようとしたのです。新しい OS バージョンを手に入れ、新しい MAPIC バージョンも準備万端でした。「さぁ、アップグレードしよう！」と甘い考えが頭に浮かび、自分に言い聞かせました。「さて、こいつを片付けてしまおう！」
土曜日の午後には、バックアップは完ぺきで、アップグレードを開始しました。「お茶の子さいさいさだ」と心の中で思いました。
土曜日の夕方には、私の世界はひっくり返り、混乱の中にありました。控えめに言っても、作業はうまくいきませんでした。コンソールに変なメッセージは出るし、ディスケットは読み取れない (そう、あのデカいディスケットです)、おまけに、その他さまざまな不可解な症状が、未熟な IT 野郎に突き付けられていたのです。苦痛の世界にいる私は、助けを求めようとしました。この問題を早くなんとかしないと、会社は月曜日に仕事になりません。
まもなく、私は IBM に助けを求める電話をしていました。必死に何とかしてほしいと電話を次々と。結局、レノにある IBM サービス・マネージャーにつながりました。彼は、私が喉から手が出るほど欲しかった交換用のディスケットを持っていました。彼は助けてくれるのかって？そう、彼は中間地点で私と会うことになりました。カリフォルニア州グラス・バレー近くのワイナリーから車に飛び乗り、雪深いドナー峠で真夜中のランデブーとなりました。
その心根の優しい IBM 社員のおかげで、その大参事とも言える状態を生き延びることができましたが、それは拭い去れない印として私の記憶に刻まれました。最後の最後まで絶対にシステムをアップグレードしないぞ、と。それは私の信念のようなものでした。そして、それは数十年続いたのです、今のいままで。
システムを 7.1 にアップグレードする恐怖を無視するときは、本当に十分な理由があります。私のように、メリットが十分あるならそのアップグレード恐怖症を克服できるでしょう。7.1 は市場に出てからしばらく経っているので、そのセキュリティー面のメリットから、アップグレードの価値はあります。詳しく見てみましょう。
OS のアップグレードとベンダー・サポート
一部の IBM i の顧客は、一般的にアップグレードしたがらないことに加えて、ソフトウェア・ベンダーに最新版の OS をサポートしてもらう場合に問題を抱えています。このように、アップグレードしたがらないのは、特に非常に専門化されたソリューションを提供する小規模なソフトウェア・ベンダーに当てはまるようです。こうしたベンダーは、私たちと同じように、アップグレードに対する情熱の欠如に冒されていることが多く、それが彼らの顧客にも影響しています。これは不幸なことです。なぜならIBM は、そのソフトウェア・パートナーに早期リリースを入手できるよう、いい仕事をしているからです。私は、IBM i 開発者サポート・チームと 10 年以上に渡って一緒に仕事をしてきましたが、彼らは早期リリースのテストでは常に助けてくれました。さらに、ソフトウェア・ベンダー向けの IBM のハードウェア・プログラムは並外れて優れています。システムを大幅に割引価格で手に入れたり、仮想の代替品を使用して新しい IBM i リリースをテストしたりできます。
あなたのソフトウェア・ベンダーがまだ 7.1 に対応していないなら、そのプロバイダーと最新版の入手について腹を割って話し合うべきだと思います。7.1 がリリースされて 2 年以上経ちますので、サポートしないもっともな言い訳はほとんどないでしょう。ソフトウェア・ベンダーがすぐに腰を上げないという理由で、7.1 のセキュリティー面のメリットを逃すのは残念なことです。
準拠性と暗号化
暗号化とセキュリティーがここまで重要になったのはなぜでしょうか。GFI Software による最近の調査によると、マルウェアを含んだスパムのせいで、米国のビジネスの 44 パーセントのネットワークが破壊されているとの報告がある、とされています (tinyurl.com/dygtxd9 の GFI のレポート参照)。データ侵害の数は、ここ数年間毎年増え続け、攻撃はより巧妙になってきています。それにしたがって、順守規定や違反告示法も、機密データの暗号化に関してさらに厳しくなってきています。あなたの会社もおそらく、データ保護を義務付けるいくつかの順守要件に該当するでしょうし、データ損失に対する金銭的罰則も厳しくなってきています。あなたの組織に影響すると思われる順守規定の例をいくつか挙げてみます。
- PCI Data Security Standard (PCI DSS) ― クレジット・カードやペイメント・カードに応じる場合
- HIPAA/HITECH Act of 2009 ― 患者の医療情報を取り扱う場合
- Sarbanes-Oxley Act (SOX) ― 株式会社の場合
- FERPA ― 教育機関の場合
- GLBA/FFIEC ― 銀行または金融機関の場合
- 州のプライバシー法 ― 生きて脈がある場合 (つまり、誰でも)
全体的に、これら順守規制はすべて、暗号化にさらに注目し、あらゆる規模の企業に大きな影響を与えています。IT システムおよびデータベース中で機密情報を扱わない組織など考えられません。
IBM コミュニティーにいる私たちのほとんどは、複数の順守規制の影響を受けているため、7.1 の暗号化機能は極めて優れているようです。では、暗号化をさらに簡単にする見込みが高い自動暗号化技術に目を向けてみましょう。
Transparent Data Encryption による自動暗号化
Transparent Data Encryption (TDE) は、データベース・レベルで実装されたデータベース全体の暗号化方式です。すべてのデータベース表とオブジェクトは暗号化され、ページは必要に応じて復号されます。開発者の目から見て、TDE の素晴らしい点はその使いやすさです。暗号化機能を起動するために何らプログラミングする必要はありません。通常、暗号化キーをいくつか作成して、TDE 暗号化機能を起動させるだけです。
IBM i では新機能ですが、TDE の概念が紹介されて何年も経っています。Microsoft が SQL Server 2008 Enterprise 以降に TDE を実装しました。Oracle の 11g Enterprise Edition with Advanced Security のユーザーも TDE を何年も使用しています。
TDE の長所はそのシンプルさにあります。欠点はスケーラビリティーに欠けている点です。非常に大規模なデータベースのパフォーマンスは TDE では劣っており、このため Microsoft と Oracle の顧客の中には TDE を使用できない顧客もいます。
図1: 自動列レベル暗号化で可能な 2 つのアプローチ
図2: 自動列レベル暗号化の Decrypt and Process (復号して処理する) モデル
IBM i では、TDE のオプションはありません。 DB2 for i が単に TDE に対応していないためです。一番近いのが iASP ディスク暗号化ですが、これはディスクレベルの暗号化であり、ディスク上にあるデータベースにたまたま対応するだけです。実装という観点または準拠性という観点からは TDE と同じではなく、顧客は iASP 暗号化のパフォーマンスに問題があると報告しています。
自動列レベル暗号化: 2 つのアーキテクチャー
魔法の帽子をしばしかぶって、自分が、キー (索引) フィールドに対して列レベルで自動暗号化を実装しなければならないデータベース開発者である、と想像してみてください。あなたは心の中でこう思うでしょう。「暗号化された値に対して、索引を使用して表から値を読み取ろうとするときは必ず、単純に索引全体を復号して、読み取ろう。その方が洗練されていてシンプルだし、順番がどうなっているかわからないような煩わしい暗号化データの心配をする必要がないから。」
それで、自動列レベル暗号化への最も簡単な道を歩んだでしょう。しかし、まもなく壁にぶつかります (後になってさらに壁にぶつかります）。
別のデータベース開発者が魔法の帽子をかぶって、別のアプローチを行います。「暗号化された値に対して、索引を使用して表から値を読み取ろうとするときは必ず、単純に検索値を暗号化して、それから暗号化された値を使用して索引を読み取ろう。そうすれば、値を 1 つだけ暗号化するだけなので、あっという間に作業できるに違いない。」
それで、その開発者は自動列レベル暗号化へ多少困難な道を歩みましたが、そのアプローチは非常に大規模なデータベースに有効です。ただし、その開発者もまもなく壁にぶつかります (同じように、後になってさらに壁にぶつかります）。
さあ、ここで魔法の帽子を取りましょう。これらは、データベース開発者が自動列レベル暗号化に対して行った 2 つの基本的なアプローチです (図1 に図示しています)。このアプローチの例をいくつか見てみましょう。
復号して処理する
あなたが、最初に出てきた開発者のように索引全体を復号してからアクセスすることにした開発者の場合、おそらく Microsoft SQL Server での作業経験が豊富だと思われます。図2 で示すようにこのアプローチでは、Microsoft SQL Server は Cell-Level Encryption (セルレベルの暗号化) を使用します (Microsoft は「セル」を「列」とほとんど同じ意味で使用します)。そのため、SQL Server 2008 Enterprise (以降) のユーザーの場合、Cell-Level Encryption (セルレベルの暗号化) にアクセスでき、次のように動作します。索引である暗号化列を使用する SELECT ステートメントを実行する場合は必ず、SQL Server は列全体を復号してから、SQL 要求を満たそうとします。
想像できると思いますが、データベースが大きくなるほど、そのデータすべてを復号するのに時間と労力がかかります (CPU サイクルなど)。実際、パフォーマンスのオーバーヘッドは、このアプローチの最も大きな欠点です。しかし、ほとんど使用しない索引を暗号化していた可能性があり、その場合はこのアプローチがうまく機能します。しかし、データベースが大きい場合、多数のユーザーで頻繁に使用されている暗号化された索引を展開してはなりません。
それがぶつかる壁です。この列レベル暗号化モデルは、小規模から中規模のデータベース表ではうまく機能しますが、IBM i プラットフォームで見られるような、大規模なデータベース表には適していません。
暗号化した状態で処理する
あなたが 2 番目に紹介したデータベース開発者のような場合、その列全体を復号して処理するようなことはしなかったでしょう。その代わり、その SQL SELECT ステートメントを解析し、検索値を暗号化して、暗号化された値に対して見出し検索を実行したでしょう。こうしたデータベース開発者なら、IBM で仕事をしていたかもしれません。図3 が示すこのアプローチは、正に、米国ミネソタ州ロチェスターの IBM データベース開発者が Field Procedure (FIELDPROC) 自動暗号化を IBM i 7.1 に実装したときに採用したアプローチです。
図3: 自動列レベル暗号化の Process While Encrypted (暗号化した状態で処理する) モデル
そうした IBM 開発者は、あらゆる SQL (または RPG または COBOL など何でも) ステートメントを解析して検索値を暗号化するのに大変な作業をしなければなりませんでしたが、その困難にうまく対処し、結果、パフォーマンスがアップしました。かなり大きなデータですか？心配ありません！確実に速くそのデータに取り組むことができます。
しかし、暗号化された値の範囲を読み取る場合はどうしましょうか。IBM i プラットフォームの特別な壁にぶつかったようですね。暗号化された値はどんなソート順にも従わないのです (もし従ったとしたら、実際は暗号化されていないということです)。その結果、値の範囲を読み取る必要がある場合、それを実行するにはさらに大変な思いをすることになるでしょう。それは、私たち IBM i 開発者として、 IBM i プラットフォームの DB2 FIELDPROC で直面する特別な課題です。暗号化された索引は思うようには動作せず、この問題を回避するために、多少の開発作業が必要になるかもしれません。しかし、FIELDPROC 全体のメリットは素晴らしいものなので、ほとんどの IBM i ユーザーはこの実装には満足するでしょう。
7.1 の DB2 FIELDPROC 暗号化
FIELDPROC 自動暗号化は 、Process While Encrypted (暗号化した状態で処理する) モデルに基づいています。FIELDPROC は DB2 データベースに実装された列レベル出口点として考えることができます。そして、その動作は正にそのようになっています。出口点を起動した後、読み取り、挿入、または更新の各操作があるときは必ず、データベースによりプログラムが呼び出され、暗号化作業は完ぺきに自動化されます。
FIELDPROC は数年間、IBM System z メインフレームで DB2 の一部でした。しかし、リリース 7.1 で導入されてから IBM i で新しくなっています。FIELDPROC は以前の IBM i リリースでは使用できません。
この FIELDPROC 機能はどのように実装するのでしょうか。FIELDPROC 出口プログラムをデータベース・ファイルに登録するのは簡単です。既存の表を変更するには SQL ステートメントが必要で、または新しい表を作成するときに FIELDPROC プログラムを定義できます。また、SQL を使用して FIELDPROC 出口点を削除することもできます。次に例を挙げます。
DDS から FIELDPROC 出口点を起動する方法はありません。このため、一部のデータベース開発者は混乱しました。FIELDPROC 出口点を DDS で作成されたデータベースで使用できるでしょうか。答えはイエスですが、SQL を使用して、出口点プログラムを追加および削除する必要があります。FIELDPROC 出口点を実装する DDS 属性はありません。
では、自動暗号化に FIELDPROC を使用するには、その他に何をする必要があるでしょうか。その出口点プログラムを作成する必要があります。他の IBM 出口点と同様に、FIELDPROC 出口点を作成する負担はあなた、開発者、またはソフトウェア・ベンダーに降りかかります。7.1 InfoCenter (tinyurl.com/4q96mgd) にいくつか例を示していますが、IBM は実際の出口点プログラムは提供しません。該当する情報を見つけるために「FIELDPROC」を検索します。これらの出口点のロジックは極めて複雑で、始める前に C 言語の構造と概念をよく理解しておく必要がある点に注意してください。
FIELDPROC 出口プログラムが実際に複雑であるという点の他に、大きな課題は暗号化キーの管理です。暗号化キーの管理というトピックはこの記事の範囲を越えていますが、概要を知りたい場合は、「Configuring FIELDPROC for Automatic Encryption and Key Management」 (tinyurl.com/8hknpnt) というタイトルで私が作成した無料の 10 分間のビデオを観ることができます。ビデオでは、IBM i で自動暗号化とキー管理を有効にする方法について示しています。
その他に重要な検討事項があります。FIELDPROC プロジェクトを開始する前に、暗号化キー管理に関する順守規制について熟知している必要があります。PCI Security Standards Council Web サイト (pcisecuritystandards.org) には、暗号化およびキー管理に関する多くの情報があり、準拠法に後れを取らないために最適な場所です。
FIELDPROC の制限事項
あらゆる自動暗号化テクノロジーには強みと弱みがあり、FIELDPROC も例外ではありません。FIELDPROC では、データの索引付けに使用する暗号化列に関して最も顕著な制限事項があります。FIELDPROC は Process While Encrypted (暗号化した状態で処理する) モデルを使用しているため、暗号化データのソート順は、期待どおりにはなりません。元データのソート順を保持する暗号化手法はありません。したがって、暗号化列を索引として使用するレポートやディスプレイは、期待通りには動作しません。この制限事項は、あなたにとり大きな障害となるかもしれませんし、多少不便を感じるかもしれません、あるいはまったく影響ないかもしれません。
FIELDPROC に伴って他にもいくつかデータベースや運用面の制限事項がありますが、個人的な意見として、それらは扱いやすいです。暗号化索引の問題が終われば、FIELDPROC で発進準備はできると思います。
7.1 の Open SSH
暗号化ファイル転送を使用して、移動しているデータを暗号化する点に注意を向けましょう。IBM i は、数リリース前に SSL FTP (FTPS) をサポートしました。IBM の無償ライセンス・プログラム機能である OpenSSH アプリケーションの Secure Shell (SSH) 実装もあり、これもしばらくの間世間に出回っていました。
IBM は、 IBM i の新リリースで OpenSSH アプリケーションにアップデートを提供する傾向があります。リリース 7.1 はこのパターンの例外ではありませんでした。7.1 では、バージョン 4.8 の OpenSSH にアクセスし、IBM のテクノロジー・リフレッシュ・プログラムを介して新しい OpenSSH バージョンを期待できます。
SSH は、セキュリティーの矢筒における重要な矢になりつつあります。過去数か月で、金融機関により Secure File Transfer Protocol (SFTP) がますます採用されているのを見てきています。多くの企業が FTPS から SSH SFTP へ移行しています。
SSH は、インターネットまたは内部ネットワーク間を移動するデータを保護する、ファイアウォールに優しくセキュアな暗号化ファイル転送を実装しています。SSH は広く受けいけられている暗号化方式で、KPI ベースの暗号化キーを実装しています。では、課題は何でしょうか。次の 2 つだと思います。
- セキュアなファイル転送の自動化
- 最新のセキュリティー・パッチに遅れずについていく
SSH SFTP 転送の自動化は大きな課題です。SSH は長い間世間に出回っている UNIX 型のアプリケーションで、ユーザー・インターフェースにコマンド行モデルを実装しています。ときどきファイル転送をする場合は、それで満足でしょう。QShell または PASE コマンド行機能を起動し、ファイルを転送できます。しかし、多くの IBM i ショップは毎日、何百または何千というファイルを転送しています。自動化のニーズが深刻な場合、シェル・スクリプト作成が実にうまくなるか、自動化ソリューションに向けてソフトウェア・ベンダーに頼ることになるでしょう。
IBM i の新リリースで、SSH のアップデート版を提供するという IBM の戦略を考えると、(まだ移行していない場合は) できるだけ早く 7.1 に移行することを検討するべきだと思います。最新のセキュリティー・パッチを備えた最新版の OpenSSH を入手できるでしょう。
7.1 ツールで困難にうまく対処する
この記事で、自動暗号化のセキュリティー・アーキテクチャー、IBM による 7.1 への FIELDPROC の実装、移動中のファイルを暗号化する SSH OpenSSH 機能について理解できたことと思います。これらは、今日の IT 社会で前進する際になければならない重要なセキュリティー機能です。一般的な IBM i ショップは、 2 年ごとしか OS のアップグレードをしません。しかし、セキュリティーの展望は急速かつ継続的に変化しています。遅れないようついていくために IBM i 7.1 が提供するツールがない状態にはしないでください。
著者について
Patrick Townsend：Townsend Security (townsendsecurity.com) の会長兼 CEO。同社は、さまざまなプラットフォームおよびオペレーティング・システムを使用している企業顧客に、暗号化およびキー管理ソリューションを提供しています。
patricktownsend@townsendsecurity.com
