Azure クラウド資産を管理する

この記事では、運用の正常性を確保するために Azure クラウド資産を効果的に管理する方法について説明します。 クラウドがビジネス目標に合うように、クラウド運用を強力に管理する必要があります。 次のベスト プラクティスに従います。

管理スコープを特定する

デプロイ モデルごとに管理スコープを明確に決定し、クラウド資産の情報に基づいた管理上の決定を行います。 インフラストラクチャ (IaaS) とプラットフォーム サービス (PaaS) は Azure 内で動作します。 これらの責任をオンプレミスの環境およびソフトウェア サービス (SaaS) と比較します。 この表を使用して、各デプロイ モデルでの責任を特定します。

変更の管理

変更は、クラウドの問題の最も一般的な原因です。 その結果、変更とその承認を追跡する変更管理アプローチが必要になります。 また、未承認の変更を検出し、目的の状態に戻す必要があります。 次の手順に従います。

1. 変更要求プロセスを開発します。 チケット ツール、pull request (GitHub または Azure DevOps)、指定されたフォームなどの正式なシステムを使用します。 変更要求プロセスでは、変更の種類、要求元 ID、ターゲット環境、スコープ、理由などのキーの詳細をキャプチャする必要があります。 パスワードのリセットなどの日常的なサービス要求に対しては、個別の手順を保持します。

2. 変更に関連するリスクを評価します。 展開速度とリスク管理のバランスを取るために、明確なリスク カテゴリ (高、中、低) を割り当てます。 ダウンタイムの許容度 (エラー予算) やワークロードの重要度などの条件に従って、各変更を評価します。 次の表を例として使用して、適切な承認ワークフローを決定します。

   リスク レベル	ダウンタイム許容量	ワークロードの重要度	承認プロセス	変更例
   高	ダウンタイムは許可されません	これらの変更は、ダウンタイムに対する許容度をゼロにして継続的な可用性を必要とするミッション クリティカルなシステムに影響します。	複数のシニア エンジニアによるレビュー、自動化されたパイプラインのアラート、迅速なカナリア リリース、アクティブな監視。	重要なインフラストラクチャの更新
   中程度	短いダウンタイムが許容される	これらの変更は、ダウンタイムに対する許容範囲が限られている重要なシステムに影響します。	自動化されたパイプラインによって変更にフラグが立てられます。 監視によってアラートが発生した場合のエンジニアによるクイック レビュー。	重要でないシステム更新プログラム、短いメンテナンス期間中の機能拡張
   低	十分なダウンタイムが許容される	これらの変更は、全体的な操作に影響を与えることなく、長時間のダウンタイムを許容できる重要でないシステムに影響します。	CI/CD による完全に自動化されたデプロイでは、デプロイ前テストと監視が実行されます。	定期的な更新、マイナー ポリシーの更新

3. 承認を明確に標準化します。 各リスク レベルで必要な承認基準と権限を定義します。 各変更をレビューする必要があるユーザーを指定し、1 人の承認者かレビュー 委員会かを指定し、レビュー担当者がフィードバックを提供して解決する方法を明確にします。

4. 展開プロセスを標準化します。 承認済みの変更を運用環境にビルド、テスト、デプロイする手順を明確に説明します。 詳細については、「クラウド リソースの管理」を参照してください。

5. デプロイ後のプロセスを標準化します。 正常な変更を確認するための監視と検証の手順を実装します。 変更によって問題が発生した場合にサービスを迅速に復元するための明確なロールバック戦略を含めます。

6. 未承認の変更を防止して検出します。変更分析 を使用して、構成の変更を検出し、その根本的な原因を説明します。 (Deny、DenyAction)、(Audit、auditIfNotExists) などの効果を使用して、Azure Policy を使用して変更を拒否および監査します。 Bicep を使用する場合は、Bicep デプロイ スタック を使用して、未承認の変更を防ぐことを検討してください。

セキュリティの管理

ID はセキュリティ境界です。 標準化されたプラットフォームを使用して、ID の確認、アクセス許可の制限、セキュリティで保護されたリソース構成の維持を行います。 次の手順に従います。

1. ID の管理。 統合 ID 管理ソリューション Microsoft Entra ID を使用します。 ロールベースのアクセス制御 (RBAC) 適用して、アクセス許可を明確に定義します。 Microsoft Entra ID Governance を使用して、アクセス要求ワークフロー、アクセス レビュー、ID ライフサイクル管理を制御します。 Privileged Identity Management を有効にして、Just-In-Time 特権アクセスを許可します。 この戦略により、不必要な過剰なアクセス権が削減されます。 3 つの ID の種類 (ユーザー、アプリケーション、デバイス) をすべて一貫して管理し、適切な認証と承認を確保します。

2. アクセスを管理します。 Azure ロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) を して、ジョブを実行するための最小限のアクセス許可を付与します。 管理オーバーヘッドを制限するために、グループ に基づいてロールの割り当てを優先します。 サブスクリプション、リソース グループ、個々のリソースなど、最も低い スコープでアクセス許可を付与します。 意図しない特権エスカレーションを防ぐために、過度に広範なアクセス許可スコープを避けてください。 各ユーザーのロールに必要なアクセス許可のみを割り当てます。

3. リソース構成を管理します。インフラストラクチャをコード (IaC) として使用して、リソースの一貫性のある再現可能な構成を確保します。 その後、Azure Policy を使用して組織の標準を適用し、コンプライアンスを評価します。 次 Azure Policy を使用して、特定の Azure サービスのセキュリティで保護された構成を適用します。 使用可能なセキュリティ機能と最適なセキュリティ構成に関するガイダンスについては、セキュリティ ベースラインの を参照してください。 アドオン機能として、Defender for Cloud のセキュリティ ポリシーを使用して、一般的なセキュリティ標準に準拠します。

4. 認証を管理します。 多要素認証 (MFA) を使用してユーザーが強力な認証を採用し、Microsoft Entra 多要素認証 (MFA) 使用することを確認します。 ユーザー ID、デバイスの正常性、アクセス コンテキストに基づいて認証を適用するには、常に 条件付きアクセス が必要です。 セルフサービス パスワード リセットを構成し、脆弱なパスワードを排除します。

5. セキュリティ情報を管理します。 セキュリティ情報およびイベント管理 (SIEM)、セキュリティ オーケストレーション、自動化、応答 (SOAR) に Microsoft Sentinel を使用します。

6. ワークロードのセキュリティを制御します。 ワークロードのセキュリティに関する推奨事項については、Well-Architected Framework の セキュリティ チェックリストの と azure サービス ガイド を参照してください (セキュリティ セクションから始めます)

コンプライアンスの管理

コンプライアンス管理により、Azure の運用は、確立されたガバナンス ポリシーと規制基準に準拠した状態を維持できます。 この方法では、潜在的な違反や構成ミスから環境を保護することで、リスクを軽減します。

1. ガバナンス ポリシーについて理解します。 ガバナンス ポリシーは、コンプライアンスを維持するためにチームが従う必要がある高レベルの制約を定義します。 組織のポリシーを確認し、各要件を運用プロセスにマップします。 ガバナンス ポリシーがない場合は、まずガバナンス ポリシーを文書化してください。

2. コンプライアンスを管理します。 コンプライアンスを適用することで、環境が組織と規制の両方の標準に準拠し続けられます。 ポリシーの推奨事項については、次の表を参照してください。

   勧告	細部
   まず、一般的なポリシー定義	許可された場所、許可されていないリソースの種類、カスタム RBAC ロールの監査など、Azure Policy の一般的な定義から始めます。
   規制標準に合わせます	ISO 27001、NIST SP 800-53、PCI DSS、EU GDPR などの規制基準に準拠した Azure Policy の無料の組み込み定義 使用する

詳細については、「Azureでのコンプライアンスの適用」を参照してください。

データの管理

クラウド運用でのデータの管理には、積極的に分類、セグメント化、アクセスのセキュリティ保護、削除からの保護が含まれます。 効果的なデータ制御は、機密情報を保護し、コンプライアンスを維持し、運用の変更中にデータの信頼性を確保します。

1. データを検出して分類します。秘密度と重要度に従ってデータを識別して分類します。 この分類では、データ型ごとに調整されたコントロールがガイドされます。 データ ガバナンスに Microsoft Purview を使用します。 詳細については、「Microsoft Purview Data Mapに接続するデータ ソース」を参照してください。

2. データの保存場所を制御します。 データ所在地の要件を満たすために、地域(米国やヨーロッパなど) 内のリージョンを選択します。 特定の Azure サービス 選択したリージョンの外部にデータが格納される可能性があるため、例外を確認します。 Azure データ所在地の設定とコンプライアンス要件を定期的に確認して、顧客データを完全に制御します。

3. 内部 ("Corp") ワークロードとインターネットに接続する ("オンライン") ワークロードを分離します。 管理グループを使用して、内部ワークロードと外部ワークロードを分離します。 通常、内部ワークロードには、企業ネットワークへの接続またはハイブリッド接続が必要です。 外部ワークロードは通常、企業ネットワーク接続を必要とせず、直接の受信または送信インターネット アクセスが必要な場合があります。 たとえば、Azure ランディング ゾーンでは、「Corp」（内部向け）および「Online」（インターネット向け）の管理グループを確認してください。

4. アクセス制御を適用します。 Azure RBAC や ABAC などの堅牢なアクセス制御を実装して、定義済みの分類に基づいて、承認された担当者のみが機密データにアクセスできるようにします。

5. 削除からデータを保護します。 論理的な削除、データのバージョン管理、不変性などの機能を使用可能な場合に使用します。 データベースのバージョン管理を実装し、ロールバック 手順を準備します。 Azure Policy を使用して、データストアの削除を明示的に拒否する (Deny または DenyAction) か、または変更を監査します (Audit または auditIfNotExists)。 Bicep を使用する場合は、Bicep デプロイ スタック を使用して、未承認の変更を防ぐことを検討してください。 重要なデータ 意図しない変更や削除を防ぐために、リソース ロック 厳密にのみ使用してください。 リソース ロックを使用して構成を保護しないようにします。リソース ロックによって IaC デプロイが複雑になります

6. ワークロード データを管理します。データ分類に関する Well-Architected Framework の推奨事項を参照してください。

詳細については、「データ ガバナンスを適用する」を参照してください。

コストの管理

クラウド運用でコストを管理することは、ワークロードごとに一元的に支出を積極的に追跡することを意味します。 コスト管理では、支出を可視化し、責任ある支出を促進する必要があります。 次の手順に従います。

1. コストの管理とレビューを行います。 Microsoft Cost Management ツールを使用して、クラウド コストの を監視します。 Azure には、特定のしきい値で支出を上限とするためのサブスクリプション全体のメカニズムがありません。 Azure Log Analytics ワークスペースなどの一部のサービスには、使用制限があります。 コスト監視戦略は、経費を管理するための主要なツールとして機能します。

2. ワークロードのコストを管理します。 ワークロード チームへの課金アクセス権を付与します。 これらのチームは、Well-Architected Framework のコスト最適化 チェックリスト使用します。

コードとランタイムを管理する

コードとランタイムの管理は、ワークロードの役割です。 ワークロード チームに、Well-Architected Framework の Operational Excellence チェックリストを使用してもらいます。このチェックリストには、コードとランタイムを制御するための 12 個の推奨事項が記載されています。

クラウド リソースの管理

クラウド リソースの管理には、すべての Azure サービス、デプロイ、インフラストラクチャのガバナンス、監視、およびメンテナンスが含まれます。 環境間の一貫性を維持するために、明確なデプロイ プロトコルとプロアクティブなドリフト検出戦略を確立します。 次の推奨事項に従います。

ポータルベースのデプロイを管理する

運用上の問題の可能性を最小限に抑えるために、ポータル ベースのデプロイのプロトコルと制限を定義します。 次の手順に従います。

1. ポータル展開ポリシーを定義します。 ポータルベースの重要な変更が、確立された変更管理プロセスに準拠していることを確認します。 ポータルのデプロイは、主に、開発環境およびテスト環境での迅速なプロトタイプ作成、トラブルシューティング、または軽微な調整に使用します。 これらの変更は、誤差、構成の誤り、コンプライアンスの問題につながるため、非構造化ポータルの変更を避けます。 代わりに、一貫性を保つため、バージョン管理されたコードとしてのインフラストラクチャ (IaC) テンプレートに依存します。 詳細については、コード ベースのデプロイを参照してください。

2. 環境を区別します。 ポータルベースの変更を非運用環境に厳密に制限します。 専用の開発環境またはテスト環境でのみ迅速なプロトタイプ作成を可能にし、運用環境で厳格な制御を適用します。

3. ポータルのアクセス許可を制限します。 ロールベースのアクセス制御 (RBAC) を使用して、ポータルからのデプロイ機能を制限します。 既定で読み取り専用のアクセス許可を割り当て、必要な場合にのみ特権をエスカレートします。

   • Just-In-Time アクセスを許可します。 Azure および Microsoft Entra リソースにアクセスするために、Privileged Identity Management (PIM) を使用します。 PIM をアクティブ化するには、複数の個人またはグループからの順次承認が必要です。 緊急シナリオ専用の特権ロール ("A0" スーパー管理者ロール) を予約します。

   • 運用モデルに基づいて RBAC を構造化します。 サポート レベル、セキュリティ運用、プラットフォーム、ネットワーク、ワークロードなど、運用チームに合わせて調整された RBAC ポリシーを設計します。

   • すべてのアクティビティを監査します。 システム内のすべてのアクションを監視して記録します。 Azure Policy を使用して、変更を監査します (Audit または auditIfNotExists)。 さらに、Azure Monitor で アラートを構成して、だれかが Azure リソースを削除したときに関係者に通知します。 Bicep を使用する場合は、Bicep デプロイ スタック を使用して、未承認の変更を防ぐことを検討してください。

4. バージョン管理されたテンプレートを使用します。 IaC デプロイを使用する場合は、ポータルの使用を緊急シナリオに制限します。 ポータルの変更により、IaC テンプレートからの構成ドリフトが発生します。 Bicep、Terraform、ARM テンプレートなどのバージョン管理された IaC テンプレートにおけるすべてのポータルベースの変更を直ちにレプリケートします。 Azure リソース構成を定期的にエクスポートし、IaC として格納して、承認済みのトレース可能な構成に合わせて運用環境を維持します。 Azure 構成を Bicep 、Terraform 、または ARM テンプレート としてエクスポートする方法に関するガイダンスを参照してください。 ARM テンプレートを使用する場合は、テンプレート のスペック を検討してください。

   ツール	ユース ケース
   Bicep	管理可能で読みやすい Azure 固有の IaC
   Terraform	マルチクラウド ソリューション、より広範なコミュニティ サポート
   ARM テンプレート	JSON で快適なフル コントロール

コードベースのデプロイを管理する

コードベースのデプロイを採用して、複雑または大規模な変更を自動化および制御します。 次の手順に従います。

1. ツールを標準化します。 コンテキストの切り替えを最小限に抑えるには、一貫性のあるツールセットを使用します。 開発者ツール (VS Code、Visual Studio)、コード リポジトリ (GitHub、Azure DevOps)、CI/CD パイプライン (GitHub Actions、Azure Pipelines)、IaC ソリューション (Bicep、Terraform、または ARM テンプレート) を選択します。

2. バージョン 管理を使用します。 コードの単一の信頼のソースを維持します。 バージョン管理を使用して、構成の誤差を減らし、ロールバック手順を簡略化します。

3. デプロイ パイプラインを使用します。CI/CD パイプライン ビルド プロセスを自動化し、テストを実行し、各プル要求で品質とセキュリティの問題をコードでスキャンします。 GitHub Actions または Azure Pipelines を使用して、アプリケーション コードと IaC ファイルをビルドおよびデプロイします。 事前コミット フックと自動スキャンを適用して、未承認または高リスクの変更を早期にキャッチします。

4. デプロイをテストします。 CI/CD パイプライン内で承認をステージし、デプロイを段階的に検証します。 開発、ビルド検証、統合テスト、パフォーマンス テスト、ユーザー受け入れテスト (UAT)、ステージング、カナリア リリース、実稼働前、最後に運用という順序に従います。

5. コードとしてのインフラストラクチャ (IaC) を使用します。 IaC を使用して一貫性を確保し、バージョン管理によってデプロイを管理します。 Azure portal ベースの概念実証から運用環境用の IaC に移行します。 リソースを定義するには、Bicep、Terraform、または ARM テンプレートを使用します。 Bicep の場合は、 モジュールを使用し、デプロイ スタック を考慮してください。 ARM テンプレートの場合は、バージョン管理されたデプロイのために テンプレート仕様 を使用することを検討してください。

6. コード リポジトリのベスト プラクティスを適用します。 これらの標準に従えば、エラーが減り、コード レビューが合理化され、統合の問題が回避されます。 優先度の高い運用環境の場合:

   要件	説明
   ダイレクト プッシュを無効にする	メイン ブランチへの直接コミットをブロックする
   プル要求を必須にする	プル要求を通過するためにすべての変更を要求する
   コード レビューを要求する	作成者以外のユーザーがすべての pull request をレビューすることを確認する
   コード カバレッジのしきい値を適用する	コードの最小割合がすべてのプル要求の自動テストに合格していることを確認する
   検証パイプラインを使用する	プル要求の検証パイプラインを実行するようにブランチ保護規則を構成する

7. ワークロード チームのオンボーディング チェックが必要です。 新しいコードベースとチームがビジネス目標、標準、ベスト プラクティスと一致していることを確認します。 チェックリストを使用して、コード リポジトリの構造、名前付け標準、コーディング標準、および CI/CD パイプライン構成を確認します。

構成の誤差を管理する

目的の構成とライブ環境の間の不一致を特定して修正することで、構成の誤差を管理します。 次のベスト プラクティスに従います。

1. 変更を防止して検出します。変更分析 を使用して、構成の変更を検出し、その根本的な原因を説明します。 (Deny、DenyAction)、(Audit、auditIfNotExists) などの効果を使用して、Azure Policy を使用して変更を拒否および監査します。 Bicep を使用する場合は、Bicep デプロイ スタック を使用して、未承認の変更を防ぐことを検討してください。

2. IaC 構成の誤差を検出します。 ドリフトは、他のユーザーが IaC ファイルを更新したとき (意図的に、意図しない)、または Azure portal で変更を加えたときに発生します。 ライブ環境を目的の構成と定期的に比較し、ドリフトを検出します。

   • 必要な構成と最後に既知の適切な構成を格納します。 目的の構成ファイルをバージョン管理されたリポジトリに保存します。 このファイルには、元の意図した構成が表示されます。 信頼性の高いロールバック参照とドリフト検出のベースラインとして、最後の既知の適切な構成を維持します。

   • デプロイ前に構成ドリフトを検出します。 デプロイ前に潜在的な変更をプレビューするために、Terraform プラン、Bicep what-if、または ARM テンプレート what-ifを使用します。 不一致を徹底的に調査して、提案された変更が目的の状態と一致することを確認します。

   • デプロイ後のドリフトを検出します。 定期的なドリフト チェックを通じて、ライブ環境と目的の構成を定期的に比較します。 これらのチェックを CI/CD パイプラインに統合するか、一貫性を維持するために手動で実行します。

   • 前回の正常な構成にロールバックします。 CI/CD パイプライン内で自動化されたプロシージャを使用する明確なロールバック戦略を開発します。 前回の既知の適切な構成を利用して、望ましくない変更をすばやく元に戻し、ダウンタイムを最小限に抑えます。

   • ポータルに基づく変更を最小限に抑えます。 緊急シナリオのみに対する IaC 以外の変更を最小限に抑えます。 Privileged Identity Management などの厳密なアクセス制御を適用します。 必要な構成の精度を維持するために手動で調整が必要な場合は、すぐに IaC ファイルを更新します。

オペレーティング システムの管理

仮想マシンを使用する場合は、オペレーティング システムも管理する必要があります。 次の手順に従います。

1. 仮想マシンのメンテナンスを自動化します。 Azure では、自動化ツール を使用して、Azure 仮想マシンを作成および管理します。 Azure Machine Configuration を使用して、Azure とハイブリッドで実行されているマシンのコードとしてオペレーティング システム設定を監査または構成します。

2. *オペレーティング システムを更新します。 ゲスト更新プログラムとホスト メンテナンス を管理、オペレーティング システムがセキュリティ上の目的で最新であることを確認する必要があります。

3. ゲスト内操作を監視します。Azure Change Tracking および Inventory サービス を使用して、ゲスト内操作の監査とガバナンスを強化します。 変更を監視し、Azure、オンプレミス、およびその他のクラウド環境全体のサーバーの詳細なインベントリ ログを提供します。

Azure 管理ツール