セグメンテーション戦略を構築するためのレコメンデーション

Power Platform Well-Architected Security チェックリストのレコメンデーションに適用されます:

SE:04 アーキテクチャ設計とプラットフォーム上のワークロードのフットプリントに意図的なセグメンテーションと境界を作成します。 セグメンテーション戦略には、ネットワーク、役割と責任、ワークロードID、およびリソース構成を含める必要があります。

セグメンテーション戦略は、独自のセキュリティ要件と対策のセットを持つ他のワークロードからワークロードを分離する方法を定義します。

このガイドでは、統合セグメンテーション戦略を構築するためのレコメンデーションについて説明します。 ワークロードで境界と分離境界を使用すると、適切なセキュリティ アプローチを設計できます。

定義

任期 定義
封じ込め 攻撃者がセグメントにアクセスした場合に被害範囲を封じ込める手法。
最小特権アクセス 職務権限を遂行するために必要なアクセス許可セットを最小限に抑えることを目的としたゼロ トラストの原則。
境界 セグメント周囲の信頼境界。
リソース組織 セグメント内のフローごとに関連リソースをグループ化する戦略。
役割 職務権限を完了するために必要な権限のセット。
セグメント 他のエンティティから分離され、一連のセキュリティ対策によって保護された論理ユニット。

主要な設計戦略

セグメンテーションの概念は、ネットワークでよく使用されます。 ただし、管理目的やアクセスの制御のためのリソースのセグメント化など、同じ基本原則をソリューション全体で使用できます。

セグメンテーションは、ゼロ トラスト モデルの原則に基づいて 多層防御を適用するセキュリティ アプローチ を設計するのに役立ちます。 異なる ID 制御を使用してワークロードをセグメント化することで、あるセグメントに侵入した攻撃者が別のセグメントにアクセスできないようにします。 安全なシステムでは、ネットワークや ID などのさまざまな属性を使用して、不正アクセスをブロックし、資産が公開されないように隠します。

セグメントの例は次のとおりです。

  • ネットワーク境界を定義するプラットフォーム制御
  • 組織のワークロードを分離する環境
  • ワークロード資産を分離するソリューション
  • 段階ごとに展開を分離する展開環境
  • ワークロードの開発と管理に関連する職務権限を分離するチームと役割
  • ワークロード ユーティリティによって分離されるアプリケーション層
  • あるサービスを別のサービスから分離するマイクロサービス

包括的な多層防御戦略を確実に構築するには、セグメンテーションの次の重要な要素を考慮してください。

  • 境界 は、セキュリティ制御を適用するセグメントの入口端です。 境界制御では、明示的に許可されない限り、セグメントへのアクセスをブロックする必要があります。 目標は、攻撃者が境界を突破してシステムを制御するのを防ぐことです。 たとえば、ユーザーは環境にアクセスできますが、権限に基づいてその環境内で特定のアプリケーションのみを起動できます。

  • 封じ込め は、システム内の側方の動きを防ぐセグメントの出口端です。 封じ込めの目標は、侵害の影響を最小限に抑えることです。 たとえば、仮想ネットワークを使用して、任意のネットワーク セグメントへのトラフィックを回避し、予期されるトラフィック パターンのみを許可するようにルーティングおよびネットワーク セキュリティ グループを構成することができます。

  • 分離 は、同様の保証を持つエンティティをグループ化して境界で保護するプラクティスです。 目標は、管理を容易にし、環境内での攻撃を封じ込めることです。 たとえば、特定のワークロードに関連するリソースを 1 つの Power Platform 環境または 1 つのソリューションにグループ化し、特定のワークロード チームのみがその環境にアクセスできるようにアクセス制御を適用できます。

境界と分離の違いに注意することが重要です。 境界とは、チェックする必要がある位置の点を指します。 分離とはグループ化することです。 これらの概念を組み合わせて使用することで、攻撃を積極的に封じ込めます。

分離とは、組織内にサイロを作ることではありません。 統一されたセグメント化戦略により、技術チーム間の連携が確保され、責任の境界線が明確になります。 明確にすることで、セキュリティの脆弱性、運用停止、またはその両方につながる可能性のある人為的エラーや自動化の失敗のリスクが軽減されます。 複雑な企業システムのコンポーネントでセキュリティ侵害が検出されたとします。 適切な人物がトリアージ チームに含まれるように、そのリソースの責任者を全員が把握することが重要です。 組織と関係者は、適切なセグメンテーション戦略を作成して文書化することで、さまざまな種類のインシデントに対応する方法を迅速に特定できます。

トレードオフ: 管理のオーバーヘッドが理由で、セグメント化は複雑さをもたらします。

リスク: 妥当な制限を超えるマイクロセグメント化は、分離のメリットを失います。 セグメントを作成しすぎると、通信ポイントを特定したり、セグメント内で有効な通信パスを許可したりすることが困難になります。

境界としての ID

人、ソフトウェア コンポーネント、デバイスなどのさまざまな ID がワークロード セグメントにアクセスします。 ID は、アクセス要求の発信元に関係なく、分離境界を越えたアクセスを認証および承認するための主要な防御線となる境界です。 ID を境界として使用して、次のことを行います。

  • 役割ごとにアクセスを割り当てる。 ID は、その仕事を行うために必要なセグメントにのみアクセスする必要があります。 要求元の ID の役割と責任を理解して、セグメントへのアクセスを要求しているエンティティとその目的を把握することで、匿名アクセスを最小限に抑えます。

    ID は、セグメントごとに異なるアクセス スコープを持つ場合があります。 各ステージに個別のセグメントを使用した、一般的な環境設定を考えてみましょう。 開発者の役割に関連付けられた ID には、開発環境への読み取り/書き込みアクセス権があります。 展開がステージングに移行すると、これらのアクセス許可は制限されます。 ワークロードが運用にプロモートされるまでに、開発者の範囲は読み取り専用アクセスに限定されます。

  • アプリケーション ID と管理 ID を別々に考慮してください。 ユーザーには、ほとんどのソリューションで開発者やオペレーターとは異なるレベルのアクセス権があります。 一部のアプリケーションでは、ID の種類ごとに異なる ID システムやディレクトリを使用する場合があります。 ID ごとに個別のロールを作成することを検討してください。

  • 最小特権アクセスを割り当てます。 ID にアクセスが許可されている場合は、アクセス レベルを決定します。 各セグメントに対して最小限の特権から始めて、必要な場合にのみ範囲を広げます。

    最小限の特権を適用することで、ID が侵害された場合の悪影響を制限できます。 アクセスが時間によって制限されると、攻撃面はさらに縮小されます。 時間制限付きアクセスは、管理者や ID が侵害されたソフトウェア コンポーネントなどの重要なアカウントに特に適用されます。

トレードオフ: ロールベースのアクセス制御 (RBAC) は、管理のオーバーヘッドが原因です。 ロールの割り当てでは、ID とそのアクセス スコープを追跡することが複雑になる場合があります。 個々の ID ではなくセキュリティ グループにロールを割り当てることを検討してください。

リスク: ID 設定は複雑になる場合があります。 誤った構成は、ワークロードの信頼性に影響を与える可能性があります。 たとえば、ロールの割り当てが誤って構成され、データベースへのアクセスが拒否されているとします。 要求は失敗し始め、最終的には実行時まで検出できない信頼性の問題が発生します。

ID 制御については、ID とアクセス管理のレコメンデーションを参照してください。

ネットワーク アクセスの制御とは対照的に、ID はアクセス時にアクセスの制御を検証します。 重大な影響を与えるアカウントの権限を取得するには、定期的なアクセス レビューを実施し、承認ワークフローを要求することを強くお勧めします。

境界としてのネットワーク

ネットワーク境界は ID を補強するのに対して、ID 境界はネットワークに依存しませんが、決して置き換えることはできません。 ネットワーク境界は、被害範囲を制御し、予期しないアクセス、禁止されたアクセス、安全でないアクセスをブロックし、ワークロード リソースを難読化するために確立されます。

ID 境界の主な焦点は最小限の特権ですが、ネットワーク境界を設計するときは侵害が発生することを想定する必要があります。

Power Platform と Azure のサービスと機能を使用して、ネットワーク フットプリント内にソフトウェアによる境界を作成します。 ワークロード (または特定のワークロードの一部) が別個のセグメントに配置される場合、それらのセグメントとの間のトラフィックを制御して、通信パスを保護します。 セグメントが侵害された場合、そのセグメントは封じ込められ、ネットワークの残りの部分への横方向の拡散が防止されます。

攻撃者の立場になって考えて、ワークロード内に足場を築き、さらなる拡大を最小限に抑えるための制御を確立します。 制御は、攻撃者がワークロード全体にアクセスすることを検出、封じ込め、阻止する必要があります。 境界としてのネットワーク制御の例は次のとおりです。

  • 公衆ネットワークとワークロードが配置されるネットワーク間のエッジ境界を定義します。 公衆ネットワークから自分のネットワークへの視野を可能な限り制限します。
  • 意図に基づいて境界を作成します。 たとえば、ワークロードの機能ネットワークを運用ネットワークからセグメント化します。

リスク: ネットワーク制御はルールベースで、構成を誤る可能性が高いので、信頼性が心配されます。

役割と責任

混乱やセキュリティ リスクを防ぐセグメント化は、ワークロード チーム内の責任範囲を明確に定義することによって実現されます。

一貫性を保ち、コミュニケーションを促進するために、役割と機能を文書化して共有します。 主要な機能を担当するグループまたは個々の役割を指定します。 オブジェクトのカスタム役割を作成する前に、Power Platform の組み込みロールを検討してください。

セグメントに権限を割り当てるときは、複数の組織モデルに対応しながら一貫性を考慮してください。 これらのモデルは、単一の集中型 IT グループから、ほぼ独立した IT および DevOps チームまで多岐にわたります。

リスク: グループのメンバーシップは、社員が入退社したり役割が変わるにつれて変わります。 セグメント全体で役割を管理すると、管理オーバーヘッドが発生する可能性があります。

リソース組織

セグメント化により、ワークロード リソースを組織内の他の部分やチーム内から分離できます。 環境やソリューションなどの Power Platform コンストラクトは、セグメント化を促進するリソースを整理する方法です。

Power Platform の促進

次のセクションでは、セグメント化戦略の実装に使用できる Power Platform 機能について説明します。

ID

すべて Power Platform 製品の使用 Microsoft Entra ID (旧 Azure Active Directory または Azure AD) を使用します。 Entra ID の組み込みセキュリティ ロール、条件付きアクセス、Privileged Identity Management、グループ アクセス管理を使用して、ID 境界を定義できます。

Microsoft Dataverse では、ロール ベースのセキュリティを使用して、権限のコレクションをグループ化します。 これらのセキュリティ ロールは、個々のユーザーに直接関連付けることも、Dataverse チームと事業単位に関連付けることもできます。 詳細については、「Microsoft Dataverse のセキュリティ概念」を参照してください。

ネットワーク

Power Platform 向け Azure Virtual Network サポートを活用すると、リソースを公共のインターネットに曝さずに、Power Platform を仮想ネットワーク内のリソースに統合できます。 Virtual Network サポートは、Azure サブネット委任を使用して、実行時に Power Platform からの送信トラフィックを管理します。 代理人を使用すると、Power Platform と統合するために保護されたリソースがインターネット経由で移動する必要がなくなります。 仮想ネットワーク、Dataverse、Power Platform コンポーネントは、Azure やオンプレミスでホストされているかどうかに関係なく、ネットワーク内で企業が所有するリソースを呼び出し、プラグインとコネクタを使用して通話を発信できます。 詳細については、Power Platform の Virtual Network サポートの概要を参照してください。

Power Platform 環境の IP ファイアウォール は、許可された IP ロケーションのみからの Dataverse へのユーザー アクセスを制限することでデータを保護します。

Microsoft Azure ExpressRoute では、プライベート接続を使用してオンプレミスのネットワークを Microsoft Cloud Services に高度な方法で接続できます。 たとえば、単一の ExpressRoute 接続を使用して、Microsoft Power Platform、Dynamics 365、Microsoft 365、Azure などの複数のオンライン サービスにアクセスできます。

セキュリティ チェックリスト

完全な推奨事項セットを参照してください。