Redshift 复制和卸载安全性答案

【问题标题】：Redshift Copy and Unload SecurityRedshift 复制和卸载安全性
【发布时间】：2018-01-25 04:07:38
【问题描述】：

我的 Redshift 集群位于完全锁定的私有子网中。我想在 Redshift 中运行 COPY 和 UNLOAD 命令，这将与 S3 存储桶进行交互。我知道我将要使用 VPC 端点来附加 S3 存储桶，但我在文档中看不到任何内容显示如何将正确的端口打开到正确的 IP 范围以允许 COPY 和 UNLOAD 发生，并且我现在可以让它工作的唯一方法是保持入站和出站网络 ACL 和安全组完全开放。我不习惯在生产环境中运行它，并且必须有更好的方法来保护这些操作的 Redshift。

非常感谢任何帮助！

【问题讨论】：

您能否澄清一下“这些操作的安全 Redshift”是什么意思？为什么要使用 NACL？安全组不足以满足您的安全需求吗？
@JohnRotenstein 我将 NACL 包含在其中只是因为现在 Redshift 是该子网上的唯一资源。没错，安全组应该足以将其锁定。我仍在研究我的 NACL 策略。不过，Redshift 和 S3 的问题都会发生。

标签： amazon-web-services amazon-s3 amazon-redshift amazon-vpc

【解决方案1】：

安全组足以保护 Amazon Redshift 集群。

由于系统通信的方式，NACL 很难在资源上配置是出了名的。例如，Amazon EC2 实例可以在端口 5439 上向 Redshift 发送请求。该数据包包含一个 返回地址，该地址在 EC2 实例上具有一个随机选择的端口，应将响应发送到该端口。这是计算机在向系统发送多个请求时处理响应的方式。

缺点是您不知道将需要哪个端口发送返回响应。这就是您在配置 NACL 时遇到问题的原因。

然而，安全组是有状态的，并自动允许出站响应返回到原始请求中指定的端口。只需将它们视为智能 NACL。

底线：使用安全组，而不是 NACL。

【讨论】：

感谢您的见解。我对NACL的用例感到困惑。在私有子网上保持开放并仅由安全组限制，并在公共子网上根据需要实施 NACL 是否被认为是一种好的做法？
最佳实践是根本不修改 NACL。它们可用于不寻常的情况，例如创建 DMZ 或阻止某些子网相互通信——尤其是与 VPC 对等互连使用时。一般来说，不要碰它们。

【解决方案2】：

假设 Redshift 将 S3 作为 Web 服务访问（就像其他一切一样），那么打开 443 出站应该就足够了。安全组不会阻止返回流量，因此无需打开入站端口（当然，对于指定来源的 5439 除外）。

但您为什么要担心阻止来自 Redshift 的出站流量？通常，如果担心不受控制的程序会在服务器上运行，您只会阻止出站流量。您可能在考虑您的网络配置。

【讨论】：

这也是我最初认为它会做的事情。事实证明 Redshift COPY 需要某个 IP 地址的 30000-65535 范围内的某个入站端口。我不知道是哪一个，所以我现在不得不把它敞开。我觉得对于这么大范围的 IP 无限制规则并不是做事的好方法。你怎么看？
这些是“临时端口”，通常在连接到外部资源时用作客户端端口（因此不会受到安全组的影响），但也偶尔在服务想要接受入站时使用连接（例如 JMX 或活动模式下的 FTP）。但是Redshift在做COPY时应该没有理由需要打开这样一个端口。你能显示你正在使用的确切命令，并描述你是如何调用它的吗？

【解决方案3】：

另一个可能的原因是增强的 VPC 路由 https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-routing.html

如果启用此功能，并且您的集群没有公共 IP，并且您的 VPC 被锁定到外部流量，那么您将需要为 S3 创建一个 VPC 端点以保留所有您的 VPC 的内部流量。

参考：https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-working-with-endpoints.html

【讨论】：