Azure における機密性の高い IaaS アプリのセキュリティに関する考慮事項

"IaaS (サービスとしてのインフラストラクチャ) " アプリを Azure にデプロイする場合、セキュリティに関する多くの考慮事項があります。 この記事は、Azure のセキュリティの基礎に基づいて、仮想マシンベースのワークロードとハイブリッド ネットワーク インフラストラクチャのリファレンス アーキテクチャを基に、Azure における機密性の高い IaaS ワークロードのセキュリティに焦点を合わせています。

「Azure 仮想マシンのセキュリティの概要」および「Azure における IaaS ワークロードのセキュリティに関するベスト プラクティス」もご覧ください。

Azure VM

Azure のコンピューティング プラットフォームは、マシンの仮想化に基づいています。 "ハイパーバイザー" は、各 Azure ノードまたはネットワーク エンドポイントの物理ハードウェア上で実行され、可変数のゲスト Hyper-V 仮想マシン (VM) をノードに作成します。 すべてのユーザー コードが VM で実行されます。 Azure VM の基本的なデプロイ手順については、「Azure で Linux 仮想マシンを実行する」または「Azure で Windows 仮想マシンを実行する」をご覧ください。 ほとんどのデプロイ プロセスは 2 つのオペレーティング システム (OS) で同じですが、ディスク暗号化などの OS 固有のツールは異なる場合があります。

Microsoft Defender for Cloud を使用して、VM の修正プログラムを管理したり、マルウェア対策ツールをデプロイして監視したりできます。 代わりに、独自またはサードパーティの修正プログラム適用ツールやマルウェア対策ツールを管理することもできます。既存のインフラストラクチャを Azure に拡張または移行する場合はこれが一般的です。

Microsoft では、Azure プラットフォームの一部として、基本的な "分散型サービス拒否 (DDoS) " 保護を提供しています。 パブリック エンドポイントを持つアプリでは、Azure DDoS Protection Standard を使用して保護を強化できます。 ただし、機密性の高いワークロードには、通常、パブリック エンドポイントがないので、"仮想プライベート ネットワーク (VPN) " または専用回線を介して特定の場所からのみアクセスできます。

n 層アーキテクチャ

多くの IaaS アプリケーションは、複数の VM でホストされている複数の層 (Web 層、ビジネス層、データ層など) で構成されています。 Azure VM への "n 層" アプリ アーキテクチャのデプロイの重要な側面は次のとおりです。

• 高可用性 (HA)。 HA アプリは、99.9% 以上の時間において使用可能である必要があります。 異なる Azure 可用性ゾーンに層内の VM を配置することで、HA を確保できます。これは、可用性ゾーンが、1 つ以上のデータセンターに広がっており、データセンターの障害への耐性による回復性を提供するためです。 可用性ゾーンをサポートしていないリージョンでは、可用性セットを使用することで、複数の分離されたハードウェア ノードに VM を分散させることができます。
• 負荷分散。 ロード バランサーは、負荷を分散し、VM に障害が発生したときの回復性を確保するために、複数の VM にトラフィックを分散します。 アプリケーションが負荷分散を管理し、個々の VM が呼び出し元に認識されている場合、ロード バランサーは不要です。
• 仮想ネットワーク。 仮想ネットワークとサブネットによってネットワークをセグメント化することで、セキュリティ管理と高度なルーティングが容易になります。
• ドメイン ネーム システム (DNS) 。 Azure DNS は、可用性が高くセキュリティで保護された DNS サービスを提供します。 Azure DNS のプライベート ゾーンを使用すると、仮想ネットワーク内でカスタム ドメインを使用できます。

バックアップと復元

人的エラー、悪意のあるデータ削除、ランサムウェアから保護するには、少なくともデータ層の VM をバックアップする必要があります。 Azure Backup は、Azure Key Vault の暗号化キーにアクセスできる場合、暗号化された VM をバックアップおよび復元できます。

Web 層とビジネス層では、仮想マシン スケール セットの自動スケーリング ルールを使用して、侵害された VM を自動的に破棄し、ベース イメージから新しい VM インスタンスをデプロイできます。

コンピューティングの分離

各 Azure ノードまたはネットワーク エンドポイントでは、ハイパーバイザーと特別なルート OS により、ゲスト VM が物理ホスト サーバーにアクセスできないことが保証され、ユーザー コードはゲスト VM でのみ実行されます。 この分離により、ユーザーはシステムへの生の読み取り、書き込み、または実行アクセス権を取得できなくなり、リソース共有のリスクが軽減されます。 Azure では、ハイパーバイザーと高度な VM 配置アルゴリズムによって、既知のすべての "サイドチャネル攻撃" と "うるさい隣人" から保護します。 詳細については、「コンピューティングの分離」をご覧ください。

機密性の高いワークロードの場合、分離された VM または専用ホストを使用して、サイドチャネル攻撃からの保護を強化できます。

分離された VM

分離された VM は、特定のハードウェアの種類に分離される、単一顧客専用の大きな VM サイズです。 分離された VM サイズを使用すると、お使いの VM が特定のサーバー インスタンス上で実行されている唯一の VM であることが保証されます。 入れ子になった仮想マシンの Azure サポートを使用することで、分離された VM のリソースをさらに分割できます。

分離された VM の最小サイズは、仮想 CPU が 64 コア、メモリが 256 GiB です。 これらの VM は、ほとんどの n 層アプリケーションに必要なサイズよりもはるかに大きいので、コストのオーバーヘッドが大きくなる可能性があります。 オーバーヘッドを削減するために、入れ子になった仮想化を使用する単一の VM、あるいは異なるプロセスまたはコンテナーで、アプリの複数の層を実行できます。 その場合も、回復性を確保するためにさまざまな VM を可用性ゾーンにデプロイし、個々の VM で非武装地帯 (DMZ) アプライアンスを実行する必要があります。 経済的な理由から 1 つのインフラストラクチャ上で複数のアプリを組み合わせると、組織のアプリ分離ポリシーに抵触する場合もあります。

Azure リージョンの機能が徐々に拡張されていくにつれて、Azure では特定の VM サイズから分離の保証を削除する可能性もあります (1 年前に通知されます)。

Azure 専用ホスト

Azure Dedicated Host は、機密性の高いワークロードに適したコンピューティング分離ソリューションです。 専用ホストとは、複数の VM をホストするための、1 顧客専用の物理サーバーです。 VM の分離に加え、専用ホストを使用すると、メンテナンスや VM の配置を制御してうるさい隣人を回避できます。

専用ホストは、最小サイズおよびサイズに関する考慮事項の多くが分離された VM と同じです。 ただし、専用ホストは、アプリケーション分離ポリシーを満たすために、異なる仮想ネットワークにある VM をホストできます。 DMZ 内の侵害された VM によるサイドチャネル攻撃を防ぐために、引き続き DMZ VM を別のホストで実行する必要があります。

暗号化

データ暗号化は、ワークロードをセキュリティで保護する重要なコンポーネントです。 暗号化によって情報がエンコードされ、承認済みの受信者だけがキーまたは証明書を使用してデコードできます。 暗号化には、保存時のデータ暗号化に使用する "ディスク暗号化" と、ネットワークを介した転送中の暗号化に使用する "トランスポート層セキュリティ (TLS) " があります。

Azure Key Vault

暗号化キーと証明書は、Azure Key Vault に格納することで保護できます。これは、連邦情報処理標準 (FIPS) 140-2 レベル 2 で検証されたクラウド ハードウェア セキュリティ モジュール (HSM) ソリューションです。 承認済みのアプリケーションとユーザーにのみ、Key Vault へのアクセスを許可するためのベスト プラクティスについては、「キー コンテナーへのアクセスをセキュリティで保護する」をご覧ください。

Key Vault のキーを保護するには、論理的な削除を有効にします。これにより、削除されたキーを確実に回復できます。 保護を強化するために、キーの復元に使用できる暗号化されたファイルに個々のキーをバックアップできます。場合によっては、同じ地域の別の Azure リージョンにバックアップすることもできます。

VM で SQL Server をホストする場合は、SQL Server コネクタ for Microsoft Azure Key Vault を使用して、Transparent Data Encryption (TDE) 、"列レベルの暗号化 (CLE) "、バックアップ暗号化のキーを取得できます。 詳細については、「Azure Virtual Machines 上の SQL Server 向け Azure Key Vault 統合の構成」をご覧ください。

Azure Disk Encryption

Azure Disk Encryption では、BitLocker 外部キー保護機能を使用して、Azure VM の OS ディスクとデータ ディスクのボリューム暗号化を提供します。ディスク暗号化のキーとシークレットを制御および管理できるように、Azure Key Vault と統合できます。 各 VM は独自の暗号化キーを生成し、Azure Key Vault に格納します。 Azure Disk Encryption を有効にするように Azure Key Vault 構成するには、「Azure Disk Encryption 用のキー コンテナーの作成と構成」をご覧ください。

機密性の高いワークロードの場合、セキュリティをさらに強化するために、"キー暗号化キー (KEK) " も使用する必要があります。 KEK を指定すると、Azure Disk Encryption では、Key Vault に書き込む前に、そのキーを使用して暗号化シークレットをラップします。 KEK は Azure Key Vault で生成できますが、より安全な方法は、オンプレミスの HSM でキーを生成し、Azure Key Vault にインポートすることです。 このシナリオは、多くの場合、Bring Your Own Key または BYOK と呼ばれています。 インポートされたキーは HSM の境界から出ることができないため、HSM でキーを生成すると、暗号化キーを完全に制御できるようになります。

HSM で保護されたキーの詳細については、Azure Key Vault の HSM で保護されたキーを生成および転送する方法に関する記事をご覧ください。

ネットワーク トラフィックの暗号化

HTTPS などのネットワーク プロトコルでは、証明書を使用して転送中のデータを暗号化します。 クライアントとアプリケーション間のトラフィックでは、通常、信頼された "証明機関 (CA) " の証明書を使用します。 内部アプリでは、内部 CA またはパブリック CA (DigiCert や GlobalSign など) の証明書を使用できます。 階層間の通信では、通常、内部 CA によって発行された証明書 (自己署名証明書) を使用します。 Azure Key Vault は、これらの証明書の種類のいずれにも対応できます。 さまざまな種類の証明書の作成方法の詳細については、「証明書の作成方法」をご覧ください。

Azure Key Vault は、階層間トラフィックの自己署名証明書の CA として機能することができます。 "Key Vault VM 拡張機能" では、ユース ケースに応じた秘密キーの有無に関係なく、VM 上の指定された証明書の監視と自動更新を提供します。 Key Vault VM 拡張機能を使用するには、「Linux 用の Key Vault 仮想マシン拡張機能」または「Windows 用の Key Vault 仮想マシン拡張機能」をご覧ください。

Key Vault には、証明書を使用しないネットワーク プロトコルのキーも格納できます。 カスタム ワークロードでは、Key Vault からキーを取得し、アプリケーションで使用できるように保存するカスタム スクリプト拡張機能のスクリプトを作成することが必要になる可能性があります。 アプリで VM のマネージド ID を使用して、Key Vault から直接シークレットを取得することもできます。

ネットワークのセキュリティ

ネットワーク セキュリティ グループ (NSG) は、Azure 仮想ネットワーク内のリソース間のトラフィックをフィルター処理します。 NSG セキュリティ規則では、IP アドレスとポートに基づいて、Azure リソースとの間のネットワーク トラフィックを許可または拒否します。 既定では、NSG はインターネットからの受信トラフィックをブロックしますが、VM からインターネットへの送信接続は許可します。 偶発的な送信トラフィックを防ぐには、優先度が最も低い (4096) カスタム規則を追加して、すべての受信トラフィックと送信トラフィックをブロックします。 その後、優先度の高い規則を追加して、特定のトラフィックを許可することができます。

NSG では、既存の接続のフロー レコードを作成し、フロー レコードの接続の状態に基づいて通信を許可または拒否します。 フロー レコードにより、NSG はステートフルになることができます。 たとえば、ポート 443 経由で任意のアドレスに送信セキュリティ規則を指定した場合、応答に受信セキュリティ規則を指定する必要はありません。 通信が外部から開始される場合、指定する必要があるのは受信セキュリティ規則のみです。

ほとんどの Azure サービスでは、NSG の代わりに仮想ネットワーク サービス タグを使用できます。 サービス タグは、Azure サービスからの IP アドレス プレフィックスのグループを表します。サービス タグにより、ネットワーク セキュリティ規則の頻繁な更新による複雑さを最小限に抑えることができます。 Azure Key Vault サービス タグを使用すると、VM が Azure Key Vault から証明書、キー、シークレットを取得するのを許可することができます。

ネットワークのセキュリティを制御するもう 1 つの方法は、仮想ネットワーク トラフィックのルーティングと "強制トンネリング" を使用することです。 Azure では、システム ルートが自動的に作成され、仮想ネットワークの各サブネットに割り当てられます。 システム ルートを作成または削除することはできませんが、システム ルートをカスタム ルートでオーバーライドすることはできます。 カスタム ルーティングを使用すると、ファイアウォールやプロキシなどの "ネットワーク仮想アプライアンス (NVA) " を介してトラフィックをルーティングできます。また、不要なトラフィックを破棄することもできます。これは、NSG によるトラフィックのブロックと同様の効果があります。

Azure Firewall などの NVA を使用して、ネットワーク トラフィックを許可、ブロック、検査できます。 Azure Firewall は、可用性の高いマネージド プラットフォーム ファイアウォール サービスです。 Azure Marketplace からサードパーティの NVA をデプロイすることもできます。 これらの NVA を高可用性にするには、「高可用性のネットワーク仮想アプライアンスをデプロイする」をご覧ください。

アプリケーション セキュリティ グループ

仮想ネットワーク内のアプリケーション階層間のトラフィックをフィルター処理するには、アプリケーション セキュリティ グループ (ASG) を使用します。 ASG を使用すると、ネットワーク セキュリティをアプリケーションの構造の拡張として構成することができ、VM をグループ化して、グループに基づくネットワーク セキュリティ ポリシーを定義できます。 明示的な IP アドレスを手動で管理せずに、セキュリティ ポリシーを大規模に再利用できます。

ASG は、サブネットではなくネットワーク インターフェイスに適用されるため、マイクロセグメンテーションが可能になります。 相互に通信できる VM を厳密に制御でき、同じ層の VM 間のトラフィックをブロックすることもできます。また、VM から ASG を削除することで、その VM を簡単に検疫できます。

ハイブリッド ネットワーク

ハイブリッド アーキテクチャでは、オンプレミス ネットワークを Azure のようなパブリック クラウドに接続します。 Azure で実行されているアプリケーションにオンプレミス ネットワークを接続するには、いくつかの方法があります。

• インターネット上のパブリック エンドポイント。 ID、トランスポート レベルのセキュリティ (HTTPS)、アプリケーション ゲートウェイを利用して、アプリケーションを保護できます。場合によっては、ファイアウォールと組み合わせることもできます。 ただし、機密性の高いワークロードの場合、インターネット上のパブリックエンド ポイントを公開することはお勧めしません。
• Azure またはサードパーティの VPN ゲートウェイ。 Azure VPN Gateway を使用して、オンプレミス ネットワークを Azure に接続できます。 トラフィックは引き続きインターネット経由で送受信されますが、TLS を使用する暗号化されたトンネルを経由します。 Azure VPN Gateway でサポートされていない特定の要件がある場合は、VM でサードパーティのゲートウェイを実行することもできます。
• ExpressRoute。 ExpressRoute 接続は、サード パーティ製接続プロバイダーを経由する、プライベートの専用接続を使用します。 プライベート接続では、オンプレミス ネットワークを Azure に拡張し、スケーラビリティと信頼性の高いサービス レベル アグリーメント (SLA) を提供します。
  • VPN フェールオーバーを使用する ExpressRoute。 このオプションでは、ExpressRoute を通常の条件で使用しますが、ExpressRoute 回線で接続が失われた場合、VPN 接続にフェールオーバーするので、可用性が向上します。
  • ExpressRoute 経由の VPN。 このオプションは、機密性の高いワークロードに最適です。 ExpressRoute は、スケーラビリティと信頼性を備えたプライベート回線を提供します。また、VPN は、特定の Azure 仮想ネットワークで暗号化された接続を終了する追加の保護レイヤーを提供します。

さまざまな種類のハイブリッド接続の選択に関する詳しいガイダンスについては、「オンプレミス ネットワークを Azure に接続するためのソリューションを選択する」をご覧ください。

DMZ のデプロイ

オンプレミス環境と Azure 環境を接続すると、オンプレミスのユーザーは Azure アプリケーションにアクセスできるようになります。 境界ネットワーク ("非武装地帯 (DMZ) ") により、機密性の高いワークロードの保護を強化できます。

「Azure とオンプレミス データセンターの間のネットワーク DMZ」で示すようなアーキテクチャでは、DMZ とアプリケーション サブネットを分離するための NSG 規則とユーザー定義ルートを使用して、すべての DMZ とアプリケーション サービスを同じ仮想ネットワークにデプロイします。 このアーキテクチャでは、オンプレミスのゲートウェイが利用できない場合でもアプリを管理するために、パブリック インターネットを介して管理サブネットを利用できるようにします。 ただし、機密性の高いワークロードの場合、ゲートウェイのバイパスは緊急時にのみ許可する必要があります。 より優れたソリューションは、Azure Bastion を使用することです。これにより、パブリック IP アドレスの公開を制限しながら、Azure portal から直接アクセスできるようになります。

パブリック IP アドレスの公開を制限しながら、リモート管理に Just-In-Time (JIT) VM アクセスを使用することもできます。 JIT VM アクセスでは、"リモート デスクトップ プロトコル (RDP) " や Secure Shell (SSH) などのリモート管理ポートが NSG によって既定でブロックされます。 要求時に、JIT VM アクセスでは、指定された時間枠でのみ、(場合によっては) 特定の IP アドレスまたは IP 範囲に対してポートを有効にします。 JIT アクセスは、プライベート IP アドレスのみを持つ VM でも機能します。 Azure Bastion を使用して、JIT VM アクセスが有効になるまで VM へのトラフィックをブロックできます。

さらに多くのアプリケーションをデプロイする場合は、Azure でハブスポーク ネットワーク トポロジを使用し、DMZ をハブ仮想ネットワークに、アプリケーションをスポーク仮想ネットワークに配置します。 ハブ仮想ネットワークには、VPN/ExpressRoute ゲートウェイ、ファイアウォール NVA、管理ホスト、ID インフラストラクチャ、その他の共有サービスを含めることができます。 スポーク仮想ネットワークは、仮想ネットワーク ピアリングを使用してハブに接続されます。 Azure 仮想ネットワークでは、スポーク間での、ハブを介した推移的なルーティングは許可されていません。 スポーク間のトラフィックは、ハブのファイアウォール アプライアンスを介してのみ可能です。 このアーキテクチャでは、アプリケーションを相互に効果的に分離します。

複数リージョンのデプロイ

事業継続とディザスター リカバリーには、アプリケーションを複数の Azure リージョンにデプロイすることが必要な場合があり、データ所在地とセキュリティに影響を及ぼす可能性があります。 複数リージョン デプロイのリファレンス アーキテクチャについては、「高可用性を得るために複数の Azure リージョンで N 層アプリケーションを実行する」をご覧ください。

リージョン ペア

Azure の地域とは、少なくとも 1 つの Azure リージョンを含む、世界の定義済みのエリアです。各リージョンには、1 つ以上のデータセンターがあります。 各 Azure リージョンは、"リージョン ペア" で同じ地域内の別のリージョンと組み合わされています。 リージョン ペアでは、2 つのリージョンが同時に更新されることはありません。両方のリージョンで災害が発生した場合は、いずれかのリージョンが優先され、先にオンラインに戻ります。 事業継続のために、複数のリージョンにデプロイする場合は、少なくとも機密性の高いアプリをリージョン ペアにデプロイする必要があります。

詳細については、「ビジネス継続性とディザスター リカバリー (BCDR): Azure のペアになっているリージョン」をご覧ください。 ホワイトペーパー「Azure を使用して基準に準拠しているデータの保存場所とセキュリティを実現する」では、データ所在地の概要と、データ所在地の要件を満たすために必要なことについて説明しています。

リージョン間のレプリケーション

IaaS アーキテクチャでは、リージョン間のデータのレプリケーションはアプリケーションの役割です。 レプリケーションの最も一般的なシナリオでは、データベース サーバー製品に組み込まれているデータベース レプリケーション テクノロジ (SQL Server Always On 可用性グループ、Oracle Data Guard、MySQL レプリケーションなど) を使用します。

IaaS データベース サーバー間のレプリケーションの設定は簡単ではなく、事業継続の要件を考慮する必要があります。 Azure SQL Database、Azure Database for MySQL、Azure Cosmos DB などの Azure データベース サービスを利用すると、リージョン間のレプリケーションが容易になりますが、機密性の高いワークロードのセキュリティ要件を満たさない場合があります。

SQL Server と Oracle の複数リージョン デプロイの詳細とガイダンスについては、次の記事をご覧ください。

• さまざまなリージョンで SQL Server を実行している Azure 仮想マシンに可用性グループを構成する
• Azure 環境内の Oracle Database 12c データベースのディザスター リカバリー

リージョン間ピアリング

グローバル仮想ネットワーク ピアリングを使用して、異なるリージョンの仮想ネットワーク間のセキュリティで保護された通信を有効にすることができます。 グローバル ピアリングは、リージョン内ピアリングと同様に機能します。 リージョン間のトラフィックは Microsoft バックボーン経由で実行され、インターネットを経由せず、他のトラフィックから分離されます。 セキュリティを強化するために、両方のリージョンに VPN NVA をデプロイし、DMZ のデプロイと同様に、"ユーザー定義ルート" を使用して、リージョン間のトラフィックを強制的に NVA 経由にすることができます。

フェールオーバーによるトラフィック ルーティング

パブリックエンド ポイントでは、Traffic Manager または Azure Front Door を使用して、"アクティブ/アクティブ" フェールオーバー構成のアクティブ リージョンまたは最も近いリージョンにトラフィックを転送できます。 ただし、Traffic Manager と Azure Front Door には、どちらも可用性を監視するためにパブリック エンドポイントが必要であり、対応する DNS エントリはパブリックになります。 機密性の高いワークロードの場合、代替ソリューションとして、DNS をオンプレミスにデプロイし、フェールオーバーのためにエントリをアクティブ リージョンに変更します。

管理とガバナンス

機密性の高い IaaS アプリをセキュリティで保護するには、適切なアーキテクチャをデプロイし、ネットワーク セキュリティ規則を実装するだけでは不十分です。 クラウド環境は簡単に変更できるため、セキュリティ ポリシーの範囲内で、特定のアクセス許可でのみ変更できるようにすることが特に重要です。 たとえば、悪意のあるアクターが、インターネットからのトラフィックを許可するようにネットワーク セキュリティ規則を変更できないようにする必要があります。

Azure にワークロードをデプロイするには、1 つ以上の "管理アカウント" が必要です。 管理アカウントのセキュリティ保護は、ワークロードのセキュリティ保護に不可欠です。 詳細については、Microsoft Entra ID でのハイブリッドおよびクラウド デプロイ用の特権アクセスをセキュリティで保護する方法に関する記事を参照してください。

管理サブネットのリソースを使用して、アプリの層を管理する必要があるユーザーにのみ、その層へのアクセス権を付与します。 たとえば、Microsoft Entra ID と共に Microsoft Identity Manager を使用できます。 ただし、クラウドネイティブのシナリオでは、Microsoft Entra Privileged Identity Management (PIM) が推奨されます。

Azure のロールとポリシーを制御する方法は他にもいくつかあります。

• Azure リソースの Azure ロールベースのアクセス制御 (Azure RBAC) を使用すると、組み込みまたはカスタム ロールをユーザーに割り当てることができるため、ユーザーには必要な権限のみが割り当てられます。 Azure RBAC と PIM を組み合わせて、一定期間、特権を昇格させる監査済み承認ワークフローを実装できます。
• ポリシーによって、会社のルール、標準、SLA を適用します。 Azure Policy は、ポリシーの作成、割り当て、管理を行い、リソースがポリシーに準拠しているかどうかを評価する Azure サービスです。
• Azure Blueprints は、ロールの割り当て、ポリシーの割り当て、およびデプロイ テンプレートを組み合わせて、組織の標準、パターン、要件を実装してそれらに従う一連のレプリケート可能な Azure リソースを定義します。 Blueprints では、リソース テンプレートや他のアーティファクトのデプロイを宣言によって調整できます。 ブループリントを自分で作成することも、既存のブループリントを利用することもできます。 たとえば、ISO 27001 共有サービス ブループリントでは、組織の要件に合わせて変更および拡張できる共有サービス ハブがデプロイされます。

監視

Microsoft Defender for Cloud は、環境のセキュリティの維持に役立つ監視とアラートを提供します。 無料サービスでは、OS 修正プログラムの欠如、セキュリティの構成の誤り、基本的なネットワーク セキュリティなどの脆弱性を自動的にチェックします。 Standard 有料版では、行動分析、アダプティブ ネットワークのセキュリティ強化機能、JIT VM アクセスなどの追加機能が提供されます。 全機能の一覧については、「マシンを対象とする機能」をご覧ください。 Defender for Cloud では、Azure Key Vault などの他のリソースに対する脅威の防止も提供します。

Azure Monitor を使用すると、さらに詳細な監視と分析を行うことができます。 ID とアクセスを監視するには、Microsoft Entra アクティビティ ログを Azure Monitor にルーティングします。 また、VM、ネットワーク、Azure Firewall を監視し、強力なログ クエリ機能を使用して、インポートされたログを分析することもできます。 Azure Monitor を "セキュリティ情報イベント管理 (SIEM)" と統合できます。サードパーティの SIEM または Microsoft Sentinel と統合できます。

関連リソース

• n 層アーキテクチャの詳細については、「Apache Cassandra を使用する Azure の Linux N 層アプリケーション」を参照してください。
• Azure Key Vault 仮想マシン拡張機能の使用方法に関するエンドツーエンドのチュートリアルについては、Key Vault に格納された SSL 証明書による Azure の Windows 仮想マシン上の Web サーバーのセキュリティ保護に関する記事をご覧ください。
• Azure Disk Encryption の詳細については、「Linux VM に対する Azure Disk Encryption」または「Windows VM 用の Azure Disk Encryption」をご覧ください。
• Azure のネットワーク セキュリティの詳細については、「Azure のネットワーク セキュリティの概要」をご覧ください。