アーキテクトは財政破綻と市場危機を止めることができるか

Société Générale（フランスの大手銀行）がJerome Kervielという人物の不正(source)により49億ユーロ（72億ドル）の損害を被ったらしいというニュースは、高い評価を持つ金融機関でのシステムにさえも穴があるということで世界中に議論を巻き起こした。

金融機関や他の金融ビジネス企業というのは財務リスク軽減や正確な会計報告を行うためにMiFID（EUの投資ビジネスに関する法）(source)やSOX（アメリカの企業財務報告に関する法）(source)といった法や規律を遵守しなければならない。企業は不正や盗みによって利益やビジネス機会を失わないようリスクマネジメントに対する社内の意識付けも行わないといけない。そのため企業はリスクを軽減する内部統制のための社会的技法や工学的技術に莫大な投資を行っている。

Bruce Schneier氏（セキュリティに関するブログで有名）であればすぐにでもこう指摘するだろう。不正防止強度は技術でなく人によって決まる、と。警察の調書によるとJerome Kerviel容疑者は自分の行う取引は高収益なのでSociété Généraleは見て見ぬふりをしていた、と主張しているという。もしこれが本当ならばこの点に関してソフトウェアシステムができることは何もない。 Kerviel容疑者の調査は社会的な問題と技術的な問題の間にある興味深い関係を物語ってくれる。

CISSP（アメリカの情報セキュリティ資格）保持者で、ある州政府の大きな機関でITセキュリティ管理を務めているJim Sheehy氏に話を聞いた。

金融機関でこれまで用いられてきた旧来の非技術的なコントロール方法を軽視してはいけません。たとえば責務の切り分け、従業員に休暇を取らせること、二重コントロールシステムなどです。

リスクマネジメントソフトウェアには誰かがワークステーションにログオンしたことや休日なのに誰かがログインしたことを検知するといった特殊な行動をトラッキングできるものもある。このようなソフトウェアであれば、Kerviel容疑者が行ったとされる他人のアカウントでのログオンを検知したり4日間しか 2007年に休暇を取ってないことを警告したりすることもできただろう。他にeメールを検索したりキーボード入力を監視して(source)怪しいキーワードやイレギュラーながないかを探知するシステムもある。Kerviel容疑者は取引リスク回避のための社内調査に対処するため架空の注文メールを大量に作っていたという。 

もちろんたった数通の偽造メールで50億ユーロが消えてしまうわけではない。すべからく金融機関には明細内容を他のソースで確認する照合手続きがある。 Robert Annett氏はオンラインストアを開発するなら支払のあった件数と発送件数が同じであるかの確認もするべきだと指摘している(source)。

Kerviel 容疑者はデータベースへのアクセス権を手に入れて自分の取引をカバーするよう値の変更をおこなうことで社内の照合チェックを逃れていたという。しかし取引システムにはデータベースの内容を監視するアプリケーションやデータベース機能が必ずある。Kerviel容疑者が手に入れた権限がデータベースの管理者権限でないかぎり、彼の不審な行動はログに残るはずだ。森の中で木が倒れた音は誰にも聞こえなかったのだろうか。 

Sheehy氏はこう述べる。

システムのあらゆるレベル（OS、データベース、アプリケーション）での監視は必要なことですが、それは必要な最低限のことでしかありません。その監視データを誰かあるいは何かが適当な形にまとめることも必要になるのですが、これがほとんどの組織で失敗していることなのです。OracleのFine- Grained Auditのログはいまいちで、OSのログもそれ以上ではありませんし、イベント相関システムはばらばらのデータから監査データとして関係付けたり分析をしようとしたりしますが、結局は他の何よりも誤判定を行ってしまうことになります。これは厄介な問題なのです。

確かにリスクマネジメントビジネスは活気がある。世の中にはBPS(サイト・英語)、 Memento(サイト・英語)、Actimize(サイト・英語)など多くの包括的なシステムがあり、SaS(source)やReuters(source)も提供を行っている。だがまだかなり未熟だ。

これは問題の一部分でしかない。企業が不正検知システムをインストールしても自己満足に終わるだろう(source)。不正検知システムは英ベアリングス銀行の破綻（8億 2700万ユーロ（14億ドル）の不正取引により1995年に破綻）後の10年で精巧になった。しかし一部の人は、ヨーロッパの金融業界の人々は自動処理を信頼しすぎではないだろうかと言う。システムが人の手を離れてセキュリティを行うことがないようにするのは重要なことである。”道徳的な”コンサルタントのほとんどは全ての企業には誰かが盗みを行える方法がある(source)ことに賛同してくれるだろう。システムやアプリケーションのセキュリティを評価しながら絶えず用心深くクリエイティブでいることが重要なのである。.

不正を検知し防止するにはソフトウェアアーキテクト（設計者）は何ができるだろうか？  

Sheely氏はこうコメントする。

私の意見では、ソフトウェアアーキテクトができることで一番重要なのはアプリケーションの業務上の役割を注意深く考え、それをロールベースのアクセスコントロールシステムへ厳密に落とし込むとです。ファイアウォールや第7層（アプリケーション層）でのフィルタリング、不正侵入検知などの技術的防壁に頼るだけでは十分でありません。開発者はアプリケーションロジックのライフサイクルの始めからセキュリティを確保するように実装しないといけません。

悩ましいことに問題はさらに難しくなっていっている。ソフトウェアはより複雑に、より疎結合になっていっている。Annett氏はSOAの隆盛によりシステムへのエントリポイントが増加したことはセキュリティリスクになっているとも指摘している。またSOAにおけるリソース分散が包括的なセキュリティ構想を実装することをさらに難しくもしている。

アーキテクトが組織内のセキュリティを改善するためにできる他の方法をあげよう。

• 初期からアーキテクチャにセキュリティを盛り込む。後付けしたセキュリティは悲しいほど無力だ。 
• しかるべき監視および照合システムがきちんと配置され、テストも行われるようにする。
• 異常性を検知するためにイベント相関システムを独自に作るなら、Esper(source)のようなオープンソースツールが役に立つだろう。 
• 指紋読取器のような強固な認証機器を提案し導入する。
• システムやアプリケーションのパスワードが定期的に変更されるようにする。パスワードが変更されたら障害復旧システムも同期することを確認する。
• システムテストには不正目的のテストも含める。
• システムへのエントリポイントは全て安全対策をおこなう。
• 以下のものを利用する。:
  • 定本Security Engineering: A Guide to Building Dependable Distributed Systems(so urce)
    
  • COSO(サイト・英語)やRIMS(サイト・英語)のようなエンタープライズリスクマネジメント業界におけるフレームワーク 
  • ITIL（The Information Technology Infrastructure Library）(source)
• 一人でやってはいけないこと。 
  
  • セキュリティ評価を行うのに道徳的な人を採用する。
  • サードパーティ製のリスクマネジメントシステムや不正検知システムの購入を考えたり、自分たちのアプリケーションにとって一番いい導入方法を考えること。

一人のアーキテクトだけでは数十億ドルもの不正を阻止することはできないだろう。しかし何人かのアーキテクトであれば企業の利益、名声そして品格を保つ助けになるだろう。

原文はこちらです：http://www.infoq.com/news/2008/02/architects-stop-market-meltdowns