Security 能否将AWS安全组配置为具有子组或嵌套组？

TLDR

我们在单个安全组中有一个很长的IP地址列表，很难管理。AWS让人感觉可以嵌套组，但不能。我说得对吗

背景

我在配置和使用安全组方面没有任何问题。这个问题更为微妙，这就确定了背景

我们已将安全组配置为将对开发实例/服务的访问权列入白名单。由于我们的配置模式是一个白名单，我们必须不断地添加新的IP地址，这取决于团队成员的工作地点。没有静态IP地址的糟糕的ISP

这不是问题所在。但想象一下，IP地址越来越乱

问题

偶尔我们会删除这个白名单（因为糟糕的ISP），并确保IP地址是相关的，最新的，并且应该仍然在白名单上

我们发现自己不愿意这样做，因为目前有效“清理”白名单的唯一方法是重新开始

AWS似乎并没有提供一种在安全组规则中标记记录或允许嵌套安全组的简洁方法

当前的工作环境

拥有大量（可能有数百个）独立的安全组，并确保这些组始终连接到相关服务

优点：易于标记/识别IP地址（如Bob的家庭IP），因此Bob可以删除旧IP地址并替换为新IP地址

缺点：每个安全组都必须附加到相关的实例，这个列表可能会很长

保留一个单独的IP/查找列表，并有一个安全组

赞成：意味着你只需要一个安全组

缺点：必须保持两个列表是最新的，不太实际，你会得到错误的匹配

某种自动化。构建一个定期检查安全组的服务，并将这些ip与一些基本的地理ip/ISP信息一起存储在DynamoDB中。用作参考

赞成者：像#2，但是自动的。不是100%准确，因为地理ip查找从来都不是

缺点：必须为感觉应该已经存在的东西编写和维护实用程序

充满希望的解决方案

子/嵌套安全组。AWS配置界面实际上意味着您可以这样做，但它不能按预期工作。例如，主安全组具有允许来自其他安全组的入站流量的规则-这些规则依次将IP地址逻辑分组在一起

将安全组指定为规则的源时，这允许与源安全组关联的实例访问安全组中的实例。（请注意，这不会将规则从源安全组添加到此安全组。）

我发现文档有点矛盾。从实验来看，这是行不通的

给每条记录贴上标签。这显然是不存在的，这将是AWS的一个功能请求

我错过了什么吗？其他人是如何管理大型安全组的？

您是对的--安全组不能嵌套

如果您在Amazon VPC中白名单实例，则可以使用名称来引用其他安全组。例如，您可能有一个

websg

和一个

appsg

。App SG可允许从Web SG访问。然后，与Web SG关联的任何实例都可以与App SG中的任何实例通信

但是，如果您在AWS外部将实例列入白名单，则您需要自己维护安全组中的IP地址列表

最好的方法是自动化：

• 在数据库、电子表格等中维护白名单IP地址的“主列表”
• 在对主列表进行更改时自动更新列表

这可以通过使用您最喜欢的编程语言编写一个相当短的程序来实现，调用

authorize security group intres

等命令

---

底线：在AWS外部维护您自己的完整标签列表，然后通过自动化使安全组匹配。

鉴于入站条目数量的限制，这似乎注定会有麻烦。我不是说你错了，约翰。我想知道什么是对的。即使我有6个人在一个团队中，每个团队有2个IP，每个IP都有多个端口需求，这也会很快超出入站条目的限制。如果有一个庞大的团队，我将超过您可以在RDS实例上安装的VPC SGs（5）。虽然你可以要求更多，但这并不能很好地扩展。很明显，我做错了——但文档并没有帮助找到正确的解决方案。有什么建议吗？@riffrazor我的假设是，对安全组规则的限制是为了避免对通过网络的每个数据包检查过多的信息。复杂的规则会在发送和接收数据时增加延迟，因此他们可能必须设置一些限制，以确保通信速度不会受到过度影响。我建议您将用户分组到CIDR范围，而不是要求对单个IP地址进行规则。是的，这种推理是有道理的。解决办法就是挑战。在传统商店，更好的苹果酒是一个很好的解决方案。由于遥远的人分散在整个创作中，这是一个不可能的开始。规模对我们来说是可以容忍的，所以我们可以管理。我只是好奇一家知道他们在做什么的大商店会做什么：）谢谢。可能是用VPN增加了一个安全屏障，但把他们带到了同一个网络中。