Azure のこれらのメトリックを追跡して稼働時間を保護し、脅威を早期に阻止する

Azure 監視シリーズの第 5 回目のブログでは、最も重要な点、つまり環境のセキュリティと可用性の維持に焦点を当てています。サービスがオフラインになったり、データが侵害されたりすれば、パフォーマンスやコストは意味をなさなくなります。この記事では、CloudOps チームが脅威を早期に検知し、スタックにレジリエンスを構築し、ユーザーやコンプライアンスに影響が出る前に障害に対処するのに役立つ Azure メトリックを紹介します。以前の記事を見逃していませんか？ 追いつく.

---

クラウド運用の成功は、セキュリティと可用性にかかっています。アプリケーションを超高速で実行し、コストを1セント単位で最適化できたとしても、サービスが侵害されたり利用できなくなったりすれば、何の意味もありません。

多くのチームは、基本的な稼働時間チェックやファイアウォールログといった表面的な指標に頼りすぎていて、より包括的な対策に注力していません。これらのチェックは重要ですが、セキュリティインシデントや障害を予測できるより深いシグナルを見逃してしまうことがよくあります。だからこそ、最も回復力の高いチームは、インフラストラクチャを監視するだけでなく、動作を追跡します。なぜなら、初期のシグナルはアラートからではなく、パターンから得られるからです。

セキュリティ指標：インシデントになる前にリスクを特定する

認証とアクセスパターン

多くの攻撃は、エクスプロイトよりも単純なもの、つまりログイン情報の侵害から始まります。有効な認証情報を入手すれば、侵入する必要はありません。だからこそ、認証の挙動を監視することが非常に重要になります。失敗した試行だけでなく、特に高い権限を持つアカウントの場合、ユーザーがどのように、いつ、どこでサインインしたかを監視することが重要です。

追跡対象:

• 時間とソース別の失敗したログイン試行: 特に見慣れない IP や地域からのアクセスの急増は、クレデンシャル スタッフィングやブルート フォース攻撃の最初の兆候となることがよくあります。
• 認証方法のトレンド： 多要素認証（MFA）の使用状況とパスワードのみのログイン状況を追跡しましょう。最も機密性の高いアカウントが依然として弱い認証方法に依存している場合、問題が発生する可能性が高くなります。
• 特権アクセスアクティビティ: 勤務時間外または新しい場所からの管理者アカウントからの予期しないログインを決して放置してはなりません。

ネットワークセキュリティ：侵害が拡大する前に発見する

すべての侵害が爆発的に始まるわけではありません。熟練した攻撃者は、公開エンドポイントを直撃するのではなく、ネットワーク内を静かに移動し、脆弱なリンクをスキャンし、横方向の侵入経路をテストし、悪用できる設定ミスを探します。攻撃者がさらに深く侵入したり、被害を拡大したりする前に、彼らを捕まえることがあなたの仕事です。

主要なネットワーク メトリック:

• ブロックされた接続試行: 不正アクセスの試みがどこから来ているのか、またそれが時間の経過とともに増加しているかどうかを追跡します。
• 異常なプロトコルの使用: リモート デスクトップ プロトコル (RDP)、セキュア シェル (SSH)、または使用すべきではない古い通信方法を使用した予期しないトラフィックにフラグを設定します。
• 東西交通異常: 内部システムが突然複数のデータベースをスキャンし始めた場合、侵入が進行中である可能性があります。本格的な侵入検知システムではありませんが、監視ソリューションは、Azureやオンプレミスのログやフローデータと組み合わせることで、内部トラフィックの量や方向の突然の変化を検知するのに役立ちます。

リソースアクセス動作: 微妙な攻撃をキャッチ

最も危険な攻撃の中には、ブルートフォース攻撃を全く伴わないものもあります。有効な認証情報と、検知されない静かなアクセスパターンから攻撃が始まります。既に鍵を持っている場合、わざわざ攻撃する必要はありません。検知を逃れるだけで十分です。だからこそ、失敗したログインを追跡するだけでは不十分です。通常のアクセスが異常に見え始めた場合も、それを認識する必要があります。 

監視対象:

• アクセス速度: ユーザーまたはサービスアカウントがリソース間を移動する速度を追跡します。アカウントが突然、これまでアクセスしたことのない複数のシステムにアクセスし始めた場合は、疑わしい状況です。
• 権限の利用: 使用されていないアカウントや過剰な権限が付与されているアカウントを特定します。ユーザーが一度も使用したことのない権限を持っている場合、その権限は必要ではない可能性があり、攻撃者にとってはまったく必要ありません。
• 初回アクセスイベント: ユーザーまたはサービスが機密システムに初めてアクセスしたときを監視します。

プロヒント： 普段はテスト環境にアクセスする開発者アカウントが本番環境でデータベースの変更を開始した場合、それが一時的なものだと決めつけず、調査を行ってください。

セキュリティ体制とコンプライアンスのトレンド

セキュリティとは、攻撃者が攻撃の機会を得る前にリスクを軽減することです。クラウド環境では、設定ミス、未修正の脆弱性、そして変更への対応の遅れなどにリスクが潜んでいます。

ここでセキュリティ体制の追跡が重要になります。すべての監査に合格することが目的ではありません。ビジネスを保護するポリシーに沿って環境を維持することが重要です。

主要な姿勢指標:

• 脆弱性を修正する時間: 既知の問題が発見されてから、チームが修正するのにどれくらいの時間がかかりますか? 対応が速いほど、リスクは低くなります。
• コンプライアンスドリフト: PCI-DSS、HIPAA、ISO 27001 などのフレームワークに準拠していないシステムに注意してください。LM Envision はコンプライアンス レポートを生成しませんが、構成とバックアップのドリフトを明らかにし、クラウド インフラストラクチャがポリシーに準拠しなくなった場合にチームに早期に警​​告を提供します。
• ポリシー施行率: ポリシーが上書きされたり無視されたりしている場合は、ポリシーを強制しているのではなく、リスクを文書化していることになります。

可用性メトリクス: サービスをスムーズに実行し続ける

稼働時間: 「稼働しているか?」以上のものを測定

何かが「稼働中」だからといって、必ずしも使えるとは限りません。サーバーがpingに応答したとしても、APIがエラーを返したり、チェックアウトプロセスが停滞したりする場合は、たとえ稼働時間モニターが緑色であっても、ダウンタイムとみなされます。CloudOpsチームは、基本的な到達可能性チェックにとどまらず、ユーザーの視点から実際のサービス機能を測定する必要があります。

監視対象:

• ユーザーが認識する可用性: HTTP チェックを使用して、サービスが応答しているだけでなく動作していることを検証します。
• 地域によるパフォーマンスの違い: 世界中のさまざまな場所から稼働時間と待ち時間を測定して、局所的な問題を検出します。
  機能検証: データベースは「稼働中」であっても、クエリが失敗し続ける場合があります。プロセスの状態だけでなく、成功率とタイムアウトパターンも監視してください。

リソースの健全性: 障害が発生する前に検出する

ほとんどのシステムは、予告なく故障することはありません。まずは性能が低下します。応答時間の遅延、パフォーマンスの不安定化、断続的なエラーなどです。ハード的な障害のみを監視していると、システムが停止する前に問題を解決するためのシグナルを見逃してしまいます。

主要なリソースの健全性指標:

• パフォーマンスが低下した状態: リソースは実行中だが、低い容量で動作しているときに監視します。
• ステータス遷移頻度: システムが正常、劣化、使用不可の状態を切り替える頻度を追跡します。
• 自己修復パターン: システムが自動的に回復するか、手動による介入が必要かどうかを測定します。

プロヒント： LM Envisionは、劣化パターンを明らかにし、インフラストラクチャ全体で相関関係を把握することで、本格的な障害に先手を打つのに役立ちます。. 動的トポロジ マッピングを使用すると、他のどのサービスやシステムが影響を受けているかを即座に確認できるため、症状を修正するだけでなく、原因を修正できます。

サービスの依存関係: 何かが失敗したときに何が壊れるかを知る

現代のクラウド環境では、すべてがつながっています。1つのサービスの遅延が、他の6つのサービスに波及する可能性があります。その連鎖が見えなければ、影響を修復することはできません。

コンポーネントを個別に監視すると、何が壊れているのかがわかるかもしれません。サービスの依存関係を監視すると、そのコンポーネントが原因で他に何が壊れているのかがわかります。

モニター：

• サービス間接続: 依存するサービスが単独でではなく、アクセス可能で連携して機能していることを確認します。
• サービス間の障害の相関関係: どの障害が他の障害に影響を与えるかを特定し、それに応じて修正の優先順位を決定します。
• 依存関係リスクマッピング: 連鎖的なダウンタイムが発生する前に、最も弱いサービスまたは脆弱なチェーンを見つけます。

災害復旧の準備：フェイルオーバーが機能することを確認する

バックアップは簡単です。しかし、リカバリは困難です。災害復旧への備えとは、最も必要な時に確実に機能することを保証することです。50ページのランブックとS3バックアップがあったとしても、プレッシャーの中で誰も実行できなければ、リージョンの停止の最中にあなたを救うことはできません。

追跡対象:

• 実際の復旧時間と目標復旧時間 (RTO): 実際の回復時間と計画された回復時間を比較します。
• フェイルオーバー成功率: フェイルオーバーが期待どおりに機能するか、新しい問題が発生するかどうかを監視します。
• 自動化の範囲: 回復プロセスのうち、自動化されている割合と手動介入が必要な割合を測定します。

CloudOpsにセキュリティと可用性を組み込む

セキュリティと可用性は、副次的な懸念事項ではありません。現代のCloudOpsチームの業務運営の中核を成すものです。ログイン異常を1つ見逃すだけで、セキュリティ侵害につながる可能性があります。また、テストされていないフェイルオーバーパスが1つあるだけで、ちょっとしたトラブルがシステム停止に繋がる可能性があります。

優れたチームは、これらを別々の問題として扱うことはありません。監視、相関分析、自動化するすべてのものに保護機能を組み込みます。

彼らが違う点:

• アクセスと認証のパターンを追跡して、脅威を早期に発見します。
• サーバーの ping だけでなく、ユーザーの視点からサービスの可用性を監視します。
• パフォーマンスの低下を検出する   ダウンタイムになってしまいます。
• 実際に必要になるものとして、フェイルオーバー ワークフローをテストして検証します。

そして、彼らはコンプライアンスだけでなく信頼を築くという 1 つの目標を念頭に置いてすべてを行っています。

LogicMonitor は、ユーザーや監査人が気付く前に問題に対処するために必要なリアルタイムのテレメトリ、動的ベースライン、サービス レベルの可視性を CloudOps チームに提供します。

---

次回： セキュリティ、パフォーマンス、コストを結び付けるなぜなら、現代の可観測性においては、孤立して存在するものなど存在せず、成功するチームはそれに応じた監視を行うチームだからです。

よくある質問

© LogicMonitor 2025 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。