次の方法で共有


クラウド ガバナンス ポリシーを文書化する

チームは、リスク評価の分析情報を使用して、これらのリスクを処理するためのポリシーを作成するようになりました。 重大なリスクまたはリスクのグループごとに、対応するガバナンス ポリシーが 1 つ以上存在する必要があります。 クラウド ガバナンス ポリシーを文書化するときは、次のベスト プラクティスを検討してください。

クラウド ガバナンスを設定して維持するプロセスを示す図。この図は、クラウド ガバナンス チームの構築、クラウド ガバナンス ポリシーの文書化、クラウド ガバナンス ポリシーの適用、クラウド ガバナンスの監視という 5 つの一連の手順を示しています。1 回実行する最初の手順。クラウド ガバナンスを設定し、継続的にクラウド ガバナンスを維持するために、最後の 4 つの手順を 1 回実行します。

1. 標準ポリシーの形式と言語を確立する

すべてのポリシーに一貫性のあるテンプレートまたは形式を作成します。 各ポリシー ドキュメント (またはセクション) には、ID、ステートメント、スコープなどの主要な要素を含める必要があります。 明確で明確な言語を使用します。 ポリシーは、権限のある参照を目的としているため、関係者が誤って解釈する余地をなくして簡単に理解できるようにする必要があります。 たとえば、要件に対して "must" や "must not" などの標準的な表現を決定し、あいまいな用語を避けます。 ID、カテゴリ、目的を持つポリシーなどの標準化された形式により、ポリシーの移動と保守が容易になります。

2. クラウド ガバナンス ポリシーを定義する

リスクを軽減するためにクラウドを使用および管理する方法を説明するクラウド ガバナンス ポリシーを作成します。 頻繁なポリシー更新の必要性を最小限に抑えます。 クラウド ガバナンス ポリシーを定義するには、次の推奨事項に従います。

  1. ポリシー ID を使用します。 ポリシー カテゴリと数値を使用して、最初のセキュリティ ガバナンス ポリシーの SC01 など、各ポリシーを一意に識別します。 新しいリスクを追加するときに、識別子を順番にインクリメントします。 リスクを取り除く場合は、シーケンスにギャップを残すか、使用可能な最小数を使用できます。

  2. ポリシー ステートメントを含めます。 特定されたリスクに対処する特定のポリシー ステートメントを作成します。 mustshouldmust notshouldn't といった確定的な表現を使用します。 リスク リストの適用コントロールを開始点として使用します。 構成手順ではなく、結果に焦点を当てます。 コンプライアンスを監視する場所を把握できるように、適用に必要なツールに名前を付けます。

  3. リスク ID を含めます。 ポリシーのリスクを一覧表示します。 すべてのクラウド ガバナンス ポリシーをリスクに関連付けます。

  4. ポリシー カテゴリを含めます。 ポリシーの分類には、セキュリティ、コンプライアンス、コスト管理などのガバナンス カテゴリを含めます。 カテゴリは、クラウド ガバナンス ポリシーの並べ替え、フィルター処理、および検索に役立ちます。

  5. ポリシーの目的を含めます。 各ポリシーの目的を指定します。 ポリシーが満たすリスクまたは規制コンプライアンス要件を出発点として使用します。

  6. ポリシー スコープを定義します。 すべてのクラウド サービス、リージョン、環境、ワークロードなど、このポリシーが適用される内容と対象を定義します。 あいまいさがないように、例外を指定します。 標準化された言語を使用して、ポリシーの並べ替え、フィルター処理、検索を簡単に行うことができます。

  7. ポリシー修復戦略を含めます。 クラウド ガバナンス ポリシーの違反に対する望ましい対応を定義します。 非運用環境の違反に関するディスカッションのスケジュール設定や、運用環境の違反に対する即時の修復作業など、リスクの重大度に合わせて対応を調整します。

詳細については、 クラウド ガバナンス ポリシーの例を参照してください。

3. クラウド ガバナンス ポリシーを配布する

クラウド ガバナンス ポリシーに準拠する必要があるすべてのユーザーにアクセス権を付与します。 組織内のユーザーにとってクラウド ガバナンス ポリシーへの準拠を容易にする方法を探します。 クラウド ガバナンス ポリシーを配布するには、次の推奨事項に従います。

  1. 一元化されたポリシー リポジトリを使用します。 すべてのガバナンス ドキュメントに対して、一元化された簡単にアクセスできるリポジトリを使用します。 すべての関係者、チーム、個人が最新バージョンのポリシーと関連ドキュメントにアクセスできることを確認します。

  2. コンプライアンス チェックリストを作成します。 ポリシーの迅速で実用的な概要を提供します。 広範なドキュメントを参照しなくても、チームが簡単に準拠できるようにします。 詳細については、 コンプライアンス チェックリストの例を参照してください。

4. クラウド ガバナンス ポリシーを確認する

クラウド ガバナンス ポリシーを評価して更新し、クラウド環境の管理に関連性があり、効果的であることを確認します。 定期的なレビューは、変化する規制要件、新しいテクノロジ、進化するビジネス目標に合わせてクラウド ガバナンス ポリシーを確実に調整するのに役立ちます。 ポリシーを確認するときは、次の推奨事項を検討してください。

  1. フィードバック メカニズムを実装します。 クラウド ガバナンス ポリシーの有効性に関するフィードバックを受け取る方法を確立します。 ポリシーの影響を受ける個人からの入力を収集して、引き続き効率的に仕事を実行できるようにします。 実際の課題とニーズを反映するようにガバナンス ポリシーを更新します。

  2. イベントベースのレビューを確立します。 失敗したガバナンス ポリシー、テクノロジの変更、規制コンプライアンスの変更などのイベントに対応して、クラウド ガバナンス ポリシーを確認して更新します。

  3. 定期的なレビューをスケジュールします。 ガバナンス ポリシーを定期的に見直し、進化する組織のニーズ、リスク、クラウドの進化に合わせて調整します。 たとえば、利害関係者との定期的なクラウド ガバナンス会議にガバナンス レビューを含めます。

  4. 変更制御を容易にする。 ポリシーのレビューと更新のプロセスを含めます。 クラウド ガバナンス ポリシーが、組織、規制、技術の変更に合わせて維持されるようにします。 ポリシーを編集、削除、または追加する方法を明確にします。

  5. 非効率性を特定する。 ガバナンス ポリシーを確認して、クラウド アーキテクチャと運用の非効率性を見つけて修正します。 たとえば、各ワークロードで独自の Web アプリケーション ファイアウォールを使用する必要があることを管理する代わりに、一元化されたファイアウォールの使用を要求するようにポリシーを更新します。 重複した作業を必要とするポリシーを確認し、作業を一元化する方法があるかどうかを確認します。

クラウド ガバナンス ポリシーの例

参考のために、次のクラウド ガバナンス ポリシーの例を示します。 これらのポリシーは、 リスク リストの例に基づいています。

ポリシー ID ポリシー カテゴリ リスク ID ポリシー ステートメント 目的 Scope Remediation モニタリング
RC01 規制に対するコンプライアンス R01 Microsoft Purview を使用して機密データを監視する必要があります。 規制に対するコンプライアンス ワークロード チーム、プラットフォーム チーム 影響を受けるチームによる即時アクション、コンプライアンス トレーニング Microsoft Purview
RC02 規制に対するコンプライアンス R01 毎日の機密データ コンプライアンス レポートは、Microsoft Purview から生成する必要があります。 規制に対するコンプライアンス ワークロード チーム、プラットフォーム チーム 1 日以内の解決、確認監査 Microsoft Purview
SC01 セキュリティ R02 すべてのユーザーに対して多要素認証 (MFA) を有効にする必要があります。 データ侵害と未承認のアクセスを軽減する Azure ユーザー ユーザー アクセスの取り消し Microsoft Entra ID の条件付きアクセス
SC02 セキュリティ R02 アクセス レビューは、Microsoft Entra ID ガバナンスで毎月実施する必要があります。 データとサービスの整合性を確保する Azure ユーザー コンプライアンス違反の即時アクセス取り消し ID ガバナンス
SC03 セキュリティ R03 Teams では、すべてのソフトウェアとインフラストラクチャ コードを安全にホストするために、指定された GitHub 組織を使用する必要があります。 コード リポジトリの安全で一元的な管理を確保する 開発チーム 指定された GitHub 組織への承認されていないリポジトリの転送と、コンプライアンス違反に対する潜在的な処分アクション GitHub 監査ログ
SC04 セキュリティ R03 パブリック ソースのライブラリを使用するチームは、検疫パターンを採用する必要があります。 開発プロセスに統合する前に、ライブラリが安全で準拠していることを確認する 開発チーム 非準拠ライブラリの削除と、影響を受けるプロジェクトの統合プラクティスのレビュー 手動監査 (月単位)
CM01 コスト管理 R04 ワークロード チームは、リソース グループ レベルで予算アラートを設定する必要があります。 過剰支出を防ぐ ワークロード チーム、プラットフォーム チーム 即時レビュー、アラートの調整 Microsoft Cost Management
CM02 コスト管理 R04 Azure Advisor のコストに関する推奨事項を確認する必要があります。 クラウドの使用を最適化する ワークロード チーム、プラットフォーム チーム 60 日後の必須の最適化監査 Advisor
OP01 オペレーション R05 運用ワークロードには、リージョン間でアクティブ/パッシブ アーキテクチャが必要です。 サービス継続性を確保する 作業負荷チーム アーキテクチャの評価、2 年 1 回のレビュー 手動監査 (運用リリースごと)
OP02 オペレーション R05 ミッションクリティカルなすべてのワークロードは、リージョン間でのアクティブ-アクティブアーキテクチャを実装する必要があります。 サービス継続性を確保する 重要なワークロードチーム 90 日以内の更新、進行状況のレビュー 手動監査 (運用リリースごと)
DG01 データ R06 転送中と保存中の暗号化は、すべての機密データに適用する必要があります。 機密データを保護する 作業負荷チーム 即時暗号化の適用とセキュリティ トレーニング Azure Policy
DG02 データ R06 すべての機密データに対して、Microsoft Purview でデータ ライフサイクル ポリシーを有効にする必要があります。 データ ライフサイクルを管理する 作業負荷チーム 60 日以内の実装、四半期ごとの監査 Microsoft Purview
RM01 リソース管理 R07 リソースをデプロイするには、Bicep を使用する必要があります。 リソース プロビジョニングを標準化する ワークロード チーム、プラットフォーム チーム 即時 Bicep 移行計画 継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン
RM02 リソース管理 R07 Azure Policy を使用して、すべてのクラウド リソースにタグを適用する必要があります。 リソースの追跡を容易にする すべてのクラウド リソース 30 日以内の正しいタグ付け Azure Policy
AI01 AI R08 AI コンテンツ フィルタリングの構成は、中以上に設定する必要があります。 AI の有害な出力を軽減する 作業負荷チーム 即時是正措置 Azure OpenAI Service
AI02 AI R08 顧客向けの AI システムは、毎月セキュリティテストを実施する必要があります。 AI バイアスを特定する AI モデル チーム ミスに対する即時レビュー、是正措置 手動監査 (月単位)

次のステップ