对于容器安全性，你会发现许多开源工具可以帮助防止像特斯拉那样遭受Kubernetes集群破坏的另一场崩溃。但容器安全性仍然很棘手，因此您需要知道要添加到您的库中的实用程序。

如果您花时间选择最佳的应用程序安全测试工具并确保您的应用程序尽可能安全，那么您不希望它在不安全的容器上运行。幸运的是，那里有商业容器安全产品，但开源项目也可以带你走得很远。许多人专注于审计，跟踪由CIS，国家漏洞数据库和其他机构建立的常见漏洞和暴露（CVE）数据库和基准。然后，工具扫描容器图像，显示其内容，并将内容与已知漏洞的这些清单进行比较。

通过帮助团队在构建管道的早期捕获问题，自动化容器审计以及使用其他容器安全流程可以为企业带来巨大的好处。

虽然有很多开源容器安全工具，但这里有最好的，最成熟的用户社区。

 

1. Docker Bench for Security

用于根据安全基准审核Docker容器的脚本

面向使用Docker社区版管理容器的开发人员，Docker Bench for Security是Docker的开源脚本，用于审核容器以防止常见的安全最佳实践。

Docker Bench的测试基于行业标准的CIS基准测试，帮助实现手动漏洞测试的繁琐过程自动化。

Docker的安全负责人DiogoMónica将其描述为“测试容器的容器”。您可以按如下方式启动容器：

docker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /var/lib:/var/lib \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/lib/systemd:/usr/lib/systemd \ -v /etc:/etc --label docker_bench_security \ docker/docker-bench-security

结果会为每个安全配置基准测试发出Info，Warning和Pass日志。您也可以从Docker主机运行此实用程序，通过Docker Compose克隆它，或直接从基本主机运行它。

一个缺点是输出结果缺乏机器可读性。许多社区软件包，如Docker Bench Test，drydock和Actuary，都在Docker Bench上得到改进。

 

2. Clair

API驱动的静态容器安全性分析，具有庞大的CVE数据库

Clair由CoreOS构建，对容器漏洞进行静态分析。它也用在Quay.io中，这是一个替代Docker Hub的公共容器注册表。

Clair引入了许多漏洞数据源，例如Debian Security Bug Tracker，Ubuntu CVE Tracker和Red Hat Security Data。由于Clair消耗了如此多的CVE数据库，因此其审计非常全面。

Clair首先索引容器图像中的功能列表。然后，使用Clair API，开发人员可以在数据库中查询与特定映像相关的漏洞。

要开始使用Clair，请参阅Running Clair指南。将它部署到Kubernetes集群很容易：

git clone https://github.com/coreos/clair cd clair/contrib/helm cp clair/values.yaml ~/my_custom_values.yaml vi ~/my_custom_values.yaml helm dependency update clair helm install clair -f ~/my_custom_values.yaml

Clair的功能集非常灵活。它允许您添加自己的驱动程序以用于其他行为。此外，对审计特定容器映像进行单独的API调用是一种流畅的，机器驱动的替代方法，可以通过大量的报告日志进行搜索。

3. Cilium

内核层的API感知网络和安全性

Cilium致力于保护网络连接。 Cilium与Linux容器平台（如Docker和Kubernetes）兼容，增加了安全可见性和控制逻辑。

它由BPF（以前称为Berkeley数据包过滤器）提供支持，这是一种Linux内核技术。其低级实现的有趣方面是您可以在不更改应用程序代码或容器配置的情况下应用和更新Cilium安全策略。

CoreOS开发了Cilium，以响应现代微服务开发和快速容器部署的不稳定生命周期。将它与Kubernetes集成是很简单的;以下是如何使用本地更改部署Cilium：

$ kubectl create -f ./cilium.yaml clusterrole "cilium" created serviceaccount "cilium" created clusterrolebinding "cilium" created configmap "cilium-config" created secret "cilium-etcd-secrets" created daemonset "cilium" created $ kubectl get ds --namespace kube-system NAME DESIRED CURRENT READY NODE-SELECTOR AGE cilium 1 1 1 <none> 2m

Cilium周围的支持和社区非常棒。你会找到大量的指南和文档，一个专门的Slack频道，甚至每周一次与项目维护人员进行环聊。

4. Anchore

使用CVE数据和用户定义的策略检查容器安全性的工具

Anchore Engine是一种用于分析容器图像的工具。除了基于CVE的安全漏洞报告之外，Anchore Engine还可以使用自定义策略评估Docker镜像。

策略导致通过或失败结果。策略基于白名单或黑名单，凭据，文件内容，配置类型或其他用户生成的提示。

Anchore打包为Docker容器映像，可以独立运行，也可以在Kubernetes等业务流程平台上运行。它还有用于CI / CD的Jenkins和GitLab集成。

Anchore命令行界面（CLI）是一种操作Anchore Engine的简便方法。例如，此CLI命令返回有关图像内容的详细信息：

anchore-cli image content INPUT_IMAGE CONTENT_TYPE

此示例命令将对映像执行漏洞扫描：

anchore-cli image vuln docker.io/library/debian:latest os

Anchore输出漏洞详细信息，威胁级别，CVE标识符和其他相关信息的列表。由于用户定义的规则是使用Anchore Cloud Service图形用户界面（GUI）创建的，因此它的运行方式与SaaS类似。

5. OpenSCAP Workbench

用于为各种平台创建和维护安全策略的环境

OpenSCAP是IT管理员和安全审核员的生态系统，包括许多开放式安全基准指南，配置基线和开源工具。

在Fedora，Red Hat Enterprise Linux，CentOS或Scientific Linux上运行的人可以将OpenSCAP Workbench安装为GUI，以在虚拟机，容器和映像上运行扫描。使用以下命令安装OpenSCAP Workbench：

#yum install scap-workbench

要根据SCAP策略指南和CVE验证容器，请使用OpenSCAP附带的oscap-docker实用程序。

OpenSCAP以NIST认证的安全内容自动化协议（SCAP）为中心，并提供许多机器可读的安全策略。 OpenSCAP安全指南指出，该项目的目标是“允许多个组织通过避免冗余来有效地开发安全内容”。

由于OpenSCAP比此列表中的其他人更广泛，因此对于希望为整个平台创建安全策略的团队而言，它是一个不错的选择。

6. Dagda

用于扫描Docker容器中的漏洞，特洛伊木马，病毒和恶意软件的工具

Dagda是另一种用于容器安全性静态分析的工具。它的CVE源包括OWASP依赖性检查，Red Hat Oval和攻击性安全漏洞利用数据库。

要使用Dagda扫描Docker容器，首先要使用漏洞数据填充Mongo数据库。执行此命令以分析单个Docker镜像：

python3 dagda.py check --docker_image jboss/wildfly

您可以远程运行它，也可以不断调用它来监视活动的Docker容器。输出显示漏洞数，严重性级别和其他详细信息以帮助修复。

Dagda的一个好处是可以广泛覆盖漏洞数据。这意味着可以直接访问大量更新，全面的漏洞利用集合。它也很灵活，您可以通过CLI和REST API来控制它。

7. Notary

用于通过加密方式委派责任的服务器来提高容器安全性的框架

公证人是事实上的Docker图像签名框架，现在开源其他实现。 Docker开发了它，然后在2017年将其捐赠给了Cloud Native Computing Foundation。

公证就是责任分离;使用Notary，开发人员可以委派角色并在容器之间定义职责。该软件包提供服务器和客户端，以提供发布和验证内容的加密安全方法。

要在本地部署Notary，请通过克隆repo来开始。接下来，使用Docker Compose部署本地配置：

$ docker-compose build $ docker-compose up -d $ mkdir -p ~/.notary && cp cmd/notary/config.json cmd/notary/root-ca.crt ~/.notary

依赖于Update Framework和Go语言作为依赖关系，Notary可以验证容器应用程序映像的加密完整性。

 

8. Grafaes

用于帮助管理内部安全策略的元数据API

Grafaes可以极大地帮助您创建自己的容器安全扫描项目。该容器安全工具于2017年底宣布，由IBM和Google开发。

开发人员可以使用Grafaes（称为“组件元数据API”）来定义虚拟机和容器的元数据。 IBM的Vulnerability Advisor也集成到项目中。

有关可靠的案例研究，请参阅Shopify如何使用Grafaes管理500,000个容器图像的元数据。与Kritis合作，该团队在使用Grafeas元数据的Kubernetes集群上实施安全策略。

能够快速获取容器元数据有助于加快补救尝试，从而减少从利用到解决的窗口。虽然Grafaes是开源的，但它由大型软件提供商维护 - 这对长期支持是有益的。

9. Sysdig Falco

提供深度容器可见性的行为活动监控

Falco是一种由Kubernetes识别的安全审计工具，由Sysdig开发，强调对容器，主机和网络活动的行为监控。使用Falco，开发人员可以对其基础架构进行连续检查，检测异常情况，并为任何类型的Linux系统调用设置警报。

Falco文档建议用户将Falco作为Docker容器运行。可以使用这些命令安装它。实施后，标准输出Falco警报如下所示：

stdout_output: enabled: true 10:20:05.408091526: Warning Sensitive file opened for reading by non-trusted program

使用Falco监视shell在容器中运行的时间，容器已安装，敏感文件的意外读取，出站网络尝试或其他可疑调用。 Sysdig在此提供了更多容器故障排除材料。

10. Banyanops Collector

Docker容器图像的静态分析框架

在Banyanops的支持下，Collector是一个开源实用程序，可用于“窥视”Docker容器图像文件。使用Collector，开发人员可以收集容器数据，实施安全策略等。

首先，Banyanops可以在私有注册表上运行，也可以作为Docker Hub上的容器运行。 Banyanops还提供可提供更深入数据分析的SaaS产品，因此如果您遇到有限的功能，请注意向上销售。

尊敬的开源

 

1. Dockscan：具有少量提交的安全漏洞扫描程序
2. Batten：类似于Docker Bench的审计工具包，但具有非活动支持
3. BlackDuck Docker安全性：作为Web服务构建的容器映像安全扫描工具。遗憾的是，目前的形式并未建议使用生产
4. Inspec：具有Docker容器测试功能的审计和测试框架

你的旅费可能会改变

由于容器化已经发展成为一种流行的部署方式，因此需要使用适当的安全控制来扩充这些容器是至关重要的。值得庆幸的是，您将找到一个强大的开源安全解决方案生态系统，这些解决方案已针对许多不同的环境进行了定制。

这些工具的整体强度取决于所进行的检查的深度。有效性还取决于CVE数据库和基准本身继续使用新漏洞更新数据并发布新的最佳实践。值得庆幸的是，正在努力缩短零日漏洞利用和容器漏洞检测之间的时间。

开发人员还将倾向于使用具有更好体验的工具，这将减少日志结果中的噪音和重复。这种粒度偏好只能通过反复试验来确定，具体取决于您的构建例程和个人偏好。

 

原文：https://techbeacon.com/security/10-top-open-source-tools-docker-security

本文：http://pub.intelligentx.net/10-top-open-source-tools-docker-security

讨论：请加入知识星球或者小红圈【首席架构师圈】

本文由Heitor Lessa提供，AWS专业解决方案架构师- Serverless

今天，我很兴奋地向您介绍Amazon API网关与AWS WAF的本地集成。以前，如果希望使用AWS WAF在Amazon API网关中保护API，就必须部署一个区域性API端点，并使用自己的Amazon CloudFront发行版。现在，这个新特性允许您提供任何—API网关端点，并使用AWS WAF保护它，而无需配置自己的CloudFront发行版来添加该功能。

在本系列的第1部分中，我描述了如何使用AWS WAF保护API网关提供的API。

在本系列的第2部分中，我描述了如何使用API密钥作为CloudFront发行版和API网关之间的共享秘密，以确保在API网关中对API的公共访问是安全的。这种新的AWS WAF集成意味着不再需要第2部分中描述的方法。

下面的图像描述了在这个特性可用之前和之后在API网关中保护API的方法。

地点:

1. AWS WAF仅保护CloudFront端点。
2. AWS WAF本地保护Amazon API网关端点。

为Amazon API网关管理的API启用AWS WAF

对于本演练，您可以使用现有的宠物商店API或您可能已经部署的API Gateway中的任何API。您将创建一个新的AWS WAF web ACL，该ACL稍后与您的API网关阶段相关联。

按照以下步骤创建web ACL:

1. 打开AWS WAF控制台。
2. 选择Create web ACL。
3. 对于Web ACL名称，输入ApiGateway-HTTP-Flood-Sample。
4. 对于地区，选择美国东部(北弗吉尼亚)。
5. 选择Next，直到您达到步骤3:创建规则。
6. 选择Create rule并输入HTTP Flood Sample。
7. 对于规则类型，选择基于速率的规则。
8. 对于速率限制，输入2000并选择Create。
9. 对于默认操作，选择“允许不匹配任何规则的所有请求”。
10. 选择Review并创建。
11. 确认您的选项与下图相似，然后选择Confirm和create next。

您现在可以按照以下步骤为API网关中的现有API启用AWS WAF web ACL:

1. 打开Amazon API网关控制台。
2. 选择阶段,刺激。
3. 在Web应用程序防火墙(Web Application Firewall, WAF)下，选择ApiGateway-HTTP-Flood-Sample(或您刚刚创建的Web ACL)。
4. 选择保存更改。

在API网关中测试您的API，现在由AWS WAF保护

AWS WAF提供HTTP洪水保护，这是一个基于速率的规则。当来自客户机的web请求超过可配置阈值时，将自动触发基于速率的规则。阈值由一个IP地址在5分钟内允许的最大传入请求数定义。

在突破这个阈值之后，IP地址的其他请求将被阻塞，直到请求速率低于该阈值为止。对于本例，您将2000个请求定义为基于HTTP洪泛率规则的阈值。

火炮是一个开源的现代负载测试工具包，用于将大量请求直接发送到API网关调用URL，以测试AWS WAF本机集成是否正常工作。

首先，按照以下步骤检索正确的宠物商店API调用URL:

• 打开API网关控制台。
• 在左侧导航窗格中，打开PetStore API。
• 选择stage、选择prod并复制Invoke URL值。

其次，使用cURL查询您的分布，并在触发速率限制规则之前查看API输出:

$ curl -s INVOKE_URL/pets

[

  {

    "id": 1,

    "type": "dog",

    "price": 249.99

  },

  {

    "id": 2,

    "type": "cat",

    "price": 124.99

  },

  {

    "id": 3,

    "type": "fish",

    "price": 0.99

  }

] 

然后，用Artillery 在短时间内发送大量请求，触发你的速率限制规则:

$ artillery quick -n 2000 --count 10 INVOKE_URL/pets

使用这个命令，炮兵 artillery 从10个并发用户向PetStore API发送2000个请求。通过这样做，您可以在5分钟内触发速率限制规则。简而言之，我没有在这里发布炮兵输出。

炮兵完成任务后，尝试重新运行cURL命令。你不应该再看到宠物列表:

{“message”:”Forbidden”}

从输出中可以看到，请求被AWS WAF阻塞。当您的IP地址低于请求限制速率时，将从阻塞列表中删除。

结论

正如您所看到的，通过AWS WAF与Amazon API网关的本机集成，您不再需要管理自己的Amazon CloudFront发行版来使用AWS WAF保护您的API。AWS WAF本机集成使此过程无缝。

我希望这篇文章中的信息对你有所帮助。请记住，您现在可以将此集成用于所有Amazon API网关端点(Edge、Regional和Private)。它在下列区域提供:

• US East (N. Virginia)
• US East (Ohio)
• US West (Oregon)
• US West (N. California)
• EU (Ireland)
• EU (Frankfurt)
• Asia Pacific (Sydney)
• Asia Pacific (Tokyo)

 

原文：https://aws.amazon.com/cn/blogs/compute/amazon-api-gateway-adds-support-for-aws-waf/

本文：http://pub.intelligentx.net/amazon-api-gateway-adds-support-aws-waf

讨论：请加入知识星球或者小红圈【首席架构师圈】

公共云基础设施内构建的私有云

机密云是在一个或多个公共云内形成的安全机密计算环境。机密云构造中的应用程序、数据和工作负载受到硬件级加密、内存隔离和其他服务的组合保护，这些服务可确保工作负载、数据和平台的完整性。

机密云是在运行时按需创建的。工作负载和数据的运行完全不受内部人员、不良参与者和恶意进程的影响，即使在物理主机出现漏洞的情况下，工作负载的各个方面也能保持安全。

Anjuna Confidential Computing软件将公共云转换为具有最强保护能力的机密云，将任何公共云转换成最安全的计算场所。Anjuna的软件允许应用程序和整个环境在机密云结构内工作，无需修改。

增加软件抽象层和虚拟化层的优势在于，机密云本身不受Intel、AMD、Amazon和ARM开发的众多专有飞地技术和版本的限制。

任何即时安全的应用程序

Anjuna机密计算软件将安全性从专有硬件和公共云实现中抽象出来，简化了云迁移和多云部署。实际上，任何定制或打包的应用程序都是在机密云中部署和运行的。不需要SDK、重新编译和重新架构。

 

默认情况下从内部人员和不良参与者中消除攻击面

使用Anjuna Software创建的机密云实际上没有数据攻击面。工作负载在硬件中是孤立的，使它们对坏人和恶意软件不可见。与基于软件的安全和密钥管理系统不同，密钥和其他关键工件永远无法通过公开内存访问。

Anjuna的机密计算软件作为云基础设施的一部分进行了无形部署，远远低于用户和IT流程。这使IT员工能够在无中断的情况下工作，与敏感数据完全隔离，从而降低风险并提高生产率。

所有数据都受保护，无处不在

Anjuna机密计算软件保护扩展到所有使用数据的地方，消除了过度访问，从而加剧了公共云中的内部风险。所有数据，即使是存储和联网的数据，都会使用以硬件为基础、外部管理的加密密钥进行验证和隔离，并完全隔离，以完全缓解甚至是常见的基于内存的攻击。

今日企业就绪

Anjuna软件扩展到多个公共云提供商，以无缝保护传统、打包和高度分布式的云本地应用程序的组合，这些应用程序通常构成企业产品组合。

Anjuna软件无缝集成到现有IT管理系统和流程中。简单的部署和虚拟化使it员工能够在几分钟内将易受攻击的应用程序和数据快速转换为严格控制的资源。第三方集成和API使IT组织能够利用其在关键、SIEM、CARTA、Kubernetes和其他系统上的投资。

为迁移到机密云做好准备

向您的团队提出以下问题：

• 如何保护公共云中的敏感应用程序和数据？
• 您的云提供商正在做什么来解决持续的内部威胁？
• 您是否在数据中心内或通过云提供商接触第三方？
• 如何在不受信任的地区保护您的应用程序和数据？
• 您是否担心政府传票可能要求访问客户数据？
• 您是否愿意重新编写应用程序以利用机密云技术？
• 拥有一个能够自动将关键应用程序和数据移动到安全环境中而无需重写或SDK的解决方案有多重要？

本文：

本文由Heitor Lessa提供，AWS专业解决方案架构师- Serverless

在本博客的第1部分中，我们描述了如何使用AWS WAF保护Amazon API Gateway提供的API。在本博客中，我们将展示如何在Amazon CloudFront分发和API网关之间使用API键，以确保除了已经在API网关中设置的首选授权(AuthZ)机制之外，还可以访问API网关中的API。有关API网关中的AuthZ机制的更多信息，请参见使用Amazon Cognito联合身份、Amazon Cognito用户池和Amazon API网关的安全API访问。

我们还扩展了以前用于自动创建此解决方案的以下必要资源的AWS CloudFormation堆栈:

1. API网关使用计划——管理专用于CloudFront的API密钥，以及必要时的节流和计量使用
2. AWS Lambda函数——更新AWS CloudFormation堆栈参数时间戳并触发API键旋转
3. Amazon CloudWatch事件调度作业——在给定的调度中触发Lambda函数

以下是使用API密钥的替代解决方案，具体取决于您的安全需求:

在CloudFront中使用随机生成的HTTP秘密头，并通过API网关请求验证进行验证

使用Lambda@Edge对传入请求进行签名，并使用API网关Lambda授权器进行验证

需求

要继续，您需要完全的权限来通过AWS CloudFormation创建、更新和删除API网关、CloudFront、Lambda和CloudWatch事件。

扩展现有AWSCloudFormation 堆栈

首先，点击这里下载完整的模板。然后按照以下步骤更新现有的AWS云形成堆栈:

1. 转到AWS管理控制台并打开AWS CloudFormation控制台。
2. 选择您在第1部分中创建的堆栈，右键单击它，然后选择Update stack。
3. 对于选项2，选择“选择文件”并选择下载的模板。
4. 填写所需的参数，如下图所示。

以下是关于这些参数的更多信息:

1. 发送流量的API网关——除了没有URL模式(https://)之外，我们使用与第1部分相同的API网关URL: cxm45444t9a.execute-api.us- east2.amazonaws.com/prod
2. 旋转API键——我们定义了Daily并使用2018-04-03作为时间戳值来追加API键名

继续使用AWS CloudFormation控制台完成操作。更新堆栈可能需要几分钟，因为CloudFront需要时间在所有存在点上传播更改。

 

在示例宠物商店API中启用API键

当堆栈在后台完成时，让我们在CloudFront将发送流量到的API中启用API键。

1. 转到AWS管理控制台并打开API网关控制台。
2. 选择您在第1部分中创建的API并选择Resources。
3. 在/pets下，选择GET，然后选择Method Request。
4. 对于所需的API键，选择下拉菜单并选择true。
5. 要保存此更改，请选择突出显示的复选标记，如下图所示。

接下来，我们需要部署这些更改，以便在没有API密钥时发送给/pets的请求失败。

• 选择Actions并选择Deploy API。

• 选择Deployment stage下拉菜单，并选择在第1部分中创建的舞台。
• 添加一个部署描述，例如“在/pets下需要API键”，然后选择Deploy。

当部署成功时，您将被重定向到API Gateway Stage页面。在那里，您可以使用Invoke URL来测试以下请求是否由于没有API密钥而失败。

这一失败是预料之中的，并证明我们部署的更改正在工作。接下来，让我们尝试访问相同的API，但这次是通过CloudFront分发。

1. 从AWS管理控制台打开AWS Cloudformation控制台。
2. 选择您在第1部分中创建的堆栈，并在左下角选择output。
3. 在CFDistribution行上，复制URL。在粘贴新浏览器选项卡或窗口之前，请在其中添加' /pets '。

与我们第一次尝试不使用API键相反，我们从PetStore API接收JSON响应。这是因为CloudFront在将请求转发到PetStore API之前注入了一个API密钥。下图演示了这两种测试:

1. 通过CloudFront访问API时请求成功
2. 通过API的调用URL直接访问API时，请求失败

这是CloudFront和API网关之间的一个秘密，它可以是任何约定的随机秘密，可以像API密钥一样旋转。但是，重要的是要知道API key是一个跟踪或度量API使用者使用情况的特性。它不是一种安全的授权机制，因此只能与API网关授权器一起使用。

 

旋转的API密钥

API键会根据更新AWS CloudFormation堆栈时选择的时间表(例如，每日或每月)自动旋转。这就不需要您进行维护或干预。在本节中，我们将解释这个过程是如何工作的，以及如果您想手动触发API键旋转，您可以做些什么。

除了第1部分之外，我们下载并用于更新堆栈的AWS CloudFormation模板还执行了以下操作。

引入一个附加到API密钥名的时间戳参数

Parameters:

  Timestamp:

    Type: String

    Description: Fill in this format <Year>-<Month>-<Day>

    Default: 2018-04-02

创建一个API网关密钥，API网关使用计划，将新密钥与作为参数给出的API网关关联，并配置CloudFront分发，以便在将流量转发到API网关时发送一个自定义头

CFDistribution:

  Type: AWS::CloudFront::Distribution

  Properties:

    DistributionConfig:

      Logging:

        IncludeCookies: 'false'

        Bucket: !Sub ${S3BucketAccessLogs}.s3.amazonaws.com

        Prefix: cloudfront-logs

      Enabled: 'true'

      Comment: API Gateway Regional Endpoint Blog post

      Origins:

        -

          Id: APIGWRegional

          DomainName: !Select [0, !Split ['/', !Ref ApiURL]]

          CustomOriginConfig:

            HTTPPort: 443

            OriginProtocolPolicy: https-only

          OriginCustomHeaders:

            - 

              HeaderName: x-api-key

              HeaderValue: !Ref ApiKey

              ...

ApiUsagePlan:

  Type: AWS::ApiGateway::UsagePlan

  Properties:

    Description: CloudFront usage only

    UsagePlanName: CloudFront_only

    ApiStages:

      - 

        ApiId: !Select [0, !Split ['.', !Ref ApiURL]]

        Stage: !Select [1, !Split ['/', !Ref ApiURL]]

ApiKey: 

  Type: "AWS::ApiGateway::ApiKey"

  Properties: 

    Name: !Sub "CloudFront-${Timestamp}"

    Description: !Sub "CloudFormation API Key ${Timestamp}"

    Enabled: true

ApiKeyUsagePlan:

  Type: "AWS::ApiGateway::UsagePlanKey"

  Properties:

    KeyId: !Ref ApiKey

    KeyType: API_KEY

    UsagePlanId: !Ref ApiUsagePlan

正如在ApiKey资源中所示，我们将给定的时间戳附加到Name中，并在API网关使用计划密钥资源中使用它。这意味着，无论何时时间戳参数发生变化，AWS CloudFormation都会触发资源替换，并更新依赖于该API键的每个资源。在本例中，这包括AWS CloudFront配置和API网关使用计划。

但是在这个例子中，您在本博客开头所选择的轮换计划意味着什么呢?

创建一个计划好的活动来触发给定计划中的Lambda函数

Parameters:

...

  ApiKeyRotationSchedule: 

    Description: Schedule to rotate API Keys e.g. Daily, Monthly, Bimonthly basis

    Type: String

    Default: Daily

    AllowedValues:

      - Daily

      - Fortnightly

      - Monthly

      - Bimonthly

      - Quarterly

    ConstraintDescription: Must be any of the available options

Mappings: 

  ScheduleMap: 

    CloudwatchEvents: 

      Daily: "rate(1 day)"

      Fortnightly: "rate(14 days)"

      Monthly: "rate(30 days)"

      Bimonthly: "rate(60 days)"

      Quarterly: "rate(90 days)"

Resources:

...

  RotateApiKeysScheduledJob: 

    Type: "AWS::Events::Rule"

    Properties: 

      Description: "ScheduledRule"

      ScheduleExpression: !FindInMap [ScheduleMap, CloudwatchEvents, !Ref ApiKeyRotationSchedule]

      State: "ENABLED"

      Targets: 

        - 

          Arn: !GetAtt RotateApiKeysFunction.Arn

          Id: "RotateApiKeys"

资源RotateApiKeysScheduledJob显示，在更新AWS CloudFormation堆栈时，通过下拉菜单选择的调度实际上转换为CloudWatch事件规则。这进而触发在相同模板中定义的Lambda函数。

 

RotateApiKeysFunction:

      Type: "AWS::Lambda::Function"

      Properties:

        Handler: "index.lambda_handler"

        Role: !GetAtt RotateApiKeysFunctionRole.Arn

        Runtime: python3.6

        Environment:

          Variables:

            StackName: !Ref "AWS::StackName"

        Code:

          ZipFile: !Sub |

            import datetime

            import os

            import boto3

            from botocore.exceptions import ClientError

            session = boto3.Session()

            cfn = session.client('cloudformation')

            

            timestamp = datetime.date.today()            

            params = {

                'StackName': os.getenv('StackName'),

                'UsePreviousTemplate': True,

                'Capabilities': ["CAPABILITY_IAM"],

                'Parameters': [

                    {

                      'ParameterKey': 'ApiURL',

                      'UsePreviousValue': True

                    },

                    {

                      'ParameterKey': 'ApiKeyRotationSchedule',

                      'UsePreviousValue': True

                    },

                    {

                      'ParameterKey': 'Timestamp',

                      'ParameterValue': str(timestamp)

                    },

                ],                

            }

            def lambda_handler(event, context):

              """ Updates CloudFormation Stack with a new timestamp and returns CloudFormation response"""

              try:

                  response = cfn.update_stack(**params)

              except ClientError as err:

                  if "No updates are to be performed" in err.response['Error']['Message']:

                      return {"message": err.response['Error']['Message']}

                  else:

                      raise Exception("An error happened while updating the stack: {}".format(err))          

  

              return response

 

这个Lambda函数所做的一切就是通过API触发AWS CloudFormation堆栈更新(与您通过控制台所做的完全相同，但是以编程方式进行的)，并更新时间戳参数。因此，它会旋转API键和CloudFront分发配置。

这为您提供了足够的灵活性，可以在任何时候更改API key rotation schedule，而无需维护或编写任何代码。您还可以手动更新堆栈，并通过更新AWS CloudFormation堆栈的时间戳参数来旋转键。

下一个步骤

我们希望你觉得这个博客的信息有帮助。您可以使用它来了解如何创建一种机制，只允许从CloudFront到API网关的通信，并避免绕过第1部分设置的AWS WAF规则。

关于这个解决方案，请记住以下几点:

• 它假设您已经拥有一个由API网关管理的强大AuthZ机制来控制对API的访问。
• 在此解决方案中创建的API网关使用计划和其他资源只适用于在相同帐户中创建的API (ApiUrl参数)。
• 如果您已经使用API键来跟踪API的使用情况，请考虑使用以下任何一种解决方案作为替代:
  • 在CloudFront源配置中使用随机HTTP头值，并使用API网关请求模型验证来验证它，而不是单独使用API键。
  • 结合Lambda@Edge和API网关自定义授权器，使用只有二者知道的共享秘密对传入的请求进行签名和验证。这是一种更先进的技术。

原文：https://aws.amazon.com/cn/blogs/compute/protecting-your-api-using-amazon-api-gateway-and-aws-waf-part-2/

本文：http://pub.intelligentx.net/protecting-your-api-using-amazon-api-gateway-and-aws-waf-part-2

讨论：请加入知识星球或者小红圈【首席架构师圈】

本文由AWS解决方案架构师Thiago Morais提供

当您构建web应用程序或在外部公开任何数据时，您可能会寻找一个平台，在这个平台上您可以构建高度可伸缩、安全且健壮的REST api。由于API是公开的，所以有许多最佳实践可以为使用API的用户提供安全机制。

Amazon API Gateway处理接受和处理多达数十万个并发API调用所涉及的所有任务，包括流量管理、授权和访问控制、监视和API版本管理。

在本文中，我将向您展示如何利用API网关中的区域性API端点特性，以便您可以创建自己的Amazon CloudFront发布，并使用AWS WAF保护您的API。

AWS WAF是一个web应用程序防火墙，它帮助保护您的web应用程序免受常见web攻击的影响，这些web攻击可能会影响应用程序的可用性、危害安全性或消耗过多的资源。

当您使您的api公开可用时，您就暴露在试图以几种方式利用您的服务的攻击者面前。AWS安全团队发布了一个使用AWS WAF的白皮书解决方案，即如何减轻OWASP的十大Web应用程序漏洞。

区域API端点

边缘优化API是通过由API网关创建和管理的CloudFront发布访问的端点。在启动区域API端点之前，这是使用API网关创建API时的默认选项。它主要帮助位于不同地理位置的API使用者减少延迟。

当API请求主要来自部署API时所在AWS区域内的Amazon EC2实例或其他服务时，区域API端点通常会降低连接的延迟。建议在这种情况下使用。

为了更好地控制缓存策略，客户可以为区域api使用自己的CloudFront发布。他们也有能力使用AWS WAF保护，正如我在这篇文章中所描述的。

Edge-optimized API端点

下图是一个经过边界优化的API端点的示例，您的API客户端通过由API网关创建和管理的CloudFront发布访问您的API。

区域API端点

对于区域API端点，您的客户可以从部署REST API的相同区域访问您的API。这有助于减少请求延迟，特别是允许您根据需要添加自己的内容交付网络。

预排

在本节中，您将执行以下步骤:

1. 使用PetStore示例API创建一个区域性API。
2. 为API创建一个CloudFront发布。
3. 测试云前分布。
4. 设置AWS WAF并创建web ACL。
5. 将web ACL附加到CloudFront分发版。
6. 测试AWS WAF保护。

创建区域API

对于本演练，请使用现有的PetStore API。所有新api都默认作为区域端点类型启动。要更改现有API的端点类型，请选择右上角的cog图标:

在您的帐户上创建了PetStore API之后，为PetStore API部署一个名为“prod”的阶段。

在API网关控制台，选择PetStore API并选择Actions, Deploy API。

对于Stage 名称，键入prod并添加舞台描述。

选择Deploy并创建新的API阶段。

使用以下AWS CLI命令将您的API从边缘优化更新到区域:

aws apigateway update-rest-api \ --rest-api-id {rest-api-id} \ --patch-operations op=replace,path=/endpointConfiguration/types/EDGE,value=REGIONAL

一个成功的响应如下:

{

    "description": "Your first API with Amazon API Gateway. This is a sample API that integrates via HTTP with your demo Pet Store endpoints", 

    "createdDate": 1511525626, 

    "endpointConfiguration": {

        "types": [

            "REGIONAL"

        ]

    }, 

    "id": "{api-id}", 

    "name": "PetStore"

}

 

将API端点更改为region之后，现在可以将自己的CloudFront分发版分配给这个API。

 

创建一个CloudFront发布

为了使事情变得更简单，我提供了一个AWS CloudFormation模板来部署指向您刚刚创建的API的CloudFront发布。单击此按钮将模板部署到us-east-1区域。

对于堆栈名称，请输入RegionalAPI。对于APIGWEndpoint，请按照以下格式输入您的API FQDN:

{api-id}.execute-api.us-east-1.amazonaws.com

填写完参数后，选择Next继续堆栈部署。完成部署需要几分钟。完成后，Output选项卡列出以下项目:

• A CloudFront domain URL
• An S3 bucket for CloudFront access logs

Output from CloudFormation

测试CloudFront 分发

要查看CloudFront发布是否配置正确，请使用web浏览器并从发行版中输入URL，并使用以下参数:

https://{your-distribution-url}.cloudfront.net/{api-stage}/pets

您应该得到以下输出:

[

  {

    "id": 1,

    "type": "dog",

    "price": 249.99

  },

  {

    "id": 2,

    "type": "cat",

    "price": 124.99

  },

  {

    "id": 3,

    "type": "fish",

    "price": 0.99

  }

]

设置AWS WAF并创建web ACL

有了新的CloudFront发布，您现在可以开始设置AWS WAF来保护您的API。

对于这个演示，您将部署AWS WAF安全自动化解决方案(https://aws.amazon.com/answers/security/aws-waf-security-automations/)，该解决方案对试图访问您的API的请求提供细粒度控制。

有关部署的更多信息，请参见自动部署(https://docs.aws.amazon.com/solutions/latest/aws-waf-security-automatio…)。

对于CloudFront访问日志桶名，添加在部署CloudFormation堆栈期间为您的CloudFront分发版创建的桶名。

该解决方案允许您调整阈值，并选择启用哪些自动化来保护您的API。配置完这些设置后，选择Next。

要启动帐户中的部署过程，请遵循创建向导并选择Create。完成部署需要几分钟。您可以通过CloudFormation控制台跟踪创建过程。

部署完成后，您可以看到新的web ACL部署在AWSWAF控制台AWSWAFSecurityAutomations上。

将AWS WAF web ACL附加到CloudFront分发版

部署了解决方案后，现在可以将AWS WAF web ACL附加到前面创建的CloudFront分发版。

要分配新创建的AWS WAF web ACL，请回到您的CloudFront发布。打开要编辑的发行版后，选择General Edit。

选择前面创建的新的AWSWAF web ACL  AWSWAFSecurityAutomations。

保存对CloudFront发布的更改，等待部署完成。

测试AWS WAF保护

要验证AWS WAF Web ACL设置，请使用 Artillery 加载测试API并查看AWS WAF的运行情况。

要在您的机器上安装火炮，请运行以下命令:

npm install -g artillery

安装完成后，您可以通过运行以下命令检查火炮是否安装成功:

$ artillery -V $ 1.6.0-12

在发布时， Artillery版是1.6.0-12。

您已经设置的WAF web ACL规则之一是基于速率的规则。默认情况下，它被设置为阻止任何请求者在5分钟内超过2000个请求。试试这个。

首先，使用cURL查询您的分布并查看API输出:

$ curl -s https://{distribution-name}.cloudfront.net/prod/pets

[

  {

    "id": 1,

    "type": "dog",

    "price": 249.99

  },

  {

    "id": 2,

    "type": "cat",

    "price": 124.99

  },

  {

    "id": 3,

    "type": "fish",

    "price": 0.99

  }

]

根据上面的测试，结果看起来不错。但是，如果您在5分钟内最大限度地完成2000个请求呢?

运行以下artillery 命令:

artillery quick -n 2000 --count 10 https://{distribution-name}.cloudfront.net/prod/pets

您所做的是从10个并发用户向API发出2000个请求。简而言之，我没有在这里发布炮兵(artillery )输出。

炮兵(artillery )完成它的执行后，尝试再次运行cURL请求，看看会发生什么:

$ curl -s https://{distribution-name}.cloudfront.net/prod/pets

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<TITLE>ERROR: The request could not be satisfied</TITLE>

</HEAD><BODY>

<H1>ERROR</H1>

<H2>The request could not be satisfied.</H2>

<HR noshade size="1px">

Request blocked.

<BR clear="all">

<HR noshade size="1px">

<PRE>

Generated by cloudfront (CloudFront)

Request ID: [removed]

</PRE>

<ADDRESS>

</ADDRESS>

</BODY></HTML>

从上面的输出可以看到，请求被AWS WAF阻止了。当您的IP地址低于请求限制速率时，将从阻塞列表中删除。

结论

在第一部分中，您了解了如何使用新的API网关区域API端点以及Amazon CloudFront和AWS WAF来保护您的API免受一系列攻击。

在第二部分中，我将演示使用API键和Amazon CloudFront自定义头保护API的其他一些技术。

 

原文：https://aws.amazon.com/cn/blogs/compute/protecting-your-api-using-amazon-api-gateway-and-aws-waf-part-i/

本文：http://pub.intelligentx.net/node/595

讨论：请加入知识星球或者小红圈【首席架构师圈】