Azure のセキュリティ管理
Azure の利用者は、そのクラウド環境をさまざまなデバイスから管理できます。その中には管理ワークステーションや開発用 PC もあれば、タスク固有の権限を持った特権付きのエンド ユーザー デバイスもあります。 管理作業は、Azure Portal など、Web ベースのコンソールを介して実行する場合もあれば、 仮想プライベート ネットワーク (VPN)、ターミナル サービス、クライアント アプリケーション プロトコル、または (プログラムによる) Azure クラシック デプロイ モデルを介して、オンプレミス システムから Azure への直接接続が存在する場合もあります。 また、クライアントのエンドポイントはドメインに参加している場合と、タブレット、スマートフォンなど、管理下にない孤立したデバイスである場合とがあります。
このように多彩なアクセスと管理が可能であることによって豊富な選択肢が存在する反面、そのばらつきがクラウド デプロイに深刻なリスクをもたらすこともあり、 管理、追跡、監査という管理上の工程が困難になる可能性があります。 そうした選択肢の多さから、クラウド サービスの管理用クライアント エンドポイントの利用に監視の目が行き届かず、セキュリティ上の脅威を招く場合もあります。 インフラストラクチャの開発と管理に共用ワークステーションや個人用ワークステーションを使用することは、Web 閲覧 (水飲み場型攻撃など) や電子メール (ソーシャル エンジニアリング、フィッシングなど) などの予測不可能な脅威要因にさらされる原因となります。
Azure のインターフェイス (SMAPI など) に対する多種多様なエンドポイントからのアクセスを適切に管理するセキュリティ ポリシーやセキュリティ メカニズムを構築することは困難であるため、この種の環境は攻撃のリスクが大きくなります。
リモート管理の脅威
攻撃者はえてして、アカウントの資格情報を不正に利用したり (パスワードのブルート フォース攻撃、フィッシング、資格情報の採集など)、ユーザーを欺いて有害なコード (悪質な Web サイトからドライブバイ ダウンロードで、または悪質な電子メール添付ファイルから) を実行させたりするなどして特権アクセスの取得を試みます。 リモートから管理されるクラウド環境では、いつ、どこからアクセスされるかわからないために、アカウント侵害はリスクの増大につながります。
主要な管理者アカウントを厳しく規制しても、それよりも低いレベルのユーザー アカウントが、セキュリティ戦略の弱点を攻略する目的で悪用される可能性があります。 またセキュリティに対する訓練が不足しているために、アカウント情報が意図せず漏えいし、侵害につながることもあります。
ユーザーのワークステーションが管理作業にも使われていると、さまざまな部分に侵入の隙が生じます。 ユーザーがサードパーティのオープン ソース ツールを使用して Web を閲覧することもあれば、トロイの木馬が忍ばされた悪質なドキュメント ファイルを開くこともあります。
一般に、データの侵害は、デスクトップ コンピューターに対するスピア フィッシング (電子メール)、ブラウザーの脆弱性の悪用やプラグイン (Flash、PDF、Java など) に端を発しており、それらが攻撃の最大の標的となっています。 これらのコンピューターには、開発や他の資産の管理を目的とした業務に関して、運用サーバーや運用ネットワーク デバイスに対する管理者レベルまたはサービス レベルのアクセス権限が割り当てられている場合があります。
運用上のセキュリティの基本
管理と運用のセキュリティは、侵入の危険のあるポイントを減らしてクライアントの攻撃対象領域を小さくすることで強化できます。 これは、"職務の分離" と "環境の分離" というセキュリティ原則を実施することで達成できます。
機密性が求められる部門を他の部門から切り離すことで、複数のレベルにセキュリティ侵害が広がるリスクを減らします。 例 :
- セキュリティの侵害を招く危険性がある業務は、管理タスクから切り離してください (たとえば管理者が受け取ったメールにマルウェアが添付されていると、インフラストラクチャ サーバーにまで感染が広がります)。
- 機密性の高い操作に使用するワークステーションは、インターネットの閲覧といった高いリスクを伴う用途に使用しないでください。
不要なソフトウェアを削除することによって、システムの攻撃対象領域を減らします。 例:
- 管理、サポート、開発に使用される標準的なワークステーションには、そのデバイスの主な目的がクラウド サービスを管理することであるならば、メール クライアントなどの生産性アプリケーションをインストールする必要はありません。
インフラストラクチャ コンポーネントに対する管理者アクセス権を持つクライアント システムには、可能な限り厳格なポリシーを適用して、セキュリティ リスクを軽減する必要があります。 例 :
- デバイスからのオープン インターネット アクセスを拒否し、制限の厳しいファイアウォール構成を使用するグループ ポリシー設定をセキュリティ ポリシーに含める。
- 直接アクセスが必要である場合はインターネット プロトコル セキュリティ (IPsec) VPN を使用する。
- 管理用と開発用に別々の Active Directory ドメインを構成する。
- 管理用ワークステーションのネットワーク トラフィックを隔離してフィルタリングする。
- マルウェア対策ソフトウェアを使用する。
- 多要素認証を導入して資格情報の盗難リスクを小さくする。
さらにアクセス リソースを一元管理し、未管理のエンドポイントをなくすことで、管理タスクを省力化することができます。
Azure のリモート管理に対するセキュリティの確保
Azure には、そのクラウド サービスと仮想マシンの管理者を支援するセキュリティ メカニズムが備わっています。 その例を次に示します。
- 認証と Azure ロールベースのアクセス制御 (Azure RBAC)。
- 監視、ログ、監査。
- 証明書と通信の暗号化。
- Web 管理ポータル。
- ネットワーク パケット フィルタリング。
クライアント側のセキュリティ構成とデータセンターにデプロイされた管理ゲートウェイによって、クラウドのアプリケーションやデータに対する管理者のアクセスを制限したり監視したりすることができます。
Note
この記事で紹介しているいくつかの推奨事項に従った場合、結果的にデータやネットワーク、コンピューティング リソースの使用量が増加したり、ライセンス コストやサブスクリプション コストが増大したりする場合があります。
管理用ワークステーションの堅牢化
ワークステーションを堅牢化するにあたっての目標は、その運用上、最も重要な機能以外を排除することによって、潜在的な攻撃対象領域をできるだけ小さくすることです。 システムの堅牢化には、インストールされているサービスやアプリケーションの数を減らすことや、アプリケーションの実行を制限すること、ネットワーク アクセスを必要最小限にすること、システムを常に最新の状態に保つことが含まれます。 そのうえで堅牢化したワークステーションを管理用途に使用することによって、管理ツールや管理作業を他のエンド ユーザーの作業から隔離します。
オンプレミスのエンタープライズ環境では、専用の管理ネットワークや、ID カードで入退出を制限するサーバー ルーム、保護されたネットワーク領域で動作するワークステーションによって、物理インフラストラクチャの攻撃対象領域を制限します。 クラウド型やハイブリッド型の IT モデルでは、IT リソースへの物理的なアクセス手段の欠落から、管理サービスの安全性を徹底することが他のモデルと比べて複雑である場合があります。 保護ソリューションを導入するためには、入念なソフトウェア構成、セキュリティにフォーカスしたプロセス、包括的なポリシーが必要です。
クラウド管理とアプリケーション開発用にロックダウンされたワークステーションでは、使用ソフトウェアに付与する特権を最小限にし、リモート管理と開発環境を標準化することによって、セキュリティ インシデントのリスクを小さくすることができます。 ワークステーションの構成にしっかりとしたセキュリティを適用することによって、脆弱性の悪用やマルウェアに多く使用される経路を遮断し、重要なクラウド リソースの管理に使用するアカウントの侵害を防ぐことができます。 具体的には、Windows AppLocker と Hyper-V テクノロジを使用して、クライアント システムの動作を制御、隔離し、メールやインターネット閲覧などの脅威を緩和することができます。
堅牢化したワークステーションで管理者が使用するのは標準ユーザー アカウントです。これで管理レベルの実行がブロックされます。また、関連するアプリケーションは許可リストによって制御されます。 ワークステーションの堅牢化は、基本的に次の要素で構成されます。
- 積極的なスキャンと修正プログラムの適用。 マルウェア対策ソフトウェアをデプロイし、脆弱性を定期的にスキャンします。また適切なタイミングで最新のセキュリティ更新プログラムを適用することによってすべてのワークステーションを最新の状態に保ちます。
- 機能の制限。 不要なアプリケーションはすべてアンインストールし、不要な (スタートアップ) サービスは無効にします。
- ネットワークの堅牢化。 Windows ファイアウォール ルールを使用して、Azure の管理に関連した有効な IP アドレス、ポート、URL だけを許可します。 リモートからワークステーションへの受信接続も確実にブロックしてください。
- 実行の制限。 管理に必要な定義済みの一連の実行可能ファイルのみ実行を許可します ("default deny")。 既定では、許可リストで明示的に定義されている場合を除き、ユーザーに対するプログラムの実行権限は自動的に拒否する必要があります。
- 最小特権。 管理用ワークステーションのユーザーに、ローカル コンピューター自体の管理者権限を割り当てることは避けます。 そうすれば、意図的であれ不注意であれ、システムの構成やシステム ファイルに変更を加えることはできなくなります。
以上の要素はすべて、Active Directory Domain Services (AD DS) のグループ ポリシー オブジェクト (GPO) を使用し、(ローカル) 管理ドメインを通じてすべての管理アカウントに適用することで履行を強制できます。
サービス、アプリケーション、データの管理
Azure クラウド サービスの構成は、Azure ポータルを使用して行うか、Windows PowerShell コマンドライン インターフェイスまたはカスタム アプリケーションで SMAPI の RESTful インターフェイスを介して行います。 このメカニズムを使ったサービスには、Microsoft Entra ID、Azure Storage、Azure Websites、Azure Virtual Network などがあります。
Virtual Machines にデプロイされるアプリケーションには、必要に応じて独自のクライアント ツールとインターフェイスが用意されています。Microsoft 管理コンソール (MMC) やエンタープライズ管理コンソール (Microsoft System Center、Windows Intune など)、各種管理アプリケーション (Microsoft SQL Server Management Studio など) がその例です。 こうしたツールは通常、企業環境内やクライアント ネットワーク内で動作するものであり、 リモート デスクトップ プロトコル (RDP) など、ステートフルな直接接続を必要とする特定のネットワーク プロトコルに依存している場合があります。 一部には Web 対応インターフェイスを備えているものもあり、そのままインターネットに公開したりインターネット経由でのアクセスを許可したりすることが望ましくない場合もあるでしょう。
Azure では、多要素認証、X.509 管理証明書、およびファイアウォール規則を使ってインフラストラクチャやプラットフォームのサービス管理へのアクセスを制限できます。 Azure ポータルと SMAPI には、トランスポート層セキュリティ (TLS) が必要となります。 一方、Azure にデプロイするサービスやアプリケーションには、アプリケーションに応じた適切な防御手段が求められます。 堅牢化したワークステーションの構成が標準化されていれば、こうしたメカニズムに何度でも簡単に対応することができます。
セキュリティ ガイドライン
一般に、クラウドでの用途に合わせて管理者が使うワークステーションのセキュリティを高めることは、オンプレミスのワークステーションに適用される慣例と似ています。 たとえば、必要最小限の機能構成とアクセス許可などです。 またクラウドの管理に伴ういくつかの作業は、企業向けのリモート管理やアウトオブバンド管理に酷似しています。 その例として、資格情報の使用や監査、リモート アクセスのセキュリティ強化、脅威の検出と対応が挙げられます。
認証
監査アクセス要求や管理ツールへのアクセスに使用される発信元 IP アドレスは、Azure のログオン制限を使用して規制できます。 管理クライアント (ワークステーションやアプリケーション) を Azure が識別できるように、SMAPI (Windows PowerShell のコマンドレットなど、ユーザーが開発したツールを使用) と Azure portal の両方を、TLS/SSL 証明書に加え、クライアント側の管理証明書のインストールを必須にするように構成できます。 加えて管理者アクセスに、多要素認証を義務付けることをお勧めします。
Azure にデプロイされるアプリケーションやサービスには、エンド ユーザーと管理者アクセスの両方に独自の認証メカニズムが採用されている場合もあれば、認証をすべて Microsoft Entra ID で行う場合もあります。 Active Directory フェデレーション サービス (AD FS) を使って資格情報を連携させるか、ディレクトリ同期を使用するか、ユーザー アカウントをクラウドにのみ保持するかに応じて、リソース間の ID ライフサイクルは、Microsoft Identity Manager (Microsoft Entra ID P1 または P2 に付属) を使って管理できます。
接続
クライアントと Azure 仮想ネットワークとの間には、いくつかの機構によって接続のセキュリティを確保できます。 これらのうち、サイト間 VPN (S2S) とポイント対サイト VPN (P2S) の 2 つのメカニズムでは、業界標準の IPsec (S2S) を使用した暗号化とトンネリングが可能となります。 Azure Portal などの公開されている Azure サービス管理機能に Azure から接続するときは、HTTPS (ハイパーテキスト転送プロトコル セキュア) が必須となります。
堅牢化したスタンドアロン ワークステーションは、Azure への接続に RD ゲートウェイを介さない場合、SSTP ベースのポイント対サイト VPN を使用し、Azure Virtual Network に対する最初の接続を作成したうえで、VPN トンネルで個々の仮想マシンに対して RDP 接続を確立するようにしてください。
管理の監査とポリシーの適用
通常、管理プロセスのセキュリティを確保するには、監査とポリシーの適用という 2 とおりの方法があります。 その 2 つの方法で包括的な管理は実現しますが、それだけでは対処できない状況もあります。 加えて 2 つの方法は、特に個人とシステム アーキテクチャに置く信頼のレベルに関して、セキュリティの管理に関連したリスクのレベルやコスト、労力が異なります。
監視、ログ、監査は、管理作業の追跡と把握の基礎となるものですが、生成されるデータの量が膨大であるため、それですべてのアクションを常に細部まで監査できるわけではありません。 とはいえ、管理ポリシーの効果の監査は積極的に行うことをお勧めします。
アクセスを厳しく制御するポリシーの適用で、管理者の操作をプログラミングによって統制する働きが生まれ、有力な防御手段をすべて確実に利用することができます。 ログは、いつだれが、どこから何を行ったかの記録となるだけでなく、ポリシーが適用されていることの裏付けとなります。 また、管理者のポリシー準拠状況について情報の監査と照合が可能となり、活動の証拠を残すことができます。
クライアントの構成
ワークステーションの堅牢化に関して Microsoft は基本となる 3 つの構成を推奨しています。 3 つの構成の最も大きな違いは、かかる費用と使いやすさ、利用しやすさであり、どの構成を選んでも同様のセキュリティ プロファイルが維持されます。 以下の表は、それぞれの構成の長所と欠点を簡単に分析したものです。 "企業 PC" とは、役割に関係なくすべてのドメイン ユーザーを対象にデプロイされる標準的なデスクトップ PC の構成を指します。
| 構成 | メリット | 短所 |
|---|---|---|
| スタンドアロン ワークステーションの堅牢化 | ワークステーションを厳しく管理できる | 専用デスクトップであるためコストが大きい |
| - | アプリケーションの脆弱性の悪用リスクを軽減できる | 管理の負担が増える |
| - | 職務に応じて明確に分離できる | - |
| 仮想マシンとしての企業 PC | ハードウェア コストを削減できる | - |
| - | 職務やアプリケーションを分離できる | - |
堅牢化の対象となるワークステーションはゲストではなくホストであり、ホスト オペレーティング システムとハードウェアの間には何もない、ということが重要です。 "クリーン ソースの原則" ("セキュア オリジン" ともいいます) に従えば、最も堅牢なセキュリティはホストに適用する必要があります。 そうしないと、ホスト システムが攻撃を受けた場合に、その影響がゲストにまで波及します。
堅牢化する各ワークステーションに対して専用のシステム イメージを用意して、特定の Azure アプリケーションとクラウド アプリケーションの管理に必要な最小限のツールと権限を与え、必要なタスクには特定のローカル AD DS GPO を適用することで、管理機能の独立性をさらに高めることができます。
オンプレミス インフラストラクチャを持たない IT 環境 (サーバーがすべてクラウドに存在するために、ローカル AD DS インスタンスへのアクセス権が GPO にないなど) では、Microsoft Intune などのサービスによって、ワークステーション構成のデプロイと管理を省力化することができます。
管理用スタンドアロン ワークステーションの堅牢化
スタンドアロン ワークステーションの堅牢化では、管理タスク用の PC (またはノート PC) と、非管理タスク用の別個の PC (またはノート PC) が管理者に割り当てられます。 スタンドアロン ワークステーションの堅牢化のシナリオ (下図) では、Windows ファイアウォール (またはサードパーティのクライアント ファイアウォール) のローカル インスタンスが、RDP などの受信接続をブロックするように構成されています。 管理者は、堅牢化されたワークステーションにログオンし、Azure Virtual Network との VPN 接続を確立した後で、Azure に接続する RDP セッションを開始できます。一方、企業 PC にログオンし、RDP を使用して、堅牢化されたワークステーションに接続することはできません。
仮想マシンとしての企業 PC
専用のスタンドアロン ワークステーションを堅牢化することがコスト面で難しい場合や都合が悪い場合は、堅牢化したワークステーションで仮想マシンをホストし、非管理タスクはそこで実行するようにします。
システムの管理とその他の日常的な作業とに 1 台のワークステーションを使用することで発生しうるさまざまなセキュリティ リスクを回避するため、堅牢化したワークステーションには Windows Hyper-V 仮想マシンをデプロイします。 この仮想マシンを企業 PC として使用することができます。 企業 PC 環境は、ホストから隔離されたままなので、攻撃対象領域を小さくし、ユーザーの日常的な作業 (電子メールなど) と機微な管理タスクとの共存を避けることができます。
企業 PC 仮想マシンは保護された空間で実行され、ユーザー アプリケーションはそこで実行されます。 ホストは "クリーン ソース" の状態を維持し、ルート オペレーティング システムには厳しいネットワーク ポリシーが適用されます (仮想マシンからの RDP アクセスをブロックするなど)。
ベスト プラクティス
Azure 内のアプリケーションとデータを管理するときは、以下のガイドラインに従ってください。
すべきこととやってはいけないこと
ワークステーションがロックダウンされているからといって、他の一般的なセキュリティ要件に準拠しなくてよい、というわけではありません。 管理者アカウントは通常、アクセス レベルが昇格されているため、その分、潜在的リスクは大きくなります。 以下の表に、セキュリティの観点からすべきこととやってはいけないことの例を示します。
| 次のことは行わないでください | 次のことを行います |
|---|---|
| 管理者アクセスの資格情報やその他のシークレット (TLS/SSL や管理の証明書など) を電子メールで送信しない。 | 機密性を保つために、アカウント名とパスワードは口頭で伝える (留守番電話は不可)。クライアント/サーバーの証明書はリモートから (暗号化されたセッション経由で) インストールする。ダウンロードは保護されたネットワーク共有場所から行う。リムーバブル メディアで手渡しする。 |
| - | 管理証明書のライフ サイクル管理を積極的に実施する。 |
| 暗号化もハッシュも適用されていない状態でアカウントのパスワードをアプリケーションの記憶域 (スプレッドシート、SharePoint サイト、ファイル共有など) に保存することは避ける。 | セキュリティ管理の原則とシステム堅牢化のポリシーを作成して開発環境に適用する。 |
| アカウントとパスワードを管理者どうしで共有したり、複数のユーザー アカウントや複数のサービスに同じパスワードを使用したりすることは避ける。特に、ソーシャル メディアなど、管理以外の作業に使用するパスワードは再利用しない。 | Azure サブスクリプションを管理するための専用の Microsoft アカウント (個人の電子メールに使用されていないアカウント) を作成する。 |
| 構成ファイルを電子メールで送信しない。 | 構成ファイルとプロファイルは、暗号化された USB フラッシュ ドライブなどの信頼のおけるソースからインストールし、電子メールのように、簡単にセキュリティが破られるような機構からインストールすることは避ける。 |
| 弱い (単純な) ログオン パスワードは使用しない。 | 強力なパスワード ポリシー、期限切れサイクル (初回使用時に変更する)、コンソール タイムアウト、自動アカウント ロックアウトを適用する。 パスワード コンテナーへのアクセスに多要素認証を使用したクライアント パスワード管理システムを使用する。 |
| 管理ポートをインターネットに開放しない。 | Azure のポートと IP アドレスをロックダウンして管理アクセスを制限する。 |
| - | すべての管理接続にファイアウォール、VPN、NAP を使用する。 |
Azure の運用
Microsoft による Azure の運用では、Azure の運用環境システムにアクセスする運用エンジニアとサポート担当者は、堅牢化されたワークステーション PC とそこにプロビジョニングされた VM を、内部的な企業ネットワーク アクセスとアプリケーション (電子メール、イントラネットなど) に使用しています。 すべての管理ワークステーション コンピューターは TPM を搭載し、ホストのブート ドライブが BitLocker で暗号化されて、Microsoft の主要な企業ドメイン内の特殊な組織単位 (OU) に参加しています。
システムの堅牢化は、グループ ポリシーの適用とソフトウェア更新の一元化によって行われています。 監査と分析に関しては、管理ワークステーションかイベント ログ (セキュリティと AppLocker) が収集されて一か所に保存されます。
加えて、Azure の運用ネットワークへの接続には、Microsoft のネットワークに置かれた、2 要素認証を必須とする専用のジャンプ ボックスが使用されています。
Azure のセキュリティ チェックリスト
堅牢化したワークステーションに対して管理者が実行できるタスクの数をできるだけ少なくすることで、開発環境と管理環境の攻撃対象領域を最小化できます。 堅牢化したワークステーションの保護には、次のテクノロジを活用できます。
- Web ブラウザーは、外部サーバーとの通信に広く使われているため、悪質なコードの主な侵入ポイントとなっています。 クライアント ポリシーを確認し、保護モードでの実行、アドオンの無効化、ファイルのダウンロードの無効化を徹底してください。 セキュリティ警告が確実に表示されるようにします。 インターネット ゾーンを有効活用し、必要な堅牢化が済んでいる信頼済みサイトのリストを作成します。 その他のサイトとブラウザー内コード (ActiveX、Java など) はすべてブロックしてください。
- 標準ユーザー。 標準ユーザーとして実行することには、さまざまな利点があります。最大の利点は、マルウェアを介して管理者の資格情報を盗むことが、より難しくなる点です。 また標準ユーザー アカウントには、ルート オペレーティング システムに対する昇格された特権がなく、構成オプションや API の多くが既定でロックアウトされています。
- コード署名。 管理者によって使用されるすべてのツールとスクリプトにコード署名を行うことによって、アプリケーションのロックダウン ポリシーをデプロイするための扱いやすいしくみを実現できます。 ハッシュでは、めまぐるしいコード変更に対応できず、また、ファイル パスでは高度なセキュリティが確保できません。 Windows コンピューターの PowerShell 実行ポリシーを設定します。
- グループ ポリシー。 管理用のドメイン ワークステーションとそれらのワークステーションで認証されるユーザー アカウントとに適用されるグローバル管理ポリシーを作成し、それ以外からのアクセスをブロックします。
- プロビジョニングのセキュリティ強化。 ベースラインとなる堅牢化したワークステーション イメージを、改ざんされないよう保護します。 暗号化や分離といったセキュリティ対策を使用してイメージや仮想マシン、スクリプトを保管し、利用を制限します (監査可能なチェックイン/チェックアウト プロセスを使用するなど)。
- 修正プログラムの適用。 機能構成の一貫性を維持 (または開発や運用などの管理タスク用に別途イメージを作成) します。変更やマルウェアがないか定期的にスキャンすると共に、機能構成を最新の状態に保ちます。また、コンピューターは必要なときにだけアクティブ化するようにしてください。
- ガバナンス。 ファイル共有など、管理者のすべての Windows インターフェイスは、AD DS GPO を使用して制御してください。 監査、監視、ログのプロセスに管理ワークステーションを追加します。 管理者と開発者のすべてのアクセスと使用状況を追跡するようにします。
まとめ
Azure のクラウド サービス、仮想マシン、アプリケーションの管理に使用するワークステーションの構成を堅牢化することで、重要な IT インフラストラクチャをリモートから管理することで生じるさまざまなリスクや脅威を排除することができます。 Azure と Windows にはどちらも、通信と認証を保護し、クライアントの動作を制御するための機能が用意されています。
次のステップ
Azure とそれに関連する Microsoft サービスの一般情報については、以下のリソースを参照してください。
- 特権アクセスのセキュリティ保護 – Azure の管理を目的とした安全な管理ワークステーションの設計と構築について、技術的な側面から説明します
- Microsoft トラスト センター – Azure のファブリックと Azure 上で動作するワークロードを保護する Azure プラットフォームの機能について説明します
- Microsoft セキュリティ レスポンス センター - このサイトでは、Azure に関する問題を含め、マイクロソフトのセキュリティの脆弱性を報告できます。メールの場合は、secure@microsoft.com 宛に報告してください。