クラウド ガバナンス ポリシーを文書化する
この記事ではクラウド ガバナンス ポリシーを定義して文書化する方法について説明します。 クラウド ガバナンス ポリシーでは、クラウドで行うべきことや起きてはいけないことを指定します。 クラウド ガバナンス チームは、リスク評価で特定されたリスクごとに 1 つ以上のクラウド ガバナンス ポリシーを作成する必要があります。 クラウド ガバナンス ポリシーはクラウドとやり取りするためのガードレールを定義します。
クラウド ガバナンス ポリシーを文書化するためのアプローチを定義する
クラウド サービスの使用を管理する規則とガイドラインを作成、維持、更新するためのアプローチを確立します。 クラウド ガバナンス ポリシーは特定のワークロードに固有であるべきではありません。 目標は、頻繁な更新を必要とせず、クラウド環境全体へのクラウド ガバナンス ポリシーの影響を考慮しているクラウド ガバナンス ポリシーを作成することです。 ポリシー ドキュメントのアプローチを定義するには、次の推奨事項に従ってください。
標準のガバナンス文言を定義します。 クラウド ガバナンス ポリシーを文書化するための標準の構造と形式を策定します。 ポリシーは、利害関係者にとって明確かつ、信頼の置けるものである必要があります。
ガバナンスのさまざまなスコープを認識します。 組織内の固有のロールに合わせて調整された特定のガバナンス責任を定義して割り当てます。 たとえば、開発者はアプリケーション コードを管理します。 ワークロード チームは 1 つのワークロードを担当し、プラットフォーム チームはワークロードが継承するガバナンスを担当します。
クラウド ガバナンスの広範な効果を評価します。 クラウド ガバナンスによって摩擦が生じます。 摩擦と自由のバランスを見つけます。 クラウド ガバナンス ポリシーを策定する際に、ガバナンスがワークロード アーキテクチャ、ソフトウェア開発プラクティス、およびその他の領域に及ぼす影響を考慮してください。 たとえば、何を許可するか禁止するかにより、ワークロード アーキテクチャが決まり、ソフトウェア開発プラクティスが影響を受けます。
クラウド カバナンス ポリシーを定義する
リスクを軽減するためにクラウドを使用して管理する方法を定めたクラウド ガバナンス ポリシーを作成します。 頻繁なポリシー更新の必要性を最小限に抑えます。 クラウド ガバナンス ポリシーを定義するには、次の推奨事項に従ってください。
ポリシー ID を使用します。 SC01 など、ポリシー カテゴリと番号を使用することで、最初のセキュリティ ガバナンス ポリシーに関する各ポリシーを一意に識別します。 新しいリスクを追加するときに、識別子を順番にインクリメントします。 リスクを削除する場合は、シーケンスに欠番を残しても、使用可能な最小数を使用してもかまいません。
ポリシー ステートメントを含めます。 特定されたリスクに対処する特定のポリシー ステートメントを作成します。 必要、べき、してはならない、べきではない などの明確な文言を使用します。 リスク リストに基づく実施コントロールを出発点として使用します。 構成手順ではなく、結果に焦点を当てます。 コンプライアンスを監視する場所を把握できるように、実施に必要なツールを指定します。
リスク ID を含めます。 ポリシーのリスクをリスト化します。 すべてのクラウド ガバナンス ポリシーをリスクに関連付けます。
ポリシー カテゴリを含めます。 ポリシーの分類にはセキュリティ、コンプライアンス、コスト管理などのガバナンス カテゴリを含めます。 カテゴリは、クラウド ガバナンス ポリシーの並べ替え、フィルター処理、検索に役立ちます。
ポリシーの目的を含めます。 各ポリシーの目的を指定します。 リスクや、ポリシーが満たす規制コンプライアンス要件を出発点として使用します。
ポリシー スコープを定義します。 すべてのクラウド サービス、リージョン、環境、ワークロードなど、このポリシーが適用されるものや人物を定義します。 曖昧さを避けるために、例外を指定します。 標準化された文言を使用すると、ポリシーの並べ替え、フィルター処理、検索を簡単に行うことができます。
ポリシー修復戦略を含めます。 クラウド ガバナンス ポリシーの違反に対する望ましい対応を定義します。 非運用環境の違反に関するディスカッションのスケジュール設定や、運用環境の違反に対する即時の修復作業など、リスクの重大度に合わせて対応を調整します。
詳細については、「クラウド ガバナンス ポリシーの例」を参照してください。
クラウド ガバナンス ポリシーを配布する
クラウド ガバナンス ポリシーに準拠する必要があるすべての人にアクセス権を付与します。 組織内の人にとってクラウド ガバナンス ポリシーへの準拠がより簡単になる方法を探します。 クラウド ガバナンス ポリシーを配布するには、次の推奨事項に従ってください。
一元化されたポリシー リポジトリを使用します。 すべてのガバナンス ドキュメントに対して、一元化された簡単にアクセスできるリポジトリを使用します。 すべての関係者、チーム、個人が最新バージョンのポリシーと関連ドキュメントにアクセスできることを確認します。
コンプライアンス チェックリストを作成します。 ポリシーをすばやく確認できる実用的な概要を準備します。 ドキュメントを広範に参照しなくても、チームが簡単に準拠できるようにします。 詳細については、「コンプライアンス チェックリストの例」をご覧ください。
クラウド ガバナンス ポリシーをレビューする
クラウド ガバナンス ポリシーを評価して更新し、クラウド環境の管理が継続的に適切で、効果的であることを確認します。 定期的なレビューは、変化する規制要件、新しいテクノロジ、進化するビジネス目標に合わせてクラウド ガバナンス ポリシーを確実に調整するのに役立ちます。 ポリシーをレビューするときは、次の推奨事項を検討してください。
フィードバック メカニズムを実装します。 クラウド ガバナンス ポリシーの有効性に関するフィードバックを受け取る方法を確立します。 ポリシーの影響を受ける個人から情報を収集して、引き続き効率的に仕事を遂行できるようにします。 実際の課題とニーズを反映するようにガバナンス ポリシーを更新します。
イベントベースのレビューを確立します。 失敗したガバナンス ポリシー、テクノロジの変更、規制コンプライアンスの変更などのイベントに対応して、クラウド ガバナンス ポリシーを確認して更新します。
定期的なレビューをスケジュールします。 ガバナンス ポリシーを定期的に見直し、進化する組織のニーズ、リスク、クラウドの発展に合わせて調整します。 たとえば、利害関係者との定期的なクラウド ガバナンス会議でガバナンス レビューを行います。
変更制御を促進します。 ポリシーのレビューと更新のプロセスを含めます。 クラウド ガバナンス ポリシーが、組織、規制、技術の変更に合わせて維持されるようにします。 ポリシーを編集、削除、または追加する方法を明確にします。
非効率性を特定します。 ガバナンス ポリシーを確認して、クラウド アーキテクチャと運用の非効率性を見つけて修正します。 たとえば、各ワークロードで独自の Web アプリケーション ファイアウォールを使用するように義務づけるのではなく、一元化されたファイアウォールの使用を求めるようにポリシーを更新します。 重複した作業を必要とするポリシーを確認して、作業を一元化する方法があるかどうかを確認します。
クラウド ガバナンス ポリシーの例
参考として、次のクラウド ガバナンス ポリシーの例をご覧ください。 これらのポリシーは、リスク リストの例に基づいています。
| ポリシー ID | ポリシー カテゴリ | リスク ID | ポリシー ステートメント | 目的 | 範囲 | 修復 | 監視 |
|---|---|---|---|---|---|---|---|
| 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 | チームでは、すべてのソフトウェアとインフラストラクチャ コードを安全にホストするために、指定された 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 モデル チーム | ミスに対する即時レビュー、是正措置 | 手動監査 (月単位) |