ガバナンスのアンチパターン
クラウド導入のガバナンス フェーズ中にアンチパターンが発生する可能性があります。 共有責任と、これらのアンチパターンを回避するために、既存のフレームワークでセキュリティ戦略を構築する方法について説明します。
アンチパターン: 共同責任を誤解している
クラウドを導入する場合、さまざまなサービス モデルに関して、お客様の責任がどこで終わり、クラウド プロバイダーの責任がどこから始まるかが常に明確であるとは限りません。 サービス モデルを使用する作業項目に関するプロセスと手法を構築するには、クラウドのスキルと知識が必要です。
例: クラウド プロバイダーが更新プログラムを管理している場合
企業の人事 (HR) 部門のメンバーは、サービスとしてのインフラストラクチャ (IaaS) を使用して、クラウド上に複数の Windows サーバーをセットアップします。 彼らは、クラウド プロバイダーが更新プログラムを管理すると想定しています。通常、オンサイトの IT 担当者が更新プログラムのインストールを処理するからです。 人事部門は、Azure が既定でオペレーティング システム (OS) 更新プログラムを展開およびインストールしないことを認識していないため、更新プログラムを構成しません。 その結果、サーバーは非準拠になり、セキュリティ上のリスクが生じます。
推奨される結果: 準備計画を作成する
クラウドにおける共同責任について理解します。 準備計画を構築します。 準備計画によって、専門知識を学び、深めるための継続的な機運を生み出すことができます。
アンチパターン: すぐに使用できるソリューションによりセキュリティが提供されると想定する
企業は、クラウド サービスに固有の機能としてセキュリティを見る傾向があります。 この想定は正しい場合が多いですが、ほとんどの環境では、セキュリティ要件とは異なる可能性があるコンプライアンス フレームワーク要件に従う必要があります。 Azure は基本的なセキュリティを提供し、 Azure ポータル は Microsoft Defender for Cloud を使用してより高度なセキュリティを提供できます。 サブスクリプションを作成するときは、コンプライアンスとセキュリティ標準を適用するようにソリューションをカスタマイズする必要があります。
例: クラウド セキュリティを軽視する
ある企業では、クラウドで新しいアプリケーションを開発しています。 多くの PaaS (サービスとしてのプラットフォーム) サービスと、デバッグ目的でいくつかの IaaS コンポーネントに基づいてアーキテクチャを選択しています。 アプリケーションを運用環境にリリースした後、ジャンプ サーバーの 1 つが侵害され、不明な IP アドレスにデータを抽出されていたことに気付きました。 ジャンプ サーバーのパブリック IP アドレスと推測しやすいパスワードが問題であることがわかりました。 クラウド セキュリティに重点を置いていれば、この状況を回避できたはずです。
推奨される結果: クラウド セキュリティ戦略を定義する
適切なクラウド セキュリティ戦略を定義します。 詳細については、CISO クラウド準備ガイドを参照してください。 このガイドには、最高情報セキュリティ責任者 (CISO) を参照してください。 CISO クラウド準備ガイドでは、セキュリティ プラットフォーム リソース、プライバシーと管理、コンプライアンス、透明性などのトピックについて説明しています。
セキュリティで保護されたクラウド ワークロードについては、Azure セキュリティ ベンチマークに関するページを参照してください。 ほとんどのセキュリティ リスクと対策に対応している、Center for Internet Security の CIS Controls v7.1 と National Institute of Standards and Technology の NIST SP800-53 に基づいて構築されています。
Microsoft Defender for Cloud を使用して、リスクを特定し、ベスト プラクティスを適応させ、企業のセキュリティ態勢を改善してください。
Azure Policy および Azure Policy as Code ソリューションを使用して、企業固有の自動化されたコンプライアンス要件とセキュリティ要件を実装またはサポートします。
アンチパターン: 独自のコンプライアンスまたはガバナンス フレームワークを使用する
業界標準に基づいていないカスタムのコンプライアンスおよびガバナンスのフレームワークを導入すると、クラウドの導入時間が大幅に長くなる可能性があります。 これは、カスタム フレームワークからクラウド設定への変換が複雑になる可能性があるためです。 この複雑さにより、カスタム対策と要件を実装可能なセキュリティ制御に変換するために必要な労力が増加する可能性があります。 企業は通常、同様のセキュリティおよびコンプライアンスの要件に準拠する必要があります。 その結果、ほとんどのカスタムのコンプライアンスおよびセキュリティ フレームワークは、現在のコンプライアンス フレームワークとわずかに異なることになります。 追加のセキュリティ要件がある企業は、新しいフレームワークの構築を検討できます。
例: カスタムのセキュリティ フレームワークを使用する
企業の CISO は、IT セキュリティ担当の従業員に、クラウド セキュリティの戦略とフレームワークを考案するタスクを割り当てます。 IT セキュリティ部門では、業界標準に基づいて構築するのではなく、現在のオンプレミス セキュリティ ポリシーに基づいて構築された新しいフレームワークを作成します。 このクラウド セキュリティ ポリシーを完了した後、AppOps チームと DevOps チームはクラウド セキュリティ ポリシーを実装するのが困難になります。
Azure には、この企業独自のフレームワークとは異なる、より包括的なセキュリティとコンプライアンスの構造が用意されています。 CISO チームは、Azure の制御が自社のコンプライアンスおよびセキュリティ規則と互換性がないと考えています。 そのフレームワークが標準化された制御に基づいていたとしたら、このような結論には至らなかったでしょう。
推奨される結果: 既存のフレームワークに依存する
カスタムの企業コンプライアンス フレームワークを確立または導入する前に、CIS Controls バージョン 7.1 や NIST SP 800-53 などの既存のフレームワークを使用または構築します。 既存のフレームワークを使用することで、クラウド セキュリティ設定への移行がより簡単になり、測定しやすくなります。 フレームワークの実装の詳細については、Azure ランディング ゾーンの実装オプションに関するページを参照してください。