アカウント名:
パスワード:
トラブル発生後、各空港にある管理サーバーとカウンターの端末との間で日付を確認しあう接続を断ち切ったところ、システムが復旧した
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
予定表アラームで解決するのでは (スコア: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: (スコア:0)
> 変えておくべきだったと話す。
これも結構恐いものがあります。影響が出る頃にはだれも背景を知っているひとが生き残っていないということだし、引き継ぎなんてやんないよと宣言しているに等しい。100年後に設定していいような内容ならなそもそも有効期限を設けないことを検討すべき。有効期限を設定する趣旨があるなら逆に期限を短くして定例作業にしてしまったほうが安心だと思うのだが。
Re: (スコア:0)
2000年問題から何も学んでいないのか…。
Re:予定表アラームで解決するのでは (スコア:2, 興味深い)
Re:予定表アラームで解決するのでは (スコア:2, 参考になる)
ウェブ系システムのサーバ証明書、ウィルス対策ソフトの契約更新、
サーバやネットワーク機器のサポート契約、ＤＢ上のカレンダーマスタデータの追加、などなど
いずれのケースも、開発チームが開発の過程で購入や契約を手配した後、
運用中に更新が必要となるモノや契約を、過不足なく保守・運用チームに引き継げていないのが原因でした。
簡単なことのようですが、各チームが別会社であったり、契約者がクライアントであったりすることも多く、
なかなか一筋縄ではいきません。
この手のトラブルを防止する上で最も難しいのは、
更新しなければならないモノや契約を洗い出して把握することと、
その更新業務の責任者を明確にすることではないでしょうか。
把握していたのに更新を忘れたのであれば、それはマヌケすぎて救いようがありませんが…。
Re:予定表アラームで解決するのでは (スコア:1)
システム上のさまざまな更新期限より「担当者の更新期限」のほうが絶対に短いと踏んでるんでしょうね…