ランサムウェアの脅威を軽減するためのWindowsのヒント

Scattered Spiderのニュースが最近も思い出させてくれているように、ランサムウェアは常に脅威です。このグループは何年も前から存在しており、今年は業界から業界へと標的を変え、新たなターゲットを探しています。ソーシャルメディアを利用して人間関係を特定し、フィッシング攻撃の対象を絞り込むだけでなく、このグループはヘルプデスク担当者になりすますことや、さまざまな手法を使ってアクセス権を得たり、ネットワークのターゲットを特定したり、データベースやストレージコンテナを攻撃するためにクラウド上の場所を監視したりしています。

Scattered Spiderのような攻撃者が私たち自身よりもネットワークについて詳しいと感じるなら、それはおそらく事実です。彼らが知っていることの一つは、ほとんどの企業がパスキーのような最新のパスワード管理方法を使っていないということです。もしまだ通常のパスワードを使い、多要素認証（MFA）も導入していないのであれば、すでに攻撃されていないとしても、時間の問題だと考えてください。

この夏、Windows 11への移行を最優先事項にする際には、組織のパスワード戦略を見直し、パスキーのようなパスワードレスソリューションを認証体制に導入することを検討しましょう。ここから始めてみてください。

安全なパスキー登録を確保する

まず、Microsoft Authenticatorアプリの利用状況を評価し、パスキーに対応させていることを確認してください。

Microsoft Entra管理センターにアクセスし、「保護」→「認証方法」へ進みます。Passkey（FIDO2）の設定を選択し、まだ導入を始めていない場合は、Microsoft Authenticator用にiPhoneおよびAndroid AAGUIDを許可されたキーとして選択してください。

Susan Bradley / CSO

次に、条件付きアクセスのポリシーを追加し、ユーザーのサインインがさまざまな条件で評価されるようにします。例えば、不適切な移動（ある場所からログインした直後に、地理的に大きく離れた場所から再度ログインするなど）です。このレベルのクラウド監査をサポートするには、追加のライセンス契約が必要になる場合があります。

リスクが高い場合は、信頼できる場所やデバイスからのみMFAやパスキー登録を許可するログインポリシーを設定する必要があるかもしれません。パンデミック以降、ほぼどこからでもログインできるようになりましたが、Windows 11への移行を控えた今こそ、自分たちの条件で設定を確認する時です。

パスポートの申請と同様の追加設定ポリシーも検討しましょう。たとえば、本人が物理的な場所に来て身分証明書を提示し、外部認証を行う、または政府サイトのID.meのように、運転免許証のスキャンとウェブカメラによる本人確認を義務付けるプロセスです。

登録プロセスは、組織のニーズだけでなく、採用候補者に関する地域のプライバシー規制にも準拠する必要があります。

認証プロトコルを管理する

セキュリティは常に監視・調整が必要なため、Azureインフラストラクチャを見直し、最新のセキュリティガイダンスやAzureセキュリティベンチマークに従っているか確認しましょう。

その際、レガシー認証プロトコルの必要性も見直してください。SMBのバージョンは制限しましょう。NTLMはすでに廃止済み、またはKerberosやより新しい技術へ移行中であるべきです。

もしレガシー認証を使っている場合は、サードパーティ製のソリューションで多要素認証を追加し、できる限り保護しましょう。duo.comのようなサービスは、まだインフラの重要な部分を担う非安全なプロトコルを守るのに役立ちます。

レガシー認証プロトコルをブロックするポリシーの設定も検討しましょう。再度、条件付きアクセスを利用して、こうしたアクセスを制限するポリシーを設定します。ポリシー展開前に、組織内でまだレガシープロトコルを使っている項目を監査しましょう。

1. Entra ID > 監視とヘルス > サインインログに移動します。
2. 「列」→「クライアントアプリ」をクリックして、クライアントアプリの列を追加します（表示されていない場合）。
3. 「フィルターを追加」→「クライアントアプリ」→すべてのレガシー認証プロトコルを選択し、「適用」をクリックします。
4. 「ユーザーサインイン（非対話型）」タブでも同様の手順を実施します。

基本情報タブのクライアントアプリ欄で、どのレガシー認証プロトコルが使われているか確認します。こうしたプロトコルを確認するには、ポータルのレガシービューに戻る必要がある場合もあります。

Susan Bradley / CSO

理想的には、こうしたプロトコルは一切使われていない状態が望ましいです。

Susan Bradley / CSO

その後、これらのレガシープロトコルをブロックするポリシーを準備し、予防策としましょう。

セキュリティと復旧のための追加ヒント

可能であれば、Microsoft 365への認証におけるフェデレーション信頼関係を無効にすることで、攻撃者がオンプレミスのActive DirectoryからMicrosoft 365クラウドサービスへ横展開するリスクを減らせます。

また、オンプレミスADネットワークに一切接続しないクラウド専用のアクセスアカウントを設定しましょう。管理者はクラウドとオンプレミスという2つのネットワークを、できる限り分離し、相互汚染を防ぐべき2つの敵対的環境と考える必要があります。

最後に、こうしたアイデンティティ攻撃に備え、復旧のためのプレイブックを用意しましょう。ランサムウェアや情報漏えいは必ず発生します。以前はバックアップからの復元やADの再構築で十分でしたが、アイデンティティが攻撃者の主な侵入口となった今、攻撃者は再構築作業が進んだ後も、乗っ取ったアイデンティティへの永続的なアクセスを維持しようとします。

アカウントに委任がないか、信頼されたデバイスが突然追加されていないか、権限が変更されていないかなど、攻撃者が侵入中にアクセスを維持するために使う手法を確認してください。これらのプロセスをクリーンアップし、乗っ取られたアカウントからの異常なアクティビティやトラフィックを事後も監視する必要があります。

アカウントによっては、そのアカウントを無効化し、新しいユーザーアカウントでクリーンなアイデンティティを作成し、攻撃者と共有されたトークンや認証手法を一切排除する必要があるかもしれません。単にクリーンアップ・再構築してPCをユーザーに返すだけでなく、インシデントが収束したと判断する前に「アイデンティティのクリーンアップ」が必要です。

好きか嫌いかに関わらず、ランサムウェアは今後も存在し続けます。認証とアクセス方針をしっかり管理することが、その影響に対抗するための強固な基盤となります。