AWSでUbuntuEC2インスタンスを実行しています。セキュリティグループを使用する代わりに、常にネットワークACLを使用してポート22へのアクセスを制御してきました。
質問1:単一のEC2インスタンスのユースケースの場合、アクセス制御にNACLとSGを使用することの長所と短所はありますか?(ステートフルとステートレス、およびAWS VPCセキュリティドキュメントの他の違いに加えて。)
質問2:大規模な環境ではこれをどのように処理しますか?ベストプラクティスはありますか?(ある大企業がNACLを完全に開いており、SGですべてを管理していることを私は知っています。)
答えを見つけるために最初にしたことは、AWSのVPCセキュリティドキュメントを読むことでした:https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html
私のユースケースでは、アクセス制御のためのいくつかの方法があります。
オプション1:ポート80、443、およびエフェメラルポートへのNACL入力を0.0.0.0/0に制限します。IPアドレスごとにポート22アクセスを追加します。他のすべてのトラフィックを拒否します。(これは私がいつも行っていることです。)プライベートサブネットインスタンスが必要な場合は、SG経由のプライベートサブネットをパブリックサブネットの内部CIDRに制限します。
オプション2:NACLを世界に向けて開き、EC2インスタンスへのアクセス制御にSGを使用します。
オプション3:冗長にし、両方を使用します。
新しい場所(喫茶店)に行き、自分のインスタンスにSSHで接続したい場合は、AWSコンソールにログインし、新しいNACLルールを追加してIPアドレスポート22へのアクセスを許可します。NACLとSGの両方にルールを追加することは、マウスのクリックと入力の量が同じであるように見えます。
実際の環境作成に関しては、テラフォームを使用しています。リソースの設定はどちらのオプションを使用しても非常に簡単なので、賛否両論とは思いません。
NACLリソース:
ingress {
protocol = 6
rule_no = 300
action = "allow"
cidr_block = "0.0.0.0/0"
from_port = 80
to_port = 80
}
SGリソース:
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
NACLに見られる唯一の大きな利点は、複数のパブリックSGがある場合、コンソールを介して手動で処理すると、NACLのIPアドレスをブラックリストに登録するのが簡単になることです。
上の図から、それは非常に明確です:
インターネットゲートウェイ> VPCレベルでインバウンドルールとアウトバウンドルールを制御します。その場合、VPC内のすべてのリソースが影響を受けます。すべてのEc2インスタンスが影響を受けます。
Nacl >サブネットレベルでインバウンドルールとアウトバウンドルールを制御します。その場合、サブネット内のすべてのリソースが影響を受けます。NACL1> Ec-1の場合、Ec-2とEc-3が影響を受け、NACL2の場合はEc2-4が影響を受けます。したがって、Naclはインターネットゲートウェイと比較してより制限的です。
セキュリティグループ>リソースレベルでインバウンドルールとアウトバウンドルールを制御します。その場合、セキュリティグループに接続されているすべてのリソースが影響を受けます。セキュリティグループ1の場合はEc2-1とEC2-2が影響を受け、セキュリティグループ2の場合はEc2-3が影響を受けます。
したがって、インターネットゲートウェイ、Nacl、およびセキュリティグループはすべて、さまざまなレベルでファイアウォールとして機能します。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加