数千社に通知」みたいなタイトルのニュース記事がロイターからありました。情報不足で正確性にかけるタイトルですが。細かい詳細はそのうちでるかも知れませんが現状はこちらを参照。Notebookが参照する)Blobストレージへのアクセストークンにアクセスできるというもののようです。DBの中身を参照したり(削除も可)しほうだい、というわけですね。Notebookへ特権昇格が可能だったということのようです。Microsoftの調査によると実際に悪用されてキーが悪用されたのはWizが調査のためにアクセスしたものだけのようです。DBアカウントが脆弱性がある状態でした。DBアカウントは既定で有効なようです。DBアカウントを作成していた場合、脆弱性がある状態だったと言えます。DBアカウントがある場合、先日Microsoftから今回の件に関するメールを受け取っていると思います。日本で言えば西日本リージョンが対象なようですね。東日本リージョンはなぜか対象外。読み取れる状態だったキーもプライマリ読み取り・書き込みキーのみで、プライマリの読み取り専用キーやセカンダリの読み取り・書き込みキー、セカンダリの読み取り専用キーは問題なかったようです。脆弱性に対する対応すでに脆弱性は修正された状態のようです。影響範囲にあったアカウントのキーをつかった不正なアクセスは(報告者のもの以外は)無かったようですが、漏れている可能性はゼロでは無いので対象アカウントはプライマリキーを再生成することが推奨されています。アカウントのようにアクセスキーによる操作を無効にする(RBACなどのみに制限する)機能が無いので、今回のケースを完全に防ぐのは難しいところですが少なくともキーが露出する個所を減らしたり検出を行うことで対応は可能になると思います。Docsセキュリティガイドラインやベースラインのドキュメントが参考になると思います。RBACを使ってデータプレーンやコントロールプレーンのアクセス時にIDが明確にわかるようにする、診断ログを有効にしてアクセスを追跡できるようにする、ネットワークアクセスを制限する、ATPで異常アクセスを検出できるようにするなどでしょうか。プロパティをtrueにすればプライマリ・セカンダリキーを無効にしてRBACを強制できるようです。API)だけみたいなので他のAPI使ってる場合は注意しましょう。SDKなどバージョン依存もあるのでロールやアプリの環境なども注意。蟻の一穴とはちょっと違いますが、一番脆いところが崩れるものなので提供側としてもこれを教訓に常に意識しておきたいですね。利用者側もわざわざ自分から脆くしないように注意したいところです。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。免責事項このBlogおよびコミュニティにおける発言やコメントは、当方の所属する会社・団体の正式な見解またはコメントではありません。フォロー中ブチザッキ現在102人フォロワーがいます。購読管理このバーを折りたたむ%d人のブロガーが「いいね」をつけました。