あなたのMicrosoft 365テナントはクラウドインフラだ。Entra ID、Exchange Online、SharePoint、Teamsにまたがる何百ものセキュリティ関連設定があり、管理されていないAWSアカウントとまったく同じようにドリフトする。管理者がインシデント対応中に設定を変えて、戻し忘れる。Microsoftがサービス更新でデフォルトを変える。2四半期前に終わったパイロットのために、ベンダーがゲストアクセスを持ったままになっている。そして誰もレビューしない。テナントは「ITのもの」であって「インフラのもの」ではないからだ。ポスチャスキャンは地味だが効く処方箋だ。テナントの実際の設定を公開されたセキュリティベースラインと継続的に比較し、ギャップを報告する。そして2026年にそのスキャナーを動かす現実的な方法はSaaSであり、つまりクラウドでクラウドをチェックすることになる。この記事はその101で、例としてAether365を使う。最初に明かしておくと、Aether365は私のプロダクトだ。

始める前にひとつの原則: read-onlyがデフォルトである。個別の明示的な同意なしに、テナントへの書き込み権限が付与されることはない。

テナントを本番アカウントとして扱う

誰かが設定監査もドリフト検知も変更履歴もなしに本番AWSを運用していたら、あなたはそれを怠慢と呼ぶだろう。ほとんどの組織はMicrosoft 365をまさにそのやり方で運用している。IDプロバイダー、すべてのメール、大半のファイルをそこに置いたままで、だ。テナントは、あなたが運用する他のすべてのもののIDプレーンだ。そこにあるConditional Accessの設定ミスは、攻撃者にとって公開S3バケットよりも価値がある。

インフラの考え方はそのまま移植できる。必要なのは、宣言されたベースライン、現実とベースラインの定期的な比較、そして両者が乖離したときのアラートだ。AWSの世界ならConfigルールやSecurity Hubスタンダードに手を伸ばすところだ。Microsoft 365における相当物がポスチャベンチマークになる。

知っておくべき3つのベンチマーク

重要なことの大半は3つのベースラインでカバーでき、まともなスキャナーは必ず少なくとも1つにマッピングされている。

  • CIS Microsoft 365 Foundations Benchmark: 最も広範なもので、MFAの強制からメールボックス監査、共有ポリシーまで、スイート全体にわたる800以上のチェックを持つ。「何に対して監査したのか?」に対するデフォルトの答え。
  • EIDSCA (Entra ID Security Configuration Analyzer): Entra IDだけに焦点を当てたもの。誰が認証し、同意し、アプリケーションを登録できるかを決める設定群だ。表面積は小さく、爆発半径は最大。
  • CISA ScuBA (Secure Cloud Business Applications): 米連邦政府のM365向けベースライン。より厳格で主張が強い。政府の外でも「堅い標的ならどうするか」のリファレンスとして有用だ。

ベンチマーク同士は重複するが、それで構わない。IDコントロールでの重複はコンセンサスがどこにあるかを教えてくれるし、コンセンサスのある検出結果こそ最初に直すべきものだ。

スクリプトかSaaSか: 本当のトレードオフ

これらのチェックを自分で走らせることはもちろんできる。Graph APIはすぐそこにあるし、Maesterのようなコミュニティツールが多くをラップしてくれるし、1テナントに対する定期的なPowerShell実行なら週末プロジェクトで済む。チェックが実際に何をしているかを学ぶには、私はこのアプローチが好きだ。

これがスケールしなくなるのは3つの軸だ。メンテナンス: ベンチマークはバージョンアップし、Graphのエンドポイントは変わり、スクリプト集はいつの間にかあなたが所有するプロダクトになる。履歴: ある時点のスクリプトは今日の状態を教えてくれるが、ポスチャの問いはトレンドの問いだ。このコントロールはいつ後退し、その前後で何が変わったのか。テナンシー: 複数テナントを管理し始めた瞬間、たとえば30社の顧客を抱えるMSPなら、テナントごとのスクリプトとクレデンシャルこそがリスクになる。

SaaSスキャナーはこのトレードを反転させる。読み取り専用のMicrosoft Graph同意を与えると、日次、週次、月次のスケジュールでコンプライアンススキャンとエクスポージャースキャンを走らせ、履歴を保持してくれる。精査すべきは同意モデルだ。外部サービスを自分のIDプレーンに接続することになるからだ。読み取り専用がデフォルトであるべきで、それを超えるものは、拒否できる別個の明示的な同意であるべきだ。このひとつの性質こそが、規制対象のEUテナントにとって、クラウドでクラウドをチェックすることを受け入れ可能にする。

Aether365がカバーする範囲

Aether365はそのスキャナーに対する私の回答だ。中核は、上記3つのベンチマークすべてに対するコンプライアンススキャンとエクスポージャースキャンで、テナントごとにスケジュールできる。加えてMSP向けのマルチテナント管理、Teamsとメールの通知、そしてAIアシスタントにスキャン結果を照会させたい場合のREST APIと組み込みのMCPサーバーが付く。EU拠点でGDPRに準拠しており、サインアップ時にデータリージョンを選択でき、スキャンデータがモデルの学習に使われることは決してない。

2つの機能は、テナントを内側から見る視点の先に踏み出している。External Attack Surfaceはテナントが外に何を晒しているかをチェックする。M365のメールを実質的に支えるSPF、DKIM、DMARCレコード、90日前警告付きの証明書期限、宙に浮いたDNSとサブドメイン乗っ取りリスク、開いたままのレガシー認証エンドポイント、公開されたSharePointとOneDriveの共有だ。そしてAI PilotはオプトインかつProとEnterprise限定で、検出結果を具体的なMicrosoft Graphの修正に変換し、何かが適用される前に項目ごとに承認させる。検証済みの監査証跡付きだ。読み取り専用がデフォルトのままで、書き込み経路は望む場合にだけ有効化する別個のMicrosoft同意になっている。1テナント月次スキャンのFreeティアがあり、最初のCISスコアを見るにはそれで十分だ。そしてその最初のスコアが、たいてい動機になる。

要点

この101はシンプルだ。あなたのMicrosoft 365テナントはクラウドアカウントと同じポスチャの規律に値するし、測定に使うベンチマークはすでに存在する。運用上の問いは、スキャナーを自分で動かすか、読み取り専用でスケジュール実行するSaaSに同意するかだけだ。スクリプトはコントロールを教えてくれる。サービスは時間を通してあなたを正直に保つ。どちらにせよ、避けるべき失敗モードは現在のデフォルト、つまり誰も何もチェックしていない状態だ。

次に読む

同じプラットフォームのAI側、つまり修復に承認ゲートが必要な理由と、AI生成レポートが実際に何のためにあるのかについては、ercan.aiのM365 Security 101: AI Pilot and Business Impact Reportsを読んでほしい。クラウド、セキュリティポスチャ、プラットフォーム業務のコンサルティング、あるいは挨拶だけでも、ercanermis.comからどうぞ。