Microsoft、顧客のクラウド製品のセキュリティログが数週間失われたと発表

 (techcrunch.com)
2 ポイント 投稿者 GN⁺ 2024-10-22 | 1件のコメント | WhatsAppで共有
  • 一部のMicrosoftクラウド顧客は、2週間以上のセキュリティログの空白を経験しており、侵入検知と事後分析に必要なデータを失った可能性がある
  • 9月2日から9月19日まで、内部監視エージェントのバグが一部ログのアップロードを妨げ、内部ロギングプラットフォームにデータが残らなかった
  • Microsoftは原因がセキュリティインシデントではなく運用上のバグであり、影響範囲は「ログイベント収集」に限定されたと説明した
  • 影響を受けた製品にはMicrosoft Entra、Sentinel、Defender for Cloud、Purviewが含まれ、顧客のデータ分析・脅威検知・セキュリティアラート生成に空白が生じた可能性がある
  • 2023年の中国関連侵入事件後、Microsoftが低料金プランにもログ提供を拡大するとしていた状況だけに、クラウドセキュリティログのアクセス性と保存信頼性が再び争点となっている

Microsoftクラウドのセキュリティログ欠落

  • Microsoftは一部クラウド製品の顧客に対し、2週間以上セキュリティログが欠落したと通知した
    • 欠落期間は9月2日から9月19日まで
    • 顧客向け通知には、Microsoftの内部監視エージェントの一部がログデータを内部ロギングプラットフォームへアップロードする過程で誤作動したと記されていた
  • このロギング障害はセキュリティインシデントによるものではなく、Microsoftは影響が「ログイベント収集」にのみ及んだと説明した
  • ロギングは製品内イベントを追跡する機能で、ユーザーログイン情報や失敗した試行などのデータを含みうる
    • ログがなければ、その期間に顧客ネットワークへの不正アクセスを特定することがより難しくなりうる
  • Business Insiderが10月初めにログデータ損失を先に報じた
  • セキュリティ研究者のKevin Beaumontは、Microsoftが影響を受けた企業に送った通知は、テナント管理者権限を持つ少数のユーザーにしか表示されない可能性が高いとみている

影響製品と顧客への影響

  • 影響を受けた製品にはMicrosoft Entra、Sentinel、Defender for Cloud、Purviewが含まれる
  • 顧客向け通知では、セキュリティ関連のログやイベントに潜在的な空白が生じた可能性があると案内した
    • この空白は、データ分析、脅威検知、セキュリティアラート生成能力に影響した可能性がある
  • Microsoftはロギング障害に関する具体的な質問には答えなかったが、corporate vice presidentのJohn Sheehanは原因を「内部監視エージェントの運用上のバグ」だと確認した
    • Microsoftはサービス変更をロールバックして問題を緩和した
    • 影響を受けたすべての顧客に通知し、必要な支援を提供するとした

2023年の中国関連侵入以降、再燃したログ問題

  • 今回の障害は、Microsoftが2023年に米連邦調査当局から、一部の米連邦政府機関にセキュリティログを提供していなかったと批判されてから1年後に発生した
    • 当時、調査当局はそのログにアクセスできていれば、中国関連の侵入をはるかに早く特定できたはずだとみていた
  • 中国関連の侵入者Storm-0558はMicrosoftネットワークに侵入し、デジタルな「skeleton key」を盗んだ
    • このキーにより、Microsoftクラウドに保存された米政府の電子メールへ無制限にアクセスできた
  • 政府によるサイバー攻撃の事後分析によれば、State Departmentはより上位のMicrosoftライセンスを購入してクラウド製品のセキュリティログにアクセスできたため、侵入を特定できた
    • 一方で、ハッキング被害を受けた他の多くの米政府機関には同じログアクセス権限がなかった
  • 中国関連ハッキングの後、Microsoftは2023年9月から低料金プランのクラウドアカウントにもログを提供すると明らかにした

関連記事

1件のコメント

 
GN⁺ 2024-10-22
Hacker News のコメント

  • 現実的な本番環境で Azure を使っているなら、その責任は自分にあると思う。
    無料クレジットを10万ドル分もらえたとしても、1か月以上使い続けるよう説得はされなかったはず。
    高価で、インターフェースは非常に不親切で、何よりこういう件があるため、製品群を本番負荷で信頼して使えるほど信頼性があるようには見えない。

    • 他のクラウドプロバイダーから Azure に来ると、濃いオレンジ色の警告灯が多すぎる。
      全体が一貫性に欠け、継ぎはぎだらけに感じられるので、誰がまともにセキュリティ監査できるのか信じがたい。
      一番不便なのはログインで、リダイレクトとエラーがばかげているほど多く、意図どおりに動いているとは思えない。
      例えば BAA をダウンロードしようとしたら、信頼済みウェブサイトでログインループに陥ったが、同じブラウザでは Azure コンソールは普通に見られた。
      新規ログインが助けになるか確認しようと Azure アカウントからログアウトしたところ、次のログインで 2段階認証 が表示されなかった。
      ブラウザウィンドウで明示的にログアウトしたなら、そのデバイスへの信頼を取り消したということなので、2段階認証がトリガーされないのは大きな警告サインだと思う。
      結局 BAA も取れず、チケットも開けなかったが、不思議なことに同僚は正常にダウンロードできていた。
    • 最近、あるところがすべての Linux マシンに MS ソフトウェア をインストールして Azure に統合しようとしているのを見て笑ってしまった。
      そこまで来たら、いったん立ち止まって考えるべきだ。
      そもそも信頼できるシステムが欲しくて Linux を選んだのではなかったのか？
    • 「もっと良くできる」と言ってトロールっぽく振る舞うつもりはないが、本当にできないと思う。
      最後に作った「良い」製品は SQL Server/Exchange/Windows 2000 で、それはずいぶん昔のことだ。
    • 社内でもそうだ：「LinkedIn でさえ Microsoft クラウドにそれほど積極的ではない：Azure 移行を断念」
      https://www.theregister.com/2023/12/14/linkedin_abandons_mig...
    • 残念ながら、こうした選択は 上層部 が決めるもので、彼らは単に流行を追うだけだ。

  • ほぼすべてのチームで、VM 上で動かしているアプリケーションに実際のバグがあり、そのアプリがアプリケーションログをストレージへ押し込む構造だった。
    私たちのチームも、ログが再び流れるようにプロセスを再起動しなければならなかった。
    これは sev 0 インシデント で、普段はバックグラウンドで静かに動いているエージェントを多数のチームが手動で再起動しなければならず、簡単には直せないミスだった。

    • Microsoft が妥当な深さで 自動テスト をしていれば、こういうことは起き続けなかったのではないかと思う。
      最近の ClownStrike の世界的障害は配布前テストの不足を示し、今回の Microsoft の問題はそれが Windows の根幹側でも起きていることを示している。
      見栄えのいい話ではない。
    • Microsoft 内部 の話なのか、それとも顧客として経験した話なのか気になる。

  • 影響を受けた製品に Microsoft Entra、Sentinel、Defender for Cloud、Purview が含まれているというくだりが痛い。
    Entra、以前の Azure Active Directory が影響を受けたというのはかなり深刻だ。
    とはいえ、SSO ログなんて誰が必要とするのだろう？

    • 空を見上げて、小惑星が地球に落ちてくるとは思っていなかった時代があった。
      知らぬが仏だ。
      ちなみに Entra と書かれているのを見て Encarta だと思い、まだ存在しているのかと一瞬わくわくした。
    • まったく、Microsoft は名前を一つ決めて使い続けるべきだ。
      Azure Active Directory も素晴らしい名前ではなかったが、何でもかんでもリブランディングし続けるのは本当に疲れる。
    • スペイン語では entra が「入ってきて／中に入って」という意味なので、ネタにされやすい。
    • 私たちには必要だ。コンプライアンス上の義務 がある。
      幸い、本番システムは Entra に統合されておらず、顧客と無関係なものだけが接続されている。
    • ログがなければ侵害もないということだ。

  • これがどんな 情報機関の作戦 を支援したのか気になる。

    • 私たちはそれを APT -1、つまり Microsoft と呼んでいる。
    • 何でもない。Microsoft の内部ロギングインフラは90年代製だ。

  • 1か月少し前に出たこの長い記事も忘れてはいけない。
    Microsoft が海外のサイバーセキュリティで失敗し、意図的に放置したように見える状況をまとめた記事だ。
    https://www.lawenforcementtoday.com/bombshell-allegations-th...

    • 一方で、この報告書には重要な中身がある。
      他方で、Schiller が完全に信頼できる証人に見えるわけではなく、政府の監督を求めた相手が極端な MAGA 共和党議員に限られているように見える点も示唆的だ。
      それでも、1) 重要な米国政府インフラのサポートを外国籍のサポート要員に依存すべきではないこと、2) ハイパースケーラーを含むすべての大手テック企業が、中国で事業を行うために Tencent や Alicloud のような国内代理事業体を通じて 中国政府の管轄圏 と取引関係を結んでいること、この2点には100%同意する。
      こうした契約や、中国側の人員がハードウェア・ソフトウェアスタックに直接アクセスできるようにする条件について、十分な監督が行われていない。

  • なぜこれを公に認めたのだろう？

    • ほとんどのセキュリティチームがアクセスできないツールの中に報告を隠していたことが ばれたから だ。
    • おそらく、外国のアクターがログを削除したと認めることになったとき、大ニュースに見えないよう、あらかじめ何かを敷いておこうとしているのかもしれない。
      MSFT がこういうことを処理するときによく使うやり方だ。

  • Azure はいまいちだ。
    特に Batch Service はジョブスケジューラーがまったく正確ではない。

  • これまで見てきた最悪のインフラとひどい運用慣行を持つところでさえ、こういうことが実質的に不可能になるよう精巧な仕組みを備えていた。
    こういうことが起きると本当に深刻だからだ。
    今回の件以前でも、自分のビジネスを Azure のマネージドクラウドインフラ の上に載せたいとは思わなかっただろう。
    こうしたことがシステム全体の致命的なエラーなしにどうして可能なのか、思考実験をしてみようとしても、うまく想像できない。

  • ここで msft は Google より企業向けに親和的だと言っていたコメントがあった。
    理由はデータを失わないというものだったが、msft は 信頼性 の対極にある。

  • 隠蔽のにおいがする。
    「当社プラットフォームの脆弱性が顧客の syslog に出てしまいました！」「急げ、みんなでログを失くして時間を稼ごう」という感じに見える。