COLUMN

セキュリティグループとNACLの基本的な仕様、違い

まずは、セキュリティグループとNACLの基本的な仕様についておさらいしていきたいと思います。すでにご存じの方は読み飛ばしていただいて構いません。

セキュリティグループ

セキュリティグループの基本的な仕様についておさらいします。

• セキュリティグループは、関連付けられたリソースの通信制御を行います。
• 複数のリソースに関連付けることも可能です。
• 送信先（アウトバウンドルールの場合）送信元（インバウンドルールの場合）およびポートを指定します。
• ホワイトリスト型で、拒否ルールを設定することはできません。
• インバウンド（外部のリソースから関連付けたリソース）方向と、アウトバウンド（関連付けたリソースから外部のリソース）方向の二つで設定が可能です。
• すべてのルールを評価して通信許可を行いますので、ルールにない通信は拒否されます。
• ステートフル型になりますので、戻りの通信に対して明示的に許可を出す必要はありません。
• 複数のVPCでセキュリティグループを共有することもできます。（2024年アップデート）

図で示すと、このような形になります。

NACL

• NACLはサブネットに関連付けします。デフォルトでは、すべてのトラフィックが許可されます。
• サブネットに割り当てられたすべてのインスタンスにルールが適用されます。
• セキュリティグループと違い、拒否ルールを作ることもできます。
• インバウンド（外部のリソースから関連付けたサブネット）方向と、アウトバウンド（関連付けたサブネットから外部のリソース）方向の二つで設定が可能です。
• NACLルールは1から32,766までの番号が設定され、低い番号のルールから評価されます。トラフィックがルールに一致すると、そのルールが適用され追加のルールは評価されません。
• NACLルールに一つも一致しなかった場合は、トラフィックが拒否されます（暗黙の拒否）。
• NACLルールはトラフィックがサブネット内でルーティングされる時ではなく、サブネットに出入りするときに評価されます。
• ステートレスのため、送信先・送信元でそれぞれ使うIPアドレス、ポート、プロトコルについて許可・拒否を設定する必要があります。
• NACLはRoute 53 Resolverで送受信されるDNSリクエストをフィルターすることはできません。DNSリクエストをフィルターする際はRoute 53 Resolver DNS Firewallを使用します。

• その他、NACLは以下の送受信されるトラフィックをフィルターすることはできません。

  • Amazon DNS
  • Amazon DHCP
  • Amazon EC2 インスタンスメタデータ
  • Amazon ECS タスクメタデータエンドポイント
  • Windows インスタンスのライセンスアクティベーション
  • Amazon Time Sync Service (NTPサービス)
  • VPCルータによる予約済みIPアドレス

図で示すと、このような形になります。

セキュリティグループとNACLの比較

セキュリティグループとNACLを表で比較すると、このような形になります。

Amazon VPCのネットワーク設計に関するお悩みやご相談などNTT東日本のクラウドエンジニアがお応えします。ぜひお気軽にご相談ください。

Well-Architected Frameworkのセキュリティの観点におけるセキュリティグループとNACLのポイント

では、セキュリティグループとNACLを利用して、Well-Architected Frameworkのどの部分に寄与することができるかを考えてみます。セキュリティグループとNACLは、執筆日時点ではWell-Architected Frameworkの「セキュリティの柱」にある下記の二つに寄与することができます。

SEC05-BP01 ネットワークレイヤーを作成する

ワークロードコンポーネントをそのデータの機密度とアクセス要件に応じて論理的にグループ化し、そのグループに基づいてネットワークトポロジをさまざまなレイヤーに分割します。インターネットからのインバウンドアクセスを必要とするコンポーネント (公開ウェブエンドポイントなど) と、内部アクセスのみを必要とするコンポーネント (データベースなど) は区別します。

期待される成果:ネットワークのレイヤーは、ワークロードにおける ID の認証と認可の戦略を補完する多層防御セキュリティアプローチに不可欠な部分です。データの機密度とアクセス要件に応じてレイヤーが配置され、トラフィックフローと統制のメカニズムが適切に機能しています。

出典:SEC05-BP01 ネットワークレイヤーを作成する - セキュリティの柱

SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する

ネットワークのレイヤー内でさらにセグメンテーションを行い、各ワークロードに必要なフローのみにトラフィックを制限します。まず、インターネットや他の外部システムからワークロードや環境へのトラフィック (North-South トラフィック) の制御に着目します。その後、さまざまなコンポーネントとシステム間のフロー (East-West トラフィック) を確認します。

期待される成果:ワークロードのコンポーネントが相互通信や、クライアントや依存先のその他のサービスとの通信に必要とするネットワークフローのみを許可します。設計では、パブリックとプライベートの送受信、データ分類、地域の規制、プロトコル要件などが考慮されます。可能な限り、最小特権の原則に基づく設計の一環として、ネットワークピアリングよりもポイントツーポイントフローを優先します。

出典:SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する - セキュリティの柱

セキュリティグループとNACLは、このうちOSI参照モデルのレイヤー3及びレイヤー4のネットワークレイヤーとトラフィックフローの制御を提供します。最小権限の原則に従い、必要なプロトコルや送信先・送信元に制限することを、リソース・ネットワーク双方で行う必要があります。

冒頭でセキュリティグループのみを使用しているという話もありましたが、万が一セキュリティグループの設定が漏れていたり、意図しないIPアドレス範囲やプロトコルを許可していたりした場合でも、NACLが適切に設定されていれば防ぐこともできますし、逆もしかりです。このように情報セキュリティの観点では双方を設定することが必要になってきます。

Amazon VPCのネットワーク設計に関するお悩みやご相談などNTT東日本のクラウドエンジニアがお応えします。ぜひお気軽にご相談ください。

セキュリティグループとNACL利用のベストプラクティス

前置きが長くなりましたがここからが本題です。実際に、どのようにセキュリティグループとNACLを併用していけばよいのでしょうか。こちらのベストプラクティスを検討したいと思います。

① Webサーバー、データベースなど、役割ごとにサブネットを分割する

これがNACLを活用するための基本的なポイントになります。複数の役割が混在したサブネットにおいては、例えばWebサーバーにデータベースのプロトコルの通信が許可されてしまうなどといったことが起きえます。したがってまずは役割ごとにサブネットを分割することをおすすめします。

サブネットを分割するのは情報セキュリティの観点だけではなく、リソース管理の観点でも優れています。

例えば、アプリケーションサーバーとデータベースが混在するサブネットにおいて、どちらか一方の負荷が上昇しスケールした結果IPアドレスが枯渇した場合、もう一方のリソースを増やすことができなくなります。これにより、一つの役割のサーバーの問題が他のサーバーの問題に波及することにもなり、可用性の観点であまりよくない状況といえます。

② サブネットとNACLの命名規則やタグをそろえる

簡単なことですが、サブネットの役割とNACLの命名規則やタグをそろえておきます。

例えば、サブネットAPServer_Subnetに対応するNACLはAPServer_NACLにするなどです。何の役割を持っているか、名前やタグで揃えておくことで、誤ったNACLの設定変更によるトラブルなどを回避することができます。

③ 一つのNACLに多数のルールを入れすぎない

ルールが足りないのは問題ですが、多数のルール設定によって不要な通信の許可を引き起こしている可能性があります。一つの役割に対しては、一つの役割に必要なルール数にします。基本的にはシンプルなルール設定を心がけましょう。

例えば、Webサーバーが配置されたサブネットであればインバウンドはHTTP/HTTPSと戻りの通信のみ、アウトバウンドはアプリケーションサーバーが使うプロトコルと戻りの通信のみ、といった設定にします。

④ AWSのマネージドリソースと通信やインターネット上のリソースと通信を行うサブネットにおいて、IPアドレス範囲の特定が難しい場合は最低限プロトコルのみを許可する

AWSのマネージドリソースや、インターネット上のリソースと通信を行う必要がある場合もあり、その場合はIPアドレス範囲の特定が難しい場合もあります。その際もデフォルトであるすべての許可を入れるのではなく、タイプやポートの指定だけでも行っておきましょう。

セキュリティグループとNACLの設定のアンチパターン

セキュリティグループとNACL設定のアンチパターンもあります。例えば、このようなものです。

① VPC内部の通信をすべて許可している

VPCの内部はプライベートだからと言って、内部の通信をすべて許可してしまうのはアンチパターンとなります。仮にVPC内部のリソース一つが侵害された場合、すべてのリソースに影響する可能性があります。場合によってはVPCを分けてしまうのも一つの手になります。

② 受信トラフィックと送信トラフィックのいずれかに制御を適用し、両方に適用はしていない

よくあるのが、インバウンドルールは適用するものの、アウトバウンドルールは適用しない、という構成です。

インバウンド通信で万が一侵害された後、侵害を受けたリソースが加害者になることになります。影響を最低限にするため、アウトバウンドルールも決めておくことをおすすめします。

このように、ベストプラクティスとアンチパターンを踏まえて、最適なセキュリティグループとNACLを決めていきますが、これら二つを設定したことによるトラブルも起こりえます。次にそれを見ていきましょう。

セキュリティグループとNACLに起因するトラブルシューティング

セキュリティグループに起因するトラブルとして、「接続ができない・タイムアウトする」があります。余談ですが、昔ルーターの設定を遠隔で行っていた際、ルーターのアクセスリストの設定を誤り、現地まで駆けつけることになったこともありました。

AWSだとデータセンターまで駆けつけることはありませんが、セキュリティグループおよびNACLのインバウンドルール、アウトバウンドルールを正しく設定されているか確認することになりますが、目視での確認は大変です。ここでは、2つのトラブルシューティングツールをご紹介します。

① VPC Reachability Analyzer

マネジメントコンソールベースで対応できる分析ツールとなります。送信先・送信元およびプロトコルを指定し、調査することができます。

たとえば、途中経路にアウトバウンド通信をすべて拒否したNACLがある場合、プライベートサブネットのインスタンスからインターネットゲートウェイまでの経路調査はこのように表示されます。

この結果からNACLで拒否されていることがわかります。

② AWSSupport-ConnectivityTroubleshooter

もうひとつ、こちらのツールをご紹介します。Systems Manager Automation Runbookのツールで、二つのIPアドレス間の到達性を確認することができます。VPC Reachability Analyzerとの違いは、マルチアカウントやマルチリージョンでも使えることやインターネットのリソースも調査できるなど、細かい条件を指定することができます。また、AWS CLIでも実行できることです。

先ほどと同じ条件でインスタンスから今度はNATゲートウェイのElastic IPアドレスまでのトラブルシュートを実行すると、evalNatNaclsで失敗しています。

詳細を確認すると、指定のサブネットのNACLアウトバウンドルールで許可されていないことがわかります。

このメッセージをもとに、NACLのアウトバウンドルールの許可を入れていきます。

そのほかにもエラー率の閾値での成否の判断や、VPC間接続のトラブルシューティングなども行うことができます。詳細のドキュメントはこちらもご覧ください。

AWSSupport-ConnectivityTroubleshooter - AWS Systems Manager オートメーションランブックリファレンス

まとめ

今回はセキュリティグループとNACLのベストプラクティスおよび、トラブルシューティングを見てきました。通信制御は古くからある仕組みですが、設定一つで大きなトラブルを起こすこともあるので、慎重な設計と実装を行うことが必要です。

NTT東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供をおこなっております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

Amazon VPCのネットワーク設計に関するお悩みやご相談などNTT東日本のクラウドエンジニアがお応えします。ぜひお気軽にご相談ください。