使用 AWS 网络 ACL 与 SG 进行访问控制？答案

【问题标题】：Using an AWS Network ACL versus an SG for access control?使用 AWS 网络 ACL 与 SG 进行访问控制？
【发布时间】：2019-10-09 08:46:48
【问题描述】：

我有一个在 AWS 上运行的 Ubuntu EC2 实例。我一直使用网络 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：将 NACL 入口限制为端口 80、443，将临时端口限制为 0.0.0.0/0。每个 IP 地址添加端口 22 访问。拒绝所有其他流量。（这是我一直在做的事情。）如果我想要一个私有子网实例，我会通过 SG 将私有子网限制为公共子网的内部 CIDR。

选项 2：向全世界开放 NACL，并使用 SG 对 EC2 实例进行访问控制。

选项 3：冗余并同时使用。

当我去一个新位置（咖啡店）并想通过 SSH 连接到我的实例时，我登录 AWS 控制台并添加新的 NACL 规则以允许 IP 地址端口 22 访问。向 NACL 和 SG 添加规则似乎是相同数量的鼠标点击和打字。

关于实际环境创建，我使用 terraform。使用任一选项设置资源都非常容易，所以我不会认为这是一个优点或一个缺点。

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 地址列入黑名单。

【问题讨论】：

相关帖子，推荐nacl medium.com/datadriveninvestor/…
@Spiff 那篇文章在哪里推荐 NACL？它讨论了 NACL 是什么，但我没有看到任何建议。
NACL 支持显式拒绝（SG 不支持）。深度安全具有价值，而且不同的团队可以对 SG 和 NACL 负责，以减少错误的影响。 NACL 适用于整个子网，因此可以缓解 EC2 实例上的 SG 的 DevOps 错误。这里有一些额外的想法：youtube.com/watch?v=X-MdCb9FMLc
@jarmod 那里：使用网络 ACL 而不是安全组阻止 IP 地址

【解决方案1】：

NACL 在子网级别运行，SG 在实例级别运行，正如它在您引用的文档中所说，因此对于其中包含单个实例的子网，NACL 具有显式拒绝是功能上的唯一区别。我建议将 AWS cli 用于您的咖啡店示例，根据哪个命令对您来说更容易在 NACL 和 sg 之间进行选择。

大型环境在子网中会包含多个实例，因此 SG 允许实例级别。我还认为 SG 作为动态的云原生选项使其更可取，因为可以在规则中使用 SG 成员身份而不是 IP 地址。这使得 infra as 代码在区域、vpcs 和 azs 之间可移植，因为寻址可以是动态的或重叠的，但您的堆栈仍然可以正常工作。

【讨论】：

【解决方案2】：

访问控制和保护 VPC 是一个大话题，AWS 建议您针对不同场景使用许多最佳实践（例如，Bastion Hosts）

对于从咖啡店计算机访问公共子网中的单个 EC2 的简单情况，您需要更改安全组以允许从咖啡店 IP 进行 SSH。

使用控制台，一般步骤是：

在 VPC 仪表板 -> 安全 -> 安全组 -> 蓝色按钮下：创建安全组。将其命名为 Coffee SG，对其进行描述并选择合适的 VPC 以将其关联并单击创建。
创建 SG 后，单击底部的入站规则选项卡，然后单击编辑规则按钮
对于类型，选择 SSH
如果您在咖啡店的计算机上，请选择“我的 ip”作为来源。浏览器会自动填入电脑ip。要允许任何 ip，您可以使用 0.0.0.0/0（不推荐）来允许范围，使用 CIDR。
点击保存规则。
启动 ec2 实例时，为您的安全组选择 Coffee SG。

如果您的 EC2 已经在运行，请转到安全组并从上面的第 2 步开始。有关更多详细信息，请参阅 AWS 指南：

This guide 提供了您需要为 Linux 实例执行的步骤。 This guide 提供了您需要为 Windows 实例执行的步骤。

【讨论】：

我了解执行此操作的不同方法，而您的方法是逐步进行的另一种方法。简而言之，我正在寻找使用 NACL 与 SG 来控制访问的优缺点。我一直只使用 NACL，但在具有堡垒主机和公共/私有子网的实验室中使用了 SG。在这方面有一些很棒的实验室！
嘿@Neal，为了通过SSH连接到一个实例，你必须改变SG。不需要更改 NACL，并且在不更改 SG 的情况下进行更改，您的 SSH 将被阻止。
哦，是的，非常正确。我只是有一个 SG 规则来打开端口 22 到 0.0.0.0/0，因为我总是在 NACL 中添加该规则。我确实认为单独的“Coffee Shop SG”是个好主意，我将尝试一下。谢谢！

【解决方案3】：

现在从上面的图表很清楚：

Internet 网关 > 在 VPC 级别控制入站和出站规则。在这种情况下，VPC 中的所有资源都会受到影响。所有 Ec2 实例都会受到影响。

Nacl > 在子网级别控制入站和出站规则。在这种情况下，子网内的所有资源都会受到影响。对于 NACL1 > Ec-1 ，Ec-2 和 Ec-3 将受到影响，对于 NACL2 Ec2-4 将受到影响。因此，与 Internet 网关相比，Nacl 的限制更大。

安全组 > 在资源级别控制入站和出站规则。在这种情况下，附加到安全组的所有资源都会受到影响。对于安全组 1，Ec2-1 和 EC2-2 将受到影响，对于安全组 2，Ec2-3 将受到影响。

所以 Internet gateway 、 Nacl 和 Security Group 都充当不同级别的防火墙

【讨论】：