米マイクロソフトは2022年2月8日午前、オンライン会議アプリ「Teams（チームズ）」で障害が発生していると発表した。
マイクロソフトによると、8日午前8時半ごろから、日本を含むアジア太平洋地域で、利用者がオンライン会議に参加できない不具合が起きている。
マイクロソフトは「利用者が会議に参加できない問題が起きていることが分かった。影響を軽減するために取り組んでいる」とコメントしている。
Microsoft Teams、再び障害（前回は2022年7月）～原因はオペミスか！？～
マイクロソフトは、2023年1月25日午後4時頃から最大で約5時間半に渡り、Microsoft AzureやMicrosoft 365、Microsoft Teamsなど幅広いサービスがほぼ全世界で利用できなくなっていた大規模障害について、予備的な報告書を公開しました。
まず原因について。同社のワイドエリアネットワークに対して行われた設定変更が全体に影響したと説明しています。
具体的には、設定変更のためにあるルーターにコマンドを送ったところ、そのルーターがWAN内のすべてのルーターに対して誤ったメッセージを送信。その結果、WAN内のすべてのルーターが再計算状態に突入し、適切にパケットを転送できなくなったことが原因とのこと。
問題の発端となったルーターは、マイクロソフトの認証プロセスで検証されていなかったことも付け加えられています。
同社としては、障害発生から約7分後に、DNSとWANに関する問題を検出し調査を開始。発生から1時間5分後にネットワークが自動的に回復し始め、ほぼ同じくして問題の引き金となった問題のあるコマンドが特定されたとのことです。
2時間後にはほぼすべてのネットワーク機器が回復したことが観測され、2時間半後にはネットワークが最終的に復帰したことが確認されたと報告されています。
ただしWAN自身が備えていた健全性維持システム、例えば健全でないデバイスを特定して削除するシステム、ネットワーク上のデータの流れを最適化するトラフィックエンジニアリングシステムなどがWAN自身の障害によって停止してしまっていたため、これを手動で再起動。
これによりWANを最適な動作状態に回復させるまでネットワークの一部でパケットの損失が増加し、約5時間時40分後にこれが完了したとのことです。
今後の対策として、影響度の高いコマンドの実行を遮断し、デバイス上でのコマンド実行は、安全な変更ガイドラインに従うことを義務付ける予定とのことです。
Exchange OnlineとMicrosoft Teamsがアジア太平洋地域でダウン
マイクロソフトの主力クラウドサービスが、アジア太平洋地域でダウンしていたことが明らかになりました。
12月2日の発表によると、「我々の最初の調査では、我々のサービスインフラが最適なレベル以下で機能しており、その結果、一般的なサービス機能に影響を及ぼしていることが判明した」と述べられています。
この問題により、Exchange Onlineのユーザーは、サービスへのアクセス、メールやファイルの送信、マイクロソフトが「一般的な機能」と説明する機能の利用ができなかった可能性があります。
Teamsへの影響は以下の通りです。
- 会議のスケジュール設定や編集、ライブ会議において問題が発生する可能性があります。
- People Picker/検索機能が期待通りに動作しない可能性があります。
- Microsoft Teamsの検索ができなくなる可能性があります。
- Microsoft Teams の [割り当て] タブが表示されない場合があります。
メッセージング、チャット、チャンネル、その他のTeamsの主要なサービスは利用できたようです。
Microsoftは、何が問題なのか分かっていないようです。
「関連する診断データの分析を続ける一方で、影響を受けたインフラのサブセットを再起動し、それによってサービスが復旧されるかを確認しています」と、最初のステータス通知から17分後に投稿された更新に記載されています。
また、別のアップデートでは、次のような情報が提供されています。
弊社では、影響を受けたシステムのごく一部の再起動に成功し、サービスが復旧するかを確認しています。監視を続けながら、根本的な原因の把握に努め、他の潜在的な緩和経路を開発する予定です。
マイクロソフトの報告によると、この問題は "アジア太平洋地域内のすべてのユーザーに影響を与える可能性がある "とされています。
Zscalerの障害（2022年10月）
2022年10月のZscalerの障害により、ユーザーは接続断、パケットロス、通信遅延の被害を受けました。
この障害は、2022年10月25日米国東部時間火曜日の午前8時頃に発生し、Twitter上でZscalerの一部の顧客は「ハードダウン」していると主張し、他の顧客は、激しい遅延とパケットロスを経験していると伝えています。
ある情報筋は、「内部メンテナンスプロセス」がProxyサーバーに大規模な混乱を引き起こし、今回の障害につながったことを共有しました。
同日12:26PM、Zscalerは、この障害は「zscalertwo.net Cloud」の問題によって引き起こされたことを認めました。
「この問題は軽減されました。現在、クラウド全体のアクティブヘルスチェックを行い、状況を監視しています。」とZscaler Trustのインシデントレポートには記載されています。
Zscalerは、障害に関する次の声明を共有しました。
「Zscalerのクラウドセキュリティプラットフォームは、パフォーマンスと耐障害性を最適化するために複数の分散型クラウドを使用して構築されています。今回の問題は、複数のクラウドのうちの1つと、そのクラウド内で提供されているZscalerのサービスのうちの1つだけに影響を与えました。そのクラウドや他のクラウドで他のZscalerのサービスを利用しているお客様には影響はありません。また、影響を受けたお客様とは密接に連携しています。PDT午前9時の時点で、大半のお客様は完全に復旧しており、検証後のチェックは30～60分以内に完了する予定です。」
ノートン360、銀行アプリを「危険」と詐称するトラブル相次ぐ
山陰合同銀行と荘内銀行はそれぞれ2022年11月7日に、オンラインバンキングに利用するアプリ（銀行アプリ）がセキュリティーソフト「ノートン360」によって起動できなくなる不具合を確認したと公表した。iPhone上で銀行アプリ起動しようとすると、ノートン360が「危険サイト このサイトは使用しないことをお勧めします」という警告を表示するという。
ノートン360を提供するノートンライフロックは、同社Webサイトのサポートページにおいて銀行アプリで発生している問題を示し、解決する方法を紹介した。ノートン360を一度アンインストールして再度インストールすれば解決するとしている。
株式会社プレイド 「Slack」における当社関係者のメールアドレス等漏えいに関するお知らせ 2022年8月29日
この度、Slack Technologies Limited（ 本社：Level 1, Block A, Nova Atria North, Sandyford Business District, Dublin 18 Ireland ）（以下、Slack社とします。）より通知があり、当社がコミュニケーションツールとして採用している「Slack」に関して、ユーザーのメールアドレス等を含むレポートが誤って、Slackを契約する他の米国企業1社に対して一時的に開示されたことが判明いたしました。（以下、本件とします。）
本件事象はSlack社における手続き上の誤りを原因としており、Slack社からは既に誤って開示された情報の収集は完了し、米国企業の手元には当該データが残っていないことが確認されたとの報告を受けています。なお、ユーザーによる通信内容は当該レポートには含まれていません。
この度は関係者の方々にご迷惑をおかけしたことをお詫び申し上げます。
1 本件の概要：
Slack社より報告を受けて明らかになっている本件の概要は以下のとおりです。
2022年7月11日、Slack社は、米国企業1社から同社のSlackワークスペースに関する情報提供の依頼を受け、2022年7月18日にレポートファイルを生成し、クラウドストレージを通じて当該米国企業に共有しました。
しかし、Slack社の手続き上の誤りにより、当該レポートには米国企業ではなく当社のワークスペースの情報が含まれ、共有されました。共有されたファイルは担当者によりダウンロード及び閲覧されましたが、内容が当該米国企業のものと異なるという指摘があったため、Slack社は同日、当該米国企業のクラウドストレージへのアクセス権を停止しました。
その後、Slack社は、2022年7月27日までに、当該米国企業の担当者にファイルの削除を要請し、完全に削除されたこと、同社内の他の人物に転送していないことを確認しました。
2022年8月9日、上記発生事実について、Slack社の米国のデータガバナンスチームから日本の当社担当営業に連絡がありました。翌10日に当社担当営業から当社にメールにて当社従業員のメールアドレスを含むレポートがSlack社の他の顧客に共有された旨の案内がありました。
その後、Slack社における調査により、レポートに含まれるメールアドレスが当社従業員だけでなく、当社に関係する外部の方のメールアドレスを含むこと、また、個人データにかかる本人の数が1,000人を超えるおそれがあることがSlack社で判明しました。このことから、2022年8月18日、Slack社から当社宛にメールにてこれらの事実について追加連絡があり、同日、当社において、1,000件を超える個人データの漏えいのおそれが発生したことを認識しました。当社が当該レポートをSlack社から受領し、その内容を確認したのは2022年8月22日となります。
2 漏えい等が発生し、又は発生したおそれがある個人データの項目：
当社のワークスペース作成時点から本件のレポート生成時点までの従業員や取引先など当社関係者のメールアドレス（2,555人分）を含むSlackユーザー名、各ユーザーが参加するチャンネル名、その他Slackが独自に付与する識別子（ユーザーID、チャンネルIDなど）
3 原因：
上記１記載のとおり、Slack社における手続き上の誤りにより、当社のワークスペースのレポートが米国企業1社に提供されました。
4 二次被害又はそのおそれの有無及びその内容：
上記１記載のとおり、Slack社により、2022年7月27日時点で誤って開示された情報の収集は完了し、米国企業の手元に当該データが残っていないことが確認されています。
現時点までに二次被害については確認されていません。
Microsoft Teamsの障害により、Microsoft 365のサービスもダウン / Microsoft Teams outage also takes down Microsoft 365 services
マイクロソフトのコラボレーション環境「Teams」に障害が発生し、不特定多数の人がビデオ/オーディオ会議の機会や、ドキュメントにアクセスする機会を失いました。
Microsoftは、2022年7月21日01:47（UTC）にこの問題を認め、対応に着手しました。
当初は小規模なMicrosoft Teamsの障害でしたが、Exchange Online、Windows 365、Office Onlineなど、Teamsを統合した複数のMicrosoft 365サービスにも障害が発生しています。
接続障害を引き起こした問題は、内部ストレージサービスへの接続が壊れていることを特徴とする最近のデプロイメントであると発表しました。
しかし、Teamsだけでなく、Microsoft 365のさまざまなサービスに接続できないとの報告がユーザーから寄せられ、障害の影響を受けています。
マイクロソフトは、この問題を確認し、その後のMicrosoft 365の停止は、Teamsの統合されたサービスのみに影響したと述べています。
「Microsoft Word、Office Online、SharePoint Onlineなど、Teamsを統合した複数のMicrosoft 365サービスへの影響を確認しています。」とマイクロソフトは説明しています。
同社がMicrosoft 365 Serviceのヘルスステータスページでさらに詳しく説明しているように、影響を受けたユーザーは、以下のサービスのいずれか、または複数に問題が発生したとのことです。
- Microsoft Teams (Access, chat, and meetings)
- Exchange Online (Delays sending mail)
- Microsoft 365 Admin center (Inability to access)
- Microsoft Word within multiple services (Inability to load)
- Microsoft Forms (Inability to use via Teams)
- Microsoft Graph API (Any service relying on this API may be affected)
- Office Online (Microsoft Word access issues)
- SharePoint Online (Microsoft Word access issues)
- Project Online (Inability to access)
- PowerPlatform and PowerAutomate (Inability to create an environment with a database)
- Autopatches within Microsoft Managed Desktop
- Yammer (Impact to Yammer experiments)
- Windows 365 (Unable to provision Cloud PCs)
トラフィックを正常なサービスにリダイレクトして影響を軽減した後、遠隔測定によりMicrosoft Teamsの機能が回復し始めたと述べています。
出典：Microsoft Teams outage also takes down Microsoft 365 services
出典：Microsoft Teams outage widens to take out M365 services, admin center
クラウドサービス利用のリスク ～設定不備で数百万円の課金が発生することも～ / How I Got Pwned by My Cloud Costs
Have I Been Pwned（HIBP）はクラウドファーストのサービスとして構築され、Azure Table Storageのような最新のクラウドパラダイムを活用して、以前は達成できなかったようなレベルのパフォーマンスでコストを大幅に削減することができました。これは小さなお金で大きな成功の実現ですが、今日はその正反対、クラウド・コストに負けた話について書きます。
それは、2021年12月のAzureの請求書が、通常よりはるかに高額だったことから始まりました。問題を発見するのに少し時間がかかりました。
その請求書は2022年1月10日に届きましたが、武漢ウイルスの影響で、請求書を見るまでにさらに10日ほどかかってしまいました。
私が最初に見るのはAzureのコスト分析で、上記のような項目を使用しているすべての個別サービスに分解しています。HIBPは、ウェブサイト、関係データベース、サーバーレス「Functions」、ストレージなど、多くの異なるコンポーネントで構成されています。すぐに、あるサービスがトップに浮き上がりました。
最初の項目が、すべてのサービスにおける帯域幅コストの98％を占めています。すべての HIBP サービスだけでなく、Hack Yourself First から Why No HTTPS まで、Azure で実行しているすべてのサービスです。ここで話しているのは、Microsoft の Azure インフラストラクチャから送信されるデータの帯域幅（GB あたり 0.1205 豪ドル）であり、通常は Web サイトへのトラフィックなどです。しかし、これはストレージアカウントです。まず、使用量が急増し始めた時期から見てみましょう。
2021年12月20日。NCAから提供された何億もの新しいパスワードとともに、FBIのためのPwned Passwordsインジェスト・パイプラインが開始されたのです。オープンソースのコードベースが初めて製品としてリリースされたのでしょうか。それとも他に何か？私は、帯域幅の使用状況をより細かく調べることから始め、さらに深く掘り下げていく必要がありました。
一貫して、それぞれのスパイクは17.3GBでした。完全に直線的な分布ではありませんが、かなり規則的なスパイクです。Pwned Passwordsのダウンロード可能なハッシュです。しかし、これらは常にCloudflareのエッジノードにキャッシュされます。そのため、私は無料でサービスを提供することができ、オリジンサービスからの帯域幅を無視できるように、そこの人々と多くの仕事をしました。実際、それが問題だったのでしょうか？ストレージアカウントで診断を有効にして、個々のリクエストのレベルまで、もう一度深く掘り下げてみましょう。
さて、そこで問題です。これらのリクエストは定期的にログに現れ、17.3GB分のコストが発生していたのです。このIPアドレスはCloudflareのもので、トラフィックは間違いなく彼らのインフラを経由しており、したがってキャッシュされるはずでした。Cloudflareのダッシュボードが何を言っているのか見てみましょう。
Cloudflareがキャッシュすべきものをキャッシュしていないという症状は明らかでしたが、根本的な原因は明らかではありませんでした。私はすべての設定、例えば「downloads」サブドメインのキャッシュポリシーを定義するページルールを調べ直しました。
そして、その結果、両方のSHA-1アーカイブが15GBを超えていました。根本的な原因がはっきりしたので、Cloudflareのルールを微調整してみました。
HIBPのウェブサイトから直接ダウンロードできるリンクを削除し、シードがたくさんあるtorrentだけを残したので、データを入手するのはまだ簡単でした。その後、Cloudflareが15GBの上限を上げたので、torrentをダウンロードできる環境にない人たちのためにリンクを復活させました。危機は去りました。
それで、被害総額はどうなったのでしょうか？
その期間の通常の使用量に加え、11,000AUD以上の費用がかかっています。痛っ! 他の地域の人たちからすると、約8,000USD、約6,000GBP、約7,000EUR、約840,000JPYに相当します。これは、1日あたり約350豪ドルが、1カ月間かかったことになる。本当に痛かったし、起こってはならないことだった。もっと早く気づいて、このようなことが起こらないような安全策をとっておくべきだったのです。
まず、Azureの帯域幅が高価であることは常に認識し、特に最も多くのデータを扱うストレージアカウントについて、もっとよく監視するべきです。この記事の最初のグラフを見ると、トラフィックが異常になる前では、帯域幅は1日に50GBを超えることはありませんでした。この閾値を超えたときに、ストレージアカウントにアラートを設定しましょう。
出典：How I Got Pwned by My Cloud Costs
【クラウド設定で恐ろしい課金額が発生した他の記事】
登録:
投稿 (Atom)