Azure Monitor デプロイをセキュリティで保護する

2025-06-20

この記事では、Azure Monitor を安全にデプロイする手順と、Microsoft が Azure Monitor をセキュリティで保護する方法について説明します。

ログインジェストとストレージ

ニーズに基づいてワークスペース内のデータへのアクセスを許可する

ワークスペースのアクセス制御モードを [ リソースまたはワークスペースのアクセス許可を使用 する] に設定すると、リソース所有者は、ワークスペースへの明示的なアクセス権を付与されることなく、リソースコンテキストを使用してデータにアクセスできるようになります。これにより、ワークスペースの構成が簡略化され、ユーザーが必要なデータにのみアクセスできるようになります。
手順: Log Analytics ワークスペースへのアクセスを管理する
適切な組み込みロールを割り当てて、責任の範囲に応じて、サブスクリプション、リソースグループ、またはワークスペースレベルで管理者にワークスペースのアクセス許可を付与します。
手順: Log Analytics ワークスペースへのアクセスを管理する
複数のリソースにまたがる一連のテーブルへのアクセスを必要とするユーザーに対して、テーブルレベルの RBAC を適用します。テーブルのアクセス許可を持つユーザーは、リソースのアクセス許可に関係なく、テーブル内のすべてのデータにアクセスできます。
手順: Log Analytics ワークスペースへのアクセスを管理する

トランスポート層セキュリティ (TLS) 1.2 以降を使用してワークスペースにデータを送信する

エージェント、コネクタ、またはログ API を使用してワークスペースにデータを照会または送信する場合は、トランスポート層セキュリティ (TLS) 1.2 以降を使用して転送中のデータのセキュリティを確保します。以前のバージョンの TLS と Secure Sockets Layer (SSL) には脆弱性があり、下位互換性を実現するために引き続き機能する可能性はありますが、 推奨されておらず、業界はこれらの古いプロトコルのサポートをすぐに中止するように移行しました。

PCI Security Standards Council は、古いバージョンの TLS/SSL を無効にし、より安全なプロトコルにアップグレードするために、2018 年 6 月 30 日の期限を設定しました。 Azure がレガシサポートを削除すると、エージェントが TLS 1.2 以上で通信できない場合、Azure Monitor ログにデータを送信できなくなります。

必要な場合を除き、TLS 1.2 のみを 使用するようにエージェント、データコネクタ、または API アプリケーションを明示的に構成しないでください。将来のセキュリティ標準を自動的に検出、ネゴシエート、利用できるようにすることをお勧めします。そうしないと、新しい標準によるセキュリティ強化が使用できなくなり、TLS 1.2 が廃止され、新しい標準が採用されたときに、問題が発生する可能性があります。

重要

2025 年 7 月 1 日に、 Azure 全体のレガシ TLS の廃止に合わせて、Azure Monitor ログの TLS 1.0/1.1 プロトコルバージョンが廃止されます。クラス最高の暗号化を提供するために、Azure Monitor ログでは、選択した暗号化メカニズムとしてトランスポート層セキュリティ (TLS) 1.2 および 1.3 が使用されます。

従来の TLS の問題に関する一般的な質問や、サポートされている暗号スイートのテスト方法については、 TLS の問題の解決と Azure Resource Manager TLS サポートに関するページを参照してください。

ログクエリの監査を設定する

ログクエリ監査を構成して、ワークスペースで実行される各クエリの詳細を記録します。
手順: Azure Monitor ログのクエリを監査する
ログクエリ監査データをセキュリティデータとして扱い、 LAQueryLogs テーブルへの安全なアクセスを適切に処理します。
手順: ニーズに基づいてワークスペース内のデータへのアクセスを構成します。
運用データとセキュリティデータを分離する場合は、各ワークスペースの監査ログをローカルワークスペースに送信するか、専用のセキュリティワークスペースに統合します。
手順: ニーズに基づいてワークスペース内のデータへのアクセスを構成します。
Log Analytics ワークスペースの分析情報を使用して、ログクエリの監査データを定期的に確認します。
手順: Log Analytics ワークスペースの分析情報。
承認されていないユーザーがクエリを実行しようとしている場合に通知するログ検索アラートルールを作成します。
手順: ログ検索アラートルール。

監査データの不変性を確保する

Azure Monitor は追加専用のデータプラットフォームですが、コンプライアンスのためにデータを削除するためのプロビジョニングが含まれています。監査データをセキュリティで保護するには:

Log Analytics ワークスペースにロックを設定して、消去、テーブルの削除、テーブルレベルまたはワークスペースレベルのデータ保有期間の変更など、データを削除できるすべてのアクティビティをブロックします。ただし、このロックは削除できることに注意してください。
手順: リソースをロックしてインフラストラクチャを保護する
完全な改ざん防止ソリューションが必要な場合は、変更できないストレージソリューションにデータをエクスポートすることをお勧めします。
1. エクスポートする必要がある特定のデータ型を決定します。すべてのログの種類が、コンプライアンス、監査、またはセキュリティに同じ関連性を持つわけではありません。
2. データエクスポートを使用して、Azure ストレージアカウントにデータを送信します。
  手順: Azure Monitor での Log Analytics ワークスペースデータのエクスポート
3. 不変ポリシーを設定して、データの改ざんから保護します。
  手順: BLOB バージョンの不変ポリシーを構成する

ワークスペース内の機密データをフィルター処理または難読化する

ログデータに機密情報が含まれている場合:

特定のデータソースの構成を使用して、収集すべきでないレコードをフィルター処理します。
データ内の特定の列のみを削除または難読化する必要がある場合は、変換を使用します。
手順: Azure Monitor での変換
元のデータを変更しない必要がある標準がある場合は、KQL クエリで 'h' リテラルを使用して、ブックに表示されるクエリ結果を難読化します。
手順: 難読化文字列リテラル

誤って収集された機密データを消去する

ワークスペースで誤って収集される可能性のあるプライベートデータを定期的に確認します。
不要なデータを削除するには、データ消去を使用します。補助プランを持つテーブル内のデータは、現在削除できないことに注意してください。
手順: Azure Monitor ログと Application Insights での個人データの管理

セキュリティ強化のためにワークスペースを専用クラスターにリンクする

Azure Monitor では、Microsoft マネージドキー (MMK) を使用して、すべての保存データと保存済みのクエリが暗号化されます。専用クラスターに対して十分なデータを収集する場合は、次のような強化されたセキュリティ機能のためにワークスペースを専用クラスターにリンクします。

柔軟性とキーライフサイクル制御を強化するためのカスタマーマネージドキー。 Microsoft Sentinel を使用している場合は、「Microsoft Sentinel のカスタマーマネージドキーの設定」の考慮事項をよく理解しておいてください。
顧客データアクセス要求を確認および承認または拒否するための Microsoft Azure のカスタマーロックボックス。カスタマーロックボックスは、お客様から開始されたサポートチケットまたは Microsoft によって特定された問題に対応しているかどうかにかかわらず、Microsoft のエンジニアが顧客データにアクセスする必要がある場合に使用されます。ロックボックスは現在、Auxiliary プランを使用したテーブルには適用できません。

手順: Azure Monitor ログで専用クラスターを作成および管理する

Azure プライベートリンクを使用してパブリックネットワークからのワークスペースアクセスをブロックする

Microsoft は、エンドツーエンドの暗号化を使用してパブリックエンドポイントへの接続をセキュリティで保護します。プライベートエンドポイントが必要な場合は、 Azure プライベートリンクを使用して、リソースが承認されたプライベートネットワークを介して Log Analytics ワークスペースに接続できるようにします。プライベートリンクを使用して、ExpressRoute または VPN を介してワークスペースデータの取り込みを強制することもできます。

手順: Azure Private Link のセットアップを設計する

Application Insights TLS インジェスト

サポートされる TLS 構成

Application Insights では、トランスポート層セキュリティ (TLS) 1.2 と 1.3 が使用されます。さらに、各バージョンでは、以下の暗号スイートと楕円曲線もサポートされます。

バージョン	暗号スイート	楕円曲線
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	• NistP384 • NistP256
TLS 1.3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

トランスポート層セキュリティ (TLS) 構成の非推奨化

重要

セキュリティを強化するために、Azure では、Application Insights の次の TLS 構成は 2025 年 5 月 1 日に廃止されます。この変更は、 Azure 全体のレガシ TLS 廃止の一部です。

TLS 1.0 および TLS 1.1 プロトコルバージョン
従来の TLS 1.2 および TLS 1.3 暗号スイート
従来の TLS 楕円曲線

TLS 1.0 と TLS 1.1

TLS 1.0 と TLS 1.1 は廃止されます。

TLS 1.2 と TLS 1.3

バージョン	暗号スイート	楕円曲線
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_RSA_WITH_AES_256_GCM_SHA384 • TLS_RSA_WITH_AES_128_GCM_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA256 • TLS_RSA_WITH_AES_128_CBC_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA • TLS_RSA_WITH_AES_128_CBC_SHA	• curve25519
TLS 1.3		• curve25519

詳細については、 Application Insights の FAQ での TLS サポートを参照してください。

アラート

マネージド ID を使用してログ検索アラートルールのアクセス許可を制御する

開発者にとって一般的な課題は、サービス間の通信をセキュリティで保護するために使用されるシークレット、資格情報、証明書、およびキーの管理です。マネージド ID を使用すると、開発者はこれらの資格情報を管理する必要がなくなります。ログ検索アラートルールにマネージド ID を設定すると、アラートルールの正確なアクセス許可を制御および把握できます。いつでも、ルールのクエリアクセス許可を表示し、そのマネージド ID に対するアクセス許可を直接追加または削除できます。

ルールのクエリが Azure Data Explorer (ADX) または Azure Resource Graph (ARG) にアクセスする場合は、マネージド ID の使用が必要です。

手順: ログ検索アラートルールを作成または編集します。

構成特権を必要としないすべてのユーザーに監視閲覧者ロールを割り当てる

ユーザーにロールに必要な最小限の特権を付与することで、セキュリティを強化します。

手順: Azure Monitor のロール、アクセス許可、セキュリティ。

セキュリティで保護された Webhook アクションを可能な限り使用する

アラートルールに Webhook アクションを使用するアクショングループが含まれている場合は、セキュリティで保護された Webhook アクションを使用して認証を強化することをお選びください。

手順: Secure webhook の認証を構成します。

ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマーマネージドキーを使用します。

Azure Monitor は、Microsoft マネージドキー (MMK) を使用して、保存されているすべてのデータと保存されたクエリを暗号化します。独自の暗号化キーを必要とし、専用クラスターに十分なデータを収集する場合は、カスタマーマネージドキーを使用して、柔軟性とキーのライフサイクル制御を強化します。

手順: カスタマーマネージドキー。

Microsoft Sentinel を使用する場合は、「Microsoft Sentinel カスタマーマネージドキーの設定」を参照してください。

仮想マシンの監視

Azure セキュリティサービスを使用して VM のセキュリティ監視を実装する

Azure Monitor は VM からセキュリティイベントを収集できますが、セキュリティ監視に使用することを意図したものではありません。 Azure には、完全なセキュリティ監視ソリューションを提供する Microsoft Defender for Cloud や Microsoft Sentinel などの複数のサービスが含まれています。これらのサービスの比較については、セキュリティの監視を参照してください。

Azure プライベートリンクを使用してプライベートエンドポイント経由で VM を Azure Monitor に接続する

手順: Azure Private Link のセットアップを設計する

コンテナー監視

マネージド ID 認証を使用してクラスターを Container insights に接続する

マネージド ID 認証は、新しいクラスターの既定の認証方法です。レガシ認証を使用している場合は、マネージド ID に移行して、証明書ベースのローカル認証を削除します。

手順: マネージド ID 認証に移行する

Azure プライベートリンクを使用してプライベートエンドポイントを介してクラスターから Azure Monitor にデータを送信する

Prometheus 用の Azure マネージドサービスは、既定でパブリックエンドポイントを使用する Azure Monitor ワークスペースにデータを格納します。 Microsoft は、エンドツーエンドの暗号化を使用してパブリックエンドポイントへの接続をセキュリティで保護します。プライベートエンドポイントが必要な場合は、 Azure プライベートリンクを使用して、クラスターが承認されたプライベートネットワークを介してワークスペースに接続できるようにします。プライベートリンクを使用して、ExpressRoute または VPN 経由でワークスペースデータを強制的に取り込むこともできます。

手順: プライベートリンク用にクラスターを構成する方法の詳細については、 Azure Monitor での Kubernetes 監視のプライベートリンクの有効化に関するページを参照してください。プライベートリンクを使用したデータのクエリの詳細については、「マネージド Prometheus と Azure Monitor ワークスペースにプライベートエンドポイントを使用する」を参照してください。

トラフィック分析を使用してクラスターとの間のネットワークトラフィックを監視する

トラフィック分析では、Azure Network Watcher NSG のフローログを分析して、Azure クラウドでのトラフィックフローに関する分析情報を提供します。このツールを使用して、クラスターのデータ流出がないことを確かめ、不要なパブリック IP が公開されているかどうかを検出します。

ネットワーク監視を有効にする

AKS のNetwork Observability アドオンでは、Kubernetes ネットワークスタック内の複数のレイヤーにわたって監視することができます。クラスター内のサービス間のアクセス (東西トラフィック) を監視および観察します。

手順: Azure Kubernetes Service (AKS) の Container Network Observability を設定する

Log Analytics ワークスペースをセキュリティで保護する

コンテナー分析情報は、Log Analytics ワークスペースにデータを送信します。 Log Analytics ワークスペース内のログインジェストとストレージをセキュリティで保護してください。

手順: ログの取り込みと保存。

Microsoft が Azure Monitor をセキュリティで保護する方法

この記事の手順は、 Microsoft のセキュリティ責任モデルに基づきます。 Microsoft は、共有責任のこのモデルの一環として、Azure Monitor のお客様に次のセキュリティ対策を提供しています。

Azure のセキュリティガイダンスとベストプラクティス

Azure Monitor のセキュリティで保護されたデプロイ手順は、次のような Azure の包括的なクラウドセキュリティガイドラインとベストプラクティスに基づいており、一貫性があります。

クラウド導入フレームワーク。テクノロジインフラストラクチャを管理するチームにセキュリティガイダンスを提供します。
Azure Well-Architected Framework。セキュリティで保護されたアプリケーションを構築するためのアーキテクチャのベストプラクティスを提供します。
Microsoft クラウドセキュリティベンチマーク (MCSB)。使用可能なセキュリティ機能と推奨される最適な構成について説明しています。
ゼロトラストのセキュリティ原則。セキュリティチームがゼロトラストのモダン化イニシアチブをサポートするための技術的な機能を実装するためのガイダンスを提供します。

次のステップ

Azure Monitor の概要について詳しくは、こちらをご覧ください。