面向红队的云端渗透测试-全-

面向红队的云端渗透测试（全）

原文：annas-archive.org/md5/640c86a8583d91f9f3f8aa69d0ac774a

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

恭喜你，亲爱的读者！在过去大约 15 年里，云平台的使用取得了巨大的增长。亚马逊的 AWS 在 2006 年正式推出，微软的 Azure 和谷歌云平台（GCP）随后在 2008 年推出。市面上有许多云平台，但 AWS、Azure 和 GCP 是最受欢迎的。AWS、Azure 和 GCP 使企业、组织和公司能够部署比自己在本地基础设施上能做的更强大、可扩展的网络。许多组织甚至在其网络中使用不止一个云平台。

云网络与公共互联网连接，因此自然容易受到各种网络攻击的威胁。随着云平台的日益普及，企业意识到需要保护其云网络以确保商业成功，具备云渗透测试技能的人才在国际就业市场上非常抢手。通过学习如何在云平台上模拟网络攻击以进行安全测试，无论你身在何处，你的能力都会受到青睐。

在云平台进行渗透测试和红队演练与在公司本地网络中进行测试有根本的不同，因为亚马逊、微软和谷歌拥有基础设施。作为渗透测试人员，你必须遵守比你所在组织的规则和政策更多的规定和政策。本书将教你如何以云原生的方式进行渗透测试和红队演练。

本书适用对象

本书适用于有经验的渗透测试人员以及刚开始学习渗透测试的人。如果你有传统本地网络渗透测试的经验，本书将教你如何在 AWS、Azure 和 GCP 中进行渗透测试，并与本地网络测试有所不同。如果你刚刚开始学习渗透测试，这本书是一个很好的起点，因为云计算是渗透测试的未来。无论哪种情况，你都应该对计算机网络有一定了解，并渴望提升自己的技能。

本书内容

第一章，企业如何利用和实施云网络？，介绍了 AWS、Azure 和 GCP，混合云、全云和多云网络之间的差异，软件即服务、平台即服务和基础设施即服务，以及组织与云服务提供商之间共享的网络安全责任。在你开始进行 AWS、Azure 和 GCP 的渗透测试之前，了解企业为什么以及如何使用这些云平台非常重要。

第二章，云网络如何遭受网络攻击？，研究了云网络如何容易受到各种网络攻击。本章解释了外部和内部的各种网络攻击类型，以及影响计算机数据的机密性、完整性和可用性的攻击，这些都是基于 CIA 三原则的网络安全模型。你将通过模拟一些网络威胁行为者的操作来测试云网络的安全性。

第三章，今天云网络渗透测试的关键概念，介绍了适用于所有云渗透测试的核心概念和流程。在进行渗透测试或红队任务之前，安全专家必须了解渗透测试目标的状态和范围。你需要进行漏洞评估，以发现暴露的服务和集成，一旦渗透测试完成，你需要有效地分享你的发现，以便改善客户的安全态势。

第四章，AWS 中的安全特性，探索了 AWS 特有的一系列功能、应用程序和工具，以及它们对渗透测试人员的影响。本章还涵盖了 AWS 的安全策略和安全工具。

第五章，通过无服务器应用和工具进行 AWS 特性渗透测试，讨论了进行最成功的 AWS 渗透测试所需的最相关和最有效的安全特性和工具。AWS 有许多特定的安全控制、安全特性和渗透测试工具，包括第一方和第三方工具。

第六章，在 AWS 中渗透测试容器化应用程序，深入探讨了在 AWS 中如何部署和管理 Docker 与 Kubernetes 的具体技术细节。企业越来越多地在 AWS 中部署容器化应用，以充分利用容器化的可扩展性进行虚拟化。你将学习到一些在 AWS 中容器化平台运行时独有的渗透测试技巧。

第七章，Azure 中的安全特性，探索了 Azure 特有的一系列功能、应用程序和工具，以及它们对渗透测试人员的影响。本章还涵盖了 Azure 的安全策略和安全工具。

第八章，通过无服务器应用和工具进行 Azure 特性渗透测试，分析了进行最成功的 Azure 渗透测试所需的最相关和最有效的安全特性和工具。Azure 有许多特定的安全控制、安全特性和渗透测试工具，包括第一方和第三方工具。

第九章，在 Azure 中渗透测试容器化应用程序，涵盖了 Docker 和 Kubernetes 在 Azure 中如何部署和管理的具体技术细节。企业越来越多地在 Azure 中部署容器化应用程序，以充分利用容器化虚拟化的可扩展性。你还将学习到针对这些容器化平台在 Azure 中运行的渗透测试技术。

第十章，GCP 中的安全功能，深入探讨了 GCP 特有的大量功能、应用程序和工具，以及它们对渗透测试人员的影响。本章还涵盖了 GCP 的安全政策和安全工具。

第十一章，通过无服务器应用程序和工具进行 GCP 功能渗透测试，研究了进行最成功的 GCP 渗透测试的最相关和有效的安全功能和工具。有许多特定于 GCP 的安全控制、安全功能和渗透测试工具，包括第一方和第三方工具。

第十二章，在 GCP 中渗透测试容器化应用程序，涵盖了 Docker 和 Kubernetes 在 GCP 中如何部署和管理的具体技术细节。企业越来越多地在 GCP 中部署容器化应用程序，以充分利用容器化虚拟化的可扩展性。你还将学习到针对这些容器化平台在 GCP 中运行的渗透测试技术。*

第十三章，最佳实践与总结，回顾了在 AWS、Azure 和 GCP 中执行渗透测试练习后所学到的内容。本章还解释了在渗透测试和红队演练前后需要进行的工作。最重要的是，你需要与所在组织定义一个遵守 AWS、Azure 和 GCP 政策的测试范围，签署正式化你责任与范围的法律文件，并撰写一份渗透测试报告，帮助公司领导和防御安全团队提升网络的网络安全性。

为了充分利用本书

你将需要以下设备：

书中涵盖的软件/硬件	操作系统要求
AWS 网页控制台：aws.amazon.com	Windows 7、8、10 或 11，macOS 11–14，或当前支持的 Linux 发行版，以及 Safari、Edge、Chrome、Firefox 或 Opera 浏览器的当前支持版本
Microsoft Azure 网页控制台：azure.microsoft.com	Windows 7、8、10 或 11，macOS 11–14，或当前支持的 Linux 发行版，以及 Safari、Edge、Chrome、Firefox 或 Opera 浏览器的当前支持版本
Google Cloud Platform 网页控制台在 console.cloud.google.com	Windows 7、8、10 或 11，macOS 11–14，或当前支持的 Linux 发行版，支持的 Safari、Edge、Chrome、Firefox 或 Opera 浏览器版本
Prowler	在 AWS、Azure 和 GCP 中支持；端点操作系统无关
Pacu	在 AWS 中支持，端点操作系统无关
Cred Scanner	在 AWS 中支持，端点操作系统无关
CloudFrunt	在 AWS 中支持，端点操作系统无关
Redboto Python 脚本	在 AWS 中支持，端点操作系统无关
Docker Desktop	Windows 7、8、10 或 11，macOS 11–14，或当前支持的 Linux 发行版
ScoutSuite	在 AWS、Azure 和 GCP 中支持；端点操作系统无关
MFASweep	在 Azure 中支持，端点操作系统无关
kube-hunter	在所有当前版本的 Kubernetes 中支持；端点操作系统无关
kdigger	在所有当前版本的 Kubernetes 中支持；端点操作系统无关
GCPBucketBrute	在 GCP 中支持，端点操作系统无关
GCP 扫描器	在 GCP 中支持，端点操作系统无关

Code in Action

本书的Code in Action视频可以在 bit.ly/3rWmFnS 上观看。

免责声明

本书中的信息仅应以道德方式使用。如果没有设备所有者的书面许可，请不要使用本书中的任何信息。如果你进行非法行为，可能会被逮捕并依法追究责任。如果你滥用本书中的任何信息，Packt Publishing 不承担任何责任。书中的信息只能在经过适当授权的测试环境中使用。

约定使用

本书中使用了一些文本约定。

文本中的代码：表示文本中的代码字、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号。例如：“将下载的WebStorm-10*.dmg磁盘镜像文件挂载为系统中的另一个磁盘。”

任何命令行输入或输出按如下格式编写：

pip install --upgrade pip 
pip install prowler

粗体：表示新术语、重要单词或屏幕上显示的单词。例如，菜单或对话框中的单词显示为粗体。例如：“从管理面板中选择系统信息。”

提示或重要说明

如下所示。

与我们联系

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何部分有疑问，请通过电子邮件联系我们：customercare@packtpub.com，并在邮件主题中注明书名。

勘误表：虽然我们已尽力确保内容的准确性，但仍然可能出现错误。如果您在本书中发现错误，我们将非常感激您向我们报告。请访问www.packtpub.com/support/errata并填写表格。

盗版：如果您在互联网上遇到任何形式的非法复制品，我们将非常感激您提供该材料的地址或网站名称。请通过版权@packt.com 与我们联系并提供链接。

如果您有兴趣成为作者：如果您在某个领域具有专业知识并且有兴趣编写或参与编写一本书，请访问authors.packtpub.com。

分享您的想法

阅读完《云渗透测试：红队实战》后，我们很想听听您的想法！请点击这里直接前往本书的亚马逊评价页面，分享您的反馈。

您的评价对我们和技术社区非常重要，它将帮助我们确保提供优质的内容。

下载本书的免费 PDF 副本

感谢您购买本书！

您喜欢在路上阅读，但无法随身携带纸质书籍吗？

您的电子书购买无法与您选择的设备兼容吗？

不用担心，现在购买任何 Packt 书籍，您都可以免费获得该书的 DRM-free PDF 版本。

随时随地，在任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制和粘贴代码到您的应用中。

优惠不仅仅是这些，你还可以每天在邮箱中获得独家折扣、新闻通讯和精彩的免费内容。

按照这些简单的步骤获取福利：

1. 扫描二维码或访问下面的链接

packt.link/free-ebook/9781803248486

2. 提交您的购买证明

3. 就是这样！我们将直接通过电子邮件发送您的免费 PDF 和其他福利。

第一部分：今天的云网络及其安全影响

渗透测试人员和红队成员测试计算机系统的安全性。在本书中，您将学习如何渗透测试的计算机系统是云应用和网络。在开始测试之前，您应该了解您正在测试的内容！因此，在这一部分，我们将学习各种云服务和应用的类型，为什么组织使用它们，以及它们是如何配置和部署的。我们还将学习渗透测试和红队的基础知识。这些知识将为您在本书中学习的其他内容奠定基础。

本节包含以下章节：

• 第一章，企业如何利用和实施云网络？

• 第二章，云网络如何遭受网络攻击？

• 第三章，当今云网络渗透测试的关键概念

第一章：企业如何利用和实施云网络？

欢迎阅读！无论你是已经有经验的渗透测试员，还是刚接触网络安全的新人，渗透测试云网络需要专门的知识。在渗透测试云网络和渗透测试本地网络及计算机系统之间的一个关键区别是，你所工作的组织并不拥有其计算环境中的所有内容。当你在云网络中进行红队演练时，你所工作的组织及其云服务提供商（无论是亚马逊云服务（AWS）、Azure，还是谷歌云平台（GCP））都有必须尊重的需求。好消息是，如果你掌握了渗透测试云网络的技能，你可能会迎来一份丰厚的职业生涯。如今，组织比以往任何时候都更依赖云服务，且对云服务的需求持续增长。

渗透测试员在得到网络所有者的许可后，模拟网络中的网络攻击，以发现攻击者可能发现的安全漏洞。雇佣你进行渗透测试（pentest）的公司可能已经对其网络进行了漏洞评估和审计。通过评估和审计，可以发现很多安全漏洞。渗透测试是一种动手操作的检查方法，用于发现可能被遗漏的额外安全漏洞。

红队是组织内部的一个团队，定期执行有针对性的渗透测试。你的公司网络安全团队可能通过安全运营中心（SOC）或更广泛的网络安全社区了解新的网络威胁和高级持续性威胁（APT）。红队会被告知某些新兴的威胁，并被要求模拟这些威胁。通过这样做，红队能够发现新兴攻击者可能利用的漏洞。这些发现会与防御安全团队共享，防御团队会根据这些信息加强其网络的安全性，以防止威胁攻击组织。例如，一个新的勒索软件团体可能成为新闻头条。红队的任务是研究这个新的勒索软件团体如何运作。然后，下一步是他们在下次红队演练中假装成这个新的勒索软件团体。红队，作为进攻性安全专家，通常会全年保持忙碌，因为每年、每月、每周甚至每天都会有新的网络攻击团体和网络威胁出现！

本章将涵盖以下主要内容：

• 今日的云网络

• 混合云、全云和多云网络

• 为什么一个组织会拥有多云网络

• 云迁移过程

• 云中的安全责任

• 基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）之间的区别

让我们开始吧！

今日的云网络

为了能够有效地测试你的渗透测试目标，你必须首先理解它。自从 AWS 在 2006 年以现有形态推出以来，云网络在企业市场中变得越来越受欢迎。微软 Azure 和 GCP 自 2008 年以来就已经存在。这三个云平台是全球各类企业和公司最常使用的平台。如今，大多数企业在其网络中至少使用一个云平台。一些企业甚至同时使用多个云平台。那么，云平台是什么，它们为何如此受欢迎？云平台如何改善公司在互联网上开展业务的方式？

在 1990 年代，企业必须在自己场所托管自己的数据中心。那个年代开始出现了网站托管服务提供商，但它们仅提供网站服务器和电子邮件服务器。这对组织的官方网站和电子邮件有好处，但对于其他任何需求则不适用。如果公司需要运行自己更复杂的应用程序和数字服务，它们就需要拥有自己的服务器机房和设备。

任何具有多年经验的网络管理员都明白，企业的计算机网络需求可能会迅速变化。带宽和数据存储的使用量可能在几个月内翻倍，然后在接下来的几个月内减半。如果它们的需求在短时间内迅速增长，那么就必须采购大量新的服务器和网络基础设施，并且需要更多的物理空间来安置它们。如果它们的需求大幅缩小，那么很多昂贵的服务器设备、网络基础设施和物理空间都会浪费掉。在公司部署大规模本地网络时，许多不便、低效和财务浪费是不可避免的。

到目前为止，21 世纪已经带来了计算机网络技术的有益进步。像亚马逊、微软和谷歌这样的科技巨头在全球各地拥有庞大的数据中心。它们开始通过将其庞大的计算机网络基础设施提供给第三方企业和其他实体来加以利用。AWS 于 2006 年推出，随后微软 Azure 和 GCP 在 2008 年跟进。它们让企业在自有基础设施上部署网络变得比以往任何时候都更简单、顺畅。

容器化是一种实现操作系统和硬件虚拟化，并通过负载均衡在网络中以可扩展和动态的方式部署应用程序的方式，能够更高效地使用服务器机器。当操作系统被虚拟化时，它像应用程序一样在另一个操作系统中运行，并具有模拟的硬件规格。负载均衡将网络流量分配到多个服务器机器上，防止服务器过载，提升应用程序的可用性和响应速度。每个容器都有操作系统组件，并且是应用程序的一部分。容器在容器编排平台和宿主操作系统或直接的虚拟机管理程序中运行。因为容器是自给自足的虚拟化实体，一个应用程序在任何时候可能会使用大量容器，而任何单个容器的生命周期可能只有几天。容器可以根据云应用程序的需求快速启动和终止，支持应用程序持续运行。

Docker 于 2013 年问世，Kubernetes 于 2015 年开始流行。虽然还有其他容器化编排平台，但 Docker 和 Kubernetes 是你在云网络中最常见的容器编排平台。这些平台是 AWS、Azure 和 GCP 最好支持的容器化编排平台。随着容器化的普及，它促进了更多企业将云平台融入其网络中。

DevOps 方法已经改变了组织推出应用程序的方式。这是一个主要用于开发面向云部署的应用程序的方法。通过将开发和运维（IT）团队结合在一起，DevOps 促进了持续的协作。团队以小规模并且非常频繁的方式修补应用程序并部署新功能。与其每年发布一次应用程序的 1.5 版本，下一年发布 1.6 版本，不如每个月更新多次应用程序。DevOps 补充了敏捷应用程序开发，因此应用程序的部署更加高效和响应迅速。虽然可以在没有云的情况下使用 DevOps 方法论，但云环境使得这一方法更加可行。作为云渗透测试员，你很可能至少会在某个时刻测试 DevOps 应用程序。而且，由于 DevOps 应用程序变化的频繁，这将使你一直忙碌。DevSecOps 是将安全性融入 DevOps 中，你很可能会成为这个过程中的安全部分。

自从 AWS、Azure 和 GCP 推出以来，它们不断增加新的服务和功能。如果每个云平台的服务列表是一份餐厅菜单，2009 年可能只有几道菜，而到 2023 年，菜单上则有多页的主菜。所有这些新的服务和功能使得组织能够用云平台做更多种类的事情。

亚马逊、微软和谷歌负责维护他们的基础设施和应用程序编程接口（APIs）以供其服务使用。他们负责运行他们的数据中心并管理他们在全球各地运营的大型设施。当企业使用云平台时，它们不再需要处理这么多负担。

如果一个组织突然需要将其数据存储容量和网络带宽翻倍，它只需向亚马逊、微软或谷歌提出要求，支付费用，几乎立即就能得到。如果一个组织的网络需求减少，减少其数据存储和带宽同样容易。这就是我们所说的可伸缩性。云服务根据组织在任何特定时间的计算需求动态地和响应地扩展。

将 AWS、Azure 和 GCP 的庞大基础设施与容器化相结合，云网络可以快速增长和演变，企业无需处理运行自己数据中心的麻烦。应用程序可以快速增长、缩小和快速变化。部署应用程序的组织拥有完全控制权，而云平台提供商处理所有物理琐事。

诸如 Netflix、Steam 和 Dropbox 等服务今天响应迅速且功能强大，因为它们利用了云的潜力。当然，许多各行各业的小组织也使用云平台。同一 AWS 数据中心可能同时拥有一家著名的视频流媒体服务和一家税务和会计小企业，甚至可能在一些相同的物理服务器上运行。

这就是为什么云平台如此受欢迎的原因。企业现在深深承诺使用云平台，因此作为红队的渗透测试人员，你将被期望非常了解它们。云平台是 21 世纪的一种必不可少的商业工具。不幸的是，由于云平台通过互联网运作，它们容易受到各种可怕的网络威胁。组织需要你的才能和技能来像网络攻击者一样思考。找出攻击者将利用的漏洞，以便你的蓝队（防御性安全专家）能够有效地加固你的云网络安全。

作为一名红队人员，网络威胁将始终让你保持警惕。你将总是很忙。请听取著名计算机科学家和网络安全专家布鲁斯·施奈尔的建议：

“安全是一个过程，而不是一个产品。产品提供一定的保护，但在一个不安全的世界中有效开展业务的唯一方法是建立一套认识到产品固有不安全性的流程。”

在接下来的部分中，我们将研究不同类型的云网络。根据组织的云网络类型，你对其进行渗透测试的方式将有所不同。

混合云、全云和多云网络

云网络可以采用几种不同形式。一些组织将其客户端机器（如个人电脑和移动设备）保留在自己的场所，然后将其后端服务器完全运行在一个特定的云平台上。这是一个在 AWS、Azure 或 GCP 等一个平台上的全云网络。

一些组织在自己的场所运行一些服务器机器，并在一个或多个云平台上运行其余网络。这就是混合云网络——部分在本地，部分在云上。

一些组织通过多个云平台部署其网络。例如，它们可能在 AWS 上运行一些网络部分，而在 Azure 上运行其他部分。这就是多云网络。

让我们来看看这些不同的云网络操作方式是如何运作的，以及为什么组织可能会选择一种方式而不是另一种方式。

全云网络

全云网络是指企业仅在其场所拥有客户端设备，其余网络全部在云服务上。称之为完全云、云优先、仅云，或其他名称。无论被称为完全基于云、云优先、仅云，或任何其他名称，远离本地后端系统的这种转变是一个新兴的行业趋势。为了明确起见，网络的后端功能是指必须作为服务器运行的一切。这包括数据库、Web 服务器、电子邮件服务器、认证系统服务器，以及任何通常在数据中心而不是在某人办公室内运行的计算机网络功能。这些需求理论上都可以从云服务中运行，而人们的手机、平板电脑和个人电脑（客户端设备）在连接到网络时充当前端设备。如果我必须亲自进入数据中心才能在手机上查看我的电子邮件，我会觉得非常不方便！

研究公司 Gartner 提到了一种云优先策略，企业优先使用云平台。云优先策略并不一定意味着企业拥有全云网络。拥有云优先策略的企业可能拥有许多传统技术，或者在 2000 年代中期云服务普及之前就存在的服务。然而，任何新功能或服务都会部署在云上，并且尽可能将旧服务和应用迁移到云上。

2021 年 11 月，Gartner 表示到 2025 年，85% 的组织将采用云优先原则。它还相信，95% 的新数字工作负载将部署在云原生平台上（www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences）。因此，如果你正在学习渗透测试云网络，你正在进入一个有利可图的行业！

混合云网络

混合云网络部分托管在云端，部分部署在本地。为了构成混合云网络，至少一些实际的后端服务器操作必须在企业的本地，并且与云网络连接。如果一个组织拥有一个本地网络和一个完全未连接的云网络，那么这个组织拥有的是两个独立的网络，而不是一个混合网络。

为什么组织会选择采用混合云网络？原因可能有很多。

他们可能有一个遗留的本地网络，但他们需要集成一些只在 AWS、Azure 或 GCP 上提供的 SaaS 或 PaaS 组件。也许他们需要 GCP 来进行 Looker 商业数据分析，Azure 用于 Azure DevOps 支持微软生态系统的 API，或者 AWS 用于 AWS Lambda 进行无忧的代码执行。三大云平台都拥有独特的服务，它们可能满足特定的业务需求。

其他一些组织认为，维持混合云网络是一种有效的冗余方式。网络运行时间（Uptime）是衡量任何类型网络运行最重要的指标。冗余是减少运营停机时间的有效方法。例如，如果一台服务器出现技术故障，导致无法继续提供服务，另一台相同的服务器可以确保其功能继续运行。企业可能认为拥有一些由自己物理控制的网络基础设施对冗余非常有益。当然，它无法物理控制云服务器；它只能控制其本地的服务器。网络基础设施也是如此。云服务提供商赋予组织对运行在云基础设施上的网络部分很大的控制权，但他们不允许组织的网络管理员走进他们的云数据中心，直接物理操作服务器的开关。组织可能选择维持混合网络的其他原因包括灾难恢复（DR）或合规性要求。可能是灾难恢复程序中的某些细节，或是它需要遵守的某些法规要求其对部分网络拥有物理访问权限。

一些组织可能与供应商签订了服务水平协议（SLA），这些协议是在他们使用云服务之前就已存在的。SLA 是供应商与客户之间的法律协议，明确了客户期望获得的服务、供应商同意提供的服务，以及用来衡量性能的指标。供应商可以是云平台（如 AWS），也可以是其他类型的 IT 服务（如 Slack 或 Cloudflare）。旧的 SLA 有时会使云迁移变得复杂。因此，一些企业可能会等到旧合同到期后再全面迁移到云端。与此同时，他们可能会找到一种折中的方案，在实现云服务的同时，继续维持一段时间的本地基础设施。

如果一个组织拥有混合云，它可能会将更敏感或关键的数据操作保留在本地。敏感数据和系统可能包括公钥基础设施（PKI）、关键数据库以及组织必须保留在本地以符合监管要求的高度敏感的财务或医疗数据。

多云网络

在多云网络中，一个企业的网络中实施了多个云提供商。例如，它可能同时拥有 AWS 和 GCP，或者 AWS 和 Azure 的组合，或者 AWS、Azure 和 GCP 的组合。如果企业还有本地组件，多云网络也可能是混合云网络。无论哪种方式，他们在不同云平台上的网络部分都必须以某种方式连接。否则，他们将拥有多个网络。当你为你的组织进行红队参与时，他们的云策略的原因很重要。这将帮助你了解它如何使用其云网络，从而帮助你了解网络威胁可能如何影响该组织。这些是你在渗透测试中应该模拟的网络威胁。因此，让我们来看看为什么许多组织选择拥有多云网络。

为什么一个组织会拥有多云网络

正如我所提到的，AWS、Azure 和 GCP 每个都有一些彼此独特的服务。一个企业可能会发现，最适合其运营需求的 PaaS 和 SaaS 应用程序组合都在不同的云平台上。一个企业可能在 Azure 上使用 OpenAI 服务进行自动客户服务，在 Amazon GameLift 上托管其在线视频游戏服务器，并在 GCP 上使用支付网关处理客户信用卡交易。

Gartner 的副总裁分析师 Michael Warrilow 说：

“大多数组织采用多云策略是出于避免供应商锁定或利用最佳解决方案的愿望。我们预计，大多数大型组织将继续自愿追求这种方法。”

根据 2019 年 Gartner 进行的一项调查，81%的受访者与两个或更多的提供商合作。那至少是几年前的情况。Gartner 预测，全球公共云服务的最终用户支出将从 2022 年的 4903 亿美元增长到 2023 年的 5918 亿美元。也许多云网络现在是一个更大的市场细分。这一点很重要，因为你可能正在对其中一些服务进行渗透测试。

你还应该了解公共云和私有云之间的区别。

直到目前为止，我提到的所有云都是指公共云。使用 AWS、Azure 和 GCP 通常指的是公共云使用。公共云是一个与其他用户、客户和客户共享物理服务器和其他基础设施的云网络。

许多消费类互联网服务都是由公有云驱动的。听 Spotify、看 YouTube、上传个人文件到 Dropbox、通过 Zoom 开会、在 Steam 上购买游戏以及参与多人游戏——这些都是消费者常用的公有云驱动应用方式。而且他们可能都不知道这一点！企业也经常以类似的方式使用公有云服务——通过 Google Docs 协作处理文档、在 Slack 上交流、以及通过 Microsoft Teams 举行会议。

大多数企业使用的 AWS、Azure 和 GCP 也是公有云。第三方基础设施上的私有云服务（如 AWS、Azure、GCP）通常更为昂贵。如果公司注册了如 AWS CodeArtifact 这样的包管理服务，或是 Azure 上的计算机视觉服务用于图像和视频分析，那些都是公有云服务。任何具有免费试用期的服务很可能都是公有云服务。

私有云服务有两种形式。它们可以部署在公司自有场所。一些企业已经在自己的基础设施上复制了云计算模型。或者，AWS、Azure 和 GCP 也提供一些私有云服务。例如，AWS 提供Amazon 虚拟私有云（Amazon VPC）。

公有云和私有云服务各有其优点和使用场景。

公有云服务通常是企业的优选，因为它们不需要资本支出；企业的会计师可以将其作为运营支出进行预算。从商业角度来看，企业不为产品买单，而是为服务付费。将服务视为运营支出而非资本支出可能会带来税务和法律上的好处。公有云服务通常更具可扩展性，因为不涉及专用的物理或虚拟服务器。只要企业愿意支付服务费用，它们可以根据需要在任何时候高效地使用任意大小的空间。公有云服务对于企业来说还具有较少的管理开销，因为基础设施的维护由第三方负责。

组织可能需要私有云服务的主要原因之一是网络安全。与其他类型的混合云网络中的任何本地组件类似，监管合规性可能要求使用私有云而非公共云。由于企业独占使用私有云，它可以保持更多控制权并实施更严格的安全措施。它可能需要遵守的法规通常适用于敏感的金融或医疗数据。例如，在某些情况下，为了符合健康保险流通与责任法案（HIPAA，美国的医疗数据法规）或萨班斯-奥克斯利法案（美国的金融数据法规），可能需要使用私有云而非公共云。此外，和非云本地网络使用一样，组织可能会选择在自己的基础设施上部署云计算模型以满足灾难恢复（DR）需求。

混合云网络可能包含非云本地组件、云本地组件，或者第三方基础设施上的私有云组件。如果私有云通过 AWS、Azure 或 GCP 部署在第三方基础设施上，它需要通过私有网络连接到企业本地的客户端机器——通常通过某种形式的虚拟专用网络（VPN）。

你所在的组织可能正在进行云迁移过程。组织如何迁移到云端将影响其安全态势！因此，我们需要更好地理解云迁移及其复杂性。

云迁移过程

云迁移是指一个组织将其数据和服务从本地基础设施迁移到云服务提供商的过程。随着过去 15 到 20 年云市场的快速增长，许多企业已经开始进行云迁移过程。但云迁移并不简单，且可能会执行不当或效果不佳。

所有企业都必须进行仔细规划，以便有效地迁移到云端。根据情况和需求，它们可能更倾向于分阶段迁移到云端，分几个月或几年进行，而不是一次性完成迁移。

在规划云迁移策略时，组织应该了解可能在云迁移过程中发生的问题，以便能够避免这些问题。

在云迁移过程中，企业的服务可能会出现停机现象。根据其迁移到云的方式，部分服务器可能需要完全下线一段时间。如果企业的服务中断，尤其是当客户花费大量资金时，可能会非常不满。在云迁移过程中，企业不仅需要考虑自己的客户群体，还要考虑供应链问题。企业可能需要为停机带来的后果做好计划和准备，或者仔细调整云迁移策略，以确保完全没有停机时间。

互操作性可能是一个问题。企业的应用程序运行在自己的基础设施上，可能与其云服务不完全兼容，需要进行一些调整或修改。如果迁移到的云服务是 IaaS，那么互操作性问题的可能性较小。但有些应用程序需要通过 PaaS 或 SaaS 来实现。在设计云迁移策略时，必须仔细考虑互操作性问题。

关键数据可能在云迁移过程中丢失，可能会面临数据泄露或无法访问的风险。特权访问管理和加密是可以在云迁移过程中使用的安全措施，以避免这一问题。同样，全面盘点迁移到云的所有数据、应用程序和工作负载也非常重要。你无法保护看不见的东西！

已习惯于在本地管理数据和工作负载的员工，可能不熟悉一旦迁移到云端，任务细节会发生怎样的变化。企业可能需要根据其云基础设施和实现细节为组织分配新的角色。员工还需要接受有关所有新技术的培训，这些技术是他们在云迁移过程中及迁移后将使用的。

这些就是云迁移过程中可能出现的一些常见问题。通过仔细的准备和规划，这些问题是可以避免的。企业进行云迁移有许多充分的理由。让我们来看看为什么。

云网络为企业提供了运营灵活性。它们使员工更容易在家工作或在旅行时继续工作。新冠疫情引发了持续的影响。来自世界各地多个实体的科学研究表明，由于新冠长期症状，全球有数百万人因早逝和长期残疾离开了劳动力市场。员工发现，在家工作比必须在现场工作更安全、更高效。聪明的雇主希望保持员工的健康和生产力，理解保护员工免受空气传播疾病的好处。通过云迁移促进在家工作是一项有效的策略。

主要的云平台具有安全控制措施，如果使用得当，可以使得远程访问企业网络在抵御网络攻击方面更加安全。云计算的采用和对远程工作的支持是 21 世纪的商业方式，而那些未能理解这一点的公司正在失去关键的人才。

云迁移可以帮助减少资本支出和相关负担。公司无需为提供额外的空间以运行自己的庞大数据中心支付更多的房地产费用。亚马逊、谷歌和微软在全球所有有人口的大陆上都拥有许多世界上最大的 数据中心。从印度到日本，从美国到印度尼西亚，从法国到南非，许多人和雇主的工作地点距离 AWS、GCP 或 Azure 的数据中心都在 1,000 公里以内。但即使一些雇主距离最近的云平台数据中心有 5,000 公里之遥，他们仍然能够享受快速的数据传输和极低的延迟。此外，这三大云提供商每年都会在全球更多地区增加新的数据中心。对于许多公司来说，用云计算的灵活性和敏捷性替代自己的本地数据中心是显而易见的选择。资本支出的减少也显著改善了他们的财务状况。

尽管一些公司希望将部分网络保留在其内部设施中以便于灾难恢复（因为他们可以对某些基础设施进行物理访问），但其他公司则以灾难恢复为理由迁移到云端。这展示了在现实世界中，运营企业网络的许多实际问题是多么复杂和微妙。AWS、Azure 和 GCP 都有灾难恢复工具，并且为公司提供如何有效使用它们的建议。由于其数据中心的庞大容量，云服务使得公司可以更轻松、更经济地维护 PB 级和 EB 级数据的备份。云平台还提供了有用的工具，帮助组织定期测试备份的可行性，同时存储不同类型的快照。如果一个组织将其所有后端完全移至云端，那么当其设施遭遇洪水、火灾或地震时，数据将更加安全。亚马逊、谷歌和微软还在自己的网络中构建了冗余性和弹性。如果他们的某个国际数据中心发生灾难，已有应急系统确保运营继续进行。此外，他们的物理安全措施已经强化，超出了大多数组织在自己设施中能够做到的程度。

那么，接下来我们来看看云迁移过程。由于每个组织的数据资产和业务操作各不相同，因此每个组织的云迁移过程略有不同。但通常都会有一些共同点。

IBM 为每个组织的云迁移检查清单推荐以下步骤：

1. 首先，组织应清点其工作负载。工作负载是指在其网络中运行的任何数据库、应用程序、容器化系统或服务。确定每个工作负载的大小、复杂性，以及它是否处于生产环境中。

2. 仔细研究每个平台及其应用和服务。AWS、Azure 和 GCP 各自提供数百种独特的服务。一个组织可能在不同的平台上需要不同的服务。应为每个工作负载选择最合适的服务，这可能导致需要使用多云网络。

3. 在选择了服务和云提供商后，下一步是进行成本评估。

4. 接下来，应该指定一个团队来执行迁移。团队中应有具备高级计算机网络和网络安全技能的人员。迁移目标应传达给团队。

5. 确定迁移中有多少工作将由内部团队处理，多少由云提供商处理。所有三大云提供商都提供云迁移服务，组织应验证这些服务的内容。

6. 优先确定应该首先迁移哪些工作负载。在迁移过程中，可能会有一段时间需要将工作负载镜像到本地网络，以使迁移过程尽量减少网络停机时间。

7. 应该制定一个计划，安排迁移过程并概述路线图。整个迁移过程可能需要几个月或几年，具体取决于每个公司的需求和实际情况。

8. 确定企业网络中是否已经存在云服务，以及是否应将其替换为其他云服务或扩展为更大的云工作负载。例如，为什么公司在其 Azure 服务已包含 Microsoft Teams 支持或其 GCP 服务已包含 Google Drive 集成的情况下，还要继续使用 Dropbox？

9. 公司相关方应了解云迁移过程中的预期和迁移后的情况。如果迁移对供应链有任何影响，应将整个供应链纳入考虑范围！

10. 应为云迁移过程设定关键绩效指标（KPIs），例如：“50%的数据库流量应发生在我们的 Amazon EC2 实例上。”

11. 应定期与云迁移团队核实和评估进展。最后，在整个过程中的各个阶段——进行测试、复查并根据需要进行调整。

作为一名云渗透测试员，云迁移过程完成后的几个月将是进行渗透测试的绝佳时机。业内的普遍经验是，网络进行重大变更时应进行渗透测试，因为变更可能会带来新的安全漏洞。虽然渗透测试和红队任务不只有在这个时机才需要进行，但这确实是进行渗透测试的一个关键时刻。

了解云中的安全责任将直接影响你作为云渗透测试员的日常工作！你必须了解自己可以做什么、不能做什么以及为什么。我们来看看安全责任和共享责任模型。

云中的安全责任

作为云渗透测试员，理解云中的共享责任模型非常重要。涉及的两个实体是使用云服务的组织和云服务提供商。当你进行红队演练时，组织是你报告的对象，无论你是雇员还是第三方承包商。

总体而言，组织和云服务提供商共同承担安全责任，这通常被称为共享责任模型。然而，云安全控制和责任在这两个实体之间是划分开的。

了解云服务提供商和你所在组织各自的安全责任非常重要。在每次渗透测试或红队演练开始时，你将签署一份合同，合同中将明确渗透测试的范围以及你被允许和不被允许做的事情。你必须严格遵守合同，并仅在指定范围内进行渗透测试。当你对云网络进行渗透测试时，你不仅仅是在模拟攻击你雇主的环境，还在模拟攻击 AWS、Azure 或 GCP 的基础设施。云服务提供商有自己的规则，规定了你能做和不能做的事情。如果你之前做过本地网络的渗透测试，你可能会发现，在云环境中进行渗透测试时，范围和权限要比本地网络更为有限。

你必须确保完全理解每个云服务提供商的渗透测试政策。你应该仔细阅读与你的雇主签署的合同，但你也应自行进行研究，核实每个云平台允许你做什么。你的雇主可能会要求你进行渗透测试，但这种测试可能会违反云服务提供商的政策。在这种情况下，遵守云服务提供商的政策是最重要的。你应该向雇主解释他们要求的渗透测试如何违反云服务提供商的政策。然后，你和你所在的组织可以修改渗透测试计划，使其符合云服务提供商的政策。

在所有三大平台——AWS、Azure 和 GCP——上，平台负责“云的安全”，而你的组织则负责“云中的安全”。

云平台始终对其物理基础设施和设施的安全负责。例如，如果恶意攻击者伪装成云服务提供商的员工进入数据中心，窃取大量数据存储设备，那么云服务提供商将对这一事件完全负责。您的组织如何可能对这次攻击负责呢？毕竟，贵组织的任何人员根本没有物理访问云服务提供商的数据中心。

贵组织始终对贵组织开发和维护的软件的安全负责。对于云服务提供商未提供的任何软件，贵组织也需负责其安全。例如，如果您使用的是一个云服务，AWS、Azure 或 GCP 为您提供了他们自己的虚拟机（VMs），那么这些虚拟机中操作系统的安全责任由云服务提供商承担。但如果贵组织在云服务提供商的基础设施中安装了自己的虚拟机，那么这些虚拟机的安全责任完全由贵组织负责。如果我没有对宿主机的 root 或管理员权限，我不能对虚拟机的更新负责，这应该由云服务提供商来处理。如果云服务提供商提供给我虚拟机并且赋予 root 或管理员权限，那么虚拟机的更新就由我负责。某些云平台专门部署的虚拟机会得到云服务提供商的完全支持进行更新，但这并非总是如此。如果贵组织使用云平台的 API，那么贵组织使用的应用程序是贵组织的责任，但 API 连接到的云平台的软件和服务则是云平台的责任。

通常来说，共享责任模型的划分与贵组织使用的服务类型（IaaS、PaaS 或 SaaS）相关。如果 AWS、Azure 或 GCP 为贵组织提供的是 SaaS，那么云服务提供商承担大部分责任，而作为渗透测试员，您可以执行的操作最为有限。如果 AWS、Azure 或 GCP 为贵组织提供的是 IaaS，那么贵组织承担大部分责任，并且在模拟网络攻击时，您作为渗透测试员能够做的事情要多得多。PaaS 则处于二者之间。

根据 AWS 的共享责任模型，贵组织负责客户数据的安全、贵组织自身的平台、应用程序和身份与访问管理（IAM）系统的安全、贵组织自身操作系统的安全、网络与防火墙配置的安全、客户端数据的安全、加密、数据完整性认证、服务器端加密以及网络流量保护。AWS 则负责其计算、存储、数据库和网络软件，以及所有硬件和全球基础设施的安全。

根据 Azure 的共享责任模型，你的组织始终负责其信息和数据、个人计算机和移动设备以及账户和身份。Azure 始终负责其物理主机、物理网络和物理数据中心。根据你的 Azure 服务是 SaaS、PaaS 还是 IaaS，身份和目录基础设施、应用程序、网络控制和操作系统的责任可能有所不同。

根据 GCP 的共享责任模型，你的组织始终对其内容和访问政策负责。这适用于 SaaS、PaaS 和 IaaS 服务。如果你的 GCP 服务是 PaaS，你的组织还需负责使用、部署和 Web 应用程序的安全。如果你的 GCP 服务是 IaaS，你的组织需要承担 SaaS 和 PaaS 的所有责任，并且还需负责身份、操作、访问和认证、网络安全、来宾操作系统、数据和内容。GCP 始终负责审计日志、自己的网络、存储和加密、加固内核和 IPC、引导过程以及其硬件。

让我们简要总结一下每个云服务提供商的渗透测试政策。相关链接将在第十三章的进一步阅读部分提供，最佳实践与总结中也会有相关信息。请务必直接从其网站验证其政策，以防其政策有所变动。

AWS

只要你遵守 AWS 的政策，AWS 允许进行渗透测试。无论是你还是你工作的组织，都不需要联系 AWS 进行渗透测试。只要你遵守 AWS 的政策，你就可以根据需要进行渗透测试和红队演练。

这些是你可以进行渗透测试的 AWS 服务（前提是你遵守 AWS 的政策）(aws.amazon.com/security/penetration-testing/):

• Amazon EC2 实例、WAF、NAT 网关和弹性负载均衡器

• Amazon RDS

• Amazon CloudFront

• Amazon Aurora

• Amazon API 网关

• AWS AppSync

• AWS Lambda 和 Lambda Edge 函数

• Amazon Lightsail 资源

• Amazon 弹性 Beanstalk 环境

• Amazon 弹性容器服务

• AWS Fargate

• Amazon Elasticsearch

• Amazon FSx

• Amazon Transit Gateway

• S3 托管的应用程序（但 S3 存储桶是严格禁止的）

以下是你和你的组织禁止进行的渗透测试活动：

• 通过 Amazon Route 53 托管区域进行 DNS 区域遍历

• 通过 Route 53 进行 DNS 劫持

• 通过 Route 53 进行 DNS 欺骗

• 拒绝服务攻击(DoS)、分布式拒绝服务攻击(DDoS)、模拟 DoS、模拟 DDoS（这些活动受限于DDoS 模拟 测试政策）

• 端口洪水攻击

• 协议洪水攻击

• 请求洪水攻击（登录请求洪水、API 请求洪水）

如果你作为红队的一部分进行渗透测试，你是在进行对抗性安全模拟。如果你计划在 AWS 内进行对抗性安全模拟，你必须提交一个模拟事件表单，供 AWS 决定是否授予你和你的组织权限。模拟事件表单可以在你的 AWS 控制台中找到，请在那里进行搜索。

网络压力测试是通过发送大量合法流量进行的性能测试，目的是测试在这些条件下你的 AWS 服务的运行效果。Amazon EC2 针对这种情况有一个具体的网络压力测试政策。你可以在第十三章的 进一步阅读 部分找到相关链接，了解 最佳实践 和 总结。

DDoS 攻击是指网络威胁行为者故意和恶意地通过流量压垮目标网络，从而迫使其无法服务。DDoS 攻击模拟可能是你红队演练的一部分。AWS 有专门的 DDoS 攻击模拟政策 (aws.amazon.com/security/ddos-simulation-testing/)。

模拟钓鱼（通过社会工程攻击从人类用户处获取敏感信息）和恶意软件测试也可能是红队演练的一部分。在这种情况下，你必须提交模拟事件表单，供 AWS 决定是否授予你和你的组织权限。

Azure

只要遵守其政策，Microsoft Cloud（包括但不限于 Azure）允许进行渗透测试。只要你遵守 Microsoft Cloud 的政策、进行渗透测试并在需要时进行红队演练，你和你所在的组织不需要联系 Microsoft。Microsoft Cloud 包括 Azure Active Directory（将更名为 Microsoft Entra ID）、Microsoft Intune、Microsoft Azure、Microsoft Dynamics 365、Microsoft Power Platform、Microsoft Account、Office 365 和 Azure DevOps。

Microsoft Cloud 禁止 在渗透测试和红队演练中进行以下活动：

• 扫描或测试属于任何其他 Microsoft Cloud 客户的资产。

• 获取任何非完全属于你所在组织的数据。

• 所有的拒绝服务（DoS）测试（包括分布式拒绝服务攻击模拟）。

• 对任何资产进行网络密集型模糊测试，除了你所在组织的 Azure 虚拟机。

• 自动化测试会产生大量流量的服务。（“大量流量”在 Microsoft Cloud 的 参与规则 中并没有明确规定。请根据你的判断进行处理。）

• 故意访问其他客户的数据。客户是指使用 Microsoft Cloud 服务的其他组织。

• 超出概念验证（PoC）复制步骤的基础设施执行问题。

• 以任何方式违反其政策。

• 对 Microsoft 员工进行钓鱼或其他社会工程攻击。

Microsoft Cloud 鼓励以下活动：

• 创建少量的测试账户或试用租户，以演示跨账户或跨租户的数据访问。但不要访问属于微软云其他客户的账户。

• 对贵组织自己的 Azure 虚拟机进行模糊测试、端口扫描，并使用漏洞评估工具。

• 通过生成预计在正常业务过程中看到的流量，包括高峰容量，来对贵组织的应用程序进行负载测试。

• 测试安全监控和检测（例如来自异常安全日志的检测）。

• 尝试突破共享服务容器（即 Azure 网站或 Azure Functions）。但是如果成功了，您必须立即向微软报告，并且不要进一步深入。绝不要访问其他微软云客户的数据。

• 在 Microsoft Intune 中应用条件访问或移动应用管理（MAM）策略，以相应地测试限制的执行。

GCP

GCP 允许渗透测试，只要您遵守其政策。无论您还是您所在的组织，都无需联系 GCP 进行渗透测试。只要遵循 GCP 的政策，您可以根据需要进行渗透测试和红队演练。您必须参考的政策是Google Cloud Platform 可接受使用政策和Google Cloud Platform 服务条款。您可以在第十三章的进一步阅读部分找到这些链接，最佳实践和总结。

根据可接受使用政策，您和您的组织禁止做以下事情：

• 分发任何类型的恶意软件、损坏文件、恶作剧或其他具有破坏性或欺骗性质的项目。

• 获取未经授权的访问、破坏或损害任何 Google 服务或用于提供这些服务的设备，以及任何 GCP 的其他客户或经销商。

• 禁用、干扰或规避 Google 软件、服务或 Google 设备的任何方面。

每个云提供商提供广泛的产品和服务。无论某项服务是 IaaS、PaaS 还是 SaaS，这些分类都会影响贵组织如何使用它们，以及作为渗透测试人员可以做或不能做的事情。让我们来探讨不同类型的云服务。

IaaS、PaaS 和 SaaS 之间的区别

AWS、Azure 和 GCP 提供的所有服务都是 SaaS、PaaS 或 IaaS。这些云服务的分类将直接影响您在进行渗透测试时可以做什么，正如我之前所解释的。因此，了解这些服务类型之间的区别至关重要！

SaaS 意味着云提供商为您的组织提供大量组件——一切运行所需的基础设施、其软件平台及相关 API，以及其软件的应用级功能。例如，当我们使用 Gmail 时，我们正在使用一个完全的 SaaS 应用程序。AWS 将 SaaS 定义为：

“SaaS 是一种业务和软件交付模式，允许组织以低摩擦、以服务为中心的方式提供其解决方案。”

您的组织将数据存入服务中，但并没有进行太多或任何软件应用开发。贵组织对 SaaS 的安全关注主要是如何配置服务以及将哪些数据放入该服务。作为渗透测试员，您的操作会受到限制。但是，通常情况下，模拟不渗透到云服务商自身平台的网络攻击是可以的，同时测试不同的 SaaS 配置也是允许的。

PaaS 本质上为您的组织提供了云服务商的基础设施和平台。您可以将云服务商的平台视为类似操作系统的东西，但并不完全相同。这是 AWS 对 PaaS 的定义：

“PaaS 消除了组织管理基础设施（通常是硬件和操作系统）的需求，并使您可以专注于应用程序的部署和管理。这有助于提高效率，因为您不需要担心资源采购、容量规划、软件维护、打补丁或任何其他运行应用程序时所涉及的重复性繁重工作。”

IaaS 为您的组织提供云服务商的基础设施，其中包括服务器、网络设备和物理网络。贵组织使用的大多数软件和数据归贵组织所有。正如 AWS 所解释的那样：

“IaaS，有时缩写为 IaaS，包含云 IT 的基本构建模块，通常提供网络功能、计算机（虚拟或专用硬件）和数据存储空间的访问。”

作为渗透测试员，您将在每个云服务商的 IaaS 服务中，获得更多模拟网络攻击的权限。

所以，您现在已经理解了混合云、多云、全云、IaaS、PaaS、SaaS、云迁移以及组织如何使用您将进行渗透测试的各种云网络。

总结

通过本章，您现在理解了测试目标的基本性质——云网络。在本书的后续章节中，我将解释作为红队员在 AWS、Azure 和 GCP 中特定的更多信息。但在下一章中，我们将探讨云网络通常是如何遭受网络攻击的。在一次云渗透测试中，云是“什么”，而您模拟的网络攻击则是“如何”。

进一步阅读

要了解本章所涉及的更多内容，您可以访问以下链接：

• 什么是红队 ？: www.synopsys.com/glossary/what-is-red-teaming.html

)

• 关于 AWS: aws.amazon.com/about-aws/

)

• Google Cloud 平台的历史：acloudguru.com/blog/engineering/history-google-cloud-platform

)

• 微软 Azure 的历史：techcommunity.microsoft.com/t5/educator-developer-blog/the-history-of-microsoft-azure/ba-p/3574204

)

• 云计算的好处是什么？（IBM）：www.ibm.com/topics/cloud-computing-benefits

)

• 什么是云网络？：www.cisco.com/c/en/us/solutions/cloud/what-is-cloud-networking.html

)

• 容器的简史：d2iq.com/blog/brief-history-containers

)

• 什么是 DevSecOps？来自 PortSwigger 的指南：portswigger.net/solutions/devsecops/guide-to-devsecops

)

• 多云与混合云：10 个关键 对比：www.spiceworks.com/tech/cloud/articles/multi-cloud-vs-hybrid-cloud/

)

• Gartner 表示云将成为新数字体验的核心：www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences

)

• 什么是云迁移？（IBM）：www.ibm.com/topics/cloud-migration

第二章：云网络是如何遭受网络攻击的？

当你开始成为一名云渗透测试员时，从基础知识开始是非常有帮助的。

你的工作是测试云网络，了解它们如何被网络攻击。你所工作的组织可以利用你的发现来提高其云网络的网络安全性。

因为亚马逊（AWS）、微软（Azure）和谷歌（GCP）拥有你将测试的基础设施，你将不被允许做任何网络攻击者在现实生活中可能尝试做的事情。但你需要了解云网络所面临的所有网络攻击类型，即使你无法模拟所有的攻击。

最好的渗透测试员能够像真实的网络攻击者一样思考。本章将帮助你更好地理解云网络如何遭受网络攻击，以帮助你进行更有效的渗透测试。

在本章中，我们将涵盖以下主要内容：

• 理解渗透测试

• 外部和内部攻击

• 对数据的机密性、完整性和可用性的攻击

• 理解云中的横向移动

• 零信任网络

让我们开始吧！

理解渗透测试

渗透测试（或简称pentest）是模拟的网络攻击，旨在发现计算机网络和应用程序中的漏洞。渗透测试与实际网络攻击的最大区别在于，前者是经过计算机或网络所有者完全同意的，而后者则不是。

作为渗透测试员或红队成员，你不仅需要获得目标所有者的同意，还必须签署一份法律协议，详细说明你被允许做什么、禁止做什么以及渗透测试的范围。这适用于你是被渗透测试组织的员工、该组织的第三方承包商、进行简单一次性渗透测试的人，还是作为红队成员进行渗透测试的情况。

无论组织是否设有红队，它都将在漏洞评估的历史之后开始进行渗透测试。漏洞评估是发现安全漏洞的第一步方法。它根据一组检查标准分析应用程序或网络的状态。这些标准通常基于一组安全标准，如OWASP 应用安全验证标准 (owasp.org/www-project-application-security-verification-standard/) 或 PCI PTS POI 模块化安全要求 (www.pcisecuritystandards.org/wp-content/uploads/2023/01/PTS_POI_v6.2_Bulletin.pdf)。有数百种不同的安全标准适用于您所在的组织。漏洞评估适用于所有企业和企业，无论其安全成熟度水平如何。安全成熟度是一个复杂的概念，但简言之，它关乎组织安全政策和控制的发展程度。

一旦组织进行了一些漏洞评估，根据这些发现加固了其网络，并组建了一个网络安全专业团队，那么它可能已经准备好进行渗透测试了。渗透测试旨在发现只能通过模拟网络攻击才能发现的安全漏洞。从法律和程序上讲，渗透测试与网络攻击大不相同，但您进行渗透测试的计算机和网络并不知道这种区别。您的渗透测试会破坏事物，即使其影响只是暂时性地使几台计算机在拒绝服务（DoS）攻击中下线一个小时。这就是为什么只有具备一定安全成熟度的组织才应进行渗透测试的原因，也是为什么在开始渗透测试之前总是需要明确的范围。例如，您的组织可能会将其生产从一个网络段移至另一个网络段，以便您可以在一个网络段内进行渗透测试而不干扰其日常运营。

红队是您组织内的一组专门人员，根据网络安全威胁景观中的模式进行频繁的渗透测试。例如，如果出现新的企业勒索软件威胁，您的红队可能被指定在您的网络内模拟该特定的新勒索软件，并观察其影响。

为了有效地进行渗透测试，你必须完全理解云网络是如何遭受网络攻击的。在本书中，你将学习到许多常用于在 AWS、Azure 和 GCP 环境中进行渗透测试的工具。正确地在合适的场景下使用这些工具，将帮助你有效进行渗透测试，找到你的组织必须解决的漏洞。但是，世界上最好的工具只有在你知道如何使用它们以及为什么使用它们时才有效。有时你也会在没有这些工具的情况下进行一些活动。在所有的场景中，作为一个有效的云渗透测试员，你必须理解云网络是如何遭受网络攻击的。这就是本章的全部内容！

外部和内部攻击

当你所在组织的防御安全团队准备应对网络攻击时，他们需要了解威胁行为者在试图恶意干扰你们数据时所采取的每一步。没有任何一次网络入侵是一步完成的。勒索软件可能需要一名员工不小心执行了一个电子邮件附件，才在配置不当的云实例之间传播开来。数据泄露可能需要贿赂一名员工，并交给他们一个含有定制间谍软件的 USB 闪存驱动器。

MITRE ATT&CK 数据库 (attack.mitre.org/) 是一个极好的资源，可以帮助各种网络安全专业人士了解网络威胁行为者在实施犯罪时所采取的各种步骤。我将在本章中频繁引用它。特别是如果你作为红队的一部分进行渗透测试，这些可能就是你在演练中模拟的网络攻击类型。

一些网络攻击链可能很简单，而另一些则相对复杂。但它们都有一个起点，可能是外部的，也可能是内部的，你作为云渗透测试员需要理解外部和内部网络攻击之间的区别。你很可能会在职业生涯中渗透测试这两种类型的场景。商业和企业云网络是许多最具破坏性的网络攻击的主要目标。

曾经有一段时间，也许是在 1990 年代和 2000 年代初，消费者经常成为网络犯罪分子的目标。普通人仍然应该小心他们手机、平板和 PC 的安全。它们有时会成为钓鱼诈骗、数字监控和恶意软件的目标。一个普通人可能在勒索软件攻击中被迫支付几百美元的加密货币给网络攻击者。即使是小型企业，年收入达到数百万美元，也可能被迫支付百万美元的加密货币赎金给网络攻击者。此外，其他类型的财务动机网络犯罪，如数据泄露，当目标是企业时，比针对一位老年人的网络攻击更具盈利性。

作为渗透测试员，你将为公司工作，无论是作为员工还是第三方承包商，这些公司都是网络犯罪的丰厚目标。这也是他们雇用你来模拟这些网络犯罪的原因，目的是为了了解如何提升防御能力。

你在新闻或最喜欢的虚构娱乐作品中常常听到的经典网络攻击，通常来源于外部。例如，一名戴着帽衫的网络犯罪分子在黑暗地下室的 PC 上破解了网络中的加密终端，然后下载了所有敏感文件！屏幕上闪现一个骷髅和交叉骨的图标……“你被黑了！”受害组织从未见过攻击者。它雇用了顶尖的网络调查团队，追踪攻击者的行踪，最终警方在另一个大陆的咖啡馆里识别出了这名网络犯罪分子。罪犯被戴上手铐，所有人鼓掌，字幕滚动。

现实世界中的网络犯罪同样具有破坏性，但它在实际发生时看起来可能更为温和。调查它并不像电影中那样快速和刺激，因为你将帮助你工作的公司为现实中的网络攻击做好准备，而这通常不符合典型的电影剧本。现在，让我们了解这些攻击的性质，并看看一些真实的例子。

外部网络攻击

外部网络攻击起源于目标组织之外。攻击者通常需要通过互联网开始对组织云服务器的网络攻击。

外部网络攻击者必须突破其攻击的组织网络。然后，他们很可能需要提升权限。

权限提升

这指的是攻击者从一个具有有限访问控制权限的用户账户开始，逐步提升权限，最终可能会获取到网络中完全具有管理权限的账户……这尤其危险！

现在，让我们来看看一些可能的外部网络攻击向量，特别是在云网络中的情况。

路过式妥协

首先是“路过式妥协”。根据 MITRE ATT&CK（attack.mitre.org/techniques/T1189/），路过式妥协发生在用户通过常规的网页浏览活动访问某个网站时。攻击者控制该网站，通过用户的网页浏览器发起攻击。有时，攻击者还会使用这种技术进行非漏洞利用的恶意行为，例如获取应用程序访问令牌。

很多对云网络的访问都是通过网页进行的，因此这是一个非常相关的攻击向量。

利用面向公众的应用程序

另一个与云网络密切相关的外部攻击向量是“利用面向公众的应用程序”。MITRE ATT&CK (attack.mitre.org/techniques/T1190/) 将其描述为攻击者通过利用互联网连接的计算机或应用程序的漏洞来进行攻击。常见的利用手段包括 SQL 数据库、标准互联网服务如 SSH 或 SMB、网络管理协议，以及具有互联网访问权限的开放插座（如 web 浏览器）。但其他连接互联网的技术也可能被用来进行这些攻击。

如果这些漏洞涉及到云基础设施或容器化应用程序（例如 Kubernetes 或 Docker），攻击者可能造成极其灾难性的破坏。他们可以拦截其他实例或容器，并且通常还能够获得它们的 API 访问权限。

外部远程服务

我将要讲解的下一个 MITRE ATT&CK 入口向量是“外部远程服务”。这是一种常见的外部网络攻击的起始方式。MITRE ATT&CK (attack.mitre.org/techniques/T1133/) 将其描述为攻击者针对外部服务进行攻击，以获取恶意访问权限或在网络中保持持久性。常见的目标远程服务包括 VPN、Citrix 或类似的远程访问技术。攻击者通常需要访问有效账户，才能使此类攻击发挥作用。通过已经被攻破的网络或像凭证农场（credential pharming）这样的方式，攻击者可以窃取凭证来获得有效账户的访问权限。当然，在外部网络攻击中，攻击者也可以通过钓鱼攻击员工来获取有效账户。钓鱼攻击有多种形式，但最常见的是使用假网站、假邮件、假短信或假社交媒体帖子来模仿可信的实体。

有效账户

这个下一个 MITRE ATT&CK 向量类别是大多数内部网络攻击的常见入口点，被称为“有效账户”。根据 MITRE ATT&CK (attack.mitre.org/techniques/T1078/)，攻击者可以通过攻破具有权限的合法用户账户，获取对计算机系统的恶意访问。他们也可能攻破特权账户，以建立持久性、进行权限升级或规避防御。有时，不活跃的用户账户也会被利用。网络管理员应当监控系统中账户的行为，并尽快停用前员工和合同工的账户。

云账户

我将在这里提到一个攻击向量的子类别，因为它与云渗透测试特别相关；它被称为“有效账户：云账户”（attack.mitre.org/techniques/T1078/004/）。请前往 MITRE ATT&CK 网站了解详细信息。云网络包含大量运作中的组件，可能有多个 SaaS 应用、容器、服务器内的服务器、虚拟机等等。它们可能非常复杂，因此攻击者可以利用更多的用户账户和机器身份进行攻击。

组织不仅要关注拥有活跃账户的内部网络攻击者，还需要关注不活跃账户，这也是一个常见的攻击向量。作为云渗透测试员时，你可能需要攻破一个组织忘记移除的不活跃账户。

内部网络攻击

内部网络攻击源自目标组织内部。攻击者可能是公司的员工、承包商、高层或供应链实体，或者外部网络攻击者通过贿赂或其他方式促使员工、承包商、高层或供应链实体帮助他们进行网络攻击。

内部网络攻击者已经进入了你的网络。如果他们是组织的员工，他们在你的网络和应用程序中至少拥有某些权限账户，即使这些权限很小。很可能他们还具有对公司计算机和本地网络的物理访问权限，这样可以更容易地对云网络发起攻击。供应链实体也已拥有对组织的特权访问，这是外部人员无法拥有的。你组织的供应链由向你组织提供产品和服务的其他公司组成，例如，向汽车制造商出售金属的公司。金属制造商是汽车制造商供应链的一部分。为学校定制开发网站应用程序的网络开发公司是学校供应链的一部分。

以下是 MITRE ATT&CK 的“初始访问”向量，这些向量可能与内部网络攻击相关。

硬件添加

第一个是“硬件添加”。MITRE ATT&CK（attack.mitre.org/techniques/T1200/）将其定义为敌对方使用计算机硬件（如网络设备）作为获取恶意访问的向量。这种技术通常使用“更强大的硬件设备”而非可移动媒体（如 USB 驱动器）来部署新的攻击功能和特性，而不仅仅是分发恶意有效载荷。

你组织的云网络可能会受到由网络犯罪分子物理连接到本地网络的硬件设备攻击。

供应链妥协

另一种可以在内部网络攻击中使用的技术是“供应链妥协”。MITRE ATT&CK (attack.mitre.org/techniques/T1195/) 将其描述为攻击者操控或拦截产品或产品交付机制，以便妥协连接的用户和网络，进而导致数据或系统的妥协。公司的供应链可能包括他们合作的其他企业、提供应用程序和网络服务的公司等。在这些攻击中，有时源代码库、开发工具、开源依赖项或软件更新机制会被操控。

对于本书的目的，供应链妥协尤为相关，因为 AWS、Azure 和 GCP 服务与应用程序可以被视为公司供应链的一部分。

供应链实体通常与组织的内部网络有连接，无论是在本地还是在云中。作为云渗透测试人员，你有时可能会模拟供应链攻击。有时，你也可能需要在进行渗透测试时与组织的供应链实体之一进行合作。

受信关系

下一个攻击向量适用于许多内部网络攻击，被称为“受信关系” (attack.mitre.org/techniques/T1199/)。MITRE ATT&CK 定义为攻击者利用目标信任的个人或组织来进行网络攻击。这些人或实体可以包括托管服务提供商、IT 合同工或建筑维护工人等。

这是一个假设的场景。清洁工要求获取服务器机房的钥匙，因为他们需要在那里清理东西。不是其他人冒充清洁工，而是真正的清洁工，他已经在这里工作了几个月。一旦清洁工进入服务器机房，他们会将一个含有可执行恶意软件的 USB 驱动器插入到公司内部的一台主服务器上，从而感染所有通过该服务器管理的客户端计算机。

网络攻击者会寻找多种方式来利用云网络和应用程序。为了获取访问权限，他们可能会发现应用程序面向互联网的部分的漏洞，如 web 应用程序和开放端口。他们可能会劫持具有访问权限的账户，甚至可能会行贿公司内部人员，让他们将恶意设备物理地放置在目标网络中。作为渗透测试人员，你主要是模拟应用程序和网络中的漏洞远程进行攻击。但在进行红队演练时，即使这些手段难以模拟，仍然要牢记网络攻击者常用的其他技术。

对云数据的机密性、完整性和可用性的攻击

所以，我们已经看过了内部网络攻击和外部网络攻击之间的区别，以及它们可能使用的一些不同的入侵点攻击路径。作为渗透测试员，您还可以通过另一种方式来分类您将模拟的网络攻击。

我们必须看一下CIA（保密性、完整性和可用性）三要素在网络安全中的重要性。这是我们研究领域中最重要的概念之一。

所有的网络攻击都会影响 CIA 三要素中的一个、两个或全部三个组成部分：

• 保密性关乎确保只有被授权的实体能够读取您组织的数据。数据泄露就是影响保密性的一种网络攻击的例子。

• 完整性关乎确保只有授权的实体能够修改或更改您组织的数据。如果一个网络攻击者将您组织的云应用程序中的合法组件替换为恶意软件，那就是影响完整性的网络攻击的一个例子。

• 可用性关乎确保当授权实体需要时，您组织的数据、服务器和应用程序随时可用。如果一个网络攻击者对您组织的云端网页服务器发起分布式拒绝服务（DDoS）攻击，导致客户无法使用您的网页应用程序，这就是影响可用性的网络攻击的一个例子。

一些网络攻击会影响 CIA 三要素中的多个组成部分。例如，现如今的企业勒索软件不仅恶意加密您组织的数据，且没有支付赎金无法获取解密密钥，还经常泄露您组织的数据。所以，在一次恶意软件攻击中，既损害了可用性，也损害了保密性。如果勒索软件通过更改云服务器上的一些数据来建立持久性，那也会损害完整性！

保密性

让我们来看一个新闻中的网络攻击例子，它影响了云网络中数据的保密性。

DC Health Link 在 2023 年 3 月发推表示，其系统的敏感数据遭到数据泄露。DC Health Link 帮助许多为美国政府工作的人员提供健康保险。它的网络至少有一个大型组件是由云服务提供商托管的。该推文(twitter.com/DCHealthLink/status/1634342617235312640)写道：

“DC 健康福利交换管理局非常重视参保人信息的数据泄露事件。2023 年 3 月 6 日星期一，一旦发现此事件，我们立即展开调查，开始与执法部门合作，并聘请第三方取证公司 Mandiant。尽管我们的调查仍在进行中，但我们想就目前情况提供更新。共有 56,415 名客户受到影响。数据字段包括以下内容，尽管并非每个参保人都一定包含所有数据字段：姓名、社会安全号码、出生日期、性别、健康计划信息（例如计划名称、承保人名称、保费金额、雇主捐款和覆盖日期）、雇主信息、参保人信息（例如地址、电子邮件、电话号码、种族、种族和公民身份状态）。”

仅仅因为数据泄露是在 2023 年 3 月报告的，并不意味着它发生在 2023 年 3 月！数据泄露经常数月未被报告。要么组织早在之前就知道了泄露事件，只是在数月后才公布信息，要么组织花了数月时间才首次发现它。

我们知道有 56,415 名客户受到影响，可以合理假设网络中的大部分数据都在云上。我们不知道数据泄露是如何发生的，但我们可以做出合理猜测。“来自云存储的数据”是 MITRE ATT&CK 数据库中的一个公认的攻击向量（attack.mitre.org/techniques/T1530/）。它说：

“许多云服务提供商提供在线数据对象存储解决方案，例如 Amazon S3、Azure Storage 和 Google Cloud Storage。这些解决方案与其他存储解决方案（例如 SQL 或 Elasticsearch）不同之处在于没有统一的应用程序。可以直接使用云提供商的 API 检索这些解决方案中的数据。在其他情况下，诸如 Slack、Confluence 和 Salesforce 等 SaaS 应用程序提供商也提供云存储解决方案作为其平台的外围用例。这些云对象可以直接从其关联应用程序中提取。攻击者可能从这些云存储解决方案中收集敏感数据。提供商通常提供安全指南以帮助最终用户配置系统，尽管配置错误是一个常见问题。已经发生过许多云存储未经适当保护的事件，通常是通过无意中允许未经身份验证的用户公开访问、所有用户过度广泛访问，甚至是在没有基本用户权限的情况下允许任何匿名人员访问，而这些人员不受身份访问管理系统控制。”

本书后面，我将向您展示如何使用工具和技术进行涉及未经授权访问云存储的渗透测试。

完整性

让我们来看看针对云数据完整性的网络攻击。以下是Ravie Lakshmanan在The Hacker News上报道的一个故事（thehackernews.com/2023/03/large-scale-cyber-attack-hijacks-east.html），内容涉及针对成人娱乐网站的攻击：

“自 2022 年 9 月初以来，一场大规模的恶意网络行动劫持了数千个面向东亚观众的网站，将访问者重定向到成人内容。这场持续的攻击活动涉及将恶意 JavaScript 代码注入到被黑的网站中，通常通过合法的 FTP 凭据连接到目标网页服务器，而这些凭据是攻击者通过未知方式先前获得的。‘在许多情况下，这些是高度安全的自动生成的 FTP 凭据，攻击者不知怎的获取并利用它们进行网站劫持，’Wiz 在本月发布的一份报告中表示。云安全公司指出，尽管被攻陷的网站——包括小型公司和跨国公司所有的网站——使用了不同的技术栈和托管服务提供商，但很难追踪到一个共同的攻击途径。”

作为云渗透测试员，你可能需要进行一项渗透测试，涉及向在多云环境中运行的 Web 应用程序注入恶意代码。这是非常狡猾的攻击者可能会成功的攻击方式，并且需要非常熟练的云渗透测试员才能模拟。

完整性攻击可能包括恶意代码注入、中间人攻击或恶意获取用户和机器身份，如传输层安全性（TLS）证书。

TLS

TLS 证书用于授予用户和机器访问使用 TLS 加密的服务的权限，例如通过 HTTPS 协议部署的加密 Web 应用程序。

可用性

最后，还有针对云数据可用性的攻击。

2022 年 8 月，Google Cloud 官方博客报道了他们检测到的有史以来最大的一次 DDoS 攻击，目标是他们的一个 GCP 服务。

这位企业客户使用的是Google Cloud Armor。Google Cloud Armor 是一项网络安全服务，GCP 客户（如企业）可以使用它来保护托管在 GCP 上的应用程序和网络免受一些常见的安全漏洞攻击。Google Cloud Armor 旨在检测和防止的一些常见攻击包括 DDoS 攻击、跨站脚本（XSS）攻击和 SQL 注入攻击。

本书稍后会介绍 XSS 和 SQL 注入攻击，但这里我们先讨论 DDoS 攻击。

什么是 DDoS 攻击？

DDoS 攻击是指网络攻击者利用分布式计算机集合向网络目标发送超出其承载能力的数据，造成目标无法处理。通过向目标发送大量数据，攻击者可能使其崩溃或暂时下线。Web 服务器和云实例是 DDoS 攻击中最常见的目标之一。

大多数 DDoS 攻击都是通过僵尸网络进行的。僵尸网络是由网络攻击者通过指挥与控制服务器控制的计算机网络，用于执行网络攻击。计算机感染了僵尸恶意软件，使其可被攻击者控制，并成为僵尸网络的一部分。个人计算机、移动设备、服务器和网络设备（如路由器）通常会被僵尸恶意软件感染，并用于组成僵尸网络。一个普通人的手机也可能成为僵尸网络的一部分，而他们自己却毫不知情！

当攻击者能够利用他们的僵尸网络中大量设备的一点计算能力时，他们可以执行更具破坏性的网络攻击。在一个由僵尸网络驱动的 DDoS 攻击中，成千上万的设备可以被同步，向一个网络攻击目标发起大量数据包，压垮目标。

这次 DDoS 攻击并没有直接针对 Google Cloud Armor。相反，Google Cloud Armor 能够检测到这次 DDoS 攻击。该事件在官方的 Google Cloud 博客中有报道 (cloud.google.com/blog/products/identity-security/how-google-cloud-blocked-largest-layer-7-ddos-attack-at-46-million-rps)，如下所示：

“2022 年 6 月 1 日，一位 Google Cloud Armor 的客户遭遇了一系列 HTTPS DDoS 攻击，峰值达到了每秒 4600 万个请求。这是迄今为止报告的最大 Layer 7 DDoS 攻击——比之前报告的记录大至少 76%。为了更好地理解攻击的规模，可以想象这相当于在 10 秒钟内接收到 Wikipedia（全球排名前十的流量网站）所有的日请求量。”

Cloud Armor 自适应保护能够在攻击生命周期的早期检测并分析流量。Cloud Armor 向客户发出了推荐的防护规则提示，并在攻击扩大到全规模之前部署了该规则。Cloud Armor 阻止了这次攻击，确保了客户的服务保持在线，并继续为终端用户提供服务。

很高兴看到 Google Cloud Armor 能够缓解如此大规模的 DDoS 攻击，保护了客户的 GCP 托管服务器。作为一名云渗透测试员，你可能会面临绕过 Google Cloud Armor 的挑战！

所有的网络攻击都会影响 CIA 三原则中的至少一个部分——机密性、完整性或可用性。机密性是指保护数据不被未授权访问。完整性是确保只有授权用户和实体才能更改数据。而可用性则是确保授权用户在需要时能够访问数据。有些攻击可能会影响 CIA 三原则中的多个部分，例如勒索软件（影响可用性）同时也可能侵犯公众数据（影响机密性）。

理解云中的横向移动

针对云应用程序的网络攻击可以是外部的，也可以是内部的。它们可能会影响数据的机密性、完整性和可用性。以下是一些需要了解的云网络攻击概念。

针对复杂企业系统（如云网络）的网络攻击很少是简单的。攻击不仅仅是突破、进入和离开。许多攻击会首先攻击复杂系统的一个部分，然后转向系统的其他部分。

一个云网络可以包含多个云平台（如 AWS、Azure 和 GCP），每个平台上都有多个不同的服务和应用程序。它们还可能通过像 Docker 和 Kubernetes 这样的编排平台包含多个容器化系统，在每个容器中集成众多服务和应用程序。云网络的所有组件可以通过共享凭据（如加密密钥和机器身份，诸如 TLS 证书）相互通信。

作为一名云渗透测试员，你可能会被要求模拟这些更复杂的横向利用技术。

MITRE ATT&CK 为横向移动利用定义了一个完整的类别。它主要是关于攻击者如何在计算机系统内部移动。攻击者可能在同一云平台的不同实体之间移动，也可能在不同的云平台之间移动，甚至如果你的组织拥有多云网络，攻击者可能会从一个云平台上的服务移动到另一个云平台。

这是 MITRE ATT&CK 的横向移动利用列表。

远程服务的利用

由于云网络通常包含多个地理位置的实体，这可能成为常见的云网络攻击技术。对于网络而言，“内部”和“外部”是指访问控制，而不是指物理位置本身。如果一个混合多云网络有一个本地位置，并且在世界不同地方的 AWS、Azure 和 GCP 数据中心拥有组件，只要配置了访问控制，禁止公众访问，它们都属于内部网络的一部分。

MITRE ATT&CK 将远程服务的利用定义为：attack.mitre.org/tactics/TA0008/：

“对手可能会利用远程服务，在进入网络后获得对内部系统的未经授权的访问权限。软件漏洞的利用发生在对手利用程序、服务、操作系统软件或内核本身中的编程错误来执行对手控制的代码时。”

内部鱼叉式钓鱼

在钓鱼攻击中，对手通过复制其网站、电子邮件、短信或社交媒体通信，伪装成可信任的实体。钓鱼攻击可以是随机的。例如，我曾收到过一个攻击者伪装成一家我没有账户的加拿大大银行的钓鱼短信。攻击者只知道我在加拿大，而加拿大只有少数几家大银行，每家银行的客户超过五百万。我的信息并没有被特别针对；攻击者向大量加拿大人发送钓鱼短信，希望有些拥有该银行账户的人会上当。

鱼叉式钓鱼与此不同。鱼叉式钓鱼攻击针对特定的个人或实体。例如，可能会有一个特定的个人，攻击者试图突破该人的公司防线。他们可以在 LinkedIn 上查找该人的信息，然后伪装成该人 LinkedIn 上的一个联系人。

MITRE ATT&CK 将内部鱼叉式钓鱼攻击 (attack.mitre.org/tactics/TA0008/) 定义如下：

“对手可能会利用内部鱼叉式钓鱼攻击，在已经获得该环境中的账户或系统访问权限后，获取更多信息或攻击同一组织中的其他用户。内部鱼叉式钓鱼是一种多阶段的攻击活动，其中电子邮件账户通过控制用户设备（先前安装的恶意软件）或通过破解用户账户凭证来被掌控。对手尝试利用受信任的内部账户，提高欺骗目标的可能性，以使其上当。”

横向工具传输

在云网络中，多个应用程序和服务可以互相连接。这些应用程序本身拥有相互之间的特权访问权限。攻击者可以利用这些连接和特权，在网络内进行横向移动。

MITRE ATT&CK 将横向工具传输 (attack.mitre.org/techniques/T1570/) 定义如下：

“对手可能会在被攻陷的环境中，在系统之间传输工具或其他文件。一旦将文件引入受害环境（即入口工具传输），这些文件就可以从一个系统复制到另一个系统，用于在操作过程中准备对手的工具或其他文件。对手可能会在受害者的内部系统之间复制文件，利用内建的文件共享协议（例如通过 SMB/Windows 管理共享到连接的网络共享，或通过远程桌面协议的身份验证连接）来支持横向移动。”

远程服务会话劫持

云网络和应用充满了旨在远程访问的服务。远程服务会话劫持可以帮助攻击者在容器化编排中的不同节点之间、在同一云服务中的不同会话之间、以及在共享凭证的不同云服务之间移动——即使它们使用的是不同的云平台！例如，可以劫持 GCP 中的 App Engine、Azure 中的 App Service 和 AWS 中的 Amazon EC2 之间的远程会话。当然，通过适当的安全配置，应用程序和平台之间可以防止这种漏洞。

MITRE ATT&CK 将远程服务会话劫持定义为如下：attack.mitre.org/tactics/TA0008/

“对手可能会接管与远程服务的现有会话，以在环境中横向移动。用户可能使用有效的凭证登录到专门设计用于接受远程连接的服务，如 telnet、SSH 和 RDP。”

软件部署工具

这类似于远程服务会话劫持，但目标不是远程会话，而是受信任的第三方管理工具。作为云渗透测试人员，你可能需要模拟很多不同类型的劫持技术。

MITRE ATT&CK 将软件部署工具定义为如下：attack.mitre.org/techniques/T1195/001/

“对手可能会访问并使用企业网络中安装的第三方软件套件，如管理、监控和部署系统，横向移动通过网络。”

污染的共享内容

想想云应用中使用的共享存储量有多大！在保护云网络时，必须仔细监控和保护每一项数据资产。

MITRE ATT&CK 将污染的共享内容定义为如下：attack.mitre.org/tactics/TA0008/

“对手可能通过向共享存储位置（如网络驱动器或内部代码库）添加内容，将有效负载传递给远程系统。存储在网络驱动器或其他共享位置的内容可能会因添加恶意程序、脚本或利用代码到本应有效的文件中而被污染。”

云应用和网络比传统应用和网络更为复杂。你的组织在一个云平台上，或者多个云平台上。每个云平台可能会实施多个不同的服务。可能还会有一个本地网络组件。一个容器化的应用可能有许多虚拟化的容器，每个容器可能在几天内生死循环。可能有成百上千个用户账户，更多的是机器身份。攻击者有很多不同的攻击向量。你可能需要在红队任务中模拟对这些复杂向量的攻击。

零信任网络

在云服务普及之前，企业的网络仅存在于自己场所内。在 1990 年代和 2000 年代初，网络安全范式完全是围绕周界展开的。

不同的网络段可能具有不同级别的安全性，但内部网络及其所有段落都被包含在一个严密防守的周界内。有时，外部流量会被允许进入内部网络，但必须通过身份验证和授权的向量。但是，一旦突破了这个周界，用户就可以在内部网络中自由活动，无需再次验证凭证。所有用户要么被信任，要么不被信任，存在于周界内部意味着自动信任。可以想象成一个有着严格边境的国家，但国内几乎没有警察存在。

旧有的周界网络安全模型已经过时多年了，原因有很多。

首先，周界安全模型并不是非常具有韧性或健壮性。网络攻击者有时会突破身份验证障碍。因此，如果他们突破了周界，通常不会再有其他的身份验证障碍需要突破。这就像银行抢劫犯挑衅银行：“你们的安全必须每次都成功，但我只需要成功一次！”

其次，周界安全模型完全无法与今天更为复杂的云网络兼容。即使有人愿意尝试，周界安全模型也无法应用于云网络。最简单的企业云网络包括几个本地的 PC 端点，并通过互联网连接到一个云平台上的云服务。而最复杂的混合多云网络则包括多个公司自有地点的本地网络和端点，远程员工和承包商在家中工作，多个云服务（如 AWS、Azure 和 GCP），以及每个云平台上多个 SaaS、PaaS 和 IaaS 服务和应用。无论哪种方式，用户都必须通过互联网连接到他们的内部企业网络。

零信任安全意味着没有任何用户或机器会自动被信任。周界安全网络会自动信任周界内部的用户。但是在云网络和互联网中，是没有周界的。因此，身份验证和授权的向量与检查会尽可能多地在网络的各个地方实现。不管你来自哪里，访问这个组件时，你必须出示你的身份！

攻击者需要攻破多个身份验证点才能在企业云网络中横行。拥有多个身份验证点可以显著减少成功发动网络攻击的可能性。然而，如果攻击者成功获取了凭证，进入云网络可能会变得毫不费力。掌握这些细节对任何参与云渗透测试的人来说都至关重要。

本书后续章节将深入探讨一些最流行的 AWS、Azure 和 GCP 应用程序与服务。我们还将介绍虚拟化和容器化在云网络中的实现方式。同时，我们将探索在云红队演习中将使用的各种工具、技术和策略。

总结

我们进行渗透测试的原因是通过模拟网络攻击来了解计算机系统中的安全漏洞。

云网络中可能有数百或数千种潜在的网络攻击路径，包括内部和外部的。用户、用户帐户、机器身份以及面向互联网的应用程序中的漏洞，都是其中的一部分可能性。

您可能无法模拟所有可能的漏洞攻击。例如，云服务提供商通常禁止模拟 DDoS 攻击，并且您也不能亲自访问云服务提供商的数据中心安装测试设备。但了解攻击者可能采取的所有不同方法，并在进行红队演习时牢记这一点，仍然是非常重要的。

攻击可以来源于组织内部或外部。网络安全的 CIA 三维模型是一个概念，用来解释网络攻击如何在机密性、完整性和可用性方面影响组织的数据。

随着云网络的普及和网络技术的进步，我们现在通过零信任安全来保护计算机网络。这意味着用户和应用程序会在网络的尽可能多的点进行身份验证，不论用户的来源是网络内部还是外部。

在下一章中，我们将探讨渗透测试云网络的关键概念。

进一步阅读

要了解本章涉及的更多内容，您可以访问以下链接：

• MITRE ATT&CK: attack.mitre.org/

)

• DDoS 僵尸网络: www.cloudflare.com/learning/ddos/what-is-a-ddos-botnet/

)

• 零信任安全与 云计算: www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-for-the-cloud

第三章：渗透测试当今云网络的关键概念

在进行第一次云渗透测试或红队任务之前，您需要学习一些概念。

云平台有针对渗透测试的政策，您和您的组织必须遵守。了解并通过基准检查验证网络性能也非常重要。服务枚举是攻击者了解您组织的公共云服务的一种方式，可以帮助他们发起网络攻击。

确保您的组织的公共云已进行漏洞评估，并在渗透测试前处理了常见的云配置错误。

MITRE 的常见漏洞和暴露（CVE）数据库、国家标准与技术研究院（NIST）的国家漏洞数据库（NVD）和事件响应与安全团队论坛（FIRST）的漏洞预测评分系统（EPSS）数据库提供的资源可以帮助渗透测试人员和红队成员定义并理解特定的已知漏洞。

您还必须了解如何有效地与组织的防御安全专家沟通与合作。

本章将介绍以下主要主题：

• 云平台政策、基准检查与服务枚举

• 暴露的服务、权限和集成

• CVE、常见漏洞评分系统（CVSS）和漏洞

• 紫队合作与编写渗透测试报告

让我们开始吧！

云平台政策、基准检查与服务枚举

在公共云平台上进行云网络渗透测试与在您组织自有场地和基础设施上进行渗透测试有根本性的不同。

如果您的组织拥有场地和基础设施，那么它有权决定在渗透测试中允许和禁止您对其网络进行的所有操作。如果我购买了一栋房子，只要我所在的市政和国家的法律没有禁止，我可以允许建筑承包商更换墙壁、重做屋顶、安装新门等等。

如果我从房东那里租房子，我就不拥有房子。如果我想支付建筑承包商对房屋进行类似修改，我需要房东的许可。

在Amazon Web Services（AWS）、Azure 和Google Cloud Platform（GCP）上，您的组织是从“房东”——Amazon、Microsoft 或 Google 租用其“房子”。Amazon、Microsoft 和 Google 制定了渗透测试人员可以做的事情的规则。

如果您所在的组织要求您在其 AWS、Azure 和 GCP 托管的网络上做一些 Amazon、Microsoft 和 Google 在其政策中禁止的事情，您绝对不应该去做。定位云服务提供商的渗透测试政策，并在各自的网站上查看这些政策，向您的雇主分享这些信息，以明确进行渗透测试的任何限制或限制是非常重要的。我们在这里列出了它们：

• AWS 客户支持渗透测试 政策: aws.amazon.com/security/penetration-testing/

)

• Amazon EC2 测试 政策: aws.amazon.com/ec2/testing/

)

• AWS DDoS 模拟测试 政策: aws.amazon.com/security/ddos-simulation-testing/

)

• Microsoft 在线订阅 协议: azure.microsoft.com/en-us/support/legal/subscription-agreement/

)

• Microsoft 云渗透测试参与规则 指南: www.microsoft.com/en-us/msrc/pentest-rules-of-engagement

)

• Google 云平台服务条款: cloud.google.com/terms/

)

• Google 云平台可接受使用 政策: cloud.google.com/terms/aup

)

在组织提出公共云网络的渗透测试或红队参与之前，我建议仔细阅读云服务提供商的政策。然后，阅读你所在组织的提案和渗透测试范围，确保你被要求执行的任务符合 Amazon、Microsoft 或 Google 的政策。根据你组织要求的内容，你可能只需要对你的测试范围和模拟网络攻击进行一些小的调整，以符合政策要求。

我在第一章中提到过 AWS、Azure 和 GCP 的渗透测试政策。但为了你的参考，以下是官方政策链接以及每项政策的简要总结。这足以证明它们的重要性！

• AWS: 大多数 AWS 服务允许进行一般渗透测试。禁止在 Route 53 上进行 DNS 区域遍历、DNS 劫持和 DNS 欺骗。大多数拒绝服务（DoS）和分布式拒绝服务（DDoS）模拟是禁止的。协议洪泛和请求洪泛也是禁止的。使用命令与控制（C2）服务器进行渗透测试需要获得 Amazon 的直接批准。你还需要向 Amazon 请求批准网络压力测试、使用 iPerf 工具、模拟钓鱼和在渗透测试中使用恶意软件的许可。详情请见 aws.amazon.com/security/penetration-testing/。

• Azure 和微软云整体：大多数未经授权的渗透测试是允许的。然而，扫描和测试其他客户的资产并访问其数据是被禁止的。生成过多流量的自动化测试是禁止的。所有的 DoS 和 DDoS 模拟都是禁止的。针对除您组织自有 Azure 虚拟机外的任何设备进行网络密集型模糊测试是禁止的。超越概念验证（PoC）执行基础设施问题的步骤是禁止的。尝试对微软员工进行社交工程攻击是禁止的。

• GCP：对您的组织使用的 GCP 基础设施进行渗透测试必须遵循 Google 的可接受使用政策（cloud.google.com/terms/aup 和 cloud.google.com/terms/）。

现在，让我们进入基准检查的内容！

基准被定义为用来衡量性能的标准。您的组织可能对其公共云网络在日常或每小时的表现有一定的期望。在云环境中，基准通常基于应用程序和服务器的可用性，定义为正常运行时间、应用程序的响应性、以及修复网络功能问题可能需要的时间。

如果您的组织希望对其公共云网络进行基准测试，我建议将其基于 AWS、Azure 或 GCP 的服务水平协议（SLA）。这些是云服务提供商在您注册其服务时，保证您的组织所遵循的网络和基础设施性能标准。

对于 AWS 服务，亚马逊保证一定的每月正常运行时间。如果未达到这些基准，您的组织可能有权获得 10%、25%或 100%的服务信用。

对于 Azure 和微软在线服务，整体上它们的 SLA 与 AWS 在概念上类似。如果某些每月正常运行时间的基准未达到，您的组织可能有权获得 10%、25%或 100%的服务信用。微软的 SLA 每年至少更新几次。

对于 GCP 服务，其 SLA 也类似。但通常，如果未满足正常运行时间的基准，它们会提供 10%、25%或 50%的服务信用。

除了针对正常运行时间进行基准测试外，您的组织可能还希望对其公共云网络进行安全性基准测试。互联网安全中心（CIS）为 AWS、Azure 和 GCP 提供了一套网络安全基准，如下所示：

• www.cisecurity.org/benchmark/amazon_web_services

• www.cisecurity.org/benchmark/azure

• www.cisecurity.org/benchmark/google_cloud_computing_platform

枚举云服务是一种外部人员确定你组织所使用的云服务、它们的使用方式、权限以及每个服务对应的访问令牌的方法。

MITRE ATT&CK 将云枚举定义如下（attack.mitre.org/techniques/T1526/）：

“在获得访问权限后，攻击者可能会尝试枚举系统中运行的云服务。这些方法可以从平台即服务（PaaS）到基础设施即服务（IaaS）或软件即服务（SaaS）有所不同。许多服务存在于不同的云提供商中，可能包括持续集成与持续交付（CI/CD）、Lambda 函数、Azure AD 等。

攻击者可能会尝试发现整个环境中启用的服务信息。Azure 工具和 API，如 Azure AD Graph API 和 Azure 资源管理器 API，可以枚举资源和服务，包括应用程序、管理组、资源、政策定义及其与身份的关系。”

现在，让我们来看看一些公共云服务中常见的安全问题。

曝露的服务、权限和集成

每个网络在进行渗透测试前都应该进行漏洞评估。确保你进行渗透测试的云网络所属的组织近期已经进行过漏洞评估。

漏洞评估（有时称为漏洞审计）是一个系统化的过程，使用检查清单来识别与某种计算机系统相关的常见安全弱点、配置错误和其他漏洞。漏洞评估是一个识别、分析和优先处理系统、网络或应用程序中漏洞的系统化过程。它涉及扫描系统以识别现有的弱点、缺陷或可能被攻击者利用的漏洞。传统的漏洞评估可能会让一位人工网络安全专家使用特定操作系统或应用程序中常见漏洞的手动列表，检查软件、硬件和网络设置与配置，确保其中没有任何项使得计算机系统更容易受到网络攻击。这项工作可能繁琐，但在 20 世纪的本地网络中是相对实用的，因为这些网络变化不大。

但 21 世纪的云网络变化非常频繁。尤其是在像 Kubernetes 和 Docker 等平台上，容器化的环境中，单个容器（虚拟化应用程序或操作系统）可能只存在几天。现代云网络还可能更加复杂，涉及更多种类的应用程序和服务。多云、混合云和混合多云环境尤其可能非常多样化和复杂。

因此，在云网络中进行传统的手动漏洞评估通常是不切实际的。几个人无法跟上云漏洞评估所需要做的所有工作。这就是为什么我们在云中使用自动化漏洞扫描器的原因。

你可以使用多种不同的云漏洞扫描器。

AWS 有自己的 Amazon Inspector (aws.amazon.com/inspector/)。微软推荐用于 Azure 的 Microsoft Defender for Cloud (www.microsoft.com/en-ca/security/business/cloud-security/microsoft-defender-cloud)（这是 Microsoft Defender for Servers 的一部分）。谷歌推荐使用快速漏洞检测（Rapid Vulnerability Detection）（cloud.google.com/security-command-center/docs/concepts-rapid-vulnerability-detection-overview），对于 GCP，则取决于你的组织订阅了哪些服务层级以及使用了哪些 GCP 服务。

如果符合你的需求，您还可以使用一些第三方漏洞扫描器。最受欢迎的一些包括 Astra Pentest、Qualys Cloud Platform 和 Aqua Security。

信息

Astra Pentest 自动化漏洞扫描，并拥有一些工具来自动化部分渗透测试工作，但它不应取代你作为云渗透测试员的工作。

在开始你的第一次云渗透测试之前，确保你的组织最近使用了一些云漏洞扫描器。确保它已修复或解决了扫描器检测到的问题，并确保你能看到最近漏洞扫描的结果。这样做的原因是，如果你的组织的云网络中存在大量常见的漏洞，且这些漏洞可以被漏洞扫描器检测到，那么你的渗透测试可能会变得毫无意义。

本节内容涉及一些最常见的云安全问题——暴露的服务、权限问题（无效的身份与访问管理，或IAM）以及配置不当的云集成。在进行渗透测试之前，尽可能修复这些问题！

首先，让我们来检查暴露的服务。

暴露的服务

暴露的服务是指在你的云网络中，未受授权访问保护的服务。想想你可以在云端和互联网上找到的各种服务和协议——HTTPS 网络服务器、FTP 文件服务器、SSH 加密的远程访问服务器、RDP Windows 远程访问服务、SMB 服务（如 Samba）——这类服务不胜枚举。你的云网络中的所有这些潜在通道应该具有强大的认证保护，并且应该通过云网络的日志进行良好的监控。从你的云网络到公共互联网的这些连接通常是网络攻击者入侵的便捷途径。

云漏洞扫描器通常非常擅长发现你云网络中可能存在的暴露服务，因此你可以通过改善服务的加密和认证访问来修复这个问题，或者如果组织不使用该服务，干脆禁用它。

另一种发现暴露服务的方法是使用 Shodan。Shodan 提供月费服务计划，可以持续监控并扫描你的云网络 IP 地址，以查找暴露的服务。

安全研究人员研究了云网络中暴露服务带来的巨大问题。2021 年，Palo Alto Networks 的 Unit 42 进行了一个研究项目。它在云网络中部署了 320 个蜜罐。蜜罐是故意设计为不安全的计算机或服务器，目的是吸引网络威胁行为者进行攻击。使用蜜罐的目的通常是转移攻击者对组织必须保持安全的服务器的注意力，并监控网络攻击活动以更好地理解攻击行为。

Unit 42 部署的 320 个蜜罐使用了 SSH、Samba、Postgres 和 RDP 的组合。它为每个蜜罐设置了非常弱的凭据，例如“用户名: admin，密码: admin”，并监控蜜罐，看看它们会被攻击多少次。所有的蜜罐在不到两天的时间内都遭到了攻击。一些蜜罐在部署后的 30 秒内就被攻击！大多数蜜罐每天都会被攻击多次；攻击最频繁的蜜罐在一天内被攻破了 169 次。

这就是为什么你的组织必须非常小心，避免在云网络中暴露任何服务。暴露的服务可能会让你的云网络容易受到各种网络攻击，其中之一就是数据泄露。根据 IBM 2023 年《数据泄露成本报告》(www.ibm.com/reports/data-breach)，数据泄露每次事件平均会让一个组织损失 435 万美元！而这仅仅是暴露的服务可能遭遇的多种网络攻击中的一种。

现在让我们来探讨云中的权限和身份与访问管理（IAM）。

权限

在一个安全的计算机系统中，所有的数据资产只有授权的用户和实体才能访问。根据 Gartner 的定义（www.gartner.com/en/information-technology/glossary/identity-and-access-management-iam），IAM 是“一项安全和商业学科，包含多种技术和业务流程，帮助合适的人或机器在合适的时间以合适的理由访问合适的资产。”每个至少获得一些计算机系统访问权限的实体都需要一个身份和身份验证方式，如密码、生物识别和访问令牌。

权限是用户在计算机系统中允许执行的操作。例如，在我个人的笔记本电脑上，我在我的 Windows 11 安装中拥有完全的管理员权限。我可以安装、卸载和配置所有应用程序。我可以创建任意数量的用户账户并给予他们任何权限。我可以更改 Windows 注册表。我可以更改所有 Windows 设置。我可以读取、写入并访问我数据存储中所有的文件系统内容。但是，当我登录到我雇主的云网络时，我的权限要有限得多。我只能访问我工作所需的应用程序。我不能创建新的用户账户。我只能访问在公司角色中所需的数据。这是因为我拥有我的笔记本电脑，但我不拥有我雇主的云网络。与许多具备良好网络安全的网络一样，我雇主的云网络使用了基于角色的访问控制（RBAC）系统。

在 RBAC 中，权限分配给文件系统中的用户组。这些组与用户在公司中的角色相关联。可能会有一个工资部门组，该组可以访问公司的工资服务器和应用程序；一个研发组，该组可以访问公司的研发数据；一个网站管理员组，该组可以对公司的网站服务器进行更改，等等。权限不是直接分配给用户的，而是分配给组的。这是一种更简化的访问控制系统，避免了逐个用户管理权限的繁琐。

强制访问控制（MAC）是最严格的访问控制模型。系统中的资源对象可以根据保密等级（如高、中、低）以及部门和特定项目的类别进行分配。然后，针对每个用户，这些对象的权限会被非常仔细地配置。维护这种访问控制模型可能是繁琐的，这也是为什么 MAC 通常用于处理高度机密数据的应用场景，例如政府机构。

在自主访问控制（DAC）中，用户为他们创建的数据对象分配权限。这是 Windows 操作系统以及其他用户自己拥有的计算机上的本地操作系统中的默认访问控制系统。

主要的云服务提供商都有自己的工具，供你的组织用来改善 IAM。

亚马逊推荐使用其自家的 AWS 身份与访问管理（IAM）来管理 AWS。你可以使用它来管理基于属性的访问控制（ABAC），这与 RBAC 类似。你还可以使用它来实施防护措施，以防止特权提升攻击和未经授权的用户账户访问。你还可以跨单一或多个 AWS 账户管理用户和机器身份。

微软推荐其自家的 Microsoft Entra ID（前身为 Azure Active Directory）用于 Azure，它类似于 Windows Server 中的 Active Directory。Azure Active Directory 的优势在于它还能够在多云和混合云环境中控制身份和访问管理（IAM）。举例来说，如果你的组织有一个混合云，且本地网络中有一些 Windows Server 机器，那么从本地到公有云的所有 IAM 都可以通过相同的 Active Directory 系统进行统一管理。

谷歌也有自己的 GCP IAM。它的一些关键功能包括自动化访问控制建议、灵活的角色和基于上下文的访问控制。

渗透测试可以用来确保组织云网络中的 IAM 配置正确。这包括只为每个用户分配必要的权限（最小权限原则，或PoLP），并确保用户拥有强密码和多重认证（如一次性密码、多因素认证应用程序、生物识别和访问令牌）。

现在，让我们来看看云集成。配置和部署云集成时，确保其安全性至关重要，因为不安全的集成是云安全中常见的问题。

云集成

云集成的核心就是将多个云网络连接在一起。在混合云网络中，集成还意味着将本地服务器与云网络连接起来。除非你的组织只有本地端点和一个公有云，否则云集成是不可避免的。

云集成中的安全问题通常发生在网络可见性差、安全解决方案在云平台间不兼容，或者云应用之间的 API 安全性差时。

你的组织无法保护它无法看到的东西。因此，网络可见性差意味着你的混合云或多云网络中的某些部分可能存在安全漏洞，而你的组织对此并不知情。为了解决这个问题，至关重要的是尽可能多地记录应用程序和服务，并确保安全监控解决方案在你的集成云环境中兼容且部署到位。

集成云应用程序和服务之间的 API 如果没有得到充分保护，特别容易受到代码注入（如 SQL 注入、命令注入）和查询注入攻击的影响，以及利用不当的访问控制和过时组件的恶意请求。正如消除暴露服务是明智的做法，消除暴露的 API 也是明智的做法。

漏洞扫描器可能无法检测到可见性问题，但一些漏洞扫描器擅长检测不安全的 API。

可见性问题可以通过使用数据映射解决方案来减轻，以保持全面的数据资产清单。对于你的多云或混合云环境，拥有强大的日志记录也是至关重要的，并且需要将这些日志输入到安全监控应用程序中。

现在，让我们来探讨一下作为云渗透测试员，你的工作应该发现什么——安全漏洞！

CVE、CVSS 和漏洞

在网络安全中，我们有正式的系统来分类网络和应用程序中的安全漏洞。已知的漏洞记录在 MITRE 的公共漏洞和暴露（CVE）数据库中，简称 CVE（www.cve.org/）。CVE 记录根据 MITRE 的 CVSS（nvd.nist.gov/vuln-metrics/cvss）进行分类。此外，已知的漏洞利用会通过 EPSS（www.first.org/epss/）进行分类。MITRE ATT&CK 是一个用于分类已知计算机系统和网络漏洞利用的数据库（attack.mitre.org/）。

因此，MITRE 是一个帮助各种网络安全专业人士理解漏洞和漏洞利用的组织。MITRE 数据库中的知识每天都在不断增长。MITRE 的数据库通过网络公开，任何人都可以作为参考使用。作为一名云渗透测试员，你的工作是发现你测试的云网络中的漏洞和漏洞利用，以便你工作的组织可以更好地了解如何提高其网络和应用程序的安全性。让我们深入了解 MITRE 及其如何维护对渗透测试员和红队人员有用的知识。

漏洞

漏洞是计算机系统中的错误、缺陷或失误，网络攻击者可以利用它来危害组织的数据。例如，如果某个公众用户能够通过点击按钮访问你组织的云平台托管的电子商务应用程序中的客户信用卡号码，那绝对是一个重大的安全漏洞。这将是对敏感数据机密性的漏洞，符合网络安全中的 CIA 三原则。

如果网络安全社区没有人知道某个漏洞，而网络犯罪分子在网络攻击中利用了它，我们称之为零日漏洞。如果我们幸运的话，安全研究人员或漏洞奖励猎人在网络攻击者利用该漏洞之前发现了这个以前未知的漏洞，这也是零日漏洞。如果某个漏洞已记录在 MITRE 的 CVE 数据库中，那么它就不是零日漏洞，而是已知漏洞。

漏洞利用是一种用来进行网络攻击的方法或技术。例如，这里有一个 MITRE ATT&CK 数据库中关于 FTP 漏洞利用的描述（attack.mitre.org/techniques/T1071/002/）：

“对手可能通过使用与传输文件相关的应用层协议进行通信，以避免检测/网络过滤，通过与现有流量融合来掩盖自己。远程系统的命令，通常也包括这些命令的结果，将嵌入客户端 和服务器 之间的协议流量中。*

像 FTP、FTPS 和 TFTP 这样的文件传输协议在某些环境中可能非常常见。由这些协议生成的数据包可能包含许多字段和头部，其中数据可能被 隐藏。”

当你为你的组织进行云渗透测试时，你可能会在其云网络中发现许多存在于 MITRE CVE 数据库中的漏洞。你可能会发现一个零日漏洞，但这很少见！通常，零日漏洞是由漏洞奖励猎人发现的，或者是由防御性安全专家在网络攻击者利用该漏洞后发现的。如果你作为红队成员或渗透测试员从未发现过零日漏洞，不要太苛责自己。你的工作是发现组织计算机系统中的漏洞，这些漏洞大多数时候是网络安全社区已知的。

特别是作为红队成员，你可能会根据 MITRE ATT&CK 中的内容模拟网络攻击。

因此，查找 MITRE 数据库中的信息肯定是你工作的一部分，你会经常做这个。

让我们了解 MITRE 作为一个组织，以及它如何为公众维护网络安全信息。

MITRE 数据库

MITRE 成立于 1958 年，是一个私立非营利组织，与美国空军合作。在云网络和互联网成为日常生活一部分的几十年前，MITRE 通过诸如联邦航空管理局（FAA）等部门与美国政府合作，开发空中交通管制系统，并在计算机编程和数据处理等领域进行研究和开发。在 1990 年代，MITRE 帮助美国政府准备“Y2K 问题”。 “Y2K 问题”是全球许多计算机系统面临的问题。许多数据库、应用程序和操作系统在计算机时间戳和时间保持中只有两个字符来表示年份。因此，当 2000 年到来时，这些系统可能会认为是 1900 年，从而引起严重的操作问题。许多组织，包括 MITRE 在内，努力修复了“Y2K 问题”。这就是为什么当 2000 年终于到来时，并没有出现太多问题。

MITRE 于 1999 年启动了其 CVE 数据库。当年仅记录了 321 个漏洞。然而，CVE 数据库不仅每年添加了更多的漏洞记录，而且漏洞记录的增长速度也在稳步增加。2003 年增加了 1,223 条记录。2008 年增加了 5,673 条记录。2017 年增加了 14,645 条记录。而在 2022 年，竟然增加了惊人的 25,059 条记录。也许现今的应用程序并不比以前更安全。也许应用程序变得更加复杂，网络安全社区用来发现漏洞的例行程序也有所改进。

2013 年，MITRE 推出了 ATT&CK，他们描述为“基于实际观察的对手战术和技术的全球可访问知识库”（attack.mitre.org/）。

让我们来看看 CVE 数据库。

漏洞是如何记录在 CVE 数据库中的呢？

MITRE 与大量的CVE 编号机构（CNAs）合作。截至 2023 年 4 月，共有 285 个 CVE 编号机构。绝大多数 CVE 编号机构是生产软件、硬件和基础设施可能存在安全漏洞的科技公司。例如，高通（半导体芯片生产商）、空中客车（飞机制造商）和 FreeBSD（操作系统开发者）都是一些 CVE 编号机构的例子。此外，许多人熟悉的大公司也是 CVE 编号机构，如微软、苹果和谷歌。

一些大型科技公司拥有漏洞悬赏计划。漏洞悬赏计划允许公众成员（不属于该科技公司的人）报告他们发现的安全漏洞。他们必须遵守公司的负责任披露政策，这通常意味着他们将漏洞发现报告给公司内部的某个个人或部门，而且不应将其发现公开。这为公司提供了在黑客发现漏洞并利用这些信息进行网络攻击之前修复漏洞的机会。

如果漏洞悬赏猎人遵守公司的漏洞悬赏计划规则，且公司认为该猎人发现的漏洞是合法且有用的，他们可能会支付漏洞悬赏猎人几百美元到超过$100,000 不等的奖励。奖励金额取决于公司为漏洞设定的奖励额度，以及他们认为漏洞的重要性。HackerOne维护着大多数漏洞悬赏计划的数据库 (hackerone.com/bug-bounty-programs)。

成为一名漏洞悬赏猎人与成为渗透测试员或红队成员非常不同。渗透测试员和红队成员通常会被分配特定的渗透测试任务，任务范围明确。漏洞悬赏猎人则是外部人员，他们可以发现任何自己感兴趣或擅长发现的漏洞，只要他们按照公司漏洞悬赏计划的规则行事，且不参与任何网络攻击。渗透测试和红队工作就像是在餐厅里做厨师；而漏洞悬赏猎人则像是在向食品银行捐赠食物。而且，只有漏洞悬赏猎人需要寻找零日漏洞，而渗透测试员和红队成员则需要在他们所工作的组织指定的范围内，通过模拟网络攻击来发现漏洞。

很多时候，漏洞记录会通过漏洞悬赏计划进入 CVE 数据库。例如，如果一名漏洞悬赏猎人在 Windows 11 中发现一个漏洞，这名漏洞悬赏猎人必须遵守微软的漏洞悬赏计划。然后，微软作为 CNA 将该漏洞记录到 CVE 数据库中。

有时，某些特定科技公司的员工和承包商（这些公司是 CNA）会发现零日漏洞。这些科技公司作为 CNA，将以与漏洞悬赏猎人相同的方式将漏洞记录到 CVE 中。

CNA 有责任确保他们在产品和服务中发现的漏洞，或者由他们报告的漏洞，能够被记录在 CVE 数据库中。CNA 通常不会记录那些与其自身产品和服务无关的漏洞。例如，记录 Mozilla Firefox 在 Android 版本中的漏洞并非苹果的责任，但记录 Firefox 在 iOS 版本中的漏洞可能是苹果的责任。也有可能是 Mozilla 的责任，或者是苹果和 Mozilla 共同的责任，这取决于哪个部分的产品受到了影响。

CVE 记录通常在 CNA 发现漏洞后并不会立即创建。CVE 记录是公开的，技术公司可能需要几个月甚至一年时间来私下解决漏洞。当漏洞可以公开披露时，通常会发布 CVE 记录。

作为一名渗透测试员，你很可能会发现你所在组织的网络存在一些已经存在几年的漏洞。例如，你可能会发现一个 2018 年的 CVE 记录。CNA 可能已经为这个漏洞提供了安全补丁，但你的组织尚未安装，或者这个漏洞虽然是公开的，但修复或缓解起来非常困难。作为渗透测试员，发现零日漏洞并不是你的工作，许多你发现的漏洞可能已经被技术厂商知晓多年！

下面是一个真实的 CVE 记录示例。

CVE-2022-3349 是索尼 PS4 和 PS5 视频游戏主机中的一个漏洞。每个 CVE 记录的标识格式都是这样的：CVE，接着是四位数的年份，再接着是该年份唯一的四位数编号。

该记录包含了漏洞的基本描述：

“在索尼 PS4 和 PS5 中发现了一个漏洞。该漏洞被分类为严重漏洞。它影响了组件exFAT处理器的UVFAT_readupcasetable功能。对参数dataLength的操控会导致堆栈溢出。可以在物理设备上发起攻击。建议升级受影响的组件。该漏洞的关联标识符为 VDB-209679。”

然后，展示了该漏洞的参考列表，通常是指向发布的报告的网页超链接，这些报告来自 CVE 数据库以外的地方。

接下来，列出了分配的 CNA。在此记录中，CNA 是 VulDB。VulDB 是一个第三方漏洞数据库。由于某些原因，索尼并不是 CNA。因此，第三方的索尼信任的机构承担着将索尼产品和服务中的漏洞添加到 CVE 数据库中的责任。

接下来，显示了记录创建的日期。在此记录中，日期是 20220928。这意味着 2022 年 9 月 28 日。这里有一个免责声明：“记录创建日期可能反映了 CVE ID 的分配或保留时间，并不一定表示该漏洞被发现、与受影响供应商共享、公开披露或更新到 CVE 中的时间。”正如我提到的，漏洞的发现与被添加到 CVE 数据库之间可能有几个月甚至一年的时间。这通常是为了给供应商（受漏洞影响的科技公司）一些时间来修复漏洞，以防止其被公开利用，防止网络攻击。

关于CVE-2022-3349（以及其他 CVE 记录）的更多信息，您需要访问 NIST 的 NVD。NVD 为大多数 CVE 记录提供网页。请见cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3349和nvd.nist.gov/vuln/detail/CVE-2022-3349。

这是 NVD 关于 CVE-2022-3349 的相关信息（cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3349）。它有一个 CVSS 评分。CVSS 为漏洞评分，分值在 0.0 到 10.0 之间。较低的分数表示漏洞不那么严重，这意味着如果网络攻击者利用这些漏洞，其危害较小。较高的分数表示漏洞更加严重，若被攻击者利用，其危害较大！CVE-2022-3349在 CVSS 3.X 版本的评分中为 6.8（中等）。

然后，NVD 列出了“建议、解决方案和工具的参考资料”。这类似于 CVE 自身数据库中的网页超链接引用。事实上，CVE 和 NVD 经常交叉引用这些资料——它们可能在这两个记录版本中是相同的超链接。

最后，NVD 列出了“弱点枚举”。这些是指向 MITRE 的通用弱点枚举（CWE）数据库的链接，MITRE 称之为“一个由社区开发的软件和硬件弱点类型列表。”弱点是漏洞可能具有的缺陷类型。NVD 对于CVE-2022-3349的记录列出了以下 CWE：

• CWE-787, 越界写入

• CWE-122, 基于堆的缓冲区溢出

• CWE-119, 内存缓冲区操作范围不当限制

让我们来看看两个常用的 CVSS 评分标准。

CVSS v2.0 是较旧的评分标准。漏洞得分 0.0 到 3.9 被归类为“低”，4.0 到 6.9 被归类为“中”，7.0 到 10.0 被归类为“高”。较新的 CVSS v3.0 有更多的分类。0.0 始终意味着漏洞不具任何危险性。我认为没有漏洞会有 CVSS v3.0 得分为 0.0；这个数字只是作为一个概念存在，用来帮助量化其他得分区间。得分为 0.1 到 3.9 的是“低”，4.0 到 6.9 的是“中”，7.0 到 8.9 的是“高”，9.0 到 10.0 的是“关键”。无论使用哪个 CVSS 版本，较高的得分表示漏洞更危险，较低的得分表示漏洞较不危险。作为渗透测试人员或红队成员，你需要帮助编写渗透测试报告。你应该在报告中提到 CVSS 得分，而这些得分将帮助你的组织确定哪些漏洞最需要优先处理。

最后是 EPSS。EPSS 由 FIRST 维护。根据 FIRST 的描述，FIRST“旨在将全球各国的事件响应和安全团队聚集在一起，确保为所有人提供一个安全的互联网”。

FIRST 使用 EPSS 来描述漏洞被网络攻击者利用的可能性或概率。FIRST 认识到，漏洞太多，无法立即修复，且漏洞常常在完全修复之前就被记录到 CVE 数据库中。有些漏洞非常难以完全修复。因此，FIRST 使用 EPSS 来确定已知漏洞是否可能被利用，以及被利用的可能性有多大。FIRST 表示，只有 2%到 7%的已知漏洞会“在 实际环境中被利用”。

EPSS 得分是以百分比表示的，范围从 0%到 100%。0%表示该漏洞永远不会被利用，而 100%表示该漏洞肯定会被利用，并且可能已经被利用了很多次。根据 FIRST 的说法，绝大多数漏洞的得分低于 25%，其中许多低于 10%。

FIRST 建议渗透测试人员和防御性安全专家根据 CVSS 和 EPSS 对漏洞进行分类。因此，CVSS 得分为 9.8 且 EPSS 得分为 97%的漏洞应当立刻处理，尽可能迅速，并给予绝对的优先级。如果一个漏洞的 CVSS 得分为 9.9，但 EPSS 得分为 2%，你可能需要等待 EPSS 得分更高的漏洞先被处理，尽管利用该漏洞的风险非常高。

现在我们知道了如何在公共数据库中记录漏洞和利用情况的信息，我们准备好理解如何编写有效的渗透测试报告以及如何进行紫队合作。紫队合作是指红队与蓝队——防御性安全专家合作的过程。

紫队合作与编写渗透测试报告

作为一名云渗透测试员，无论你是作为外部承包商为所在组织工作，还是作为组织内部红队的一员，你将在一个项目中投入从几天到几个月的时间。你的目标是在组织合同定义的范围内，尽可能发现更多的安全漏洞，同时执行组织和云服务提供商（AWS、Azure、GCP）允许的模拟网络攻击。

因此，在这些天、周或月的过程中，你可能发现了多个漏洞。大多数漏洞是网络安全社区所熟知的，且在 CVE 数据库、NIST 的 NVD 以及与漏洞相关的厂商（向你的组织提供产品和服务的科技公司）的安全警报和补丁公告中都有广泛记录。也许你发现的一些漏洞只是常见的安全配置问题，例如在从未使用的情况下启用 Windows 的 RDP。这本应该在漏洞评估中发现。但至少你能捕捉到它！或者，也许你还发现了其他在企业中常见的网络安全问题。

太棒了！你在一段时间内付出了很多努力，你和你的团队发现了一堆只有通过有效和适当的渗透测试才能发现的严重网络安全问题。（嗯，除了那个不必要启用的 RDP。为什么你们的组织在漏洞评估中没发现这个？）

现在，你可以回家，玩会儿视频游戏，或者请你的浪漫伴侣吃顿美味的美食，来庆祝你在工作上的成就。

等等，所有这些渗透测试到底是为了什么？是为了炫耀你聪明的黑客技巧吗？那很好，你工作的公司也非常印象深刻。你模拟了他们认为只有 APT 才能完成的网络攻击。（APT代表高级持续性威胁，指的是可以长期攻击目标的网络犯罪集团。他们是最先进的网络攻击者，并且非常持久！）

但归根结底，组织雇佣渗透测试员和组建红队的真正原因是，他们需要发现漏洞评估可能遗漏的安全漏洞，以便他们能够改善 其网络的安全态势。

为了使他们能够利用你发现的信息来改善网络的安全态势，你需要能够有效地传达你发现的信息。这意味着要参与紫队协作并编写一份渗透测试报告，使得你组织中的防御安全专家能够轻松理解。

很有可能，在你的一生中，你曾见过某个天才试图以别人无法理解的方式表达自己的创意。

为了让你的渗透测试对你所工作的组织有益，你的目标应该是避免成为那种无法有效沟通的聪明人。你需要帮助你所工作的组织理解你发现的安全问题，并可能甚至提出一些建议来解决这些问题。

多年来，我与许多其他渗透测试人员一起工作。有很多知识渊博、技能高超的专业黑客。但只有少数人能够有效地进行紫队合作并撰写高质量的渗透测试报告。据我所知，那些善于沟通的渗透测试人员已经成功地工作了几十年，而那些沟通效果不佳的渗透测试人员更有可能失去工作。

如果你能向你的组织展示你已经找到了关于他们网络安全漏洞的信息，这些信息可以帮助他们显著提升安全姿态，那么你将受到他们高度重视，并且很可能会有一个成功的职业生涯。

这本书涵盖了许多关于对 AWS、Azure 和 GCP 进行渗透测试的有效工具和技术的知识，熟悉这些工具和技术对于成为红队中成功的云渗透测试人员至关重要。但撰写良好的渗透测试报告和有效的紫队合作同样重要。

首先，让我们了解一下紫队合作以及为什么这是你的组织需要的一种实践。

紫队合作

紫队合作是网络安全领域相对较新的概念。

红队是一群攻击性安全专家。他们的工作是复制特定威胁行为者可能采取的特定工具和技术，这些工具和技术可能被用来攻击你的组织。他们的参与可能持续数月。他们从事攻击性网络安全，扮演模拟网络攻击者的角色，为你的组织带来好处。与普通的渗透测试不同，他们必须特别模仿特定的攻击者，比如一个公认的 APT 组织。

蓝队是一群防御性安全专家。他们的工作是寻找新的方法来提升组织的安全姿态，每天都在工作。安全运营中心（SOC）分析员、数字取证专家以及事件响应（IR）组等都在防御性网络安全领域工作。但一个合适的蓝队总是对最新的网络威胁和技术感兴趣，并根据所学到的内容设计其安全加固工作。

如果你曾经乐在混合颜料和色彩理论中，你会知道混合红色和蓝色颜料会得到紫色。因此，紫队是红队和蓝队所做的事情的结合。

我的朋友 Daniel Miessler 是紫队领域的顶尖思想领袖之一，也是这一概念的先驱。根据 Miessler 的观点，紫队是在红队和蓝队成员之间有效合作时形成的。有些组织可能会考虑创建一个专门的紫队，作为鼓励他们的红队和蓝队更好地沟通和合作的替代方案。但这可能不会非常有效。

Miessler 为什么认为专门的紫队是个坏主意的类比，基于一个专业的餐厅厨房。如果一家餐厅发现其服务员难以将食物从厨房送到顾客那里，解决方案不是雇佣一支新的“厨房到餐桌协调员”团队。解决方案是找到让服务员有效送餐的方法。如果一家餐厅有一位精英厨师认为他们的菜肴过于精致，顾客难以欣赏，那么再多的烹饪技巧也无法让餐厅受欢迎。厨师可能会把他们的菜肴留在厨房，而如果顾客没有得到食物，餐厅就会失败。所以，如果你是一个不重视与蓝队合作的红队成员，你的技能和才华将无人受益。

因此，紫队的技巧完全是关于有效的团队合作和沟通技巧。这些并不完全是技术技能；它们是人际交往技巧。作为红队成员，保持谦逊并愿意从蓝队中倾听和学习也至关重要。我见过很多行业中的巨大自负——不要成为其中之一！

GitLab 进行大量的紫队合作工作。它们的工作流程如下。

首先是攻击规划阶段，在这一阶段，红队和蓝队拥有平等的责任。它们会进行头脑风暴，提出并讨论可能的网络威胁，或许会使用威胁情报（TI）或新的威胁检测能力作为灵感。接下来，他们将讨论行动的后勤安排（责任、时间表等），并概括他们计划模拟的攻击者。攻击者可能使用什么样的 C2 服务器？他们可能使用哪些战术和技术？攻击者的目标是什么？然后，他们将进行桌面演练，这是防御性安全专家的一项流行活动。这有点像玩桌面角色扮演游戏，但他们将用它来回顾真实世界的威胁行为者战术、技术和程序（TTPs）。如果攻击者使用这些 TTP，蓝队在事件响应中会如何反应？这些 TTP 如何危害他们组织的网络和数据？

攻击仿真阶段是红队和蓝队分别专注于各自职责的阶段。红队将测试执行其 TTP（战术、技术和程序）所需的基础设施和工具。然后，红队将利用这些 TTP 模拟网络攻击，如定向渗透测试。在红队模拟攻击的同时，蓝队将验证这些（模拟的）攻击的预期结果。

最终阶段是操作的总结。红队准备并分享其渗透测试报告。然后，红队和蓝队聚集在一起讨论发生的细节。哪些方面有效？哪些方面可以做得更好？

进行紫队合作的方式有很多种。GitLab 的工作流程就是一种模式。SCYTHE 公开分享了它自己的模式——紫队演练框架（PTEF）。

SCYTHE 框架的工作流程是这样的。在演练协调员的指导下，红队和蓝队聚集在一起讨论特定的威胁行为者、该行为者的 TTP（战术、技术与程序）以及相关的技术细节。接下来，红队和蓝队在桌面演练或讨论中作为平等的合作伙伴，讨论这些 TTP 以及你们组织的安全控制措施。如果进攻方做了某些特定的事情，防守方会如何回应？然后，红队模拟攻击者的 TTP，而蓝队则仔细观察。蓝队可能应该做笔记。接下来，蓝队检测并响应红队的 TTP 模拟；它所做的一切应该对红队可见。检测工程步骤中，蓝队调整其安全控制并改善网络安全事件日志，以提高其对红队模拟攻击的可视性。最后，红队和蓝队再次聚集在一起，重复他们的流程，记录结果，然后进入下一个 TTP 模拟——一个新的紫队演练。

如果你只是以渗透测试员的身份为组织工作，那么紫队的工作流程对你来说可能不太相关。然而，你仍然需要注意尊重组织防御安全专家的需求，并与他们有效沟通。

如果你是一个正式红队的一员，组织中如何进行紫队合作的这些例子可以作为你工作的范例。如果你的公司还没有与蓝队达成一致的紫队合作流程，建议推动紫队合作流程的建立。如果你能向安全团队的领导解释与防御安全组有效协作的重要性，你的努力一定是值得的。你可能需要在上级面前充分阐述正确紫队合作的重要性，但你的主动性可能会得到奖励。

现在，让我们来学习你可能被期望做的事情——无论你是否是红队的一员，那就是编写有效的渗透测试报告！

编写渗透测试报告

如果你不擅长创意写作，你的渗透测试团队至少需要有一位擅长此项技能的同事。只要你的渗透测试团队中的每个人能够以其他方式有效地相互沟通，你就可以将编写渗透测试报告的任务简单地委托给团队中最擅长写作的人。当然，如果你是作为团队进行渗透测试，那么你的渗透测试报告是一个团队的努力。每个人的发现都应该包含在报告中。你的渗透测试报告的撰写者将需要你所有的发现，当撰写者询问时，你需要能够解释你做了什么以及发生了什么。你还应该妥善保管你在渗透测试期间使用的任何工具的日志，因为你将需要将它们作为报告的参考。

但如果你是独立的渗透测试人员，那么编写渗透测试报告的责任完全由你承担！这是渗透测试人员需要不仅具备技术技能，还需要具备创意和沟通技能的一个例子。

因此，让我们看看你的组织对你的渗透测试报告有什么期望。

所有优秀的渗透测试报告必须包括以下内容：

• 报告开头的执行摘要。

• 渗透测试范围的定义。这是你测试的“什么”。你的测试的主题究竟是什么？

• 对你的渗透测试方法论进行彻底和详细的解释。这是你测试的“如何”。

• 你的渗透测试发现的漏洞清单。这些漏洞可能需要按照最关键的漏洞在前，最不关键的漏洞在后进行分类。

• 对你发现的漏洞可能对组织造成的影响进行分析。这部分非常关键，因为如果你的组织不了解如果不解决漏洞可能会造成的危害，那么他们为什么要在意呢？

• 如何纠正你的渗透测试发现的具体漏洞的建议。逐个漏洞进行处理。

建议如何改进组织的安全策略。这超出了纠正特定漏洞的范围。你需要提出建议，说明组织如何全面提升其安全姿态。例如，如果你成功利用的大多数漏洞在 CVE 数据库中已经存在超过十年，你可以建议改进其补丁管理，并努力用更现代的硬件和软件替换传统技术。

执行摘要应该在报告的开头而不是结尾。执行摘要是给高管看的。他们通常是组织中具有很大权力和影响力的人，但并不特别擅长技术方面。

他们也是非常忙碌的人。在他们的优先事项清单中，阅读你的渗透测试报告可能排在当天的第 27 位。他们不会花几个小时阅读你的报告。如果你幸运的话，他们可能会给你 5 分钟的时间。因此，执行摘要需要放在报告的开头，并且必须简明扼要。执行摘要应该是一到两页，最多就是这样。如果按字数计算，目标是 300 到 600 字。高层管理人员不太可能读超过这个字数。

在你的执行摘要中，仅需解释你测试了哪些内容，发现了什么样的模式，或者你发现的最重要的问题是什么。下面是一个例子：

“我们尝试通过代码注入漏洞来访问托管在 Amazon EC2 实例上的组织微服务，目标是电商网站的界面。结果成功了，我们通过这些 API 获得了未授权的访问权限，能够访问敏感数据。这些漏洞如果被利用，可能会对公司造成的损害就是这样。这是如果发生真实的网络攻击，可能会导致公司损失的金额。”

将每个“this”替换为你实际的渗透测试发现。我坚信在报告中提到这些网络攻击可能对公司造成的估算财务损失。这正是你的高层管理人员最关心的——金钱。获得可信的财务风险数据比你想象的要容易。例如，如果漏洞利用可能导致数据泄露，你可以从 IBM 的《数据泄露成本报告》(www.ibm.com/reports/data-breach)中获得大致的损失金额。如果是勒索软件攻击，你可以引用以下报告：www.cybereason.com/ransomware-the-true-cost-to-business-2022。

你报告的其余部分是供你公司内部的网络安全专家阅读的。只要执行摘要简短，其余的报告可以根据需要写得长一点，以便包含所有重要的技术细节。报告的长度会根据你在渗透测试过程中所做的工作量而有所不同。但渗透测试报告很少超过 100 页，大多数报告的页数在 20 到 70 页之间。

解释你的渗透测试范围。“我们测试了这个特定的 DevOps 网络。” “我们测试了这个特定的 Web 应用程序。” “我们测试了这个特定的网络段。” 当然，你需要为测试范围提供更多的细节。列出网络地址、IP 地址或任何适用的标识符，以便安全团队知道你具体测试了什么内容。

方法论部分也应详细具体。你应该按时间顺序逐步解释你在测试中采取的确切行动。列出你使用的工具、模拟的漏洞利用以及尝试的技术。如果有疑问，宁可详细描述，也不要简略。你可能想引用 MITRE 的 ATT&CK 数据库（attack.mitre.org/）来命名具体的漏洞利用技术。这个资源在网上是免费的并且公开可用。

接下来，你需要展示你的渗透测试发现的漏洞。你发现的每一个漏洞都必须包括。无论何时适用，都要引用具体的 CVE 编号。我建议按照从最严重到最轻微的顺序展示漏洞。提到 CVSS 和 EPSS 分数。根据 CVSS 和 EPSS 的综合评分来权衡每个漏洞的严重性。例如，如果有几个漏洞的 CVSS 分数在 7.0 到 9.0 之间，那么 EPSS 为 30%的漏洞应排在前面，EPSS 为 10%的漏洞应排在后面。MITRE 的 CVE 数据库（cve.org）、NIST 的 NVD 数据库（nvd.nist.gov/）以及 FIRST 的 EPSS 数据库（www.first.org/epss/）都是免费的公开资源，你可以通过它们查找 CVE 编号、CVSS 分数和 EPSS 分数。

接下来，你需要提供修复建议。要具体明确。提到需要安装的补丁、需要更改的配置和设置等。这些内容会根据漏洞的性质有所不同。

你知道“看树不见森林”这句话吗？它意味着某人过于关注情况的细节，导致忽视了“全局视角”。但是在你的渗透测试报告中，你的组织必须同时看到森林和树木。修复建议部分是“树木”，而安全策略改进建议部分是“森林”。“升级和更换过时的技术。”“雇佣安全运营中心团队。”“改善事件响应计划。”这些都与安全策略相关，但要根据你特定的组织和渗透测试使用适当的细节。

我建议在第一次编写渗透测试报告之前，查看一些公开的真实世界渗透测试报告。可以查看 juliocesarfort 在 GitHub 上维护的真实渗透测试报告集（github.com/juliocesarfort/public-pentesting-reports）。在 pentestreports.com 网站上也有一个大型报告集（pentestreports.com/reports/）。如果你想进一步了解，我曾在SANS Pen Test HackFest Summit 2021上做过一场关于编写有效渗透测试报告的演讲，演讲题目是Writing Reports: The Overlooked Pen Testing Skill。你可以在 YouTube 上观看这场演讲（www.youtube.com/watch?v=r-6LBjlM14Y）。

就是这样。这就是为什么要进行渗透测试的原因。你进行渗透测试是为了发现安全漏洞信息，推荐行动方案，并帮助防御安全团队提升你组织的安全态势。

总结

AWS、Azure 和 GCP 有渗透测试政策，你和你的组织必须遵守。基准检查验证你组织云服务的性能。云服务商的 SLA 是一个很好的通用基准来源。CIS 还为网络安全提供了具体的基准。云服务枚举是攻击者用来发现你组织如何使用云服务的一种方式。你可以执行一些脚本来测试你组织对漏洞的易受攻击性。

漏洞评估可以通过漏洞扫描应用程序进行。在渗透测试之前，重要的是要有漏洞评估的最新历史记录，并对这些评估发现的漏洞进行缓解。常见的安全配置错误必须首先解决，才能确保你的组织准备好进行渗透测试。

暴露的服务是你组织云网络中的互联网服务和端口，攻击者可以通过互联网利用这些服务进行网络攻击。确保你的公有云中所有这些点都采取了适当的访问控制措施，以防止服务暴露至关重要。权限是访问控制的组成部分——用户和机器在你组织的每个应用和服务中被允许执行什么操作？云集成是指你网络中不同的云平台（如 AWS、Azure、GCP）相互连接，或它们中的任何一个部分与本地网络连接。确保云集成的安全非常重要，因为它们可能特别容易受到网络攻击。

公共已知的安全漏洞记录在 MITRE 的 CVE 数据库中。NIST 将相同的 CVE 记录在其 NVD 数据库中，并为它们分配 CVSS 评分，确定它们的严重程度。FIRST 为这些 CVE 分配 EPSS 评级，指示攻击者利用这些漏洞的可能性。

作为一名渗透测试人员或红队成员，与你的防守安全团队或蓝队团队进行良好的沟通和合作至关重要。紫队协作是红队和蓝队共同执行的操作，旨在发现安全漏洞。每次渗透测试后都应编写渗透测试报告，报告应有效地解释你发现的漏洞、其影响以及为组织的高层和防守安全团队提供的修复建议。

在下一章中，我将介绍 AWS，亚马逊的云平台。你将了解各种 AWS 应用程序和服务，以及它们的使用原因。我们还将探索亚马逊自带的 AWS 安全工具，以及一些第三方工具。

AWS 是目前最受欢迎的云平台之一。你可能会对 AWS 能够支持的多种不同使用场景感到惊讶。AWS 还拥有许多对云渗透测试者至关重要的安全控制功能，值得深入理解。

延伸阅读

要了解更多本章内容，你可以访问以下链接：

• AWS 官方渗透测试 政策：aws.amazon.com/security/penetration-testing/

• 微软官方渗透测试参与规则：www.microsoft.com/en-us/msrc/pentest-rules-of-engagement

• Google 官方渗透测试 政策：cloud.google.com/terms/aup

• MITRE 的 CVE 数据库：

  • cve.mitre.org/cve/

  • www.cve.org/

• 通过 HackerOne 的完整漏洞悬赏计划列表：hackerone.com/bug-bounty-programs

• NIST 的 CVSS 系统：nvd.nist.gov/vuln-metrics/cvss

• FIRST 的 EPSS 系统：www.first.org/epss/

第二部分：渗透测试 AWS

亚马逊的 AWS 是最受欢迎的云平台之一。在本部分中，我们将学习 AWS 的各种软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）应用程序。我们将部署自己的 AWS 实例，用于测试我们的渗透测试技能。我们将使用 AWS 安全中心检查我们 AWS 部署的安全状况。我们还将逐步尝试一些在 AWS 中的渗透测试工具。然后，我们将部署 Docker 和 Kubernetes 容器并进行测试。

本部分包含以下章节：

• 第四章，AWS 中的安全功能

• 第五章，通过无服务器应用程序和工具进行 AWS 功能的渗透测试

• 第六章，在 AWS 中进行容器化应用程序的渗透测试

第四章：AWS 中的安全功能

作为一名云渗透测试员，可能会经常被要求对 AWS 的应用程序和服务进行渗透测试。AWS 在过去 20 年的云计算热潮中扮演了核心角色。所以，在这一章中，我将向你介绍 AWS。你将了解最受欢迎的 AWS 服务、应用程序和功能，以及它们为何被使用。我们还将讨论 AWS 的 SaaS、IaaS 和 PaaS 功能，探讨亚马逊自有的 AWS 安全工具和第三方安全工具。

在这一章中，我们将讨论以下主题：

• AWS 简介

• 常用的 AWS SaaS 特性

• AWS IaaS 特性

• AWS PaaS 特性

• AWS 安全控制与工具

让我们开始吧！

AWS 简介

AWS代表Amazon Web Services，它是最受欢迎的云平台之一。亚马逊最初于 1994 年作为一个在线书籍零售商起步，但即便在那些早期，亚马逊创始人杰夫·贝索斯就曾说过，Amazon.com是一个技术公司，旨在简化消费者的在线交易。类似传统零售商的业务部分，如维护库存仓库和客户服务，只是一些必要的组成部分。贝索斯真正看重的基础设施一直是亚马逊的数据中心。

随着 1990 年代的推进，亚马逊的库存已经远远超出了书籍。它开始销售音乐、电影、服装、家居配件等。在 21 世纪，亚马逊几乎销售所有可以在室温下妥善存储并合法销售给消费者的商品。它们还为消费者提供了许多不同的互联网服务，比如Amazon Prime的流媒体娱乐和Kindle 电子书。

随着 2000 年代的到来，亚马逊发现自己拥有比大多数大型公司更多的计算机网络基础设施。地球上没有其他公司能通过网络如此成功地销售产品。因此，到了 2002 年，亚马逊开始允许其他零售企业使用它的一些基础设施和软件来更成功地部署自己的电子商务。这就是 AWS 的起源，但 AWS 直到 2006 年才以其现在的形式出现，当时它推出了弹性计算云（EC2）和简单存储服务（S3）。EC2 向企业和公司客户出租计算处理能力，S3 则出租数据存储。

截至 2023 年，AWS 提供了广泛的应用程序，能够满足各种业务需求。EC2 和 S3 多年来不断改进，并且是非常常用的服务。AWS 拥有一整套应用程序和服务，适用于许多 SaaS、PaaS 和 IaaS 使用案例。自 AWS 约 20 年前推出以来，它不断新增新的服务和应用程序。

无论你的组织是将 AWS 作为唯一的云服务提供商，还是拥有多云网络，它很可能已经将一个以上的 AWS 服务或应用程序集成到其网络中。有些组织甚至同时使用数十个 AWS 应用程序。

详细描述每个 AWS 服务和应用程序超出了本书的范围。但当你对贵组织的 AWS 网络进行渗透测试时，了解为什么许多最流行的 AWS 服务和应用程序存在是非常重要的。让我们来看看。

常用的 AWS SaaS 功能

AWS 的功能、应用程序和服务属于许多不同类别。一些服务是免费提供的，或者提供有限的免费试用。大多数服务，尤其是企业最有可能使用的服务，是根据服务类型和使用量收取费用的。例如，一个需要少量带宽、每月为几百名用户提供服务的云应用程序，通常比一个需要大量带宽并为数万名用户提供服务的云应用程序便宜得多。

当然，管理 AWS 服务费用是贵组织的责任，而不是你的责任。所以，我将解释渗透测试人员需要了解的内容：企业经常使用的 AWS 服务及其使用原因。

我将从一些 SaaS 功能和应用程序开始。这些应用程序使用 AWS 的基础设施、平台以及其自己的软件。SaaS 服务是亚马逊最有责任和控制权的服务。作为渗透测试人员，你不允许以任何方式对其进行渗透测试。请参考 AWS 的渗透测试政策（aws.amazon.com/security/penetration-testing/）。然而，尽管你不能对其进行渗透测试，但你仍然应该了解这些应用程序是什么，即使你不能测试它们。这将帮助你理解你的组织如何使用 AWS 整体服务，也有助于你设计更有效的红队场景并将安全测试结果放入背景中。

Amazon Chime 是亚马逊相当于 Zoom 或 Skype 的服务，通过 AWS 生态系统托管。Chime 支持几乎所有类型的客户端计算机和移动设备，包括 Windows、Mac、iOS、Android 和 Web 应用程序。你的组织可能会使用 Chime 进行员工和承包商之间的视频会议。它可以控制谁有权限访问其视频会议，以及他们拥有何种访问权限。

Amazon WorkMail 提供电子邮件服务和集成日历，功能类似于 Gmail 和 Google 日历。WorkMail 可以与 Microsoft Outlook 客户端或几乎所有支持 IMAP 协议的电子邮件客户端软件一起使用。

AWS Budgets 旨在帮助小型企业跟踪支出。它们可以设置一个预算，例如每月 $5,000。它们可以跟踪员工或其他利益相关者从企业银行账户中花费的金额及其用途。还有许多其他功能，例如生成详细报告和触发支出异常警报。

AWS SaaS 服务非常用户友好，能够帮助商业客户和消费者完成大量工作。尽管你不能对这些应用进行渗透测试，但很有可能至少一些 AWS SaaS 应用是你公司网络的一部分。例如，如果一家公司将大量数据存储在 Amazon S3 中，那么它也可能使用 Amazon WorkMail 来提供公司邮件服务器。AWS 服务订阅使得公司可以方便地同时使用各种 SaaS、IaaS 和 PaaS 应用，并通过同一账单进行支付。

AWS IaaS 特性

IaaS或基础设施即服务特性是 AWS 中企业控制和责任最大的一部分。与 PaaS 和 SaaS 相比，渗透测试者在这些组件上被允许做的事情更多。但你仍然在亚马逊的基础设施上，因此他们仍然有一些必须遵守的规则。请参阅 AWS 在第二章和第三章中的渗透测试政策，或者你可以在他们的官网上查找(aws.amazon.com/security/penetration-testing/)。

AWS IaaS 可以分为两大类：计算和存储。

计算服务

亚马逊 EC2 是 AWS 的首个计算服务，代表 Amazon Elastic Compute Cloud。EC2 主要由开发自己软件的企业使用，但它们需要大量的计算处理能力来处理数据库、进行科学研究等。

我将总结一些公司的客户评价。

Orangetheory Fitness是美国和加拿大的知名健身连锁品牌。它为客户提供“结合高强度间歇训练的高科技团体健身课程，旨在提高力量和心肺健康水平。”它通过 EC2 部署内部软件，分析每天从成千上万客户那里获取的健身数据。

丰田研究院使用 EC2 来训练机器学习模型。在机器学习中，人工智能通过处理大量数据，并根据从数据中学到的内容不断调整程序。

航空公司是 IBM 大型主机计算机在 1960 年代的最早客户之一。想想看，航空公司必须不断处理的数据——例如票务销售和航班数据。如果航班延误，计算机必须记录航班延误的时间、飞机的位置以及延误的原因。这仅仅是航空公司在日常运营中必须处理的信息的一个例子。国泰航空是一家非常大的亚洲航空公司，提供“覆盖 49 个国家和地区近 200 个目的地”的服务。如今，使用像 Amazon EC2 这样的云服务，是运行大型本地主机计算机的更有效的 21 世纪替代方案。

Netflix 是另一个使用 EC2 的大公司例子。它的证明说，在 COVID-19 大流行初期，更多人开始观看 Netflix。Netflix 称这段时间为“这段前所未有的时期”。假设全球有 2000 万人在某个时间点同时观看 Netflix，而在另一个时间点又有 5000 万人同时观看，那就意味着计算和网络资源需求的巨大增加。因此，Netflix 说它喜欢 EC2，因为它具有良好的可扩展性。

Amazon Elastic Container Service** (ECS**) 是另一种 IaaS 计算解决方案。它是希望寻找必要基础设施来部署容器化应用程序的公司的合适选择，因为使用容器化应用程序是利用云基础设施的常见方式。

在有简化复杂话题的风险下，容器是一种在虚拟机中运行多个组件的应用部署方式。

什么是容器？

容器是一种非常精准的虚拟化部署方式，是一种通过软件模拟计算机硬件的方式。一个容器只包含运行一个更大应用程序的小部分所需的操作系统组件。单个容器的生命周期可能只有几天，甚至几小时。

容器可以根据当前需求动态启动和销毁，这是一种提供可扩展性的方法。容器通常包含一个虚拟化的操作系统和一个更复杂应用的组成部分。但容器需要一个容器化编排解决方案来进行管理和分配硬件资源。亚马逊将 ECS 描述为“一项完全托管的容器编排服务，帮助组织轻松部署、管理和扩展容器化应用程序”。

Docker 是一个容器编排平台。ECS 是一个可以用来部署此类平台的服务。可以把公司软件看作是游泳者，Docker 是水，ECS 是游泳池。如果你的公司使用 Kubernetes 作为容器编排平台，它可以选择 Amazon Elastic Kubernetes Service** (Amazon EKS**) 来执行与 ECS 相似的功能。

AWS Lambda 是 AWS 允许进行渗透测试的另一个服务。它被归类为计算服务。它可以帮助将应用程序部署到亚马逊的基础设施上，作为一个无服务器计算服务，同时根据任何给定时间的需求动态分配资源。开发人员可以在 Lambda 中部署自定义逻辑。例如，如果用户在购物车中留下未结账的商品，可以在三天后发送电子邮件提醒用户，并在七天后将商品从购物车中移除。Lambda 可以运行使用任何第三方库的应用程序，也原生支持 Java、Go、PowerShell、Node.js、C#、Python 和 Ruby。

Amazon CloudFront 是一个 内容分发网络（CDN）。CDN 被定义为一个地理分布广泛的代理服务器及其数据中心网络。CDN 最早在 1990 年代末期被创建，用以支持互联网的快速扩展使用。因此，CDN 可以动态分配网络资源，避免瓶颈——即在传输路径中可能导致性能下降的节点。因此，如果网络的某一部分已经处理了所有可承载的数据，CDN 数据传输路径会利用网络的其他部分来处理更多的数据。YouTube 是一个使用 CDN 的非常流行的流媒体平台示例。根据需求和容量，向 YouTube 用户传输视频的数据中心和服务器是可以变化的。

Amazon CloudFront 支持 WebSocket、边缘终止、Amazon EC2、Amazon S3、弹性负载均衡和 Lambda。

AWS Fargate 是一种无服务器容器计算解决方案。开发人员可以通过 Amazon ECS 部署 Docker 应用，或通过 Amazon EKS 部署 Kubernetes 应用。所有必要的硬件和网络资源都将动态分配。任何给定时刻所需的内存量都会被使用。我将在本章的 AWS PaaS 特性 部分，以及在 第六章、第九章 和 第十二章 中，进一步解释容器化的内容。

AWS Elastic Beanstalk 使用 Amazon 的计算服务和基础设施来部署 Web 应用程序。它原生支持 Java、.NET、Node.js、PHP、Ruby、Python、Go 和 Docker。开发人员可以使用他们已经熟悉的 集成开发环境（IDE），如 Eclipse 和 Visual Studio，通过 Elastic Beanstalk 部署应用程序。

让我们来看看一些用于存储的 IaaS 解决方案。

存储服务

企业可以生成 PB 级别的数据。一个 PB 约等于 1,024 TB。你可能在手机、笔记本电脑和外部硬盘上至少有几 TB 的存储空间。企业通常需要 PB 级别的存储，有时甚至需要 EB！一个 EB 约等于 1,024 PB。任何拥有 PB 或 EB 数据的组织都需要庞大的数据中心来存储这些数据。现在，将这些数据中心托管在云端变得更加可行，因为即使是为数个 PB 存储运行一个数据中心，也可能是一个巨大的麻烦。

Amazon S3 是 AWS 首个存储服务。如果一家公司需要存储大量数据，Amazon S3 是最受欢迎的选择之一。

Snap，制作 Snapchat 的公司表示，它通过 Amazon S3 存储了大约 2 个 Exabyte 的数据。Snap 表示，这相当于超过 1.5 万亿 张照片和视频。所以，这就是一个拥有大量数据的公司如何使用它的例子。但是公司不需要拥有如此庞大的数据量也能使用 Amazon S3。

Amazon 承诺，如果客户按照设计使用 Amazon S3，它将确保用于存储数据的基础设施的安全，并确保客户的数据可以尽快方便地检索。

Amazon S3 的一个常见用途是存储数据湖。数据湖是一个巨大的、集中的结构化和非结构化数据存储库。例如，Google Photos 中每个用户账户里的所有照片可以作为一个数据湖进行收集，容量可达低 exabytes。大科技公司通常使用数据湖来训练机器学习 AI。

另一个使用 Amazon S3 的常见原因是备份数据，无论是大公司还是小公司。AWS 在全球有多个数据中心，企业通过 Amazon S3 存储的数据可能会物理存储在多个大陆上。可能发生大规模的网络攻击、地震或飓风摧毁某个地点的大量计算机。与其冒险将所有公司的重要数据存储在公司本地，不如通过 Amazon S3 将其存储在全球各地。

AWS Backup 集中化并自动化数据备份。它可以与 Amazon S3 配合使用，存储组织的数据，并与 Amazon EC2 配合创建按需备份任务。想象一下，一家公司在多个国家有成千上万的用户和电脑，他们每天为公司做的工作需要备份到公司在 AWS 网络中的数据。大多数员工在早上 9 点到下午 5 点之间工作，但他们可能分布在十几个不同的时区。因此，虽然每天下午 5 点执行备份任务可能是方便的，但下午 5 点在全球各地的时间点不同。这些正是 AWS Backup 旨在处理的复杂数据备份需求。AWS Backup 完全兼容所有 AWS 服务。

如果你的组织拥有大量的软件开发人员和 IT 人员，很有可能可以充分利用 AWS 的 IaaS 服务。AWS IaaS 为组织提供了对其自定义软件的高度控制，而不需要承担维护本地数据中心的弊端。

AWS PaaS 功能

PaaS 或 平台即服务 在安全责任方面介于 IaaS 和 SaaS 之间。AWS 提供了基础设施和平台，但不会像 SaaS 那样提供所有软件。PaaS 服务大多数时候是软件开发工具。作为渗透测试人员，你通常只能在非常有限的条件下对 PaaS 服务进行渗透测试。在 IaaS 中你可以做的很多事情，在 PaaS 中是被禁止的。如果不确定，默认假设你不能做某件事，并查阅 AWS 渗透测试政策（aws.amazon.com/security/penetration-testing/）。在某些情况下，例如网络压力测试，你可以提交表单向 AWS 请求许可。如果 AWS 同意你执行你的计划，那么在确认后才可以进行红队测试。根据 AWS 对你询问的回应，你可能需要调整你的计划。

与 SaaS 一样，即使你不被允许进行某些渗透测试，了解公司如何使用 AWS PaaS 仍然很有帮助。这将帮助你更好地理解你的红队测试以及它们的影响。

AWS 命令行界面(AWS CLI) 基本上就是它的字面意思。就像你可以通过命令行输入命令并按 Enter 来管理自己的电脑一样，AWS 也允许开发人员以类似的方式管理 AWS 服务。开发人员通常喜欢 CLI，因为它给了他们比 图形用户界面(GUI) 更多的控制权。或者，至少，他们可以更快速、更高效地完成他们的工作。AWS CLI 拥有良好的文档和执行 shell 脚本的支持（docs.aws.amazon.com/cli/latest/reference/）。你可以在 Windows、Mac 或 Linux 上安装的应用程序中使用 AWS CLI，或者通过你的网页浏览器使用 AWS CloudShell 访问 AWS CLI。

AWS CDK 是 AWS 的 云开发工具包。软件开发人员熟悉 软件开发工具包(SDKs) 的概念。例如，为了创建在多个操作系统上都能正常运行的 Java 应用程序，你的 IDE（即软件开发应用程序）需要 Java SDK。AWS CDK 在概念上类似，但它是针对云的。当一个组织开发云应用程序并通过 AWS 内部部署时，AWS CDK 非常有用。

因此，AWS CDK 有助于在内部开发的云应用程序中支持云功能。开发人员很可能还需要使用 AWS 工具和 SDK（aws.amazon.com/developer/tools/）来支持他们可能使用的其他技术和平台。AWS 提供了针对 C++、Go、Java、JavaScript、Kotlin、.NET、Node.js、PHP、Ruby、Python、Rust 和 Swift 的 SDK。

AWS Cloud9是 Amazon 自己开发的集成开发环境（IDE），用于使用 AWS CDK 和所需的编程语言特定 SDK 和工具开发云应用程序。Cloud9 直接在网页浏览器中运行，开发者可以在任何兼容的计算机上登录并进行应用开发，无论身处何地。这是因为 Cloud9 通过云存储了所有的工作内容！真是方便。

如果人们制作的是电影和卡通片，而不是基于云的软件应用程序呢？这就是Amazon Nimble Studio的用途。与 Cloud9 类似，用户可以在任何地方进行项目工作。他们还可以与团队中的其他成员合作，共同进行项目开发。

互联网上传输的所有数据都应该使用公钥密码学进行加密。AWS 证书管理器是公钥基础设施（PKI）的主要组成部分，企业需要部署它来通过 SSL 或 TLS 加密他们通过 AWS 部署的应用程序。

用户通常通过他们的 iPhone 和 Android 手机与基于云的应用程序进行交互。软件开发者知道，在没有在特定设备上测试应用程序之前，无法确定其在该设备上的运行效果。

维护一批不同型号的 iPhone 和 Android 手机是件麻烦事。因此，开发者可以使用AWS Device Farm作为替代方案。AWS Device Farm 虚拟化了多种型号的手机和平板设备，开发者可以直接看到他们的应用程序如何运行。通过触摸屏模拟，开发者甚至可以像用户一样与应用进行互动。

AWS Amplify承诺帮助开发者“在几小时内构建全栈的 Web 和移动应用程序”。如果应用程序相对简单，它可能是一个合适的解决方案。例如，奢侈品零售商 Neiman Marcus 使用 AWS Amplify 来创建和管理其在线零售业务。

数据库通常是许多不同类型应用程序的必要组件。根据所需数据库的类型，AWS 提供了多种 PaaS 数据库服务。不同数据库技术的深入讲解超出了本书的范围，但一个有经验的开发团队通常会知道他们需要哪种类型的数据库。

Amazon Aurora支持 MySQL 和 PostgreSQL 数据库。它还与 Amazon S3、AWS 备份、AWS EKS 和许多其他 AWS 服务直接集成。

Amazon 关系型数据库服务（RDS）是为关系型数据库提供的服务。它可以使用 Amazon Aurora 作为引擎，也可以直接使用 MySQL、MariaDB、PostgreSQL、Oracle 和 SQL Server。

Amazon Redshift是用于数据仓库的服务。虽然数据湖可以包含大量的非结构化数据，但数据仓库则用于存储大量精心结构化的数据。它使用 SQL 分析组织的数据仓库中的数据。部署大规模数据分析是 Amazon Redshift 的常见使用场景。

Amazon Lightsail 承诺帮助开发人员通过一系列虚拟服务器“仅需几次点击”即可部署 Web 应用程序。它支持使用 MySQL 或 PostgreSQL 的托管数据库。它在与 Amazon CloudFront 相同的基础设施上提供 CDN 支持。它还通过 Lightsail 容器服务支持 Docker 容器。

AWS CodeDeploy 通过组织的本地服务器或 Amazon EC2、AWS Lambda、AWS Fargate 或 AWS ECS 自动化代码部署。您可以根据需要监控和回滚应用程序，配置和编排部署，并同时维护不同的应用程序版本。

AWS PaaS 服务深受软件开发人员欢迎，它们帮助开发人员创建定制的应用程序，而无需从零开始构建所有组件。如今，应用程序很少是从头开始开发的。

AWS 安全控制和工具

作为一名 AWS 渗透测试员，您需要熟悉 AWS 使用的各种安全控制以及您可以用来进行渗透测试的工具。有关如何使用这些工具的详细信息将在 第五章 和 第六章 中解释，但我会在这里简要介绍这些工具。

安全控制

首先，什么是安全控制，AWS 提供了哪些安全控制？

安全控制是可以帮助防止或减轻网络攻击或其他可能威胁组织数据的组成部分。所有安全威胁都与 CIA（机密性、完整性和可用性）三元组 相关。因此，安全控制的设计旨在帮助防止数据机密性和数据完整性的破坏，同时也可能设计来帮助维护数据的可用性。安全控制可以帮助解决这三个组件中的一个或多个。

安全控制的示例包括杀毒软件、对含有计算机的房间进行物理门锁、入侵检测传感器、监控摄像头、DDoS 缓解解决方案（如 Cloudflare）、入侵预防系统、防火墙、身份验证系统（用户名、密码或双因素认证）、人工安保人员以及门禁卡和令牌。

如果这些工具、系统和机制得到正确使用，它们可以帮助提高公司的网络安全性，但没有任何安全控制能够保证完美的安全性。合理使用的安全控制可以减少网络攻击的频率和负面影响。作为渗透测试员，您通常需要通过模拟网络攻击来测试组织实施这些控制的有效性。在您的渗透测试报告中，您可能需要描述安全控制如何应对您的渗透测试，以及组织如何改进这些控制的使用。有时，您甚至可能与防御性安全专家合作，建议更好的替代方案或升级。

亚马逊为客户提供了许多可以在 AWS 网络中使用的安全控制。与所有安全控制一样，它们只有在正确使用时才能有效！亚马逊负责其基础设施的安全，而您的组织负责自己代码的安全。但亚马逊仍然提供了一些工具，您的组织可以利用这些工具来帮助您管理自己的安全责任。我曾为一家提供机器身份管理服务的公司做过研究，比如 TLS 证书。我发现，许多使用云平台的开发人员并未使用这些平台提供的工具来加密应用程序（venafi.com/blog/want-more-secure-more-effective-cloud-watch-your-machine-identities/）。

不加密从云应用程序传输的数据是一个巨大的安全漏洞！云平台在做正确的事情。他们说，“这是如何使用我们的工具加密您的应用程序，以及如何使用它们的文档。”我不能过分强调，您所在的组织查看亚马逊为 AWS 服务提供的所有安全工具，并阅读他们提供的如何使用这些工具的广泛免费文档，是多么重要。

话虽如此，让我们来看看亚马逊一些最重要的 AWS 安全工具。

AWS 安全中心是所有 Amazon 原生 AWS 安全服务的汇聚点。来自 AWS IAM、Amazon Macie、AWS Health、AWS Systems Manager、Amazon Inspector、AWS 防火墙管理器、Amazon GuardDuty 和 AWS Config 的数据都会在此集中。

安全发现可以在不同的 AWS 安全服务之间进行关联，以呈现完整的安全状况。可以从 AWS 安全中心启动 Amazon Detective，进一步调查安全警报和事件，并且一旦管理员和组织的安全团队熟悉 AWS 安全服务如何协同工作，就可以启动安全编排、自动化和响应（SOAR）工作流，从而提高工作效率。

AWS 身份与访问管理（IAM）提供了一个控制台和系统来管理组织 AWS 账户中的所有用户身份和机器身份。组织通过同一账户使用的所有 AWS 服务都可以通过同一个 AWS IAM 应用程序进行管理。该控制台叫做IAM身份中心。

一些身份可以保持多年不变，例如管理员的用户身份。其他身份可能只需要几天或几周，例如临时云工作负载的机器身份。IAM 可以管理组织的 AWS 服务使用的所有不同类型的身份。在访问管理方面，管理员可以“精细化”定制每个身份的权限和访问。

IAM 还支持服务控制策略，以帮助为每个身份的访问提供保护框架。策略可以帮助限制身份的访问权限。无论哪条规则或设置最为严格，都将胜出。这与最小权限原则相关，最小权限原则是网络安全中的常见概念。最小权限原则意味着用户和其他实体只拥有完成工作所必需的访问权限，不多也不少。这不仅限制了用户因错误可能造成的损害，也限制了网络威胁行为者恶意获取账户访问权限后可能造成的损害。

有效使用 AWS IAM 意味着每次用户或机器登录系统时，都会生成详细的日志，并且每当身份用于访问组织的 AWS 服务时，也会有日志记录。如果安全专业人员怀疑某个威胁行为者可能进行了权限提升攻击（即攻击者获得了账户访问权限并从中提升了自己的权限），AWS IAM 是他们应该首先检查的地方。当检测到异常时，AWS IAM 还会生成警报。

AWS 目录服务 是另一个与 IAM 相关的工具，但它专门用于通过 轻量级目录访问协议（LDAP）管理 Microsoft Active Directory。自从 Windows 2000 服务器版以来，Active Directory 就一直是 Windows 服务器用来管理 Windows 客户端计算机的默认方式。如果您的组织通过 AWS 管理 Windows 计算机，可以使用 AWS 目录服务，并且可以与 AWS IAM 集成。

Amazon GuardDuty 积极监控组织的 AWS 服务，以检测潜在的网络威胁。GuardDuty 会通过 AWS 和第三方威胁情报源，持续接收关于不断变化的网络威胁态势的更新。该系统利用机器学习、行为建模和异常检测的组合来识别潜在威胁。

例如，GuardDuty 可能会了解到，在您组织的应用程序中，某种类型的用户在会话期间会传输一定量的数据。如果某个用户突然下载的数据量是普通用户的 30 倍，这可能会触发异常检测机制。然后，GuardDuty 会将异常数据与系统通过机器学习学到的信息结合起来，以决定这是否是 妥协指示符（IOC）。人类安全专业人员可能会收到警报。有时，安全专业人员需要调查警报，以确定是否真的发生了网络攻击，或者这只是一个误报。就像那辆停着的车上的防盗警报是因为真正的汽车盗窃企图被触发，还是因为一只猫跳上了车？在云安全中，无害的错误也时有发生。

GuardDuty 可以持续监控和分析实例和容器工作负载、用户账户、无服务器应用程序、Amazon S3 资源和数据库。GuardDuty 还可以扫描恶意软件，并为安全警报及其相关事件生成上下文信息。

当安全专业人员需要调查与 GuardDuty 警报相关的活动时，他们可以使用Amazon Detective来帮助。GuardDuty 的安全发现，以及来自 Amazon EKS 审计、VPC 流量和 AWS CloudTrail 的日志，都已集成到该系统中。使用 Detective 不仅可以调查 GuardDuty 警报，还可以调查来自 AWS Security Hub 和集成的安全合作伙伴产品的警报。

Detective 可以从 AWS 管理控制台启动，管理员可以查看他们的警报的可视化图表和上下文信息。

Amazon Inspector是为漏洞管理而设计的。还记得我提到过在第三章中提到的频繁漏洞扫描的重要性吗？一旦建立了漏洞评估和安全强化的历史记录，您的组织就为渗透测试和红队演习做好了准备。之后，在渗透测试和红队演习之间，应该进行频繁的漏洞扫描和修复。

尽管 AWS 中有第三方工具用于漏洞扫描，Amazon Inspector 是原生工具。Inspector 会自动检测新的云工作负载，维护一个经常更新的漏洞数据库，并持续扫描您的整个 AWS 服务。GuardDuty 用于检测潜在威胁，而 Inspector 则用于检测威胁行为者可能利用的漏洞。GuardDuty 像是抓住了正在作案的小偷，而 Inspector 则是检测到小偷可能用来作案的未锁门。但是，像 Detective 一样，Inspector 也会为它检测到的漏洞提供上下文信息。

在第三章中，我讨论了 CVE 数据库，它包括软件、硬件和网络设备中大多数已知安全漏洞的记录。Inspector 工具利用 CVE 数据库和 CVSS 来识别漏洞，并提供关于如何优先修复漏洞的建议。例如，CVSS 评分为 9.1 的关键漏洞应该比 CVSS 评分为 3.8 的低危漏洞更早解决。由于防御安全团队不可能一次性解决所有漏洞，因此对漏洞进行优先级排序至关重要。

除了 CVE 中的已知漏洞，Inspector 还利用了 50 个漏洞情报来源来帮助检测零日漏洞。这些技术没有万无一失，但 Inspector 能够检测一些零日漏洞的能力是一个很大的帮助。也许有一天，您的渗透测试会帮助您的组织发现其他零日漏洞！

AWS CloudTrail 监控用户活动以及在组织 AWS 服务中如何使用API（应用程序编程接口，一种应用程序间交换数据的方式）。可以通过 CloudTrail 事件中的“谁、什么和何时”信息分析未经授权的 API 使用情况。机器学习模型用于检测 API 使用中的异常，日志和审计报告会存储在 Amazon S3 中，方便合规检查。

有一个专用的 AWS CloudTrail 控制台，日志文件也可以通过 Amazon Athena 进行分析。

想象一下贵组织 AWS 网络可能有多大和多复杂。可能存在如此多的不同数据资产，以至于如果没有合适的工具，可能很难全面了解它们。

Amazon Macie利用机器学习和模式匹配技术，查找贵组织 AWS 网络中的任何位置的敏感数据。Amazon Macie 会持续扫描贵组织的所有 Amazon S3 存储。随后，管理员不仅仅收到“发现新敏感数据”的警报，而是通过 Macie 生成互动式数据地图，帮助管理员准确找到敏感数据的位置以及它如何与贵组织网络中的其他部分相连接。

除了持续扫描外，还可以随时启动定向的完整发现扫描。Macie 结果会整合到 AWS 安全中心，方便发现。

AWS 网络防火墙可以配置控制数据如何在贵组织的 AWS 服务之间流动，并且进出这些服务的方式。AWS 防火墙管理器用于根据网络防火墙规则创建策略。这些相同的策略可以应用于贵组织可能已连接的任何虚拟私有云（VPCs）。

过滤入站流量可以防止外部网络威胁进入贵组织的网络。过滤出站流量可以防止敏感数据泄露和恶意软件通信（例如，间谍软件将按键记录数据报告给威胁行为者的指挥与控制服务器），并有助于遵守法规要求。防火墙规则和策略也可以应用于连接贵组织 AWS 服务的客户端设备。

AWS 证书管理器在贵组织的 IAM 和 PKI 中扮演着专业角色。它与公有和私有的 TLS 和 SSL 证书一起工作。通过 AWS 证书管理器，可以部署和管理证书。

AWS 证书管理器可以与贵组织 AWS 网络中的任何证书颁发机构（CAs）一起使用，无论证书是通过 Amazon Trust Services、AWS 私有 CA 还是可以导入的公私有证书。

证书可以通过 Amazon CloudWatch 和 Amazon EventBridge 进行监控。

AWS Secrets Manager监控您组织的所有 AWS 服务中的秘密。秘密用于身份验证和鉴权。秘密包括各种加密密钥、API 密钥、访问令牌以及其他类型的凭证。

秘密可以进行轮换，而不会中断应用程序和服务的正常运行，从而限制凭证泄露的风险。秘密可以与贵组织的日志记录、监控和通知服务集成。AWS Secrets Manager 完全集成了 AWS IAM，以应用权限和策略。

您组织的所有秘密都以集中和高度安全的方式存储。

AWS 审计管理器旨在促进合规性。它还帮助防御性安全专家执行风险评估。“发生坏事的可能性有多大？它会造成什么影响？”

审计框架可以从一组预构建的框架中选择，也可以定制。可以定义具体的范围，并在评估过程中不断收集证据。从中可以识别出安全问题的根本原因。

如您所见，亚马逊为您的组织提供了许多不同的安全服务。您的组织应该尽可能多地使用与您组织工作相关的服务。同时，亚马逊的安全服务彼此集成，以管理网络安全各个方面如何相互影响。

我强烈建议您和贵组织的安全专业人员探索官方的 AWS 安全文档（docs.aws.amazon.com/security/）。它涵盖了我在这里提到的所有服务，以及所有其他 AWS 安全服务和功能。

安全工具

有许多不同的第三方工具可以用于渗透测试。我在这里提到的大部分工具是专门为 AWS 设计的。它们也主要是开源的，这意味着黑客社区可以不断改进这些工具，而不需要特别的许可。

通过合适的工具，您的渗透测试工作中的一些繁琐任务可以实现自动化，但重要的是要理解，渗透测试不仅仅是运行一些工具并查看它们生成的日志。有些渗透测试完全不使用任何自动化工具，所有渗透测试都需要一个聪明的人来像人类网络攻击者一样接近其计算机网络目标。无论是否使用任何自动化工具，都是如此。

渗透测试和红队任务中通常涉及一些事项，如物理安全测试（例如破坏物理锁）和 开源情报(OSINT)。在渗透测试的框架内，OSINT 涉及收集和分析关于目标的公开信息，以及他们可能拥有的任何漏洞。OSINT 侧重于合法收集信息，有时来源于书籍和印刷记录等物理资源，但主要来自于互联网上的在线资源。

许多与计算机网络渗透测试相关的概念同样适用于 AWS 渗透测试，除了共享责任模型以及亚马逊的政策如何限制你能够渗透的内容和方式。然而，很多关于 AWS 渗透测试的信息，特别是针对 AWS 和其他云平台开发的工具，具有很强的针对性。

如何使用这些工具将在 第五章 和 第六章 中详细介绍，但在本节中，我会简要介绍它们并解释它们的功能。

Prowler (github.com/prowler-cloud/prowler) 是一个开源的命令行工具，提供了多种功能，用于渗透测试 AWS、Azure 和 GCP (docs.prowler.cloud/en/latest/)。我将在 第五章 中为你演示如何使用 Prowler 进行 AWS 测试，在 第八章 中演示 Azure，在 第十一章 中演示 GCP。

Prowler 提供了预构建的测试，专门用于评估 CIS、PCI-DSS、ISO27001、GDPR、HIPAA、FFIEC、SOC2、AWS FTR 和 ENS 合规性。你还可以配置 Prowler 根据自定义安全框架进行工作。

Prowler 可以通过多种方式执行。它可以直接从不同类型的工作站 PC 上运行，包括 Linux 或 macOS。也可以在 Windows 上运行，但需要安装 Cygwin。Prowler 还可以通过 AWS CloudShell、Cloud9、Fargate 以及 Docker 和 Kubernetes 容器使用。

Prowler 拥有多个库，包括检查暴露的秘密、暴露的服务，以及检查 AWS 网络中是否有部分内容可以在 Shodan 上被发现的功能。

awspx (github.com/WithSecureLabs/awspx) 是专为 AWS 设计的。通过这个工具，你可以生成关于 AWS 网络中所有数据资源的详细可视化图，及所有访问关系。

你可以绘制从一个资源到另一个资源的可能攻击路径。你可以深入探索哪些操作会影响哪些资源。

awspx 必须从运行 Linux 或 macOS 的 Docker 容器中启动，并且你还需要能够访问 AWS 网络的其他部分。

入侵者 (www.intruder.io/) 是一个带有月度或年度订阅费用的商业漏洞扫描器。它旨在与 OpenVAS 和 Tenable 漏洞扫描平台配合使用。它具有用于扫描各种不同类型网络的工具，并且与 GitHub、Slack、Jira 以及许多不同的应用程序集成。它还包括 AWS、Azure 和 GCP 的集成，这与我们相关。

就 AWS 而言，入侵者可以运行自动化扫描，检查 AWS 的不安全配置，您的 AWS 是否公开了机密信息以及在哪里展示了服务，以及一个经常更新的库以检查认证和代码注入漏洞。

入侵者可以执行外部和网络扫描，并且还有用于扫描 Web 应用程序的工具。

Acunetix (www.acunetix.com/vulnerability-scanner/) 也是一个专门用于 Web 应用程序的全功能漏洞扫描器。AWS 仅是其可以使用的许多不同技术之一。

根据其开发者 Invicti，Acunetix 是第一个 Web 安全扫描器，自 2005 年以来一直在发展。 Invicti 声称其专有的 Smart Scan 算法可以在扫描的前 20% 中检测系统中 80% 的漏洞。

它具有扫描 AWS Web 应用程序防火墙的功能。它还具有项目管理系统集成，可能对您的组织有用。

与入侵者不同，Acunetix 可以作为独立的漏洞扫描器运行。它可以在 Linux、macOS 或 Windows 上本地运行，也可以集成到 OpenVAS 中。扫描可以在内部和外部执行。如果您请求报价，可以获得定价信息。

Rhino Security Labs 的 Buckethead (github.com/RhinoSecurityLabs/Security-Research/blob/master/tools/aws-pentest-tools/s3/buckethead.py) 是一个简单的开源工具，以 Python 脚本形式运行。它旨在扫描您组织的亚马逊 S3 存储桶，查找漏洞以及是否可以在未经授权情况下外部上传文件。

我看了 Python 脚本（github.com/RhinoSecurityLabs/Security-Research/blob/master/tools/aws-pentest-tools/s3/buckethead.py）。它只有 258 行代码。因此，您只需要一个命令行实用程序，能够运行 Python，并连接到您组织的 AWS 网络。

Rhino Security Labs 的 Buckethead 非常棒的一点是，它可以在不留下任何痕迹的情况下发现严重的漏洞。它可能不会触发您组织的安全控制。

GitHub 用户 toniblyx 参与了 Prowler 的开发。他们在 GitHub 上还拥有一系列其他有用的 AWS 渗透测试工具。虽然他们并未亲自开发所有这些工具，但它们都是他们“武器库”的一部分。以下是我最喜欢的一些工具（可以在 github.com/toniblyx/my-arsenal-of-aws-security-tools#offensive 中找到）：

• WeirdAAL (github.com/carnal0wnage/weirdAAL) 是一个 AWS 攻击库。没错，README 文件中提到了 “Weird Al” Yankovic。它包含以下 AWS 组件的模块：

  • AWS Lambda

  • CloudFront

  • CloudTrail

  • CloudWatch

  • Config

  • Data Pipeline

  • Database (local)

  • DynamoDB

  • EC2

  • ECR

  • Elastic Beanstalk

  • EMR

  • Firehose

  • IAM

  • Lightsail

  • OpsWorks

  • RDS

  • Recon

  • S3

  • SES

  • SQS

• Pacu (github.com/RhinoSecurityLabs/pacu) 是 Rhino Security Labs 提供的一个完整的开源 AWS 渗透测试框架。它可以从 Docker 容器中运行，也可以通过支持 Python3.7+ 和 pip3 的 Linux 或 macOS 客户端通过命令行直接运行。它包含 36 个插件模块，用于在 AWS 中执行各种模拟攻击，包括权限提升、数据外泄、日志篡改、服务利用和枚举。每个模块都需要你组织的 AWS 访问密钥才能运行其测试。

  Pacu 设计时考虑到了可扩展性，并鼓励其他开发者通过新模块和改进为项目做出贡献。

• Cred Scanner (github.com/disruptops/cred_scanner) 是一款可以通过命令行运行的 Python 程序，支持 Python 3.6。它的功能很简单：查找文件中的 AWS 凭证。

• CloudFrunt (github.com/MindPointGroup/cloudfrunt) 是另一个有用的 Python 命令行工具。它旨在查找 AWS CloudFront 中的配置错误。

• Redboto (github.com/ihamburglar/Redboto) 是一组旨在帮助进行 AWS 红队演习的脚本集合。它是一系列可以通过 pip 安装的 Python 文件。

  这个特定的脚本可能是最有用的：

  "getEC2Files.py
  

  它无疑是这组脚本中最复杂的。这个脚本与 describeInstances.py 配合使用效果最佳，后者可以提供关于 EC2 实例的元数据。使用 API 密钥，你可以从 EC2 实例中提取文件。该脚本会对目标卷进行快照，启动一个实例并将其附加到卷上，然后启动并创建一个 S3 存储桶。当实例启动完成后，它会加密并将选定的文件复制到 S3 存储桶中，脚本从 S3 存储桶中下载并解密这些文件。最后，脚本会拆除它所创建的基础设施，只留下日志（如果启用的话）。

所以，就是这样！最有用的 AWS 渗透测试工具从复杂的商业漏洞扫描器（需要月度订阅费）到简单的开源 Python 脚本不等。我期待在接下来的章节中详细解释如何使用这些工具。

总结

AWS 是目前最流行的云平台之一。作为一名云渗透测试员，你几乎可以肯定会需要使用 AWS 的应用程序和服务。

AWS 包括了许多自己的安全控制和工具，而你的组织可能在使用，也可能没有使用它们。它理应使用这些工具，因为实施亚马逊自己的安全控制是一个至关重要的网络安全基线，可以防止许多网络攻击。

一些 AWS 的第一方安全应用程序包括 Amazon Inspector、AWS Security Hub 和 Amazon GuardDuty。

还有一些第三方脚本和工具可以帮助你在遵守亚马逊政策的前提下进行漏洞扫描和渗透测试。它们包括 Prowler、Pacu、CloudFront 等许多工具。

理解亚马逊的渗透测试政策和规则并遵守它们非常重要。亚马逊拥有所有 AWS 基础设施。所以，即使你正在与自己组织的 AWS 网络合作，你实际上是在亚马逊的“家”里。你需要做一个体贴的客人。

在下一章中，我将更详细地介绍 AWS 的安全控制。我还会带你实际使用 Prowler 和 Pacu，并附有视频。你可以设置自己的 AWS 实例来亲自尝试这些工具。

进一步阅读

要了解更多本章涉及的主题，你可以访问以下链接：

• AWS 中的 CLI（命令行界面）：aws.amazon.com/cli/

• AWS 安全产品和 服务：aws.amazon.com/products/security/

• Prowler 文档：docs.prowler.cloud

第五章：通过无服务器应用程序和工具进行 AWS 渗透测试。

到目前为止，你是一个非常耐心的读者。理解概念和理论非常重要，尤其是在你开始学习如何进行渗透测试的实际操作之前。你现在已经到达了本书的第一章，在这里我们不仅仅是理论探讨，还将把我们的知识付诸实践。

本章介绍了如何使用 Amazon Web Services** (AWS**) 官方安全工具，逐步检查安全配置并进行漏洞评估，配置最流行的第三方 AWS 渗透测试工具。我们还将讨论渗透测试的步骤，包括查找凭证、列举 AWS 服务、进行漏洞扫描，并使用 Prowler 和 Pacu 发现暴露的服务。

本章包括以下主要内容：

• 如何获取 AWS 网络。

• 使用 AWS PowerShell 和 AWS CLI。

• 探索 AWS 原生安全工具。

• 安装和准备 AWS 渗透测试工具。

• 利用 AWS 应用程序

让我们开始吧！

技术要求。

我们将与微软的基础设施一起工作。大规模的 Azure 数据中心将承担本章练习的大部分计算处理工作，因此，幸运的是，你不需要拥有顶级工作站。你将需要以下设备：

• 一款网页浏览器。

• 一台台式电脑或笔记本电脑。

• 一部安卓或 iPhone 智能手机。

• 一条可靠的互联网连接。

查看以下视频以查看实际操作中的代码：bit.ly/3Qo5Ewg

如何获取 AWS 网络。

在我们准备渗透测试 AWS 服务之前，我们需要有 AWS 服务来进行渗透测试！你可以做两件事：

• 你可以从你工作的组织获得 AWS 凭证。

• 或者，如果你只是刚开始学习，还没有为某个组织工作，你可以免费设置自己的 AWS 实例。

亚马逊通过免费服务和试用让人们在其基础设施上做很多事情。

请记住，无论是使用组织的付费 AWS 实例，还是自己设置的免费 AWS 实例，相同的 AWS 渗透测试政策都适用。详情请参考 第二章 和 第三章。你还可以在这里查看 AWS 的渗透测试政策：github.com/prowler-cloud/prowler。

如果你需要设置免费的 AWS 实例，我会带你一步步完成设置过程。按照以下步骤操作：

1. 在浏览器中访问 aws.amazon.com/。

2. 点击网页右上角的橙色按钮，上面写着 创建 AWS 账户。

3. 在 Root 用户电子邮件地址 一栏中，输入你能可靠访问的电子邮件地址。我建议你使用你的主个人电子邮件账户，这样即使换工作，你仍能保留 AWS 账户。

4. 在AWS 账户名称下，输入一个对你来说容易记住的唯一名称。确保它不是你在工作公司面前会感到尴尬的名称。同时，确保你的账户名称不会泄露你的密码或其他敏感数据。不要在其中放入你的社会安全号码！

5. 一封验证码将发送到你使用的电子邮件地址。检查你的电子邮件以获取验证码，输入到表单字段中，然后点击验证。快点操作——验证码将在 10 分钟内过期！

6. 创建一个新密码，并在两个表单字段中输入该密码以进行验证。你的密码应该既长又复杂。我建议使用密码管理器生成一个安全的密码并由其帮你记住。

7. 在如何计划使用 AWS？下，选择个人。在表单的其余部分输入你的全名、电话号码和邮寄地址。确保电话号码与你的智能手机关联，以防你需要使用它进行多因素认证（MFA）。勾选我已阅读并同意 AWS 客户协议的条款框，并点击继续。

8. 你将被要求输入你的信用卡号码。如果你尝试做一些会导致信用卡收费的操作，AWS 会提醒你，而且你可以随时在你的账户的账单部分查看是否已经被收费。

注意

本章中的所有教程都不会产生信用卡费用，但我将在本章演示的一些服务（如 Amazon Inspector）有有限的免费试用期。如果你不想被收费，记得在免费试用期结束之前取消 AWS 账户。详情请参见AWS 免费套餐指南（aws.amazon.com/free/）。

一旦你设置了 AWS 账户或获得了对你组织 AWS 账户的访问权限，你就可以继续进行本章的其他内容。

使用 AWS PowerShell 和 AWS CLI

本章中的许多练习可以直接通过 AWS CloudShell 执行。只要你拥有一台带有互联网连接和网页浏览器的 Windows、Linux 或 Mac 电脑，就可以轻松访问 AWS CloudShell。你的电脑无需具备工作站或游戏 PC 的硬件规格，因为所有虚拟化和计算都由亚马逊的基础设施进行。但是我强烈建议你使用某种台式机或笔记本电脑，而不是手机或平板电脑。AWS CloudShell 的用户界面在配备物理键盘的设备上运行最好。

当你在网页浏览器中登录到你的 AWS 账户时，可以随时通过点击屏幕顶部的图标来访问 AWS CloudShell。AWS CloudShell 图标看起来像一个带有命令提示符的小方块：

图 5.1 – AWS CloudShell 图标

如果你希望在没有 AWS CloudShell 的情况下访问 AWS CLI，你可以从 GitHub 安装 aws-shell 应用程序 (github.com/awslabs/aws-shell)。它需要 Bourne Again Shell** (Bash**) 命令行，因此 Linux 操作系统或 macOS 是最适合的选择。

注意

本书中的所有演示都使用 CloudShell。但是，如果你更倾向于安装 AWS CLI 桌面应用程序，可以在这里找到：aws.amazon.com/cli/。

这里有一份可以在 AWS CloudShell 命令提示符下使用的命令指南。这些命令也可以直接在 AWS CLI 应用程序中使用。

无论你是在 AWS CloudShell 还是 AWS CLI 应用程序中，你应该始终使用以下命令检查你安装的是哪个命令行：

aws –-version

命令行将显示你的操作系统信息（是在 AWS 上，而不是你自己的电脑上）、已安装的 Python 版本等等。输出可能像这样，但根据你安装的内容可能会有所不同：

aws-cli/2.10.0 Python/3.11.2 Linux/4.14.133-113.105.amzn2.x86_64 botocore/1.13

如果你安装了 Linux 或 Mac 系统，可以使用 Bash 命令。我提到的这些 Bash 命令也适用于 Z Shell** (Zsh**)，这是 Mac 的默认 shell。如果你在 AWS 中安装了 Windows，你可以使用 Windows PowerShell 命令提示符命令。Bash、Zsh 和 Windows PowerShell 都内置于 AWS CloudShell 和独立的 AWS CLI 应用程序中，你不需要安装额外的东西来使用这些命令。

Bash 命令

这里有一些方便的 Bash（和 Zsh）命令：

• 这个命令会列出当前目录中的所有文件和文件夹：

  • ls

• 这个命令会改变你当前打开的目录。不要使用括号！在该位置输入目录的路径：

  • cd <插入目录名称>

• 这个命令会显示你当前所在的目录，以防你迷失方向：

  • pwd

• 如果你不确定某个命令的作用，可以使用这个命令查看。不要使用括号！

  • man <**命令名称>**

• 这个方便的命令会让你退出已执行的 shell 脚本、SSH 会话，或者让你退出 AWS PowerShell 或 AWS CLI：

  • exit

• 获取关于正在运行的进程的信息，包括它们的 进程ID（PID）：

  • ps

• 如果你想停止某个进程，并且知道它的 PID，可以使用此命令：

  • kill <**进程 ID>**

• 如果你忘记了在会话中使用过哪些命令，这个命令会显示给你：

  • history

• 移动或重命名一个目录：

  • mv <当前目录名称> <新目录名称>

• 创建一个新目录：

  • mkdir <新目录名称>

• 创建一个新文件，并指定文件名：

  • touch <**新文件名>**

• 阅读文件内容。这个命令仅适用于文本文件和脚本，不能用于媒体文件等非文本内容：

  • less <文件名>

• 如果你需要执行需要 root 权限的操作，请在命令前加上 sudo。之后你可能需要输入密码：

  • sudo <命令>

• 使用这些命令来安装你仓库中的程序，或者通过 pip 包管理器安装 Python 程序：

  • sudo install <program name> <in repository>

  • sudo pip3 install <program name>

  • sudo <name of package manager here, such as apt or yum> install <program name>

接下来让我们看一些 PowerShell 命令。

PowerShell 命令

如果你的 AWS 服务器运行的是 Windows，下面是一些你可以使用的 Windows PowerShell 命令。只要你的 AWS 实例运行 Windows，这些命令在 AWS PowerShell 和 AWS CLI 应用程序中都可以使用：

• 这可能是最重要的 Windows 命令，它会显示其他可用命令及其功能：

  • help

• 就像在 Bash（和 Zsh）中一样，这个命令会更改你当前打开的目录：

  • cd <directory name>

• 在 PowerShell 中创建新目录的命令与 Bash 和 Zsh 中相同：

  • mkdir <new directory name>

• 该命令将文件移动到新位置：

  • move <file or directory> <destination directory>

• 该命令更改当前打开的目录：

  • chdir <directory>

• 查看正在运行的进程及其 PID：

  • ps

• 获取关于当前打开目录的信息：

  • pwd

• 删除文件或目录：

  • rm <filename>

  • rmdir <directory name>

• 显示文件的一部分内容。这个命令最适合用在文本文件或脚本文件上：

  • cat <filename>

• 创建新文件或目录：

  • ni <new filename or new directory name>

  如果你创建了一个新文件，文件可能没有内容。然而，你可以在文本编辑器或 集成开发环境（IDE）中打开文件，并在其中创建内容。

现在我们已经了解了 AWS 和 AWS CLI，接下来是时候学习 AWS 提供的工具，以帮助我们进行网络安全工作了。

探索 AWS 原生安全工具

AWS 为你提供了两个本地工具，这些工具对于渗透测试人员特别有用：AWS Security Hub 和 Amazon Inspector。

首先，让我们看看 AWS Security Hub。

AWS Security Hub

AWS Security Hub 是一种简便的方式，可以查看所有 AWS 安全配置、AWS 原生安全扫描报告以及安全警报。它能够结合来自 Amazon GuardDuty、Amazon Inspector、Amazon Macie 和 AWS Network Firewall 的数据。

如果你的 AWS 实例出现任何重大安全问题，AWS Security Hub 会通知你！你可以在渗透测试报告中提到在 AWS Security Hub 中发现的数据。但是，通过使用第三方应用程序进行漏洞扫描和渗透测试，你可能会发现更多的漏洞。我建议同时使用 AWS 提供的工具和第三方工具，以便获得关于 AWS 实例安全状态的最全面数据。

让我们第一次来看一下 AWS Security Hub。按照以下步骤操作：

1. 登录到您的 AWS 账户后，您可以在顶部搜索栏中搜索AWS 安全中心来找到它。它位于您启动 AWS CloudShell 的图标左侧。如果您有免费套餐 AWS 账户，可以注册 30 天的免费试用。或者，您也可以在服务标签下找到 AWS 安全中心。

警告！

如果这是您自己的免费 AWS 教育账户，请务必在免费试用期结束之前进入账单界面取消 AWS 安全中心。

1. 在右侧，点击前往安全中心。如果这是首次设置，您需要选择启用 AWS Config。接下来，在显示为您可以通过 AWS Config 控制台手动启用资源记录的地方，点击AWS Config控制台链接。

2. 接下来，您将进入 AWS Config 页面。在右侧，点击一键设置：

图 5.2 – 一键设置选项

审核默认设置后，点击右下角的橙色确认按钮。将为您创建一个Amazon 简单存储服务（S3）存储桶。此过程可能需要一些时间。

1. 当存储桶创建完成后，您将被带到主AWS 安全中心仪表板。现在，我们可以保持所有默认设置不变。请打开您的网页浏览器标签，点击启用 AWS安全中心。

2. 在安全标准部分，保持默认选项：

   • 启用 AWS 基础安全最佳实践 v1.0.0

   • 启用 CIS AWS 基础基准 v1.2.0

图 5.3 – AWS 安全中心设置页面

1. 如果这是您所在公司使用的 AWS 网络，他们可能有自己的安全基准需要遵守。但是，如果您只是使用免费 AWS 账户进行个人学习，可以保持默认基准设置不变。因此，也请保持AWS 集成和委托管理员（默认设置是没有集成和没有额外的委托管理员）不变。点击橙色按钮，选择启用安全中心。

2. 现在，您应该可以看到AWS 安全中心仪表板。

图 5.4 – AWS 安全中心仪表板

现在您应该在概览页面。到目前为止尚未运行任何扫描，因此所有可能的信息源，如发现和见解，都没有数据可显示。

1. 但我发现了一些有趣的内容。请前往左侧菜单，点击发现。

   看起来当我启用了 AWS Config 后，系统已经执行了一些安全检查！大约有十几个检查未通过，严重性评级为低、中和严重。以下是一个失败的安全检查示例。您的结果可能会有所不同：

   MEDIUM    NEW    ACTIVE    us-east-2    489`****`(my account ID)    AWS Security Hub    Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
   

2. 现在，点击左侧菜单中的安全标准。

3. 我找到一个AWS 基础安全最佳实践 v1.0.0的框。点击了查看结果，结果显示有很多检查未通过。这里有一个例子：

   CRITICAL    CodeBuild.1    CodeBuild GitHub or Bitbucket source repository URLs should use OAuth
   

所以，AWS 安全中心一开始就会为你提供很多非常有用的漏洞信息。你完全可以在渗透测试报告中提到这些细节，但我建议你还可以运行一些第三方工具，正如我将在本章后面描述的那样。多个工具可以发现更多漏洞，如果多个工具发现了相同的漏洞，那也是有用的信息。记住，你的渗透测试报告不应该只是日志的输出。你需要用自己的话描述这些漏洞如何影响你的组织，以及你对如何修复它们的建议。

现在，让我们继续了解 Amazon Inspector。

Amazon Inspector

Amazon Inspector 是 AWS 内置的漏洞扫描工具。它能够非常好地扫描你的 AWS 应用程序，找出已知的漏洞。它还可以发现 AWS 网络中暴露给公共互联网的那些不安全的部分。我建议在使用第三方应用程序进行扫描之前，先用 Amazon Inspector 进行扫描。

我将一步步展示如何使用 Amazon Inspector：

1. 我通过在顶部搜索栏中搜索Inspector找到了 Amazon Inspector。如果你还没有设置 Amazon Inspector，右上角会有一个白色框显示开始使用 Inspector并提供 15 天的试用期。点击橙色的开始使用按钮。如果你只是想在免费的 AWS 账户中玩玩，记得在 15 天试用期结束前取消 Amazon Inspector。

2. 如果你只是尝试在免费账户中进行测试，那么可以保持委派管理员和服务权限的默认设置。点击右下角的激活 Inspector按钮。激活过程可能需要几分钟。

3. 激活后，你会看到顶部显示概览的页面。如果点击右上角的管理所有账户按钮，你可以在你的Amazon 弹性计算云（Amazon EC2）、Amazon 弹性容器注册表（Amazon ECR）和 AWS Lambda 实例中也启用 Amazon Inspector。

4. 顶部有一个绿色的通知，写着欢迎使用 Inspector，您的第一次扫描正在进行中。所以我们将等待自动扫描完成，然后查看结果。我的第一次扫描大约花了半个小时。

   如果你在等待时感到不耐烦，实际上可以做一些有趣的事情。看看左侧的菜单，点击视频教程。那里有一个页面，包含了许多嵌入的 YouTube 视频，如新亚马逊 Inspector 简介和Amazon Inspector 用于 AWS Lambda 工作负载。我建议你观看所有这些视频！你学到的信息将帮助你作为渗透测试员更有效地使用 Amazon Inspector。

5. 扫描完成后，点击左侧菜单中的Findings。你可以通过点击顶部的标签按漏洞、账户、实例等分类排序你的发现。每个发现都会显示其常见漏洞评分系统（CVSS）严重性评级，例如CRITICAL、HIGH或MEDIUM。每个发现的常见漏洞与暴露（CVE）编号也会显示，你可以点击每个 CVE 数据库链接查看更多信息。

如你所见，Amazon Inspector 是一个非常有用的渗透测试 AWS 的工具。我非常欣赏 Inspector 展示的 CVE 数据。这些是非常有用的细节，可以放入渗透测试报告中。

现在，我们来看看一些第三方工具。我建议在进行渗透测试和红队任务时，使用多种工具以确保全面性。在这些情况下，使用更多工具通常更好，因为你可以获得更多的信息。

安装和准备 AWS 渗透测试工具

让我们安装并准备好在下一节中使用的第三方软件。

重要说明

如果在安装这些工具时遇到磁盘空间问题，你可能需要删除旧文件以腾出空间。文件可以通过本章前面提到的 Bash 命令删除。你可能还需要部署一个新的 AWS EC2 实例。有关更多信息，请参见官方 AWS 文档：docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html。

尽可能地，我将使用 AWS CloudShell 来安装应用程序。

首先，让我们从 Prowler 开始。

Prowler

Prowler 是一个云平台漏洞扫描器。Prowler 可以根据互联网安全中心（CIS）、国家标准与技术研究院（NIST）800、NIST网络安全框架（CSF）、网络安全与基础设施安全局（CISA）、联邦风险与授权管理（FedRAMP）、支付卡行业数据安全标准（PCI-DSS）、通用数据保护条例（GDPR）、健康保险可携性与责任法案（HIPAA）以及其他安全标准扫描 AWS 的漏洞和安全配置错误。

通过在浏览器中登录 AWS 账户，打开 AWS CloudShell（一个带有命令提示符的小方框图标）。

在我们安装 Prowler 之前，你可能需要将 AWS CloudShell 中的 Python 版本更新为 Python 3.9。你可以使用接下来的命令更新 Python。

首先，检查你已经安装的 Python 版本：

python --version

如果显示 Python 3.9，那么你就可以继续了。否则，执行以下操作：

sudo apt update
sudo apt-get install python3.9

安装过程完成后，你可以通过以下命令验证它是否正常工作：

python --version

以下是需要输入的命令：

• 这使用yum安装程序安装一些 Prowler 依赖项。你可能需要输入你的 AWS 账户密码：

  sudo yum -y install gcc openssl-devel bzip2-devel libffi-devel
  

• 这将为 Python 3.9 下载包，这是通过pip安装 Prowler 的一个依赖项：

  wget https://www.python.org/ftp/python/3.9.16/Python-3.9.16.tgz
  

• 这将安装 Python 包，配置它，并设置“启用优化”。有时候，命令执行可能需要几分钟：

注意

小心确保--是输入为两个连字符，中间没有空格。有些浏览器可能会将--转换为一个长破折号–，这会导致错误。

tar zxf Python-3.9.16.tgz
cd Python-3.9.16/
./configure --enable-optimizations
sudo make altinstall
python3.9 –-version
cd

现在，你已经回到了主目录。

• 这将从pip安装 Prowler：

  pip3.9 install prowler
  prowler -v
  

恭喜！稍后，当我们实际使用 Prowler 时，你可以通过点击 AWS PowerShell 屏幕右上角的操作，找到你的渗透测试和漏洞评估的输出。然后，去下载文件并打开 CSV 文件。它将有一个类似下面的路径和文件名：

/home/cloudshell-user/output/prowler-output-<a bunch of numbers>.csv

如果操作 | 下载文件不起作用，你可能需要在 Google Chrome 中打开 AWS CloudShell。如果你没有 Chrome，可以访问 www.google.com/chrome/ 安装它。希望你已经将 AWS 根账户的电子邮件地址和密码安全记录，以便在需要时切换浏览器！

现在，让我们安装 Pacu。

Pacu

Pacu 是一个 AWS 渗透测试应用。如果你已经按照我的指示安装了 Prowler，那么你已经安装了 Python。这太好了，因为我们可以使用pip来安装 Pacu，方法如下：

pip3 install  pip

这将准备pip安装程序：

pip3 install  pacu

这将安装 Pacu。现在，让我们执行它！

Pacu

Cred Scanner

现在，让我们安装 Cred Scanner。它是一个非常简单的脚本，用于扫描 AWS 实例中的敏感凭证文件。你绝对不希望密码等信息暴露给网络攻击者！请按照以下步骤操作：

1. 首先，打开 GitHub 上的 Python 脚本，网址是：github.com/disruptops/cred_scanner/blob/master/cred_scanner.py。

2. 复制整个 Python 脚本。将其粘贴到文本编辑器中，并确保文件保存为cred_scanner.py。

3. 接下来，我们需要将脚本从本地计算机上传到 AWS 服务器。点击 AWS CloudShell 屏幕右上角的操作，然后转到上传文件，点击选择文件，找到你保存在本地计算机上的 cred_scanner.py 文件，打开它。

4. 访问 github.com/disruptops/cred_scanner/blob/master/requirements.txt，并做类似的操作。只需要一行代码，上面写着点击。但你仍然需要将其保存为名为requirements.txt的文件。然后，像上传cred_scanner.py一样，将该文件上传到 AWS CloudShell。

5. 现在，回到命令行！确保 Cred Scanner 已具备其要求，输入以下内容：

   pip install -r ./requirements.txt
   

6. 然后，我们可以执行 Python 脚本：

   python cred_scanner.py
   

   继续进行 Cred Scanner 操作。下面是扫描的一个示例：

图 5.5 – Cred Scanner 扫描输出

或者，您可以通过克隆其 GitHub 仓库来安装 Cred Scanner。要克隆仓库，请按照 GitHub 文档中的说明操作：docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository。

您需要克隆的代码可以在此找到：

github.com/disruptops/cred_scanner

然后，运行以下命令：

pip install -r ./requirements.txt

使用 Cred Scanner 非常简单，我将直接展示如何进行扫描，而不是在下节中解释：

• 这将显示 Cred Scanner 的选项：

  python cred_scanner.py –-help
  

• 这将显示您在命令行中打开的目录中的密钥：

  python cred_scanner.py –-secret
  

• 这将在另一个目录中运行 Cred Scanner：

  python cred_scanner.py –-path <directory path>
  

或者，您可以使用cd命令切换到您希望在其中运行 Cred Scanner 的目录。

CloudFrunt

CloudFrunt 是 MindPoint Group 开发的一个脚本，用于识别 AWS CloudFront 中的配置错误。

由于 CloudFrunt 的简单性，我将在这里同时展示安装和执行方法。记住——您必须在 AWS 服务器上配置 AWS CloudFront，才能使 CloudFrunt 正常工作。

在 AWS CloudShell 命令行中，下载 CloudFrunt 脚本：

git clone --recursive https://github.com/MindPointGroup/cloudfrunt

以下是结果：

图 5.6 – CloudFrunt 安装

然后，安装它及其依赖项：

pip install -r requirements.txt

假设我们已经安装了 CloudFrunt，现在开始使用它吧！

以下是使用cloudfrunt.py的命令结构：

python cloudfrunt.py -o cloudfrunt.com.s3-website-us-east-1.amazonaws.com -i S3-cloudfrunt -l list.txt

请勿输入该命令。您需要根据自己的情况修改它。-<letter> 中的内容被称为参数。

将cloudfrunt.com.s3-website-us-east-1.amazonaws.com替换为您正在扫描的域名。将S3-cloudfrunt替换为您要添加的漏洞域名的源。将list.txt替换为一个包含要扫描的域名的文本文件。

这是如何显示使用 CloudFrunt 的指南：

python cloudfrunt.py –-help

这将显示如下内容：

图 5.7 – CloudFrunt 帮助屏幕

使用此指南来执行 CloudFrunt。如果在执行 CloudFrunt 时使用-s或--save，您可以通过单击 AWS PowerShell 屏幕右上角的操作来找到您的 CloudFrunt 扫描结果。然后，转到下载文件并打开文本文件。文件将包含如下位置和文件名：

/home/cloudshell-user/output/results.txt

接下来是 Redboto！

Redboto

我将带您安装的最后一个第三方工具是 Redboto Python 脚本集合。这些脚本执行对 AWS API 的红队操作。首先，让我们安装其前置条件：

pip install cryptography boto3 texttable

接下来，在另一个浏览器标签页中打开其 GitHub 集合：

github.com/ihamburglar/Redboto

Redboto 是一组脚本。打开您想尝试的每个脚本的每个网页。记住我如何指导您从 GitHub 复制脚本，将脚本粘贴到文本编辑器中，使用其特定的文件名保存它，然后在 AWS CloudShell Web UI 中使用 Actions** | **Upload file** | **Select file 上传文件？对于您想使用的每个 Redboto 脚本，都要这样做。Redboto GitHub 存储库提供了每个脚本的说明。然后，在您上传文件的目录中，您可以像这样执行每个脚本：

python checkAWSKey.py
python describeUserData.py
python runSSMShellScript.py
python <insert a different Reboto Python script name here>

之后，您应该能够在 AWS CloudShell UI 的 Actions** | **Download File 中找到此目录中的输出文件：

/home/cloudshell-user/output/

请牢记该目录，因为如果本章中我提供给您的教程是您的劳动成果，那么该目录中的内容就是您的劳动成果。但您不仅仅会将该目录中的输出提供给您的渗透测试客户。您将使用输出文件作为您为客户编写渗透测试报告时部署的信息。成为一名优秀的渗透测试人员不仅仅是执行脚本和共享输出和其他日志。您的工作是解释这些日志，并帮助客户和防御安全团队理解它们，并利用漏洞信息来加固客户的 AWS 网络和应用程序安全。

好了！现在是时候在 Prowler 和 Pacu 中进行一些通用的渗透测试和漏洞扫描活动了。

利用 AWS 应用程序

现在我们已经安装了一些渗透测试应用程序并运行了一些简单的脚本，让我们深入了解如何利用 Prowler 和 Pacu 进行 AWS 渗透测试。

Prowler

首先，让我们在 Prowler 中进行一些渗透测试和漏洞扫描活动。

准备好您的 AWS 凭据。您可以通过从 Web 浏览器登录到您的 AWS 帐户来验证它们。在顶部菜单栏中，查看最右边的下拉菜单与您的用户名。单击 Security credentials 导航到正确的 AWS Identity and Access Management** (IAM**) 页面。顶部应显示 My security credentials (root user)。记下您的 AWS 帐户 ID、访问密钥 ID 和秘密访问密钥。然后，按照以下步骤操作：

1. 现在，让我们再次打开 AWS CloudShell。输入此命令以配置您的密钥：

   aws configure
   

2. 在 AWS_ACCESS_KEY_ID= 字段中，粘贴您生成的密钥 ID 并按 Enter。其它字段也按 Enter，我们将留空它们。

注意

如果您希望每次 AWS 配置发生时为您的帐户节省 0.0003 美元的费用，您可以使用以下方式配置 AWS：

export AWS_ACCESS_KEY_ID=your_access_key_id

export AWS_SECRET_ACCESS_KEY=your_secret_access_key)（译者注：需要将 your_secret_access_key 替换成你的秘密访问密钥）

1. 执行 Prowler：

   prowler
   

   如果这不起作用，请按照本章前面的说明再次安装 Prowler。

   默认情况下，您的 Prowler 扫描输出应该在这附近，文件名类似于：

   /home/cloudshell-user/output/prowler-output-<a bunch of 
   numbers>.csv
   

Prowler 命令本身将执行一个默认扫描，显示你所拥有的 AWS 服务（如 EC2、IAM 等），扫描是否通过，及每个服务根据 CVSS 评分的严重、高、中、低漏洞数量。它将执行几十项检查，如check121、check122、check23和check24。它可能会将各种信息打印到屏幕上（并写入 CSV 日志），这些信息对你的渗透测试报告非常有用，例如以下内容：

[check25] Ensure AWS Config is enabled in all regions – configservice [Medium]
FAIL! au-north-1: AWS Config recorder disabled

在此示例中，check25扫描了你的所有 AWS 服务，以查看它们是否启用了 AWS Config。单独启用 AWS Config 并不能保证安全性，但必须启用它才能安全地配置，就像你的车必须安装安全带一样。安全带的存在并不能保证司机和乘客会系上安全带，但如果它们根本没有安装，司机和乘客就无法使用安全带。

注意

你可能会遇到 AWS 密钥访问问题。如果是这样，请访问console.aws.amazon.com/kms查看AWS 密钥管理服务（AWS KMS），并在创建新密钥时记录下你的密钥访问密码。你也可以在 AWS 文档中获取故障排除帮助，链接如下：docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html 和 docs.aws.amazon.com/kms/latest/developerguide/programming-keys.html。

如果你想更精确地执行操作，可以先查看你可以从 Prowler 执行哪些特定检查项或服务，使用以下命令之一：

prowler --list-checks
prowler –-list-services

当你找到想要执行的检查项时，可以使用以下语法：

prowler -c check11,check12

当然，替换check11和check12为你想要执行的检查项。

你也可以运行所有的检查项，除了其中的一些，方法如下：

./prowler -E check32,check33

这将运行所有的检查项，除了 check32 和 check33。

默认情况下，Prowler 将扫描你所有已经选择的区域中的 AWS 服务。但你可以像这样限制扫描仅限于某些区域：

./prowler -f 'eu-west-1 us-east-s'

因此，在这种情况下，只有eu-west-1和us-east-s中的服务器将被扫描。

这就是在 AWS 中使用 Prowler 执行漏洞扫描和渗透测试的基本步骤。欲了解更多信息，请参阅 Prowler 的 README 文件（github.com/prowler-cloud/prowler#readme）和文档。

Pacu

现在，是时候使用 Pacu 了。我将带你执行漏洞扫描模块。还会向你展示如何查找 Pacu 扫描的输出报告。请按照以下步骤操作：

1. 你可以使用两种方法之一。你可以输入以下命令序列，准备你的访问密钥以免费使用 Pacu：

   export AWS_ACCESS_KEY_ID=your_access_key_id
   export AWS_SECRET_ACCESS_KEY=your_secret_access_key
   

2. 作为步骤 1的替代方案，你可以输入此命令来配置你的密钥：

警告

这个命令可能会向您的 AWS 账户收取 0.0003 美元的费用。

aws configure

1. 然后，输入我们为 Prowler 使用的密钥 ID。导航到我们安装 Pacu 的目录：

   cd /Pacu
   

2. 在 AWS CloudShell 命令行中，我们首先查看帮助选项：

   pacu –-help
   

3. 如果那不起作用，您可以尝试此处的替代安装说明：rhinosecuritylabs.com/aws/pacu-open-source-aws-exploitation-framework/。如果您是通过这种方式安装的 Pacu，您可以使用此命令执行 Pacu。只要确保您在正确的目录中：

   python3 pacu.py
   

4. 当 Pacu 要求您命名一个新会话时，您可以随意为该会话命名，然后按 Enter。例如，您可以尝试 TestPacuSession。

5. 查看您可以尝试的模块列表：

   ls
   

   这是您应预期的结果：

图 5.8 – Pacu 帮助屏幕

尝试任何您想要的模块。例如，有一个名为 backdoor_users_password 的模块。是否存在能够揭示用户密码的 AWS 服务后门？您还可以查看此处的完整模块列表：github.com/RhinoSecurityLabs/pacu/wiki/Module-Details。

尝试这个命令：

run <module name>

例如，您可以尝试以下内容：

run backdoor_users_password

然后，您应该能够从 AWS CloudShell 用户界面中选择 Actions** | **Download file，并在此目录中找到输出文件：

/home/cloudshell-user/output/

我建议查看 Pacu 的 Wiki 以获得更多有关如何最大化使用 Pacu 进行 AWS 渗透测试的信息：

github.com/RhinoSecurityLabs/pacu/wiki

总结

任何人都可以在他们的免费套餐下设置 AWS 账户，尝试一些通用的 AWS 渗透测试工具。

AWS 有自己的应用程序，对于渗透测试员来说非常有用。它们包括 AWS CloudShell、AWS Security Hub 和 Amazon Inspector。

AWS CloudShell 提供了一个命令行界面（CLI），您可以在登录到 AWS 账户后从网页浏览器中使用它。或者，您也可以使用 AWS CLI 应用程序，将其直接安装在您的 Windows、Mac 或 Linux 电脑上。

AWS Security Hub 是一个方便的统一应用程序，用于检查您所有 AWS 安全设置、配置和报告。

Amazon Inspector 是 AWS 原生的漏洞扫描应用程序。我建议在使用本书中演示的其他漏洞扫描器和渗透测试应用程序时，额外使用它。

使用 Prowler、Cred Scanner、CloudFrunt 和 Pacu，可以执行广泛的漏洞扫描和渗透测试。这些工具帮助您发现安全问题，例如暴露的服务和不良的安全配置。记住——您需要自己解读这些工具的输出并在渗透测试报告中解释它们。如果您只是分享扫描的 CSV 输出文件，那就没有履行渗透测试员的职责！

在第六章，我们将返回 AWS 账户，尝试使用 Docker 和 Kubernetes 进行容器化。然后，我们将测试我们将创建的 Docker 和 Kubernetes 实例。

进一步阅读

要了解本章涵盖的主题更多信息，请访问以下链接：

• AWS CloudShell 文档：docs.aws.amazon.com/cloudshell/

• 安装 Prowler：github.com/prowler-cloud/prowler

• Prowler 文档：docs.prowler.cloud/en/latest/

• Pacu：github.com/RhinoSecurityLabs/pacu

第六章：在 AWS 中渗透测试容器化应用

云网络的最常见应用之一是容器化应用的部署。在你的云渗透测试职业生涯中，你需要在容器化环境中进行测试的可能性非常高。

流行的容器化平台 Docker 和 Kubernetes，在它们的容器化系统内的操作方式是相同的，无论它们是在 AWS、GCP、Azure 还是任何其他云平台上部署。然而，AWS、GCP 和 Azure 与 Docker 和 Kubernetes 的接口方式在每个实例中都有些不同。

可以这样理解。无论是放在陶瓷盘、铝盘还是纸盘里，一片涂了黄油的烤面包都是同一片涂了黄油的烤面包。无论它放在哪种盘子里，味道都一样，你吃的方式也一样。但在你吃完面包后，清理或处置盘子的方式将会有所不同。

希望这能让你明白！嗯，等你读完这一章后，你会更能理解它。

在这一章中，我将解释以下内容：

• 容器化如何工作

• Docker 在 AWS 中的工作原理

• Kubernetes 在 AWS 中的工作原理

• 在 AWS 中的 Docker 和 Kubernetes 渗透测试技术

开始吧！

技术要求

使用 AWS 的一个好处，无论是用于容器化还是其他任何事情，就是我们能够使用亚马逊基础设施的计算能力。这意味着你不需要一台非常高端的工作站就可以进行本章中的任何练习。你只需要以下这些：

• 一台运行 Windows、macOS 或常见 Linux 发行版（如 Ubuntu 或 Debian）的现代桌面或笔记本电脑。一台至少配备 4 GB RAM 的 MacBook 或 Windows 11 OEM PC 就非常适合。

• 一个良好支持的网页浏览器，如 Safari 15 或更高版本、Microsoft Edge 83 或更高版本、Mozilla Firefox 105 或更高版本，或 Google Chrome 115 或更高版本。

• 稳定的互联网连接。

查看以下视频以观看代码演示：bit.ly/46VJSp3

容器化如何工作

首先，有了虚拟机（VMs）。虚拟机运行在宿主操作系统内，而宿主操作系统直接在计算机硬件上运行。就宿主操作系统而言，虚拟机只是一个它正在运行的应用程序，该应用程序分配了一定数量的内存（RAM）和磁盘空间（以虚拟磁盘的形式）。VMware 和 Oracle VirtualBox 都提供虚拟化客户端，你可以轻松地在 Windows、Mac 或 Linux PC 上运行和安装这些客户端。使用这些虚拟化客户端，你可以创建一个虚拟机来运行大多数版本的 Windows、macOS、Linux 或 Unix。

虚拟机有着大量的应用场景。我的背景是网络安全，所以我最熟悉的应用场景是恶意软件测试。我可以在虚拟机中安全地执行恶意软件，而不会对主机操作系统或其硬件造成损害。这是因为虚拟机确保虚拟操作系统与主机操作系统“沙盒化”隔离。在最坏的情况下，如果我的虚拟操作系统中的恶意软件导致虚拟操作系统无法正常启动，我可以进入主机操作系统，卸载虚拟机并删除其虚拟磁盘。然后，我可以创建一个新的虚拟机，重新开始。

我经常听到的关于主机计算机和虚拟机的类比是“计算机和它的宠物计算机”。但基本上，主机操作系统只是将虚拟机当作任何其他类型的应用程序来对待。

计算机虚拟化的实现比人们通常认为的要早得多。最早的计算机虚拟化案例出现在 1960 年代末和 1970 年代初的 IBM 大型机上。时代共享系统在当时的主机和小型计算机上很常见，因为直到个人计算机发明之前，人们并没有自己的计算机。

直到个人计算机的出现之前，所有计算机都是多人共享的。IBM 发明了虚拟化技术，使得在时代共享系统中的多个用户能够从 CPU、内存和磁盘存储中获得一层抽象。每个用户都可以拥有自己虚拟化的计算机，可以分配主机计算机的真实硬件资源，而不会影响其他用户在同一主机计算机上进行的操作。

正如计算机技术中的其他一切一样，在过去的几十年中，虚拟化技术变得越来越成熟。容器化是与虚拟机类似的概念，但并不完全相同。然而，虚拟化技术的发展进步使得容器化的发明成为可能。

简而言之，容器化类似于虚拟机，但更为轻量级。如果虚拟机是一座由砖块、木材、石头或混凝土建成的房子，那么容器就是一个可以根据需要迅速搭建和拆卸的帐篷。

虚拟机可以根据需要创建和删除。但安装和删除虚拟机并非即时的过程。要在我的 Windows 电脑上使用 Oracle VirtualBox 安装 macOS 虚拟机，我仍然需要为每一个新的 macOS 虚拟机经历 macOS 的安装过程。每次至少需要几分钟。

Docker 和 Kubernetes 都是容器化编排平台。Docker 和 Kubernetes 各自拥有分配硬件资源、负载均衡和进程隔离的系统。第一次设置 Docker 或 Kubernetes 容器化编排系统时，确实需要几分钟的安装和配置时间。然而，一旦 Docker 或 Kubernetes 容器化编排系统准备就绪，容器就可以非常快速地部署和移除。如果你的 AWS 服务提供足够的磁盘空间和网络带宽，你甚至可以在同一个编排平台下同时运行数百个容器。

你的云应用将立即受益于容器化所带来的可扩展性和效率。在典型的云容器化部署中，容器会根据应用程序在任意时刻的需求不断地被部署和移除。有时，某个容器可能只会存在几天或更短时间。

Docker 是第一个广泛流行的容器化平台。Docker 于 2013 年首次亮相，它使得容器化对开发者、企业和爱好者来说比以往任何时候都更容易。Kubernetes 团队受到 Docker 的启发，Kubernetes 的第一个版本于 2014 年发布。

虚拟机（VM）可以在个人电脑、服务器和云环境中运行。然而，尽管像 Docker Desktop 这样的应用程序使得可以在本地测试多容器应用，容器化技术实际上是为云环境而设计的。

AWS、Azure 和 GCP 等云平台为组织提供了硬件和网络的可扩展性，因为亚马逊、微软和谷歌在全球各地（除了南极洲）运营着大量的庞大数据中心，这些数据中心包含数百万台服务器和极高容量的网络基础设施。如果一个组织一天需要十几台服务器，第二天需要几百台服务器，亚马逊、微软和谷歌几乎可以立即以合适的费用提供这些资源。没有硬件资源被浪费，硬件资源的分配可以灵活且动态地进行。

因此，容器化技术是为云环境中的应用场景而设计的。云平台在宏观层面分配硬件资源，而容器化平台则在微观层面分配硬件资源。

开发者非常喜欢容器化技术，因为他们可以设计自己的软件运行在特定的容器配置中，而不必担心硬件兼容性问题。

容器将应用程序代码与它运行所需的依赖项、库和配置文件捆绑在一起，而如果他们为虚拟机或主机计算机开发代码，则必须关注操作系统。如果他们的代码是为了直接在主机计算机上运行而设计的，他们还需要了解其 CPU 和硬件规格。当容器化正确执行时，它能大大减少开发者的挫败感。因此，他们的时间和精力可以集中在改进应用程序上，而不必浪费时间解决硬件和操作系统的问题。

使用 AWS 而不进行容器化是可能的。在上一章中，我直接在 AWS 中安装了 Linux 操作系统，以制作那一章的 Code In Action 视频。当我使用 Prowler 时，它是在扫描一个非常简单的 Linux-in-AWS 设置的漏洞。如果一个 AWS 客户只需要一个或几个他们会持续维护的服务器，直接在 AWS 中使用操作系统就能满足他们的需求。

然而，许多 AWS 客户需要部署可能在任何时间都有成千上万，甚至数十万用户的应用程序。在这种情况下，容器化无疑是最实际的选择。云平台帮助实现容器化。因此，作为渗透测试人员，了解如何有效地对 Docker 和 Kubernetes 部署进行渗透测试是很重要的。

Docker 在 AWS 中的工作原理

Docker 容器化系统中的层次结构如下，从底部到顶部：

• AWS、Azure 或 GCP 是云平台。

• 云平台运行一个支持 Docker 主机的服务，比如 Amazon Elastic Container Service** (Amazon ECS**)。Docker 主机是一个服务器，管理员通过他们本地计算机上的 Docker 客户端进行管理。

• Docker 主机运行 Docker 守护进程，管理 Docker 镜像。守护进程还可以从 Docker 注册中心下载镜像。注册中心可以是远程的公共 Docker Hub，也可以是组织自己的私有注册中心。守护进程还处理 API 请求。

• Docker 镜像是创建 Docker 容器的指令。容器是从镜像生成的。

下面是 Docker 架构的示例：

图 6.1 – Docker 架构

AWS 中的 Docker 部署使用 Amazon Elastic Compute Cloud** (Amazon EC2**)，因为那是主要的计算平台。

Amazon ECS 是在 AWS 中运行 Docker 的主要服务，无论 Docker 部署的大小和规模如何。Amazon ECS 是你直接使用的服务，它为你处理 Amazon EC2 的工作。

在 AWS 中安装 Docker 有两种常见方法：

• 如果你更喜欢通过 图形用户界面(GUI) 安装 Docker，你可以通过 AWS 的 Web 应用程序实现。

• 或者，如果你更喜欢尽可能使用命令行界面（CLI），或者如果你希望在 AWS 上部署 Docker 之外，还可以使用 Docker Desktop 在本地测试你的容器化系统，你可以使用 Docker Compose CLI 在 AWS 上安装 Docker。如果你的 Docker Desktop 版本中没有包含 Docker Compose 插件，可能需要安装它。请参阅 Docker 文档，链接：docs.docker.com/compose/install/。

无论你选择哪种方式安装 Docker，你仍然可以使用你选择的兼容 GUI 和 CLI 应用程序来使用、管理和配置 Docker 部署。

在 AWS 上使用 Amazon ECS 安装 Docker 集群

首先，我将带你通过 AWS 的网页应用程序 GUI 安装 Docker 集群：

1. 第一步是启动 Amazon ECS 首次运行向导。通过网页浏览器登录到你的 AWS 账户，向导会让你轻松启动 Amazon ECS 并部署 Docker。

2. 在 AWS 的网页界面中，我喜欢通过在顶部的 AWS 应用程序菜单的搜索栏中搜索服务和应用程序的名称来进行导航。搜索Amazon ECS，点击弹性容器服务，你就能快速到达正确的页面。

3. 在右侧，有一个白色的框框，上面写着部署你的容器化应用程序。点击橙色的开始按钮。

4. 页面上会显示集群，点击右上角的橙色按钮，按钮上写着创建集群。

5. 在集群配置下，给你的集群命名。我选择了AWS-Docker-Test，但你可以选择任何有效的名称。

6. 在网络下，保持默认的虚拟私有云（VPC）、子网和命名空间设置。

7. 在基础设施下，保持默认的AWS Fargate（无服务器）设置。这是让 Amazon ECS 为你的 Docker 部署分配硬件资源的最简单方式。

8. 同样，保持监控和标签部分的默认设置。在右下角，点击橙色的创建按钮。

   顶部会出现一条蓝色进度条，显示集群创建正在进行中。可能需要几分钟。如果一切顺利，进度条会变成绿色，并显示集群创建成功。如果没有，请重复我带你走过的步骤再试一次。当我自己测试集群创建过程时，第一次尝试返回了一个红色进度条，显示创建过程失败。但第二次尝试成功了。

9. 现在你的集群已成功创建，你可以在列表中看到新集群的名称。点击集群的名称。

10. 您将被带到一个新页面，页面顶部会显示您的集群名称（在我的例子中是AWS-Docker-Test）。页面下方的第一部分显示集群概览，接下来的部分有六个选项卡：服务、任务、基础设施、指标、定时任务和标签。在服务选项卡下，点击右上角的橙色创建按钮。

11. 在下一页面中，保持环境部分的所有默认设置。在部署配置部分，将应用类型保留为服务。在下方，您将看到一个任务定义区域，其中写着选择现有任务定义。要创建新的任务定义，请转到任务定义，然后点击转到任务定义**。

12. 一个新页面将会在您的网页浏览器的新标签页中加载。在任务定义页面中，点击右上角的橙色创建新任务定义按钮。在配置任务定义和容器部分，给您的任务定义家族命名。我选择了Docker-Test-Task-Definition，因为我真是太有创意了。但您可以创建任何您喜欢的名称。

13. 在容器 - 1下，给您的容器命名（我选择了Docker-Container-Test）。您还需要输入一个镜像 URI（如果需要帮助，可以访问 docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/docker-custom-images-tag.html 了解如何选择基础镜像 URI）。在我的情况下，我使用的是亚马逊的us-east-1数据中心。所以，我的镜像 URI 是 711395599931.dkr.ecr.us-east-1.amazonaws.com/spark/emr-6.10.0:latest。将所有其他默认设置保持不变。点击右下角的橙色创建按钮。

14. 在家族下，输入您的新任务定义名称（我的名称是Docker-Test-Task-Definition）。将修订版保持不变。在服务名称下创建一个新名称。我选择了Docker-Test-Service。将其他所有默认设置保留不变。点击右下角的橙色创建按钮。

您的新服务的部署可能需要几分钟时间，正如屏幕顶部的蓝色通知所示。我向您展示的所有使用 Amazon ECS 部署的服务默认都会使用 Docker。所以，您正在创建一个新的 Docker 实例。

使用 Docker Desktop 部署 Docker

在亚马逊 ECS 中部署 Docker 的另一种主要方式是使用 Docker Desktop。如果您更喜欢这种方式，首先需要在本地计算机上安装 Docker Desktop。Docker Desktop 是用于运行 Docker CLI 命令的应用程序。要安装它，请按照以下步骤操作：

1. 访问 docs.docker.com/desktop/install/mac-install/ 以在 Mac 上安装，或者访问 docs.docker.com/desktop/install/windows-install/ 以在 Windows 上安装。如果 Docker Desktop 中没有包含 Docker Compose 插件，你可能还需要安装它。相关安装说明可以参考 Docker 文档 (docs.docker.com/compose/install/)。如果你的本地计算机使用的是 Linux 操作系统，你需要在这里安装 Docker Compose CLI： docs.docker.com/cloud/ecs-integration/#install-the-docker-compose-cli-on-linux。

2. 通过你的网页浏览器登录到 AWS 账户。你需要确保你的 AWS 凭证拥有访问某些 AWS 身份与访问管理(IAM) 权限。如果你需要更多帮助，可以查看 AWS 的权限管理文档 (aws.amazon.com/iam/features/manage-permissions/)。如果你只有根账户，你将需要创建一个新的 IAM 账户，并赋予下面列出的权限。这些是你的凭证所需的权限：

   • application-autoscaling:*

   • cloudformation:*

   • ec2:AuthorizeSecurityGroupIngress

   • ec2:CreateSecurityGroup

   • ec2:CreateTags

   • ec2:DeleteSecurityGroup

   • ec2:DescribeRouteTables

   • ec2:DescribeSecurityGroups

   • ec2:DescribeSubnets

   • ec2:DescribeVpcs

   • ec2:RevokeSecurityGroupIngress

   • ecs:CreateCluster

   • ecs:CreateService

   • ecs:DeleteCluster

   • ecs:DeleteService

   • ecs:DeregisterTaskDefinition

   • ecs:DescribeClusters

   • ecs:DescribeServices

   • ecs:DescribeTasks

   • ecs:ListAccountSettings

   • ecs:ListTasks

   • ecs:RegisterTaskDefinition

   • ecs:UpdateService

   • elasticloadbalancing:*

   • iam:AttachRolePolicy

   • iam:CreateRole

   • iam:DeleteRole

   • iam:DetachRolePolicy

   • iam:PassRole

   • logs:CreateLogGroup

   • logs:DeleteLogGroup

   • logs:DescribeLogGroups

   • logs:FilterLogEvents

   • route53:CreateHostedZone

   • route53:DeleteHostedZone

   • route53:GetHealthCheck

   • route53:GetHostedZone

   • route53:ListHostedZonesByName

   • servicediscovery:*

3. 现在，你需要在 Docker Compose CLI 中运行一些命令。首先运行以下命令：

   docker context create ecs <name of your ECS context>
   

   以下内容将会显示在你的屏幕上：

   ? Create a Docker context using:  [Use arrows to move, type to filter]
     An existing AWS profile
     AWS secret and token credentials
   > AWS environment variables
   

4. 选择 AWS 环境变量。按照屏幕上的指示，配置你的 ECS 上下文以获取 AWS 凭证。配置完成后，你可以使用以下命令查看你的 Docker 上下文：

   docker context ls
   

5. 现在，你可以使用 dockercompose 命令在 Amazon ECS 中部署和管理你的 Docker 容器化应用。

关于 Docker Compose CLI 命令和配置的帮助指南可以在 Docker 文档 网站上找到 (docs.docker.com/cloud/ecs-integration/)。我强烈建议同时参考 Docker 命令行指南 (docs.docker.com/engine/reference/commandline/cli/)。不过，我个人更喜欢完全使用 AWS 的 Web 应用 GUI 来部署 Docker 的另一种方式。

如果你需要删除 Docker 集群，请参考 AWS 文档：

docs.aws.amazon.com/AmazonECS/latest/userguide/delete_cluster-new-console.html

当你不再使用 Docker 容器时，也可以将其移除。以下命令（在 Docker CLI 中）将删除 Docker 容器及其卷（数据存储单元，或 DSUs）：

docker rm --volumes <name of docker container>

因此，Docker 是在 AWS 中部署容器化应用程序的一种方式。Kubernetes 是另一种方式，它建立在 Docker 系统的基础上。但它的设置方式有所不同，正如你将看到的那样。

Kubernetes 在 AWS 中的工作方式

Kubernetes 容器化系统的层次结构如下，从底部到顶部：

• AWS、Azure 或 GCP 是云平台。

• 云平台运行一个服务，如 Amazon Elastic Kubernetes Service** (Amazon EKS**)，它支持控制平面。

• 下一层是控制平面，由 Kubernetes 管理。它是集群的根节点。

• 控制平面根据云管理员定义的不断变化的网络应用指标部署 Pods。Pods 被部署以随时管理 Kubernetes 应用程序的需求。例如，更多的用户和更高的带宽消耗通常会导致更多的 Pods。

• Pods 部署容器。

下面是 Kubernetes 架构的示意图：

图 6.2 – Kubernetes 架构

Kubernetes 在 AWS 中的部署使用 Amazon EC2，因为它是主要的计算平台。也可以直接在 Amazon EC2 中管理 Kubernetes。但更常见的做法是组织选择使用 Amazon EKS 作为与 Amazon EC2 的接口，这样可以省去管理员需要管理 etcd 和实例的麻烦。

本书中我使用的所有 AWS Kubernetes 示例都假设正在使用 Amazon EKS。

使用 AWS 的 Web 应用程序创建 Kubernetes 容器化系统的最简单方式是使用 Amazon EKS 集群。虽然也可以通过 AWS CLI 启动集群，但我发现设置 IAM 和 JSON 配置文件需要花费额外的时间。如果你更倾向于使用命令行，可以参考 AWS 文档中的指南：docs.aws.amazon.com/eks/latest/userguide/getting-started.html。不过，我猜你只是为了练习渗透测试环境的搭建。所以，通过 AWS Web 界面以默认设置启动 EKS 集群应该足够满足你的需求。接下来，按照以下步骤操作：

1. 通过浏览器登录到你的 AWS 账户，访问 aws.amazon.com。在顶部菜单的搜索框中，输入EKS或Elastic Kubernetes Service。会有一个链接，点击打开 Amazon EKS 界面。或者，你也可能会在屏幕右侧看到一个白色框，框中写着添加集群，你可以点击它。

2. 系统会立即带你进入集群页面。点击右上角的橙色创建集群按钮，从下拉菜单中选择创建。或者，你可能需要点击标有创建的下拉菜单，然后点击创建集群。

3. 现在，你进入了配置集群页面。为你的集群输入一个原始名称，选择你喜欢的名称。我选择了EKS-Pentest。保持默认的 Kubernetes 版本。选择下拉菜单中的集群服务角色。如果没有可选的集群服务角色，请按照 Amazon EKS 用户指南中的说明（docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html#create-service-role）创建一个具有 EKS 集群权限的 AWS IAM 角色。

4. 保持其他默认设置不变，然后点击右下角的橙色下一步按钮。

5. 在下一页面，你需要配置网络设置。将VPC、子网、安全组和IP 地址保留为默认设置。将集群端点访问设置为公共，然后点击右下角的橙色下一步按钮。

6. 在配置日志记录页面，将控制平面设置为记录API 服务器、审计、身份验证器、控制器管理器和调度器。对于渗透测试和红队用途，更多的日志记录永远是最好的！点击右下角的橙色下一步按钮。

7. 保持 Amazon EKS 插件为默认设置。它们包括 CoreDNS、Amazon VPC CNI 和kube-proxy。点击右下角的橙色下一步按钮。

8. 保持插件的默认版本。点击右下角的橙色下一步按钮。

9. 审核你所有的配置，然后点击右下角的橙色创建按钮。

   你将在屏幕顶部看到一个蓝色通知条，显示你的集群正在创建。可能需要几分钟时间。当你看到绿色的通知条时，说明你的 Kubernetes 集群已经创建成功，恭喜！

如果你需要删除 Kubernetes 集群，请参考 AWS 文档：

docs.aws.amazon.com/eks/latest/userguide/delete-cluster.html

所以，我们现在已经在 AWS 上设置了 Docker 和 Kubernetes 容器化系统。接下来，是时候进行渗透测试了。

在 AWS 中进行 Docker 和 Kubernetes 渗透测试技术

在上一章中，我带你使用 Prowler 来进行 AWS 部署的渗透测试。我将向你展示一些脚本和漏洞检查，你可以执行这些操作来查找 Docker 和 Kubernetes 漏洞，使用不同的工具。但首先，值得在这里提到的是，Prowler 可以从 Docker 实例中执行！你可以使用 Docker 容器中的 Prowler 来帮助渗透测试你组织的整个 AWS 网络。从 Docker 运行 Prowler 不仅仅是为了评估 Docker 的漏洞。

从上一章中得到的相同 Prowler CLI 命令，可以在你从 Docker 运行 Prowler 时使用。

在 Docker 中的安装

这是从 Docker 安装 Prowler 的方法：

1. 确保你的本地计算机上安装了 Docker Desktop。你可以在这里找到 Docker Desktop 的 Windows、Mac 和 Linux 客户端：docs.docker.com/get-docker/。

2. 准备好你的 AWS 凭证。你可以通过在浏览器中登录 AWS 账户来验证它们。在顶部菜单栏，查看最右侧的下拉菜单，点击你的用户名。然后点击 Security credentials 以导航到正确的 AWS IAM 页面。页面顶部应该显示 My security credentials (root user)。记下你的 AWS 账户 ID、访问密钥 ID 和秘密访问密钥。

3. 通过查看顶部菜单栏，导航到 AWS CloudShell。点击位于铃铛图标左侧的命令提示符图标来启动它。

4. 在 AWS CloudShell CLI 中，输入 pwd 来验证你的主目录路径。你可能需要使用 ls（列出文件和文件夹）命令和 cd（更改目录）命令来找到你的主目录。

5. 输入以下命令，在 Docker 容器内安装并配置 Prowler。确保在脚本中输入你的 AWS 访问密钥：

   docker run -ti --rm -v /your/local/dir/prowler-output:/home/prowler/output \
   export AWS_ACCESS_KEY_ID="ASXXXXXXX"
   export AWS_SECRET_ACCESS_KEY="XXXXXXXXX"
   export AWS_SESSION_TOKEN="XXXXXXXXX"
   --name prowler \
   --env AWS_ACCESS_KEY_ID \
   --env AWS_SECRET_ACCESS_KEY \
   

   将 /your/local/dir 替换为你的主目录路径。在每个 \ 实例后输入你的访问密钥 ID 和秘密访问密钥。

如果你需要帮助生成 AWS_SESSION_TOKEN 实例，考虑使用此指南：

www.websitebuilderinsider.com/how-do-i-get-my-aws-session-token/#:~:text=To%20get%20your%20session%20token,best%20to%20contact%20AWS%20support

Prowler 将在您的 Docker 实例中安装，现在您应该能够从 Docker Desktop 的 Docker Compose CLI 执行 Prowler。上一章中的所有 Prowler 命令在这里都能正常工作。此外，请通过以下 Docker Docs 指南熟悉 Docker 命令：docs.docker.com/engine/reference/commandline/cli/。

Vishnu Nair 提供了一个简单的自动化渗透测试脚本，您可以用来进行真实的渗透测试，也可以用于教育用途。我推荐您试试看！它可以在 Docker Hub 找到 (hub.docker.com/r/vishnunair/pentest)。

因为我只是试用一下，所以决定在Play With Docker** (PWD**) (labs.play-with-docker.com/) 模拟环境中运行 Vishnu Nair 的脚本。PWD 提供了一个“简单、互动且有趣的游乐场”，您可以在其中的虚拟机上进行 Docker 实验，并且可以直接从浏览器执行。当然，Vishnu Nair 的脚本也可以在真实的 Docker 实例中运行。

Vishnu Nair 的自动化渗透测试会自动执行包括（但不限于）Nmap、Uniscan、TheHarvester、XSSStrike、Dirb、SSLScan 和 DNSmap 等多个模块。然后，它会将结果打印到屏幕上，并保存到容器内的 /src 文件夹中。

这是一个非常简单的脚本——我使用过的最用户友好的容器自动化漏洞扫描工具之一。

这里是要使用的命令：

1. 首先，创建一个 Docker 卷：

   docker volume create pentest-reports
   

2. 然后，下载脚本：

   docker run -d --name pentest -d -v pentest-reports:/src vishnunair/pentest:latest
   

3. 按照以下方式执行它：

   docker exec -it pentest bash
   ./pentest.sh -d <domain name of your container here>
   

   扫描结果将显示在您的屏幕上。

4. 在 /var/lib/docker/volumes 路径中查找您的 Docker 卷。您可能需要使用 cd 命令导航到该路径。

5. 然后，使用以下命令查找您的扫描报告：

   docker volume inspect pentest-reports
   

继续进行 Kubernetes！

在 Kubernetes 中安装

Aqua Security 的 kube-bench 是一个自动化脚本，根据 互联网安全中心(CIS) Kubernetes 基准标准进行漏洞扫描 (www.cisecurity.org/benchmark/kubernetes)。该基准标准包括以下类别的检查：

• 控制平面组件

• etcd

• 控制平面配置

• 工作节点

• 策略

有多种方式可以运行 kube-bench (github.com/aquasecurity/kube-bench/blob/main/docs/running.md)，其中包括作为 Kubernetes 作业使用 YAML 文件。在本章中，我为 Kubernetes 创建了一个 Azure Kubernetes Service** (AKS**) 集群。所以，让我们在那里尝试运行 kube-bench：

1. 首先，确保按照 GitHub 上的说明，kubectl-node-shell 已经安装在您的 EKS 集群中：github.com/kvaps/kubectl-node-shell。

2. 在安装了 Docker 的 AWS CLI 中，运行 kube-bench 脚本：

   docker run --rm -v `pwd`:/host docker.io/aquasec/kube-bench:latest install
   ./kube-bench
   

3. 你的基准检查结果将在屏幕上打印出来，你还应该能在容器的/src文件夹中找到报告。

   如果你需要故障排除帮助，请参考kube-bench文档：github.com/aquasecurity/kube-bench/tree/main/docs。

提示

这里有一个关于尝试本书中提到的所有 Docker 和 Kubernetes 渗透测试工具和脚本的小贴士。你还记得我在本章开头用一个比喻来说明云平台（AWS、Azure、GCP）就像一道菜，而容器化编排平台（Docker、Kubernetes）就像一片抹了黄油的吐司吗？

AWS（第五章）、Azure（第八章）、和 GCP（第十一章）的渗透测试是针对这些云平台的特定内容。但本章中提到的 Docker 和 Kubernetes 渗透测试工具和脚本，以及第九章和第十二章中的内容，可以在任何 Docker 或 Kubernetes 实例中运行，而不管使用的云平台是什么。

所以，本书后续内容中还有更多有用的 Docker 和 Kubernetes 渗透测试工具和脚本！

总结

AWS、Azure 和 GCP 等云平台之所以流行，是因为它们为组织提供了大量的可扩展性，尤其是在它们的庞大数据中心中。

由 Docker 或 Kubernetes 编排的容器化充分利用了云基础设施，通过帮助组织更好地管理硬件和软件资源，优化了其网络应用。容器使用虚拟化，但比虚拟机更轻量、更便于移植。作为一名云端渗透测试员，你几乎肯定会与容器化打交道。

在 AWS 中，Docker 通常通过 Amazon ECS 运行，Kubernetes 通过 Amazon EKS 运行。它们都是 Amazon EC2 的接口。

Docker 和 Kubernetes 的渗透测试脚本和基准测试在不同云平台之间是可以互换的。

现在我们已经在 AWS 中部署了虚拟机和容器化应用并进行了渗透测试，接下来我们将在下一章转向微软 Azure。

进一步阅读

要了解更多关于本章涉及的主题，你可以访问以下链接：

• AWS 上的 Docker：aws.amazon.com/docker/

• AWS 上的 Kubernetes：aws.amazon.com/kubernetes/

• Docker CLI 指南：docs.docker.com/engine/reference/commandline/cli/

• PWD 测试实验室：www.docker.com/play-with-docker/

第三部分：渗透测试微软 Azure

Azure 是微软自家的云平台，已经被各种企业广泛使用超过 15 年。在这一部分，我们将学习 Azure 的各种软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）应用程序。我们将部署自己的 Azure 实例来测试渗透测试技能。我们将使用 Microsoft Defender for Cloud 来检查我们 Azure 部署的安全状况。我们还将一步一步尝试 Azure 中的一些渗透测试工具。然后，我们将部署 Docker 和 Kubernetes 容器并进行测试。

本节包含以下章节：

• 第七章，Azure 中的安全功能

• 第八章，通过无服务器应用程序和工具对 Azure 功能进行渗透测试

• 第九章，在 Azure 中对容器化应用程序进行渗透测试

第七章：Azure 中的安全功能

作为一名云渗透测试员，了解 Azure 这一最受欢迎的云平台之一是非常重要的。你可能会经常进行 Azure 网络和应用的渗透测试。

本章中，我们将首先检查 Azure 生态系统中最常用的方面，以及最受欢迎的 Azure 服务、应用和功能，以及它们为何被使用。接下来，我们将探讨 Azure 软件即服务（SaaS）、基础设施即服务（IaaS）和 平台即服务（PaaS）功能。最后，我们将讨论微软自有的 Azure 安全工具和第三方安全工具。

本章涵盖以下主要主题：

• Azure 介绍

• 常用的 Azure SaaS 应用

• Azure IaaS 应用

• Azure PaaS 应用

• Azure 安全控制与工具

让我们直接开始吧！

Azure 介绍

在 2000 年代初期，微软的数据中心基础设施比现在的云平台竞争对手 Amazon 和 Google 要小。但微软的财力相对雄厚。当它在 2002 年推出 Xbox Live（现为 Xbox 网络）时，已经构建了庞大的后台基础设施，以支持当时世界上最大容量的在线游戏服务。从那时起，微软不断扩大其数据中心容量，进入网络服务行业（MSN 不算）并与其视频游戏主机业务同步扩展。

从我了解的情况来看，微软为消费市场打造 Xbox Live/ Xbox 网络的经历，为其提供了进入企业市场提供网络服务的经验。2002 年，亚马逊以“Amazon.com Web Services”推出了 AWS，旨在为企业提供云服务。微软可能想，“我也想参与这场竞争。”

这花费了几年的研究和开发，以及更多的基础设施建设。但到 2008 年 10 月，微软准备宣布“红狗计划”。

红狗计划（Project Red Dog）

红狗计划是微软的云操作系统项目，是 Azure 的前身。并没有所谓的“红狗”操作系统；它演变成了本章提到的 Azure 服务。

到 2010 年，微软的新云服务以 Windows Azure 推出，2014 年更名为 Microsoft Azure。

与其主要竞争对手 Amazon 和 Google 一样，微软在过去几年里一直稳步向其云平台添加新功能和服务。

微软的一大优势是其在市场上占据主导地位的商业操作系统和应用程序。大量使用 Windows Server 和 Active Directory 的企业，在 Azure 托管云网络和应用程序时能够获得极大的协同效应。AWS 和 GCP 也可以与 Windows Server 和 Active Directory 一起使用，但那就像是法国人做的意大利菜。而 Windows Server 和 Microsoft Azure 就像是意大利人做的意大利菜！因此，许多组织选择将 Azure 集成到其网络中，无论其云是完全使用 Azure 还是多云环境。

在进行任何 Azure 网络渗透测试之前，确保遵守微软的渗透测试参与规则是很重要的。以下是微软官网上所述内容（www.microsoft.com/en-us/msrc/pentest-rules-of-engagement）：

“该计划的目标是让客户能够在不对其他微软客户造成损害的情况下，测试其在微软云服务中托管的服务。

以下活动 是禁止的：

• 扫描或测试属于任何其他微软 云客户的资产。

• 访问任何非完全属于 自己的数据。

• 进行任何形式的拒绝服务 测试。

• 对任何资产进行网络密集型模糊测试，除了你的 Azure 虚拟机。

• 对生成大量流量的服务进行 自动化测试。

• 故意访问任何其他 客户的数据。

• 超越“概念验证”步骤，解决基础设施执行问题（例如，证明你通过 SQLi 获得了 sysadmin 访问权限是可以接受的，但运行 xp_cmdshell 则不行）。

• 以违反《微软在线服务条款》中所述的可接受使用政策的方式使用我们的服务。

• 尝试进行钓鱼或其他社交工程攻击 针对我们的员工。

以下活动 是鼓励的：

• 创建少量测试账户和/或试用租户，用于演示和证明跨账户或跨租户的数据访问。然而，禁止使用其中一个账户访问另一个客户 或账户的数据。

• 对自己的 Azure 虚拟机进行模糊测试、端口扫描或运行漏洞评估工具。

• 通过生成正常业务过程中预期的流量进行应用程序负载测试。这包括测试 激增容量。

• 测试安全监控和检测（例如，生成异常安全日志，丢弃 EICAR 等）。

• 尝试从共享服务容器中突破，如 Azure 网站或 Azure Functions。如果成功，你必须立即向微软报告并停止进一步探索。故意访问其他客户的数据是 违反条款的行为。

• 在 Microsoft Intune 中应用条件访问或移动应用管理（MAM）策略，以测试这些策略强制执行的限制。

即使有这些禁止性规定，微软保留对其网络中任何看起来具有恶意性质的行为作出响应的权利。微软云中采用了许多自动化的缓解机制，这些机制不会因为渗透测试而被禁用。

简而言之，你可以在 Azure 中进行渗透测试，而无需获得微软的许可。但你所能做的事情是有限制的。你不能执行可能干扰其他 Azure 客户的活动，例如分布式拒绝服务（DDoS）攻击模拟或压力测试。你甚至不能尝试访问不属于你所在公司的 Azure 数据和资产。模拟犯罪基础设施执行漏洞是严格禁止的。你可以对公司自己的服务和应用进行负载测试，但不能生成超过正常操作所需的数据或消耗更多带宽。微软鼓励你创建新的用户账户来测试身份和访问管理（IAM）问题，只要你不尝试访问不属于你所在公司的数据。当然，你还需要公司书面许可才能进行任何形式的渗透测试、安全测试或红队活动。

Microsoft Azure 是一个独特的云平台。但在许多方面，它与 AWS 和 GCP 相似。与 AWS、GCP 以及许多其他云提供商一样，Azure 提供了广泛的云服务，这些服务可以根据微软负责的程度和客户（你所在的公司）负责的程度进行分类。与其他云平台一样，所有 Azure 服务可以分为 SaaS、PaaS 或 IaaS。

无论服务是 SaaS、PaaS 还是 IaaS，组织都要对其自身数据的安全负责。如果客户自己的代码中的软件漏洞在网络攻击中被利用，这是客户需要处理的问题。微软提供了许多非常有用的安全工具，能够大大改善组织在 Azure 中的安全态势，但必须实际使用这些工具，它们才能发挥作用。

无论如何，微软负责其 Azure 基础设施的安全。这也是为什么没有人被允许在没有微软明确许可和严格监督的情况下访问其任何数据中心。这也是为什么在执行渗透测试和红队活动时，渗透测试人员在 Azure 中的权限受到限制的原因。客户对云中的安全负责；云服务提供商对云的安全负责。客户自己的代码和应用程序是他们的事；微软的服务器、网络设备、数据中心建筑和微软自己的代码是微软的事。

第三章详细介绍了云计算的共享责任模型。但为了方便起见，你可以查看微软的 渗透测试参与规则（www.microsoft.com/en-us/msrc/pentest-rules-of-engagement）和 微软在线订阅协议（azure.microsoft.com/en-us/support/legal/subscription-agreement/）。在你开始任何 Azure 渗透测试之前，务必理解并遵守微软的规则。因此，查阅这些资源并重新阅读 第三章，确保你了解你被允许做的事情和禁止的事项。如果你所在的组织要求你做微软禁止的事情，那么微软的权威将优于他们的。当你在 Azure 进行渗透测试时，你是在微软的“家”里做客。

SaaS、PaaS 和 IaaS 表示 Azure 服务中有多少部分是属于微软的，且你所在公司的责任和自主权有多少。在 SaaS 中，很多软件代码归微软所有。你的公司需要做的工作最少（相对于 PaaS 和 IaaS）。你公司的数据运行在微软的在线应用中。在 IaaS 中，微软提供的是自己的基础设施，其他几乎没有。你的组织拥有最多的灵活性和控制权，但也必须构建和维护几乎所有的软件代码和网络配置，这些都是在微软的基础设施中使用的。PaaS 介于这两者之间。PaaS 提供比 IaaS 更多的微软 API 和服务功能。微软提供一个应用程序和服务平台，但它支持你组织自己的软件。

现在，让我们探索一下最常用的 Azure 服务。

常用的 Azure SaaS 应用程序

我将总结 Azure 中最受欢迎的 SaaS 应用程序。你不太可能对它们进行渗透测试，因为微软在其 SaaS 的安全性方面负有更多责任，而不是 PaaS 和 IaaS。你的公司只是将自己的数据输入到这些应用程序中，或者将它们嵌入到自己的应用程序中。但作为一个 Azure 渗透测试员，理解 Azure 的多种使用方式非常重要，这样你才能将 SaaS 与 Azure 其他部分的关系进行背景化，并了解你所在公司如何使用 Azure 的 SaaS 应用程序。此外，你所在组织输入到 Azure SaaS 应用程序中的数据是你们组织的安全责任。例如，如果你所在组织的某个人将他们的敏感银行账户信息输入到 Microsoft Cost Management 中，而绕过了微软所实现的加密，那么这是你们组织的问题。如果你的组织有一个与 SaaS 应用程序接口的 PaaS 或 IaaS 应用程序，那么这个数据流很可能可以从 PaaS 或 IaaS 端进行渗透测试。

Azure Maps

Azure Maps 类似于 Google Maps。它提供了几乎所有建设区域的详细地图。内置功能使用 IP 和 GPS 地理定位，用户可以看到自己在地图上的位置以及目的地。Azure Maps 可以集成到 Azure 客户开发的移动应用和网页应用中。例如，企业可以在其网页上嵌入一个 Azure Maps 小组件，展示其实体位置的地图。Azure Maps 在 GitHub 上有大约 250 个不同的代码示例（samples.azuremaps.com/），使开发者的集成工作变得简单。代码示例涵盖了从在地图上为多个点添加动画，到展示带有不同类型地理和气象数据的不同地图层，再到使用 Azure Maps Web Control 实现室内空间地图等内容。

图 7.1 – Azure Maps 截图

Azure Maps 提供多种数据流，涵盖交通、天气、摄影图像和数据可视化。例如，哪里是最高的山峰和最深的峡谷？哪一地区的年降水量最多？零售商的所有门店都在哪些地方？Azure Maps 的数据可视化功能可以与商业客户自己的数据进行配合。

Azure Digital Twins

Azure Digital Twins 使用客户自己的物联网设备来创建物理对象、业务流程和地点的数字模型。当物联网设备检测到物理环境的变化时，Azure Digital Twins 可以相应地调整数字模型。它与 REST API、Azure IoT Hub、Logic Apps、Event Hubs、Azure Data Explorer 和 Azure Synapse Analytics 集成。虽然有点奇怪，但也有点酷。

Azure Monitor

前两个应用程序（Azure Maps 和 Azure Digital Twins）更为专业化。但 Azure Monitor 则更加通用。Azure Monitor 可以进行配置，使组织通过动态仪表板界面查看广泛的业务网络数据。度量、日志、变化和跟踪会传送到 Azure Monitor。然后，管理员可以观察不同的网络事件，其中并非所有事件都直接与安全事件相关。你还可以显示实时数据，查看如“有多少用户在使用哪些应用程序， 以及何时使用？”等指标。

Azure Monitor 集成到每一个可能的 Azure 服务和应用程序中。你还可以通过 Azure Arc 实现来自其他云服务提供商（多云环境）和本地网络的数据。

Microsoft 成本管理

Microsoft 成本管理 为 Azure 客户提供有关他们在各种 Azure 服务、应用程序和功能上的支出非常详细的信息。它有详细的面板，用于成本分析、成本警报、预算数据、账单费用和使用情况，以及与公司部门和账户相关的 Azure 成本。

可以显示图表，展示客户在 Azure 服务上的支出趋势和模式。会计人员和 首席财务官（CFO）对此类信息非常喜爱。它不仅仅是“我们公司本月在 Azure 上花费了 $25,657。” Microsoft 成本管理展示了所有可以在会计账本中显示的 Azure 支出指标。因此，当然，客户可以看到饼图，展示整体 Azure 支出的各个相关类别。

Azure Advisor

Azure Advisor 类似于 Microsoft 成本管理，但它显示的是与安全性、可靠性、性能、运营卓越性和成本相关的各种指标，而非预算和账单信息：

图 7.2 – Azure Advisor 截图

可以通过 Azure 命令行界面（Azure CLI）、Advisor API 或 Azure 门户启动 Azure Advisor，以显示相关的度量数据。如果管理员问“我们如何更有效地管理 Azure 资源和应用程序？”，Azure Advisor 将提供所需的信息，帮助他们做出这些决策。

网络观察器

Network Watcher 是一种全面的网络性能监控和诊断解决方案。它显示带有动态实时网络度量的仪表板，涵盖 虚拟机（VMs）、虚拟专用网络（VPNs）和网络流量模式。

查看组织中每个部分使用的 Azure 云网络带宽！通过安全中心查看一般安全指标、资源安全卫生、安保警报和合规数据。网络观察器也可以用来诊断各种连接性问题。

现在我们已经了解了 SaaS，让我们来看看 IaaS。虽然 SaaS 将最大控制权和安全责任交给微软，但 IaaS 则将大部分控制权和安全责任交给你所在的组织。

Azure IaaS 应用程序

Azure IaaS 仅为你的组织提供关于软件代码的基础内容。你所在的组织在 IaaS 中部署的大多数代码都属于你的组织，并且就网络安全而言是你组织的责任。

这里是 Azure 中一些最常用的 IaaS 应用程序。

Azure 虚拟机

Azure 虚拟机使你的组织能够部署带有 Windows 和 Linux 的虚拟机。你可以部署大量的虚拟化 Windows 和 Linux 服务器，用于执行 Linux 和 Windows 服务器的所有任务，从运行大型企业应用程序到部署 Web 服务器和其他类型的互联网服务。

Azure Kubernetes 服务

Azure Kubernetes 服务（AKS）支持 Azure 中的 Kubernetes 容器化编排 (azure.microsoft.com/en-ca/products/kubernetes-service/)。

AKS 是专为 Kubernetes 集群设计的，因此它是部署基于 Kubernetes 的应用程序到 Azure 的最佳方式。我能够在几分钟内通过 AKS 在 Azure 上部署 Kubernetes，而在没有 AKS 的情况下在 Azure 上部署 Kubernetes 至少需要数小时的工作，并且过程充满麻烦：

图 7.3 – AKS 的截图

有关 AKS 的更多信息，请参考第九章！

Azure 容器实例

Azure 容器实例（ACI）使 Azure 客户能够开发和部署自己的软件应用程序，而无需管理虚拟机或学习新工具：

图 7.4 – ACI 的截图

ACI 可以与 AKS 和 Azure Functions（更多内容将在下一节介绍）一起使用，以支持具有大量容器的复杂应用程序。

Azure 专用主机

Azure 专用主机是用于托管运行 Windows 和 Linux 的 Azure 虚拟机的专用物理服务器。是的，通过 Azure 专用主机，你的组织可以在微软的场地上拥有自己的物理服务器。这是一个相对昂贵的选择，适合那些有预算的企业，但它为企业提供了在 Azure 生态系统中能够获得的最大控制权：

图 7.5 – Azure 专用主机的截图

现在，让我们来看看 Azure 中的 PaaS。

Azure PaaS 应用程序

Azure PaaS 在控制和自主性方面介于 SaaS 和 IaaS 之间，具体取决于 Azure 客户（例如你所在的商业组织）。

在 PaaS 中，Azure 提供平台。只有 Azure SaaS 提供 Azure 自己的完整应用程序，客户可以将数据部署到其中，而 Azure IaaS 基本上提供 Azure 的服务器硬件和网络基础设施，几乎没有 Azure 的代码。在 IaaS 部署中，绝大多数代码属于客户，并由客户负责。

这是 Azure PaaS 服务，客户在这些平台系统中运行他们开发的应用，而这些系统由 Microsoft 开发。

Azure SQL 数据库

Azure SQL 数据库使客户能够构建带有 SQL 数据库的应用程序。SQL 是顶级的供应商中立数据库开发技术之一。需要后端服务支持的各种类型的应用程序使用 SQL，不仅仅是移动应用或 web 应用。

Web 应用

Web 应用用于托管 ASP.NET web 应用程序。ASP.NET 是一个开发平台，提供构建 web 应用的工具、编程语言和库。它使用 HTML、CSS、JavaScript、Node.js、Python、Java 和 C#。

移动应用

移动应用是 Microsoft Azure 提供的服务，用于部署各种 iOS 和 Android 应用的后台。它通过 Azure Active Directory 部署单点登录（SSO）认证，支持与 Facebook、Twitter 和 Google 的 API 集成。它还使应用能够在长时间离线的情况下工作，尽管移动应用应定期在线以进行同步。

Azure 逻辑应用

Azure 逻辑应用是一个非常专业的逻辑应用开发工具。逻辑应用可以创建和自动化工作流，而无需编写大量代码。逻辑应用可以通过图表构建，其中事件触发相应的动作。

Azure Functions

Azure Functions是一个无服务器计算平台，意味着 Azure 客户可以部署应用程序而无需管理服务器。Azure Functions 是事件驱动的，这意味着如果在你组织开发的应用程序中发生某些定义的事件，Azure Functions 将根据你定义的方式响应这些事件（azure.microsoft.com/en-us/products/functions/）。

现在，让我们看看 Microsoft 为 Azure 用户提供的用于管理网络安全的应用程序。

Azure 安全控制和工具

可以使用 Microsoft Azure 部署具有卓越安全性的云网络。但是，网络安全是日常工作。作为一名云渗透测试员，你将执行渗透测试、红队演练和漏洞扫描，这些工作将为组织提供所需的漏洞数据，帮助其不断加强网络和应用的安全性。防御安全专家需要将你的安全建议付诸实践，并且实际使用 Microsoft 为 Azure 提供的各种安全工具。

使用 Azure 可以实现卓越的网络安全。但你需要付出努力，并使用 Microsoft 提供的工具！

安全控制

微软提供了多个应用程序，帮助你的组织维护其在 Azure 中的应用和服务的网络安全。这些应用同样对于渗透测试人员检查 Microsoft 自身安全控制能够发现的安全警报和漏洞非常有用。

以下是微软提供的主要安全控制措施，用于确保 Azure 的安全。

Microsoft Defender for Cloud

Microsoft Defender for Cloud 是其主要的统一云原生应用保护平台。如果你已经熟悉 Windows 中的 Microsoft Defender，Microsoft Defender for Cloud 包含了许多这些功能，并且在此基础上进行了扩展，增加了保障云网络安全所需的功能。

Microsoft Defender for Cloud 不仅提供对 Azure 中安全状况的可见性，还能在 AWS、GCP 和组织的本地网络中提供可见性。它为各种服务提供反恶意软件和安全监控。管理员可以看到经过优先级排序的关键风险，并具有上下文感知的安全性。它还提供 扩展检测与响应(XDR) 来检测和响应网络攻击。你甚至可以看到有关网络合规性的实时数据。

如果 Microsoft Defender for Cloud 正在你进行渗透测试的服务中运行，组织应该能够看到你正在模拟的网络攻击的详细信息！

Microsoft Defender 外部攻击面管理

Microsoft Defender 外部攻击面管理(Defender EASM) 基于 Microsoft Defender 的基本功能进行扩展。组织可能会有独特的外部网络攻击面。Defender EASM 会发现未知的资源，帮助组织全面了解其安全状况。

Defender EASM 动态工作并实时更新，因此管理员可以在新的外部面向资源出现时获得警报。

注意

Shadow IT 是许多组织中的一个重大问题。Shadow IT 是指员工、承包商及其他公司内部人员在使用公司网络时，使用了自己的应用程序和设备。Shadow IT 的问题在于，内部人员将新技术引入公司网络时，这些技术并未由公司的网络安全或 IT 团队进行管理。因此，Shadow IT 可能会引入新的攻击向量、漏洞和恶意软件，而组织往往对此毫不知情。Shadow IT 是 Defender EASM 能够检测和缓解的众多外部风险之一。

Azure DDoS 保护

Azure DDoS 保护顾名思义。在 DDoS 攻击中，网络攻击者通过巨大的恶意数据流量淹没你的应用和网络服务，目的是使它们崩溃。这是对网络安全中机密性、完整性和可用性（CIA 三元组）中的“可用性”发起的重大攻击。分布式部分意味着攻击者利用多个分布式机器来执行攻击。DDoS 攻击最常用的方法是使用僵尸网络，这些设备通常是被恶意软件感染的计算设备，包括任何类型的 PC、服务器、手机、平板电脑、物联网设备和路由器。攻击者通过其指挥与控制（C2）服务器控制这些僵尸网络。因此，僵尸网络提供了大量计算能力，可用于执行 DDoS 攻击。

Azure DDoS 保护使用自适应的威胁智能（TI）结合人工智能（AI）和 DDoS 缓解能力。后者功能利用微软的数据处理和网络基础设施，在攻击者的大量恶意数据对你的组织 Azure 服务和应用造成损害之前，将这些数据吸收掉。

Azure Bastion

Azure Bastion使得组织能够以安全的方式部署对虚拟机的远程访问。这是一个常见需求，因为如今企业支持的远程工作者比以往任何时候都多。如果员工从家里连接到他们雇主的 Azure 托管虚拟机，应通过 Azure Bastion 进行路由。

可以随时在 Azure 门户中发起 RDP 和 SSH（常见远程网络互联网协议）会话的直接连接。你组织的虚拟机无需额外的软件即可使用 Azure Bastion。Azure Bastion 与防火墙和其他安全控制集成。最重要的是，Azure Bastion 防止分配给虚拟机的 IP 地址暴露给公众。这使得外部网络攻击者更难访问并危害你组织的虚拟机。

Azure 防火墙

Azure 防火墙旨在安全地管理并限制对组织 Azure 虚拟网络（VNet）的访问。可以动态拒绝来自恶意 IP 地址和域的流量。它使用传输层安全性（TLS）来防止通过加密会话传播恶意软件。网络和应用防火墙规则可以在组织的所有虚拟网络中进行管理。

Azure 防火墙还具备内置的入侵检测与防御系统（IDPS）功能，能够生成安全事件警报，输出日志，并实时阻止多种攻击。因此，它不仅具有根据一系列安全规则阻止或过滤流量的基本防火墙功能，还通过使用机器学习（ML），根据你组织的网络流量模式，随着时间推移不断提升其功能。

Azure Web 应用防火墙

Azure Web 应用程序防火墙（WAF）是一个专门针对 Web 应用程序的防火墙。开放 Web 应用程序安全项目（OWASP）是一个维护 Web 安全标准的组织，包括其十大安全风险。Azure WAF 专门设计用来缓解这些风险。

针对 Web 应用程序和 Web 服务器的特定技术有很多，因此 Azure WAF 被设计为在这种用例中本地工作。

Azure 防火墙管理器

Azure 防火墙管理器作为一个独立的应用程序列出。它仅作为 Azure 防火墙的配置和管理界面。它为管理员提供一个统一的控制平面仪表板，让他们可以随时看到 Azure 防火墙的所有操作，并查看安全警报。多个 Azure 防火墙实例可以通过一个 Azure 防火墙管理器控制平面进行管理。它还可以与第三方安全即服务（SECaaS）应用程序集成。

Microsoft Sentinel

Microsoft Sentinel是一个安全信息和事件管理（SIEM）系统，直接集成到 Azure 中。如果你的组织有安全运营中心（SOC），他们可能会使用它。

SOC 是做什么的？

SOC 是一个防御性网络安全团队和部门，负责实时监视安全事件和事故并对其做出响应。

SIEM 系统分析输入到系统中的各种网络和服务器日志，并在看起来可能发生安全事件（通常是网络攻击）时，向 SOC 分析人员显示安全警报。

SOC 在事件响应（IR）中扮演着重要角色。他们的工作是在攻击或泄露发生时尽早缓解或遏制事件，以尽可能减少损害。

通俗来说，使用 Microsoft Sentinel，SOC 分析人员可以查看一个控制平面和仪表板，显示通过网络和应用程序活动发现有不良事件正在发生。当确实出现严重问题时，SOC 分析人员会收到通知，内容大致是“危险，危险！”。然后，他们可以使用 Microsoft Sentinel 调查该事件，帮助阻止坏事发生。

密钥保管库

密钥保管库存储了你组织在 Azure 中使用的各种加密密钥和机密。密钥和机密用于获取对敏感数据和应用程序的特权访问。如果这些密钥落入不当之手，那将是非常危险的。因此，它们被保存在一个比喻的保险库中！

密钥保管库确保应用程序无法直接访问密钥。密钥既可以由密钥保管库创建，也可以导入到密钥保管库中。

你组织尽可能多的传输数据和存储数据应当被加密。这是网络安全基础 101的一部分。将明文数据加密为密文垃圾串，保护了 CIA 三原则中的机密性和完整性。

Azure 拥有您组织需要的所有工具，以确保所有存储和传输中的数据都经过强加密。应使用 Key Vault，以确保未经授权的人员和网络攻击者无法“解锁”其中任何数据。

Microsoft Azure Attestation

Microsoft Azure Attestation 存在的原因是，组织部署的 Azure 云不仅仅实现了 Azure 生态系统内的实体。许多组织还将第三方服务和应用程序集成到其 Azure 网络中。Microsoft Azure Attestation 在与这些平台交互之前，验证第三方平台的身份和安全态势。

您的组织有许多不同的安全政策、基准和标准。Microsoft Azure Attestation 将验证这些是否可以在第三方平台上建立。如果可以，Microsoft Azure Attestation 可以确保这些安全政策、基准和标准通过这些平台得以执行。

Active Directory 是 Windows Server 用来管理用户账户、用户组和管理员账户安全的工具。Azure Active Directory 将这些 IAM 功能扩展到 Azure。

控制用户账户可以执行的操作是安全运营的重要组成部分，同时确保这些账户具有适当的身份验证和授权也至关重要。控制平面提供了账户使用情况的完全可视化。Azure Active Directory 还实现了 SSO 和 多因素认证（MFA）系统。MFA 是绝对必要的！MFA 通常不是默认启用的，但它应该是。即使是最强的密码也容易受到数据泄露和某些类型的密码分析攻击的威胁。通过生物识别和 一次性密码（OTP）/PIN 应用等额外的身份验证方式来增强密码的安全性，可以大大提高账户的安全性。

Azure 信息保护

Azure 信息保护（AIP）是另一种描述其功能的通用名称。它通过根据敏感性标签对数据进行分类，并确保这些数据仅在允许的情况下与外部共享，从而执行大量的 数据丢失防护（DLP）功能。

AIP 可以保护文档、许多其他类型的文件和电子邮件。作为网络安全从业者，我们时刻将电子邮件附件视为恶意软件的传播途径。我们也意识到，带有指向危险钓鱼网站链接的钓鱼邮件频繁被发送和接收。但电子邮件也是突破机密或敏感数据的主要途径！AIP 有助于防止通过电子邮件泄露敏感数据。

Azure 专用 HSM

Azure 专用 HSM 是一种非常专业的 Azure 网络安全应用。HSM 代表 硬件安全模块。HSM 是一种物理计算设备，通常大小与 RAM 或显卡相似，用于保护加密密钥、执行数字签名的加密和解密操作，并通过其他方式确保强身份验证。

组织可以在其端点和客户计算机以及本地网络中使用 HSM 设备。 Azure Dedicated HSM 是支持在 Azure 云平台上运行的 HSM 的后端。 Azure Dedicated HSM 可用于管理组织内的 HSM 访问，并将其配置为与 Azure 服务配合使用。

VPN 网关

VPN 网关使组织能够将自己的 VPN 基础架构与其 Azure 服务集成。 VPN 是通过计算机网络在两个端点之间实现端到端（E2E）加密的一种方式，通常通过互联网实现。 企业通常拥有自己的 VPN 服务器，以便完全控制该技术的使用方式。

许多组织要求在诸如远程办公并连接到雇主网络以及保护员工出差和自带设备（BYOD）政策等使用情况下使用 VPN。 一个好的 VPN 可以防止中间人（MITM）攻击，即网络攻击者拦截网络会话以侵犯机密性或篡改网络传输数据的完整性。

应用配置

应用配置适用于在 Azure 中开发和部署自己的应用程序的组织。 应用配置使组织能够统一安全配置设置，涵盖其所有 Azure 应用程序和应用程序用户。 这对于遵守监管合规性和符合组织自身安全政策尤为有用。

如果应用程序配置存在关键问题，可以实时修复问题，而无需重新部署应用程序。 如果多个应用程序之间共享的组件存在安全漏洞或配置错误，也可以进行故障排除和修复。

这就是微软为 Azure 客户提供的所有主要安全控制措施，以帮助他们提高 Azure 网络、应用程序和服务的安全性。

现在，让我们来看看一些顶级第三方 Azure 渗透测试和漏洞扫描工具！

安全工具

Azure 有许多由第三方开发的漏洞评估和渗透测试工具。 作为渗透测试人员，您可能会使用其中至少一些！ 在第 8和第 9章中，我将指导您使用其中一些工具，以便您可以按照 Microsoft 的 Azure 政策允许的方式发现 Azure 的网络安全漏洞。

Prowler

如果您已经阅读了关于 AWS 渗透测试的第 5和第 6章，您可能已经熟悉Prowler（github.com/prowler-cloud/prowler）。 Prowler 也可以用于对 Azure 进行渗透测试！ Prowler 可以从 CLI 运行，检查常见的安全配置错误，并根据 CIS 基准进行漏洞扫描。

与 AWS 一样，当您在 Azure 上使用 Prowler 时，您可以生成漏洞扫描日志，这些日志为您提供可以直接用于渗透测试报告的数据，并附有 常见漏洞评分系统(CVSS) 的漏洞评分，涵盖严重、高、中、低四个类别。

MicroBurst

MicroBurst 是一组由 NetSPI 开发的 Microsoft Azure 安全评估脚本 (github.com/NetSPI/MicroBurst)。

它可以发现您网络中的 Azure 服务，审计弱配置，并模拟网络攻击者的行为，例如凭证转储。

MicroBurst 与 Az、AzureAD 和 MSOnline PowerShell 模块一起工作。PowerShell 是 Microsoft 用于管理 Windows Server 和 Azure 的命令行界面。

MicroBurst 使用 Az 模块从应用服务、存储帐户、Cosmos DB、密钥保管库、自动化帐户和 AKS 获取敏感的密码、密钥、证书以及其他敏感的身份验证和授权秘密。

AzureAD

AzureAD 是一个已过时的 PowerShell 模块，因此，已妥善修补且不支持遗留系统的 Azure 部署将不会使用它。但是，如果您正在对具有遗留系统的 Azure 实例进行渗透测试（这些系统本身就容易受到攻击！），AzureAD 模块将帮助 MicroBurst 利用与 Azure 中如何实现 Active Directory 相关的漏洞。不安全的 Active Directory 配置可能导致危险的权限提升攻击！它们还可能导致攻击者获得对特权用户帐户的未经授权访问。Active Directory 是 Azure 和 Windows Server 中 IAM（身份和访问管理）工作的核心，因此发现和减轻 Active Directory 漏洞至关重要。

MSOnline

MSOnline 是另一个过时的 PowerShell 模块，因此它仅对支持旧版 Azure Active Directory 的遗留系统的 Azure 网络有用。MSOnline 模块使 MicroBurst 支持类似于 AzureAD 模块的 IAM 相关漏洞利用。

PowerZure

PowerZure (github.com/hausec/PowerZure) 是另一个与 PowerShell 配合使用的有用 Azure 渗透测试工具，由 hausec 开发。

与 MicroBurst 一样，PowerZure 使用 az PowerShell 模块扫描 Azure 中的 Active Directory 漏洞。PowerZure 可以利用漏洞进行信息收集、数据提取和恶意凭证访问。一旦安装了 PowerZure，它可以通过一些简单的命令在 CLI 中执行。

ScoutSuite

ScoutSuite (github.com/nccgroup/ScoutSuite) 是一个由 nccgroup 开发的 CLI 应用程序。nccgroup 曾开发过 Azucar，一种 "用于 Azure 环境的安全审计工具"。由于不再维护 Azucar，nccgroup 推荐使用 ScoutSuite 替代它。

ScoutSuite 是一个多云安全审计工具。 因此，与 Prowler 一样，它也可以用于 AWS 和 GCP。 ScoutSuite 还在开发支持阿里云和 Oracle 云基础设施(OCI)，这两个云平台在本书中没有涵盖。

ScoutSuite 扫描 API 以查找常见漏洞，使用该工具可以让渗透测试人员更准确地了解其云环境的外部网络攻击面的范围。

Azurite

蓝宝石 (github.com/FSecureLABS/Azurite) 是由 FSecureLABS 开发的，包括两个组件——Azurite Explorer 和 Azurite Visualizer。 Azurite 是一种新颖的使用 PowerShell 进行 Azure 渗透测试的方式。让我们稍微详细地看一下它的组件：

• Azurite Explorer 可以导入 PowerShell 模块来指纹识别 Azure 实例并检索敏感配置数据。 这是个坏消息，作为 Azure 渗透测试人员，你需要警惕并模拟。 如果真正的网络攻击者知道你的组织的 Azure 服务和帐户如何配置，他们可以造成很大的伤害！

• Azurite Visualizer 从 Azurite Explorer 的输出中生成数据可视化。 可视化可以帮助渗透测试人员和安全管理员更好地了解不同 Azure 漏洞之间的关系。

Azurite 扫描以下 Azure 组件：

• VNets

• 子网

• VNet 网关

• Azure SQL 服务器

• Azure SQL 数据库

• Azure 网站

• Azure 密钥保管库

云刀

云刀 (github.com/Azure/Cloud-Katana) 是由 Microsoft 领导开发的开源工具。 云刀 (cloud-katana.com/intro.html) 用于评估和评估客户在其 Azure 网络中使用的安全工具。 它是一个构建在 Azure Functions 之上的无服务器应用程序。

SkyArk

SkyArk (github.com/cyberark/SkyArk) 是由 CyberArk 开发的，用于发现、评估和保护 Azure 中最特权的实体。 它也适用于 AWS。

SkyArk 的 AzureStealth 模块用于扫描 Azure 环境。

SkyArk 的目的很简单——发现最特权的云用户！

如果网络攻击者能够获取高度特权的 Azure 帐户的恶意访问权限，他们可以造成巨大的破坏。 他们可以在 Azure 环境中安装各种恶意软件，获取非常敏感的数据，甚至使 Azure 网络完全失效。 如果他们可以访问管理帐户，数据泄露和勒索软件部署是攻击者可以轻松执行的两个主要网络安全问题！

云影子管理员是一个重大的安全风险，SkyArk 将帮助渗透测试人员和安全管理员发现它们，并防范给予攻击者特权和管理访问权限的漏洞。

MFASweep

MFASweep（github.com/dafthack/MFASweep）是由 dafthack 开发的一个工具，用于检查多种 Microsoft 服务中是否启用了 MFA，包括用于 Azure 的服务。

与云影子管理员（这是一种非常、非常糟糕的情况）不同，MFA 是一项非常、非常好的安全措施！希望在使用 MFASweep 时，能发现贵组织所有的 Azure 账户都启用了 MFA！

密码经常在数据泄露中暴露，因此网络安全界普遍认为，保护账户启用 MFA 是必要的。密码的第二因素可以是生物识别扫描（如指纹和虹膜扫描）或发送到用户设备的 OTP，且该 OTP 会在几分钟内过期。

MFASweep 扫描以下服务：

• Microsoft Graph API

• Azure 服务管理 API

• Microsoft 365 Exchange Web Services

• Microsoft 365 Web 门户（Windows、Linux、macOS、Android 手机、iPhone、Windows Phone）

• Microsoft 365 ActiveSync

• Active Directory 联邦服务(ADFS)

Azure AD Connect

Azure AD Connect 密码提取工具（github.com/dirkjanm/adconnectdump）由 Foxit 开发。它正如其名所示，利用了 Azure 中 Active Directory 配置的漏洞来提取密码。如果真正的网络攻击者能够做到这一点，那么贵组织的 Azure 网络存在一些非常危险的 Azure 漏洞！

该工具包可以从 Azure Active Directory 中提取高度特权的凭证。

CloudBrute

CloudBrute（github.com/0xsha/CloudBrute）是由 0xsha 开发的多云枚举工具。如果贵组织的网站和 Web 应用程序有公开的 URL，那么确保贵组织的云网络中敏感部分不被暴露给网络攻击者是非常重要的。

CloudBrute 不仅适用于 Azure 和其他 Microsoft 服务，还适用于 AWS、GCP、DigitalOcean、阿里巴巴、Vultr 和 Linode。

CloudBrute 将帮助你发现贵组织是否通过互联网暴露了敏感的云实体。暴露的服务是云网络攻击的重要攻击向量！理想情况下，任何服务都不应该以使其易受网络攻击的方式暴露。

BlobHunter

BlobHunter（github.com/cyberark/blobhunter）是 CyberArk 提供的另一个工具。与 CloudBrute 一般查找暴露的云服务不同，BlobHunter 查找在互联网上公开可访问的 Azure Blob 存储容器。

它可以发现配置不当的容器，这些容器可能存储大量敏感数据。在攻击者找到之前，先发现这些配置错误！

如你所见，Azure 中有广泛的应用程序，同时也有许多第三方工具用于对 Azure 进行渗透测试。

总结

微软 Azure 提供了多种 SaaS、PaaS 和 IaaS 应用程序和服务。您的组织将根据具体的业务需求选择使用哪些 Azure 组件。

微软还提供了多种安全控制措施，使得 Azure 实例能够实现有效的网络安全。这包括通过 Active Directory 保护身份和访问管理（IAM）、防止暴露服务，并保护高度敏感的加密密钥以及其他类型的认证数据和组件。

许多第三方开发了开源的 Azure 渗透测试和漏洞扫描工具，作为渗透测试员，您将使用这些工具。使用这些工具是发现 Azure 环境中漏洞的有效方法，同时避免违反微软的渗透测试政策。

在下一章，我们将部署我们自己的 Azure 网络并在其中进行一些渗透测试。

进一步阅读

要深入了解本章涉及的主题，您可以访问以下链接：

• Microsoft Azure 服务列表： azure.microsoft.com/en-ca/products/

• Microsoft Azure 对 PaaS 的定义： azure.microsoft.com/en-ca/resources/cloud-computing-dictionary/what-is-paas

• Microsoft Azure 对 IaaS 的定义： azure.microsoft.com/en-ca/resources/cloud-computing-dictionary/what-is-azure/azure-iaas/

• Kyuu-Ji 在 GitHub 上的 Azure 渗透测试工具合集： github.com/Kyuu-Ji/Awesome-Azure-Pentest

第八章：通过无服务器应用程序和工具进行 Azure 渗透测试

在上一章中，我们查看了 Azure 提供的各种 SaaS、PaaS 和 IaaS 服务。

现在，是时候在你自己的 Azure 部署中实际进行一些漏洞扫描和渗透测试了！这将会既有趣又富有教育意义。如果你已经阅读过 第五章，通过无服务器应用程序和工具进行 AWS 渗透测试，我们将在本章进行类似的工作，但是在 Azure 上。

本章将提供一个逐步指南，教你如何使用 Azure 自有的第一方安全工具检查安全配置并进行漏洞评估。重点介绍的工具是 Microsoft Defender for Cloud 和 Azure Firewall Manager。之后，我们将学习如何配置最流行的第三方 Azure 渗透测试工具。重点介绍的工具有 Prowler、MFASweep 和 ScoutSuite。最后，我们将通过 Prowler、MFASweep 和 ScoutSuite，查看渗透测试教程，找出凭证、列举 Azure 服务、进行漏洞扫描，并发现暴露的服务。

本章将涉及以下主题：

• 设置 Azure 实例

• 设置 Azure 账户

• 使用 Azure Cloud Shell 和 PowerShell

• Azure 原生安全工具

• Azure 渗透测试工具

• 利用 Azure 应用程序

那么，让我们开始一些实际的练习吧！

技术要求

我们将与 Microsoft 的基础设施合作。本章练习中的大部分计算处理将由庞大的 Azure 数据中心完成。所以，幸运的是，你不需要拥有顶级工作站。你需要以下设备：

• 一个网页浏览器

• 一台桌面或笔记本电脑

• 一部 Android 或 iPhone 智能手机

• 一个良好的、可靠的互联网连接

请查看以下视频，查看代码实战：bit.ly/3rUulqT

设置 Azure 实例

任何人都可以设置自己的 Microsoft Azure 账户。许多 Azure 服务是免费的。我强烈建议你在为客户做付费工作之前，先部署自己的 Azure 实例来练习漏洞扫描和渗透测试，这样你可以练习你的技能。而且你在 Azure 上进行的测试部署可能比你所在组织的 Azure 网络还要简单！

多亏了云计算的魔力，以及计算处理、数据存储和带宽都托管在 Microsoft 的基础设施上，你不需要拥有一台强大的工作站电脑就能尝试本章中我所演示的练习。一台典型的桌面或笔记本电脑，配备 Windows、macOS 或 Linux，良好的网络功能和现代浏览器就足够了。

首先，打开你的网页浏览器，访问 Microsoft 免费 Azure 服务的指南（azure.microsoft.com/en-ca/free）。以下是截至 2023 年本书撰写时大部分免费的 Azure 服务：

• Azure Active Directory 始终免费，但你被限制为 50,000 个存储对象，并提供单点登录（SSO）身份验证接口。同样，对于你的测试部署，这应该不是问题。

• Azure Advisor 服务始终免费且不限量。Advisor 提供个性化建议，并识别使用 Azure 的最佳实践。

• 你可以免费使用 12 个月的Anomaly Detector服务。Anomaly Detector 利用人工智能（AI）和机器学习（ML）帮助你在 Azure 中排除技术问题。

• Azure App Configuration 始终免费，但每日请求数限制为 1,000 次，存储空间为 10 MB。你的 Azure 测试部署不太可能超过每日 1,000 次请求。App Configuration 用于管理和存储你的 Azure 应用配置。

• Azure App Service 始终免费。App Service 使你能够使用 PHP 和 Node.js 等工具为任何平台或设备创建应用。你被限制为 10 个应用，存储为 1 GB，每天使用 1 小时。对于你的测试部署来说，这不太可能成为问题。

• Azure DevOps 始终免费，但限制为五个用户。Azure DevOps 帮助通过 CI/CD 方法构建应用，使用 Git 存储库。基本上，如果你的应用需要每天进行多次更新，Azure DevOps 将帮助你实现这一目标。

• Azure Files 在前 12 个月是免费的。它使你能够跨平台迁移文件，而无需更改任何代码。但你被限制为 100 GB 的本地冗余存储（LRS）事务和 200 万次文件操作。这对于一些企业客户可能会有些限制，但对于你的测试部署来说不太可能是个问题。（LRS 是指将数据同步复制到三个磁盘上。）

• Azure Kubernetes Service（AKS）始终免费。这非常重要，因为 Kubernetes 容器化是云网络中最常见的用例之一！你将在第九章中了解在 Azure 中渗透测试 Kubernetes 容器化。

• Azure Lighthouse 始终免费。它允许你在“零信任”网络安全模型下，管理与你的 Azure 网络接口的不同服务提供商。零信任是比旧的周界安全模型更安全的一种替代方案。与其有一个周界，信任内部的计算机，外部是互联网和其他不受信任的计算机，并在周界进行身份验证，零信任在所有可能的点创建身份验证矢量，并默认不信任所有未经身份验证的数据传输，即使它们来自你自己的网络内部。

• Azure Maps 是 Azure 生态系统中类似于 Google Maps 的服务。它拥有许多 API 和功能，并且与所有 Azure 应用程序本地集成。您可以在移动设备、桌面和 Web 应用程序中使用自定义嵌入地图。在您开发的应用程序中使用 Azure Maps 是免费的，但特定的地图和位置洞察功能限制为 1,000 到 5,000 个事务。

• Azure Migrate 总是免费的。它帮助您将虚拟机（VMs）从您的本地环境或其他云平台迁移到 Azure。

• Azure Policy 帮助您遵守数据隐私和网络安全法规。这对您的雇主可能比您的 Azure 测试部署更为重要。但您可以免费访问配置和更改跟踪功能。

  首次 12 个月内，您将免费获得 15 GB 的出站数据传输带宽，并且始终免费获得 100 GB 的入站数据传输。

• Blob 是一种非结构化数据对象。在 Blob Storage 中，首次 12 个月内免费获得 5 GB 的 LRS 存储空间，包括 20,000 次读取和 10,000 次写入操作。但我不预期您会在测试部署中使用 Blob Storage。

• 就 Cloud Shell 而言，在 Azure 文件中免费获得 5 GB 存储空间，首次 12 个月免费。这是 AWS CloudShell 的 Azure 等效，我在 第 5 和 第 6 章中演示了它。在 Web 浏览器中访问 CLI 非常重要，您几乎肯定也会在 Azure 测试部署中使用 Azure Cloud Shell！

• Container Apps 总是免费的，但有一些限制。Container Apps 可以在无服务器容器中部署应用程序和微服务，但您的使用受到 180,000 vCPU 秒、360,000 GiB 秒和 2 百万请求的限制，除非您愿意额外付费。

• 容器注册表 在 Azure 生态系统中存储和管理容器映像。首次 12 个月免费，但您的限制为一个标准层注册表，包括 100 GB 存储和 10 个 Webhook。

• 成本管理 总是免费的。因此，您不需要额外付费来节省和优化 Azure 云服务的费用，可以全面了解您的支出情况。当然，如果始终保持在免费服务及其限制内，那么就根本不会有支出！但无论如何，您都可以通过成本管理进行检查。

• 数据库迁移服务 使数据库从本地服务器迁移到云更加轻松。但是在测试部署中，免费标准计算级别总是免费的。

• DevTest Labs 让开发人员能够在开发/测试环境中测试其工作。它总是免费的。

• Event Grid 保证在大规模下可靠地传递事件，以促进服务集成。它总是免费的，但您每月的操作限制为 100,000 次。这应该足够了！

• 函数使得可以使用无服务器代码架构处理事件。万一你需要使用它，1,000,000 次请求始终免费。

• 密钥保管库安全地存储你在 Azure 服务中使用的加密密钥。它的服务在前 12 个月免费，但你限于 10,000 次事务、RSA 2048 位密钥或标准级别的机密操作。

• 在前 12 个月内，你可以免费获得一定数量的 Linux 虚拟机。限制是 750 小时的 B1s 弹性虚拟机。

• 负载均衡器确保你的 Azure 部署根据任何给定时刻的需求，在服务器间平衡使用。在前 12 个月内，你可以免费获得 750 小时、15 GB 数据处理和最多五个规则的标准负载均衡器。

• 托管磁盘是用于 Azure 虚拟机块存储的服务。在前 12 个月内，你可以免费获得 2 个 64 GB SSD 存储驱动器、1 GB 快照和 200 万次 I/O 操作。超出部分将产生费用！

• 媒体服务让你能够将流媒体部署到任何设备上，如流视频或音频。你可能在测试部署中不需要这样做，但万一需要，你可以在前 12 个月内免费获得每项 5 小时的标准通道、实时转录和标准流媒体端点服务。

• 监控让你可以全面了解和观察你的应用程序、基础设施和网络。每个功能有不同的限制，但除此之外，它始终免费。

• 网络观察器帮助你监控、诊断并理解你的 Azure 网络性能。它始终免费，但你限于 5 GB 存储，1,000 次检查，10 次测试和 10 个连接度量。

• 通知中心允许你向任何移动设备（iOS 和 Android）发送推送通知。你限于 100 万次推送通知，但这些是免费的。不过，如果你用 Azure 部署移动应用，才需要关注这个限制。

• 私有链接让你可以从任何自己的端点私密地访问你的 Azure 服务。它始终免费。

• 资源管理器让你查看应用资源的使用情况，并使你能够管理它们。它始终免费。

• 安全中心使你能够在所有 Azure 部署中防止、检测和响应威胁。策略评估和建议始终免费！

• 很可能你的 web 应用和其他基于数据库的应用需要 SQL 数据库。在前 12 个月内，你可以免费获得一个 250 GB S0 实例，并附带 10 个数据库事务单元。

• SQL Server 2019 开发版让你可以在生产环境之外构建、测试和展示应用程序。它始终免费。

• 在前 12 个月内，你也可以免费获得一定数量的 Windows 虚拟机。同样，限制是 750 小时的 B1s 弹性虚拟机。

• 你将免费获得 50 个 虚拟网络 实例，永久有效。但这是用于配置私有网络并将其连接到你本地的数据中心。对于你的测试部署来说，这不太可能是必需的。

• VPN 网关 使得在数据中心和云服务之间部署 VPN 成为可能。这能非常有效地加密你的传输数据。前 12 个月内，你可以免费使用 750 小时。但这可能是对于你所在的组织来说，比对于你的 Azure 测试部署更有用的服务。

让我们部署一个 Azure 实例，供你用于测试目的。

设置 Azure 账户

启动你的第一个 Azure 实例并练习渗透测试技能所需的所有操作都可以通过网页浏览器完成。以下是操作步骤：

1. 当你进入 Azure 免费服务网页时（azure.microsoft.com/en-ca/free），点击绿色的 开始免费 按钮：

图 8.1 – Azure 免费账户创建页面

你将被引导到一个登录微软账户的页面。如果你在家使用 Windows 10 或 Windows 11，可能已经拥有微软账户。你可以选择使用现有的微软账户，创建一个新的微软账户（即使你已经有另一个微软账户，也可以创建新的账户），或者如果有 GitHub 账户，可以用 GitHub 凭证登录。

我决定使用我已经拥有的微软账户。我对网络安全很谨慎，所以我已经在我的 Android 手机上通过微软身份验证器设置了 多因素身份验证（MFA）。我使用密码和通过微软身份验证器发送到我手机的验证码成功登录。微软身份验证器适用于 Android 和 iOS，且免费使用，我强烈建议你在使用 Azure 服务时使用它。你可以在这里了解更多关于微软身份验证器的信息：www.microsoft.com/en-ca/security/mobile-authenticator-app。

为确保没有任何混淆，我使用手机进行微软身份验证器（Microsoft Authenticator），但我使用 Windows 11 笔记本电脑通过其网页界面与 Azure 进行工作。从手机管理云服务不太实际。幸运的是，MacBook 或 Linux 电脑与 Windows 电脑一样适合这项工作。

1. 登录后，我被引导到一个表单，填写了我的姓名、所在地区（在我的情况中是加拿大）和电话号码。我还获得了 200 美元的信用额度，可以在前 30 天内使用！谢谢，微软。我的电话号码通过短信进行了验证。然后，我填写了我的家庭邮寄地址并同意了客户协议。在表单底部，点击 下一步。

2. 然后，你将看到一个需要输入信用卡信息的屏幕。即使你正在使用免费服务，这一步也是必须的。如果你使用了任何收费服务或超出了免费服务限制，信用卡将会被扣费。我建议使用 Azure 的成本管理应用来密切关注这一点！

   在底部，点击那个蓝色的注册按钮。

3. 等待片刻，账户将会被设置好。然后，你将看到一个显示你已准备好开始使用 Azure的屏幕。点击那个蓝色按钮，按钮上写着前往 Azure 门户。听起来非常激动人心！我们将一起踏上云服务之旅。

   快速入门中心将为你展示多种不同的选项，帮助你开始使用。你可以参加在线课程、跟随设置指南或开始一个项目。在项目和指南标签下的项目选项有：

   • 创建一个Web 应用

   • 部署虚拟机

   • 部署并运行一个基于容器的应用

   • 设置数据库

   • 开始数据分析、机器学习和智能化工作

   • 存储、备份或归档数据

   • 构建、部署并运营一个无服务器应用

   你可以在这里看到概述：

图 8.2 – Microsoft Azure 快速入门中心

现在，让我们来部署一个虚拟机。（我们将在第九章中部署并运行一个基于容器的应用。）

1. 接下来，你将有机会创建一个 Windows 虚拟机或 Linux 虚拟机：

图 8.3 – 从快速入门中心部署虚拟机的屏幕

因为在 AWS 章节中我使用了 Linux 虚拟机，所以我们来点不同的，选择一个 Windows 虚拟机。但是如果你创建一个 Linux 虚拟机，你可以在 CLI 中使用我在第五章中为 AWS 使用的 Linux Bash 命令。

1. 下一屏幕顶部显示创建虚拟机。你将需要填写一个表单：

   • 在项目详情下，保持订阅为默认值或Azure 订阅 1。在资源组下，保持为（新建）资源组。

   • 在实例详情下，为虚拟机取一个你容易记住的名字。我输入了PentestingWindowsVM。不允许使用空格和特殊字符！

   • 我选择了（美国）东部美国作为我的区域。但你可以选择任何你喜欢的区域。它甚至不需要靠近你的实际位置。你可以在印度并选择（欧洲）挪威东部，如果你愿意的话！

   • 在可用性选项下，我选择了不需要基础设施冗余。如果你希望避免服务费用，这是最安全的选择。不过，你所在的组织需求远大于你的测试部署，可能会选择不同的选项。

   • 在 安全类型 下，我选择了 标准。这是针对你自己的测试部署来说最安全的选择，可以避免产生服务费用，但对于企业、机构或大公司来说，可能需要选择更高的安全级别。

   • 我保留了默认的 Windows Server 2016 数据中心作为我的镜像。x64 是该镜像的唯一虚拟机架构选项。另外，ARM64 不是免费的服务选项。

   • 我选择了最小的配置（1 vCPU，3.5 GiB 内存，月费用 $91.98）。我只打算使用我的实例一个月，而这正好可以在我的 $200 USD 免费额度内。希望一切顺利！对于你自己的测试部署来说，不需要选择较大的配置。

2. 在下一屏上，为你的管理员账户创建一个用户名和密码。确保你的密码足够强！我使用了密码管理器来生成一个包含大量字符的复杂密码。我也建议你使用密码管理器，或许是一个内置于你浏览器中的密码管理器。这样，你就不必记住那些复杂的密码了。

3. 在下一屏上，我禁用了公共入站端口。然后，在左下角，我点击了蓝色的 审核 + 创建 按钮，因为我决定保留 磁盘、网络、管理 和 监控 的默认设置。你的界面可能看起来差不多，或者略有不同。仔细查看屏幕上的文字。我计划在大约一个月后取消我的 Azure 账户。如果你需要长时间保留你的 Azure 测试部署，我建议你点击 下一步 而不是 审核 + 创建，然后仔细考虑你的选项。

4. 如果屏幕上的选项看起来不错，点击左下角的蓝色 创建 按钮。否则，点击 上一步 按钮来更改你的配置。

   部署准备好需要一些时间，请耐心等待！

你的体验可能有所不同。但对我来说，部署大约花了一分钟时间才生效。然后，屏幕上显示 您的部署已完成。于是，我点击了蓝色的 转到资源 按钮。

在 第九章中，我们将对刚才部署的虚拟机进行渗透测试。

如果你真的很懂技术，你一定会喜欢点击 转到资源 后出现的界面。你可以浏览你虚拟机和其他 Azure 服务的所有技术细节。但现在，我们先进入 Azure Cloud Shell。

使用 Azure Cloud Shell 和 PowerShell

无论你在管理 Azure 服务的网页界面上在哪一位置（你地址栏中的 URL 应该显示为 portal.azure.com），只要你已登录，在页面顶部会有一条蓝色菜单栏。在搜索栏的右侧，会有一个类似命令提示符的图标（大概是这样：>_）：

图 8.4 – Azure 菜单栏和 Cloud Shell

点击它来启动 Azure Cloud Shell。在 Azure Cloud Shell 中，你可以通过左上角的下拉菜单在 PowerShell 和 Bash 之间切换。首次启动 Cloud Shell 时，你可能需要选择 创建存储：

图 8.5 – Azure Cloud Shell 屏幕

你将在 第五章 中找到一些 Bash 命令，通过无服务器应用和工具渗透测试 AWS 功能。我们将在本章中使用 Bash 来安装和执行工具。但让我们先回顾一些你可以在 Azure Cloud Shell CLI 中使用的有用的 PowerShell 命令。它们非常实用，你可能在执行 Azure Cloud Shell 中的其他活动时需要使用 PowerShell 命令：

• 类似于 Bash，你可以使用以下命令来更改当前打开的目录：

  • cd

  • chdir

• 在你复制项目之前，使用以下命令之一，并在命令中输入你想要复制的文件名：

  • copy

  • cp

• 你可以使用以下任何命令来移动项目。你还需要在命令中输入要移动的文件路径和文件名，以及目标文件路径：

  • mi

  • move

  • mv

• 使用以下命令和你想要删除的文件名来移除一个项目。记住，这将删除你的文件：

  • del

  • erase

  • rd

  • ri

  • rm

• 这个命令将删除整个目录。使用时请小心：

  • rmdir

• 如果你想创建一个新项目，请使用以下命令。通常，我只会用它来创建可以在记事本中修改的文本文件。使用这个命令会创建一个空文件，并使用你在命令中选择的文件名：

  • ni

• 使用这个命令设置项目的新值：

  • si

  例如，你可以输入 si path <string> 来设置一个字符串，或者 si value <object> 来设置一个对象，例如 ss64.com/ps/set-item.html。

• 使用这个命令启动一个后台任务（可执行任务）：

  • sajb

• 使用这个命令挂起任务：

  • sujb

• 使用这个命令恢复任务：

  • rujb

• 启动一个已停止的服务：

  • sasv

在 Azure Cloud Shell 中，无论你运行的是 PowerShell 还是 Bash，启动 Cloud Shell 后，以下指南将会显示出来。我在这里展示的命令适用于 Azure CLI，查看内置帮助指南总是一个很好的时间利用方式：

Type "az" to use Azure CLI
Type "help"" to learn about Cloud Shell

接下来，让我们看看一些原生的 Azure 安全工具。

Azure 原生安全工具

这是 Azure 中内置的可以帮助你提高安全性的一些工具。

Microsoft Defender

Microsoft Defender for Cloud 是一个重要的应用程序，用于检查你在 Azure 中的安全状况。它会根据你当前的配置提供安全建议，并告知你存在的一些安全漏洞。这些信息可以用于你的渗透测试报告。

让我们打开 Microsoft Defender，看看我们能了解到有关 Azure 部署的安全性：

1. 要执行该应用，首先确保你已在浏览器中登录 Azure 帐户。访问 portal.azure.com。你应该会看到这个屏幕。

2. 接下来，在顶部的蓝色菜单栏中，在搜索框中输入Defender。应该会显示出指向 Microsoft Defender for Cloud 的链接。点击它。

   你可能需要将 Microsoft Defender for Cloud 添加为付费服务。如果你尚未注册，可以在应用的主页面看到一个方便的升级按钮。提交前务必检查订阅费用！

3. 一旦进入 Microsoft Defender for Cloud，你将在左侧菜单中看到多个不同的部分（图 8.6）。它们代表了用于了解你在 Azure 中安全态势的不同工具：

   • 推荐将向你显示一些安全改进建议，按严重程度分类为高、中和低。

   • 附加路径分析将显示 Defender 是否已识别出攻击者可能利用的攻击路径，指向你的 Azure 实例。希望该页面显示未找到攻击路径。无论是否找到攻击路径，你都可以将此信息纳入你的渗透测试报告。

   • 安全警报类似于推荐。警报按严重程度分类为高、中和低。

   • 云安全探索器将展示一系列你可以执行的查询模板：

     • 互联网暴露的虚拟机

     • 存在高危漏洞的互联网暴露虚拟机

     • 存在特定漏洞的虚拟机

     • 公开访问的带有托管身份的互联网暴露 SQL 服务器

     • 没有 MFA 且具有存储账户权限的用户账户

     • 运行具有高危漏洞的 Azure Kubernetes Pods

     • 没有任何过期期限的 Key Vault 密钥和机密

     • 拥有脆弱虚拟机权限的用户账户

     • 标记为生产环境的互联网暴露 SQL 服务器

     • 拥有 SQL 虚拟机权限并允许在主机上执行代码的外部用户

     • 存在 Log4Shell 漏洞并具有存储账户权限的虚拟机

     • 含有漏洞 Pods 的 Kubernetes 命名空间

     • 公开访问的互联网暴露的简单存储服务（S3）存储桶，包含敏感数据

     • 公开访问的存储账户容器，包含敏感数据并允许公开访问

   • 诊断和解决问题提供了多个自动化故障排除工具，帮助解决以下领域的问题：

     • Defender 云安全态势管理（CSPM）计划

     • 服务器防护

     • 入驻和设置

     • 定价、计费和使用情况

     • 安全评分和推荐

     • 安全警报

     • 漏洞评估（VA）

   后两个故障排除工具对你确保安全警报和漏洞评估正常工作特别有用！

   • 在云安全下，安全态势会展示一个概览，包含安全评分和环境指标（管理组、订阅、不健康资源和建议）。你还可以从屏幕顶部生成治理报告。这些数据可能在你的渗透测试报告中有所帮助。

   • 在 Microsoft Defender for Cloud 的左侧菜单中，你还可以查看Azure 防火墙管理器，它会显示监控报告和概览。

   • 你还可以管理Azure 防火墙策略、分布式拒绝服务（DDoS）保护计划和Web 应用防火墙策略。

在下一节，我将带你了解我们在利用自己 Azure 测试部署时使用的安装过程。

Azure 渗透测试工具

在上一章，我列出了几种你在进行 Azure 渗透测试时可以使用的第三方应用程序。

我在这里演示的所有操作都符合 Microsoft 的政策，只要你是在自己的 Azure 实例中进行这些活动，或者你已获得你正在使用的 Azure 实例所有者的许可，允许你在其上进行漏洞扫描和渗透测试。

但我认为没有过于谨慎的说法。因此，我再次提供微软的政策链接（www.microsoft.com/en-us/msrc/pentest-rules-of-engagement）。请阅读并理解这些政策，以便你能够遵守它们，无论你在的 Azure 实例是否属于你，因为归根结底，无论如何你还是在微软的基础设施中工作！

Prowler

在 AWS 部分（第五章），我们发现 Prowler 是一个非常有用的漏洞扫描工具。Prowler 在 Azure 中也同样适用，所以我将带你了解如何在 Azure 中安装 Prowler：

1. 通过查看顶部搜索栏右侧，点击一个类似命令提示符的图标（像这样：>_）来启动 Azure Cloud Shell。

   点击它！

2. 我们不打算在 Azure Cloud Shell 中启动 PowerShell CLI，而是需要运行 Bash。在 Azure Cloud Shell 显示的左上方，有一个下拉菜单，可以在 PowerShell 和 Bash 之间切换。确保选择了 Bash。

3. 我们将使用pip来安装 Prowler，因此确保你在 Azure 中安装的pip版本是最新的可能会很有帮助。首先尝试这个命令：

   pip install --upgrade pip
   

4. 现在，我们将通过一个简单的命令来安装 Prowler。首先，确保你位于主目录或者你希望在其中运行并安装 Prowler 的目录。如果需要，可以使用cd命令来进行切换。然后，使用pip来安装 Prowler，像这样：

   pip install prowler
   

你会看到命令行中下载了各种 Prowler 组件，然后所有必要的包应该都会被安装。希望一切顺利！如果你需要更多帮助，可以查看官方的 Prowler 文档 (docs.prowler.cloud/en/latest/) 和官方的 pip 文档 (pip.pypa.io/en/stable/)。

接下来，让我们安装 MFASweep (github.com/dafthack/MFASweep)。

MFASweep

MFASweep 是一个 PowerShell 脚本，尝试使用提供的凭据登录到各种 Microsoft 服务，并检查是否启用了多因素认证（MFA）。对于 Azure 中的所有用户账户，启用 MFA 非常重要，以保护这些账户免受网络攻击者的侵害。

让我们开始安装吧！

1. 在另一个浏览器标签页中，确保你已登录到你的 GitHub 账户，网址是 github.com。如果需要，可以创建一个新的 GitHub 账户。

2. 接下来，运行此命令将你的 GitHub 账户与 Azure 账户关联。你可能需要输入 一次性密码（OTP）来完成此操作。如果是这样，你将会生成一个 OTP，输入到 GitHub（在另一个浏览器标签页中）：

   gh auth login
   

3. 现在，输入这个命令来使用 Git 安装 MFASweep：

   gh repo clone dafthack/MFASweep
   

图 8.6 – MFASweep 在 Azure 中的安装过程

在前面的截图中，你可以看到 GitHub 仓库克隆过程以及 MFASweep 在命令行中的安装过程。

ScoutSuite

现在，让我们安装 ScoutSuite。ScoutSuite 对审计我们的 Azure 实例的安全状态非常有用。在 Bash 中输入以下命令：

pip install scoutsuite

各种 ScoutSuite 组件将会被下载并安装。如果这一步没有正常进行，建议访问 GitHub 上的 ScoutSuite 页面 (github.com/nccgroup/ScoutSuite) 获取更多帮助：

图 8.7 – ScoutSuite 安装过程

现在，让我们使用我们安装的工具！

利用 Azure 应用程序

现在，让我们使用我们安装的工具进行一些安全测试。

Prowler

首先，让我们在 Azure 中运行一个默认的 Prowler 扫描。默认扫描是一个有效的通用漏洞评估。请按照以下步骤进行：

1. 启动 Azure Cloud Shell，确保使用的是 Bash。在 Azure Cloud Shell 界面左上方，有一个下拉菜单可以在 PowerShell 和 Bash 之间切换。搞定了！

2. 我喜欢在开始扫描之前先确认 Prowler 是否正确安装。使用以下命令检查你安装的 Prowler 版本：

   prowler -v
   

3. 接下来，让我们使用这个命令查看你可以在 Azure 中运行的 Prowler 安全检查：

   prowler azure --list-checks
   

4. 现在，让我们运行一些先前命令响应中列出的检查。确保--az-cli-auth位于你的prowler azure命令的末尾，以便你可以用必要的权限执行它。

   如果在命令行中遇到 IAM 的技术问题，你可以通过在另一个浏览器标签页中访问这个页面来检查你的 IAM 设置（确保你已正确登录到你的 Azure 管理帐户！）：

   portal.azure.com/#view/Microsoft_AAD_IAM/RolesManagementMenuBlade/~/AllRoles/adminUnitObjectId//resourceScope/%2F

5. 运行几个来自--list-checks输出的检查，像这样：

   prowler azure --checks defender_ensure_defender_for_app_services_is_on defender_ensure_defender_for_storage_is_on storage_infrastructure_encryption_is_enabled --az-cli-auth
   

   在--checks和--az-cli-auth之间，你可以输入任何显示为prowler azure --list-checks命令结果的检查名称。试试看！尽可能多地尝试各种检查。

   检查扫描的结果将根据其通过或失败情况显示在屏幕上。你还可以通过访问/home/<your_name_here>/output/目录，以 HTML、CSV 和 JSON 格式获取扫描日志。

6. 接下来，你可以通过这个命令查看你可以在 Azure 中使用 Prowler 扫描哪些服务：

   prowler azure --list-services
   

   你可以扫描的 Azure 服务将在命令行中输出一个列表。

7. 接下来，让我们扫描这些服务！使用类似这样的命令：

   prowler azure --services defender iam storage --az-cli-auth
   

   在--services和--az-cli-auth之间，你可以输入任何你希望从prowler azure --list-services命令中显示在屏幕上的服务名称：

与检查扫描一样，你也可以通过访问/home/<your_name_here>/output/目录，以 HTML、CSV 和 JSON 格式获取扫描日志。

让我们使用 MFASweep 进行 MFA 检查。

MFASweep

确保在与你（或你的客户）Azure 实例关联的所有帐户上启用 MFA 非常重要！密码是一种相对较弱的身份验证方法，密码经常被破解或泄露。实施 MFA 对确保你的帐户仍然安全至关重要，即使在网络威胁者威胁到你的密码时。我在手机上使用 Microsoft Authenticator 作为我的第二身份验证因素。在网络安全术语中，我的密码是“我知道的东西”，而 Microsoft Authenticator（通过我的手机）是“我拥有的东西”。如果我实施某种生物识别技术，例如指纹扫描仪，那将是“我是谁”。

让我们执行 MFASweep 检查 Azure 中的用户帐户是否启用了 MFA。这个命令将让 MFASweep 检查我的主 Azure 帐户和Active Directory FederationServices（ADFS）：

Invoke-MFASweep -Username <insert_username_of_account_email_address_here>@<insert_domain_name_here> -Password <insert_password_here> -Recon -IncludeADFS

注意我在那个例子中是多么小心地不分享我的 Azure 凭证！这就是你在网络安全中需要采用的思维方式。我们称之为OPSEC，即操作安全。

一个新的命令行将以 >> 开头。我发现查看扫描结果需要几分钟，因此你可能需要耐心等待：

图 8.8 – MFASweep 扫描结果

ScoutSuite

现在，是时候在 Azure 中进行基本的 ScoutSuite 扫描了。您的身份验证凭据应该已经通过使用之前的工具设置好了。

使用以下命令运行扫描：

scout azure --cli

一些操作将在命令行输出结果，如下所示：

图 8.9 – 在命令行上使用 ScoutSuite 扫描

完成后，JS、JSON 和 HTML 格式的日志将写入此处：

scoutsuite-report/scoutsuite-results/scoutsuite_results_azure-tenant-<unique_identifier_here>.<file_extension_here>

Prowler、MFASweep 和 ScoutSuite 应该会产生命令行输出和日志，这些内容在渗透测试 Azure 时非常有用。确保将这些结果包含在渗透测试报告中，并用你自己的话解释它们。

总结

您可以使用多种便捷工具来检查您在 Azure 中的安全态势，运行漏洞扫描并进行简单的渗透测试。您从这些工具中获得的所有信息都可以作为渗透测试报告的一部分。

Microsoft Defender for Cloud 是您的主要安全态势中心。它提供安全建议、安全警报、攻击路径分析、故障排除工具和安全配置相关信息。Azure 防火墙管理器也内置其中。Azure 防火墙有助于在您的 Azure 实例中允许或拒绝活动。您绝对需要拒绝可能帮助网络威胁行为者的活动！

Azure Cloud Shell CLI 可以在您登录 Azure Web 应用程序时在浏览器中执行。我们可以从 Azure Cloud Shell 安装并运行第三方渗透测试工具。

Prowler 在渗透测试 Azure 时与渗透测试 AWS 一样有用。

MFASweep 专为 Azure 设计。它是确保 MFA 设置保护所有访问您 Azure 实例的帐户的最有效方法。

ScoutSuite 是另一个工具，内置了许多非常有用的 Azure 扫描和检查功能。

在下一章中，我们将部署容器化应用程序到 Azure，并进行渗透测试。

进一步阅读

要了解本章涵盖的主题，您可以访问以下链接：

• Azure 中的免费服务列表：azure.microsoft.com/en-ca/free

• 带有 PowerShell 命令的备忘单：www.comparitech.com/net-admin/powershell-cheat-sheet/

• Prowler 文档：docs.prowler.cloud

• MFASweep：github.com/dafthack/MFASweep

• ScoutSuite：github.com/nccgroup/ScoutSuite

第九章：在 Azure 中对容器化应用进行渗透测试

在上一章，我们介绍了如何设置一个 Microsoft Azure 环境，以便我们在其中练习渗透测试和漏洞扫描。接着我们部署了一个虚拟机（VM），学习了一些 PowerShell 命令，并使用 Bash 在 Azure Cloud Shell CLI 中进行了一些应用扫描。

有时，组织会仅仅在普通的 Windows 和 Linux 虚拟机中运行它们的应用程序。然而，很多时候，组织需要一个高度可扩展的云配置，应用程序组件可以快速、灵活地启动和关闭。这在 DevOps 应用中尤其重要，这正是容器化派上用场的地方。

由于许多公司在其 Azure 网络中使用容器化，因此你学习如何进行渗透测试变得尤为重要。这正是本章的内容。

在本章中，我将解释什么是容器化，为什么使用容器化，以及容器化的基本工作原理。我们还将讨论 Docker 和 Kubernetes 在 Azure 中的工作方式，并介绍测试它们的渗透测试技术。

本章将涵盖以下主题：

• 容器化的工作原理

• 在 Azure 中的 Docker 和 Kubernetes 渗透测试技术

那么，让我们开始吧！

技术要求

我们将使用微软的基础设施。大量的 Azure 数据中心将负责本章练习的主要计算处理工作。所以，幸运的是，你不需要一台顶级的工作站。你将需要以下设备：

• 一个网页浏览器

• 一台台式机或笔记本电脑

• 一台安卓手机或 iPhone 手机

• 一个良好的、可靠的互联网连接

查看以下视频，查看代码实际操作：bit.ly/3QmGlKX

容器化的工作原理

虚拟机是模拟计算机。它不是直接运行在 PC 或服务器的硬件上，而是模拟操作系统运行所需的所有硬件组件。因此，一台物理计算机可以运行多个模拟计算机，每个模拟计算机就像在宿主操作系统的虚拟化程序（hypervisor）中运行的一个应用程序，或者在直接运行在硬件上的虚拟化程序中运行。

你可以使用自己的 PC 上的应用程序，如 Oracle VirtualBox 或 VMware Workstation Player，作为虚拟机的虚拟化程序。你只需要一个你想在虚拟机中运行的操作系统的磁盘映像文件，并将其配置在虚拟化程序中即可。操作系统不需要与宿主操作系统匹配，实际上，通常并不匹配。我可以在我的 Windows 11 PC 上运行一个 Kali Linux 虚拟机。你可以在你的 MacBook 上运行一个 Windows 11 虚拟机。而我可以在我的 Ubuntu Linux 桌面上运行一个 macOS 虚拟机。

然而，设置虚拟机确实需要一些时间，就像我们在第八章中所做的那样，当你设置虚拟机时，需要使用整个操作系统的磁盘映像。

也可以在云平台上运行虚拟机，正如我们在前一章中所做的那样。即使我使用的是微软的计算机，而不是自己的计算机来运行虚拟机，在 Azure 上设置一个虚拟机仍然需要几分钟的时间。此外，云平台上的传统虚拟机在功能上与自己计算机上的虚拟机类似；它使用整个操作系统。

在云平台上运行这样的虚拟机非常适合当公司希望让同一虚拟机运行几个月或更长时间时使用。在云平台上运行简单的 web 服务器是一个很好的使用案例。

然而，如今，DevOps 和 CI/CD 应用开发方法论使得公司能够部署需要快速扩展的动态应用程序。这些应用程序的后台可能会发生剧烈变化，每天甚至每时每刻都可能响应当前生产网络的需求。

容器 是部署虚拟化的一种非常精确的方式。一个 容器 只包含运行更大应用程序小部分所需的操作系统组件。单个容器的生命周期可能只有几天，甚至只有几个小时。

Docker 和 Kubernetes 是公司今天常用的两种容器化编排平台。容器化编排平台会自动启动和停止容器，而无需直接的人类干预。这些平台管理容器的部署，并处理虚拟化硬件中的负载均衡，只在需要时分配硬件资源，如 CPU 和内存。

云平台使得公司和其他类型的企业能够实现容器化应用。微软在其全球各地的 Azure 数据中心拥有巨大的硬件和网络能力。因此，如果容器化应用某天需要 1,000 台机器，第二天需要 200 台，第三天需要 2,000 台，Azure 可以提供这样的支持，这样公司就不需要在自己的场地上部署和停用这些机器。

你很可能会被要求在 Azure 中对基于 Docker 和 Kubernetes 的应用程序进行渗透测试。

正如 AWS 有自己管理 Docker 和 Kubernetes 的方式，Azure 也有自己的方式。因此，让我们来了解一下这些内容。

如何在 Azure 中使用 Docker

你可以通过 Docker Desktop 从本地计算机启动 Azure 中的 Docker 实例，或者直接通过 Azure CLI 启动。Docker Desktop 要求你在计算机上安装 Docker Desktop 应用程序（docs.docker.com/cloud/aci-integration/），但也可以直接通过 Azure Cloud Shell（这是一种在网页浏览器中访问 Azure CLI 的方式）启动 Docker 实例。我个人更倾向于后者。如果你只是为了测试目的以最简单的方式启动 Docker，这可能是最方便的方式。如果你要为特定的业务用途启动 Docker，并对其进行更多控制，Docker Desktop 可能是更好的选择。

让我们从 Azure Cloud Shell 开始工作，使用 Azure 默认提供的 Docker 镜像（当然也可以获取或创建你自己的 Docker 镜像，但对于本书中的练习，这不是必要的；Docker 镜像类似于传统虚拟机中使用的磁盘镜像，但它是为容器优化的）：

1. 通过你的网页浏览器登录到我们在上一章中设置的 Azure 帐户。

   在 Azure 中部署 Docker 的原生方式是使用 Azure 容器实例，这是一个无服务器服务。严格来说，背后是有服务器的，但由 Azure 管理，而不是你！在你按照这些指令操作时，这就是后台运行的服务。

2. 在网页顶部的蓝色菜单栏中，点击搜索栏右侧的第一个图标。它应该看起来像>_。

3. 点击它以启动 Azure Cloud Shell。接下来，我们将使用 Bash 而不是 PowerShell，因为本章中的渗透测试工具使用的是 Bash。在 Azure Cloud Shell 屏幕的顶部栏选择Bash。

4. 然后，确保你拥有所需版本的 Azure CLI。输入以下命令：

   az version
   

   只要你有 2.0.55 版本或更高版本，就可以正常使用。我现在使用的是 2.50.0 版本，所以不需要升级。如果你需要升级，请输入以下命令：

   az upgrade
   

5. Azure 中的容器使用资源组来管理 Azure 的资源以满足你的需求。让我们设置一个资源组。输入以下命令：

   az group create --name <resourceGroupNameOfYourChoiceHere> --location eastus
   

   eastus 可以替换为你选择的任何 Azure 数据中心区域名称。例如，如果你愿意，可以选择 canadacentral、brazilsouth 或 westus 等。

6. 接下来，我们需要创建一个容器！为了本章练习的目的，使用 Microsoft 默认的 Docker 容器镜像即可。使用以下命令操作：

   az container create --resource-group <resourceGroupNameOfYourChoiceHere> --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld --dns-name-label <dns-name-label-of-your-choice-here> --ports 80
   

   确保你的资源组名称与前一个命令中创建的名称相同。

7. 现在，你可以验证容器的状态，查看一切是否正常！输入以下命令：

   az container show --resource-group <resourceGroupNameOfYourChoiceHere> --name mycontainer --query "{FQDN:ipAddress.fqdn,ProvisioningState:provisioningState}" --out table
   

   如果一切顺利，命令行上会打印出类似的内容：

   FQDN                                         ProvisioningState
   ---------------------------------            -------------------
   aci-demo.eastus.azurecontainer.io            Succeeded
   

   如果没有成功，请从创建资源组命令重新开始。现在，我们已经启动了一个 Docker 实例，可以在其中测试我们的渗透测试技能！恭喜！

还有一个非常有用的命令，可以用来对你的新 Docker 实例进行渗透测试。我们在渗透测试报告中提到的许多漏洞数据都来源于日志记录。你可以使用以下命令来拉取容器实例日志：

az container logs --resource-group <resourceGroupNameOfYourChoiceHere> --name mycontainer

在命令行中，你会看到一条消息，显示监听端口 80（HTTP 的 TCP/IP 端口），最终，你将看到 HTTP GET 请求在命令行中显示出来，这些请求来自你的计算机或互联网上的其他计算机，针对你的 Docker 实例。

你可以使用这个命令删除你的 Docker 容器：

docker rm <name of folder with container here>

现在，让我们继续讲解 Kubernetes。

Kubernetes 在 Azure 中的工作方式

Azure 提供了专门用于部署 Kubernetes 的服务！Azure Kubernetes 服务（learn.microsoft.com/en-us/azure/aks/intro-kubernetes）使得在 Azure 平台上部署 Kubernetes 容器化变得非常简单。

Kubernetes 是目前最流行的容器编排平台。然而，有一个事实可能会让一些新手感到困惑——Kubernetes 扩展了 Docker 开创的一些技术。实际上，Kubernetes 中也可以运行 Docker 容器！因此，Docker 和 Kubernetes 在企业 DevOps 和 CI/CD 应用中经常相互交织，尤其是那些运行在云中的应用。

在前一部分中，我们部署了一个完全基于 Docker 的容器化系统，Azure 的无服务器 Azure 容器实例服务在后台支持这一切。现在，我们将把容器化部署到 Azure Kubernetes 服务中。

Kubernetes 具有非常特殊的架构（如 第六章 中所讨论的）。

注意

Kubernetes 的架构在不同的云平台中是相同的。

Kubernetes 部署的基础是控制平面。它是其他所有组件的父级，位于其上方。控制平面包含一个 API 服务器，用于管理与外部应用的连接，以及一个控制器管理器。我们将通过 kubectl（Kubernetes 的命令行工具）向其发送命令。

控制平面的子组件是节点。它们共享计算、网络和存储资源。节点的子组件是Pod，而 Pod 的子组件是单个容器。因此，可以这样理解——容器是容器的曾祖父母。

容器是最具动态性的组件；它们是变化最频繁的。它们根据应用的需求响应性地从容器镜像中生成。容器中仅包含执行代码所需的配置文件、库和依赖项。这是因为节点处理硬件资源的负载均衡，而控制平面对所有内容具有最终控制权，并且也是 Kubernetes 容器化系统外部系统的网关。

如果你想听起来像个真正的 Kubernetes 专家，可以称其为 K8s。这是 Kubernetes 开发者和管理员给它起的昵称。不过，我更喜欢用它的正式名称。

好的，让我们在 Azure 网络中部署 Kubernetes！我们可以在本章后面用它进行渗透测试：

1. 首先，我们需要再次启动 Azure Cloud Shell。从网页顶部的蓝色菜单栏中，点击搜索栏右侧的第一个图标，它应该像 >_ 这样。

2. 点击它以启动 Azure Cloud Shell。从这里，我们将使用 Bash 而不是 PowerShell。在 Azure Cloud Shell 屏幕的顶部栏中选择Bash。

3. 然后，确保你有正确版本的 Azure CLI。使用此命令：

   az –version
   

   只要你有版本 2.0.55 或更高版本，就可以继续使用了。否则，输入此命令：

   az upgrade
   

   在 Azure CLI 中操作 Kubernetes 时，我了解到首先需要创建一个具有访问我的容器注册表权限的服务主体，这样其他操作才能正常进行。

4. 复制这段脚本并粘贴到文本编辑器中，如记事本。将 $containerRegistry 替换为你选择的名称（例如 acrKim）。将 $servicePrincipal 替换为你选择的名称（例如 KIM_KUBERNETES）：

    #!/bin/bash
    # This script requires Azure CLI version 2.25.0 or later. Check version with `az --version`.
    # Modify for your environment.
    # ACR_NAME: The name of your Azure Container Registry
    ACR_NAME=$containerRegistry
    # SERVICE_PRINCIPAL_NAME: Must be unique within your AD tenant
    SERVICE_PRINCIPAL_NAME=$servicePrincipal
    # Obtain the full registry ID
    ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query "id" --output tsv)
    # echo $registryId
    # Create the service principal with rights scoped to the registry.
    # Default permissions are for docker pull access. Modify the '--role'
    # argument value as desired:
    # acrpull:   pull only
    # acrpush:   push and pull
    # owner:    push, pull, and assign roles
    PASSWORD=$(az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query "password" --output tsv)
    USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].appId" --output tsv)
    # Output the service principal's credentials; use these in your services and
    # applications to authenticate to the container registry.
    echo "Service principal ID: $USER_NAME"
    echo "Service principal password: $PASSWORD"
   

5. 如果你的密码不会很快被丢弃，最好将密码更改为一个复杂的、包含大量随机字符的密码。

   现在，我们终于可以部署我们的 Kubernetes 集群了！将 kimAKSCluster 替换为你选择的集群名称。将 acrKim 替换为你在前一个脚本的 ACR_REGISTRY_ID=$(az acr show --name $acrKim --query "id" --output tsv) 行中使用的 ACR 名称：

   az aks create \
       --resource-group myResourceGroup \
       --name kimAKSCluster \
       --node-count 2 \
       --generate-ssh-keys \
       --attach-acr acrKim
   

6. 几分钟后，JSON 输出将显示确认 Azure Kubernetes Service 部署的度量信息。

   Kubernetes CLI，也就是 kubectl，已经安装在 Azure Cloud Shell 中。

7. 然后，我们需要使用 kubectl 连接到我们的 Kubernetes 集群。输入以下命令，但将 myResourceGroup 替换为你之前使用的资源组名称，将 kimAKSCluster 替换为你之前使用的集群名称：

   az aks get-credentials --resource-group myResourceGroup --name kimAKSCluster
   

8. 现在，我们可以验证一切是否正常，并确保我们的节点在运行。输入以下命令：

   kubectl get nodes
   

现在，我们在 Azure 中使用 Azure 容器实例有了一个基础的 Docker 实例，并且使用 Azure Kubernetes Service 配置了一个基本的 Kubernetes 实例。

在接下来的部分，我们将在这些实例中运行一些漏洞扫描和渗透测试脚本。这才是有趣的部分！

Azure 中的 Docker 和 Kubernetes 渗透测试技术

让我们探索一些在 Azure 中进行容器渗透测试的工具。

kube-hunter

我们将尝试的第一个渗透测试应用程序是 GitHub 上 Aqua Security 提供的 kube-hunter。kube-hunter README 文件中的介绍在 github.com/aquasecurity/kube-hunter/blob/main/README.md 中提到如下内容：

“kube-hunter 会搜索 Kubernetes 集群中的安全漏洞。该工具的开发目的是提高 Kubernetes 环境中安全问题的意识和可见性。你不应该在你 不拥有的 Kubernetes 集群上运行 kube-hunter！”

绝对可以！这就是为什么我们在本章中在我们自己的 Azure 服务中设置了自己的 Kubernetes 集群。当你实际做渗透测试工作时，你将需要得到拥有 Azure 网络和 Kubernetes 实例的公司签署的法律许可。

使用 kube-hunter，你可以进行许多不同类型的扫描。首先，让我们安装它。然后，我们将进行一次快速扫描。

在 Azure Cloud Shell 中的 Bash 中，让我们使用此命令克隆 kube-hunter 的git仓库：

git clone https://github.com/aquasecurity/kube-hunter.git

现在，我们将安装它的依赖项：

cd ./kube-hunter
pip install -r requirements.txt

kube-hunter 是一个 Python 应用程序，所以我们可以使用以下命令启动它：

python3 kube_hunter

还有另一种安装方法我喜欢使用，它利用pip仓库。试试这个：

pip install kube-hunter

如果你是通过这种方式安装了 kube-hunter，你可以使用这个命令启动它：

kube-hunter

你也可以在指定特定日志级别的情况下运行 kube-hunter。试试这个命令：

kube-hunter --active --log WARNING

这样会输出WARNING级别的日志。这些事件你应该特别关注，它们在渗透测试报告中非常有用。或者，你可以使用这个命令输出DEBUG日志：

kube-hunter --active --log DEBUG

启动 kube-hunter 时，默认会记录INFO级别的事件。如果你更改了日志记录为WARNING或DEBUG，并且希望切换回INFO，可以使用以下命令：

kube-hunter --active --log INFO

由于我们在自己的 Kubernetes 实例中进行教育用途的操作，可以随意尝试不同的日志记录选项。

当你使用kube-hunter命令进行快速扫描时，命令行将输出以下内容：

图 9.1 – 在 Azure 中运行 kube-hunter

接下来，你输入1、2或3，选择你想执行的扫描类型。如果选择1或3，你需要在以下提示中输入 IP 地址。

我常常忘记在玩弄 Azure 实例时所使用的 IP 地址。我们在 Bash 中，因此检查 Azure 中 IP 地址的最简单方法是使用以下命令：

ifconfig

命令行应该会输出类似这样的内容：

图 9.2 – Azure 中的 ifconfig 命令

是的，我知道字符X在 IPv4 或 IPv6 IP 地址中并未使用。我替换了我的 IP 地址中的某些字符，目的是出于操作安全考虑。你永远也不能太小心！

你还可以在 Docker 容器内安装并运行 kube-hunter！通过以下命令在 Docker 中安装 kube-hunter：

docker run -it --rm --network host aquasec/kube-hunter

默认情况下，kube-hunter 通过一个名为stdout的实体输出所有扫描日志。因此，你可以通过 Azure Monitor 界面找到你的日志：

1. 返回到您的 Azure 账户界面，portal.azure.com。

2. 在顶部的蓝色菜单栏中，在搜索栏中输入 监控。

3. 在左侧，有一个 监控 下的部分列表，例如 概述 和 活动日志。点击 活动日志。

   以下屏幕将以这种方式显示您的日志：

图 9.3 – Azure 中的活动日志

您在 kube-hunter 中的操作将被记录在那里。我的操作产生了很多名为 列出存储帐户密钥 的条目。这就是 kube-hunter 要寻找的敏感信息！

探索 kube-hunter 文档（aquasecurity.github.io/kube-hunter/）以了解您可以执行的其他操作。

现在，让我们尝试 kdigger。

kdigger

kdigger 是一个多用途的 Kubernetes 渗透测试工具。它能够在您的 Kubernetes 实例中进行挖掘，查看它能找到哪些实体。当然，能够指纹识别和列举容器化部署对于网络威胁行为者来说是一项非常危险的能力，因为他们将知道如何继续进行攻击。

使用 kdigger 获得的数据也可以用于在 Kubernetes 中进行更有根据的渗透测试。

kdigger 还可以用于模糊测试。这意味着将无效、意外或随机的数据输入到应用程序中，以查看它是否会崩溃。如果应用程序设计用于验证输入并处理代码中的异常，它就不会容易受到模糊测试攻击。要了解如何使用 kdigger 进行模糊测试和其他功能，请查看它们的文档：github.com/quarkslab/kdigger。

让我们安装 kdigger 并进行一些挖掘。

根据您的配置，您可能会发现以下两种安装方法中的一种效果最佳：

• 第一个方法是默认的 Git 源技术：

  git clone https://github.com/quarkslab/kdigger
  cd kdigger
  

  然后，您需要将二进制文件移到您的路径中的工作目录：

  sudo install kdigger </usr/local/bin or enter your path name here>
  

  该方法将要求您记住您的 sudo 密码。

• 这个更简单的安装方法使用 go：

  go install github.com/quarkslab/kdigger@main
  

现在，让我们试试 kdigger！

导航到您的 Pods 所在的目录以及 kdigger 安装的目录。当我在 Bash 中迷失方向时，我输入这个命令来列出当前目录的内容：

ls

然后，我输入这个命令来切换到我正在寻找的目录：

cd go/bin

当您进入 kdigger 安装目录时，您可以通过一个非常简单的命令进行一般扫描：

 ./kdigger dig all

对我来说，这就是命令行输出的内容。我出于操作安全的原因，将 DNS 名称和 IP 地址中的一些字符替换为 X：

; <<>> DiG 9.16.33 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33463
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1224
;; QUESTION SECTION:
;.                              IN      NS
;; ANSWER SECTION:
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
.                       7048    IN      NS      XXX.net.
;; ADDITIONAL SECTION:
XXX.net.     1461    IN      A       198.XX.X.X
XXX.net.     1461    IN      AAAA    2001:503:XXXXX
XXX.net.     1461    IN      A       192.58.XX.XX
XXX.net.     1461    IN      AAAA    2001:503:XXXXX
XXX.net.     1461    IN      A       192.XXX.XX.XX
XXX.net.     1461    IN      AAAA    2001:XXXXX
XXX.net.     1461    IN      A       199.X.XX.XX
XXX.net.     1461    IN      AAAA    2001:XXX
;; Query time: 0 msec
;; SERVER: 168.63.129.16#53(168.XX.XXX.XX)
;; WHEN: Fri Jul 28 21:56:48 UTC 2023
;; MSG SIZE  rcvd: 824

如果您想扫描所有的桶，试试这个：

dig all

您可以在渗透测试报告中提到 kdigger 找到的任何暴露的 Kubernetes 实体。

总结

组织通常在他们的云平台上部署容器化，因为这是一种非常响应迅速且动态的方式，利用虚拟化实施快速可扩展且不断发展的应用程序，使用 DevOps 或 CI/CD 方法。

容器只包含执行其处理的代码所需的操作系统部分。负载均衡和硬件资源管理由容器化平台内容器的父容器、祖父容器或曾祖父容器完成。

现在，我们知道如何在 Azure 中部署 Docker 和 Kubernetes 容器化实例，并测试其安全漏洞。Docker 和 Kubernetes 是最常用的容器化平台。Kubernetes 基本上是对 Docker 功能的进一步扩展，甚至可以与 Docker 镜像和容器一起使用。

在接下来的章节中，我将介绍 Google Cloud Platform 及其各种服务。

延伸阅读

要了解更多关于本章所涉及的主题，您可以访问以下链接：

• 使用 Azure CLI 部署容器实例: learn.microsoft.com/en-us/azure/container-instances/container-instances-quickstart

)

• 什么是 Azure Kubernetes 服务？: learn.microsoft.com/en-us/azure/aks/intro-kubernetes

)

• kube-hunter 文档: aquasecurity.github.io/kube-hunter/

)

• kdigger 文档: github.com/quarkslab/kdigger

第四部分：渗透测试 GCP

GCP是谷歌的云平台！不过，业内人士通常使用这个缩写。在这一部分，我们将了解 GCP 的各种软件即服务、平台即服务和基础设施即服务应用。我们将部署自己的 GCP 实例，在其中测试我们的渗透测试技能。我们将使用 Security Command Center 检查 GCP 部署的安全状态。我们还将逐步尝试一些在 GCP 中的渗透测试工具。然后，我们将部署 Docker 和 Kubernetes 容器，并对其进行测试。

本节包含以下章节：

• 第十章，GCP 中的安全特性

• 第十一章，通过无服务器应用和工具进行 GCP 特性渗透测试

• 第十二章，在 GCP 中进行容器化应用的渗透测试

第十章：GCP 中的安全功能

欢迎来到谷歌云平台，简称GCP。GCP 是本书中提到的三大最流行云平台中的最后一个。GCP 的工作方式与 AWS 和 Azure 非常相似，但也有一些独特的方面，渗透测试人员在进行平台渗透测试之前需要了解。

首先，让我们来看看 GCP 生态系统中一些最常用的方面。在本章中，你将了解最受欢迎的 GCP 服务、应用和功能，以及它们的用途。接下来，我们将深入探讨 GCP 的软件即服务（SaaS）、基础设施即服务（IaaS）和平台即服务（PaaS）功能。最后，我们将讨论谷歌自有的 GCP 安全工具以及第三方安全工具。

在我们进行 GCP 渗透测试之前，了解我们所在公司可能如何使用 GCP，以及谷歌提供的哪些安全功能可以帮助渗透测试人员了解他们所使用的 GCP 部署的安全态势，会有所帮助。

本章涵盖以下主要主题：

• GCP 简介

• 常用的 GCP SaaS 应用

• GCP IaaS 服务

• GCP PaaS 服务

• GCP 安全控制和工具

让我们开始吧！

GCP 简介

谷歌推出的第一项服务是它的同名搜索引擎。那是在 1998 年，当时普通人开始大量使用互联网。创始人拉里·佩奇和谢尔盖·布林使用的第一台服务器（infolab.stanford.edu/pub/voy/museum/pictures/display/0-4-Google.htm）配备了 10 个 4GB 的硬盘，它们的硬件放在由乐高积木搭建的框架中！他们的第一台服务器运行在斯坦福大学的网络基础设施和场地上。

谷歌专为企业客户推出的第一项服务是其 AdWords 广告平台，现在称为 Google Ads（ads.google.com/home/）。此后几年，它推出了许多仍然非常流行的服务，例如 Gmail，并且它也关闭了更多的服务（killedbygoogle.com/）。

一项应该能持续发展并进化多年的服务集合是 GCP。

GCP 最初只是 2008 年的 App Engine (cloudplatform.googleblog.com/2008/04/introducing-google-app-engine-our-new.html)。那是亚马逊推出 AWS（我们现在所知的版本）大约两年之后。App Engine 是一个让企业和其他实体能够在 Google 平台内推出自己网络应用程序的方式。在 App Engine 初期，Google 将其使用限制在 10,000 个客户。这样，Google 有机会修复漏洞，并逐步扩展其基础设施，以便与亚马逊的 AWS 和微软的 Azure 更具竞争力。

到 2011 年 11 月，Google 将 App Engine 作为正式支持的产品，提供给任何愿意为其服务付费并遵守其政策的个人或实体。Google 逐步推出更多云服务，而 App Engine 成为 GCP 旗下多个产品中的一个。

截至 2023 年，GCP 的免费套餐提供的磁盘存储（5 GB 的云存储）比 Google 第一台服务器机器中单个 HDD 的整个容量（4 GB）还要大。Google 服务 25 年来，我们的进步确实不小！

在 GCP 进行任何渗透测试之前，重要的是要审查 Google 的Google Cloud Platform 可接受使用政策，以确保我们遵守该政策。以下内容来自 Google Cloud (cloud.google.com/terms/aup?sjid=12831346254261876451-NA)：

客户同意不使用，也不允许第三方使用 服务：

• 侵犯或鼓励侵犯他人法律权利 的行为；

• 从事、宣传或鼓励非法活动，包括儿童性剥削、儿童虐待或恐怖主义或暴力行为，这些行为可能对个人或群体 造成死亡、严重伤害或伤害；

• 出于任何非法、侵入性、侵权、诽谤或欺诈目的，包括非自愿明确图像（NCEI）、侵犯他人知识产权、网络钓鱼或创建 金字塔骗局；

• 传播病毒、蠕虫、木马、损坏文件、骗局或其他具有破坏性或 欺骗性质的项目；

• 未经授权访问、干扰或削弱客户、授权经销商或其他 授权用户使用服务或提供服务的设备；

• 禁用、干扰或规避任何服务、软件或用于提供服务的设备的任何方面；

• 生成、传播、发布或促进未经请求的大宗电子邮件、促销、广告或其他 solicitations（“垃圾邮件”）；或

• 使用服务或与服务提供的任何接口，以违反其他 Google 产品或服务的服务条款的方式访问任何其他 Google 产品 或服务。

简而言之，你可以在 GCP 上进行渗透测试，而无需请求 Google 的许可。但你被允许做的事情是有限制的。你绝对不能进行任何可能对其他 GCP 客户造成干扰的渗透测试。这意味着不能进行 DDoS 攻击模拟，不能分发恶意软件，不能尝试访问你所在公司拥有的资产以外的内容，而且——显然——不能违反法律。鼓励非法活动和分发恶意软件还可能会危害到不使用 GCP 的人群。漏洞扫描、查找公司所拥有资源中的暴露和未受保护的敏感数据是被允许的。只要确保你的公司已经书面授权你进行这些操作。

现在，让我们探索一下 GCP 提供的内容。

常用的 GCP SaaS 应用

GCP 生态系统中有大量的应用和服务，其中许多被归类为 SaaS。这意味着 Google 提供了基础设施、平台和运行在其上的应用。作为用户或组织，你只需对输入到应用中的代码或数据负责。

由于 Google 对其 SaaS 服务有更大的责任和控制，因此你在遵守其政策的前提下，进行渗透测试的能力非常有限，甚至几乎没有。Google 支持团队表示如下内容（support.google.com/cloud/answer/6262505?hl=en#zippy=%2Cdo-i-need-to-notify-google-that-i-plan-to-do-a-penetration-test-on-my-project）：

我是否需要通知 Google，我计划对 我的项目进行渗透测试？

如果你计划通过渗透测试评估你的云平台基础设施的安全性，你无需联系我们。你需要遵守云平台可接受使用政策和服务条款，并确保你的测试只影响你的项目（而不是其他客户的应用）。如果发现漏洞，请通过漏洞 奖励计划 进行报告。

这与基础设施有关，而非应用程序。你将拥有更多自由来渗透测试和漏洞扫描 Google 的 PaaS 和 IaaS 服务。

尽管如此，云渗透测试人员仍然需要了解 GCP 生态系统中有哪些 SaaS 服务。理解 GCP 中的 SaaS 有助于你了解你所在的组织如何整体使用 GCP。组织通常会使用一些 PaaS 或 IaaS 服务，除了 SaaS 之外，GCP 服务也能够互相连接。而且，有时，组织的 IaaS 和 PaaS 应用会与 GCP 的 SaaS 应用接口。如果一个组织的数据从 IaaS 或 PaaS 应用流向 SaaS 应用，那么这些数据的安全性可能会从 IaaS 或 PaaS 端进行渗透测试。

以下是一些最常用的 GCP SaaS 服务。

Google Workspace

Google Workspace (workspace.google.com/) 在某种程度上相当于谷歌的 Microsoft 365 for Business。Google Workspace 的特点是它将谷歌知名的生产力应用程序整合在一起，例如 Gmail、Google Calendar、Google Meet、Google Chat、Google Drive、Google Docs、Google Sheets、Google Slides 和 Google Forms。

如果这些听起来很熟悉，那是因为这个套件以前被称为 G Suite。谷歌确实喜欢不时地更改品牌名称！这让我们保持警觉！无论企业是否订阅 GCP，第一次使用 Google Workspace 时，都会获得 14 天的免费试用期。Google Workspace 及其组件具有更大的使用容量和企业特定功能，而这些功能在 Gmail、Google Docs 等消费者版本中是没有的。

Google App Engine

Google App Engine 在本章开头提到过，因为它是谷歌为企业市场提供的首个云服务，也是首个 GCP 组件。

App Engine (cloud.google.com/appengine) 是一种在谷歌基础设施上部署 Web 应用程序的“无服务器”方式。虽然技术上有服务器，但 App Engine 用户不需要管理或配置它。

由于 App Engine 用户不管理其平台或基础设施，因此它本质上是一个 SaaS 服务。App Engine 用户可以使用 Node.js、Java、Ruby、C#、Go、Python 和 PHP 等常用的应用程序开发技术来构建应用程序。如果开发人员在其他平台上已经熟练掌握这些语言之一或多个，那么学习如何使用 App Engine 应该是相当容易的。

Cost Management

AWS 和 Azure 都提供供其平台用户使用的应用程序，用于管理在这些平台上的云服务开支。谷歌也为 GCP 提供了类似的应用程序——Cost Management。

Cost Management (cloud.google.com/cost-management) 不仅仅是简单地说“你上个月花费了 $364.24。”相反，它提供了大量的图表和图形，让你能够理解自己在使用每个 GCP 组件时的开支趋势。

当我带你完成在 第十一章 中部署 GCP 环境以进行渗透测试教育时，我强烈建议定期检查 Cost Management，以确保不会产生意外费用。如果不小心，免费服务可能会变成付费服务！

Google Cloud app

Google Cloud app (cloud.google.com/app) 可以安装在你的 iPhone 或 Android 手机上，让你随时随地轻松查看你的 GCP 服务和网络。

配备物理键盘的笔记本电脑或台式 PC 是进行详细开发和管理工作时最理想的界面。但 Google Cloud 应用程序可以帮助您理解并发现生产问题，管理您的资源，如项目、计费、App Engine 应用和计算引擎虚拟机，接收和响应与生产相关的警报，并对您的 GCP 部署进行一般更改。

Google Cloud 应用程序的功能包括警报、错误报告、事件管理、可自定义的仪表板、计费以及检查您在计算引擎、云存储、云 SQL 和 App Engine 中的使用情况。

Google 营销平台

Google 最早的盈利模式是基于广告收入（Google AdWords，现在称为 Google Ads）和为广告商提供数据挖掘服务。因此，Google 不仅懂技术，也非常了解营销。因此，Google 营销平台对于企业来说是非常有用的。

Google 营销平台 (marketingplatform.google.com/about/enterprise/) 包括用于衡量用户如何使用您的应用程序的 Analytics 360，针对营销需求测试应用程序的 Optimize 360，帮助更好理解营销活动效果的 Search Ads 360，用于了解您在营销中使用的标签效果的 Tag Manager 360，以及帮助了解每个营销活动的效果的 Campaign Manager 360。

现在，让我们深入了解 IaaS。这些是提供给企业最多控制权的云服务，同时也将操作和确保服务安全的责任最大程度地委托给它们。

GCP IaaS 服务

使用 GCP IaaS 服务，您可以获得最大的控制权，但同时也承担最大的责任。Google 提供其网络基础设施以及用于部署虚拟机的硬件和工具。

使用 IaaS 服务与部署本地云网络之间的主要区别在于，您所在的组织无法物理接触到基础设施。您所在的组织中的任何人都不允许触碰 GCP 数据中心中任何计算机的物理电源按钮。您甚至不被允许物理进入这些数据中心。

但是，在 IaaS 服务中，您有更多的自由来进行渗透测试活动。您仍然需要确保遵守 Google Cloud Platform 可接受使用政策。不过不用担心，因为我在第十一章和第十二章中提供的所有渗透测试教程都是符合政策的！

以下是 GCP 组件，它们为您的组织提供了 Google 的基础设施，并让您的组织完成其余工作。（这些服务有时也可以与其他服务结合，用于 PaaS 和 SaaS 提供的服务。）

计算引擎

Compute Engine (cloud.google.com/compute) 是 GCP 组件，允许你的组织在 Google 的基础设施上运行虚拟机。Compute Engine 就是字面意思，它处理计算处理。Compute Engine 也推动了许多 GCP 的 PaaS 和 SaaS 服务。但如果你只是使用 Compute Engine 和 Cloud Storage，那你得到的就是一个 IaaS 解决方案。

Compute Engine 对于广泛的云网络应用场景非常有用，因为 Google 在其 GCP 数据中心拥有的硬件远远超过大多数公司能拥有的硬件。Compute Engine 特别适用于大量的 DevOps 和 持续集成/持续部署（CI/CD）需求。但你也可以在 Compute Engine 中部署简单的虚拟机（VM）。

Cloud Storage

虽然 Compute Engine 基本上负责 CPU 功能，Cloud Storage (cloud.google.com/storage) 负责磁盘功能。许多 SaaS 和 PaaS 解决方案也使用 Cloud Storage，但 Cloud Storage 也可以直接用于 IaaS 设置。

Google 说，使用 Cloud Storage，你可以存储任何数量的数据，并且可以随时检索。这个说法很大胆，但 Google 拥有存储 PB 级别数据的基础设施，如果你需要的话。只是不能免费提供——会收费的！当我们在下一章部署 GCP 网络用于教育目的时，我会免费获得 5 GB 的存储空间。这对于我的临时测试需求已经足够了。

受保护虚拟机（Shielded VMs）

如果你的组织处理的是额外敏感的数据，比如——例如——你在医疗、法律或公共部门工作，受保护虚拟机可能是最适合你云安全和合规需求的解决方案。

受保护虚拟机（Shielded VMs）(cloud.google.com/shielded-vm) 是专门配置的，用来实施防止启动病毒和根工具的安全控制。根工具是授予攻击者恶意管理员权限的恶意软件，而启动病毒是能够在操作系统启动过程中持久执行的恶意软件。

受保护虚拟机（Shielded VMs）运行在专用硬件上，使用特殊的 统一可扩展固件接口（UEFI）固件（该固件用于在物理机器启动操作系统或虚拟机监控程序前启动机器），虚拟可信平台模块和完整性监控。

在 GCP 的标准 Compute Engine 配置中，你可以以非常安全且符合规定的方式运行虚拟机，但受保护虚拟机通过其专用硬件和其他功能更进一步。如果一个组织的安全需求特别高，并且有相应预算，他们通常会选择多花点钱购买受保护虚拟机。尝试渗透测试受保护虚拟机中的额外安全控制将会带来麻烦，所以不要考虑这样做！

独占节点（Sole-tenant nodes）

独占节点是另一种可能非常昂贵的 IaaS 选项，用于在 Google 的基础设施上部署超敏感的应用程序。

像 GCP 这样的云平台可以用来部署公共云和私有云。大多数 GCP 用户实现的是公共云服务，这意味着我们的应用程序运行在同样也供其他 GCP 客户使用的硬件上。每当我在本书中向你讲解如何部署云网络用于教育目的时，我们使用的都是公共云服务。

私有云可以托管在公司自己的场所，但 GCP 和其他云平台也提供可以仅供单一客户使用的机器。这里所说的“客户”是指订阅云服务以托管自己应用程序的个人或公司，而不是指客户的客户，如果这样说清楚的话。假设我是一个 GCP 客户，我可以支付 GCP 服务费用来托管我的鞋店电子商务网站。我从我的 GCP 托管站点购买鞋子的顾客，在这个意义上并不是 GCP 客户；我才是 GCP 客户。呼！

不管怎样，GCP 所称的独占节点（cloud.google.com/compute/docs/nodes/sole-tenant-nodes）是另一种在 GCP 生态系统中部署私有云服务的方式。某些行业和公司出于合规性要求必须仅使用私有云服务。因此，他们可能会支付高额费用给 Google，以确保他们的机器不会与其他 GCP 客户共享。

所以，那些是可以用于 IaaS 部署的 GCP 服务。现在，轮到 PaaS 了。

GCP PaaS 服务

PaaS 介于 SaaS 和 IaaS 之间。SaaS 意味着你基本上只是在 Google 的应用程序中运行你的代码、命令、文档或媒体，运行在 Google 的平台和基础设施上。IaaS 意味着 Google 允许你使用它的硬件，但你负责提供自己的平台和应用程序。PaaS 意味着 Google 提供一个平台，你可以在其上运行自己的应用程序。

PaaS 的责任和工作量不如 IaaS 部署那样大，但它仍然比 SaaS 更具工作量。以下是 GCP 中的一些服务，它们为客户提供 Google 的平台，以支持客户自己的定制应用程序。

云 SDK

Cloud SDK（cloud.google.com/sdk）是开发人员的标准开发工具包。它包括 Java、Python、Node.js、Ruby、Go、.NET、C++、PHP 和 高级商业应用编程（ABAP）的客户端库。它具有可以集成到 Google Cloud CLI 中的特殊工具。

简而言之，Cloud SDK 是一组工具，开发人员可以使用它们来开发自己的定制应用程序，利用 GCP 生态系统中的各种技术。

Cloud SQL

Cloud SQL 用于在 GCP 上托管 结构化查询语言（SQL）数据库。绝大多数后台驱动的应用程序，无论是基于 Web 的还是其他类型的，都至少需要一个数据库。而如今，绝大多数数据库都使用某种类型的 SQL。

Cloud SQL (cloud.google.com/sql) 是一个托管的关系数据库服务，支持 MySQL、PostgreSQL 和 SQL Server。它消除了许多部署 SQL 服务器的麻烦。Cloud SQL 简化了 SQL 服务器的部署和管理过程。

Cloud Run

Cloud Run (cloud.google.com/run) 使得部署容器化应用程序变得更加容易。如果需要，Cloud Run 可以使用 Docker 镜像。（不过，Google Kubernetes Engine（GKE）可能是 Kubernetes 部署的更好选择。）

Cloud Run 支持 Go、Python、Java、Node.js、.NET、Ruby 以及其他许多流行的应用开发编程语言。

GKE

所以，这自然过渡到了 GKE。

Kubernetes 是一个容器编排平台，建立在 Docker 核心功能的基础上。Kubernetes 是开源的，并使用许多开源标准，但最初是由 Google 的一个团队开发的，包括 Joe Beda、Brendan Burns 和 Craig McLuckie。因此，尽管可以在 AWS 和 Azure 上通过原生支持部署 Kubernetes，但可以说 GCP 才是 Kubernetes 的真正家园。GKE (cloud.google.com/kubernetes-engine) 是在 GCP 中部署 Kubernetes 最便捷的方式。

Anthos

Anthos (cloud.google.com/anthos) 旨在帮助组织部署多云和混合云网络。

正如本书前两章所解释的，混合云是指公司在云平台上拥有服务，并在本地拥有服务器，两者互相集成。多云是指组织使用多个云服务提供商，并且来自多个提供商的云服务相互集成。

所以，一个组织可能拥有 GCP 服务和一些自有服务器，这就是混合云。它们可能在 AWS、Azure 和 GCP 上都有服务，这就是多云。它们也可能有自有服务器和 AWS、Azure、GCP 上的服务，这就是同时拥有混合云和多云的情况。这就是混合多云！

Anthos 使得管理这些不同类型的云配置变得更加简单。

接下来，让我们看看一些重要的 GCP 安全控制和应用程序。

GCP 安全控制和工具

让我们来看看 Google 为 GCP 客户提供的一些应用和功能，以提升他们的安全性。你的组织真应该使用这些功能！然后，我们将讨论一些有用的第三方安全工具。

安全控制

Google 提供了许多有用的应用程序，可以帮助我们管理 GCP 中的安全态势。让我们来看看它们。

身份与访问管理

身份与访问管理（IAM）（cloud.google.com/iam）是云安全的重要组成部分，GCP 也不例外。

用户和用户组会被授予有关他们可以对公司文件、应用程序和其他云资源执行哪些操作的权限。您的组织应当实施最小权限原则（PoLP），确保用户和用户组仅拥有执行工作所需的最小访问权限，而不会过度访问。

IAM 与 Cloud Identity 配合使用，用于在应用和项目之间同步用户帐户。双因素认证（2FA）可以直接通过 Google 管理控制台进行设置。这非常有用，因为云安全基准和一些数据法规要求用户除了密码外，还必须提供其他认证方式。

要求启用 2FA（或多因素认证，MFA）并不是为了让管理员和用户烦恼的愚蠢规定。密码被认为是一种弱认证方式，因为它们经常被破解或泄露。增加另一个认证因素可以像用户在手机上安装 Google Authenticator，并在登录公司 GCP 服务时输入该应用生成的 OTP 一样简单。

IAM 还具有强大的详细用户帐户日志功能。每个用户都必须对自己的行为负责，IAM 使管理员能够看到每个用户的操作记录。这些日志还可以传送到其他安全工具中，如入侵检测系统（IDS）。

Cloud IDS

说到 IDS，有Cloud IDS，这是 GCP 的原生 IDS。

当正确使用 Cloud IDS（cloud.google.com/intrusion-detection-system）时，它可以检测许多种恶意软件攻击和从命令与控制（C2）服务器发起的网络攻击。

Cloud IDS 可以监控 GCP 部署中的东西向流量和南北向流量。东西向流量是在云网络内部不同服务和机器之间的流量，而南北向流量则是云网络与公共互联网及其他外部网络之间的流量。网络攻击可以在东西向和南北向流量中传播！

Cloud IDS 可以生成警报，帮助管理员在攻击发生时及时应对。

Cloud IDS 生成的数据也可以在网络安全事件发生后用于调查。

Cloud Firewall

Cloud Firewall 可以配置为过滤或限制云网络内某些类型的流量或网络活动。

谷歌表示，Cloud Firewall (cloud.google.com/firewall) 可以提供“精细控制，包括无需重新架构网络的微分段”。这是一堆复杂的计算机网络术语，我很乐意将其翻译成简单的英语——Cloud Firewall 让管理员可以控制非常小的活动以及更大活动中的小组件，包括在不需要完全改变网络设置的情况下，将一个网络划分为更小的管理区段。

防火墙有很多方式来管理流量，包括 Cloud Firewall。流量可以根据其 TCP/IP 端口、IP 地址、域名和用户账户来管理。Cloud Firewall 可以利用 威胁情报（TI）来自第三方，来确定需要阻止的 IP 地址、域名和用户。

Secret Manager

Secret Manager (cloud.google.com/secret-manager) 为 GCP 用户提供了一种安全的管理其秘密的方式。这些秘密并不是指“我小时候数学课上不允许用计算器时偷偷用了计算器”这样的事，而是 Secret Manager 保护的是如密码、加密证书、API 密钥（它们让应用程序之间进行通信）以及其他各种敏感的身份验证数据。

因此，当您为 web 服务器设置 TLS 证书，或者用户通过 IAM 创建账户密码时，这些信息会被存储在 Secret Manager 中。可以把它当作一个巨大的银行保险库，里面有一扇厚重的防弹门，而所有的密钥都保存在里面。保护这些密钥是至关重要的，防止黑客和其他恶意实体对您的 GCP 应用程序和数据做出不良行为。

Cloud DLP

Cloud DLP（即数据丢失防护）（cloud.google.com/dlp) 帮助确保您的 GCP 中的重要数据不会丢失！没错—它的名字正好描述了它的功能，但显然，它所使用的技术需要更多的描述。

Cloud DLP 可以使用掩码和令牌化来模糊化您的数据。例如，如果一个信用卡号码通过您的电子商务应用的销售点（POS）系统，而它的号码是 G2F69，Cloud DLP 可能会将其伪装成 B7K31（请注意，实际信用卡号码不会使用这种格式；这里我为了安全起见做了额外的保守处理！）

Cloud DLP 还可以向安全管理员展示某段数据是如何从这里经过，然后那里再经过，最后从另一个更远的组件流出的。当然，这不是那么模糊。Cloud DLP 还可以追踪数据离开云端的路径，并防止那些不应该离开云端的敏感数据被泄露。

安全指挥中心

Security Command Center (cloud.google.com/security-command-center) 是一个统一的界面，将这些 GCP 安全控制与其他 GCP 安全控制结合在一起。

理论上，你可以在一台显示器上打开一个 IAM 面板，独立于另一台显示器上显示的 Cloud Firewall 面板。

然而，当所有这些安全应用程序相互集成时，它对安全管理员的帮助非常大。当管理员能够看到一个安全组件如何与另一个组件协同工作，或者网络攻击如何尝试做一种坏事，然后再做另一种坏事时，这对于防御网络攻击帮助巨大。

Security Command Center 使得识别安全配置错误和多种类型的安全漏洞成为可能，从而能够尽快有效地解决这些问题。

除了帮助管理员检测网络威胁外，Security Command Center 还可以设置以帮助公司确保他们遵守适用于他们的数据安全法规。

现在，进入你在 GCP 中进行漏洞扫描和渗透测试时可以使用的第三方工具。

安全工具

许多非常有才华的渗透测试人员开发了旨在 GCP 中使用的第三方渗透测试和安全测试工具。此处提到的所有工具都是开源的，并可以通过 GitHub 获得。在本节中，你将找到我认为最有用的 GCP 渗透测试工具。

GCPBucketBrute

GCPBucketBrute (github.com/RhinoSecurityLabs/GCPBucketBrute) 是由 Rhino Security Labs 开发的。你可能已经注意到，在本书中，Rhino Security Labs 还开发了一些我提到过的其他渗透测试工具，如 Pacu 和 CloudScraper。

GCPBucketBrute 是一个脚本，用于列举 Google Storage 桶，查看哪些组件和实体有权访问它们，以及是否可以提升权限。如果网络犯罪分子能够访问你组织的桶，尤其是当他们能够提升权限做任何他们想做的事情时，这非常危险。因此，渗透测试人员应该运行此工具，在坏人发现这些漏洞和攻击路径之前先找出这些问题。

根据 README 文件（github.com/RhinoSecurityLabs/GCPBucketBrute/blob/master/README.md），脚本执行以下步骤来查找安全问题：

1. 给定一个关键词，这个脚本会根据从 关键词生成的多个排列组合来列举 Google Storage 桶。

2. 然后，任何发现的桶都会 被输出。

3. 然后，任何你被授予的权限（如果有）对任何已发现的桶都会 被输出。

4. 然后脚本将检查这些权限是否存在权限提升（storage.buckets.setIamPolicy），并输出任何有趣的信息（例如公开可列出、公开可写、经过身份验证可列出、权限提升等）。

Scout Suite

我之前提到过 nccgroup 的 Scout Suite (github.com/nccgroup/ScoutSuite)。它也与 GCP 配合得很好，所以我再提一下。正如 README 所说：

“ScoutSuite 是一个开源的多云安全审计工具，能够对云环境进行安全态势评估。通过使用云服务商公开的 API，Scout Suite 收集配置数据供人工检查，并突出显示风险区域。与在 Web 控制台上浏览数十页不同，Scout Suite 自动呈现攻击面视图。”

和我提到的许多工具一样，您可以直接从每个平台使用的 CLI 运行 ScoutSuite。

Hayat

Hayat (github.com/DenizParlak/hayat) 由 Deniz Parlak 开发。Hayat 在土耳其语中意为“生命”，开发者还将其脚本命名为自己侄女的名字，真甜！

Hayat 是一款可以审计 Cloud SQL 实例、IAM、Cloud Storage、网络配置、VM、日志和监控系统以及 Kubernetes 集群的脚本。

Parlak 说这 暂时 就是这些，这似乎意味着将来会添加更多功能。我等不及了！

gcp_firewall_enum

Chris Moberly 的 gcp_firewall_enum (gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_firewall_enum) 解析您的 GCP 数据输出，列举出通过其网络端口暴露在互联网上的计算实例！过多这种暴露肯定是个坏事。

然后，gcp_firewall_enum 根据结果生成 Nmap 脚本。Nmap 是最常用的网络安全测试工具之一；它是一个网络映射器，可以用来绘制网络图。我喜欢这些描述性的名字——它们非常方便。

Gcploit

Gcploit (github.com/dxa4481/gcploit) 是一套用于渗透测试的工具集，旨在发现 GCP 中的安全漏洞。

让我们来看看它们吧！

• BFS Search 是一款威胁建模工具。它可以帮助您找出威胁行为者可能如何攻击您的 GCP 应用程序。

• Mock Graph 也可以用于威胁建模。

• 然后，主要的 Gcploit 组件执行两个特定的漏洞利用，actAs 和 dataproc。Dataproc API 用于配置数据资源，actAs 是一个可以用来进行恶意访问的漏洞利用。

Gcploit 基于 Dylan Ayrey 和 Allison D 在 2020 年 Black Hat 上的演示。在 Gcploit 的 README 中，他们提到过其他他们希望添加的漏洞，但尚未实现。

gcp-iam-role-permissions

Brad Geesaman 和 Josh Larsen 的 gcp-iam-role-permissions (github.com/darkbitio/gcp-iam-role-permissions) 是一个脚本，用于查找 GCP IAM 角色及其权限，包括基本角色和预定义角色。

在设置 GCP 中的用户帐户时，必须非常小心，保持默认设置通常是非常糟糕的主意，因为攻击者可能会尝试基于这些设置的漏洞。用户帐户及其访问权限应该根据一些与更改默认密码相同的原因进行定制。

Geesaman 和 Larsen 的工具帮助渗透测试人员在坏人之前检测出这些类型的漏洞。

GCP Scanner

GCP Scanner (github.com/google/gcp_scanner) 拥有许多不同的贡献者，并且它在 Google 的官方 GitHub 账户下发布。但 README 的开头有这样的免责声明：

“这个项目不是官方的 Google 项目。它不受 Google 支持，Google 特此声明不对其质量、适销性或特定用途的适用性承担任何保证。”

那肯定和 Google 的律师有关。这就像 Google 在说：“这是一个很酷的渗透测试工具，但如果它不能正常工作，别怪我们。”我觉得你还是应该尝试一下，尤其是如果你想在 GCP 部署中尝试，作为自己的教育用途。

GCP Scanner 可以帮助你确定在 GCP 网络和应用程序中某些凭据的访问级别。你可以将 GCP Scanner 的结果用于渗透测试报告，也可以用来加强你组织在配置 IAM 时的安全性。

GCP Scanner 可与以下类型的凭据一起使用：

• GCP VM 实例元数据

• 存储在 Google Cloud (gcloud) 配置文件中的用户凭据

• 授予云平台范围的 OAuth2 刷新令牌

• GCP 服务帐户密钥（JSON 格式）

GCP Scanner 可以测试 Compute Engine、App Engine、Cloud Storage、GKE、Bigtable、BigQuery 和 Cloud Functions。

我们一定会在 CLI 中运行 GCP Scanner，具体见 第十一章；应该会很有趣！

摘要

GCP 的根源可以追溯到 2008 年 Google 发布了 App Engine，这是一个让企业和其他实体可以在 Google 平台上发布自己 Web 应用程序的方式。App Engine 被证明非常受欢迎。因此，随着时间的推移，Google 发布了大量额外的云服务，企业和组织可以使用这些服务来管理其生产网络和网络应用程序。

GCP 是 Google 与 Amazon 的 AWS 和 Microsoft Azure 竞争的方式。然而，许多组织部署了多云网络，使用所有这些云平台以及更多平台。

在 IaaS 中使用的两个最重要的 GCP 组件（但也可以在 SaaS 和 PaaS 中使用）是 Compute Engine 和 Cloud Storage。Compute Engine 就像 CPU，Cloud Storage 就是你的磁盘。

Google 还提供了许多非常有用的安全控制，您的组织应该利用这些工具来增强抵御网络攻击的能力。它们包括云防火墙、IAM、密钥管理器、云 IDS 以及一些其他应用程序。管理员可以通过安全指挥中心的集成界面，全面实时查看组织的安全状态、安全事件和漏洞。

有许多第三方工具可用于对 GCP 进行渗透测试。它们包括 Scout Suite、GCPBucketBrute、Hayat、GCP Scanner、Gcploit 和 gcp_firewall_enum。

在我们已大致了解了如何对 GCP 进行渗透测试后，在下一章中，我们将对 GCP 中的 Docker 和 Kubernetes 集群进行渗透测试。

深入阅读

若要了解本章中涵盖的主题，您可以访问以下链接：

• GCP 免费 套餐: cloud.google.com/free

)

• Google Cloud 产品: cloud.google.com/products

)

• Google Cloud 平台服务条款: cloud.google.com/terms/

第十一章：通过无服务器应用程序和工具渗透测试 GCP 特性

现在我们已经了解了 Google Cloud Platform（GCP）所提供的各种服务，是时候开始我们的 GCP 部署，并通过动手实践学习一些 GCP 渗透测试工具了。

我们将在我们在第十章中设置的 GCP 虚拟机上安装并执行一些渗透测试工具。这些工具包括 Prowler、GCPBucketBrute 和 GCP Scanner。我们还将查看 Google 在安全指挥中心为我们提供的安全工具。

本章将涵盖以下主题：

• GCP 免费层

• 启动一个 GCP 网络

• 使用 GCP Cloud Shell

• GCP 原生安全工具

• GCP 渗透测试工具

• 利用 GCP 应用程序

让我们开始吧！

技术要求

我们将使用 Google 的基础设施。巨大的 GCP 数据中心将负责本章练习的大部分计算工作。所以幸运的是，你不需要一台顶级工作站。你将需要以下设备：

• 一个网页浏览器

• 一台台式电脑或笔记本电脑

• 一部安卓手机或 iPhone

• 一条可靠的互联网连接

查看以下视频，观看代码演示：bit.ly/4093wMk

GCP 免费层

我强烈建议你设置自己的 GCP 网络，以便测试本章和第十二章中的练习。

有几个 GCP 产品和服务，你可以在免费层中享受而不产生费用。然而，请记住，在注册时，你需要提供 GCP 的信用卡号码。如果你超出了免费层的限制，你的信用卡将被收费，因此你必须非常小心地检查你的使用情况和账单。当我注册时，我获得了 300 美元的免费服务费用信用额度，有效期为我订阅的前 90 天。根据你注册的时间、地点以及具体情况，你可能会或不会获得类似的信用额度。本章稍后我会展示如何检查你的账单状态，以确保你不会产生无法负担或不想支付的服务费用。

截至 2023 年撰写本文时，以下是 GCP 免费层中提供的服务以及它们的限制 (cloud.google.com/free/docs/free-cloud-features):

• Compute Engine是为 GCP 上的虚拟机提供支持的服务。免费额度包括每月一个 e2-micro 实例。这意味着“每月在以下美国区域之一获得 1 个非抢占性 e2-micro VM 实例：us-west1、us-central1、us-east1。30 GB-月的标准持久磁盘。每月从北美到所有区域目的地（不包括中国和澳大利亚）的 1 GB 网络出口流量”(cloud.google.com/free/docs/free-cloud-features?hl=en#compute)。请记住，区域是 GCP 数据中心的位置。你不必物理上位于美国。你和你的笔记本电脑可以在巴西、印度、埃塞俄比亚或任何能够连接到 GCP 服务的国家。只要你使用的 GCP 数据中心位于us-west1、us-central1或us-east1，你就可以使用这些服务。

• Cloud Storage是存储数据的主要服务。每月包含 5 GB 的免费额度。那么每月 5 GB 意味着什么呢？“每月 5,000 次 A 类操作，50,000 次 B 类操作，来自北美的 100 GB 网络出口流量，覆盖所有地区目的地（不包括中国和澳大利亚）每月。”(cloud.google.com/free/docs/free-cloud-features#storage)。如果你按照本书中我展示的方式使用 GCP 网络，应该没问题。

• BigQuery是一个无服务器的数据分析平台。我们在本书中不会使用它，但在免费额度中，你每月可以获得 1 TB 的 BigQuery 查询。

• App Engine是一个用于部署 Web 应用程序和移动应用的平台。免费额度为每天 28 小时实例。我们在本书中不会使用 App Engine，但如果你部署一个有大量用户的 App Engine 应用，你肯定会因此产生费用。

• Cloud Run是一个用于部署无状态容器的服务。免费额度为每月 200 万次请求，因此你应该没问题。

• Cloud Build可以从 Cloud Storage、Cloud Source Repositories、GitHub 或 Bitbucket 导入源代码构建，创建 Docker 容器或其他类型的软件工件。你每天可以获得 120 分钟的构建时间，免费额度内有此服务。本书中我们不会使用此服务，而是将使用标准的默认 Docker 和 Kubernetes 容器镜像。你应该没问题。

• 使用Google Kubernetes Engine，每月可以获得一个自动驾驶或区域集群。我们将在第十二章中部署一个集群。

  在免费套餐中，你可以获得一些 Cloud Logging、Cloud Monitoring 和 Cloud Trace 的配额，这些都属于运营套件（以前称为 Stackdriver）。这些功能可以帮助你分析 GCP 中的云活动。免费配额有点复杂，但按照本书中的说明操作，超出配额的可能性很小。为了安全起见，你可以阅读更多关于免费配额的内容 (cloud.google.com/stackdriver/pricing)。

• Firestore 是一个 NoSQL 文档数据库服务。在免费套餐中，你可以获得 1 GB 的存储空间，但我在这里不会使用它。它主要用于应用开发。

• 在免费套餐中，Cloud Functions 每月提供 200 万次调用。这是一个无服务器环境，用于构建和连接云服务。我们可能不会用到它。

• Workflows 便于在 GCP 与外部 HTTP API 之间进行服务调用。每月提供 5,000 个免费的内部步骤，这应该足够了。

• 免费套餐包括 Cloud Source Repositories 的五个用户的免费访问权限，这是一个用于托管私有 Git 仓库的服务，适用于应用开发。我们也不会使用这个服务。

• 我们将使用 Secret Manager，它用于存储密码、证书、API 密钥等。每月在免费套餐中我们可以获得六个秘密版本，这已经足够了。

好的！现在我们知道了我们要做什么，让我们一起部署一个 GCP 网络。在本书中，我们将需要自己的 GCP 部署来测试我们的渗透测试技能。就像我们在 AWS 和 Azure 上部署实例一样，我会一步一步地引导你完成整个过程。

启动 GCP 网络

和 AWS、Azure 一样，你只需要一台运行 Windows、macOS 或 Linux 发行版的现代笔记本或台式电脑，就可以启动和管理 GCP 网络。谷歌的计算机和基础设施负责处理所有计算资源方面的工作。

我还建议你在 Android 手机上使用 Google Authenticator (play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&pli=1) 或 iPhone 上使用 (apps.apple.com/us/app/google-authenticator/id388497605)，这样你就可以在 GCP 服务中启用 多因素认证（MFA）。我不建议你用手机做大部分的 GCP 工作，因为 PC 屏幕和物理键盘更适合这类操作。但如果你想查看 GCP 服务的状态，可以在手机上安装 Google Cloud 应用 (cloud.google.com/app)。它特别适合在路上检查你的账单，确保你没有做出任何昂贵的操作！

过去十年内制造的 PC 或 MacBook 和一个可靠的互联网连接，足以让你在全球任何地方部署 GCP 并进行 GCP 上的渗透测试。

所有开始自己的 GCP 部署的工作都可以在你的网页浏览器中完成。让我们开始吧：

1. 设置自己的 GCP 网络的第一步是访问 Google Cloud 免费层页面（cloud.google.com/free），并点击屏幕中央的蓝色免费开始按钮：

图 11.1 – Google Cloud 注册页面

1. 在下一个屏幕中，确保你的 Gmail 或 Google 账户已登录。如果你还没有账户，设置一个，或者登录你已经有的账户。在下拉框中选择你的国家，并回答什么最能描述你的组织或需求？的问题。我选择了其他。确保你选择了你已阅读服务条款，然后点击上面写着继续的蓝色按钮：

图 11.2 – Google Cloud 注册屏幕

1. 下一屏要求你选择你的支付配置文件。如果你在使用 GCP 服务时发生费用，Google 需要有一个方式向你收费，即使你能保持在免费层的限制内。我已经有了支付配置文件，因为我购买过 Google Play 应用和服务，是 YouTube Premium 订阅者，并且使用过 Google Pay。如果你没有支付配置文件，你可能需要输入信用卡号码或链接你的 Google Pay 账户（payments.google.com/）。

2. 在账户类型下，我选择了个人。除非你是代表企业或组织设置 GCP，否则我建议你选择个人。

3. 在姓名和地址下，确保你的姓名和街道地址与信用卡或 Google Pay 账户上的信息一致。

4. 在下面，点击蓝色的开始我的免费试用按钮。任何关于额外服务和信用的时间限制（例如我的 90 天$300 服务信用）现在开始！

   如果你往下滚动一点，你会看到启动 GCP 项目的按钮。首先，是一些预建的解决方案模板：

   • 部署负载均衡的托管虚拟机

   • 创建一个安全的CI/CD 管道

   • 使用Compute Engine 部署 Java 应用

   也有按钮可以在没有模板的情况下启动产品：

   • 创建虚拟机

   • 创建一个容器化应用

   • 运行容器化应用

   • 现代化并运行应用

   • 执行构建

   • 开始使用容器

   这是项目启动页面的样子：

图 11.3 – Google Cloud 项目启动页面

1. 现在，让我们点击创建虚拟机，在 GCP 上使用 Compute Engine 部署一个简单的虚拟机，用于本章中的渗透测试。

2. 下一屏显示计算引擎 API，概述中写着在 Google Cloud Platform 上创建和运行虚拟机。点击蓝色的启用按钮。

3. 你将被引导到虚拟机实例仪表板，界面如下所示。点击蓝色的创建实例按钮：

图 11.4 – GCP 计算引擎屏幕

1. 在下一屏中，我们可以为实例命名并选择其区域和可用区，以及其机器配置。我将向你展示一个最不可能产生服务费用的配置：

图 11.5 – 虚拟机实例的机器配置

• 在名称字段中，给你的实例取个名字。我给它取名为crowgirl-1。

• 在免费层中，我们使用 Compute Engine 的配额限制为“每月在以下美国区域中的一个，最多创建 1 个不可抢占的 e2-micro 虚拟机实例：us-west1、us-central1、us-east1。”因此，我选择了us-east1作为我的区域。无论你身处世界的哪个角落，你都可以选择us-west1、us-central1或us-east1。

• 在机器配置下，为了节省费用，我选择了通用型，E2 系列，e2-micro 机器类型（这是唯一一个在免费层中涵盖的机器类型），以及标准虚拟机配置模型。然后点击底部的蓝色创建按钮。

几秒钟到一分钟后，我们的基础虚拟机将在 Compute Engine 中准备好！你会看到类似这样的屏幕：

图 11.6 – 项目中的虚拟机实例列表

默认会安装 Debian Linux 镜像。我们现在有一台可以使用 Bash CLI 的 Linux 虚拟机！

我总是偏向使用云平台网页界面中内置的 CLI。因此，我们来启动 GCP Cloud Shell。

使用 GCP Cloud Shell

要启动 GCP Cloud Shell，请看顶部的菜单栏，点击位于搜索框右侧的>_图标。你是否注意到 GCP 的网页界面和 AWS、Azure 的网页界面非常相似？

图 11.7 – GCP 控制台中的顶部菜单栏

我们在第五章为 AWS 和第八章为 Azure 使用的所有 Bash 命令，在这里也能正常工作。我们在 GCP 中的 Linux 虚拟机本质上和任何其他基于 Linux 的计算机一样；Bash CLI 是标准配置。如果你愿意，可以回顾一下在第五章中提到的 Bash 命令。

Cloud Shell 屏幕长这样：

图 11.8 – Cloud Shell 屏幕

接下来，我们来看一下 Google 提供的一些工具，它们将在我们作为 GCP 渗透测试人员工作时发挥作用。

GCP 原生安全工具

Security Command Center 是您访问 GCP 中所有安全工具的起点。它集成了我在第十章中提到的多种第一方 GCP 安全工具。这意味着您可以在Security Command Center（SCC）面板中查看来自这些应用和服务的数据：

• Identity and Access Management (cloud.google.com/iam)，用于管理您 GCP 网络中所有用户身份和机器身份（例如，Web 服务器的 TLS 证书），并提供强大的日志记录功能，该功能已集成到 SCC 中，也可以集成到组织的第三方安全监控服务中。“Identity and Access Management (IAM) 允许管理员授权谁可以对特定资源进行操作，赋予您对 Google Cloud 资源的完全控制和可视性，以集中管理这些资源。”

• Cloud IDS (cloud.google.com/intrusion-detection-system)，其功能与大多数基于网络的入侵检测系统（IDS）相同。它实时读取您的网络日志，并在可能出现网络威胁迹象时通知安全管理员。它可以监控并生成针对入口流量（东西向，从一个内部服务器或应用到另一个）和出口流量（南北向，在您的云网络和公共互联网或其他外部网络之间）的警报。这是零信任网络安全的核心概念——恶意流量可能来自任何地方。内部网络和外部网络之间的安全边界已经不再是过去的常态。Cloud IDS 能够检测的潜在威胁包括恶意软件和由指挥控制中心驱动的攻击。

• Cloud Firewall (cloud.google.com/firewall)，其功能类似于大多数其他基于状态检测的网络防火墙。可以应用全局网络防火墙策略，以根据一般的 GCP 安全基线允许或禁止流量。可以使用 IAM 管理的标签来根据用户和机器身份账户的标签标记来允许或禁止流量。Google Cloud Threat Intelligence 列表也可以应用，以便当 Google 发现新的网络威胁时，您的防火墙会相应更新。当然，安全和网络管理员也可以手动阻止或允许特定的用户和机器。

• Cloud DLP (cloud.google.com/dlp)，一个用于数据丢失防护（DLP）的工具。它追踪数据在您的 GCP 网络中的流动以及如何离开您的 GCP 网络，以确保敏感数据不会被网络泄露。敏感数据可以被防止上传到外部目的地，或者根据情况进行令牌化或掩码处理（例如，将信用卡号写为45xx-xxxx-xxxx-xxx）。

在测试 SCC 时，我了解到必须设置 Cloud Identity 才能访问该应用程序。Cloud Identity Premium 是一项收费服务，提供额外功能。我选择了Cloud Identity 免费版，因为我们希望在进行 GCP 渗透测试时保持低成本：

1. 访问 workspace.google.com/gcpidentity/signup?sku=identitybasic，一旦你创建了 GCP 账户，就可以设置 Cloud Identity 免费版。以下截图显示了设置Cloud Identity 免费版的第一步：

图 11.9 – 设置 Cloud Identity 账户

1. 在下一个界面，你需要输入你的名字、姓氏和联系邮箱地址。点击下一步。然后，你需要输入一个你有权限访问的域名（例如packtpub.com，但不能是packtpub.com，因为该域名属于本书的出版社）。幸运的是，我已经有一个用于其他项目的域名。如果你没有自己的域名并且具有管理权限，建议通过 namecheap.com 获取一个。根据你选择的顶级域名（如 .com、.net 或 .io），每年可能只需 5.00 美元。

2. 一旦你为 Cloud Identity 免费版提供了一个你拥有并且具有管理权限的域名，最后一步是为你的新 Cloud Identity/Google Workspace 账户输入用户名和密码：

图 11.10 – Cloud Identity 凭证创建界面

1. 接下来，Cloud Identity 向导会引导你添加一个 DNS 验证记录到你的域名，以便 Cloud Identity 可以保护它。该应用程序知道我使用 Namecheap 注册域名，并在添加验证记录时引导我，如下所示：

图 11.11 – 如何将 Cloud Identity 账户与 DNS 提供商连接

一旦按照向导中的步骤操作，可能需要等待几分钟才能完成 DNS 验证过程。

1. 然后，你将看到这样一个界面，在这里你可以点击蓝色的继续按钮：

图 11.12 – Cloud Identity 用户设置界面

一旦 Cloud Identity 设置完成，Google 还不会让你访问 SCC。请按照 Google Cloud 文档中 创建和管理组织资源 (cloud.google.com/resource-manager/docs/creating-managing-organization) 页面上的说明，将你的 Cloud Identity 添加到具有 SCC 访问权限的组织中。我发现 TechTrapture 的 YouTube 视频 如何在 GCP 中创建组织、文件夹和项目 (www.youtube.com/watch?v=QvpedBNZqvA) 对确保我的 Cloud Identity 账户是我可以添加项目的组织非常有帮助，从而能够访问 SCC。

在我的 Google Cloud 控制台的 IAM 部分（console.cloud.google.com），我需要确保我的所有者账户具有 Security Center Admin 访问权限，像这样：

图 11.13 – 在 GCP 中为用户账户分配角色

探索 GCP 控制台

一旦进入，你会看到左侧的菜单，其中包含以下面板：

• 概览

• 威胁

• 漏洞

• 合规性

• 资产

• 发现

• 来源

现在我们已经看过了 SCC，知道如何在进行渗透测试时访问它，以获取重要的安全状态信息。

一旦你用你的管理员 Cloud Identity 账户和组织设置好一切，你可以随时通过 console.cloud.google.com 的 Web 应用程序访问 SCC。我通常的做法是在控制台屏幕顶部菜单栏的搜索框中搜索 SecurityCommand Center。

你可以在渗透测试报告中使用这些数据。合规性 面板对你组织的蓝队尤其重要。你的组织可能需要遵守许多数据保护法规，包括 PCI DSS、萨班斯-奥克斯利法案、HIPAA、GDPR 等等。哪些适用于你的组织取决于你的行业、所在地区以及你公司管理哪些外国国家的数据。例如，你的公司可能位于印度，但如果一些客户在欧盟，GDPR 将适用于你组织如何处理他们的数据。

在进行 GCP 渗透测试之前，确保查看 Security Command Center，并在编写渗透测试报告之前。漏洞、资产 和 发现 面板对你的报告特别有用。

现在，让我们在 GCP 中运行一些漏洞扫描和渗透测试吧！

安装 GCP 渗透测试工具

我们将在 GCP 实例中使用一些不同的第三方工具来进行安全扫描。首先，我们将安装它们。

Prowler

我在 第五章 中提到过 Prowler 在 AWS 上的应用，在 第八章 中提到过在 Azure 上的应用。你也可以使用 Prowler 来查找 GCP 中的漏洞。我将简要地带你走过这个过程，因为 Prowler 在本书中已经讲解得比较多了。

我们将做的所有操作都将在 Cloud Shell 中完成。在 GCP 控制台的 Web 应用中，点击搜索栏右侧看起来像 >_ 的图标打开 Cloud Shell。默认的 CLI 是终端，即 Bash。我们在 AWS 和 Azure 章节中使用的所有 Linux Bash 命令都能在这里工作。

首先，我通过以下命令验证了是否安装了 pip 以及版本：

pip -V

这是我在命令行中得到的响应：

pip 20.3.4 from /usr/lib/python3/dist-packages/pip (python 3.9)

因此，pip 已经在我的 GCP 基于 Linux 的虚拟机中安装好了 Python 3.9，而我无需做任何操作。pip 是一个用来安装 Python 应用程序的工具。Prowler 基于 Python。所以，你可以使用以下命令在 GCP 中安装 Prowler：

sudo apt-get install python3-distutils
pip install prowler

另外，你也可以使用 GitHub 来安装 Prowler，使用以下命令，然后安装后进行验证：

git clone https://github.com/prowler-cloud/prowler
cd prowler
python prowler.py -v

接下来，让我们安装 GCPBucketBrute，这是我在 第十章 中介绍的工具。

GCPBucketBrute

GCPBucketBrute 专门用于扫描 Google Storage 桶，确定你对它们的访问权限，以及是否能够进行权限提升。这对于你的渗透测试报告非常有用，因为如果 GCPBucketBrute 可以轻松访问你的桶，那么恶意的网络攻击者也能做到！

我们可以使用 git 从 Cloud Shell 安装 GCPBucketBrute（如果你仍在 Prowler 目录中，先使用 cd 命令返回主目录）：

git clone https://github.com/RhinoSecurityLabs/GCPBucketBrute.git
cd GCPBucketBrute/
pip3 install -r requirements.txt

现在，让我们安装 GCP Scanner。

GCP Scanner

GCP Scanner 是一个由 Google 开发的 GCP 渗透测试应用程序，但他们在 README 文件中说明了这一点 (github.com/google/gcp_scanner)：

“这个项目不是 Google 官方项目。它不受 Google 支持，Google 明确声明不对其质量、适销性或适用于特定用途的保证负责。”

我发现通过 git 安装 GCP Scanner 最为有效：

git clone https://github.com/google/gcp_scanner
cd gcp_scanner
pip install .

接下来，让我们运行刚刚安装的应用程序！

利用 GCP 应用

现在我们已经安装了一些第三方扫描工具，是时候使用它们了。

Prowler

让我们首先通过 Prowler 来了解 GCP 扫描的基础。

默认情况下，Prowler 会使用你用于登录 GCP 的账户凭证。如果你需要更换账户，可以在 GCP Web 控制台的 IAM 中验证你的账户。验证账户凭证后，你可以使用以下命令更改 GCP 中的账户：

gcloud config set account <account>

现在，我们可以通过这个命令在 GCP 中运行默认的 Prowler 扫描。首先确保你在 Prowler 目录中，然后运行扫描：

cd prowler
prowler gcp

如果你使用 GitHub 安装了 Prowler，请在命令中使用 prowler.py，而不是 prowler。

我建议首先执行 help 文件，这样你可以查看 Prowler 中可以使用的所有命令和选项。和之前的章节一样，你可以让 Prowler 列出服务和检查项，并在特定位置使用特定的日志选项运行服务扫描和检查。所有这些信息都可以通过以下命令在 Cloud Shell CLI 上打印出来：

prowler -h

或者，你也可以使用以下命令：

python prowler.py -h

扫描结果可以在屏幕上打印，也可以以 CSV、JSON 或 HTML 文件的形式保存在 Prowler 目录中。你可以在撰写渗透测试报告时使用这些日志。

GCPBucketBrute

接下来，让我们使用 GCPBucketBrute 进行扫描。只要你登录的是用户账户而不是服务账户，你就可以通过未认证扫描获得有效的结果。你可能需要先进入 GCP 网络控制台，确保你已登录用户账户。

接下来，输入这个命令：

python3 gcpbucketbrute.py -k <enter your keyword here> -u

在 CiA 视频中，我使用了 test 关键词，像这样：

python3 gcpbucketbrute.py -k test -u

我还建议尝试其他可能出现在你存储桶文件中的关键词，比如 file 或 print。

当我用 test 进行扫描时，这就是我的结果的开始。不过，我在命令行界面的输出远比这个长：

    EXISTS: test-pubsub
    EXISTS: project_test
    EXISTS: dl_test
    EXISTS: test_6
    EXISTS: test-export
    EXISTS: gcplogs-test
    EXISTS: teamcity-test
    EXISTS: testproject
    EXISTS: appenginetest
    EXISTS: test-artifacts
    EXISTS: estest
    EXISTS: ops_test
    EXISTS: staging_test
    EXISTS: testtemp
    EXISTS: templates-test
    EXISTS: bucket_test
    EXISTS: testservices
    EXISTS: syslog-test
    EXISTS: test-sitemaps
    EXISTS: cloudtest
    EXISTS: trace-test
    EXISTS: audit_test
    EXISTS: test_ml
    EXISTS: gcp-logs-test
    EXISTS: test-videos
    EXISTS: ux_test
    EXISTS: test_tasks
    EXISTS: tmp_test
    EXISTS: dockertest
    EXISTS: testassets
    EXISTS: testops
    EXISTS: test_support
    UNAUTHENTICATED ACCESS ALLOWED: pictures-test
        - UNAUTHENTICATED LISTABLE (storage.objects.list)
        - UNAUTHENTICATED READABLE (storage.objects.get)
        - ALL PERMISSIONS:
            [
                "storage.objects.get",
                "storage.objects.list"
            ]

GCP Scanner

现在，让我们试一下 GCP Scanner。首先，确保你位于 GCP Scanner 所在的目录：

cd gcp_scanner

创建一个文件夹来保存你的扫描结果：

mkdir <folder name of your choice here>

如果你输入这个命令，你将在命令行中得到一个便捷的帮助指南：

python3 scanner.py -h

我使用这个命令运行了一个简单的元数据扫描。这个命令检查你 GCP VM 文件中的元数据，以查看是否有敏感凭证暴露在其中：

python3 scanner.py -o <folder name you used in mkdir command here> -ls -m

随时玩转 GCP Scanner 帮助指南中显示的所有选项和参数：

GCP Scanner
optional arguments:
  -h, --help            show this help message and exit
  -ls, --light-scan     Return only the most important GCP resource fields in the output.
  -k KEY_PATH, --sa-key-path KEY_PATH
                        Path to directory with SA keys in json format
  -g GCLOUD_PROFILE_PATH, --gcloud-profile-path GCLOUD_PROFILE_PATH
                        Path to directory with gcloud profile. Specify - to search for credentials in default gcloud config path
  -m, --use-metadata    Extract credentials from GCE instance metadata
  -at ACCESS_TOKEN_FILES, --access-token-files ACCESS_TOKEN_FILES
                        A list of comma separated files with access token and OAuth scopes.TTL limited. A token and scopes should be stored in JSON format.
  -rt REFRESH_TOKEN_FILES, --refresh-token-files REFRESH_TOKEN_FILES
                        A list of comma separated files with refresh_token, client_id,token_uri and client_secret stored in JSON format.
  -s KEY_NAME, --service-account KEY_NAME
                        Name of individual SA to scan
  -p TARGET_PROJECT, --project TARGET_PROJECT
                        Name of individual project to scan
  -f FORCE_PROJECTS, --force-projects FORCE_PROJECTS
                        Comma separated list of project names to include in the scan
  -c CONFIG_PATH, --config CONFIG_PATH
                        A path to config file with a set of specific resources to scan.
  -l {DEBUG,INFO,WARNING,ERROR,CRITICAL}, --logging {DEBUG,INFO,WARNING,ERROR,CRITICAL}
                        Set logging level (INFO, WARNING, ERROR)
  -lf LOG_FILE, --log-file LOG_FILE
                        Save logs to the path specified rather than displaying in console

恭喜你，你刚刚生成了一些 GCP 渗透测试扫描日志，你可以在渗透测试报告中引用它们！

在下一章中，我们将进行 GCP 中 Docker 和 Kubernetes 容器内的渗透测试扫描。

总结

创建一个 GCP 网络进行渗透测试练习所需的一切，都可以通过 GCP 免费层的服务来完成。只需确保你在 GCP 网络控制台中检查账单，确保不会产生费用。

你可能需要设置一个 Google Workspace 或 Cloud Identity 账户，才能充分利用 GCP。这包括使用 SCC。SCC 是所有 GCP 内置安全工具的起点。它整合了各种第一方的 GCP 安全工具。你可以使用 SCC 检查一些威胁、漏洞和基于 Google 威胁情报的安全建议。就像使用第三方渗透测试工具一样，SCC 也可以提供一些有用的信息，供你在渗透测试报告中使用。

就像在 AWS 和 Azure 中一样，Prowler 也可以用来扫描 GCP 中的漏洞和合规性。我们在 Cloud Shell 的命令行中运行了 Prowler 漏洞扫描。

GCPBucketBrute 检查攻击者是否能访问你的 GCP 存储桶，以及他们是否可以提权。因为我们刚刚在 GCP 上设置了一个简单的虚拟机部署，内容不多，没想到 GCPBucketBrute 竟然还能找到存在未认证访问权限的地方！

GCP 扫描器可用于确定特定凭证在你的 GCP 部署中拥有何种访问权限。

在下一章，我们将部署 Docker 和 Kubernetes 集群在 GCP 上，并在其中运行一些漏洞扫描。

深入阅读

若想了解本章涉及的更多内容，请查看以下资源：

• GCP 中的免费服务列表：cloud.google.com/free?hl=en

• TechTrapture 的 YouTube 视频 如何在 GCP 中创建组织、文件夹和项目：www.youtube.com/watch?v=QvpedBNZqvA

• Prowler 在 GCP 中的使用：docs.prowler.cloud/en/latest/#google-cloud

• GCPBucketBrute：github.com/RhinoSecurityLabs/GCPBucketBrute

• GCP 扫描器：github.com/google/gcp_scanner

第十二章：在 GCP 中进行容器化应用的渗透测试

如果你所在的组织从事 DevOps 或 CI/CD 应用程序开发，极有可能他们在 GCP 中有 Docker 或 Kubernetes 集群。让我们学习如何对它们进行渗透测试。

本章中，我将解释什么是容器化，为什么要使用容器化，以及容器化通常是如何工作的。我们将学习 Docker 和 Kubernetes 在 GCP 中的工作原理，以及如何在 GCP 中使用 Trivy 与基于 Docker 和 Kubernetes 的应用程序进行配合。

本章中，我们将涵盖以下主题：

• 容器化是如何工作的

• Docker 在 GCP 中是如何工作的

• Kubernetes 在 GCP 中是如何工作的

• 在 GCP 中进行 Docker 和 Kubernetes 的渗透测试技术

那么，让我们在 GCP 中探索容器化吧！

技术要求

我们将使用微软的基础设施。庞大的 Azure 数据中心将为本章中的练习提供大量计算处理工作。因此，幸运的是，你不需要一台顶级的工作站。你需要以下设备：

• 一个网页浏览器

• 一台桌面或笔记本电脑

• 一台安卓手机或 iPhone 手机

• 一个良好的、可靠的互联网连接

查看以下视频以查看代码演示：bit.ly/404CEg8

容器化是如何工作的

计算机虚拟化是关于软件模拟硬件功能的。例如，我的笔记本电脑是一台计算机。但在我的电脑上，我可以运行一些软件，假装同时运行几台不同的计算机。（幸好我将笔记本电脑的内存扩展到了 64GB，因为每台模拟计算机可能需要 4GB 的内存！）每台计算机的 CPU、RAM、硬盘和 I/O 设备接口都在软件中被模拟。软件使用我笔记本电脑的实际 CPU、RAM、硬盘和 I/O 接口，并分配它们的容量，以创建几台虚拟计算机。当操作系统和应用程序安装在这些虚拟计算机上时，就操作系统和应用程序本身而言，它们认为每台虚拟计算机都是在自己的物理计算机上运行。

在云网络中部署虚拟化有两种常见方式——虚拟机和容器。

虚拟机

VMs 是模拟计算机，正如我在示例中所描述的那样。它们并不是直接在 PC 或服务器硬件上运行，而是模拟运行操作系统所需的所有硬件组件。在这个模型中，我的笔记本电脑运行一个虚拟机监控器，它充当虚拟机与我的物理计算机之间的层。

你可以在自己的 PC 上使用像 Oracle VirtualBox 或 VMware Workstation Player 这样的应用程序，作为虚拟机的虚拟机监控器。你所需要的只是一个操作系统的磁盘镜像文件，想要在虚拟机中运行该操作系统，然后在虚拟机监控器中进行配置。操作系统不需要与主机操作系统匹配，实际上它们通常并不匹配。我可以在我的 Windows 11 PC 上运行一个 Kali Linux 虚拟机。你可以在你的 MacBook 上运行一个 Windows 11 虚拟机。我也可以在我的 Kubuntu Linux 桌面上运行一个 macOS 虚拟机。

虚拟机也可以在 GCP 等云平台上运行。这样，虚拟化计算机就运行在 Google 的计算机上，而不是你可以物理接触的自己设备上。虚拟机是 GCP 的一个常见使用案例，当公司希望长时间在 GCP 上运行单一计算机时，虚拟机是一个不错的解决方案，例如作为 Web 服务器或邮件服务器。你每天访问的许多网站都托管在运行在云平台（如 GCP）上的虚拟机上！

但是，当公司部署大规模的动态应用时，虚拟机并不是最佳选择，例如使用 DevOps 或 CI/CD 方法论，这些方法要求应用具有高度可扩展性和响应能力。DevOps 或 CI/CD 应用所需的计算处理能力、内存和网络带宽可能一天减少一半，第二天又增加一倍，而虚拟机的硬件容量无法像容器一样迅速变化。分配给虚拟机的硬件资源相对固定。

容器化应运而生。

容器

Docker 和 Kubernetes 是当今公司常用的两种容器化编排平台。容器化编排平台可以自动启动和终止容器，无需直接的人为操作。这些平台管理容器的部署，并处理虚拟化硬件内的负载均衡，只分配所需的硬件资源，如 CPU 和内存。

云平台使得公司和其他类型的企业能够实现容器化应用。Google 在全球各地的多个数据中心拥有庞大的计算机网络和硬件资源，其中很多资源专门用于向全球的商业客户提供 GCP 服务。

Docker 在 GCP 中的工作原理

Docker 不是第一个存在的容器化技术，但它可能是第一个被全球公司和组织广泛使用的容器化技术。它也是 Kubernetes 的基础，Kubernetes 是另一种流行的容器部署方式。Docker 和 Kubernetes 不是像可口可乐与百事可乐那样的竞争对手，而是 Kubernetes 是 Docker 的一个分支，就像将 Debian Linux 和基于 Debian 的 Ubuntu Linux 进行对比一样。

这是一个 Docker 容器化编排系统的基本架构（你可以参考第六章查看架构图）。

Docker 主机直接运行在你的电脑上，或在你管理的云服务上的计算机（例如 Google Compute Engine，或 GCE）。在 Docker 主机中，Docker 守护进程存储 Docker 镜像，并根据这些镜像创建和管理容器。Docker 镜像非常像操作系统的磁盘镜像 ISO 文件，你可以使用这些镜像来创建虚拟机。事实上，许多 Docker 镜像是使用普通操作系统（如 Ubuntu Linux）制作的。然而，这些镜像及其容器可能没有操作系统的所有组件，而仅包含运行容器化应用所需的部分。

Docker 主机连接到注册表，通常（但不总是）该注册表托管在外部网络上，通常是互联网。注册表使 Docker 镜像可以供 Docker 主机下载。注册表还会维护这些镜像并像其他互联网托管的软件一样进行更新，类似于 Git 仓库。

最后，运行在 GCP 控制台或 Docker Desktop 终端上的 Docker 客户端是你可以执行命令的地方，命令将传递给 Docker 守护进程（在你的 Docker 主机下）。这就是你如何向 Docker 容器化编排系统发送指令。在本章中，我们将通过这种方式向 Docker 系统执行命令。

在 GCP 中部署 Docker 容器化系统的默认方式是使用 Cloud Build 来简化 Docker 构建步骤，并利用 Cloud Run 来运行容器化的应用程序，同时 Docker 主机在 GCE 中运行。

这是 Google 对 Cloud Build 的描述（cloud.google.com/build）：

“Cloud Build 根据需要进行扩展和缩小，无需设置、升级或扩展基础设施。在 Google Cloud 中的完全托管环境中运行构建，并与您自己的私有网络连接。”

Cloud Build 是一个在后台运行的系统，当你以常规方式在 GCP 中部署 Docker 容器化时，它会执行相关操作。它使开发人员免去管理运行 Docker 容器的服务器的繁琐工作。

这是 Google 对 Cloud Run 的描述（cloud.google.com/run/docs/overview/what-is-cloud-run）：

“Cloud Run 使开发人员能够将更多时间花在编写代码上，而很少需要操作、配置和扩展 Cloud Run 服务。你不需要创建集群或管理基础设施就可以高效使用 Cloud Run。”

Cloud Run 是另一个在后台运行的系统，当你以常规方式在 GCP 中部署 Docker 容器化时，它将为开发人员省去调整计算处理配置的麻烦，这些配置用于执行 Docker 容器。

现在我们已经了解了在 GCP 中使用 Docker，接下来是时候学习 Kubernetes 在 GCP 中的工作原理。

Kubernetes 在 GCP 中的工作原理

Kubernetes 可以用于在 AWS 和 Azure 上部署容器化应用程序。在第六章和第九章中，我带领你们了解了如何在这些平台上部署 Kubernetes，并对其进行了渗透测试。但是，GCP 可以说是 Kubernetes 的发源地。原因如下。

Kubernetes 最初是由 Google 的一个团队开发的。Kubernetes 项目在 2014 年由 Google 云计算专家 Eric Brewer 宣布（web.archive.org/web/20150910171929/http:/www.wired.com/2014/06/google-kubernetes）。Kubernetes 的灵感来自于 Docker 所推动的一些容器化创新。但 Kubernetes 主要受到 Borg 的影响（web.archive.org/web/20160701040235/http:/www.wired.com/2015/06/google-kubernetes-says-future-cloud-computing/），Borg 是 Google 用于内部目的的专有云计算中间件。Borg 帮助支撑 Gmail、Google 搜索、Google 地图和其他许多流行的 Google 服务的后台运行。

Google 的 Joe Beda、Brendan Burns、Brian Grant、Tim Hockin 和 Craig McLuckie 将 Kubernetes 构思为一个开源平台，可以用于许多 Google 在内部为 Borg 部署的相同用例。到 2015 年 7 月，Kubernetes 的第一个版本公开发布。到 2017 年，Red Hat（IBM）、VMware、Docker, Inc.、Microsoft Azure 和 AWS 等大型科技公司和软件开发商都宣布支持它。这就是 开源软件（OSS）和开放标准的魅力！正如一些组织拥有集成 AWS、Azure 和 GCP 服务的多云网络一样，一些组织同时也拥有 Docker 和 Kubernetes 容器化应用。

这是一个 Kubernetes 容器化编排系统的基本架构（你可以参考 第六章 查看架构图）。

控制平面支持整个容器化系统，并作为 Kubernetes 基于的网络和云平台之间的载体，例如 GCP 中的 Google Kubernetes Engine（GKE）。控制平面包含几个组件，其中包括以下列出的组件：

• etcd 是一个键值存储。它维护着你所有集群的数据。

• Pods 在节点的支持下运行，kube-scheduler 会为新创建的 Pods 分配节点。

• kube-apiserver 管理 Kubernetes API。因此，它帮助你的 Kubernetes 基于的应用程序与外部应用程序集成。这也是 kubectl（ctl 代表 命令行工具）连接的地方，以便向你的 Kubernetes 系统发送命令。

• kube-controller-manager 运行控制器过程。这里有用于维护节点的控制器、用于执行计划任务的控制器（例如，“每天晚上 6 点备份这些文件”）、用于在服务和 Pods 之间生成链接的控制器，以及用于创建服务账户的控制器。Pods 和节点将在本节后面讲解。

• cloud-controller-manager将你的 Kubernetes 网络连接到云提供商的 API。在 GCP 中，cloud-controller-manager通常与 GKE 接口对接。

• 节点是控制平面的子资源。根据应用程序的需求，节点的数量可能是 2 个、20 个，或者更多。每个节点都包含一个 kubelet。kubelet 是一个节点代理，使用主机名或其他特定于云提供商的标识符将节点注册到 API 服务器。

• Pod是节点的子资源，也因此是控制平面的孙子资源。每个节点中的 kubelet 根据 PodSpec 来定义节点，PodSpec 是以 YAML 或 JSON 文件形式编写的。需要知道的是，YAML 在某些方面类似于 HTML，而 JSON 是为 JavaScript 使用而创建的——这两种技术都是为 Web 开发而产生的。YAML 和 JSON 文件可以在文本编辑器中查看，有时它们仅包含几行代码。你在作为渗透测试员或红队成员进行漏洞扫描时，可能会扫描 YAML 和 JSON 文件，具体情况视情况而定。但本书的目的并不要求你学会编写自己的 YAML 或 JSON 文件。

每个 Pod 都有一个容器运行时环境，容器在其中运行。容器是由容器镜像构成的，这些镜像类似于操作系统的 ISO 磁盘镜像，通常用于虚拟机中。但是，Kubernetes 的容器镜像只包含执行代码所需的操作系统组件。可以使用许多默认的容器镜像，有时，容器镜像也会根据特定公司及其应用程序进行定制。

最后，节点（包含 Pods）通过负载均衡器与外部交互，负载均衡器帮助管理任何给定时间所需的硬件和网络资源。负载均衡器还为基于 Kubernetes 的应用程序和终端用户之间提供了一个接口。

作为一名云渗透测试员，了解负载均衡器和 API 服务器都可能成为针对 Kubernetes 应用的网络攻击的攻击面是很有帮助的！负载均衡器最常受到来自 Ingress 的网络攻击，Ingress 的流量是从你的云与外部网络之间的南北方向流动的，而 API 服务器则更容易遭受来自云网络内部组件之间东西向的攻击。有时，网络攻击会通过入口路由从公共互联网进入，然后利用横向移动在云网络的不同部分之间传播，这可能涉及权限提升。这有点像小偷闯入百货商店的珠宝部，接着又转到香水和化妆品部。

整个 Kubernetes 容器化系统被称为集群。某些组织可能会部署多个集群。但是，无论组织使用多少个集群，每个集群都由控制平面、节点和 Pods 组成，顺序从底至顶。

GKE（cloud.google.com/kubernetes-engine）是一个专为运行基于 Kubernetes 的应用程序而设计的 GCP 服务。它自动化了集群和节点管理，以及通过负载均衡器提供硬件资源的方式。在绝大多数情况下，大大小小的组织都会选择通过 GKE 在 GCP 上运行 Kubernetes 应用程序。

云计算和容器化的优势在于，应用程序可以变得非常可扩展、动态且高效地使用硬件资源。很多应用程序部署和网络管理的繁琐工作可以通过自动化来完成。因此，组织自然会倾向于使用 GKE，以免陷入服务器管理任务的困扰。在云中的容器化应用程序甚至可以在几天内实现翻倍或减半。无论何时，都应该根据需求提供足够的计算能力和带宽，而容器有时甚至只有几个小时的生命周期。

难怪云计算彻底改变了各类组织在各行各业中通过互联网部署应用程序的方式。然而，组织通过云部署的容器化应用程序与通过云部署的虚拟机一样，可能成为网络攻击者的有吸引力的目标。它们与互联网连接，这为攻击者提供了访问的途径。而且，它们可能包含敏感信息，这些信息能为网络犯罪分子带来丰厚的回报，比如敏感的财务数据。

作为云渗透测试员，你的任务是确保在攻击者尝试进行攻击之前，发现攻击者如何危害你客户的云网络。这样，你所在的公司就能相应地改进其安全措施。

因此，在本书的最后一组实际渗透测试练习中，让我们开始在 GCP 中进行 Docker 和 Kubernetes 的渗透测试吧！

GCP 中的 Docker 和 Kubernetes 渗透测试技术

既然我们了解了 Docker 和 Kubernetes，让我们在 GCP 中部署它们。然后，我们将进行渗透测试。首先，让我们部署我们将练习渗透测试的 Docker 和 Kubernetes 集群。

部署 Docker

我们将在 Docker 部署中使用基本的默认 Docker 容器镜像，因为我们并没有做什么复杂的操作；我们只是试用我们的渗透测试工具！请按照以下步骤进行：

1. 我们在 GCP 中部署 Docker 集群的最简单方式是从 Cloud Run 开始。使用你的网络浏览器登录到我们在第十一章中设置的 Google Cloud 帐号。进入 GCP 网页控制台后，访问 console.cloud.google.com/run 使用 Cloud Run。

   Cloud Run 界面应该像这样：

图 12.1 – GCP 控制台中的 Cloud Run 面板

1. 点击顶部菜单栏下方的 +CREATE SERVICE。你将看到一个像这样的界面：

图 12.2 – 在 GCP 中创建 Cloud Run 服务以运行 Docker

我们将尽可能使用默认设置，以便创建一个基础的 Docker 环境来尝试我们的渗透测试工具。如果你打算使用 Docker 容器部署某种特定类型的应用，可能需要在 Cloud Run 中使用不同的设置。

为了简单起见，以下是我为我的 Docker 部署在 Cloud Run 中选择的选项：

• 在顶部提供的从现有容器镜像部署一个版本和从源代码仓库持续部署新版本选项中，我选择了第一个选项。

• 接下来，我没有输入容器镜像 URL，而是点击了使用示例容器进行测试。

在此页面，我点击了容器注册表选项卡，并选择了hello演示容器。然后，我点击了容器镜像 URL 旁的选择：

图 12.3 – 为我们的 Docker 实例选择 Docker 镜像

• 在服务名称字段中，我输入了crawleydockertest。我保留了我的默认区域，对于我来说是us-central1 (lowa)。你的默认区域可能不同。每个区域代表一个特定的 Google 数据中心，而且可能不在你的国家。

• 为了节省费用，在CPU 分配和定价下，我选择了仅在请求处理期间分配 CPU。

• 我没有更改自动扩展选项。默认情况下，0 是最小实例数，100 是最大实例数。这种设置反映了云应用的可扩展性。新实例可以根据应用的需求自动生成。

• 在入口控制下，我选择了全部，这将允许从互联网直接访问你的服务。

• 在身份验证下，我选择了允许未经身份验证的调用。这些选项可能不是最佳的网络安全实践，但它们使得在我们的 Docker 应用中尝试渗透测试工具变得更加简单。

1. 最后，我点击了底部的蓝色创建按钮。

   当服务创建完成时，你的网页控制台界面应该会像这样。对于我来说，创建过程大约花了 30 秒；我并没有等待很长时间：

图 12.4 – 为我们的 Docker 实例创建服务

现在，我们的 Docker 环境已经在 GCP 中创建好了，接下来是创建 Kubernetes 环境！

部署 Kubernetes

在 Cloud Shell 或其他某些 CLI 中也可以部署 Kubernetes，但我更喜欢使用网页控制台来部署服务，使用 CLI 来进行渗透测试工具的操作。按照以下步骤部署 Kubernetes：

1. 在 GCP 的网页端登录并进入网页控制台后，访问console.cloud.google.com/projectselector2/home/dashboard。

2. 目前，保持你刚刚打开的项目选择器网页标签不动。在另一个标签页中打开启用 API 访问，并使用此链接：console.cloud.google.com/flows/enableapi?apiid=artifactregistry.googleapis.com。

   你会看到如下界面：

图 12.5 – 为 Kubernetes 启用所需的 API 访问

1. 点击确认项目。启用 API会过渡并显示你即将启用Artifact Registry API和Kubernetes Engine API。这正是我们要做的。点击启用。

2. 你可能需要等待几分钟才能完成 API 启用的处理。我很惊讶这比创建我的 Docker 测试容器还花了更多时间。但完成后，返回到带有项目选择器仪表板的网页标签。那应该看起来像这样：

图 12.6 – 在 GCP 中为我们的 Kubernetes 实例选择一个项目

1. 点击一个项目。记下你的项目 ID；它应该类似于blissful-axiom-115916，如前面的截图所示。

2. 现在，我们将在 Cloud Shell 的 CLI 中完成剩下的工作。点击右上角菜单栏中看起来像这样图标：>_。

3. 首先，我们将确保我们选择的项目是默认项目，方法是在命令行中输入以下命令：

   gcloud config set project <your project ID goes here>
   

4. 接下来，我们将使用此命令创建一个默认的自动驾驶 Kubernetes 集群。如果你之前设置的区域不是us-central1，则将其更改为你的区域名称：

   gcloud container clusters create-auto hello-cluster \
       --location=us-central1
   

   如你在本练习的Code in Action视频中所见，创建集群可能需要几分钟时间。耐心等待！幸运的是，Cloud Shell 中的命令行会显示等待时的进展。

5. 在创建 Kubernetes 集群的几分钟过程完成后，你接下来需要为集群创建身份验证凭证。这将使kubectl（你在命令行中用来管理 Kubernetes 集群的程序）准备好使用你的新集群。只要确保如果你的区域名称与us-central1不同，请更改为你所在的区域名称：

   gcloud container clusters get-credentials hello-cluster \
      --location us-central1
   

6. 接下来，我们将使用以下命令在新的 Kubernetes 集群中创建应用程序部署。image=后面的目录路径是我们默认的hello Kubernetes 容器镜像，用于测试目的。如果你在读完本书后，想在 GCP 中使用 Kubernetes 做一些特定的操作，可以修改命令以使用不同的容器镜像：

   kubectl create deployment hello-server \
       --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

7. 现在，我们需要设置负载均衡器，以便将我们的部署暴露到互联网上。我们将通过互联网访问我们的 Kubernetes 部署以进行渗透测试，所以这一步是绝对必要的：

   kubectl expose deployment hello-server \
       --type LoadBalancer \
       --port 80 \
       --target-port 8080
   

8. 最后，我们需要运行一些检查，以确保我们的 Kubernetes 部署已经准备好使用。首先，让我们检查一下 Pods：

   kubectl get pods
   

   命令行应该显示一个hello-server Pod。

9. 现在，我们将检查hello-server：

   kubectl get service hello-server
   

10. 复制命令行上打印出的外部 IP。

11. 在新的 Web 浏览器标签页中，在地址栏输入http://<your external IP here>并按Enter。

12. 我访问 Kubernetes 部署的外部连接较慢，但最终还是成功了。在 Firefox 中，我收到了一个错误提示，警告我目标是 HTTP 而非 HTTPS。我点击了按钮，访问 HTTP 网站，屏幕上显示了这个内容。成功了！

图 12.7 – 在 Web 浏览器中查看我们的 Kubernetes 部署的 IP 地址

现在我们在 GCP 中已经有了一个正常工作的 Docker 环境和 Kubernetes 环境，是时候利用这些环境来尝试一些渗透测试工具了。

Trivy

Trivy (github.com/aquasecurity/trivy) 是由 Aqua Security 开发的渗透测试工具，且可在 GitHub 上获取。它是一个安全扫描工具，可以在文件系统、虚拟机镜像和 AWS 中发现漏洞。同时，它也可以用来扫描 Docker 和 Kubernetes 镜像。

Trivy 可以在 Red Hat、CentOS、Arch Linux 和 macOS 上运行。所有支持平台的安装说明可以在此处找到：aquasecurity.github.io/trivy/v0.44/getting-started/installation/。我在 GCP 部署的 Linux 虚拟机基于 Debian，因此我将使用 Debian 的安装说明：

wget https://github.com/aquasecurity/trivy/releases/download/v0.44.1/
trivy_0.44.1_Linux-64bit.deb
sudo dpkg -i trivy_0.44.1_Linux-64bit.deb

现在我们已经在 GCP 的 Linux 虚拟机上安装了 Trivy，让我们尝试几个基本的容器扫描练习。如果你想尝试其他的，Trivy 用户和开发者在他们的网站上提供了广泛的容器渗透测试教程 (aquasecurity.github.io/trivy/v0.45/tutorials/overview/)。

让我们尝试寻找我配置 Docker 镜像时的错误配置。记住——错误配置是可以被网络攻击者利用的安全漏洞！按照以下步骤操作：

1. 我使用了 GCP 的默认hello测试 Docker 镜像来构建我的 Docker 容器。这是它的名称和地址：

   us-docker.pkg.dev/cloudrun/container/hello
   

2. 你需要验证你使用的镜像的名称和地址。在你的 GCP 控制台中，搜索Cloud Run。然后你将看到如下画面：

图 12.8 – 在 Cloud Run 界面查看我们的 Docker 实例

1. 我点击了我的 Docker 集群的名称，在我的案例中是crawleydockertest。

   然后，我点击了YAML选项卡，查看了用于构建我的 Docker 集群的 YAML 文件。在image:所在的位置，我找到了我使用的 Docker 镜像的名称和地址。你可以通过相同的方法找到你的镜像：

图 12.9 – 查看用于创建我的 Docker 集群的 YAML 文件

1. 现在，让我们运行扫描：

   trivy image --image-config-scanners config <insert image location and name here>
   

   我的 Docker 镜像找到了，而且配置非常错误！以下是我得到的结果：

图 12.10 – Trivy 扫描输出

如果你正在进行实际的渗透测试，你可以在报告中使用这种类型的数据。

现在，让我们尝试使用 Trivy 对我在 GCP 中的 Kubernetes 集群进行渗透测试：

1. 首先，我发现我需要再次暴露我的 Kubernetes 集群，以便 Trivy 能够扫描它：

   kubectl expose deployment hello-server \
       --type LoadBalancer \
       --port 80 \
       --target-port 8080
   

2. 然后，我检查了 Pods：

   kubectl get pods
   

3. 现在，这里有一个 Trivy 命令，对我的 Kubernetes 集群进行了非常彻底的扫描：

   trivy k8s -n kube-system --report summary all –timeout 1500s
   

   在 Cloud Shell CLI 中等待了几分钟后，我得到了一个非常详细的总结，可以用于渗透测试报告中：

图 12.11 – Trivy 扫描漏洞报告

Trivy 非常有趣，值得探索！

总结

在本章中，我们了解了 GCP 中哪些服务负责容器化管理。我们部署了自己的 Docker 和 Kubernetes 集群。然后，我们使用 Trivy 进行了安全评估。

在 GCP 中部署 Docker 容器化系统的默认方式是使用 Cloud Build 简化 Docker 构建步骤，使用 Cloud Run 帮助运行容器化应用，同时 Docker 主机运行在 GCE 中。

在 GCP 中部署 Kubernetes 的最简单方式是使用 GKE。

Trivy 是一个第三方渗透测试应用，具有许多出色的功能，用于扫描 Docker 和 Kubernetes 部署的漏洞。

在接下来的最后一章，我将测试你对前 12 章所学内容的掌握情况。此外，我还会给你一些编写和签署渗透测试合同的技巧，更多的渗透测试报告写作建议，并向你介绍一些云计算和渗透测试相关的认证，这些认证可能会使你作为云渗透测试员更具竞争力。

深入阅读

要了解更多关于本章所涵盖的主题，你可以访问以下链接：

• Google Cloud Run: cloud.google.com/run

)

• Google Cloud Build： cloud.google.com/build

)

• GKE: cloud.google.com/kubernetes-engine

)

• Google Cloud 文档关于将容器部署到 Cloud Run： cloud.google.com/run/docs/deploying

)

• Google Cloud 文档：在 GKE中部署 Kubernetes 应用： cloud.google.com/kubernetes-engine/docs/deploy-app-cluster

)

• Trivy：github.com/aquasecurity/trivy

第十三章：最佳实践与总结

所以，我们已经学习了最流行的云平台——AWS、Azure 和 GCP。我们还在自己的 AWS、Azure 和 GCP 部署中进行了一些漏洞扫描和渗透测试练习。

现在，让我们回顾一下所学的内容。我们还将为你提供关于专业认证、渗透测试合同和渗透测试报告的有用信息。在本章中，我们将通过基于本书前面内容的问答回顾知识点，讨论你在云渗透测试工具包中应具备的工具，以及你可以追求的有用的云计算和渗透测试认证。

我们还将讨论渗透测试合同中应包含的内容以及如何撰写有效的渗透测试报告。

我们将涵盖以下主要内容：

• 内容回顾

• 你的云渗透测试工具包

• 云计算与渗透测试认证

• 渗透测试合同

• 渗透测试报告

让我们直接开始吧！

内容回顾

你从阅读本书中学到了很多！我们不仅讨论了一个云平台，而是涵盖了三大最常用的云平台——AWS、Azure 和 GCP。此外，你还了解了渗透测试和红队工作的基本原则和概念，以及如何与防守性网络安全专家和企业领导层分享你发现的安全漏洞。

这是一大堆信息需要吸收。在你作为云渗透测试员的头几年，你可能会时不时地重新阅读本书的某些部分。然而，为了准备你的职业生涯，重要的是要看看你是否能记住你所学的内容。人脑更容易记住信息，当它以多种方式思考时。到目前为止，你已经吸收了信息，并通过尝试本书中的多个渗透测试教程将学习付诸实践。现在，是时候回顾你所学的内容，以便追踪你的进展并更容易记住。

幸运的是，这不是一场正式的考试。这只是为了你自己受益的练习。如果你答错了一些问题，不要对自己太苛刻。你会发现自己需要关注的领域，以便改进。学习过程总是涉及从错误中学习！

好的——让我们开始吧！

问题

下面是一些问题，帮助你了解自己的进展：

1. 什么是多云网络？

2. 什么是混合云网络？

3. 当谈到云计算中的安全责任时，云服务提供商负责什么，而你的组织（云服务提供商的客户）负责什么？

4. 在什么情况下，亚马逊允许你在 AWS 中模拟 DDoS 攻击？

5. SaaS、PaaS 和 IaaS 有什么区别？

6. 外部网络攻击和内部网络攻击有什么区别？

7. 什么是 MITRE ATT&CK 数据库？

8. CIA 三元组代表什么，它意味着什么？

9. 什么是零信任网络？

10. 为什么云渗透测试人员需要寻找暴露的服务？

11. 什么是漏洞评估？

12. 什么是身份与访问管理（IAM）？

13. 什么是 RBAC？

14. 什么是 CVE 数据库？

15. 什么是 CVSS？

16. 什么是 EPSS？

17. 红队与蓝队有什么区别？

18. 什么是紫队演练？

19. 什么是渗透测试报告？

20. 什么是 AWS 安全中心（AWS Security Hub）？

21. 什么是 Amazon Inspector？

22. Prowler 用于什么？

23. Pacu 用于什么？

24. 什么是虚拟机（VM）？

25. 什么是容器化？

26. 什么是 Docker？

27. 什么是 Kubernetes？

28. 什么是控制平面？

29. 什么是容器镜像？

30. 本书中提到的可以在所有三个云计算平台（AWS、Azure 和 GCP）上使用的渗透测试工具有哪些？（这不包括只能在某一云平台上使用的工具，如 Microsoft Azure 的 MFASweep 或 AWS 的 Pacu。）

答案

以下是前面问题的答案：

1. 多云网络是指使用多个云平台的云网络。一个多云网络可能包含 AWS 和 GCP、Azure 和 AWS、AWS、Azure 和 GCP，也可能包括本书未涉及的云平台，如 DigitalOcean、Salesforce、IBM Cloud、Oracle Cloud、Rackspace Cloud 等。任何由两个或更多云提供商组成的云网络都属于多云网络。组织通常会部署多云网络，因为他们可能需要某些云平台独有的功能或应用。例如，一家公司可能会使用 Microsoft Azure 来支持其本地 Windows Server 机器的 Active Directory，而使用 GCP 来支持 Google Maps 和其他 Google 服务 API。AWS、Azure 和 GCP 都能够集成到一个大的企业云网络中。

2. 混合云网络将云网络与组织内部的网络相结合。在过去 10-15 年里，全球各行各业的公司都出现了将本地网络功能迁移到云的巨大趋势。但有时，组织发现其网络中的某些部分出于多种原因必须继续保留在本地服务器上。AWS、Azure 和 GCP 都能够与公司的本地网络集成。混合云网络可以使用单一的云平台，也可以是多云网络。对多云混合网络进行渗透测试和红队演练尤其对渗透测试人员来说具有挑战性！

3. 记住云服务提供商的安全责任和贵组织的安全责任的一个简单方法是记住——云服务提供商负责“云的”安全，而贵组织负责“云中的”安全。

   例如，亚马逊对其全球各地的数据中心有着非常强大的物理安全性。很少有人被允许进入其中之一。即使你的公司每月在 AWS 服务上花费 100,000 美元，它也不会让你进入其数据中心。云服务提供商对其数据中心的物理安全性负全责。它还负责确保其网络基础设施和所有物理硬件的安全。如果硬盘驱动器发生物理故障，替换工作由云服务提供商负责。云服务提供商还负责其开发和维护的软件代码。

   你的组织对你投入云基础设施的所有软件代码的安全性负责。你的组织还负责通过云基础设施传输的网络流量。SaaS、PaaS 和 IaaS 是关于你的组织开发（或从第三方开发者处获得）的代码量与云服务提供商开发的代码量的分类。因此，从这个基础出发，很容易理解共享安全责任模型如何在不同类型的云服务之间有所不同。

4. 大多数情况下，你被禁止在任何云平台上模拟 DDoS 攻击，因为它们可能会对云服务提供商的其他客户造成干扰。然而，AWS 会在某些情况下允许 DDoS 模拟测试。根据 AWS DDoS 模拟测试政策（aws.amazon.com/security/ddos-simulation-testing/），在测试中，如果数据包体积不超过每秒 20 GB，或者在测试 CloudFront 时数据包体积不超过每秒 500 万个数据包，或者在测试其他类型的 AWS 资源时不超过每秒 50,000 个数据包，则允许进行某些 DDoS 测试。DDoS 模拟不得来自其他 AWS 资源，并且 AWS 可以随时要求你的组织终止模拟测试。如果你的组织申请了例外请求并且 AWS 明确批准，AWS 可能会对这些规则做出例外。如果这些标准对于你的红队或渗透测试人员来说过于复杂，或者你稍微担心你的 DDoS 模拟可能会被云服务提供商禁止，最好一开始就不要尝试。冒着违反云服务提供商政策的风险是毫无意义的。

5. SaaS 意味着 软件即服务，PaaS 意味着 平台即服务，IaaS 意味着 基础设施即服务。SaaS 表示云服务提供商拥有大部分软件代码和大部分安全责任——例如，Google 生态系统中的 Gmail。PaaS 表示提供商为您组织的部分自有代码（或您从第三方开发者那里获得的代码）开发了一个软件基础。亚马逊的 弹性 Kubernetes 服务（EKS）是 PaaS 的一个例子。亚马逊负责其自有的 Amazon EKS 代码，但您自己的容器镜像、第三方容器镜像、您的容器，以及您的组织如何在 Amazon EKS 中使用 Kubernetes 集群则是您组织的安全责任。IaaS 是指云服务提供商基本上只提供云基础设施。IaaS 的一个例子是 Azure 虚拟机（VM），其中微软仅提供物理服务器和用于您组织虚拟机的虚拟化程序。如果黑客利用您的虚拟机操作系统中的漏洞进行攻击，那么这将是您组织的责任，而非微软的责任。

6. 外部网络攻击源自公司网络之外，而内部网络攻击则源自公司网络内部。外部网络攻击包括大多数人所认为的经典网络攻击类型。坏人通过互联网侵入公司服务器并部署勒索软件。类似的事情。有时被忽视的是内部网络攻击。它们来自那些已经在公司网络内部拥有特权访问的人和实体。通常是员工、承包商、管理层或可信赖的供应链实体。例如，一名员工可能怀疑自己即将被解雇，于是通过将公司敏感数据泄露到公共网站上进行报复。内部网络攻击可能更容易实施且更具破坏性，因为攻击者不需要黑入公司网络；他们已经在内部，因为他们应该在那儿。然而，他们可能会进行特权升级攻击和横向移动，访问他们本不应访问的内部网络部分。

7. MITRE ATT&CK 数据库 (attack.mitre.org/) 是一个有用且免费提供的在线资源，可以帮助学习攻击者常用的网络攻击技术。大多数网络攻击在攻击链的过程中涉及不止一种攻击技术。该数据库由 MITRE 公司维护，并会不时更新，以包括新发现的网络攻击技术。

8. CIA三元组代表机密性、完整性和可用性。这些是数据的属性，网络攻击会损害这些属性。所有网络攻击都会影响这三个组成部分中的一个或多个。机密性是确保数据仅对被授权访问的实体开放。例如，如果攻击者能够读取我的电子邮件收件箱，那就是对我机密性的攻击。完整性是确保只有授权实体才能更改数据。因此，如果攻击者使用我的电子邮件冒充我发送邮件，或者更改我收件箱中的邮件内容或通过 IMAP 协议接收的邮件内容，那就是对我电子邮件完整性的攻击。可用性是确保数据和数据服务在需要时可用且可访问。如果攻击者对我的电子邮件服务器发起 DDoS 攻击，导致我无法接收或发送新邮件，那就是对我电子邮件可用性的攻击。有些攻击会影响 CIA 三元组的多个部分。例如，如今的企业勒索软件不仅会恶意加密数据，使其远离合法所有者；如果不支付赎金，还会威胁将敏感数据泄露给公众。

9. 在零信任网络中，无论机器、设备还是用户的来源如何，都不会自动被信任。零信任网络与传统的外围安全模型形成对比。在外围安全模型中，内部网络与外部网络（例如互联网）之间有一个安全边界。来自外部网络的实体需要在安全边界进行身份验证和授权，才能被允许进入内部网络，但所有在内部网络中传输的数据和所有来自内部网络的实体都被自动信任。这个安全模型在 1990 年代，云计算尚未普及，组织完全使用本地网络，且网络威胁形势不那么复杂时可能有效。但随着云计算和其他 21 世纪计算技术的出现，只有零信任模型才对良好的网络安全有效，无论是在云内还是云外。考虑到云网络的运行方式，零信任模型无论如何都是唯一适用的。而且，它显然在检测和防止内部网络攻击方面效果更好。在零信任网络中，您的设备会在每个可能的身份验证点进行认证。

10. 暴露服务是指在您组织的云网络中，攻击者可以通过互联网利用的互联网服务和端口，进行网络攻击。确保您工作所在的组织没有暴露任何服务是至关重要的。企业运营的云网络是不断变化的，今天可能没有暴露服务，但下周可能有 20 个暴露服务。我在本书中演示的一些渗透测试工具，如 Pacu，具有可以查找暴露服务的模块，您可以在渗透测试报告中提及这些服务。云服务提供商为其客户提供的一些安全工具，如 Amazon Inspector，也可以查找暴露服务。

11. 漏洞评估是使用检查清单来识别与特定计算机系统类型相关的常见安全漏洞、配置错误和其他漏洞。本书中大多数第三方渗透测试工具都可以用于进行漏洞评估。构成漏洞评估基础的一些检查清单包括 CIS 安全基准，它们适用于特定的服务和应用程序，以及安全标准，如支付卡行业数据安全标准（PCI DSS）规定，适用于销售点（PoS）计算机支付系统。

12. IAM代表身份与访问管理。这是网络安全领域的一个专门化方向，涉及到维护用户账户和机器身份（如用于加密的 TLS 证书）、身份验证方法（如密码和生物识别）、访问控制系统（如 RBAC）、用户账户权限，并确保用户和机器只能访问他们被授权访问的数据和系统。它是一个比云网络更早出现的网络安全专长领域。然而，AWS、Azure 和 GCP 都有各自的 IAM 系统。确保 IAM 的安全对于网络、应用和数据的整体安全至关重要！

13. RBAC代表基于角色的访问控制。访问控制方法有很多种，例如强制访问控制（MAC）、基于规则的访问控制和自主访问控制（DAC）。但 RBAC 是云网络中最常用的访问控制方法。它也是 Kubernetes 原生的访问控制方法。在 RBAC 中，用户根据其在组织中的角色被分配到用户组，然后将权限分配给这些用户组。例如，只有管理员组中的用户才可能创建新的用户账户，而只有工资组的用户才有权访问工资服务器。用户只有在工作需要访问时，才应被放入特定的用户组；这就是最小权限(PoLP)原则。

14. CVE 数据库（www.cve.org/）是另一个由 MITRE 公司维护的公开可访问的数据库。CVE代表常见漏洞和暴露。它旨在尽可能全面地记录已知的安全漏洞。一个组织发现其产品中的漏洞并将其公开记录到 CVE 数据库中，可能会有几个月的延迟，以便该组织在漏洞成为公开知识并可能被潜在攻击者利用之前有时间进行修补。CVE 记录的编号格式为—CVE-YYYY-NNNN。例如，CVE-2023-1234（www.cve.org/CVERecord?id=CVE-2023-1234）。年份（YYYY）表示该编号被保留的年份；这可能是漏洞被发现或在数据库中发布的年份，也可能不是。NNNN 只是一个随机的四位数字，表示该年份独有的编号。从我的理解来看，如果漏洞进入数据库的速度增加，可能需要增加一个数字。已发布的漏洞通常有可用的修补程序，但并非总是如此！这个想法令人恐惧。出于工作需要和实际考虑，我通常将已知漏洞定义为那些有 CVE 记录的漏洞。本书中的一些渗透测试和漏洞扫描工具将通过 CVE 记录来标识它们发现的漏洞。

15. CVSS是常见漏洞评分系统（由 FIRST 维护），用于根据漏洞的严重性对 CVE 数据库中的漏洞进行分类。CVSS 得分的定性评级使用以下分类标准：0.0 表示漏洞完全没有问题（我从未见过 0.0 的评分），0.1 到 3.9 是低风险，4.0 到 6.9 是中等风险，7.0 到 8.9 是高风险，9.0 到 10.0 是严重风险。分数越高，漏洞被利用对计算机系统的威胁就越大。

16. 利用预测评分系统（EPSS）是 FIRST 的系统，用于描述漏洞被网络攻击者利用的可能性或概率。EPSS 得分是根据漏洞被利用的百分比可能性给出的。一个漏洞可能有 9.5 的 CVSS 评分，但如果其 EPSS 评分为 5%，它在你的渗透测试报告中的优先级可能低于一个 CVSS 评分为 5.7 但 EPSS 评分为 95%的漏洞。

17. 红队根据新兴的网络威胁模拟公司网络中的网络攻击。渗透测试可能仅进行一次，持续时间可能为一到两周。而红队行动则是持续不断的红队攻击模拟，模拟不断变化的网络威胁，以发现漏洞。红队是一种进攻性安全专业。蓝队是防守性安全的对应角色。蓝队由防御性安全专家组成，他们进行蓝队行动，模拟保护其网络免受网络攻击的策略。

18. 当你将红队和蓝队结合在一起，就形成了紫队。紫队行动是红队和蓝队共同进行的演练活动。红队模拟网络攻击，而蓝队模拟网络防御。紫队活动可以成为进攻性和防守性安全专家共同合作的绝佳方式，让他们了解组织的安全状况，并共同改进它。

19. 渗透测试报告是渗透测试的成果。它是你在渗透测试过程中发现的漏洞的详细指南，说明漏洞如何被利用来危害组织的网络，以及如何对漏洞进行分级和缓解。如果你不能有效地将你的安全发现传达给防御安全团队和公司高管，使他们知道如何利用这些信息并相应地加强安全防护，那么你作为渗透测试人员的辛勤工作就毫无意义了。

20. AWS Security Hub 是所有 Amazon 原生 AWS 安全服务的汇聚地。来自 AWS IAM、Amazon Macie、AWS Health、AWS Systems Manager、Amazon Inspector、AWS Firewall Manager、Amazon GuardDuty 和 AWS Config 的数据将被聚合。你可以查看关于你公司在 AWS 中的安全状况的实时信息，因此它对渗透测试人员和安全管理员都很有帮助。

21. Amazon Inspector 是一个内建于 AWS 的第一方工具，不仅提供动态的安全数据以显示在 AWS Security Hub 中，还可以在安全管理员或渗透测试人员决定进行扫描时，使用该工具进行漏洞扫描。它具备本书中一些第三方渗透测试工具的功能，包括根据 CVE 记录和 CVSS 分数对漏洞进行分类。

22. Prowler 是一个第三方安全测试工具，供渗透测试人员运行各种类型的漏洞扫描，包含预编程的检查和服务。它可以在 AWS、Azure 和 GCP 中使用。与本书中的所有第三方工具一样，Prowler 可以从命令行运行。Prowler 可能是本书中最重要的第三方工具。

23. Pacu 是一个第三方工具，用于发现 AWS 中的安全漏洞。它有大量模块，可以模拟各种类型的网络攻击；它不仅仅是一个漏洞扫描器。

24. 虚拟机（VM）是一个虚拟化的计算机，就主机操作系统而言，它只是另一个应用程序。它虚拟化了硬件组件，如内存、磁盘存储和网络连接。如果我的 Windows OEM 笔记本电脑是我的计算机，那么虚拟机就是我的“计算机的宠物计算机”。虚拟机可以通过主机操作系统中的应用程序运行，例如 VMware 客户端或 Oracle VirtualBox。或者，带有多个虚拟机的虚拟机监控器（hypervisor）可以直接在计算机硬件上运行；不需要主机操作系统。在主机操作系统中，VMware 客户端或 Oracle VirtualBox 也充当虚拟机监控器。我可以在我的 Windows OEM 笔记本上运行多个虚拟机，如果我愿意，这些虚拟机可以使用 Linux 或 Mac 操作系统；虚拟机的操作系统不必与主机操作系统匹配。虚拟机也常用于云中。许多云服务提供商的 IaaS 服务基本上就是在提供商的基础设施上运行自己的虚拟机所需的一切，仅此而已。

25. 容器化是另一种使用虚拟化的方法。虚拟机运行的是一个操作系统及其所有组件，而容器仅运行执行代码所需的必要组件。容器化集群可以在任何给定时刻包含数十个或更多的容器，响应云应用的需求。单个容器的生命周期可能只有几天。云网络提供了组织所需的基础设施，使得容器化能够真正发挥出其可扩展性的优势。

26. Docker 是其中一个更受欢迎的容器化编排平台。它是如何工作的呢？Docker 主机直接运行在你的计算机上，或者运行在你管理的云服务上的计算机中。在 Docker 主机中，Docker 守护进程存储 Docker 镜像，并基于这些镜像创建和管理容器。Docker 主机连接到一个注册表，注册表通常托管在外部网络上，通常是互联网。Docker 客户端是你可以向 Docker 守护进程发送命令的地方。

27. Kubernetes 是另一个流行的容器化平台，它建立在 Docker 创建的基础上。Kubernetes 集群包含控制平面、节点和 Pod。节点由控制平面支持，节点支持 Pod，而 Pod 生成并运行容器。

28. 控制平面支持整个容器化系统，并作为基于 Kubernetes 的网络和云平台之间的桥梁。控制平面包含一些组件，包括etcd、kube-scheduler、kube-apiserver、kube-controller-manager、cloud和controller-manager。

29. 容器镜像在概念上类似于操作系统的 ISO 文件（磁盘镜像），这些 ISO 文件可以直接安装到计算机上或用于创建虚拟机，只不过容器镜像专门用于创建容器。容器镜像不包含完整的操作系统，只包含根据容器的使用方式所需的必要组件。有时，组织会创建自己的自定义容器镜像。容器镜像可以由第三方为特定的使用场景提供，或者你也可以使用 AWS、Azure 和 GCP 提供的容器镜像。

30. 你能记得可以在所有三个云平台上使用多少个渗透测试工具吗？以下是本书中提到的所有工具：Prowler、ScoutSuite、Vishnunair 的 automated-pentest（仅在 Docker 中使用）、kube-bench（仅在 Kubernetes 中使用）、kube-hunter（仅在 Kubernetes 中使用）、kdigger（仅在 Kubernetes 中使用）和 Trivy（在 Docker 和 Kubernetes 中使用）。

现在，让我们来看一下在进行本书中的练习和作为云渗透测试人员工作时，你需要用到的工具。

你的云渗透测试工具包

以下是你在云渗透测试工具包中应具备的工具。你可以使用这些工具跟随本书中的教程进行操作，也可以用来进行实际的云渗透测试：

• 过去十年生产的大多数 Windows 和 Mac 笔记本及台式机都非常适合你的云渗透测试工具包。你不需要拥有最先进的硬件规格，因为云网络的计算能力会完成大部分工作。如果你需要更具体的信息，可以寻找至少配备四核 64 位 CPU（Intel 或 AMD x86-64 架构或 Apple M1）的 Windows 或 Mac PC，并且至少有 4 GB 的 RAM。你的电脑硬件也应支持以太网和 Wi-Fi 网络。Windows 8、10 或 11，macOS 11 Big Sur 或更高版本，或任何当前支持的 Debian、Ubuntu 或 Fedora Linux 操作系统都非常适合。最好至少有 100 GB 的内存存储空间，但根据这些硬件规格，你的设备极不可能低于这个要求。

• 必须使用当前支持的网页浏览器。这将是你用来打开 AWS、Azure 和 GCP 的网页控制台的工具。它将作为你与所使用的云网络的接口。网页浏览器的版本更新非常频繁，但任何当前支持的 Mozilla Firefox、Google Chrome、Apple Safari、Microsoft Edge 或 Opera 版本都可以。如果你的浏览器版本过旧，浏览器可能会提醒你更新。

• 目前支持的 iPhone 或 Android 智能手机是一个额外的加分项。你可以用它运行 Google Authenticator 或 Microsoft Authenticator，为你的 AWS、Azure 和 GCP 账户提供额外的身份验证因素。这些平台的安全基准强烈建议在所有账户上实施多因素身份验证（MFA）。这是 Android 版的 Google Authenticator：play.google.com/store/apps/details?id=com.google.android.apps.authenticator2。这是 iPhone 版的 Google Authenticator：apps.apple.com/us/app/google-authenticator/id388497605。这是 Android 版的 Microsoft Authenticator：play.google.com/store/apps/details?id=com.azure.authenticator。这是 iPhone 版的 Microsoft Authenticator：apps.apple.com/us/app/microsoft-authenticator/id983156458。

• GitHub 不需要安装，但你会发现它是一个非常有用的服务，可以在你的网页浏览器中打开，用来安装第三方渗透测试工具和脚本。也许你应该把github.com保留在浏览器的一个独立标签页中。

• console.aws.amazon.com上的 AWS 网页控制台。设置好自己的 AWS 部署后，或者当你有权限访问组织的 AWS 网络时，你将登录到这个控制台。

• azure.microsoft.com上的 Azure 网页控制台。设置好自己的 Azure 部署后，或者当你有权限访问组织的 Azure 网络时，你将登录到这个控制台。

• console.cloud.google.com上的 GCP 网页控制台。设置好自己的 GCP 部署后，或者当你有权限访问组织的 GCP 网络时，你将登录到这个控制台。

• Prowler (github.com/prowler-cloud/prowler) 是本书中最有用的渗透测试工具之一。你不会在自己的电脑上安装它；你将会在云服务提供商的计算机上安装它。（所有第三方渗透测试工具也同样适用此规则。）

• Pacu (github.com/RhinoSecurityLabs/pacu) 是一个专门为 AWS 设计的攻击框架。

• Cred Scanner (github.com/disruptops/cred_scanner) 是一个针对 AWS 的渗透测试工具，用于查找文件中暴露的访问点和密钥。

• CloudFrunt (github.com/MindPointGroup/cloudfrunt) 是一个用于识别 AWS 中配置错误的 CloudFront 域名的工具。

• MFASweep (github.com/dafthack/MFASweep) 是一个可以在 Microsoft Azure 和 365 中使用的工具，用于检查是否启用了 MFA。启用 MFA 对用户账户非常重要，因为提供更多的认证因素可以使用户账户更加安全。

• ScoutSuite (github.com/nccgroup/ScoutSuite) 是一款适用于 AWS、Azure 和 GCP 的安全审计工具。

• GCPBucketBrute (github.com/RhinoSecurityLabs/GCPBucketBrute) 是一个脚本，用于枚举 Google 存储桶，检查它们是否可以访问、如何访问，并判断是否能够进行权限提升。Google 存储桶仅适用于 GCP。

• GCP Scanner (github.com/google/gcp_scanner) 不是一个官方的 Google 项目，但由 Google 的一个团队进行维护。它是一个 GCP 资源扫描器，能够帮助确定某些凭证在 GCP 上具有什么级别的访问权限。

• Docker Desktop (www.docker.com/products/docker-desktop/) 不是必需的，但如果你正在进行 Docker 集群的渗透测试，安装在本地计算机上可能会非常有用。它可以在 Windows、Mac 或 Linux 上本地安装。

• Vishnunair 的自动化渗透测试工具 (hub.docker.com/r/vishnunair/pentest) 是一个基于 Parrot OS 的 Docker 容器镜像，可以用于对 Docker 部署进行渗透测试。你实际上是将其安装在 Docker 中，而不是直接安装在你的云平台上！

• kube-bench (github.com/aquasecurity/kube-bench) 在 Kubernetes 中运行漏洞评估，确保它们符合 CIS Kubernetes 基准，这是配置 Kubernetes 安全性的标准。它直接在你的 Kubernetes 集群中运行，也可以作为计划任务在 Kubernetes 中运行。

• kube-hunter (aquasecurity.github.io/kube-hunter/) 在 Kubernetes 集群中寻找安全漏洞。它可以从 Kubernetes 集群中的 Pod 或从其他机器上运行。我使用了 Azure 中的虚拟机来扫描我在 Azure 中的 Kubernetes 集群。

• kdigger (github.com/quarkslab/kdigger) 是一个专注于 Kubernetes 的容器评估和上下文发现工具，用于渗透测试。建议在 Pods 中运行，而不是在主机机器上运行。

• Trivy (github.com/aquasecurity/trivy) 是一个全面且多功能的安全扫描器，能够同时在 Docker 和 Kubernetes 中工作。

• 你工具包中的这一部分绝对至关重要，但很容易被忽视——可靠的互联网连接！你在云网络上的所有操作都需要通过互联网进行。希望你在家里或工作场所有一个可靠的互联网连接。如果没有，网吧或公共图书馆也可以。但如果你在公共 Wi-Fi 上工作，一定要特别小心，使用 VPN。若在家中使用 VPN 也可能是个不错的主意。

接下来，我们将看看一些与云和渗透测试相关的认证，你可以选择攻读它们，帮助你获得云渗透测试工作。

云和渗透测试认证

有很多认证可能会让你作为云渗透测试人员更具竞争力。有些认证来自供应商，有些是供应商中立的。有些与云网络相关，有些是通用的渗透测试认证。

云

亚马逊提供了十多种 AWS 云认证 (aws.amazon.com/certification/exams/)。以下是最适合云渗透测试人员的几种认证：

• 入门级的基础认证是云从业者 (aws.amazon.com/certification/certified-cloud-practitioner/)。它涵盖了云计算的基础知识，无需任何先前经验。

• SysOps 管理员 (aws.amazon.com/certification/certified-sysops-admin-associate/) 是我推荐给云渗透测试人员的助理级认证。在备考过程中，你将学习到以下内容：

  • 如何在 AWS 上部署、管理和操作工作负载

  • 如何实施安全控制并满足合规要求

  • AWS 管理控制台和 AWS CLI

  • AWS Well-Architected 框架以及 AWS 网络和安全服务

• 解决方案架构师 (aws.amazon.com/certification/certified-solutions-architect-professional/) 是我推荐给云渗透测试人员的专业级认证。你将学习以下内容：

  • 如何在 AWS 中优化安全性

  • 如何自动化手动流程

  • 如何为复杂问题提供复杂解决方案

  我推荐的 AWS 专业级认证有两种。这是 AWS 认证的最高级别：

  • 高级网络认证 (aws.amazon.com/certification/certified-advanced-networking-specialty/) 如果你将来能够开发自己的云渗透测试工具，这个认证将非常有用！它涵盖了高级网络架构技能。

  • 安全 (aws.amazon.com/certification/certified-security-specialty/) 是我推荐的另一个 AWS 专业级认证。该认证验证你在 AWS 中创建和实施安全解决方案的专业知识。

Microsoft 有自己的 Azure 安全认证 (learn.microsoft.com/en-us/certifications/browse/?roles=security-engineer&products=azure)。这些认证都不是入门级的，它们属于中级和高级认证。

• Microsoft Azure 安全技术 (learn.microsoft.com/en-us/certifications/exams/az-500/) 是中级认证。该认证涵盖通过 Azure 平台保护身份与访问、数据、应用程序和网络。它还展示了如何保护多云和混合云网络。

• Microsoft 安全运营分析师 (learn.microsoft.com/en-us/certifications/exams/sc-200/) 是另一个中级认证。它主要关注安全事件分流、事件响应（IR）、威胁狩猎、威胁情报（TI）分析以及漏洞管理。所有这些认证都是偏向防御性的，包括这一项，但了解防御方面的知识可以帮助你提高网络进攻能力。

• Azure 安全工程师助理 (learn.microsoft.com/en-us/certifications/azure-security-engineer/) 是另一个中级认证。它涵盖威胁建模、威胁保护、漏洞管理和管理组织的安全态势。

• Microsoft 身份与访问管理员助理 (learn.microsoft.com/en-us/certifications/identity-and-access-administrator/) 也是中级认证。它涵盖了在 Azure Active Directory 中设计、实施和操作 IAM。

• Microsoft 身份与访问管理员 (learn.microsoft.com/en-us/certifications/identity-and-access-administrator/) 是上一项认证的下一级，属于高级认证。

Altered Security (www.alteredsecurity.com/) 是一家独立于 Microsoft 的第三方机构，提供一些与 Azure 相关的认证，可能对你有所帮助：

• Altered Security 提供免费的 Azure 渗透测试入门课程，地址是 azure.enterprisesecurity.io/。

• 认证 Azure Web 应用安全专家(CAWASP) (www.alteredsecurity.com/azureappsec) 是一个基于实践技能的认证，您将在其培训项目提供的实验室中培养这些技能。包括的部分领域有企业应用、应用服务、函数、OAuth 权限、API 安全、存储账户、密钥库和数据库。（这不是一个免费的项目。）

• 认证 Azure 红队专家(CARTP) (www.alteredsecurity.com/azureadlab) 证明了你在 Azure 中进行红队演练的能力。该培训项目充满了关于红队技能和技术的动手实验。24 小时的考试也在 Altered Security 的实验室中进行。（此认证也不是免费的。）

Google，拥有并开发 GCP 的公司，提供了一些云认证 (cloud.google.com/learn/certification#why-get-google-cloud-certified)，供你参考，具体如下：

• 云数字化领导者 (cloud.google.com/learn/certification/cloud-digital-leader) 是 Google 的入门级云认证，属于 Google Cloud 认证链中的基础级别。它涵盖的四个领域如下：

  • 使用 Google Cloud 进行数字化转型

  • 在 Google Cloud 上进行数据创新

  • 基础设施和应用现代化

  • Google Cloud 安全与运维

• 云工程师 (cloud.google.com/learn/certification/cloud-engineer) 是下一个级别的认证，属于 Google Cloud 认证链的助理级别。该考试测试你完成以下任务的能力：

  • 配置云中的访问权限和安全性

  • 设置、规划、配置、部署和实施云解决方案

  • 确保云解决方案的成功运行

  到目前为止，Google Cloud 认证链中的专业级别有九个认证，我将重点介绍与云渗透测试者更相关的认证：

  • 云安全工程师 (cloud.google.com/learn/certification/cloud-engineer) 涵盖以下领域：

    • 配置云解决方案中的访问权限

    • 配置网络安全

    • 数据保护

    • 管理云运维

    • 确保合规性

  这些内容大多集中在防御安全方面，但更好地理解网络防御也能使你在网络进攻方面更有优势！

  • 云网络工程师 (cloud.google.com/learn/certification/cloud-network-engineer) 更加深入计算机网络技术，涵盖以下领域：

    • 网络服务配置

    • 管理、监控和优化网络运营

    • 实施混合互连

    • 实施虚拟私有云(VPCs)

    • 设计和规划 Google Cloud 网络

  • 我最强烈推荐的一个供应商中立的云认证是云安全联盟的云安全知识证书（CCSK）(cloudsecurityalliance.org/education/ccsk/). 它涵盖以下领域：

    • IAM 最佳实践

    • 云 IR

    • 安全即服务(SECaaS)

    • 应用安全

    • 数据加密

我推荐的最后一个云认证是 ISC2 的认证云安全专家（CSSP）(www.isc2.org/Certifications/CCSP).

该认证表明你具备使用最佳实践、政策和程序在云中安全保护数据和应用的技术能力。

渗透测试

现在，这里有一些我推荐的渗透测试认证：

EC-Council 的认证的道德黑客(CEH) (www.eccouncil.org/train-certify/certified-ethical-hacker-ceh-v12/) 是一种你会经常听到的认证。CEH 的学习计划包括超过 200 个动手渗透测试实验室、超过 500 种攻击技术和许多黑客工具。

另一个你经常听到的渗透测试认证是 OSCP，(www.offsec.com/courses/pen-200/), OffSec（前称 Offensive Security）认证的专业人员。确保在开始追求 OSCP 之前，你对 TCP/IP 网络、Bash 和 Python 脚本编写以及 Windows 和 Linux 管理有良好的理解。

最后，CompTIA 的 PenTest+ (www.comptia.org/certifications/pentest) 认证不容忽视。它涵盖以下领域：

• 规划和界定渗透测试项目

• 信息收集和漏洞扫描

• 攻击和利用

• 报告和沟通

• 工具和代码分析

现在，让我们看看你应该从渗透测试合同中期望什么。

渗透测试合同

渗透测试和真实网络攻击的关键区别在于，渗透测试是在计算机系统的所有者完全合法同意的情况下进行的。

完整的法律同意书不应仅仅是口头协议或通过握手签署的“君子协议”。你必须确保有书面的法律文件，由计算机系统所有者的代表和你本人共同签署。在进行渗透测试之前，如果没有签署法律文件，将会是灾难的开始，因为在大多数国家/地区，未经法律同意而进行渗透测试的行为通常构成数字犯罪。可能会在民事法庭甚至刑事法庭产生严重的法律后果。签署的法律合同是双方同意内容的证明，而口头协议和其他类型的非正式协议在法庭上绝对无法站得住脚！你需要在法律上保护自己，特别是在未来某个时候可能发生争议时。

无论你是你所在组织的员工、第三方承包商，还是在其他任何情况下工作，这都不重要。无论你是否曾与组织成员线下见面，也都不重要。即便是一个简单的漏洞扫描，如果没有书面且可验证的双方同意，也可能会让你陷入麻烦。如果你需要正确的法律建议，我强烈建议你咨询律师。一位合格的律师将确认我在这里所写的内容，并且可能能够为你提供关于你客户或组织提供的渗透测试合同是否符合你法律利益的建议。如果你能承担这项服务，找律师审查合同是一个不错的主意。

PentestUSA 有一个示例通用渗透测试合同（www.pentestusa.com/pdfs/PentestUSAPentestContractTemplate.pdf），我鼓励你查看，以便了解预期的内容。

Cure53 在 GitHub 上有一个渗透测试合同模板集合（github.com/cure53/Contracts），可能对你有帮助。

一个值得你签署的渗透测试合同应当明确规定你所期望进行的渗透测试的完整范围。定义的范围可能包括指定的 IP 地址、网络段和域名。确保定义的范围是具体的！无论何种情况，你都不应在合同规定的范围之外进行任何渗透测试活动，即使你认为这样做对组织有利。

你还应该确保你的渗透测试合同不会要求你做任何违反亚马逊、微软和谷歌渗透测试政策的事情。请随时审查这些政策；它们在这里列出。记住——你将在亚马逊、微软和谷歌的基础设施中进行渗透测试，因此它们的规则优先于你所在组织希望你做的事情：

• AWS 渗透测试客户支持政策：aws.amazon.com/security/penetration-testing/

• Amazon EC2 测试政策: aws.amazon.com/ec2/testing/

• AWS DDoS 模拟测试政策: aws.amazon.com/security/ddos-simulation-testing/

• Microsoft 在线订阅协议: azure.microsoft.com/en-us/support/legal/subscription-agreement/

• Microsoft Cloud 渗透测试参与规则: www.microsoft.com/en-us/msrc/pentest-rules-of-engagement

• Google Cloud Platform 服务条款: cloud.google.com/terms/

• Google Cloud Platform 可接受使用政策: cloud.google.com/terms/aup

现在，让我们最后看一下你渗透测试的成果——渗透测试报告。

渗透测试报告

渗透测试报告是你渗透测试劳动的成果。你在几天或几周内进行各种漏洞扫描和模拟攻击所付出的辛勤努力，如果没有有效地将漏洞发现报告给你组织的防御安全团队和企业领导层，那就毫无意义。他们需要以一种易于理解的方式，了解你发现的关于网络安全状况的所有信息。如果你的渗透测试报告有效，你的组织将能够利用你的安全发现来加强网络和应用程序的安全。

渗透测试报告可以从几页到超过 100 页不等；这取决于你进行的渗透测试练习和扫描的数量。根据我经验，50 页接近平均值。但不要设定目标让报告大约是 50 页；长度会根据你需要分享的信息量而变化。你的报告可以是 PDF 或 Word DOCX 格式。你最好同时准备这两种格式的报告，以防万一。

你的渗透测试报告应该包含以下几个部分：

• 一份高管摘要，放在开始部分。它应该只有一到两页。这正是高管们查看的内容。你应该简明扼要地描述渗透测试所发现的主题。“加密密钥存储得很好，但太多拥有特权访问权限的账户缺乏多因素认证，使这些账户容易受到网络攻击者的攻击。”“我们托管在 Azure 上的虚拟机幸运地很难被外部攻击者发现。但与我们的 Google Cloud 存储桶连接的暴露服务实在是太多了。”确保提到，如果你发现的漏洞没有得到缓解，成功的网络攻击可能会给你的组织带来巨大的经济损失。金钱是激励公司高管的动力。如果你发现的漏洞可能使你的组织容易受到数据泄露的威胁，可以引用 IBM 的《数据泄露成本报告》中的货币数据（www.ibm.com/reports/data-breach）。

• 在下一部分，解释你的渗透测试范围以及你寻找了哪些类型的漏洞。你可以将这一部分命名为“审计范围”或“渗透测试范围”。

• 下一部分可以叫做“漏洞发现”。本书中的许多工具将生成扫描结果，列出根据 CVE 记录和有时是 CVSS 评分发现的漏洞。EPSS 评级也非常重要。如果你知道漏洞的 CVE 记录编号，但不知道其 CVSS 评分或 EPSS 评级，我建议从 CVEDetails.com 查找（www.cvedetails.com/）。按 EPSS 评分排序漏洞，再按 CVSS 评分排序。例如，EPSS 评分为 90%的漏洞应排在最前面。如果多个漏洞的 EPSS 评分为 90%，首先列出 CVSS 评分较高的漏洞。务必包括每个漏洞的 CVE 数据库描述，并用你自己的话说明攻击者可能如何利用该漏洞。

• 如果你有不对应于 CVE 记录的安全问题，可以在另一个标题为“其他发现”或“附加发现”的部分中提到它们。在这里，你可以提到一些情况，例如“这些用户账户缺少多因素认证”或“网页表单未对弹出窗口输出进行清理，可能使攻击者获得可用于发动网络攻击的信息。”

• 以下部分可以命名为“修复建议”。你可以提到如何修补或缓解这些漏洞。漏洞发现部分应该能够为防御安全团队提供线索，告诉他们如何对漏洞进行优先级排序，如果你按照我的指导，将漏洞从最关键到最不关键进行排序（基于 EPSS 和 CVSS）。但你仍然可以在这里用自己的话解释，你会建议防御安全团队如何优先处理漏洞。因为他们不可能同时修复所有漏洞，而且有时某个漏洞无法修复，安全分析师或 CISO 可能需要选择接受风险或转移风险（通常是通过网络安全保险）。

• 最后，你可以添加一个“结论”或“总结”，就像执行摘要一样，概括你的发现主题。但在这里你可以使用更多的技术性语言。

• 如果你有需要引用的资料，包括像 CVE 记录或其他网络安全专家在网上撰写的漏洞解释；它们会在最后列出并超链接。

这里有一些方便的资源可以帮助你处理渗透测试报告。

我在 SANS PenTest HackFest Summit 2021 上做了一个名为“写报告：被忽视的渗透测试技能”的演讲，你可以在 YouTube 上观看！(www.youtube.com/watch?v=r-6LBjlM14Y.)

Juliocesarfort 在他的 GitHub 上保留了一个非常庞大的真实渗透测试报告集合 (github.com/juliocesarfort/public-pentesting-reports)，我建议你查看一下。

总结

恭喜你！你已经准备好开始作为云渗透测试员的旅程了。

你工作所需要的工具是一台普通的个人电脑、一款更新的网络浏览器和一个可靠的互联网连接。你可以通过网络应用程序完成大部分工作。互联网真是太神奇了，不是吗？

亚马逊、微软、谷歌、云安全联盟、OffSec、ISC2 和 CompTIA 提供云网络和渗透测试的认证，这些认证可以让你更具就业竞争力。

所有合规的渗透测试都从一份写得很好的合法渗透测试合同开始，以一份写得很好的渗透测试报告结束。

深入阅读

要了解本章所涵盖的主题，你可以访问以下链接：

• MITRE ATT&CK 数据库： attack.mitre.org/

• MITRE CVE 数据库： www.cve.org/

• 常见漏洞评分 系统： www.first.org/cvss/

• 漏洞预测评分 系统： www.first.org/epss/