マイクロソフト、AzureやOffice 365にログインできなくなる多要素認証の障害を二度も発生。アップデートしたコードにバグが潜り込んでサーバがフリーズ

2018年12月3日

ユーザーIDとパスワードだけでログインが可能なシステムは、もはやセキュアなシステムとはいえません。セキュリティトークンやショートメッセージの利用や、生体認証などの要素を加えた多要素認証を用いることが、特に企業向けサービスなどセキュリティを重視するシステムへのログインでは欠かせない仕組みになっています。

ところが、マイクロソフトのクラウドサービスであるMicrosoft AzureやOffice 365、Microsoft Dynamicsなどへログインするための多要素認証のシステムが、この2週間で2回もダウンするという障害を引き起こしています。障害が発生しているあいだは多要素認証を用いたログインができない深刻な状態でした。

一度目の障害は11月19日午前4時(世界協定時。日本時間の19日午後1時39分)から、午後6時38分(日本時間20日午前3時38分)までと、ほぼ一日の営業時間全体で止まっており、二度目は11月27日午後2時20分(日本時間午後11時20分)から午後5時39分(日本時間翌28日午前2時39分)まで約3時間、止まっていました。

それぞれの原因は異なっており、マイクロソフトは「Azure Status History」のページで二度の障害についての原因と対策を報告しています。

なぜ多要素認証という重要なシステムで障害が発生したのか、そしてどのような対策が行われたのか。同社の報告から概要を見ていきます。

システムアップデート後、トラフィック増大が引き金になってバグが発生。

11月19日の一度目の障害の遠因となったのが、13日から16日にかけての内部システムのアップデートでした。ここで潜り込んだバグが、数日後の19日になって、あるデータセンターでのトラフィックが閾値を超えたタイミングで以下の障害を次々に引き起こすことになったのです。

1)多要素認証システムの負荷が一定以上に高まると、多要素認証システムのフロントエンドからキャッシュサービスへのアクセスに対する遅延が発生した
2)この遅延が多要素認証システムのバックエンドサーバを再利用する際に競合状態を作り出し、それがさらに全体の遅延を引き起こした
3)上記の遅延が障害検知システムにもおよび、障害の検知そのものができなくなっていた

それでもなんとか障害に気づいた多要素認証システムの担当チームは、遅延が遅延を呼んで障害を起こしているシステムをなんとか立て直そうとシステムの一部に変更を加えます。

対策するはずが火に油をそそぐ結果に

残念ながらそれは火に油を注ぐような逆効果になったと、次のように報告されています。

The MFA team recently deployed a change to more effectively manage connections to the caching services. Unfortunately, this change introduced more latency and a race-condition in the new connection management code, under heavy load.

多要素認証チームはキャッシュサービスへの接続を効率よく行えるような変更を投入した。しかし負荷の高い状況でのそうした変更は、さらに新たな遅延と競合状態を呼び込むだけであった。

これによってさらに障害は拡大していきますが、その時点でさらに対策としてデータセンターのトラフィックパターンの変更、自動回復システムをオフにし、システムの容量追加、トラフィック制限の管理などの対策も行った結果、徐々に多要素認証システムは回復へと向かっていきます。

その後、障害の原因となった上記3つの要因を把握。それぞれに対処をした結果、システムが回復します。

マイクロソフトは対策として次の3つを挙げています。

  • アップデートプロセスに対する開発とテスト時の見直し
  • 障害の検出と復旧を迅速に行うためのモニタリングサービスの見直し
  • データセンターを超えて障害が広がらない仕組みの見直し
  • 障害発生時に迅速に検出しダッシュボードへ表示するツールのコミュニケーションプロセスの改善

二度目はDNSのエントリ切れと別のバグが障害を引き起こした

ところがこの障害から1週間ほど経過した11月27日。多要素認証システムは再び数時間ほど障害を起こします。

今度の原因は、多要素認証システム内部で使用しているDNSのエントリが期限切れとなり、多要素認証のフロントエンドとバックエンドの通信ができなくなったことでした。

この障害が解消されると次の障害が待っていました。フロントエンドとバックエンドの通信が回復したことによりバックエンドへのトラフィックが急激に増大。すると、19日に障害を引き起こしたコンポーネントと同じコンポーネントにまだバグが潜んでおり、それがバックエンドのリソースの枯渇と競合を発生させ、最終的にサーバをフリーズさせてしまいます。

これに対処するためにサーバリソースの追加投入などを行い、障害からの復帰を行いました。

二度の障害に対して、マイクロソフトは報告の中で以下のように平身低頭で謝罪しています。

We sincerely apologize for the impact to affected customers. We are continuously taking steps to improve the Microsoft Azure Platform and our processes to help ensure such incidents do not occur in the future.

障害の影響を受けたお客様に、私たちは心からお詫びいたします。私たちはこうしたインシデントを将来において二度と起こさないように、継続的にMicrosoft Azureプラットフォームおよびプロセスを改善していきます。

同社はバックエンドサーバがフリーズしないようにコードを見直すこと、多要素認証にシステムキャパシティを増大させること、トラフィックのスパイクに対するスロットリング制御の改善、DNSの変更を自動化することなどを対策として挙げています。

これだけの障害の原因を短時間で発見し、対策する技術力はさすがマイクロソフトと思わせる面はあります。しかしシステムにログインできなければ、顧客にとってそのシステムは存在しないのも同然ですから、この多要素認証システムの二度の障害はマイクロソフトにとって非常に深刻な重大な出来事であることは間違いないでしょう。

あわせて読みたい

Microsoft Azure クラウド クラウド障害 Microsoft




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本