Google 和 Amazon API 之间的安全机制差异

信息安全 验证 谷歌 网络服务 api 亚马逊
2021-09-10 17:25:27

有谁知道为什么 Google 和 Amazon (AWS) 的 API 有如此不同的方式来处理安全问题?例如,谷歌有一个简单的 API 密钥,您可以随时撤销,而亚马逊除了复杂的请求签名要求外,还有这种公钥/秘密密钥机制。

亚马逊的签名过程如此复杂以至于看起来更像是混淆而不是真正的安全?除非您想花几个小时弄清楚需求,否则您几乎被迫使用他们的 SDK。

为什么这两种方法完全不同,亚马逊的签名是否真正为他们的 API 增加了安全性?为什么 Google 会使用如此简单的替代方案?考虑到亚马逊也强制使用 HTTPS,亚马逊的方法真的有用吗?

2个回答

我认为这里的问题应该更多地从营销而不是安全角度来回答。

总的来说,我会说谷歌可能会使用一个相对简单的 API 密钥来提高可用性/可访问性,以便让广大开发人员更容易实现他们的服务(并从中赚钱)。

亚马逊可能更关心他们的 API 的使用,并使用不同的公钥和密钥系统。使用密钥确实增加了一定的保护,不能直接被认为是混淆安全(虽然技术上大多数安全基本上是一种混淆形式)。


要在评论中回答您的问题:

我真的很想知道为什么有人想让公共(有利可图的)服务难以使用。除了复杂性之外,使用密钥对 VS 进行签名还有什么其他好处?

对此,我想到了两个原因:

第一个可能是它给人一种安全感,这可能是公司选择更难实现的服务而不是易于实现的服务的原因。因为它被认为“更安全”。这提出了一个问题,如果安全功能实际上增加了额外的安全层,或者它们只是使事情变得不必要地复杂化。

第二个可能是它实际上可以增加额外的安全性例如,当我们使用一项为每个请求收费的服务并且唯一的身份验证是一个密钥时。然后,如果密钥泄漏,任何人都可以使用我的密钥使用该 API,因此我将为此付费。额外安全层的一个示例是结合密钥的 IP 白名单。这至少缓解了任何人都可以滥用我的密钥的问题。SSL (HTTPS) 为服务器和客户端之间的通信添加了一层加密(可能减轻中间人攻击)。其他可能的功能或措施可以是 DNSSEC、自定义加密、时间框架、密钥/凭证到期等,所有这些都增加了实际的安全性以减轻不同的攻击。

对于供应商而言,它(通常与安全性一样)是可用性和安全性之间的持续考虑。他们会考虑以下事项:

  • 在不偏执的情况下,我们可以而且应该走多远?
  • 我们需要走多远来保护我们提供的服务(数据)?
  • 如果我们走到这一步,开发人员是否仍然可以接受?

我一直在为亚马逊的部分产品 API 构建自己的包装器,而且使用起来非常非常困难。

我相信这是因为亚马逊 API(至少是市场 API)必须处理快速变化的数据,并且允许第三方访问显示这个市场需要大量的限制来保证显示的对象是准确的。

API 调用包括制作签名(包括时间戳)以防止基于时间的数据操作。(也许显示的产品价格实际上是几年前的价格?)