2024从基础到应用云上安全航行指南

阿里云开发者“藏经阁”海量电子手册免费下载 扫码回看【ECS安全季】全部课程 如何保障云上业务的应用安全和数据安全，是每一个上云的企业和用户关注的重点。云上安全建设是一个体系化工程，需要用户主动进行多方面的考虑和实施，包括制定完善的安全策略和规范，如身份认证、访问控制、漏洞管理、安全审计、数据备份、数据加密等；建立安全监控与防御机制，当出现安全攻击时业务能快速止损等。安全用云是用好云的第一步，也是最为关键的一步。 在这个背景下，阿里云弹性计算技术公开课在2024年开年全新推出新一季【ECS安全季】，由阿里云八位产品&技术专家组成讲师团，通过分享云上安全体系相关产品与最佳实践，让用户快速上手构建业务的安全防护能力。 本书内容整理自ECS安全季中的全部课程，供各位开发者&用户阅览。 阿里云产品专家教你如何全方位构建ECS安全体系5 九大提升ECS实例操作系统安全性的技巧23 干货长文快收藏！阿里云专家教你如何安全访问和管理ECS资源52 来上课！一文掌握守住ECS网络安全的最佳方法78 万字干货教你如何保证业务数据全流程安全104 云安全专家教你如何实现一体化、自动化的云安全审计，运营闭环137 一文教你如何从零构建机密计算平台解决方案163 阿里云产品专家教你如何全方位构建ECS安全体系 2024开年伊始，阿里云弹性计算团队全新推出新一季【ECS安全季】，通过分享云上安全体系相关产品与最佳实践，让用户快速上手构建业务的安全防护能力。 首节课程《如何全方位构建ECS的安全体系》由阿里云弹性计算高级产品专家马小婷带来，课程涵盖了“云上安全的重要性、云安全责任模型、ECS安全能力大图解读”等内容，本系列全部课程也将在阿里云官网、阿里云官方微信视频号、阿里云官方钉钉视频号、阿里云开发者微信视频号同步播出。 以下内容根据课程整理而成，供各位开发者阅读： 对于安全问题，很多用户的直接反应就是操作是否太难？没有安全背景和基础能否快速上手？又或是云上业务规模很小，是否需要知道并了解这些安全措施呢？结合以上的种种问题，今天的分享希望带给大家两个收获：第一点是让大家对ECS的安全责任边界和作为ECS的用户所肩负的安全责任有基本的认知，第二点是让大家能够掌握一些解决ECS常见问题的一些安全技巧，通过本节课程的学习，大家可以立马用起来，毕竟安全无小事。 本次的分享主要分为以上四个方面。 一、云上安全的重要性 首先我们来关注一下云上安全的重要性，一直以来安全问题都是用户上云最关心的问题，我们得到的调研报告显示96%的受访者其实非常关注云上安全问题，同时有70%及以上的用户对云上的安全状态信心是不足的。 想要告诉大家的是，这种担心并不是可有可无。随着全球信息化浪潮的不断推进，我们发现针对数据安全的风险也在不断上升，甚至愈演愈烈，这一部分的风险也来源于攻击者不断进化的攻击手段和日趋增加的安全事件。 根据cyberattacks-2022年的数据统计显示，2022年全球网络攻击事件相比增加了38%，而网络攻击带来的后果一般都非常严重，不仅会导致我们的业务中断不可用，而且会导致敏感数据泄露，以致带来严重的经济损失，比如病毒勒索等。根据IBM调查报告显示，2023年因为数据泄露导致的平均损失高达445万美元，而数据泄露的平均周期是277天，这也 意味着企业在遭遇了数据泄露以后，平均需要花费277天来识别并控制一个活跃的数据泄露，时间成本和经济成本非常高。 那么除了日趋复杂和严峻的安全环境之外，我们来看看ECS的用户们经常遇到的威胁都有哪些。 其实很多用户上云购买的第一个云产品就是云服务器ECS。我们发现很多用户在使用ECS的过程中存在着一个误解，那就是购买了ECS之后就可以“安全无患、高枕无忧”，其实 不然。上图列举了目前ECS面临的一些典型的安全威胁，相信各位开发者可能也遭遇过。比如各位的实例遭遇DDos攻击，导致整个应用拒绝服务，或者ECS中了勒索病毒，导致数据无法被找回，又或者实例登陆密钥被泄露，导致数据被删除无法找回等等。 其实大家遇到的问题只是ECS安全问题的冰山一角，在阿里云后台，我们每天默默处理掉的ECS的各种安全问题数量也非常惊人。阿里云每天发现并发出以上的漏洞病毒告警超过10万次，每天帮助用户清理的DDos攻击流量高达2.08Tdps，而我们每天扫描出来的操 作系统这种安全漏斗高达3亿个，每天帮助客户清理的黑客工具高达700万个，这些问题每天依然在发生，那么导致以上问题的根因是什么呢？ 当前云计算安全建设的主要驱动力其实是合规性要求，我们对安全攻击和防护的重视度是远远不够的，而安全的本质其实是对抗，要抵御各种威胁才是提高安全的最终目标。随着云计算得到了广泛的应用，聚焦于云计算的攻击者其实会搜集网络上各种云服务，进而去发现脆弱性并且加以利用。这些脆弱性主要来源于上图展示的五个方面。 根据2023年cloudsecurityAlliance的topcloudsecuritychallenges我们可以看到，首当其冲的是用户配置不当导致；其次是因为客户在云计算的技能不足导致；第三是多云 环境下的能见度不足导致的。根据Gartner预测，到2025年，由于用户配置不当导致的安全问题的比例可以高达99%。由此我们可以看到很多安全问题最终的根因其实归结为两点，第一个其实就是安全意识的不足，第二个是我们安全实践技能相关的缺失。 安全意识的不足这一点大家有目共睹，尤其是在我们DoveOps这种开发模式下，为了提升我们的开发效率，我们的开发运维团队会大量使用三方开源工具或者一些软件库，甚至是一些公开的容器镜像。这些开源软件或者是镜像中如果存在了一些安全漏洞，或者说遭遇了恶意污染，但我们的开发运维同学并不会去做严格的安全风控。最终如果用户使用了这些软件，那么接下来大家的业务则会面临着一些安全的风险，同时我们也注意到有很多人在无疑是的把业务中的一些敏感代码或者数据在互联网上进行托管，这种操作其实也会存在着一些数据泄露的安全风险。 另一个调查可以显示，23%的企业承认自身的业务其实对网络攻击的准备是不足的，而50%的企业承认自身的网络安全水平其实是落后于起初规划的。其中一方面是因为大家自身技能的确实，另一方面也是大家不得不考量的成本问题，所以我希望今天的分享能够给大家做到安全方面的基础的科普，以及安全尝试，帮助大家尽量做到尽量避免因为配置不当或者意识不足导致的业务风险问题。 二、安全责任共担模型介绍 第二部分将为大家详细介绍ECS的安全责任共担模型。这个责任模型是我们进行云上安全实践的重要基础，也是主要依据之一。在介绍模型之前，先为介绍一下ECS的底层架构，因为这也是我们对ECS的安全性进行配置的一个基础。 在传统的云下应用架构下，搭建一个信息系统，需要自行负责信息系统所以来的所有底层软硬件的资源和服务搭建。如果把信息系统的搭建比作为一个房子，那在我们的传统服务模式下，我们则需要自行准备搭建一个房子所需要的全部资源。其实这里可以类比为我们在乡下宅基地自建房，需要选址打地基，设计房屋构造和布局，拉上水电煤等技术服务，最后做内部装潢，可能还需要判断房子外围是否需要加盖院子和围墙，来保障房子的安全。所以我们可以看到，在传统架构下，所有的任务和服务都需要我们自行设计、自行管理和自行维护。 而在infrastructureasservice基础设施及服务这种的服务模式下，我们可以看到云服务提供商就像房地产开发商一样，每一个基础且重要的“建房步骤”都由云服务提供商来负责管理和维护，同时他们还需要保障不同的用户或者不同房子之间的资源隔离问题，需要做到互不影响。而我们作为用户，只需要根据业务需要以及当前的属性去做一些选择和配置即可。 那我们来看一下选购一个ECS和选购一个“房子”有哪些重要的参考参数呢？ 首先就是选择地域和可用区，ECS的地域和可用区类似于房子地段的情况，地段由城市和县市决定。在地域和可用区的选择上，主要交由用户选择。建议大家选择在更靠近业务服务的目标用户的区域，这样整个网络延迟相对更低。 其次选择对应的VPC和交换机。VPC是用户自定义的一种私有网络，而不同的VPC之间在逻辑上是完全隔离的，但同一个VPC中子网又是默认互通的，交换机则是将一个VPC划分成一个或多个子网，所以从这个概念上来说我们可以把VPC理解为一个小区，同一个小区 中的房子在不出小区的情况下就能够互通，如果我们在一个小区中有多套房子，就可以通过交换机操作类似单元楼的方式进行划分，方便管理。所以在某种程度上，我们选择ECS的VPC和交换机，其实就相当于我们在选择房子所在的一个小区和单元楼。 然后我们要选择ECS镜像。ECS镜像我们也叫操作系统，其实我们在选择镜像的时候，可以分不同的类型和版本，比如我们选择Windowsserver2023这个版本。这就相当于我们去选择这个房子的户型究竟是三室两厅还是两室两厅。 下一步选择对应的ECS安全组。安全组其实是一个虚拟的防火墙，主要用来控制安全组内的ECS实例的入出方向的流量，相当于我们设置的一个“规则”来允许什么人可以进出单元楼，所以我们可以把安全组类比做门禁卡，可以通过设置门禁卡的规则来限定什么样的人能够进入我们的小区，进入我们的房子。 最后则是选择实例的用户名和密码，也就相当于“房子钥匙”，不同的人可以用钥匙打开我们的门，进入到房子中去，所以如果我们的用户名和密码没有得到很好的保障，则相当于我们的钥匙也没有得到很好的保管，那么我们整个ECS其实是可以任由大家访问的。 理解了整个ECS架构，我们就可以看到作为ECS用户，我们就相当于一个房子的租客一样，需要我们作为租客（用户），对房子中所有的基础设施的配置来负责，包括对应的ECS有没有设置对应的网络隔离，整个实例操作系统的安全性有没有得到保障等等，以及有没有设置对应的访问策略，以及在里面跑的这些应用是否安全。这意味着整个ECS内部的这一部分是由我们作为用户，需要自己管理并负责的。而云服务提供商其实就和房地产开发商一样，主要负责两部分的安全，第一部分其实负责对整个地域和可用区里面的基础设施进行和管理和维护，第二部分其实对于我们这个虚拟化服务和云产品的管理和服务进行负责。 在了解底层架构之后，我们再来讨论ECS的安全责任共担模型，其实就会发现，这个模型会更清晰。上图右侧列举了云服务提供商和我们的用户之间的责任边界，可以看到云服务提供商对云本身的安全性负责，而云本身的安全性分成了两个维度，第一个就是基础设施的安全性，第二个是云服务的安全性。基础设施的安全性主要包括底层硬件的主机安全，以及一些虚拟化的安全。要提供一个安全、合规、可靠的基础设施，这也类似于我们房子的地基，房子的地基是否安全，房体所使用的钢筋水泥土是否符合国家建筑安全的规定。云厂商的第二个安全责任就是需要对云服务的安全性负责，主要是云服务本身是否安全。 而在这个基础上，用户侧需要围绕云上安全性需要做哪些事情呢？上文介绍到了ECS一些重要的参数和组件，其实也是我们在提升ECS安全性方面所需要考虑的几个维度，目前我们可以分为四个维度。 最底层GuestOs安全其实是我们ECS所有安全的基础，相当于房子的门窗和钥匙是否安全。其次是访问安全，本质上来说，主要控制有哪些用户能够访问我们的实例。第三块是网络安全，主要通过网络隔离和网络控制手段提升整个网络的安全性。最后一部分是数据安全，也是云上安全的最终目标，当然其中也存在着不同的维度，比如我们可以用快照做数据备份，也可以对存储的数据进行加密，甚至可以通过机密计算的方式保证数据在计算过程中 的安全性，这里预告一下，数据安全在后续章节也会有讲师为大家做深入的开展。 整体来说，ECS的安全责任共担模型明确了云厂商和用户大家的责任边界，以及在每个维度上用户能够做的提升ECS安全性的一些事情。 前面介绍的安全责任共担模型其实是一个整体大原则，根据《中华人民共和国网络安全法》以及《互联网信息服