セグメント化戦略を構築するための推奨事項
以下の Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に対応します。
| SE:04 | アーキテクチャ設計とプラットフォーム上のワークロードの占有領域に意図的なセグメント化と境界を作成します。 セグメント化戦略には、ネットワーク、ロールと責任、ワークロード ID、リソース組織が含まれている必要があります。 |
|---|
セグメントは、ソリューションの論理的なセクションであり、1 つのユニットとしてセキュリティ保護する必要があります。 セグメント化戦略では、独自のセキュリティ要件と対策のセットを使用して、1 つのユニットを他のユニットから分離する方法を定義します。
このガイドでは、統合セグメント化戦略を構築するための推奨事項について説明します。 ワークロードで境界と分離境界を使用して、ユーザーに適したセキュリティ アプローチを設計できます。
定義
| 相談 | 定義 |
|---|---|
| 封じ込め | 攻撃者がセグメントにアクセスした場合に、爆発半径を含める手法。 |
| 最小限の特権アクセス | 職務権限を完了するための一連のアクセス許可を最小限にすることを目的としたゼロ トラスト原則。 |
| 境界 | セグメントの周囲の信頼境界。 |
| リソースの編成 | セグメント内のフローごとに関連リソースをグループ化する戦略。 |
| ロール | 職務権限を完了するために必要なアクセス許可のセット。 |
| Segment | 他のエンティティから分離され、一連のセキュリティ対策によって保護される論理ユニット。 |
主要な設計戦略
セグメント化の概念は、ネットワークでよく使用されます。 ただし、管理目的のリソースのセグメント化やアクセスの制御など、ソリューション全体で同じ基本原則を使用できます。
セグメント化は、ゼロ トラスト モデルの原則に基づいて多層防御を適用するセキュリティ アプローチを設計するのに役立ちます。 異なる ID 制御でワークロードをセグメント化することで、あるネットワーク セグメントに違反した攻撃者が別のネットワーク セグメントにアクセスできないようにします。 セキュリティで保護されたシステムでは、ID 属性とネットワーク属性によって未承認のアクセスがブロックされ、資産が公開されないようにします。 セグメントの例をいくつか次に示します。
- 組織のワークロードを分離するサブスクリプション
- ワークロード資産を分離するリソース グループ
- ステージごとにデプロイを分離するデプロイ環境
- ワークロードの開発と管理に関連する職務権限を分離するチームと役割
- ワークロード ユーティリティによって分離されるアプリケーション層
- あるサービスを別のサービスから分離するマイクロサービス
セグメント化の次の重要な要素を考慮して、包括的な多層防御戦略を構築していることを確認します。
境界線または境界とは、セキュリティ制御を適用するセグメントの入口エッジです。 境界コントロールは、明示的に許可されていない限り、セグメントへのアクセスをブロックする必要があります。 目的は、攻撃者が境界を突破してシステムの制御権を持つことを防ぐことです。 たとえば、アプリケーション層は、要求を処理するときにエンド ユーザーのアクセス トークンを受け入れる場合があります。 ただし、データ層では、特定のアクセス許可を持つ別のアクセス トークンが必要になる場合があります。これは、アプリケーション層のみが要求できます。
封じ込めとは、システム内の横移動を防止するセグメントの終了エッジです。 封じ込めの目的は、侵害の影響を最小限に抑えることです。 たとえば、Azure 仮想ネットワークを使用して、ルーティングとネットワーク セキュリティ グループを構成し、想定されるトラフィック パターンのみを許可し、任意のネットワーク セグメントへのトラフィックを回避できます。
分離とは、類似の保証を持つエンティティをグループ化して境界線で保護する方法です。 目的は、管理の容易さと環境内での攻撃の封じ込めです。 たとえば、特定のワークロードに関連するリソースを 1 つの Azure サブスクリプションにグループ化し、特定のワークロード チームのみがサブスクリプションにアクセスできるようにアクセスの制御を適用できます。
境界と分離の区別に注意することが重要です。 境界は、チェックする必要がある場所のポイントを指します。 分離とは、グループ化に関することです。 これらの概念を一緒に使用して攻撃を積極的に封じ込めます。
分離とは、組織内にサイロを作成することを意味するものではありません。 統合されたセグメント化戦略は、技術チーム間の連携を提供し、明確な責任の体系を設定します。 明確にすることで、セキュリティの脆弱性、運用上のダウンタイム、またはその両方につながる可能性のある人的エラーや自動化エラーのリスクが軽減されます。 複雑なエンタープライズ システムのコンポーネントでセキュリティ違反が検出されたとします。 適切な人物がトリアージ チームに含まれるように、そのリソースの責任者を誰もが理解していることが重要です。 組織と利害関係者は、適切なセグメント化戦略を作成して文書化することで、さまざまな種類のインシデントに対応する方法をすばやく特定できます。
トレードオフ: セグメント化では、管理にオーバーヘッドがあるため、複雑さが生じます。 コストのトレードオフもあります。 たとえば、並列で実行されるデプロイ環境がセグメント化されると、さらに多くのリソースがプロビジョニングされます。
リスク: 合理的な制限を超えたマイクロセグメント化では、分離の利点が失われます。 セグメントを作成しすぎると、通信ポイントを特定したり、セグメント内の有効な通信パスを許可したりすることが困難になります。
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 境界の主な焦点は最小限の特権ですが、ネットワーク境界を設計するときに侵害があると想定する必要があります。
Azure のサービスと機能を使用して、ネットワーク占有領域にソフトウェア定義の境界を作成します。 ワークロード (または特定のワークロードの一部) が個別のセグメントに配置されている場合、それらのセグメント間のトラフィックを制御して、通信パスをセキュリティで保護します。 セグメントが侵害された場合、それを封じ込め、ネットワークの残りの部分に横方向に拡散するのを防ぎます。
ワークロード内に足掛かりを得ようとする攻撃者になったつもりで考え、さらなる拡大を最小限に抑えるためのコントロールを確立します。 コントロールは、攻撃者によるワークロード全体へのアクセスを検出、封じ込め、阻止する必要があります。 境界としてのネットワーク制御の例を次に示します。
- パブリック ネットワークとワークロードが配置されているネットワークの間のエッジ境界を定義します。 パブリック ネットワークから自身のネットワークへの見通し線を可能な限り制限します。
- ファイアウォールを介して適切な制御を行って、アプリケーションの前に非武装地帯 (DMZ) を実装します。
- ワークロードの一部を個別のセグメントにグループ化して、プライベート ネットワーク内にマイクロセグメント化を作成します。 それらの間にセキュリティで保護された通信パスを確立します。
- 意図に基づいて境界線を作成します。 たとえば、運用ネットワークからワークロード機能ネットワークをセグメント化します。
ネットワークのセグメント化に関連する一般的なパターンについては、「ネットワークのセグメント化パターン」を参照してください。
プライベート接続によってアーキテクチャ設計が変更され、多くの場合、コンピューティング ノードへのプライベート アクセス用のジャンプ ボックスなどのコンポーネントが追加されます。
ネットワーク境界はネットワーク上の制御ポイント (ホップ) に基づいているため、各ホップが障害点になる可能性があります。 これらのポイントは、システムの信頼性に影響を与える可能性があります。
ネットワーク制御の詳細については、「ネットワークと接続性」を参照してください。
ロールを定義し、明確な責任の体系を定義する
混乱とセキュリティ リスクを防ぐセグメント化は、ワークロード チーム内で責任の体系を明確に定義することによって実現されます。
一貫性を生み出し、コミュニケーションを容易にするために、役割と機能を文書化して共有します。 主要な機能を担当するグループまたは個々のロールを指定します。 オブジェクトのカスタム ロールを作成する前に、Azure の組み込みロールを検討してください。
セグメントにアクセス許可を割り当てる際は、複数の組織モデルに対応しながらも一貫性を考慮します。 これらのモデルは、単一の一元化された IT グループから、大部分は独立した IT チームや DevOps チームまで多岐にわたります。
リソースを整理してセグメント化を促進する
セグメント化を行うと、ワークロードのリソースを組織の他の部分から、あるいはチーム内から分離することができます。 管理グループ、サブスクリプション、環境、リソース グループなどの Azure コンストラクトは、リソースを整理してセグメント化を促進する方法です。 リソース レベルの分離の例を次に示します。
- ポリグロットな永続化には、セグメント化をサポートする単一データベース システムではなく、データ格納テクノロジの組み合わせが含まれます。 さまざまなデータ モデルによる分離、データ ストレージや分析などの機能の分離、またはアクセス パターンによる分離には、ポリグロットな永続化を使用します。
- コンピューティングを整理するときに、サーバーごとに 1 つのサービスを割り当てます。 このレベルの分離により、複雑さが最小限に抑えられ、攻撃を封じ込めるのに役立ちます。
- Azure では、ストレージからのコンピューティングの分離など、一部のサービスに対して組み込みの分離が提供されます。 その他の例については、「Azure パブリック クラウドでの分離」を参照してください。
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) 環境を基にしています。 次の図は、組織によって実行される管理グループ レベルでのセグメント化を示しています。
ID セグメント化パターン
パターン 1: 役職ベースのグループ化
セキュリティ グループを整理する方法の 1 つは、ソフトウェア エンジニア、データベース管理者、サイト信頼性エンジニア、品質保証エンジニア、セキュリティ アナリストなどの役職別にすることです。 このアプローチでは、その役割に基づいてワークロード チームのセキュリティ グループを作成します。達成する必要がある作業は考慮されません。 ワークロードでの責任に応じて、セキュリティ グループに永続的またはジャスト イン タイム (JIT) の RBAC アクセス許可を付与します。 必要に応じたアクセスに基づいて、セキュリティ グループに人間とサービスの原則を割り当てます。
メンバーシップはロールの割り当てレベルで明確に表示されるため、ロールがアクセスできる対象を簡単に確認できます。 通常、各ユーザーは 1 つのセキュリティ グループのみのメンバーであるため、オンボーディングとオフボードが簡単になります。 ただし、役職が責任と完全に重複しない限り、役職ベースのグループ化は最小限の特権の実装には適していません。 職務ベースのグループ化と組み合わせた実装となる場合があります。
パターン 2: 職務ベースのグループ化
職務ベースのグループ化は、チーム構造を考慮せず、達成する必要がある個別の作業を反映するセキュリティ グループ組織の方法です。 このパターンでは、ワークロードでの必要な職務に応じて、セキュリティ グループに永続的または JIT の RBAC アクセス許可を随時付与します。
必要に応じたアクセスに基づいて、セキュリティ グループに人間とサービスの原則を割り当てます。 可能であれば、既存の同種グループを職務ベースのグループのメンバーとして使用します (パターン 1 のグループなど)。 職務ベースのグループの例を次に示します。
- 実稼働データベース オペレーター
- 稼働前データベース オペレーター
- 実稼働証明書ローテーション オペレーター
- 稼働前証明書ローテーション オペレーター
- 実稼働サイト/トリアージ
- 稼働前のすべてのアクセス
このアプローチでは、最も厳密な最小限の特権アクセスが維持され、スコープが明らかであるセキュリティ グループが提供されるため、実行された職務に対するメンバーシップを簡単に監査できます。 多くの場合、この職務権限に一致する組み込みの Azure ロールが存在します。
ただし、メンバーシップは少なくとも 1 つのレイヤーに抽象化されるため、リソースの観点から見ると、グループ内のユーザーを把握するには ID プロバイダーに移動する必要があります。 さらに、完全なカバレッジを確保するには、1 人のユーザーが複数のメンバーシップを維持する必要があります。 重複するセキュリティ グループのマトリックスは複雑になる場合があります。
組織図ではなくアクセス パターンに焦点を当てる場合には、パターン 2 をお勧めします。 組織図とメンバー ロールは変更される場合があります。 職務の観点からワークロードの ID およびアクセス管理をキャプチャすることで、ワークロードのセキュリティで保護された管理からチーム組織を抽象化できます。
ネットワーク セグメント化パターン
パターン 1: ワークロード内のセグメント化 (ソフト境界)
このパターンでは、ワークロードはサブネットを使用して境界線をマークする単一の仮想ネットワークに配置されます。 セグメント化は 2 つのサブネットを使用して実現されます (データベース用と Web ワークロード用)。 サブネット 1 がサブネット 2 のみと通信し、サブネット 2 がインターネットのみと通信することを許可する NSG を構成する必要があります。 このパターンは、レイヤー 3 レベルの制御を提供します。
パターン 2: ワークロード内でのセグメント化
このパターンは、プラットフォーム レベルのセグメント化の例です。 ワークロード コンポーネントは、それらの間でピアリングすることなく、複数のネットワークに分散されます。 すべての通信は、パブリック アクセス ポイントとして機能する中継局を介してルーティングされます。 ワークロード チームは、すべてのネットワークを所有しています。
パターン 2 は封じ込めを提供しますが、仮想ネットワークの管理とサイズ設定の複雑さが増しています。 2 つのネットワーク間の通信はパブリック インターネット経由で行われます。これはリスクになる可能性があります。 パブリック接続の待機時間もあります。 ただし、2 つのネットワークをピアリングでき、それらを接続してセグメント化を中断して、より大きなセグメントを作成できます。 他のパブリック エンドポイントが必要ない場合は、ピアリングを実行する必要があります。
| 考慮事項 | パターン 1 | パターン 2 |
|---|---|---|
| 接続とルーティング: 各セグメントの通信方法 | システム ルーティングは、ワークロード コンポーネントへの既定の接続を提供します。 外部コンポーネントはワークロードと通信できません。 | 仮想ネットワーク内では、パターン 1 と同じです。 ネットワーク間では、トラフィックはパブリック インターネットを経由します。 ネットワーク間に直接接続はありません。 |
| ネットワークレベルのトラフィック フィルター処理 | セグメント間のトラフィックは、既定で許可されます。 NSG または ASG を使用してトラフィックをフィルター処理します。 | 仮想ネットワーク内では、パターン 1 と同じです。 ネットワーク間では、ファイアウォールを介してイングレス トラフィックとエグレス トラフィックの両方をフィルター処理できます。 |
| 意図せず開かれたパブリック エンドポイント | ネットワーク インターフェイス カード (NIC) はパブリック IP を取得しません。 仮想ネットワークは、インターネット API 管理に公開されません。 | パターン 1 と同じです。 1 つの仮想ネットワーク上のオープン パブリック エンドポイントを意図しており、多くのトラフィックを受け入れるように誤って構成される可能性があります。 |
リソースの編成
所有権の責任に基づいて Azure リソースを整理する
複数のワークロードと、ハブ仮想ネットワーク、ファイアウォール、ID サービス、Microsoft Sentinel などのセキュリティ サービスなどの共有サービス コンポーネントを含む Azure 資産について考えてみましょう。 資産全体のコンポーネントは、機能領域、ワークロード、所有権に基づいてグループ化する必要があります。 たとえば、共有ネットワーク リソースを単一サブスクリプションにグループ化し、ネットワーク チームによって管理する必要があります。 個々のワークロード専用のコンポーネントは、独自のセグメント内に存在する必要があり、アプリケーション層やその他の組織の原則に基づいてさらに分割される場合があります。
RBAC ロールの割り当てを作成して、個々のセグメント内のリソースを管理するためのアクセス権を付与します。 たとえば、クラウド ネットワーク チームには、個々のワークロード サブスクリプションへの管理アクセス権ではなく、リソースを含むサブスクリプションへの管理アクセス権が付与される場合があります。
適切なセグメント化戦略により、各セグメントの所有者を簡単に識別できます。 Azure リソース タグを使用して、リソース グループまたはサブスクリプションに所有者チームで注釈を付けることを検討してください。
アクセスの制御を構成して確認する
リソースのセグメントを明確に定義することで、ニーズに基づいて適切なアクセス権を付与します。
アクセスの制御ポリシーを定義する場合は、最小限の特権の原則を検討してください。 コントロール プレーン操作 (リソース自体の管理) とデータ プレーン操作 (リソースによって格納されたデータへのアクセス) を区別することが重要です。 たとえば、従業員に関する機密情報を含むデータベースを含むワークロードがあるとします。 データベース バックアップなどの設定を構成する必要がある一部のユーザーや、データベース サーバーのパフォーマンスを監視するユーザーに管理アクセス権を付与する場合があります。 ただし、これらのユーザーは、データベースに格納されている機密データに対してクエリを実行することはできないようにする必要があります。 ユーザーが職務を遂行するために必要な最小限のスコープを付与するアクセス許可を選択します。 各セグメントのロールの割り当てを定期的に確認し、不要になったアクセス権を削除します。
Note
RBAC の所有者ロールなど、一部の高い特権ロールを使用すると、ユーザーは他のユーザーにリソースへのアクセス権を付与できます。 所有者ロールが割り当てられているユーザーまたはグループの数を制限し、監査ログを定期的に確認して、正当な操作しか実行できないようにします。
関連リンク
セキュリティ チェックリスト
レコメンデーションの完全なセットを参照してください。