对于容器安全性，你会发现许多开源工具可以帮助防止像特斯拉那样遭受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

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

 

 

我们根据行业评论，您的反馈和自己的经验，准备了2018年最佳黑客工具的有用列表。 此列表将告诉您有关用于黑客目的的最佳软件，包括端口扫描程序，Web漏洞扫描程序，密码破解程序，取证工具，流量分析和社交工程工具。

我们编制了这个顶级黑客软件列表及其最佳功能和下载链接。 阅读它们，了解如何使用它们并分享您的评论，以使这个列表更好。 如果您正在寻找用于道德黑客攻击和测试的专用操作系统，请查看此专用文章 

1. Metasploit | Best collection of exploit tools

 

我不是将Metasploit称为漏洞利用工具的集合，而是将其称为可用于构建自己的自定义工具的基础架构。 这个免费工具是最流行的网络安全工具之一，允许您在不同平台上查找漏洞。 Metasploit拥有超过200,000名用户和贡献者，可帮助您获得洞察力并发现系统中的弱点。

这个2018年的顶级黑客工具包让你可以模拟真实世界的攻击，告诉你弱点并找到它们。 作为渗透测试人员，它使用Top Remediation报告通过Nexpose闭环集成来确定漏洞。 使用开源Metasploit框架，用户可以构建自己的工具并充分利用这个多用途黑客工具。

支持的平台和下载：

Metasploit适用于所有主要平台，包括Windows，Linux和OS X.

2. Acunetix WVS | Vulnerability Scanner

 

Acunetix是一个Web漏洞扫描程序（WVS），可以扫描并发现网站中可能导致致命错误的缺陷。 这个多线程工具抓取一个网站，发现恶意的跨站点脚本，SQL注入和其他漏洞。 这个快速且易于使用的工具可以从WordPress.ethical-hacking-course-square-ad中的1200多个漏洞中扫描WordPress网站

Acunetix附带一个登录序列记录器，允许用户访问网站的密码保护区域。 此工具中使用的新AcuSensor技术可以降低误报率。 这些功能使Acunetix WVS成为您需要在2018年结账的首选黑客工具。

支持的平台和下载：

Acunetix适用于Windows XP及更高版本。

3. Nmap | Port scanner tool

Nmap - 也称为网络映射器 - 属于端口扫描程序工具的类别。 这个免费的开源黑客工具是最流行的端口扫描工具，可以实现高效的网络发现和安全审计。 Nmap用于广泛的服务，使用原始IP数据包来确定网络上可用的主机，它们的服务以及详细信息，主机使用的操作系统，使用的防火墙类型以及其他信息。

去年，Nmap赢得了多项年度奖项的安全产品，并出现在多部电影中，包括The Matrix Reloaded，Die Hard 4等。 在命令行中可用，Nmap可执行文件也带有高级GUI头像。

支持的平台和下载：

Nmap适用于所有主要平台，包括Windows，Linux和OS X.

4. Wireshark | Packet analyzer

 

Wireshark是一种众所周知的数据包制作工具，可以发现网络中的漏洞并探测防火墙规则集。 成千上万的安全专业人员使用它来分析数百个协议的网络和实时口袋捕获和深度扫描。 Wireshark可帮助您从以太网，IEEE 802.11，PPP / HDLC，ATM，蓝牙，USB，令牌环，帧中继，FDDI等读取实时数据。

这个免费的开源工具最初被命名为Ethereal。 Wireshark还有一个名为TShark的命令行版本。

支持的平台和下载：

这种基于GTK +的网络协议分析器可在Linux，Windows和OS X上轻松运行。

5. oclHashcat | Password cracking tool

 

如果密码破解是您每天都要做的事情，您可能会注意到免费密码破解工具Hashcat。 虽然Hashcat是一个基于CPU的密码破解工具，但oclHashcat是其高级版本，它使用GPU的强大功能。

oclHashcat称自己是世界上第一个也是唯一一个基于GPGPU的引擎的世界上最快的密码破解工具。 对于使用该工具，NVIDIA用户需要ForceWare 346.59或更高版本，AMD用户需要Catalyst 15.7或更高版本。

此工具使用以下攻击模式进行破解：

• 直接
• 组合
• 暴力
• 混合字典+面具
• 混合蒙版+字典

提到另一个主要功能，oclHashcat是一个MIT许可下的开源工具，可以轻松集成或打包常见的Linux发行版。

支持的平台和下载：

这个有用的密码破解工具可以在Linux，OSX和Windows的不同版本中下载。

6. Nessus | 漏洞扫描程序

 

这个2018年的顶级免费安全工具在客户端 - 服务器框架的帮助下工作。该工具由Tenable Network Security开发，是我们最受欢迎的漏洞扫描程序之一。 Nessus为不同类型的用户提供不同的用途--Nessus Home，Nessus Professional，Nessus Manager和Nessus Cloud。

使用Nessus，可以扫描多种类型的漏洞，包括远程访问漏洞检测，错误配置警报，拒绝针对TCP / IP堆栈的服务，准备PCI DSS审计，恶意软件检测，敏感数据搜索等。要启动字典攻击，Nessus也可以称之为流行工具Hydra external.ethical-hacking-course-square-ad

除了上述基本功能外，Nessus还可用于扫描IPv4，IPv6和混合网络上的多个网络。您可以将计划扫描设置为在所选时间运行，并使用选择性主机重新扫描重新扫描先前扫描的主机的全部或子部分。

支持的平台和下载：

Nessus得到了各种平台的支持，包括Windows 7和8，Mac OS X以及Debian，Ubuntu，Kali Linux等流行的Linux发行版。

7. Maltego 取证平台

 

Maltego是一个开源取证平台，提供严格的挖掘和信息收集，以描绘您周围的网络威胁。 Maltego擅长展示基础设施和周围环境中故障点的复杂性和严重性。

Maltego是一个很棒的黑客工具，可以分析人，公司，网站，域名，DNS名称，IP地址，文档等等之间的真实世界链接。 该工具基于Java，在易于使用的图形界面中运行，在扫描时丢失了自定义选项。

支持的平台和下载：

Maltego安全工具适用于Windows，Mac和Linux。

8. Social-Engineer Toolkit

 

TrustedSec的Social-Engineer Toolkit也是Robot先生的特色，是一个用于模拟多种类型的社会工程攻击的高级框架，如凭据收获，网络钓鱼攻击等。 在节目中，Elliot被使用来自Social-Engineer Toolkit的SMS欺骗工具。

这个Python驱动的工具是社交工程渗透测试的标准工具，下载量超过200万。 它可以自动化攻击并生成伪装的电子邮件，恶意网页等。

支持的平台和下载：

要在Linux上下载SET，请键入以下命令：

git clone https://github.com/trustedsec/social-engineer-toolkit/ set /

除Linux之外，Mac OS X和Windows部分支持Social-Engineer Toolkit。

9. Netsparker | Web app scanner

 

Netsparker是一种流行的Web应用程序扫描程序，可以找到SQL注入和本地文件归纳等缺陷，以只读和安全的方式建议补救措施。 由于这个黑客工具产生了一个利用证据，您不需要自己验证漏洞。 万一它无法自动验证缺陷，它会提醒您。 这个黑客工具很容易上手。 只需输入URL并让它执行扫描。 Netsparker支持基于JavaScript和AJAX的应用程序。 因此，您无需配置扫描仪或依赖某些复杂的扫描设置来扫描不同类型的Web应用程序。

如果你不想为Netsparker的专业版付钱，他们也有一个你可以使用的演示版。

支持的平台和下载：

Netsparker Web应用程序扫描程序适用于Windows

10. w3af | Web app scanner

 

w3af是一款免费的开源Web应用程序安全扫描程序，被黑客和渗透测试人员广泛使用。 w3af代表Web应用程序攻击和审计框架。使用此黑客工具，可以获得可以在渗透测试约定中进一步使用的安全漏洞信息。 w3af声称可识别200多个漏洞（包括跨站点脚本，SQL注入，PHP错误配置，可猜测的凭据和未处理的应用程序错误），并使Web应用程序（和网站）更安全。

w3af同时提供命令行和图形用户界面，以满足黑客的需求。只需不到5次点击并为初学者使用预定义的配置文件，就可以审核Web应用程序的安全性。由于它有详细记录，新用户可以轻松找到自己的方式。作为一个开源黑客工具，经验丰富的开发人员可以使用代码，添加新功能和创建新功能。

支持的平台和下载：

w3af适用于Linux，BSD和OS X.在Windows上，支持其旧版本。

11. John The Ripper

 

在密码破解工具方面，John The Ripper成为大多数道德黑客的最佳选择。 这个免费的开源软件以源代码的形式分发。

John The Ripper主要使用C编程语言编写。 它已经能够实现一个伟大的伴侣的地位，因为它是许多密码破解者合二为一的事实。 不同的模块使其能够使用不同的加密技术破解密码

支持的平台和下载：

John The Ripper黑客软件可在各种平台上使用，包括Windows，Linux，DOS，OpenVMS和Unix。

12. Aircrack-ng | Password cracking tool

在密码破解方面，Aircrack-ng是您可以探索的另一种选择。 该网络套件包括探测器，流量嗅探器和密码破解工具。 所有这些工具都是基于命令行的，并允许繁重的脚本。

使用Aircrack-ng黑客软件，您可以捕获数据包，将数据导出到文本文件，执行不同的攻击，检查WiFi卡和驱动程序功能，破解WEP和WPA PSK等。

支持的平台和下载：

Aircrack-ng适用于macOS，Linux，FreeBSD，Windows等不同平台。 Lunux版本也已移植到Android。

2018年的多种类别的其他顶级黑客和安全工具：

• Web漏洞扫描程序 - Burp Suite，Firebug，AppScan，OWASP Zed，Paros Proxy，Nikto，Grendel-Scan
• 漏洞利用工具 - Netsparker，sqlmap，Core Impact，WebGoat，BeEF
• 法医工具 - Helix3 Pro，EnCase，Autopsy
• 端口扫描仪 - Unicornscan，NetScanTools，愤怒的IP扫描仪
• 交通监控工具 - Nagios，Ntop，Splunk，Ngrep，Argus
• 调试器 - IDA Pro，WinDbg，Immunity Debugger，GDB
• Rootkit探测器 - DumpSec，Tripwire，HijackThis
• 加密工具 - KeePass，OpenSSL，OpenSSH / PuTTY / SSH，Tor
• 密码破解者 - John the Ripper, Hydra, ophcrack

我们希望您发现此列表有用。 在下面的评论中分享您的评论，并帮助我们改进此列表。

下载地址:

1. Metasploit :https://www.metasploit.com/
2. Acunetix WVS:http://www.acunetix.com/vulnerability-scanner/
3. Nmap:https://nmap.org/
4. Wireshark :https://www.wireshark.org/
5. oclHashcat :https://hashcat.net/oclhashcat/
6. Nessus:http://www.tenable.com/
7. Maltego :https://www.paterva.com/web6/products/maltego.php
8. Social-Engineer Toolkit:https://github.com/trustedsec/social-engineer-toolkit/
9. Netsparker :https://www.netsparker.com/web-vulnerability-scanner/
10. w3af :http://w3af.org/
11. John The Ripper:http://www.openwall.com/john/
12. Aircrack-ng:https://www.aircrack-ng.org/

阅读此列表的更新版本：您应该考虑的47个强大的开源应用程序秒工具

您无需花费大量资金在应用程序开发和交付日程中引入高功率安全性。这本开源应用程序工具指南旨在帮助那些希望投资应用程序安全软件的团队了解开源领域的内容，以及如何思考这些选择。随后将发布商业app sec供应商指南。

为什么需要免费的app sec工具指南？一般而言，有关应用程序安全性的信息可能会令人困惑，因为网站通常会在没有明确描述所提供解决方案类别的情况下展示产品的优势。这使得将一种产品与下一种产品进行比较变得困难。开源项目的网站通常提供有关特定工具的非常精细的信息，这要求读者已经了解如何以及为何使用特定工具。

开源app sec工具的价值

大多数开源项目都是针对app sec要求而设计的，其规模小于商业供应商所倾向的目标。尽管如此，我们认为这个高度专注的开源应用程序提供商名单应该为安全爱好者所熟悉，他们寻求针对特定类型的网络威胁的新的创造性方法。

其中一些操作系统项目非常活跃，并且经常使用新功能进行更新;其他人，嗯，不是那么多，但他们值得一试。自网络诞生以来，一些更强大的OS技术已经存在;其他人都很新，在推特和其他地方有越来越多的粉丝。

请注意，此处的一些列表是免费的“社区版”的高级商业产品。另请注意，您无法再通过.org或.net后缀识别开源项目。正如您将看到的，许多人现在使用.com约定以及许多其他URL约定。

Andiparos

着名的Paros Proxy的一个分支，一个开源Web应用程序安全评估工具，为渗透测试人员提供了抓取网站，分析内容，拦截和修改请求的能力
网址：https：//code.google.com/archive/p/andiparos

 

BackTrack

这个发行版称为基于Linux的渗透测试工具，配置有数百种安全测试工具和脚本
网址：http：//www.backtrack-linux.org

BeEF

开源的渗透测试
网址：http：//beefproject.com

 

Caja

用于使第三方HTML，CSS和JavaScript安全嵌入网站的编译器。它使用对象功能安全模型来实现各种灵活的安全策略。
网址：http：//developers.google.com/caja

 

ClamAV

用于检测特洛伊木马，病毒，恶意软件和其他恶意威胁的开源防病毒引擎
网址：http：//clamav.net

 

DOM Snitch

实验性Chrome扩展程序，使开发人员和测试人员能够识别客户端代码中常见的不安全做法。开发人员和测试人员可以在浏览器内部进行DOM修改，无需使用调试器逐步执行JavaScript代码或暂停其应用程序的执行
网址：https：//code.google.com/archive/p/domsnitchdomsnitch

 

Ettercap

被称为“针对中间人攻击的综合套件......具有嗅探现场连接，动态内容过滤以及许多其他有趣的技巧。”
网址：http：//ettercap.github.io/ettercap

 

GoLismero

用于安全测试的免费软件框架。
网址：http：//www.golismero.com

 

谷歌黑客数据库（GHDB）

SecTools.org将其描述为“安全研究人员和渗透测试人员的金矿”，该网站是漏洞利用数据库的一部分，这是一个非营利性项目，由进攻性安全部门提供为公共服务。
网址：https：//www.exploit-db.com/google-hacking-database

 

Google应用安全工具

谷歌表示，这些工具“解决了其他开源工具中存在的差距。这些工具可能需要进行一些小的调整或编译才能在您的系统上运行。”有些是单独列在此列表中。
网址：https：//www.google.com/about/appsecurity/tools

Grabber

Web应用程序扫描程序，可以检测Web应用程序中的许多安全漏洞。一个开源的Web应用程序渗透测试工具
网址：http：//rgaucher.info/beta/grabber

 

Grendel

扫描Web应用程序安全工具以查找安全漏洞;功能也可用于手动渗透测试
网址：https：//sourceforge.net/projects/grendel

 

Gruyere

被称为“小型，俗气的网络应用程序”;允许用户发布文本片段并存储各种文件。警告：Gruyere有多个安全漏洞，包括跨站点脚本和跨站点请求伪造，信息泄露，拒绝服务和远程代码执行
网址：http：//google-gruyere.appspot.com

 

Kali

Linux渗透测试
网址：http：//kali.org

 

Keyczar

开源加密工具包旨在使开发人员在其应用程序中使用加密更容易，更安全。它支持对称和非对称密钥的身份验证和加密;旨在实现开放，可扩展和跨平台兼容。
网址：https：//github.com/google/keyczar

 

Kismet

无线网络探测器，嗅探器和入侵检测系统。 Kismet主要使用Wi-Fi（IEEE 802.11）网络，但可以通过插件扩展以处理其他网络类型。
网址：http：//kismetwireless.org

 

Malwarebytes

适用于Windows的端点安全恶意软件扫描程序。
网址：http：//malwarebytes.org

 

Metasploit

通过Rapid7渗透测试开源的Metasploit
网址：http：//metasploit.com

 

ModSecurity

WAF开源
网址：http：//modsecurity.org

 

Nagios

监控整个IT基础架构，以确保系统，应用程序，服务和业务流程正常运行。
网址：http：//nagios.org

Native Client (NaCl)

一种在浏览器中运行本机编译代码的技术。 NaCl旨在保持人们对Web应用程序的操作系统可移植性和安全性
网址：http：//developer.chrome.com/native-client

 

Nikto2

Web服务器测试工具，用于查找已知的易受攻击脚本，配置错误和相关的安全问题
网址：http：//cirt.net/nikto2

 

NMAP

使用NSE脚本进行网络发现和安全审核的渗透测试实用程序，可以检测网络服务中的漏洞，错误配置和安全相关信息
网址：http：//nmap.org

 

NoScript

Firefox插件，为Firefox，Seamonkey和其他基于Mozilla的浏览器提供额外保护;允许JavaScript，Java，Flash和其他插件只能由您选择的受信任网站执行
网址：http：//noscript.net

 

OpenSSH

通过SSH隧道隧道安装不安全的协议来保护两点之间的流量
网址：http：//www.openssh.com

 

OpenVAS

开源漏洞扫描套件
网址：http：//openvas.org

 

OSSEC

基于主机的入侵检测系统或HIDS
网址：http：//ossec.github.io

 

OWASP

owasp.org提供了一大类开源sec测试工具
网址：https：//www.owasp.org/index.php/Appendix_A:_Testing_Tools

 

Packet Storm

提供各种用于漏洞和渗透的扫描仪工具
网址：http：//packetstormsecurity.org/files/tags/scanner

 

Paros Proxy

用于安全性和漏洞测试的测试工具。用于对整个站点进行爬行/爬网，然后执行预装漏洞扫描程序测试
网址：http：//www.testingsecurity.com/paros_proxy

 

Powerfuzzer

基于HTTP协议的应用程序模糊器基于许多其他开源模糊器
网址：http：//www.powerfuzzer.com

 

Ratproxy

旨在克服用户在使用其他代理工具进行安全审核时通常面临的问题;能够区分CSS样式表和JavaScript代码
网址：https：//code.google.com/archive/p/ratproxy

 

Secunia PSI

一种免费的计算机安全解决方案，可识别私人PC上的应用程序中的漏洞
Web：http：//learn.flexerasoftware.com/SVM-EVAL-Personal-Software-Inspector

 

Security Onion

用于入侵检测，网络安全监控和日志管理的Linux发行版
网址：http：//blog.securityonion.net

 

Skipfish

活跃的Web应用程序安全侦察工具。它通过执行递归爬网和字典工具为站点准备交互式站点地图。使用自定义HTTP堆栈编写的C语言，性能高，易于使用且可靠
网址：https：//code.google.com/archive/p/skipfish

 

Snort

用于UNIX衍生产品和Windows的开源，免费和轻量级网络入侵检测系统（NIDS）
网址：http：//snort.org

 

SonarQube

SonarQube™软件（以前称为“Sonar”）是一个管理代码质量的开放平台。因此，它涵盖了7轴代码质量。
网址：https：//github.com/SonarSource/sonarqube

SQLMAP

渗透测试工具，自动化在网站数据库中查找和利用SQL注入漏洞的过程
网址：http：//sqlmap.org

 

TCPDUMP

在其网站上称为“功能强大的命令行数据包分析器”，许多人仍然使用此工具作为资源密集型Wireshark的替代工具。
网址：http：//tcpdump.org

 

Vega

Web漏洞扫描器和测试平台; SQL注入，跨站点脚本等
网址：https：//subgraph.com/vega

 

W3AF

SQL注入，跨站点脚本检测工具
网址：http：//w3af.org

 

Wapiti

Web漏洞扫描程序，可让您审核Web应用程序的安全性。它通过扫描网页和注入数据来执行黑盒测试
网址：http：//wapiti.sourceforge.net

 

Watcher

一个Fiddler插件，帮助渗透测试人员被动地发现Web应用程序漏洞
网址：http：//websecuritytool.codeplex.com

 

WATOBO

执行高效（半自动）Web应用程序安全审核
网址：http：//watobo.sourceforge.net/index.html

 

WebScarab

基于Java的安全框架，用于使用HTTP或HTTPS协议分析Web应用程序。用Java编写，可移植到许多平台;提供多种操作模式，由多个插件实现。在最常见的用法中，WebScarab作为拦截代理运行
网址：http：//www.owasp.org/index.php/Category：WHASP_WebScarab_Project

 

Websecurify

GNUCITIZEN（参见商业供应商列表）
网址：

 

Wfuzz

免费提供的用于Web应用程序渗透测试的开源工具。它可用于强制GET和POST参数，以便针对SQL，XSS，LDAP等许多其他注入进行测试
网址：http：//code.google.com/p/wfuzz

 

SensePost

设备，网络和应用程序的漏洞工具。工具包括autoDANE，reGeorg，Jack和SensePost Maltego工具集
网址：http：//sensepost.com

 

Wireshark

Wireshark渗透测试和数据包级监控开源;根据需要查看详细的流量;关注网络流并发现问题
网址：http：//wireshark.org

 

Zed攻击代理

也称为Zap。开源，拦截代理是fork和更新严重过时的Paros Proxy。相当强大的手动测试，并包含一些自动测试功能。
网址：https：//www.owasp.org

 

讨论：请加入只是星球【首席架构师圈】

Gauntlt为各种安全工具提供了钩子，并将它们放在安全，开发和运营团队的手中，以协作构建坚固的软件。 它旨在促进组之间的测试和通信，并创建可操作的测试，这些测试可以连接到您的部署和测试过程中。

特征

 

• Gauntlt攻击以易于阅读的语言编写
• 轻松连接到组织的测试工具和流程
• 安全工具适配器配有gauntlt
• 使用unix标准错误和标准输出来传递状态

Gauntlt包含这些工具的攻击适配器：

• curl
• nmap
• sslyze
• sqlmap
• Garmr
• generic command line
• more coming soon

有两种方法可以开始使用gauntlt。 您可以使用gem安装方法，这将需要您下载和设置安全工具（不用担心gauntlt引导您完成）或者您可以使用Gauntlt入门工具包，这是一个流浪脚本，将自动为您启动工具。

 

Get started using in 3 easy steps

1. Install the gem

   
   $ gem install gauntlt
   		    

2. Download example attacks and customize. Here is a very simple network attack using the nmap adapter.

   
   # nmap-simple.attack
   Feature: simple nmap attack to check for open ports
   
     Background:
       Given "nmap" is installed
       And the following profile:
         | name     | value       |
         | hostname | example.com |
   
     Scenario: Check standard web ports
       When I launch an "nmap" attack with:
         """
         nmap -F <hostname>
         """
       Then the output should match /80.tcp\s+open/
       Then the output should not match:
         """
         25\/tcp\s+open
         """
   

3. Run gauntlt to launch the attack defined above

   
   $ gauntlt
     # equivalent to gauntlt ./**/*.attack
     # you can also specify one or more paths yourself:
   $ gauntlt my_attacks/nmap-simple.attack
     # other commands to help
   $ gauntlt --list
     # the list option will show you the tools that are 
     # available to use with gauntlt
   $ gauntlt --steps
     # the steps option will show the gauntlt specific 
     # steps you can use in your attacks
   $ gauntlt --allsteps
     # the allsteps option will show all steps including 
     # aruba file operations and parsing steps that are 
     # available to use in attacks
   $ gauntlt --help
     # when all else fails use the help
   		

   For more attack examples, refer to the examples.

安全测试通常在审计员的日程安排上进行，测试输出并不总是可操作的。 因此，针对已修复问题的回归常常会回到代码中。 这不好。 它应该是不同的。

原文：http://gauntlt.org/

本文：http://pub.intelligentx.net/gauntlt-be-mean-your-code-and-it

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

nginx是一个网络服务器，它正在世界上越来越多的网站上取代Apache。到目前为止，nginx还不能从ModSecurity提供的安全性中获益。下面是如何安装ModSecurity并让它与nginx一起工作。

今年早些时候，流行的开源网络应用防火墙ModSecurity发布了其软件的第三版。版本3与早期版本有很大的不同，因为它现在已经模块化了。在版本3之前，ModSecurity仅作为一个依赖模块与Apache web服务器一起工作，因此其他HTTP应用程序无法使用ModSecurity。现在，HTTP过滤引擎ModSecurity的核心功能作为一个独立的库libModSecurity存在，它可以通过一个“连接器”集成到任何其他应用程序中。连接器是允许任何应用程序访问libModSecurity的一小段代码。

Web应用程序防火墙(WAF)是用于HTTP请求的一种防火墙。标准防火墙在数据包到达和离开网络接口时检查数据包，并根据规则列表比较数据包的属性。规则规定防火墙是允许数据包通过还是阻止数据包。

ModSecurity执行与标准防火墙相同的任务，但它不是查看数据包，而是在HTTP流量到达服务器时检查它。当HTTP请求到达服务器时，它首先通过ModSecurity路由，然后再路由到目标应用程序，如Apache2或nginx。ModSecurity将入站HTTP请求与规则列表进行比较。这些规则定义了恶意或有害请求的形式，因此，如果传入的请求与规则匹配，ModSecurity将阻止请求到达可能造成伤害的目标应用程序。

下面的例子演示了ModSecurity如何保护WordPress站点。下面的HTTP请求是index.php文件的非恶意请求，它出现在Apache2的日志文件中:

GET /index.php HTTP/1.1

这个请求不匹配任何规则，因此ModSecurity允许它进入web服务器。

WordPress在一个名为wp-config的文件中保存了很多秘密信息，比如数据库密码。它位于与index.php文件相同的目录中。粗心的系统管理员可能不保护这个重要的文件，这意味着像Apache或nginx这样的web服务器很乐意为它提供服务。这是因为它们将提供不受特定配置保护的任何文件。这意味着以下恶意请求:

GET /wp-config.php HTTP/1.1

将由Apache提供给任何请求它的人。

这就是ModSecurity为接受HTTP数据的应用程序提供保护的地方。在本例中，免费的核心ModSecurity规则集包含拒绝任何试图访问WordPress安装中的任何敏感文件的HTTP请求的规则。核心规则集还包含另一个流行的CMS Drupal的规则。

核心规则集还包含许多其他规则，这些规则涵盖了恶意构造HTTP请求以从网站获得访问或机密信息的许多其他方法。这些方法包括SQL注入、漏洞扫描、Java和PHP漏洞利用等等。ModSecurity还支持自定义规则，因此您可以通过编写自己的规则来保护HTTP应用程序免受特定目标的攻击。

首先让我们安装核心ModSecurity库libModSecurity，然后安装nginx连接器，使nginx能够使用ModSecurity。在版本3之前，nginx不可能使用ModSecurity。如果您正在使用Apache2，您应该继续使用ModSecurity version 2，因为Apache2连接器仍然有很多bug，不建议在生产环境中使用。

 

编译和安装libModSecurity

ModSecurity3不能通过包管理器用于任何主要的Linux发行版。相反，您需要克隆ModSecurity GitHub存储库，并从其源代码构建库。但在此之前，您必须安装所有必需的构建工具和依赖项。下面的列表的包提供了所有必需的和大部分的可选的差异在Debian和Ubuntu发行版:野牛,flex,, automake, gcc, pkg-config, libtool, doxygen, git,卷发,zlib1g-dev, libxml2-dev, libpcre3-dev,建设重要,libyajl-dev, yajl-tools, liblmdb-dev, rdmacm-utils, libgeoip-dev, libcurl4-openssl-dev, liblua5.2-dev, libfuzzy-dev, openssl和libssl-dev。

注意，其中一些包在基于Red hat的发行版上有不同的名称。这个页面将帮助您确定具体的包名是什么。

安装这些包之后，您可以继续编译库。这些指令与分布无关。

首先，克隆libModSecurity git存储库，它将下载构建libModSecurity所需的所有源代码。使用/opt/目录作为所有源代码的目标。移动到/opt/目录，并使用以下命令克隆libModSecurity git存储库:

cd /opt/
git clone https://github.com/SpiderLabs/ModSecurity

接下来，进入克隆ModSecurity存储库时创建的新目录，并切换到v3分支。你还需要引入几个必要的子模块:

cd ModSecurity
git checkout v3/master
git submodule init
git submodule update

现在可以构建libModSecurity了。对于任何从源代码编译程序的人来说，这应该是一个熟悉的过程。你只需要以下三个命令来编译和安装程式库:

sh build.sh
./configure
make
make install

如果您在一个普通的虚拟服务器上运行make命令，则需要几分钟。libModSecurity库现在安装在/usr/local/modsecurity/lib/ libModSecurity .so上。但是，在安装将HTTP数据连同一些规则重定向到libModSecurity库的应用程序和连接器之前，它不能做任何事情。下一节将介绍如何安装nginx连接器和ModSecurity开发人员提供的核心规则集。

编译nginx连接器

让我们利用nginx动态加载第三方模块的能力来编译nginx连接器。nginx从1.11.5版开始就能够做到这一点。此版本或更高版本在大多数主要发行版的标准存储库中都不可用。nginx为Red Hat/CentOS、Debian和Ubuntu的当前稳定版本提供了存储库，其中包含一个支持动态模块加载的版本。这个页面列出了这些存储库以及将nginx存储库添加到您的发行版的信息。在将nginx存储库添加到存储库配置之后，需要使用包管理器安装nginx。当你安装了nginx，用这个命令找到你安装的版本:

nginx - v

当您拥有版本号时，请切换到/opt/目录并从此页下载与nginx版本匹配的源代码，然后解压缩下载的存档文件。

接下来，您需要为ModSecurity nginx连接器克隆git存储库。从/opt/目录中运行以下命令克隆这个存储库:

git clone https://github.com/SpiderLabs/ModSecurity-nginx

现在切换到解压nginx源存档时创建的新目录。在该目录中，运行以下命令编译连接器:

./configure --with-compat
 ↪--add-dynamic-module=/opt/ModSecurity-nginx
make modules

现在，您需要使用以下命令将连接器模块复制到nginx modules目录中:

cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

现在已经编译了nginx连接器并将其复制到正确的位置，您需要配置nginx来使用它。此外，还需要下载libModSecurity用于过滤HTTP数据的规则。

首先，移动到nginx配置目录:

cd /etc/nginx/

并将以下行添加到nginx的主配置文件/etc/nginx/nginx.conf:

load_module modules/ngx_http_modsecurity_module.so;

您需要将这一行放在以pid开头的行下面的第一个部分中，而不是放在事件或http部分中。

接下来，创建一个新的目录，并加载ModSecurity规则和配置到其中:

mkdir /etc/nginx/modsec
cd /etc/nginx/modsec
git clone https://github.com/SpiderLabs/
↪owasp-modsecurity-crs.git

使用从git存储库下载的ModSecurity rules配置文件，使用以下命令重新命名它:

mv /etc/nginx/modsec/owasp-modsecurity-crs/
↪crs-setup.conf.example /etc/nginx/modsec/
↪owasp-modsecurity-crs/crs-setup.conf

现在需要将ModSecurity配置文件从构建libModSecurity的目录复制到/etc/nginx/modsec/:

cp /opt/ModSecurity/modsecurity.conf-recommended
 ↪/etc/nginx/modsec/modsecurity.conf

最后，创建一个新的配置文件，加载这两个配置文件和所有规则文件。这个文件将由nginx服务器配置块中的几行代码调用，这将调用ModSecurity的使用。用文本编辑器创建并开始编辑这个文件:

nano /etc/nginx/modsec/main.conf

添加以下三行到这个文件:

Include /etc/nginx/modsec/modsecurity.conf
Include /etc/nginx/modsec/owasp-modsecurity-crs/crs-setup.conf
Include /etc/nginx/modsec/owasp-modsecurity-crs/rules/*.conf

现在已经完成了nginx、libModSecurity、nginx连接器和ModSecurity规则的构建和安装。现在可以启动或重新启动nginx来加载新配置。如果一切正常，在重新启动nginx时，您不会看到打印出任何错误。

测试ModSecurity

让我们通过向“默认”服务器添加几行代码并发出一个将被ModSecurity阻塞的请求来测试ModSecurity。默认的服务器配置是nginx在安装时使用的配置，并且只在本地主机上监听，而不在面向internet的网络接口上监听。这使得在创建任何自定义服务器配置之前启动nginx是安全的，因为默认配置无法从internet访问。

默认服务器配置位于/etc/nginx/conf.d/default.conf。使用文本编辑器打开此文件，并在server_name行下添加以下两行:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;

重新启动nginx来加载这个新配置。现在，要测试ModSecurity是否正常工作，您所需要做的就是发出一个匹配禁用规则的HTTP请求。

ModSecurity有两种操作模式。默认情况下，它将只记录与禁止规则匹配但允许它们传递给应用程序的查询。这种模式允许系统管理员运行ModSecurity一段时间，并确保没有干扰网站正常运行的假阳性请求被阻塞。ModSecurity将这些与/var/log/modsec_audit.log中禁止的规则匹配的请求记录下来。

您可以创建一个HTTP请求，通过使用curl发出包含禁用用户代理头的请求，该请求将被记录到该日志文件中。下面的命令发出一个HTTP请求，其中包含标题“User-Agent: masscan”。这是一个被禁止的用户代理，所以ModSecurity记录了它目睹了一个被禁止的HTTP请求。这个命令看起来像:

curl -H "User-Agent: masscan" http://localhost/

nginx返回默认的欢迎页面作为原始HTML，但是ModSecurity在/var/log/modsec_audit.log中创建了一个很长的日志条目，开头是:

ModSecurity: Warning. Matched "Operator `PmFromFile'
 ↪with parameter `scanners-user-agents.data' against
 &rarrhkk;variable `REQUEST_HEADERS:User-Agent' (Value: `masscan' )

这表明ModSecurity成功拦截并匹配了恶意HTTP请求。

当您想要将ModSecurity从记录恶意HTTP请求切换到主动阻塞它们时，请编辑/etc/nginx/modsec/modsecurity.conf中的行:

SecRuleEngine DetectionOnly

to

SecRuleEngine On

并重启nginx。现在相同的curl请求将导致403错误:

curl -H "User-Agent: masscan" http://localhost/
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.12.2</center>
</body>
</html>

被阻塞的请求也将被记录到/var/log/modsec_audit.log。

额外的ModSecurity连接器

ModSecurity新的模块化特性意味着任何接受或处理HTTP数据的应用程序都可以使用ModSecurity及其规则来分析HTTP数据。在撰写本文时，ModSecurity v3的发布质量只有几个月的时间，因此没有太多额外的连接器可以让应用程序连接到libModSecurity。

谷歌代码之夏产生了一些有趣的新连接器。第一个扩展了Snort v3使用ModSecurity规则的能力。Snort是一个入侵检测和实时包嗅探及日志记录应用程序。这个连接器允许Snort将捕获的HTTP数据发送到libModSecurity，并根据ModSecurity规则集对其进行检查。这个项目的主页(https://akoul.github.io/)在这里。

第二个google赞助的连接器目标是node.js服务器。js是一个JavaScript运行时，支持创建可伸缩的网络应用程序。该连接器通过ModSecurity路由所有入站HTTP请求，从而向节点应用程序添加一个安全层。你可以在它的主页上阅读更多关于这个项目的信息(https://m2n.me/gsoc)。

ModSecurity v3的发布将ModSecurity从Apache模块转换为一个灵活的应用程序，任何接受HTTP数据的应用程序都可以轻松地利用这个灵活的应用程序。由于人们所依赖的应用程序越来越多地从本地计算机转移到数据中心，因此确保这些应用程序和数据的安全性变得越来越重要。

 

原文：https://www.linuxjournal.com/content/modsecurity-and-nginx

本文：

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

有时我们看到ModSecurity用户在邮件列表中询问性能。在这篇文章中，我将讨论一些提高ModSecurity性能的重要主题。

1 - HTTP缓存和加速

在一个通用的web环境中，静态内容(例如。图像)http通信的大部分区域。通常，用户不希望对这类内容执行安全规则。因此，第一个建议是在ModSecurity前面设置一个HTTP缓存和加速解决方案。

我们有有趣的开源解决方案，其中之一就是Varnish。。您可以将其设置在ModSecurity前面，并将其配置为缓存静态流量。一旦完成，Varnish将开始提供这类内容，ModSecurity将只看到真正需要的东西。

另一个可能的解决方案是设置规则来检测您想要检查和忽略其他文件扩展名:

SecRuleEngine On

SecAction "id:'1', phase:1, t:none,setvar:'tx.inspect_extensions=.html/ .php/', nolog, pass"

SecRule REQUEST_BASENAME "\.(.*)$""chain,capture,allow,setvar:tx.exts=.%(tx.1}/,phase:1, t:none,t:urlDecodeUni, t:lowercase,id:2,logdata:'%{TX.0}'"

SecRule TX:EXTS "!@within %{tx.inspect_extensions}"

然而，这并不是最好的解决方案，因为即使您跳过所有其他规则，ModSecurity也会花时间对这类数据进行缓冲、转发和执行一些规则。

2 -规则选择

如果您正在使用OWASP核心规则集，那么规则选择是另一个要讨论的重要主题。

我们在CRS中有许多类别的规则，您应该重新查看它们，并确定所有类别和规则对您是否重要。

我们建议加载所有规则，但是从性能的角度来看，有时是不可能的。所以你应该做一个风险分析，并载入原始数据。

3 -规则执行模式

OWASP核心规则集项目中的规则可以在两种不同的模式下执行:

自包含模式——规则继承“拒绝”破坏性操作。第一个匹配的规则将被阻塞。

协作检测模式——这是一种“延迟阻塞”操作模式，其中每个匹配规则将继承“通过”操作，并且只会导致异常分数。

从性能的角度来看，自包含模式是最好的解决方案，因为它执行的规则应该少于协作模式，从而减少了由规则引擎和日志引擎引起的开销。然而，从假阳性的角度来看，协作模式可以发出较少的假阳性。

也就是说，您应该首先尝试默认模式(自包含模式)，然后决定是否适合您。如果没有，在决定转向协作检测模式之前，我建议先使用ModSecurity规则异常特性。

值得一提的是，只有在SecRuleEngine打开时，才应该从性能的角度看到结果。

4 -规则预过滤

如果您打算编写自己的规则，特别是使用@rx操作符和非平凡的正则表达式来检查大量数据，比如响应体，您应该考虑使用@pm操作符作为预过滤器规则:

SecRule RESPONSE_BODY "@pm some_leak_patterns" "phase:4,chain,id:12345,deny"SecRule RESPONSE_BODY "@rxyour_nontrivial_regex_some_leak_patterns"

@pm操作符使用一种名为Aho-Corasick的快速多模式匹配算法，可以用来避免对入站和出站缓冲区执行regex。

另一个预过滤器的想法是:

1. 立即拒绝来自国家的ip
2. 立即拒绝有坏名声的ip
3. 立即拒绝不允许参数数量的事务
4. 立即拒绝参数长度不允许的事务。。

有了这个想法，您可以构建一小组规则，这些规则将在CRS之前运行，并将立即拒绝事务，以避免根据所有CRS规则检查它们。

5 -缓冲

ModSecurity工作，缓冲入站和出站数据到belater受规则检查。与此主题相关的主要瓶颈是缓冲响应体，原因有二:它将消耗大量RAM，并且通常放置在响应体阶段的规则非常昂贵。

也就是说，您可以考虑禁用响应体检查功能，将SecResponseBodyAccess设置为Off，并有条件地启用它，在特定情况下使用针对特定类型ecresponsebodymimetypes的responseBodyAccessOn ..

例如:

SecResponseBodyMimeType text/plain text/html text/xml

SecResponseBodyAccess Off

SecRule REQUEST_BODY|ARGS "@pm union select""phase:2,chain,id:1234,ctl:responseBodyAccess=On"

SecRule REQUEST_BODY|ARGS "@rxyour_nontrivial_regex_union_select"

SecRule RESPONSE_BODY "@pm some_leak_patterns""phase:4,chain,id:12345,deny"

SecRule RESPONSE_BODY "@rxyour_nontrivial_regex_some_leak_patterns"

6 -日志

如果你不集中注意力，日志引擎可能会成为性能杀手:

在规则中不断执行调优过程，以避免太多的误报。请记住，磁盘i/o非常昂贵，并且您不希望花费资源来记录误报。

不要使用串行记录模式。它使用锁来保护文件，这会降低性能。而是使用并发模式。

检查正在记录的审计日志部分。像k和E这样的部分可能会增加日志引擎带来的开销，因为它通常需要向磁盘写入大量数据。

不要启用生产中的调试日志。

7 - PCRE-JIT

在pcrelibrary中插入了即时编译器支持(>=8.20)。即时编译是一种优化，可以极大地加快模式匹配操作。当相同的条件被多次匹配时，效果最好。

发布8.20 21-Oct-2011——

这个版本的主要变化是包含了ZoltanHerczeg的即时编译器支持，可以通过构建PCREwith——enable-jit来访问它。8.20还修复了8.13中引入的一个不幸的bug，并消除了与Perl的一些错误和差异。

ModSecurity 2.7。x系列可以使用PCRE-JIT执行regex。从性能的角度来看，这是一个非常好的特性。要启用它，您必须使用以下配置选项编译ModSecurity:

./configure –enable-pcre-jit

确保您的PCRE库是使用JIT支持编译的(使用上面的PCRE发行说明中描述的选项)。而且modsecurityandapache必须使用相同的库版本。你可以查看intoerror log来检查它。

例如，我们发送了一个大的输入，请求体规则处理并测量了花费的时间:

JIT Disabled Phase 2 rules = 422749 usecs

JIT Enabled Phase 2 rules = 115777 usecs

看看这个例子，pcr -jit可以使规则平均速度提高75%。

8.缓存Lua虚拟机

这适用于需要在同一事务中执行多个Lua脚本的人。正常情况下，ModSecurity会创建并销毁一个运行在同一事务中的VM foreach lua脚本。你可以改变这个行为，重新编译ModSecurity与选项:

./configure –enable-lua-cache

重新编译后，ModSecurity将在整个事务期间将LuaVM保存在内存中，从而减少create/destroyVM操作造成的开销。

作为一个例子，让我们来测量在同一事务中执行的三个脚本的性能:

禁用缓存

Lua: Executing script: /etc/apache2/modsecurity/script1.lua

Lua: Script completed in 742 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script2.lua

Lua: Script completed in 517 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script3.lua

Lua: Script completed in 489 usec, returning: 1.

Total: 1748usecs

缓存启用

Lua: Executing script: /etc/apache2/modsecurity/script1.lua

Lua: Script completed in 592 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script2.lua

Lua: Script completed in 130 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script3.lua

Lua: Script completed in 101 usec, returning: 1.

Total: 823usecs

我们可以看到由VM创建/销毁操作导致的开销减少了约50%。

9.检测昂贵的规则。

如果有更多的性能问题，您可以尝试以下步骤来找到昂贵的规则，然后有机会改进它。

作为一个例子，假设我们试图检测运行在阶段2(请求体)上的昂贵规则。如果您使用的是最新的modsecurity版本(>= 2.7.4)，则可以使用所有这些特性。

创建一个规则来检测阶段2是否存在问题。假设1000微秒太多了

SecRule PERF_PHASE2 "@qt 1000" "id:1234,phase:3"

如果你有一个触发器，它表明你有昂贵的规则。因此，让我们试着检测它们是否添加了遵循规则

# All rules that spent more than 50usecs will be present inaudit log part H

SecRulePerfTime 50

# PERF_RULES is a collection that will contain all rulesthat spent more than SecRulePerfTime vallue to run.

SecRule PERF_RULES "@qt 50" "id:1,phase:3"

所以如果你有昂贵的规则，我们会看到警告:

[Tue Apr 23 17:50:26 2013] [error] [client 192.168.0.103]ModSecurity: Warning. Operator GT matched 50 at PERF_RULES:960032. [file"/etc/apache2/modsecurity/owasp-modsecurity-crs-2.2.6/base_rules/modsecurity_crs_99_perl.conf"][line "2"] [id "1"] [hostname "192.168.0.104"][uri "/acao.php"] [unique_id "UXcCIsCoAGUAACvOLqcAAAAD"]

[Tue Apr 23 17:50:26 2013] [error] [client 192.168.0.103]ModSecurity: Warning. Operator GT matched 50 at PERF_RULES:958022. [file"/etc/apache2/modsecurity/owasp-modsecurity-crs-2.2.6/base_rules/modsecurity_crs_99_perl.conf"][line "2"] [id "1"] [hostname "192.168.0.104"][uri "/acao.php"] [unique_id "UXcCIsCoAGUAACvOLqcAAAAD"]

[Tue Apr 23 17:50:26 2013] [error] [client 192.168.0.103]ModSecurity: Warning. Operator GT matched 50 at PERF_RULES:973323. [file"/etc/apache2/modsecurity/owasp-modsecurity-crs-2.2.6/base_rules/modsecurity_crs_99_perl.conf"][line "2"] [id "1"] [hostname "192.168.0.104"][uri "/acao.php"] [unique_id "UXcCIsCoAGUAACvOLqcAAAAD"]

我们可以看到，规则960032、958022和973323的执行花费了50 usecs。，但具体需要多少时间呢?您将把这些信息放入审计日志H部分:

Rules-Performance-Info: "960032=622","958022=731", "973323=109".

请查看参考手册以查看所有PERF_variables。

10 -永久存储

ModSecurity的持久存储机制是基于磁盘的。尽管如此，它并不快，好像我们可以共享内存中的数据。因此，如果可能的话，我们可以在RAMDISK中设置和定义数据目录。modsecurity中持久存储文件可能比需要的大，因为旧条目只有在过期时才会被覆盖。默认过期时间是3600秒，这通常太多了，您可能需要几分钟的数据，所以可以使用SecCollectionTimeout指令减少默认超时。

 

原文：https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-performance-recommendations/

本文:http://pub.intelligentx.net/modsecurity-performance-recommendations

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

 

OWASP依赖性检查

Dependency-Check是一个软件组合分析实用程序，用于识别项目依赖关系并检查是否存在任何已知的，公开披露的漏洞。目前，支持Java和.NET;为Ruby，Node.js，Python添加了额外的实验支持，并为C / C ++构建系统（autoconf和cmake）提供了有限的支持。该工具可以作为OWASP Top 10使用已知漏洞的组件的解决方案的一部分，该漏洞以前称为OWASP Top 10 2013 A9  - 使用具有已知漏洞的组件。

介绍

OWASP Top 10 2013包含一个新条目：A9-使用具有已知漏洞的组件。依赖性检查当前可用于扫描应用程序（及其依赖库）以识别任何已知的易受攻击的组件。

Jeff Williams和Arshan Dabirsiaghi在题为“不安全库存的不幸现实”的论文中很好地描述了使用已知易受攻击组件的问题。本文的要点是，作为开发社区，我们在应用程序中包含第三方库，其中包含众所周知的已发布漏洞（例如国家漏洞数据库中的漏洞）。

Dependency-check有一个命令行界面，一个Maven插件，一个Ant任务和一个Jenkins插件。核心引擎包含一系列分析器，用于检查项目依赖性，收集有关依赖项的信息（在工具中称为证据）。然后，该证据用于标识给定依赖项的公共平台枚举（CPE）。如果标识了CPE，则会在报告中列出关联的常见漏洞和披露（CVE）条目的列表。

依赖关系检查使用NIST托管的NVD数据源自动更新自身。重要说明：数据的初始下载可能需要十分钟或更长时间。如果您每七天至少运行一次该工具，则只需要下载一个小的XML文件，以使数据的本地副本保持最新。

 

Quick Download

Version 5.1.0

• Command Line
• Ant Task
• Maven Plugin
• Gradle Plugin
• Mac Homebrew:
  brew update && brew install dependency-check

Version 4.0.2

• Jenkins Plugin

Other Plugins

• sbt Plugin
• lein-dependency-check

Integrations

• SonarQube Plugin
• Circle CI Orb

 

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

引擎

1. 网络入侵检测系统(NIDS)引擎
2. 网络入侵防御系统(NIPS)引擎
3. 网络安全监控(NSM)引擎
4. 离线分析PCAP文件
5. 使用pcap记录器记录流量
6. Unix套接字模式，用于自动PCAP文件处理
7. 与Linux Netfilter防火墙的高级集成

操作系统支持

1. Linux
2. FreeBSD
3. OpenBSD
4. macOS / Mac OS X
5. Windows

配置

1. 配置文件-人和机器可读
2. 良好的注释和文档
3. 支持包括其他文件

TCP / IP引擎

1. Scalable flow engine
2. Full IPv6 support
3. Tunnel decoding
   • Teredo
   • IP-IP
   • IP6-IP4
   • IP4-IP6
   • GRE
4. TCP stream engine
   • tracking sessions
   • stream reassembly
   • target based stream reassembly
5. IP Defrag engine
   • target based reassembly

协议解析器

1. 支持数据包解码
   1. IPv4, IPv6, TCP, UDP, SCTP, ICMPv4, ICMPv6, GRE
   2. 以太网，PPP, PPPoE, Raw, SLL, VLAN, QINQ, MPLS, ERSPAN
2. App层解码:
   1. HTTP、SSL、TLS、SMB、DCERPC、SMTP、FTP、SSH、DNS、Modbus、ENIP/CIP、DNP3、NFS、NTP、DHCP、TFTP、KRB5、IKEv2
   2. 使用Rust语言开发的新协议，用于安全快速的解码。

HTTP引擎

• Stateful HTTP parser built on libhtp
• HTTP request logger
• File identification, extraction and logging
• Per server settings — limits, personality, etc
• Keywords to match on (normalized) buffers:
  • uri and raw uri
  • headers and raw headers
  • cookie
  • user-agent
  • request body and response body
  • method, status and status code
  • host
  • request and response lines
  • decompress flash files
  • and many more

探测引擎

• Protocol keywords
• Multi-tenancy per vlan or capture device
• xbits – flowbits extension
• PCRE support
  • substring capture for logging in EVE
• fast_pattern and prefilter support
• Rule profiling
• File matching
  • file magic
  • file size
  • file name and extension
  • file MD5/SHA1/SHA256 checksum — scales up to millions of checksums
• multiple pattern matcher algorithms that can be selected
• extensive tuning options
• live rule reloads — use new rules w/o restarting Suricata
• delayed rules initialization
• Lua scripting for custom detection logic
• Hyperscan integration

输出

• Eve log, all JSON alert and event output
• Lua output scripts for generating your own output formats
• Redis support
• HTTP request logging
• TLS handshake logging
• Unified2 output — compatible with Barnyard2
• Alert fast log
• Alert debug log — for rule writers
• Traffic recording using pcap logger
• Prelude support
• drop log — netfilter style log of dropped packets in IPS mode
• syslog — alert to syslog
• stats — engine stats at fixed intervals
• File logging including MD5 checksum in JSON format
• Extracted file storing to disk, with deduplication in the v2 format
• DNS request/reply logger, including TXT data
• Signal based Log rotation
• Flow logging

报警/事件过滤

• per rule alert filtering and thresholding
• global alert filtering and thresholding
• per host/subnet thresholding and rate limiting settings

包获取

• High performance capture
  • AF_PACKET
    • experimental eBPF and XDP modes available
  • PF_RING
  • NETMAP
• Standard capture
  • PCAP
  • NFLOG (netfilter integration)
• IPS mode
  • Netfilter based on Linux (nfqueue)
    • fail open support
  • ipfw based on FreeBSD and NetBSD
  • AF_PACKET based on Linux
  • NETMAP
• Capture cards and specialized devices
  • Endace
  • Napatech
  • Tilera

多线程

完全可配置线程——从单线程到几十个线程

预煮的“runmodes”

可选CPU关联设置

使用细粒度锁定和原子操作获得最佳性能

可选锁分析

IP的声誉

• loading of large amounts host based reputation data
• matching on reputation data in the rule language using the “iprep” keyword
• live reload support
• supports CIDR ranges

工具

• Suricata-Update for easy rule update management
• Suricata-Verify for QA during development

原文:https://suricata-ids.org/features/all-features/

本文：

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

对于企业来说，通往云的旅程并不像云提供商的营销视频所描述的那么容易和简单。这篇文章详细介绍了我们旅程中某个阶段的一些背景故事。

我们首先设置由ACM管理的ELB负载平衡器w/ certificates来处理面临HTTPS流量的客户。这些流量最终代理到运行WAF的现有web服务器，然后再代理到应用服务器。

我们从列出所有的NAT网关IP地址开始，这些地址会从我们的VPC攻击我们现有的WAF，这样如果我们现有的WAF阻塞了流量，它就不会避开作为我们NAT网关的IP。在这一点上，我们仍然会403恶意请求，但我们没有办法防火墙关闭IP完全停止他们的流量。

我们在AWS WAF上测试了几家供应商提供的一些托管规则，但说实话，我们只是觉得我们不了解这个产品，不知道如何配置它来真正阻止某些东西，等等。要完全取代我们现有的WAF，学习它们的WAF需要花费更多的时间。

我们仍然有一个问题，就是想要在一段时间内阻止恶意流量，一旦攻击被检测到，就像我们可以用我们的内部基础设施一样。我们需要在流量进入VPC之前阻止它。是时候写一些胶水代码了…

因此，让我们深入研究一下我们如何通过ModSecurity和AWS WAF进一步实现这一点。ModSecurity是可用的最流行的WAF (web应用程序防火墙)之一。Apache的ModSecurity已经存在很长时间了，最新的libmodsecurity 3也是如此。x把这个功能带到Nginx。ModSecurity提供的规则集范围从免费到付费和专业维护:

• OWASP Core Rule Set
• Atomicorp Secure Linux
• Trustwave Rule Set

我们的组织长期以来一直是Atomicorp Secure Linux (ASL)的用户，因此我们非常熟悉他们的规则集、对它们进行调优，并与他们的支持进行交互。很好的合作组织。

所以让我们来看看我们今天是如何探索事物的核心。ASL管理web服务器的Apache和ModSecurity组件。当恶意请求发生时，将一个条目输出到/var/log/httpd/audit_log，然后在/var/asl/audit/data/…下面写入一个文件，处理流程如下所示。

1. 我们的web服务器监视程序跟踪audit_log，读取单个事件记录，执行一些正则表达式解析，然后通过HTTPS将事件数据发送到AWS API网关
2. API网关将数据推送到SQS“shun”队列中。
3. 我们将“SHUN”Lambda函数连接到SQS队列，以便立即调用它。它读取有效负载(提取ELB头，等等)，与RDS数据库交互，以确定应该为给定的规则和IP的历史做什么，然后如果需要，我们更新一个绑定到黑名单规则的AWS WAF IP集。将IP放在黑名单规则的IP集中，相当于ASL运行iptables命令来避开linux防火墙级别的IP。lambda函数还将modsecurity事件有效负载的副本存储在S3中，以便以统一的方式进行进一步检查。
4. 就像标准的ASL一样，您通常希望在一段时间后解除IP阻塞。因此，我们为“unshun”发送另一个SQS队列，但是这个队列被配置为有10分钟的交付延迟。
5. 我们的“UNSHUN”lambda由SQS队列调用，然后决定是否应该解封IP地址。如果是这样，则从AWS WAF IP集中删除它。这个lambda函数还执行一些审计工作，以确保AWS WAF IP集中反映了我们希望基于跟踪数据库阻塞的IP。有时候，如果您有一批IP，并且必须一个接一个地重试，那么从IP集中删除一个IP将会失败。经过一些尝试和错误，使审计例程健壮。

所以我们用

• 1 API Gateway
• 1 S3 bucket
• 2 SQS queues
• 2 Lambda functions
• 1 RDS cluster (3 tables)
• AWS WAF
• ASL ModSecurity WAF

是一个基于云的WAF，具有业界领先的规则，可以在几毫秒内响应恶意请求，并在所有的esb中使用AWS WAF避开流量。

 

我们希望ASL能够更新他们的产品，提供与AWS WAF的直接集成来提供这个功能。在我们的理想世界，ASL会:

• 不运行本地数据库，而是所有实例都能够使用RDS Aurora MySQL数据库进行跨多个web服务器的所有事件跟踪、规则配置、IP信誉等，而无需进行glass部署。
• 通过一个简单的配置选项(当然还有分配给允许它的实例的IAM角色)管理AWS WAF IP集，将其列入黑名单
• 向SNS公开事件流信息，以便将其路由到其他各种AWS服务进行集成和分析。

我们还进行了一些实验，以构建尽可能轻的web服务器，并实现类似的阻塞功能。我们测试了下列各项:

• 从源代码编译modsecurity，在CentOS上支持JSON。这并不像你想象的那么糟糕，一旦你找到了依赖关系。
• 配置modsecurity和mlogc，直接将HTTPS PUT执行到API网关(因为它是JSON，我们可以直接进入API网关，而无需修改任何代码)

这个场景可以很好地使用OWASP核心规则集或ASL规则集，但是我们必须编写一个规则集升级引擎来自动化它，因为在那个特定的场景中我们没有完整的ASL安装。

我们做的另一件非常有效的事情是阻塞流量，其中主机头是一个数字IP地址，URL以.php结尾。这些只不过是恶意扫描器通过IP在internet上逐个查找易受攻击的PHP安装。它们会向您的服务器发出数百个请求。因此，我们现在对fire请求发出一个block，防止它们滥用我们的基础设施。

我们发现另一个有用的场景是，我们的应用程序使用403响应代码阻塞请求(这将导致生成modsecurity事件)，并包含一个HTTP响应头和一个附加的原因代码。我们的shun lambda函数看到这些事件并执行块，就像触发了实际的modsecurity规则一样。这允许我们通过利用现有的管道将应用程序级安全代码绑定到AWS WAF。

在我们的跟踪数据库中，我们也完全禁止ip在他们绊倒一定数量的块之后。这些都是持续的不良行为ip，所以我们会在很长一段时间内禁止它们。

这个管道场景的操作成本是多少?最昂贵的部分将是RDS Aurora数据库集群，但大多数AWS客户至少有一个可以利用的数据库集群。其余的API网关、SQS和Lambda处理可能是< $1/mo。编写的代码量可能少于1000行。通过WAF传输的成本将根据您正在处理的请求的数量而变化。底线是这是一个廉价的解决方案。

你能把这个解扩展到多高?AWS WAF ACL可以有10条规则，如果这些规则都是黑名单规则，那么您可以同时阻塞多达100,000 (10 x 10,000)个ip。

我们和ASL的人分享了这个想法，他们都很兴奋。我非常希望在不久的将来，我们会在ASL或OSSEC中看到对此的原生支持。

原文：https://medium.com/@jonathantew/integrating-modsecurity-with-aws-waf-f26b5af4c1a8

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

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

什么是机密计算？

机密计算是一种使用安全飞地技术的方法，可以基于CPU供应商提供的安全特性创建可信执行环境（TEE）。TEE允许在CPU内进行加密/解密、内存和数据隔离，以及其他因CPU供应商而异的安全功能。安全飞地技术是机密计算的基础。

云端及其以外的硬件级隐私

数据泄露的风险是巨大且持久的。它威胁到云本身的信任、完整性和生存能力。计算机科学已经解决并克服了对存储中的静态数据和网络传输中的数据进行加密的问题。但棘手的问题仍然存在：如何保护内存中实际使用的数据和代码——这个目标似乎受到传统计算架构本身的限制。使用软件加密隐藏数据的尝试失败。计算硬件要求加密密钥在使用前解密并在内存中公开，从而使其容易受到黑客或内部人员的攻击。

作为回应，机密计算通过安全飞地（通常与TEE互换使用）创新了前所未有的硬件级体系结构安全方法。Confidential Computing特别关注使用中的数据的安全，通过保护内存来消除数据在处理过程中未加密时的致命缺陷。

消除风险：默认建立数据安全和隐私

只要使用中的数据暴露在外，敏感的个人身份信息（PII），财务或健康信息在云中仍然存在风险。安全实体一直在努力消除网络威胁，但这场恶作剧的游戏往往输给了高价值信息的泄露和过滤。需要的是，未经修改的工作负载应用程序和数据系统内存能够在任何环境中的任何地方运行，完全与内部和外部攻击隔离。

现在，机密计算解决了在安全空间内隔离数据和执行的问题。使用CPU的一部分作为保护区或飞地，可以创建一个可信执行环境（TEE）。安全的飞地是一个内存和CPU专用环境，它与给定主机上的所有其他用户和进程隔离，并且对它们不可见。在一个安全的飞地内，代码只能引用自身。

保护领地安全：一项重大进展，但部署起来很复杂

实施安全封包既复杂又昂贵，需要重新设计每个应用程序。飞地要求工程师和专家亲自参与，这将运营费用提高到不切实际的高度。每个芯片和云提供商都创建了自己的飞地解决方案：Intel SGX、Azure、AMD SEV、AWS Nitro Enclaves和Google VM。但是，这些努力无论多么值得，都为已经维护本地、混合和多云环境的客户创造了一个令人眼花缭乱的选择领域。他们必须学习各自的安全飞地技术，这会增加工程人员、时间、应用程序性能和成本方面的开销。

化解未经授权的内部人士和外部威胁

在不降低IT生产力的情况下加强安全性是一个令人困惑的安全挑战，云只会加剧这一挑战，暴露出对IT云平台提供商的员工和第三方承包商的控制有限的问题。内部人员获得主机访问权限来执行其工作，这会使他们过度暴露于主机数据。为了一个组织的安全，需要一个报复心强、注意力不集中或机会主义的员工。

但机密计算关闭了“可信的内部人员”数据暴露和外部威胁。它确保了独占的数据控制和硬件级别的数据风险最小化；数据保护是数据本身的组成部分，无需依赖薄弱的外围安全层。数据所有者控制数据在it计算、存储和通信的基础架构中存储、传输或使用的任何位置。

Anjuna软件：默认保护数据

Anjuna机密计算软件不需要重新设计应用程序或内核。客户无需担心芯片或云基础设施级别的底层TEE。应用程序和整个环境在公共云基础设施上创建的私有环境中无需修改即可工作。在几分钟内，Anjuna自动创建了一个隔离且坚固的硬件加密环境，应用程序在其中运行并扩展机密计算硬件技术，以保护使用中、传输中和静止的数据。

Anjuna的独特之处是什么？

多平台和多云支持。

企业无需锁定在一个硬件平台或云上。Anjuna支持Intel、AMD和AWS Nitro Enclaves平台以及本地Kubernetes Key管理解决方案，适用于任何环境：内部部署、混合或多云。无需修改即可跨任何飞地平台执行工作负载。

无性能影响。

使用Anjuna，所有TEE技术都预先调整了环境。因为应用程序不需要重新编码，所以在软件的隔离环境中运行的延迟最小。

在几分钟内大规模加强安全性。

在每个应用程序周围快速创建一个隔离的安全环境，以显著减少攻击面并保护应用程序，即使基础架构遭到破坏。

全方位包覆

通过硬件和软件的全栈加密，将保护范围从内存扩展到存储和网络。运行应用程序时，数据被隔离，任何其他实体都无法访问；内存与机器上的任何其他东西都是隔离的，包括操作系统。

透明数据共享。

Anjuna软件使企业能够通过认证安全飞地运行的硬件为正版，在分布式应用程序上使用硬件信任根。这证实了飞地内存对远程方的完整性。

探索这些机密计算用例

安全云迁移

将应用程序迁移到云，其安全姿态超过本地保护。Anjuna扩展了机密计算技术提供的强化安全功能，并使任何公共云成为敏感企业应用程序和数据最安全的地方。云经济和强大的安全性之间不再妥协。

数据库保护

即使是安全的数据库也会在内存中存储未加密和公开的数据。Anjuna确保数据库及其数据在隔离的私有环境的安全范围内运行。通过加密和物理方式将数据与恶意进程和不良参与者隔离，实际上消除了数据泄露或渗出的可能性。

数据保护

Anjuna提供了最强大、最完整的数据安全和隐私控制。创建、处理、存储和联网的敏感数据受到基于硬件的零信任保护的保护，在整个生命周期中保护PII免受内部人员和不良行为者的侵害。数据默认受保护，包括密钥、PII、PHI、PCI、IP、专有算法、商业机密等。

加密MPC和区块链保护

见Anjuna首席技术官兼联合创始人Yan Michalevsky，讨论区块链应用的安全飞地、加密密钥和基础设施的安全存储，以及区块链和加密货币的挑战。Anjuna为加密公司保护MPC应用程序、数字资产、数字钱包、托管交易所、NFT和AI/ML算法。

密钥管理系统（KMS）

有了机密计算，您现在可以现代化和扩展KMS功能，并禁止访问在隔离环境中运行的KMS应用程序。Anjuna与HashiCorp和Venafi合作，保护密钥和机密，甚至防止具有root访问权限的攻击者获取身份验证凭据。

强化的DevSecOps

DevSecOps管道的手动安全和审计流程可能是软件供应链受损的主要风险向量。这些缓慢的劳动密集型流程可能使迅速识别管道攻击变得困难。使用Anjuna在安全的飞地内运行应用程序可以提供基于硬件的软件组件完整性证明，从而更广泛地保护软件供应链。

本文：https://jiagoushi.pro/what-confidential-computing-and-why-it-important-…

零失业率是一个有吸引力的数据。它肯定是指导顾问为学生选择网络安全作为职业的原因。毫无疑问，这是一个很好的特权，但它与一些追求网络安全职业的更有说服力的理由相比。

您不需要成为网络安全专家就能理解这是一个增长领域。网络安全已成为任何现代企业结构的关键。由于违规行为突破了头条新闻，所以每个人都清楚组织需要更多专注于网络安全的专业人士。

IT中的每个角色都有网络安全方面。专注于安全性作为您的主要角色开辟了一个选择的世界。从安全操作到风险评估，应用程序安全，调查到遵从教育工作者，网络安全中的角色与浏览器中运行的代码行一样多。

不要让那些负面的头条新闻让你失望。对于每一个Equifax，在线都有成千上万的成功交易。我们作为一个职业正在取得进步。

以下是您应该考虑从事网络安全职业生涯的四大理由 - 这也是您不应该这样做的原因之一。

 

1.实际上无限增长

随着范围不断扩大，网络安全呈现出最终的增长潜力 - 无论是在您的职业道路上还是在学习机会方面。

我们将安全作为自己的学科教授，但它与所有其他IT技能组合相关联。一个优秀的网络安全专业人员尽可能地了解技术和组织的工作方式。

一位伟大的网络安全专家意识到学习永远不会停止。

这是一个保持参与和挑战的巨大机会。

当安全团队开始时，他们是从“万事通”类型构建的。该学科尚未发展到足以支持法医学或应用程序安全或事件响应方面的专业。

当前的工作量迫使安全团队迅速扩大规模。愿意挑战自我的专业人士有机会接受它。

无论您是希望以首席信息安全官（CISO）角色工作还是使用全新技术，唯一能够限制您成长的是您的愿望。

这是一个令人兴奋的命题和理由足以选择一个网络安全职业。

2.种类繁多

所有增长机会都与安全专业人员必须处理的各种技术和情况有关。如果它使用1和0，它有一个网络安全组件（有些角色甚至扩展到物理安全！）。

安全专业人员有机会直接与团队合作，研究他们从未梦想过的技术和系统。从机器人到汽车，再到为数百万用户提供服务的网站，品种几乎无限。

这是一个令人兴奋的职业前景。无聊不是经常使用的词。

这个品种有一个有趣的分支：由于正确理解现代安全挑战所需的广泛技能，网络安全专业人士来自不同的背景。事实上，你的背景越多，安全专业人士就越好！

没有“正确”的方式来培养成为网络安全专业人士。

3.解决难题的能力

将技术及其变化的增长加在一起，您就会开始瞥见网络安全专业人员可以处理的各种类型的谜题。

在网络安全方面，我们依赖于一些经过验证的原则，但这些策略可以在日常工作中发生变化。而且总会有一个需要解决的新难题。

随着每一次新技术浪潮的出现，都会产生新的风险。安全专业人员的工作是识别，理解并帮助解决这些风险。当您考虑如何保护在云中运行的网站而不是保护老年患者的心脏起搏器时，这种情况会发生显着变化。

每种情况都是一个独特的难题，也是迎接挑战的新机遇。

4. 这项工作有实际影响

最后一个用例 - 为老年患者辩护心脏起搏器 - 是一个真实的用例。由于安全问题，最近大规模召回了心脏起搏器。 Equifax黑客攻击了1.45亿美国人。

网络安全很重要。它的影响超越了数字世界，进入了物理世界。

这是一个可怕而令人兴奋的前景，也是一个突出其重要性的前景。

如果您想处理具有实际影响的IT问题，网络安全可能是您的纪律。

为什么不选择这条道路：感知

不犯错误。网络安全的多样性，增长机会，难题和影响加起来令人兴奋。但如果你期望职业生涯更符合好莱坞安全专业人士的介绍......再想一想。

网络安全中的绝大多数角色都不要求你在世界各地躲避子弹或在几毫秒内获得扫描结果，或者能够通过红色立即识别恶意代码（<sarcasm>感谢你，CSI：Cyber​​ </讽刺>）。

当然，这并不意味着这些角色没有回报。他们是。他们可能不是很迷人。

开始学习，不断学习

网络安全对于强大的职业生涯具有两个关键的后勤优势：低失业率和无失业补偿。

另外，如果您选择此路径，您将始终有成长空间。您将不断学习新技能并努力学习新技术。新挑战将不断涌现，您将接触到大量新人，情境和机会。

你永远不会觉得无聊，因为新的谜题需要解决，你总是可以自豪，因为你的工作将对数字和物理世界产生积极的影响。

你还能在职业生涯中要求什么呢？

 

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

你的敏感资料是否安全?

这并不夸张:任何公司都可能成为网络犯罪的受害者。有关网络攻击的报告来自政府机构、教育和医疗机构、银行、律师事务所、非营利组织和许多其他组织。

黑客、内部威胁、勒索软件和其他危险都存在。

聪明的企业正在加大对网络安全的投资，以消除风险，确保敏感数据的安全，这已经带来了首批成果。请看下面的信息图表，了解网络安全的最新趋势。

接下来的问题是:作为一名企业主，在2019年我能做些什么来保护我的数据?

上图显示，在政府机构和企业都开始加大对网络安全的投资的同时，数据泄露的数量显著下降。

不知道从哪里开始加强你的网络安全政策?我们准备告诉你网络安全的趋势和最新的技术。

以下是我们2019年的IT安全最佳实践清单:

1. 考虑生物安全

生物识别技术确保了快速认证、安全访问管理和精确的员工监控。

在提供对有价值资产的访问之前，验证用户的身份对企业来说至关重要。语音识别、指纹扫描、手掌生物识别、面部识别、行为生物识别和步态分析是识别用户是否是他们自称的人的完美选择。

使用生物识别技术提供了比密码和短信验证更安全的身份验证。这就是为什么生物识别技术已经成为多因素认证的重要组成部分。

然而，身份验证并不是生物识别的唯一用途。安全人员受益于各种生物识别驱动的工具，这些工具允许他们实时检测受损的特权帐户。

行为生物学分析用户与输入设备交互的方式。如果检测到异常行为，工具会向安全人员发送警告，以便他们能够立即做出反应。

以下是用户和实体行为分析(UEBA)系统可以使用的几种行为生物识别技术:

• 击键动态——考虑打字速度和在某些单词中出现典型错误的倾向，以创建用户行为概要文件
• 鼠标动态—跟踪鼠标点击和鼠标移动速度、节奏和样式之间的时间间隔
• 眼动生物测定-使用眼睛和注视跟踪设备来记录眼睛运动的视频和检测独特的模式

market sandmarkets对2018年的预测显示，到2023年，生物识别市场将从2018年的168亿美元增长到418亿美元。因此，请密切关注生物特征安全技术，并为您的用例选择最佳技术。

2. 形成分级的网络安全政策

为什么书面的网络安全政策如此重要?

首先，书面政策作为贵公司所有网络安全措施的正式指南。

它允许您的安全专家和员工处于同一页面，并为您提供了一种强制执行保护数据的规则的方法。然而，每个部门的工作流程可能是独特的，而且很容易被不必要的网络安全措施打乱。

虽然集中式安全策略作为整个公司的基本方针是有益的，但它不应该覆盖每个部门的每个流程。相反，允许您的部门基于中央策略创建自己的安全策略。

以这种分层的方式确定安全策略有很多好处。通过这样做，您可以考虑每个部门的需求，并确保他们的工作流和您的底线不会在安全的名义下受到损害。

伊利诺伊州政府网站提供了一个很好的网络安全政策模板，可以作为你分级管理的起点。

如果您想学习如何预防、检测和纠正内部攻击，您应该考虑构建一个内部威胁程序。

3.采用基于风险的安全方法

法规遵从性不能保护您的数据。

每个行业都有其特定的和隐藏的风险，因此关注法规遵从性和满足所有标准法规不足以保护您的敏感数据。

注意你的公司所面临的风险，以及它们如何影响你的底线。这里最好的工具是全面的风险评估。

以下是风险评估允许你做的一些最重要的事情:

识别所有有价值的资产，公司当前的网络安全状况，明智地管理你的安全策略

适当的风险评估可以让你避免许多不愉快的事情，比如因不遵守规定而被罚款，为潜在的泄漏和违规行为而付出的补救成本，以及由于流程缺失或效率低下而造成的损失。

找出网络安全的薄弱环节，并做出相应的调整。此外，请密切关注使用数据库和框架的新黑客技术，例如MITRE ATT&CK for enterprise。

全面的风险评估将帮助您优先考虑您的安全措施，并使您的策略以最佳方式服务于公司的底线。

您可以在Compliance Forge网站上找到一个风险评估工作表和评估报告的实际示例。如果你需要更多关于如何在你的公司进行风险评估的信息，请查看它。

4. 备份数据

定期备份数据，确保数据的安全性。

备份数据是近年来越来越重要的信息安全最佳实践之一。随着勒索软件的出现，对所有数据进行完整的、当前的备份可能是一种救星。

如何处理备份?您需要确保它们被彻底保护、加密并经常更新。同样重要的是，将备份任务分配给几个人，以减轻内部威胁。

美国计算机应急准备小组(US-CERT)提供了一份文件，详细说明了不同的数据备份选项。如果你想了解更多关于这个话题的信息，你应该读一读联邦调查局关于勒索软件的一篇优秀文章。

5. 物联网安全管理

今年延续了2018年以来的趋势——物联网设备越来越受欢迎。

贝恩公司预测，物联网市场将在2021年增长到约5200亿美元。然而，无论我们多么渴望看到新技术，安全总是第一位的。

物联网设备最具挑战性的地方是它们对敏感信息的访问。

安全摄像头、门铃、智能门锁、供暖系统、办公设备——所有这些你的商业网络的小部件都是潜在的接入点。

例如，一台受损的打印机可以允许恶意行为者查看正在打印或扫描的所有文档。

以下是一些企业网络安全的最佳实践:

• 进行渗透测试，了解真正的风险，并据此制定安全策略。
• 为静态和传输中的数据提供加密(端到端加密)。
• 确保正确的身份验证只允许到端点的可信连接。
• 不要使用默认的硬编码凭证:通常使用的密码在互联网上很容易找到。
• 购买安全和最新的路由器，并启用防火墙。
• 开发一个可伸缩的安全框架来支持所有物联网部署。
• 考虑实现端点安全解决方案。

6. 使用多因素身份验证

多因素身份验证(MFA)是高级安全策略的必备解决方案。

虽然这是一个基本的实现，但MFA仍然属于网络安全最佳实践。它是如此有效，以至于国家网络安全联盟甚至将MFA加入到其安全意识和教育运动中。

MFA通过添加额外的安全层帮助您保护敏感数据，使恶意行为者几乎没有机会像您一样登录。

即使恶意行为者拥有您的密码，他们仍然需要您的第二个或第三个身份验证“因素”，例如安全令牌、您的移动电话、您的指纹或您的语音。

作为一个额外的好处，MFA还允许您明确区分共享帐户的用户，从而改进访问控制。

还请阅读:双因素身份验证:类别、方法和任务

7. 处理密码安全

提到密码和安全密码处理的重要性总是值得的。

密码管理是企业安全的一个关键部分，尤其是涉及特权访问管理(PAM)时。特权帐户是网络罪犯的宝石谁试图获得访问您的敏感数据和最有价值的商业信息。

确保适当安全性的最佳方法是使用专用工具，如密码保险库和PAM解决方案。这样，您可以防止未经授权的用户访问特权帐户，同时简化员工的密码管理。

网络威胁行为者仍然使用密码喷雾攻击来窃取敏感信息，扰乱运营，损害组织的财务和声誉。

当你为你的员工设定密码要求时，以下是你应该考虑的主要技巧:

• 为一个帐户使用一个密码。
• 使用容易记住的短语，而不是由随机字符组成的短字符串。
• 使用助记符或其他个人策略来记住长密码。
• 无论多么方便，都不能互相共享凭据。
• 要求员工在一段时间后更改密码。

美国国家网络安全和通信集成中心(National Cybersecurity and Communications Integration Center)提出了一套选择和保护强密码的建议。如果你想了解更多细节，可以查看它们。

8. 使用最少特权原则

注意:有太多特权用户访问您的数据是非常危险的。

默认情况下，授予新员工所有特权允许他们访问敏感数据，即使他们不一定需要这样做。这种方法增加了内部威胁的风险，并允许黑客在您的任何员工账户受到攻击时访问敏感数据。

一个更好的解决方案是使用最小特权原则。

换句话说，为每个新帐户分配尽可能少的特权，并在必要时升级特权。当不再需要访问敏感数据时，应立即撤销所有相应的特权。

持续的特权管理可能是困难和耗时的，特别是对于大公司，但是市场上有很多访问管理解决方案可以使其变得更容易。

特别是，当您需要处理不受控制的特权时，专门化的PAM解决方案可以证明是一种救命稻草。

最小特权原则似乎类似于零信任安全模型，该模型还通过显著减少无保证的信任来降低内部威胁的风险。

零信任实践表示，只向那些已经在系统中进行了身份验证和验证的用户和设备授予访问权限。

9. 关注特权用户

拥有特权帐户的用户是公司最大的资产之一，还是对数据安全的最大威胁之一?

有特权的用户拥有所有必要的手段来窃取您的敏感数据，并且不被注意。无论你多么信任拥有特权账户的员工，任何事情都有可能发生。

你怎样才能把风险降到最低?以下是一些简单而有效的步骤:

• 通过实现最小特权原则来限制特权用户的数量。
• 确保在用户终止使用特权帐户时，立即删除特权帐户。
• 使用用户活动监视解决方案来记录在网络中采取的任何操作。

您可以查看Ponemon研究所的这份出色的报告，了解更多关于特权用户在内部威胁场景中的角色。

10. 监控对数据的第三方访问

控制第三方访问是您的安全策略的一个重要部分。

远程员工、分包商、业务合作伙伴、供应商和供应商——这只是可能远程访问您数据的人员和公司的一小部分。

第三方访问不仅会带来更高的内部攻击风险，还会为恶意软件和黑客进入您的系统打开大门。

通过第三方访问来保护您的敏感数据不受攻击的一个好方法是监视第三方操作。您可以限制第三方用户的访问范围，并知道谁确切地连接到您的网络以及为什么。

用户活动监视还应该与一次性密码结合使用，以便提供所有用户操作的完整日志记录，以便您可以检测恶意活动并在必要时进行调查。

11. 小心网络钓鱼

你们所有的员工都知道网络钓鱼吗?

值得注意的是，内部威胁不会以恶意员工告终。更常见的情况是，善意的员工无意中帮助了犯罪者，为他们提供了进入你的系统的方法。

网络攻击者使用垃圾邮件和电话等网络钓鱼技术来获取员工信息、获取他们的证书，或者用恶意软件感染系统。

你的基本防御可以很简单，只包括两个步骤:

获得一个正确配置的垃圾邮件过滤器，并确保最明显的垃圾邮件总是被阻塞。

教育你的员工流行的网络钓鱼技术和最好的处理方法。

幸运的是，教育和意识确实起了作用，人们现在对网络威胁的意识要高得多。Verizon 2018年的数据泄露调查报告强调，73%的人在2017年没有点击任何恶意邮件。他们2019年的报告显示，2018年网络钓鱼攻击的点击率只有3%。

您可以在US-CERT网站上找到更多关于网络钓鱼的信息，包括报告形式。

12. 提高员工的意识

这可能很难相信，但你的员工是保护你数据的关键。

处理员工疏忽和安全错误的一个可靠方法是教育他们为什么安全很重要:

• 提高对公司面临的网络威胁及其如何影响底线的认识。
• 向你的员工解释每项电脑安全措施的重要性。
• 展示现实生活中安全漏洞的例子，它们的后果，以及恢复过程的困难。
• 询问员工对当前公司安全体系的反馈。
• 询问员工关于如何将健壮的安全性与高效的工作流结合起来的新想法。

雇佣你的员工作为你辩护的一部分，你会发现疏忽和错误的情况将会减少。让你的员工接受适当的培训比处理意外行为造成的数据泄露要好得多。

上述网络安全最佳实践将帮助您保护您的数据和您的企业的声誉。然而，实现它们是另一个挑战。

 

原文：https://www.ekransystem.com/en/blog/best-cyber-security-practices

本文：https://pub.intelligentx.net/12-best-cybersecurity-practices-2019

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

 

保护云中的数据和应用程序从未如此重要。

头条新闻不断提醒人们，在违规行为之后，对业务的破坏性（或灾难性）影响。 2017年最引人注目的漏洞事件中的许多都提醒您组织内部和外部可能存在的漏洞。

虽然没有单一的解决方案可以防止每次攻击，但是在整个组织中主动建立云安全意识是阻止通常在违规之前发生的恶意活动的第一道防线。

以下是应该在2018年推动您的安全策略的4种做法：

1. 了解您的安全责任
2. 确保您团队的云安全技能能够应对挑战
3. 在每个部署级别实施安全性
4. 建立安全第一的文化

1.了解您的安全责任

在云中，整个安全框架在提供者和客户之间的共享责任模型下运行。为了使这个模型有效，清楚地了解每一方的角色和责任是一个重要的起点。

从基础架构的角度来看，云服务提供商负责确保其数据中心具有足够的物理安全级别。服务提供商管理整个全球基础架构的安全性，从物理存在到提供计算，存储，数据库和网络服务的底层基础资源。这些功能共同提供了一个安全的云环境。

导入数据并利用提供商服务的客户有责任使用这些服务和功能来设计和实施他们自己的安全机制。这可能包括访问控制，防火墙（实例和网络级别），加密，日志记录和监控等。
AWS，Azure和Google Cloud都采用了共享责任模型。检查与每个提供商的服务水平协议，以充分了解双方的义务。

2.确保您团队的云安全技能能够应对挑战

根据迈克菲的说法，36％的组织正在采用云，即使承认没有正确的安全技能。

36％的组织正在采用云，即使在没有采用正确的安全技能的情况下也是如此。
2017年，由于人为错误以及Amazon Simple Storage Service（S3）等服务中配置不当的安全设置，数以百万计的客户记录和其他敏感数据暴露出来。 RedLock的研究人员发现，40％使用云存储的组织意外地向公众公开了这些服务中的一项或多项。黑客和其他不良行为者充分意识到人类的错误，他们完全有能力在企业走捷径时利用安全漏洞。

在这些情况下，这不是技术的失败，而是缺乏对安全重要性的理解以及缺乏使您的企业面临风险的技能。

正如业务压力首先影响急于迁移一样，领先的公共云供应商发布的新服务和更新的速度和数量使得团队难以跟上。云提供商已快速开发和发布创新技术，以确保云数据和应用程序的安全。例如，11月发布的AWS GuardDuty本质上是一种智能威胁检测服务，也是第一种使用人工智能和机器学习来检测可疑活动的服务。

对于公司来说，投入所需的时间和资源来培训内部云团队以正确有效地设计安全，可靠，可审计和可追溯的云解决方案同样满足您的业务需求至关重要。

3.在每个部署级别实施安全性

您的基础架构仅与其最薄弱的环节一样安全。威胁不仅限于外部来源。您的团队必须准备好正确地构建针对非恶意内部漏洞或用户特权漏洞以及最复杂攻击的漏洞以及介于两者之间的所有漏洞。
通过在部署的每个层实施安全措施，您可以最大限度地减少基础架构的攻击面积。

Amazon Web Services，Microsoft Azure和Google Cloud Platform提供了一系列服务和工具，您的团队可以使用这些服务和工具来设计，实施和构建适当级别的安全性，以保护云中的数据和应用程序。您的团队应充分了解您的云服务提供商提供的托管安全服务，以及在开发和部署生命周期各自部分内构建相关安全措施的知识和技能。

4.建立安全第一的文化

云采用会影响整个业务，从基础架构级别的技术变更到涉及所有级别和员工团队的文化变更。因此，安全性必须成为您业务战略的一部分，并且必须从组织的最高层加强。

如果不了解安全性在每个部署层面的影响，就可以忽略最佳实践，可能会出现错误，可能会出现快捷方式，并且会将漏洞安静地设计到解决方案中。建立以安全为先的文化将确保安全性处于所有相应方法，实践，流程和程序的最前沿。

通过发布“安全优先”指令并在业务的所有领域采取行动进行备份，您的组织将更自信地在云中运营。

 

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

数据保护者和数据窃贼之间的战争被描述为猫捉老鼠游戏。一旦白帽反击一种形式的黑帽恶意行为，另一种恶意形式就会抬起它的丑陋头脑。如何在有利于信息安全战士的情况下倾斜比赛场地？以下是五种新兴的安全技术，可以做到这一点。

 

1.硬件认证

用户名和密码的不足之处是众所周知的。显然，需要一种更安全的身份验证形式。一种方法是将身份验证烘焙到用户的硬件中。英特尔正在朝着这个方向发展，在其新的第六代Core vPro处理器中使用Authenticate解决方案。它可以同时结合各种硬件增强因子来验证用户的身份。

英特尔在之前的努力基础上，将一部分芯片组用于安全功能，使设备成为身份验证过程的一部分。良好的身份验证需要用户提供三件事：他们知道什么，例如密码;他们是谁，例如用户名;他们有什么，比如令牌。在Authenticate的情况下，该设备成为你拥有的。

“这不是新事物，”451 Research信息安全研究主任斯科特克劳福德说。 “我们已经在其他表现形式中看到了这一点，例如许可技术和令牌。”

硬件身份验证对于物联网（IoT）尤为重要，因为网络希望确保尝试访问它的东西能够访问它。

但是，克劳福德指出，“该技术最直接的应用是在传统IT环境中对端点进行身份验证 - 使用英特尔芯片组的笔记本电脑，台式机和移动设备。”

 

2.用户行为分析

一旦某人的用户名和密码遭到入侵，拥有这些用户名和密码的人就可以跳入网络并参与各种恶意行为。如果他们采用用户行为分析（UBA），那么这种行为可能会触发系统防御者的红旗。该技术使用大数据分析来识别用户的异常行为。

“这对企业有很大的兴趣，”451的克劳福德说。

“用户活动是安全专业人士的头号问题。”

他解释说，该技术解决了企业安全问题的盲点。 “一旦攻击者进入企业，那么会发生什么？”他问。 “他们做的第一件事就是妥协凭证。那么问题就变成了，你能区分合法用户的活动和已经获得进入的攻击者，破坏了合法用户的凭据，现在正在寻找其他目标吗？”

对不符合合法用户标准的活动的可见性可以在攻击链的中间关闭一个盲点。 “如果你认为攻击链是初始渗透，横向移动，然后是敏感数据的妥协，盗窃和泄漏，那么攻击链中的中间环节对于企业安全专业人员来说并不是很明显，这就是为什么对今天的用户行为分析，“克劳福德说。

将用户的当前行为与过去的行为进行比较并不是UBA识别恶意行为者的唯一方式。 “有一种叫做'同行分析'的东西，”威胁分析公司Bay Dynamics的项目管理副总裁Steven Grossman解释道。 “它比较了某人的行为与同一经理或同一部门的人的比较。这可能表明该人正在做他们不应该做的事或其他人接管他们的账户。”

此外，UBA可以成为培训员工更好的安全实践的宝贵工具。 “公司最大的问题之一是员工不遵守公司政策，”格罗斯曼说。 “能够识别这些人并通过正确训练来降低风险是至关重要的。”

“用户可以被识别并自动注册参加适合他们违反的政策的培训。”

3.数据丢失预防

防止数据丢失的关键是加密和标记化等技术。他们可以将数据保护到字段和子字段级别，这可以通过多种方式使企业受益：

如果成功违规，网络攻击者无法通过数据获利。

可以在扩展的企业中安全地移动和使用数据 - 可以对受保护形式的数据执行业务流程和分析，从而显着降低风险和风险。

企业可以极大地帮助遵守数据隐私和安全法规，以保护支付卡信息（PCI），个人身份信息（PII）和受保护的健康信息（PHI）。

“在过去的几年里，有很多安全支出，但2015年遭遇的记录数量比去年大幅增加，”451的克劳福德说。 “这促使人们对加密感兴趣。”

然而，正如SANS研究所新兴安全趋势主管John Pescatore指出的那样，身份验证在预防数据丢失方面发挥着重要作用。

“没有密钥管理就无法实现强大的加密，没有强大的身份验证就无法进行密钥管理。”

4.深度学习

深度学习包括许多技术，例如人工智能和机器学习。 “无论它被称为什么，出于安全目的，人们都非常感兴趣，”451的克劳福德说。

与用户行为分析一样，深度学习侧重于异常行为。 “你想要了解恶意行为在安全方面偏离合法或可接受行为的地方，”克劳福德解释说。

“当你在企业网络上查看活动时，其行为不是用户行为，而是仍然是恶意的。因此，即使它正在关注行为，它也会关注行为分析的略有不同的应用。”

Booz Allen的高级副总裁Brad Medairy解释说，该系统不是关注用户，而是关注“实体”。 “精确的业务分析和机器学习模型的最新发展意味着我们现在能够查看企业中从微观层面到宏观层面的各种实体。例如，数据中心作为一个实体，可以表现为某种方式，类似于用户。“

高级恶意软件检测平台制造商Acuity Solutions的总裁Kris Lovejoy补充说，使用机器学习可以帮助消除高级持续性威胁的祸害。 “凭借其能够以线速度解读好坏软件之间的能力，机器学习技术将为寻求缩短高级威胁检测和根除时间的安全从业者提供重要的福利，”她说。

克劳福德表示，他希望继续为安全目的进行深度学习投资。然而，他补充说，“企业面临的挑战是，很多公司都会采用类似的方法来解决同样的问题。区分不同厂商之间的区别对于未来一年的企业来说将是一项重大挑战。超越“。

5.云

“云计算将对安全技术行业产生一种变革性影响，”克劳福德说。

他解释说，随着越来越多的组织将云用于传统上属于内部部署IT的领域，将出现更多出现在云中的安全方法。内部部署技术将转换为云。诸如虚拟化安全硬件，虚拟化防火墙以及虚拟化入侵检测和防御系统之类的东西。但这将是一个中间阶段。

“如果你考虑基础设施即服务提供商可以为所有客户做大规模的事情，可能就没有必要在现场提供你需要的所有防御措施，”克劳福德说。 “基础架构即服务提供商将把它构建到他们的平台中，这将减轻为单个云客户做到这一点的需求。”

SANS'Pescatore补充说，政府机构和私营企业通过使用亚马逊和Firehost等IaaS服务提高了数据中心的安全性。 “GSA FedRAMP计划是”经过认证的足够安全“云服务的一个很好的例子，它使普通企业更容易拥有高于平均水平的数据中心安全性，”他说。

这五个应该帮助infosec战士获得上流。我们错过了什么？您建议使用哪些技术来推动信息安全？通过以下评论称重。

原文：https://techbeacon.com/security/5-emerging-security-technologies-set-level-battlefield

本文：

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

尼尔·西蒙的戏剧和电影“奇怪的夫妇”取决于两个角色，奥斯卡和菲利克斯，他们有着完全不同的优先事项，却发现自己生活在一起 - 并且互相制造挫败感。

经过短暂的一段时间，奥斯卡将费利克斯赶出了他的公寓，但在最后一幕中，他发现（剧透警告）他意识到菲利克斯对他产生了积极的影响。菲利克斯的生活变化将两者结合在一起。

同样，IT安全和运营的变化正在促使更多的合作。虽然这些团队通常在一定距离内操作，但彼此之间的强制容忍，必须改变。来自欧盟通用数据保护法规（GDPR）和加州消费者隐私法案（CCPA）等隐私法的监管压力越来越大，以及由于补丁管理缓慢导致的高可见性黑客攻击，正在推动这些团队更加紧密地协调他们以互惠互利的方式努力。

我们还看到了DevOps的结果，模糊了开发人员和运营团队之间的界限，以更快速，更成功地部署代码。 DevOps所经历的成功是SecOps关系复兴的路线图。

菲利克斯和奥斯卡之间的争吵有时导致菜肴破碎。在现实生活中的IT中，监管罚款和安全漏洞等待那些不能一起工作的团队。寻找以下机会，以加强2019年安全和运营团队之间的合作。

 

1.建立补丁管理合作伙伴关系

谁在您的组织中拥有补丁管理？通常，运营是负责任的，负责任的，安全和审计提供政策和验证。该系统可以工作，但它有时会产生“我们与他们”的心态。

很容易指出操作，并说他们的补丁管理系统被破坏或缺乏足够的优先级。有时就是这种情况;必须为操作提供明确的时间表，以便部署能够关闭关键漏洞的补丁，并且需要资源来实现这一点。

但有时候，对于操作来说，更改量可能会非常大，有时必须锁定系统，或者在不破坏旧应用程序的情况下无法修补应用程序。

如果安全性将补丁管理视为一种伙伴关系，那么这些挑战可以一起解决。安全性可以通过定期重新确定漏洞的优先级来帮助运营，并且在冻结变更的情况下，可以提供缓解策略，例如网络分段或其他安全监控。

2.共享身份和访问数据

虽然补丁管理几乎总是操作的责任，但身份和访问管理（IAM）通常是一个联合监管程序。通常，管理和治理职责之间存在界限，但它们使用通用的IAM平台。

根据2018年的Verizon数据违规调查报告，凭借安全漏洞的最高威胁，凭据受到损害，安全和运营对于管理和管理身份和访问的集成方法至关重要。

实际上，这意味着使用身份和访问数据作为安全信息和事件管理（SIEM）的洞察源。这不仅仅是为了法医目的，在违规后搜索证据，而且还可以实时用作通过警告异常访问模式或滥用特权来识别正在进行的违规行为的方法。

响应特权滥用还应该导致权利的快速撤销，直到可以调查事件，因为一旦攻击者拥有内部人员的证书，损害可以在几分钟内完成。这需要集成回IAM平台以自动响应。

3.管理数据 - 而不仅仅是数据库

数据库管理是操作提供的关键技能，但通常侧重于维护数据库的性能。由于隐私权要求和攻击者专注于数据，安全团队可以使用应用程序和数据库管理员的一些支持来保护数据。

加密虽然不是隐私法规要求，但在攻击者访问包含PII的数据库时，可为个人身份信息（PII）提供重要保护。一些管理员不愿意支持加密，担心复杂性或性能挑战。然而，现有的格式保留加密方法以不改变数据格式的方式加密数据，导致强加密，几乎不需要应用程序已经运行的方式进行更改。

4.拥抱变化

很少有管理员愿意接受通常属于特权管理工具的手铐。但是，随着DevOps的压力越来越快，并且与补丁管理保持同步，需要使实施变更更容易进行操作。

安全团队必须抵制在每个系统上实现特权管理工具的每个功能的冲动。应该应用多少权限管理的选择必须基于风险。对于许多系统，检查密码和会话记录就足够了。更好的是基于风险的活动控制，如果使用高风险命令，则终止访问或升级身份验证。

此外，一些变化对时间敏感，以防止正在发生的事件成为头条新闻。通过编排工具自动执行对安全事件的常见响应，以便在选择更改时实现快速反应，同时将风险降至最低。

5.共同规划和培训响应程序

所有优秀的团队一起练习和训练，并且需要做同样的事情来应对网络攻击。 NIST网络安全框架于2018年4月更新，要求将响应计划，通信，分析，缓解和改进作为核心响应功能的一部分。

建立和实施上述每项活动的协议和程序的时间是在发生违规行为之前。试图在危机中弥补它们会留下不可避免的空白并延长暴露时间，从而造成更多的破坏。

在构建和培训这些协议和程序时，操作和安全性同等重要。一些组织认为安全性是IT安全团队的唯一责任。这不是一种实用的方法，因为任何处理过重大安全漏洞的人都会告诉您。

虽然IT操作和安全可能感觉像一对奇怪的夫妇一起被迫生活在一起，但是两个团队一起做的工作越多，每个人对另一个人的看法就会越多。

这最终将提高IT服务的机密性，完整性和可用性。这只是安全性和操作如何更紧密地协同工作的部分列表。加入对话，分享您的想法。

原文：https://techbeacon.com/security/why-security-it-ops-must-team-2019

本文：

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

DevOps是一种软件开发实践，开发和运营工程师在整个产品生命周期中进行协作。随着DevOps在主流级别的采用，我们现在看到安全性开始在DevOps的日常职责中发挥更大的作用。从安全角度来看，DevOps可以通过将安全性从最早阶段更紧密地嵌入到软件开发生命周期中来帮助提高应用程序的安全级别。但这种进步并非没有挑战和权衡。在这篇文章中，我们将研究DevOps对企业安全和安全组织的影响。

关于安全责任的辩论

编写好的代码意味着在代码开发过程中采用良好的安全实践。毫无疑问，开发人员需要编写具有高安全性标准的代码，但是出现的问题是谁负责组织的安全性？

在非DevOps环境中，我们看到集中安全模型的趋势，其中安全解决方案由公司安全团队管理。该团队执行组织安全策略 - 这意味着他们对安全性负责，并将实施和控制所需的安全产品以检测和阻止攻击。

但是，在应用程序开发方面，集中式安全模型存在已知的挑战。我们从不止一个Imperva客户那里听说，安全团队和应用团队之间往往没有很强的合作（协调，沟通......）。例如，应用程序团队在应用程序更改时不会更新安全团队，因此安全团队无法在启动新版本之前更新安全策略。

DevOps方法改变了组织思维。这个想法是“每个人现在都负责安全” - 这就是DevSecOps概念的出现方式。但企业安全团队如何适应新形象？

将安全责任转移给开发人员的挑战

采用DevOps通常会改变安全模型。一些职责从IT安全组织转移到应用程序团队。例如，除了部署应用程序之外，我们还看到应用程序团队部署（和运行）安全解决方案，例如Web应用程序防火墙（WAF）。

虽然这种变化可能带来好处，但它也可能给组织的安全带来一系列新的挑战。首先，在每个应用程序组中维护安全人才是低效的。在不同团队之间拆分安全知识会使在整个组织中应用统一安全策略的工作变得复杂。

此外，并非所有问题都可以通过编写安全代码来解决。作为一个例子，让我们看一下外部库的使用。现代应用程序倾向于依赖提供标准和经过验证的功能的第三方框架和库。通过使用这些库可能出现的安全漏洞的演示是Heartbleed，这是广泛使用的OpenSSL加密库中的一个漏洞，它影响了数百万个网站。通过单独修补所有应用程序来缓解Heartbleed和类似的漏洞是一项几乎不可能完成的任务。但是，使用集中式安全解决方案（例如使用虚拟修补程序的WAF）可以快速有效地保护所有系统。

但我觉得有一个更大的问题需要讨论。安全所有权。

安全团队的角色转变

在与客户交谈时，我们听到安全架构师说他们的角色将转变为“组织的安全顾问。”听起来很棒 - 这种转变可能会带来好的结果。安全工程师将开始与开发人员密切合作，减少组之间的摩擦，提高开发人员对安全性的意识。另一方面，将角色从所有者更改为顾问可能会降低安全专业人员的承诺水平，因为他们不再感到自己“拥有”安全性。

另一个主要问题是事件响应，因为安全性的所有权并未在部署时结束。虽然安全团队生活和呼吸安全，专注于预防和缓解，但应用程序团队无法对安全性给予同等程度的关注。在DevSecOps中，应用新的安全配置是一项任务，例如发布新版本的代码。安全工程师会立即将更新的策略应用为高优先级，但在DevSecOps下，此任务将成为代码发布管道的一部分，其时间可能因不同的应用程序团队而异。

安全组织在未来时代的作用

鉴于违规成本高且不断增长，安全仍将是优先事项。有人总是需要对组织的整体安全负责。执行管理层将继续让安保人员对整个安全负责，这似乎很自然。在这种情况下，安保人员必须继续在制定和执行安全战略方面发挥积极作用，不仅可以担任顾问。

毫无疑问，安全组织必须适应DevOps引入的不断变化的环境。即使在他们的新角色中，无论在其环境中如何形成，安全团队仍将定义和实施安全准则，自己的安全系统并定义如何将安全性合并到DevOps流程中。

安全产品还必须适应新环境，并提供与DevOps环境的更好集成。安全供应商必须意识到他们的用户可能不再只是安全专业人员，因为部署可以由软件工程师执行。安全经理有责任通过要求更多的自动化功能，推动供应商在需要时调整产品。

最后的想法

高层管理人员花了几十年的时间才要求安保人员在行政桌上提供企业安全状况更新。 DevOps可能会改变游戏规则，因为它为组织带来了很多价值 - 它提高了生产力和质量，甚至（在某些情况下）提高了安全标准。但共享的安全所有权可能会使事情倒退 - 消除了多年来在保护网站和服务方面取得的许多进展。虽然安全组织需要适应DevOps和DevSecOps的新世界，但它无法逐步淘汰并完全将安全性的所有权移交给开发人员。放弃完全控制可能最终会降低安全标准。随着安全漏洞趋势如今，安全团队发现一旦放开缰绳就很难重新获得控制权。

原文：https://www.imperva.com/blog/managing-security-devops-environment/

本文：

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

 

“安全永远是我们的首要任务。——沃纳·沃格尔斯，亚马逊副总裁兼首席技术官

敏捷性、成本、自主和更快的上市时间是为什么大多数客户将在06工作负载到云——让我们找出我们可以移动安全←左边对齐到这些软件开发原则——安全不应成为瓶颈,您可以使用云安全的工作负载在云上。

目标受众

如果您已经使用AWS Cloud几年了，我相信您能够理解我在这篇文章中试图表达的观点。请与更广泛的观众分享你的经历。如果你即将开始你的旅程，这是一个很好的开始，因为我将总结我多年来学到的一些实践。

我想你已经和AWS合作至少一年了。因此，在本系列的这一部分中，我不会详细解释本文中提到的任何AWS服务;相反，我将重点介绍您应该实现的策略，以获得更好的安全体系结构。本系列的其他部分将介绍一些实现。

在过去的两年里，我花了大量的时间与我的团队和其他云专家通过许多开源平台一起工作，试图改进AWS云上的安全实践。虽然在纸面上听起来很简单，但是在生产规模上实现它是一项非常具有挑战性的任务，需要跨不同的团队和非常不同的技术堆栈集进行协作。

不要担心，因为我们将涵盖所有的细节和即将发布的帖子。希望你能从我们的错误中吸取教训，并利用我们的胜利。重要的是，与我们分享你的经验。

这就解决了。我们走吧，走DevOps的路!

文化

消除指责的循环

在讨论AWS上的安全实现之前，让我们先从我们(安全人员)、我们的文化、我们的流程和思维方式开始。

“总的来说，我们辜负了客户。——VMWare首席执行官帕特•盖尔辛格(Pat Gelsinger)表示。

帕特说的对极了，我们的安全团队。多年来，我们关注的是威胁，而不是建立安全能力。首先，安全团队将大部分时间花在应对威胁上，而不是预防威胁。

我们应该更多地讨论收缩攻击表面的实现和预防机制。复杂、缓慢和团队间的冲突破坏了许多组织。只有当您将简单性应用于流程，将更多的协作精神应用于企业文化，并将可靠的安全原则(由数据支持)应用于决策引擎时，您才能看到事情正在朝着正确的方向发展。我也同意安全团队资金不足的说法，他们总是为了“最好的性价比”而奋斗。“这使我们更聪明!

我们的团队必须共同努力，以实现组织的安全目标;最后，安全应该是每个人的工作。我们花在互相指责上的时间越少，我们就越容易有效地合作。

共享责任模型

我知道，你在想，从哪里开始呢?我知道您正试图赶上每天发布新特性或bug修复的应用程序团队，他们有很多需要担心的事情。我知道这很容易跳的很酷的东西,开始实施策略通过自动化或其他方式,但理解你作为一个客户的责任就是你需要开始,所以开始与共同责任模型因为你会避免很多新手的错误。

AWS共享责任模型

根据您对AWS计算服务(EC2、ECS/EKS或lambda等)或公共云模型(IaaS、PaaS或SaaS)的选择，您作为客户的责任可能会发生根本性的变化，但是我们不会在本文中详细讨论这一点，因为这篇文章可以独立撰写。

但是，在高层次上，您应该非常担心数据的安全性，因为您不能将此责任转移给AWS，无论您使用什么AWS服务或采用什么公共云模型，这都是您的义务。

您越接近无服务器，就越不需要担心补丁管理和OS级别的安全加固噩梦。

对于您的公共云模型也是如此，您越倾向于SaaS，就越不需要担心基础设施安全性。请注意，我不是提倡SaaS，我只是陈述事实。

公共云模型

多账户模型

理解了作为客户的安全性职责之后，就可以考虑大规模地实现治理了。早期采用者学到的重要经验之一是;从安全和成本管理的角度来看，将应用程序部署在一个AWS帐户上是一种危险的做法，因为它会使云管理过程复杂化。

AWS帐户体系结构

我将让您决定如何构建您的帐户，但是上面的图表说明了一个常见的模式。

您需要为开发人员提供一个沙箱帐户来尝试新功能，并为每个产品提供正式的开发、预戳和戳帐户。拥有一个日志帐户，您可以在其中聚合所有CloudTrail日志、配置规则、S3访问日志和其他与安全相关的数据，审计人员可能需要访问这些数据，以防发生违规。

您还需要一个用于对其他帐户执行策略的管理帐户。尝试将帐单委托给帐单管理帐户，而不是使用主帐户。使用主帐户对链接帐户应用组织服务控制策略。

资源标签是一个巨大的问题，成本控制是当今企业面临的重要问题之一。再一次，多账户模型来拯救，因为您已经将每个产品部署到一个单独的AWS帐户上，所以您知道“产品团队”可以吃掉整个账单，您不应该过多地担心他们的标记缺陷事件，尽管我认为标记对于许多其他原因是必要的。

许多为所有应用程序使用一个帐户的AWS客户都经历了服务限制不断增加的痛苦。您有许多工程师在争夺有限的资源(s3 bucket、计算机资源和其他资源)，更不用说AWS有一些无法为您增加的硬限制。

我一直最喜欢的多账户模式的好处是它提供的有限爆炸半径。我可以确保开发团队A不能访问开发团队B的账户，这样他们就不会破坏他们的东西。我也可以在晚上睡觉时知道，如果我的猫在AWS账户120上的图像处理产品被入侵，我在其他AWS账户上的其他产品将不会受到影响。我想你现在看到了使用这个模型的好处:)而且它不会花费你更多的钱!在您开始使用资源之前，AWS帐户是免费的。

云计算赋能

确保您所做的一切不会毫无理由地阻塞您的开发人员。必须在允许开发人员快速开发和确保环境安全之间取得平衡。首先要确保开发人员知道，您并不是要充当拦路虎，而是要充当推动者。

建立一个商定的安全基线，该基线需要满足您的业务的每个帐户，以符合特定于行业的法规。

解剖学和速度是必不可少的业务安全所以确保你对齐安全实践你的业务工作在和谐,说这很简单,因为它需要大量的传福音,了解你的产品和基础设施除了你所有的合规要求。

自动化&策略as Code (PaC)

云托管

我不知道您的想法，但是用代码构建安全策略并在几分钟内将其部署到生产环境中，这种想法非常酷。你可以控制你的策略的版本，知道谁做了一个糟糕的合并，以及最后一个好的版本是什么。

还记得开发人员需要等待五周才能批准防火墙请求吗?那些日子一去不复返了。开发人员现在可以在几秒钟内创建安全组规则，并在更短的时间内向全世界开放端口22。

开发人员从不关心充满过时安全策略的冗长文档，他们从不阅读这些文档，即使您花费了宝贵的时间来更新它们，他们也不会这样做。

那么你应该怎么做呢?如果您正在考虑自动化您的安全策略，那么您应该拍拍自己的肩膀。为了跟上速度，云提供了你的业务;安全策略需要像您的基础设施一样灵活。您需要像您的应用程序团队一样快速或缓慢地移动。

在AWS、AWS组织服务控制策略、IAM策略以及特定于服务的策略(如KMS键策略和bucket策略)上定义策略的方法有很多。

自动化使这种灵活性成为可能，而编写策略是不可思议的，因为可以将安全策略视为基础设施和应用程序代码。策略可以在git中检入、修改、改进、重构、由多人查看，应用于应用程序代码的所有内容都可以应用于策略代码。

您可以使用Lambda和CloudWatch事件等服务，或者利用云托管等开源工具来帮助您通过自动化实现遵从性。

关键是，自动化您的安全控制，或者准备好输掉这场战斗。

实时检测、通知和修复是非常云化和人性化的。

如果您的开发人员在部署Prd期间向全世界开放了s3 bucket，请检测到这一点，并立即通知他们您已经检测到这个问题并为他们修复了它。如果您在产品投产两周后发现安全性问题，那么说服构建器修复它将不是一项有趣的工作。实时反馈通常很受欢迎，因为他们可以立即采取行动。

身份和访问管理

AWS  IAM

AWS IAM是AWS安全的核心。如果你和我的忍者交谈，他们会告诉你，让AWS的IAM正确是一个游戏改变者，因为在我看来，这是AWS最强大的服务之一。

AWS IAM使您能够定义非常细粒度的策略，帮助您轻松设置边界和实现最小特权原则。IAM集成了所有AWS服务，甚至包括允许您直接在其上建立策略的服务，如s3和KMS。

IAM的关键是使用角色并假设这些角色，而不是在任何地方都必须使用API键。此外，尽可能自动化策略、组和角色的创建，并为策略、角色和组定义良好的命名转换，以避免配置偏移。理解条件和IAM操作可能比较棘手，但是如果您想要严格控制访问策略，那么这是必不可少的。

我给您的建议是，请避免使用单一的AWS帐户模型，这样您就可以避免切割策略。

数据安全

通过加密静止、传输中的数据，并确保只有需要访问数据的人才能访问数据，从而确保数据的安全是至关重要的。尽管这看起来很简单，但是许多组织都不能理解它。

我经常在google上搜索s3 bucket泄漏的数据，并与我圈子里的人分享我的发现，以吓走所有人。我记得有好几天没有听到这种新闻。

我学到的教训是尽早对数据进行分类，并确保所有数据存储都有所有者。您还应该加密所有内容，并确保所有数据存储都受到保护。

KMS是不可思议的，因为它为您完成了所有繁重的工作，创建主键、数据键和键旋转都是由AWS为您管理的。如果你想有更多的控制权，你可以带客户的钥匙，自己管理他们。

基础设施安全

由于AWS为您处理物理基础设施安全性，所以您可以关注VPC中的流量和资源的安全性。首先创建私有和公共子网，使用VPN或bastion主机访问服务器。使用nacl和安全组来限制流量是必须实现的最佳实践。

通过利用不可变基础设施的概念，避免使用SSH之类的协议，因为它本质上提供了更大的安全性。

不修补实例只是重新构建一个新的AMI，不进行适当的更新，只是从一个基本映像进行销毁和构建。

使用AWS git-secrets检测意外签入git存储库的密钥。使用EC2角色而不是API密钥，也不要忘记您的EC2密钥对，如果这些泄漏，rest确保您的服务器将在短时间内挖掘比特币。

如果您使用s3作为静态web主机，我强烈建议使用CloudFront发行版作为bucket的前端，并利用AWS原始访问标识将bucket限制在发行版中。该模式将对象隐藏起来，使您能够访问AWS WAF和Shield等不能直接与s3一起工作的安全特性。

 

弹力

Netflix混乱的猴子

高可用性、操作的连续性、健壮性和恢复能力以及灾难恢复通常是使用AWS部署云的原因。多az和多区域部署都是我们都需要根据AWS架构良好的框架进行调整的模式。

使用诸如AWS架构良好的工具可以帮助您在AWS上部署更具弹性的工作负载。AWS使您更容易为失败进行架构，大多数服务提供高可用性和持久性，其他服务可以被架构为更具弹性。AWS建议我们在设计时考虑四大支柱;安全性、可靠性、成本优化和性能。

AWS架构的四大支柱

在完成设计和实现阶段之后，可以通过引入混沌工程和增强对基础设施的信心来测试基础设施，还可以定义能够帮助您在出现故障时更快地恢复的过程。您可以从单个节点(AZs)开始测试，或者取下整个区域，看看您的应用程序如何处理这些问题。

日志记录和监控

必须启用CloudTrail、Config和VPC流日志，并将其聚合到日志帐户中。您还应该确保在每个区域中都启用了这些服务，如果有人试图禁用其中任何一个服务，则会通过自动化得到通知。

还应启用AWS guardduty和AWS SecurityHub;两者都提供出色的监视功能。被动监视是不够的，我们应该以实时自动化来应对安全事件为目标。

事件响应

说到实时自动化，我们应该拥有一个剧本，帮助指导我们业务中的安全专业人员和涉众更有效地响应安全事件。

不知道谁拥有这些数据，不知道如何处理一个受攻击的实例或更糟的事件——一个被劫持的AWS帐户——是一个糟糕的处境。我们需要尽可能地自动化，但我们也需要定义的职责和文档化的流程，以便我们可以参考。我认为这个主题写起来会很有趣，所以我很快就会在这里停下来写一篇博客!

DevSecOps

这是一个很像DevOps的流行词汇。DevSecops或SecDevOps是在CI/CD工作流上实现安全性的实践。当代码通过所有较低的环境进入生产环境时，将扫描并检查其安全性漏洞。

我们不会等到安全团队在我们的代码投入生产前的最后一分钟才祝福我们的代码，我们会尽早从安全性着手，在编写代码时使用IDE插件来查找安全性bug。使用Docker bench等工具以及其他可以轻松与Jenkins集成的工具是一个很好的起点。

DevSecOps是一种以“每个人都对安全负责”的心态来处理IT安全的方法。它涉及到将安全实践注入组织的DevOps管道。目标是将安全性合并到软件开发工作流的所有阶段。这与它的前辈开发模型相矛盾——DevSecOps意味着您没有为SDLC的最后阶段保存安全性。

合规验证

你有客户的信用卡信息吗?医疗保健信息?或任何个人识别资料(PII)?当您根据特定于行业的最佳实践检查基础设施时，您需要了解您正在做什么。

如果你不遵守行业规则，你就不能做生意。我们可以使用AWS配置规则来持续审计我们的基础设施。如果我们不需要遵守其他框架，如PCI DSS或HPPA，那么我们至少应该从CIS基准开始。

 

原文：https://itnext.io/architecting-security-governance-across-your-aws-accounts-part-1-introduction-ae200624424d

本文：

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

 

一些IT安全框架和网络安全标准可用于帮助保护公司数据。以下是为您的组织选择合适的建议。

信息安全管理包括许多领域--从外围保护和加密到应用程序安全和灾难恢复。法规遵从性法规和标准（如HIPAA、PCI DSS、Sarbanes-Oxley法案和GDPR）使IT安全更具挑战性。

这就是IT安全框架和标准有帮助的地方。法规、标准和框架的知识对所有信息安全和网络安全专业人员至关重要。从审计的角度来看，遵守这些框架和标准也很重要。

为了帮助管理流程，让我们看看IT安全标准、法规和框架是什么，以及一些更受欢迎的选项可供选择以及如何使用。

什么是IT安全标准和法规？

标准就像一个配方；他们列出了要执行的步骤。管理良好的IT组织必须符合标准中规定的要求。

相比之下，法规具有法律约束力。他们描述如何做某事的方式表明政府和公众对法规中规定的规则和程序的支持。不遵守以IT为重点的法规可能会导致经济处罚和诉讼。

什么是IT安全框架？

IT安全框架是一系列文档化的过程，定义了信息安全控制的实施和持续管理的政策和程序。这些框架是管理风险和减少脆弱性的蓝图。

信息安全专业人员使用框架来定义管理企业安全所需的任务并确定其优先级。框架还用于帮助为合规性和其他IT审计做准备。因此，该框架必须支持标准或法规中定义的特定要求。

组织可以自定义框架来解决特定的信息安全问题，例如特定于行业的要求或不同的法规遵从性目标。框架也有不同程度的复杂性和规模。如今的框架经常重叠，因此选择一个有效支持运营、合规和审计要求的框架非常重要。

为什么安全框架很重要？

框架为建立信息安全管理的流程、政策和行政活动提供了一个起点。

安全要求经常重叠，导致“人行横道”可以用来证明符合不同的监管标准。例如，ISO 27002在第5节中定义了信息安全政策；信息和相关技术的控制目标（COBIT）在“协调、计划和组织”部分对其进行了定义；Treadway委员会赞助组织委员会（COSO）框架在“内部环境”部分对其进行了定义；HIPAA在“分配的安全责任”部分对其进行了定义；PCI DSS在“维护信息安全策略”部分对其进行了定义。

使用通用框架（如ISO 27002），组织可以建立人行横道，以证明其符合多项法规，包括HIPAA、Sarbanes-Oxley法案（SOX）、PCI DSS和Graham Leach Bliley法案。

如何选择IT安全框架

使用特定IT安全框架的选择可能受到多种因素的驱动。行业类型或合规性要求可能是决定性因素。例如，上市公司可能希望使用COBIT来遵守SOX，而医疗保健行业可能会考虑HITRUST。另一方面，ISO 27000系列信息安全框架适用于公共和私营部门。

虽然ISO标准的实施通常很耗时，但当组织需要通过ISO 27000认证来展示其信息安全能力时，这些标准会很有帮助。虽然NIST特别出版物（SP）800-53是美国联邦机构要求的标准，但任何组织都可以使用它来制定特定技术的信息安全计划。

这些框架帮助安全专业人员组织和管理信息安全计划。在这些框架中，唯一糟糕的选择是不选择任何一个。

IT安全标准和框架示例

1.ISO 27000系列

ISO 27000系列是由国际标准化组织开发的。它是一个灵活的信息安全框架，可以应用于所有类型和规模的组织。

 

两个主要标准——ISO 27001和27002——确立了创建信息安全管理系统（ISMS）的要求和程序。拥有ISMS是一项重要的审计和合规活动。ISO 27000包括概述和词汇表，并定义了ISMS要求。ISO 27002规定了开发ISMS控制的实施规范。

遵守ISO 27000系列标准是通过审计和认证过程建立的，通常由ISO和其他认可机构批准的第三方组织提供。

ISO 27000系列有60个标准，涵盖广泛的信息安全问题，例如：

• ISO 27018涉及云计算。
• ISO 27031提供了有关IT灾难恢复计划和相关活动的指导。
• ISO 27037涉及数字证据的收集和保护。
• ISO 27040解决了存储安全问题。
• ISO 27799定义了医疗保健中的信息安全，这对需要遵守HIPAA的公司非常有用。

2.NIST SP 800-53

NIST开发了一个广泛的IT标准库，其中许多标准侧重于信息安全。NIST SP 800系列于1990年首次发布，几乎涵盖了信息安全的各个方面，并越来越关注云安全。

NIST SP 800-53是美国政府机构的信息安全基准，在私营部门广泛使用。SP 800-53有助于推动信息安全框架的发展，包括NIST网络安全框架（NIST CSF）。

3.NIST SP 800-171

NIST SP 800-171因美国国防部对承包商遵守安全框架的要求而广受欢迎。政府承包商由于靠近联邦信息系统，经常成为网络攻击的目标。政府制造商和分包商必须有一个IT安全框架来竞标联邦和州的商业机会。

NIST SP 800-171框架中包含的控制与NIST SP 800-53直接相关，但不太详细，更为笼统。如果一个组织必须以NIST SP 800-171为基础，证明其符合NIST SP 800-53，则可以在这两个标准之间建立人行横道。这为较小的组织创造了灵活性——它们可以使用NIST SP 800-53中包含的额外控制措施，在成长过程中显示出合规性。

4.NIST-CSF

NIST改善关键基础设施网络安全框架（NIST CSF）是根据2013年2月发布的第13636号行政命令制定的。它的开发是为了解决美国的关键基础设施问题，包括能源生产、供水、食品供应、通信、医疗保健和运输。这些行业必须保持高度的准备，因为它们都因其重要性而成为民族国家行为者的目标。

与其他NIST框架不同，NIST CSF专注于网络安全风险分析和风险管理。该框架中的安全控制基于风险管理的五个阶段：识别、保护、检测、响应和恢复。与所有IT安全计划一样，这些阶段需要高级管理层的支持。NIST CSF适用于公共和私营部门。

5.NIST SP 1800系列

NIST SP 1800系列是对NIST SP 800系列标准和框架进行补充的一套指南。SP 1800系列出版物提供了有关如何在现实应用中实施和应用基于标准的网络安全技术的信息。

SP 1800系列出版物提供了以下内容：

• 具体情况和能力的示例。
• 基于经验的操作方法，使用多种产品来实现所需的结果。
• 关于各种规模组织能力实施的模块化指导。
• 所需组件的规范以及安装、配置和集成信息，使组织能够轻松地复制流程本身。

6.COBIT

COBIT是由ISACA在20世纪90年代中期开发的，ISACA是一个由IT治理专业人员组成的独立组织。ISACA提供著名的认证信息系统审计员和认证信息安全经理认证。

COBIT最初专注于降低IT风险。2012年发布的COBIT 5包含了新技术和业务趋势，以帮助组织平衡IT和业务目标。当前版本为COBIT 2019。它是实现SOX合规性最常用的框架。许多出版物和专业认证都满足了COBIT的要求。

7.CIS控制

互联网安全中心（CIS）关键安全控制，版本8（以前称为SANS Top 20）列出了可应用于任何环境的技术安全和操作控制。它不像NIST CSF那样涉及风险分析或风险管理；相反，它只专注于降低风险和提高技术基础设施的弹性。

18个CIS控件包括以下内容：

• 企业资产的盘点与控制。
• 数据保护。
• 审核日志管理。
• 恶意软件防御。
• 渗透测试。

CIS控制与现有的风险管理框架相联系，以帮助补救已识别的风险。对于缺乏技术信息安全经验的IT部门来说，它们是有用的资源。

8.HITRUST通用安全框架

HITRUST通用安全框架（CSF）包括风险分析和风险管理框架以及操作要求。该框架有14个不同的控制类别，几乎可以应用于任何组织，包括医疗保健。

HITRUST CSF对于任何组织来说都是一项巨大的事业，因为它对文档和流程的重视程度很高。因此，许多组织最终确定了HITRUST关注的较小领域。获得和维护HITRUST认证的成本增加了采用该框架所需的努力水平。认证由第三方审核，这增加了有效性。

9.GDPR

GDPR是全球组织必须实施的安全要求框架，以保护欧盟公民个人信息的安全和隐私。GDPR要求包括限制未经授权访问存储数据的控制措施和访问控制措施，如最低权限、基于角色的访问和多因素身份验证。

 

10.COSO

COSO是五个专业组织的联合倡议。其内部控制——综合框架于1992年发布，并于2013年更新，帮助公司实现基于风险的内部控制方法。它包括以下五个组成部分：

• 控制环境。
• 风险评估和管理。
• 控制活动。
• 信息和通信。
• 监测。

COSO于2004年发布了企业风险管理（ERM）——综合框架，并于2017年进行了更新。该框架旨在帮助组织改进网络风险管理，涵盖以下五个组成部分的20项原则：

• 治理和文化。
• 战略和目标设定。
• 表演
• 审查和修订。
• 信息、沟通和报告。

2019年发布的一份指导文件《数字时代的网络风险管理》就如何准备和应对企业网络威胁提供了建议。它与COSO ERM框架保持一致。

 

11.FISMA

《联邦信息安全现代化法案》（FISMA）与NIST风险管理框架紧密一致，为保护联邦政府数据和系统提供了一个安全框架。FISMA于2002年推出，并于2014年更新，建议在2023年更新；立法悬而未决。

FISMA要求联邦机构及其第三方、承包商和供应商制定、记录和实施安全政策和做法，包括监控其IT基础设施和进行定期安全审计。

12.NERC CIP

北美电力可靠性公司关键基础设施保护是一个由14个已批准和提议的标准组成的框架，适用于大容量电力系统内的公用事业公司。这些标准概述了监测、监管、管理和维护关键基础设施系统安全的建议控制和政策。

CIP标准包括以下内容：

• CIP-004-6网络安全——人员和培训。
• CIP-008-6网络安全——事件报告和响应计划。
• CIP-013-1网络安全——供应链风险管理。
• CIP-014-1物理安全。

大容量电力系统所有者、运营商和用户必须遵守NERC CIP框架。

Web应用程序攻击正在增加。最近的一项研究发现，它们是2017年和2018年第一季度报告的违规行为的主要原因。这一显着增长部分是由于Web应用程序漏洞的多样性，因为新的攻击媒介被发现并被利用。

缺乏对安全性的关注也是一个问题，另一项研究发现，96％的Web应用程序都包含某些可能用于伤害用户的漏洞。

应用程序开发人员和安全人员需要了解这些新兴的Web应用程序漏洞，以及应该采用的网络安全实践来加快应用程序安全策略和过程。知识是保护应用程序及其用户的关键，特别是在新威胁出现时（攻击者抓住机会利用它们）。

教育：2019年的主要Web应用程序漏洞

1.人工智能攻击

人工智能（AI）为Web应用程序开发带来许多好处，允许开发人员创建更有意义和更强大的产品。但AI也被用于恶意活动。

攻击者可以使用基于AI的黑客算法来查找最微小的应用程序漏洞并分析复杂的用户行为和场景。通常需要数周和数月才能完成的分析几乎可以立即完成，从而为攻击者提供可用于利用Web应用程序的信息。

检测到的第一个AI网络攻击是2017年末，当时攻击软件能够通过模仿正常行为来伪装自己，使其更难被发现。自动机器人也可用于发动攻击，因为它们变得更难以与人类区分并且越来越善于表现出“正常”行为。

这种攻击的最佳防御方法是使用AI。使用AI来保护您的应用程序是应用程序安全性的未来，也是行业发展的方向。将其构建到您的安全系统中，以进行主动监控和事件报告。

AI可以帮助减少误报，确定威胁的优先级，并自动化修复过程。公司还需要改进认证措施，以便自动化机器人更难以规避。典型的安全问题，用户名和密码是不够的。例如，如果您还没有添加软件或硬件令牌，请考虑使用它们。

2.开源安全威胁

开源组件通常用于Web应用程序开发。它们缩短了开发时间，允许开发人员为其Web应用程序添加功能，而无需从头开始编写代码。增加的功能有助于在保持预算和时间表的同时提供更好的最终产品。

但是，如果不考虑安全性，这些好处就会消失。我们始终建议对所有开源组件进行安全测试。不要因为其他人使用它们而认为它们是安全的。

这在未来一年将变得更加重要。为什么？随着开源在Web应用程序开发中变得越来越普遍，它成为攻击者的一个更大（更具吸引力）的目标。如果他们可以找到一个开源组件或库的漏洞利用，他们可能会同时攻击多个应用程序。并且因为这些库和组件是开放的，所以它们使得它们更容易找到这些漏洞。

最近对开源安全性的分析发现，开源组件的使用正在增加，但对安全性的关注并未跟上步伐。被审查的企业中有三分之一尚未修补源自开源组件的漏洞，发现的威胁中有一半以上被认为是关键漏洞。

防御这些攻击的第一步是仅使用来自受信任存储库的开源代码 - 无论这看起来多么明显，这是一个非常少的开发人员打扰的预防措施。活跃的用户社区是开发人员目前正在使用并（希望）测试开源组件以解决安全问题的好兆头。

除此之外，应使用软件组合分析（SCA）工具（如Black Duck Hub和OWASP依赖项检查）在部署之前扫描源代码中的漏洞。

另一个重要的，看似简单的预防措施是创建一个工作文档来跟踪应用程序中的开源组件 - 您正在使用的所有组件，它们的使用位置以及当前部署的版本。如果发生攻击，此文档将允许您快速识别受影响的应用程序或代码行，从而帮助您快速修复威胁。

如果发现漏洞，还可以使用正式的补救策略来确保您的团队准备好快速采取行动。移动得越快，造成的伤害就越小。

3.勒索软件

根据2018年赛门铁克互联网安全威胁报告，勒索软件是2017年最普遍的攻击类型之一，增长了46％。

勒索软件经常让我们想到整个网络被攻击锁定（如WannaCry违规的情况），但它也可能发生在应用程序级别。在这种情况下，应用程序会受到攻击，无法再正常使用。攻击者要求赎金以换取释放申请。

Spora是一个强硬的勒索软件攻击的例子。在此攻击中，JavaScript代码会添加到网站并生成弹出式提醒，提示用户更新其Chrome浏览器。然后攻击者窃取用户的凭据并索要赎金或出售信息以换取金钱。

Web应用程序对勒索软件攻击并不安全。最常见的进入途径是通过Web应用程序中使用的软件包。攻击者可以将勒索软件工具包嵌入到软件包中，开发人员可能会在不知不觉中将软件包作为其Web应用程序的一部分进行安装。

如上所述，开发人员经常在Web应用程序开发中使用第三方软件包，其中许多开源解决方案容易受到攻击，因此攻击者很容易创建恶意版本并诱骗开发人员使用它们。

为了保护您的Web应用程序免受勒索软件的侵害，您当然应该对Web应用程序中使用的所有第三方组件执行定期安全测试。我们还建议使用包管理器（如Sonatype）来创建一个受信任的包存储库，供开发人员选择。

4.攻击已知漏洞

Gartner预测，到2020年，99％的漏洞利用已经知道至少一年 - “已知”意味着这些漏洞已被识别和披露，但尚未修复。使用具有已知漏洞的组件会使您的应用程序受到攻击。

Heartbleed漏洞就是一个很好的例子。此漏洞可以追溯到一行代码，这会使敏感数据面临风险。许多公司一旦曝光就争先恐后地更新补丁。如果不对其他漏洞执行此操作，您的组织将面临破坏性攻击。

一旦发现漏洞，尤其是那些可能危及敏感信息的漏洞，这一点很重要。教育开发人员了解应用程序安全性的重要性可以激励他们为安全性提供应有的关注。

从第一天开始，安全性需要整合到设计和开发过程中。有很多方法可以使这种集成变得更容易，正如您将在讨论来年的网络安全趋势时所看到的那样。

预防：2019年最重要的网络安全趋势

1. Bug赏金计划

赏金计划正在变得越来越受欢迎，其中攻击者付费试图侵入应用程序和系统以暴露漏洞。这些“友好”的攻击者通过在恶意攻击者利用漏洞之前发现漏洞来帮助提高应用程序的安全性。这种方法填补了自动安全测试可能遗漏的空白。

有时需要通过人工触摸来找到暴露应用程序以进行攻击的新方法，并且发现新的或罕见漏洞的攻击者获得了良好的回报。像HackerOne这样的Bug赏金公司管理经过审查的攻击者并帮助组织更快地发现漏洞。

2.应用程序漏洞管理

正如我们前面提到的，安全性需要集成到开发过程中。更多组织将开始使用工具来简化此过程。应用程序漏洞管理器通过从多个测试工具中删除重复结果并确定结果优先级来简化应用程序安全测试流程，以便您可以首先处理最严重的威胁。

质量应用程序漏洞管理工具集成到开发人员的工作环境中，例如Eclipse和Jenkins，因此可以查看和跟踪漏洞，而无需强迫开发人员切换到其他应用程序。像这样的工具允许全面的应用程序安全性测试，而不会减慢开发过程。

3.数据安全治理计划

更多组织将在2019年开始采用数据安全治理（DSG）计划。数据治理可保护组织内所有数据（包括应用程序）的完整性，可用性，可用性和安全性。

正式的DSG计划详细说明并实施标准化的策略和程序，以便更有效，更安全地保护用户和业务数据。作为该计划的一部分，确定并处理安全方面的差距。您的DSG计划应该是更大的IT治理策略的一部分，因此它适合您的整体安全计划。

4.运行时应用程序自我保护（RASP）

RASP通过实时检测攻击来提高Web和移动应用程序的安全性。代理程序安装在应用程序中，并监视应用程序是否存在攻击并对其进行防护。

它在应用程序运行时为应用程序添加一层保护，检查每个执行的指令并确定任何给定的指令是否实际上是攻击。

它可以在诊断时使用，在发现攻击时引发警报或警报。它还可以用于自我保护，并实际上停止可能导致攻击的执行。

到2022年，全球RASP市场目前预计将以29％的复合年增长率（CAGR）增长。

5.减少对密码的依赖

虽然我们不希望密码完全消失（它们已经过于成熟），但会发生转变，更加重视其他识别技术。这种转变将在中高风险应用中更频繁地发生，以使其更安全。

面部识别是一个可以改善网络和移动应用程序安全性的示例。随着威胁数量和种类的增加，这些更先进的验证程序变得越来越重要。

随着Web应用程序攻击的不断增加，开发人员和安全团队必须共同努力，以防止或抵御新的和现有的威胁。将安全性整合到整个应用程序设计，开发和部署过程中的全面应用程序安全策略是保护您的企业和用户免受攻击的最佳方式。该策略必须包括对最新攻击媒介的教育和网络安全的进步，以便您的防御始终处于最佳状态。

原文：https://codedx.com/predicted-web-application-vulnerabilities-and-cybersecurity-trends-for-2019/

本文：

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

 

运行时应用程序自我保护技术（RASP）可直接从运行时引擎（如JVM）缓解应用程序级漏洞。

开发人员依靠Python，Node.js和Java等语言来编写和发布复杂的Web应用程序，但是他们快速的开发周期使这些应用程序的安全成为一项挑战。输入RASP（运行时应用程序自我保护），它将漏洞保护直接整合到应用程序中，以阻止出现的威胁。

应用程序使用RASP通过将安全控件包含到应用程序运行时引擎（如JVM）中来自我防御内部和外部攻击。由于控件是运行时引擎的一部分，因此RASP可以全面了解应用程序的逻辑流程，数据流和配置。

 



在基本级别，RASP通过阻止未经授权的尝试执行shell命令来保护应用程序。完成所有这些操作无需对应用程序代码进行任何更改。

“RASP在应用程序内部移动保护，”Immunio的首席技术官Mike Milner说，它提供了一个保护Java和其他动态语言的平台，包括Python，Node.js和Ruby on Rails。

Immunio的平台不仅限于检测和防范代码级漏洞和跨站点脚本和SQL注入等应用程序问题。它还可以检测和阻止帐户接管。 Immunio最近在平台上添加了Node.js支持，以反映企业内Node.js的增长。

许多企业将其开发工作集中在单一语言（如Java或.Net）上，并使用静态分析工具来查找这些应用程序中的漏洞。动态语言的采用率的增长使得依靠静态代码分析来发现漏洞变得更加困难。动态语言越来越多地为大量互联网提供动力，企业需要更快的方法来缓解生产环境中的漏洞。

企业通常必须等待供应商发布商业应用程序的补丁，这为攻击者留下了机会之窗。开源应用程序的情况甚至更加模糊。但是，使用RASP，组织可以在等待官方补丁时保护应用程序，无论它何时到达。

考虑一下今年早些时候公布的Java反序列化漏洞。该漏洞已经在JBoss和Websphere等应用程序中进行了修补，但在较旧的Rails应用程序中可能仍未修补，而且Milner指出许多自定义Java应用程序可能仍然存在缺陷。这就是RASP派上用场的地方，因为它可以保护应用程序免受试图触发该漏洞的攻击。

毫无疑问 -  RASP并不能解决Web应用程序中的软件漏洞问题。它不应被视为Web应用程序防火墙的替代品，甚至不应被视为转储应用程序安全测试和静态代码分析的借口。 WAF擅长检测和阻止针对应用程序的网络级攻击，例如检测恶意IP和自动机器人，以及阻止拒绝服务攻击。另一方面，RASP更适合监视代码级漏洞并减轻跨站点脚本和SQL注入威胁。

应用程序受到攻击，因此企业需要结合使用跨越开发和运营的检测和保护技术，而不是寻找一颗银弹来保护它们。开发人员仍然需要通过静态代码分析扫描程序运行代码，以便在开发阶段发现漏洞。应用程序安全测试有助于在软件上线之前发现安全问题。

对于devops爱好者，安全测试和代码扫描解决了方程式的“开发”部分，而RASP涵盖了“操作”，因为它让团队“主动应对其应用程序中的漏洞，而不是被动反应”，Milner说。

 

原文：https://www.infoworld.com/article/3089951/how-rasp-protects-applications-from-attacks.html

本文：

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

 

JFrog Xray  - 不仅仅是另一个安全漏洞扫描程序。

我们刚刚正式推出了JFrog Xray，客户已经问过为什么我们认为应该使用JFrog Xray而不是$ YOUR_FAVORITE_SECURITY_SCANNING_TOOL。 Xray喜欢黑鸭吗？ 也许它就像Docker Security Scanning？ 也许它类似于Sonatype Nexus组件智能？

在进入差异列表之前，有一个巨大的概念转变。 Xray不仅仅是另一个带有普通扫描器的安全数据库。它是通用二元影响分析产品。递归分析的能力使Xray成为独一无二的，并且它是开放且通用的，可以连接到您的安全和许可证数据库或任何其他元数据。不确定我的意思？继续阅读，这篇文章的结尾都有意义。

现在，在我们成功确定Xray与传统安全漏洞扫描程序（如Sonatype Nexus组件智能或Docker Security Scanner）不同的类别之后，让我们将苹果与橙子进行比较，以更好地理解为什么Xray会大大改变您对二进制影响的思考方式分析：

1.这不仅仅是安全漏洞。影响分析应该是普遍的。

确实恐慌是卖（问一些政治家），但正如Roy Schestowitz博士所说，我们不卖FUD。您希望了解许多不同的度量标准，并提醒您有关组件的许可 - 许可证合规性，运行时性能问题，错误，体系结构决策，过时的组件，甚至还有完全特殊的规则要应用，例如检测组件你的竞争对手的IP。是的，安全漏洞也是如此。

Xray使用内部元数据源与其连接的外部元数据源相结合，为您提供真正的通用影响分析。

2.那容器怎么样？！并非所有的软件都是Java（或NuGet或npm）。影响分析应该是普遍的。

Java主导软件世界（或多或少），但今天，很难找到只做Java的组织。 Polyglot编程是新的“正常”，然后有DevOps将其他类型的软件带到开发人员的板块 -  Docker，RPM，YUM，Vagrant。一个只能扫描Java组件的工具是...... 2005年？

目前，Xray能够扫描Java JAR和WAR，Nuget包，Python egg，npm包，RPM和Debian包，当然还有Docker镜像。很快，Xray将支持世界上最全面的工件库中支持的所有包类型 -  JFrog Artifactory。

3.一个数据库无法全部了解，但影响分析应具有普遍性。

世界上没有数据库可以包含全面影响分析所需的所有元数据 - 所有不同类型组件的所有安全漏洞，所有许可证，所有版本，当然世界上没有数据库可以包含您的专有决策制作元数据。此外，有不同的影响分析方法可能适合其他组织，但不适合您的（例如，您是否可以将依赖关系的指纹发送到云？）。

Xray为您提供了选择的自由 - 您可以使用Xray的内部安全漏洞，许可证和组件版本数据库来实现零配置体验。由于我们设计Xray是通用的，我们的合作伙伴已经构建了集成，因此您可以连接任意数量的外部工具，如Black Duck，WhiteSource和Aqua（如果它们更适合您的需求，请继续关注更多）。 JFrog还将继续添加更多元数据提供程序以与Xray集成。但是自定义元数据怎么样？通过一个开放的REST API，Xray为您提供了一种将任何决策机制挂钩到Xray的简单方法，并了解它如何影响您的应用程序。

4.组件不是扁平的。影响分析应该是普遍的。

因此，例如，Nexus Component Intelligence能够扫描Java组件。或者，让我们来看看Docker Security Scanner。它只能扫描Docker镜像。但是，在Docker镜像，RPMor Debian软件包或gzip压缩文件中，Java组件呢？不。在Nexus Component Intelligence的世界中，组件只能以独立的扁平结构存在。

现实世界是不同的。组件像俄罗斯娃娃一样包含在内; WAR中的JAR，Debian软件包内，Docker镜像内，Vagrant框内的JAR。 Xray作为一个通用工具，知道如何打开这些包，发现内部的内容，并递归地索引这些组件。

5.您需要在全公司范围内进行影响分析，这应该是普遍的。

想象一下，如果Xray在组织内某个项目的一个生产环境中的Docker容器内运行的其中一个Nuget包中发现了运行时错误（现在你知道它可以）。如果你的其他项目的同事也知道受这个bug影响的所有组件，那不是很梦幻吗？

您可以使用Nexus组件智能或类似工具无法完成Xray的其他工作 - 全公司范围的影响分析。一旦Xray连接到公司内不同项目和组织中运行的所有Artifactory实例，它就构建了一个真正的通用组件图，并且可以对公司内可能受所讨论的单个组件影响的所有组件运行影响分析。

好吧，我相信你现在已经有了这个想法。你需要你的影响分析是普遍的，你只能用JFrog Xray来实现。

为了完善整个故事，JFrog Artifactory 4.11与JFrog Xray共同发布，这两款产品紧密相互补充。 Artifactory，唯一真正的通用工件存储库，提供所有二进制工件及其随附的元数据，JFrog Xray是唯一可以连接到任意数量的外部源并真正提供通用影响分析的产品，为您提供完整的图片所有问题和漏洞都会影响整个组织中任何格式的二进制工件。

原文：https://jfrog.com/blog/it-is-time-to-trust-your-software/

本文：http://pub.intelligentx.net/it-time-trust-your-software

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

这是“跨AWS帐户架构安全性和治理”的第二部分。”系列。在这一部分中，我们将在AWS cloud上浏览事件响应规划的窄巷;我们还将使用云托管实现有趣的自动事件响应活动。

“建立声誉需要20年的时间，而几分钟的网络事件就能毁掉它。——史蒂芬·纳波

NIST,安全事件”的发生实际上或潜在危害的保密性,完整性或可用性的信息系统或信息系统流程、商店、传送或构成违反或违反安全策略的迫在眉睫的威胁,安全程序,或可接受的使用政策”。

好吧，满嘴都是，我们化简一下。意外事件是对您的IT服务的意外降级。

在本部分中，我们将介绍您轻松应对安全漏洞的过程、AWS服务和策略。

有很多事件响应框架，它们详细地解释了您需要实现哪些内容，以便围绕流程实现有效的事件响应团队、剧本和自动化。

让我们从讨论事件响应阶段和AWS上的攻击面开始，然后尝试招募AWS Lambda到我们的事件响应团队中，在出现问题时提供帮助;我希望我们能负担得起Lambda的薪水:)

云中的事件响应阶段(NIST)

参考文献:NIST SP 800-53，修订版4

当涉及到对安全事件的响应时，与传统数据中心相比，云中的阶段并没有发生太大的变化，但是技术实现确实发生了巨大的变化，变得更好。让我们来探索这些阶段。

高效运行手册的七个事件响应阶段

1-准备阶段:

准备阶段

你猜对了，这个阶段就是准备阶段。我们需要做好准备，完成威胁建模，缩小攻击面，并采取任何必要的主动措施，从一开始就防止安全事件的发生。我们需要启用日志记录、监控、加密和限制爆炸半径。

采取积极措施做好准备:

1. 数据分类:识别数据敏感性级别、所有者和安全需求。
2. 所有权:所有资源都应该被标记，很高兴知道谁拥有一组受损的资源，至少所有者可以提供关于资源或配置中数据存储的敏感性级别的信息，这可能会导致折衷。提示:我们应该始终标记我们的资源!
3. 风险管理:识别威胁、风险和漏洞，确定您的风险偏好，然后根据您愿意容忍的风险级别管理您的风险和漏洞。
4. 弹性:架构师高度可用，容错基础设施。提示:使用AWS well architect工具并阅读well-architect白皮书。
5. 最小特权原则:使用AWS IAM和资源策略，只授予需要访问数据或操作环境的人有限的访问权限。
6. 测试(比赛日):测试您的事件响应计划。我相信在真正的安全事件发生之前，您会发现可以解决的缺点。

准备好一切:

没有理由不在所有帐户和区域上启用CloudTrail和其他日志服务。你将没有法医学来告诉你的资产发生了什么事，在事件的违反。

当您启用CloudTrail时，您接触的任何AWS服务都将在CloudTrail中记录对它们采取的操作，CloudTrail还可以与CloudWatch和日志集成，并将存储在一个集中的s3存储桶中。

CloudWatch事件可以被AWS Lambda用于实时修复，也可以被SNS用于实时通知。无论您使用的是SDK、控制台还是AWS CLI，所有操作都将被记录下来。你对AWS资源采取的任何行动都可能被用来对付你:)我知道这是坏的，我保证不再这样做。最后一点，请不要忘记启用ClouTrail日志文件验证。

CloudTrail工作流

通过限制爆炸半径来准备

爆炸半径

使用AWS组织和VPC、子网NACLs、EC2安全组等，根据业务单元、产品等隔离AWS帐户和资源，限制爆炸半径。

这种方法与深度防御等原则相结合，可以提供更大的保护，抵御威胁。

准备加密一切:

数据隐私专家会告诉你，“对待你的数据就像每个人都在看它一样，因为他们可能一直在看。”

加密是使用加密算法和加密密钥屏蔽数据的过程。如果使用了健壮的加密算法，如果坏人能够在传输过程中拦截数据或在静止时访问数据，他们就无法将数据读取为明文。

AWS提供了加密数据的选项，包括但不限于KMS。

AWS KMS和其他直接加密数据的服务使用一种称为信封加密的方法来提供性能和安全性之间的平衡。见下文:

服务器端加密

2-鉴定阶段:

识别阶段

折衷的指标有很多，比如AWS GuardDuty high severity alert，它说明您的EC2实例正在向与比特币挖掘相关的域发出出站调用，或者最好不是正在下降的生产服务。

识别阶段是我们发现事件正在实现的阶段。实现标识阶段的最佳方法是确保为所有您认为重要的安全发现(如AWS root帐户登录)设置警报。

以下是当你意识到某个事件已经发生时，你需要回答的一些问题:

1. 原因:了解攻击背后的意图可以帮助您确定产品和资源的范围和攻击的性质。
2. 内容:识别丢失的数据和损坏的资源，以及您需要清理、隔离和减轻哪些工作和资源。
3. 如何:找出他们利用的弱点，以获得未经授权的访问您的系统。
4. When:确保你记录下所有的事件
5. 谁:谁是坏演员。

在识别安全问题时，依赖于人类是一种不好的做法，因为我们在关联异常值和异常方面不如机器。使用AWS服务的自动事件响应是解决之道，您还可以通过应用机器学习和安全分析来解决这一问题。

3-围堵阶段:

控制阶段:

你已经经历了所有繁琐的识别步骤现在怎么办?这一阶段涉及的是消除安全威胁。

我们应该有一个Cloudformation或Terraform模板，它拥有构建用于取证调查的隔离环境所需的所有资源。我们需要采取的一些行动是:

1. 将您的AWS帐户移动到一个组织单元，该组织单元具有非常严格的AWS组织服务控制策略。
2. 拒绝访问s3桶
3. 限制安全小组，所以他们只允许指定的港口进行调查。
4. 全球拒绝* IAM政策应附加到所有实体，不涉及此阶段

应该部署自动化来停止受损害的资源、快照卷、禁用KMS加密密钥和更改的Route53记录集。

4-调查阶段:

调查阶段

调查阶段包括包含阶段之后的活动，包括但不限于取证和一般日志分析。调查阶段应披露事件发生的时间，以及不法分子为进入我们的系统采取了什么行动，这次入侵的副作用是什么，以及根据目前收集到的证据，这次入侵再次发生的可能性。如前所述，调查应在一个孤立的环境中进行。

你可以使用的服务:

1. VPC Flow Logs.
2. CloudTrail.
3. CloudWatch.
4. Athena for analyzing logs.

5-根除阶段:

根除阶段

这个阶段涉及到对受影响资源的仔细处理。如果有必要，我们会删除资源，并将健康和清洁资源转移到更安全的环境中。

加密的数据应该是无法被攻击者破译的，这意味着我们可以执行以下一些操作:

1. 禁用或删除KMS密钥
2. 从EBS卷中删除溢出的文件，并将干净的数据转移到新的加密的EBS卷
3. 删除s3服务器端加密的加密s3对象
4. 删除使用KMS或客户密钥加密的s3对象和s3对象的加密CMKs

如果数据没有加密，您唯一的选择是将存储资源从最后一个已知的良好状态恢复到您可以保证它没有被篡改的状态。

6-恢复阶段:

经济复苏阶段

现在我们已经做了一切来确定发生了什么，并且已经尽我们最大的能力进行了数据清理，我们需要将操作恢复到正常状态。

我们可以在这个舞台上表演的一些动作:

1. 恢复资源。
2. 恢复网络连接。
3. 使用新的和改进的访问控制策略和加密密钥。
4. 监控你的环境是否有任何不寻常的行为。

7-后续阶段:

后续阶段

后续阶段，也就是事后分析，是关于吸取的教训和需要采取的后续行动，以避免发生新的安全事件，并改进我们的事件运行记录。

自动化

AWS警卫自动化工作流程

如果你已经做到了，谢谢你!让我们动手看看一个用例，这个用例应该能够使我们到目前为止所讨论的思想深入人心。最后，如果你不付诸行动，只有一个可靠的计划是不够的。

为此，我们需要:

1. 孤立的AWS环境。请不要使用您的生产环境，因为此活动可能会占用资源。
2. 在孤立的AWS环境中，必须启用AWS GuardDuty，以便生成将由CloudWatch事件和AWS Lambda使用的结果。
3.  EC2实例(t2.micro)，为了生成一些安全结果，我们可以打开所有端口或类似的东西。
4. 我们将设置Cloud保管器，以便它部署此活动所需的无服务器组件。

注意:您需要将云托管部署到您启用GuardDuty的同一区域。

当我们的云托管策略检测到AWS GuardDuty生成的中/高严重性发现时，它应该对范围内的资源采取行动，这个解决方案非常简单。

托管方将对受影响的EC2实例采取什么行动:

1. 删除附加到EC2实例的IAM角色。
2. 停止EC2实例。
3. 取证调查卷快照。

让我们从安装云托管开始，并编写我们的第一个策略。在你的终端机运行以下命令安装抄送:

安装云托管

然后，创建一个名为custodian.yml，内容如下:

你的第一个政策

这个策略所做的就是，停止任何具有标记键“托管人”的EC2实例。

执行您的第一个策略:

我假设你使用概要文件访问通过CLI AWS帐户,如果不是你可以查找如何验证使用API密钥托管,或托管人承担角色的命令,如果你正在使用一个配置文件,下面是如何使用AWS CLI概要文件在本地运行政策,意味着这一政策不会运行基于CloudTrail所产生的一个事件或一个预定义的时间表。

如果成功，您应该在命令行上看到类似于下面的输出:

现在您是一个云托管专家，可以在AWS上实现安全自动化，让我们拿出真正的策略!

真正的交易

 

遵循您的第一份保单提供的步骤;编写策略，保存策略，并将其部署到一个独立的AWS环境中，然后观察其神奇之处。如果GuardDuty生成结果，策略Lambda将使用生成的事件，并通过执行我们在上面解释的操作进行响应。

好吧!这就是事件响应部分!

原文：https://itnext.io/architecting-security-governance-across-your-aws-accounts-part-2-incident-response-on-aws-44b1ee01f1ee

本文：

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

基本CIS控件

1. 硬件资产的库存和控制
2. 软件资产的库存和控制
3. 持续漏洞管理
4. 管理特权的使用
5. 移动设备、笔记本电脑、工作站和服务器上的硬件和软件的安全配置
6. 审计日志的维护、监控和分析

基础CIS控制

1. 电子邮件和Web浏览器保护
2. 恶意软件防御
3. 网络端口、协议和服务的限制和控制
4. 数据恢复功能
5. 网络设备（如防火墙、路由器和交换机）的安全配置
6. 边界防御
7. 数据保护
8. 基于知情需要的受控访问
9. 无线接入控制
10. 账户监控

组织CIS控制

1. 实施安全意识和培训计划
2. 应用软件安全
3. 事件响应和管理
4. 渗透测试和红队演习

 

原文：https://www.cisecurity.org/controls/cis-controls-list/

本文：

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】

组织正在利用许多开源产品，包括代码库，操作系统，软件和各种用例的应用程序。开源在灵活性，成本效益和速度方面可能是有利的，但是它提出了一些独特的安全挑战。高达96％的商业应用程序可能包含开源组件，因此面临的挑战是确保您的软件安全。

什么是开源漏洞？

开源中的漏洞就像是专有产品中出现的漏洞。这些是代码作者意外编写的代码，黑客可以从中受益，或者允许攻击者以代码作者未规划的方式进行资本化的功能。在某些情况下，这可能导致诸如拒绝服务（DoS）和使服务脱机等问题，而在严重违规时，黑客可以获得对组织系统的远程访问。

但是，专有和开源之间的相似之处在此结束。虽然内部代码是由一组坚持组织集中指导的开发人员编写的，但开源是在编写，修复和保持项目运动的社区成员之间分配的。

这种集中式与分布式系统通常被称为大教堂和市集。在集中式系统中，有一个独特的组织，它有一个处理修复和新增功能的标准系统。组织可能会发现开源代码更难以处理，因为它遵循一套不同的，通常更为模糊的规则。

在这种非结构化环境中工作对于组织来说可能很难处理，并且黑客通常会利用这种缺乏集中管理的能力。很多时候，开发人员将从站点上的存储库中获取开源代码，并且无法查看该组件是否具有任何已知漏洞。更可怕的是，没有多少组织建立了跟踪其产品或库存中的开源的解决方案。

Equifax Breach

新发布的2018年OSSRA报告研究了来自500多个组织的1,000多个商业代码库的审计结果。扫描确定的中心数据点是，平均而言，发现漏洞需要更长的时间。平均而言，审计中发现的漏洞在六年前与2017年记录的四年相比有所揭示。这些调查结果表明，负责补救的人可能需要更长的时间来重新调解，或者没有重新调解所有。它还表明这些人正在让开源漏洞在他们的代码库中积累。

一个例子是导致Equifax漏洞的Apache Struts漏洞。这一漏洞影响了超过1.48亿美国客户，接近7,00,000英国居民和19,000多名加拿大消费者的数据。 2017年3月，Struts漏洞被公布，并发布了一个补丁。 2017年9月，由未修补的Struts版本推动的Equifax漏洞被公布。随后的宣传将使参与应用程序安全的任何人都难以忽略修补任何易受攻击的Struts版本的需要。

然而，似乎组织没有被提示采取行动，并且Equifax新闻几乎没有影响。据发现，8％的审计代码库包含Apache Struts，其中33％仍有Struts漏洞导致Equifax漏洞。

4开源安全风险和漏洞需要注意

1.攻击的公共性质

在开源项目中，代码可供任何人使用。这有其优势，因为开源社区中的人可以标记他们在代码中识别的潜在漏洞，这使得开源团队领导者有时间在公开发布漏洞信息之前修复问题。但是，所有漏洞都会及时成为国家漏洞数据库（NVD）的公共信息。黑客可以访问这些信息，并追踪那些对依赖于具有漏洞的开源项目的应用程序进行修补的速度慢的组织。

2.潜在的侵权风险

开源组件可能会产生知识产权侵权风险，因为这些项目没有标准的商业控制。因此，专有代码可以进入开源项目。

3.运营问题

使用开源组件的企业面临的一个关键风险领域是组织的运营效率低下。从操作的角度来看，严重关注的是组织未能跟踪开源组件并更新这些组件，与新版本保持一致。

4.开发人员的医疗事故

开发人员的不法行为，包括从开源库复制和粘贴代码。复制和粘贴是有问题的，因为开发人员在复制时会复制项目代码中可能存在的任何漏洞。此外，一旦开发人员将代码片段添加到组织的代码库中，就无法更新或跟踪代码片段。这使得组织的应用程序容易出现将来可能发生的漏洞。可能发生的另一个不法行为是通过电子邮件手动转移开源组件。

结论

未来一年，开源安全可能会变得更加紧迫。你问为什么？随着开放在Web应用程序开发中变得越来越普遍，它将成为攻击者更大，更具吸引力的目标。攻击者可能会找到一个开源库或组件的漏洞，并且可能同时影响多个应用程序。由于这些库和组件是开放的，攻击者可以更容易地找到这些漏洞。

那么我们从这一切中得到什么呢？在2019年保持最新的开源安全风险和漏洞是值得的，并且您解决这些潜在风险的速度越快，您的组织可能承受的损害就越小。

 

原文：https://blog.bitsrc.io/open-source-security-risks-and-vulnerabilities-to-know-in-2019-8354058f6ad3

本文:http://pub.intelligentx.net/open-source-security-risks-and-vulnerabilities-know-2019

讨论: 加入知识星球【首席架构师圈】

Black Duck Software创建产品以保护和管理应用程序和容器中的开源，消除与开源安全漏洞和许可证合规性相关的痛苦。他们在2016年进行的第十届开源调查年度未来，提供了证明我们已经知道的许多关于开源的事情的数字。

首先，“每个人”都在使用开源，或者作为调查结果状态......

“无处不在的全球开源软件开发是常规。”

该调查还显示，使用开源的主要驱动力是免于供应商锁定。这也是JFrog的主要驱动因素之一，也是我们创造的一切都是通用的原因：

Artifactory，通用工件存储库管理器

Bintray，通用软件分发平台，

Xray，用于通用工件分析，

Mission Control，通用仓库管理。

大多数组织盲目使用开源

但调查还显示，大多数组织缺乏对开源软件的可见性和控制力。开源通过许多已知和未知的来源（包括开发人员，供应商和外部承包商）在组织的应用程序代码中输入和传播。 Black Duck On-Demand服务进行的开源审计发现，平均而言，公司使用的开源数量是之前所知的两倍，而67％的应用程序包含已知的开源漏洞。

你需要一个过程才能看到光明

为了解除开源使用的“迷雾”，组织需要一些自动化且可重复的过程，在大多数情况下，这些过程不存在。这些包括：

• 在进入代码流时检测和批准新的开源
• 盘点并跟踪其代码库和Docker容器中开源软件的使用情况
• 识别或监控与他们使用的开源软件相关的已知开源漏洞（如Heartbleed，ShellShock等）
• 随着时间的推移，协调或跟踪风险补救工作
• 评估使用具有不兼容许可条款的开源软件可能产生的诉讼和知识产权（IP）风险。
• 审核和实施开源安全策略和许可证合规性。

所有这些过程现在都更容易实现，Black Duck Hub集成到JFrog Xray和Black Duck的二进制存储库集成插件中，用于JFrog Artifactory

Xray通过Black Duck Hub点亮前进的道路

Xray的深度递归扫描会将Artifactory存储库中的包和深入到最深层次，以识别您正在使用的所有开源依赖项。 Xray通过其漏洞的全局数据库交叉引用这些依赖关系，这些漏洞汇集自不同的来源。

Black Duck Hub在整个软件开发生命周期（SDLC）中为组织提供开源风险管理 - 包括IDE，SCM，构建，CI，二进制存储库和Docker容器。

 

通过Xray与Black Duck Hub的集成，您可以大大扩展漏洞数据库，包括Black Duck全面的KnowledgeBase（™），包括2,000,000多个开源项目和150,000个漏洞。 您需要做的就是在Xray的集成模块中输入您的Black Duck凭证。

Black Duck与JFrog Artifactory和Xray的集成允许组织在SDLC中的不同级别管理构建输出扫描和存储库检查。在使用Artifactory Pro的存储库级别或在Xray的正式SDLC过程之外。例如，构建输出扫描程序插件可以在开发过程中更早地监视构建并提供风险信息，例如，当需要监视开发人员构建时。当企业拥有多个不同的SDLC工具集并且无法在所有工具集中进行统一集成时，存储库检查器插件提供了监视工件的功能。将Black Duck Hub集成到Xray中也可以通过Xray提供类似的功能。 Xray根据您定义的Watches扫描存储库中的构建和工件，使用其全局数据库与Black Duck KnowledgeBase交叉引用这些工件以识别问题和漏洞，然后它可以生成相应的警报以进行补救。

 

将JFrog Xray和JFrog Artifactory的强大功能与Black Duck Hub相结合，使组织能够消除开源安全漏洞，满足许可证合规性义务并限制操作风险。

识别组件和开源安全风险

Xray会自动跟踪Artifactory存储库中组件和Docker镜像使用的开源。它将这些组件映射到其全局数据库和Black Duck的KnowledgeBase中报告的已知开源安全漏洞的组件，并监视许可证和组件质量风险。

自动化补救和政策执行

使用Watches中定义的许可过滤器轻松实施开源许可策略，并通过在构建中检测到漏洞的早期干预自动CI过程来简化实施。

持续监控新漏洞的应用程序

Xray的全球数据库和Black Duck的KnowledgeBase都聚合了多个漏洞数据源，因此您可以获得生产应用中检测到的新漏洞的当天警报。通知可以通过Xray UI，通过电子邮件或调用webhooks发布

随着Xray和Black Duck守卫你的大门，你对开源软件的使用受到了关注。您完全了解组织使用的所有开源组件，可以在SDLC的早期检测和修复漏洞，当检测到生产系统中可能潜伏的新漏洞并使用开源时，您会立即收到通知不仅无处不在，而且也是安全的。

原文：https://jfrog.com/blog/frogs-and-ducks-your-sentinels-for-open-source-security/

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

讨论：加入知识星球【首席架构师圈】

规模，自动化和不断增长的成本越来越多地促使组织采用安全的软件开发生命周期（SDLC）方法。虽然静态代码分析和漏洞扫描等工具在提高应用程序安全性方面取得了成功，但组织已经开始认识到SDLC内安全审查早期集成的价值 - 最显着的是它降低了管理和修复成本的能力与安全相关的错误。

但是，许多用于执行此操作的方法（如OpenSAMM，BSIMM和Microsoft的SDL）采用的方法类似于低效，自上而下的瀑布式方法。这些保护SDLC的方法在业界很多都失败了，需要采用新的方法。

流行的安全SDLC方法

正如许多专家建议的那样，软件组织通常采用自上而下的方法来实施安全的SDLC方法。虽然这种方法的好处是可以确保安全软件开发过程所需的组件，但它并不能保证安全的产品。

以下是目前帮助组织在其SDLC中集成安全性的流行方法的简短列表。

1. OpenSAMM：软件保障成熟度模型（SAMM）是一个OWASP项目，用于指导SDLC中的安全性集成。所描述的12项活动分为四类：治理，建设，验证和部署。
2. BSIMM：由Cigital开发的建筑安全成熟度模型（BSIMM）由12个实践组成，分为4个领域：治理，智能，安全软件开发生命周期（S-SDLC）接触点和部署。
3. SDL：Microsoft安全开发生命周期旨在创建符合法规标准的安全软件，同时降低开发成本。微软开始推广这种方法，强调分别在2001年和2002年遵循CodeRed和Nimda蠕虫的安全编码实践的重要性。

安全SDLC方法已经为软件开发人员做出了许多承诺，特别是SDLC中早期安全集成带来的成本节约，这有助于避免代价高昂的设计缺陷并提高软件项目的长期可行性。

但是，这些方法并非没有缺点。

瀑布SDLC方法在敏捷环境中受阻

流行的方法通常将组织划分为业务单元或业务功能，并且仅在其他活动完成后才依赖于启动某些活动。这种组织结构假设业务活动以特定的线性顺序发生，这是敏捷框架难以协调的主张。

例如，Microsoft SDL定义了一种称为“建立安全和隐私要求”的做法，该做法建议尽早开发安全和隐私目标，以便最大限度地减少调度冲突，但这也会产生创建敏捷环境中通常不存在的严格时间线的效果。

在敏捷框架下，他们强调持续集成和持续部署，很少有软件开发团队创建详细记录长期计划的文档。这使得敏捷团队难以实现这种以瀑布为中心的安全SDLC。

实施成本很高

与实施SDLC相关的成本可能过高。根据OpenSAMM自己的估计，当使用下表第二列中描述的估计小时费用时，实施其12项活动中的每项活动将花费大约90,000美元。

尽管为确保整个组织的开发过程提供90,000美元看起来似乎很划算，但应该提到三个警告。

90,000美元的估算仅包括实施OpenSAMM第一级到期水平的成本，不包括第二级或第三级的成本，这无疑会大大提高最终成本。

90,000美元的估计是保守的。 OpenSAMM每年为第一个成熟度级别所需的代码审查活动分配五到九天。因此，这可能是一个非常小的组织，或者估计是不完整的，可能只考虑设置成本而不是持续的运营费用。我组织并参与了无数的代码审查，我可以证明它们是一项耗时的活动，在大多数情况下很容易超过90,000美元的估算。

最后，方法所推荐的实施活动的价值往往在这个过程中丢失，而这些活动的实施完全是因为它们作为必须满足的清单上的要求而存在才能继续前进。例如，实施漏洞扫描并不能保证甚至可以查看扫描，更不用说采取行动了。如果要从其实施中获得价值，则必须了解活动的背景及其相关指标的相互作用。

自下而上的安全SDLC

也许SDLC方法不应该从上到下，而是从下到上来处理和实施。您可以先确定目标，然后确定并采用最有效地帮助您实现这些目标的活动，而不是实施满足检查表要求的活动。

对于这种方法，有必要首先确定对您的组织成功至关重要的指标。在我看来，有两个重要指标：漏洞总数及其平均补救时间。

1. 漏洞总数：任何方法的唯一目的是帮助组织系统地，始终如一地生成更安全的代码。查找并减少代码中的漏洞数量意味着您已经创建了一个更安全的最终项目。
2. 平均修复时间：由于两个重要原因，修复后期制作中的错误比在预生产中修复它们要成本高得多。首先，存在的错误越长，攻击者就越需要利用它们。其次，随着开发人员转向不同的项目，或者在某些情况下，其他公司，组织解决安全问题的能力会降低，从而增加与修复这些问题相关的成本。

确定关键指标后，首先要实施可以帮助您尽快达到指标目标的活动。所选指标将指导您识别和实施可帮助您实现目标的活动。安全的用户故事，安全代码审查，渗透测试和环境强化只是一些可能有用的活动。

 

分析后的行动项目

在最初的活动实施后，您的重点应转向持续的投资和改进。例如，如果安全代码审查的实现揭示了过多的错误，那么投资培训以改进安全编码技术可能是有利的。或者，如果需要时间进行补救，那么投资漏洞管理系统可以帮助开发人员更好地管理漏洞并缩短补救时间。

敏捷，度量驱动的方法

当前的技术前景要求公司认真对待软件安全以获得成功，并且越来越多的人已经做到这一点，向左转并采用安全的SDLC方法。

虽然大多数组织依赖于敏捷软件开发框架（如Scrum），但许多安全的SDLC方法都是针对瀑布式方法而设计的。遗憾的是，DevOps对速度和自动化的关注意味着这些方法落后，需要大量的手动工作才能跟上快速发展的发展前景。

如果开发人员要保持领先于他们日常面临的日益增长的安全挑战，那么在当今敏捷，以开发为导向的世界中，对更轻，敏捷和度量驱动的方法的需求已成为必需。

原文：https://techbeacon.com/security/why-existing-secure-sdlc-methodologies-are-failing

本文：

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

介绍

开源软件 - 其代码可供公众查阅，通常可免费使用 - 非常棒。作为消费者，它使我们无需重新发明轮子，让我们专注于我们的核心功能并大幅提高我们的生产力。作为作者，它让我们分享我们的工作，获得社区的爱，建立声誉，并且有时对软件的工作方式产生实际影响。

因为它太神奇了，开源使用率飙升。实际上，从妈妈和流行商店到银行和政府的每个组织都依靠开源来运营他们的技术堆栈 - 以及他们的业务。工具和最佳实践已经发展到使这种消费变得越来越容易，通过单个代码或终端线来降低大量功能。

不幸的是，使用开源也存在很大的风险。我们依靠这些由陌生人编写的众包代码来运行任务关键型系统。通常情况下，我们很少或根本没有仔细检查，几乎没有意识到我们正在使用什么，完全不知道它的血统。

您使用的每个库都存在多个潜在的陷阱。该库是否存在攻击者可以利用的软件漏洞？它是否使用病毒许可证使我们的知识产权面临风险？恶意贡献者是否在良好的代码中隐藏了恶意软件？

与商业软件不同，免费开源软件（FOSS）很少提供任何担保或保证。作为开源软件的消费者，您有责任了解并减轻这些风险。

2017年9月宣布的Equifax数据泄露事件使这一风险完全成为现实。由于开源Apache Struts库存在严重漏洞，该漏洞暴露了1.43亿人的极端个人信息。 2017年3月披露了此漏洞，只有在发现漏洞后，有问题的Equifax系统才会在7月底之前修补。 Equifax完全有能力更早识别和解决这个问题，防止大规模泄漏，许多人声称不这样做是公司的疏忽。 Equifax漏洞肯定会成为保护数据和负责任地使用开源的重要性的典型代表。

书籍目的和目标受众

本书将帮助您解决易受攻击的开源库的风险，这是绊倒Equifax的原因。正如我将在本书中讨论的那样，这些易受攻击的依赖项最有可能被攻击者利用，并且您需要良好的实践和工具来大规模保护您的应用程序。

由于在开发（包括DevOps）和应用程序安全性之间共享应用程序及其库的安全责任，因此本书面向这两个部门的架构师和从业者。

考虑到这一点，接下来的几节将进一步解释本书的内容和范围。其余主题有望在未来更广泛的书中介绍。

工具与库

开源项目有多种形式和形式。对它们进行分类的一种有些过于简单的方法是将它们分成工具和库。

工具是独立的实体，无需编写自己的应用程序即可使用或运行。工具可以大小，从小型Linux实用程序（如cat和cURL）到完整和复杂的平台（如CloudFoundry或Hadoop）。

库具有旨在在应用程序内部使用的功能。示例包括Node.js的Express Web服务器，Java的OkHttp HTTP客户端或本机OpenSSL TLS库。与项目一样，库的大小，复杂性和广度也有很大差异。

本书专注于库。虽然一些开源项目可以作为工具和库使用，但本书仅考虑库方面。

应用程序与操作系统依赖关系

开源软件（OSS）项目可以直接从他们的网站或GitHub存储库下载，但主要通过注册表来使用，注册表包含打包和版本化的项目快照。

一类注册表包含操作系统依赖性。例如，Debian和Ubuntu系统使用apt注册表来下载实用程序，Fedora和RedHat用户利用yum，许多Mac用户使用HomeBrew在他们的机器上安装工具。这些通常被称为服务器依赖项，更新它们通常称为“修补服务器”。

另一种类型的注册表包含主要用于应用程序的软件库。这些注册表主要是语言特定的 - 例如，pip包含Python库，npm包含Node.js和前端JavaScript代码，Maven服务于Java和相邻社区。

保护服务器依赖性主要归结为通过经常运行诸如apt-get upgrade之类的命令来更新依赖关系。虽然现实问题从未如此简单，但保护服务器依赖性比保护应用程序依赖性要好得多。因此，虽然它的大部分逻辑适用于所有类型的库，但本书仅专注于应用程序依赖性。

要了解有关保护服务器（包括其依赖关系）的更多信息，请查看Lee Brotherston和Amanda Berlin的防御安全手册（O'Reilly，2017）。

已知的漏洞与其他风险

消费开源库存在多种类型的风险，包括对库许可的法律问题，陈旧或管理不善的项目中的可靠性问题，以及具有恶意或妥协贡献者的库。

但是，在我看来，最直接的安全风险在于开源库中的已知漏洞。正如我将在下一章解释的那样，这些已知的漏洞是攻击者利用的最简单的途径，并且大多数组织都很难理解和处理。

本书侧重于不断发现，修复和预防开源库中的已知漏洞。其目的是帮助您了解这种风险以及您需要采取的措施。

 

比较工具

有助于解决易受攻击库的工具通常称为软件组合分析（SCA）工具。这个首字母缩略词并不代表整个风险范围（特别是，它没有捕获分析后的补救措施），但由于这是分析师使用的术语，我将在本书中使用它。

由于工具环境正在迅速发展，我将主要避免引用特定工具的功能，除非工具与相关功能紧密相关。在命名工具时，我将专注于免费或免费增值工具，允许您在使用前对其进行审核。第6章从更高层次的角度对评估工具进行了评估，从而在选择解决方案时提供了更加明确的视角，了解哪些方面最重要。

书大纲

既然您已经理解了本书的主题，那么让我们快速回顾一下这个流程：

• 开源软件包中的已知漏洞定义并讨论了已知的漏洞以及为什么跟上它们的重要性。
• 第2章到第5章解释了解决开源库中已知漏洞的四个逻辑步骤：查找漏洞，修复漏洞，防止添加新的易受攻击的库，以及响应新披露的漏洞。
• 如前所述，第6章从解释SCA工具之间的差异，突出我认为最重要的属性重点。
• 最后，第7章总结了我们所学到的内容，并简要介绍了未详细介绍的主题。

本书假定您已熟悉使用开源注册表（如npm，Maven或RubyGems）的基础知识。如果你不是，那么在开始阅读本书之前，有必要阅读一两个这样的生态系统，以充分利用它。

开源软件包中的已知漏洞

“已知漏洞”听起来像是一个非常不言自明的术语。顾名思义，这是一个公开报道的安全漏洞。然而，由于这些缺陷的数量和重要性，围绕这种风险形成了一个完整的生态系统，包括广泛使用的标准以及商业和政府参与者。

本章试图更好地定义已知漏洞的含义，并解释在建立解决方法时需要理解的关键行业术语。

 

可重用产品中的漏洞

已知漏洞仅适用于具有多个部署的可重用产品，也称为第三方组件。这些产品可以是软件或硬件，免费或商业，但它们总是部署多个实例。如果一个漏洞仅存在于一个系统中，则对其进行清点并让其他人了解它（除了攻击者之外）是没有价值的。

因此，当我们谈到已知的漏洞时，我们只提到可重用的产品。由于大多数已知漏洞处理商业产品（开源已知漏洞的世界有点新生），负责产品的实体通常被称为供应商。在本书中，因为它涉及开源软件包而不是商业软件，所以我将该实体称为软件包的所有者或作者。

漏洞数据库

在最基本的层面上，一旦漏洞被公开发布在一个相当容易找到的位置，就会被认为是漏洞。一旦漏洞被广泛披露，维护者就可以了解它并保护他们的应用程序，但攻击者 - 包括自动化或不太复杂的攻击者 - 也有机会轻松找到并利用它。

也就是说，互联网是一个很大的地方，并拥有大量的软件。新的漏洞会定期披露，有时甚至会在一天内泄漏数十个漏洞。为了使防御者能够跟上，这些漏洞需要存储在一个易于查找的中心位置。为此目的，已经创建了许多结构化数据库，包括商业和开放数据库，以编译这些漏洞和有关它们的信息，允许个人和工具查询测试他们的系统以防止他们持有的漏洞。

此外，有几个数据库专注于开源软件包中的漏洞，例如Snyk的DB，Node Security Project，Rubysec和Victims DB。但是，在深入研究之前，让我们回顾一下已知漏洞数据库世界的更广泛和更标准化的基础：CVE，CWE，CPE和CVSS。

技巧
已知的漏洞与零日
漏洞也可以为某些方所知，但不能公开发布。例如，糟糕的演员经常在流行的库中发现漏洞并在黑市上出售（通常称为“黑暗网络”）。这些漏洞通常被称为零日漏洞，这意味着自披露以来零日已过去。

 

Common Vulnerabilities and Exposures 

常见漏洞与暴露（CVE）

最常见的漏洞信息是常见漏洞和披露（CVE）。 CVE是一个免费的漏洞词典，由美国政府创建和赞助，由MITRE非营利组织维护。在美国政府的支持下，CVE在全球范围内被用作分类系统。

当披露新的漏洞时，可以向MITRE（或其他CVE编号机构之一）报告，该漏洞可以确认问题是真实的并为其分配CVE编号。从那时起，CVE编号可以用作此缺陷的跨系统标识符，从而可以轻松地在安全工具之间进行关联。实际上，即使在为给定漏洞维护自己的ID时，大多数漏洞数据库也会保留并共享CVE。

值得注意的是，CVE本身不是一个数据库，而是一个ID字典。为了帮助自动化系统访问所有CVE，美国政府还支持国家漏洞数据库（NVD）。 NVD是一个数据库，通过标准化的安全内容自动化协议（SCAP）公开漏洞信息。

CVE是一个非常混乱的漏洞列表，因为它适用于各种各样的系统。为了使其与消费者保持一致和可用，MITRE围绕内容和分类制定了各种指导方针和政策。至少对于OSS库世界而言，三个最值得注意的是CPE，CWE和CVSS。

 

Common Platform Enumeration

通用平台枚举（CPE）

除了它们所代表的大量漏洞之外，CVE还表明了极其不同的产品存在缺陷。为了使您更容易发现给定的CVE是否适用于您的产品，NVD可以使用一个或多个Common Product Enumeration（CPE）字段修改每个CVE。 CPE是一种相对宽松的数据结构，它描述了此CVE适用的产品名称和版本范围（以及可能还有其他数据）。请注意，CPE不是CVE的一部分，而是NVD的一部分。这意味着一个已知的漏洞不会有产品信息，除非它进入NVD，这并不总是会发生（稍后会详细介绍）。

CPE是一个强大的想法，可以实现漏洞的自动发现。但是，以通用方式定义产品非常困难，并且缺乏许多CVE的内容质量。因此，在实践中，CPE通常是不准确的，部分的，或者根本不是自动化友好的，足以实用。严重依赖CPE的产品，如OWASP依赖检查器，需要使用模糊逻辑来理解CPE，并在缺少内容时失败，从而导致大量误报和漏报。

为了解决这一差距，OSS库空间中的大多数商业漏洞扫描程序和数据库仅使用CPE作为起点，但是将CVE的映射保持为相关产品。

 

Common Weakness Enumeration

常见弱点枚举（CWE）

虽然每个漏洞都是它自己独特的雪花，但在一天结束时，大多数漏洞都属于更有限的漏洞类型列表。 MITER将这些类型分类为Common Weakness Enumeration（CWE）列表，并提供有关每种弱点类型的信息。虽然CWE项目可以非常具体（例如，CWE-608表示在Struts的ActionForm类中使用非私有字段），但其更广泛的类别被更广泛地使用。例如，CWE-285描述了不正当授权，而CWE-20代表了不正确输入验证的许多变体。 CWE也是分层的，允许更广泛的范围CWE包含多个更窄范围的CWE。

较少数量的CWE使得为每个项目提供丰富的详细信息和补救建议更为可行，或者根据漏洞类型定义策略。每个CVE都使用一个或多个CWE进行分类，帮助其消费者专注于他们最感兴趣的CWE，并且无需为每个相关的CVE重复CWE级信息。

常见漏洞评分系统（CVSS）
漏洞定期披露，并以相当惊人的速度披露，但并非所有漏洞都需要放弃所有内容并采取行动。例如，向攻击者泄露信息并不像允许他们远程执行服务器上的命令那么糟糕。此外，如果可以通过简单的HTTP请求利用漏洞，则修复比要求攻击者修改后端文件的漏洞更紧急。

也就是说，对漏洞进行分类并不容易，因为有很多参数，很难判断每个参数的重量。访问DB的程度是否比远程命令执行更严重？如果此执行是作为低权限用户完成的，那么与以root身份执行的漏洞利用相比，应该降低其严重性分数的程度是多少？如何判断需要长序列请求的漏洞，但是可以使用从Web下载的工具来完成？

除此之外，问题的严重性还取决于它所在的系统。例如，银行网站上的信息泄露漏洞比静态新闻网站上的漏洞更严重，需要物理机访问的漏洞对设备而言比对云服务更重要。

为了帮助解决所有这些问题，MITRE创建了一个通用漏洞评分系统（CVSS）。该系统目前处于第三次迭代，因此您可能会看到对CVSSv3的引用，这是此处讨论的版本。 CVSSv3将得分分为三个不同的分数，每个分数分成几个较小的分数：

基础（Base）

有关漏洞的不可变细节，包括攻击媒介，利用复杂性以及它可能产生的影响。

暂时的 （Temporal）

时间敏感信息，例如漏洞利用工具的成熟度或易于修复。

环境的 （Environmental）

易受攻击的系统的上下文信息，例如它的敏感程度或可访问性。

图1-1显示了样本漏洞的CVSSv3评分的变量和计算（计算是使用FIRST.org的在线工具生成的）。

虽然所有三个分数都很重要，但公共数据库通常仅显示基于Base组件的CVSS分数。时间分数的不断变化使维护成本高昂，根据定义，环境分数是每个漏洞实例特有的。尽管如此，这些数据库的用户仍然可以填写这两个分数，根据需要调整权重，并获得最终分数。

 

CVE和NVD之外的已知漏洞

拥有CVE很有帮助，但这也很麻烦。收到CVE号码要求作者或记者首先了解它，然后进行一定量的文书工作和备案工作。最后，CVE需要得到特定CVE编号机构（CNA）的批准，这需要时间。因此，尽管CVE是某些类型系统（例如，网络设备）中的漏洞的标准，但它们在其他世界中并不常见。

当涉及OSS包中的已知漏洞时，CVE的形状尤其糟糕。截至2017年10月，基于Snyk的数据库，只有67％的Ruby gem漏洞分配了CVE，而11％的npm软件包漏洞只有这样的ID。

造成这种差距的一个原因是，开发人员（而非安全研究人员）报告了许多库漏洞，并将其作为漏洞进行通信。这些问题通常很快得到解决，但一旦修复，作者和记者很少会通过CVE流程。即使他们这样做，CVE的任务也远远落后，而攻击者可能正在利用现在已知的漏洞。

在CVE的分配和将其发布到NVD之间又发生了另一个滞后，提供了更多的细节，也许还有CPE。当新漏洞在经过负责任的披露过程中保留一定数量时，预计会出现此类延迟，但这种延迟通常在漏洞已知后发生。

在查看易受攻击的Maven软件包时，这种滞后非常明显：37％的具有CVE的Maven软件包漏洞在被添加到NVD之前是公开的，其中20％在被添加之前已经公开了40周或更长时间。

NVD上没有的已知漏洞仍然存在，但难以检测。库漏洞可能要么没有CVE，要么没有在NVD上列出（因此没有咨询或CPE），或者质量差的CPE。其中每一项都会阻止它们通过专门依赖这些公共数据源的工具进行检测，尤其是OWASP依赖检查器。

技巧
在没有CVE的情况下使用CWE和CVSS
虽然CVE，CWE和CVSS都是MITRE标准，但它们可以彼此独立使用。 CWE和CVSS通常用于没有CVE的漏洞，即使没有行业范围的ID，也提供标准化的分类和严重性。

未知与已知漏洞

每个已知的漏洞在某些时候都是未知的。这似乎是显而易见的，但这是一个重要的理解点 - 一个新的已知漏洞不是一个新的漏洞，而是一个新披露的漏洞。在发现和报告之前，漏洞本身已存在。然而，虽然披露漏洞并不能创建它，但它确实改变了它应该如何处理，以及它应该如何紧急修复。

对于攻击者来说，查找和利用未知漏洞很难。存在无穷无尽的潜在攻击变体，需要在避免检测的同时快速调用。确定攻击是否成功并不总是容易的，这意味着提交的有效载荷可能已经成功通过，而攻击者仍然不是更聪明。

一旦泄露漏洞，利用它就变得容易多了。攻击者可以详细了解漏洞及其调用方式，只需要识别正在运行的软件（称为指纹识别的过程）并获取恶意负载。通过自动漏洞利用工具可以更轻松地完成此过程，该工具可以列举已知的漏洞及其漏洞。这种自动化还降低了进入障碍，允许不太复杂的攻击者尝试渗透。

已知的漏洞在很大程度上被认为是野外成功攻击的主要原因。引用两个样本来源，Verizon表示“大多数攻击都利用已知的漏洞，这些漏洞从未修补过，尽管有几个月，甚至几年可用的补丁”，赛门铁克预测“到2020年，99％的漏洞利用将继续是已知的漏洞由安全和IT专业人员至少一年“。在应用方面，Gartner和RedMonk等分析公司一再声明处理开源库中已知漏洞的重要性。

因此，应该紧急处理已知的漏洞。即使它是相同的漏洞，它的披露使攻击者更有可能使用它来访问您的系统。漏洞的披露引发了一场竞赛，看看一名防守者是否可以在攻击者通过它之前封堵洞。图1-2显示了攻击者对前面提到的严重Struts2漏洞披露的反应，在几天内从零攻击逐渐增加到每天观察到的超过一千次攻击。

好消息是已知漏洞比未知漏洞更容易防御。通常，已知的漏洞也具有已知的解决方案，通常以软件升级或补丁的形式。即使不存在软件解决方案，您至少应该更好地了解如何检测攻击并防止它们通过安全控制。正如我将在第5章中讨论的那样，重要的是投资系统，让您快速了解此类披露，并比不良行为者更快地采取行动。

负责任的披露

到目前为止，我谈到了披露作为一个单一的时间点，实际上它不应该是二元的。披露漏洞的正确方式，被称为负责任的披露，涉及几个步骤，旨在让维权者在上述竞选中领先一步。

理解负责任的披露对于开源消费者来说并不重要，但对于开源作者来说这一点非常重要。要了解有关负责任披露的更多信息，您可以阅读Tim Kadlec的优秀博客文章，或者查看Snyk负责任的披露模板。

摘要

已知的漏洞并不像最初出现的那么简单。已知的内容的定义和漏洞元数据的管理很难做得很好。

CVE和NVD适用于策划商业产品中的漏洞，但不能扩展到开源项目的卷和所有权模型。随着时间的推移，这些标准可能会发展以满足这种需求，但是现在它们的覆盖范围和细节水平还不足以保护您的库。

原文：https://www.oreilly.com/ideas/what-defines-a-known-open-source-vulnerability

本文:http://pub.intelligentx.net/node/422

讨论： 加入知识星球【首席架构师圈】

借助DevOps实践，企业IT更快，更灵活。自动构建，测试和发布形式的自动化在实现这些优势方面发挥着重要作用，并为持续集成/持续部署（CI / CD）管道奠定了基础。但是，是否可以在不降低流程速度的情况下将安全性集成到混合中？ IT团队可以将安全性集成到DevOps管道中的一种方法是确保发布的代码从一开始就是安全的。将安全性作为一流公民集成到DevOps流程中的概念称为DevSecOps，是安全敏感型企业的最佳实践。

Cloud Academy最近发布了一套新的DevOps实验室，重点介绍了CI / CD管道自动化的一些最佳实践。在这篇文章中，我将向您展示如何在CI / CD管道中使用静态分析来提高代码质量，从而减少现在和将来的问题。

什么是静态分析？

静态分析是一种在推送到生产之前分析缺陷，错误或安全问题的代码的方法。静态分析工具通常被称为“linters”，可以从代码中删除不必要的毛茸茸，并执行一些自动检查以提高代码质量。静态分析工具可以检查：

• 代码风格约定和标准不一致。它可以像执行一致的缩进和变量名一样简单，也可以像强制执行MISRA或CERT安全编码标准那样复杂
• 资源泄漏，例如无法释放已分配的内存，最终可能导致程序崩溃或无法关闭文件
• 应用程序编程接口（API）的使用不正确
• 常见的安全漏洞，例如Open Web Application Security Project（OWASP）或Common Weakness Enumeration（CWE）所识别的漏洞

有哪些静态分析工具？

可用的静态分析工具可以根据它们支持的功能进行分类，包括：

1. 编程语言：工具可能支持单语言或多语言。如果你的代码库涵盖多种语言，像Coverity这样支持14种语言（包括JavaScript，.NET，Java和Python）的单一工具可能是发现跨语言错误的最全面的选择。
2. 实时工具：瞬时分析工具非常适合在编写开发环境时检查代码。在这里，权衡是对更彻底，耗时的检查的速度。其中许多是开源的，可以更容易地采用和定制。
3. 深度分析工具：另一方面，深度分析工具可能需要更长的时间，并且可能会识别实时工具可能遗漏的问题。该领域的企业级工具通常需要很高的许可费用，并且它们可能会带来更多的问题，而不是您要解决的带宽问题。其中许多工具可能配置为仅报告最重要的问题。
4. 编译器：虽然不是专用的静态分析工具，但编译器也可用于提高代码质量。您可以使用配置标志来调整它们执行的检查数。

在CI / CD中集成静态分析

在使用静态分析工具的众多好处中，对组织最有益的是能够在错误发布之前发现错误（以及修复成本较低的时候）。在CI / CD的DevOps实践中，静态分析工具提供了额外的好处。

在开发过程中，需要花费很长时间才能运行的工具会被忽略。即使静态分析并不总是一个漫长的过程，它仍然不是开发人员时间的最佳用途。在CI / CD中集成分析工具可确保一致且自动地使用它们，同时提供额外级别的分析，以确保无法通过任何内容。

如何在您的环境中集成静态分析工具有不同的选项。一种方法是在管道的早期运行它以及其他自动化测试。此时，您将能够在同行代码审查之前解决任何问题，并加快整个过程。反过来，开发人员花在审查上的时间更少，并且有更多时间来开发新代码。

如果您拥有大量代码库，则在每次提交时运行深入分析可能会花费太多时间。相反，您可以在开发分支上使用不太全面的分析配置，并按计划执行更昂贵的扫描，或者在集成到上游分支时执行。我们的目标是尽可能早地发现错误，您可以选择最适合您团队的系统。像Klocwork这样的工具完全采用了CI / CD工作流程，并且可以逐步分析每次提交时的代码更改。

高端静态分析工具还可以随时跟踪错误。这可以帮助您选择在当前发布周期中处理哪些问题，因为源代码不断被集成。在长期遗留的代码中报告的问题没有引起问题，可能不值得花时间投资来解决它们。相反，使用宝贵的开发人员时间来关注更近期的问题。

另一个实际约束是可用于静态分析的预算。不是为每个开发人员获取许可证，而是在一定数量的构建计算机（如果可能的话，单个计算机）上运行分析工具。

通过在Cloud Academy上的CI / CD管道实验室中完成静态代码分析，您可以体验静态分析在CI / CD中的工作原理。这个新的动手实验室使用以AWS为中心的连续部署管道来部署Node.js应用程序。该应用程序最初发布到生产中而不执行静态分析。您将学习如何对已部署的应用程序执行注入攻击，然后使用静态分析来识别安全问题。最后，将静态分析集成到管道中的AWS CodeBuild构建阶段，以防止在实施修复之前部署易受攻击的代码。这是最终的环境：

CI / CD中基础设施静态分析代码

作为代码的基础设施（IaC）为开发人员提供了许多好处，包括没有配置偏差，易于重现的环境以及简化的版本控制协作。您是否知道静态分析还可用于实施代码标准并识别基础架构的安全漏洞？通过对基础架构代码使用静态分析，与需要实际部署基础架构的基础架构测试相比，您可以自动化流程并接收早期反馈，这可能是一项耗时的操作。

对于您可能正在使用的大多数IaC框架，通常都会内置某种形式的静态分析。可能有命令检查语法，确保使用有效的参数值，并自动设置代码样式。您还可以执行干运行部署，以检查环境中发生的更改，或在实际部署任何基础结构更改之前检测错误。

您可以使用自己的自定义分析代码补充这些命令，以检查您需要验证的任何内容，例如确保某些端口不对公共互联网开放。幸运的是，通常有开源静态分析工具已经提供了常见的检查。例如，cfn_nag可用于检查AWS CloudFormation模板（AWS的本机IaC框架）中的安全问题。 cfn_nag检查的其他示例包括：

• 确保IAM策略不会过于宽松
• 确保在提供加密的服务上启用加密
• 确保安全组不会过于宽松

如果开源IaC静态分析工具不提供您想要的检查，则可能更容易将其添加到现有代码库而不是从头开始。

您可以亲身体验如何在云学院动手实验室的CI / CD管道中进行IaC静态分析：静态分析和基础设施警报作为代码。该实验室使用Terraform作为IaC框架，使用Jenkins作为其持续集成管道。您将了解Terraform中内置的静态分析功能以及两个改进Terraform本机功能的开源静态分析工具。通过推送到Git存储库，可以持续集成新的基础架构代码。您还将学习如何根据静态分析的结果配置Amazon SNS通知。这是实验室的最终环境：

补充静态分析

虽然静态分析工具在不断改进，但它们并不是满足您所有代码质量和安全需求的灵丹妙药。 相反，将它们视为更全面的解决方案的一部分，以提高应用程序和基础架构代码的质量和安全性。 有时，您仍然需要使用传统的应用程序单元和集成测试，甚至是基础架构测试。 您将能够在我们的动手实验室，使用Serverspec进行基础架构测试中自行测试Serverspec基础架构测试框架。

安全性是另一个重要的自动化测试框架类别。 在此动手实验中学习如何使用Gauntlt保护您的代码免受攻击。 使用Gauntlt，您可以为几种流行的安全分析工具编写自动化测试，并且可以轻松扩展到其他工具。

确保安全的应用程序是安全性的一个重要方面。 传输层安全性（TLS）/安全套接字层（SSL）协议是保护Web上通信的标准。 了解部署SSL / TLS的最佳实践以及在此Cloud Academy实验室中测试SSL / TLS部署的工具。

原文：https://cloudacademy.com/blog/what-is-static-analysis-within-ci-cd-pipelines/

本文：http://pub.intelligentx.net/what-static-analysis-within-cicd-pipelines

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

应用程序已成为希望渗透企业的Web掠夺者的成熟目标。这是有充分理由的。 Black Hats知道如果他们能够在应用程序中找到并利用漏洞，他们就有三分之一的机会成功解决数据泄露问题。更重要的是，在应用中发现漏洞的可能性也很大。 Contrast Security表示，90％的应用程序在开发和质量保证阶段都没有针对漏洞进行测试，甚至更多的应用程序在生产过程中没有受到保护。

由于企业中存在如此多的易受攻击的应用程序，网络防御者面临的挑战是如何保护这些应用程序免受攻击。一种方法是让应用程序通过实时识别和阻止攻击来保护自己。这就是运行时应用程序自我保护（RASP）所做的技术。

什么是RASP？

RASP是一种在服务器上运行并在应用程序运行时启动的技术。它旨在实时检测对应用程序的攻击。当应用程序开始运行时，RASP可以通过分析应用程序的行为和该行为的上下文来保护它免受恶意输入或行为的影响。通过使用应用程序持续监控自己的行为，可以立即识别和缓解攻击，无需人为干预。

RASP将安全性整合到正在运行的应用程序中，无论它位于服务器上。它拦截从应用程序到系统的所有调用，确保它们是安全的，并直接在应用程序内验证数据请求。 Web和非Web应用程序都可以通过RASP进行保护。该技术不会影响应用程序的设计，因为RASP的检测和保护功能在应用程序运行的服务器上运行。

RASP如何运作

当应用程序中发生安全事件时，RASP会控制应用程序并解决问题。在诊断模式下，RASP只会发出警告，表示出现问题。在保护模式下，它会尝试阻止它。例如，它可以停止执行似乎是SQL注入攻击的数据库的指令。

RASP可以采取的其他操作包括终止用户会话，停止应用程序执行或警告用户或安全人员。

开发人员可以通过几种方式实现RASP。他们可以通过应用程序源代码中包含的函数调用来访问该技术，或者他们可以将完整的应用程序放入一个包装器中，该应用程序只需按一下按钮即可保护应用程序。第一种方法更精确，因为开发人员可以在应用程序中做出有关他们想要保护的内容的具体决策，例如登录，数据库查询和管理功能。

无论哪种方法与RASP一起使用，最终结果就像将Web应用程序防火墙与应用程序的运行时上下文捆绑在一起。与应用程序的紧密连接意味着RASP可以更好地适应应用程序的安全需求。

超越外围以获得更好的应用安全性

RASP与传统防火墙具有一些共同特征。例如，它查看流量和内容，并可以终止会话。但是，防火墙是一种外围技术，无法看到周边内部发生的情况。他们不知道应用程序内部发生了什么。此外，随着云计算的兴起和移动设备的激增，外围变得更加多孔化。这降低了通用防火墙和Web应用防火墙（WAF）的有效性。

“安全顾问与WAF有着爱恨交织的关系，因为他们通常在服务的那一天最有效，并且在接下来的几个月里逐渐变得不那么有效，”Rendition InfoSec的首席顾问杰克·威廉姆斯在一篇论文中写道SANS研究所题为“内部保护：应用安全方法比较”。

“有效性下降的原因是，在组织执行成本分析并决定WAF部署比修复应用程序的源代码更便宜之后，WAF部署通常是针对某些渗透测试或安全事件而发生的。”

自我保护应用程序成为现实

RASP的一个优点是，一旦攻击者穿透了外围防御，它就可以保护系统。它深入了解应用程序逻辑，配置和数据事件流。这意味着RASP可以高精度地阻止攻击。它可以区分实际攻击和合法的信息请求，从而减少误报，并允许网络防御者花费更多的时间来解决实际问题，减少追逐数字安全死角的时间。

此外，它自我保护应用程序数据的能力意味着保护随着数据从出生到破坏而传播。这对于需要满足合规性要求的组织尤其有用，因为自我保护的数据对于数据窃贼来说是无用的。在某些情况下，如果被盗数据的形式使其在被盗时不可读，则监管机构不要求报告数据泄露事件。

与WAF一样，RASP也不会修复应用程序的源代码。但是，Williams解释说它确实与应用程序的底层代码库集成，并在源代码级别保护应用程序的易受攻击区域。

“当客户端进行包含可能对Web应用程序造成损害的参数的函数调用时.RASP在运行时拦截调用，记录或阻止调用，具体取决于配置。这种保护Web应用程序的方法与WAF基本不同。 “

为BYOD提供更好的技术，但需要付出代价？

RASP还可以使移动环境受益。根据移动操作系统的不同，保护应用程序免受攻击对组织来说是一个可疑的主张。使用RASP保护它们可以使BYOD成为IT部门的安全挑战。

不利的一面是，在部署RASP时，应用程序性能可能会受到打击，尽管受到多大关注是该技术的批评者和支持者之间争论的焦点。自我保护过程可以减慢应用程序的速度，RASP的动态特性也是如此。如果这种延迟对用户来说变得明显，那么它肯定会在组织中产生焦虑。但是，在更多应用程序开始将RASP合并到其功能中之前，性能问题的严重程度将不明确。

记住RASP是盾牌也很重要。如果某个应用程序存在缺陷，即使受到RASP保护，它也会保持不变。此外，RASP无法抵御所有类型的漏洞。因此，尽管它将为应用程序提供大量保护，但它并不能使应用程序像从开始到结束时安装到应用程序中的安全性一样安全。出于这些原因，一些安全专家建议将该技术与其他方法一起使用以保护应用程序。

在安全方面建设更好，但在那之前......

由于RASP还处于青春期，它相信它将能够克服其缺陷并成为应用程序安全的未来。正如Veracode首席创新官约瑟夫·费曼（Joseph Feiman）在担任Gartner研究副总裁期间所说：

“现代安全无法测试和保护所有应用程序。因此，应用程序必须能够进行安全自检，自我诊断和自我保护。它应该是CISO的首要任务。”

另一方面，如果安全性开始在开发时间线中更深入地传播，那么RASP旨在阻止的许多攻击将被内置到应用程序的源代码中。这将减少对RASP的需求，但保护旧版应用程序仍然很方便。

 

原文：https://techbeacon.com/security/what-runtime-application-self-protection-rasp

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

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

没有人想生病，所以我们会在天气变冷的时候穿夹克，服用维生素C，避免在湿雪的雪地里外出。我们都做了不同的事情，以避免讨厌令人讨厌的病毒和细菌，因为我们知道生产力的损失和我们必须努力使我们的身体系统再次恢复良好的负担远远超过我们一直采取的这些预防措施。

检测安全漏洞，以便您的系统不会“感冒”

您的软件系统也是如此。如果具有已知问题或漏洞的工件进入您的生态系统，则需要花费您去除它。当然，既然您拥有JFrog Xray，您就可以检测到安全漏洞，性能问题甚至是您定义的自定义问题，但如果您只是在使用它们时才检测到这些问题，那么您将需要做一些工作。您的组件已经经历了X开发和QA循环，您可能已准备好发布到生产中，然后有人记得Xray在几周前暴露了其中一个依赖项中的安全漏洞。哎呀，停止开发，找到替代组件，重构代码，开发-QA-repeat-X-times，花费数周的时间让你的代码再次运行良好。如果你可以避免这种情况，那不是很好吗？好吧，现在你可以！

预防胜于治疗

到目前为止，这些东西都是手动处理的。将工件下载到远程存储库缓存时，会触发Xray运行扫描，如果检测到任何问题，则会通知DevSec工作人员。然后你必须决定是否发布工件以供下载，并手动管理。 JFrog Artifactory的最新版本允许您将DevSec带出循环。您现在可以自动阻止Xray检测到安全漏洞的工件下载。

有两个级别的保护。首先，您可以指定引入Artifactory的工件（无论它们是否已缓存在远程存储库中，还是上载到本地存储库），在Xray对其进行索引和扫描之前，无法下载这些工件。这类似于信用卡公司在授予您信用卡之前进行的背景调查。同样，在对它们运行背景检查（X射线扫描）之前，您不希望为工件提供任何信用。

第二级保护可以更好地控制应该阻止哪些工件（如果有的话）。 工件中发现的问题按严重性级别进行评级：次要，主要或严重。 并非每一个小问题都必须成为您的交易障碍。 这是你控制的东西。 当问题暴露时，您会收到通知，但在您有机会进一步调查问题之前，您可能不想立即停止开发。 相反，你很有可能想要阻止任何有关键问题的工件，而你的开发人员只需要寻找其他东西。 因此，如果Xray检测到问题，您可以指定要在哪个严重性级别阻止工件。

 

无论您选择使用哪种设置，只要设置它们，Xray就会被触发扫描整个存储库，因此任何未通过信用检查的组件都会立即被阻止。

为避免让开发人员误解他们为什么空手而归，Artifactory会在树形浏览器中显示有关被阻止工件的通知，并为REST API调用提供信息性错误消息，因为工件已被阻止而失败。

所以Xray和Artifactory一起是你的软件系统夹克，羊毛帽子或膳食补充剂。 他们是不知疲倦的哨兵，防止任何未经检查，可疑和可能有害的文物进入您珍贵的生产系统附近。 通过下载阻止，您的系统可以接种神器疾病，因此您可以信任它们以最佳状态执行并执行他们应该执行的操作。 这一切都是自动发生在背景中而不必抬起手指。

原文：https://jfrog.com/blog/blocking-downloads-with-artifactory-and-xray/

本文：

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

描述

实验室概述

DevOps中的一个重要原则是测试您的基础架构。测试应作为持续交付管道的一部分运行，为您提供基础架构变更的灵活性和信心。 Serverspec是基础架构测试框架的一个示例。 Serverspec可用于通过SSH或WinRM连接来测试本地和远程目标计算机。

本实验说明了如何使用Serverspec执行基础结构测试。您将编写Serverspec测试以指定在反向代理，负载平衡层和示例应用程序的应用程序层中运行的计算机的预期行为。测试说明了如何描述服务器和Docker容器的预期行为。您将在命令行和Docker容器中使用Serverspec运行测试。

实验室目标

完成本实验后，您将能够：

• 了解自动化基础架构测试适合DevOps的位置
• 初始化Serverspec基础结构测试套件
• 编写Serverspec测试各种Serverspec资源，包括包，服务，端口和Docker基础结构
• 从命令行和Docker容器中运行Serverspec

实验室先决条件

你应该熟悉：

• 一种编程语言。 Ruby熟悉是最有益的，但不是必需的。
• 基本的Docker概念，例如图像和容器
• 基本的Linux概念，例如命令行，进程，包和服务

实验室环境

在完成实验室说明之前，环境将如下所示：

完成实验室说明后，环境应类似于：

 

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

每个组织都希望具备网络弹性。大多数团队使用横向软件开发生命周期（SDLC）思维模式（如安全要求，威胁建模，代码扫描程序等）自下而上地解决问题。不幸的是，尽管这些方法很有用，但它们并不能很好地扩展。

利益相关者不知道围绕安全要求要求什么，威胁建模是不一致的 - 取决于建模和代码扫描程序错过50％或更多安全问题的团队。但是有更好的方法。

专注于您的垂直管道 - 从标准和知名行业框架生成的安全策略到SDLC启动的过程。策略提供了一个指导SDLC的护栏，以便您建立安全性。

由于管道本质上是垂直的，因此在SDLC中完成的任何工作都会自动汇总到更高级别，从而使您可以近乎实时地了解应用程序组合的安全状况。

以下是如何以独立于平台的方式创建策略到执行管道。

解决政策与执行之间的差距

在一个专注于安全性的典型企业中，您通常会看到三组人：

1. 安全团队，专注于应用程序和操作安全性，供应商风险管理，威胁监控和培训
2. 风险和合规团队，专注于处理隐私，审计和策略创建的合规生命周期
3. IT团队（包括开发和运营）专注于与敏捷，DevOps和混合基础架构管理相关的活动

图1.安全性与创建策略的风险和合规性团队以及必须执行这些策略的IT团队之间经常存在策略到程序的差距。

安全性以及风险和合规性团队根据ISO-27001等标准制定策略，并将这些策略交给IT团队，假设IT可以针对他们执行。

但大多数IT团队并不了解如何解释这种高级抽象政策。它们习惯于处理与缓存，身份和访问管理相关的过程。

因此，根本的挑战是将抽象的高级策略转换为IT团队可以执行的事项。这是政策与执行之间的差距。

使用集成流程实现策略到执行

每个团队都有自己的流程和工作流程。安全团队有自己的流程专注于持续的安全管理。同样，风险和合规团队拥有持续的风险和合规性管理工作流程，技术团队拥有DevOps管道。

图2.安全性与风险和合规性团队（左）和技术团队（右）创建的流程之间经常存在脱节。

图3.在安全性，风险和合规性团队以及技术团队之间架起不同的流程需要创建对所有方面都有意义的通用标准。

面临的挑战是将每个不同的流程整合到对风险管理有意义的业务中。实现这一目标的方法是从生成安全标准的安全团队开始。

在安全标准中，您有几个子句。这些条款然后进入另外两个工作流程：

1. 技术团队，其中安全控制由标准中的条款生成
2. 风险和合规团队，根据风险来衡量这些条款，以确定哪些条款具有更高的优先级

当技术团队执行日常活动时，他们的工作结果就是确认政策是否得到满足。您可以通过将安全控件映射到预定义的应用程序体系结构来实现此证明。映射到体系结构而不是单个应用程序的原因是为了减少为每个应用程序复制一组接受的控件的开销。

集成工具

这一切都始于对业务风险的评估。通过该评估，您可以确定安全业务需求，从而进入使用建模工具捕获的体系结构或服务定义。

然后，此体系结构将进行威胁建模活动，其结果将进入与DevOps管道集成的业务安全需求存储库。在管道中，您将集成应用程序生命周期管理（ALM）工具，构建工具和静态/动态分析测试工具。构建成功后，工件将移动到包含配置文件，代码文件和脚本的存储库中。

在构建存储库中，您将部署执行到测试环境中，该测试环境使用功能和非功能测试工具来解决质量问题。如果发现错误，它将被推回到您的ALM，DevOps管道再次启动。如果一切都过去了，管道的下一个阶段将返回到存储库并部署到您的预生产和生产环境中，您可以在其中进行真正的用户测试。

但是如果有任何错误，它会在测试环境中重新测试。最后，如果在测试中确认了失败，则必须在DevOps管道开始时返回并启动它。

构建生产后，SecOps工具会监视生产环境。如果发现任何漏洞，它们将再次返回到您的DevOps管道中，并根据需要修改安全策略。这创建了一个完整的循环，从业务风险管理一直到您的DevOps管道，并带有持续改进的反馈循环。

[另请参阅：为什么以及如何使用Jenkins将管道实现为代码]

关注相关指标

考虑对业务最有意义的领域。在Info-Tech Research Group的研究中，我们发现了三个：

1. 弹性：哪些指标会显示您可以在发生违规时快速恢复的业务？
2. 风险和合规性：哪些指标会显示您符合标准或法规？
3. 速度：哪些指标会显示您在保持安全的同时不会妨碍业务？

以下是一些需要考虑的指标：

1. 是时候修补漏洞了
2. 大多数代码区域已更改
3. 部署频率
4. 改变失败率
5. 应用性能

一步一步

总之，您需要了解三件事。 首先，高层政策与执行之间存在根本差距。 其次，解决这一差距需要整合安全性，风险和技术工作流程。 第三，不要试图一次性完成这一切。 从最容易注入安全性的地方开始，然后从那里开始构建。

最终，您的目标是建立一种价值安全的文化，因为它降低了业务风险，并且不会妨碍其需求。 正如需要通过DevOps集成开发和运营活动一样，您现在需要集成安全和风险团队。

想知道更多？ 来参加我的SecureGuild在线安全测试会议，我将从威胁建模的角度详细介绍如何创建垂直管道。 会议从5月20日到21日举行。不能成功吗？ 活动结束后，注册人可以完全访问所有演示文稿。

原文：https://techbeacon.com/security/threat-model-scale-how-go-policy-execution

本文：

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

开源软件的本质意味着，虽然它由多个开发人员审查，但应采取额外步骤以确保其安全性。

企业正在利用各种开源产品，包括操作系统，代码库，软件和应用程序，用于各种业务用例。虽然使用开源具有成本，灵活性和速度优势，但它也可能带来一些独特的安全挑战。鉴于开源组件可能存在于高达96％的商业应用程序中，您如何确保您的软件是安全的？

我们询问了Cloud Academy内容团队的两名成员 - 我们的DevOps专家Logan Rakai和我们的所有安全专家Stuart Scott  - 分享他们帮助保持开源组件安全的技巧。

是什么让开源组件容易受到安全风险的影响？

一些开源项目的短暂发布周期可能难以跟上。

从好的方面来说，新功能和补丁很快就会被部署。但是，审核每个版本可能是某人的全职工作，当您在一个版本中管理所有问题时，另一个版本已准备就绪。本周风味的开源框架是一个安全的噩梦，虽然拥有一个扫描最新更新的自动化系统将有所帮助，但它不是一个可以识别所有问题的故障保护。

有了这么广泛的用户群来测试软件，发现潜在的漏洞安全漏洞，开源软件（OSS）通常被认为更安全。但是，在捕获和修复安全问题时，仅仅关注问题是不够的。安全问题需要安全专业知识，并非所有开发人员都是安全专他们可能已经足够了解并尝试实施某些修复，但这可能会产生错误的风险缓解感。例如，加密等更高级的主题可以进一步缩小那些可以检查代码是否存在此类安全漏洞的人。

开源项目中的依赖性允许一些漏洞在雷达下飞行。

从包管理器中提取的包含未知第三方库的项目可能会传递不易看到的漏洞。许多开发人员确定版本范围，以确保未来的补丁可用。但是，删除多个项目的依赖项可能首先更难以注意到，并且更有可能是可以被利用的攻击向量。

开发人员和DevOps团队可以做些什么来更好地保护开源组件？

将所有内容视为代码，包括合规性。这样做有助于确保遵循已知的法规，包括支付卡行业（PCI）或医疗保健（HIPAA）信息隐私。这也可以更容易地确保普遍应用补丁。

拥抱自动化。

及时了解在线源（例如国家漏洞数据库）中记录的漏洞或在项目主页上发布的漏洞，这也是非常耗时的。放置一些前线工具以帮助捕获明显的事物（有一些很棒的商业和开源动态应用程序安全测试（DAST）解决方案可用）并使用监控工具来跟上实时发生的事情。 SumoLogic等工具非常棒，可作为安全信息和事件管理（SIEM）的现代替代品。静态代码分析至少必须是CI / CD过程的一部分，它可以自动，及早地检测安全问题，以补充同行评审。

将开发人员和安全性结合。

在一起请您的安全团队培训开发人员，以全面了解安全性和最新趋势。与安全团队合作举办的初步安全编码研讨会是开展工作的好方法。邀请他们设计评论，并在进行高风险变更时将其纳入会议。

 

建立安全第一的文化。

 

您的组织必须关注的不仅仅是将开发人员和安全性结合在一起，还要确保将有效的安全实践内置到您执行的所有操作中。世界上最好的解决方案和最好的警报机制无法解决不良的安全措施。例如，Equifax漏洞归因于开源软件Adobe Struts的易受攻击版本，就是一个很好的例子。自2017年广为人知的违规行为以来，尽管有补丁可用，公司仍在下载易受攻击的软件包版本。 （补丁也在Equifax漏洞发布前两个月发布，并且自那时起多次发布。）在DevOps文化中，安全性讨论必须尽早发生，并且通常在整个软件开发生命周期内及之后发生。如果您使用的是开源组件，那么您有责任了解更新并实际应用它们。

幸运的是，有一些工具可以帮助您评估并提供有关您在应用程序中使用的开源软件的安全性的信心。 Black Duck和Sonatype Nexus提供两种工具，为管理开源风险提供企业级端到端解决方案。请注意，这些解决方案不是一夜之间的解决方案，需要时间进行集成。

还有免费工具可用于评估开源软件和容器中的风险。许多开源软件包使用免费的静态分析扫描仪，结果可供所有人检查。

Coverity Scan提供对开源软件的免费深度扫描，其中包括Common Weakness Enumeration（CWE / SANS）Top 25漏洞。许多项目都信任Coverity Scan，包括Linux内核和Apache项目，如Hadoop。您可以在项目页面上找到它们。

如果您对所识别的风险不满意，可以考虑使用备用软件或版本。同样，如果您在DevOps实践中使用Docker容器，则可以利用Docker托管的官方映像的Docker Security Scanning结果，并使用相同的技术扫描您自己的私有存储库映像。

 

原文：https://dzone.com/articles/open-source-software-security-risks-and-best-pract

本文：http://pub.intelligentx.net/open-source-software-security-risks-and-best-practices

讨论:请加入知识星球【首席架构师】

今年早些时候，一群网络犯罪分子开始使用大杂烩技术攻击公司，留下电影“黑客帝国”的参考资料，并使用勒索软件加密关键企业系统。

这一被反病毒软件供应商Sophos称为“MegaCortex”的攻击似乎来自受攻击的域控制器，攻击者可能使用窃取的管理员凭据访问了这些域控制器。一旦进入内部，攻击者就会使用常用技术来使用已经受到攻击的系统上的工具 - 称为“在陆地上生活” - 以避免被发现。

例如，该组使用PowerShell中的命令行界面，可在所有Microsoft Windows系统上使用。使用PowerShell，他们解码并运行一个模糊的脚本，在系统中设置后门，然后使用Windows Management Instrumentation（WMI）软件自动感染网络上的其他计算机。

Sophos高级安全顾问John Shier表示，这些技术正变得越来越普遍，并且不乏可以为攻击者目的而增加的工具。

“有超过100种不同的工具可供攻击者自动攻击使用。他们正在使用Windows系统自己的工具来对抗它。”

-John Shier

以下是攻击者针对您的企业系统的主要工具。

1. PowerShell

当Windows系统成为攻击的目标时，PowerShell通常是攻击者的常驻工具。与Linux系统上的Bash shell一样，PowerShell允许攻击者创建可以自动执行危害系统任务的脚本。

2010年，两位安全专业人士--Dave Kennedy和Josh Kelly在DEFCON 18的演讲中强调了PowerShell作为后期开发技术的实用性。2011年，另一位安全专业人士Matt Graeber写了一篇关于他自己涉足帖子的描述-exploitation PowerShell编码，在他博客的帖子中有一个例子。

Palo Alto Networks威胁情报副总裁Ryan Olson表示，Graeber开发的脚本已经进入许多公共工具，用于将代码加载到内存中以避免将代码写入磁盘。

“自Windows 7以来，PowerShell内置于所有Windows系统中，这意味着总有一个强大的脚本引擎可以访问他们可以访问的任何Windows主机上的资源。”

-Ryan Olson

2. Docker

对于许多开发人员和运营专业人员而言，Docker是一种工具，可以让容器快速旋转，以便在自定义应用程序环境中工作。它还可以在软件转移到生产之前测试正在开发的应用程序。

但是，如果开发人员不关心他们使用哪些图像作为其容器的基础，则攻击者可以使用恶意Docker容器在公司网络内运行代码。虽然Docker容器的安全功能是他们无法在没有明确许可的情况下访问本地软件，但他们可以扫描网络以寻找其他系统来感染或执行其他任务，Crowdstrike威胁情报副总裁Adam Meyers表示，安全服务公司。

“这是一个很棒的工具，但是如果镜像不安全或者镜像上的东西不必存在，或者它们有漏洞，那么攻击者可能会利用它。”

-Adam Meyers

3. WMI

这种基于Windows的应用程序界面允许访问管理信息，并且作为攻击者获取有关网络上系统的其他信息并自动进一步攻击的管道非常有用。

Meyers说，WMI已被犯罪分子和民族国家的对手使用。

“对手可以访问的任何东西，以及可以发出命令并让它执行动作的东西，对他们来说都具有潜在的价值。”

-Adam Meyers

4. VBScript

Microsoft系统管理员使用Visual Basic Sc​​ripting（VBScript）语言使用类似Visual Basic的语言自动管理计算机。但是VBScript也是攻击者自动感染系统的常用方法，特别是如果它们将其作为Office文档的一部分包含在内。

Palo Alto Networks的Olson表示，使用VBScript和其他工具防范攻击需要安全管理员权衡工具的好处和风险。

“对于很多像PowerShell和VBScript这样的工具，限制它们的使用和实用性非常重要。为这些工具创建白名单和黑名单。你可以将它们仅限于某些系统或某些功能。”

-Ryan Olson

 

5.压缩工具

任何攻击者的一个关键步骤是从目标系统中获取数据，因此他们通常会在系统上使用压缩工具，这不仅可以缩小数据的大小，还可以对信息进行模糊处理。他们可以共同选择各种常用工具来帮助他们。

“对于数据泄露，攻击者通常需要在将文件发送到另一个位置之前对其进行归档，”Olson说。 “他们可以使用Windows中的内置压缩功能实现这一目标，或者寻找其他已安装的工具，如7-Zip或WinRAR。”

这些常用工具并不是攻击者从受感染系统扩展妥协的唯一方法。开发人员必须提防知识渊博的攻击者，他们将代码插入到他们的开发路径中，例如最近针对游戏公司的攻击。

Sophos的Shier表示，在这些情况下，攻击者采取编译器和陷阱陷阱，以便当开发人员编写代码时，它会在那里放一些特殊的酱 - 一个后门。

“仅仅因为它不是PowerShell或WMI并不意味着具有足够技能的攻击者无法进入您的环境并在您的路径中添加DLL，最终会为您的代码添加后门。”

-John Shier

关闭你的系统

虽然适用于网络安全的“生活在陆地上”这一术语有点新，但技术却并非如此。 1986年，正如“咕咕蛋”中记载的那样，来自西德的攻击者闯入劳伦斯利弗莫尔国家实验室的计算机，攻击了其他各种政府和军用计算机，主要使用系统上已有的工具。

然而，当前技术使用的增加标志着十年前趋势的逆转，当时攻击者使用自定义恶意软件。 Crowdstrike的Meyers表示，随着越来越多的公司使用可以检测恶意定制软件的防御系统，攻击者会专注于以恶意方式使用现有工具。

“从威胁演员的角度来看，他们希望在检测之前增加时间，以便他们可以离开那个系统。通过在陆地上生活并使用已经在系统上的工具，他们可以避免大量的传统的防病毒类解决方案。“

-Adam Meyers

 

原文：https://techbeacon.com/security/when-your-own-tools-attack-top-5-offenders

本文：

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

如果您已经拥有端到端测试，UI测试或其他与真实最终用户相似的测试，请考虑在开发生命周期的早期阶段向这些测试添加Web应用程序防火墙（WAF）。它不会花费太多时间，您将获得许多额外的安全性和其他好处。

理想情况下，您已经对Web应用程序进行了测试。如果没有，请创建它们。然后使用相同的测试来确定您是否仍然在应用程序前面使用WAF具有完整的应用程序功能。您的测试仍应成功，并且您的ModSecurity日志应为空 - 这意味着您的测试不会触发WAF规则。

作为WAF ModSecurity的OWASP核心规则集（CRS）的共同开发者，我觉得分享如何将WAF引入DevOps非常重要。我希望通过自动化WAF测试来减少对WAF的恐惧。

以下是如何确保您的团队使用WAF顺利进行。

什么是WAF？

传统防火墙在TCP或IP网络层工作，而WAF在应用层阻止攻击。它有助于保护您免受Web应用程序攻击，并在您的应用程序前创建一个安全网。你需要它，因为你永远不能相信你的代码100％。

不幸的是，WAF也可能阻止合法流量，导致误报和生产问题。只有当所有组件都是DevOps /测试/自动化管道的一部分时，DevOps，测试和自动化才有意义。让一切都完全自动化并经过测试是没有意义的，然后在生产中将WAF放在您的应用程序前面。使WAF成为您测试的一部分。

如果您在开发周期的早期开始使用Web应用程序测试WAF，则可以确保Web应用程序正常运行。 WAF可以帮助防止Web应用程序攻击，例如SQL注入，跨站点脚本，对HTTP协议的攻击以及其他威胁。 WAF不会阻止所有攻击，但它使攻击者更难以利用漏洞。

以下是您的测试工具所需的工具。

ModSecurity WAF

ModSecurity是一种流行的WAF，可用作NGINX，Apache或IIS模块。 ModSecurity是引擎，它需要规则来检查每个HTTP请求和响应。

这就是CRS的用武之地。它主要由正则表达式组成，它为每个请求决定它是合法的，攻击还是信息泄漏。 ModSecurity和CRS都是免费提供的开源软件，并且拥有出色的社区支持。

 

OWASP DevSlop的Pixi

OWASP DevSlop代表“草率的DevOps”。该项目的目标是使用几个示例管道，博客文章，YouTube频道等展示DevSecOps。

DevSlop由不同的模块和管道组成。有些可以作为DevSecOps如何完成的一个例子。它的一些应用程序或模块可以作为试验Web应用程序攻击或使用ModSecurity和CRS的游乐场。

Pixi是DevSlop项目中许多计划应用程序中的第一个。您可以使用这个故意易受攻击的Web应用程序来试验Web应用程序攻击。当Pixi受CRS（另一个DevSlop模块）保护时，示例Web应用程序攻击不再成功。

TestCafe

您可以使用TestCafe的开源版本来测试Web应用程序，同时模拟用户的使用方式，您也可以使用相同的测试来测试您的WAF。

具体来说，您可以测试在应用程序前是否仍具有WAF的完整应用程序功能，以及ModSecurity日志是否仍为空。

设置管道

手动测试WAF是一个枯燥且容易出错的过程。相反，使用自动端到端测试在前面测试带有WAF的Pixi应用程序。您不必再关心测试了：每次将Web应用程序代码提交到存储库时，一切都会自动启动并运行。

 

获取您的WAF

使用正确的工具和软件，您可以在其前面使用WAF测试任何Web应用程序，并自动执行此操作。

这不仅适用于WAF专家。只要你测试它，WAF就是每个人的朋友。这是您抵御网络攻击的第一层防线。它是开源的，免费的，并创建了其他可能性，如虚拟补丁，扩展日志记录和监控。你绝对应该在测试和生产中使用WAF。

 

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

在应用程序安全性测试领域，经常使用术语“代码覆盖率”和“漏洞覆盖率”。但他们真正的意思是什么？代码覆盖率是扫描的代码量，用于识别软件应用程序中的潜在漏洞。漏洞覆盖率是指软件代码中可能存在潜在威胁的特定缺陷或系统错误配置的数量。

您的AppSec团队应该实现100％的代码和漏洞覆盖吗？这是现实的吗？真正的答案是，“这取决于。”让我们看看各种考虑因素以及如何尽可能获得最佳覆盖率。

代码和漏洞覆盖范围：SAST，DAST等

软件开发人员和渗透测试人员使用复杂的软件保障测试工具来查找其软件中的漏洞。挑战在于没有一种工具（或工具类型）能够为整个目标应用提供足够的覆盖。当今市场上的应用程序安全测试工具在应用程序中发现了特定的弱点。尽管他们在识别特定漏洞方面可能非常出色，但没有一种解决方案可以做到这一切。

每个工具都专注于不同的语言和不同的弱点类（例如，缓冲区处理，文件处理，初始化和关闭以及数字处理）。虽然您可能对识别某些类型的弱点的测试结果感到欣喜若狂，但如果您只测试一小部分代码，则结果不能提供真实的表示。

静态应用程序安全性测试（SAST）工具（也称为白盒测试工具）在软件开发过程的早期阶段用于从内到外测试应用程序。它们逐行进行测试源代码，字节代码或二进制文件。

使用SAST工具，可以实现100％的代码覆盖率，因为它们可以访问应用程序的内部。

但是，即使可以访问所有代码的静态分析工具也无法提供完整的漏洞覆盖。事实上，专家表示，普通工具只能覆盖代码中14％的漏洞。因此，利用多种工具和相互补充的工具类型是行业最佳实践。

黑盒测试工具，也称为动态应用程序安全测试（DAST）工具，通常具有有限的代码覆盖率，基于他们能够识别的攻击面的多少以及它们在应用程序中模糊的输入以导致不同类型的漏洞。 DAST工具从外部进行测试。他们在应用程序运行时对其进行测试，尝试渗透它以发现潜在的漏洞，包括代码之外和第三方界面中的漏洞。

如果您想要实现全面的代码和漏洞覆盖，其他类型的工具（如交互式应用程序安全测试（IAST）工具，威胁建模工具，甚至手动测试）也是AppSec难题中的重要部分。即便如此，我们建议您更进一步，使用可帮助您理解这些AppSec工具的工具，并真正了解您的代码覆盖率是多么完整。

 

超越AppSec工具：使用代码覆盖工具提高可见性

虽然使用多个应用程序安全测试工具有许多优点，但也有一些障碍需要克服。使用每个额外的工具需要额外的成本，更多的时间来实现和运行它，以及比较不同结果集（例如，命名约定和严重性评级）的挑战。这是代码覆盖工具（如应用程序漏洞管理器和可视化工具）提供无与伦比的优势的地方。

应用程序漏洞管理工具将商业和开源工具的结果进行关联和规范化。它提供了一组统一的结果，可以更好地覆盖源代码中的潜在漏洞，并更好地评估组织的整体企业风险。

这一工具可处理重复数据删除，补救管理，报告和合规性检查。工作流集成选项允许您的开发人员在解决应用程序漏洞问题的同时保留其首选环境 -  Eclipse，Jira，Jenkins和其他环境。

Code Dx应用程序漏洞管理工具还提供应用程序漏洞关联（AVC），通常称为混合分析。这是指SAST结果（识别潜在漏洞）与DAST结果（确定哪些威胁实际可利用）的组合。这使您可以确定代码中存在哪些威胁，并且可以被外部攻击者利用，因此您可以先解决这些威胁。

Code Dx团队还开发了一个免费的OWASP解决方案，称为Code Pulse。这种开源渗透测试可视化工具提供了对实时代码覆盖率分析测试的深入了解。它可以帮助您的测试团队评估用于应用程序安全性测试的每个工具的性能和覆盖范围。

它通过对应用程序攻击面的可视化说明以及渗透测试如何与之交互来实现。因为它在您的应用程序处于活动状态时实时运行，所以您可以准确地确定渗透测试涵盖了代码的哪些部分，以及哪些部分不是。

Code Pulse还会显示每个工具涵盖应用程序的哪些部分，因此您可以看到存在重叠的位置 - 更重要的是，哪里有间隙。这有助于您评估代码和漏洞覆盖率，并确定是否需要在测试过程中添加不同的工具。您可以快速比较所有工具的覆盖范围，查看尚未测试的任何代码，并立即查看扫描设置调整的结果。

总之，SAST工具可以提供100％的代码覆盖率（与DAST工具不同），但它们不能提供100％的漏洞覆盖率。为了尽可能接近100％的漏洞覆盖率，我们建议结合使用SAST，DAST和其他AppSec测试工具来获得全面的覆盖率。虽然这似乎是一项艰巨的任务，但应用程序漏洞管理器可帮助您了解这些工具的结果。像Code Pulse这样的可视化工具可以让您轻松查看覆盖的位置以及放大保护所需的位置。

原文：https://codedx.com/100-code-vulnerability-coverage-realistic/

本文：

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

使用调整的ModSecurity / Core规则集安装优化您的NGINX设置。

 

站点管理员使用Web应用程序防火墙（WAF）来阻止恶意或危险的Web流量，但也存在阻止某些有效流量的风险。误报是您的WAF阻止有效请求的实例。

误报是每次WAF安装的天敌。每个误报都意味着两件坏事：你的WAF工作太辛苦，消耗计算资源以便做一些不应该做的事情，并且不允许合法的流量通过。产生太多误报的WAF造成的伤害可能与成功攻击造成的伤害一样糟糕 - 并且可能导致您在挫折中放弃使用您的WAF。

调整您的WAF安装以减少误报是一个繁琐的过程。本文将帮助您减少NGINX上的误报，让您进行干净安装，允许合法请求通过并立即阻止攻击。

WAF引擎ModSecurity最常用于与OWASP ModSecurity核心规则集（CRS）协调。这为Web应用程序攻击创建了第一道防线，例如OWASP Top Ten项目所描述的攻击。

CRS是用于对传入请求中的异常进行评分的规则集。它使用通用黑名单技术在攻击应用程序之前检测攻击。 CRS还允许您通过更改配置文件crs-setup.conf中的Paranoia Level来调整规则集的激进程度。

误报与真实攻击相互混合

由于使用CRS导致的误报导致阻止合法用户的恐惧是真实的。如果您有大量用户或具有可疑流量的Web应用程序，则警报的数量可能会令人生畏。

开箱即用的CRS配置已经过调整，可以积极地减少误报的数量。但是，如果您对默认安装的检测功能不满意，则需要更改偏执等级以改善覆盖范围。在配置文件中提高偏执等级会激活默认关闭的规则。它们不是Paranoia Level 1默认安装的一部分，因为它们有产生误报的倾向。妄想症等级设置越高，实施的规则就越多。因此，规则集变得越激进，产生的误报就越多。

考虑到这一点，您需要一种减轻误报的策略。如果允许它们与真实攻击的痕迹混合，它们会破坏规则集的价值。所以，你需要摆脱误报，以便最终得到一个干净的安装，让合法的请求通过并阻止攻击者。

问题很简单：

1. 如何识别误报
2. 如何处理个人误报
3. 实用的方法是什么样的？ （或者：你如何扩展这个？）

当十几个误报出现时，很难识别它们。对应用程序的深入了解有助于从恶意的请求中获取良性但可疑的请求。但是，如果您不想逐个查看它们，则需要过滤警报并确保最终只得到包含误报的数据集。因为如果你不这样做，你可能最终会调出指向发生攻击的真实警报。

您可以使用IP地址来识别已知用户，已知本地网络等。或者，您可以假设成功通过身份验证的用户不是攻击者（可能是天真的，具体取决于您的业务规模）。或者您可以使用其他一些识别方法。确切的方法实际上取决于您的设置和您的测试过程。

当您确定个体误报时，有多种方法可以避免将来重复误报。使用CRS，您不会编辑规则集，因为它意味着作为一个不可编辑且连贯的整体运行。相反，您可以通过ModSecurity指令重新配置规则集的使用方式。这使您可以将相同的更改应用于CRS的未来版本，而无需重新创建编辑。

通常有四种处理误报的方法：

1. 您可以完全禁用规则
2. 您可以通过规则从检查中删除参数
3. 您可以在运行时禁用给定请求的规则（通常基于请求的URI）
4. 您可以在运行时从规则检查中删除给定请求的参数

很明显，禁用某些规则会影响规则集的检测率。实际上，您希望对规则集进行最小的更改，以允许良性但可疑的请求通过，从而避免误报。在各种情况下做出最佳选择需要一些经验。

我在cheatsheet上总结了四个一般变体，你可以从netnea.com下载。

缩放调整过程

掌握这个调整过程需要一些练习。当你对这个新手时，看起来并不像它会扩展。事实上，许多新人只是接近警报并尝试通过它 - 通常没有太大的成功。

鉴于ModSecurity警报的可读性较低，人们采用这种方法的事实并不令人意外。以下是真实攻击的一个例子（真正的正面）：

2018/01/15 18:52:34 [info] 7962#7962: *1 ModSecurity: Warning. Matched "Operator `PmFromFile' with parameter `lfi-os-files.data' against variable `ARGS:test' (Value: `/etc/passwd' ) [file "/home/dune73/data/git/nginx-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "71"] [id "930120"] [rev "4"] [msg "OS File Access Attempt"] [data "Matched Data: etc/passwd found within ARGS:test: /etc/passwd"] [severity "2"] [ver "OWASP_CRS/3.0.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "OWASP_CRS/WEB_ATTACK/FILE_INJECTION"] [tag "WASCTC/WASC-33"] [tag "OWASP_TOP_10/A4"] [tag "PCI/6.5.4"] [hostname "127.0.0.1"] [uri "/index.html"] [unique_id "151603875418.798396"] [ref "o1,10v21,11t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase"], client: 127.0.0.1, server: localhost, request: "GET /index.html?test=/etc/passwd HTTP/1.1", host: "localhost"

 

如果您有数千个这样的日志条目，警报疲劳是正常的反应。你需要工具来找到自己的方式。最简单的工具是一组shell别名，它们以更易读的方式提取信息并显示它 - 我开发了一组执行此任务的shell别名。您也可以从netnea下载这些。

以下是此文件中的一个示例，它提供了警报消息的摘要：

alias melidmsg='grep -o "\[id [^]]*\].*\[msg [^]]*\]" 
| sed -e "s/\].*\[/] [/" -e "s/\[msg //" | cut -d\  -f2- | tr -d "\]\"" 
| sed -e "s/(Total .*/(Total ...) .../"'

以上面的示例消息为例，并应用此别名：

$> cat sample-alert.log | melidmsg
930120 OS File Access Attempt

这样做要好得多：ID为930120的规则是由请求触发的，指向操作系统文件访问尝试。可疑请求试图访问/ etc / passwd-服务器的本地密码文件，Web服务器永远不应该访问该文件。这是真正攻击的明显迹象。

现在让我们列出一个在Paranoia Level 3上使用CRS安装的典型非调整站点上发现的误报列表。我应用了melidmsg别名并按规则对它们求和（sort | uniq -c | sort -n）：

      

 8 932160 Remote Command Execution: Unix Shell Code Found
     30 921180 HTTP Parameter Pollution (ARGS_NAMES:op)
     75 942130 SQL Injection Attack: SQL Tautology Detected.
    275 942200 Detects MySQL comment-/space-obfuscated injections and backtick 
termination
    308 942270 Looking for basic sql injection. Common attack string for mysql, 
oracle and others.
    402 942260 Detects basic SQL authentication bypass attempts 2/3
    445 942410 SQL Injection Attack
    448 921180 HTTP Parameter Pollution (ARGS_NAMES:fields[])
    483 942431 Restricted SQL Character Anomaly Detection (args): # of special 
characters exceeded (6)
    541 941170 NoScript XSS InjectionChecker: Attribute Injection
   8188 942450 SQL Hex Encoding Identified

给出的第一个数字是误报的数量。第二个数字是触发的规则的ID。后面的字符串是规则的文本描述。

这是分布在11个不同规则上的数千个错误警报。这不仅仅是我们可以一口咬下来的，而只是从第一个警报开始就不会让我们到任何地方。至少我们获得了定量信息。好像最大的问题似乎是看起来是十六进制编码的信息，CRS认为它可能是一个混淆的攻击。通常，这是一个会话ID，如果它在cookie中。

然而，即使以最大数量的误报开始也会给我们带来即时的满足感，但这并不是最好的方法。当我们点击XSS规则时，由此规则产生的541警报（编号941170）很可能会转换为数十种不同的形式和参数。这将使得在单个块中正确处理它们变得非常困难。

所以，我们不要急于求成。让我们想出一个更好的方法。

为调整过程带来意义和理由

我们需要开发更好的方法是一个不同的视角。我们不应该再看不同的规则了。我们应该查看触发规则的请求。因此，我们将查看成千上万的请求，并将误报放在一边，而不是几千个警报。

为此，我们需要知道服务器上所有请求的异常分数。不仅是那些得分，还有那些没有引起任何警报的人。该分数显然为零，​​但必须知道此类别中的请求数量，以便更好地了解误报的数量。

当我以前在Apache上工作时，让ModSecurity在服务器的访问日志中报告每个请求的异常分数是相当容易的。使用NGINX并不容易。因此，我们需要采用不同的技术：我们添加一条规则，在请求完成后报告异常分数（在ModSecurity的日志记录阶段5）。我们分配此规则ID 980145。

SecAction \
    "id:980145,\
    phase:5,\
    pass,\
    t:none,\
    log,\
    noauditlog,\
    msg:\'Incoming Anomaly Score: %{TX.ANOMALY_SCORE}\'"

当我们grep这个规则ID时，我们得到每个请求的分数。

重新格式化输出，我们可以有效地提取异常分数：

$> cat error-2.log | grep 980145 | egrep -o "Incoming Anomaly Score: [0-9]+" | 
cut -b25-
0
0
0
5
0
0
10
0
3
0
0
0
...

这些价值如何分配？

$> cat error-2.log | grep 980145 | egrep -o "Incoming Anomaly Score: [0-9]+" | 
cut -b25- | modsec-positive-stats.rb --incoming

INCOMING                     Num of req. | % of req. |  Sum of % | Missing %
Number of incoming req. (total) | 897096 | 100.0000% | 100.0000% |   0.0000%

Empty or miss. incoming score   |      0 |   0.0000% |   0.0000% | 100.0000%
Reqs with incoming score of   0 | 888984 |  99.0957% |  99.0957% |   0.9043%
Reqs with incoming score of   1 |      0 |   0.0000% |  99.0957% |   0.9043%
Reqs with incoming score of   2 |      3 |   0.0003% |  99.0960% |   0.9040%
Reqs with incoming score of   3 |   1392 |   0.1551% |  99.2512% |   0.7488%
Reqs with incoming score of   4 |      0 |   0.0000% |  99.2512% |   0.7488%
Reqs with incoming score of   5 |    616 |   0.0686% |  99.3199% |   0.6801%
Reqs with incoming score of   6 |      1 |   0.0001% |  99.3200% |   0.6800%
Reqs with incoming score of   7 |      0 |   0.0000% |  99.3200% |   0.6800%
Reqs with incoming score of   8 |     10 |   0.0011% |  99.3211% |   0.6789%
Reqs with incoming score of   9 |      0 |   0.0000% |  99.3211% |   0.6789%
Reqs with incoming score of  10 |   5856 |   0.6527% |  99.9739% |   0.0261%
Reqs with incoming score of  11 |      0 |   0.0000% |  99.9739% |   0.0261%
Reqs with incoming score of  12 |      0 |   0.0000% |  99.9739% |   0.0261%
Reqs with incoming score of  13 |     12 |   0.0013% |  99.9752% |   0.0248%
Reqs with incoming score of  14 |      0 |   0.0000% |  99.9752% |   0.0248%
Reqs with incoming score of  15 |     82 |   0.0091% |  99.9843% |   0.0157%
Reqs with incoming score of  16 |      0 |   0.0000% |  99.9843% |   0.0157%
Reqs with incoming score of  17 |      0 |   0.0000% |  99.9843% |   0.0157%
Reqs with incoming score of  18 |      5 |   0.0005% |  99.9849% |   0.0151%
Reqs with incoming score of  19 |      0 |   0.0000% |  99.9849% |   0.0151%
Reqs with incoming score of  20 |      5 |   0.0005% |  99.9855% |   0.0145%
Reqs with incoming score of  21 |      0 |   0.0000% |  99.9855% |   0.0145%
...
Reqs with incoming score of  29 |      0 |   0.0000% |  99.9855% |   0.0145%
Reqs with incoming score of  30 |    126 |   0.0140% |  99.9995% |   0.0005%
Reqs with incoming score of  31 |      0 |   0.0000% |  99.9995% |   0.0005%
...
Reqs with incoming score of  60 |      4 |   0.0001% |  99.9999% |   0.0001%

Incoming average:   0.0796    Median   0.0000    Standard deviation   0.9168

在这里，我使用了一个名为modsec-positive-stats.rb的脚本，我也在netnea网站上发布了这个脚本。它需要STDIN的异常分数并对它们运行几个统计数据。您可以获得各种百分比，平均分数，中位数甚至标准差。

让我们现在专注于第二列：它给出了传入异常分数的分布。现在我们有了数字，我们可以想象它们：

fixme图形分布

图1.传入请求的异常分数的分布。 Y轴上每个分数的请求数，以对数标度表示。资料来源：O'Reilly。

我们得到一条非常崎岖不平的曲线，在长尾中向右延伸。最高请求数的异常得分为0.这是所有通过规则集而没有任何警报的请求被记录的地方。在此位置右侧是触发一个或多个警报的请求。

我们越靠右，分数越高。你可以说这些是最可疑的请求。左侧更多，分数较低，我们看到仅触发一个或两个规则的请求。也许这些甚至都不是关键规则，但那些具有更多信息的弯曲 - 就像缺少Accept标题等。

如您所知，核心规则集是一种异常评分规则集。请求首先通过所有规则，并计算异常分数。然后，我们将累积的异常分数与异常阈值进行比较。默认阈值为5，这意味着单个关键规则警报将导致阻止请求。这就是我们希望它在安全设置中的方式。

实际上，如果我们愿意，我们可以更改此限制。在整合过程中，这实际上很有意义。如果我们将限制设置为10,000（是的，我在生产系统中看到了10,000分），我们可以确定核心规则集不会阻止任何合法请求。这样，我们可以使用真实数据检查规则集和我们的服务，并开始调整误报。

目标是将异常评分阈值降低到5，但我们不要试图一步完成。最好从10,000到100，然后到50，到20，到10，再到5。

如果我们采取这条道路，那么采取第一步并将异常限制设定为较低值的方法是什么？再看一下图1中的图表。如果我们在该图表中将异常阈值设置为50，我们将以60的分数阻止请求。因此，如果我们想要降低限制，我们会更好地处理这些请求以及所有其他要求得分更高的请求超过目标限制。

我们不需要立即查看大量剩余的误报 - 通常是令人生畏的景象。相反，我们专注于少量具有最高异常分数的请求作为开始。如果我们确定了这些，我们可以过滤导致这些高分的警报。我们可以借助作为ModSecurity警报消息一部分的唯一标识来完成此操作。

$> grep 980145 error.log  | grep "Incoming Anomaly Score: 60\"" | melunique_id > ids

然后使用这些唯一ID来过滤那些导致上述得分的警报：

$> grep -F -f ids error.log | melidmsg | sort | uniq -c | sort -n
  8 941140 XSS Filter - Category 4: Javascript URI Vector
 12 932130 Remote Command Execution: Unix Shell Expression Found
 12 941210 IE XSS Filters - Attack Detected.
 16 941170 NoScript XSS InjectionChecker: Attribute Injection

然后我们可以调整这些误报并使我们能够降低异常阈值，同时高度保证不会阻止合法客户。如果您对此不熟悉，不要急于求成。调整一些误报，然后让调整后的规则集运行几天。

随着时间的推移，您已准备好进行下一次迭代：调整误报，阻止您进一步降低限制。当你看到这些请求时，你会发现一个惊人的发现。第一次调整迭代还减少了您在第二轮中必须检查的请求数。

如果你想一下这一点，那就很有意义了。导致得分最高的许多规则是导致中等分数的相同规则。因此，如果我们处理导致得分最高的第一批规则，则第二次调整迭代只需处理那些在得分最高的请求中不存在的误报。

这整个方法允许您构建规则集的调整以消除误报。看起来像是一个不可逾越的山峰，已经变成了一系列较低的，可行的山丘。您可以逐个使用它们，通常在给定的迭代中解决5到10个误报。 （如果更多，请采取更小的步骤。）

选择正确的误报来处理不再是猜谜游戏，您将能够快速降低异常分数阈值。因此，从降低异常限制的那一刻起，您就可以提高站点的安全性。 （根据我的经验，实质性保护只从20或更低的阈值开始）。

简而言之，调整过程

让我总结一下这种处理误报的方法。我们总是在阻止模式下工作。我们最初将异常阈值设置为一个非常高的数字，并进行多次迭代：

1. 查看具有最高异常分数的请求并处理其误报
2. 将异常分数阈值降低到下一步
3. 冲洗并重复，直到异常评分阈值为5

我通常称之为误报调整的迭代方法。有些人称之为Folini方法，因为我似乎是唯一一个以这种方式使用ModSecurity和CRS教授课程的人。

许多人已经在Apache上以非常成功的方式使用了这种技术多年。我强烈建议您试试NGINX ModSecurity / CRS设置。

 

Links:

• OWASP ModSecurity Core Rule Set (CRS)
• BIG Cheatsheet Download
• Apache / ModSecurity Tutorials
• NGINX Plus Admin Guide and Tutorial

This post is a collaboration between O'Reilly and NGINX. 

See our statement of editorial independence.

 

原文：https://www.oreilly.com/ideas/how-to-tune-your-waf-installation-to-reduce-false-positives

本文：http://pub.intelligentx.net/how-tune-your-waf-installation-reduce-false-positives

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

 

身份和访问管理 (IAM) 是一个业务流程、策略和技术框架，可促进数字身份（人类、设备和应用程序）的管理。从根本上讲，IAM 定义了如何在系统中识别用户、他们拥有什么样的访问权限、提供/取消提供数字身份、保护系统中的数据以及最后保护系统本身。

云托管变得流行，因为它更灵活、可扩展、安全、经济高效和高度可配置。促成这些好处的最大因素是“多租户”。多租户架构为超过 1 个客户提供对云的 4 种基本资源（计算、网络、存储和数据库）的并发共享访问。随着越来越多的监管和合规法律，业务和技术领导者比以往任何时候都更加依赖 IAM 来保护他们——在数据丢失、数据损坏、法律罚款、企业资源访问等方面。

• Basic building blocks of IAM.

上图显示了 IAM 的基本构建块。 这一切都始于“身份元素”，如身份、组等，用于定义“身份模式”，如 DIM、FIM 等，在其上构建“身份协议”，如 oAuth 2.0。 身份元素、IAM 模式和协议都放在一起设计和实施 IAM 云解决方案。 为了进一步阅读，我强烈推荐“Isuru J. Ranawaka”撰写的“云计算中的身份和访问管理”关于每个云工程师应该知道的 97 件事 (redhat.com)

以下是我们可以建立安全企业的安全架构的 8 条指导原则，其中大部分是不言自明的。

• 8 Design Principles of Security Architecture.

总而言之，IAM 解决方案、框架和设计原则可帮助企业满足行业合规要求、隐私法，并帮助他们节省时间和金钱，同时降低业务部门的风险。

原文：https://medium.com/@krishnacavva/enterprise-security-series-part-2-iden…

本文：https://jiagoushi.pro/enterprise-security-series-part-2-identity-and-ac…

令牌身份验证，OAuth或JSON Web令牌的新手？ 这是一个很好的起点！

首先，什么是JSON Web令牌，或JWT（发音为“jot”）？ 简而言之，JWT是用于令牌认证的安全且值得信赖的标准。 JWT允许您使用签名对信息（称为声明）进行数字签名，并且可以在以后使用秘密签名密钥进行验证。

什么是令牌认证？

应用程序确认用户身份的过程称为身份验证。传统上，应用程序通过会话cookie保持身份，这些cookie依赖于服务器端存储的会话ID。在此结构中，开发人员被迫创建独特且特定于服务器的会话存储，或实现为完全独立的会话存储层。

令牌认证是一种更现代的方法，设计解决了服务器端会话ID无法解决的问题。使用令牌代替会话ID可以降低服务器负载，简化权限管理，并提供更好的工具来支持分布式或基于云的基础架构。在此方法中，为用户提供可验证凭据后会生成令牌。初始身份验证可以是用户名/密码凭据，API密钥，甚至来自其他服务的令牌。 （Stormpath的API密钥身份验证功能就是一个例子。）

有兴趣了解更多？查看此博客文章，了解如何使用令牌扩展用户管理或完整的产品文档。

JWT的剖析

如果您在野外遇到JWT，您会注意到它分为三个部分，标题，有效负载和签名。 （随着我们剖析JWT的解剖结构，请关注Stormpath的开源Java JWT工具！）以下是典型JWT的示例：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
.
eyJzdWIiOiJ1c2Vycy9Uek1Vb2NNRjRwIiwibmFtZSI6IlJvYmVydCBUb2tlbiBNYW4 
.
1pVOLQduFWW3muii1LExVBt2TK1-MdRI4QjhKryaDwc

在此示例中，第1节是描述令牌的标头。 第2节是有效载荷，其中包含JWT的声明，第3节是签名散列，可用于验证令牌的完整性（如果您有用于签名的密钥）。

当我们解码有效载荷时，我们得到这个包含JWS声明的漂亮，整洁的JSON对象：

{
 "sub": "users/TzMUocMF4p",
 "name": "Robert Token Man",
 "scope": "self groups/admins",
 "exp": "1300819380"
}

要求(Cliam) 告诉你，至少：

• 这个人是谁以及他们的用户资源的URI（子要求）
• 此人可使用此令牌访问的内容（范围声明）
• 令牌过期时您的API应在验证令牌时使用此功能。

因为令牌是使用密钥签名的，所以您可以验证其签名并隐含地信任所声称的内容。

JWE，JWS和JWT

根据JWT规范，“JWT将一组声明表示为以JWS和/或JWE结构编码的JSON对象。”术语“JWT”在技术上仅描述了无符号标记;我们称之为JWT的通常是JWS或JWS + JWE。

JWS - JSON Web签名

在JWS方案中，服务器对JWT进行签名并使用签名将其发送到客户端。签名保证了JWT要求没有被伪造或篡改。但是，JWT未加密（内容基本上是纯文本）。

JWE - JSON Web加密

另一方面，JWE方案在不签名的情况下加密内容。这为您的JWT带来了机密性，但不是JWE签名和封装JWE的安全性。

什么是OAuth？

OAuth 2.0是与可以委派身份验证或提供授权的服务进行交互的框架。它被广泛用于许多移动和Web应用程序。 OAuth 2.0没有指定令牌格式，但JWT正在迅速成为业界的事实标准。

在OAuth范例中，有两种令牌类型：访问和刷新令牌。首次进行身份验证时，通常会为您的应用程序（以及您的用户）提供两个令牌，但访问令牌设置为在短时间后过期（此持续时间可在应用程序中配置）。初始访问令牌到期后，刷新令牌将允许您的应用程序获取新的访问令牌。刷新令牌具有设置的到期时间，允许无限制地使用，直到达到该到期点。 Access和Refresh Tokens都具有内置安全性（签名时）以防止篡改，并且仅在特定持续时间内有效。

Stormpath使用OAuth，因为它是一个行业标准，任何兼容的库都可以利用它。 Stormpath目前支持三种OAuth的授权类型：

• 密码授予类型：提供基于用户名和密码获取访问令牌的功能
• 刷新授权类型：提供基于特殊刷新令牌生成另一个访问令牌的功能
• 客户端凭据授权类型：提供为访问令牌交换API密钥对的功能。这通过API密钥管理功能得到支持

用Java创建和验证JWT

所以，你在代币上出售，现在，你如何在你的应用程序中使用它们？

好吧，如果你是Java开发人员，你应该从JJWT开始。 JJWT是一个Java库，提供由我们自己的Les Hazlewood开发并由开发人员社区维护的端到端JSON Web令牌创建和验证。永远免费和开源（Apache许可证，版本2.0），它设计了一个以构建者为中心的界面，隐藏了其大部分复杂性。

创建

由于JJWT的流畅界面，JWT的创建基本上分为三个步骤：

令牌的内部声明的定义，如Issuer，Subject，Expiration和ID。

密码签名JWT（制作JWS）

根据JWT Compact Serialization规则，将JWT压缩为URL安全字符串

最终的JWT将是一个由三部分组成的Base64编码字符串，使用提供的密钥使用指定的签名算法进行签名。在此之后，令牌已准备好与另一方共享。

这是使用JJWT库从上面创建JWT的示例：

String jwt = Jwts.builder()
 .setSubject("users/TzMUocMF4p")
 .setExpiration(new Date(1300819380))
 .claim("name", "Robert Token Man")
 .claim("scope", "self groups/admins")
 .signWith(
 SignatureAlgorithm.HS256,
 "secret".getBytes("UTF-8")
 )
 .compact();

证实

一旦拥有JWT，您通常会将其交还给请求它的客户端。 然后，客户端将其存储并将请求中的令牌传递给您的应用程序。 这通常使用HTTP中的cookie值或授权标头来完成。 例如：

HTTP/1.1
 
GET /secure-resource
 
Host: https://yourapplication.com
 
Authorization: Bearer eyJraWQiOiIzMUUzRDZaM0xaMVdFSEJGWVRQRksxRzY4IiwiYWxnIjoiSFMyNTYifQ.eyJqdGkiOiI2a3NjVFMyUjZuYlU3c1R
hZ0h0aWFXIiwiaWF0IjoxNDQ1ODU0Njk0LCJpc3MiOiJodHRwczovL2FwaS5zdG9ybXBhdGguY29tL3YxL2FwcGxpY2F0aW9ucy8zUUlNbEpLS04yd2hHQ1l
6WFh3MXQ4Iiwic3ViIjoiaHR0cHM6Ly9hcGkuc3Rvcm1wYXRoLmNvbS92MS9hY2NvdW50cy8xeG15U0dLMXB5VVc1c25qOENvcmU1IiwiZXhwIjoxNDQ1ODU
4Mjk0LCJydGkiOiI2a3NjVE9pTUNESVZWM05qVTIyUnlTIn0.VJyMOicMOdcOCtytsx4hoPHy3Hl3AfGNfi2ydy8AmG4

验证JWT允许您验证其真实性（通过检查其数字签名，您可以检查它是否已过期并验证它是否未被篡改）并获取有关发送令牌的用户的信息。

以下是验证我们在上面创建的JWT的示例：

String jwt = <jwt passed in from above>
Jws<Claims> claims = Jwts.parser()
 .setSigningKey("secret".getBytes("UTF-8"))
 .parseClaimsJws(jwt)
String scope = claims.getBody().get("scope")
assertEquals(scope, "self groups/admins");

如果签名不正确，则对parseClaimsJws的调用将抛出SignatureException。成功解析后，可以获取并检查单个声明，如下所示：String scope = claims.getBody（）。get（“scope”）。

例外

JJWT在与JWT合作时进行了各种验证。所有与JJWT相关的异常都是RuntimeExceptions，以JwtException作为基类。

这些错误会导致抛出特定异常：

• ClaimJwtException：在验证JWT声明失败后抛出
• ExpiredJwtException：表示JWT在过期后被接受，必须被拒绝
• MalformedJwtException：当JWT未正确构造并且应该被拒绝时抛出
• PrematureJwtException：表示JWT在被允许访问之前被接受，必须被拒绝
• SignatureException：表示计算签名或验证JWT的现有签名失败
• UnsupportedJwtException：在接收到与应用程序预期格式不匹配的特定格式/配置的JWT时抛出。例如，如果在应用程序需要加密签名的声明JWS时解析无符号明文JWT，则会抛出此异常
• JJWT使用了许多其他Exception类。它们都可以在JJWT源代码中的io.jsonwebtoken包中找到。

令牌安全吗？

这里真正的问题是，你安全地使用它们吗？在Stormpath，我们遵循这些最佳实践，并鼓励我们的客户也这样做：

• 将您的JWT存储在安全的HttpOnly cookie中。这可以防止跨站点脚本（XSS）攻击。
• 如果您使用cookie来传输JWT，CSRF保护非常重要！未经用户同意，向您的网站提出请求的其他域名可能会恶意使用您的Cookie。如果您的服务器盲目地对用户进行身份验证，只是因为他们有cookie，那么您遇到的问题比硬盘驱动器大。您还允许进行CSRF攻击，其他网站会在未经用户同意的情况下触发您服务器上的状态更改操作。这是可能的，因为浏览器将始终自动发送用户的cookie，无论请求是如何被触发的。使用众多CSRF预防措施之一来降低此风险。
• 使用仅可用于身份验证服务的强密钥对您的令牌进行签名。每次使用令牌对用户进行身份验证时，您的服务器必须验证令牌是否已使用您的密钥签名。
• 不要将任何敏感数据存储在JWT中。这些令牌通常被签名以防止操纵（未加密），因此可以容易地解码和读取权利要求中的数据。如果您必须在其中放入敏感的，不透明的信息，请加密您的令牌。秘密签名密钥只能由发行方和消费者访问;它不应该在这两方之外进行。
• 如果您担心重播攻击，请在声明中包含nonce（jti声明），到期时间（exp声明）和创建时间（ifat声明）。这些在JWT规范中有明确定义。

JJWT，JSONWebToken.io和JWT Inspector

Stormpath支持开发几个与JWT相关的开源开发人员工具，包括：

JJWT

JJWT是一个易于使用的工具，供开发人员用Java创建和验证JWT。在Stormpath支持的许多库中，JJWT是完全免费和开源的（Apache License，Version 2.0），因此每个人都可以看到它的作用以及它是如何做到的。不要犹豫，报告任何问题，建议改进，甚至提交一些代码！

JSONWebToken.io

JSONwebtoken.io是我们创建的一个开发工具，可以轻松解码JWT。将现有JWT简单粘贴到适当的字段中以解码其标头，有效负载和签名。 JSONWebToken.io由nJWT提供支持，nJWT是Node.js开发人员最干净的免费和开源（Apache License，Version 2.0）JWT库。

JWT检查器

JWT Inspector是一个开源的Chrome扩展程序，允许开发人员直接在浏览器中检查和调试JWT。 JWT Inspector将在您的站点上发现JWT（在cookie，本地/会话存储和标题中），并通过导航栏和DevTools面板轻松访问它们。

想要了解有关JWT，令牌认证或用户身份管理的更多信息？以下是我们团队的一些进一步资源：

• 单页应用程序的令牌认证
• 使用Spring Boot和Stormpath进行OAuth令牌管理
• Java应用程序的令牌认证
• 使用JSON Web令牌构建安全的用户界面
• OAuth不是单点登录

Java对JWT（JSON Web Tokens）的支持过去需要大量的工作：广泛的自定义，几小时的解析依赖关系，以及仅用于组装简单JWT的代码页。不再！

本教程将向您展示如何使用现有的JWT库来做两件事：

• 生成JWT
• 解码并验证JWT

您会注意到该教程非常简短。那是因为它很容易。如果您想深入挖掘，请查看JWT规范或深入了解有关在Spring Boot应用程序中使用JWT进行令牌身份验证的更长篇文章。

什么是JWT？

JSON Web令牌是用于以紧凑和安全的方式在各方之间发送信息的JSON对象。 JSON规范或Javascript Object Notation定义了一种使用键值对创建纯文本对象的方法。它是构建基于原始类型（数字，字符串等）的数据的紧凑方式。你可能已经非常熟悉JSON了。它就像没有所有括号的XML。

令牌可用于在各方之间发送任意状态。通常这里“聚会”表示客户端Web应用程序和服务器。 JWT有许多用途：身份验证机制，URL安全编码，安全共享私有数据，互操作性，数据到期等。

实际上，这些信息通常涉及两件事：授权和会话状态。服务器可以使用JWT告诉客户端应用程序允许用户执行哪些操作（或允许他们访问哪些数据）。

JWT通常还用于存储Web会话的依赖于状态的用户数据。因为JWT在客户端应用程序和服务器之间来回传递，这意味着状态数据不必存储在某个数据库中（并随后在每个请求中检索）;因此，它可以很好地扩展。

让我们来看一个示例JWT（取自jsonwebtoken.io）

 

JWT有三个部分：标题，正文和签名。标题包含有关如何编码JWT的信息。身体是令牌的肉（声称存在的地方）。签名提供安全性。

关于如何编码令牌以及如何将信息存储在正文中，我们将不会详细介绍这些细节。如果需要，请查看前面提到的教程。

不要忘记：加密签名不​​提供机密性;它们只是一种检测篡改JWT的方法，除非JWT是专门加密的，否则它们是公开可见的。签名只是提供了一种验证内容的安全方法。

大。得到它了？现在你需要用JJWT制作一个令牌！在本教程中，我们使用的是现有的JWT库。 Java JWT（a.k.a.，JJWT）由Les Hazlewood创建（Apache Shiro的前任提交者，Stormpath的前联合创始人兼首席技术官，目前是Okta自己的高级架构师），JJWT是一个简化JWT创建和验证的Java库。它完全基于JWT，JWS，JWE，JWK和JWA RFC规范以及Apache 2.0许可条款下的开源。该库还为规范添加了一些不错的功能，例如JWT压缩和声明实施。

用Java生成令牌

这部分超级简单。我们来看一些代码吧。克隆GitHub仓库：

git clone https://github.com/oktadeveloper/okta-java-jwt-example.git 
 cd okta-java-jwt-example

这个例子非常基本，包含一个带有两个静态方法的src / main / java / JWTDemo.java类文件：createJWT（）和decodeJWT（）。 狡猾的是，这两种方法创建了JWT并解码了JWT。 看看下面的第一种方法。

public static String createJWT(String id, String issuer, String subject, long ttlMillis) {
 
 //The JWT signature algorithm we will be using to sign the token
 SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
 long nowMillis = System.currentTimeMillis();
 Date now = new Date(nowMillis);
 //We will sign our JWT with our ApiKey secret
 byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(SECRET_KEY);
 Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
 //Let's set the JWT Claims
 JwtBuilder builder = Jwts.builder().setId(id)
 .setIssuedAt(now)
 .setSubject(subject)
 .setIssuer(issuer)
 .signWith(signatureAlgorithm, signingKey);
 
 //if it has been specified, let's add the expiration
 if (ttlMillis > 0) {
 long expMillis = nowMillis + ttlMillis;
 Date exp = new Date(expMillis);
 builder.setExpiration(exp);
 } 
 
 //Builds the JWT and serializes it to a compact, URL-safe string
 return builder.compact();
}

总而言之，createJWT（）方法执行以下操作：

1. 设置散列算法
2. 获取Issued At声明的当前日期
3. 使用SECRET_KEY静态属性生成签名密钥
4. 使用流畅的API添加声明并签署JWT
5. 设置到期日期

这可以根据您的需求进行定制。 例如，如果您要添加不同或自定义声明。

解码令牌

现在来看看更简单的decodeJWT（）方法。

public static Claims decodeJWT(String jwt) {
 //This line will throw an exception if it is not a signed JWS (as expected)
 Claims claims = Jwts.parser()
 .setSigningKey(DatatypeConverter.parseBase64Binary(SECRET_KEY))
 .parseClaimsJws(jwt).getBody();
 return claims;
}

该方法再次使用静态SECRET_KEY属性生成签名密钥，并使用它来验证JWT是否未被篡改。 如果签名与令牌不匹配，则该方法将抛出io.jsonwebtoken.SignatureException异常。 如果签名匹配，则该方法将声明作为声明对象返回。

这就是它！

运行JUnit测试

为了额外的功劳，您可以在示例项目中运行JUnit测试。 有三个测试，它们展示了JJWT库的一些基本功能。 第一个测试显示了快乐路径，创建并成功解码了有效的JWT。 第二个测试显示当您尝试将完全伪造的字符串解码为JWT时JJWT库将如何失败。 最后一个测试显示了被篡改的JJWT将如何导致decodeJWT（）方法抛出SignatureException。

您可以使用以下命令从命令行运行这些测试：

./gradlew test -i

-i是将Gradle的日志级别设置为Info，以便我们从测试中看到简单的日志记录输出。

了解有关在Java应用程序中使用JWT的更多信息

JJWT库使得创建和验证JWT变得非常容易。只需指定一个密钥和一些声明，你就有了一个JJWT。稍后，使用相同的密钥对JJWT进行解码并验证其内容。

创建和使用JJWT现在非常简单，为什么不使用它们？

不要忘记SSL！请记住，除非JWT加密，否则其中编码的信息通常只有Base64编码，任何小孩和一些宠物都可以阅读。因此，除非您希望中国，俄罗斯和FBI读取您的所有会话数据，否则请使用SSL对其进行加密。

Baeldung在Java和JWT方面有很好的深度教程。

此外，以下是来自Okta博客的更多链接，以便您继续：

• Java应用程序的简单令牌认证
• 开始使用Spring Boot，OAuth 2.0和Okta
• 10种保护Spring Boot应用程序的绝佳方法
• 如果您的JWT被盗，会发生什么？
• JWT分析仪和Inspector Chrom插件
• 在线编码或解码JWT

 

 

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

描述

安全地处理错误是安全编码的一个关键方面。有两种类型的错误需要特别注意。第一个是在处理安全控制本身时发生的异常。重要的是，这些异常不会启用对策通常不允许的行为。作为开发人员，您应该考虑安全机制通常有三种可能的结果：

• 允许操作
• 禁止操作
• 例外

通常，您应该设计安全机制，以便故障将遵循与禁止操作相同的执行路径。例如，如果在处理期间存在异常，则isAuthorized（），isAuthenticated（）和validate（）等安全方法都应返回false。如果安全控制可以抛出异常，那么它们必须非常清楚该条件的确切含义。

另一种类型的安全相关异常是在不属于安全控制的代码中。如果它们影响应用程序是否正确调用控件，则这些异常与安全性相关。异常可能导致安全方法在不应该被调用时，或者它可能会影响安全控件中使用的变量的初始化。

例子

isAdmin

isAdmin = true; 
try { 
  codeWhichMayFail(); 
  isAdmin = isUserInRole( “Administrator” ); 
}
catch (Exception ex)
{
  log.write(ex.toString()); 
} 

如果codeWhichMayFail（）失败，则默认情况下用户是管理员。这显然是一种安全风险。在这种情况下，修复很简单。它涉及简单的逻辑反转。在示例实例中，这很容易做到。

isAdmin = false;
try {
  codeWhichMayFail();
  isAdmin = isUserInrole( "Administrator" );
}
catch (Exception ex)
{
  log.write(ex.toString());
}

此示例也是最低权限原则的示例，该原则声明您永远不应授予超出要求的访问权限。如果codeWhichmayFail（）需要管理员访问权限，我们应该在运行该代码之前验证管理员访问权限。

相关漏洞

• Vulnerability 1

相关控制

• Error handling

相关原则

• Least privilege

参考

https://buildsecurityin.us-cert.gov/articles/knowledge/principles/faili…

 

讨论：加入知识星球【首席架构师圈】

Spring Boot极大地简化了Spring应用程序的开发。它的自动配置和启动器依赖关系减少了启动应用程序所需的代码和配置量。

Spring Boot于2014年首次发布，自那以后发生了很多变化。就像代码质量和测试一样，安全性已经成为开发人员关注的问题。如果您是一名开发人员，并且不关心安全性，那么您可能认为您应该关心安全性。本文的目的是向您介绍如何创建更安全的Spring引导应用程序。

我与Simon Maple合作撰写了这篇文章，他是斯奈德的Java冠军和开发人员关系主管。我们都为安全行业的公司工作，热爱Java，并希望帮助开发人员创建更安全的应用程序。我们认为写这篇文章将是一个回馈社区的有趣方式。如果您对我们列出的有其他建议，请在评论中添加!

1. 在生产中使用HTTPS

传输层安全性(TLS)是HTTPS的官方名称。您可能听说过它被称为SSL(安全套接字层)。SSL是不推荐的名称。TLS是一种通过计算机网络提供安全通信的加密协议。它的主要目标是确保计算机应用程序之间的隐私和数据完整性。

TLS/SSL证书过去很昂贵，HTTPS被认为很慢。机器变得更快，解决了性能问题，让我们加密提供免费的TLS证书。这两个发展已经改变了游戏，并使TLS成为主流。

自2018年7月24日起，谷歌Chrome浏览器将HTTP站点标记为“不安全”。虽然这在web社区中引起了相当多的争议，但它仍然存在。特洛伊亨特，一位著名的安全研究员，创造了一个为什么没有HTTPS?跟踪不使用HTTPS的大型网站的站点。你可能不会开发下一个主要的网站，但是为什么要限制自己呢?

生成和更新Let 's加密的TLS证书可以实现自动化。既然他们是免费的，就没有理由不去做!Let 's Encrypt保护的Spring引导是关于如何做到这一点的有用指南。

要在Spring Boot应用程序中强制使用HTTPS，可以扩展WebSecurityConfigurerAdapter并要求安全连接。

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.requiresChannel().requiresSecure();
 }
}

此配置还将强制HTTPS进入开发，这可能会带来麻烦，因为您必须使用自签名证书。如果使用Heroku、Cloud Foundry或其他云提供商，更合理的配置是寻找x - forward - proto头文件。

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.requiresChannel()
 .requestMatchers(r -> r.getHeader("X-Forwarded-Proto") != null)
 .requiresSecure();
 }
}

云提供商可以极大地简化TLS证书。Amazon证书管理器与Let 's加密完全一样，只是默认情况下它内置在所有AWS产品/服务中。它允许您提供100%免费的SSL证书，并处理自动更新等，几乎不需要任何工作/配置。Heroku也有自动的证书管理。

另一个要做的重要事情是使用HTTP严格传输安全(HSTS)。HSTS是一种web安全策略机制，用于保护网站免受协议降级攻击和cookie劫持。服务器使用名为Strict-Transport-Security的响应头字段将HSTS策略与浏览器通信。Spring Security在缺省情况下发送此头，以避免在开始时不必要的HTTP跳转。

2. 使用斯奈德(Snyk)检查依赖

您很可能不知道应用程序使用了多少直接依赖项。您极有可能不知道应用程序使用了多少传递依赖项。这通常是正确的，尽管依赖关系构成了整个应用程序的大部分。攻击者越来越多地瞄准开源依赖关系，因为它们的重用为恶意黑客提供了许多受害者。确保应用程序的整个依赖树中没有已知的漏洞是很重要的。

斯奈德测试你的应用程序构建构件，标记那些已知漏洞的依赖关系。它为您提供了一个存在于您的应用程序中用作仪表板的包中的漏洞列表。

此外，它将建议升级版本或提供补丁，通过对源代码存储库发出拉请求来修复安全性问题。snyder还保护您的环境，通过确保将来在您的存储库中提出的任何pull请求都被自动测试(通过webhook)，以确保它们不会引入新的已知漏洞。

每天都会在现有的项目和库中发现新的漏洞，因此监视和保护生产部署非常重要。斯奈德会拍快照并监控你的部署，这样当发现新的漏洞时，你可以通过你喜欢的频道，JIRA, slack或电子邮件自动通知你，并创建拉请求来为新的漏洞提供升级和补丁。

snyder k通过web UI和CLI可用，因此您可以轻松地将其集成到CI环境中，并在漏洞严重程度超过设置阈值时配置它来破坏构建。

你可以免费使用斯奈德的开源项目或私人项目，每月测试的次数有限。

3.升级到最新版本

定期升级应用程序中的依赖项有多种原因。安全性是促使您进行升级的最重要原因之一。start.spring。io starter页面尽可能使用最新版本的Spring包以及依赖项。

“我发现，在依赖关系中寻找漏洞可能有助于激励人们进行升级。然而，有大量证据表明，并不是所有的cve都被报道。一般来说，我发现理想的解决方案(可能不实用)是最新的和最好的。——Rob Winch

基础设施升级的破坏性通常小于依赖项升级，因为库的作者对向后兼容性和版本之间的行为变化的敏感性不同。也就是说，当您在配置中发现安全漏洞时，您有三个选项:升级、补丁或忽略。

升级是最安全的，就应用程序的整体健康而言，在您对应用程序进行任何必要的更改以使用新版本之后。

脆弱项目的补丁将从包中消除该漏洞，但通常会留下一个配置，该配置可能没有经过很好的测试。对库的代码更改会更少，因为补丁只会更改易受攻击的代码，所以破坏向后兼容性或引入行为更改的几率会降低。第三方安全公司，如斯奈德手工修补了许多漏洞，所以如果不能升级到一个新的版本的库，你仍然可以使用旧版本的补丁。

忽略漏洞当然是一种选择，但不是一个好的选择。也许您知道某个漏洞，但是不相信它是可以直接利用的。请记住，它现在可能不在您的应用程序流中，但是在某个时候，开发人员可能会添加使用脆弱路径的额外代码。

4. 使CSRF保护

跨站点请求伪造是一种攻击，它迫使用户在当前登录的应用程序中执行不需要的操作。如果用户是普通用户，则成功的攻击可能涉及状态更改请求，如转移资金或更改电子邮件地址。如果用户拥有更高的权限，CSRF攻击可能危及整个应用程序。

Spring Security默认支持优秀的CSRF。如果您使用Spring MVC的标记或Thymeleaf和@EnableWebSecurity, CSRF令牌将自动添加为一个隐藏的输入字段。

如果您正在使用像Angular或React这样的JavaScript框架，则需要配置CookieCsrfTokenRepository，以便JavaScript能够读取cookie。

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http
 .csrf()
 .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
 }
}

如果你使用Angular，这就是你需要做的。如果使用React，则需要读取XSRF-TOKEN cookie并将其作为X-XSRF-TOKEN头发送回去。

当通过HTTPS发出请求时，Spring Security会自动向XSRF-TOKEN cookie添加一个安全标志。Spring Security对CSRF cookie不使用SameSite=strict标志，但在使用Spring会话或WebFlux会话处理时使用。这对于会话cookie是有意义的，因为它被用来标识用户。它没有为CSRF cookie提供太多的价值，因为CSRF令牌也需要在请求中。

5. 使用内容安全策略来防止XSS攻击

内容安全策略(CSP)是一种附加的安全层，有助于减轻跨站点脚本攻击和数据注入攻击。要启用它，您需要将应用程序配置为返回Content-Security-Policy头。还可以在HTML页面中使用标记。

Spring security在默认情况下提供了许多安全头:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Spring Security默认情况下不添加CSP。您可以使用下面的配置在Spring Boot应用程序中启用CSP头。

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.headers()
 .contentSecurityPolicy("script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/");
 }
}

CSP是防止XSS攻击的一种很好的防御手段。请记住，打开您的CSP以允许使用CDN通常会允许访问许多非常古老和脆弱的JavaScript库。这意味着使用CDN通常意味着您不再为应用程序的安全性增加很多价值。

您可以使用securityheaders.com测试您的CSP头文件。

6. 使用OpenID Connect进行身份验证

OAuth 2.0是用于授权的行业标准协议。它使用范围来定义授权用户可以执行哪些操作的权限。但是，OAuth 2.0不是一个身份验证协议，它不提供关于经过身份验证的用户的任何信息。

OpenID Connect (OIDC)是一个提供用户信息的OAuth 2.0扩展。除了访问令牌之外，它还添加了ID令牌，以及/userinfo端点，您可以从该端点获得附加信息。它还添加了端点发现特性和动态客户端注册。

下图显示了OIDC如何进行身份验证。

如果使用OIDC进行身份验证，就不必担心存储用户、密码或身份验证用户。相反，您将使用标识提供程序(IdP)为您完成这项工作。您的IdP甚至可能提供安全附加组件，比如多因素身份验证(multi-factor authentication, MFA)。

要了解如何在Spring引导应用程序中使用OIDC，请参阅Spring Security 5.0和OIDC入门。要总结如何使用它，您需要向项目添加一些依赖项，然后在应用程序中配置一些属性。yml文件。

spring:
 security:
 oauth2:
 client:
 registration:
 okta:
 client-id: {clientId}
 client-secret: {clientSecret}
 scope: openid email profile
 provider:
 okta:
 issuer-uri: https://{yourOktaDomain}/oauth2/default

注意:使用发布器uri只在Spring Security 5.1中得到支持，Spring Security 5.1正在积极开发中，计划于2018年9月发布。

您可以使用像Keycloak这样的开源系统来设置自己的OIDC服务器。如果您不希望在生产中维护自己的服务器，可以使用Okta的开发人员api。今天注册一个免费帐户，每月在developer.okta.com/signup上获得1000个活跃用户!

如果您想使用OAuth 2.0、OIDC以及它所允许的不同流，请参见https://www.oauth.com/playground。这个站点不需要您创建帐户，但是它确实在幕后使用了Okta的开发人员api。

7. 管理密码吗?使用密码散列!

对于应用程序的安全性来说，用纯文本存储密码是最糟糕的做法之一。幸运的是，Spring security默认不允许使用纯文本密码。它还附带一个加密模块，您可以使用该模块进行对称加密、密钥生成和密码散列(也称为密码散列)。、密码编码)。

PasswordEncoder是Spring Security中密码散列的主要接口，其外观如下:

public interface PasswordEncoder {
 String encode(String rawPassword);
 boolean matches(String rawPassword, String encodedPassword);
}

Pbkdf2PasswordEncoder。

对于一般的密码管理，我们建议使用SCrypt或Argon2。SCrypt现在很老了(已经有一段时间了)，并且有一个BCrypt没有的额外复杂性因素，这使得使用蛮力变得更加困难/昂贵。它由著名的密码学者/安全专家(Colin Percival)编写，几乎每种编程语言都有很棒的库。SCrypt也得到了Latacora的认可。

Okta开发人员关系团队的密码学专家Randall Degges说:

Argon2相对较新(现在已经有几年的历史了)，但是已经得到了广泛的审计/审查，并且是许多组织在几年的过程中参与的密码散列挑战的结果。毫无疑问，它们中“最强”的哈希算法增加了scrypt所没有的另一层复杂性，这使得与scrypt相比，使用暴力的代价要高得多/困难得多。Argon2非常棒，我已经在好几种语言中成功地使用了它，但是如果您担心过于尖端的scrypt是一个安全的选择，而且没有争议。

From Rob Winch, Spring Security Lead:

“我喜欢BCrypt，但一般的建议是单向自适应散列。出于遵从性的原因，一些用户可能需要使用PBKDF2。有一个Argon2支持的票据记录，但是我没有找到任何Apache 2原生Java实现(如果您知道任何实现，请让我知道!)相反，库依赖于它们委托给的二进制文件，在我看来这并不理想。对于等待还是利用委托给二进制的实现之一，我们持观望态度。”

对于那些希望使用SCrypt的用户，在SCryptPasswordEncoder中有通过Bouncy Castle实现Spring安全性的支持。Spring Security 5.1 (est. 2018年9月下旬)将附带一个UserDetailsPasswordService API，允许您升级密码存储。

8. 存储机密安全

密码、访问令牌等敏感信息应谨慎处理。您不能将它们放在周围，不能以纯文本形式传递它们，或者如果将它们保存在本地存储中，则不能进行预测。正如(GitHub)的历史一次又一次地证明，开发人员对于如何存储他们的秘密考虑得不够仔细。

当然，您可以也应该加密您的敏感数据，比如密码。现在您的密码是安全的，您有一个新的秘密，您的解密密钥!你打算怎么处理这个新秘密?也许在本地存储?也许在另一个地方，某个你认为攻击者很难找到它的地方。这并不能解决问题;它只是推迟了它。如果没有适当的程序，黑客想要破解你的秘密只会稍微困难一点。

一个好的实践是将秘密存储在一个保险库中，该保险库可用于存储、提供对应用程序可能使用的服务的访问，甚至生成凭据。HashiCorp的Vault使得存储秘密变得微不足道，同时还提供了许多额外的服务。Vault可以配置为不允许任何人访问所有数据，从而不提供单一的控制点。根密钥库定期使用更改，并且只存储在内存中。有一个主开关，当触发时将密封你的保险库，阻止它分享秘密，如果发生问题。Vault使用被分配给策略的令牌，这些策略可以作用于特定的用户、服务或应用程序。还可以与常见的身份验证机制(如LDAP)集成以获得令牌。

除了不存在问题的gold -path视图之外，Vault还帮助您处理被黑客攻击时存在的场景。此时，重要的是撤销单个或多个秘密，可能由特定用户或特定类型的用户来撤销。Vault提供了一种自动化的方法，当时机成熟时，可以快速完成这项工作。

如果您对此感兴趣，请务必花一些时间研究Spring Vault，它在HashiCorp Vault上添加了一个抽象，为客户端提供基于Spring注释的访问，允许他们访问、存储和撤销机密，而不会在基础设施中丢失。下面的代码片段显示了使用注释从Spring Vault提取密码是多么容易。

@Value("${password}")

String password;

9. 使用OWASP的ZAP测试您的应用程序

OWASP ZAP安全工具是一个代理，它在运行时对您的活动应用程序执行渗透测试。这是一个流行的(超过4k明星)免费开源项目，托管在GitHub上。

OWASP ZAP用于发现漏洞的两种方法是Spider和Active Scan。Spider工具从url种子开始，它将通过每个响应访问和解析url种子，识别超链接并将它们添加到列表中。然后，它将访问这些新发现的url并递归地继续，为web应用程序创建url映射。活动扫描工具将自动测试您所选择的目标，针对一系列潜在的漏洞。它向您提供了一个报告，显示您的web应用程序可以在何处被利用，以及关于该漏洞的详细信息。

10. 您的安全团队是否进行了代码评审

代码评审对于任何高性能的软件开发团队都是必不可少的。在Okta，我们所有的生产代码和官方开源项目都需要经过专家安全团队的分析。您的公司可能没有安全专家，但是如果您正在处理敏感数据，那么您应该这样做!

不要让你的缺乏安全感成为困扰

Okta有一些很棒的t恤，上面写着“我发现你缺乏安全保障，令人不安”。当我们在机场旅行时，我们喜欢听到乳胶手套被戴上的声音。不要成为在Spring引导应用程序中缺乏安全性的开发人员!

我发现你缺乏安全保障令人不安

要了解更多关于Spring引导和应用程序中的安全性，请参阅以下教程和文章:

1. 开始使用Spring Security 5.0和OIDC
2. 使用React和Spring Boot构建一个简单的CRUD应用程序
3. 使用Spring Security和Thymeleaf将基于角色的访问控制添加到您的应用程序中
4. 安全性和API之旅
5. 准备在Heroku上生产一个Spring Boot应用程序

应用程序安全性是一个移动目标业务需求和对速度的需求促使许多开发组织快速，持续地发布软件，并以牺牲安全性为代价。虽然越来越多的组织已开始采用自动化测试和DevSecOps方法来解决其中一些问题，但应用程序安全状态仍然是大多数企业主要关注的领域。

以下是32个数据点的集合，可提供当前应用程序安全性的快照。我们收集了各种分析报告，供应商调查和研究报告中的统计数据，涵盖了围绕应用程序安全性的最重要趋势和实践。

以下是数字的应用程序安全性。

85.1：可以在外部轻松发现且访问不当的应用程序的平均数量

可以在黑暗网络上访问属于金融时报（FT）500列表中70％公司的网站，因为这些应用程序不受强身份验证和其他访问控制措施的保护。

资料来源：被遗弃的网络应用：英国“金融时报”500强企业的致命弱点，高科技桥梁安全研究

92％：具有可被利用的安全漏洞或弱点的Web应用程序的百分比

大约16.2％的美国公司拥有两个或更多外部Web应用程序，允许通过Web表单输入个人身份信息（PII），并运行易受攻击的SSL / TLS版本，有时还有其他Web软件的过时和易受攻击的版本。

资料来源：被遗弃的网络应用：英国“金融时报”500强企业的致命弱点，高科技桥梁安全研究

 

66％：组织经历过应用层DDoS攻击的IT高管比例

来自2018年调查的790名高管中超过一半（56％）表示，他们必须每月更换面向公众的应用程序，以应对安全威胁。其余的更改了Web应用程序。

资料来源：2018-2019全球应用与网络安全报告，Radware

13：通过DAST找到的构建公司网站上的平均漏洞数量

在使用动态应用程序安全性测试发现的漏洞中，平均有五个是严重的。金融，零售和医疗保健 - 在最具针对性的行业中 - 具有较少的严重漏洞，其网站平均分别为1.6,2.7和1.7。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

86％：具有一个或多个会话管理漏洞的已测试应用程序的百分比

由于输入验证错误（例如未能清理用户输入或未正确验证它），攻击者能够在大量情况下劫持或窃听用户会话。这是第二种最常见的错误类型，59％的测试应用程序具有一个或多个错误。

资料来源：2018年Trustwave全球安全报告

16％：中等，高或严重风险的测试应用程序中的安全漏洞百分比

在渗透测试期间发现的最常见的高风险漏洞是跨站点脚本错误，默认凭据使用和垂直权限提升漏洞。

资料来源：2018年Trustwave全球安全报告

19,954：2017年来自259家供应商的1,865份应用程序检测到的漏洞总数

这个数字比2016年发现的17,147个缺陷增加了14％，与五年前相比增长了38％。

来源：漏洞评论2018年，Flexera软件

14：2017年报告的零日漏洞总数

在披露之前利用漏洞的零日漏洞数量比2016年的23个零日漏洞减少了近40％。零日攻击可能造成重大损失，但数据显示它们仍然是一种罕见的威胁。

来源：漏洞评论2018年，Flexera软件

86％：在披露后24小时内提供补丁的漏洞百分比

补丁可用性的速度使组织有更多机会在2017年被利用之前修复严重且影响较大的应用程序漏洞。这一转变标志着2016年增加了5个百分点。

来源：漏洞评论2018年，Flexera软件

38：无论严重性如何，修补Web应用程序漏洞所需的平均天数

通常，企业需要54天来修补低严重性漏洞，花34天时间修复2018年第二季度的高严重性漏洞，平均需要38天才能修补Web应用程序漏洞，无论严重程度如何。

来源：生产中Web应用程序的安全报告，tCell

70％：由开源软件，第三方库等组成的应用程序中的代码比例。

开源软件，第三方库和其他可重用组件中的严重漏洞数量继续增加，使得不采用跟踪第三方组件使用措施的团队几乎不可能进行补救。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

45％：在DAST期间发现的导致信息泄漏的漏洞百分比

在动态应用程序安全测试期间发现的漏洞几乎有一半导致数据泄露。其他三个最可能的DAST漏洞是内容欺骗（40％），跨站点脚本（38％）和传输层保护不足（23％）。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

44％：组织发现主要存在Nessus缺陷的受访者的百分比

在本次调查中，有437名受访者表示，他们的组织主要通过Nessus发现应用程序漏洞。该数字比任何其他漏洞评估产品或工具高20分。

资料来源：2018年应用安全报告，网络安全内部人员

70％：主要进行笔测试以测试安全控制有效性的组织的百分比

虽然七分之一的人说进行渗透测试的主要原因是验证其安全控制的有效性，但十分之六的人使用笔测试来识别可能被攻击者利用的弱点。大约一半是为了满足法规或合规要求。

资料来源：2018年网络安全和渗透测试调查，由Decision Analyst主持并由SecureAuth + Core Security委托

84％：使用红色和蓝色团队安全测试的组织的百分比

在笔测试中，超过八成的组织使用红色和蓝色团队安全测试，因为他们认为这些方法是有效的。与小型公司相比，中型和大型公司更倾向于进行渗透测试。

资料来源：2018年网络安全和渗透测试调查，由Decision Analyst主持并由SecureAuth + Core Security委托

16％：组织不进行任何渗透测试的IT决策者的比例

在202名IT决策者的调查中，大约六分之一的受访者表示，他们所代表的组织不会进行任何渗透测试，或者如果他们这样做则不知道。 6％的人每年不到一次，75％的人表示他们的组织每年进行几次笔测试。

资料来源：2018年网络安全和渗透测试调查，由Decision Analyst主持并由SecureAuth + Core Security委托

31％：因开源而遭受破坏的组织的百分比

在对2,076名IT专业人员进行的调查中，近三分之一的受访者表示，他们的组织在其软件中遇到了与易受攻击的开源组件相关的漏洞。这个数字比2017年增加了55％。

资料来源：2018年DevSecOps社区调查，SonaType

38％：拥有软件中所有组件的完整物料清单的公司比例

不到四分之一的组织拥有完整的材料清单，用于其软件产品中的所有组件。近三分之二（62％）的人无法控制其应用中使用的组件。

资料来源：2018年DevSecOps社区调查，SonaType

48％：缺乏时间花在他们认为重要的安全问题上的开发人员的百分比

近一半的开发人员表示他们没有足够的时间花在安全上，即使他们意识到它的重要性。

资料来源：2018年DevSecOps社区调查，SonaType

37％：执行DevOps的组织的百分比，他们说静态应用程序分析工具至关重要

虽然有近四分之一的公司拥有成熟的DevOps实践，但静态分析工具至关重要，但只有12％没有DevOps实践的组织表示同样的事情。大约三分之一（33％）拥有成熟DevOps的组织使用动态分析工具，而只有8％的组织没有采用DevOps。

资料来源：2018年DevSecOps社区调查，SonaType

21％：通过SAST发现的与未修补的库相关的漏洞的比例

虽然通过静态应用程序安全性测试发现的近四分之一的缺陷与未修补的库有关，但在SAST期间发现的其他常见漏洞类包括应用程序配置错误（10.5％），跨站点脚本（8.3％）和明文密码（6.5％） ）。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

28％：拥有应用程序安全风险管理流程的CIO和CTO的百分比

虽然超过四分之一的C级高管负责应用风险，但首席信息安全官（CISO）仅在10％的组织中承担责任 - 尽管他们通常是第一个受到指责的人。安全漏洞。

资料来源：2018年应用保护报告，F5实验室

13％：访问问题和攻击导致的Web应用程序违规比例

在2017年和2018年第一季度，与访问相关的问题引发了十分之一的问题。此类问题的示例包括访问控制错误配置，强力密码破解以及来自被盗密码的凭据填充。

资料来源：2018年应用保护报告，F5实验室

52％：使用第三方组件的开发人员在披露漏洞时更新的百分比

在披露新的安全漏洞时，大约一半在其应用程序中使用第三方组件的开发人员更新组件。其中近一半的人不会更新已知的易受攻击的组件，从而使应用程序面临不必要的风险。

来源：由Veracode委托的Vanson Bourne DevSecOps调查报告

71％：表示公司有正式的应用程序计划的开发人员的比例

在2018年对400名开发人员的调查中，25％的人表示他们的组织没有应用程序安全计划，4％的人表示他们不知道他们的组织是否有一个。

来源：由Veracode委托的Vanson Bourne DevSecOps调查报告

19％：不熟悉OWASP Top 10的开发人员比例

近五分之一的开发人员表示他们根本不熟悉十大OWASP应用安全风险。几乎四分之一（22％）的软件设计师并不熟悉，相比之下，20％的团队领导者和10％的团队经理都不熟悉。

来源：由Veracode委托的Vanson Bourne DevSecOps调查报告

90％：OWASP Top 10未涵盖至少一个缺陷的应用程序的百分比

10个应用程序中有9个至少有一个OWASP Top 10未解决的安全漏洞。几乎一半（49％）的测试应用程序有一个或多个严重或高严重性的安全漏洞，OWASP Top 10未涵盖这些漏洞。

资料来源：2018年应用安全研究更新，Micro Focus Fortify软件安全研究团队

70亿美元：到2023年估计的应用程序安全市场规模

安全扫描工具的企业支出将在不久之后增加一倍以上，并为增长带来很多动力。

资料来源：Forrester Research

25％：表示其组织的应用程序支出的IT和安全团队的百分比是足够的

四分之一的组织在对1,400名IT和安全从业者的调查中表示，他们的组织正在充分利用应用程序安全性。近一半（48％）的业务经理认为应用程序性能和速度比安全性更重要。

资料来源：2018年全球应用安全研究，Arxan Technologies

65％：如果客户受到影响，将增加app sec的公司比例

只有当客户或最终用户在违规行为中受到负面影响时，才有超过六家公司会增加应用安全支出。尽管事实上近四分之三的组织可能，最有可能或肯定在过去的12个月内遇到过与应用程序相关的网络攻击或漏洞。

资料来源：2018年全球应用安全研究，Arxan Technologies

45％：面临已知但未修补的云应用程序缺陷攻击的公司百分比

运行云应用程序的组织中几乎有一半经历过针对已知但未修补的漏洞或先前未知的漏洞以及已知未修补的操作系统漏洞的一次或多次攻击。

资料来源：甲骨文和毕马威云威胁报告2018

30％：具有云应用程序的公司称识别漏洞的比例是优先考虑的因素

近三分之一的云应用程序企业表示，识别应用程序软件漏洞是其最关键的安全任务之一。组织希望提高对云托管工作负载的可见性的其他领域包括识别不合规的工作负载配置，异常工作负载活动和异常特权用户活动。

资料来源：甲骨文和毕马威云威胁报告2018

哪个app sec统计数据可以让你和你的团队在晚上工作？在下面的评论部分分享您的想法，并与您的同行互动。

 

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

Web 应用程序网络安全的过去一年并不平静，如果 PerimeterX 首席技术官 Ido Safruti 对来年的预测是准确的，那么这将是保护 Web 应用程序的又一年努力。

Safruti 预测 2022 年，定制的恶意软件、机器人攻击和登录后欺诈激增，导致领导者最终面对在线欺诈的现实：它变化很大，目标变得越来越有选择性，从登录前到输入用户名和密码后。 “因此，我们相信 2022 年将是全面账户保护之年，”Safruti 说。

通过“全面的帐户保护”，Safruti 意味着超越老式边界或城堡和护城河身份验证的安全性。 “这意味着从用户帐户完整性的角度来处理安全性，并在整个应用程序旅程和帐户生命周期中提供多层保护，”Safruti 说。想想零信任和其他形式的身份验证，它们跟踪行为并记录操作以查找可疑行为。

 

Safruti 和 PerimeterX 对 2022 年的 Web 应用程序安全性做出了以下五项预测，整个情况看起来像是一场解决方案有限的安全风暴即将来临。

如果你对这些预测是否可靠感到好奇，Safruti 会指着他去年预测的成绩单。五个中的三个，即网络犯罪社区将变得更强大、GraphQL 将成为安全风险以及闪购将由机器人主导，被评为正确。 DevSecOps 成为主流被认为是“难以判断”，并且认为在线购买店内取货将是一种大型新型欺诈行为的想法被贴上了错误的标签。

预计供应链攻击防范将变得更加重要

SolarWinds 攻击背后的组织 Nobelium 已经重新浮出水面，使用类似的方法攻击其他目标，这些目标本身就是利用第三方软件的弱点进行的供应链攻击。结合日益严格的数据保护法规，Safruti 预测，在这一年，企业开始将下游供应商的弱点视为严重的责任问题，而不仅仅是开展业务的成本。

“92% 的网站决策者对其软件供应链缺乏完整的可见性。获得这种可见性将是旨在防止重大数据泄露并避免在 2022 年及以后发生大规模监管罚款的公司的首要任务，”Safruti 说。

自定义恶意软件将攻击 100 个最大市场中的 50% 以上

众所周知，可以在互联网上找到恶意软件进行销售，并且可以对其开发人员进行定制、销售和支持，并且随着时间的推移，所述恶意软件的开发人员只能进行更多定制调整，以使他们的恶意软件更有效的。

Safruti 说，商品化的攻击工具很便宜，并且可以在线获取免费视频，帮助新兴的网络犯罪分子学习使用他们的工具。 “我们正在目睹‘犯罪即服务’(CaaS) 生态系统的兴起，这推动了针对特定应用程序或网站的定制恶意软件的兴起。由于进入门槛低且产生结果的潜力很大，定制恶意软件将成为2022 年更流行的攻击媒介，”Safruti 说。

登录后环境将开始受到安全关注

我们生活在两个安全世界中：旧的依赖登录来验证身份，而新的则用户名和密码远不够安全，无法依靠它来验证一个人是谁。说他们是。即使是多因素身份验证也只会增加外围安全性，使其有益但不是永久的解决方案。

“到 2022 年，我们预计在线企业将采用解决此问题的解决方案。了解用户是否确实是他们所说的人——以及他们的登录后活动是否合法——将是维护账户完整性的关键，”Safruti 说.

欺诈将导致一家大公司今年贬值

“在过去，许多公司将欺诈视为开展业务的成本，”Safruti 说。现在情况已不再如此，因为他预测针对在线业务的整体欺诈行为将增加到对公司产生重大影响的程度。

“最近的研究表明，不良机器人对在线零售商的运营成本产生了 75% 到 80% 的负面影响，这相当于净收入的 18% 到 23%。当欺诈转化为对每股收益（EPS）的几美分的影响时)，它将成为企业变得更加积极主动的警钟，”Safruti 说。

至少有一家大型零售商会放弃密码

暗网上有很多可供出售的凭证。例如，Safruti 指出 2021 年 6 月发布的 1.2TB 数据库包含来自超过 320 万台 Windows 计算机的信息，其中包括超过 4 亿个有效的 Web 登录 cookie。

“由于被盗凭据如此广泛，获取用户名和密码不再是对网络犯罪的威慑——因此企业需要重新考虑他们的欺诈预防策略，”Safruti 说。他预测，2022 年将是一个或多个面向消费者的大型企业“通过采用不仅仅依赖凭证的更强大的解决方案，完全消除对凭证的需求”的一年。

原文：https://www.techrepublic.com/article/5-predictions-to-help-you-focus-yo…

确保对您的业务重要的东西。

当库伊特在那里工作的时候，想很多关于云的秘密。除了选择和执行各种工具外，您还必须采用和关联身份和访问管理方面的最佳实践。

无论您是开发人员还是系统管理员专业人员，您都需要明确指出，您有正确的选择工具来确保您的环境安全。应用程序需要访问适当的配置数据才能正确运行。虽然大多数配置数据是非敏感的，但有些数据需要保密。这些线被称为秘密。

好吧，如果您正在构建一个可靠的应用程序，那么您的函数很可能需要访问您保存的机密或任何其他类型的敏感信息。这些秘密包括：

1. API密钥
2. 数据库凭据
3. 加密密钥
4. 敏感配置设置（电子邮件地址、用户名、调试标志等）
5. 密码

然而，安全地处理这些秘密可能会在以后被证明是一项艰巨的任务。因此，以下是对开发人员和系统管理员的一些提示：

修补功能依赖项

始终记住跟踪函数中使用的库，并通过持续监视来标记漏洞。

使用API网关作为安全缓冲区

不要将函数精确地暴露给用户交互。利用云提供商的API网关功能，在您的功能之上包含另一层安全性。

保护和验证传输中的数据

请确保利用HTTPS作为安全通信通道，并验证SSL证书以保护远程身份。

遵循应用程序代码的安全编码规则

由于没有服务器可攻击，攻击者会将注意力转向应用程序层，因此请格外小心保护您的代码。

在安全存储中管理机密

敏感信息很容易被泄露，如果您忽视采用适当的秘密管理解决方案，过期的凭证很容易受到彩虹表攻击。记住不要在应用程序系统、环境变量或源代码管理系统中存储机密。

由于缺乏知识和资源等原因，合作世界的关键管理非常痛苦。相反，一些公司将加密密钥和其他软件机密直接嵌入到使用它们的应用程序的源代码中，从而带来了泄露机密的风险。

由于缺乏太多现成的解决方案，许多公司都在寻求建立自己的机密管理工具。这里有一些，你可以利用你的需求。

Vault

HashiCorp Vault是一个安全存储和访问机密的工具。

它提供了一个统一的秘密接口，同时保持严格的访问控制和记录全面的审计日志。它是一种保护用户应用程序和基础的工具，在出现漏洞时限制表面空间和攻击时间。它提供了一个API，允许基于策略访问机密。API的任何用户都需要验证并且只查看他有权查看的机密。

使用256位AES加密保险库数据。

它可以在各种后端（如Amazon DynamoDB、Consult等）中积累数据。对于audit services，Vault支持记录到本地文件、Syslog服务器或直接记录到套接字。Vault将记录有关执行操作的客户端、客户端IP地址、操作以及执行操作的时间的信息

启动/重新启动总是需要一个或多个操作员打开保险库。它主要使用代币。每个令牌被赋予一个策略，该策略可以约束操作和路径。保险库的主要功能包括：

• 它在不存储数据的情况下对数据进行加密和解密。
• Vault可以根据需要为某些操作生成机密，例如AWS或SQL数据库。
• 允许跨多个数据中心进行复制。
• 保险库具有内置的秘密撤销保护。
• 用作具有访问控制详细信息的机密存储库。

AWS机密管理者

你期望AWS出现在这个列表上。你不是吗？

AWS有解决所有问题的方法。

AWS Secrets Manager使您能够快速旋转、管理和检索数据库凭据、API密钥和其他密码。使用Secrets Manager，您可以保护、分析和管理访问AWS云、第三方服务和本地功能所需的机密。

机密管理器使您能够使用细粒度权限管理对机密的访问。AWS Secrets Manager的主要功能包括：

1. 使用加密密钥加密静态机密。
2. 然后通过TLS安全地传输秘密
3. 提供有助于调用Secrets Manager API的代码示例
4. 它有客户端缓存库来提高可用性并减少使用机密的延迟。
5. 配置Amazon VPC（虚拟私有云）端点，以保持AWS网络内的流量。

Keywhiz

Square Keywhiz帮助处理基础设施机密、GPG密钥环、数据库凭据，包括TLS证书和密钥、对称密钥、API令牌和外部服务的SSH密钥。Keywhiz是一个处理和分享秘密的工具。

Keywhiz的自动化使我们能够无缝地分发和设置服务的基本机密，这需要一个一致和安全的环境。Keywhiz的主要特点是：

• Keywhiz服务器提供用于收集和管理机密的JSON api。
• 它只将所有秘密存储在内存中，从不重现到磁盘上
• 用户界面是用AngularJS制作的，因此用户可以验证和使用UI。

Confidant

confident是一个开源的秘密管理工具，它可以安全地维护用户友好的存储和对机密的访问。confidentint在DynamoDB中以追加的方式存储秘密，并使用Fernet对称认证密码学为每一次修改生成一个唯一的KMS数据密钥。

它提供了一个AngularJS web界面，为最终用户提供了高效管理机密、服务机密形式和更改记录的功能。其中一些功能包括：

• KMS身份验证
• 静态加密版本化机密
• 用于管理机密的用户友好的web界面
• 生成可应用于服务到服务身份验证或在服务之间传递加密消息的令牌。

Strongbox

Strongbox是一个方便的工具，用于处理、存储和检索访问令牌、私有证书和加密密钥等机密。Strongbox是一个客户端便利层。它为您维护AWS资源，并安全地配置它们。

通过深度搜索，您可以快速有效地检查您的整套密码和机密。您可以选择在本地或云上存储凭据。如果选择云，则可以选择存储在iCloud、Dropbox、OneDrive、Google Drive、WebDAV等。

Strongbox与其他密码安全兼容。

Azure密钥库

在Azure上托管应用程序？如果是，那么这将是一个不错的选择。

Azure密钥保险库允许用户在特定位置管理其云应用程序的所有机密（密钥、证书、连接字符串、密码等）。它与Azure中秘密的来源和目标集成在一起。它可以被Azure之外的应用程序进一步利用。

您还可以通过将加密密钥存储在云中（而不是内部部署）来减少云应用程序的延迟，从而提高性能。

Azure可以帮助实现数据保护和法规遵从性要求。

Docker secrets

Docker secrets允许您轻松地将机密添加到集群中，并且它只在相互验证的TLS连接上共享。然后数据到达Docker secrets中的manager节点，并自动保存到内部Raft store中，保证数据加密。

Docker secrets可以很容易地应用于管理数据，从而将数据传输到有权访问数据的容器。它可以防止机密在应用程序用完时泄露。

Knox

由社交媒体平台Pinterest开发的Knox解决了他们手工管理密钥和保持审计跟踪的问题。Knox是用Go编写的，客户机使用restapi与Knox服务器通信。

Knox使用易失性临时数据库来存储密钥。它使用带有主加密密钥的AES-GCM对存储在数据库中的数据进行加密。Knox也可以作为Docker映像提供。

结论

我希望上面的内容能让您了解一些管理应用程序凭据的最佳软件。

 

原文：https://geekflare.com/secret-management-software/

本文：http://jiagoushi.pro/node/1085

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

点击任何列表中的CWE ID，您将被引导到MITRE CWE站点中的相关站点，在那里您可以找到以下内容：

• 前25名的排名，
• 链接到完整的CWE条目数据，
• 弱点流行率和后果的数据字段，
• 补救成本，
• 容易被发现，
• 代码示例，
• 检测方法，
• 攻击频率和攻击者意识
• 相关CWE条目，以及
• 针对这一弱点的相关攻击模式。

前25个软件错误站点的每个条目还包括相当广泛的预防和补救步骤，开发人员可以采取这些步骤来减轻或消除弱点。

档案文件

• View the Top 25 Software Errors for 2010 Here
• View the Top 25 Software Errors for 2009 Here

CWE前25名

Rank	ID	Name
[1]	CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer
[2]	CWE-79	Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
[3]	CWE-20	Improper Input Validation
[4]	CWE-200	Information Exposure
[5]	CWE-125	Out-of-bounds Read
[6]	CWE-89	Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
[7]	CWE-416	Use After Free
[8]	CWE-190	Integer Overflow or Wraparound
[9]	CWE-352	Cross-Site Request Forgery (CSRF)
[10]	CWE-22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
[11]	CWE-78	Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
[12]	CWE-787	Out-of-bounds Write
[13]	CWE-287	Improper Authentication
[14]	CWE-476	NULL Pointer Dereference
[15]	CWE-732	Incorrect Permission Assignment for Critical Resource
[16]	CWE-434	Unrestricted Upload of File with Dangerous Type
[17]	CWE-611	Improper Restriction of XML External Entity Reference
[18]	CWE-94	Improper Control of Generation of Code ('Code Injection')
[19]	CWE-798	Use of Hard-coded Credentials
[20]	CWE-400	Uncontrolled Resource Consumption
[21]	CWE-772	Missing Release of Resource after Effective Lifetime
[22]	CWE-426	Untrusted Search Path
[23]	CWE-502	Deserialization of Untrusted Data
[24]	CWE-269	Improper Privilege Management
[25]	CWE-295	Improper Certificate Validation

 

 

Rank	ID	Name
[1]	CWE-119	内存缓冲区范围内的操作限制不正确
[2]	CWE-79	网页生成过程中输入的中和不正确（“跨站点脚本”）
[3]	CWE-20	输入验证不正确
[4]	CWE-200	信息披露
[5]	CWE-125	越界读取
[6]	CWE-89	SQL命令中使用的特殊元素的不正确中和（“SQL注入”）
[7]	CWE-416	释放后使用
[8]	CWE-190	整数溢出或环绕
[9]	CWE-352	跨站点请求伪造（CSRF）
[10]	CWE-22	路径名对受限制目录的限制不正确（“路径遍历”）
[11]	CWE-78	操作系统命令中使用的特殊元素的不正确中和（“操作系统命令注入”）
[12]	CWE-787	越界写入
[13]	CWE-287	身份验证不正确
[14]	CWE-476	空指针取消引用
[15]	CWE-732	关键资源的权限分配不正确
[16]	CWE-434	不受限制地上载危险类型的文件
[17]	CWE-611	XML外部实体引用的限制不正确
[18]	CWE-94	代码生成控制不当（“代码注入”）
[19]	CWE-798	硬编码凭证的使用
[20]	CWE-400	不受控制的资源消耗
[21]	CWE-772	有效生存期后缺少资源释放
[22]	CWE-426	不受信任的搜索路径
[23]	CWE-502	不可信数据的反序列化
[24]	CWE-269	权限管理不当
[25]	CWE-295	证书验证不正确

帮助消除前25个软件错误的资源

SAN应用程序安全课程

SANS应用程序安全课程旨在通过提供世界级的教育资源来设计、开发、采购、部署和管理安全软件，将安全性深入人心。应用程序安全系是具有数十年应用程序安全经验的实战人员。我们课程中涵盖的概念将适用于您返回工作岗位当天的软件安全计划：

• DEV522：保护Web应用程序安全要素
• DEV534：安全DevOps：实用介绍
• DEV540：安全的DevOps和云应用程序安全

 

• DEV522: Defending Web Applications Security Essentials
• DEV534: Secure DevOps: A Practical Introduction
• DEV540: Secure DevOps & Cloud Application Security

SANS维护一个应用程序安全网络人才评估，该评估衡量安全编码技能，允许程序员确定其安全编码知识的差距，并允许买家确保外包程序员有足够的编程技能。组织可以在https://www.sans.org/cybertalent/assessment-detail?msc=top25hp#appsec。

开发人员安全意识培训

SANS安全意识开发人员产品根据需要提供精确的软件安全意识培训，所有这些都是在您的办公桌上进行的。应用安全意识培训包括30多个模块，平均7-10分钟，最大限度地提高学习者的参与度和保持力。这些模块涵盖了PCI第6.5节法规遵从性主题的全部广度和深度，以及对安全软件开发非常重要的项目。

前25个错误列表将定期更新，并发布在SANS和MITRE站点

CWE Top 25 Software Errors Site

MITRE在美国国土安全部国家网络安全部门的支持下维护CWE（Common Weakness Enumeration）网站，详细描述前25个软件错误，并提供减轻和避免这些错误的权威指导。该站点还包含700多个额外软件错误、设计错误和架构错误的数据，这些错误可能导致可利用的漏洞。CWE网站

SAFECode—

软件保证卓越代码论坛（成员包括EMC、Juniper、Microsoft、Nokia、SAP和Symantec）已出版了两本优秀的出版物，概述了软件保证的行业最佳做法，并为实施安全软件开发的经验证方法提供了实用建议。

安全软件开发基本实践第3版

• https://safecode.org/publications/#安全代码出版物-2362个
• 软件完整性控制概述
• https://safecode.org/publications/#安全代码出版物-189个
• 软件供应链完整性框架
• https://safecode.org/publications/#安全代码出版物-188
• 安全软件开发的基本实践
• https://safecode.org/publications/#安全代码出版物-186个
• 软件保证：当前行业最佳实践概述
• https://safecode.org/publications/#安全代码出版物-185个

软件保障社区资源网站和DHS网站

作为DHS风险缓解工作的一部分，为了提高网络资产的弹性，软件保证计划旨在减少软件漏洞，最大限度地减少利用，并解决如何以可预测的执行方式定期获取、开发和部署可靠和可信赖的软件产品，以及提高诊断能力分析系统是否存在可利用的弱点。

近十几家软件公司提供自动化工具来测试这些错误的程序。

 

原文：https://www.sans.org/top25-software-errors/

本文：http://jiagoushi.pro/node/1078

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

越来越多的IT专业人士看到DevSecOps是一种在开发过程早期集成安全措施以提高生产代码质量的实践，是未来应用程序开发的主要支柱。

其中很大一部分源于通过采用DevOps，容器和微服务的架构以及支持自动化工具链和框架来加速应用程序开发的趋势。这一趋势为网络犯罪分子提供了机会，他们越来越关注这些类型环境中的安全漏洞和漏洞。鉴于当今的开发速度和体积以及更大的环境复杂性，将DevSecOps作为优先事项从未如此重要。

无论您的角色是CISO，开发人员，安全架构师，运营工程师还是DevOps团队的其他成员，了解如何在这些新环境中采取主动和预防性的应用程序安全性方法非常重要。特别是，这意味着关注：

1. 使用API​​保护环境
2. 实施持续安全
3. 采用不断发展的安全实践
4. 保护敏感数据
5. 维护应用程序漏洞的当前最佳实践

继续阅读以了解有关这五种安全策略的更多信息。

＃1：了解如何使用API​​将应用程序安全性部署到环境中

Web应用程序防火墙（WAF）解决方案对于现代应用程序环境变得更加重要，因为它们添加了专门的安全功能，补充了API网关等组件，这些组件本身只执行此过滤的基本功能。为了确保API安全性，需要使用WAF解决方案来检查传入和传出的HTTP / HTTPS，就像使用任何其他Web应用程序一样，并提供诸如性能分析，阻止攻击，僵尸程序和DDoS保护，防止帐户接管等功能。在此处详细了解Imperva可以为API安全做些什么。

您的WAF还应该帮助保护新应用程序环境中的应用程序和数据，并在配置新服务或容器时随时自动部署。

＃2：实施持续安全性

安全团队面临的挑战是开发安全软件，同时建立适当的安全实践，这些实践不会在开发过程中产生瓶颈并可能影响上市时间。这需要旨在轻松无缝集成到DevSecOps工作流程中的解决方案。

连续，自动化的安全性

DevOps通常使用称为持续实施 - 持续部署（CI-CD）的实践（图1），它将开发和启动过程紧密结合在一起，以推出功能和应用程序。从安全角度来看，这意味着管理WAF解决方案的操作方面应该是自动化和模板化的，这样可以轻松扩展您的安全性。因此，无论您是启动新服务器，部署新应用程序，还是将现有服务从一台服务器移动到另一台服务器，都会自动部署链接到该服务的安全策略和配置层。

安全解决方案的可编程性有助于自动扩展，并支持在部署新应用程序和微服务时快速部署安全资源。在集成安全解决方案时，利用AWS Cloud Formation或Microsoft Azure Resource Manager（ARM）等云特定模板可以是在云环境中实现此类自动扩展的一种方法。

图1：持续集成 - 持续开发（CI-CD）的过程是DevOps中常用于构建和部署应用程序的互锁工作流程

＃3：坚持继续发展的安全解决方案

除非您使用的安全解决方案也在不断发展以跟上新的应用程序环境和工具，否则很难实现以前的策略并继续发展您的安全立场。

例如，现代应用程序方法和基础架构（包括DevOps，API，微服务，公共云，容器等）需要安全解决方案，旨在提供：

1. 高可用性：您的所有解决方案都应通过允许您的组织保护敏感Web应用程序而不会引入过多的IT开销或阻止合法的Web流量来确保稳定的业务连续性。
2. 集成：选择支持DevOps中使用的适当的自动化工具链和其他编排技术的安全解决方案，以便在部署新的应用程序，实例和容器时，安全功能可以随时随地自动实现。这通常需要通过支持DevOps工作流，云部署和编排的API来暴露功能。
3. 功能/功能奇偶校验：您的解决方案应该与应用程序是否跨公共云和私有云，容器或内部部署无关。这使您可以在不影响安全性的情况下将传统开发过渡到敏捷DevOps。
4. 集中管理：从单一管理控制台管理内部部署和云网关，以整合和简化混合云部署的安全性。

＃4：保护您的数据

虽然DevSecOps的大部分重点都放在应用程序和基础架构上，但不要忽视数据。随着应用程序和基础架构变得更加分散，数据安全性变得更加重要，其复杂的相互依赖性可能跨越服务，API，容器和云。

在这个日益复杂的应用程序生态系统中保护数据的一种方法是使用以数据为中心的审计和保护（DCAP）解决方案。 DCAP解决方案通过实时监控，审计以及安全和权限管理，帮助您保护数据库，文件存储和大数据存储库中的数据。

使用DCAP解决方案，您可以：

1. 实时分析所有数据库活动。您可以监控访问数据库的所有用户，无论是通过浏览器，移动应用程序还是桌面应用程序。
2. 采取措施避免危害和数据丢失，例如根据安全策略阻止对敏感数据的访问。

＃5：继续做你正在做的事

虽然应用程序开发和体系结构实践正在发生变化，但相同的Web安全漏洞仍然会威胁到DevOps环境，因此金标准安全最佳实践仍然具有相关性。如果暴露API，您的攻击面可能会更大，因为代码可能更频繁地部署 - 包括您堆栈中可能存在的第三方软件和服务，这会增加您引入漏洞的风险和速度。

出于所有这些原因，您的组织应继续关注：

1. 通过强化基础架构和服务来减少攻击面
2. 通过加密静态通信和数据来确保机密性
3. 实施细粒度访问控制
4. 过滤恶意软件并阻止已知的错误流量
5. 监控和检测异常行为以防止所有类型的攻击，包括：分布式拒绝服务（DDoS），滥用功能，访问冲突，利用等等
6. 使用日志记录和分析审核访问和事件

将安全性集成到您的工作流程中

今天的应用程序，服务和API是寻求访问您的环境的网络犯罪分子的有吸引力的目标。管理和保护新的应用程序生态系统需要应用与过去相同的安全最佳实践，还需要使用为处理当今环境而构建的解决方案。

要了解有关Imperva解决方案如何集成到您的DevSecOps工作流程的更多信息，请下载我们的电子书：“DevOps，API和微服务的五种安全策略”。

原文：https://www.imperva.com/blog/security-strategies-for-devops-apis-containers-and-microservices/

本文：http://pub.intelligentx.net/security-strategies-devops-apis-containers-and-microservices

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

在注册期间及以后验证您的客户身份。

什么是身份验证？

身份验证，有时也称为身份证明，是验证最终用户身份的过程，以确保他们的数字身份与其真实身份相关联。 这让您更加确信您的用户从一开始就是他们声称的正确人选。

身份验证如何使我的业务受益？

平衡便利性和安全性

与替代方法和传统方法相比，通过让用户在不影响安全性的情况下简单地验证其身份来减少挫败感。

防止欺诈活动

在降低帐户创建和接管风险以及降低下游交易各方风险的同时加强安全性。

满足监管要求

保持对了解您的客户 (KYC) 和其他法规的遵守，同时支持数字化转型计划。

身份验证提供哪些功能？

身份验证解决方案能够：

• 简化的自助服务帐户创建和重置
• 使用经过验证的属性自动填写表格
• 将身份验证嵌入到新的或现有的应用程序和工作流程中
• 将客户身份与设备或凭证相关联

身份验证的工作原理

面部活泼

系统会提示用户提供使用 ISO 认证技术被动检查活跃度的自拍照。

文件认证

用户使用移动设备的摄像头扫描政府身份证的正面和背面，并使用超过 150 次加权分析和机器学习来检查身份证的真实性。

身份验证

现场自拍与用户在政府身份证上的照片进行比较，结果与用户的身份记录相关联。

 

以数据为中心与以文档为中心的身份验证

以数据为中心的身份验证依赖于向用户询问可与可靠来源进行比较的信息。 不幸的是，不良行为者和软件机器人可以轻松获取这些数据——包括构建通过许多遗留或替代检查的合成身份。

 

以文件为中心的身份验证让您对机器学习和自拍匹配与 ISO 认证的 liveness 技术更有信心，以验证政府 ID 并验证您的用户身份。

从一开始就了解您的客户

 

• 通过降低欺诈和帐户接管的风险，自信地与您的客户在线互动。身份验证为您的企业提供了适当的保证，即与您互动的客户是他们在注册或开户时所说的真实身份。
• 在与用户互动时优化体验和安全性
• 通过快速集成到应用程序中来缩短上市时间
• 保持敏捷性，为您的业务实现持续的数字化创新

与您的用户建立信任

 

• 从一开始就集成身份验证，与您的用户建立信任。通过让您更有信心将人连接到他们的设备和凭据，这增强了对每次交互的信任。 身份验证解决方案可让您在用户旅程中无缝集成确认身份，而无需复制或存储 PII。
• 简化为您的用户体验添加身份验证
• 通过将身份验证无缝集成到您的用户体验中来消除摩擦。身份验证功能可以通过 REST API 轻松添加以提高灵活性或使用原生 SDK 让用户在您的移动应用程序中确认身份。
•  
• 此外，编排功能可帮助您构建、测试和优化将身份验证与在线欺诈检测和身份验证服务相结合的用户旅程，以增强体验和安全性。

原文：https://www.pingidentity.com/en/platform/capabilities/identity-verifica…

本文：

哪些库容易受到攻击以及如何防止它们。

 

TL; DR：如果您使用带有非对称密钥的node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt（RS256，RS384，RS512，ES256，ES384，ES512），请更新到最新版本。有关易受攻击库的更多信息，请参阅jwt.io。 （2015-04-20更新）

这是来自Tim McLean的客座文章，他是Auth0安全研究员名人堂成员。蒂姆通常在www.timmclean.net上发表博客。

最近，在审查各种JSON Web令牌实现的安全性时，我发现许多具有关键漏洞的库允许攻击者绕过验证步骤。在许多实现和语言中都发现了同样的两个缺陷，所以我认为准确地写出问题的位置会很有帮助。我认为对标准的更改有助于防止未来的漏洞。

“我发现许多具有严重漏洞的库允许攻击者绕过验证步骤。”

对于那些不熟悉的人来说， JSON Web Token (JWT) 是一种创建令牌的标准，可以断言一些声明。例如，服务器可以生成具有声明“以管理员身份登录”并将其提供给客户端的令牌。然后，客户端可以使用该令牌来证明他们以管理员身份登录。令牌由服务器密钥签名，因此服务器能够验证令牌是否合法。

JWT通常有三个部分：标题，有效负载和签名。

标头标识用于生成签名的算法，看起来像这样：

header = '{"alg":"HS256","typ":"JWT"}'

HS256表示此令牌使用HMAC-SHA256签名。

有效负载包含我们希望提出的声明：

payload = '{"loggedInAs":"admin","iat":1422779638}'

正如JWT规范中所建议的那样，我们包含一个名为iat的时间戳，即“发布时”的缩写。

签名由base64url编码头和有效负载计算，并以句点作为分隔符连接：

key = 'secretkey'

unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload) signature = HMAC-SHA256(key, unsignedToken)

总而言之，我们base64url编码签名，并使用句点将这三个部分连接在一起：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)

# token is now: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYW

RtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRg

CzcmJmMjLiuyu5CSpyHI

很棒。那么，那有什么不对？

好吧，让我们尝试验证令牌。

首先，我们需要确定用于生成签名的算法。没问题，标题中有一个alg字段告诉我们。

但是等等，我们还没有验证这个令牌，这意味着我们还没有验证头。这使我们处于一个尴尬的境地：为了验证令牌，我们必须允许攻击者选择我们用来验证签名的方法。

这对某些实现具有灾难性的影响。

迎接“None”算法

无算法是JWT的一个奇怪的补充。它旨在用于已经验证令牌完整性的情况。有趣的是，它是必须实施的两种算法之一（另一种是HS256）。

不幸的是，一些库处理了使用无算法签名的令牌作为带有经过验证的签名的有效令牌。结果？任何人都可以使用他们想要的任何有效负载创建自己的“签名”令牌，允许在某些系统上进行任意帐户访问。

将这样的标记放在一起很容易。修改上面的示例标题以包含 "alg": "none" 而不是HS256。对有效负载进行任何所需的更改。使用空签名（signature = ""）。

大多数（希望所有？）实现现在都有一个基本检查来防止这种攻击：如果提供了密钥，那么使用none算法的令牌验证将失败。这是一个好主意，但它并没有解决潜在的问题：攻击者控制算法的选择。让我们继续挖掘。

RSA还是HMAC？

JWT规范还定义了许多非对称签名算法（基于RSA和ECDSA）。使用这些算法，使用私钥创建和签名令牌，但使用相应的公钥进行验证。这非常简洁：如果您发布公钥但保留私钥，只有您可以签署令牌，但任何人都可以检查给定令牌是否正确签名。

我看过的大多数JWT库都有这样的API：

# sometimes called "decode"

verify(string token, string verificationKey)

# returns payload if valid token, else throws an error

在使用HMAC签名的系统中，verificationKey将是服务器的秘密签名密钥（因为HMAC使用相同的密钥进行签名和验证）：

verify(clientToken, serverHMACSecretKey)

在使用非对称算法的系统中，verificationKey将是应该验证令牌的公钥：

verify(clientToken, serverRSAPublicKey)

不幸的是，攻击者可以滥用此功能。如果服务器期望使用RSA签名的令牌，但实际上接收到使用HMAC签名的令牌，则会认为公钥实际上是HMAC密钥。

这怎么是灾难？ HMAC密钥应该保密，而公钥是公共密钥。这意味着您的典型 ski mask-wearing attacker 可以访问公钥，并可以使用此伪造服务器将接受的令牌。

这样做非常简单。首先，抓住您最喜欢的JWT库，并为您的令牌选择一个有效负载。然后，获取服务器上使用的公钥作为验证密钥（最有可能采用基于文本的PEM格式）。最后，使用PEM格式的公钥作为HMAC密钥签署您的令牌。实质上：

forgedToken = sign(tokenPayload, 'HS256', serverRSAPublicKey)

最棘手的部分是确保serverRSAPublicKey与服务器上使用的验证密钥相同。字符串必须完全匹配才能使攻击工作 - 完全相同的格式，并且没有额外或缺少的换行符。

最终结果？知道公钥的任何人都可以伪造将通过验证的令牌。

对库开发人员的建议

我建议JWT库在其验证函数中添加一个算法参数：

verify(string token, string algorithm, string verificationKey)

服务器应该已经知道它用于签署令牌的算法，并且允许攻击者提供此值是不安全的。

有些人可能会争辩说，出于兼容性原因，某些服务器需要支持多个算法。在这种情况下，可以（并且应该）为每个支持的算法使用单独的密钥。 JWT可以方便地为此提供“密钥ID”字段（孩子）。由于服务器可以使用密钥ID来查找密钥及其相应的算法，因此攻击者无法再控制密钥用于验证的方式。在任何情况下，我都不认为JWT库甚至不应该查看标题中的alg字段，除非可以检查它是否与预期的算法匹配。

任何使用JWT实现的人都应该确保拒绝具有不同签名类型的令牌。一些库有一个可选的白名单或黑名单算法机制;利用它，否则你可能会面临风险。更好的是：制定一项政策，对用于提供任务关键功能的任何开源库执行安全审核。

改进JWT / JWS标准

我想建议弃用标题的alg字段。正如我们在这里看到的，它的滥用会对JWT / JWS实施的安全性产生破坏性影响。据我所知，密钥ID提供了一个充分的选择。这保证了对规范的改变：JWT库由于依赖于alg而继续编写有安全漏洞。

JWT（和JOSE）提供了一个拥有跨平台安全加密套件的机会

旁白：将JWT实施委托给专家

JWT是OpenID Connect标准不可或缺的一部分，OpenID Connect标准是位于OAuth2框架之上的标识层。 Auth0是OpenID Connect认证的身份平台。这意味着如果您选择Auth0，您可以确定它与遵循规范的任何第三方系统100％可互操作。

OpenID Connect规范要求使用JWT格式的ID令牌，其中包含以声明形式表示的用户配置文件信息（例如用户名和电子邮件）。这些声明是关于用户的声明，如果令牌的使用者可以验证其签名，则可以信任该声明。

虽然OAuth2规范没有规定访问令牌的格式，用于授权应用程序代表用户访问API，但业界也广泛接受JWT的使用。

作为开发人员，您不必担心直接验证，验证或解码服务中与身份验证相关的JWT。您可以使用Auth0的现代SDK来处理JWT的正确实施和使用，因为他们知道JWT遵循最新的行业最佳实践并定期更新以解决已知的安全风险。

例如，用于 Auth0 SDK for Single Page Applications提供了一种从ID令牌auth0.getUser中提取用户信息的方法。

如果您想试用Auth0平台，请注册免费帐户并开始使用！使用您的免费帐户，您将可以使用以下功能：

• Universal Login for Web, iOS & Android
• Up to 2 social identity providers (like Twitter and Facebook)
• Unlimited Serverless Rules

要了解有关JWT的更多信息，它们的内部结构，可以与它们一起使用的不同类型的算法以及它们的其他常见用途，请查看JWT Handbook.。

原文：https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

本文:  http://pub.intelligentx.net/node/507

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

Hydra是一个OAuth 2.0和OpenID连接提供商。换句话说，它是OAuth 2.0授权框架和OpenID Connect Core 1.0框架的实现。因此，它发出OAuth 2.0访问、刷新和ID令牌，使第三方能够以用户的名义访问您的api。

灵活的用户管理

ORY Hydra最大的优点之一是，与其他OAuth 2.0实现不同，它实现了OAuth和OpenID连接标准，而无需强制您使用“Hydra用户管理”(登录、注销、配置文件管理、注册)、特定的模板引擎或预定义的前端。

这允许您在您的技术堆栈中实现用户管理并以您自己的方式进行登录，并使用您的用例(基于标记的2FA、SMS 2FA等)所需的身份验证机制。当然，您可以使用现有的解决方案，如authboss或auth0.com。它为您提供了OAuth 2.0和OpenID连接的所有好处，同时对您的业务逻辑和技术堆栈具有最低限度的侵入性。

密钥存储

除了OAuth 2.0功能之外，ORY Hydra还提供了用于加密密钥(例如用于签署JSON Web令牌)的安全存储，并可以管理OAuth 2.0客户机。

认证

ORY Hydra是OpenID Connect认证(挂起)，实现OpenID基金会提出的所有要求。特别是，它正确地实现了IETF和OpenID Foundation指定的各种OAuth 2.0和OpenID连接流。

安全第一

ORY Hydra的体系结构和工作流程旨在中和许多常见(OWASP前十)和不常见的攻击载体。学习更多的知识。

高性能

Hydra具有较低的CPU和内存占用、较短的启动时间，并且可以轻松地在许多平台上伸缩，包括Heroku、Cloud Foundry、Docker、谷歌容器引擎等。

开发友好型。

Hydra适用于所有流行的平台，包括Linux、OSX和Windows。它作为一个单独的二进制文件发布，没有任何附加的依赖性。为了进一步简化，可以使用Docker映像。

Hydra还提供了一个开发人员友好的CLI。

限制

九头蛇也有一些限制:

1. Hydra不管理用户帐户，即用户注册、密码重置、用户登录、发送确认邮件等。在Hydra的体系结构中，身份提供者负责此工作。
2. Hydra不支持OAuth 2.0资源所有者密码凭据流，因为它是遗留的、不鼓励使用的和不安全的。

九头蛇适合你吗?

OAuth 2.0可以在许多环境中用于各种目的。这个列表可以帮助你决定OAuth 2.0和Hydra是否适合用例:

1. 允许第三方解决方案访问您的api:这就是OAuth2提供程序所做的，Hydra是一个完美的选择。
2. 像谷歌、Facebook或Microsoft这样的身份提供者:OpenID连接，因此Hydra是一个完美的选择。
3. 让您的浏览器、移动或可穿戴应用程序访问您的api:运行OAuth2提供程序可以很好地实现这一点。您不必在设备上存储密码，并且可以随时撤销访问令牌。GMail登录是这样工作的。
4. 您希望限制后端服务可以相互读取的信息类型。例如，评论服务应该只允许获取用户配置文件更新，但不应该能够读取用户密码。OAuth 2.0可能对您有意义。

 

原文：https://www.ory.sh/docs/hydra/

本文：

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

了解OAuth 2.0设备流如何为有限输入设备提供流畅的身份验证和授权。

厌倦了与遥控器和屏幕电视键盘摔跤，以在智能电视上输入凭据？你已经处理了太多次，你可以打赌你的客户必须这样做。如果您可以通过手机上的几个水龙头帮助他们登录，该怎么办？

使用电视遥控器的人的图象输入凭据

嗨，来自Auth0的Dan为您带来OAuth 2.0设备流程：一种快速，简便，安全的方式来登录智能电视和其他输入受限设备上的应用程序。没有键盘？没有浏览器？没问题！

普通登录可能很乏味且错误很重。 OAuth 2.0设备流程轻巧，可在几秒钟内对您进行身份验证，不仅适用于电视，还适用于游戏机，CLI，打印机等等！

Auth0为开发人员提供了完全兼容的OAuth 2.0设备流程实现，可以轻松应对这一用户体验难题。让我们更多地了解哪些输入受限设备，此授权授权如何工作以及Auth0如何提供帮助。

什么是互联网连接，输入约束设备？

您是否有连接互联网的设备（1）没有浏览器或（2）提供不切实际的输入文本方式？

如果你回答是，那么你有一个输入受限的设备！你想到了什么类型的设备？我在想...

1. 多功能一体机
2. 健身追踪器
3. 流媒体设备
4. 牙刷
5. 游戏主机
6. 冰箱
7. 泰迪熊
8. 车载信息娱乐系统
9. 智能电视
10. 真的，任何在它面前都有“聪明”这个词的东西

物联网（IoT）的狂热使很多设备上线。无论是现在还是将来，在这些设备上运行的软件都可以与您的服务API进行通信，以获取为客户提供跨设备和平台的丰富用户体验所需的数据。但是，如果设备不提供授权外部服务的便捷方式，则该用户体验可能不那么丰富或安全。

“在输入受限的设备上授权是一项挑战。但是什么是输入受限的设备呢？在这篇博文中了解更多信息！”

作为竞争企业，您不希望通过无法提供无浏览器身份验证来限制可以使用您的服务的设备。但是，如果设备提供浏览器或用户界面，您不希望客户使用电视遥控器的箭头输入凭据，以从巨大的屏幕键盘中选择按键。例如，当他们慢慢输入屏幕时，有人会记录他们的凭据。

此外，您还需要确保未在您无法控制的系统上输入用户凭据，并且可以将其存储以供将来访问，例如有时利用专有系统的智能显示器或访问API的第三方客户端。

您所需要的是一种授权第三方应用程序的方法，这些应用程序可以在各种设备上对您的API进行受控访问。 OAuth 2.0设备流程可以帮助您实现这一目标！即使在没有浏览器的设备上，您也可以利用标准委派授权协议的安全性和用户体验优势。

 

要了解如何使用设备流，最好使用视频流应用程序作为示例在游戏中看到它。

OAuth 2.0设备流程在行动中

假设您想在电视上观看AuthU TV，这是一个虚构的技术视频平台。 首先将AuthU TV应用程序下载到智能电视上。 当您第一次打开应用程序时，您将受到登录屏幕的欢迎。

为了解决问题，您将被要求访问其他设备（如智能手机或笔记本电脑）上的URL，输入一个简短的代码，然后登录到您的AuthU帐户进行身份验证。

完成此过程后，电视上的软件即可访问您的AuthU帐户，并允许您使用遥控器导航AuthU内容 - 而不是输入凭据。

在较高级别，此过程与YouTube重定向到accounts.google.com以处理用户登录的方式非常相似。使用OAuth 2.0设备流，您可以在集中登录页面上管理身份验证过程，使用辅助设备可以更快，更安全地输入凭据。通过将身份验证从设备移到浏览器中，您可以利用更高级的身份和安全功能，例如MFA，SSO和社交登录。

但谈话很便宜：让我们看看设备流程在行动！我们Auth0的工程师创建了一个交互式演示，可让您直接从浏览器模拟AuthU智能电视应用的授权。

首先访问Device Flow Playground。在那里，您可以使用我们的默认演示设置尝试游乐场，也可以使用Auth0帐户设置进行配置，以尝试使用自己的应用程序。

需要Auth0帐户？立即免费入门。在使用Auth0的免费试用版所提供的一切时，你会说“哇！”！

您还可以选择所需的范围。完成后，点击“开始使用”。

接下来，要从模拟AuthU TV应用程序流式传输内容，系统会提示您通过单击“授权”按钮来授权应用程序。

现在，系统会提示您通过导航到激活URL acme-demo.auth0.com/activate，使用其他设备并输入智能电视上显示的代码来授权设备。 您还可以扫描QR码，这将自动输入用户代码。 电视应用程序将等待您在辅助设备上完成此过程，这将触发可用于访问AuthU电视服务的授权响应。

 

访问提供的链接，输入一次性代码，然后单击“继续”。 您可以使用其他浏览器标签或智能手机移动浏览器执行此操作。

 

确认网站上显示的代码与智能电视上显示的代码相符，然后单击“继续”。

 

接下来，注册一个帐户或使用现有帐户登录。

 

 

 

网站上将显示一条消息，确认设备现已连接。

回到智能电视上，AuthU应用程序已准备好开始流媒体内容。 电视应用程序有权获取有关您的其他信息以自定义UI。

 

这是对OAuth 2.0设备流程的高级技术概述。 让我们来看看如何使用Auth0作为您的身份平台促进此过程。

使用Auth0轻松实现OAuth 2.0设备流程

当您的输入受限设备需要从API获取用户数据时，会发生以下过程：

1. 如果设备应用程序尚未获得授权，则设备应用程序将调用Auth0授权服务器以检索设备代码。
2. Auth0使用URL和用户代码进行响应。您的设备应用要求用户访问辅助设备（如笔记本电脑或智能手机）上的特定网址并提供激活码。
3. 您的设备应用程序开始轮询您的Auth0授权服务器以获取访问令牌和刷新令牌。
4. 用户使用您已配置的身份验证方法之一在辅助设备上使用Auth0进行身份验证。 Auth0是一个身份中心，支持使用各种协议的许多身份提供商（如OpenID Connect，SAML，WS-Federation等）。
5. 身份验证完成后，Auth0会使用访问令牌和刷新令牌响应您的设备应用，这样您就可以刷新访问令牌，而无需再次请求用户的许可。
6. 访问令牌可用于调用API并检索请求的数据。

 

“通过访问令牌和刷新令牌，您可以快速进行身份验证并使其成为最后一次！了解有关令牌如何在OAuth 2.0设备流中工作的更多信息。”

概括

今天，您了解了互联网连接，输入受限设备，这些设备给开发人员和客户带来的挑战，以及Auth0和OAuth 2.0如何让您通过实施设备流来应对这些挑战。

OAuth 2.0设备流程的最佳部分是它允许您将现有的身份验证解决方案扩展到智能设备平台。此授权授权仅允许您的客户对通过另一个设备运行的应用程序进行身份验证和授权。

您可能对您或您的开发团队如何通过代码实现此功能感到好奇。我们很快就会为您提供有关设备流程的详细教程。敬请关注！在此期间，请查看以下资源以获取更多信息：

1. 介绍设备流程
2. Auth0设备授权流程文档
3. 使用设备授权流程调用API
4. OAuth 2.0设备授权授权，草案15

“OAuth 2.0设备流程专为在互联网连接的设备上执行的应用程序而设计，这些设备没有浏览器或受输入限制。它使最终用户能够授权设备应用程序访问服务API。”

 

原文：https://auth0.com/blog/oauth-device-flow-no-hassle-authentication-as-seen-on-tv/

本文：

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

1.简介

在这篇文章中，从头开始实施OAuth 2.0和OpenID Connect服务器的开发人员（我）讨论了调查结果。基本上，实施的考虑点是在讨论中写出来的。因此，对于那些正在寻找“如何及时设置OAuth 2.0和OpenID Connect服务器”等信息的人来说，这不是一个文档。如果您正在寻找此类信息，请访问GitHub上的java-oauth-server和java-resource-server。使用这些，您可以在10分钟内启动授权服务器和资源服务器，发出访问令牌并使用访问令牌调用We​​b API，而无需设置数据库服务器。

偏见

我是Authlete，Inc。的联合创始人，该公司是一家在云端提供OAuth 2.0和OpenID Connect实施的公司，因此本文档可能会受到这种偏见的影响。因此，请在脑海中阅读本文档。但是，基本上，我将从纯工程师的角度来写这篇文章。

2.OAuth是否必要？

“我们希望在我们的公司网站上这样做。我们应该实施OAuth吗？“ - 这经常被问到。从本质上讲，这个问题是询问OAuth是什么。

我经常用来解释OAuth的一句话答案如下。

OAuth 2.0是一种框架，其中服务的用户可以允许第三方应用程序访问他/她在服务中托管的数据，而无需向应用程序透露他/她的凭据。

重要的一点是“不向第三方应用程序透露凭据”。 OAuth就是为此而存在的。一旦理解了这一点，您可以通过检查是否满足以下条件来判断您是否应该为公司的服务准备OAuth服务器。

1. 您的服务管理用户的数据。
2. 您希望第三方为您的服务用户开发应用程序。
3. 您不希望向第三方开发的应用程序透露用户凭据。

即使上述条件不满足且贵公司服务的应用程序仅为自制服务，如果您可能希望第三方在将来开发应用程序和/或建议应用程序，建议您实施OAuth服务器如果您想遵循Web API开发的最佳实践。

但是，混淆可能无法解决。当您想要让用户使用他们的外部服务帐户（如Facebook和Twitter）登录您的网站时。由于“OAuth身份验证”这一术语经常在此上下文中使用，因此您可能认为必须为您的服务实施OAuth。但是，在这种情况下，由于您的服务是使用外部服务实施的OAuth的客户端，因此您的服务本身不必实施OAuth。确切地说，您的服务必须编写代码以使用其他公司的OAuth。换句话说，从外部服务的角度来看，您的服务必须表现为OAuth客户端。但是，在此用例中，您的服务不必像OAuth服务器那样运行。也就是说，您不必实现OAuth服务器。

3.认证和授权

我解释了让人们感到困惑的术语 - “OAuth身份验证”。

每个解释都说“OAuth是授权规范，而不是身份验证规范。”这是因为RFC 6749（OAuth 2.0授权框架）明确指出认证“超出了本规范的范围。”以下段落摘自“ 3.1。 RFC 6749中的“授权端点”。

授权端点用于与资源所有者交互并获得授权授权。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如，用户名和密码登录，会话cookie）超出了本规范的范围。

尽管如此，“OAuth身份验证”一词泛滥并使人们感到困惑。这种混淆不仅在商业方面，而且在工程师中也是如此。例如，“OAuth授权与身份验证”之类的问题有时会发布到Stack Overflow（我对问题的回答是这个）。

由术语，认证和授权（在OAuth的上下文中）处理的信息可以描述如下。

1. 身份验证 - 谁是谁。
2. 授权 - 谁授予谁谁的权限。

身份验证是一个简单的概念换句话说，它是对身份的确认。在网站上识别人的最流行方式是请求该人提供一对ID和密码，但还有其他方式，如使用指纹或虹膜的生物识别身份验证，一次性密码，随机数字表等。无论如何，无论使用何种方式，身份验证都是识别身份的过程。使用开发人员的话，可以表示为“身份验证是识别用户唯一标识符的过程”。

另一方面，授权是复杂的，因为涉及三个元素，即“谁”，“什么权限”和“对谁”。另外，令人困惑的是，在这三个要素中，识别“谁”是认证的过程。换句话说，授权过程包括认证过程作为一个部分的事实使事情变得混乱。

如果三个元素应该被开发人员使用的单词替换，“who”可以替换为“user”，“who”替换为“client application”。因此，OAuth上下文中的授权可以说是用户向客户端应用程序授予权限的过程。

下图描绘了到目前为止所解释的概念。

此图说明了授权页面（用户授予客户端应用程序权限的页面）中的哪些部分用于身份验证和授权。身份验证和授权之间的区别很明显。

现在，是时候谈论“OAuth身份验证”了。

因为授权过程包括认证过程作为一部分，所以授权意味着认证。因此，有些人开始使用OAuth进行身份验证。这是“OAuth身份验证”，并且由于“管理用户凭据的任务可以委托给外部服务”以及“新用户开始使用该服务的障碍因为用户而变得更低”等优点而迅速占据主导地位注册过程可以省略。“

OpenID的人对这种情况抱有怨恨。 - 抱歉，我不知道他们是否真的有这种感觉，但至少我可以想象他们认为OAuth身份验证远远超出他们之前定义的规范级别，如OpenID 2.0和SAML。然而，不可否认的是，他们的规范并没有占上风，世界各地的开发人员都选择了OAuth身份验证的简易性。因此，他们在OAuth之上定义了一个新的身份验证规范OpenID Connect。 OpenID Connect常见问题解答将关系描述为如下所示的等式。

(Identity, Authentication) + OAuth 2.0 = OpenID Connect

由于这一点，OpenID Connect的身份验证可以在OAuth授权过程中同时执行。

由于业界的主要参与者一直致力于规范创建和主动实施（FAQ），OpenID Connect肯定会占上风。因此，OmniAuth等OAuth身份验证库将逐渐完成其角色。

但是，人们肯定会变得更加困惑，因为用于身份验证的OpenID Connect建立在用于授权的OAuth之上。很难解释，特别是在我的情况下，因为Authlete专注于授权，虽然它支持OpenID Connect，但它不会对身份验证做任何事情。在开始向客户解释产品本身之前，我总是要解释身份验证和授权之间的区别。

关于OAuth身份验证的问题，请阅读John Bradley先生的文章“OAuth for Authentication的问题”。在文章中他说：“这是一个安全漏洞，你可以开车穿过。”

“再说OAuth是一种认证标准。”Nat Sakimura先生和John Bradley先生。 （来自https://twitter.com/ve7jtb/status/740650395735871488）

4. OAuth 2.0和OpenID Connect之间的关系

然而，到目前为止，所有内容只是这篇文章的序言。开发人员的技术内容从这里开始。第一个主题是OAuth 2.0和OpenID Connect之间的关系。

在我完成RFC 6749（OAuth 2.0授权框架）的实施之后，我注意到了OpenID Connect的存在。当我收集有关OpenID Connect的信息时，我认为我应该实现该功能，因此请阅读OpenID Connect Core 1.0和其他相关规范。在阅读之后，我得出的结论是“所有人都应该从头开始重写”。

OpenID Connect网站称“OpenID Connect 1.0是一个基于OAuth 2.0协议的简单身份层。”这给人的印象是OpenID Connect可以在现有的OAuth 2.0实现之上轻松无缝地实现。然而，事实却完全不同。恕我直言，OpenID Connect实际上是OAuth 3.0。

有许多与OpenID Connect相关的规范，它们令人费解，难以破译它们。在我能够掌握整个画面之前，我几乎疯了，不得不读了三遍。与OpenID Connect规范相比，RFC 6749可以说很容易。

5.响应类型

特别是，与现有实现冲突的是处理请求参数response_type的方法。可以肯定的是，RFC 6749声明请求参数可能需要多个值，但这是将来的可能性。如果我们直接读取RFC 6749，则response_type是代码或令牌。几乎不可能想象这两个是同时设置的。这是因为该参数用于确定处理来自客户端应用程序的请求的流程。具体而言，当response_type的值是代码时使用授权代码流，并且当值是token时使用隐式流。谁能想象这些流量是混合的？即使可以想象它，我们应该如何解决流量之间存在的冲突？例如，授权代码流要求将响应参数嵌入到重定向URI（4.1.2。授权响应）的查询部分中，而隐式流要求将响应参数嵌入到片段部分中（4.2.2。访问令牌）响应），并不能同时满足这些要求。

但是，OpenID Connect已将id_token添加为response_type的新值，并明确允许将code，token和id_token的任意组合作为response_type的值。此外，也没有添加。详情见“3。身份验证“OpenID Connect Core 1.0和OAuth 2.0多响应类型编码实践”。

它需要进行重大更改才能修改在假定选择或选择的情况下编写的现有代码，以便它可以处理可能值和混合流的任意组合。因此，如果将来有可能支持OpenID Connect，OAuth库的实现者应该从头开始用OpenID Connect编写它。换句话说，现有的OAuth库无法在不进行重大修改的情况下支持OpenID Connect。

例如，Spring Security OAuth。此库尚未支持OpenID Connect（截至2016年6月）。对于要支持OpenID Connect的库，首先，请求参数response_type必须能够采用除代码和令牌之外的其他值。对它的请求被列为“问题＃619处理其他response_types”，但它尚未得到解决，并且该主题的最后一条评论是“任何评论都非常受欢迎，因为事实证明（正如我预测的那样）a大型重构练习。“我阅读了一些相关的源文件，发现支持OpenID Connect需要进行大的修改才是真的。除非一些公司在财务上支持该项目，否则我担心该项目需要很长时间才能支持OpenID Connect。

顺便说一句，我也想提到Apache Oltu。该项目声称它支持OpenID Connect，但我的猜测是初始实现仅支持OAuth 2.0，并且在稍后阶段添加了OpenID Connect支持。我认为这样的原因是OAuth 2.0（org.apache.oltu.oauth2）的包和OpenID Connect（org.apache.oltu.openidconnect）的包是隔离的。但是，这种方法会破坏架构。例如，OpenIdConnectResponse类是OAuthAccessTokenResponse的后代是不合适的，因为包含ID令牌的响应不一定包含访问令牌。其他示例是存在名为OAuthClientRequest.AuthenticationRequestBuilder的类（由于某些原因而不是“授权”但是“身份验证”）以及存在GitHub特定的类GitHubTokenResponse。 Apache Oltu的架构至少给我带来了问题。我不知道有关该项目的细节，但在我个人看来，它注定要缩小。

6.客户端应用程序的元数据

正如在RFC 6749的客户端注册中明确写出的那样，客户端应用程序必须在发出授权请求之前提前注册到目标授权服务器。因此，在典型情况下，授权服务器的实现者定义数据库表以存储关于客户端应用程序的信息。

要确定表应该具有哪些列，实现者通过阅读规范来列出项目。例如，阅读RFC 6749将使您意识到至少需要以下项目。

1. Client ID
2. Client Secret
3. Client Type
4. Redirect URIs

除此之外，实现者可以添加更多属性。例如，“应用程序名称”。

即使您通过RFC 6749进行搜索，客户端应用程序的属性也没有那么多，因此存储客户端应用程序属性的数据库表的列数不会变大 - 这样的好日子已经因为出现了OpenID Connect。客户端应用程序应具有的许多属性列在2. OpenID Connect动态客户端注册1.0的客户端元数据中。以下是清单。

1. redirect_uris  - 客户端使用的重定向URI值。
2. response_types  - 客户端声明它将自己限制为使用的response_type值。
3. grant_types  - 授权客户端声明它将限制自己使用的类型。
4. application_type  - 应用程序的种类。
5. 联系人 - 负责此客户的人员的电子邮件地址。
6. client_name  - 要呈现给最终用户的客户端的名称。
7. logo_uri  - 引用客户端应用程序徽标的URL。
8. client_uri  - 客户端主页的URL。
9. policy_uri-依赖方客户端向最终用户提供的URL，以了解如何使用配置文件数据。
10. tos_uri-依赖方客户提供给最终用户的URL，以了解依赖方的服务条款。
11. jwks_uri-客户端的JSON Web密钥集文档的URL。
12. jwks  - 客户端的JSON Web Key Set文档，按值传递。
13. sector_identifier_uri  - 使用https方案的URL，用于由OP计算伪名标识符。
14. subject_type  - 要求对此客户的响应的subject_type。
15. id_token_signed_response_alg  - 签署发给此客户端的ID令牌所需的JWS alg算法。
16. id_token_encrypted_response_alg  - 加密发给此客户端的ID令牌所需的JWE alg算法。
17. id_token_encrypted_response_enc-加密发给该客户端的ID令牌所需的JWE enc算法。
18. userinfo_signed_response_alg-签署UserInfo响应所需的JWS alg算法。
19. userinfo_encrypted_response_alg  - 加密UserInfo响应所需的JWE alg算法。
20. userinfo_encrypted_response_enc  - 加密UserInfo响应所需的JWE enc算法。
21. request_object_signing_response_alg  - 必须用于签署发送给OP的请求对象的JWS alg算法。
22. request_object_encryption_alg  -  RP声明它可以用于加密发送给OP的请求对象的JWE alg算法。
23. request_object_encryption_enc  -  JWE enc算法，RP声明它可以用于加密发送给OP的请求对象。
24. token_endpoint_auth_method-请求端点的请求客户端身份验证方法。
25. token_endpoint_auth_signing_alg  - 必须用于对JWT进行签名的JWS alg算法，该JWT用于在令牌端点对private_key_jwt和client_secret_jwt身份验证方法的客户端进行身份验证。
26. default_max_age  - 默认最大认证年龄。
27. require_auth_time  - 布尔值，指定是否需要ID令牌中的auth_time声明。
28. default_acr_values  - 默认请求的身份验证上下文类参考值。
29. initiate_login_uri  - 使用https方案的URI，第三方可以使用该方案来启动RP的登录。
30. request_uris  - 由RP预先注册以在OP上使用的request_uri值。

因此，客户端应用程序的数据库表应该能够存储这些信息。此外，应该注意的是，允许本地化某些属性（例如client_name，tos_uri，policy_uri，logo_uri和client_uri）（2.1。元数据语言和脚本）。需要额外考虑数据库表设计来存储本地化属性值。

以下小节是我对客户应用程序属性的个人意见。

6.1 客户类型

我担心定义规范是一种错误2. OpenID Connect动态客户端注册1.0的客户端元数据不包含“客户端类型”。我认为这样做的原因是，当我们实现授权服务器时，必须考虑两种客户端类型之间的区别，“机密”和“公共”（在2.1。客户端类型的RFC 6749中定义）。事实上，“客户端类型”被列为要在2.注册RFC 6749的客户端注册的客户端属性的示例如下。

...注册可以依赖于其他方式来建立信任并获得所需的客户端属性（例如，重定向URI，客户端类型）。

如果这不是错误，则必须就动态客户端注册注册的客户端应用程序的客户端类型达成共识。但是，我无法在相关规范中找到此类信息。

无论如何，我认为在为客户端应用程序定义数据库表时，应该存在客户端类型的列。

您可以在问题991中找到关于此的一些讨论。

6.2。申请类型

根据规范，application_type是可选属性。 application_type的预定义值是native和web。如果省略，则将web用作默认值。

如果省略时使用默认值，则自然结果是客户端应用程序的应用程序类型必须是本机和Web。因此，您可能希望在application_type的列中添加NOT NULL。但是，Authlete的实现不敢添加NOT NULL并允许NULL。

原因是我不确定应用于每个OAuth 2.0客户端的OpenID Connect动态客户端注册1.0中定义的application_type所施加的重定向URI值的限制。

使用OAuth隐式授权类型的Web客户端必须仅使用https方案注册URL作为redirect_uris;他们不能使用localhost作为主机名。本机客户端必须仅使用自定义URI方案或URL使用http：scheme注册redirect_uris，并使用localhost作为主机名。

2年前，我发布了一个问题“应用程序类型（OpenID Connect）是否与客户端类型（OAuth 2.0）对应？”到Stack Overflow，但我无法得到任何答案。所以我自己调查和回答。如果有兴趣请看。

6.3。客户秘密

客户秘密的长度应该是多长时间？

例如，“OpenAM管理指南”使用密码作为客户端机密值的示例。下面是12.4.1的截图。将OpenAM配置为授权服务器和客户端。

似乎OpenAM允许用户使用短字符串作为客户端密钥。

另一方面，在Authlete的实现中，客户端机密自动生成并变得像下面那样长。

GBAyfVL7YWtP6gudLIjbRZV_N0dW4f3xETiIxqtokEAZ6FAsBtgyIq0MpU1uQ7J08xOTO2zwP0OuO3pMVAUTid

这个长度的原因是我想支持512位的对称签名和加密算法。例如，我想支持HS512作为JWS的签名算法。因为客户机密码必须具有512位或更多的熵以支持HS512，所以上述示例的长度是86，这是使用base64url编码512位数据的结果。

关于对称签名和加密算法的熵，OpenID Connect Core 1.0中的16.19对称密钥熵如下所述。

在10.1节和10.2节中，密钥是从client_secret值派生的。因此，当与对称签名或加密操作一起使用时，client_secret值必须包含足够的熵以生成加密强密钥。此外，client_secret值还必须至少包含所使用的特定算法的MAC密钥所需的最小八位字节数。因此，例如，对于HS256，client_secret值必须包含至少32个八位字节（并且几乎可以肯定应该包含更多，因为client_secret值可能使用受限制的字母表）。

并且，3.1。 RFC 7518（JSON Web算法）中的JWS的“alg”（算法）头部参数值指出必须支持HS256（使用SHA-256的HMAC）作为JWS的签名算法。作为合乎逻辑的结果，任何声称符合OpenID Connect的实现都需要生成具有256位或更多熵的客户机密钥。

6.4。签名算法

id_token_signed_response_alg列在“2。 “OpenID Connect动态客户端注册1.0的客户端元数据”。它表示客户端应用程序要求授权服务器用作ID令牌的签名算法的算法。如上所述，有效值列在RFC 7518中，应注意不允许任何值。如果在注册时省略id_token_signed_response_alg的值，则使用RS256。

userinfo_signed_response_alg也是客户端应用程序要求授权服务器使用的签名算法。该算法用于签署从UserI返回的信息

这是偏离主题的，但是为nv-websocket-client（日语信息）创建了一个问题，这是一个用于Java的WebSocket客户端库我在GitHub上向公众开放。问题是一个功能改进的提议，表明当开发人员同时调用setSSLContext（）方法和setSSLSocketFactory（）方法时，库有一个警告机制。之所以提出这个提案，是因为记者对这两种方法的不正当行为感到不安。我的回答是它在JavaDoc中明确写出了当调用这两个方法时哪个设置优先，并且这样的插入检查会使WebSocketFactory类难以使用。然后，反应是“在调用这两种方法之前，先没有详细阅读文档，这是我的错。但是，您认为有多少其他开发人员会在犯同样错误之前先详细阅读文档？“

哦，如果开发人员由于他/她没有阅读文件的原因而浪费时间在自制错误上，这只是一个当之无愧的惩罚......

帮助那些不阅读文件的人的试验将是无止境的。即使库阻止了alg = none的签名，这些工程师也会毫不犹豫地将私钥包含在通过授权服务器的JWK Set端点发布的JWK集中。为什么？你认为那些不读文件的人可以注意到JWKSet类的toPublicJWKSet（）方法的存在（在Nimbus JOSE + JWT库中）并理解方法的含义吗？可能，他们天真地说，“是的，我可以创建一个JWKSet类的实例。我们发布吧！我已经完成了JWK Set端点的实现！“

不参考RFC等主要来源的工程师无法发现他们找到的答案中的错误，并毫无疑问地相信答案。但是，工程师必须避免阅读RFC以成为真正的工程师。

要成为真正的工程师，请不要避免阅读RFC。只搜索技术博客和Stack Overflow寻找答案永远不会把你带到正确的地方。

6.5。 Client Application Developer

一些开源授权服务器提供了一种机制，可以动态注册客户端应用程序，如HTML表单（ForgeRock的OpenAM）和Web API（MITRE的MITREid Connect）。但是，似乎只有授权服务器的管理员才能注册客户端应用程序。但是，理想的方法是创建类似于Twitter的应用程序管理控制台，让开发人员登录，并提供一个环境，让每个开发人员都可以注册和管理他/她自己的客户端应用程序。为此，客户端应用程序的数据库表应该有一个包含开发人员唯一标识符的列。

它经常被遗忘，因为实现授权服务器本身很麻烦，但是还需要提供管理客户端应用程序的机制，以便向公众开放Web API。如果Web API的预期用户仅限于封闭组，则授权服务器的管理员可以在每次请求他/她时注册客户端应用程序。事实上，有一家公司的管理员为每个注册请求手动键入SQL语句。但是，如果要向公众开放Web API，此类操作将无法运行，您将意识到必须为客户端应用程序提供合适的管理控制台。如果您成功确保了开发授权服务器和Web API的预算，但忘记了为客户端应用程序确保管理控制台的预算，则会导致“已实现Web API但无法向公众开放”。

作为此类管理控制台的示例，Authlete为上述用例提供了开发者控制台。 Authlete本身不管理开发人员帐户，但通过名为“开发人员身份验证回调”的机制，其帐户由Authlete客户管理的开发人员可以使用开发人员控制台。因此，Authlete客户不必为客户端应用程序开发管理控制台。

7.访问令牌

7.1。访问令牌表示

如何表示访问令牌？有两种主要方式。

作为无意义的随机字符串。与访问令牌相关联的信息存储在授权服务器后面的数据库表中。

作为一个自包含的字符串，它是通过base64url或类似的东西对访问令牌信息进行编码的结果。

在这些方式之间进行选择将导致后续差异，如下表所述。

如果访问令牌是随机字符串，则每次都需要查询授权服务器以获取有关访问令牌的信息。相反，如果访问令牌本身包含信息，则无需查询授权服务器。这使得自包含样式听起来更好，但是因为必须对授权服务器进行查询以检查访问令牌是否已被撤销，即使采用自包含样式，在任何情况下，网络通信也是如此。每次客户端应用程序呈现访问令牌时都需要。

自包含样式中的繁琐之处在于，每次请求访问令牌撤销时，我们必须添加表示“已撤销”的记录，并且必须保留此类记录，直到访问令牌到期为止。否则，如果删除了记录，则撤销的访问令牌将被复活并再次生效（如果尚未达到原始到期日期）。

相反，在随机字符串样式的情况下，可以简单地通过删除访问令牌记录本身来实现访问令牌撤销。因此，由于任何意外，撤销访问令牌无法复活。此外，不会发生在独立风格中观察到的负面影响“撤销增加记录”。

要启用访问令牌吊销，即使在自包含样式的情况下，也必须为访问令牌分配唯一标识符。否则，无法分辨哪个访问令牌已被撤销。换句话说，授权服务器采用自包含样式但不为访问令牌分配唯一标识符是授权服务器，它不能撤销访问令牌。它可能是实现策略之一，但是这样的授权服务器不应该发出长期访问令牌，也不应该发出刷新令牌。

“无法撤销访问令牌的授权服务器？！”，您可能想知道。但是，这种授权确实存在。某个全球大型系统集成商收购了一家公司，并正在使用被收购公司的产品开发授权服务器，但在后期阶段，系统集成商及其客户注意到授权服务器无法撤销访问令牌。当我听到这个故事时，我猜想授权服务器会发出没有唯一标识符的自包含样式的访问令牌。

自包含的样式看起来很好，因为有一些优点，例如“无需查询授权服务器来提取访问令牌的信息”和“无需在授权服务器端维护访问令牌记录”，但是当你考虑访问令牌撤销，有讨论的余地。

7.2。访问令牌删除

为防止数据库无限增长，应定期从数据库中删除过期的访问令牌。

请求授权服务器不必要地发出访问令牌的客户端应用程序是麻烦制造者。虽然他们已经有一个尚未过期的访问令牌，但他们会重复丢弃这样一个有效的访问令牌并请求新的令牌。如果发生这种情况，则会在数据库中累积未使用但无法删除的访问令牌（因为它们尚未过期）。

要防止出现这种情况，请将访问令牌最后一次使用的时间戳保存到数据库中，以及访问令牌到期的时间戳，并定期运行程序，以便长时间删除未使用的访问令牌。当然，它取决于服务的特性是否可以在未过期时删除未使用的访问令牌。

在此之前，我遇到了一位工程师，他在某个大公司的OAuth实施项目中工作，而他却属于该公司。他告诉我，系统的构建没有考虑访问令牌的删除，因此系统的数据库可能拥有数以亿计的访问令牌。吓人，可怕。当开发生成某个东西的系统时，应该同时考虑删除生成的东西的时间。

8.重定向URI

8.1。重定向URI验证

2014年5月，获博士学位。新加坡的学生发表了一篇文章，它引起了人们对“OAuth中的漏洞？”的讨论，这是一个关于所谓的Covert Redirect的问题。那些正确理解OAuth 2.0的人很快意识到这不是由于规范中的漏洞而是由于不正确的实现。然而，该主题让很多人感到不安，OAuth领域的专家无法帮助编写解释性文档。约翰布拉德利先生的“隐蔽重定向及其对OAuth和OpenID Connect的真正影响”就是其中一个文件。

如果未正确处理重定向URI，则会出现安全问题。相关规范中描述了如何处理重定向URI，但很难正确实现它，因为有许多事情要关注，例如，（a）RFC 6749的要求和OpenID Connect的要求是不同的（b） ）必须考虑客户端应用程序的application_type属性的值。

如何正确处理重定向URI的部分取决于实现者如何仔细和详尽地阅读相关规范。因此，读取部件的实现代码可以很好地猜测整个授权服务器的实现质量。所以，每个人都尽最大努力实施它！

......如果我冷冷地抛弃了你，到目前为止我读过我的长篇文章，我会感到很遗憾，所以我向你展示了Authlete的实施诀窍。以下是处理授权请求中包含的redirect_uri参数的伪代码。请注意，伪代码不必分解为可浏览性的方法，但在实际的Authlete实现中，代码流很好地分解为方法。因此，出于性能目的，实际代码流与伪代码不同。 （如果实际的实现包含如此多的嵌套if和for伪像，那将是一种耻辱。）

 

// Extract the value of the 'redirect_uri' parameter from
// the authorization request.
redirectUri = ...
// Remember whether a redirect URI was explicitly given.
// It must be checked later in the implementation of the
// token endpoint because RFC 6749 states as follows.
//
//   redirect_uri
//      REQUIRED, if the "redirect_uri" parameter was
//      included in the authorization request as described
//      in Section 4.1.1, and their values MUST be identical.
//
explicit = (redirectUri != null);
// Extract registered redirect URIs from the database.
registeredRedirectUris = ...
// Requirements by RFC 6749 (OAuth 2.0) and those by
// OpenID Connect are different. Therefore, the code flow
// branches according to whether the request is an OpenID
// Connect request or not. This is judged by whether the
// 'scope' request parameter contains 'openid' as a value.
if ( 'openid' is included in 'scope' )
{
    // Check requirements by OpenID Connect.
    // If the 'redirect_uri' is not contained in the request.
    if ( redirectUri == null )
    {
        // The 'redirect_uri' parameter is mandatory in
        // OpenID Connect. It's optional in RFC 6749.
        throw new Exception(
            "The 'redirect_uri' parameter is missing.");
    }
    // For each registered redirect URI.
    for ( registeredRedirectUri : registeredRedirectUris )
    {
        // 'Simple String Comparison' is required by the
        // specification.
        if ( registeredRedirectUri.equals( redirectUri ) )
        {
            // OK. The redirect URI specified by the
            // authorization request is registered.
            registered = true;
            break;
        }
    }
    // If the redirect URI specified by the authorization
    // request matches none of the registered redirect URIs.
    if ( registered == false )
    {
        throw new Exception(
            "The redirect URI is not registered.");
    }
}
else
{
    // Check requirements by RFC 6749.
    // If redirect URIs are not registered at all.
    if ( registeredRedirectUris.size() == 0 )
    {
        // RFC 6749, 3.1.2.2. Registration Requirements says
        // as follows:
        //
        //   The authorization server MUST require the
        //   following clients to register their
        //   redirection endpoint:
        //
        //     o Public clients.
        //     o Confidential clients utilizing the
        //       implicit grant type.
        // If the type of the client application which made
        // the authorization request is 'public'.
        if ( client.getClientType() == PUBLIC )
        {
            throw new Exception(
                "A redirect URI must be registered.");
        }
        // If the client type is 'confidential' and if the
        // authorization flow is 'Implicit Flow'. If the
        // 'response_type' request parameter contains either
        // or both of 'token' and 'id_token', the flow should
        // be treated as a kind of 'Implicit Flow'.
        else if ( responseType.requiresImplicitFlow() )
        {
            throw new Exception(
                "A redirect URI must be registered.");
        }
    }
    // If the authorization request does not contain the
    // 'redirect_uri' request parameter.
    if ( redirectUri == null )
    {
        // If redirect URIs are not registered at all,
        // or if multiple redirect URIs are registered.
        if ( registeredRedirectUris.size() != 1 )
        {
            // A redirect URI must be explicitly specified
            // by the 'redirect_uri' parameter.
            throw new Exception(
                "The 'redirect_uri' parameter is missing.");
        }
        // One redirect URI is registered. Use it as the
        // default value of redirect URI.
        redirectUri = registeredRedirectUris[0];
    }
    // The authorization request contains the 'redirect_uri'
    // parameter, but redirect URIs are not registered.
    else if ( registeredRedirectUris.size() == 0 )
    {
        // The code flow reaches here if and only if the
        // client type is 'confidential' and the authorization
        // flow is not 'Implicit Flow'. In this case, the
        // redirect URI specified by the 'redirect_uri'
        // parameter of the authorization request is used
        // although it is not registered. However,
        // requirements written in RFC 6749, 3.1.2.
        // Redirection Endpoint are checked.
        // If the specified redirect URI is not an absolute one.
        if ( redirectUri.isAbsolute() == false )
        {
            throw new Exception(
                "The 'redirect_uri' is not an absolute URI.");
        }
        // If the specified redirect URI has a fragment part.
        if ( redirectUri.getFragment() != null )
        {
            throw new Exception(
                "The 'redirect_uri' has a fragment part.");
        }
    }
    else
    {
        // If the specified redirect URI is not an absolute one.
        if ( redirectUri.isAbsolute() == false )
        {
            throw new Exception(
                "The 'redirect_uri' is not an absolute URI.");
        }
        // If the specified redirect URI has a fragment part.
        if ( redirectUri.getFragment() != null )
        {
            throw new Exception(
                "The 'redirect_uri' has a fragment part.");
        }
        // For each registered redirect URI.
        for (registeredRedirectUri : registeredRedirectUris )
        {
            // If the registered redirect URI is a full URI.
            if ( registeredRedirectUri.getQuery() != null )
            {
                // 'Simple String Comparison'
                if ( registeredRedirectUri.equals( redirectUri ) )
                {
                    // The specified redirect URI is registered.
                    registered = true;
                    break;
                }
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the scheme parts.
            if ( registeredRedirectUri.getScheme().equals(
                     redirectUri.getScheme() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the user information parts. Here I use
            // an imaginary method 'equalsSafely()' because
            // the code would become too long if I inlined it.
            // The method compares arguments without throwing
            // any exception even if either or both of the
            // arguments are null.
            if ( equalsSafely(
                     registeredRedirectUri.getUserInfo(),
                         redirectUri.getUserInfo() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the host parts. Ignore case sensitivity.
            if ( registeredRedirectUri.getHost().equalsIgnoreCase(
                     redirectUri.getHost() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the port parts. Here I use an imaginary
            // method 'getPortOrDefaultPort()' because the
            // code would become too long if I inlined it. The
            // method returns the default port number of the
            // scheme when 'getPort()' returns -1. The last
            // resort is 'URI.toURL().getDefaultPort()'. -1 is
            // returned If 'getDefaultPort()' throws an exception.
            if ( getPortOrDefaultPort( registeredRedirectUri ) !=
                 getPortOrDefaultPort( redirectUri ) )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the path parts. Here I use the imaginary
            // method 'equalsSafely()' again.
            if ( equalsSafely( registeredRedirectUri.getPath(),
                     redirectUri.getPath() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // The specified redirect URI is registered.
            registered = true;
            break;
        }
        // If none of the registered redirect URI matches.
        if ( registered == false )
        {
            throw new Exception(
                "The redirect URI is not registered.");
        }
    }
}
// Check requirements by the 'application_type' of the client.// If the value of the 'application_type' attribute is 'web'.
if ( client.getApplicationType() == WEB )
{
    // If the authorization flow is 'Implicit Flow'. When the
    // 'response_type' request parameter of the authorization
    // request contains either or both of 'token' and 'id_token',
    // it should be treated as a kind of 'Implicit Flow'.
    if ( responseType.requiresImplicitFlow() )
    {
        // If the scheme of the redirect URI is not 'https'.
        if ( "https".equals( redirectUri.getScheme() ) == false )
        {
            // The scheme part of the redirect URI must be 
            // 'https' when a client application whose
            // 'application_type' is 'web' uses 'Implicit Flow'.
            throw new Exception(
                "The scheme of the redirect URI is not 'https'.");
        }
        // If the host of the redirect URI is 'localhost'.
        if ( "localhost".equals( redirectUri.getHost() ) )
        {
            // The host of the redirect URI must not be
            // 'localhost' when a client application whose
            // 'application_type' is 'web' uses 'Implicit Flow'.
            throw new Exception(
                "The host of the redirect URI is 'localhost'.");
        }
    }
}
// If the value of the 'application_type' attribute is 'native'.
else if ( client.getApplicationType() == NATIVE )
{
    // If the scheme of the redirect URI is 'https'.
    if ( "https".equals( redirectUri.getScheme() ) )
    {
        // The scheme of the redirect URI must not be 'https'
        // when the 'application_type' of the client is 'native'.
        throw new Exception(
            "The scheme of the redirect URI is 'https'.");
    }
    // If the scheme of the redirect URI is 'http'.
    if ( "http".equals( redirectUri.getScheme() ) )
    {
        // If the host of the redirect URI is not 'localhost'.
        if ( "localhost".equals(
                 redirectUri.getHost() ) == false )
        {
            // When a client application whose 'application_type'
            // is 'native' uses a redirect URI whose scheme is
            // 'http', the host port of the URI must be
            // 'localhost'.
            throw new Exception(
              "The host of the redirect URI is not 'localhost'.");
        }
    }
}
// If the value of the 'application_type' attribute is neither
// 'web' or 'native'.
else
{
    // As mentioned above, Authlete allows 'unspecified' as a
    // value of the 'application_type' attribute. Therefore,
    // no exception is thrown here.
}

 

8.2。其他的实施

在OpenID Connect中，redirect_uri参数是必需的，关于如何检查呈现的重定向URI是否已注册的要求只是“简单字符串比较”。因此，如果您需要关注的只是OpenID Connect，那么实现将非常简单。例如，在2016年10月在GitHub上赢得大约1,700颗星并且已通过OpenID认证计划认证的IdentityServer3中，检查重定向URI的实现如下（摘自DefaultRedirectUriValidator.cs以及其他格式化新行）。

public virtual Task<bool> IsRedirectUriValidAsync(

string requestedUri, Client client)

{

return Task.FromResult(

StringCollectionContainsString(

client.RedirectUris, requestedUri));

}

OpenID Connect只关心手段，换句话说，授权服务器不接受传统授权代码流和范围请求参数中不包含openid的隐式流。也就是说，这样的授权服务器无法响应任何现有的OAuth 2.0客户端应用程序。

那么，IdentityServer3是否拒绝传统的授权请求？看看AuthorizeRequestValidator.cs，你会发现这个（格式化已经调整）：

if (request.RequestedScopes.Contains(

Constants.StandardScopes.OpenId))

{

request.IsOpenIdRequest = true;

}

//////////////////////////////////////////////////////////

// check scope vs response_type plausability

//////////////////////////////////////////////////////////

var requirement =

Constants.ResponseTypeToScopeRequirement[request.ResponseType];

if (requirement == Constants.ScopeRequirement.Identity

requirement == Constants.ScopeRequirement.IdentityOnly)

{

if (request.IsOpenIdRequest == false)

{

LogError("response_type requires the openid scope", request);

return Invalid(request, ErrorTypes.Client);

}

}

您无需了解此代码的详细信息。关键是有一些路径允许在scope参数中不包含openid的情况。也就是说，接受传统的授权请求。如果是这样，IdentityServer3的实现是不正确的。但是，另一方面，在AuthorizeRequestValidator.cs中的另一个位置，实现拒绝所有不包含redirect_uri参数的授权请求，如下所示（格式化已调整）。

//////////////////////////////////////////////////////////

// redirect_uri must be present, and a valid uri

//////////////////////////////////////////////////////////

var redirectUri = request.Raw.Get(Constants.AuthorizeRequest.RedirectUri);

if (redirectUri.IsMissingOrTooLong(

_options.InputLengthRestrictions.RedirectUri))

{

LogError("redirect_uri is missing or too long", request);

return Invalid(request);

}

因此，实现不必关心省略redirect_uri参数的情况。但是，因为redirect_uri参数在RFC 6749中是可选的，所以行为 - 没有redirect_uri参数的授权请求被无条件拒绝，尽管传统的授权请求被接受 - 违反了规范。此外，IdentityServer3不会对application_type属性进行验证。要实现验证，作为第一步，必须将application_type属性的属性添加到表示客户端应用程序（Client.cs）的模型类中，因为当前实现错过了它。

9.违反规范

细微违反规范的行为有时被称为“方言”。 “方言”一词可能给人一种“可接受”的印象，但违法行为是违法行为。如果没有方言，则为每种计算机语言提供一个通用OAuth 2.0 / OpenID Connect库就足够了。但是，在现实世界中，违反规范的授权服务器需要自定义客户端库。

Facebook的OAuth流程需要其自定义客户端库的原因是Facebook的OAuth实现中存在许多违反规范的行为。例如，（1）逗号用作范围列表的分隔符（它应该是空格），（2）来自令牌端点的响应的格式是application / x-www-form-urlencoded（它应该是JSON） ，以及（3）访问令牌的到期日期参数的名称是过期的（应该是expires_in）。

Facebook和其他大牌公司不仅违反了规范。以下是其他示例。

9.1。范围清单的分隔符

范围名称列在授权端点和令牌端点的请求的范围参数中。 RFC 6749,3.3。访问令牌范围要求将空格用作分隔符，但以下OAuth实现使用逗号：

• Facebook
• GitHub
• Spotify
• Discus
• Todoist

9.2 令牌端点的响应格式

RFC 6749,5.1。成功响应要求来自令牌端点的成功响应的格式为JSON，但以下OAuth实现使用application / x-www-form-urlencoded：

• Facebook
• Bitly
• GitHub

默认格式为application / x-www-form-urlencoded，但GitHub提供了一种请求JSON的方法。

9.3 来自令牌端点的响应中的token_type

RFC 6749,5.1。成功响应要求token_type参数包含在来自令牌端点的成功响应中，但以下OAuth实现不包含它：

松弛

Salesforce也遇到过这个问题（OAuth访问令牌响应丢失token_type），但它已被修复。

9.4 token_type不一致

以下OAuth实现声称令牌类型为“Bearer”，但其资源端点不接受通过RFC 6750（OAuth 2.0授权框架：承载令牌使用）中定义的方式访问令牌：

GitHub（它通过授权格式接受访问令牌：令牌OAUTH-TOKEN）

9.5 grant_type不是必需的

grant_type参数在令牌端点是必需的，但以下OAuth实现不需要它：

• GitHub
• Slack
• Todoist

9.6 错误参数的非官方值

规范已为错误参数定义了一些值，这些值包含在授权服务器的错误响应中，但以下OAuth实现定义了自己的值：

GitHub（例如application_suspended）

Todoist（例如bad_authorization_code）

9.7。错误时参数名称错误

以下OAuth实现在返回错误代码时使用errorCode而不是error：

线

10.代码交换的证明密钥

10.1。 PKCE是必须的

你知道PKCE吗？它是一个定义为RFC 7636（OAuth公共客户端的代码交换证明密钥）的规范，于2015年9月发布。它是针对授权代码拦截攻击的对策。

 

攻击成功需要一些条件，但如果您考虑发布智能手机应用程序，强烈建议客户端应用程序和授权服务器都支持PKCE。否则，恶意应用程序可能拦截授权服务器发出的授权代码，并将其与授权服务器的令牌端点处的有效访问令牌交换。

在2012年10月发布了RFC 6749（OAuth 2.0授权框架），因此即使熟悉OAuth 2.0的开发人员也可能不知道2015年9月最近发布的RFC 7636。但是，应该注意的是“OAuth 2.0 for Native Apps”草案表明，在某些情况下，它的支持是必须的。

客户端和授权服务器都必须支持PKCE [RFC7636]使用自定义URI方案或环回IP重定向。授权服务器应该使用自定义方案拒绝授权请求，或者如果不存在所需的PKCE参数，则将环回IP作为重定向URI的一部分，返回PKCE [RFC7636]第4.4.1节中定义的错误消息。建议将PKCE [RFC7636]用于应用程序声明的HTTPS重定向URI，即使这些URI通常不会被拦截，以防止对应用程序间通信的攻击。

支持RFC 7636的授权服务器的授权端点接受两个请求参数：code_challenge和code_challenge_method，令牌端点接受code_verifier。并且在令牌端点的实现中，授权服务器使用（a）客户端应用程序呈现的代码验证器和（b）客户端应用程序在授权端点处指定的代码质询方法来计算代码质询的值。如果计算的代码质询和客户端应用程序在授权端点处呈现的code_challenge参数的值相等，则可以说发出授权请求的实体和发出令牌请求的实体是相同的。因此，授权服务器可以避免向恶意应用程序发出访问令牌，该恶意应用程序与发出授权请求的实体不同。

 

RFC 7636的整个流程在Authlete的网站上进行了说明：代码交换的证明密钥（RFC 7636）。如果您有兴趣，请阅读。

10.2 服务器端实现

在授权端点的实现中，授权服务器必须做的是将授权请求中包含的code_challenge参数和code_challenge_method参数的值保存到数据库中。因此，实现代码中没有任何有趣的内容。需要注意的是，想要支持PKCE的授权服务器必须将code_challenge和code_challenge_method的列添加到存储授权码的数据库表中。

Authlete的完整源代码是保密的，但是为了您的兴趣，我在这里向您展示了实际的Authlete实现，它验证了令牌端点处code_verifier参数的值。

private void validatePKCE(AuthorizationCodeEntity acEntity)

{

// See RFC 7636 (Proof Key for Code Exchange) for details.

// Get the value of 'code_challenge' which was contained in

// the authorization request.

String challenge = acEntity.getCodeChallenge();

if (challenge == null)

{

// The authorization request did not contain

// 'code_challenge'.

return;

}

// If the authorization request contained 'code_challenge',

// the token request must contain 'code_verifier'. Extract

// the value of 'code_verifier' from the token request.

String verifier = extractFromParameters(

"code_verifier", invalid_grant, A050312, A050313, A050314);

// Compute the challenge using the verifier

String computedChallenge = computeChallenge(acEntity, verifier);

if (challenge.equals(computedChallenge))

{

// OK. The presented code_verifier is valid.

return;

}

// The code challenge value computed with 'code_verifier'

// is different from 'code_challenge' contained in the

// authorization request.

throw toException(invalid_grant, A050315);

}

private String computeChallenge(

AuthorizationCodeEntity acEntity, String verifier)

{

CodeChallengeMethod method = acEntity.getCodeChallengeMethod();

// This should not happen, but just in case.

if (method == null)

{

// Use 'plain' as the default value required by RFC 7636.

method = CodeChallengeMethod.PLAIN;

}

switch (method)

{

case PLAIN:

// code_verifier

return verifier;

case S256:

// BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

return computeChallengeS256(verifier);

default:

// The value of code_challenge_method extracted

// from the database is not supported.

throw toException(server_error, A050102);

}

}

private String computeChallengeS256(String verifier)

{

// BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

// SHA256

byte[] hash =

Digest.getInstanceSHA256().update(verifier).digest();

// BASE64URL

return SecurityUtils.encode(hash);

}

用于实现computeChallengeS256（String）方法的Digest类包含在我的开源库nv-digest中。它是一个实用程序库，可以轻松进行摘要计算。使用此库，计算SHA-256摘要值可以写成一行，如下所示。

byte[] hash = Digest.getInstanceSHA256().update(verifier).digest();

10.3。客户端实施

客户端应用程序必须为PKCE做些什么。一种是生成一个由43-128个字母组成的随机码验证器，使用代码验证器和代码质询方法（plain或S256）计算代码质询，并包括计算出的代码质询和代码质询方法作为值授权请求中的code_challenge参数和code_challenge_method参数。另一种是在令牌请求中包含代码验证器。

作为客户端实现的示例，我将介绍以下两个。

1. AppAuth for Android
2. AppAuth for iOS

它们是用于与OAuth 2.0和OpenID Connect服务器通信的SDK。他们声称他们包括最佳实践并支持PKCE。

如果为code_challenge_method = S256实现计算逻辑，则可以通过在代码验证器的值为dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk时检查代码质询的值是否变为E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM来测试它。这些值在RFC 7636的“附录B. S256 code_challenge_method的示例”中作为示例值找到。

11.最后

有些人可能会说实施OAuth和OpenID Connect很容易，其他人可能会说不是。在任何一种情况下，事实上，即使是拥有足够预算和人力资源的Facebook和GitHub等大型科技公司也未能正确实施OAuth和OpenID Connect。着名的开源项目如Apache Oltu和Spring Security也存在问题。因此，如果您自己实施OAuth和OpenID Connect，请认真对待并准备一个体面的开发团队。否则，安全风险将会增加。

仅仅实现RFC 6749并不困难，但是从头开始实施OpenID Connect会让您发疯。因此，建议使用现有实现作为起点。第一步是在OpenID Connect网站中搜索与OAuth和OpenID Connect相关的软件的“库，产品和工具”页面（尽管未列出Authlete）。当然，作为Authlete，Inc。的联合创始人，如果您选择Authlete，我将很高兴。

感谢您阅读这篇长篇文章。

原文：https://medium.com/@darutk/full-scratch-implementor-of-oauth-and-openid-connect-talks-about-findings-55015f36d1c3

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

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

 

在任何公司，网络用户必须经过身份验证和授权，才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。在本指南中，我讨论了管理系统访问控制的两种主要方法：基于角色的访问控制（RBAC）和基于属性的访问控制。我还回顾了SolarWinds®访问权限管理器，它是我的首选解决方案，可帮助团队更轻松地监控整个组织的访问控制。

• 身份验证和授权
• 基于角色访问控制（RBAC）与基于属性访问控制（ABAC）
  • 什么是RBAC？
  • 什么是ABAC？
  • RBAC与ABAC
• 最佳访问管理工具
• 如何选择访问控制解决方案

身份验证和授权

安全的两个基本方面是身份验证和授权。输入凭据以登录计算机或登录应用程序或软件后，设备或应用程序将进行身份验证以确定您的授权级别。授权可能包括您可以使用哪些帐户、您可以访问哪些资源以及您可以执行哪些功能。

基于角色访问控制（RBAC）与基于属性访问控制（ABAC）

基于角色访问控制（RBAC）和基于属性访问控制（ABAC）是控制身份验证过程和授权用户的两种方式。RBAC和ABAC的主要区别是RBAC基于用户角色提供对资源或信息的访问，而ABAC基于用户、环境或资源属性提供访问权限。本质上，当考虑RBAC与ABAC时，RBAC控制整个组织的广泛访问，而ABAC采用细粒度方法。

什么是RBAC？

RBAC是基于角色的，因此根据您在组织中的角色，您将拥有不同的访问权限。这由管理员决定，管理员设置角色应具有的访问权限的参数，以及分配给哪些用户的角色。例如，某些用户可能被分配到一个角色，在该角色中，他们可以编写和编辑特定文件，而其他用户可能被限制为只能阅读文件，但不能编辑文件。

一个用户可以被分配多个角色，从而可以访问许多不同的文件或功能。假设有一个团队在一个大型项目上工作。项目经理可以访问所有文件，并可以编辑和更改项目中的内容。然而，开发团队可能只能访问编程文件，无法查看或编辑项目的财务信息或员工详细信息。另一方面，人力资源或管理团队可能可以访问所有员工和财务信息，但不能使用编程文件。

组织可能会将RBAC用于此类项目，因为使用RBAC，不需要在每次人员离开组织或更改工作时更改策略：只需将其从角色组中删除或分配给新角色即可。这也意味着新员工可以相对快速地获得访问权限，这取决于他们履行的组织角色。

 

什么是ABAC？

基于属性的访问控制利用了一组称为“属性”的特性。这包括用户属性、环境属性和资源属性。

• 用户属性包括用户名、角色、组织、ID和安全许可等内容。
• 环境属性包括访问时间、数据位置和当前组织威胁级别。
• 资源属性包括创建日期、资源所有者、文件名和数据敏感性。

本质上，ABAC具有比RBAC多得多的可能控制变量。ABAC的实现是为了减少未经授权的访问带来的风险，因为它可以在更细粒度的基础上控制安全和访问。例如，ABAC可以对其访问设置进一步的限制，例如只允许在特定时间或与相关员工相关的特定分支机构访问，而不是让HR角色的人员始终能够访问员工和工资信息。这可以减少安全问题，也有助于以后的审核过程。

RBAC与ABAC

通常，如果RBAC足够了，您应该在设置ABAC访问控制之前使用它。这两个访问控制过程都是过滤器，ABAC是这两个过程中比较复杂的，需要更多的处理能力和时间。如果你不需要它，那么使用这个更强大的过滤器并承担相应的资源成本是没有意义的。

无论如何，使用最少数量的RBAC和ABAC过滤器来构建访问和安全环境都很重要。它可以帮助您仔细规划目录数据和访问方法，以确保您没有使用不必要的过滤器或使事情过于复杂。在许多情况下，RBAC和ABAC可以分层使用，RBAC协议实施广泛访问，ABAC管理更复杂的访问。这意味着系统将首先使用RBAC来确定谁有权访问资源，然后使用ABAC来确定他们可以使用资源做什么以及何时可以访问资源。

 

最佳访问管理工具

无论您使用RBAC还是ABAC，或者两者的组合，我强烈建议您使用访问权限管理工具。一个好的工具可以简化设置并减少设置和管理筛选器所涉及的管理开销。我选择的是Access Rights Manager，这是一个高质量的工具，专门用于管理和审核整个IT基础架构的访问权限。

Access Rights Manager包括一个用户管理系统，用于监视、分析和报告Active Directory和组策略，并可以向您显示所做的更改、更改者和更改时间，这有助于您最大限度地减少内部威胁的可能性。它包括旨在帮助您实施特定于角色的安全性以及用户帐户的设置和取消设置的模板。您可以在一个简单的过程中顺利地委派对文件、文件夹或资源的访问，以减少管理开销。

如何选择访问控制解决方案

在安全方面，仔细规划和监控访问控制过程至关重要。使用强大的访问管理工具来帮助您设置访问控制，并定期检查您的设置，以确保它仍然符合您的组织需求。无论您是投资SolarWinds的Access Rights Manager，还是走另一条路，请确保您选择的工具可以设置协议和机制，以确保用户能够正确访问他们的工作所需的内容，而无需其他。

【应用安全】SAML2 vs JWT：比较

这篇文章总结了我们对SAML2和JWT的讨论。在这里，我们看一下这两种技术的特性和用例的比较。很难对JWT和SAML2进行直接比较。正如我们在本系列中看到的那样，必须考虑与这些规范一起使用的规范。

对于JWT，我们必须考虑：

• OAuth2 family of specs
• OpenID Connect family of specs
• JWE
• JWS

对于SAML2，我们必须考虑

• SAML2 family of specs
• XML Digital Signature
• XML Encryption
• WS-Security
• WS-Trust

以下总结了SAML2和JWT之间的主要区别。此帖子的原始版本使用表格格式，但Medium.com不支持表格。

年龄

 

• SAML2：SAML 1.0于2002年推出; SAML2于2005年推出。
• JWT：2014年发布的JWT RFC.JWT更新。

采用

 

• SAML2：SAML2是Enterprise SSO的事实标准。它已经有一段时间了。
• JWT：JWT，OAuth2和OpenID Connect在社交媒体和科技创业公司中很常见，但现在才进入企业。

哲学

 

• SAML2：更多的学术方法。简单性不是设计目标。假设将开发运行时库来实现此功能。
• JWT：简单。首先假设应用程序开发人员将实现客户端代码。随着规范的成熟和企业的采用，社区开始摆脱这种局面。

令牌类型

 

• SAML2：SAML断言（格式严格按规格定义）
• OAuth2：access_token（可以是JWT，但不一定是）
• OIDC：access_token（可以是JWT）和id-token（必须是JWT）。

数据结构

 

• SAML2：XML（使用XSD定义的结构）
• JWT：JSON（有趣的是，结构不是由JSON Schema定义的）

大小

 

• SAML2：与JWT相比，趋向于非常大。大小取决于存在的字段，使用签名和加密。
• JWT：比SAML2令牌小很多。 Spec鼓励使用对签名证书的引用而不是嵌入它 - 消除了大型x509签名者证书。
• 支持消息传递协议
• SAML2：主要基于SOAP。
• JWT：REST API

绑定和传输协议

 

• SAML2：SAML2可以是HTTP POST，HTTP GET，SOAP（取决于场景），JMS（很少见，但可能发生），等等
• JWT：HTTPS

数字签名

 

• SAML2：XML签名
• JWT：JWS（支持的散列和加密算法略有不同）

消息级加密

 

• SAML2：XML加密
• JWT：JWE（支持的加密算法略有不同）***

X509证书表示

 

• SAML2：X509BinarySecurityToken类型
• JWT：JSON Web Key规范（JWK）

核心规格范围

 

• SAML2：定义令牌（SAML断言）和底层协议（用于Web App SSO）的结构。
• JWT：JWT仅定义令牌结构。 OAuth2和OpenID Connect定义协议。

客户端基础架构

 

• SAML2：通常需要支持库（重量级）
• JWT：通常可以通过构造简单的HTTP查询来实现。签名和加密将是此规则的例外。*

主题确认方法支持

 

• SAML2：SAML2支持承载令牌，密钥持有者和发件人凭证。
• JWT：JWT最初只支持Bearer Tokens。 Key持有人（2016年4月增加了占有证明支持）。

授权和假冒（OnBehalfOf和ActAs）

 

• SAML2：在WS-Trust规范中定义
• JWT：OAuth2的扩展规范（OAuth2令牌交换规范）

支持动态信任库更新和元数据信息的发布。

 

• SAML2：WS-Federation规范定义了如何发布此信息。但是，它并没有普遍使用。客户端很少动态检索IdP发布的信息以更新其签名者证书信任库。
• JWT：OpenID Connect Discovery规范定义了发布IdP元数据的元数据端点。强烈建议构建可以访问此信息并动态构建/更新信任库的客户端。**

*使用库几乎总是建议从头开始构建查询/请求。
**当必须续签签名者证书时，这一个细节可以节省1000个工时。
*** JWE和XML加密也会有很多相关的差异，但我还没有达到那个系列:)。
XML DSig与JSON Web签名系列中列出的所有差异也适用于此处。

讨论: 请加入知识星球【首席架构师圈】