インベントリと可視性に関する考慮事項
組織がクラウド環境を設計して実装する際、プラットフォーム管理とプラットフォーム サービス監視の基盤が重要な考慮事項になります。 クラウド導入を確実に成功させるには、環境の規模に応じてこれらのサービスを構成し、組織のニーズに対応する必要があります。
初期の計画フェーズで行ったクラウド運用モデルの決定が、ランディング ゾーンの一部として提供される管理の運用方法に直接影響します。 プラットフォームの管理をどの程度一元化するかは、重要な例です。
この記事のガイダンスを使用して、クラウド環境においてインベントリと可視性にどのようにアプローチすべきかを検討してください。
インベントリに関する基本的な考慮事項
- 管理境界として、Azure Monitor Log Analytics ワークスペースなどのツールの使用を検討します。
- システムによって生成されたプラットフォームのログを使用する必要があるチームと、ログへのアクセスが必要なユーザーを決定します。
ログ データに関連する次の項目を考慮して、照合したり使用したりするデータの種類を通知します。
| Scope | Context |
|---|---|
| アプリケーション中心のプラットフォーム監視 |
メトリックとログのホットおよびコールド テレメトリ パスの両方を含めます。 オペレーティング システムのメトリック (パフォーマンス カウンターやカスタム メトリックなど)。 オペレーティング システム ログ。次に例を示します。
|
| セキュリティ監査ログ | 組織の Azure 資産全体にわたる水平方向のセキュリティ レンズを実現します。
|
| Azure のデータ保持のしきい値とアーカイブ要件 |
|
| 運用上の要件 |
|
可視性に関する考慮事項
- アラート通知を受信する必要があるのはどのチームですか?
- 複数のチームに通知する必要があるサービスのグループはありますか?
- アラートを送信する必要がある既存のサービス管理ツールはありますか?
- ビジネス クリティカルと見なされ、問題に対して高い優先度の通知が必要なのはどのサービスですか?
インベントリと可視性に関する推奨事項
- Azure ロールベースのアクセス制御 (Azure RBAC)、データ主権の要件、データ保持ポリシーにより個別のワークスペースが必要な場合を除き、1 つのモニター ログ ワークスペースを使用してプラットフォームを一元管理してください。 ログ記録の一元化は、運用管理チームに必要な可視性にとって重要であり、これにより、変更管理、サービス正常性、構成、および IT 運用のその他の側面に関する多くのレポートが容易になります。 一元化されたワークスペース モデルに集中することで、管理作業が軽減され、可観測性のギャップが生じる可能性が低くなります。
- ログの保持期間の要件が 7 年を超える場合は、ログを Azure Storage にエクスポートします。 1 回の書き込みと多数回の読み取りのポリシーで不変ストレージを使用して、ユーザーが指定した間隔でデータを消去不可および変更不可にします。
- アクセス制御とコンプライアンス レポートには Azure Policy を使用します。 Azure Policy により、組織全体の設定を適用して、一貫したポリシーの準拠と迅速な違反検出を確実に行えます。 詳細については、「Azure Policy の効果について」を参照してください。
- Network Watcher を使用して、トラフィック フローを Network Watcher NSG フロー ログ v2 経由で予防的に監視します。 Traffic Analytics は、NSG フロー ログを解析し、仮想ネットワーク内の IP トラフィックに関する詳細な分析情報を収集します。 また、効果的な管理や監視に必要となる次のような重要な情報も提供します。
- ほとんどの通信ホストとアプリケーション プロトコル
- ほとんどの会話しているホスト ペア
- 許可またはブロックされたトラフィック
- 受信および送信トラフィック
- 開かれたインターネット ポート
- ほとんどのブロック ルール
- Azure データセンターごとのトラフィック分布
- 仮想ネットワーク
- サブネット
- 悪意のあるネットワーク
- 重要な共有サービスが誤って削除されないように、リソース ロックを使用します。
- Azure ロールの割り当てを補うために、拒否ポリシーを使用します。 拒否ポリシーは、リソース プロバイダーへの要求の送信をブロックすることで、定義された基準を満たしていないリソースのデプロイと構成を防ぐことができます。 拒否ポリシーと Azure ロールの割り当てを組み合わせることで、適切なガードレールが確保され、リソースのデプロイと構成を行うことができるのは "だれ" で、その人物がデプロイおよび構成できるリソースは "どれ" であるかが制御されます。
- プラットフォーム監視ソリューション全体の一部として、サービスとリソースの正常性イベントを含めます。 プラットフォームの観点からサービスとリソースの正常性を追跡することは、Azure のリソース管理の重要なコンポーネントです。
- 生のログ エントリをオンプレミスの監視システムに送信しないでください。 代わりに、"Azure で生まれたデータは Azure に保持する" という原則を採用します。 オンプレミスの SIEM 統合が必要な場合は、ログではなく重要なアラートを送信します。
Azure ランディング ゾーン アクセラレータと管理
Azure ランディング ゾーン アクセラレータには、組織の迅速なスケーリングと成熟に役立つ主要な Azure 管理機能をデプロイするための厳密な構成が含まれています。
Azure ランディング ゾーン アクセラレータのデプロイには、次のような主要な管理と監視のツールが含まれています。
- Log Analytics ワークスペースと Automation アカウント
- Microsoft Defender for Cloud による監視
- Log Analytics に送信されるアクティビティ ログ、仮想マシン、サービスとしてのプラットフォーム (PaaS) リソースの診断設定
Azure ランディング ゾーン アクセラレータでの一元的なログ記録
Azure ランディング ゾーン アクセラレータのコンテキストでは、一元化されたログ記録は主にプラットフォームの操作に関係しています。
このような重点的な対応は、VM ベースのアプリケーションのログ記録に同じワークスペースを使用することを妨げるものではありません。 リソース中心のアクセス制御モードで構成されたワークスペースでは、詳細な Azure RBAC が適用され、アプリケーション チームは自身のリソースのログにのみアクセスできるようになります。
このモデルでは、アプリケーション チームには、既存のプラットフォーム インフラストラクチャを使用することで管理オーバーヘッドを削減できるというメリットがあります。
非コンピューティング リソース (Web アプリや Azure Cosmos DB データベースなど) については、アプリケーション チームは、独自の Log Analytics ワークスペースを使用できます。 その後、これらのワークスペースに診断とメトリックをルーティングできます。