在GCS存储桶名称中使用project-id有什么风险？

Question

我一直在我的GCS存储桶名称中使用project-id作为前缀来轻松获得唯一名称。 当我阅读GCS-best practises

它清楚地表明不要使用项目名称或项目编号（与projectId：s无关） 但是另一方面，当我启动GAE时，会自动创建两个包含project-id的存储桶。

Google是不是遵循自己的最佳做法，还是我错过了什么？

因为存储桶名称是公开可见的，所以我在存储桶名称中拥有projectId的最大风险是我向潜在的攻击者提供有关该项目的线索吗？

Answer 1

在某种程度上，确实表明Google可能未遵循其最佳做法（如该页面上列出的，假设项目名称和编号表示GCP名称和编号）。置于GCP之上的Firebase项目的默认存储桶也是如此。

您链接的文档说明了避免使用项目名称的原因：

  

...因为任何人都可以探测到桶的存在...

这个想法是，如果有人知道您的项目名称，则可以使用该名称来构建存储桶的全名，并在攻击中使用该知识以获得其内容。但是，如果您的安全配置正好是应该的，那么知道存储桶的名称将不是问题。对于Firebase项目而言尤其如此，该项目使用安全规则来确定谁应该能够访问哪些对象。

为了避免攻击者猜测您的存储桶名称及其任何内容，我会采纳文档中的建议，以作为一种通过模糊处理来确保安全性的措施。但是，如果这不是您的问题，那就不要理会。

Answer 2

似乎他们只是担心泄漏PII。我不确定他们为什么提到项目名称，除非是因为有人可能在项目名称中包含PII。

  

请勿在存储桶名称中使用用户ID，电子邮件地址，项目名称，项目编号或任何个人身份信息（PII），因为任何人都可以探测到存储桶的存在。同样，将PII放在对象名称中时要非常小心，因为对象名称会出现在对象的URL中。

我看到在我的帐户中创建的两个存储桶都有一个 appspot.com 后缀。您无法创建任意的 appspot.com 存储桶，因为它们具有。在名称和thus are subject to verification中：

  

存储桶名称只能包含小写字母，数字，破折号（-），下划线（_）和点（。）。不允许使用空格。包含点的名称需要验证。

您是正确的，尽管自动创建存储桶与他们的最佳做法指南不一致。