機械翻訳について

第6章 仮想ネットワークの概要

目次

プライベート・クラウドを構築する際、最初のステップの1つは、クラウド・リソースの仮想クラウド・ネットワークを設計および構成することです。 この章では、ネットワーキング・サービスで使用可能なコンポーネントの概要について説明します。 そのうちのいくつかは、すでに慣れている従来のネットワーク・コンポーネントの仮想バージョンです。

この章の項では、ネットワーキング・サービスの仕組みと、それを使用して仮想クラウド・ネットワークの設計、オンプレミス・ネットワークとの接続、ネットワークを通過するトラフィックの制御などについて説明します。 一般的なネットワーク・シナリオの詳細な説明は、独自の構成のよい開始点となる場合があります。

6.1 仮想クラウド・ネットワーク

仮想クラウド・ネットワーク(VCN)は、ファイアウォール・ルールと様々なタイプの通信ゲートウェイを備えた、従来のネットワークと同等のソフトウェア定義です。 VCNはOracle Private Cloud Applianceインストールの単一のリージョンに存在し、選択した1つの連続的なCIDRブロックについて説明しています。

VCNのサイズは、 /16から /30です。 CIDRブロックは、VCNの作成後に変更できません。 VCN内のプライベートIPの最大数は64,000です。 Oracleでは、RFC 1918 (10.0.0.0/8,172.16.0.0 /12および192.168.0.0 /16)で指定されているプライベートIPアドレス範囲を使用することをお薦めします。 このドキュメントでは、VCN CIDRのIPアドレスを参照するときにプライベートIPアドレスという用語を使用します。

トラフィックがアプライアンスの安全なネットワーク環境を離れないように、VCNを別のVCNにプライベート接続できます。 ただし、2つのVCNのCIDRは重複できません。 VCNをプライベート接続するという概念は「ピアリング」と呼ばれます。 これには、ローカル・ピアリング・ゲートウェイと呼ばれる仮想ルーターのタイプの設定が含まれます。 VCNでのゲートウェイの使用の詳細は、第6.4項、「ネットワーク・ゲートウェイ」を参照してください。

6.1.1 サブネット

VCNはサブネットに分割されます。 VCN内の各サブネットは、VCN内の他のサブネットと重複しない連続したIPv4アドレスの範囲で構成されます。 例: 172.16.1.0/24。 最初の2つのIPv4アドレスとサブネットCIDRの最後のアドレスは、ネットワーキング・サービスによって予約されています。 作成後にサブネットのサイズを変更することはできません。

サブネットは構成の単位として機能: 特定のサブネット内のすべてのインスタンスは、同じルート表、セキュリティ・リストおよびDHCPオプションを使用します。 サブネットはパブリックまたはプライベートのいずれかにできます。 これはサブネットの作成時に定義され、後で変更できません。 プライベート・サブネットでは、インスタンスにパブリックIPアドレスを割り当てることはできません。

コンピュート・インスタンスはサブネットに存在するものと考えることができます。 ただし、正確にはするために、各インスタンスは仮想ネットワーク・インタフェース・カード(VNIC)にアタッチされます。VNICは、次にサブネットに存在し、そのインスタンスのネットワーク・アタッチを有効にします。

IPv6アドレス指定は、現在Oracle Private Cloud Applianceではサポートされていません。

6.1.2 ルート表

各VCNには、自動的に空のデフォルト・ルート表が付属しています。 サブネットでは、別のルート表を明示的に割り当てる場合を除き、親VCNのデフォルト・ルート表が使用されます。 VCNにルート・ルールを追加すると、必要に応じてデフォルト表にルート・ルールを追加できます。 ただし、パブリック・サブネットとプライベート・サブネットの両方が必要な場合、かわりにサブネットごとに個別のカスタム・ルート表を作成します。

プライマリ・ルーティング・シナリオは、サブネット・トラフィックをVCN外部の宛先に送信することです。 サブネットには、作成時に選択した1つのルート表が関連付けられます。 そのサブネット内のすべてのVNICは、ルート表内のルールに従います。 VCN内のトラフィックはVCN内部ルーティングによって自動的に処理されます。 そのトラフィックを有効化するために必要なルート・ルールはありません。 サブネットが使用するルート表は、いつでも変更できます。 ルート表ルールを編集したり、表からすべてのルールを削除することもできます。

ルート・ルールでは、そのCIDRに一致するトラフィックの宛先CIDRブロックおよびターゲット(ネクスト・ホップ)を指定します。 ターゲットを選択する場合は、そのコンパートメントも指定します。 ルート・ルールでサポートされているターゲット・タイプは、異なるVCNゲートウェイです。

ネットワーク・トラフィックが目的の宛先に到達し、削除されないように、ルート・ルールを慎重に構成する必要があります。 コンパートメント間でのルート・ルールの移動はサポートされていません。

6.2 プライベート・クラウドのパブリック・ネットワーク

Oracle Private Cloud Applianceは、「プライベート」クラウド・ソリューションです。 クラウド・ワークロードをデプロイするために必要なサービスを提供するインフラストラクチャは、データ・センターのネットワーク環境内で動作するように構成されます。 初期化中、アプライアンスのコア・ネットワーク・コンポーネントは、既存のデータセンター・ネットワーク設計と統合されます。 アプライアンス・スイッチのアップリンク・ポートは、次レベルのデータ・センター・スイッチに接続して、すべてのトラフィックをアプライアンスとの間で送受信する冗長な高速および高帯域幅の物理接続を提供します。

これは、データ・センター内のシステムへのアクセスを制限するサービス・プロバイダによってインフラストラクチャが管理される「パブリック」クラウド環境との重要な違いです。 クラウド・リソースは自分のネットワーク内にないため、セキュアなトンネル接続を使用して、インターネット経由でアクセスします。 このコンテキストでは、パブリック・クラウドと外部のロケーションの間のネットワーク・トラフィックは、定義によってインターネットを介して送信されます。 つまり、クラウド環境のパースペクティブから見ると、パブリック・ネットワークは実質的にインターネットです。 これとプライベート・クラウド環境を比較します。パブリック・ネットワークはオンプレミス・ネットワークであり、インターネット・アクセスは常にデータ・センターのエッジ・ルーターを介して間接的です。

Oracle Private Cloud Applianceは、Oracleパブリック・クラウド・オファリング後にモデル化されます: Oracle Cloud Infrastructure。 これは、ネットワーキング・サービスだけでなく、すべての主要なインフラストラクチャ・サービスにも適用されます: これらは単一ラックの小規模なスケール用に最適化されていますが、同じコア機能を提供します。 主な目的の1つは、両方のクラウド・プラットフォーム間の最大互換性を維持することです: これにより、非常に類似したユーザー・エクスペリエンスが提供され、プライベート・クラウド環境とOracle Cloud Infrastructureアカウント間でワークロードを効率的に移行できます。

パブリック・クラウド・ネットワーク・モデルは、パブリック・ネットワークが実際にデータ・センター・ネットワークであるプライベート・クラウド環境に適用されるため、特定のネットワーク・リソースまたはコンポーネントは異なる動作を示します。 Oracle Private Cloud Applianceで仮想クラウド・ネットワークを設計および構成する場合は、これらの違いに注意する必要があります。

  • オンプレミス・ネットワークへのアクセス

    アプライアンス・ラックはお客様の施設にあります: データ・センター内で設定され、オンプレミス・ネットワークに直接接続されます。 クラウド・リソースとオンプレミス・ネットワークが相互に通信できるように、インターネットを介したセキュアなトンネルは必要ありません。 アクセスは、仮想クラウド・ネットワーク(VCN)とオンプレミス・ネットワークの間のゲートウェイを介して有効になります。

  • インターネットへのアクセス

    クラウド環境のリソースには、インターネットに直接アクセスすることはできません。 パブリック・クラウド環境とは異なり、VCNに対して直接インターネット接続を有効にできるゲートウェイはありません。 パブリック接続とは、リソースがデータ・センター・ネットワークにアクセスできることを意味します。 データ・センター内のネットワーキング・コンポーネントの構成によって、クラウド・リソースがインターネットに接続する方法と、インターネットからアクセスできるかどうかが決まります。

  • VCNゲートウェイ

    VCNへのネットワーク・トラフィックの管理には、いくつかのタイプのゲートウェイが使用されます。 VCN内のリソースは、動的ルーティング・ゲートウェイ(DRG)、NATゲートウェイまたはインターネット・ゲートウェイを介して外部ホストに接続できます。 技術的には、これらのゲートウェイはそれぞれ、オンプレミス・ネットワークへのパスを提供します。 ただし、DRGは、アドレス変換を実行しないため、VCNとオンプレミス・ネットワーク間の重複を処理できないという点で重要な制限があります。

    これらのゲートウェイはある程度交換できるように見えますが、意図した目的のために厳密に構成して使用することが重要です。 プライベート・クラウド・ネットワーク構成がパブリック・クラウド・ネットワーク・モデルと互換性を持つように維持するのに役立ちます。 ワークロードをOracle Cloud Infrastructureに移動すると、データ・センター・ネットワークが式から削除されます。つまり、NATおよびインターネット・ゲートウェイは直接インターネット・アクセスを提供し、DRGはオンプレミス・ネットワークへのアクセスのみを提供します。

  • パブリックIPアドレス

    仮想クラウド・ネットワークのパースペクティブから、パブリック・ネットワークは事実上データ・センター・ネットワークであるため、パブリックIPアドレスはCIDR内に存在する必要があります。 これに対応するには、データ・センターCIDR内のアドレス範囲を予約して、Oracle Private Cloud Applianceでのみ使用する必要があります。 通常は、初期システム設定時にパブリックIP範囲を構成します。 範囲は後で延長できますが、IPの削除は許可されません。 ネットワーキング・サービスでは、この範囲をプールとして使用します。プールから、パブリックIPアドレスを、必要とするクラウド・リソースに割り当てます。 パブリックIPによって、リソースが存在するVCNの外部からリソースにアクセスできます。 プライベート・クラウド・コンテキストでは、データ・センターまたはオンプレミス・ネットワーク内の他のリソースと相互作用できます。 パブリックとみなされるIPは、実際にはデータ・センターのプライベート範囲の一部です。

    パブリックIPの使用は、特定のワークロードをOracle Cloud Infrastructureに移動する場合に異なる意味を持ち、パブリックIPは本当に一意でパブリックにルーティング可能です。 真のパブリックIPは希少で高価なリソースです。 プライベート・クラウド環境でアプリケーションとサービスを設計する際に考慮に入れます: プライベートIPを使用してコンポーネント間の接続を有効にし、パブリックIPを割り当てるのは、真のパブリック接続が必要な場合のみです。

6.3 インスタンス接続

この項では、インスタンス接続の様々な側面について説明します。

6.3.1 仮想ネットワーク・インタフェース・カード(VNIC)

Oracle Private Cloud Applianceのコンピュート・ノードには物理ネットワーク・インタフェース・カード(NIC)があります。 いずれかのサーバーでコンピュート・インスタンスを作成して起動すると、ネットワーキング・サービスは、インスタンスがネットワーク経由で通信できるように、物理インタフェースの上にVNICが作成されるようにします。 各インスタンスには、起動時に自動的に作成およびアタッチされるプライマリVNICがあります。 プライマリVNICは、インスタンスの作成時に指定したサブネットに存在します。 インスタンスから削除できません。

VNICを使用すると、インスタンスはVCNに接続でき、インスタンスがVCNの内外のエンドポイントとどのように通信するかを決定します。 各VNICはVCN内のサブネット内にあり、次のアイテムが含まれます:

  • VNICが属するサブネットの1つのプライマリ・プライベートIPv4アドレス。

  • 任意で割り当てられる、各プライベートIPのオプションのパブリックIPv4アドレス。

  • 各プライベートIPアドレスのDNSのオプションのホスト名。

  • MACアドレス。

  • VNICネットワーク・トラフィックでソース/宛先チェックを有効または無効にするフラグ。

  • 1つ以上のネットワーク・セキュリティ・グループ(NSG)のオプション・メンバーシップ。

  • Oracle割当て識別子(OCID)。

  • 選択および割り当てることができるオプションのわかりやすい名前。

セカンダリVNICは、起動後にインスタンスに追加できます。 セカンダリVNICを使用できるようにするには、そのインスタンスOSも構成する必要があります。 インスタンスのVNICの最大数はシェイプによって異なります。 各セカンダリVNICは、プライマリVNICとは異なるサブネット(同じVCN内または別のセカンダリVNIC内)に存在できます。 セカンダリVNICは、プライマリVNICと同じサブネットにあってもかまいません。 ただし、同じサブネットCIDRブロックからインスタンスに複数のVNICをアタッチすると、特にLinuxインスタンスで非対称ルーティングが発生する可能性があります。

セカンダリVNICは常にインスタンスにアタッチする必要があり、移動できません。 セカンダリVNICを作成するプロセスによって、インスタンスに自動的にアタッチされます。 セカンダリVNICをデタッチするプロセスによって、自動的に削除されます。 インスタンスを終了すると、自動的にデタッチされて削除されます。 アタッチされたVNICの数に関係なく、インスタンス帯域幅は固定されます。 インスタンスの特定のVNICに対して帯域幅制限を指定することはできません。

すべてのVNICは、デフォルトでネットワーク・トラフィックのソース/宛先チェックを実行します。 VNICは、各ネットワーク・パケットのヘッダーにリストされている送信元と送信先を確認します。 VNICが送信元または送信先でない場合、パケットは削除されます。 VNICがトラフィックを転送する必要がある場合 - たとえば、ネットワーク・アドレス変換(NAT)を実行する必要がある場合 - VNICでソース/宛先チェックを無効にする必要があります。

VNICはサブネット内に存在しますが、インスタンスにアタッチします。 インスタンスへのVNICアタッチメントは、VNICまたはインスタンス自体とは別のオブジェクトです。 VNICとサブネットは常に同じコンパートメントに存在しますが、インスタンスへのVNICアタッチメントは常にインスタンス・コンパートメントに存在します。 ネットワーク管理者がネットワークを管理し、他のユーザーがインスタンスを管理するアクセス制御シナリオを設定した場合、この区別はIAMポリシーに影響します。

6.3.2 IPアドレス指定

インスタンスは通信にIPアドレスを使用します。 各インスタンスには、少なくとも1つのプライベートIPアドレスがあり、オプションで1つ以上のパブリックIPアドレスがあります。 プライベートIPアドレスを使用すると、インスタンスはVCN内の他のインスタンス、またはオンプレミス・ネットワーク内のホストと通信できます。 パブリックIPアドレスを使用すると、インスタンスはOracle Private Cloud Applianceネットワーク環境の外部ホストと通信できます。

テナンシ内の特定のタイプのリソースは、セキュアなアプライアンス・ネットワーク環境の外部から直接アクセスできるように設計されているため、自動的にパブリックIPアドレスが付きます。 次に例を示します: NATゲートウェイ。 他のタイプのリソースは、そのように構成した場合にのみ直接アクセス可能です。 次に例を示します: VCN内の特定のインスタンス。 直接パブリック接続では、VCNにインターネット・ゲートウェイがあり、パブリック・サブネットでルート表およびセキュリティ・リストが正しく構成されている必要があります。

プライベートIP

ネットワーキング・サービスでは、プライベートIPv4アドレスとDNSのオプションのホスト名で構成されるOracle割当てのOCIDで識別されるプライベートIPオブジェクトを定義します。 各インスタンスは、起動時にプライマリ・プライベートIPオブジェクトを受け取ります。 Networkingサービスは、DHCPを使用してプライベートIPアドレスを割り当てます。 このアドレスはインスタンスの存続期間中に変更されず、インスタンスから削除できません。 プライベートIPオブジェクトは、インスタンスの終了時に終了します。

インスタンスにセカンダリVNICがアタッチされている場合、それらの各VNICにもプライマリ・プライベートIPがあります。 プライベートIPには、任意の時点でパブリックIPを割り当てることができます。 プライベートIPをVCN内のルート・ルールのターゲットとして使用することはサポートされていません。

セカンダリ・プライベートIPアドレスは、Oracle Private Cloud Applianceのコンピュート・インスタンスではサポートされていません。 セカンダリ・プライベートIPは、サブネットのCIDRから既存のVNICに割り当てられている追加のプライベートIPです。 かわりに、追加のIPをコンピュート・インスタンスに割り当てるには、セカンダリVNICを使用できます。

パブリックIP

プライベート・クラウド・モデルでは、パブリックIPアドレスは、事実上一意でパブリックにルーティング可能なインターネットIPではなく、クラウド環境のVCN外部のアドレスです。 アプライアンスの初期設定時に、オンプレミス・ネットワークからのアドレスのプールは、パブリックIPとして使用するために予約されています。 システムを使用するには、これらのパブリックIPの小さいセットが必要です。

パブリックIPアドレスをインスタンスに割り当てて、外部通信を有効にできます。 インスタンスには、アドレス・プールからパブリックIPアドレスが割り当てられます。 技術的には、割当てはインスタンスのプライベートIPオブジェクトであり、プライベートIPが割り当てられているVNICはパブリック・サブネットに存在する必要があります。 特定のインスタンスに複数のセカンダリVNICを含めることができます。各VNICは(プライマリ)プライベートIPを持ちます。 したがって、特定のインスタンスをVNIC全体で複数のパブリックIPに割り当てることができます。

ネットワーキング・サービスは、Oracle割当てのOCIDで識別されるパブリックIPオブジェクトを定義します。これは、プライベートIPv4アドレスと、パブリックIPタイプと動作をさらに定義する追加プロパティで構成されます。 パブリックIPには2つのタイプがあります:

  • 「かない」パブリックIPは一時的であり、インスタンスの存続期間中に存在します。

  • 「予約済」パブリックIPは、割り当てられているインスタンスの存続期間を超えて永続的に存在します。 割当てを解除し、別のインスタンスに再割当てできます。

次の表は、両方のタイプの違いをまとめたものです:

説明

エフェメラル・パブリックIP

予約済パブリックIP

許可された割当

VNICプライマリ・プライベートIP

制限: VNICごとに1つ、インスタンスごとに2つ

VNICプライマリ・プライベートIP

制限: VNICごとに1つ

作成

オプションで、インスタンスの起動時またはセカンダリVNICの作成時に作成および割り当てられます。 VNICがまだ存在しない場合は、後から作成して割り当てることができます。

いつでも作成します。 必要に応じて割り当てることができます。

未割当

いつでも割当て解除でき、それによって削除されます。 これは、インスタンスを起動したユーザーがパブリックIPを含んでいたが、インスタンスにパブリックIPが含まれないようにする場合に実行できます。

インスタンスを停止しても、その一時的パブリックIPはインスタンスに割り当てられたままになります。

いつでも割当て解除できます。これにより、予約済パブリックIPのテナンシ・プールに返されます。

別のリソースへの移動

エフェメラル・パブリックIPを別のプライベートIPに移動することはできません。

割当て解除してから別のプライベートIPに再割当てすることで、いつでも移動できます。 別のVCNまたはアベイラビリティ・ドメイン内に存在できます。

自動削除

その存続期間はプライベートIPの存続期間に関連付けられています。 次の場合に自動的に割当て解除および削除されます:

  • プライベートIPが削除されます

  • そのVNICはデタッチまたは終了

  • インスタンスの終了

Never 削除するまで存在します。

有効範囲

可用性ドメイン

リージョン(リージョン内のどの可用性ドメインでもプライベートIPに割り当てることができます)

コンパートメントおよび可用性ドメイン

プライベートIPと同じ

プライベートIPとは異なる場合があります

パブリック・サブネットでインスタンスを起動すると、特に指定しないかぎり、インスタンスはデフォルトでパブリックIPを取得します。 特定のパブリックIPを作成した後は、そのタイプを変更できません。 たとえば、アドレス203.0.113.2のエフェメラル・パブリックIPが割り当てられているインスタンスを起動した場合、エフェメラル・パブリックIPをアドレス203.0.113.2の予約済パブリックIPに変換できません。

直接公開されるように設計されたリソースは、作成時にプールから割り当てられたパブリックIPアドレスを自動的に取得します。 NATゲートウェイの場合、割り当てられたアドレスはリージョナル・エフェメラル・パブリックIPです。 他のエフェメラル・パブリックIPと同様に、割り当てられたリソースを終了すると、自動的に割当て解除されて削除されます。 ただし、他のエフェメラル・パブリックIPとは異なり、自分で編集したり、割当て解除することはできません。

6.3.3 DHCPオプション

Networkingサービスは、DHCPを使用して、起動時にインスタンスに構成情報を自動的に提供します。 DHCPでは一部の設定を動的に変更できますが、その他の設定は静的であり、変更されることはありません。 たとえば、インスタンスを起動するときに、インスタンスのプライベートIPアドレスを指定するか、システムによって選択されます。 インスタンスが起動するか、インスタンスDHCPクライアントを再起動するたびに、DHCPは同じプライベートIPアドレスをインスタンスに渡します。 インスタンスの存続期間中にアドレスが変更されることはありません。

ネットワーキング・サービスには、VCN内のインスタンス上で特定タイプの構成を制御できるDHCPオプションが用意されています。 これらのオプションの値は自由に変更できます。また、その変更は、次に特定のインスタンスDHCPクライアントを再起動したり、インスタンスを再起動したときに有効になります。

1つのVCN内の各サブネットは、それに関連付けられた単一のDHCPオプションのセットを保有できます。 そのオプションのセットは、サブネット内のすべてのインスタンスに適用されます。 各VCNには、初期値を変更できるDHCPオプションのデフォルト・セットが付属しています。 異なるDHCPオプションのセットを作成して割り当てる場合を除き、すべてのサブネットはVCNデフォルト・セットを使用します。

構成できるDHCPオプションは、次のとおりです:

  • ドメインネームサーバー

    デフォルト設定はDNSタイプ= Internet and VCN Resolverです。

    かわりに、DNSタイプにCustom Resolverを設定した場合は、最大3つのDNSサーバーを選択できます。

  • 検索ドメイン

    DNSラベルを使用してVCNを設定する場合、「ドメインの検索」オプションのデフォルト値はVCNドメイン名です: <VCN_DNS_label>.oraclevcn.com。 それ以外の場合は、DHCPオプションのデフォルト・セットに「ドメインの検索」オプションが存在しません。

    通常、DHCPオプションのセットが最初に作成されるとき - デフォルト・セットまたはカスタム・セット -ネットワーキング・サービスは、「ドメインの検索」オプションを自動的に追加し、これらすべてがtrueの場合、それをVCNドメイン名(<VCN_DNS_label>.oraclevcn.com)に設定します:

    • VCNにはDNSラベルがあります。

    • DNSタイプ= Internet and VCN Resolver。

    • DHCPオプションのセットの作成時に、選択した検索ドメインを指定しませんでした。

    DHCPオプションのセットを作成したら、常に「ドメインの検索」オプションを削除するか、別の値に設定できます。 DHCPオプションのセットには、1つの検索ドメインのみを指定できます。

インスタンスとDHCPオプションに関する重要なノート:

  • DHCPオプションのいずれかの値を変更した場合は常に、インスタンスでDHCPクライアントを再起動するか、インスタンスを再起動して変更を有効にする必要があります。 これは、そのDHCPオプションのセットに関連付けられたサブネット内の既存のすべてのインスタンスに適用されます。

  • 常にインスタンスにアクセスできるように、DHCPクライアントを実行したままにします。 DHCPクライアントを手動で停止するか、NetworkManagerを無効にすると、インスタンスはDHCPリースを更新できず、リースが期限切れになるとアクセスできなくなります(通常は24時間以内)。 別のメソッドを使用してリースの更新を保証しないかぎり、NetworkManagerを無効にしないでください。

  • DHCPクライアントを停止すると、リースの期限が切れたときにホスト・ルート表が削除される可能性があります。 また、iSCSI接続へのネットワーク接続が失われると、ブート・ドライブが失われる可能性があります。

  • /etc/resolv.confファイルに加えた変更は、DHCPリースの更新時またはインスタンスの再起動時に上書きされます。

  • /etc/hostsファイルに加えた変更は、DHCPリースの更新時またはインスタンスの再起動時に上書きされます。 Oracle LinuxまたはCentOSインスタンスの/etc/hostsファイルへの変更を永続化するには、次の行を/etc/oci-hostname.confに追加: PRESERVE_HOSTINFO=2。 /etc/oci-hostname.confファイルが存在しない場合は作成します。

6.3.4 名前解決

ドメイン・ネーム・システム(DNS)は、人間が読めることのできるドメイン名をマシン読取り可能なIPアドレスに変換します。 たとえば、ブラウザにドメイン名を入力すると、そのドメインの認可ネーム・サーバーが見つかるまで、オペレーティング・システムは複数のDNSネーム・サーバーを問い合せます。 認可ネーム・サーバーは、IPアドレスまたはその他のリクエストされたレコード・データで応答します。回答はブラウザにリレーされ、DNSレコードはwebページに解決されます。

VCN内でのDNSの名前解決には、2つのオプションがあります。 DHCPオプションのサブネット・セットを使用して、VCN内の各サブネットのオプションを選択します。

デフォルトの選択肢は、Oracle提供のソリューションである「インターネットおよびVCNリゾルバ」です。 2つの部分で構成されます: インターネット・リゾルバおよびVCNリゾルバ。 インターネット・リゾルバを使用すると、インスタンスはインターネット上でパブリックに公開されているホスト名を解決でき、インターネット・ゲートウェイまたはオンプレミス・ネットワークへの接続を介してインターネットにアクセスする必要はありません。 VCNリゾルバを使用すると、インスタンスは同じVCN内の他のインスタンスのホスト名(割り当てることができる)を解決できます。

または、「カスタム・リゾルバ」を使用することもできます。 名前解決に最大3つのDNSサーバーを使用できます。 これらは、インターネット、VCN内、またはDRGを介してVCNに接続されているオンプレミス・ネットワークで使用可能なDNSサーバーです。

ドメインおよびホスト名

VCNおよびサブネットを作成する際、それぞれにDNSラベルを指定できます。 サブネットDNSラベルを設定できるのは、VCN自体がDNSラベルで作成されている場合のみです。 ラベルは、oraclevcn.comの親ドメインとともにVCNドメイン名とサブネット・ドメイン名を形成します。 次に、インスタンスを起動するときに、ホスト名を割り当てることができます。 インスタンスの起動時に自動的に作成されるプライマリVNICに割り当てられます。 ホスト名は、サブネット・ドメイン名とともに、インスタンスの完全修飾ドメイン名(FQDN)を形成します。

  • VCNドメイン名: <VCN_DNS_label>.oraclevcn.com

  • サブネット・ドメイン名: <subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com

  • インスタンスFQDN: <host_name>。<subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com

FQDNはインスタンスのプライベートIPアドレスに解決されます。 インターネットおよびVCNリゾルバは、プライベートIPアドレスに対応するホスト名を決定できる逆引きDNS参照も有効にします。

セカンダリVNICをインスタンスに追加する場合、ホスト名を指定できます。 その結果、FQDNはVNICのプライマリ・プライベートIPアドレスに解決されます。 その結果、FQDNはそのプライベートIPアドレスに解決されます。

DNSラベルとホスト名は、次の要件を満たしている必要があります:

  • VCNおよびサブネットのラベルは文字で始まり、最大15文字の英数字である必要があります。 ハイフンとアンダースコアは使用できません。 この値は後で変更できません。

  • ホスト名の長さは最大63文字であり、RFCの952および1123に準拠している必要があります。 この値は後で変更できます。

  • VCN DNSラベルは、テナンシ内のVCN全体で一意である必要があります。 サブネットDNSラベルはVCN内で一意である必要があり、ホスト名はサブネット内で一意である必要があります。

ホスト名の検証と生成

VCNおよびサブネットにDNSラベルを設定すると、インスタンス起動時にホスト名がコンプライアンスに対して検証されます。 ホスト名を指定しない場合は、インスタンスの表示名が使用されます。 表示名が検証に合格しない場合、または指定しなかった場合は、DNS準拠のホスト名が生成されます。 生成されたホスト名がコンピュートWeb UIのインスタンスの詳細ページに表示されます。

CLIまたはSDKを使用してインスタンスを起動し、ホスト名または表示名を指定していない場合、システムではそれらが生成されません。 つまり、インターネットおよびVCNリゾルバを使用してインスタンスは解決できません。

セカンダリVNICをインスタンスに追加しても、ホスト名は生成されません。 インターネットおよびVCNリゾルバを使用してプライベートIPアドレスを解決可能にする場合は、有効なホスト名を指定する必要があります。

パブリックDNSゾーン

VCN内にデプロイされたインスタンスのDNS名の解決を有効にするには、アプライアンス・ネットワーク環境の外部から、Oracle Private Cloud ApplianceによってパブリックDNSゾーンの構成サポートが提供されます。 テナンシ内で、DNSゾーンまたはDNSネームスペースのセクションを作成し、Compute Web UIを介して管理します。 アプライアンスのエッジ・ネットワークは、対象となるドメインのすべてのDNS問合せを処理します。

DNSゾーンの作成時に、管理するドメインの名前を指定 - たとえば: example.com。 ゾーンがプライマリかセカンダリかを選択します。 プライマリ・ゾーンには独自のDNSレコードが含まれ、セカンダリ・ゾーンは別のゾーンからレコードを取得します。 外部ゾーン・レコードにアクセスするには、セカンダリ・ゾーンに外部ゾーン用のサーバーIPアドレスが少なくとも1つ必要です。 さらに、TSIG (トランザクション・シグネチャ)キーが必要になる場合があります。 TSIGキーは、セカンダリDNSゾーンの認証に使用される共有シークレットです。 これらのキーは、選択したコンパートメントに格納できます。

作成する各DNSゾーンには、次の2つの重要なレコードが自動的に含まれます:

  • SOA (Start of Authority)レコードは、DNSゾーンに関する認可情報を指定します。 この情報には、プライマリ・ネーム・サーバー、ドメイン管理者の電子メール・アドレス、ドメイン・シリアル番号、およびゾーンのリフレッシュに関連する複数のタイマーが含まれます。 SOAレコードの詳細は、RFC 1035を参照してください。

  • NS (ネーム・サーバー)レコードには、ゾーンの認可ネーム・サーバーがリストされます。 NSレコードの詳細は、RFC 1035を参照してください。

DNSゾーンを構成するには、リソース・レコードの形式で特定のドメイン情報を追加します。 たとえば、アドレス・レコードを使用して、ドメイン名をVCNのパブリック・サブネット内のインスタンスのパブリックIPアドレスに解決します。 Oracle Private Cloud ApplianceのパブリックDNSゾーンは、次の表で説明するリソース・レコード・タイプをサポートしています。

リソース・レコード・タイプ

説明

A

ホスト名をIPv4アドレスに指定するために使用されるアドレス・レコード。 Aレコードの詳細は、RFC 1035を参照してください。

AAAA

使用されるアドレス・レコードは、IPv6アドレスのホスト名をポイントします。 AAAAレコードの詳細は、RFC 3596を参照してください。

ALIAS

ゾーンのapexでCNAME機能を許可するプライベート疑似レコード

CAA

認証局認可レコードを使用すると、ドメイン名保持者は、そのドメインの証明書を発行する権限を持つ1つ以上の認証当局を指定できます。 CAAレコードの詳細は、RFC 6844を参照してください。

CDNSKEY

子DNSKEYは、CDNSSECキーを子ゾーンから親ゾーンに移動します。 このレコードに指定された情報は、他のDNSプロバイダのドメインのCDNSKEY情報と一致する必要があります。 このレコードは、Oracle Private Cloud Appliance DNSのプライマリ・ゾーンでDNSSECを有効にした場合に自動的に作成されます。 CDNSKEYの詳細は、RFC 7344を参照してください。

CDS

子委任署名者レコードは、親ゾーンに転送するためのDSレコードの子コピーです。 CDSレコードの詳細は、RFC 7344を参照してください。

CERT

証明書レコードは、公開鍵証明書および関連する証明書失効リストをDNSに格納します。 CERTレコードの詳細は、RFC 2538およびRFC 4398を参照してください。

CNAME

標準名レコードは、ドメインの正規名を識別します。 CNAMEレコードの詳細は、RFC 1035を参照してください。

CSYNC

子と親の同期レコードは、子ゾーンから親ゾーンにレコードを同期します。 CNAMEレコードの詳細は、RFC 7477を参照してください。

DHCID

DHCP識別子レコードを使用すると、DHCPクライアント識別子をDNSに格納して、ゾーン内のホスト名競合の可能性を排除できます。 DHCIDの詳細は、RFC 4701を参照してください。

DKIM

ドメイン・キー識別メールは、ドメインに対する到着メールの認証に使用される公開キーを提供するために特別に設定された特別なTXTレコードです。 DKIMレコードの詳細は、RFC 6376を参照してください。

DNAME

委任名レコードはCNAMEレコードと類似した動作ですが、ラベルの下のサブツリー全体を別のドメインにマップできます。 DNAMEレコードの詳細は、RFC 6672を参照してください。

DNSKEY

DNSキー・レコードは、DNSSECに使用される公開キーをドキュメント化します。 このレコードの情報は、他のDNSプロバイダのドメインのDNSKEY情報と一致する必要があります。 DNSKEYレコードの詳細は、RFC 4034を参照してください。

DS

委任署名者レコードは最上位ドメインに存在し、子ゾーンDNSKEYレコードを指しています。 DSレコードは、DNSSECセキュリティ認証がゾーンに追加されたときに作成されます。 DSレコードの詳細は、RFC 4034を参照してください。

IPSECKEY

IPSecキー・レコードには、IPセキュリティ(IPSec)システムに接続するためのホスト、ネットワークまたはアプリケーションの公開キーが格納されます。 IPSECKEYレコードの詳細は、RFC 4025を参照してください。

KEY

キー・レコードには、ドメイン名に関連付けられている公開キーが格納されます。 現在、SIGおよびTKEYレコードでのみ使用されます。 IPSECKEYおよびDNSKEYは、それぞれIPSecおよびDNSSECで使用するためのキーに置き換えられました。 KEYレコードの詳細は、RFC 4025を参照してください。

KX

キー・エクスチェンジャ・レコードは、一部の暗号化システム(DNSSECを含まない)に関連付けられたドメイン名に対するキー管理エージェントを識別します。 KXレコードの詳細は、RFC 2230を参照してください。

LOC

ロケーション・レコードには、DNS内のコンピュータ、サブネットおよびネットワークの地理的なロケーション・データが格納されます。 LOCレコードの詳細は、RFC 1876を参照してください。

MX

メール交換レコードは、ドメインのメールを受け入れるメール・サーバーを定義します。 MXレコードはホスト名を指している必要があります。 MXレコードはCNAMEまたはIPアドレスをポイントできません。 MXレコードの詳細は、RFC 1035を参照してください。

NS

ネーム・サーバー・レコードには、ゾーンの認可ネーム・サーバーがリストされます。 NSレコードは、作成する新しいプライマリ・ゾーンごとに自動的に生成されます。 NSレコードの詳細は、RFC 1035を参照してください。

PTR

ポインタ・レコード・リバースは、IPアドレスをホスト名にマップします。 この動作は、ホスト名をIPアドレスにマップするAレコードの反対です。 PTRレコードは、通常、逆引きDNSゾーンにあります。 PTRレコードの詳細は、RFC 1035を参照してください。

PX

X.400マッピング・プロトコルで使用されるリソース・レコード。 PXレコードの詳細は、RFC 822およびRFC 2163を参照してください。

SOA

Start of Authorityレコードでは、DNSゾーンに関する次のような認可情報を指定します:

  • プライマリ・ネーム・サーバー

  • ドメイン管理者の電子メール

  • ドメイン・シリアル番号

  • ゾーンのリフレッシュに関連する複数のタイマー

SOAレコードは、ゾーンの作成時に自動的に生成されます。 SOAレコードの詳細は、RFC 1035を参照してください。

SPF

Sender Policy Frameworkレコードは、電子メールのスプーフィングを検出するように設計されたデータを格納するために使用される特別なTXTレコードです。 SPFレコードの詳細は、RFC 4408を参照してください。

SRV

サービス・ロケータ・レコードを使用すると、管理者は1つのドメインに複数のサーバーを使用できます。 SRVレコードの詳細は、RFC 2782を参照してください。

SSHFP

SSH公開キー・フィンガープリント・レコードは、DNSを使用してSSHパブリック・ホスト・キー・フィンガープリントを公開します。 SSHFPレコードの詳細は、RFC 6594を参照してください。

TLSA

Transport Layer Security Authenticationレコードは、TLSサーバー証明書(公開鍵)を、レコードが見つかったドメイン名に関連付けます。 この関係は、TLSA証明書関連付けと呼ばれます。 TLSAレコードの詳細は、RFC 6698を参照してください。

TXT

テキスト・レコードには、記述的で人間が読めるテキストがあり、特定の用途に人間が読めないコンテンツを含めることもできます。 通常は、人間が読めないテキスト・アイテムを必要とするSPFレコードおよびDKIMレコードに使用されます。 TXTレコードの詳細は、RFC 1035を参照してください。

トラフィック管理ステアリング・ポリシー

リング・ポリシーでは、DNS問合せに対するインテリジェントなレスポンスを提供するようにポリシーを構成できます。つまり、ポリシーで定義されたロジックに応じて、問合せに対して様々な回答(エンドポイント)が提供される場合があります。 Oracle Private Cloud Applianceは、次のタイプのトラフィック管理リング・ポリシーをサポートしています:

ポリシー・タイプ

説明

ロード・バランサ

ロード・バランサ・ポリシーを使用すると、複数のエンドポイント間でトラフィックを分散できます。

エンドポイントに同等の重みを割り当てて、エンドポイント間でトラフィックを均等に分散したり、カスタム重みを比率ロード・バランシングに割り当てることができます。

IP接頭辞ステアリング

IPプレフィクス・ステアリング・ポリシーを使用すると、元の問合せのIPプレフィクスに基づいてDNSトラフィックを制御できます。

リクエストの発生元のサブネットに基づいてユーザーをグループに分割し、行ったサブディビジョンに基づいてユーザーを特定のリソースに移動できます。 たとえば、外部ユーザーとは異なるレスポンスを内部ユーザーに提供できます。

リング・ポリシーには、DNS問合せに応答するルールが含まれています。 これらのルールを使用して、DNSリクエストのプロパティに基づいて回答をフィルタ処理します。 DNS問合せに応じて複数の回答が提供される場合、その回答グループは回答プールと呼ばれます。 プール内の回答は優先度でソートされ、適格または不適格とマークされます。 不適格な回答はレスポンスから除外されます。

DNSゾーンにアタッチされている場合、リング・ポリシーはカバーするゾーンのすべてのリソース・レコードよりも優先され、リング・ポリシー・ルールからDNSレスポンスが構築されます。 たとえば、example.com DNSゾーンにアタッチされているリング・ポリシーに、ドメインapplication.example.comおよびA (アドレス)レコード・タイプの回答を含むルールが含まれている場合、そのゾーンに存在する関連Aレコードに関係なく、リング・ポリシーはその回答で応答します。 リング・ポリシーでリクエストされているレコード・タイプの回答がない場合、DNSリクエストは、次のリング・ポリシーまたはベース・ゾーン・レコードに渡されます。

リング・ポリシーは、タイプA、AAAA、CNAMEのレコードのみをサポートします。 ドメインには、特定のレコード・タイプをカバーする最大1つのリング・ポリシー・アタッチメントを含めることができます。 つまり、DNSゾーン(example.com)には、特定のドメインの様々なレコード・タイプをカバーする複数のアタッチされたリング・ポリシーが存在する可能性があります - たとえば、1つのAレコード・ポリシーと1つのCNAMEレコード・ポリシーはapplication.example.comです。 DNSゾーンには、異なるドメインの特定のレコード・タイプをカバーする複数のアタッチされたリング・ポリシーも含めることができます - たとえば、application.example.comのレコード・ポリシーおよびdatabase.example.comのAレコード・ポリシーです。 ただし、回答は1つのポリシーのみ提供できるため、同じドメインおよびレコード・タイプに対する複数のリング・ポリシーはサポートされていません。

6.4 ネットワーク・ゲートウェイ

VCNとの間のトラフィックを管理するために、追加機能を提供するオプションの仮想ルーターを追加できます。 ルート表にルールを設定して、サブネットからゲートウェイを介してVCN外の宛先にトラフィックをルーティングします。 この項では、各ゲートウェイ・タイプのロールと使用方法について説明します。

6.4.1 動的ルーティング・ゲートウェイ

動的ルーティング・ゲートウェイ(DRG)は、VCNとオンプレミス・ネットワーク間のプライベート・ネットワーク・トラフィックのパスを提供します。 Oracle Private Cloud Applianceのコンテキストでは、このトラフィックはデータ・センター・ネットワークとその宛先にルーティングされます。 データ・センター・ネットワークは、アプライアンス環境の外部にあるため、パブリック・ネットワークとみなされます。 しかし、トラフィックがインターネットを経由しないため、トンネルの形式は必要ありません。 これは、パブリック・クラウド環境との大きな違いです。

アクセス制御の目的で、DRGを作成するときは、DRGを配置するコンパートメントを指定する必要があります。 使用するコンパートメントがわからない場合は、DRGをVCNと同じコンパートメントに配置します。

DRGはスタンドアロン・オブジェクトです。 これを使用するには、VCNにアタッチする必要があります。 APIでは、アタッチのプロセスによって、独自のOCIDを持つDRGアタッチメント・オブジェクトが作成されます。 DRGをデタッチするには、アタッチメント・オブジェクトを削除します。

VCNは一度に1つのDRGにのみアタッチできますが、DRGは複数のVCNにアタッチできます。 DRGをデタッチして、いつでも再アタッチできます。 DRGをアタッチした後、DRGを使用するようにVCNのルーティングを更新する必要があります。 そうしないと、VCNからのトラフィックはDRGに流れません。

基本的なルーティング・シナリオでは、VCNのサブネットからDRGにトラフィックを送信します。 サブネットからオンプレミス・ネットワークにトラフィックを送信する場合、サブネット・ルート表にルールを設定します。 ルール宛先CIDRはオンプレミス・ネットワークまたは内部のサブネットのCIDRで、ルール・ターゲットはDRGです。

6.4.2 NATゲートウェイ

NATゲートウェイにより、パブリックIPを持たないクラウド・リソースがオンプレミス・ネットワークにアクセスでき、これはVCNの視点から外部パブリック・ネットワークであり、それらのリソースを公開しません。 特定のVCNのコンテキストでNATゲートウェイを作成すると、作成時にゲートウェイがそのVCNに自動的にアタッチされます。 ゲートウェイを使用すると、ホストはオンプレミス・ネットワークへの接続を開始してレスポンスを受信できますが、オンプレミス・ネットワークから開始されたインバウンド接続の受信を阻止できます。 NATゲートウェイは高可用性で、TCP、UDPおよびICMPのpingトラフィックをサポートします。 Networkingサービスは、パブリックIPアドレスをNATゲートウェイに自動的に割り当てます。 パブリックIPアドレスを選択できません。

プライベート・ネットワークのホストがオンプレミス・ネットワークへの接続を開始すると、NATデバイスのパブリックIPアドレスがアウトバウンド・トラフィックのソースIPアドレスになります。 したがって、オンプレミス・ネットワークからのレスポンス・トラフィックは、そのパブリックIPアドレスを宛先IPアドレスとして使用します。 次に、NATデバイスは、レスポンスをプライベート・ネットワークに、接続を開始したホストに転送します。

VCNルーティングはサブネット・レベルで制御されるため、NATゲートウェイを使用するサブネットを指定できます。 Oracle Private Cloud Applianceは、VCNごとに1つのNATゲートウェイのみをサポートします。

アクセス制御の目的で、NATゲートウェイを作成するときは、ゲートウェイを配置するコンパートメントを指定する必要があります。 使用するコンパートメントがわからない場合は、ゲートウェイをVCNと同じコンパートメントに配置します。

デフォルトでは、NATゲートウェイは、作成時にトラフィックを許可します。 ただし、ゲートウェイを介したトラフィックをいつでもブロックまたは許可できます。 NATゲートウェイをブロックすると、VCN内の既存のルート・ルールまたはセキュリティ・ルールに関係なく、すべてのトラフィックが防止されます。

6.4.3 インターネット・ゲートウェイ

インターネット・ゲートウェイは、VCNのエッジをオンプレミス・ネットワークに接続します。 インターネット・ゲートウェイを介してルーティングされるトラフィックの最終的なターゲットは、インターネットである可能性があります。 ただし、プライベート・クラウド・モデルでは、インターネット・ゲートウェイはトラフィックをオンプレミス・ネットワークにルーティングします。 インターネットとの間のトラフィックは、オンプレミス・ネットワークのルーティング構成によって管理されます。

特定のVCNのコンテキストでインターネット・ゲートウェイを作成すると、作成時にゲートウェイがそのVCNに自動的にアタッチされます。 ゲートウェイを使用するには、接続の両端にあるホストにルーティング用のパブリックIPアドレスが必要です。 VCNで発生し、VCNの内部または外部のパブリックIPアドレスを宛先とする接続は、インターネット・ゲートウェイを経由します。 VCNの外部で発生し、VCN内のパブリックIPアドレスを宛先とする接続もインターネット・ゲートウェイを通過します。

特定のVCNは、インターネット・ゲートウェイを1つのみ持つことができます。 サブネット関連ルート表を構成することで、VCN内のどのパブリック・サブネットがゲートウェイを使用できるかを制御します。 パブリック・サブネットのセキュリティ・リスト・ルールは、最終的に、サブネット内のリソースとの間で許可される特定のタイプのトラフィックを決定します。 インターネット・ゲートウェイは無効にできます。つまり、そのようなトラフィックを有効にする既存のルート・ルールに関係なく、インターネットとのトラフィック・フローやインターネットからのトラフィック・フローはありません。

アクセス制御の目的で、インターネット・ゲートウェイを作成する場合、ゲートウェイを配置するコンパートメントを指定する必要があります。 使用するコンパートメントがわからない場合は、ゲートウェイをVCNと同じコンパートメントに配置します。

6.4.4 ローカル・ピアリング・ゲートウェイ

VCNピアリングは、リソースがプライベートIPアドレスを使用して通信できるように、複数の仮想クラウド・ネットワーク(VCN)を接続するプロセスです。 VCNピアリングを使用して、たとえば、部門や事業分野に基づいてネットワークを複数のVCNに分割でき、各VCNは他のVCNに直接プライベート・アクセスします。 このほか、共有リソースを、他のすべてのVCNからのプライベート・アクセスが可能な1箇所のVCNに置くこともできます。 ピアリングされた2つのVCNは、同じテナンシ内にすることも、異なるものにすることもできます。

ピアリング接続を設定するには、次のコンポーネントが必要です:

  • 重複しないCIDRを持つ2つのVCN

  • ピアリング関係の各VCN上のローカル・ピアリング・ゲートウェイ(LPG)

  • 2つのLPG間の接続

  • 各VCNの目的のサブネットとの間のピアリング接続を介したトラフィックを有効化するルート・ルール

  • 問題のサブネットのインスタンスとの間で許可されるトラフィックのタイプを制御するセキュリティ・ルール

ポリシー

2つのVCN間のピアリングでは、各パーティが独自のVCNコンパートメントまたはテナンシ用に実装するIAMポリシーの形式で、両方のパーティからの明示的な合意が必要です。 VCNが異なるテナンシにある場合は、各管理者がテナンシOCIDを指定し、ピアリングを有効にするために特別な調整されたポリシー・ステートメントを配置する必要があります。

ピアリングに必要なIAMポリシーを実装するには、2人のVCN管理者が1人の管理者をリクエスタとして、もう1人をアクセプタとして指定する必要があります。 リクエスタは、2つのLPGを接続するリクエストを開始する必要があります。 次に、アクセプタは、アクセプタ・コンパートメント内のLPGに接続するリクエスタ権限を付与する特定のIAMポリシーを作成する必要があります。 そのポリシーがないと、リクエスタは接続リクエストが失敗します。 いずれのVCN管理者がLPGを削除することでピアリング接続を終了できます。

ルーティングとトラフィックの制御

VCNの構成の一部として、各管理者はVCNルーティングを更新して、トラフィックがCN間で流れるようにする必要があります。 実際には、これは、インターネット・ゲートウェイや動的ルーティング・ゲートウェイなど、任意のゲートウェイに対して設定したルーティングのように見えます。 他のVCNと通信する必要があるサブネットごとに、サブネット・ルート表を更新します。 ルート・ルールでは、宛先トラフィックCIDRおよびターゲットとしてLPGを指定します。 LPGは、そのルールに一致するトラフィックを他のLPGにルーティングし、これにより、トラフィックは他のVCNの次のホップにルーティングされます。

VCNのルート表を使用してピアリング接続上のパケット・フローを制御できます。 たとえば、トラフィックを他のVCN内の特定のサブネットのみに制限できます。 ピアリングを終了せずに、VCNから別のVCNにトラフィックを転送するルート・ルールを削除するだけで、他のVCNへのトラフィック・フローを停止できます。 また、他のVCNとのイングレス・トラフィックまたはエグレス・トラフィックを有効にするセキュリティ・リスト・ルールを削除することで、トラフィックを効果的に停止することもできます。 これにより、ピアリング接続を介するトラフィックは停止せず、VNICレベルで停止します。

セキュリティ・ルール

各VCN管理者は、他のVCNとのすべてのアウトバウンドおよびインバウンド・トラフィックが、想定され、適切に定義されていることを確認する必要があります。 実際には、これは、VCNが他方に送信して他方から受け入れるトラフィックのタイプを明示的に示すセキュリティ・リスト・ルールを実装することを意味します。 サブネットでデフォルト・セキュリティ・リストを使用する場合、任意の場所からのSSHおよびICMPイングレス・トラフィックを許可する2つのルールがあるため、他のVCNも可能です。 これらのルール、および保持するか更新するかを評価します。

セキュリティ・リストおよびファイアウォールに加えて、VCN内のインスタンス上のその他のOSベースの構成を評価する必要があります。 独自のVCN CIDRに適用されないが、他のVCN CIDRに不注意で適用されるデフォルト構成がある可能性があります。

6.4.5 サービス・ゲートウェイ

オブジェクト・ストレージ・サービスなどの特定のサービスは、概念的な「サービス・ネットワーク」で内部的に公開されます。 通常、これらのサービスは、パブリック・ネットワークを介して到達できるパブリックIPアドレスを使用 - またはインターネット経由でパブリック・クラウド・モデル内。 かわりに、サービス・ゲートウェイの目的は、VCNがサービス・ネットワーク内のサービスにプライベート・アクセスできるようにすることです。つまり、プライベート・サブネット内のリソースは、外部アクセスのない狭いVCN内でそれらのサービスに接続できます。

VCNに指定できるサービス・ゲートウェイは1つのみです。 特定のVCNのコンテキストでサービス・ゲートウェイを作成すると、作成時にゲートウェイがそのVCNに自動的にアタッチされます。 サービス・ゲートウェイでは、作成時にすべてのサブネットとの間のトラフィックが許可されます。このトラフィックをブロックまたは無効にするメカニズムはありません。

Oracle Private Cloud Applianceでは、これらのサービスは管理ノード・クラスタを介してインフラストラクチャ・レベルで実装されます。 技術的には、完全修飾ドメイン名であるサービス・エンドポイントは、デフォルトでオンプレミス・ネットワーク全体からアクセス可能です。つまり、サービス・ゲートウェイに実際の機能はありません。 特にプライベート・クラウドを使用する場合、サービス・エンドポイントへのプライベート・アクセスを有効にするために、サービス・ゲートウェイおよび関連するルート・ルールを構成する必要はありません。 ただし、Oracle Cloud Infrastructureとの互換性を維持するために、サービス・ゲートウェイの概念が存在します。

サービス・ゲートウェイは、対象となるサービスまたはサービスのグループのエンドポイントを表す文字列であるサービスCIDRラベルを使用します。 つまり、特定のエンドポイントを知る必要はありません。 サービス・エンドポイントが将来変更された場合、調整する必要はありません。 サービスCIDRラベルは、サービス・ゲートウェイを構成する場合に使用します。 Oracle Private Cloud Applianceを使用すると、サービス・ゲートウェイを作成し、「"サービスCIDRブロック"」を含むルート・ルールを構成できます。 ただし、互換性以外の目的は果たさないことに注意してください。

Oracle Private Cloud Applianceはデータ・センター・ネットワークの安全な境界内に設定されるため、サービスへのプライベート・アクセスの保護は、Oracle Cloud Infrastructureなどのパブリック・クラウド環境と比較して、あまり関心がありません。 したがって、サービス・ゲートウェイに対してセキュリティ・ルールは実装されません。 詳細は、第6.5.1項、「セキュリティ・ルール」を参照してください。

6.5 仮想ファイアウォール

Networkingサービスは、両方ともセキュリティ・ルールを使用してパケット・レベルでトラフィックを制御する、2つの仮想ファイアウォール機能を提供します。 仮想ネットワーク・インタフェース・カード(VNIC)のセットにセキュリティ・ルールを適用する様々な方法を提供します。

  • セキュリティ・リスト:

    セキュリティ・リストは、サブネット・レベルでセキュリティ・ルールを定義します。つまり、特定のサブネット内のすべてのVNICが同じルールに従います。 各VCNには、必須トラフィックのデフォルト・ルールを含むデフォルト・セキュリティが付属しています。 カスタム・セキュリティ・リストが指定されていないかぎり、デフォルト・セキュリティ・リストはすべてのサブネットで自動的に使用されます。 1つのサブネットは、最大5つのセキュリティ・リストを関連付けることができます。

  • ネットワーク・セキュリティ・グループ(NSG):

    ネットワーク・セキュリティ・グループは、メンバーシップに基づいてセキュリティ・ルールを定義します。 セキュリティ・ルールは、NSGに明示的に追加されたリソースに適用されます。 VNICは最大5つのNSGに追加できます。 NSGは、一連のクラウド・リソースに、同じセキュリティ状態を持つ仮想ファイアウォールを提供することを目的としています。 次に例を示します: 同じタスクを実行するため、同じポート・セットを使用する必要があります。

NSGではVCNサブネット・アーキテクチャをアプリケーション・セキュリティ要件から分離できるため、Oracleではセキュリティ・リストのかわりにNSGを使用することをお薦めします。 ただし、NSGは特定のサービスでのみサポートされます。 セキュリティ・リストとNSGの両方を、特定のセキュリティ・ニーズに応じて組み合せて使用できます。

VCN内のすべてのVNICに対して適用するセキュリティ・ルールがある場合、最も簡単な解決策は、ルールを1つのセキュリティ・リストに入れ、そのセキュリティ・リストをVCN内のすべてのサブネットに関連付けることです。 このようにして、組織内の誰がVCNにVNICを作成するかに関係なく、ルールが適用されるようにできます。 または、必要なセキュリティ・ルールをVCNのデフォルト・セキュリティ・リストに追加できます。

セキュリティ・リストとネットワーク・セキュリティ・グループを結合することを選択した場合、特定のVNICに適用されるルールのセットは、次のアイテムを結合したものです:

  • VNICサブネットに関連付けられたセキュリティ・リスト内のセキュリティ・ルール

  • VNICが使用されているすべてのNSGのセキュリティ・ルール

関連するリストおよびグループのいずれかの「任意のルール」でトラフィックが許可されている場合、またはステートフル・ルールのためにトラフィックが追跡されている既存の接続の一部である場合、問題のパケットは許可されます。

6.5.1 セキュリティ・ルール

この項では、セキュリティ・リストまたはネットワーク・セキュリティ・グループの一部として実装するために理解する必要があるセキュリティ・ルールの重要な側面について説明します。 セキュリティ・ルールを作成、管理および適用する方法は、セキュリティ・リストとネットワーク・セキュリティ・グループによって異なります。 関連セクションには、各実装に関する詳細情報が表示されます。

セキュリティ・ルールの構成要素

セキュリティ・ルールでは、特定のタイプのトラフィックをVNIC内外に許可します。 たとえば、一般的に使用されるセキュリティ・ルールでは、インスタンスへのSSH接続を確立するために、イングレスTCPポート22トラフィックを許可します。 セキュリティ・ルールがないと、VCN内のVNICとの間のトラフィックは許可されません。

各セキュリティ・ルールは次のアイテムを指定します:

  • 方向(イングレスまたはエグレス): イングレスはVNICへのインバウンド・トラフィックで、エグレスはVNICからのアウトバウンド・トラフィックです。

    セキュリティ・リストのREST APIモデルは、ネットワーク・セキュリティ・グループとは異なります。 セキュリティ・リストでは、IngressSecurityRuleオブジェクトと個別のEgressSecurityRuleオブジェクトがあります。 ネットワーク・セキュリティ・グループでは、SecurityRuleオブジェクトのみが存在し、オブジェクトのdirection属性によって、ルールがイングレス・トラフィック用かエグレス・トラフィック用かが決まります。

  • ステートフルまたはステートレス: ステートフルの場合、ルールに一致するトラフィックに接続トラッキングが使用されます。 ステートレスの場合、接続トラッキングは使用されません。 このセクションの「ステートフルおよびステートレス・ルール」を参照してください。

  • ソース・タイプおよびソース: イングレス・ルールの場合のみ。指定するソースは、選択したソース・タイプによって異なります。 次のソース・タイプを使用できます:

    ソース・タイプ

    許可されたソース

    CIDR

    トラフィックの発生元のCIDRブロック。 すべてのIPアドレスを指定するには、0.0.0.0/0を使用します。 プレフィクスは必須です。 たとえば、個々のIPアドレスを指定する場合は、 /32を含めます。

  • 宛先タイプと宛先: エグレス・ルールの場合のみ。指定する宛先は、選択した宛先タイプによって異なります。 次の宛先タイプを使用できます:

    宛先タイプ

    許可される宛先

    CIDR

    トラフィックの宛先のCIDRブロック。 すべてのIPアドレスを指定するには、0.0.0.0/0を使用します。 プレフィクスは必須です。 たとえば、個々のIPアドレスを指定する場合は、 /32を含めます。

  • IPプロトコル: すべてのプロトコルをカバーする単一のIPv4プロトコルまたは「all」。

  • ソース・ポート: トラフィックの発生元のポート。 TCPまたはUDPの場合、すべてのソース・ポートを指定するか、オプションで単一のソース「ポート番号」または範囲を指定できます。

  • 宛先ポート: トラフィックの宛先のポート。 TCPまたはUDPの場合、すべての宛先ポートを指定するか、オプションで単一の宛先「ポート番号」または範囲を指定できます。

  • ICMPタイプおよびコード: ICMPでは、すべてのタイプおよびコードを指定するか、オプションで単一のタイプで打つをオプション・コードとともに指定できます。 タイプに複数のコードがある場合は、許可するコードごとに個別のルールを作成します。

  • 説明: NSGセキュリティ・ルールには、ルールの説明を含めるオプションの属性が含まれます。 これは現在、セキュリティ・リスト・ルールではサポートされていません。

ステートフルおよびステートレス・ルール

セキュリティ・ルールを作成する場合は、ステートフルかステートレスかを選択します。 デフォルトはステートフルです。 HTTP/HTTPSトラフィックのインターネットに直接接続するwebサイトが大量にある場合、ステートレス・ルールをお薦めします。

セキュリティ・ルールを「ステートフル」としてマークすることは、そのルールに一致するトラフィックに対して接続トラッキングを使用することを示します。 そのため、ステートフルingressルールに一致するトラフィックをインスタンスが受信した場合、それに対するレスポンスは追跡され、そのインスタンスに適用されるegressルールに関係なく、元のホストへのレスポンスは自動的に許可されます。 また、ステートフルegressルールに一致するトラフィックをインスタンスが送信した場合、ingressルールに関係なく、受信レスポンスは自動的に許可されます。

セキュリティ・ルールを「ステートレス」としてマークすることは、そのルールに一致するトラフィックに対して接続トラッキングを使用しないことを示します。 そのため、レスポンス・トラフィックは自動的に許可されません。 ステートレスingressルールでレスポンス・トラフィックを許可するには、対応するステートレスegressルールを作成する必要があります。

ステートフル・ルールとステートレス・ルールの両方を使用し、特定の方向でステートフル・ルールとステートレス・ルールの両方に一致するトラフィックがある場合、ステートレス・ルールが優先され、接続は追跡されません。 レスポンス・トラフィックを許可するには、他の方向(ステートレスまたはステートフル)に対応するルールが必要です。

ステートレス・セキュリティ・ルールを使用して、VCN外のエンドポイントとの間のトラフィックを許可する場合は、ソース0.0.0.0/0および任意のソース・ポートからのイングレスICMPトラフィック・タイプ3コード4を許可するセキュリティ・ルールを追加することが重要です。 このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。 このルールは、インスタンスへの接続を確立するために重要です。 そうしないと、接続性の問題が発生する可能性があります。

セキュリティ・ルールのベスト・プラクティス

  • ネットワーク・セキュリティ・グループの使用

    Oracleでは、すべて同じセキュリティ状態を持つコンポーネントにNSGを使用することをお薦めします。 たとえば、複数層アーキテクチャでは、層ごとに個別のNSGを使用します。 特定の層VNICは、すべてその層NSGに属します。

    特定の層内で、特別なセキュリティ要件が追加された層VNICの特定のサブセットを持つ場合があります。 そのため、これらの追加ルール用に別のNSGを作成し、そのVNICのサブセットを追加のルールを持つ層NSGとNSGの両方に配置します。

  • デフォルト・セキュリティ・リスト・ルールの理解

    各VCNには、ネットワーキング・サービスの使用を開始する際に役立ついくつかのデフォルト・セキュリティ・ルールを含むデフォルト・セキュリティ・リストが自動的に付属しています。 これらのルールは、基本的な接続を有効にするため存在します。

    セキュリティ・リストまたはデフォルト・セキュリティ・リストを使用しない場合でも、ネットワーク・クラウド・リソースが必要とするトラフィックのタイプをよく理解できるように、ルールについて理解してください。 これらのルールは、NSGまたは設定したカスタム・セキュリティ・リストで使用できます。

    pingリクエストを許可するデフォルト・ルールはありません。 インスタンスをpingする場合は、ping元となる予定のソース・ネットワークからのICMPトラフィック・タイプ8を明示的に許可するステートフル・イングレス・ルールを追加します。 インターネットからのpingアクセスを許可するには、ソースに0.0.0.0/0を使用します。 pingのこのルールは、デフォルト・セキュリティ・リストのデフォルトのICMP関連ルールとは異なります。 これらのルールは削除しないでください。

  • デフォルト・セキュリティ・ルールを無条件に削除しない

    VCNには、デフォルト・セキュリティ・リストをデフォルトで使用するサブネットがある場合があります。 リストのデフォルト・セキュリティ・ルールは、VCN内のリソースがそれらを必要としないことを最初に確認しないかぎり、削除しないでください。 そうしないと、VCN接続が中断する可能性があります。

  • 必要に応じて、pingリクエストを許可するルールを追加

    pingリクエストを許可するデフォルト・ルールはありません。 インスタンスをpingする場合は、ping元となる予定のソース・ネットワークからのICMPトラフィック・タイプ8を明示的に許可するステートフル・イングレス・ルールを追加します。 インターネットからのpingアクセスを許可するには、ソースに0.0.0.0/0を使用します。 pingのこのルールは、デフォルト・セキュリティ・リストのデフォルトのICMP関連ルールとは異なります。 これらのルールは削除しないでください。

  • 必要に応じて、断片化されたUDPパケットを処理するルールを追加

    インスタンスはUDPトラフィックを送受信できます。 UDPパケットが接続に対して大きすぎる場合は、断片化されます。 ただし、パケットの最初のフラグメントにのみプロトコルおよびポート情報が含まれます。 このイングレスまたはエグレス・トラフィックを許可するセキュリティ・ルールで特定の(ソースまたは宛先)ポート番号が指定されている場合は、最初のポート番号の後にフラグメントが削除されます。 インスタンスが大規模なUDPパケットを送受信することを想定している場合は、該当するセキュリティ・ルールのソース・ポートと宛先ポートの両方を特定のポート番号ではなくALLに設定します。

  • OSファイアウォール・ルールとセキュリティ・ルールの連携

    Oracle Private Cloud Applianceで提供されるイメージを実行しているインスタンスには、インスタンスへのアクセスを制御するOSファイアウォール・ルールもあります。 インスタンスへのアクセスのトラブルシューティングを行う際は、次のアイテムがすべて正しく設定されていることを確認してください:

    • インスタンスが存在するネットワーク・セキュリティ・グループ内のルール

    • インスタンス・サブネットに関連付けられたセキュリティ・リスト内のルール

    • インスタンスOSファイアウォール・ルール

6.5.2 セキュリティ・リスト

セキュリティ・リストは、インスタンスの仮想ファイアウォールとして機能し、送受信を許可するトラフィック・タイプを指定するイングレスおよびエグレス・ルールを使用します。 各セキュリティ・リストは、VNICレベルで適用されます。 ただし、サブネット・レベルでセキュリティ・リストを構成します。つまり、特定のサブネット内のすべてのVNICが同じセキュリティ・リストのセットに従います。 セキュリティ・リストは、VCN内の別のインスタンスと通信しているか、VCN外のホストと通信しているかに関係なく、特定のVNICに適用されます。 各サブネットには複数のセキュリティ・リストを関連付けることができ、各リストには複数のルールを含めることができます。

各VCNにはデフォルトのセキュリティ・リストが付属しています。 サブネットのカスタム・セキュリティ・リストを指定しない場合、そのサブネットではデフォルト・セキュリティ・リストが自動的に使用されます。 デフォルト・セキュリティ・リストでルールを追加または削除できます。 ステートフル・ルールの初期セットがあり、ほとんどの場合、認可されたサブネットからのインバウンド・トラフィックのみを許可するように変更する必要があります。 デフォルトのルールは次のとおりです:

  • ステートフル・イングレス: 認可されたソースIPアドレスおよびすべてのソース・ポートからの宛先ポート22 (SSH)でTCPトラフィックを許可します。

    このルールを使用すると、新しいクラウド・ネットワークおよびパブリック・サブネットを簡単に作成でき、Linuxインスタンスを起動し、ただちにSSHを使用してそのインスタンスに接続できます。セキュリティ・リスト・ルールは自分で記述する必要はありません。

    デフォルトのセキュリティ・リストには、リモート・デスクトップ・プロトコル(RDP)アクセスを許可するルールは含まれていません。 Windowsイメージを使用している場合は、認可されたソースIPアドレスおよびすべてのソース・ポートから、宛先ポート3389上のTCPトラフィックに対してステートフル・イングレス・ルールを追加してください。

  • ステートフル・イングレス: 認可されたソースIPアドレスからのICMPトラフィック・タイプ3コード4を許可します。

    このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。

  • ステートフル・イングレス: VCN CIDRブロックからのICMPトラフィック・タイプ3 (すべてのコード)を許可します。

    このルールにより、インスタンスがVCN内の他のインスタンスから接続エラー・メッセージを受信しやすくなります。

  • ステートフル・エグレス: すべてのトラフィックを許可します。

    これにより、インスタンスは任意の宛先への任意の種類のトラフィックを開始できます。 これは、パブリックIPアドレスを持つインスタンスが、VCNに構成済のインターネット・ゲートウェイがある場合、任意のインターネットIPアドレスと通信できることを意味します。 また、ステートフル・セキュリティ・ルールでは接続トラッキングが使用されるため、イングレス・ルールに関係なくレスポンス・トラフィックが自動的に許可されます。

セキュリティ・リストを使用する一般的なプロセスは次のとおりです:

  1. セキュリティ・リストを作成します。

  2. セキュリティ・リストにセキュリティ・ルールを追加します。

  3. セキュリティ・リストを1つ以上のサブネットに関連付けます。

  4. サブネット内にコンピュート・インスタンスなどのリソースを作成します。

    セキュリティ・ルールは、そのサブネット内のすべてのVNICに適用されます。

サブネットを作成する場合、少なくとも1つのセキュリティ・リストを関連付ける必要があります。 これは、VCNデフォルト・セキュリティ・リストか、すでに作成した1つ以上の他のセキュリティ・リストのいずれかです。 サブネットが使用するセキュリティ・リストは、いつでも変更できます。 セキュリティ・リストでルールを追加または削除できます。 セキュリティ・リストにルールが含まれていない可能性があります。

6.5.3 ネットワーク・セキュリティ・グループ

ネットワーク・セキュリティ・グループ(NSG)は、単一のVCN内で、すべて同じセキュリティ体制を持つ一連のクラウド・リソースに対して仮想ファイアウォールを提供します。 次に例を示します: すべて同じタスクを実行するコンピュート・インスタンスのグループで、すべて同じポート・セットを使用する必要があります。

NSGのルールはVNICに適用されますが、NSGメンバーシップは親リソースを介して決定されます。 すべてのクラウド・サービスがNSGをサポートしているわけではありません。 現在、次のタイプの親リソースはNSGの使用をサポートしています:

  • コンピュート・インスタンス: インスタンスの作成時に、インスタンスのプライマリVNICに1つ以上のNSGを指定できます。 セカンダリVNICをインスタンスに追加する場合、そのVNICに1つ以上のNSGを指定できます。 既存のVNICのNSGメンバーシップを変更することもできます。

  • マウント・ターゲット: ファイル・システムのマウント・ターゲットを作成する場合、1つ以上のNSGを指定できます。 1つ以上のNSGを使用するように既存のマウント・ターゲットを更新することもできます。

NSGをまだサポートしていないリソース・タイプについては、セキュリティ・リストを引き続き使用して、それらの親リソースとの間のトラフィックを制御します。

NSGには、次の2つのタイプの要素があります:

  • VNICs: 1つ以上のVNIC。たとえば、すべて同じセキュリティ体制を持つコンピュート・インスタンスのセットにアタッチされたVNICです。 すべてのVNICは、NSGが属するVCN内にある必要があります。 VNICは最大5つのNSG内にできます。

  • セキュリティ・ルール: グループ内のVNICに対して許可されるトラフィックのタイプを定義するルール。 次に例を示します: 特定のソースからのイングレスTCPポート22 SSHトラフィック。

NSGを使用する一般的なプロセスは次のとおりです:

  1. NSGを作成します。

    NSGを作成すると、セキュリティ・ルールまたはVNICを使用せずに、最初は空になります。 NSGの作成後、セキュリティ・ルールを追加または削除して、グループ内のVNICに必要なイングレス・トラフィックおよびエグレス・トラフィックのタイプを許可します。

  2. セキュリティ・ルールをNSGに追加します。

  3. 親リソース(特にVNIC)をNSGに追加します。

    NSG VNICメンバーシップを管理する場合、NSG自体ではなく親リソースの操作の一部として行います。 親リソースの作成時にこれを実行することも、親リソースを更新して1つ以上のNSGに追加することもできます。

    コンピュート・インスタンスを作成してNSGに追加すると、インスタンスのプライマリVNICがNSGに追加されます。 セカンダリVNICは個別に作成でき、オプションでNSGに追加できます。

セキュリティ・リストと比較して、NSGのREST APIモデルにはいくつかの違いがあります:

  • セキュリティ・リストでは、IngressSecurityRuleオブジェクトと個別のEgressSecurityRuleオブジェクトがあります。 ネットワーク・セキュリティ・グループでは、SecurityRuleオブジェクトのみが存在し、オブジェクトのdirection属性によって、ルールがイングレス・トラフィック用かエグレス・トラフィック用かが決まります。

  • セキュリティ・リストでは、ルールはSecurityListオブジェクトの一部であり、たとえばセキュリティ・リスト操作をコールしてルールを使用: UpdateSecurityList。 NSGでは、ルールはNetworkSecurityGroupオブジェクトの一部ではありません。 かわりに、別の操作を使用して、特定のNSGのルールを操作します。たとえば、: UpdateNetworkSecurityGroupSecurityRules。

  • 既存のセキュリティ・ルールを更新するモデルは、セキュリティ・リストとNSGで異なります。 NSGでは、特定のグループ内の各ルールに一意の識別子があります。 UpdateNetworkSecurityGroupSecurityRulesをコールするときに、更新する特定のルールのIDを指定します。 セキュリティ・リストでは、ルールに一意の識別子はありません。 UpdateSecurityListをコールする場合、コールで更新されていないルールを含め、ルールのリスト全体を渡す必要があります。

  • セキュリティ・ルールを追加、削除または更新する操作をコールする場合、ルールは25に制限されています。

6.6 ネットワーク・セキュリティ

この項では、クラウド・ネットワークでのアクセスおよびセキュリティの制御について説明します。 VCN内のファイアウォール機能の詳細は、第6.5項、「仮想ファイアウォール」を参照してください。 ここでは、セキュアなネットワーク・アクセスに関する追加のトピックについて説明します。

6.6.1 ネットワークを保護する方法

クラウド・ネットワークとコンピュート・インスタンスのセキュリティを制御するには、いくつかのメカニズムがあります:

  • プライベート・サブネット: インスタンスにパブリックIPアドレスが必要ない場合、インスタンスがプライベートIPを取得しないように、サブネットをプライベートに指定できます。

  • ファイアウォール・ルール: インスタンスとの間のパケット・レベルのトラフィックを制御するには、インスタンス自体でファイアウォール・ルールを直接構成できます。 Oracle Linuxを実行するOracle Private Cloud Applianceで提供されるイメージには、SSHトラフィックのTCPポート22でのイングレスを許可するデフォルト・ルールが自動的に含まれます。 また、Windowsイメージには、リモート・デスクトップ・アクセス用にTCPポート3389でイングレスを許可するデフォルト・ルールが含まれることがあります。

  • ゲートウェイおよびルート表: クラウド・ネットワークから外部宛先への一般トラフィック・フローを制御するため - インターネット、オンプレミス・ネットワークまたは別のVCN - クラウド・ネットワーク・ゲートウェイおよびルート表を構成して、事実上必要な接続のみを許可します。

  • IAMポリシー: Oracle Private Cloud Applianceインタフェースにアクセスできるユーザーを制御できます。 アクセスできるクラウド・リソースと、許可されるアクセスのタイプを制御できます。 たとえば、ネットワークとサブネットを設定できるユーザーや、ルート表、ネットワーク・セキュリティ・グループまたはセキュリティ・リストを更新できるユーザーを制御できます。

6.6.2 アクセス制御

このトピックでは、コンパートメントとIAMポリシーを使用したクラウド・ネットワークへのアクセスの制御に関する基本情報を示します。

ネットワーク・リソースでのコンパートメントの使用

仮想クラウド・ネットワーク(VCN)やコンピュート・インスタンスなどのクラウド・リソースを作成する場合、そのリソースに含めるIAMコンパートメントを指定する必要があります。 コンパートメントは、テナンシの管理者から権限を付与された特定のグループのみがアクセスできる関連リソースのコレクションです。 管理者は、コンパートメントと対応するIAMポリシーを作成して、組織内のどのユーザーがどのコンパートメントにアクセスするかを制御します。 最終的に、ユーザーは必要なリソースにのみアクセスできるようにすることが目標です。

エンタープライズ本番環境では、通常、テナンシを複数のコンパートメントに分割して、特定のタイプのリソースへのアクセスをより簡単に制御します。 たとえば、管理者はVCNおよび他のネットワーキング・コンポーネントのCompartment_Aを作成できます。 管理者は、HR部門が使用するすべてのコンピュート・インスタンスおよびブロック・ストレージ・ボリュームにCompartment_Bを作成し、マーケティング部門が使用するすべてのインスタンスおよびブロック・ストレージ・ボリュームにCompartment_Cを作成できます。

管理者は、各コンパートメントで必要なアクセス・レベルのみをユーザーに付与するIAMポリシーを作成します。 たとえば、HRインスタンス管理者は既存のクラウド・ネットワークを変更する資格がありません。 したがって、Compartment_Bに対する完全な権限を持ちますが、Compartment_Aへのアクセスは制限されます: インスタンスをネットワークに起動するために必要なもののみ。 Compartment_A内の他のリソースを変更しようとすると、リクエストは拒否されます。

VCN、サブネット、ルート表、セキュリティ・リスト、サービス・ゲートウェイ、NATゲートウェイなどのネットワーク・リソースは、コンパートメント間で移動できます。 リソースを新しいコンパートメントに移動すると、固有のポリシーがただちに適用されます。

コンパートメントの使用およびクラウド・リソースへのアクセスの制御方法の詳細は、「Identity and Access Management概要」の章を参照してください。 詳細は、第4.4項、「コンパートメント内のリソースの編成」および第4.5項、「ポリシーの仕組み」を参照してください。

ネットワーキングに対するIAMポリシーの使用

ネットワークへのアクセス権を付与する便利な一般的な方法は、ネットワーク管理者グループにVCNおよび関連するすべてのネットワーキング・コンポーネントを管理する権限を付与することです: サブネット、セキュリティ・リスト、ルート表、ゲートウェイなど。 ネットワーク接続をテストするために、ネットワーク管理者によるインスタンスの起動も許可すると便利です。 両方のポリシー - ネットワーク・リソースの管理およびインスタンスの起動 - 第4.5.3項、「共通ポリシー」を参照してください。 必要なポリシー・ステートメントは、次の例のようになります: 

Allow group NetworkAdmins to manage virtual-network-family in tenancy
Allow group NetworkAdmins to manage instance-family in compartment ABC
Allow group NetworkAdmins to use volume-family in compartment ABC

IAMポリシーをまだ理解していない場合は、「Identity and Access Management概要」の章の第4.5項、「ポリシーの仕組み」を参照してください。

アクセス制御へのきめ細かいアプローチを好む場合は、個々のリソース・タイプに焦点を当てるポリシーを記述できます。 たとえば、virtual-network-familyリソース・タイプには、subnets, route-tables, security-listsやlocal-peering-gatewaysなどの個々のリソース・タイプが含まれます。 リソース・タイプごとに個別のポリシーを記述することで、これらの特定のアクセス権を付与できます。

さらに、たとえば別のポリシー動詞を使用して、アクセス・レベルを制限するポリシーを記述できます: manageとuseなど。 これを行うと、ネットワーキングのポリシー動詞を理解する微妙な違いがいくつかあります。

inspect動詞は、セキュリティ・リストまたはルート表の名前およびOCIDなど、ネットワーク・コンポーネントに関する一般情報を返すだけでなく、注意してください。 また、コンポーネントのコンテンツ(たとえば、セキュリティ・リスト内の実際のルール、ルート表内のルートなど)も含まれます。

また、次の操作はmanage動詞でのみ使用でき、use動詞では使用できません:

  • internet-gatewaysの更新(有効化/無効化)

  • security-listsの更新

  • route-tablesの更新

  • dhcp-optionsの更新

  • DRGのVCNへのアタッチ

  • ピア2つのVCN

各VCNには、ネットワークの動作に直接影響を与える様々なコンポーネントがあります: ルート表、セキュリティ・リスト、DHCPオプション、インターネット・ゲートウェイなど。 これらのコンポーネントのいずれかを作成する場合、そのコンポーネントとVCNの間の関係を確立します。つまり、コンポーネントの作成とVCN自体の管理の両方を行うポリシーで許可されている必要があります。 ただし、そのコンポーネントを更新する機能 - ルート・ルールやセキュリティ・リスト・ルールなどを変更 - コンポーネントを変更するとネットワークの動作に直接影響を与える可能性がありますが、VCN自体を管理する権限は必要ありません。 この不一致は、ユーザーに最低限の権限を付与する柔軟性を提供するように設計されており、ユーザーがネットワークの他のコンポーネントを管理できるように、VCNへの過剰なアクセス権を付与する必要はありません。 特定のタイプのコンポーネントを更新する機能を誰かに与えれば、ネットワーク動作を制御して暗黙的に信頼していることに注意してください。

6.7 ネットワーキング・シナリオ

この項では、ネットワーキング・サービスの理解に役立ついくつかの基本的なネットワーキング・シナリオと、ネットワーキング・コンポーネントの連携方法について説明します。

6.7.1 パブリック・サブネット

この項では、VCNとパブリック・サブネットで構成される設定について説明します。 外部接続の場合、VCNにはインターネット・ゲートウェイが必要です。 オンプレミス・ネットワークでは、このゲートウェイを使用してVCN内のリソースと通信することもできます。 このシナリオで使用されるIPアドレスはパブリックである必要があります。 プライベート・クラウドのコンテキストでは、これは、オンプレミス・ネットワークから直接アクセス可能な一意のアドレスであることを意味します。

サブネットはデフォルトのセキュリティ・リストを使用します。このリストには、簡単に開始できるように設計されたデフォルト・ルールがあります。 ルールにより、一般的な必須アクセス(インバウンドSSH接続や任意のタイプのアウトバウンド接続など)が可能になります。 セキュリティ・リスト・ルールではトラフィックのみが許可されることに注意してください。 セキュリティ・リスト・ルールで明示的にカバーされていないトラフィックは、暗黙的に拒否されます。 このシナリオでは、デフォルト・セキュリティ・リストにルールを追加します。 かわりに、これらのルールのカスタム・セキュリティ・リストを作成できます。 次に、デフォルトのセキュリティ・リストとカスタム・セキュリティ・リストの両方を使用するようにサブネットを設定します。

サブネットは、VCNの作成時にルールを含まないデフォルト・ルート表を使用します。 このシナリオでは、表には1つのルールのみがあります: すべての宛先(インターネット・ゲートウェイを介して0.0.0.0/0))を対象としたトラフィックをルーティングします。

このネットワーキング・シナリオを設定するには、次のステップを実行します:

  1. VCNを作成します。

    作業する権限があるコンパートメントを選択します。 VCNに重複しないCIDRブロックを1つ以上指定します。次に例を示します: 172.16.0.0/16。 オプションで、DNSを有効にして、VCNのDNSラベルを指定します。

  2. パブリック・サブネットを作成します。

    たとえば、VCN CIDRブロック内に単一の連続するCIDRブロックを指定: 172.16.10.0/24。 デフォルト・ルート表を選択します。 インスタンスがパブリックIPアドレスを取得できるように、サブネットがパブリック・サブネットであることを確認してください。 VCNレベルでDNSを有効にした場合、サブネットにホスト名を割り当て、サブネットDNSラベルも指定できます。

  3. インターネット・ゲートウェイを作成します。

    インターネット・ゲートウェイを作成すると、すぐに有効になります。 ただし、トラフィックがゲートウェイに流れるようにルート・ルールを追加する必要があります。

  4. インターネット・ゲートウェイを使用するようにデフォルト・ルート表を更新します。

    デフォルトのルート表は、ルールなしで開始されます。 VCN自体でトラフィックをルーティングするために必要なルート・ルールはありません。 VCN外部のアドレス宛てのすべてのトラフィックをインターネット・ゲートウェイにルーティングするルールを追加する必要があります。 次のパラメータを入力します:

    • ターゲット・タイプ: インターネット・ゲートウェイ

    • 宛先CIDRブロック: 0.0.0.0/0

      つまり、ルート表内の他のルールでカバーされていないVCN以外のトラフィックはすべて、このルールで指定されたターゲットに送信されます。

    • ターゲット: 作成したインターネット・ゲートウェイ。

    サブネットはデフォルト・ルート表を使用するように設定されているため、サブネット内のリソースでインターネット・ゲートウェイを使用できるようになりました。 このルールが存在する場合、インターネット・ゲートウェイを介したサブネットへのインバウンド接続も有効になります。 次のステップでは、サブネットで後で作成するインスタンスとの間で許可するトラフィックのタイプを指定します。

  5. デフォルト・セキュリティ・リストを更新します。

    サブネットは、VCNのデフォルト・セキュリティ・リストを使用するように設定します。 次に、VCN内のインスタンスが必要とする接続のタイプを許可するセキュリティ・リスト・ルールを追加します。

    たとえば、サブネット内のインスタンスがwebサーバーである場合、多くの場合、インバウンドHTTPS接続を受信する必要があります。 このトラフィックを有効にするには、次のパラメータを使用して、デフォルト・セキュリティ・リストにイングレス・ルールを追加します:

    • ソース・タイプ: CIDR

    • ソースCIDR: 0.0.0.0/0

    • IPプロトコル: TCP

    • ソース・ポート範囲: すべて

    • 宛先ポート範囲: 443

  6. インスタンスの作成

    次のステップでは、サブネットに1つ以上のインスタンスを作成します。 各インスタンスは、自動的にプライベートIPアドレスを取得します。 このシナリオのネットワーク設定では、各インスタンスにパブリックIPアドレスを割り当てる必要があります。そうしないと、インターネット・ゲートウェイを介してインスタンスにアクセスできません。

6.7.2 プライベート・サブネット

この項では、VCNとプライベート・サブネットで構成される設定について説明します。 オンプレミス・ネットワークへの接続には、VCNに動的ルーティング・ゲートウェイ(DRG)が必要です。

サブネットはデフォルトのセキュリティ・リストを使用します。このリストには、簡単に開始できるように設計されたデフォルト・ルールがあります。 ルールにより、一般的な必須アクセス(インバウンドSSH接続や任意のタイプのアウトバウンド接続など)が可能になります。 セキュリティ・リスト・ルールではトラフィックのみが許可されることに注意してください。 セキュリティ・リスト・ルールで明示的にカバーされていないトラフィックは、暗黙的に拒否されます。 このシナリオでは、デフォルト・セキュリティ・リストにルールを追加します。 かわりに、これらのルールのカスタム・セキュリティ・リストを作成できます。 次に、デフォルトのセキュリティ・リストとカスタム・セキュリティ・リストの両方を使用するようにサブネットを設定します。

サブネットは、VCNの作成時にルールを含まないデフォルト・ルート表を使用します。 このシナリオでは、表には1つのルールのみがあります: すべての宛先(DRGを介して0.0.0.0/0))を対象としたトラフィックをルーティングします。

このネットワーキング・シナリオを設定するには、次のステップを実行します:

  1. VCNを作成します。

    作業する権限があるコンパートメントを選択します。 VCNに重複しないCIDRブロックを1つ以上指定します。次に例を示します: 172.16.0.0/16。 オプションで、DNSを有効にして、VCNのDNSラベルを指定します。

  2. プライベート・サブネットを作成します。

    たとえば、VCN CIDRブロック内に単一の連続するCIDRブロックを指定: 172.16.10.0/24。 サブネットをプライベートにします。作成するインスタンスはパブリックIPアドレスを取得できません。 デフォルト・ルート表を選択します。 VCNレベルでDNSを有効にした場合、サブネットにホスト名を割り当て、サブネットDNSラベルも指定できます。

  3. デフォルト・セキュリティ・リストを更新します。

    サブネットは、VCNのデフォルト・セキュリティ・リストを使用するように設定します。 次に、VCN内のインスタンスが必要とする接続のタイプを許可するセキュリティ・リスト・ルールを追加します。

    たとえば、サブネットにWindowsインスタンスが含まれ、RDPを使用してインスタンスにアクセスする場合は、次のパラメータを使用して、イングレス・ルールをデフォルト・セキュリティ・リストに追加します:

    • ソース・タイプ: CIDR

    • ソースCIDR: 0.0.0.0/0

    • IPプロトコル: TCP

    • ソース・ポート範囲: すべて

    • 宛先ポート範囲: 3389

  4. 動的ルーティング・ゲートウェイ(DRG)を作成し、それをVCNにアタッチします。

    DRGを作成すると、短期間の「プロビジョニング中」状態になります。 続行する前にプロビジョニングが完了していることを確認してください。 次に、作成したDRGをVCNにアタッチします。 このシナリオでは、拡張添付オプションは無視できます。 DRGアタッチメントは、準備ができるまでしばらく「アタッチ中」状態になります。

    トラフィックがDRGに流れるようにするには、ルート・ルールを追加する必要があります。

  5. DRGを使用するようにデフォルト・ルート表を更新します。

    デフォルトのルート表は、ルールなしで開始されます。 VCN自体でトラフィックをルーティングするために必要なルート・ルールはありません。 オンプレミス・ネットワーク内のアドレス宛てのすべてのトラフィックをDRGにルーティングするルールを追加する必要があります。 次のパラメータを入力します:

    • ターゲット・タイプ: 動的ルーティング・ゲートウェイ。

      VCNにアタッチされたDRGがターゲットとして自動的に選択されます。

    • 宛先CIDRブロック: 0.0.0.0/0

      つまり、ルート表内の他のルールでカバーされていないVCN以外のトラフィックはすべて、このルールで指定されたターゲットに送信されます。

    サブネットはデフォルト・ルート表を使用するように設定されているため、DRGでは、サブネットとオンプレミス・ネットワークのリソース間のトラフィックが有効になります。

  6. インスタンスの作成

    次のステップでは、サブネットに1つ以上のインスタンスを作成します。 各インスタンスは、自動的にプライベートIPアドレスを取得します。 このシナリオでのネットワーク設定では、オンプレミス・ネットワークからインスタンスにアクセスするために追加の構成は必要ありません。

6.7.3 パブリック・サブネットとプライベート・サブネット

この項では、パブリックおよびプライベート・サブネットを持つVCNで構成される単純な多層設定について説明します。 パブリック・サブネットはwebサーバーなどのパブリック・インスタンスを保持し、プライベート・サブネットはデータベース・サーバーなどのプライベート・インスタンスを保持します。 VCNには、オンプレミス・ネットワークに接続するための動的ルーティング・ゲートウェイ(DRG)があります。 パブリック・サブネット内のインスタンスには、インターネット・ゲートウェイを介した外部アクセスがあります。

ノート

パブリック・クラウド環境では、プライベート・サブネット内のインスタンスは、ソフトウェア更新の取得など、NATゲートウェイを使用して外部接続を開始できます。 ただし、Oracle Private Cloud Applianceでは、NATゲートウェイによってオンプレミス・ネットワークへのアクセスが提供され、DRGではこれらのインスタンスに対してすでに有効化されています。 NATゲートウェイとDRGの組合せによって、非決定的なルーティングが原因で問題が発生する可能性があります。

各サブネットは、デフォルトのセキュリティ・リストを使用します。このリストには、簡単に開始できるように設計されたデフォルト・ルールがあります。 ルールにより、一般的な必須アクセス(インバウンドSSH接続や任意のタイプのアウトバウンド接続など)が可能になります。 セキュリティ・リスト・ルールではトラフィックのみが許可されることに注意してください。 セキュリティ・リスト・ルールで明示的にカバーされていないトラフィックは、暗黙的に拒否されます。

また、各サブネットには、サブネット・インスタンスのニーズに固有のルールを含む、独自のカスタム・セキュリティ・リストおよびカスタム・ルート表もあります。 このシナリオでは、開始に常に空であるVCNデフォルト・ルート表は使用されません。

このネットワーキング・シナリオを設定するには、次のステップを実行します:

  1. VCNを作成します。

    作業する権限があるコンパートメントを選択します。 VCNに重複しないCIDRブロックを1つ以上指定します。次に例を示します: 172.16.0.0/16。 オプションで、DNSを有効にして、VCNのDNSラベルを指定します。

  2. 必要なゲートウェイをVCNに追加します。

    パブリック・サブネット内のインスタンスには、受信および送信パブリック・トラフィック用のインターネット・ゲートウェイが必要です。 プライベート・サブネットのインスタンスは、データ・センター・ネットワークとインターネットに接続できるようにNATゲートウェイが必要です。 これらのゲートウェイは、作成時にただちに有効になっていますが、トラフィックが転送されるようにルート・ルールを追加する必要があります。

    オンプレミス・ネットワークからVCNのプライベート・インスタンスにアクセスできるようにするには、DRGを作成してVCNにアタッチします。 DRGを作成すると、短期間の「プロビジョニング中」状態になります。 VCNにアタッチする前に、プロビジョニングが完了していることを確認してください。 このシナリオでは、拡張添付オプションは無視できます。 DRGアタッチメントは、準備ができるまでしばらく「アタッチ中」状態になります。 トラフィックがDRGに流れるようにするには、ルート・ルールも追加する必要があります。

  3. 後で作成するサブネットのカスタム・ルート表を作成します。

    1. パブリック・サブネットの場合は、ルート表を作成し、VCN外部のアドレス宛のすべてのトラフィックをインターネット・ゲートウェイにルーティングするルールを追加します。 次のパラメータを入力します:

      • ターゲット・タイプ: インターネット・ゲートウェイ

      • 宛先CIDRブロック: 0.0.0.0/0

        つまり、ルート表内の他のルールでカバーされていないVCN以外のトラフィックはすべて、このルールで指定されたターゲットに送信されます。

      • ターゲット: 作成したインターネット・ゲートウェイ。

    2. プライベート・サブネットの場合は、ルート表を作成し、2つのルールを追加: オンプレミス・ネットワーク宛のトラフィックをDRGにルーティングし、その他すべてのトラフィックをVCNからNATゲートウェイにルーティングするトラフィック。

      次のパラメータを使用して、NATゲートウェイのルート・ルールを作成します:

      • ターゲット・タイプ: NATゲートウェイ

      • 宛先CIDRブロック: 0.0.0.0/0

        つまり、ルート表内の他のルールでカバーされていないVCN以外のトラフィックはすべて、このルールで指定されたターゲットに送信されます。

      • ターゲット: 作成したNATゲートウェイ。

      次のパラメータを使用して、DRGのルート・ルールを作成します:

      • ターゲット・タイプ: 動的ルーティング・ゲートウェイ。

        VCNにアタッチされたDRGがターゲットとして自動的に選択されます。

      • 宛先CIDRブロック: 10.25.0.0/16

        つまり、オンプレミス・ネットワーク内のアドレスを対象とするトラフィック(10.25.x.y)は、このルールで指定されたDRGターゲットに移動します。

  4. デフォルト・セキュリティ・リストを更新します。

    VCN内のインスタンスが必要とする接続のタイプを許可するセキュリティ・リスト・ルールを追加します。

    ソースCIDRが0.0.0.0/0,ではなく、オンプレミス・ネットワークのCIDRになるように、既存のステートフル・イングレス・ルールをそれぞれ編集します。この例では、: 10.25.0.0/16。

  5. 後で作成するサブネットのカスタム・セキュリティ・リストを作成します。

    1. パブリック・サブネットのカスタム・セキュリティ・リストを作成し、パブリック・インスタンスが必要とする接続のタイプを許可するルールを追加します。 たとえば、webサーバーは、HTTPおよびHTTPSイングレス・トラフィックを受信する必要がある可能性があります。 HTTPの場合は、次の設定を使用します。 HTTPSの場合は、TCPポート443に類似した別の規則を追加します。

      • ソース・タイプ: CIDR

      • ソースCIDR: 0.0.0.0/0

      • IPプロトコル: TCP

      • ソース・ポート範囲: すべて

      • 宛先ポート範囲: 80

    2. プライベート・サブネットのカスタム・セキュリティ・リストを作成し、プライベート・インスタンスが必要とする接続のタイプを許可するルールを追加します。 たとえば、データベース・サーバーは、プライベートおよびパブリック・サブネット内のクライアントからSQL*Net (TCPポート1521)イングレス・トラフィックを受信する必要がある可能性があります。 パブリック・サブネット内のクライアントの場合は、次の設定を使用します。 プライベート・サブネット内のクライアントの場合は、プライベート・サブネットのCIDRに類似したルール(172.16.1.0/24))を追加します。

      • ソース・タイプ: CIDR

      • ソースCIDR: 172.16.2.0/24

      • IPプロトコル: TCP

      • ソース・ポート範囲: すべて

      • 宛先ポート範囲: 1521

  6. VCNにサブネットを作成します。

    • パブリック・サブネット:

      たとえば、VCN CIDRブロック内に単一の連続するCIDRブロックを指定: 172.16.2.0/24。 インスタンスがパブリックIPアドレスを取得できるように、サブネットがパブリック・サブネットであることを確認してください。 以前に作成したカスタム・パブリック・サブネット・ルート表を選択します。

      2つのセキュリティ・リストを選択: デフォルト・セキュリティ・リストと、前に作成したパブリック・サブネット・セキュリティ・リストの両方。 VCNレベルでDNSを有効にした場合、サブネットにホスト名を割り当て、サブネットDNSラベルも指定できます。

    • プライベート・サブネット:

      たとえば、VCN CIDRブロック内に単一の連続するCIDRブロックを指定: 172.16.1.0/24。 サブネットをプライベートにします。このサブネットで作成したインスタンスは、パブリックIPアドレスを取得できません。 以前に作成したカスタム・プライベート・サブネット・ルート表を選択します。

      2つのセキュリティ・リストを選択: 以前に作成したデフォルト・セキュリティ・リストとプライベート・サブネット・セキュリティ・リストの両方。 VCNレベルでDNSを有効にした場合、サブネットにホスト名を割り当て、サブネットDNSラベルも指定できます。

  7. インスタンスの作成

    次のステップでは、サブネットにインスタンスを作成します。 各インスタンスは、自動的にプライベートIPアドレスを取得します。 パブリック・サブネット内のインスタンスごとに、必ずインスタンスにパブリックIPアドレスを割り当てます。 そうしないと、オンプレミス・ネットワークからインスタンスにアクセスできません。 設定したDRGにより、オンプレミス・ネットワークからプライベート・サブネット内のインスタンスに追加の構成なしでアクセスできます。

Copyright © 2013, 2022, Oracle and/or its affiliates.