计算机安全原理与实践手册：从CIA到主机加固的落地指南

简介面向计算机安全学习者及备考人士的实验室手册是《计算机安全原理CompTIA Security及以后实验室手册》第二版由资深网络安全专家团队编写。全书围绕Security认证框架展开覆盖密码学、身份验证、访问控制、主机安全、应用安全、网络攻击与防御、恶意代码、风险评估、安全策略等主题并针对常见安全威胁给出应对思路借助大量实验练习帮助读者把理论与实践结合既能备考也能应对真实威胁。书中配有可动手操作的实验场景与操作说明适合在虚拟机或实验环境中逐步操作。资源为完整英文原版PDF手册压缩包内共1个PDF文件大小11.16MB排版规范、目录清晰方便在电脑或移动端阅读。目前已有148人学习或下载适合网络安全初学者以及希望提升实战能力的在职人员参考使用。1. 计算机安全原理与实践手册先想清楚要防谁再谈防火墙和杀软很多人拿到一台服务器第一反应是装杀毒软件、开防火墙然后觉得“安全”已经到位了。但真实情况是绝大多数安全事件不是被外部黑客“攻破”的而是内部配置失误、权限过宽、补丁缺失给了攻击者一条顺畅的通行路。我见过一个客户的业务系统杀软和防火墙都齐全结果一个共享文件夹的权限是Everyone完全控制勒索病毒进来之后横扫了整个内网。计算机安全原理与实践手册不是让人背术语的教材它解决的核心问题是把“机密性、完整性、可用性”这些原则翻译成具体的账号策略、权限矩阵、补丁节奏和监控动作。这份路线适合运维工程师、安全工程师、刚转行做IT治理的从业者也适合在写安全制度时不知道怎么落地的管理者。原理必须先行但每一条原理背后都要有能执行的参数否则手册就只是一堆正确的废话。2. 把CIA与纵深防御落成参数最小权限、密码策略和基线表格2.1 CIA三元组是安全手册的核心假设打开任何一本计算机安全教材前几章必定是CIA三元组机密性Confidentiality、完整性Integrity、可用性Availability。这三个词不是用来考试的它决定了你写安全手册时所有策略的优先级。机密性管的是“谁能看”完整性管的是“数据能不能被改”可用性管的是“业务能不能持续转”。很多新手把安全等同成保密文件加个密码就觉得完事却忘了可用性——你把数据库磁盘加密了但密钥丢了业务直接停摆这比被攻击还惨。我在做安全方案时习惯先画一张表把业务资产按这三个维度打分。比如财务系统的交易数据机密性和完整性都是高优先级官网的静态页面完整性重要但机密性几乎不涉及。这样打分有什么好处当你在手册里写“所有数据必须加密”时你得知道哪些数据值得加密到哪种强度。给官网页面做全字段加密性能损耗巨大收益甚微但给用户密码表不做哈希和加盐就是等着脱库。CIA不是装饰它是安全决策的排序器决定了有限的人力先花在哪个环节。2.2 最小权限落成权限矩阵一个仓库的示例最小权限Least Privilege是实践手册里最容易喊口号、最难执行的一条原则。口号是“每个用户只给够用的权限”但落到实操你需要明确“够用”的边界是什么。我建议直接用权限矩阵来定义边界。新建一个项目仓库常见的做法是分三层角色管理员、开发者、只读访客。管理员能读能写能删分支开发者能写自己分支和提PR访客只能拉代码。下面是一份用Markdown表格就能维护的权限矩阵模板建议直接抄进你的手册资源/动作管理员开发者只读访客代码仓库-拉取允许允许允许代码仓库-推送主干允许拒绝拒绝代码仓库-推送分支允许允许拒绝CI/CD-修改流水线允许拒绝拒绝生产服务器-SSH登录允许拒绝拒绝生产服务器-日志读取允许允许拒绝这张表看起来简单但真正执行起来很多团队会忽略“开发者能SSH登录生产服务器”这一行。开发人员本地调试遇到问题第一反应是上生产看日志如果你在手册里明文禁止又没给日志查询平台开发者就会用各种方式绕过去比如把SSH密钥复制到跳板机或者在生产服务器上装一个临时web终端。权限设计的本质不是不信任人而是让权限错误的影响面可控。一个开发者的账号被钓鱼如果他有生产服务器的SSH权限损失是失控的如果只有代码提交权限攻击者最多往仓库里塞点垃圾代码风险等级完全不同。权限矩阵落地时我一般把生产环境的用户统一收编到跳板机管理目标服务器只开放堡垒机IP的访问。用sudo权限而不是直接给root并在sudoers里限制可执行命令范围。下面是一段Linux侧的用户与sudo配置示例能直接套用在一台新部署的Ubuntu服务器上# 创建新用户并加入 sudo 组 adduser deploy usermod -aG sudo deploy # 限定 sudo 权限只允许 apt、systemctl、tail 和 grep 日志 echo deploy ALL(ALL) NOPASSWD: /usr/bin/apt, /bin/systemctl, /bin/tail, /bin/grep /etc/sudoers.d/deploy # 禁止 root 直接登录 ssh只允许普通用户登入后提权 sed -i s/^#PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config systemctl restart sshd逻辑说明创建deploy用户并加入sudo组是为了让运维人员先以普通用户身份登录再通过sudo执行特定命令。写sudoers.d文件时务必用visudo -c检查语法否则容易把sudo搞坏导致所有管理员都无法提权。这里配置的权限范围很保守只允许deploy做四件事装软件apt、管理服务systemctl、查看日志tail和grep。很多团队会给运维全员root权限这在少人数环境勉强能接受但只要超过三个人一旦某个人的密钥泄露你连追责的依据都没有——所有操作都像root干的审计日志形同虚设。参数说明NOPASSWD表示sudo时不需要再输一次密码适合脚本执行如果公司安全要求严格可以去掉这个参数让每次提权都输密码。PermitRootLogin no是必须的root直接登录会让所有权限控制的努力白费因为root可以做任何事。改完sshd_config后要sshd -t先测试语法再执行systemctl restart sshd避免配置写错把自己锁在门外。2.3 密码策略与账户生命周期参数密码策略是手册里最容易被写成“所有密码必须不少于12位、每90天更换、包含大小写数字特殊字符”这种绝对化条款的。这些参数本身没有错但如果不配合账户生命周期管理就是给运维挖坑。一个真实的场景密码每90天强制更换开发者为了避免麻烦就把密码设为Passw0rd!、Passw0rd!1这样连续递增的序列攻击者拿到一个历史密码就能猜到后续迭代。所以我在写密码策略时核心参数不是“密码多复杂”而是“密码是否唯一、是否在已知泄露库中、失效后如何找回”。推荐用PAM模块配合libpam-pwquality来限制新密码不能与旧密码相似同时禁止用户设置常见弱密码。配置示例# 安装密码质量检查模块 apt install libpam-pwquality -y # 编辑 /etc/pam.d/common-password在 password 行后追加参数 # password requisite pam_pwquality.so retry3 minlen12 difok3 reject_username # 配置密码最大有效期为 90 天最小修改间隔为 1 天 sed -i s/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 90/ /etc/login.defs sed -i s/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 1/ /etc/login.defs # 禁止使用最近 5 次使用过的旧密码 echo password sufficient pam_unix.so remember5 /etc/pam.d/common-password逻辑说明retry3表示输入错误可重试3次minlen12是密码最小长度difok3要求新密码与旧密码至少有3个字符不同reject_username禁止密码包含用户名。PASS_MAX_DAYS 90是90天到期PASS_MIN_DAYS 1是设置后1天内不得再改这个参数能防止用户当天改完密码立刻又改回去。remember5让系统记住最近5次密码避免循环使用。这里必须提醒一点密码策略再强也阻止不了用户在键盘上贴便利贴。真正解决口令问题的方向是推广SSO单点登录和硬件密钥。手册里可以写“密码策略是最低标准”但管理员心里要清楚战略重心应该放在多因子认证上。给关键系统都套上TOTP令牌比密码复杂度提升十倍的防御效果好得多。3. 主机加固实操从补丁管理到日志监控的五个落地步骤3.1 补丁管理的优先级先修RCE再优化体验补丁管理是安全手册里最无聊但最救命的一章。很多运维养成了“补丁有风险能不打就不打”的习惯原因是以前打过一次补丁导致服务兼容性崩溃从此有了心理阴影。这个想法可以理解但做法需要修正不是“打不打补丁”的问题而是“先打哪些补丁”的问题。补丁优先级应该按漏洞危害等级排序而不是按厂商发布时间排序。我在手册里定了一个简单的补丁优先级规则分为三个等级P0远程代码执行RCE漏洞涉及公网开放的Web服务、数据库、中间件必须在24小时内评估并上线补丁。P1权限提升或敏感信息泄露漏洞影响内网核心系统但无公网暴露面在一个补丁窗口期内完成。P2功能性问题修复或低风险漏洞随常规月度补丁一起更新。执行补丁前先在测试环境跑一遍自动化回归脚本确认核心业务接口无异常。跑完以后用镜像快照做备份再批量推到生产。这个过程不是开发流程的附属品它就是安全策略的骨架。有一个常见误区是只打操作系统补丁而忽略了应用依赖的组件。比如Java应用用的Log4j爆出漏洞光升级Linux内核没有任何意义还要追踪到应用目录下lib里面的具体版本。所以补丁清单要维护两份OS补丁清单和中间件/依赖库清单。3.2 Linux主机加固脚本与参数说明在给新服务器做初始化时我通常会把加固动作写成一个Shell脚本而不是靠人工一条条执行。人工操作必漏脚本至少可审计、可重复。下面这个加固脚本覆盖了一些最基本的项目可以直接抄下来按需裁剪保存为security_hardening.sh#!/bin/bash # 1. 关闭ICMP重定向防路由欺骗 echo net.ipv4.conf.all.accept_redirects 0 /etc/sysctl.conf echo net.ipv6.conf.all.accept_redirects 0 /etc/sysctl.conf sysctl -p # 2. 设置umask新文件默认权限不对外开放写 echo umask 027 /etc/profile # 3. 修改SSH默认端口并禁用空密码登录 sed -i s/^#Port 22/Port 2222/ /etc/ssh/sshd_config sed -i s/^#PermitEmptyPasswords no/PermitEmptyPasswords no/ /etc/ssh/sshd_config systemctl restart sshd # 4. 安装并启用fail2ban防SSH暴力破解 apt install fail2ban -y cat /etc/fail2ban/jail.local EOF [sshd] enabled true port 2222 maxretry 5 bantime 3600 EOF systemctl restart fail2ban逻辑说明accept_redirects关闭ICMP重定向可以防止攻击者通过伪造路由跳数来劫持流量这在公网服务器上是一个低成本的防护手段。umask 027是让新建文件的默认权限变成750即所有者和组可读可写可执行其他用户不可访问能有效防止粗心创建的可写文件暴露到内网。SSH改端口是防自动化扫描的工具箱手段注意如果你改了端口别忘了在防火墙里放行新端口并关闭旧端口否则改和不改一样。fail2ban框架设了5次错误就封禁1小时当然不是绝对防御但对脚本化的扫描器很有效。参数说明maxretry是允许连续失败次数建议不要设成1否则内部人员密码敲错一次就被封IP体验极差bantime是封禁时长单位是秒。这里port 2222必须和你改的SSH端口一致否则fail2ban监听的是默认的22端口封禁不生效。改完脚本后先在测试机上执行一遍再在服务器上用ssh -p 2222 userhost验证能登录再关闭原端口。3.3 Windows事件日志与syslog集中采集很多企业内网同时跑着Windows和Linux如果日志各自为政安全事件就变成瞎子摸象。Windows的安全事件日志记录登录成功/失败、账号创建、服务安装等关键操作Linux的/var/log/messages或/var/log/secure记录了系统级变更。把这些日志集中到一个平台才能做关联分析。最常见的做法是用Rsyslog把Linux日志转发到中央日志服务器Windows则使用自带的事件转发Windows Event Forwarding。Linux端配置rsyslog转发的步骤# 编辑 /etc/rsyslog.conf在文件末尾追加 # *.* 192.168.1.100:514 # 如果走加密改用 # *.* 192.168.1.100:6514 # 重启服务 systemctl restart rsyslog逻辑说明表示UDP传输表示TCP传输。UDP速度快但可能丢包TCP可靠但会占用连接。内网日志量大时建议用TCP防止关键日志在攻击者爆破时丢失。中央日志服务器上要提前开好对应端口514/UDP或6514/TCP并且配置日志轮转否则日志一天涨几个GB磁盘很快写满。Windows侧便宜实用的方案是配置事件日志的转发把安全日志发送到统一的收集器。在组策略里设置“Configure target Subscription Manager”指向收集器机器然后在收集器上用wevtutil命令创建订阅。这个配置相对繁琐小型环境如果Windows服务器数量不多可以先用商业Agent统一采集资源更划算。日志集中之后真正有价值的是规则。我在手册里建议至少做三条基础告警规则同一账号15分钟内10次登录失败非工作时间管理员组新增成员防火墙规则被批量修改。这三条规则不依赖任何商业平台用脚本或SIEM里的原语都能实现。告警不需要多但每条都必须有明确的响应责任人。日志采了没人看比不采还危险因为会造成“有人在监控”的错觉。3.4 备份策略与恢复演练安全手册必须包含备份章节而且备份策略的每一行都要能回答一个问题今天系统被勒索加密你能在多久内恢复多少数据常见的备份策略是“3-2-1规则”3份数据副本2种不同存储介质1份异地存放在物理隔离的位置。听起来简单但执行起来最容易翻车的点是备份脚本静默失败。很多备份软件默认只在失败时发一封邮件这封邮件被运维的邮箱过滤到垃圾箱一个月后需要恢复时才发现上一个有效备份是45天之前的。我建议把备份检查纳入日常巡检用自动化脚本每天验证备份任务退出码和备份文件大小#!/bin/bash # 检查昨天的备份文件是否存在且大小大于 1GB BACKUP_FILE$(ls -t /data/backup/mysql_*.sql.gz | head -1) if [ -z $BACKUP_FILE ]; then echo 备份文件缺失请立即检查备份任务 exit 1 fi FILE_SIZE$(stat -c%s $BACKUP_FILE) if [ $FILE_SIZE -lt 1073741824 ]; then echo 备份文件大小异常仅 $FILE_SIZE 字节 exit 1 fi echo 备份检查通过$BACKUP_FILE ($FILE_SIZE 字节)逻辑说明ls -t按时间排序取最新文件如果为空则说明备份根本没跑stat -c%s拿到字节数和1GB1073741824字节比较如果备份文件小于这个阈值说明数据库可能只备份了部分数据或者压缩失败。这个脚本建议放在crontab里每天早上9点执行一次并把输出打到监控平台。恢复演练至少要每季度做一次选一台测试服务器真实还原备份数据记录恢复时长。恢复时间目标RTO和数据恢复点目标RPO不是写在纸上的两个名词它们要拿实际的恢复测试报告来背书。4. 安全落地避坑清单杀软异常、权限过紧、补丁翻车的六个现场4.1 杀毒软件服务异常保护进程自己先挂了现象装好杀毒软件后客户端提示“安全服务异常无法保障计算机安全”任务栏图标变灰扫描和防护功能全部不可用。原因最常见的是杀毒软件的核心服务和系统更新补丁冲突或者是第三方安全软件抢先占用了内核驱动接口导致服务无法启动。很多国产杀软依赖的驱动和某些版本的Windows补丁不兼容尤其是跨版本升级后旧版驱动被系统拒绝加载。解决先确认服务状态以管理员身份打开PowerShell执行Get-Service | Where-Object {$_.DisplayName -like *杀毒软件名*}查看服务是否为Running如果服务停止尝试恢复服务并重启电脑。若重启后仍然异常卸载当前安全软件重启系统后用官方提供的卸载工具做一次彻底清理再重装最新版本。这里要提醒的是别同时装两款杀毒软件它们会互相杀驱动最终就是两个都趴窝。生产服务器上如果装了杀毒软件补丁升级窗口要多留一台备用机先升级一台观察24小时再批量推。4.2 权限收紧过头业务服务直接起不来现象按照手册把服务账号的权限收紧后Web应用出现403错误或数据库连接失败业务中断。原因常见的权限收紧动作是把服务账号从本地管理员组移除或者修改了服务登录身份但没有检查该账号对配置目录、日志目录和临时目录的读写权限。.NET和Java类应用在启动阶段需要写临时文件权限不足时JVM/CLR直接抛异常服务进程反复重启。解决做权限变更前先用Process MonitorWindows或straceLinux记录服务启动过程确认它实际访问了哪些路径然后对照路径逐一分配最小权限。变更之后重启服务前先清理日志目录的残留文件因为旧文件属主不是你新分配的账号会导致覆盖失败。一个更稳妥的做法是先以账号需要的最宽松权限启动服务确认运行正常然后用测试环境逐步收紧每收紧一次跑一遍自动化冒烟测试直到权限边界清晰为止。4.3 补丁没做兼容性测试关键服务器直接重启失联现象批量打补丁之后部分服务器网络无响应或者远程桌面连不上只能去机房接显示器。原因补丁本身的bug或者补丁和服务器上已有的安全Agent冲突。例如某些主防类安全软件会hook系统内核系统补丁替换了被hook的函数驱动未适配导致内核崩溃。越是老旧的服务器越容易出现这种问题因为硬件驱动的版本太老不在兼容性测试矩阵里。解决给服务器分组建立补丁灰度批次。第一批是测试环境第二批是低风险的非核心生产第三批才是核心业务。每一批之间留24小时观察窗口看监控里的CPU、内存、磁盘错误率和报错日志。对于老旧服务器如CentOS 6/7或Windows Server 2008评估补丁时优先看补丁是否涉及内核模块或驱动文件涉及系统底层的补丁尽量不做跨小版本升级。如果厂商已经停止维护该系统版本建议直接在手册里标记为“高危待替换”而不是试图用补丁续命——停止维护的系统根本不具备可修复性。4.4 日志不轮转监控平台先失明现象某天监控面板突然没有任何日志更新点开磁盘空间一看/var/log占用100%rsyslog进程因为无法写入文件而退出了。原因日志轮转策略没有配置老日志永远不会被压缩或删除。访问量大的Web服务器一晚上产生几十GB日志两天就能把磁盘写满。更麻烦的是日志写满后系统会变得极其缓慢或直接崩溃。解决在/etc/logrotate.conf和/etc/logrotate.d/下为关键应用配置轮转规则。标准配置是/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 www-data adm }逻辑说明daily每天轮转一次rotate 14保留14份即两周compress对轮转后的旧日志做gzip压缩delaycompress让最近一份日志延迟压缩方便当天排查。create 0640 www-data adm指定新日志文件的权限和属主避免应用无法写入。配置完之后用logrotate -d /etc/logrotate.conf做debug模式检查确保语法无误。日志集中到远程服务器之后本地保留天数可以缩短到7天远程端保留30天即可对应等保要求。4.5 备份只在后台跑恢复时才知道白做了现象勒索病毒把生产数据和备份数据一并加密后你登录备份服务器一看发现备份服务器和业务服务器在同一域内备份文件连存储账号都是Domain Admin权限病毒直接继承了这个权限加密了备份。原因备份策略写了“异地备份”但实际部署时备份服务器就搁在业务机房的同一网段账号权限也没做隔离等于把鸡蛋放在同一个篮子里。此外备份任务是静默运行的没人定期检查备份内容是否可读。解决备份机必须独立于业务域账号不能用域管理员备份存储的写权限只对备份服务账号开放。备份验证脚本中加入测试性恢复至少每季度做一次真实恢复到隔离环境的演练。这不是技术问题而是流程纪律问题手册里写不出什么神奇命令但可以写清楚验证清单备份文件能否解压、数据库文件能否挂载、应用能否连接数据库。4.6 基线配置漂移安全状态没长效现象服务器上线时做了安全基线加固三个月后检查发现基线已经失效。有些端口被业务人员临时放开了防火墙规则越堆越多SSH密码登录又被启用了。原因业务在线变更时因为着急跳过了流程改完以后没有同步更新基线文档。安全基线如果不能自动检测和恢复就是一个一次性动作而不是持续状态。解决用自动化巡检脚本定期比对基线。例如把需要关闭的端口写入配置清单用脚本每分钟扫描监听端口一旦发现清单外的端口监听就自动触发告警甚至执行封禁策略。基线漂移是一切安全工作的终极敌人手工维护基线不可持续。把基线固化成代码每次上线任务自动执行基线检查并输出报告这样才能防止安全投入在几个月里蒸发殆尽。5. 验证安全做没做到位一次30分钟的基线巡检与日志排查5.1 用巡检脚本快速核对用户、权限、端口和补丁安全手册写得再厚最终要回答一个问题当前系统真的处于安全状态吗我每次接手一个新环境都会花30分钟跑一轮基线巡检。下面这个脚本基本覆盖了最核心的检查项可以在Linux服务器上直接执行#!/bin/bash echo 用户与特权检查 # 列出所有 UID0 的用户正常情况下只有 root awk -F: $3 0 {print $1} /etc/passwd # 列出所有可登录用户检查是否有非预期账号 grep -v nologin\|false /etc/passwd | cut -d: -f1 echo 端口监听检查 # 查看当前监听端口重点关注非标准端口 ss -tlnp echo 关键文件权限检查 # 检查 /etc/shadow 权限应该只有 root 可读 ls -l /etc/shadow # 检查全局可写文件排除 /tmp 和 /dev/shm 等正常目录 find / -xdev -type f -perm -0002 -not -path /tmp/* -not -path /proc/* 2/dev/null echo 补丁级别检查 # Debian/Ubuntu 显示可更新包数量 apt list --upgradable 2/dev/null | wc -l巡检思路说明awk -F: $3 0是抓取passwd文件中UID为0的账号正常情况下只有root一个。如果多出额外的账号说明有人创建了影子账号这是入侵或后门的重要标志。ss -tlnp看当前监听端口如果在服务器上发现了一个你没有部署过的端口在监听大概率是有恶意进程。find找全局可写文件的逻辑是全局可写意味着任何账号都能改这个文件如果它是一个脚本或者配置文件就相当于给攻击者提供了一条持久化路径。apt list --upgradable统计可更新包数量数量过多说明系统补丁滞后需要安排补丁窗口。这四条命令组合起来可以在几分钟内判断一台服务器的基本健康状态。我建议把它做成一个cron任务每周跑一次并把输出保存到日志目录这样你至少拥有历史快照能对比出“上周正常、这周多了一个端口”这类变化。5.2 日志异常模式识别密码爆破与横向移动痕迹安全的另一个验证维度是日志分析。新手看日志常常无从下手只看有没有error关键字其实攻击者的行为在日志里是有固定模式的。我最常看的几个特征是短时间内同一个账号大量失败登录成功登录之后紧接着有大量的目录枚举请求非工作时间出现管理员账号登录。用一条命令行就能快速筛查# 统计最近一小时内 SSH 登录失败的 IP 和次数 grep $(date -d -1 hour %b %d %H) /var/log/auth.log | grep Failed password | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20逻辑说明先按当前小时过滤出这一个小时内的日志行再筛Failed password关键字取IP字段即倒数第四个字段排序后统计各IP失败次数按频率降序取前20个。如果某个IP出现了几十甚至上百次失败说明正在被爆破。响应动作是先封禁IP再排查该IP是否曾成功登录过。如果失败和成功之间只有几十秒间隔就要立刻调查那个账号的后续行为。安全工作的核心是在日志里训练出“不对劲”的直觉这种直觉不是天生的是每天看日志积累出来的。5.3 把安全基线固化成上线流程的一部分最后一个验证维度也是最容易被忽略的新系统上线时的安全检查。很多团队的安全检查是在系统被攻击之后才补做的这是本末倒置。正确做法是把安全基线检查卡在变更流程中——任何系统在上线前必须通过安全巡检脚本的所有检查项未通过的不能进入生产。这样做不需要额外增加工作量只是把上面写的巡检脚本在部署流水线里跑一遍。一旦形成这个习惯你手里的安全手册才算真正运转起来它不再是文档库里的死文件而是一套随时对生产环境生效的活规则。我个人的血泪经验是有一次给服务器做基线加固改了sudoers文件之后直接用visudo保存退出结果没有先开一个新的SSH会话验证而是直接断开了现有连接随后发现sudo语法错误导致所有提权操作失败差点把一台核心数据库锁死。后来我给自己定了一条铁律任何涉及权限和认证的配置变更必须先开一个备用SSH会话变更完成后用备用会话验证无误再关掉主会话。这条习惯我希望能写进你的实践手册里希望帮到你。本文还有配套的精品资源点击获取