云服务器面临的问题_无服务器安全面临的多方面威胁以及我们应如何应对

云服务器面临的问题

by Yan Cui

崔燕

无服务器安全面临的多方面威胁以及我们应如何应对 (The many-faced threats to Serverless security, and how we should address them)

Threats to the security of our server­less appli­ca­tions take many forms. Some are old foes we have faced before. Some are new. And some have taken on new forms in the server­less world.

对无服务器应用程序安全性的威胁有多种形式。 有些是我们以前遇到过的老敌人。 有些是新的。 在无服务器世界中，有些已经采取了新的形式。

As we adopt the server­less par­a­digm, we del­e­gate even more operational respon­si­bil­i­ties to our cloud providers. With AWS Lambda, you no longer have to con­fig­ure AMIs, patch the OS, and install monitoring dae­mons. AWS takes care all that for you.

当我们采用无服务器模式时，我们将更多的运营责任委托给了云提供商。 使用AWS Lambda，您不再需要配置AMI，打补丁OS和安装监控后台程序。 AWS会为您全力以赴。

What does this mean for the Shared Respon­si­bil­i­ty Mod­el that has long been the cor­ner­stone of secu­ri­ty in the AWS cloud?

什么这是否意味着为分担责任模式是早已安全的AWS的云的基石？

防范针对操作系统的攻击 (Protection from attacks against the OS)

AWS takes over the respon­si­bil­i­ty for main­tain­ing the host OS as part of their core com­pe­ten­cy. This alleviates you of the rig­or­ous task of apply­ing all the latest secu­ri­ty patch­es. This is something most of us don’t do a good enough job of, as it’s not our pri­ma­ry focus.

AWS负责维护主机操作系统，这是其核心竞争力的一部分。 这减轻了您应用所有最新安全补丁的严格任务。 这是我们大多数人做不到的事情，因为这不是我们的主要重点。

In doing so, it pro­tects us from attacks against known vul­ner­a­bil­i­ties in the OS and pre­vents attacks such as Wan­naCry.

这样，它可以保护我们免受针对操作系统中已知漏洞的攻击，并防止诸如WannaCry之类的攻击。

By remov­ing long-lived servers from the pic­ture, we are also removing the threats posed by com­pro­mised servers that live in our envi­ron­ment for a long time.

通过从图片中删除长期存在的服务器，我们还消除了长期存在于我们环境中的受感染服务器所带来的威胁。

How­ev­er, it is still our respon­si­bil­i­ty to patch our appli­ca­tion and address vul­ner­a­bil­i­ties that exist in our code and our depen­den­cies.

但是，修补应用程序并解决代码和依赖项中存在的漏洞仍然是我们的责任。

OWASP前10名仍然像以往一样重要 (OWASP top 10 is still as relevant as ever)

A glance at the OWASP top 10 for 2017 shows us famil­iar threats. Injec­tion attacks, Broken Authentication, and Cross-Site Script­ing (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 breach­es in 2016, they found that 12 of the top 50 data breach­es were caused by appli­ca­tions using com­po­nents with known vul­ner­a­bil­i­ties.

当在人Snyk在2016搜索的1792所数据破坏的数据集，他们发现， 在顶部50 的数据泄露 的12通过使用与组分已知的漏洞的应用引起的。

Fur­ther­more, 77% of the top 5000 URLs from Alexa include at least one vul­ner­a­ble library. This is less sur­pris­ing than it first sounds when you con­sid­er that some of the most pop­u­lar front-end js frame­works — eg. jQuery, Angu­lar and React — all had known vul­ner­a­bil­i­ties. It high­lights the need to con­tin­u­ous­ly update and patch your depen­den­cies.

此外， 来自Alexa的前5000个URL中的77％至少包含一个易受攻击的库 。 当您考虑到一些最流行的前端js框架时，这并不比最初听起来的令人惊讶。 jQuery ， Angular和React —都具有已知漏洞。 它强调了不断更新和修补依赖项的需求。

Unlike OS patch­es, which are stand­alone, trust­ed and easy to apply. Secu­ri­ty updates to 3rd par­ty depen­den­cies are often bun­dled with fea­ture and API changes that need to be inte­grat­ed and test­ed. It makes our life as devel­op­ers dif­fi­cult. It’s yet anoth­er thing we have to do when we’re work­ing over­time to ship new fea­tures.

与OS修补程序不同，后者是独立的，可信任的且易于应用。 对第三方依赖关系的安全更新通常与功能和API更改捆绑在一起，需要进行集成和测试。 这使我们作为开发人员的生活变得困难。 当我们加班工作以发布新功能时，这是我们要做的另一件事。

And then there’s the mat­ter of tran­sient depen­den­cies. If these tran­sient depen­den­cies have vul­ner­a­bil­i­ties, then you too are vul­ner­a­ble through your direct depen­den­cies.

然后就是瞬时依赖的问题。 如果这些临时依赖项存在漏洞，那么您也将通过直接依赖项受到攻击。

Find­ing vul­ner­a­bil­i­ties in our depen­den­cies is hard work and requires constant dili­gence. Which is why ser­vices such as Snyk is so use­ful. It even comes with a built-in inte­gra­tion with Lamb­da, too!

在我们的依存关系中寻找漏洞是一项艰巨的工作，需要不断努力。 这就是为什么诸如Snyk之类的服务如此有用的原因。 它甚至还带有与Lambda的内置集成 ！

攻击NPM发布者 (Attacks against NPM publishers)

Last year, a secu­ri­ty boun­ty hunter man­aged to gain direct push rights to 14% of NPM pack­ages. The list of affect­ed pack­ages 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 pack­ages account for 20% of the total num­ber of month­ly down­loads 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 sophis­ti­cat­ed meth­ods to cir­cum­vent NPM’s secu­ri­ty?

他是否使用复杂的方法来规避NPM的安全性？

Nope, it was a com­bi­na­tion of brute force and using known account and credential leaks from a num­ber of sources includ­ing Github. In oth­er words, any­one could have pulled these off with very lit­tle research.

不，这是蛮力和使用已知帐户以及来自包括Github在内的许多来源的凭据泄漏的结合。 换句话说，只要很少的研究，任何人都可以实现这些目标。

It’s hard not to feel let down by these pack­age authors when so many dis­play such a cav­a­lier atti­tude towards secur­ing access to their NPM accounts.

当这么多软件包的开发者对确保获取其NPM帐户的访问权限表现出如此轻率的态度时，很难不感到失望。

662 users had pass­word «123456», 174 — «123», 124 — «password».

662位用户拥有密码« 123456 »，174 —« 123 »，124 —« password »。

1409 users (1%) used their user­name as their pass­word, in its orig­i­nal form, with­out any mod­i­fi­ca­tions.

1409个用户(占1％)以其原始形式使用用户名作为密码，未经任何修改。

11% of users reused their leaked pass­words: 10.6% — direct­ly, and 0.7% — with minor mod­i­fi­ca­tions.

11％的用户重复使用了泄漏的密码：直接修改的密码为10.6％，直接修改的密码为0.7％。

As I demon­strat­ed in my talk on Server­less secu­ri­ty, you can steal tem­po­rary AWS cre­den­tials by adding a few lines of code.

正如我在无服务器安全性演讲中所演示的那样 ，您可以通过添加几行代码来窃取临时AWS凭证。

Imag­ine, then, a sce­nario where an attack­er had man­aged to gain push rights to 14% of all NPM pack­ages. He could pub­lish a patch update to all these pack­ages and steal AWS cre­den­tials at a mas­sive scale.

想象一下，攻击者设法获得了所有NPM软件包的14％的推送权限。 他可以为所有这些软件包发布补丁更新，并大规模窃取AWS凭证。

The stakes are high and it’s pos­si­bly the biggest secu­ri­ty threat we face in the server­less world. And, it also impacts applications running inside EC2 or containers.

风险很高，这可能是我们在无服务器世界中面临的最大安全威胁。 而且，它还会影响在EC2或容器中运行的应用程序。

The prob­lems and risks with pack­age man­age­ment are not spe­cif­ic to the Node.js ecosys­tem. I have spent most of my career work­ing with .Net and now Scala, and pack­age man­age­ment has been a chal­lenge every­where. We need package authors to exer­cise due diligence towards the security of their accounts.

程序包管理的问题和风险并非特定于Node.js生态系统。 我一生的大部分时间都在.Net以及现在的Scala上工作，而软件包管理一直是一个挑战。 我们需要软件包作者对其帐户的安全性进行尽职调查 。

A1-注射剂和A3-XSS (A1 — Injection & A3 — XSS)

SQL injec­tion and oth­er forms of injec­tion attacks are still pos­si­ble in the server­less world. As are Cross-Site Script­ing (XSS) attacks.

在无服务器世界中，SQL注入和其他形式的注入攻击仍然可能。 跨站点脚本(XSS)攻击也是如此。

Even if you’re using NoSQL data­bas­es you might not be safe from injec­tion attacks either. Mon­goDB, for instance, expos­es a num­ber of attack vec­tors through its query APIs.

即使您使用的是NoSQL数据库，也可能无法免受注入攻击。 例如，MongoDB通过其查询API公开了许多攻击媒介 。

DynamoDB’s more rigid API makes an injection attack harder. But you’re still open to oth­er forms of exploits. For example, XSS and leaked cre­den­tials which grant attack­er access to DynamoDB tables.

DynamoDB更严格的API使得注入攻击更加困难。 但是您仍然可以接受其他形式的攻击。 例如，XSS和泄露的凭据使攻击者可以访问DynamoDB表。

Nonethe­less, you should always san­i­tize user inputs, as well as the out­put from your Lamb­da func­tions.

但是，您应该始终清除用户输入以及Lambda函数的输出。

A6 —敏感数据暴露 (A6 — Sensitive Data Exposure)

Along with servers, web frame­works are also redundant when you move to the server­less par­a­digm. These web frame­works have served us well for many years. But they also hand­ed us a loaded gun we can shot our­selves in the foot with.

与服务器一起，当移至无服务器模式时，Web框架也是多余的。 这些网络框架已经为我们服务了很多年。 但是他们也给了我们一把装满枪的枪，我们可以用它开枪射击自己的脚。

Troy Hunt demon­strat­ed how we can acci­den­tal­ly expose all kinds of sen­si­tive data by leav­ing direc­to­ry list­ing options ON. From web.config con­tain­ing cre­den­tials (at 35:28) to SQL back­ups files (at 1:17:28)!

特洛伊·亨特(Troy Hunt) 演示了如何通过保持目录列表选项为开来意外地暴露各种敏感数据。 从包含凭据的web.config(在35:28)到SQL备份文件(在1:17:28)！

With API Gate­way and Lamb­da, acci­den­tal expo­sures like this are very unlike­ly. Because direc­to­ry list­ing becomes a “fea­ture” you’d have to imple­ment your­self. It forces you to make a con­scious decision about when to sup­port direc­to­ry list­ing, and the answer is likely nev­er.

随着API网关和Lambda，像这样的意外接触是不太可能。 因为目录列表成为“功能”，所以您必须实现自己。 它迫使您对何时支持目录列表做出有意识的决定，而答案可能更重要。

我是 (IAM)

If your func­tions are com­pro­mised, the next line of defense is to restrict what the com­pro­mised func­tions can do.

如果您的功能受到损害，则下一道防线是限制受到损害的功能可以做什么。

This is why you need to apply the Least Priv­i­lege Prin­ci­ple when con­fig­ur­ing Lamb­da per­mis­sions.

这就是配置Lambda权限时需要应用“ 最低权限”原则的原因 。

In the Serverless frame­work, the default behav­iour is to use the same IAM role for all func­tions in the ser­vice.

在无服务器框架中，默认行为是对服务中的所有功能使用相同的IAM角色。

How­ev­er, the serverless.yml spec allows you to spec­i­fy a dif­fer­ent IAM role per func­tion. But it involves a lot more devel­op­ment effort and adds enough fric­tion 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 short­com­ing with Lamb­da and IAM con­fig­u­ra­tion is that IAM poli­cies are not ver­sioned with the Lamb­da func­tion.

Lambda和IAM配置的缺点是IAM策略未使用Lambda功能进行版本控制。

If you have mul­ti­ple ver­sions of the same func­tion in active use (per­haps with dif­fer­ent alias­es), then it becomes prob­lem­at­ic to add or remove per­mis­sions:

如果您正在使用同一功能的多个版本(可能具有不同的别名)，则添加或删除权限会变得很成问题：

• Adding per­mis­sions to a new ver­sion allows older ver­sions more access than they need
  向新版本添加权限使旧版本的访问权限超出了所需
• Remov­ing per­mis­sions from a new ver­sion can break older versions that still need those per­mis­sions
  从新版本中删除权限可能会破坏仍需要这些权限的旧版本

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 sep­a­rate 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 lev­el iso­la­tion can also help mit­i­gate the prob­lems of adding/removing per­mis­sions. This iso­la­tion also helps compartmentalize secu­ri­ty breach­es. For example, a compromised func­tion in a non-pro­duc­tion account can­not be used to gain access to pro­duc­tion data.

帐户 级别隔离还可以帮助减轻添加/删除权限的问题。 这种隔离还有助于划分安全漏洞。 例如，非生产帐户中的安全功能无法用于访问生产数据。

删除未使用的功能 (Delete unused functions)

One of the ben­e­fits of the server­less par­a­digm is that you don’t pay for func­tions 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. How­ev­er, these func­tions still exist as attack sur­faces. They are also more dangerous than active­ func­tions because they’re less like­ly to be updat­ed and patched. Over time, these unused func­tions can become a hotbed for known vul­ner­a­bil­i­ties that attack­ers can exploit.

不利的一面是您没有动力删除未使用的功能，因为它们不会花费您任何费用。 但是，这些功能仍然作为攻击面存在。 它们也比活动功能更危险，因为它们不太可能被更新和打补丁。 随着时间的流逝，这些未使用的功能可能成为攻击者可以利用的已知漏洞的温床。

Lambda’s doc­u­men­ta­tion also cites this as one of the best prac­tices.

Lambda的文档也将其作为最佳实践之一 。

Delete old Lamb­da func­tions that you are no longer using.

删除不再使用的旧Lambda函数。

DoS攻击的面貌不断变化 (The changing face of DoS attacks)

With AWS Lamb­da, you are far more like­ly to scale your way out of a Denial-of-Service (DoS) attack. How­ev­er, scal­ing your server­less archi­tec­ture aggressively to fight a DoS attack with brute force has a sig­nif­i­cant cost implication.

使用AWS Lambda，您更有可能摆脱拒绝服务(DoS)攻击。 但是，积极地扩展无服务器体系结构以用蛮力抵抗DoS攻击具有重大的成本影响。

No won­der peo­ple start­ed call­ing DoS attacks against server­less appli­ca­tions Denial of Wal­let (DoW) attacks!

难怪人们开始将DoS攻击称为无服务器应用程序拒绝电子钱包(DoW)攻击！

“But you can just throt­tle the no. of con­cur­rent invo­ca­tions, right?”

“但是你可以限制不。 并发调用，对吗？”

Sure, and you end up with a DoS prob­lem instead… it’s a lose-lose sit­u­a­tion.

当然，您最终会遇到DoS问题……这是双输的情况。

Of course, there is AWS Shield. For a flat fee, AWS Shield Advanced gives you payment pro­tec­tion in the event of a DoS attack. But at the time of writ­ing, this pro­tec­tion does not cov­er Lamb­da costs.

当然，还有AWS Shield 。 如果发生DoS攻击，AWS Shield Advanced会向您收取一定的费用，以支付一定的费用。 但在撰写本文时，此保护并不涵盖Lambda成本。

Also, Lamb­da has an at-least-once invo­ca­tion pol­i­cy. Accord­ing to the folks at Sun­Gard, this can result in up to three (suc­cess­ful) invo­ca­tions. From the arti­cle, the report­ed rate of mul­ti­ple invo­ca­tions is extreme­ly low, at 0.02%. But one won­ders if the rate is tied to the load and might man­i­fest itself at a much high­er rate dur­ing a DoS attack.

而且，Lambda 至少有一次调用策略 。 据SunGard的人员称 ，这可能导致最多三个(成功)调用。 根据该文章，报告的多次调用率非常低，仅为0.02％。 但有人想知道速率是否与负载有关，是否可能在DoS攻击期间以更高的速率表现出来。

Fur­ther­more, you need to con­sid­er how Lamb­da retries failed invo­ca­tions by an asyn­chro­nous source. For example, S3, SNS, SES, and Cloud­Watch Events.

此外，您需要考虑Lambda如何重试 异步源 失败的调用 。 例如，S3，SNS，SES和CloudWatch Events。

Offi­cial­ly, these invo­ca­tions are retried twice before they’re sent to the assigned Dead Letter Queue (DLQ) if one is configured. How­ev­er, an analy­sis by Ops­Ge­nie showed that the number of retries can go up to as many as 6 before the invo­ca­tion 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 poten­tial for the actu­al number of Lamb­da invocations to explode dur­ing a DoS attack. As we dis­cussed ear­li­er, while your infra­struc­ture might be able to han­dle the attack, can your wal­let stretch to the same extent? Should you allow it to?

所有这些加在一起可能导致DoS攻击期间实际Lambda调用数量激增。 正如我们前面所讨论的，虽然您的基础架构可能能够应对攻击， 但是您的钱包能否延展到同样的程度 ？ 你应该允许吗？

保护外部数据 (Securing external data)

Due to the ephemer­al nature of Lamb­da func­tions, chances are all your functions are state­less. More than ever, states are stored in exter­nal sys­tems and we need to secure them both at rest and in-tran­sit.

由于Lambda函数具有短暂性，因此所有函数都是无状态的。 状态比以往任何时候都更存储在外部系统中，我们需要保护它们在静止和传输期间的安全。

Com­mu­ni­ca­tion to all AWS ser­vices happens via HTTPS and every request is signed and authen­ti­cat­ed. A hand­ful of AWS ser­vices also offer serv­er-side encryp­tion for your data at rest. For example, S3, RDS and Kine­sis streams spring to mind. Lamb­da also has built-in inte­gra­tion with KMS to encrypt envi­ron­ment vari­ables.

与所有AWS服务的通信都通过HTTPS进行，并且每个请求都经过签名和认证。 少数AWS服务还为静止数据提供服务器端加密。 例如， S3 ， RDS和Kinesis流立即浮现 。 Lambda还与KMS内置集成以加密环境变量。

Recently DynamoDB has also announced support for encryption at-rest.

最近，DynamoDB还宣布了对静态加密的支持 。

The same dili­gence needs to be applied when stor­ing sen­si­tive data in services/databases that do not offer built-in encryp­tion. In the case of a data breach, it pro­vides anoth­er lay­er of pro­tec­tion for your users’ data.

将敏感数据存储在不提供内置加密的服务/数据库中时，需要应用相同的注意事项。 如果发生数据泄露，它将为用户数据提供另一层保护。

We owe our users that much.

我们欠我们的用户那么多 。

Use secure trans­port when trans­mit­ting data to and from ser­vices (both exter­nal and inter­nal ones). If you’re build­ing APIs with API Gate­way and Lamb­da then you’re forced to use HTTPS by default, which is a good thing. How­ev­er, API Gate­way endpoints are always public, you need to take the nec­es­sary pre­cau­tions to secure access to inter­nal APIs.

与服务(外部和内部)之间进行数据传输时，请使用安全传输。 如果您要使用API​​ Gateway和Lambda构建API，那么默认情况下您将被迫使用HTTPS，这是一件好事。 但是，API网关端点始终是公共的，您需要采取必要的预防措施来保护对内部API的访问。

You should use IAM roles to protect internal APIs. It gives you fine-grained con­trol over who can invoke which actions on which resources. Using IAM roles also spares you from awk­ward con­ver­sa­tions like this:

您应该使用IAM角色来保护内部API。 它使您可以精确控制谁可以对哪些资源调用哪些操作。 使用IAM角色还可以避免像这样的尴尬对话：

“It’s X’s last day, he prob­a­bly has our API keys on his lap­top some­where, should we rotate the API keys just in case?”

“这是X的最后一天，他可能在笔记本电脑上的某个地方有我们的API密钥，我们是否应该旋转API密钥以防万一？”

“Hmm.. that’d be a lot of work, X is trust­wor­thy, he’s not gonna do any­thing.”

“嗯..那将是很多工作，X是值得信赖的，他不会做任何事情。”

“Ok… if you say so… (secret­ly prays that X doesn’t lose his lap­top or devel­op a belat­ed grudge against the com­pa­ny)”

“好吧……如果你这么说……(暗地里祈祷X不会丢失他的笔记本电脑或对公司产生迟来的怨恨)”

For­tu­nate­ly, this can be eas­i­ly con­fig­ured using the Serverless frame­work.

幸运的是，可以使用Serverless框架轻松配置它。

凭证泄漏 (Leaked credentials)

The inter­net is full of hor­ror sto­ries of devel­op­ers rack­ing up a mas­sive AWS bill after their leaked cre­den­tials are used to mine bit­coins. For every such sto­ry, many more have been affect­ed but chose to stay silent. For the same reason, many secu­ri­ty breach­es are not disclosed pub­licly as com­pa­nies do not want to lose face.

互联网上充斥着恐怖的故事，即开发人员在泄漏的凭证用于挖掘比特币后，ing起了大量的AWS账单。 对于每个这样的故事，更多的人受到了影响，但选择保持沉默。 出于同样的原因，许多安全漏洞没有公开披露，因为公司不想丢脸。

Even with­in my small social cir­cle, I know of two such inci­dents. Nei­ther were made pub­lic and both result­ed in over $100k worth of dam­ages. For­tu­nate­ly, in both cas­es AWS agreed to cov­er the cost.

即使在我很小的社交圈中，我也知道两次这样的事件。 两者均未公开，均造成了超过10万美元的损失。 幸运的是，在两种情况下，AWS均同意承担费用。

AWS scans pub­lic Github repos for active AWS cre­den­tials and tries to alert you as soon as pos­si­ble. But even if your cre­den­tials were public for a brief moment, it might not escape the watch­ful gaze of attack­ers. Plus, they still exist in Git com­mit his­to­ry unless you rewrite the his­to­ry, too. If your credentials came into the public domain then it’s best to deac­ti­vate the cre­den­tials as soon as possible.

AWS扫描公共Github仓库以获取活动的AWS凭证，并尝试尽快向您发出警报。 但是，即使您的凭据短暂公开，它也可能无法逃脱攻击者的注意。 另外，除非您也重写了历史记录，否则它们仍然存在于Git提交历史记录中。 如果您的凭据已进入公共领域，则最好尽快停用凭据。

A good approach to pre­vent AWS cre­den­tial leaks is to use Git pre-com­mit hooks as out­lined 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 num­ber of secu­ri­ty threats to our server­less appli­ca­tions in this post. Many of them are the same threats that have plight­ed the soft­ware indus­try for years. All the OWASP top 10 still apply to us, includ­ing SQL, NoSQL, and oth­er forms of injec­tion attacks.

在这篇文章中，我们研究了对无服务器应用程序的许多安全威胁。 其中许多威胁已经困扰了软件行业多年。 所有OWASP前10名仍然适用于我们，包括SQL，NoSQL和其他形式的注入攻击。

Leaked AWS cre­den­tials remain a major issue and can impact any organ­i­sa­tion that uses AWS. Whilst there are quite a few pub­licly report­ed inci­dents, I have a strong feel­ing that the actu­al number of inci­dents are much much high­er.

AWS凭证泄漏仍然是一个主要问题，并且可能影响使用AWS的任何组织。 尽管有很多公开报道的事件，但我强烈认为实际事件数要高得多。

We are still respon­si­ble for secur­ing our users’ data both at rest as well as in-tran­sit. API Gate­way is always pub­licly acces­si­ble, so we need to take the nec­es­sary pre­cau­tions to secure access to our inter­nal APIs, prefer­ably with IAM roles. IAM offers fine-grained con­trol over who can invoke which actions on your API resources, and make it easy to man­age access when employ­ees come and go.

我们仍然有责任保护用户的静态数据以及传输中的数据。 API网关始终是可公开访问的，因此我们需要采取必要的预防措施，以确保对内部API的访问(最好使用IAM角色)。 IAM提供了对谁可以调用您的API资源上的哪些操作的细粒度控制，并且使员工出入时易于管理访问。

On a pos­i­tive note, hav­ing AWS take over the respon­si­bil­i­ty for the secu­ri­ty of the host OS gives us a number of secu­ri­ty ben­e­fits:

积极的一点是，让AWS接管主机OS的安全性将为我们带来许多安全优势：

• Pro­tec­tion against OS attacks, because AWS can do a much bet­ter job of patch­ing known vul­ner­a­bil­i­ties in the OS
  抵御OS攻击，因为AWS可以更好地修补OS中的已知漏洞
• Host OSs are ephemer­al which means no long-lived com­pro­mised 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 tak­en a new form in the server­less world. While you’re able to scale your way out of an attack, it’ll still hurt you in the wal­let instead. Lamb­da costs incurred dur­ing a DoS attack is not cov­ered by AWS Shield Advanced at the time of writ­ing.

在无服务器领域，DoS攻击已采用了一种新形式。 虽然您可以扩展自己的攻击方式，但仍然会伤害钱包。 DoS攻击期间发生的拉姆达成本在写作的时间不 涵盖 AWS盾高级 。

Mean­while, some new attack sur­faces have emerged with AWS Lamb­da:

同时，AWS Lambda出现了一些新的攻击面：

• Func­tions are often over-per­mis­sioned. A com­pro­mised func­tion can do more harm than it might oth­er­wise.
  功能通常被过度使用。 受损的功能所造成的危害要大于其他方面。
• Unused func­tions are often left around for a long time, because there is no cost penalty. But attack­ers can exploit them. They’re also more like­ly to con­tain known vul­ner­a­bil­i­ties since they’re not actively maintained.
  未使用的功能通常会保留很长时间，因为不会产生成本损失。 但是攻击者可以利用它们。 由于它们没有得到积极维护，因此它们更有可能包含已知漏洞。

Above all, the most wor­ri­some threat for me are attacks against the pack­age authors them­selves. Many authors do not take the secu­ri­ty of their accounts seri­ous­ly. This endan­gers them­selves as well as the rest of the com­mu­ni­ty that depends on them. It’s difficult to guard against such attacks and erodes one of the strongest aspect of any soft­ware ecosys­tem — the com­mu­ni­ty behind it.

最重要的是，对我来说，最令人担忧的威胁是对程序包作者本身的攻击。 许多作者并不认真考虑其帐户的安全性。 这危及自己以及依赖他们的社区其他人。 很难防范此类攻击并侵蚀任何软件生态系统最强大的方面之一(即其背后的社区)。

Once again, peo­ple have proven to be the weak­est link in the secu­ri­ty chain.

再次证明，人们是安全链中最薄弱的环节。

翻译自: https://www.freecodecamp.org/news/the-many-faced-threats-to-serverless-security-and-how-we-should-address-them-c0d24dc43a66/

云服务器面临的问题