Firestore是否具有内部机制来保护应用程序免受来自DDOS请求的过多费用? [英] Does Firestore have internal mechanism to protect app from excessive $ charge from DDOS requests?

问题描述

我想知道Firestore是否具有类似于DDOS的内部机制来阻止请求，以防止意外的费用激增，或者是否具有所有者可以限制最大请求/收费的功能.

I was wondering if Firestore has internal mechanism to block requests similar to DDOS to prevent surprise surge in costs, or has a feature for owners to put limits on max requests/charges.

例如，假设Firestore中有一个集合，只要用户登录我的应用程序就可以访问该集合.

For instance, assume that there is a collection in Firestore which is accessible as long as a user is logged in in my application.

如果攻击者创建了大约100个用户帐户，并编写了一个脚本，该脚本逐渐并连续地从不同计算机上访问集合中的一个条目，每个条目大约有10〜50tps(例如100个随机计算实例，每个用户1个)，每天的读取访问数量可以超过2.16亿个请求.

If an attacker creates around 100 user accounts, and writes a script which gradually and continuously access one entry from the collection with around 10~50tps each from different computers (e.g. 100 random compute instances, 1 for each user), the total number of read access per day can go over 216 million requests.

(100个用户* 25个平均TPS * 86400秒/天)= 2.16亿.

(100 users * 25 avg TPS * 86400sec/day) = 216 million.

这相当于每天约$ 129美元，当前定价单位为$ 0.06/10万个请求.

This translates to around $129 dollars/day, with current pricing unit of $0.06/100k requests.

如果攻击者使用list请求并一次访问10个项目而不是单个项目，则费用可能高达$ 1290/天.如果其中一个馆藏允许用户一次查询多达100条记录，则每天的费用为$ 12900.

If attacker uses list request and access 10 items at once instead of just a single item, the charge can go up to $1290/day. If one of the collection allows users to query up to 100 records at once, this can become $12900/day.

我对此可能有点偏执，但是我想避免面对一夜积累的1万美元的惊喜账单，并在早晨醒来时对其进行了解.我知道发生这种攻击的可能性很小，但是如果有需要的话，任何攻击者仍然有可能执行该攻击.

I might be too paranoid about this, but I want to avoid facing $10k surprise bill which accumulated overnight and learn about it in the morning when I wake up. I know that chance of this attack happening is low, but it still seems possible for any attacker to execute it if wanted.

由于这种风险，我永远不想直接将我的Firestore集合公开给客户端SDK(例如，将所有读/写安全规则设置为false)，而是希望使用自定义的终结点& Firebase Admin SDK可以控制速率限制...但是，这只是失去了可用客户端SDK的所有优势，从而减少了延迟并简化了开发.

Because of this risk, I wouldn't ever want to expose my Firestore collection directly to client sdks (e.g. set all read/write security rules to false), and would rather want to use custom made endpoints & Firebase Admin SDK to control rate limits... but this just loses all advantages of available client sdks for reduced latency and ease in developments.

Firestore是否具有某种形式的机制来防止此类问题的发生?还是允许速率限制请求类似于AWS dynamoDB中的最大读/写容量限制?

Does Firestore have some form of mechanism to prevent this kind of issue from happening? Or does it allow rate-limiting requests similar to max read/write capacity limits in AWS dynamoDB?

推荐答案

Cloud Firestore作为独立产品，默认情况下没有任何速率限制.整体而言，Google Cloud Platform具有适用的可配置的结算提醒到您的整个项目. (所有Firebase项目也是Google Cloud Platform项目.)

Cloud Firestore, as a standalone product, doesn't have any rate limiting by default. Google Cloud Platform, as a whole, has configurable billing alerts that apply to your entire project. (All Firebase projects are also Google Cloud Platform projects.)

如果您有无法解释的意外费用，请联系Firebase支持寻求解决方案的帮助.

If you have a surprise bill that can't be explained, contact Firebase support for help resolving that.

这篇关于Firestore是否具有内部机制来保护应用程序免受来自DDOS请求的过多费用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！