アカウント名:
パスワード:
別のニュースで１２時間HTTPSサービス停止って書いてありますが、なぜ１２時間もかかるの。証明書なんて数キロ程度のファイルインポートで終わりじゃないのでしょうか？
むしろ３，４時間で復旧が普通ではないのでしょうか
ふつうは有効期限切れになる前に修正がかかるはず。
米Microsoft、Windows AzureがSSL証明書失効で約12時間サービス機能停止に -INTERNET Watch [impress.co.jp]
この問題についてフォーラムの中では、「Windows Azureでエンタープライズ向けアプリケーションを使用することは適切なのか」などという疑問が提起されるなど、当然ながら多くの不満の声が上がっている。その一方で、Microsoft社内でこの問題に対処している担当者、または責任者が気の毒だ、といった同情の声も上がっている。 クラウドサービスでは、犯罪者によるサービスの妨害や盗難などのセキュリティ上の問題が取り上げられることは多い。しかし、今回はSSL証明書の期限切れ失効という非常に初歩的なミスによって世界中でクラウドサービスが利用できなくなってしまった。
この問題についてフォーラムの中では、「Windows Azureでエンタープライズ向けアプリケーションを使用することは適切なのか」などという疑問が提起されるなど、当然ながら多くの不満の声が上がっている。その一方で、Microsoft社内でこの問題に対処している担当者、または責任者が気の毒だ、といった同情の声も上がっている。
クラウドサービスでは、犯罪者によるサービスの妨害や盗難などのセキュリティ上の問題が取り上げられることは多い。しかし、今回はSSL証明書の期限切れ失効という非常に初歩的なミスによって世界中でクラウドサービスが利用できなくなってしまった。
「非常に初歩的なミス」、Windows Azure Forums [microsoft.com]でも手厳しい評価を受けてますよｗ
本当になんでやらかしちゃったのかしらねぇ……この手の証明書期限トラブルって、期限切れが近くても見た目が変わらないせいなんでしょうか。WSUS含め [technet.com] 修正パッチでも期限系でやっちゃってるしなぁ [microsoft.com]SSL証明書は「問題が起こってから対応」では遅くて、「問題が起きる前に対応」という特異さがあるからなんでしょうかね。良く有りそうなハードウェア障害とかは自動的に切り替わって後からとか、セキュリティパッチは出たら対応といった後手で可能ですしね。
12時間という時間に関しては、アメリカ4、アジア2、ヨーロッパ2と計8拠点あって台数もそれなりにありそうなので早いか遅いかは解らないかも。
なので内部資料上、他社より早く完了しているのです。
多分、次の2点だろうが、想像に過ぎない。(1) 休日は平日より(スキルも含めて)人員が手薄だった(2) 影響範囲が大きかったので、サポート部門をパンクさせた(3) 台数が多かったので、手順の作成・作業確認に時間が掛かった
(1) 運用担当が通信が繋がらないことぐらいしか把握できず、証明書のエラーにたどり着くまでの情報をサポート部門伝えるのに時間が掛かったとか
(2)は、影響範囲が大きいので、1時間ごとに報告せよって騒ぐようなお客からの電話でサポート部門がパンクして、(1)の情報採取と確認に手間取ったとか。
(3)は、人員を緊急収集して、しかるべきスキルの人間が手順を策定して、大量のサーバに確実に作業を行ったかどうかのエビデンス(証拠)を残しながらの作業と考えると、6～8時間ぐらいはかかっても不思議ではない。※想定され、手順が準備されていれば、2～4時間ぐらいだろう。
残り、4時間分は上記の作業を複数の拠点(国外もある？)で意識あわせしつつやると、そのぐらい掛かりそう。
セキュリティ強化のために証明書の検証必須にしたら、証明書の期限切れで検証通らず、証明書が更新出来なかったでござる
複数の拠点(国外もある？)
参考までにAzureは米国内に4拠点、アジアで2拠点、ヨーロッパに2拠点あります。
米国・バージニア[East US]・シカゴ[North Central US]・サンアントニオ[South Central US]・カリフォルニア[West US]
アジア・香港[East Asia]・シンガポール[Southeast Asia]
ヨーロッパ・ダブリン[North Europe]・アムステルダム[West Europe]
後半のソース等のリンクが漏れたorzサーバーの場所に関してはプライバシーの所で触れてます。 [windowsazure.com]法的リスクとかが絡むので結構大切。具体的地名は手元のメモ資料なのですが引っ越してたらすいません。
CDNに関しては上記より多くあります。 [microsoft.com]
訂正： 2点→3点
> プログレスバー上では1時間と表示(MS談)手順があったとしても、それなら、むしろ早いほうという気がする。
原因究明→方針策定→承認（いちばんかかる）→施策
を12時間ではウチの会社ではむりw
確かに、うちの会社も、抱えてる顧客も無理ですね。
12時間でできないところは1年あったってできない(からこそ期限を切らす)よ。
管理コンソール(https)に繋がらないので、雲の中を飛び回る時間が12時間
証明書が切れていたら更新対象が実際に更新対象であることを確認できないので物理的に証明書を運ばなければ安全とは言えないのではないでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
12時間 (スコア:0)
別のニュースで１２時間HTTPSサービス停止って書いてありますが、
なぜ１２時間もかかるの。
証明書なんて数キロ程度のファイルインポートで終わりじゃないのでしょうか？
むしろ３，４時間で復旧が普通ではないのでしょうか
Re:12時間 (スコア:4, 興味深い)
http://www.itmedia.co.jp/news/articles/1302/24/news006.html [itmedia.co.jp]
３，４時間で復旧が普通？ (スコア:2)
ふつうは有効期限切れになる前に修正がかかるはず。
米Microsoft、Windows AzureがSSL証明書失効で約12時間サービス機能停止に -INTERNET Watch [impress.co.jp]
「非常に初歩的なミス」、Windows Azure Forums [microsoft.com]でも手厳しい評価を受けてますよｗ
モデレータは基本役立たずなの気にしてないよ
Re:３，４時間で復旧が普通？ (スコア:1)
本当になんでやらかしちゃったのかしらねぇ……
この手の証明書期限トラブルって、期限切れが近くても見た目が変わらないせいなんでしょうか。
WSUS含め [technet.com] 修正パッチでも期限系でやっちゃってるしなぁ [microsoft.com]
SSL証明書は「問題が起こってから対応」では遅くて、「問題が起きる前に対応」という特異さがあるからなんでしょうかね。
良く有りそうなハードウェア障害とかは自動的に切り替わって後からとか、セキュリティパッチは出たら対応といった後手で可能ですしね。
12時間という時間に関しては、アメリカ4、アジア2、ヨーロッパ2と計8拠点あって台数もそれなりにありそうなので早いか遅いかは解らないかも。
プログレスバー上では1時間と表示(MS談) (スコア:0)
なので内部資料上、他社より早く完了しているのです。
Re: (スコア:0)
多分、次の2点だろうが、想像に過ぎない。
(1) 休日は平日より(スキルも含めて)人員が手薄だった
(2) 影響範囲が大きかったので、サポート部門をパンクさせた
(3) 台数が多かったので、手順の作成・作業確認に時間が掛かった
(1) 運用担当が通信が繋がらないことぐらいしか把握できず、
証明書のエラーにたどり着くまでの情報をサポート部門伝えるのに時間が掛かったとか
(2)は、影響範囲が大きいので、1時間ごとに報告せよって騒ぐようなお客からの電話で
サポート部門がパンクして、(1)の情報採取と確認に手間取ったとか。
(3)は、人員を緊急収集して、しかるべきスキルの人間が手順を策定して、
大量のサーバに確実に作業を行ったかどうかのエビデンス(証拠)を残しながらの作業と
考えると、6～8時間ぐらいはかかっても不思議ではない。
※想定され、手順が準備されていれば、2～4時間ぐらいだろう。
残り、4時間分は上記の作業を複数の拠点(国外もある？)で意識あわせしつつやると、
そのぐらい掛かりそう。
私の想像では (スコア:4, 参考になる)
セキュリティ強化のために証明書の検証必須にしたら、
証明書の期限切れで検証通らず、
証明書が更新出来なかったでござる
Re:12時間 (スコア:2)
参考までにAzureは米国内に4拠点、アジアで2拠点、ヨーロッパに2拠点あります。
米国
・バージニア[East US]
・シカゴ[North Central US]
・サンアントニオ[South Central US]
・カリフォルニア[West US]
アジア
・香港[East Asia]
・シンガポール[Southeast Asia]
ヨーロッパ
・ダブリン[North Europe]
・アムステルダム[West Europe]
Re:12時間 (スコア:2)
後半のソース等のリンクが漏れたorz
サーバーの場所に関してはプライバシーの所で触れてます。 [windowsazure.com]
法的リスクとかが絡むので結構大切。
具体的地名は手元のメモ資料なのですが引っ越してたらすいません。
CDNに関しては上記より多くあります。 [microsoft.com]
Re: (スコア:0)
訂正： 2点→3点
> プログレスバー上では1時間と表示(MS談)
手順があったとしても、それなら、むしろ早いほうという気がする。
Re:12時間 (スコア:2, おもしろおかしい)
原因究明→方針策定→承認（いちばんかかる）→施策
を12時間ではウチの会社ではむりw
Re:12時間 (スコア:1)
確かに、うちの会社も、抱えてる顧客も無理ですね。
Re: (スコア:0)
12時間でできないところは1年あったってできない(からこそ期限を切らす)よ。
Re: (スコア:0)
管理コンソール(https)に繋がらないので、
雲の中を飛び回る時間が12時間
Re: (スコア:0)
証明書が切れていたら更新対象が実際に更新対象であることを確認できないので
物理的に証明書を運ばなければ安全とは言えないのではないでしょうか?