服务器 解决方案
In recent years, the growth of Serverless has been monumental. More and more organisations are realising the benefits of the technology of not having to manage the underlying infrastructure and being able to scale on demand. Much of the growth has been haphazard and without a strategy which has lead to security being much of an afterthought.
近年来，Serverless的增长具有里程碑式的意义。 越来越多的组织正在意识到该技术的好处，即不必管理底层基础结构并能够按需扩展。 大部分增长都是偶然的，没有能够导致安全性成为后事的战略。
This article will describe how an organisation can protect its Serverless solution. It will focus on solutions deployed in AWS with its Serverless offering, Lambda. Nevertheless, many of the principles can be applied to all cloud platforms.
本文将介绍组织如何保护其无服务器解决方案。 它将专注于通过其无服务器产品Lambda在AWS中部署的解决方案。 但是，许多原理可以应用于所有云平台。
为什么无服务器解决方案不安全？ (Why are Serverless Solutions Insecure?)
Serverless technology enforces the use of microservice design patterns. This results in numerous, small services performing unique functionality. With many services, the organisation can develop Serverless Sprawl and can lead to unknown, unmanaged and insecure Serverless solutions.
无服务器技术强制使用微服务设计模式。 这导致许多小型服务执行独特的功能。 借助许多服务，组织可以开发无服务器蔓延和 可能导致未知，不受管理和不安全的无服务器解决方案。
无服务器的组成部分 (The Components of Serverless)
At the core of all Serverless solutions will be a form of programming language or code. Any solution will require various touchpoints and integrations such as data stores and orchestration technologies. These components will form part of the entire solution and therefore the security of each of them is just as important as the code itself.
所有无服务器解决方案的核心都是一种编程语言或代码。 任何解决方案都需要各种接触点和集成，例如数据存储和编排技术。 这些组件将构成整个解决方案的一部分，因此，每个组件的安全性与代码本身一样重要。
成本效益分析 (Cost-Benefit Analysis)
The first step in securing any solution is to perform a Cost-Benefit Analysis. This involves identifying the components of the Serverless solution that is being considered. A risk assessment is then performed. The impact and the likelihood of the loss of part or the entire solution must be determined using both a quantitative and qualitative approach. The resulting risk assessment will determine how important the solution is to the organisation. It will assist in the understanding of the approach to risk that will be taken; whether the risk should be mitigated, accepted, avoided or transferred. The total cost of security controls implemented should always be less than the cost of the loss of the system.
确保任何解决方案的第一步是执行成本效益分析。 这涉及确定正在考虑的无服务器解决方案的组件。 然后进行风险评估。 必须使用定量和定性方法来确定部分或整个解决方案的影响和损失的可能性。 最终的风险评估将确定解决方案对组织的重要性。 它将有助于理解将要采取的风险方法； 是否应减轻，接受，避免或转移风险。 实施的安全控制的总成本应始终小于系统丢失的成本。
无服务器定价 (Serverless Pricing)
To secure the solution, the pricing of Serverless needs be considered. There are 2 types of pricing when working with Serverless: Direct and Indirect.
为了确保解决方案的安全，需要考虑无服务器的定价。 使用无服务器时，有两种定价类型：直接定价和间接定价。
直接定价 (Direct Pricing)
This is pricing that applies to the Serverless function; the code.
这是适用于无服务器功能的定价； 代码。
There is a generous free tier that some organisations take advantage of and never exceed. After the free tier is exhausted the following pricing elements will affect how much an organisation has to pay:
有一些组织可以利用并且永远都不会超过的免费层级。 免费套餐用尽后，以下定价要素将影响组织必须支付的费用：
Requests — the number of times the Serverless function is invoked
请求 -调用无服务器功能的次数
Memory — the memory consumed by the Serverless function
内存 -无服务器功能消耗的内存
Duration — the amount of time taken by the execution of the Serverless function
持续时间 -执行无服务器功能所花费的时间
Provisioned Concurrency — the expected use of the function. This helps to reduce Serverless function invocation latency
预配置并发 -该功能的预期用途。 这有助于减少无服务器功能调用延迟
间接定价 (Indirect Pricing)
As mentioned earlier, the Serverless function itself will interact with a number of other components to form part of the overall solution. There will be a cost associated with the various components that are used by the solution. For example, if S3 is used, then the cost of the amount of storage and the cost of data requests will have to be accounted for.
如前所述，无服务器功能本身将与许多其他组件交互以构成整个解决方案的一部分。 解决方案所使用的各种组件将产生一定的成本。 例如，如果使用S3，则必须考虑存储量的成本和数据请求的成本。
One of the often-forgotten aspects of any solution is data transfer costs. Any data that is transferred out of the AWS region will have to be included. This is often the source of surprise if it is not initially factored into the pricing of the solution.
任何解决方案中经常被遗忘的方面之一就是数据传输成本。 从AWS区域转移出的任何数据都必须包括在内。 如果最初没有将其计入解决方案的价格中，这通常会令人感到意外。
共同责任模式 (The Shared Responsibility Model)
The benefit of using the cloud is that the underlying platform that services run on are managed by the cloud provider. Part of a cloud solution will be managed by the cloud provider and part of it will be managed by the cloud customer. The level of responsibility will depend on the service that is being used.
使用云的好处是，运行服务的基础平台由云提供商管理。 云解决方案的一部分将由云提供商管理，一部分将由云客户管理。 责任级别将取决于所使用的服务。
With Serverless, the cloud provider manages the platform that the cloud customer’s code will run on. Feature and security updates to the platform are carried out by the cloud provider. The configuration and code of the solution will lie with the cloud customer.
借助Serverless，云提供商可以管理将运行云客户代码的平台。 平台的功能和安全更新由云提供商执行。 解决方案的配置和代码将由云客户承担。
Organisations adopting Serverless solutions need to understand where their responsibility starts and where it stops. This will provide detailed knowledge as to where security controls need to be deployed.
采用无服务器解决方案的组织需要了解他们的责任从哪里开始和在哪里停止。 这将提供有关在何处部署安全控件的详细知识。
知道正常 (Know Normal)
Several questions should be asked regarding the solution when securing it:
保护解决方案时，应询问几个问题：
- What is it trying to achieve for the business? 它试图为企业实现什么？
- How is the solution technically implemented? 该解决方案在技术上如何实施？
- How is it orchestrated? 它是如何编排的？
- What are the touch and integration points? 接触点和整合点是什么？
- How is it operationally maintained? 如何进行操作维护？
- Which users and services have access? 哪些用户和服务可以访问？
- What are the recurring issues? 经常出现什么问题？
- How are errors handled? 错误如何处理？
- How is it monitored and what alerts are in place? 如何对其进行监控，并设置哪些警报？
Before implementing any security controls, it is vital to have a grasp on the important metrics and the key performance indicators (KPIs). To understand what the performance is measured on, how often is it used, concurrency and loads at various times during the day is fundamental. Having these metrics enables the organisation to know what the normal behaviour of the solution is. Any metrics that fall outside of the expected range could indicate security incidents.
在实施任何安全控制之前，至关重要的是要掌握重要的指标和关键性能指标(KPI)。 要了解衡量性能的依据，在一天中的不同时间使用频率，并发性和负载的基础是至关重要的。 拥有这些指标可使组织了解解决方案的正常行为。 任何超出预期范围的指标都可能表示安全事件。
保护代码 (Protecting the Code)
Serverless solutions are primarily constituted of programming code. A Source Code Manager (SCM) such as GitHub or AWS CodeCommit is typically used to store and manage the code. An SCM provides accountability by recording information of any changes that are made to the code. The SCM is typically provided as a Software-as-a-Service (SaaS) service by the SCM provider. An option to host and manage it internally is usually available for those that prefer to retain the code internally and not in the cloud.
无服务器解决方案主要由编程代码组成。 诸如GitHub或AWS CodeCommit之类的源代码管理器(SCM)通常用于存储和管理代码。 SCM通过记录对代码进行的任何更改的信息来提供责任。 SCM通常由SCM提供者作为软件即服务(SaaS)服务提供。 对于那些希望在内部而不是在云中保留代码的人来说，通常可以选择在内部托管和管理它。
A minimum set of privileges should be provided to the users or processes for them to be able to complete their task. This is referred to as the Principle of Least Privilege (POLP). If a user only needs read-only access to the code, then this is the only permission that should be provided.
应该向用户或进程提供最小权限集，以使他们能够完成其任务。 这称为最小特权原则(POLP) 。 如果用户仅需要对代码的只读访问权限，则这是应提供的唯一权限。
Multi-factor authentication (MFA) should be enabled to provide the additional layer of security when authenticating to the SCM.
向SCM进行身份验证时，应启用多因素身份验证(MFA)以提供附加的安全层。
When working with the code, SCMs will offer the use of SSH or HTTPS to clone the repository. Both of these are secure transport methods used to transfer the code.
在使用代码时，SCM将提供使用SSH或HTTPS克隆存储库的功能。 这两种都是用于传输代码的安全传输方法。
The key branches such as the master or some feature branches need to be protected. Engineers should not be able to push directly to these branches. They should create develop branches which should be reviewed by a pull request before it is merged into one of the key branches.
的 关键分支 例如master或某些功能分支需要受到保护。 工程师不应直接将其推向这些分支。 他们应创建开发分支，并应通过拉取请求进行审查 在将其合并到关键分支之一之前。
A consistent naming convention should be applied to function names and commit messages. It is good practice to include a task reference number. This then can then tie back to the project tracking system to understand the context and full description of any changes to the code.
一致的命名约定应应用于函数名称和提交消息。 最好包含任务参考号。 然后，这可以绑定到项目跟踪系统以了解上下文以及对代码的任何更改的完整描述。
A virtual desktop environment, such as AWS Workspaces, in the cloud, can be provisioned for each engineer. These can be either a Windows or Linux operating system. All development can be carried out in the cloud. The code therefore never resides on the engineer’s laptop or device. Should the device get stolen or misplaced, the code will not be lost.
虚拟桌面环境，例如AWS Workspaces， 在云中，可以为每个工程师配置。 这些可以是Windows或Linux操作系统。 所有开发都可以在云中进行。 因此，该代码永远不会驻留在工程师的笔记本电脑或设备上。 如果设备被盗或放错地方，代码将不会丢失。
If mobile devices are used to locally work with code, then a baseline set of requirements should be verified on the device such as antivirus or encryption on drives. Mobile data management (MDM) or mobile application management (MAM) solutions should be considered which can remotely wipe data in the event of a device loss.
如果使用移动设备在本地处理代码，则应在设备上验证一组基本要求，例如防病毒或驱动器上的加密 。 应该考虑使用移动数据管理(MDM)或移动应用程序管理(MAM)解决方案，这些解决方案可以在设备丢失时远程擦除数据。
身份访问管理(IAM)和角色 (Identity Access Management (IAM) and Roles)
IAM controls access to resources and the AWS console. Access to the resources should be restricted using POLP. Ideally, the Lambda console should be read only for viewing purposes and all functions should be updated from an automated pipeline.
IAM控制对资源和AWS控制台的访问。 应该使用POLP限制对资源的访问。 理想情况下，Lambda控制台应仅出于查看目的而只读，并且应从自动管道更新所有功能。
AWS IAM Access Analyser — is a useful service when working with AWS. It provides detailed information on when resources are accessed and by whom.
AWS IAM Access Analyzer —在使用AWS时是一项有用的服务。 它提供有关何时访问资源以及由谁访问的详细信息。
Roles allow AWS services to be able to interact. For example, the role attached to Lambda would need to be able to write to CloudWatch to create logs. It is tempting during development to create a single role which is able to interact with any service and attach that role to every function. This, however, causes a security concern and violates the POLP. The recommended practice is to create a single role which contains access to only the services is requires and associate that to a single function. Each function should have its own role.
角色使AWS服务能够进行交互。 例如，附加到Lambda的角色将需要能够写入CloudWatch以创建日志。 在开发过程中很容易创建一个角色，该角色能够与任何服务交互并将该角色附加到每个功能。 但是，这引起了安全隐患并且违反了POLP。 建议的做法是创建一个仅包含需要访问的服务的角色，并将其与单个功能相关联。 每个功能应有其自己的作用。
网络 (Network)
By default, Lambda will have access to the internet. It is possible to allow Lambda to access resources within a VPC. The function will then not have access to the internet. To allow it to access the internet, a Network Address Translation (NAT) solution can be implemented which is the pattern that would be followed when resources in private subnets require external access.
默认情况下，Lambda可以访问互联网。 可以允许Lambda访问VPC中的资源。 该功能将无法访问互联网。 为了允许它访问Internet，可以实施网络地址转换(NAT)解决方案，当私有子网中的资源需要外部访问时，将采用这种解决方案。
机密 (Secrets)
Credentials should never be specified or hardcoded into the code or environment configuration. They become visible and easily available. Secrets should be stored centrally where they can be managed and rotated. A secrets manager provides secrets dynamically at runtime. AWS has two options which can be used:
绝不应该将凭证指定或硬编码到代码或环境配置中。 它们变得可见并且容易获得。 机密应集中存储，以便对其进行管理和轮换。 机密管理器在运行时动态提供机密。 AWS有两个可以使用的选项：
AWS SSM Parameter Store — basic secrets management
AWS SSM参数存储 -基本机密管理
AWS Secrets Manager — feature-rich secrets management
AWS Secrets Manager-功能丰富的秘密管理
Access should be restricted to the secret manager console itself using IAM.
应该使用IAM将访问权限限制在密码管理器控制台本身上。
功能配置 (Function Configuration)
Some of the configuration properties of Lambda are
Lambda的一些配置属性是
Concurrency — the number of invocations of the function that can occur simultaneously
并发-可以同时发生的函数调用次数
Throttling — the errors that are generated when concurrency limits are reached
节流—达到并发限制时生成的错误
Timeout — the duration that the function can run for
超时-函数可以运行的持续时间
These need to be set to appropriate values based on metrics and KPIs. Any issues with the above may be caused by a security issue and therefore should be investigated.
需要根据指标和KPI将这些值设置为适当的值。 以上任何问题均可能由安全问题引起，因此应进行调查。
数据 (Data)
Lambda can write to any data store type. Data at rest should be encrypted. Most data stores tend to be encrypted by default or it is as simple as ticking a flag to enable basic encryption. Access to encryption keys should be restricted and they should be rotated
Lambda可以写入任何数据存储类型。 静态数据应加密 。 默认情况下，大多数数据存储都倾向于加密，或者只需勾选一个标记即可启用基本加密。 应该限制对加密密钥的访问，并且应该对其进行轮换
The residency of the data should be according to the local laws and regulations. There may be a requirement that ensures that data does not leave the region where it is located. This can have an impact on disaster recovery plans which may involve relocation to an alternative region and potentially violate the laws and regulations.
数据的居住地应根据当地法律和法规。 可能存在确保数据不会离开其所在区域的要求。 这可能会对灾难恢复计划产生影响，该计划可能涉及将其迁移到其他区域，并可能违反法律和法规。
Retention and archiving policies should be set for the data in order to comply with the laws and regulations. Organisations should only retain data as long as the laws allow or are required to do so.
应为数据设置保留和归档策略 ，以符合法律法规。 组织仅应在法律允许或要求保留数据的前提下保留数据。
API网关 (API Gateway)
Most solutions require interaction with multiple APIs. Use of an API Gateway provides a central management service for internal and external APIs. The AWS API Gateway has many security controls:
大多数解决方案都需要与多个API交互。 使用API网关可为内部和外部API提供集中管理服务。 AWS API Gateway具有许多安全控件：
· Gateway Resource Policies and IAM — can be used to control access and invocation of APIs
· 网关资源策略和IAM-可用于控制API的访问和调用
· API Keys — used to ensure that consumers provide expected keys, to control throttling and manage the monitoring of APIs
· API密钥 -已使用 确保使用者提供预期的密钥，控制限制并管理API的监视
· Lambda Authorisers and AWS Cognito — provide mechanisms to control authorisation to the API
· Lambda Authorisers和AWS Cognito —提供控制对API授权的机制
· Throttling and Caching — control the number of invocations of the API and caching which is useful when the APIs are under heavy loads such as being under DDoS attack.
· 限制和缓存 -控制API的调用和缓存的次数，这在API承受重负载(例如遭受DDoS攻击)时非常有用。
AWS组织 (AWS Organizations)
AWS encourages the creation of multiple accounts to segregate departments and capabilities. With AWS Organizations a hierarchical account structure sitting underneath a master account can be created. Service Control Policies (SCPs) can be used to allow or deny sub-accounts the use of particular services.
AWS鼓励创建多个账户以区分部门和功能。 借助AWS Organizations，可以创建位于主账户下方的分层账户结构。 服务控制策略(SCP)可用于允许或拒绝子帐户使用特定服务。
Consolidated Billing allows for billing and costs to be shown per individual account provided to the master account. Combining that with enforced tagging of resources can lead to the benefit of having a granular view of the cost of the resources that are being used.
合并帐单允许 帐单和费用将显示在提供给主帐户的每个个人帐户中。 结合，与资源的强迫吨agging可导致具有正在使用的资源的费用的粒状视图的益处。
无服务器开发 (Serverless Development)
Serverless can be developed using several methods. The traditional model would be for developers to work locally and to push the code up to AWS through the Lambda console.
可以使用多种方法来开发无服务器。 传统模型是供开发人员在本地工作，并通过Lambda控制台将代码推送到AWS。
More modern approaches would be use containers that are enclosed so can include all required packages and libraries. This makes it easier to keep all the requirements for the function in a single place.
更现代的方法是使用封闭的容器 ，以便可以包含所有必需的包和库。 这样可以更轻松地将功能的所有要求都放在一个地方。
Cloud Integrated Development Environments (IDEs) such as AWS Cloud9 are rising in popularity. They, like virtual desktop environments, allow for all development to be carried out and remain in the cloud.
诸如AWS Cloud9之类的云集成开发环境(IDE)越来越受欢迎。 与虚拟桌面环境一样，它们允许进行所有开发并将其保留在云中。
Secure development practices should be followed and could be specific to the programming language being used. The Open Web Security Project (OWASP) provides a useful set of resources and recommended practices on how to secure web applications. They contain a list of high priority security risks that anyone involved in a Serverless solution should familiarise themselves with.
应遵循安全的开发实践，并且可能特定于所使用的编程语言。 开放式Web安全项目(OWASP)提供了有用的资源集和有关如何保护Web应用程序的推荐做法。 它们包含一系列高优先级安全风险，无服务器解决方案中涉及的任何人都应该熟悉这些风险。
The OWASP Top 10 (2017) of critical risks are:
OWASP十大风险(2017)为：
1. Injection
1.注射
2. Broken Authentication
2.身份验证失败
3. Sensitive Data Exposure
3.敏感数据公开
4. XML External Entities (XXE)
4. XML外部实体(XXE)
5. Broken Access Control
5.损坏的访问控制
6. Security Misconfiguration
6.安全配置错误
7. Cross-Site Scripting (XSS)
7.跨站点脚本(XSS)
8. Insecure Deserialization
8.不安全的反序列化
9. Using Components with Known Vulnerabilities
9.使用具有已知漏洞的组件
10. Insufficient Logging & Monitoring
10.日志和监控不足
DevOps / DevSecOps (DevOps / DevSecOps)
Adopting a Development Operations (DevOps) or Development Security Operations (DevSecOps) culture in the organisation results in breaking down of barriers between capabilities and results in rapid collaboration. It involves the use of automation tools such as AWS CodeCommit, AWS CodeDeploy and AWS CodePipeline along with third-party tools.
在组织中采用开发操作(DevOps)或开发安全操作(DevSecOps)的文化可以打破功能之间的障碍，并实现快速协作。 它涉及使用自动化工具(例如AWS CodeCommit，AWS CodeDeploy和AWS CodePipeline)以及第三方工具。
Automation of code build, test and deploy activities provide numerous benefits particularly with the ability to audit changes, provide rapid changes and remediation of security issues. The Security capability of an organisation can be integrated into the teams and the automation pipeline. Approval of various stages should involve the key reviewers along with the Security team.
代码构建，测试和部署活动的自动化提供了许多好处，特别是具有审计变更，提供快速变更和补救安全问题的能力。 组织的安全能力可以集成到团队和自动化管道中。 各个阶段的批准应包括关键审核者以及安全团队。
测试中 (Testing)
Various forms of testing can be integrated into the deployment pipelines. Static Testing is the review of the code in its non-running, uncompiled state. This can be either done manually using code reviews, pull requests or tools such as AWS CodeGuru and SonarQube for security and performance-related testing.
可以将各种形式的测试集成到部署管道中。 静态测试是对处于非运行，未编译状态的代码的检查。 可以使用代码审阅，拉取请求或AWS CodeGuru和SonarQube之类的工具手动完成此操作，以进行与安全性和性能相关的测试。
Dynamic Testing is the testing of code when the solution is in a running state. There are various solutions on the AWS Marketplace to support dynamic testing and solutions such as Selenium and Apache Bench for security and performance testing.
动态测试是在解决方案处于运行状态时进行的代码测试。 AWS Marketplace上有各种支持动态测试和解决方案的解决方案，例如Selenium和Apache Bench，用于安全性和性能测试。
Penetration Testing involves hiring a third party in an attempt to find vulnerabilities in an organisation’s systems by putting themselves in the mindset of a malicious actor. This can be done as part of the organisation’s wider security program or as a focus on the Serverless solution.
渗透测试涉及雇用第三方，以通过使自己陷入恶意行为者的思维中来寻找组织系统中的漏洞。 这可以作为组织更广泛的安全计划的一部分，也可以作为对无服务器解决方案的关注。
结构完善的框架-无服务器镜头 (The Well-Architected Framework — Serverless Lens)
AWS provides the Well-Architected Framework that contains the pillars of cost optimisation, operational excellence, reliability, performance efficiency and security. They provide best practices in these areas.
AWS提供了结构完善的框架，其中包含成本优化，卓越运营，可靠性，性能效率和安全性的Struts。 他们在这些领域提供最佳实践。
There is a Serverless Lens that can be followed to maximise the benefits of Serverless along with securing the solution.
可以遵循无服务器镜头，以最大程度地发挥无服务器的优势并确保解决方案的安全。
监视，故障排除和警报 (Monitoring, Troubleshooting and Alerting)
Many services are available to monitor and investigate security incidents in AWS. A combination of tools should be used and integrated with the Security and Information Events Management (SIEM) service. These should be made available to the Operations and Security teams of the organisation.
许多服务可用于监视和调查AWS中的安全事件。 应使用工具的组合，并将其与安全和信息事件管理(SIEM)服务集成。 这些应提供给组织的运营和安全团队。
- AWS CloudWatch — used to capture logs for the solution AWS CloudWatch-用于捕获解决方案的日志
- AWS CloudTrail — an audit trail capturing AWS API calls AWS CloudTrail —捕获AWS API调用的审核跟踪
- AWS Config — captures changes to resources and along with tagging and Lambda can implement remediation AWS Config-捕获对资源的更改，并与标记一起使用，Lambda可以实施补救
- AWS X-Ray — allows to trace solution flows and understand where issues lie along with any latency AWS X-Ray —允许跟踪解决方案流并了解问题所在以及任何延迟
- AWS SNS — used for alerts based on configured thresholds AWS SNS-用于基于配置的阈值的警报
- AWS Security Hub — a SIEM providing dashboards that reflect the security posture of a solution AWS安全中心—一个SIEM，提供可反映解决方案安全状况的仪表板
- AWS Detective — providing a visual history of incidents allowing for further investigation AWS Detective —提供事件的可视历史记录，以便进行进一步调查
There are also many specialised third party products that offer the services listed above. Splunk is an example of a popular monitoring, logging and SIEM service.
也有许多专门的第三方产品提供上面列出的服务。 Splunk是流行的监视，日志记录和SIEM服务的示例。
事件响应 (Incident Response)
The security view of any organisation should be to expect a security incident to occur. A security policy, business continuity and disaster recovery plan should be created, reviewed and maintained.
任何组织的安全视图都应该期望发生安全事件。 应创建，审查和维护安全策略，业务连续性和灾难恢复计划。
Application metrics should be monitored to understand normal behaviour. Anomalies to the baseline can identify a security incident occurring. Implementing alerts based on unexpected behaviour of the application can allow the Operations or Security team to investigate and respond.
应监控应用程序指标以了解正常行为。 基线异常可以标识发生的安全事件。 基于应用程序的意外行为实施警报可以使运营或安全团队进行调查和响应。
Rehearsals to common incidents should be carried out frequently. Some rehearsals may require a full interruption test which disrupts the organisation. With the benefits of the cloud and the ability to provision infrastructure instantaneously, parallel tests can be carried out by deploying temporary solutions without affecting the organisation.
对常见事件的演练应经常进行。 某些排练可能需要全面中断测试 ，这会破坏组织。 利用云的好处和即时配置基础架构的能力，可以通过部署临时解决方案来进行并行测试 ，而不会影响组织。
你永远不会完成 (You’re Never Finished)
Serverless solutions have outstanding benefits for organisations that do not want to manage the underlying platform. Changes in technologies and local regulations may lead to changes in the security of the Serverless solution. Implementing security controls is never a one-time job. The threat landscape is large and always growing. New methods are continuously being developed by malicious actors to disrupt and penetrate systems. It’s crucial that organisations strive to stay ahead of threats and review their security posture regularly. Security is an eternal process and the work is never done.
对于不想管理基础平台的组织，无服务器解决方案具有显着的优势。 技术和本地法规的变化可能会导致无服务器解决方案安全性的变化。 实施安全控制绝不是一项一次性的工作。 威胁范围很大，并且一直在增长。 恶意行为者正在不断开发新方法来破坏和渗透系统。 至关重要的是，组织必须努力保持领先地位，并定期检查其安全状况。 安全是一个永恒的过程，工作永远不会完成。
About the Author
关于作者
Sat Gainda is a Cloud Solutions Architect at Version 1, working on enterprise-level engagements that utilise innovative Cloud systems. Stay tuned to Version 1 on Medium for more Cloud-focused posts from Sat.
Sat Gainda是 版本1 的云解决方案架构师 ， 致力于利用创新的云系统进行企业级合作。 敬请关注Sat中的第1版，以获取更多有关 云的帖子 。
翻译自: https://medium.com/version-1/protecting-your-serverless-solution-cd5d4247e27c
服务器 解决方案
169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
