Velvoria 科技观察 Velvoria 科技观察 云端 · 治理 · 韧性
数据中心冷通道内工程师正在整理机架线缆

云端部署与资安基础 · 综述

云端部署中的身份验证与权限基础

企业把系统搬到云上时,先要回答谁能进、能做什么、做过什么留下记录。这篇综述按这个顺序梳理做法,面向第一次负责云环境加固的工程人员。

总览

先把人、权限和记录理顺,再谈加固

企业把系统搬到云上时,最先要处理的通常不是机器规格,而是谁能进、能做什么、做过什么留下记录。这三件事分别对应身份验证、权限控管与日志监控。本文按这个顺序梳理常见做法与容易出错的环节,面向第一次负责云环境加固的工程人员。涉及 AWS 的内容只说明配置环节,不做平台比较。

阅读方式很直接:先看身份与权限两节,确认账号体系没有明显缺口;再看日志与修补两节,确认出事时有线索可查、修补有先后;最后看零信任与常见失误,做一次对照检查。中小团队可以先完成文末列出的几件基础工作。

本文覆盖

  • 身份验证:人员与服务账号分开,多因素验证先行
  • 权限控管:按职责划分,定期回收临时授权
  • 日志监控:访问与操作分开留存,保护日志本身
  • 修补节奏与零信任:按暴露面排序,从内网验证起步

身份起点

为什么从身份开始

云端部署 · 身份验证

云环境的入口是账号体系。多数配置失误不是防火墙写错,而是某个服务账号权限开得太宽,或者离职人员的凭证没有及时回收。入口不清,后面的规则写得再细也站不住。

身份验证的第一步通常是启用多因素验证,第二步是区分人员账号与服务账号,两者的权限策略不该共用。人员账号对应到具体负责人,离职、调岗时可以直接停用;服务账号对应到固定用途,只给完成任务所需的最小范围。这一步做扎实,后面的加固才有意义。

刚接手环境时,建议先导出一份账号清单:谁在使用、对应什么职责、上次使用是什么时候。长期没有登录记录的账号先停用观察,确认无影响再删除。服务用的密钥单独保管,不与个人账号混放,也不写在代码或文档里。

接手时先核对的三件事

  • 多因素验证是否覆盖管理员

    特别是最高权限与计费账号,先确认,再谈其他。

  • 人员与服务账号是否分开

    共用策略会让回收和排查都变难,分开后责任更清楚。

  • 离职与闲置账号是否已停用

    先停用、观察一段时间,确认无调用再删除。

冷色调运维室内操作人员双手正在键盘上工作

现场记录

权限问题多半不在发布当天出现,而在三个月后:临时授权没有回收,测试账号还在使用。定期回看一次清单,比写更细的规则更有效。

权限控管

权限控管的最小化思路

最小权限原则说起来简单,落地时要回答一个问题:这个角色实际需要哪些操作。常见做法是按职责划分角色,而不是给每个人单独配一套权限。职责变动时,调整角色归属即可,不用逐条改策略。

定期回看权限清单也很关键,尤其是临时授权的项目结束后是否回收。建议把临时授权写上到期时间,到期自动提醒复核。AWS 的权限策略可以写得很细,但过度细化的策略反而难维护,需要找平衡点:先按职责分粗组,再对高敏感操作单独收紧。

机架上成束网线的近距离特写

把职责分组写清楚,临时授权标上到期时间,复核时对照调用记录增删。

核对栏

  • 按职责分组,不按个人堆权限

    新人加入先归入职责组,离岗直接移出,减少遗漏。

  • 临时授权写到期时间

    上线、排障等短期需求单独建组,到期复核是否收回。

  • 高敏感操作单独收紧

    删除数据、修改网络出口等动作,缩小到最少人数。

难度提示:分组梳理多数团队可以自己完成;跨账号的策略重构,人手不足时再考虑外部协助。

日志监控要留存多久

日志的价值在事后排查时才体现出来。留存时间太短,出事时查不到线索;留存太久,存储成本会上升。常见做法是把访问日志与操作日志分开处理,操作日志保留更久,因为它直接记录谁改了什么。

日志本身也要保护,避免被有权限的人改写。做法包括集中收集到独立的存储位置、限制删除权限、开启防篡改保留。没有集中之前,至少做到关键系统的日志异地留一份,本地被清理时还有副本可查。

访问日志

量大,用于看趋势与异常登录,周期可以短一些。

操作日志

记录变更动作,排查时最有用,建议保留更久。

日志保护

集中存放、限制删除,关键系统多留一份副本。

补丁难在排期,不难在技术:先修既对外、又碰敏感数据的系统。

修补、零信任与常见失误

下面四组按同一版式排列,方便对照阅读。每组结尾标了自行处理的难度,方便小团队安排人手。

漏洞修补 漏洞修补的节奏怎么排补丁管理难在排期,不难在技术。内部系统、对外服务、测试环境的风险等级不同,修补窗口也应该不同。可以按对外暴露程度和数据敏感度两个维度排序,先处理既对外又碰敏感数据的系统。测试环境不补丁,往往会成为进入内网的跳板,至少做到与生产环境同步修补高危项。 零信任基础 零信任常被误解的地方零信任不是买一套产品就能达成的状态,它更像一组持续的检查动作:每次访问都验证身份、每次授权都按当时的情境判断。对多数企业来说,起点是把内网访问也纳入验证范围,而不是默认内网可信。这个转变涉及流程调整,技术只是其中一部分,比如先从远程接入与跨部门系统开始试点。

对照检查

常见配置失误举例

存储桶权限设置为公开、网络放行范围过大、日志未开启或未集中、密钥写在代码里,这几类问题在云环境中反复出现。它们的共同点是配置成本很低,出事时代价很高。定期做配置检查比事后补救省事。

混凝土墙面上门禁读卡器的近距离外观

公开存储与过大放行:发布前检查一次对外暴露面,收紧后再上线。

窗光下键盘与工作桌面的局部细节

未集中日志与硬编码密钥:把密钥移入专用保管,日志汇总到独立位置。

小团队

中小企业能自己做到哪一步

账号梳理、多因素验证启用、备份还原测试,这几件事通常不需要外部协助,一个下午加一个周末就能起步。权限体系的重新设计、日志集中管理、威胁情报接入,则要看内部有没有相应的人手。本文涉及的做法会标注难度,方便读者判断,先做投入小、效果直接的部分。

自己先做的三件事

停用闲置账号并开启多因素验证;做一次备份还原演练,确认备份真的能恢复;把临时授权列出来,逐条确认是否到期回收。这三件做完,环境已经比多数同规模团队整齐。

从基础到下一步

把身份、权限、日志三件事理顺之后,再考虑网络分段与威胁情报接入会顺很多。关键基础设施防护与金融业资安韧性两篇综述里,有更多关于分层防护与应变流程的说明,可以作为下一步的阅读材料。

浏览全部文章存档