AWS 网络防火墙的策略支持将源和目标设置成FQDN吗？

【以下的回答经过翻译处理】 这是一个常见的问题，简短的回答是“否”。但是，如果您对为什么会这样感兴趣，请继续阅读。

HTTP 和 HTTPS 是有趣的协议，因为协议的一部分（以几种不同的方式 - Host 标头或在证书中）在协议中包含预期目的地的主机名。因此，如果您可以捕获该信息（在 HTTP 中容易；在 HTTPS 中更难，并且随着 TLS 1.3 的采用而变得更加困难，因为它旨在隐藏更多证书信息），那么您可以（在防火墙中）做出基于在那个信息上。很棒的东西。

请注意，如果此信息不可用，则防火墙唯一需要继续的就是目标 IP 地址。将其映射回 FQDN 非常耗时（反向 DNS 查找需要时间）；可能无法工作（并非所有站点都有最新的甚至准确的反向 DNS 查找）；并且不适用于在单个 IP 地址上托管多个站点的服务。除了 HTTP 和 HTTPS 之外，几乎所有内容都是如此。会有例外，但现在就去吧。

FQDN 和 IP 地址之间的映射是在发起连接的主机上完成的。通常该进程 (DNS) 与网络过滤进程 (防火墙) 完全分离。防火墙对主机如何将 FQDN 解析为 IP 地址一无所知。绝对没有。

您能否构建一个系统，让您的 DNS 解析器将 DNS 查询、解析后的 IP 和原始主机 IP 传递给防火墙？是的，你可以。它仍然不是完美的——如果主机查找两个 DNS 记录，它们都指向相同的 IP 地址，然后连接到它们，防火墙如何知道允许或丢弃哪个会话？这是一个边缘案例，但现实世界的影响使这个过程变得更加困难。而诸如 DNSSEC 和 DNS-over-HTTPS 之类的东西将使它几乎不可能。

假设解析器可以在原始主机尝试连接之前找到它需要与防火墙通信的信息。这在小型网络中并不太难，如果 DNS 解析器和防火墙是边缘的单个设备，那就更容易了。但在大型网络中，它根本无法扩展。现在您需要 DNS 解析器与一组（可能）分布式防火墙进行通信（因为您不知道哪个防火墙实例将接收会话）。

并且：甚至可能在主机尝试连接之前几秒或几分钟——如果该信息超时怎么办？您需要在防火墙上保留多少内存来跟踪所有内容？

简而言之，这不是一件可以轻易大规模完成的事情，因为有很多方法可能会失败。

最后回答你的问题（再次以长格式）：小心尝试锁定你的网络，以便只有设备 X 可以与设备 Y 对话以获取一组特定的协议。虽然您可以这样做，但您最终会遇到这样一种情况：您的企业、开发人员或任何其他试图做某事的人都需要等待您（或您的团队）更改网络才能让他们完成工作。不要让“安全”成为业务的障碍。

当然，设置安全组，以便只有内部（到您的网络）主机可以连接到某些实例。这就说得通了。但是不要编写非常具体的 NACL 和防火墙规则，以至于当主机更改 IP 地址时（这种情况一直发生！），您需要花费数小时进行故障排除，然后获得紧急变更控制批准，以便您可以修复问题每个人都可以回去工作。问我是如何学到这一课的……（或者不是——你可以猜到）。

我意识到我现在正在布道 - 道歉。但这是一个很大的话题，因为它深入研究了业务和安全团队愿意承受的风险与他们希望继续工作的速度。

与您当地的 AWS 客户团队合作非常值得——他们可以引入网络、安全、合规等方面的专家解决方案架构师来找出最适合您的解决方案。