无服务器应用程序中的出口过滤

Nobody cares about security. The only people who really care are under regulatory compliance to do so and are usually under more assault from their own developers in their desperate quest to get things done than hackers. With the rise of serverless computing and cloud-native applications, the flood gates are open. Agile software development teams are spinning up code in ephemeral environments that are compliance officer’s worst nightmare. But an often-overlooked security threat is egress filtering, especially if you use NPM and NodeJS.

没有人关心安全性。 唯一真正关心的人是在法规遵从下这样做的人，通常他们自己的开发者比黑客更迫切地寻求完成任务，因此他们受到的攻击更多。 随着无服务器计算和云原生应用程序的兴起，洪水的大门已打开。 敏捷软件开发团队正在临时环境中整理代码，这是合规官最可怕的噩梦。 但是，经常被忽略的安全威胁是出口过滤，尤其是在使用NPM和NodeJS的情况下。

什么是出口过滤 (What is Egress Filtering)

“In computer networking, egress filtering is the practice of monitoring and potentially restricting the flow of information outbound from one network to another.” — wikipedia.org.

“在 计算机网络中 ，出口过滤是监视并可能限制从一个网络到另一个网络的信息流的实践。” — wikipedia.org 。

That’s a pretty good definition. In serverless applications, your code can run in a “public” VPC that is wide open to the internet, or in a private VPC which has no internet access by default. What most developers fail to recognize is that any code, including the hundreds (if not thousands) of NPM packages you are consuming, can also connect to internet resources and transfer data. The worst part is you won’t know about it unless you block internet access or perform egress filtering. To say this is a bit worrisome is an understatement. It’s a major issue that needs to be addressed as part of your architecture.

这是一个很好的定义。 在无服务器应用程序中，您的代码可以在对Internet敞开的“公共” VPC中运行，也可以在默认情况下无法访问Internet的私有VPC中运行。 大多数开发人员无法识别的是，任何代码(包括您正在使用的数百个(如果不是数千个)NPM软件包)也可以连接到Internet资源并传输数据。 最糟糕的是，除非您阻止Internet访问或执行出口过滤，否则您将一无所知。 说这有点令人担忧是轻描淡写。 这是一个主要问题，需要作为体系结构的一部分加以解决。

Most developers opt for optimization (usually premature) over security. One of the most common go-to mistakes is to use a public VPC instead of executing functions in a private VPC. Developers will explain that a private VPC adds to cold start times. They may even opt to publicly expose APIs and other resources to avoid using a private VPC. While the new AWS Hyperplane and Provisioned Concurrency have alleviated most of these concerns, I’m surprised how many developers still cling to this argument. I’m all for using the right tool for the job, but if you are dealing in any way with private data security needs to trump performance.

大多数开发人员选择对安全性进行优化(通常为时过早)。 最常见的常见错误之一是使用公共VPC而不是在私有VPC中执行功能。 开发人员将说明，专用VPC增加了冷启动时间。 他们甚至可以选择公开公开API和其他资源，以避免使用私有VPC。 尽管新的AWS Hyperplane和Provisioning Concurrency减轻了大多数此类顾虑，但令我惊讶的是仍然有如此多的开发人员坚持这种观点。 我全都使用正确的工具来完成这项工作，但是如果您以任何方式处理私有数据安全性，则都需要压倒性能。

为什么要担心 (Why you should be concerned)

1. PCI Compliance: Ingress/Egress filtering is a requirement.
   PCI合规性：入口/出口过滤是必需的。
2. GDPR Compliance: Data needs to stay within the region it originates.
   GDPR合规性：数据需要保留在其来源区域内。
3. HIPPA and COPPA Compliance: You need consent to access and share data. Data of all parties must remain private.
   HIPPA和COPPA合规性：您需要同意才能访问和共享数据。 各方的数据必须保密。
4. User expectation of privacy: Most users expect you aren’t going to transfer their photos, text, emails, and other data to Ukrainian bots.
   用户对隐私的期望：大多数用户期望您不会将其照片，文本，电子邮件和其他数据传输给乌克兰机器人。
5. “Go to Prison Data”: This is most relevant to the internal line of business applications where secure data (often being delivered to or from a business partner) is exposed because of developer negligence.
   “转到监狱数据”：这与内部业务应用程序最相关，在内部业务应用程序中，由于开发人员的疏忽而暴露了安全数据(通常是向业务伙伴发送或从业务伙伴处传递)。

A general rule of thumb: if the information isn’t public then you need to make sure it stays in a secure location.

一般的经验法则：如果信息不是公开的，则需要确保其位于安全的位置。

有记录的违规 (Documented Breaches)

If you think this is an edge case, just create some Google fodder using “npm package security breach”. And if you think Maven is immune to this type of issue think again. Anytime you consume third party software you take third party risks!

如果您认为这是一个极端情况，只需使用“ npm软件包安全漏洞”创建一些Google饲料。 如果您认为Maven不受此类问题的影响，请再考虑一下。 每当您使用第三方软件时，都将承担第三方风险！

解决方案 (Solutions)

1. Use private endpoints and block all outbound traffic. But not all AWS services support private endpoints (CodeDeploy at the time of writing).
   使用专用端点并阻止所有出站流量。 但是，并非所有的AWS服务都支持私有终结点(在编写本文时为CodeDeploy)。

2. Add a NAT Gateway to filter outbound traffic

   添加NAT网关以过滤出站流量

3. Purchase a solution from a third party.

   从第三方购买解决方案。

结论 (Conclusion)

While there are some solutions that meet the majority of use cases, egress filtering can be a pain the rear. This doesn’t mean you should scrap it, it means you should plan for it ahead of time and budget time and resources accordingly. Serverless is a dream, but it can quickly become a nightmare if you don’t do your part and ensure your application is secure.

尽管有一些解决方案可以满足大多数用例，但是出口过滤可能会给您带来痛苦。 这并不意味着您应该废弃它，而是意味着您应该提前计划，并相应地预算时间和资源。 无服务器是一个梦想，但如果您不做自己的事并确保应用程序安全，它很快就会成为噩梦。

翻译自: https://medium.com/swlh/egress-filtering-in-serverless-applications-25c2953a7290