全日空のシステム障害は「有効期限切れ」が原因 53
そこかっ！ 部門より
あるAnonymous Coward 曰く、
朝日新聞の記事によると、14日に全日空の全国各地の空港カウンターにある端末が一斉ダウンし、多くの欠航や遅れが生じた問題で、原因はシステムの一部機能の「有効期限切れ」と分かったそうだ。欠航で宿泊を余儀なくされた客らへの費用負担は、約2億円になるとのこと。同社は社長ら役員10人の1カ月の報酬を、10～50%減額する処分とした。
ANAによると、問題があったのは同社の「データセンター」(東京都)にある「端末認証管理サーバー」で、全国51空港にある1556台の端末などを管理しているが、このサーバーのデータを暗号化する機能の有効期限が、市販時の初期設定のまま「3年」(2008年9月14日午前1時44分まで有効)と設定されていたため、14日未明からシステムが動かなくなったのだそうだ。サーバーの導入は2005年で、当時の搭乗システムではデータを暗号化する機能を使っていなかったため、有効期限の設定は市販時のまま放置された。昨年9月に空港での搭乗手続きを簡素化する新システムが導入された際、個人情報を保護するためデータを暗号化するサーバー機能を使うことになったが、その際、あと1年に迫っていた有効期限についてサーバー管理者からの明確な引き継ぎはなく、チェックし損ねたという。
更に昨年5月に大規模な同様のシステム障害を起こし、コンサルタント会社から複数のシステムの組み合わせや更新により様々な問題が起きることが指摘されていたが、対策として生かせなかった。ANAのIT推進室長は「きわめて初歩的なミス」と謝罪。今月中に運航システムを含む全システムについて有効期限などの問題がないか総点検するそうだ。
本件について、全日空からプレスリリースが発表されています。
システムの問題もあるだろうが (スコア:1, すばらしい洞察)
トラブルは必ず起こる物なんだが、その為の準備なんぞはコストダウンの狭間に消えてしまっているみたいだし、
社員の行動としても「早く直さないと」ってのは感じられたのだけど、「手間がかかってもお客様への対応をする」って点は余り見られなかった。
Re:システムの問題もあるだろうが (スコア:3, おもしろおかしい)
予定表アラームで解決するのでは (スコア:1)
Re:予定表アラームで解決するのでは (スコア:4, 参考になる)
http://itpro.nikkeibp.co.jp/article/NEWS/20080918/315052/ [nikkeibp.co.jp]
どうやら、認証切れが発生することは「共通認識」だったものの
(共通認識だったがゆえにかもしれませんが)
「データセンタ担当者がやるだろう」と思いこんでしまっていたとのこと。
このような思い込みが原因であれば、アラームメールが飛んできたとしても
放置してしまうかもしれません。
いずれにせよ、「明らかと思っても確認はしておけ」という話なのでしょうね。
-----引用ここから---------------------------------
有効期限切れを2回防げるチャンスがあった」（佐藤室長）。
2度のチャンスの1回目は、2005年のサーバー導入時である。
当時から有効期限の設定を初期設定から100年後など影響が及ぼさないように
変えておくべきだったと話す。
有効期限切れを防げたかもしれない2回目のチャンスは、
暗号化認証機能ソフトを新たに導入した業務端末の認証用に使い始めた2007年9月。
データセンターで認証サーバーを管理する担当者と、端末を設計する担当者は、
実は、有効期限が残り1年間しかない暗証キーを使うことを認識していたという。
両者の打ち合わせの中で書類で有効期限の情報は共有していたという。
「（端末の開発担当者は）データセンターの担当者が更新するだろうと
思い込んでいたようだ。
-----引用ここまで---------------------------------
Re:予定表アラームで解決するのでは (スコア:4, すばらしい洞察)
これは「担当者のミス」とか「担当者の確認ミス」ではないと思います。
どういうもの上に自分達が提供するサービスが成り立ったいるか理解出来てない、管理できてない。
マネージメントのミスと思いました。
Re: (スコア:0)
有効期限の意味わかってる？100年後って？
Re:予定表アラームで解決するのでは (スコア:2, すばらしい洞察)
証明書無しで復旧させたんだろ。
Re:予定表アラームで解決するのでは (スコア:1)
当日の報道では、とかいわれてたんで、端末の時計を戻した(上で修正されないよう日付確認停止した)ら、そのときはなんだかわからないままだけどとにかく動いた、だとおもったんですが、日付があってない場合は証明書無しで動作する、ってこと?
どっちにしろ証明書の存在意義が(もともとよくわかってないのですが)よくわからないや。
当日の発表がでたらめだったんかな。
Re: (スコア:0)
なぜ３年後だったのか？ (スコア:0)
セキュリティ管理の問題で定期的に変更する必要があるようなものなら，初期設定は１ヶ月後とか少なくとも
１年以内ぐらいが適当なところだろう．（もちろんアラームのような機能はつけておいて）
そんな初期値設定がトラブルの種になる可能性があるのなら，初期値は無期限とか255年後ぐらいの設定に
しておいて，ユーザーが必要に応じて再設定出来るようにするものではないのかなあ？
Re:なぜ３年後だったのか？ (スコア:1)
これがSSLサーバ証明書のことだとして、なおかつ正規のルート証明機関に署名された証明書だとして、
単に最長の契約が3年だった、というオチだったりしないかな。
2005年あたりだと大手のVeriSignとかBartimore(後のBeTrusted、今のCyberTrust)は最長3年だったような記憶がある。
thawteとかあたりは5年ものもやってたと思うけど。
3年もたつと担当者の入れ替えがあったり、逆にSSL証明書ベンダー側の申請システムの変更があったりするから、
長期契約で料金割引を受けるのではなく、あえて毎年更新の1年契約にしておいて定期的にノウハウの更新を行う
というのもありではないかと思うのだ。
Re:なぜ３年後だったのか？ (スコア:1, 興味深い)
こんばんわ。 MPKI管理者のわたしが通りますよ。（笑
気づくタイミングなら、2度ではなく、有効期限切れの60日前から2回以上、管理者のメールアドレスに
カウントダウンであと何日ですとしつこく連絡がありますね。 宛先メアドが消えてしまってたら、報
道のタイミングは2度あったってことにしかならないんでしょうね。
有効期限が切れてはじめて認証システムが期待通りに動作していたことが実証されたとも思いますので
これで期限切れでも認証できてたとかだと表沙汰にはならないでしょうが、システム構築は信頼できる
ものだったということになりはしないでしょうか。
今回のケースで、MPKI管理者はヘマでもやらかすと or 悪意でも持ったヒにゃ、社長、役員の給料まで
減給できる権限があるに等しいのかとビビりましたので、機会をみて辞任を申し出たほうがいいのかと
感じはじめましたよ。 軽々、引き受けるもんじゃありませんね。 軽々、頼むものでもないと自覚し
た人が沸いて出てきて欲しいものですね。
Re: (スコア:0)
>セキュリティ管理の問題で定期的に変更する必要があるようなものなら
パスワードとは違って、
実用的な暗号解読に要する期間 ＜＜ 暗号の有効期限
でないの？
パスワードの場合は打ち込んでいるところを見られたり、キーロガーで
盗まれるとかの可能性があるので、重要なパスワードは１ヶ月とか３ヶ月の
短期間で変更するのが推奨されるだけ。
>そんな初期値設定がトラブルの種になる可能性があるのなら，初期値は無期限とか
>2
Re: (スコア:0)
こんな人を室長にしててANAは大丈夫なのかい？
Re: (スコア:0)
＞「（端末の開発担当者は）データセンターの担当者が更新するだろうと
＞思い込んでいたようだ。
なんというか、ローマの空港並みの失態ですね。
1999年10月、レオナルド・ダ・ヴィンチ国際空港で、ジェット燃料の備蓄が
枯渇するという大珍事が起きた。空港で燃料を補給する予定だった旅客機は
軒並み足止めを食らい、空港と周辺空域は混乱に陥った。
原因は、それまで備蓄燃料を管理する部門が存在しなかったから。
それまではあちこちの部門の人間が気がついたときに燃料を発注していた
のだが、このときに限って「まぁ、危なくなったら誰かがやるだろう」
「二重発注になったら困るし‥」でみんな最後まで発注しなかったのだ。
しかし責任部門がないのにもかかわらず、20世紀末になるまで問題を発生
させなかったイタリア人の空気読み力に関心すべきなのかも‥
Re:予定表アラームで解決するのでは (スコア:2, 興味深い)
Re:予定表アラームで解決するのでは (スコア:2, 参考になる)
ウェブ系システムのサーバ証明書、ウィルス対策ソフトの契約更新、
サーバやネットワーク機器のサポート契約、ＤＢ上のカレンダーマスタデータの追加、などなど
いずれのケースも、開発チームが開発の過程で購入や契約を手配した後、
運用中に更新が必要となるモノや契約を、過不足なく保守・運用チームに引き継げていないのが原因でした。
簡単なことのようですが、各チームが別会社であったり、契約者がクライアントであったりすることも多く、
なかなか一筋縄ではいきません。
この手のトラブルを防止する上で最も難しいのは、
更新しなければならないモノや契約を洗い出して把握することと、
その更新業務の責任者を明確にすることではないでしょうか。
把握していたのに更新を忘れたのであれば、それはマヌケすぎて救いようがありませんが…。
Re:予定表アラームで解決するのでは (スコア:1)
システム上のさまざまな更新期限より「担当者の更新期限」のほうが絶対に短いと踏んでるんでしょうね…
ちょっとまて (スコア:0)
Re:ちょっとまて (スコア:2, 興味深い)
しかし認証の期限切れ、恐らく証明書の期限切れだと思いますが怖いですね。
なまじ最初に1年だけ動くなどというものが添付されているので同じ障害が多発しています。
SIベンダの某社ではあまりの多発に耐えかね全ての過去のプロジェクトにおいて証明書の利用とその期限を洗い出したほどです。
Re:ちょっとまて (スコア:1)
より厳密に処理するのであれば、認証サーバーのラインセンスは期限の切られた「資産」とみなし、きちんと台帳管理した方がいいでしょうね。会計法まわりがそれを許してくれるかどうかちょっとすぐには分からないですが、できれば有効期間で償却する資産にしたいところですよね……
-- Where your reading book is, there will your heart be also 天戸 司郎 (Silo Amato)
Re: (スコア:0)
はじめからまとめておかなかったの?
Re: (スコア:0)
下請けの実力です
#どこなの？
Re:ちょっとまて (スコア:1)
とりあえずここ [asp-kk.co.jp]かな？
----------------------------------------
You can't always get what you want...
Re: (スコア:0)
Re: (スコア:0)
ウチも引き継ぎや規模がどんどん大きくなってて
何時把握漏れの問題が発生するか・・
「きわめて初歩的なミス」 (スコア:0)
大規模なシステムの全てを維持管理するのは難しい問題だと思うけど
Re:「きわめて初歩的なミス」 (スコア:2, すばらしい洞察)
辞書を編纂するのは大変だし高度なことだけど、
「スペルミス」のような「極めて初歩的なミス」は
初歩的であるが故に根絶は難しい。
Re: (スコア:0)
認識されていた問題点を放っておくと結果は甚大になるというのは。
それは単なる運用上の問題であって技術的なものではないし
防ごうと思えば容易に防げたものだ。
#知らないことが原因ではなく、気付いていたことなのだから。
Re:「きわめて初歩的なミス」 (スコア:1, すばらしい洞察)
いや、それが運用管理責任者に「現状存在する問題」として伝達されていれば防げたものだと思うのだが。
現場担当者が触った時のみ認識しているなんてのは、運用上は「認識して居る」とは言わない。
結局は上下間で情報の共有が為されていないで良しとする体制自体の問題だよ。
だからあれほど (スコア:0)
# そして起こる情報漏洩
ごときというけど (スコア:1, おもしろおかしい)
機嫌が悪いとキレてアクセス拒否する生物もいることだし・・・
# ほにゃらら心と秋の空
Re: (スコア:0)
# と親コメントは言いたいのだろうか
本当に初歩的なのか？ (スコア:0)
Re:本当に初歩的なのか？ (スコア:2, すばらしい洞察)
きわめて初歩的なミスと言ってるんだと思うよ。
車の免許取るときに「だろう運転はダメだよ」ってみんな言われているはずなんだけど、意外とやっちゃうもんなんだよねぇ。
最近の若い者は… (スコア:2, おもしろおかしい)
それが今じゃ、「やらないか」と言われればホイホイついてきちまう技術者ばかり。
いいのかい？ワシは「有効期限切れ証明書」も「オレオレ証明書」も使っちまう男なんだぜ？
（いいんです、警告メッセージが表示されるけどセキュリティ上の問題はありませんから…）
ｱｯｰ
Re:最近の若い者は… (スコア:4, すばらしい洞察)
開発に比べると、保守は軽く見られがちな傾向はあると思いますね。
保守系の格言だと他にもこんなのが。
「能ある鷹はさっさとタカ飛び」
「立つ鳥後は任せた」
「一寸のバグでも五分以内に開発担当呼び出せゴルァ」
Re:最近の若い者は… (スコア:2, 参考になる)
たしかイタリアの空港で、空港内のジェット燃料備蓄が0になって空港が機能しなかったという問題が起きてましたよね。
原因は、管理部門が存在せず、いつも誰か気がついた人が発注してた事で、このときは誰も発注してなかったからだったとか。
管理部門が存在しなかったっていうのも勿論だけど、21世紀にさしかかろうって時期(問題発生は1999年)までこれで運用できてたのが凄い。
Re: (スコア:0)
本件だと担当者が誰かがあいまいだったのが致命的かと。つまり「（ある）担当者のボーンヘッド」という初歩的ミスに閉じ込めるのは危険。
オレに銃を撃たせろ (スコア:4, すばらしい洞察)
日本の開発現場ではマネジメントが機能しておらず、今までも担当者や責任範囲が
明確に決まっている方が珍しかった。それを「現場に臨んでは臨機応変」と現場の
独断と超法規的処置で当たることで、なんとか凌いできた。
最近は現場の人間が短期間の派遣や契約社員などばかりで、上からの明確な指示も
情報もないままに、上からの指示を待たずして現場の独断で動くことは一層難しく
なり、今までなら現場の人間が水面下に押さえつけてきた問題も表面化することも
多くなったというだけでは。
Re:オレに銃を撃たせろ (スコア:3, おもしろおかしい)
ＳＳＬ？ (スコア:0)
まぁ良くある事かと・・・・他人事
サブとメイン (スコア:0)
バグじゃないよな (スコア:0)
Re:バグじゃないよな (スコア:2, すばらしい洞察)
Re:バグじゃないよな (スコア:1)
Re: (スコア:0)
Re:バグじゃないよな (スコア:1)
数日前にポップアップ窓が出るとか…素人考え？
Re: (スコア:0)
ポップアップでリマインドなんて案が出ている時点で、既にそのプロジェクトはどうかしてます。
が、今回の状況を見れば、最後の砦として機能したかもしれません。
Re: (スコア:0)
そんなエサで俺がクマー