セグメント化戦略を構築するための推奨事項

Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。

SE:04 アーキテクチャ設計で意図的なセグメント化と境界を作成し、プラットフォーム上のワークロードのフットプリントを作成します。 セグメント化戦略には、ネットワーク、ロールと責任、ワークロード ID、リソース organizationが含まれている必要があります。

セグメントは、1 つのユニットとしてセキュリティで保護する必要があるソリューションの論理セクションです。 セグメント化戦略では、セキュリティ要件とメジャーの独自のセットを使用して、1 つのユニットを他のユニットから分離する方法を定義します。

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

定義 

期間 定義
Containment 攻撃者がセグメントにアクセスした場合に爆発半径を格納する手法。
最小特権アクセス ジョブ機能を完了するための一連のアクセス許可を最小限にすることを目的とするゼロ トラスト原則。
境界 セグメントの周囲の信頼境界。
リソースの編成 セグメント内のフロー別に関連リソースをグループ化する戦略。
ロール ジョブ機能を完了するために必要な一連のアクセス許可。
Segment 他のエンティティから分離され、一連のセキュリティ対策によって保護される論理単位。

主要な設計戦略

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

セグメント化は、ゼロ トラスト モデルの原則に基づいて多層防御を適用するセキュリティ アプローチを設計するのに役立ちます。 あるネットワーク セグメントに違反した攻撃者が、異なる ID 制御を使用してワークロードをセグメント化することで、別のネットワーク セグメントにアクセスできないようにします。 セキュリティで保護されたシステムでは、ID 属性とネットワーク属性によって未承認のアクセスがブロックされ、資産が公開されないようにします。 セグメントの例をいくつか次に示します。

  • organizationのワークロードを分離するサブスクリプション
  • ワークロード資産を分離するリソース グループ
  • ステージ別にデプロイを分離するデプロイ環境
  • ワークロードの開発と管理に関連するジョブ機能を分離するチームとロール
  • ワークロード ユーティリティによって分離されるアプリケーション層
  • あるサービスを別のサービスから分離するマイクロサービス

セグメント化のこれらの重要な要素を考慮して、包括的な多層防御戦略を構築していることを確認します。

  • 境界または境界は、セキュリティ制御を適用するセグメントのエントリ エッジです。 境界コントロールは、明示的に許可されていない限り、セグメントへのアクセスをブロックする必要があります。 目標は、攻撃者が境界を突破してシステムを制御するのを防ぐことです。 たとえば、アプリケーション層は、要求を処理するときにエンド ユーザーのアクセス トークンを受け入れる場合があります。 ただし、 データ 層には、アプリケーション層のみが要求できる特定のアクセス許可を持つ別のアクセス トークンが必要になる場合があります。

  • 包含 は、システム内の横方向の移動を防止するセグメントの終了エッジです。 封じ込めの目的は、侵害の影響を最小限に抑することです。 たとえば、Azure 仮想ネットワークを使用してルーティングとネットワーク セキュリティ グループを構成し、予期したトラフィック パターンのみを許可し、任意のネットワーク セグメントへのトラフィックを回避できます。

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

境界と分離の区別に注意することが重要です。 境界は、チェックする必要がある場所のポイントを指します。 分離とは、グループ化に関することです。 これらの概念を組み合わせて使用して、攻撃を積極的に封じ込めます。

分離とは、organizationでサイロを作成することを意味するものではありません。 統合セグメント化戦略は、技術チーム間の連携を提供し、明確な責任線を設定します。 Clarityは、セキュリティの脆弱性、運用上のダウンタイム、またはその両方につながる可能性がある人的エラーと自動化エラーのリスクを軽減します。 複雑なエンタープライズ システムのコンポーネントでセキュリティ違反が検出されたとします。 適切な人物がトリアージ チームに含まれるように、すべてのユーザーがそのリソースの責任者を理解することが重要です。 organizationと利害関係者は、適切なセグメント化戦略を作成して文書化することで、さまざまな種類のインシデントに対応する方法をすばやく特定できます。

トレードオフ: セグメント化では、管理にオーバーヘッドがあるため、複雑さが生じます。 コストのトレードオフもあります。 たとえば、並列で実行されるデプロイ環境がセグメント化されると、さらに多くのリソースがプロビジョニングされます。

リスク: 合理的な制限を超えたマイクロセグメンテーションは、分離の利点を失います。 セグメントを作成しすぎると、通信ポイントを特定したり、セグメント内の有効な通信パスを許可することが困難になります。

境界としての ID

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

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

    ID は、セグメントごとに異なるアクセス スコープを持つ場合があります。 ステージごとに個別のセグメントを使用して、一般的な環境のセットアップを検討してください。 開発者ロールに関連付けられている ID には、開発環境への読み取り/書き込みアクセス権があります。 デプロイがステージングに移行すると、これらのアクセス許可は抑制されます。 ワークロードが運用環境に昇格される頃には、開発者のスコープは読み取り専用アクセスに縮小されます。

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

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

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

トレードオフ: ワークロードのパフォーマンスは、ID 境界によって影響を受ける可能性があります。 各要求を明示的に検証するには、追加のコンピューティング サイクルと追加のネットワーク IO が必要です。

ロールベースのアクセス制御 (RBAC) でも、管理オーバーヘッドが発生します。 ID とそのアクセス スコープを追跡することは、ロールの割り当てで複雑になる可能性があります。 回避策は、個々の ID ではなくセキュリティ グループにロールを割り当てることです。

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

ID 制御の詳細については、「 ID とアクセス管理」を参照してください。

ネットワーク アクセス制御とは対照的に、ID はアクセス時にアクセス制御を検証します。 定期的なアクセス レビューを実施し、重大な影響を与えるアカウントの特権を取得するために承認ワークフローを要求することを強くお勧めします。 たとえば、「 ID セグメント化パターン」を参照してください。

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

ID 境界はネットワークに依存しませんが、ネットワーク境界は ID を拡張しますが、それを置き換えることはありません。 ネットワーク境界は、爆発半径を制御し、予期しない、禁止された、安全でないアクセスをブロックし、ワークロード リソースを難読化するために確立されます。

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

Azure サービスと機能を使用して、ネットワークフットプリントにソフトウェア定義の境界を作成します。 ワークロード (または特定のワークロードの一部) が別々のセグメントに配置されると、 それらのセグメントとの間のトラフィックを制御して、通信パスをセキュリティで保護します。 セグメントが侵害された場合、セグメントは含まれており、ネットワークの残りの部分を介して横方向に広がらないようにします。

ワークロード内の足掛かりを達成し、さらなる拡張を最小限に抑えるためのコントロールを確立することは、攻撃者と考えてください。 コントロールは、攻撃者がワークロード全体にアクセスするのを検出し、封じ込め、阻止する必要があります。 境界としてのネットワーク制御の例を次に示します。

  • パブリック ネットワークとワークロードが配置されるネットワーク間のエッジ境界を定義します。 パブリック ネットワークからネットワークへの視線を可能な限り制限します。
  • ファイアウォールを介して適切な制御を使用して、アプリケーションの前に非武装地帯 (DMZ) を実装します。
  • ワークロードの一部を個別のセグメントにグループ化して、プライベート ネットワーク内にマイクロ セグメント化を作成します。 それらの間にセキュリティで保護された通信パスを確立します。
  • 意図に基づいて境界を作成します。 たとえば、運用ネットワークからワークロード機能ネットワークをセグメント化します。

ネットワークセグメント化に関連する一般的なパターンについては、「 ネットワークセグメント化パターン」を参照してください。

トレードオフ: ネットワーク セキュリティ制御は、Premium SKU に含まれているため、コストが高くなることがよくあります。 ファイアウォールで規則を構成すると、多くの場合、広範な例外を必要とする複雑さが増します。

プライベート接続によってアーキテクチャの設計が変更され、多くの場合、コンピューティング ノードへのプライベート アクセス用のジャンプ ボックスなどのコンポーネントが追加されます。

ネットワーク境界はネットワーク上の制御ポイント (ホップ) に基づいているため、各ホップが障害点になる可能性があります。 これらの点は、システムの信頼性に影響を及ぼす可能性があります。

リスク: ネットワーク制御はルールベースであり、構成ミスが発生する可能性が非常に高く、これは信頼性の問題です。

ネットワーク制御の詳細については、「 ネットワークと接続」を参照してください。

ロールと責任

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

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

セグメントにアクセス許可を割り当てるときに、複数の組織モデルに対応しながら一貫性を考慮してください。 これらのモデルは、単一の一元化された IT グループから、大部分は独立した IT チームや DevOps チームまで多岐にわたります。

リスク: グループのメンバーシップは、従業員がチームに参加したり、チームから離れたり、ロールを変更したりすると、時間の経過と同時に変化する可能性があります。 セグメント間でロールを管理すると、管理オーバーヘッドが発生する可能性があります。

リソースの編成

セグメント化を使用すると、ワークロード リソースをorganizationの他の部分から、またはチーム内から分離できます。 管理グループ、サブスクリプション、環境、リソース グループなどの Azure コンストラクトは、セグメント化を促進するリソースを整理する方法です。 リソース レベルの分離の例をいくつか次に示します。

  • ポリグロット永続化には、セグメント化をサポートする 1 つのデータベース システムではなく、データ格納テクノロジの組み合わせが含まれます。 さまざまなデータ モデルによる分離、データ ストレージや分析などの機能の分離、またはアクセス パターンで分離するには、ポリグロット永続化を使用します。
  • コンピューティングを整理するときに、サーバーごとに 1 つのサービスを割り当てます。 このレベルの分離により、複雑さが最小限に抑えられます。攻撃を封じ込めるのに役立ちます。
  • Azure では、ストレージからのコンピューティングの分離など、一部のサービスに対して組み込みの分離が提供されます。 その他の例については、「 Azure パブリック クラウドでの分離」を参照してください。

トレードオフ: リソースの分離により、総保有コスト (TCO) が増加する可能性があります。 データ ストアの場合、ディザスター リカバリー中に複雑さと調整が追加される可能性があります。

Azure ファシリテーション

特定の Azure サービスは、次のセクションで概説するように、セグメント化戦略の実装に使用できます。

ID

Azure RBAC では、ジョブ関数別にアクセスを分離することでセグメント化がサポートされています。 特定のロールとスコープに対してのみ、特定のアクションが許可されます。 たとえば、システムを監視するだけで済むジョブ関数には、閲覧者のアクセス許可と、ID がリソースを管理できるようにする共同作成者のアクセス許可を割り当てることができます。

詳細については、「 RBAC のベスト プラクティス」を参照してください。

ネットワーク

セグメント化のネットワーク オプションを示す図。

仮想ネットワーク: 仮想ネットワークは、2 つの仮想ネットワーク間にトラフィックを追加することなく、リソースのネットワーク レベルの包含を提供します。 仮想ネットワークは、サブスクリプション内のプライベート アドレス空間に作成されます

ネットワーク セキュリティ グループ (NSG): 仮想ネットワーク内のリソースとインターネットなどの外部ネットワーク間のトラフィックを制御するためのアクセス制御メカニズム。 ユーザー定義ルート (UDR) を実装して、トラフィックの次ホップを制御します。 NSG は、サブネット、仮想マシン (VM)、または VM のグループの境界を作成することで、セグメント化戦略を詳細なレベルに引き上げることができます。 Azure のサブネットで可能な操作の詳細については、「 サブネット」を参照してください。

アプリケーション セキュリティ グループ (ASG): ASG を使用すると、アプリケーション タグの下に VM のセットをグループ化し、基になる各 VM に適用されるトラフィック ルールを定義できます。

Azure Firewall: 仮想ネットワークまたは Azure Virtual WAN ハブデプロイにデプロイできるクラウドネイティブ サービス。 Azure Firewallを使用して、クラウド リソース、インターネット、オンプレミス リソース間のトラフィック フローをフィルター処理します。 Azure Firewall または Azure Firewall Manager を使用して、レイヤー 3 からレイヤー 7 のコントロールを使用してトラフィックを許可または拒否するルールまたはポリシーを作成します。 高度なフィルター処理とユーザー保護のためにサード パーティのセキュリティ プロバイダーを介してトラフィックを転送することで、Azure Firewallとサード パーティを使用してインターネット トラフィックをフィルター処理します。 Azure では、サードパーティのファイアウォールからのセグメント化に役立つネットワーク仮想アプライアンスデプロイがサポートされています。

Azure でワークロードをセグメント化するための一般的なパターンをいくつか次に示します。 ニーズに基づいてパターンを選択します。

この例は、 セキュリティ ベースライン (SE:01) で確立された情報技術 (IT) 環境に基づいています。 次の図は、organizationによって実行される管理グループ レベルでのセグメント化を示しています。

さまざまなワークロードに対するorganizationのセグメント化戦略の例を示す図。

ID セグメント化パターン

パターン 1: 役職ベースのグループ化

セキュリティ グループを整理する方法の 1 つは、ソフトウェア エンジニア、データベース管理者、サイト信頼性エンジニア、品質保証エンジニア、セキュリティ アナリストなどの役職です。 このアプローチでは、ワークロード チームの役割に基づいて セキュリティ グループを作成 する必要があります。実行する必要がある作業は考慮されません。 ワークロードの責任に従って、セキュリティ グループに RBAC アクセス許可を付与します(永続的または Just-In-Time (JIT)。 必要に応じてアクセスに基づいて、セキュリティ グループに人間とサービスの原則を割り当てます。

メンバーシップはロールの割り当てレベルで高く表示されるため、 ロール がアクセスできる内容を簡単に確認できます。 通常、各ユーザーは 1 つのセキュリティ グループのメンバーであるため、オンボーディングとオフボードが簡単になります。 ただし、役職が責任と完全に重複しない限り、タイトルベースのグループ化は最小特権の実装には最適ではありません。 実装と関数ベースのグループ化を組み合わせることになる場合があります。

パターン 2: 関数ベースのグループ化

関数ベースのグループ化は、チーム構造を考慮せず、達成する必要がある個別の作業を反映するセキュリティ グループ organizationメソッドです。 このパターンでは、ワークロードで必要な機能に従って 、必要に応じて、セキュリティ グループに RBAC アクセス許可を付与します

必要に応じてアクセスに基づいて、セキュリティ グループに人間とサービスの原則を割り当てます。 可能であれば、パターン 1 のグループなど、関数ベースのグループのメンバーとして既存の同種グループを使用します。 関数ベースのグループの例を次に示します。

  • 運用データベース演算子
  • 運用前データベース演算子
  • 運用証明書ローテーション演算子
  • 実稼働前証明書ローテーション演算子
  • 運用ライブ サイト/トリアージ
  • すべてのアクセスの運用前

このアプローチでは、最も厳密な最小特権アクセスが維持され、スコープが明らかなセキュリティ グループが提供されるため、実行されたジョブの職務に対するメンバーシップを簡単に監査できます。 多くの場合、このジョブ機能に合わせて組み込みの Azure ロールが存在します。

ただし、メンバーシップは少なくとも 1 つのレイヤーに抽象化されるため、リソースの観点から見ると、グループ内のユーザーを理解するために ID プロバイダーに移動する必要があります。 さらに、1 人のユーザーが完全なカバレッジのために複数のメンバーシップを維持する必要があります。 重複するセキュリティ グループのマトリックスは複雑になる可能性があります。

パターン 2 は、organizationグラフではなく、アクセス パターンをフォーカスにすることをお勧めします。 組織図とメンバー ロールが変更されることがあります。 ワークロードの ID とアクセス管理を機能的な観点からキャプチャすると、ワークロードのセキュリティで保護された管理からチームのorganizationを抽象化できます。

ネットワークセグメント化パターン

パターン 1: ワークロード内のセグメント化 (ソフト境界)

単一の仮想ネットワークを示す図。

このパターンでは、ワークロードは、サブネットを使用して境界をマークする単一の仮想ネットワークに配置されます。 セグメント化は、データベース用と Web ワークロード用の 2 つのサブネットを使用して実現されます。 サブネット 1 がサブネット 2 とのみ通信し、サブネット 2 がインターネットとのみ通信できるように NSG を構成する必要があります。 このパターンは、レイヤー 3 レベルの制御を提供します。

パターン 2: ワークロード内でのセグメント化

複数の仮想ネットワークを示す図。

このパターンは、プラットフォーム レベルのセグメント化の例です。 ワークロード components は、それらの間をピアリングすることなく、複数のネットワークに分散されます。 すべての通信は、パブリック アクセス ポイントとして機能する中継局を介してルーティングされます。 ワークロード チームは、すべてのネットワークを所有しています。

パターン 2 は封じ込め機能を提供しますが、仮想ネットワークの管理とサイズ設定の複雑さが増しています。 2 つのネットワーク間の通信は、パブリック インターネット経由で行われます。これはリスクになる可能性があります。 パブリック接続の待機時間もあります。 ただし、2 つのネットワークをピアリングし、セグメント化を中断して接続することで、より大きなセグメントを作成できます。 他のパブリック エンドポイントが必要ない場合は、ピアリングを実行する必要があります。

考慮事項 パターン 1 パターン 2
接続とルーティング: 各セグメントの通信方法 システム ルーティングでは、ワークロード コンポーネントへの既定の接続が提供されます。 外部コンポーネントはワークロードと通信できません。 仮想ネットワーク内では、パターン 1 と同じです。
ネットワーク間では、トラフィックはパブリック インターネットを経由します。 ネットワーク間に直接接続はありません。
ネットワークレベルのトラフィック フィルター処理 セグメント間のトラフィックは、既定で許可されます。 NSG または ASG を使用してトラフィックをフィルター処理します。 仮想ネットワーク内では、パターン 1 と同じです。
ネットワーク間では、ファイアウォールを介してイングレス トラフィックとエグレス トラフィックの両方をフィルター処理できます。
意図せず開かれたパブリック エンドポイント ネットワーク インターフェイス カード (NIC) はパブリック IP を取得しません。 仮想ネットワークは、インターネット API 管理に公開されません。 パターン 1 と同じです。 1 つの仮想ネットワーク上のオープン パブリック エンドポイントを意図しています。これは、より多くのトラフィックを受け入れるように正しく構成されていない可能性があります。

リソースの編成

所有権の責任に基づいて Azure リソースを整理する

複数のワークロードを含む Azure 資産の図。

複数のワークロードと、ハブ仮想ネットワーク、ファイアウォール、ID サービス、Microsoft Sentinel などのセキュリティ サービスなどの共有サービス コンポーネントを含む Azure 資産について考えてみましょう。 資産全体のコンポーネントは、機能領域、ワークロード、所有権に基づいてグループ化する必要があります。 たとえば、共有ネットワーク リソースを 1 つのサブスクリプションにグループ化し、ネットワーク チームによって管理する必要があります。 個々のワークロード専用のコンポーネントは、独自のセグメントに含める必要があり、アプリケーション層やその他の組織の原則に基づいてさらに分割される場合があります。

RBAC ロールの割り当てを作成して、個々のセグメント内のリソースを管理するためのアクセス権を付与します。 たとえば、クラウド ネットワーク チームには、個々のワークロード サブスクリプションではなく、リソースを含むサブスクリプションへの管理アクセス権が付与される場合があります。

適切なセグメント化戦略により、各セグメントの所有者を簡単に識別できます。 Azure リソース タグを使用して、リソース グループまたはサブスクリプションに所有者チームに注釈を付ける方法を検討してください。

アクセス制御の構成と確認

リソースのセグメントを明確に定義することで、ニーズに基づいて適切なアクセス権を付与します。

アクセス制御ポリシーを定義する場合は、最小特権の原則を考慮してください。 コントロール プレーン操作 (リソース自体の管理) とデータ プレーン操作 (リソースによって格納されているデータへのアクセス) を区別することが重要です。 たとえば、従業員に関する機密情報を含むデータベースを含むワークロードがあるとします。 データベース バックアップなどの設定を構成する必要がある一部のユーザーや、データベース サーバーのパフォーマンスを監視するユーザーに管理アクセス権を付与できます。 ただし、これらのユーザーは、データベースに格納されている機密データに対してクエリを実行することはできません。 ユーザーが職務を遂行するために必要な最小スコープを付与するアクセス許可を選択します。 各セグメントのロールの割り当てを定期的に確認し、不要になったアクセス権を削除します。

注意

RBAC の所有者ロールなど、一部の高い特権を持つロールにより、ユーザーは他のユーザーにリソースへのアクセスを許可できます。 所有者ロールが割り当てられているユーザーまたはグループの数を制限し、監査ログを定期的に確認して、有効な操作のみを実行するようにします。

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

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