amazon-s3 - 如何以安全的方式从 S3 提供 HLS 流(授权和认证)

Question

问题:

我正在存储的号码HLS 流在 S3 使用给定的文件结构:

Video1
  ├──hls3
      ├──hlsv3-master.m3u8
      ├──media-1
      ├──media-2
      ├──media-3
      ├──media-4
      ├──media-5
  ├──hls4
      ├──hlsv4-master.m3u8
      ├──media-1
      ├──media-2
      ├──media-3
      ├──media-4
      ├──media-5

在我的用户中 API 我知道哪个用户可以访问哪些视频内容
但我还需要确保视频链接不可共享且只能访问
由具有正确权限的用户。

解决方案:

1)使用签名/临时 S3 私有(private)网址 S3 内容。每当客户端想要播放某些特定视频时
发送请求到我的 API .如果用户有正确的权限 API 正在生成签名网址
并将其返回给客户端，客户端将其传递给玩家。

我在这里看到的问题是真实的视频内容存储在 中的几十个片段文件中。媒体-* 目录
而且我真的不知道如何保护所有这些 - 我是否需要分别签署每个段文件 url？

2) S3 内容是私有(private)的。玩家提出的视频流请求正在通过我的 API 或单独 反向代理 .
因此，每当客户端决定播放特定视频时， API / 反向代理正在获取请求，进行身份验证和授权
并传递正确的内容(主播放列表文件和片段)。

在这种情况下，我仍然需要制作 S3 内容私有(private)且只能由我访问 API / 反向代理 .这里推荐的方式应该是什么？
S3 rest authentication via tokens ?

3) 使用 protected key 进行加密。在这种情况下，所有的视频片段都是加密的并且是公开的。 key 也存储在 S3
但不公开。玩家提出的每一个 key 请求都经过我的认证和授权 API / 反向代理 .

这是我现在想到的 3 个解决方案。不相信所有这些。我正在寻找简单且防弹安全的东西。任何建议/建议？

使用技术:

ffmpeg用于将视频编码为不同比特率

bento4用于视频分割

Answer 1

would I need to sign each of the segment file urls separately?

如果玩家直接从 S3 请求，那么是的。所以这可能不是理想的方法。

一种选择是存储桶前面的 CloudFront。 CloudFront 可以配置一个源访问身份，它允许它签署请求并将它们发送到 S3，以便它可以代表授权用户获取私有(private) S3 对象，并且 CloudFront 支持这两种签名 URL(使用与 S3 不同的算法，有两个重要的区别，我将在下面解释)或 signed cookies . CloudFront 中已签名的请求和 cookie 的工作方式非常相似，重要的区别是 cookie 可以设置一次，然后浏览器会自动为每个后续请求使用，无需对单个 URL 进行签名。 (啊哈。)

对于 CloudFront 中的签名 URL 和签名 cookie，如果您使用自定义策略，您将获得 S3 无法轻松完成的两项附加功能:

与 CloudFront 签名关联的策略可以允许 wildcard in the path ，因此您可以授权访问任何文件，例如 /media/Video1/*直到签名到期。 S3 签名 URL 不支持任何形式的通配符——S3 URL 只能对单个对象有效。

只要 CloudFront 分配仅针对 IPv4 进行配置，您就可以将签名绑定(bind)到特定的客户端 IP 地址，从而仅允许从单个 IP 地址使用该签名进行访问(CloudFront 现在支持 IPv6 作为可选功能，但它不是当前与此选项兼容)。这有点激进，可能不适合移动用户群，因为他们会在从提供商网络切换到 Wi-Fi 并返回时切换源地址。

仍然必须为所有内容链接生成所有签名 URL，但您只能生成和签名 URL 一次，然后重用签名，只需为每个文件重写 URL 字符串，使该选项的计算成本更低......但仍然麻烦。另一方面，签名 cookie 应该“适用于”任何匹配的对象。

当然，添加 CloudFront 还应该通过缓存和缩短 Internet 路径来提高性能，因为与通常直接发送到 S3 的请求相比，请求跳到离浏览器更近的托管 AWS 网络上。使用 CloudFront 时，来自浏览器的请求将被发送到 60 多个全局“边缘站点”中的任何一个，这些站点被假定为最靠近发出请求的浏览器。 CloudFront 可以向具有不同 URL 或 cookie 的不同用户提供相同的缓存对象，当然，只要 sig 或 cookie 有效。

要使用 CloudFront 签名 cookie，至少您的应用程序的一部分(设置 cookie 的部分)需要位于指向存储桶的相同 CloudFront 分配的“后面”。这是通过将您的应用程序声明为分发的附加源，并为特定路径模式创建缓存行为来完成的，在请求时，CloudFront 将其转发到您的应用程序，然后应用程序可以响应适当的 Set-Cookie:标题。

我不隶属于 AWS，所以不要将以下内容误认为是“推销”——只是期待你的下一个问题:CloudFront + S3 的定价使得与单独使用 S3 相比的成本差异通常可以忽略不计——S3 没有当通过 CloudFront 请求对象时，不会向您收取带宽费用，而且 CloudFront 的带宽费用在某些情况下略低于直接使用 S3 的费用。虽然这似乎有悖常理，但 AWS 会以一种鼓励在其网络中分发请求而不是将它们全部集中在单个 S3 区域的方式来构建定价是有道理的。

请注意，没有一种机制，无论是上面的还是下面的，都不能完全免于未经授权的“共享”，因为身份验证信息必须对浏览器可用，因此对用户可用，这取决于用户的专业知识……但这两种方法让诚实的用户保持诚实似乎绰绰有余，这是您所希望做的。由于签名 URL 和 cookie 上的签名有过期时间，共享能力的持续时间是有限的，您可以通过 CloudFront 日志分析识别此类模式，并做出相应的 react 。无论您采用何种方法，都不要忘记掌握日志的重要性。

反向代理也是一个好主意，可能很容易实现，如果运行代理的 EC2 机器与存储桶位于同一 AWS 区域，并且代理基于可靠、高效的代码，如 Nginx 或 HAProxy 中的代码。

在此环境中您无需签署任何内容，因为您可以将存储桶配置为允许反向代理访问私有(private)对象，因为它具有固定的 IP 地址。

在存储桶策略中，您通过授予“匿名”用户 s3:getObject 来实现这一点。特权，仅当其源 IPv4 地址与代理之一的 IP 地址匹配时。代理代表授权用户从 S3 匿名(无需签名)请求对象。这要求您不使用 S3 VPC 终端节点，而是为代理提供弹性 IP 地址或将其放在 NAT 网关或 NAT 实例后面，并使 S3 信任 NAT 设备的源 IP。如果您确实使用了 S3 VPC 端点，则应该可以允许 S3 信任该请求，因为它遍历了 S3 VPC 端点，尽管我尚未对此进行测试。 (S3 VPC Endpoints 是可选的；如果您没有明确配置一个，那么您就没有一个，并且可能不需要一个)。

如果我理解正确的话，您的第三个选项似乎最弱。授权但恶意的用户获得 key 并可以整天共享它。