云服务器面临的问题
by Yan Cui
崔燕
无服务器安全面临的多方面威胁以及我们应如何应对 (The many-faced threats to Serverless security, and how we should address them)
Threats to the security of our serverless applications take many forms. Some are old foes we have faced before. Some are new. And some have taken on new forms in the serverless world.
对无服务器应用程序安全性的威胁有多种形式。 有些是我们以前遇到过的老敌人。 有些是新的。 在无服务器世界中,有些已经采取了新的形式。
As we adopt the serverless paradigm, we delegate even more operational responsibilities to our cloud providers. With AWS Lambda, you no longer have to configure AMIs, patch the OS, and install monitoring daemons. AWS takes care all that for you.
当我们采用无服务器模式时,我们将更多的运营责任委托给了云提供商。 使用AWS Lambda,您不再需要配置AMI,打补丁OS和安装监控后台程序。 AWS会为您全力以赴。
What does this mean for the Shared Responsibility Model that has long been the cornerstone of security in the AWS cloud?
什么这是否意味着为分担责任模式是早已安全的AWS的云的基石?
防范针对操作系统的攻击 (Protection from attacks against the OS)
AWS takes over the responsibility for maintaining the host OS as part of their core competency. This alleviates you of the rigorous task of applying all the latest security patches. This is something most of us don’t do a good enough job of, as it’s not our primary focus.
AWS负责维护主机操作系统,这是其核心竞争力的一部分。 这减轻了您应用所有最新安全补丁的严格任务。 这是我们大多数人做不到的事情,因为这不是我们的主要重点。
In doing so, it protects us from attacks against known vulnerabilities in the OS and prevents attacks such as WannaCry.
这样,它可以保护我们免受针对操作系统中已知漏洞的攻击,并防止诸如WannaCry之类的攻击。
By removing long-lived servers from the picture, we are also removing the threats posed by compromised servers that live in our environment for a long time.
通过从图片中删除长期存在的服务器,我们还消除了长期存在于我们环境中的受感染服务器所带来的威胁。
However, it is still our responsibility to patch our application and address vulnerabilities that exist in our code and our dependencies.
但是,修补应用程序并解决代码和依赖项中存在的漏洞仍然是我们的责任。
OWASP前10名仍然像以往一样重要 (OWASP top 10 is still as relevant as ever)
A glance at the OWASP top 10 for 2017 shows us familiar threats. Injection attacks, Broken Authentication, and Cross-Site Scripting (XSS) still occupy the top spots seven years on.
浏览OWASP 2017年的前10名 ,就可以看出我们熟悉的威胁。 注入攻击,身份验证失败和跨站点脚本(XSS)仍然占据7年之首。
A9 —已知漏洞的组件 (A9 — Components with Known Vulnerabilities)
When the folks at Snyk looked at a dataset of 1792 data breaches in 2016, they found that 12 of the top 50 data breaches were caused by applications using components with known vulnerabilities.
当在人Snyk在2016搜索的1792所数据破坏的数据集,他们发现, 在顶部50 的数据泄露 的12通过使用与组分已知的漏洞的应用引起的。
Furthermore, 77% of the top 5000 URLs from Alexa include at least one vulnerable library. This is less surprising than it first sounds when you consider that some of the most popular front-end js frameworks — eg. jQuery, Angular and React — all had known vulnerabilities. It highlights the need to continuously update and patch your dependencies.
此外, 来自Alexa的前5000个URL中的77%至少包含一个易受攻击的库 。 当您考虑到一些最流行的前端js框架时,这并不比最初听起来的令人惊讶。 jQuery , Angular和React —都具有已知漏洞。 它强调了不断更新和修补依赖项的需求。
Unlike OS patches, which are standalone, trusted and easy to apply. Security updates to 3rd party dependencies are often bundled with feature and API changes that need to be integrated and tested. It makes our life as developers difficult. It’s yet another thing we have to do when we’re working overtime to ship new features.
与OS修补程序不同,后者是独立的,可信任的且易于应用。 对第三方依赖关系的安全更新通常与功能和API更改捆绑在一起,需要进行集成和测试。 这使我们作为开发人员的生活变得困难。 当我们加班工作以发布新功能时,这是我们要做的另一件事。
And then there’s the matter of transient dependencies. If these transient dependencies have vulnerabilities, then you too are vulnerable through your direct dependencies.
然后就是瞬时依赖的问题。 如果这些临时依赖项存在漏洞,那么您也将通过直接依赖项受到攻击。
Finding vulnerabilities in our dependencies is hard work and requires constant diligence. Which is why services such as Snyk is so useful. It even comes with a built-in integration with Lambda, too!
在我们的依存关系中寻找漏洞是一项艰巨的工作,需要不断努力。 这就是为什么诸如Snyk之类的服务如此有用的原因。 它甚至还带有与Lambda的内置集成 !
攻击NPM发布者 (Attacks against NPM publishers)
Last year, a security bounty hunter managed to gain direct push rights to 14% of NPM packages. The list of affected packages include some big names too: debug
, request
, react
, co
, express
, moment
, gulp
, mongoose
, mysql
, bower
, browserify
, electron
, jasmine
, cheerio
, modernizr
, redux
and many more. In total, these packages account for 20% of the total number of monthly downloads from NPM.
去年,一名安全赏金猎人成功获得了对NPM包装数量的14%的直接推权。 受影响的软件包列表包括一些大牌明星也: debug
, request
, react
, co
, express
, moment
, gulp
, mongoose
, mysql
, bower
, browserify
, electron
, jasmine
, cheerio
, modernizr
, redux
等等。 这些软件包合计占NPM每月下载总数的20% 。
Let that sink in for a moment.
让它陷入片刻。
Did he use sophisticated methods to circumvent NPM’s security?
他是否使用复杂的方法来规避NPM的安全性?
Nope, it was a combination of brute force and using known account and credential leaks from a number of sources including Github. In other words, anyone could have pulled these off with very little research.
不,这是蛮力和使用已知帐户以及来自包括Github在内的许多来源的凭据泄漏的结合。 换句话说,只要很少的研究,任何人都可以实现这些目标。
It’s hard not to feel let down by these package authors when so many display such a cavalier attitude towards securing access to their NPM accounts.
当这么多软件包的开发者对确保获取其NPM帐户的访问权限表现出如此轻率的态度时,很难不感到失望。
662 users had password «
123456
», 174 — «123
», 124 — «password
».662位用户拥有密码«
123456
»,174 —«123
»,124 —«password
»。
1409 users (1%) used their username as their password, in its original form, without any modifications.
1409个用户(占1%)以其原始形式使用用户名作为密码,未经任何修改。
11% of users reused their leaked passwords: 10.6% — directly, and 0.7% — with minor modifications.
11%的用户重复使用了泄漏的密码:直接修改的密码为10.6%,直接修改的密码为0.7%。
As I demonstrated in my talk on Serverless security, you can steal temporary AWS credentials by adding a few lines of code.
正如我在无服务器安全性演讲中所演示的那样 ,您可以通过添加几行代码来窃取临时AWS凭证。
Imagine, then, a scenario where an attacker had managed to gain push rights to 14% of all NPM packages. He could publish a patch update to all these packages and steal AWS credentials at a massive scale.
想象一下,攻击者设法获得了所有NPM软件包的14%的推送权限。 他可以为所有这些软件包发布补丁更新,并大规模窃取AWS凭证。
The stakes are high and it’s possibly the biggest security threat we face in the serverless world. And, it also impacts applications running inside EC2 or containers.
风险很高,这可能是我们在无服务器世界中面临的最大安全威胁。 而且,它还会影响在EC2或容器中运行的应用程序。
The problems and risks with package management are not specific to the Node.js ecosystem. I have spent most of my career working with .Net and now Scala, and package management has been a challenge everywhere. We need package authors to exercise due diligence towards the security of their accounts.
程序包管理的问题和风险并非特定于Node.js生态系统。 我一生的大部分时间都在.Net以及现在的Scala上工作,而软件包管理一直是一个挑战。 我们需要软件包作者对其帐户的安全性进行尽职调查 。
A1-注射剂和A3-XSS (A1 — Injection & A3 — XSS)
SQL injection and other forms of injection attacks are still possible in the serverless world. As are Cross-Site Scripting (XSS) attacks.
在无服务器世界中,SQL注入和其他形式的注入攻击仍然可能。 跨站点脚本(XSS)攻击也是如此。
Even if you’re using NoSQL databases you might not be safe from injection attacks either. MongoDB, for instance, exposes a number of attack vectors through its query APIs.
即使您使用的是NoSQL数据库,也可能无法免受注入攻击。 例如,MongoDB通过其查询API公开了许多攻击媒介 。
DynamoDB’s more rigid API makes an injection attack harder. But you’re still open to other forms of exploits. For example, XSS and leaked credentials which grant attacker access to DynamoDB tables.
DynamoDB更严格的API使得注入攻击更加困难。 但是您仍然可以接受其他形式的攻击。 例如,XSS和泄露的凭据使攻击者可以访问DynamoDB表。
Nonetheless, you should always sanitize user inputs, as well as the output from your Lambda functions.
但是,您应该始终清除用户输入以及Lambda函数的输出。
A6 —敏感数据暴露 (A6 — Sensitive Data Exposure)
Along with servers, web frameworks are also redundant when you move to the serverless paradigm. These web frameworks have served us well for many years. But they also handed us a loaded gun we can shot ourselves in the foot with.
与服务器一起,当移至无服务器模式时,Web框架也是多余的。 这些网络框架已经为我们服务了很多年。 但是他们也给了我们一把装满枪的枪,我们可以用它开枪射击自己的脚。
Troy Hunt demonstrated how we can accidentally expose all kinds of sensitive data by leaving directory listing options ON. From web.config containing credentials (at 35:28) to SQL backups files (at 1:17:28)!
特洛伊·亨特(Troy Hunt) 演示了如何通过保持目录列表选项为开来意外地暴露各种敏感数据。 从包含凭据的web.config(在35:28)到SQL备份文件(在1:17:28)!
With API Gateway and Lambda, accidental exposures like this are very unlikely. Because directory listing becomes a “feature” you’d have to implement yourself. It forces you to make a conscious decision about when to support directory listing, and the answer is likely never.
随着API网关和Lambda,像这样的意外接触是不太可能。 因为目录列表成为“功能”,所以您必须实现自己。 它迫使您对何时支持目录列表做出有意识的决定,而答案可能更重要。
我是 (IAM)
If your functions are compromised, the next line of defense is to restrict what the compromised functions can do.
如果您的功能受到损害,则下一道防线是限制受到损害的功能可以做什么。
This is why you need to apply the Least Privilege Principle when configuring Lambda permissions.
这就是配置Lambda权限时需要应用“ 最低权限”原则的原因 。
In the Serverless framework, the default behaviour is to use the same IAM role for all functions in the service.
在无服务器框架中,默认行为是对服务中的所有功能使用相同的IAM角色。
However, the serverless.yml
spec allows you to specify a different IAM role per function. But it involves a lot more development effort and adds enough friction that almost no one does this.
但是, serverless.yml
规范允许您为每个函数指定不同的IAM角色 。 但是它涉及更多的开发工作,并且增加了很多摩擦,几乎没有人这样做。
Thankfully, Guy Lichtman created a plugin for the Serverless framework called serverless-iam-role-per-function. This plugin makes applying per function IAM roles much easier. Follow the instructions on the Github page and give it a try yourself.
值得庆幸的是, Guy Lichtman为无服务器框架创建了一个名为serverless-iam-role-per-function的插件。 此插件使按功能的IAM角色的应用变得更加容易。 请按照Github页面上的说明进行操作,然后自己尝试一下。
IAM策略未随Lambda版本化 (IAM policy not versioned with Lambda)
A shortcoming with Lambda and IAM configuration is that IAM policies are not versioned with the Lambda function.
Lambda和IAM配置的缺点是IAM策略未使用Lambda功能进行版本控制。
If you have multiple versions of the same function in active use (perhaps with different aliases), then it becomes problematic to add or remove permissions:
如果您正在使用同一功能的多个版本(可能具有不同的别名),则添加或删除权限会变得很成问题:
- Adding permissions to a new version allows older versions more access than they need 向新版本添加权限使旧版本的访问权限超出了所需
- Removing permissions from a new version can break older versions that still need those permissions 从新版本中删除权限可能会破坏仍需要这些权限的旧版本
Before 1.0, this was a common problem with the Serverless framework because it used aliases to implement stages. Since 1.0, this is no longer a problem, because each stage is deployed as a separate function. For example:
在1.0之前,这是无服务器框架的常见问题,因为它使用别名来实现阶段。 从1.0开始,这不再是问题,因为每个阶段都作为单独的功能部署。 例如:
service-function-dev
service-function-dev
service-function-staging
service-function-staging
service-function-prod
service-function-prod
This means only one version of each function is active at any moment in time. Except when you use aliases during a canary deployment.
这意味着每个功能在任何时候都只有一个版本处于活动状态。 除了在Canary部署期间使用别名时。
Account level isolation can also help mitigate the problems of adding/removing permissions. This isolation also helps compartmentalize security breaches. For example, a compromised function in a non-production account cannot be used to gain access to production data.
帐户 级别隔离还可以帮助减轻添加/删除权限的问题。 这种隔离还有助于划分安全漏洞。 例如,非生产帐户中的安全功能无法用于访问生产数据。
删除未使用的功能 (Delete unused functions)
One of the benefits of the serverless paradigm is that you don’t pay for functions when they’re not used.
无服务器模式的好处之一是,不用时不用为功能付费。
The flip side is that you have less incentive to remove unused functions since they don’t cost you anything. However, these functions still exist as attack surfaces. They are also more dangerous than active functions because they’re less likely to be updated and patched. Over time, these unused functions can become a hotbed for known vulnerabilities that attackers can exploit.
不利的一面是您没有动力删除未使用的功能,因为它们不会花费您任何费用。 但是,这些功能仍然作为攻击面存在。 它们也比活动功能更危险,因为它们不太可能被更新和打补丁。 随着时间的流逝,这些未使用的功能可能成为攻击者可以利用的已知漏洞的温床。
Lambda’s documentation also cites this as one of the best practices.
Lambda的文档也将其作为最佳实践之一 。
Delete old Lambda functions that you are no longer using.
删除不再使用的旧Lambda函数。
DoS攻击的面貌不断变化 (The changing face of DoS attacks)
With AWS Lambda, you are far more likely to scale your way out of a Denial-of-Service (DoS) attack. However, scaling your serverless architecture aggressively to fight a DoS attack with brute force has a significant cost implication.
使用AWS Lambda,您更有可能摆脱拒绝服务(DoS)攻击。 但是,积极地扩展无服务器体系结构以用蛮力抵抗DoS攻击具有重大的成本影响。
No wonder people started calling DoS attacks against serverless applications Denial of Wallet (DoW) attacks!
难怪人们开始将DoS攻击称为无服务器应用程序拒绝电子钱包(DoW)攻击!
“But you can just throttle the no. of concurrent invocations, right?”
“但是你可以限制不。 并发调用,对吗?”
Sure, and you end up with a DoS problem instead… it’s a lose-lose situation.
当然,您最终会遇到DoS问题……这是双输的情况。
Of course, there is AWS Shield. For a flat fee, AWS Shield Advanced gives you payment protection in the event of a DoS attack. But at the time of writing, this protection does not cover Lambda costs.
当然,还有AWS Shield 。 如果发生DoS攻击,AWS Shield Advanced会向您收取一定的费用,以支付一定的费用。 但在撰写本文时,此保护并不涵盖Lambda成本。
Also, Lambda has an at-least-once invocation policy. According to the folks at SunGard, this can result in up to three (successful) invocations. From the article, the reported rate of multiple invocations is extremely low, at 0.02%. But one wonders if the rate is tied to the load and might manifest itself at a much higher rate during a DoS attack.
而且,Lambda 至少有一次调用策略 。 据SunGard的人员称 ,这可能导致最多三个(成功)调用。 根据该文章,报告的多次调用率非常低,仅为0.02%。 但有人想知道速率是否与负载有关,是否可能在DoS攻击期间以更高的速率表现出来。
Furthermore, you need to consider how Lambda retries failed invocations by an asynchronous source. For example, S3, SNS, SES, and CloudWatch Events.
此外,您需要考虑Lambda如何重试 异步源 失败的调用 。 例如,S3,SNS,SES和CloudWatch Events。
Officially, these invocations are retried twice before they’re sent to the assigned Dead Letter Queue (DLQ) if one is configured. However, an analysis by OpsGenie showed that the number of retries can go up to as many as 6 before the invocation is sent to the DLQ.
正式地,如果已配置这些调用,则将它们重试两次,然后再将它们发送到分配的死信队列(DLQ)。 但是,OpsGenie的分析显示,在将调用发送到DLQ之前,重试次数最多可以达到6次。
If the DoS attacker is able to trigger failed async invocations then they can magnify the impact of their attack.
如果DoS攻击者能够触发失败的异步调用,则他们可以扩大攻击的影响 。
For example, if your application allows the client to update a file to S3 for processing. Then the attacker can DoS you by uploading large numbers of invalid files that will cause your functions to error and retry.
例如,如果您的应用程序允许客户端将文件更新到S3以进行处理。 然后,攻击者可以通过上传大量无效文件来对您进行DoS,这将导致您的功能出错并重试。
All these add up to the potential for the actual number of Lambda invocations to explode during a DoS attack. As we discussed earlier, while your infrastructure might be able to handle the attack, can your wallet stretch to the same extent? Should you allow it to?
所有这些加在一起可能导致DoS攻击期间实际Lambda调用数量激增。 正如我们前面所讨论的,虽然您的基础架构可能能够应对攻击, 但是您的钱包能否延展到同样的程度 ? 你应该允许吗?
保护外部数据 (Securing external data)
Due to the ephemeral nature of Lambda functions, chances are all your functions are stateless. More than ever, states are stored in external systems and we need to secure them both at rest and in-transit.
由于Lambda函数具有短暂性,因此所有函数都是无状态的。 状态比以往任何时候都更存储在外部系统中,我们需要保护它们在静止和传输期间的安全。
Communication to all AWS services happens via HTTPS and every request is signed and authenticated. A handful of AWS services also offer server-side encryption for your data at rest. For example, S3, RDS and Kinesis streams spring to mind. Lambda also has built-in integration with KMS to encrypt environment variables.
与所有AWS服务的通信都通过HTTPS进行,并且每个请求都经过签名和认证。 少数AWS服务还为静止数据提供服务器端加密。 例如, S3 , RDS和Kinesis流立即浮现 。 Lambda还与KMS内置集成以加密环境变量。
Recently DynamoDB has also announced support for encryption at-rest.
The same diligence needs to be applied when storing sensitive data in services/databases that do not offer built-in encryption. In the case of a data breach, it provides another layer of protection for your users’ data.
将敏感数据存储在不提供内置加密的服务/数据库中时,需要应用相同的注意事项。 如果发生数据泄露,它将为用户数据提供另一层保护。
We owe our users that much.
我们欠我们的用户那么多 。
Use secure transport when transmitting data to and from services (both external and internal ones). If you’re building APIs with API Gateway and Lambda then you’re forced to use HTTPS by default, which is a good thing. However, API Gateway endpoints are always public, you need to take the necessary precautions to secure access to internal APIs.
与服务(外部和内部)之间进行数据传输时,请使用安全传输。 如果您要使用API Gateway和Lambda构建API,那么默认情况下您将被迫使用HTTPS,这是一件好事。 但是,API网关端点始终是公共的,您需要采取必要的预防措施来保护对内部API的访问。
You should use IAM roles to protect internal APIs. It gives you fine-grained control over who can invoke which actions on which resources. Using IAM roles also spares you from awkward conversations like this:
您应该使用IAM角色来保护内部API。 它使您可以精确控制谁可以对哪些资源调用哪些操作。 使用IAM角色还可以避免像这样的尴尬对话:
“It’s X’s last day, he probably has our API keys on his laptop somewhere, should we rotate the API keys just in case?”
“这是X的最后一天,他可能在笔记本电脑上的某个地方有我们的API密钥,我们是否应该旋转API密钥以防万一?”
“Hmm.. that’d be a lot of work, X is trustworthy, he’s not gonna do anything.”
“嗯..那将是很多工作,X是值得信赖的,他不会做任何事情。”
“Ok… if you say so… (secretly prays that X doesn’t lose his laptop or develop a belated grudge against the company)”
“好吧……如果你这么说……(暗地里祈祷X不会丢失他的笔记本电脑或对公司产生迟来的怨恨)”
Fortunately, this can be easily configured using the Serverless
framework.
幸运的是,可以使用Serverless
框架轻松配置它。
凭证泄漏 (Leaked credentials)
The internet is full of horror stories of developers racking up a massive AWS bill after their leaked credentials are used to mine bitcoins. For every such story, many more have been affected but chose to stay silent. For the same reason, many security breaches are not disclosed publicly as companies do not want to lose face.
互联网上充斥着恐怖的故事,即开发人员在泄漏的凭证用于挖掘比特币后,ing起了大量的AWS账单。 对于每个这样的故事,更多的人受到了影响,但选择保持沉默。 出于同样的原因,许多安全漏洞没有公开披露,因为公司不想丢脸。
Even within my small social circle, I know of two such incidents. Neither were made public and both resulted in over $100k worth of damages. Fortunately, in both cases AWS agreed to cover the cost.
即使在我很小的社交圈中,我也知道两次这样的事件。 两者均未公开,均造成了超过10万美元的损失。 幸运的是,在两种情况下,AWS均同意承担费用。
AWS scans public Github repos for active AWS credentials and tries to alert you as soon as possible. But even if your credentials were public for a brief moment, it might not escape the watchful gaze of attackers. Plus, they still exist in Git commit history unless you rewrite the history, too. If your credentials came into the public domain then it’s best to deactivate the credentials as soon as possible.
AWS扫描公共Github仓库以获取活动的AWS凭证,并尝试尽快向您发出警报。 但是,即使您的凭据短暂公开,它也可能无法逃脱攻击者的注意。 另外,除非您也重写了历史记录,否则它们仍然存在于Git提交历史记录中。 如果您的凭据已进入公共领域,则最好尽快停用凭据。
A good approach to prevent AWS credential leaks is to use Git pre-commit hooks as outlined by this post.
一个好的方法来防止AWS凭据泄漏是使用Git的预提交挂钩由概述的这个帖子 。
From what I hear, attackers are most likely to launch EC2 instances in the Sao Paulo and Tokyo regions. You can use CloudWatch event patterns and Lambda to alert you when there are EC2 API calls in regions you’re not using. That way, you can at least react more quickly when your credentials are leaked.
据我了解,攻击者最有可能在圣保罗和东京地区启动EC2实例。 当您不使用的区域中有EC2 API调用时,您可以使用CloudWatch事件模式和Lambda来提醒您。 这样,当您的凭据泄漏时,您至少可以更快地做出React。
结论 (Conclusions)
We looked at a number of security threats to our serverless applications in this post. Many of them are the same threats that have plighted the software industry for years. All the OWASP top 10 still apply to us, including SQL, NoSQL, and other forms of injection attacks.
在这篇文章中,我们研究了对无服务器应用程序的许多安全威胁。 其中许多威胁已经困扰了软件行业多年。 所有OWASP前10名仍然适用于我们,包括SQL,NoSQL和其他形式的注入攻击。
Leaked AWS credentials remain a major issue and can impact any organisation that uses AWS. Whilst there are quite a few publicly reported incidents, I have a strong feeling that the actual number of incidents are much much higher.
AWS凭证泄漏仍然是一个主要问题,并且可能影响使用AWS的任何组织。 尽管有很多公开报道的事件,但我强烈认为实际事件数要高得多。
We are still responsible for securing our users’ data both at rest as well as in-transit. API Gateway is always publicly accessible, so we need to take the necessary precautions to secure access to our internal APIs, preferably with IAM roles. IAM offers fine-grained control over who can invoke which actions on your API resources, and make it easy to manage access when employees come and go.
我们仍然有责任保护用户的静态数据以及传输中的数据。 API网关始终是可公开访问的,因此我们需要采取必要的预防措施,以确保对内部API的访问(最好使用IAM角色)。 IAM提供了对谁可以调用您的API资源上的哪些操作的细粒度控制,并且使员工出入时易于管理访问。
On a positive note, having AWS take over the responsibility for the security of the host OS gives us a number of security benefits:
积极的一点是,让AWS接管主机OS的安全性将为我们带来许多安全优势:
- Protection against OS attacks, because AWS can do a much better job of patching known vulnerabilities in the OS 抵御OS攻击,因为AWS可以更好地修补OS中的已知漏洞
- Host OSs are ephemeral which means no long-lived compromised servers 主机操作系统是临时性的,这意味着不会存在寿命长的受到威胁的服务器
With API Gateway and Lambda, you don’t need web frameworks to create an API anymore. Without web frameworks, there is no easy way to support directory listing. But, that’s a good thing, because it makes a directory listing a concise design decision. No more accidental exposure of sensitive data through misconfiguration.
使用API Gateway和Lambda,您不再需要Web框架来创建API。 没有Web框架,就没有简单的方法来支持目录列表。 但这是一件好事,因为它使目录中列出了简洁的设计决策。 不会因配置错误而意外暴露敏感数据。
DoS attacks have taken a new form in the serverless world. While you’re able to scale your way out of an attack, it’ll still hurt you in the wallet instead. Lambda costs incurred during a DoS attack is not covered by AWS Shield Advanced at the time of writing.
在无服务器领域,DoS攻击已采用了一种新形式。 虽然您可以扩展自己的攻击方式,但仍然会伤害钱包。 DoS攻击期间发生的拉姆达成本在写作的时间不 涵盖 AWS盾高级 。
Meanwhile, some new attack surfaces have emerged with AWS Lambda:
同时,AWS Lambda出现了一些新的攻击面:
- Functions are often over-permissioned. A compromised function can do more harm than it might otherwise. 功能通常被过度使用。 受损的功能所造成的危害要大于其他方面。
- Unused functions are often left around for a long time, because there is no cost penalty. But attackers can exploit them. They’re also more likely to contain known vulnerabilities since they’re not actively maintained. 未使用的功能通常会保留很长时间,因为不会产生成本损失。 但是攻击者可以利用它们。 由于它们没有得到积极维护,因此它们更有可能包含已知漏洞。
Above all, the most worrisome threat for me are attacks against the package authors themselves. Many authors do not take the security of their accounts seriously. This endangers themselves as well as the rest of the community that depends on them. It’s difficult to guard against such attacks and erodes one of the strongest aspect of any software ecosystem — the community behind it.
最重要的是,对我来说,最令人担忧的威胁是对程序包作者本身的攻击。 许多作者并不认真考虑其帐户的安全性。 这危及自己以及依赖他们的社区其他人。 很难防范此类攻击并侵蚀任何软件生态系统最强大的方面之一(即其背后的社区)。
Once again, people have proven to be the weakest link in the security chain.
再次证明,人们是安全链中最薄弱的环节。
云服务器面临的问题