ビギナー向け「OCIネットワークセキュリティ」入門：OCIのNSGとセキュリティ・リストをAWSと比較してみた

2026.06.17

AWS
Oracle Cloud Infrastructure（OCI）
クラウド

はじめに

こんにちは！クラウド技術部2年目A.Tです。私はIT未経験の状態から、昨年の入社後は主にAWSの基礎的な知識を固めてきましたが、Oracle AI Database@AWSの構築にあたって、OCIの知識がある程度求められるため、OCIに関する基礎知識を学ぶことになりました。

OCI基礎知識の学習を経て、OCIのネットワークセキュリティはAWSと似ているようで、設計思想に大きな違いがあることが分かったので、本記事をまとめるに至っています。

今回は、自分自身の理解を整理する意味も込めて、AWSを経験したことによって違いに気が付いたポイントを中心にまとめてみたいと思います。

1. AWSとOCIの対応表

まずはAWSとOCIについて、簡単に比較していきたいと思います。

OCIの機能の役割をAWSの近しい機能と比較すると、以下のようになります。

制御単位	AWS	OCI
インスタンス（VNIC）単位	セキュリティグループ（SG）	ネットワーク・セキュリティ・グループ (NSG)
サブネット単位	ネットワークACL (NACL)	セキュリティ・リスト (SL)

一見名前が違うだけのように思えますが、ステートフルか否か、また、拒否ルールの有無において、両者には決定的な違いがあります。

2. ステートフルと拒否ルールの決定的な違い

それでは、AWSとOCIの違いについて、こちらの項目で確認していきます。

① 「ステートフル」の概念とOCI独自の判断基準

AWSでは「SG(セキュリティグループ)＝ステートフル」「NACL(ネットワークアクセスコントロールリスト)＝ステートレス」と固定されていますが、OCIのセキュリティ・リストはデフォルトでステートフルになっています。

OCIでステートフルを選択すると、内部の接続トラッキング表に状態が保存されます。インターネットからのアクセスが集中するWebサイトなど、トラフィックが多い場合、この表がいっぱいになるとパケット損失が発生します。高いスループットが求められる場合は、あえてステートレス・ルールを選択し、行き帰り両方のルールを明示的に記述するのがOCIです。

② 「Deny（拒否）」ルールが存在しない

AWSのNACLには、特定のIPを拒否するルールが記載できますが、OCIのNSGおよびセキュリティ・リストには「許可（Allow）」ルールしか存在していません。

→OCIでは、許可リストに記載がない＝拒否という考え方のみで動作します。許可したいもののみを記載し、それ以外はすべて拒否される方式です。 AWSのように、特定の悪意あるIPだけを弾くようなブラックリスト形式の運用ができないため、常に最小限の許可での設計が求められます。

番外編：「ステートレス」って何！？

ちなみに私は、IT未経験の時点で「ステートレス」と言われてもまったくピンときませんでした。本記事に目を通してくださった方が、万が一「ステートレスとは...？」と躓いてしまわないよう、この項目で簡単にご説明します。もちろん知っているよ！という方はさっそく次項[ 3. OCIの「NSG」：主力となる仮想ファイアウォール ]にお進みください！

1.ネットワークにおける「ステートレス」

今回のOCIネットワークセキュリティの文脈における「ステートレス（Stateless）」とは、簡単に例えると「すべてのパケットを初対面として扱う」性格のことです。

ステートフル（状態を保持する）: 「さっき通ったパケットの帰りですね。そのままどうぞ」と、過去の通信を覚えている。

ステートレス（状態を保持しない）: 「通るなら許可証を見せてください。帰りの許可証もちゃんと持ってきてくださいね」と、過去の通信情報を保持しない。

そのため、ステートレスなルール（AWSのNACLや、OCIのステートレス・セキュリティ・リスト）を使う場合は、「行き」と「帰り」の両方のルールを手動で用意しなければなりません。

2.アプリケーション設計における「ステートレス」

一方で、IT用語としての「ステートレス」には別の側面もあります。

AWSにおける「ステートレス」：State（状態）less（ない）の文面通り、アプリケーションやサーバーが、以前の処理結果やクライアントのセッション情報を保持しない設計思想のことを指します。

これは「サーバーがユーザーのログイン状態などを覚えない」というアプリケーションの作り方の話です。

3.なぜあえて「ステートレス」を使うのか？

初めてステートレスについて知ったとき、私は「ステートレスはただ手間が増えるだけなのかな？」と疑問を持ちました。しかし、当然ただ手間が増えるだけなわけではなく、ネットワークにおいてステートレスには大きな武器があります。

「記憶」に頼らない＝速い: ステートフルは裏側で「通信の記憶（接続トラッキング表）」をメモしていますが、アクセスが爆発的に増えると、そのメモ帳がいっぱいになってパンクしてしまいます。その分、ステートレスはメモを一切しないため、メモリを消費せず、大量のアクセスをさばくのが得意であるという点です。

どちらも「状態（State）を持たない（Less）」という点では同じ意味ですが、インフラエンジニアとしては「パケットの往復を覚えない＝ステートレス」という解釈がまず基本になります。

以上で番外編は終わりです。本編に戻ります↓↓↓

3. OCIの「NSG」：主力となる仮想ファイアウォール

OCIのネットワーク・セキュリティ・グループ（NSG）は、AWSのSGと同じような感覚で扱うことができます。

VNICレベルの適用: 仮想ネットワーク・インタフェース・カード（VNIC）に対して直接適用します。1つのVNICは最大5つのNSGに属することができます。

デフォルトでステートフル:インバウンドで通信を許可すれば、戻りのアウトバウンド通信は自動的に許可されます。

柔軟なルール記述:ルールの宛先やソースに「同じVCN内の別のNSG」を直接指定できます。これにより、IPアドレス（CIDR）を意識せず、アプリケーション階層間の通信を直感的に制御できます。

デフォルトでは存在しない: セキュリティ・リストと異なり、VCN作成時に自動生成されるNSGはありません。

現在のOCIでは、サブネット構成とセキュリティ要件を分離して管理できるため、NSGの利用が強く推奨されています。

4. AWSエンジニアが注意すべき点

以上を踏まえて、実務で焦らないための注意点を3つ紹介します。

①デフォルトではPing（ICMP）が通らない！

VCN作成時の「デフォルト・セキュリティ・リスト」には、Ping（ICMPタイプ8）の許可が含まれていません。疎通確認を行うには、手動で許可ルールを追加する必要があります。

②トラブルシューティングの矛先

通信が遮断された際、OCIでは「VNICメトリック」でドロップを確認します。また、クラウド設定が正しくても、インスタンス内のOSファイアウォール（firewalld等）が原因である可能性が非常に高いのも特徴です。

③大容量UDP通信のフラグメンテーション

UDPパケットが大きすぎて断片化されると、2つ目以降のパケットにポート情報が含まれず、ドロップされることがあります。この場合、ポートを「ALL」に設定する対策が必要です。

5. 設計思想のまとめ

最後に、OCI特有の評価ロジックを理解できるようまとめます。

「セキュリティ・リスト」と「NSG」を併用した場合、ルールは「結合（OR条件）」として評価されます。

サブネットに関連付けられたセキュリティ・リスト、またはVNICに関連付けられたNSGのどちらか一方で通信が許可されていれば、その通信は通ります。

注意点:「セキュリティ・リストで絞っているから大丈夫」と思っていても、NSG側で広く許可されていると通信が全開放されてしまいます。

6.最後に

いかがでしょうか。OCIとAWSのネットワークセキュリティは、似ているようで設計思想が大きく異なります。

1. NSGはAWSのSGと同じ感覚で使える。

2. セキュリティ・リストはステートフルだが、高負荷時はステートレスを検討する。

3. OCIには「Denyルール」が存在しないため、ホワイトリスト形式で設計する。

4. Ping許可の追加忘れや、ルールの「結合評価」による意図しない開放に注意する。

これらを正しく理解して、より安全で効率的なOCI環境構築ができることを目指しましょう！

参考・出典

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Security.html

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_stateless.html

https://docs.oracle.com/ja-jp/iaas/Content/Network/Concepts/permissions.htm

https://docs.oracle.com/ja-jp/iaas/Content/Network/Concepts/networksecuritygroups.htm

https://docs.oracle.com/ja-jp/iaas/Content/Network/Concepts/securityrules.htm

ブログ一覧へ戻る

RELATED SERVICES関連サービス

クラウドサービス

GCP、 AWS、Azure、OCIのクラウドを中心にインフラ基盤を構築します。
また、SRE技術支援、コンテナ技術支援、ガバメントクラウド移行支援などクラウド環境で必要となる技術支援をいたします。

Careersキャリア採用

キャリア採用募集職種

ステップアップのために環境をかえることをお考えですか？
でしたら、ぜひこちらをご覧下さい。技術領域別説明会やカジュアルWeb面談など、ご状況にあった方法をご案内させて頂きます。

キャリア・ストーリー

社員のキャリアップ・ストーリーを掲載しています。
一人一人の志向にあわせたキャリア形成をプロジェクト、研修、国内外のイベント等を通してサポートしています。あなたはどのようにステップアップしたいですか？

この記事をシェアする

資料請求・お問い合わせはこちら

TECH BLOG