2005年11月

2005年11月22日

可用性とセキュリティ(2)

 名証の記事のタイトルを「可用性とセキュリティ」としたが、少しばかり羊頭狗肉気味だったので、少し"Blueprints for High Availability"という本の中でセキュリティに触れている箇所を紹介したい。

 高可用性設計原理の#17が「セキュリティの強化」になっている。内容は以下のようなもので、詳細はこの場では省略するが、それほど目新しいものではない。
 可用性というものは結局つまらないように思える小さな注意の積み重ねで達成されるものなのだ。

  • 不必要なユーザーのアカウントは削除する。

  • 特権ユーザーを制限する。また、ログを取る。

  • ファイアウォールを使う

  • 適切なパスワードを選ぶ

  • デフォルトのパスワードは使わない

  • 基本的なセキュリティーについてユーザーを教育する

  • 退職した従業員のアカウント/ファイルを削除する

  • ウィルスチェックソフトを使う

  • www.cert.orgのようなウェブをチェックする


 11章では、さらに

  • データの暗号化

  • パスワードの覚えやすく破られにくい選択方法

  • パスワードの保護

  • 監査機能の使用

  • パスワードの預託


 を上げ、ディザスター・リカバリー計画の文書のセキュリティーや、アクセス性とセキュリティーのバランスについて言及している。

 ウィルスやワームは、業務継続に対する脅威としては自然災害に匹敵する。むしろ、大きな地震のように何十年・何百年に1度しか襲ってこない自然災害よりも、セキュリティが甘かったらほぼ確実に被害を受けるという点で、脅威として大きいのではないだろうか。

2005年11月21日

技術者スキルとしての高可用性

 こんなサイトが目に付いた。

■情報サービス業界の各職種×レベルに求められる経験/スキル

 この中で、技術者に必要なスキルの一つとして『高可用性』を上げている。
 世間的にだいぶ認知されるようになって、企業ニーズもあるということでしょう。

 ただ、カテゴリーが「複雑性」の所になっているのは、いかがなものでしょうか?
 しごく単純なもののような気もするのですが。

 もっとも、低可用なシステムに比べれば、クラスターにしたり冗長化したりして、相対的に複雑なことは確かですが。

2005年11月20日

ITpro:名証システム障害、原因は外注先オペレータの“操作ミス”(ヨミウリの記事はガセでした)

 先日の名証のトラブルの原因は、どうも単純なパスワード入力ミスとかじゃないみたいだ。(ヨミウリの記事はガセでした)

 詳しくはITproの記事参照。

ITpro:名証システム障害、原因は外注先オペレータの“操作ミス”

 キャンセルって、CTL-Cですかね?
 Oracleって、コマンドが中断されてもロールバックしてくれないの?
 Oracle始め、今どきのミドルウェアはパラメータ設定ミスとかあっても、ほとんどノーチェックで突っ走りますからね。しかも、原因が容易に特定できるようなエラーメッセージは絶対に出力しないし。

 運用する側にも問題があったみたいだけど、もっと人に優しいソフトにしてくれないと、ヒューマン・エラーはなくなりません。(これをヒューマン・エラーと言うのなら。ですけど)

2005年11月19日

可用性とセキュリティ

 名古屋証券取引所で11/4にシステムが起動できなかった件も、人為ミスが原因のようだ。

富士通がまた原因、陳謝

 名古屋証券取引所で4日午前の取引を停止させたシステム障害は、システム管理を委託されている富士通の関連会社社員が前々日にシステムの終了処理をした際、パスワードの入力を誤ったことが原因とわかった。(YOMIURI ONLINE)

 セキュリティも、やりすぎは考え物ということか?
 いや、人間が誰しもがミスを犯すものと考え、あらゆる自体が起こり得ると想定していれば、こんなことにはならなかっただろう。

 パスワードを変えた後の変更手順はどうなっていたか?
 次回にシステムを立ち上げる人が立ち会わなくて良かったのか?
 パスワードが分からなくて起動できない場合の対処方法は考えてあったのか?

教訓:何も仮定するな

2005年11月16日

高可用性と単一故障点をめぐる実例(その2)

 引き続き、高可用性と単一故障点をめぐる話題。

 あるユーザでは、停電に備えて二つの電力会社から電力を引いていた。
(これは、電力が自由化されているアメリカではよくある対策みたいだ。日本でもできる?)
 ただ、電線は建物の直前にある1本の同じ電柱を共用し、建物に引き込まれていた。理論上は、その電柱は単一故障点に相当するが、誰も気にはしなかった。
 ある日、そのまさかが起きてしまった。
 建物の近くの道路で交通事故が起り、衝突した車が「その」電柱をなぎ倒したのだ。

 あるユーザでは、停電に備えて*最新式のガスタービン発電機を屋上に備え付けていた。ある日、停電が起きたので管理者たちは屋上までせっせと階段を上って行った。(停電なので当然エレベーターは使えない)
 そして、いざ発電機を動かそうとした時、ある重大なことに気が付いた。
 なんと、ガスタービン発電機用のジェット燃料を誰も買っていなかったのだ。
 この話の教訓は、「何も仮定するな。すべてをテストしろ」でもある。実際にテストし、訓練していたなら、燃料がないことにすぐ気が付いただろう。

*)なぜか、この種の実例には停電・電力がらみの話題が多い。コンピュータ関連機器を除けば一番起りやすいからだろうか?
 恥ずかしながら、私のいる部門のメールサーバーの電源も、つい最近まで二重化されていなかった。何千人かの従業員が利用しているサーバーであるにも関わらずだ。
 あなたの会社は大丈夫ですか?

2005年11月12日

冗長化の一つの方法

 東証のニュースについて、同じソフトを二重化するだけではなく、異なったソフトを用意する方法について触れた。
 この「多様化」が可用性を高める上では有効だ。

 こちらの記事(米人気サイトでアクセス障害」,その真相は?)を読んで頂きたいが、DNSの階層のもっともトップにあるルート・サーバが世界には13台あるそうだが、どのように冗長化されているかの一端が知れて興味深い。続きを読む

2005年11月10日

「ソフトは二重化できない」?????

「ソフトは二重化できない」――東証の取引停止、原因はプログラムミス

 東証のシステムは、ハードを二重化してバックアップ体制を整えているが、ソフトは富士通に委託して構築した独自仕様品。「ソフトのバックアップを整えることは、現実的には不可能」(天野富夫常務取締役)。今後はテスト態勢を見直し、チェックを厳重にするなどして障害を防ぐとした。

 「ソフトは二重化できない」と言っているのが何を言おうとしているのか良く分かりませんね。何か誤解を招く表現だし。
続きを読む

意外なところにあったNTT Comの「単一故障点」

意外なところにあったNTT Comの「単一の障害点」

NTTコミュニケーションズのネットワーク障害は、分電盤の故障が原因。電源系統については十分な冗長化を図っていたが、障害が起きたのはそれ以外の部分だった。

 大分前の話ですが、こんな話もありました。
 単一故障点を無くすのがいかに難しいかの実例です。
(もっとも、この例はそれほど難しくないような気もしますが・・・)

SPOF(Single Point Of Failure)−単一故障点4

 SPOF=Single Point Of Failureは日本語で何と言ったらいいだろう?
 「単一故障」では故障のことを言っているようだし「Point」であることが分からない。自分は「単一故障点」と訳しているのだが、どうでしょうか?

 さて、システムの可用性を高める上で、最も重要で最も分かりやすい一つが、「単一故障点を無くす」ということだ。つまり、あらゆるハード、あらゆるソフトを二重化・冗長化して、一つが故障しても業務が継続できるようにしなければならない。
続きを読む

Tales from the Field5

 Blueprints for High Availabilityという本には、Tales from the Fieldという囲み記事がたくさん載っている。経験豊富な二人の著者が実際に経験したり、見聞きした話だが、ためになる話、面白い話が多いのでいくつか紹介していくことにします。
 記事のカテゴリーが「Tales from the Field」となっているのがそうです。

2005年11月04日

ディザスター・リカバリー以前

 今週は立て続けに社会システムがダウンしました。
 詳細はまだ明らかになっていないものの、テスト不足やら運用方法の問題など基本的なところができていないとしか思えません。
 これでは、DRどころの話じゃないですね。まずは可用性というものを勉強し直した方がいいのでは?

名証でもシステム障害、午前の取引中止

 名古屋証券取引所で11月4日、相場報道システムに障害が発生し、午前の市場取引が中止された。障害の原因は不明だが、その後システムは復旧し、午後の取引は通常通り12時30分から行われる予定。

東証、システム障害で株売買停止

 東京証券取引所で11月1日、システム障害が発生し、午前9時から株式の全銘柄、転換社債型新株予約権付き社債全銘柄、交換社債全銘柄の立会取引を一時停止している。復旧のめどは立っていない。