メニューボタン
IBMi海外記事2014.04.16

自社のIBM iビジネスをモダン化する パート2:セキュリティー

Trevor Perry 著

自社のビジネスにとってもっとも大切な資産は何ですか? この問いに対する答えはビジネスで扱っている製品によって異なるかもしれません。しかし何がもっとも大切かとは別に、ビジネスが生き残っていけるようにそれを守らなければならないということは誰もが認めるところでしょう。
最近、私はある会社を訪ねました。その会社では敷地内に入る前に権利放棄書に署名させられ顔写真を撮られました。署名した権利放棄書には、私が同社の製品に使用されている原料に対して何らかの有害反応を起こした場合に同社が免責を受けるというものでした。興味深いことに、この権利放棄書には同社の最も重要な機密事項である、同社の製品の中核となる製法を外部に漏らさないようにとの条件はありませんでした。もしこの会社がコカコーラ社だったらと想像してみてください。そして私がコカコーラ社を訪ねている間に同社の製法をなんとか手に入れることができたと想像してみてください。もし同社のソフトドリンクの製法を誰もが知ってしまったとしたら、コーラはどれくらいビジネスにとどまっていられるでしょうか。
「秘伝の製法」をもっている企業ならどこも、その製法をどこかに厳重に保管しているはずです。昔はそれが自社の金庫か貸金庫だったのかもしれません。いまでもそうしている企業があるかもしれませんが、今や秘密の製法を電子的に保管していることのほうが多いでしょう。IT部門は自社のデータの管理者として自社のこうした機密事項を保護し、許可された社員だけがアクセスできるようになっていることを確実にしなければなりません。

セキュリティーをゼロから構築する

もし私がIT部門をゼロから構築するとしたら、最初に考慮するのはあらゆることにアクセスできるのは誰であるべきか、ということです。インフラストラクチャーを基礎から構築するということは、セキュリティーがアーキテクチャの根本であるということを確実にする機会を与えてくれているということです。既存のインフラストラクチャーにセキュリティーを適用するのは船底から水が漏れている船の穴を塞ぐようなものになりかねません。
IBM iの世界の輝かしい過去においては、10文字のパスワードがセキュリティーを保つのに十分な場合がほとんどで、パスワードの共有を誰もためらおうともしませんでした。2013年でさえもこうした状況がはびこっています。たとえば、最近大型ホテル&カジノ施設にチェックインしようとしているとき、スタッフが緑色画面の予約アプリケーションを使用しているのに気づきました。デスク越しに画面の写真を撮りました。もちろん後代のためにです。あとでその写真を見てみると、ユーザー名とパスワードがモニタの上部にテープで貼り付けられているのに気づきました。もしこの施設内のどこかでエミュレータが動くPCを見つけたら、きっと私は(少なくとも)予約システムにアクセスできたことでしょう。この企業は、そして同様の他の多くの企業でも、機密事項を保護するために何か手段を講じなければなりません。
IBM iを使用している企業にとっての課題とは、従来のセキュリティーが長きに渡って十分なものであったということです。しかしインターネットが拡大し、同時にハッカー人口が増大したため、セキュリティー違反が頻発するようになりました。IBM iのアーキテクチャはウィルスを撃退し続けますが、企業の設備、記憶装置、データに対するアクセスは従来のセキュリティー対策では防ぐことはできません。通常どうするかというと、IBM iを使用している企業はセキュリティー・アーキテクチャを後付けで対応するのです。これとて決して簡単なことではありませんが。
さらに功を奏する方法は戦略を適用するというものです。自社に合ったセキュリティー・アーキテクチャを設計するということは白紙状態から始めるのが最適です。この手法を取れば、既存のインフラストラクチャー、アプリケーション、データに対して考えうるあらゆるアクセスを考慮することができ、社員増加、顧客、パートナー、ベンダー、消費者からのアクセス増大などといった自社の成長に貢献することができます。この設計ではどんな点においても妥協を許してはいけません。必ず達成する必要のある目標なのです。
新しいセキュリティー・インフラストラクチャーの初期設計が終わったら、次のステップは既存のセキュリティー・インフラストラクチャーを理解することです。これを理解することで現在使用しているアプリケーションやインフラストラクチャーが新しいセキュリティー・インフラストラクチャーの設計にどう位置づけられるのか、そしてどのような修正が必要なのかを洗い出すのに役立つでしょう。このレビュー過程において新しいセキュリティー・アーキテクチャがさらに洗練された形になります。
このレビューが終わると各アプリケーションのロードマップを構築することができます。このロードマップにより、各アプリケーションが新しいセキュリティー設計の中で最初にどう動作するのかが決まります。それは別のセキュリティーであったり、サインオンのステップであったりするかもしれません。次にこのロードマップは、各アプリケーションを新しいセキュリティー・アーキテクチャに適合させるために修正するのに必要なプロセスの概要をまとめ、セキュリティーの恩恵を活用し、ユーザー・コミュニティにシームレスに見えるようになります。
ITセキュリティー・インフラストラクチャーの詳細に入っていく前に、一番重要なセキュリティーの話題である物理的セキュリティーについて考えてみましょう。

物理的セキュリティー

インターネットにより情報へのアクセスが容易になりましたが、業界に関するニュースの配信も容易になりました。たとえば、銀行のコンピュータ・システムに侵入して海外にある自分たちの口座に送金するプログラムをインストールした強盗団の話は最近のことでした。この事件の場合、ハッカーたちは銀行を訪れて自分たちはIT部門からPCの修理に来たと行員に言ったのです。応対した行員は珍しいことではなかったのでハッカーたちのことを疑問に思うことなどなかったのです。行員が休憩を取るためにデスクを離れたとき、偽IT部門のハッカーたちはその銀行のアプリケーション群に自分たちのソフトウェアをインストールしたのです。
この話からの教訓は、ハッカーの侵入は必ずしも外部からのインターネットの進入に限った話ではないということです。新しいセキュリティー・インフラストラクチャーや改良したセキュリティー・インフラストラクチャーに乗り込む前に、ユーザーが自社のアプリケーションやデータとやり取りできるあらゆるポイントにおいて物理的なアクセスを保護しなければなりません。その保護とは単なるセキュリティー・カードや守衛室、ドアの施錠といったものにとどまりません。自社の機密事項を継続的な努力で意識して保護し、不正なアクセスを感知したら報告するという企業文化になっていなければなりません。
どんな端末もアプリケーションやデータへのアクセス・ポイントであるということを覚えておいてください。ホテルの予約デスクに置いてあるPC。社長のポケットからするりと落ちたスマートフォン。クローゼットの中に置いてあるサーバー。地球上のどこかのクラウド・ホスティング施設の中に設置してあるサーバー、など。クラウドやホスティング・サービスの契約書に署名する時、物理的なセキュリティーやそれに関連する条項への言及があることを確認してください。
今日の分散コンピューティング環境では、我々のセキュリティー・アーキテクチャ上のアプリケーションやデータへのあらゆる物理的な接点を検討しなければなりません。またそれぞれの場所での不正アクセスの回避手段を設計し、不正アクセスが発生した時の回復計画を準備し、そのような不正が事故によるものであれ意図的なものであれ、それを行った人物に対する関連条項あるいは処罰が規定されていることを確認してください。

インフラストラクチャーのセキュリティー

インフラストラクチャーのセキュリティーについては大量の書籍や記事が書かれています。セキュリティーに関する会議や大会は定期的に開催されており、ハッキングやセキュリティー攻撃に関する会議や大会も定期的に開催されています。セキュリティー違反や企業への攻撃の報告は毎日あり、セキュリティーのアルゴリズムが破られ、企業がインターネット上で丸裸にされたというニュースも毎日のように目にします。21世紀において不正なアクセスを防ぐことは、企業が継続的な一連の戦いに臨むという戦争なのです。

既存のシステムのセキュリティー・ホールに継ぎ当てをする
ことでセキュリティーやITの監査に対処するのは、
企業の機密事項を守っているのではなく、一時的に
セキュリティー・ホールを見えなくしているにすぎません。

当たり前のことが3点あります。まずは継続的な努力が必要であるということです。新たな攻撃や侵入方法が開発されているので、防御は常に強化し新しい防御も構築しなければなりません。次に、継続的な努力にはテクノロジーの進化に関する研究と評価が常に必要となります。セキュリティーに関する研究それ自体が専任を必要とする仕事になりかねませんから、中規模から大規模なビジネスではセキュリティーに関する専門知識を買うか借りるか構築する必要があり、小規模な企業でも外部機関の支援やアドバイスを求めなければなりません。そして3つ目は、セキュリティーの話題を網羅するにはモダン化シリーズの一節では不十分であるということです。本稿ではその概要を提供することしかできません。すなわち、調査を始めるためのハイレベルのチェックリストの提供です。自社のセキュリティー要件に合ったセキュリティーの解を見つけるのは皆さん自身の仕事です。
インフラストラクチャーのセキュリティーをいくつかの主要な要素に分解してみましょう。最初は外部世界への接続です。使用しているインターネット・プロバイダは自前のセキュリティーを構築していますか。そのセキュリティー環境はオープンになりすぎていてプロバイダが未然に防ぐことのできる攻撃に対して無防備になっていませんか。たとえば、プロバイダはDOS(サービス拒否) 攻撃が社内ネットワークに到達する前に捕まえることができますか。ランダムな攻撃や略奪の危険に直接さらされていてサーバーやデータに簡単にアクセスできるようになっていませんか。あるいは、外部世界への接続が厳しすぎてビジネス・パートナーや顧客、遠隔地にいる社員への接続ができなくなっていませんか。そのプロバイダが時代遅れのルールに従っているため自社が送るメールが外部世界にとってスパム・メールになっていませんか。そのプロバイダとの契約ではセキュリティー違反が起こった時に法的手段が利用できるようになっていますか。
さて、そのような外部接続に何をつないだでしょうか。どのようなネットワーク機器、ルーター、ファイヤーウォール、サーバーがその外部世界に直接接続されていますか。そうした機器のすべてが最新のOSレベルやパッチレベルになっていますか。ウィルスやトロージャンに侵されたりしていませんか。ウィルスやトロージャンのチェックはどれくらいの頻度で行っていますか。どのポートがオープンになっていますか。各ポートにはどのような出口プログラムが備わっていますか。どのような監視用ソフトウェアおよびハードウェアが、ネットワークや接続されている機器上でのアクティビティのログを記録していますか。監視ログはだれがどれくらいの頻度でレビューしていますか。
サーバーはどうでしょうか。サーバーが何台あり、それらにアクセスできるのは誰ですか。インフラストラクチャー上には仮想サーバーはありますか。もしある場合、作成してアクセスできるのは誰ですか。一貫性のあるユーザー命名規則があり標準的なパスワード構造の規則がありますか。パスワードには有効期限がありますか。
通常のキーボードやマウス以外の手段でサーバーや機器にアクセスできるのは誰ですか。データやプログラムはUSBで投入することができますか。USBを使ってデータやプログラムを環境から取り除くことができますか。社員はインターネットのファイル共有サービスを利用してデータやプログラムを投入したり取り除いたりできますか。
新しく入社した社員がネットワーク、サーバー、およびアプリケーションにアクセスできるようにするためのプロセスはありますか。社員が退職するときのプロセスはありますか。会社のメールにアクセスできるのは誰ですか。そのプロセスは、ベンダー、顧客、パートナー、消費者などといった非社員からのアクセスにも関係していますか。ユーザー・プロフィールには有効期限がありますか。
メールはどのように扱われていますか。スパム・メールやウィルスの進入の他に、メールはユーザーの端末に伝染しますか。社員はスパム・メールやウィルスを侵入させてしまうようなウェブサイトにアクセスできますか。あらゆる端末やウェブのアクティビティを監視して怪しいあるいは危険なアクティビティをレビューしていますか。社員は怪しいメールを開くこと、危険なウェブ・サーフィンをすること、権限を有していない人とセキュリティー情報を共有することなどの危険性に関して注意を払い、また教育を受けていますか。

アプリケーションのセキュリティー

今日のテクノロジー環境下においてアプリケーションに関する最も功を奏しているアーキテクチャは、単一でグローバルなロールに基づいたポータルです。すべてのユーザーが1つの入り口点を使用してアプリケーションにアクセスしなければならないということは、一般的にはセキュリティーが強化され、保守やサポートの作業を削減でき、ログの記録と監視に一貫性が保てるということになります。
もう一つおまけで得られる恩恵としては、1つの入り口点からのアクセスしか許さないということは、企業内のすべてのアプリケーションに対して一貫性のあるラッパーあるいは出口点を提供できるということです。ユーザーは、自分たちがすべてのアプリケーションにアクセスするためのポータルが最新でモダン化されているというだけで、自分たちが使用しているアプリケーション群全体がモダン化されていると考えがちです。こうすることで、一時的ではありますが、アプリケーションに表面上の改良を加えて欲しいという要求のプレッシャーから逃れることができます。
このようなポータルを設計して構築することは簡単なことではなく、優先度付け、継続的な調査、詳細な注意が必要となります。ポータルのアーキテクチャの設計にはセキュリティーの専門家たちに入ってもらうべきです。ポータルは徹底的なストレステストを実施しなければなりません。そしてもし可能であればセキュリティーのコンサルタントにも入ってもらってどんな手段でもかまわないからセキュリティーを破ろうと試みるよう依頼すべきです。 (当たり前のことですが、設計段階とテスト段階で同じ専門家を雇わないことが重要です。)
ここで提案したアプローチと同じくらい徹底したアプリケーションのセキュリティー・インフラストラクチャーによる恩恵に気がつかない企業が多いようです。しかし、いったんセキュリティーが破られたりハッカーにデータを奪われてしまったりすると企業にとっては致命的ですから、きちんと設計されきちんと運用されるようなセキュリティー・インフラストラクチャーに投資することは報われるはずです。事が起こってから水漏れを塞いで損害を修復するために必要なコストはこのような投資よりもはるかに高く、会社にとって壊滅的にもなりえます。
セキュリティーに対して別のアプローチを取ろうとしているのであれば、考慮点や自分で解答を見つけなければならない質問がモダン化シリーズの私の記事に書かれています。もちろん、今日ITアプリケーションを使用しているあらゆる企業はセキュリティーに積極的に取り組むべきです。既存のシステムに対してもぐら叩き的にセキュリティーやIT監査に対応することでは、企業の機密事項を一時的に隠すことはできても保護することはできません。

アナリティクス

さて自社のセキュリティー・インフラストラクチャーのために考慮すべき重要なポイントについて考える準備ができました。これらのポイントはいずれも重要で順番は関係なく、同じレベルの優先度で考える必要があります。
ポータルを介したすべてのアクティビティのログを記録する必要があり、すべてのアプリケーションに対するすべてのアクセスを記録しておく必要があります。すべてのジョブ、セッション、アクティビティの日付、時刻、時間も記録しておかなければなりません。IBM iアプリケーションのトランザクションに関する情報自体はジャーナルやレシーバーなどで記録することができます。その他のアプリケーションについては組み込みのログ機能が提供されていない場合、トランザクションやアクティビティのログ記録機能を構築する必要があります。すべてのアプリケーションのすべてのトランザクションにおいてあらゆる詳細を記録する必要はありません。これはトランザクション・データベース自体の一部機能かもしれません。ただし、タイムスタンプやユーザーなどといった重要な情報は記録しておかなければなりません。
理想的には、こうした情報はインテリジェントな知識ベースに収集して、記録されたデータから異常なアクティビティがないかを自動的にレビューする分析プロセスを実行すべきです。もしそのようなプロセスがないのであれば、矛盾やアプリケーションへの不正なアクセス、不正なアプリケーションの使用がないか定期的にデータをレビューすべきです。ここではパターンが鍵となります。そして監査情報がないとかアクセス失敗が繰り返されているとか、異常なアプリケーションへのアクセス(通常のアクティビティ以上および以下の両方)があるとか、サイン・インしたユーザーと監査記録との間にレベルの矛盾があるとか、1つのポイントから複数のアクセスがある、などといったことがないか調べる必要があります。
どんな方法でもよいですが、セキュリティー分析データの収集、照合、分類、レビューはIT作業の鍵を握ります。こうした作業の責任がごく少数のユーザーの手に委ねられているのであればそれ自体が障害の発生ポイントになりかねないので、できるだけ人手を介さず自動化したほうが良いでしょう。

ロール

モダン化されたアプリケーションは個別の作業ステップに対するアクセスによって促進されます。通常、個々のユーザーが実行できるこのステップは企業内でのロールに関連付けられています。一人のユーザーが複数のロールにアクセスできる場合もあり、ユーザーが実行する権限を持つロールは時折変わることもあります。ロール・ベースのアーキテクチャに基づいて設計されたアプリケーションにアクセスするためのポータルは、セキュリティー違反の予防やユーザーの効率向上に役立つのです。
ロール・ベースのアプリケーション・システムを設計する際は、考えられるあらゆるユーザー・ロールを考慮しなければなりません。自社のウェブサイトにアクセスする消費者にはセキュリティーが必要ないかもしれません。自分のアカウントだけに関連する情報にアクセスする消費者には強固なセキュリティーが必要となるでしょう。上級経営幹部にはレベルの高い重要な会社情報の要約にアクセスさせる必要がありますが、すべての請求書の詳細にアクセスさせる必要はないでしょう。セキュリティー管理ロールの強固なコントロールを維持し、アプリケーションやインフラストラクチャーを使用するセキュリティー担当者に対して統制のとれた監視およびレビュープロセスを遂行することが重要です。

自社の機密事項を継続的な努力で意識して保護し、
不正なアクセスを感知したら報告するという
企業文化になっていなければなりません。

ロール・ベースのアーキテクチャの中には、アプリケーションや機能レベルでの詳細アクセスだけでなくアプリケーション機能内のタスクへのアクセスを含むものもあります。たとえば、あるユーザーが情報へ問い合わせできるアクセス権があり、別のユーザーがその情報を修正することができるロールに属し、さらに別のユーザーがアプリケーションの情報を削除するアクセス権限を持っているかもしれません。

裏口

セキュリティーの設計は不正なアクセスや裏口からの侵入を許すようなものであってはなりません。ロール・ベースのシステムでは、必要に応じてアクセスを認めるシステムによりレベルの高いセキュリティーを実現することができ、ユーザーのロールの変更が記録され、ユーザーのすべてのアクティビティはログに記録されます。追加のQSECOFRやアドミニストレータ、root権限を持っているプログラムは、安全なアクセスを取得する必要はありません。

包括的なセキュリティー

本稿はITセキュリティーの詳細を網羅するものではありません。それには1冊の本が必要となります。取るに足りないように見えるその他の考慮点やユーザー登録、アクティビティのタイムアウト、ロール・ベースのアプリケーションへのアクセスに対する例外などたくさんのトピックについても触れなければなりません。必要とされる注意点を過小評価してはいけませんし、ITセキュリティーの設計で近道をしてはいけません。専門家にアドバイスを求めてください。

政府の規制

ITセキュリティーのアーキテクチャはすべて法律を意識したものでなくてはなりません。ヨーロッパでは、クラウド上のデータは自国内のみでホスティングしなければならないという国がいくつかあります。米国では、機密データの暗号化に関する規制が多数あります。米国では「個人および機密データ」に関する連邦法案を成立させようという動きが何件かあり、それらはデータの安全性やセキュリティー違反から派生する問題についての規則が盛り込まれています。連邦政府は最近の国会会期ではこれらの法律を成立させることはできませんでしたが、最終的には成立するものと見られています。一方、州独自の「個人および機密データ」法案を成立させた州政府がいくつかあり、それらの州では自社のアプリケーション内のデータをどのように格納し、安全性を保ち、そしてアクセスを提供するのかに影響を与えるものもあるようです。
こうした法律を調査し、自社に当てはまるものはどれかを見極め、自社のセキュリティー・インフラストラクチャーにその法律をどう反映させるのかは皆さん自身の責任になります。また自社のセキュリティー・アーキテクチャは、自社に影響のある新しい法律が制定されたときにアーキテクチャをすばやく修正できるものでなくてはなりません。州境や国境をまたがって運用しているのであれば、こうしたタスクはより広範なものになりそしてより多くの注意が必要になります。

早めの計画

エレガントなセキュリティー・インフラストラクチャーとは進化するように設計されています。テクノロジーの進歩に伴い、そしてセキュリティーの回避や違反が明らかになるにつれて、火曜日に配布される通常のWindowsの修正パックでは社内外からの違反を防ぐのに十分ではないかもしれません。それ以上に調査が必要で、定期的かつ継続的なアーキテクチャのレビューをスケジュールしておかなければなりません。セキュリティー・インフラストラクチャーで使用されるテクノロジーはすぐに使い物にならないものになってしまうかもしれず、ソフトウェアの修正版が利用可能でなければソフトウェアそのものを交換しなければならないかもしれません。セキュリティー・ホールを見つけたらすぐに修正しなければなりません。そして以後に影響がないように正しい手順を踏まないといけません。
エレガントなセキュリティー・インフラストラクチャーはまたセキュリティー違反に備えた計画を持っています。企業はセキュリティー違反が発生したときに何をしなければならないのかを意識していなければなりません。しかも修正あるいは予防の観点からだけでなく、事後の対処の観点からもです。企業のデータが喪失して競合他社に使用されたら、法的手段が利用できるかもしれません。個人あるいは機密データを喪失した場合はそれを公表しなければならないでしょうし、それによって損害をこうむる可能性のある人が自社に対して法的手段をとるかもしれません。
本稿は独自のITセキュリティー・アーキテクチャを構築するのに必要なありとあらゆる情報を網羅することはできませんが、本シリーズで最も重要なトピックです。モダン化により自社の情報がより多くの端末、ユーザーに提供され、セキュリティー攻撃が増加します。しっかりとした準備をしてください。

あわせて読みたい記事

PAGE TOP