企業ポリシー

完了

不適切なガバナンス ポリシーは、不要な制約をもたらし、企業を保護できない可能性があります。 このユニットでは、適切でアクションにつながる企業ポリシーを作成するための各方法を評価します。

Tailwind Traders の不適切な企業ポリシー

顧客のストーリーで紹介した Tailwind Traders の既存のポリシーは、何が問題なのでしょうか。

Tailwind のポリシー: "顧客と財務に関するデータは既存のデータ センターの特定のネットワーク セグメントでのみホストでき、保護された資産と呼ぶ。"

企業ポリシーは、組織によって許容範囲内と見なされない明確なリスクに対処するための最善の方法を、チームに指示するために設計されます。 企業ポリシーは、特定の技術的な実装を要求するために設計されるものではありません。

既存の企業ポリシーを評価する

クラウドや他の新しいテクノロジに適用するために既存の企業ポリシーを評価する場合は、次の質問に答えられるようにする必要があります。

  • このポリシーで軽減しようとしているのは、どのようなリスクか?
  • そのリスクが組織のリスク許容範囲内にないのはなぜか?
  • そのリスクを許容できないと判断したのはだれか?
  • このポリシーはどのようなタイミングで適用すべきか (ワークロードの分類、状況に応じて、など)? 例外はいつ確認すべきか?
  • このプロセスはどのように適用するか? このポリシーの妥当性はどのくらいの頻度で確認すべきか?
  • テクノロジに重点を置いたプロセスの場合、特定のテクノロジ ソリューションやテクノロジ ベンダーに依存することで、このポリシーによって新たなリスクが発生するか?

次のユニットで学習するように、保護されたデータに関する Tailwind Traders のポリシーでは、これらの質問に回答することができません。 その一部については、ポリシー ハンドブックのような別の場所で対処されている可能性がありますが、最後のテクノロジに重点を置いた場合に関する質問は、否定できないミスです。 リスクを軽減する代わりに、実際には 1 つのソリューションに固定することによって長期的なリスクがもたらされています。

企業ポリシーの定義

企業ポリシーを定義するには、組織が使用しているクラウド プラットフォームに関係なく、ビジネス上のリスクを特定して軽減することに注目する必要があります。 正常なクラウドガバナンス戦略は、健全な企業ポリシーを定義することから始まります。 以下の 3 ステップのプロセスは、健全な企業ポリシーを反復開発の指針となります。

   

Business risk icon.

ビジネス リスク:現在のクラウド導入計画とデータ分類を調査し、ビジネス上のリスクを特定します。 企業と協力し、リスク許容度とリスク軽減コストのバランスを取ります。

Policy and compliance icon.

ポリシーとコンプライアンス: リスク許容度を評価することで、クラウドの導入を統制しリスクを管理するためのポリシーに役立てます。 業界によっては、サードパーティのコンプライアンスが最初のポリシー作成に影響を及ぼします。

Process enforcement icon.

プロセス: 導入の速度とイノベーションのアクティビティにより、自然にポリシー違反が発生します。 関連するプロセスを実行することは、ポリシーへの準拠を監視し、徹底する上で役立ちます。

ビジネス リスク

クラウドの導入時には、さまざまなリスクが発生します。 次に、導入作業のさまざまな時点で発生する可能性があるリスクの例をいくつか示します。

  • 初期の実験の間に、ほとんどまたはまったく関連のないデータが含まれる少数の資産がデプロイされます。 リスクは小規模です。
  • 最初のワークロードがデプロイされると、リスクは少し上がります。 このリスクは、ユーザー ベースの小さい、本質的にリスクの低いアプリケーションを選択することで簡単に修復できます。
  • より多くのワークロードがオンラインになるにつれて、リスクはリリースごとに変わります。 新しいアプリケーションがリリースされると、リスクは変わります。
  • 企業が最初の 10 個または 20 個のアプリケーションをオンラインにするときのリスク プロファイルは、1000 個目のアプリケーションをクラウドで運用環境に移行するときとは大きく異なります。

リスクは相対的です。 オフラインの建物内にある、IT 資産を少量しか持たない小規模な企業の場合、リスクはほとんどありません。 ユーザーを増やし、これらの資産にアクセスできるインターネット接続を追加すると、リスクは増大します。 その小規模な企業が Fortune 500 を獲得するまでに成長すると、リスクは急激に大きくなります。 収益、ビジネス プロセス、従業員数、IT 資産が蓄積するにつれて、リスクは増加し、合体していきます。 収益の創出に役立つ IT 資産には、障害の発生時に収入源が停止するという明確なリスクがあります。 ダウンタイムのあらゆる瞬間が損失に相当します。 同様に、データが蓄積されると、顧客に害を与えるリスクが増大します。

Tailwind Traders の顧客ストーリーに関するユニットからの概要によれば、Tailwind の CIO が最も関心を持っているリスクは次のとおりです。

  • クラウドでの支出超過
  • 組織がセキュリティまたはコンプライアンスの要件を満たさない
  • 運用管理に関する問題または見落としの原因となる資産構成
  • 未承認のアクセスによってシステムやデータが侵害される
  • 未熟なプロセスやチームのスキル不足に起因するガバナンスの不整合

懸念事項は、Tailwind の現在のポリシーで言及されている "既存のデータセンターの特定のネットワーク セグメント" とはどれも無関係であるという点に注意することが重要です。 クラウドへとスケーリングできる健全なガバナンス ポリシーを作成するには、さらに掘り下げる必要があります。 現行のポリシーで把握できる具体的なリスクと、現在の状態でのソリューションとを対比してみましょう。

利害関係者の懸念事項とクラウド導入計画を詳細に調査することによって、組織にとって許容できないリスクがさらに明らかになる可能性があります。 ただし今のところ、これらの明確なリスクに対処するガバナンス ポリシーの作成を開始するには、これで十分です。

ポリシーとコンプライアンス

企業ポリシーによって、IT スタッフと自動化システムがサポートする必要がある要件、標準、および目標を確立します。 個々のポリシー ステートメントは、リスク評価プロセス中に確認された特定のリスクに対処するためのガイドラインです。 パブリックおよびプライベート クラウドのデプロイにおける導入をガイドし、特定のベンダーのロックインを回避する、適切な企業ポリシーの例を次にいくつか示します。

  • 過度の支出を避ける: クラウドのデプロイでは、過度の支出が発生するリスクがあります (セルフサービスのデプロイでは特に)。 すべてのデプロイは、承認された予算と予算制限を適用するメカニズムを持つ請求単位に割り当てる必要があります。

    "設計上の考慮事項": Azure では、Microsoft Cost Management で予算を管理できます。 一方、Azure Advisor では、資産別の支出削減のための最適化の推奨事項が提供されます。

  • 機密データをセキュリティで保護する: 機密データを操作する資産に十分な保護が与えられず、データ漏洩やビジネスの中断につながる可能性があります。 セキュリティ チームは、機密データを操作するすべての資産を特定して確認し、適切なレベルの保護が確実に実施されるようにする必要があります。

    "設計上の考慮事項": Azure では、デプロイされたすべての資産に適切なデータ分類レベルのタグを付ける必要があります。 クラウド ガバナンス チームとアプリケーション所有者は、クラウドへのデプロイの前に、この分類を確認する必要があります。

プロセス

クラウドを使用する場合、実装の構成に基づく検証のトリガーを指定することで、同じプロセスを繰り返す人的オーバーヘッドを軽減できるガードレールが提供されます。 次の表では、Tailwind Traders の CIO が関心を持っているリスクに対処できるいくつかのトリガーとアクションの概要を示します。

リスク サンプル トリガー サンプル アクション
クラウドでの支出超過 月間のクラウド支出が予想よりも 20% 高くなる。 請求単位のリーダーに、リソース使用状況の確認を開始するよう通知する。
クラウドでの支出超過 デプロイされた資産によって割り当てられた CPU またはメモリが使用されていない。 請求単位のリーダーに通知し、可能な場合は実際の使用量に合わせて自動的にサイズを変更する。
組織がセキュリティまたはコンプライアンスの要件を満たさない 定義されたセキュリティまたはコンプライアンスからの逸脱を検出する。 IT セキュリティ チームに通知し、可能な場合は自動的に修復する。
運用管理に関する問題または見落としの原因となる資産構成 ワークロードの CPU 使用率が 90% を超える。 IT 運用チームに通知し、負荷に対応できるよう追加のリソースをスケールアウトする。
運用管理に関する問題または見落としの原因となる資産構成 修正プログラムの適用またはビジネス継続性とディザスターの要件を満たしていない資産によって、運用コンプライアンスに関する警告がトリガーされる。 IT セキュリティ チームに通知し、可能な場合は自動的に逸脱を解決する。
未承認のアクセスによってシステムやデータが侵害される トラフィック パターンが承認されたネットワーク トポロジから逸脱している。 IT セキュリティ チームに通知し、可能な場合は自動的に攻撃ベクトルを閉じる。
未承認のアクセスによってシステムやデータが侵害される 適切なロールの割り当てまたは昇格された特権なしで資産が構成されている。 IT セキュリティ チームに通知し、可能な場合は自動的に逸脱を解決する。
未熟なプロセスやチームのスキル不足に起因するガバナンスの不整合 必須のガバナンス プロセスに含まれていないことが確認された資産。 IT ガバナンス チームに通知し、可能な場合は自動的に逸脱を解決する。

これらの各トリガーとアクションは、Azure のガバナンス ツールを使用して自動化できます。 他のクラウド プロバイダーではより手動的なアプローチが必要になる可能性がありますが、定義されたポリシーは引き続き適用できます。 今後このプロセスを繰り返す必要がないように、特定のベンダーの使用にロックするポリシーを定義しないように注意してください。

クラウド ポリシー ステートメントを確立し、設計ガイドの草案を作成したら、ポリシー要件に従ってクラウドをデプロイするための戦略を作成する必要があります。 この戦略には、クラウド ガバナンス チームの継続的な確認プロセスとコミュニケーション プロセスが含まれている必要があります。 この戦略は、クラウド ガバナンス チームの継続的な確認プロセスとコミュニケーション プロセスを含み、また、どのような場合にポリシー違反に対してアクションが必要かの基準を確立する必要があります。 また、違反を検出して修復アクションをトリガーする、監視とコンプライアンスの自動システムに対する要件も定義する必要があります。

次のユニットでは、これらの種類のリスクをアクションにつながるクラウド規範にグループ化します。