Azure 監視シリーズの第 5 回目のブログでは、最も重要な点、つまり環境のセキュリティと可用性の維持に焦点を当てています。サービスがオフラインになったり、データが侵害されたりすれば、パフォーマンスやコストは意味をなさなくなります。この記事では、CloudOps チームが脅威を早期に検知し、スタックにレジリエンスを構築し、ユーザーやコンプライアンスに影響が出る前に障害に対処するのに役立つ Azure メトリックを紹介します。以前の記事を見逃していませんか？ 追いつく.
クイックダウンロード
セキュリティ リスクはデータを脅かすだけでなく、ダウンタイムの根本的な原因となることも少なくありません。
-
セキュリティ上の欠陥は、多くの場合、可用性の問題を引き起こします。ログイン失敗、権限昇格、ラテラルムーブメントなどの指標を追跡することで、稼働時間を阻害するインシデントを防止できます。
-
未解決の Defender 推奨事項、コンプライアンスの逸脱、MFA の採用率の低さなどを、侵害につながる前に監視します。
-
実際のユーザーの可用性、エラー率、リソースの健全性パターンを使用して、ユーザーが報告する前にパフォーマンスの低下を検出します。
-
LogicMonitor を使用して、統合監視プラットフォームで Azure のセキュリティと稼働時間の信号を相関させてみましょう。
-
AI の導入は増加していますが、実稼働環境での成熟度は低く、ほとんどがまだ試験段階です。統合された説明可能な AI がそれを解き放ちます。
稼働時間とセキュリティはサイロ化されていません。Azure環境では、単一の構成ミスやログイン異常が、障害と同じくらい簡単に侵害を引き起こす可能性があります。そのため、CloudOpsチームは、サービスの整合性と回復力を維持するために、Azureのセキュリティ指標とAzureの稼働時間指標の両方を活用しています。
これらの分析情報を統合された Azure 監視メトリック戦略に基づいて組み合わせることで、IT チームは、リスクが実際の問題にエスカレートする前に検出するために必要なコンテキストを得ることができます。
Azure の稼働時間とセキュリティの監視が切り離せないのはなぜですか?
CloudOps チームにとって、稼働時間とセキュリティは独立した目標ではなく、深く関連しています。
ログイン失敗の急増や権限設定の誤りは、重要なサービスの停止や機密データの漏洩につながる可能性があります。そのため、可用性に影響を与える可能性のある脅威を可視化せずに、可用性を監視するだけではもはや不十分です。
Azureのセキュリティ指標をMicrosoft Azureの稼働時間指標と併せて監視することで、組織は可用性と整合性の両方に影響を与えるリスクを検出できます。ラテラルムーブメントの特定、劣化したリソースの追跡、アクセス異常のフラグ付けなど、セキュリティ重視のテレメトリは、サービスの稼働と回復力の維持に重要な役割を果たします。
したがって、中断のないサービスを提供することが目標である場合、セキュリティは別個の取り組みではなく、稼働時間戦略の一部にする必要があります。
Azure の共有責任を理解する
Azure では、稼働時間とセキュリティは密接に関連しており、両方を効果的に監視するには、共有責任モデルを理解することが不可欠です。
コア インフラストラクチャは Microsoft が管理しますが、データ、ID、アカウント、アクセスなど、管理する Azure リソースの保護はお客様の責任となります。
そのため、監視はシステムをオンライン状態に保つことだけでなく、サービス継続性とセキュリティの両方を損なう可能性のある誤った構成、侵入、ポリシーの変更の早期の兆候を捉えることも重要です。
スタックのどのコンポーネントを担当しているかを把握することで、適切なAzure監視メトリックをより適切に優先順位付けできます。アプリの可用性を追跡する場合でも、ラテラルムーブメントをスキャンする場合でも、優れた可視性は、早期の対応、迅速なトラブルシューティング、そして回復力の維持に役立ちます。
セキュリティ指標：インシデントになる前にリスクを特定する
セキュリティインシデントは予告なく発生することは稀で、見落とされた設定ミスや脆弱なアクセス制御によって蓄積されます。そのため、AzureのセキュリティメトリクスをID、ネットワーク、ワークロードの各レイヤーにわたって追跡することは、Azureの脅威を早期に検出するために不可欠です。
適切な Azure アラート構成により、CloudOps チームはリスクが侵害にエスカレートする前にそれを捕捉できます。
Azure セキュリティ メトリックの監視が重要な理由
Azureでは、セキュリティ脅威は適切なテレメトリがなければ見逃されやすいパターンを通じて蓄積されます。メトリクスは、CloudOpsチームがこうした兆候を早期に把握し、小さな問題が大きなインシデントに発展する前に対処する方法を提供します。
アクセス、ID、データ保護の責任がある場合、監視はオプションではなく、リスクに先手を打つための手段となります。
- アカウントが侵害される前に異常なサインインパターンを見つける
- セキュリティ体制を弱める構成変更を検出する
- 最初にどこを確認するかを知って、Azure のインシデント対応をスピードアップ
- Azure セキュリティ メトリックを使用して、最小権限とアクセス衛生を強化する
この可視性がなければ、ユーザーや監査人が最初に脅威を発見するまで、脅威が気付かれないことがよくあります。
横方向の移動を検出するためのネットワークメトリクス
Azureにおけるネットワークベースの攻撃は、多くの場合、最初のアクセスを既に取得した後、静かに開始されます。環境内のトラフィックの流れを監視することで、不審な動きを早期に発見し、サービスが中断される前に稼働時間を確保することができます。
次のメトリックを監視します。
ブロックされた着信接続: Azure がネットワーク エッジでトラフィックを拒否する頻度を示します。これらのメトリックは、ネットワーク セキュリティ グループ (NSG) と Azure Firewall のログから取得され、誰がどこから環境にアクセスしようとしているかを把握するために重要です。急増や繰り返し発生するブロックを追跡することで、チームは Azure ネットワーク セキュリティを強化し、攻撃者が侵入する前に公開されているサービスを特定できます。
予期しないプロトコルの使用: トラフィックが通常の動作には含まれないポートやプロトコル（想定されていない環境でのRDPやSSHアクティビティなど）に依存している場合に表示されます。この動作を監視することで、構成ミスや不正なアクセスパスを検出できます。
東西交通異常: 内部システムが異常な方法で通信を開始した場合、例えばVMが突然複数のサービスをスキャンするなど、問題が発生します。これらのパターンは、認証情報が侵害された後のラテラルムーブメントを示唆しています。これを監視することで、CloudOpsチームは脅威を早期に検知し、可用性への影響を最小限に抑えることができます。
不正アクセス試行を検出するための認証メトリック
認証関連のイベントは、アカウント侵害の最も初期の兆候となることがよくあります。主要なログイン行動を追跡することで、プロアクティブなAzure監視を実現し、脅威が拡大する前に防御することができます。
監視すべき内容は次のとおりです。
時間とソース別の失敗したログイン試行: ブルートフォース攻撃またはクレデンシャルスタッフィング攻撃を示します。Azure セキュリティ メトリックの一部としてこれらのパターンを監視することで、アクセスが許可される前に侵入を検知できます。
多要素認証（MFA）の使用傾向： アカウント保護の弱点を明らかにします。特権ユーザーのMFA導入率が低い場合、Azure監視メトリクスにおいて警告サインとなります。
アカウントのロックアウト: 認証情報の誤入力や繰り返しの攻撃試行を指摘します。ロックアウトの傾向を確認することで、チームはユーザーエラーと標的型リスクを区別することができます。
特権アクセスアクティビティ: 内部での不正使用や認証情報の漏洩を警告します。これらの指標は、環境内で最も機密性の高い制御ポイントを的確に把握するのに役立ちます。
アカウントの不正使用を特定するためのアクセス行動指標
アカウントが認証されると、アクセスの使用方法にリスクの高い行動が現れることがよくあります。Azureデータ収集テレメトリツールを通じて収集されるこれらのAzureセキュリティメトリックは、Azureの異常を早期に検出し、Azureインシデント対応時に迅速に対応するのに役立ちます。
アクセス速度: ユーザーまたはサービス アカウントが複数の Azure リソース間を移動する速度を測定します。突然の増加は、資格情報の不正使用や、直ちに確認が必要な自動アクティビティを示している可能性があります。
初回アクセスイベント: 誤って構成された権限や、通常の範囲外で使用されているアカウントを明らかにします。
権限の利用: ユーザーがほとんど使用しない、あるいは全く使用しない権限を行使しているかどうかを示します。これを監視することで、攻撃が発生していない場合でもセキュリティリスクを高める過剰な権限を持つアカウントを特定できます。
特権ロールの割り当て: 管理者ロールや高い権限を持つロールへの変更は、Azure において最も機密性の高いアクションの一つです。これらのロールがいつ、どのように割り当てられたかを追跡することで、意図しない権限昇格を防ぐことができます。
ジャストインタイム (JIT) アクセス要求: 特定のタスクの権限を一時的に昇格します。JITの使用頻度と使用者を監視することで、昇格されたアクセスを制御し、必要な期間のみに制限することができます。
脆弱性が悪用される前に発見するためのコンプライアンス指標
Azureでは、コンプライアンス指標は、構成ミスやガバナンスの不備に起因するリスクの早期指標として機能します。これらのAzureセキュリティ指標は、Azureインフラストラクチャの継続的な保護を維持し、Azure監視指標戦略全体を向上させるために不可欠です。
未解決の推奨事項: クラウド向け Microsoft Defender 現在の構成に基づいて、セキュリティに関する推奨事項をフラグ付けします。未解決の項目の数を監視することで、攻撃者が悪用する可能性のあるセキュリティ体制の重大な欠陥を特定します。
ポリシー不遵守率: 定義されたポリシーに準拠していない Azure リソースの数を表示します。この割合が高い場合、多くの場合、制御不能な増加やチーム間での一貫性のないデプロイメントが示唆されます。
脆弱性の修復にかかる時間（MTTR）: 既知の問題にどれだけ迅速に対応できるかを測定します。規制の厳しい環境では、迅速な修復がコンプライアンスリスクの直接的な軽減につながります。
コンプライアンスドリフト: 監査の失敗につながる前に、微妙な変化を捉えます。
ポリシー施行率: サブスクリプション全体で Azure Policy がどの程度効果的に適用され、遵守されているかを表します。適用率が低い場合、ガバナンスが不十分であり、セキュリティ ベースラインが弱まる可能性があります。
アプリケーションメトリクス
アプリケーションレベルのアクティビティは、インフラストラクチャアラートが発報される前にセキュリティ上の問題を明らかにすることがよくあります。Azure Application InsightsとAzure Log Analyticsを通じて収集されるこれらのAzureセキュリティメトリックは、疑わしい動作と実際のアプリケーションへの影響を結び付け、Azure監視メトリック戦略全体を強化します。
許可されていない API 呼び出し: 資格情報の不足または無効なためにリクエストが拒否されたことを表示します。Azure Application Insights でこれらのイベントを追跡することで、ユーザーやデータに影響を与える前に、公開されたエンドポイントや不正なトークンを特定できます。
ストレージ アカウント アクセスの失敗: 権限の設定ミス、または不正なIDによるデータアクセスの試みを示します。Azure Log Analyticsでこれらのイベントを分析することで、潜在的なデータ漏洩リスクを可視化できます。
SQL 認証の失敗: 誤った認証情報を使用したデータベースへの接続試行の失敗をハイライト表示します。これらの失敗を監視することで、ブルートフォース攻撃を検出し、コアアプリケーションのパフォーマンスワークロードに関連する機密データを保護します。
可用性メトリクス: サービスをスムーズに実行し続ける
可用性メトリックは、CloudOps チームがサービスがユーザーにどれだけの信頼性と一貫性を持って価値を提供しているかを測定するのに役立ちます。
サービスが複数のレイヤーに依存する Azure のような複雑な環境では、可用性を追跡することで弱点を特定し、エンドツーエンドの信頼性を維持するのに役立ちます。
Azure の可用性メトリックの監視が重要な理由
インフラが技術的に「稼働中」であっても、ユーザーはエラー、遅延、または不完全な機能に遭遇する可能性があります。そのため、基本的なチェックにとどまらず、ユーザーの視点からサービスの動作を監視することが不可欠です。
これらのメトリックは、パフォーマンスの低下や局所的な障害に関する分析情報を提供し、組織が迅速に対応して SLA を維持するのに役立ちます。
- 正常なインフラストラクチャコンポーネントによって隠されている障害を特定する
- エンドユーザーに影響を与える速度低下や API の問題をキャッチする
- Azure ゾーン間の可用性の地域差を理解する
- 部分的な障害が拡大する前に検出する
次の Azure 可用性メトリックは、Azure のパフォーマンスを最適化し、信頼性の高いエクスペリエンスを提供するためのあらゆる取り組みの中心となります。
稼働時間: 「稼働しているか?」以上のものを測定
Azureの稼働時間を効果的に追跡するには、実際のサービスの応答性、エラーの挙動、ユーザーが主要なワークフローを完了できるかどうかを可視化する必要があります。これらの指標は、実用的なAzure監視指標の基盤となります。
ユーザーが認識する可用性: ユーザーが期待どおりにサービスにアクセスし、操作できるかどうかを評価します。Azureでは、次のようなツールが利用できます。 アプリケーションインサイト および ウェブテスト 実際のやり取りをシミュレートして完全な機能を検証するのに役立ちます。
地域によるパフォーマンスの違い: ルーティング、負荷分散、またはゾーン レベルの中断によって発生するリージョン固有の問題を検出するのに役立ちます。
機能検証: ログインやチェックアウトの完了といったアプリのコアビジネスロジックの動作を検証します。Azure Web Tests は、これらのユーザーフローを模倣し、アクセス可能性だけでなく機能性も検証できます。
高いエラー率: インフラが健全に見えても、信号が劣化したサービスがあります。これらをリアルタイムで監視することで、ユーザーに影響を与える根本的な問題を明確に把握できます。
リソースの健全性: 障害が発生する前に検出する
リソースの正常性メトリックは、障害が発生する前であっても、何か問題が発生していることを示す早期警告サインを提供します。ITチームは、ユーザーからの問題の報告を待つことなく、Azureリソースが負荷、不安定性、または自動復旧時にどのように動作するかを追跡できます。これらのメトリックはAzureパフォーマンス監視の基盤であり、迅速な診断と対応を通じてダウンタイムの短縮に役立ちます。
パフォーマンス低下状態: リソースは稼働しているものの、最適なパフォーマンスを発揮していない状態を示します。例えば、VMは稼働しているもののディスクI/Oに問題がある場合などです。アラートやユーザーからの苦情が発生する前に、速度低下や不安定さに対処するのに役立ちます。
ステータス遷移頻度: 不安定なインフラストラクチャや設定ミスを指摘します。これらの遷移を監視することで、繰り返し発生する問題を明らかにし、サービス計画の改善に役立ちます。
自己治癒パターン: Azure が手動介入なしにリソースの問題を自動的に解決したタイミングを追跡します。これらのパターンを認識することで、Azure 監視メトリックを使用したよりスマートなキャパシティプランニングと回復力戦略の強化が可能になります。
リソース劣化指標
一部のサービスは一度にすべて失敗するわけではなく、時間の経過とともに性能が低下し、速度低下、再起動、断続的なエラーなどの兆候が現れます。
次のリソース劣化メトリックは、この低下を早期に発見し、ユーザーに影響が出る前に信頼性を維持するのに役立ちます。
サービス低下頻度: サービスが応答速度の低下や部分的な障害など、劣化状態になる頻度を追跡します。この値が上昇傾向にある場合、パフォーマンスやリソースのスケーリングに根本的な問題がある可能性があります。
リソースの健全性の遷移: リソースが正常、警告、エラー状態の間をどのくらいの頻度で切り替わるかを測定します。頻繁な遷移は不安定さを示す強いシグナルであり、プロアクティブな修復措置を講じるのに役立ちます。
サービスの依存関係: 何かが失敗したときに何が壊れるかを知る
Azure環境は相互接続されたサービス上に構築されており、単一の障害が複数のシステムに波及する可能性があります。依存関係に関連するAzure監視メトリックを追跡することで、影響を迅速に把握し、サービスを迅速に復旧できます。
サービス間接続: 依存するサービスが期待どおりに通信できるかどうかを示します。個々のサービスが正常に動作しているように見えても、接続が途切れると下流の障害が発生する場合があります。
サービス間の障害相関: どの問題が原因であり、どの問題が副作用であるかを明らかにします。これにより、修正の優先順位付けと平均復旧時間の短縮に役立ちます。
依存関係リスクマッピング: アーキテクチャ内の脆弱なリンクをハイライト表示します。どのサービスが相互に依存しているかを把握することで、影響範囲を予測し、より安全な変更を計画するのに役立ちます。
災害復旧の準備：フェイルオーバーが機能することを確認する
災害復旧メトリクスは、復旧計画が最も重要なときに稼働時間を保護しているかどうかを検証します。
これらの Azure 監視メトリックは、DR をドキュメント化から運用準備に移行します。
実際の復旧時間 vs. 目標復旧時間 (RTO): 復旧に実際にかかった時間と計画された時間を比較します。大きな差は、プロセスまたは自動化の改善が必要であることを示しています。
フェイルオーバー成功率: エラーや手動修正なしでフェイルオーバーが完了する頻度を追跡します。成功率が低い場合、リカバリ設計に潜在的なリスクがあることを示しています。
自動化範囲: 復旧プロセスがどの程度自動化されているかを測定します。自動化レベルが高ければ高いほど、人為的ミスが減り、緊急性の高いインシデント発生時の復旧が迅速化されます。
CloudOpsにセキュリティと稼働時間を組み込む
Azure では、セキュリティと稼働時間は別々の目標ではなく、相互に依存しています。
Azure Monitor ログの異常を見逃したり、リソースにパッチが適用されていないと、システムの健全性が徐々に低下し、最終的にはサービスがオフラインになる可能性があります。回復力の高い CloudOps ワークフローを構築するには、あらゆるセキュリティギャップを潜在的なアップタイムリスクとして扱う必要があります。
リアルタイム監視によりそれが可能になります。
主要な Azure セキュリティ メトリックを Azure 監視メトリックと並行して追跡することで、CloudOps チームは、失敗したログインの急増、ポリシーの更新、リソースの劣化の進行など、警告のサインを早期に検出できます。
Azure の稼働時間をコンテキスト内で追跡する機能により、ユーザーに影響が出る前に修正が必要な項目を優先順位付けできます。
この統合ビューは、インシデント対応の迅速化にも役立ちます。チームは、ばらばらのアラートを追うのではなく、セキュリティ指標とパフォーマンス指標を相関させ、依存関係を把握し、何かが適切に機能していない場合に迅速に対応できるようになります。
Azure 環境におけるセキュリティと稼働時間監視のベスト プラクティス
優れたCloudOpsチームは、セキュリティと稼働時間を別々の分野として扱いません。Azureでは、セキュリティを弱めるのと同じ構成ミスが、サービスをオフラインにしてしまう可能性もあります。Azure監視のベストプラクティスに従うということは、アクセス、データ、そしてサービスの継続性を同時に保護する監視を設定することを意味します。
セキュリティのベストプラクティス
セキュリティのベストプラクティスをいくつか紹介します。
- 監視データへのアクセスをロックダウンします。 Log Analytics ワークスペースでロールベースのアクセス制御を使用すると、ユーザーは必要なデータのみを表示できるため、内部での露出や誤用のリスクが軽減されます。
- 安全なログの取り込みとログデータの保存: 特にセキュリティおよび監査データを Azure Monitor および Application Insights に送信する場合は、アクティビティ ログが TLS 1.2+ を使用して転送中に暗号化され、保存時に保護されていることを確認します。
- 監視アクティビティの監査と保護: ログ クエリの監査とワークスペース ロックを有効にすると、セキュリティ データに対する変更、クエリ、または削除が追跡され、サイレントに変更されなくなります。
稼働時間のベストプラクティス
稼働時間に関するベストプラクティスをいくつか紹介します。
- サービス層から可用性を監視します。 Azure Monitor メトリックを機能チェックと組み合わせることで、可用性はリソースの状態だけでなく実際のユーザー アクセスを反映します。
- 騒音ではなく衝撃に関する警告を設計します。 ダウンタイムが発生する前に問題を検出するために、ハード障害だけでなく、劣化状態やサービス ヘルスの変化に関するアラートを構成します。
- リカバリパスを定期的に検証します。 リカバリ時間とフェイルオーバーの成功を追跡して、実際の状況でバックアップと災害復旧計画が実際に機能することを確認します。
LogicMonitor が Azure メトリックの監視にどのように役立つか
LogicMonitor は、Azure のメトリック、ログ、サービス コンテキストを 1 か所にまとめるため、CloudOps チームはセキュリティ イベントやパフォーマンスの問題が稼働時間にどのように影響するかをリアルタイムで確認できます。
ツールを切り替える代わりに、アイデンティティ アクティビティ、ネットワーク動作、サービスの健全性を相関させて、何が起こっているのか、なぜ起こっているのかをより早く把握できます。
LogicMonitor は、自動検出、動的なしきい値、サービスレベルビューを備えており、チームがリスクを早期に発見し、ユーザーに影響が出る前に対応できるよう支援します。Azure の監視を簡素化し、稼働時間をより効果的に保護する準備ができたら、デモをリクエストするか、サインアップして LogicMonitor の実際の動作をご確認ください。
次回： セキュリティ、パフォーマンス、コストを結び付けるなぜなら、現代の可観測性においては、孤立して存在するものなど存在せず、成功するチームはそれに応じた監視を行うチームだからです。
問題が本番環境に到達する前に、監視するすべてのサービスに回復力を組み込みます。
会員登録について
よくあるご質問
ログイン異常における実際の脅威と誤検知の違いをどのように見分けることができますか?
時間帯、場所、MFAバイパスの試みなど、複数のシグナルに注目して、調査する価値があるほど異常なイベントかどうかを判断します。これが鍵となります。 Azure でのリアルタイム脅威検出.
アクセス速度を追跡する最適な方法は何ですか?
サービスアカウントがY分以内にX回以上の新規リソースにアクセスするなど、異常なパターンのしきい値を設定し、それを超えた場合にのみアラートをトリガーします。これは、最もスマートなアラートの1つです。 Azure 監視のベストプラクティス.
完全なエンドツーエンドのテストがない場合、「ユーザーが認識する可用性」をどのように測定すればよいですか?
マルチステップWebChecksを使用して、主要なアクション（ログインやAPI呼び出しなど）をシミュレートし、稼働時間ではなく応答時間とエラーを監視します。これにより、より明確な状況把握が可能になります。 Azure サービスの可用性監視.
サービスが「低下」しているが、技術的にはまだオンラインである場合、それは何を意味しますか?
サービスは利用可能だが、パフォーマンスが低い、遅い、タイムアウトする、または断続的に障害が発生することを意味します。ハード的な障害が検出されなくても、ユーザーに影響が出る可能性があります。そのため、トラッキングは クラウドインフラストラクチャのセキュリティメトリクス 可用性と同じくらい重要です。
災害復旧フェイルオーバーが機能することを確認するために、どのくらいの頻度でテストする必要がありますか?
少なくとも四半期ごと、または大規模なインフラやアプリケーションの変更後には、フェイルオーバーテストを実施してください。単にドキュメントをざっと確認するのではなく、実際の状況をシミュレートする必要があります。これは、強力な 災害復旧準備指標.
ネットワーク内で異常なプロトコルの使用に気付いた場合はどうすればよいでしょうか?
どのシステムがトラフィックを開始したか、それが予期された動作であるかどうか、およびポートまたはプロトコルを制限する必要があるかどうかを直ちに調査します。
製品管理、IT コンサルティング、ソフトウェア開発、フィールド イネーブルメント、戦略計画、ソリューション アーキテクチャの経験を持ち、顧客中心のソリューションを 20 年以上提供してきた、結果重視で細部にこだわる技術プロフェッショナルです。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
