米CISAのM365設定点検ツールScubaGearが2.0に 前の版の設定ファイルは書き換えを

Microsoft 365の管理センターを開き、外部共有、多要素認証、迷惑メールの設定を1画面ずつ見て回る。半日はかかるこの点検を、PowerShellのコマンド1行で済ませられる無料のツールがあります。

米CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）の「ScubaGear」です。2.0が10月22日（米国時間）にGitHubで公開され、CISAは27日、Google Workspace向けの「ScubaGoggles」1.1.0とあわせて告知しました。2022年の公開から数えて、いちばん大きな更新だそうです。

すでに1.x系を使っているなら、動かす前に設定ファイルを見直してください。Defenderの基準が廃止され、2.0はdefenderという製品名を受け付けません。これから試す会社にとっては、読み取りの役割で大半のサービスを点検できるので、自社の設定を外の物差しで測ってみるよい機会でしょう。

Defenderの基準はSecurity Suiteへ

2.0でいちばん影響が大きいのは、基準の組み替えです。これまでのDefenderの基準と、Exchange OnlineとTeamsのうちメールの保護やDLPの項目が、新しい「Security Suite」の基準にまとまりました。CISAの説明では、Defender、Purview、Exchange Online、Teamsの対策を一つの枠組みに集めた、という位置づけです。

移ったのは、Exchange Onlineの8〜17番、Teamsの6〜8番、それにDefenderの項目です。そのまま1対1で移ったものもあれば、いくつかに分かれたもの、点検できないため消えたものもあります。どの番号がどこへ行ったかは、対応表に1行ずつ載っています。リポジトリのscuba-baseline-policy-migrations.csvです。

設定ファイルで直すのは3か所。ProductNamesのdefenderをsecuritysuiteに変え、例外を書いたDefender:の節をSecuritySuite:に改めます。OmitPolicyやAnnotatePolicyに書いた古い番号も、対応表を見て置き換えます。手で直すより、付属の設定の画面（Start-ScubaConfigApp）で読み込み直したほうが、番号の打ち間違いは防げます。

管理用モジュールに頼らず、直接問い合わせる

点検の速さも変わりました。2.0は、対応するすべてのサービスへREST APIで直接問い合わせます。CISAは、そのぶん速く正確になったとしています。Exchange Onlineの読み取りもREST APIに移ったので、ExchangeOnlineManagementのモジュールは要りません。SharePointとPower Platformは、すでに1.8.0でREST APIに移っていて、PnP.PowerShellなどの管理用モジュールは要りません。Power BIの点検は、2.0で自動になりました。

ただ、動かす端末の条件は前のままです。Microsoftのライブラリの一部がPowerShell 5に縛られているため、ScubaGearはWindows PowerShell 5.1でしか動かず、Windowsが前提です。更新の手引きも、PowerShell 7でモジュールを入れないよう、わざわざ注意しています。

増えた機能のうち、運用で効きそうなのは次の3つです。

• Invoke-SCuBADiffで、2回分の結果のファイルを比べられる。テナントには接続せず、結果が変わった項目だけを色分けした報告を作る
• 危険なアプリの一覧に深刻度の点数が付き、CSVでも出せる
• Disconnect-ScubaTenantのあとに、使い回せるトークンが残らないよう直った

連邦機関に必須の項目が増えた

CISAは、米国の連邦機関に「BOD 25-01」という指令で、基準の一部を必須として守らせています。2.0では、その必須の項目がかなり入れ替わりました。日本の会社に関係しそうなものを表にしました。

まず見ておきたいのは、SharePointの行です。社外と「すべてのユーザー」リンクでファイルをやり取りしている会社は多く、リンクの有効期限と権限の初期値は、SharePoint管理センターの共有の画面ですぐ確かめられます。一方で、緩んだ項目もあります。SPFは、これまで-allだけを合格にしていましたが、2.0では~allも認めるようになりました。

Google Workspace版は、管理ログに頼らない

ScubaGoggles 1.1.0で変わったのは、設定の読み方です。これまでは管理者の操作のログから設定を割り出す項目があり、ログの保存期間が短いと読めない、初期値のままの設定は見えない、という問題を抱えていました。1.1.0はGoogleのPolicy APIで今の設定を直接読むので、この2つが片づきます。CISAは、設定ファイルのYAMLをテキストエディターでなく画面で作れる点も、変化に挙げています。

基準のほうでは、Assured Controlsの基準とGeminiの項目に手が入りました。Assured Controlsは、Google Workspaceの有料のアドオンです。基準には「サポートの担当を米国内のGoogleの社員に限る」という項目まであり、米国の政府機関向けであることがよく分かります。契約していない会社は読み飛ばしてかまいません。

Geminiの基準は、管理コンソールの設定を5つ見ます。ライセンスの無い人にGeminiアプリを使わせない、ベータの機能を止める、会話の履歴を残す、その保存を18か月以上にする、会話の共有を止める、の5つです。社内でGeminiを使わせる規程を作るなら、この5項目はたたき台になるでしょう。

影響を受けるのは、1.x系の利用者だけ

BOD 25-01は米国の連邦の行政機関に向けた指令で、日本の会社に従う義務はありません。CISA自身も、政府の外の組織には参考として示すという立場です。ですから、ScubaGearを使っていない会社で、今回の更新で困ることは起きません。

困るのは、1.x系を定期の点検に組み込んでいる会社です。Update-ScubaGearで2.0に上げたあと、設定ファイルにdefenderが残っていると動きません。社内の手順書やスクリプトがInitialize-SCuBAを呼んでいる場合、こちらはInstall-ScubaDependenciesの別名として残っているので、そのまま使えます。

権限と、結果のファイルの置き場所

ScubaGearの権限は、思ったより小さくて済みます。Entra ID、Security Suite、Exchange Online、SharePoint、Teamsは、グローバル閲覧者の役割で点検できます。例外はPower BIとPower Platformです。Power BIはFabric管理者の役割に加えて、Power BIかFabricのライセンスが要ります。Power Platformは、Power Platform管理者の役割と、Power Appsのライセンスが前提です。初回は、Microsoft Graph PowerShellへの同意も求められます。求める権限は、Directory.Read.AllやPolicy.Read.Allなど、読み取りの7つです。

Google Workspace版は事情が違います。ScubaGogglesは特権管理者の役割を前提にしていて、求める権限の範囲にも、読み取り専用でないもの（グループの設定など）が混じります。CISAはこの点を、グループの閲覧者の役割を使う仕組みで抑えているとしています。動かす端末と、作ったOAuthのクライアントやサービスアカウントは、点検が終わったら片づける前提で用意したいところです。

もう一つ気をつけたいのが、結果のファイルです。ScubaResultsのJSONには、テナントから読み取った設定がそのまま入ります。HTMLの報告にも、テナントのドメイン名や特権を持つ利用者の一覧が載ります。設定のバックアップと同じ重さで扱い、チケットやチャットに貼らず、置き場所を決めておくべきでしょう。

試すときの段取り

1. Windows PowerShell 5.1を開き、Install-Module -Name ScubaGearで入れる。1.x系が入っているならUpdate-ScubaGearで2.0に上げる
2. Install-ScubaDependenciesで、依存するモジュールとOPAを入れる
3. グローバル閲覧者の点検用アカウントで、設定ファイルなしのInvoke-SCuBA -ProductNames *を一度動かす
4. 出てきたBaselineReports.htmlを読み、ActionPlan.csvで不合格の必須項目を洗い出す
5. 基準どおりにしないと決めた項目は、設定ファイルのOmitPolicyやAnnotatePolicyに理由と一緒に書く。2回目からは-ConfigFilePathと-SilenceBODWarningsを付けて動かす
6. 結果のフォルダーは置き場所を限って残し、次の点検でInvoke-SCuBADiffにかけて前回と比べる

1.x系の設定ファイルがある会社は、3の前にdefenderをsecuritysuiteに直しておきます。

例外を書くことが、規程の下書きになる

この基準は、米国の政府機関が想定する脅威と、許せるリスクの幅に合わせてあります。日本の会社が全部を満たす必要はありません。

ただ、外れた項目ごとに「うちはなぜ違うのか」を設定ファイルに1行ずつ書いていくと、それがそのまま、Microsoft 365の設定の規程の下書きになります。監査や取引先のチェックシートで設定の根拠を聞かれたとき、出せるものが一つ増えるはずです。年に一度の点検を、来年は前回との差分を見るだけで済ませる。そこまで持っていければ、半日の画面めぐりから解放されます。