はじめに
こんにちは！クラウド事業部の中根です。
OCIのセキュリティ・リストとネットワーク・セキュリティ・グループについて学んだ時に、AWSと同じ考え方でいると重大な事故が起こり得ると感じました。
今回は、OCIのセキュリティ・リストとネットワーク・セキュリティ・グループを実際に使って、AWSとの動作の違いを確認してみました。
AWS経験者でOCIを学習している方の参考になれば幸いです。
OCIとAWSの違い
AWS経験者がOCIを学ぶと、以下のように用語が対応していると考えるのではないでしょうか。
- サブネット単位のファイアウォール
セキュリティ・リスト(OCI) ≒ NACL(AWS) - インスタンスなどリソース単位のファイアウォール
ネットワーク・セキュリティ・グループ(OCI) ≒ セキュリティグループ(AWS)
注意すべき点
AWSの場合、NACLとセキュリティグループ両方のルールを満たさないと通信ができません。（参考）
しかしOCIの場合、セキュリティ・リストまたはネットワーク・セキュリティ・グループのどちらかで許可されていれば通信が可能になります。
OCIは和集合、AWSは積集合と考えておくとわかりやすいかもしれません。
デフォルトのNACLはインバウンド、アウトバウンド両方全許可になっています。（参考）
そして、デフォルトのセキュリティグループでは、同じセキュリティグループからの全てのインバウンド通信を許可し、アウトバウンドは全許可です。（参考）
仮にOCIで同じように設定してしまうと、ネットワーク・セキュリティ・グループでどんなに制御しても全ての通信が筒抜けになってしまいます！
ちなみに、デフォルトのセキュリティ・リストでは、SSH通信とICMPのタイプ3,4が許可されています。（参考）
そしてデフォルトのネットワーク・セキュリティ・グループはないため、何も許可していないです。（参考）
どう使えばいい？
OCIでは基本的にネットワーク・セキュリティ・グループを使うことが推奨されています。（参考）
ここはAWSと同じですね！
検証
ここからはおまけみたいなものです。
OCIで実際に試してみました。
検証環境
構成は以下の通りです。
Bastion(要塞)による接続に少し苦戦したのですが、こちらが非常に参考になりました！
おすすめです。
各インスタンスのIPアドレスは以下です。
検証前の状態
まずはinstance-1からinstance-2に接続ができるか確認してみましょう。
デフォルトのセキュリティ・リストが作成されているだけでネットワーク・セキュリティ・グループもないので、pingを許可するルールがなく通らないはずです。
やってみると、予想通りpingはタイムアウトしました。
ちなみに、同じVCN内のサブネット間通信は、VCNローカル・ルーティングによってルート表になくても処理されます。（参考）
検証①: セキュリティ・リストの変更
プライベートサブネット1からのICMP通信を受け付けるルールを持つセキュリティ・リストを作成しました。
これをプライベートサブネット2に追加します。
pingが通ることが確認できました！
検証②に進む前に、追加したセキュリティ・リストは削除して、pingが再び通らなくなることを確認します。
検証②: ネットワーク・セキュリティ・グループの変更
プライベートサブネット1からのICMP通信を受け付けるルールを持つネットワーク・セキュリティ・グループを作成しました。
これをinstance-2に追加します。
ちなみにデフォルトではなしになっていました。
pingが通ることが確認できました！
まとめ
AWS経験者が必ず覚えておきたいネットワークアクセス制御の考え方についてご紹介しました！
大事故にならないように肝に銘じておきましょう！
- OCIは和集合、AWSは積集合
- 基本的にネットワーク・セキュリティ・グループを使う
おわりに
私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
