了解服务器架构：使用 Nginx 反向代理或 Apache 服务器从 AWS S3 传送内容

Question

这个问题的目的是在设计服务器端架构时了解策略。

用例：我想为允许用户上传和下载多媒体内容（图像、视频等）的应用程序构建一个 http 服务器。预计会有大量并发用户（例如，大约 50k）上传/下载内容。

所有内容都将存储在 AWS S3 存储桶中。 有关 S3 存储桶的信息，即存储桶名称/身份验证标头，应向用户屏蔽。 由于 S3 存储桶有多个访问控制选项 ( AWS-ACL )，因此最好不要让存储桶可供 All_Users（经过身份验证的和匿名用户）使用。 我不想在公共领域公开内容。

查询

• 由于我想对用户屏蔽 AWS S3，我需要使用网络服务器或反向代理。 我浏览了多个比较 Apache 与 Nginx 的资源。 由于服务器需要从 S3 向大量并发用户提供静态内容，Nginx 似乎是一个更好的选择。 不是吗？？

• 将 S3 存储桶的访问控制级别设置为 ALL_USERS（针对经过身份验证的用户和匿名用户）是否会损害数据隐私？ 如果我使用反向代理，则用户无法确定 S3 存储桶 url。 数据是否安全和私密？

• 但是，如果 S3 存储桶仅供经过身份验证的用户使用，那么 nginx 反向代理会起作用吗？ 我已经完成了S3 的 Nginx 反向代理。 为了让 Nginx 作为反向代理工作，需要准备一个预签名的 URL 。 预签名网址的到期时间又是一个棘手的决定。 为预签名的 url 设置一个巨大的到期时间有意义吗？ 它是否会损害数据的安全性或隐私性（类似于 s3 对 ALL_USERS 的访问控制）？ 如果是，有没有办法仅通过 nginx 将请求反向代理到动态生成的预签名 url（到期时间短）？

任何巩固我的理解的信息和资源都将非常有帮助。

Answer 1

将 S3 存储桶的访问控制级别设置为 ALL_USERS（针对经过身份验证的用户和匿名用户）是否会损害数据隐私？

绝对地。 不要这样做。

如果我使用反向代理，则用户无法确定 S3 存储桶 url。 数据是否安全和私密？

理论上，他们无法确定，但是如果错误消息或错误配置泄露了信息怎么办？ 这是通过默默无闻的安全感，它只会给您一种虚假的安全感。 总有更好的方法。

有关 S3 存储桶的信息，即存储桶名称/身份验证标头，应向用户屏蔽。

带有签名 URL 的 S3 身份验证机制的设计目的是将其暴露给用户不会造成任何危害。 唯一的秘密是您的 AWS 密钥，您会注意到它不会在签名 URL 中公开。 它也不能合理地进行逆向工程，并且签名 URL 仅适用于签名允许的资源和操作。

签署 URL 并将其呈现给用户不会带来安全风险，尽管不可否认，您可能不想这样做还有其他原因。 我经常这样做——在呈现页面时签署一个 URL，具有相对较长的到期时间，或者签署一个 URL 并在用户单击返回我的应用程序服务器的链接时将用户重定向到签名的 URL（这会验证他们的访问资源的授权，然后返回一个过期时间很短的签名 URL，例如 5 到 10 秒；过期可以在下载过程中发生而不会造成问题——签名只需要避免在过期之前对 S3 的请求被接受）。

但是，如果您想使用代理路由（除上述之外，这也是我在我的系统中所做的事情），有一种比您想象的更简单的方法：可以将存储桶策略配置为允许根据源 IP 地址授予的特定权限......您的服务器。

这是直接从我的一个桶中获取的（经过消毒的）政策。 IP 地址来自RFC-5737，以避免本示例中的私有 IP 地址会引起混淆。

这些 IP 地址是公共 IP 地址……它们将是附加到您的 Web 服务器的弹性 IP 地址，或者最好是附加到 Web 服务器用于其传出请求的 NAT 实例。

{
    "Version": "2008-10-17",
    "Id": "Policy123456789101112",
    "Statement": [
        {
            "Sid": "Stmt123456789101112",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "203.0.113.173/32",
                        "203.0.113.102/32",
                        "203.0.113.52/32",
                        "203.0.113.19/32"
                    ]
                }
            }
        }
    ]
}

这有什么作用？ 如果请求从列出的 IP 地址之一到达 S3，则向请求者授予GetObject权限。 使用代理，您的代理的 IP 地址将是 S3 看到的 IP 地址，如果它与存储桶策略匹配，则该请求将被授予，允许您的代理从 S3 获取对象同时不允许互联网的其余部分，除非备用提供凭据，例如带有签名的 URL。 此策略不会直接“拒绝”任何事情，因为拒绝是隐含的。 重要的是，不要使用public-read ACL 上传您的对象，因为这将允许任何人下载被反对的对象。 默认private ACL 非常适合此应用程序。

S3 可以根据其他条件授予这样的权限，例如Referer:标头，您可以在网上找到相关示例，但不要这样做。 信任浏览器报告为引用页面的内容是一种极其脆弱和原始的安全机制，它几乎不提供真正的保护——标题非常容易欺骗。 这种过滤真的只适合那些热链接到您的内容的烦人的懒人。 源 IP 地址完全是另一回事，因为它不包含在第 7 层标头中，并且不容易被欺骗。

由于 S3 仅通过 TCP 协议与 Internet 交互，因此您的源地址——即使知道您如何使存储桶信任这些地址——也不能以任何实际方式被欺骗，因为这样做意味着破坏AWS 核心 IP 网络基础设施的安全性——TCP 要求原始机器可以通过它使用的源 IP 地址跨子网访问，AWS 网络只会将这些响应路由回您合法分配的 IP 地址，这将除了重置或丢弃连接之外别无选择，因为它们不是由您发起的。

请注意，此解决方案不能与 Amazon 最近宣布的S3 VPC 端点结合使用，因为对于 S3 VPC 端点，您的源 IP 地址（由 S3 看到）将是私有地址，这不是您的 VPC 独有的...但这应该不是问题。 我提到这个警告只是为了彻底。 S3 VPC 端点不是必需的，默认情况下不启用，如果启用，可以在每个子网的基础上进行配置。