Oracle Cloud Infrastructureドキュメント

セキュリティ・リスト

IAMポリシーを使用して、VCNを操作できるユーザーを制御する(たとえば、インターネット・ゲートウェイ、ルート表ルールの変更)以外に、「セキュリティ・リスト」を使用してパケット・レベルのトラフィックを制御できます。

警告

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用してクラウド・リソースに説明、タグまたはわかりやすい名前を割り当てるときは、機密情報を入力しないでください。

セキュリティ・リストの概要

セキュリティ・リストは、インスタンスに対して仮想ファイアウォールを提供します。イングレスおよびエグレス・ルールは、入出力を許可するトラフィックのタイプを指定します。 各セキュリティ・リストは、インスタンス・レベルで適用されます。 ただし、セキュリティ・リスト「サブネット・レベルで」を構成します。これは、特定のサブネット内のすべてのインスタンスが同じルール・セットの対象であることを意味します。 セキュリティ・リストは、VCN内の別のインスタンスまたはVCN外のホストと話しているかどうかにかかわらず、特定のインスタンスに適用されます。

各サブネットには複数のセキュリティ・リストが関連付けられており、各リストには複数のルールを設定できます(最大数については「サービス制限」を参照)。 「リストのいずれかのルール」がトラフィックを許可する場合(またはトラフィックがトラッキングされている既存の接続の一部である場合)、問題のパケットが許可されます。 リストに、同じトラフィックをカバーするステートフルとステートレスの両方のルールが含まれている場合は注意が必要です。 詳細については、「ステートフル・ルールとステートレス・ルール」を参照してください。

重要

Oracle提供のLinuxイメージまたはWindowsイメージを実行しているインスタンスには、インスタンスへのアクセスを制御するファイアウォール・ルールもあります。 インスタンスへのアクセスをトラブルシューティングするときは、インスタンス・サブネットに関連付けられたセキュリティ・リストとインスタンス・ファイアウォール・ルールの両方が正しく設定されていることを確認してください。 詳細は、「Oracle提供イメージ」を参照してください。

インスタンスがOracle Linux 7を実行している場合、firewalldを使用してiptablesルールと対話する必要があります。 参考までに、ポートを開くためのコマンドを以下に示します(この例では1521):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

セキュリティ・リストはリージョン・エンティティです。 VCNに含めることができるセキュリティ・リストの数の制限については、「サービス制限」を参照してください。

ノート

セキュリティ・リストは、iSCSIやインスタンス・メタデータなどのサービスを含む、169.254.0.0/16 CIDRブロックを含むトラフィックでは施行されません。

ステートフル・ルールとステートレス・ルール

セキュリティ・リスト・ルールを作成するときは、statefulまたはstatelessのいずれかを選択します。 その違いを以下に説明します。 デフォルトはステートフルです。 大量のインターネット対応Webサイト(HTTP/HTTPSトラフィック用)を使用している場合は、ステートレス・ルールが推奨されます。

ステートフル・ルール

セキュリティ・リスト・ルールをステートフルとしてマークすることは、そのルールに一致するトラフィック(セキュリティ・リストが関連付けられているサブネット内のインスタンス用)の接続トラッキングを使用することを示します。 これは、インスタンスがステートフルなイングレス・ルールに一致するトラフィックを受信すると、そのインスタンスに適用可能なエグレス・ルールに関係なく、レスポンスが追跡され、自動的に元のホストに戻されることを意味します。 また、インスタンスがステートフルなエグレス・ルールに一致するトラフィックを送信すると、イングレス・ルールに関係なく、着信レスポンスが自動的に許可されます。 詳細は、「ステートフル・ルールの接続トラッキングの詳細」を参照してください。

次の図は、HTTPトラフィックを受信して応答する必要があるインスタンスのステートフルなイングレス・ルールを示しています。 インスタンスAとホストBは通信しています(ホストBはインスタンスであろうとなかろうと、どのホストでもかまいません)。 ステートフルなイングレス・ルールは、任意の送信元IPアドレス(0.0.0.0/0)から宛先ポート80のみ(TCPプロトコル)へのトラフィックを許可します。 レスポンス・トラフィックを許可するには、エグレス・ルールは必要ありません。

着信HTTPトラフィックとレスポンスを許可するステートフルなイングレス・ルール

ステートレス・ルール

セキュリティ・リスト・ルールをステートレスとしてマークすることは、そのルールに一致するトラフィック(セキュリティ・リストが関連付けられているサブネット内のインスタンス)の接続トラッキングを使用しないことを示します。 つまり、レスポンス・トラフィックは自動的に許可されません。 ステートレス・イングレス・ルールのレスポンス・トラフィックを許可するには、対応するステートレス・エグレス・ルールを作成する必要があります。

次の図は、以前のようにインスタンスAとホストBを示していますが、現在ではステートレス・セキュリティ・リストのルールを使用しています。 上記のステートフル・ルールの場合と同様に、ステートレス・イングレス・ルールは、(TCPプロトコルを使用して)宛先ポート80上のすべてのIPアドレスおよび任意のポートからのトラフィックを許可します。 レスポンス・トラフィックを許可するには、宛先ポート番号(0.0.0.0/0)および任意のポート(TCPプロトコルを使用)からの送信元ポート80へのトラフィックのみを許可する、対応するステートレス・エグレス・ルールが必要です。

着信HTTPトラフィックおよびレスポンスを許可するステートレスのイングレスおよびエグレス・ルール

インスタンスAがHTTPトラフィックをinitiateする代わりにレスポンスを取得する必要がある場合は、別のステートレス・ルール・セットが必要です。 次の図に示すように、エグレス・ルールには送信元ポート= allと宛先ポート= 80 (HTTP)があります。 イングレス・ルールには、送信元ポート80と宛先ポート= allがあります。

インスタンスがHTTPトラフィックを開始してレスポンスを得ることを可能にするステートレスのイングレスおよびエグレス・ルール

インスタンスAでポート・バインディングを使用してHTTPトラフィックがどのポートから来るのかを正確に指定する場合は、エグレス・ルールの送信元ポートとイングレス・ルールの宛先ポートとして指定できます。

ノート

何らかの理由でセキュリティ・リストにステートフル・ルールとステートレス・ルールの両方が含まれていて、特定の方向(たとえばイングレス)でステートフル・ルールとステートレス・ルールの両方に一致するトラフィックがある場合は、ステートレス・ルールが優先され、接続は追跡されません。 レスポンス・トラフィックを許可するには、他の方向に対応するルール(たとえば、エグレス、ステートレスまたはステートフル)が必要です。

ステートレス・ルールのPath MTU Discoveryメッセージの使用可能化

VCN以外のエンドポイントからのトラフィックを許可するためにステートレス・セキュリティ・リスト・ルールを使用する場合は、イングレスICMPトラフィック・タイプ3コード4を送信元0.0.0.0/0および送信元ポートから許可するセキュリティ・リスト・ルールを追加することが重要です。 このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。 このルールは、インスタンスへの接続を確立するために重要です。 それがなければ、接続の問題を経験することができます。 詳細は、「ハンギング接続」を参照してください。

デフォルト・セキュリティ・リスト

各クラウド・ネットワークには「デフォルト・セキュリティ・リスト」があります。 サブネットの作成中に1つ以上の他のセキュリティ・リストを指定しないと、特定のサブネットに関連付けられているデフォルトのセキュリティ・リストが自動的に設定されます。 サブネットを作成した後は、いつでもそれに関連付けるセキュリティ・リストを変更できます。 また、リスト内のルールを変更できます。

他のセキュリティ・リストとは異なり、デフォルトのセキュリティ・リストには、最初に変更されるステートフル・ルール・セットが付属しています:

  • ステートフルなイングレス: ソース0.0.0.0/0および任意の送信元ポートからの宛先ポート22 (SSH)上のTCPトラフィックを許可します。 このルールにより、新しいクラウド・ネットワークとパブリック・サブネットを作成し、Linuxインスタンスを起動し、セキュリティ・リストのルールを自分で作成することなく、すぐにSSH経由でそのインスタンスに接続することができます。

    重要

    デフォルトのセキュリティ・リストには、リモート・デスクトップ・プロトコル(RDP)アクセスを許可するルールは含まれていません。 「Windowsイメージ」を使用している場合は、宛先ポート3389のTCPトラフィック用のステートフルなイングレス・ルールをソース0.0.0.0/0および任意の送信元ポートから追加してください。

    詳細については、「RDPアクセスを有効にするには」を参照してください。

  • ステートフルなイングレス: ICMPトラフィック・タイプ3コード4をソース0.0.0.0/0から許可します。 このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。

  • ステートフルなイングレス: source = VCN CDIRからのICMPトラフィック・タイプ3(すべてのコード)。 このルールは、インスタンスがVCN内の他のインスタンスから接続エラー・メッセージを受信するのを容易にします。
  • ステートフルなエグレス:すべてのトラフィックを許可します。 これにより、インスタンスは任意の種類のトラフィックを任意の宛先に送信できます。 これは、パブリックIPアドレスを持つインスタンスが、VCNにインターネット・ゲートウェイが構成されている場合に、すべてのインターネットIPアドレスと通信できることを意味します。 また、ステートフル・セキュリティ・ルールでは接続トラッキングが使用されるため、レスポンス・トラフィックはイングレス・ルールに関係なく自動的に許可されます。 詳細は、「ステートフル・ルールの接続トラッキングの詳細」を参照してください。

デフォルトのセキュリティ・リストには、ステートレス・ルールはありません。 ただし、必要に応じて、デフォルトのセキュリティ・リストにルールを追加または削除することができます。

Pingの有効化

デフォルトのセキュリティ・リストには、pingリクエストを許可するルールが含まれていません。 インスタンスをpingする場合は、インスタンスのセキュリティ・リストにadditionalステートフル小さい小さい小さい小さい小さい小さい小さい小さいルールが含まれていることを確認して、pingを行う予定のソース・ネットワークからICMPトラフィック・タイプ8を具体的に有効にします。 インターネットからのpingアクセスを許可する場合は、ソースに対して0.0.0.0/0を使用します。 このpingのルールはデフォルト・セキュリティ・リストのデフォルトのICMP関連のルールとは別のものです。 これらのルールは削除しないでください。

セキュリティ・リスト・ルールの一部

各セキュリティ・リストには1つ以上のルールを含めることができ、各ルールにはイングレス・トラフィックまたはエグレス・トラフィックのどちらかが優先されます。 ルールがステートフルかステートレスかを選択します。 ルールの例は、「ステートフル・ルールとステートレス・ルール」を参照してください。「Networkingシナリオ」を参照してください。 セキュリティ・リストに含めることができるルールの数の制限については、「サービス制限」を参照してください。

各イングレス・ルールは、次の項目を指定します:

  • ステートフルまたはステートレス:ステートフルの場合、ルールに一致するトラフィックに接続トラッキングが使用されます。 ステートレスの場合、接続トラッキングは使用されません。 「ステートフル・ルールとステートレス・ルール」を参照してください。
  • ソースのタイプ:可能な値:
  • ソースCIDR: ソースのタイプCIDRの場合のみ(典型的な選択)。 ソースCIDRは、トラフィックの発生元であるCIDRブロックです。 すべてのIPアドレスを示すには、0.0.0.0/0を使用します。 プレフィクスは必須です(たとえば、個々のIPアドレスを指定する場合は /32を含めます)。
  • ソース・サービス: ソースのタイプサービスCIDRの場合のみ(つまり、Oracleサービスからサービス・ゲートウェイを介してトラフィックが取得されます)。 ソース・サービスは、必要な「サービスCIDRラベル」です。
  • IPプロトコル:すべてのプロトコルをカバーする単一のIPv4プロトコルまたはall。
  • ソース・ポート:トラフィックが発生したポート。 TCPまたはUDPの場合は、すべての送信元ポートを指定するか、オプションで単一の送信元「ポート番号」または範囲を指定することができます。
  • 宛先ポート:トラフィックの宛先ポート。 TCPまたはUDPの場合、すべての宛先ポートを指定するか、オプションで単一の宛先「ポート番号」または範囲を指定することができます。
  • ICMPタイプとコード: ICMPの場合は、すべてのタイプとコードを指定するか、オプションで単一のtypeをオプションのコードで指定することができます。 タイプに複数のコードがある場合は、許可するコードごとに個別のルールを作成します。

各エグレス・ルールは、以下を指定します:

  • ステートフルまたはステートレス:ルールに一致するトラフィックに接続トラッキングを使用するかどうか。 「ステートフル・ルールとステートレス・ルール」を参照してください。
  • 宛先タイプ:可能な値:
  • 宛先CIDR: 宛先タイプCIDRの場合のみ(一般的な選択)。宛先CIDRは、トラフィックの宛先であるCIDRブロックです。 すべてのIPアドレスを示すには、0.0.0.0/0を使用します。 プレフィクスは必須です(たとえば、個々のIPアドレスを指定する場合は /32を含めます)。
  • 行き先サービス: DestinationTypeサービスCIDRの場合のみ(つまり、トラフィックがサービス・ゲートウェイを通じてOracleサービスに渡されることを意味します)。 宛先サービスは、必要な「サービスCIDRラベル」です。
  • IPプロトコル:すべてのプロトコルをカバーする単一のIPv4プロトコルまたはall。
  • ソース・ポート:トラフィックが発生したポート。 TCPまたはUDPの場合は、すべての送信元ポートを指定するか、オプションで単一の送信元「ポート番号」または範囲を指定することができます。
  • 宛先ポート:トラフィックの宛先ポート。 TCPまたはUDPの場合、すべての宛先ポートを指定するか、オプションで単一の宛先「ポート番号」または範囲を指定することができます。
  • ICMPタイプとコード: ICMPの場合は、すべてのタイプとコードを指定するか、オプションで単一のtypeをオプションのコードで指定することができます。 タイプに複数のコードがある場合は、許可するコードごとに個別のルールを作成します。

セキュリティ・リストとルールの操作方法については、以降のセクションを参照してください。

ステートフル・ルールの接続トラッキングの詳細

Oracleは接続トラッキングを使用して、ステートフル・ルールに一致するトラフィックに対するレスポンスを許可します(「ステートフル・ルールとステートレス・ルール」を参照)。 各インスタンスには、インスタンス・シェイプに基づいて追跡できる同時接続の最大数があります。

TCP、UDP、およびICMPのレスポンス・トラフィックを判別するために、Oracleは次のアイテムについてパケットの接続トラッキングを実行します:

  • プロトコル
  • 送信元および宛先IPアドレス
  • 送信元ポートと宛先ポート(TCPとUDPのみ)
ノート

他のプロトコルの場合、OracleではプロトコルとIPアドレスのみが追跡され、ポートは追跡されません。 これは、インスタンスが別のホストへのトラフィックを開始し、そのトラフィックがエグレス・セキュリティ・リスト・ルールによって許可された場合、インスタンスがそのホストからその後一定期間受信するトラフィックはレスポンス・トラフィックとみなされ、許可されることを意味します。

断片化されたUDPパケットを処理するルール

インスタンスはUDPトラフィックを送受信できます。 UDPパケットが接続には大きすぎると、フラグメント化されます。 ただし、パケットの最初のフラグメントだけがプロトコルとポート情報を含んでいます。 このイングレス・トラフィックまたはエグレス・トラフィックが特定のポート番号(送信元または送信先)を指定するセキュリティ・リストのルールの場合、最初のもの以降のフラグメントは破棄されます。 インスタンスで大きなUDPパケットを送受信することが予想される場合は、該当するセキュリティ・リスト・ルールの送信元ポートと宛先ポートの両方をALL (特定のポート番号ではなく)に設定します。

必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者が作成するポリシーで、コンソールまたはSDK、CLIまたはその他のツールを使用したREST APIのどちらを使用しているかにかかわらず、必要なタイプのアクセスを付与する必要があります。 アクションを実行しようとしたときに、権限のないメッセージや権限のないメッセージを取得する場合は、管理者に付与されているアクセスのタイプと作業するコンパートメントを確認してください。

管理者向け: 「ネットワーク管理者がクラウド・ネットワークを管理できるようにします」のポリシーは、セキュリティ・リストを含むすべてのNetworkingコンポーネントの管理を対象としています。

Networkingのセキュリティ・リストを管理する必要があるが、他のコンポーネントは管理しないセキュリティ管理者がいる場合は、より限定的なポリシーを書くことができます:

Allow group SecListAdmins to manage security-lists in tenancy

Allow group SecListAdmins to manage vcns in tenancy

両方のステートメントは、セキュリティ・リストの作成がセキュリティ・リストが入っているVCNに影響するため、必要です。 2番目のステートメントでは、SecListAdminsグループで新しいVCNを作成できますが、セキュリティ・リスト以外のサブネットを作成したり、これらのVCNに関連する他のコンポーネントを管理したりすることはできません。 また、すでにサブネットがある既存のVCNを削除することはできません。

詳細は、「NetworkingのIAMポリシー」を参照してください。

セキュリティ・リストの操作

新しいサブネットを作成するときは、少なくとも1つのセキュリティ・リストを関連付ける必要があります。 クラウド・ネットワークのデフォルト・セキュリティ・リストか、作成した1つ以上の他のセキュリティ・リスト(最大数については、「サービス制限」を参照)のいずれかになります。 「サブネットが使用するセキュリティ一覧を変更する」はいつでも利用できます。

オプションで、作成中にセキュリティ・リストにフレンドリ名を割り当てることができます。 ユニークである必要はなく、後で変更することもできます。 Oracleでは、Oracle Cloud ID (OCID)という一意の識別子がセキュリティ・リストに自動的に割り当てられます。 詳細は、「リソース識別子」を参照してください。

アクセス制御の目的で、セキュリティ・リストを配置するコンパートメントを指定する必要があります。 使用するコンパートメントがわからない場合は、組織の管理者に相談してください。 詳細は、「アクセス制御」を参照してください。

セキュリティ・リストからルールを追加および削除できますが、APIでセキュリティ・リストを更新すると、新しいルールセットが既存のルールセット全体を置き換えることに注意してください。

セキュリティ・リストを削除するには、それをまだサブネットに関連付けることはできません。 クラウド・ネットワークのデフォルト・セキュリティ・リストは削除できません。

リソースのタギング

リソースにタグを適用して、ビジネス・ニーズに合わせてタグを整理するのに役立てることができます。 リソースを作成するときにタグを適用することも、後でそのタグを使用してリソースを更新することもできます。 タグの適用に関する一般的な情報は、「リソース・タグ」を参照してください。

コンソールを使用した場合

クラウド・ネットワークのデフォルト・セキュリティ・リストを表示するには
既存のセキュリティ・リスト内のルールを更新するには
新しいセキュリティ・リストを作成するには
サブネットが使用するセキュリティ・リストを変更するには
セキュリティ・リストを削除するには
セキュリティ・リストのタグを管理するには

APIの使用

APIおよび署名リクエストの使用については、REST APIおよび「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

VCNセキュリティ・リストを管理するには、次の操作を使用します:

このトピックは移動しました。2秒後にリダイレクトされない場合は、次のリンクをクリックしてください: セキュリティ・リスト。