![]()
0x1本周话题
话题一：请教下，大家会把Linux服务器的root账号名修改成其他账号名吗？修改掉会不会有风险？
A1：root直接禁用，为啥还要改？
A2：说是有些运维平台对接要用root账号。
A3：可以梳理一下到底有哪些，程序进程是必须用root的，如果没有直接禁用掉，或者有需求单独申请root权限。一般配置文件中针对root的配置都是写的 root 而不是uid ,所以你直接改名字，肯定有问题。
A4：一般sudo都能搞定吧，没说肯定得root。新增的可以这样搞，存量的得慢慢搞了。
A5：一般都能搞定，就是需要避免环境变量的问题，在一个需要考虑哪些用户有sudo权限，如果批量配置了，相当于开放root了。
A6：禁用root跟程序用root权限跑是两个概念。
A7：禁用root只是禁用无法登录吧？设置/sbin/nologin。
A8：遇到的是有些运维监控指标是需要root权限，这种可以给运行这个监控进程的普通账号加sudo权限即可，无需已root账号运行进程，root账号默认是禁止登录的。
A9：堡垒机配root做特权账号管理，和允许sudo有啥区别，而且不允许root直接远程登录，可以普通账号切换。
A10：sudo是配置到具体需要的命令，不是默认sudo su - 到root啊，堡垒机我们不授予root远程登录，root就是默认不允许登录，另外我们的账号密码不托管到堡垒机，防止堡垒机被接管了，影响大。
Q：都linux了为什么还要用账号密码登陆？有密码是不是还要考虑弱口令问题？
A11：所有的sudo命令都会被审计到，记录在auth.log这里，root执行的命令如果不在堡垒机是没办法审计的。
A12：我是讨论root账号管理的方式，只要控制权限不就行么。直接普通账号证书登陆，登陆限制只能堡垒机，然后允许特定账号可以su切换到root。而且通过人记账号密码，这不是风险更大么。
A13：只需要控制好堡垒机权限和linux中账号权限就可以了。
A14：证书的口令，外加一层，只有VPN能到堡垒机访问，做成巷子式封闭式访问。
A15：我们是atrust控制谁有权限登陆atrust，然后服务器登陆的证书都是维护在堡垒机上，只有运维的证书和证书口令是下发到运维负责人手里。
Q：请教个题外话，如果哪天堡垒机挂了，但是又紧急有维护需求，会有一个后门预留吗？就类似之前好像是google的某个集中服务挂了结果进不去机房。
A16：我们是除了堡垒机还搞了一台跳板机，跳板机控制就更严格了，只有指定一两个人可以登陆。
Q：现有的业务用root用户部署的后期修改成普通用户，运维人员说没法改。改了后应用会出问题，这个怎么破？
A17：root启动的可以用普通用户维护么？堡垒机托管普通用户，然后su到root用户么？
![]()
话题二：请问开发、运维人员访问生产服务器是如何安全管控的？生产服务器是不是不会开给开发人员远程访问权限的？
A1：堡垒机啊，细化访问权限。严格来说研发人员不允许有生产环境权限，也就是权限最小化原则。
A2：细化命令管控。
A3：生产也不会直接给开发啊，生产只会给应用运维。
A4：你估计是生产环境的日志，排查问题时这些要给到开发，这样的需求。集中采集到日志中心。
A5：是的，有些日志要在服务器上排查，还有些配置文件修改的，服务启停的操作。访问控制只能在服务器上做吧，我们用的堡垒机很辣鸡，没什么功能。
A6：有两点：
- 稍微松一点的话，堡垒机开临时授权，过期自动失效，或者走审批，部门开发走申请，业务部门负责人审批----运维部门审批后开临时授权。
- 应用服务器的日志吐到日志平台，让开发去日志平台看日志排查问题。
A7：大家会做一些堡垒机的安全监测告警吗？比如非正常时间登录、改密之类。A8：这种可以接到soc里，做处置。还有，非正常时间是什么概念？A9：上班时间9-6，你凌晨两点上来不需要监控下？正常上班时间段和申请变更时间外；其他都是非正常时间。非工作时间，根据你们业务的模式来看，如果工作日9点到22点是运维的高发时间，那么其他时间的都是需要确认的。A10：我们24小时运维人工值班，凌晨变更处理也不是啥过分的，不过也理解这样的设置规则。A11：每家公司具体情况不太一样，不过周六晚上凌晨两三点的变更确实比较奇怪。单一指标可叠加行成多维度数据，偏离预警。战时会，平时不会针对时间，处理故障太正常了，但会对高危命令啥的做监控。A13：大家把堡垒机告警推给谁确认？运维人员部门安全员还是负责人？A14：昨天拦截了一个这个 mv /* 的误操作，我一般是推给运维部门钉钉群。A16：嗯，堡垒机的日志比较规范，简单易懂。拆解一下字段再告警模板自定义推出来就可以了。话题三：大家有用到SCA软件成分分析去管理开源组件的吗？或者说大家sca都是怎么用的？
A1：SCA我们在提测时候用，风险数据吐到devops工具链作为上线门禁，当前在实施构建时候控制风险依赖下载，筹划定期对中央仓库开展存量检测和在IDA环境通过插件方式控制编码安全。A2：整改是个很好的课题，我当前通过黑名单漏洞库为强孔，非黑名单但属于高危及以上不影响上线，但列计划整改，后面就是闭环问题。A3：另外间接依赖这块整改，建议升级直接依赖消除，如版本太新存在较大兼容问题或者新版本直接依赖的间接依赖任然存在问题，可以指定问题的间接依赖版本升级，在退一步就是项目组澄清不调用存在问题的间接依赖，双方当前是邮件留档，后面也准备做到线上流程里。Q：对我们来说整改是个大问题，主要是那些上线已久的存量系统。另外再请教一下，咱们sca是归属于研发？架构？还是安全来管理？A4：工具和治理都有的话，SCA属于开发安全，肯定是安全管理吧。A5：我之前的理解是软件供应链治理归属架构比较合适。sca用来做开发过程的质量把控让研发管理比较合适，安全只是作为上线门禁阶段使用。A6：SCA使用是测试团队，SCA治理和卡点设计、标准由安全来制定，上线由生产质量团队来判断，这个只是参考，还得结合每个单位devops目标和对应组织来看。A7：比如上面下发了一个开源组件的高危漏洞，需要全网进行排查，这个肯定是安全负责完成吧。A8：漏洞的排查治理应该是安全来牵头，然后内部在联动处理。A9：SCA的核心作用也是这个，至于做私库的开源组件过滤，只是协助开发而已。Q：你们的SCA是怎么结合到DevOps流程中的？流水线？测试？制品库都搞吗？怎么分级呢？A10：都搞。分级是什么概念？是组件风险分级？还是指先搞哪个环节？A11：不同环节的，扫描标准规则之类的，IDE流水线代码提交，测试，制品库。A12：目前没有标准规则的说法，接入扫描后用的是平台的扫描规则，自己只能加黑加白调整不了规则。不同环节根据识别出来的组件漏洞风险等级来制定修复优先级，像前面说的直接依赖以最近的安全版本推荐升级，间接依赖看资源情况升级一般也是推荐采用直接依赖升级覆盖间接依赖或者不调用间接依赖的形式来解决风险。流程优先级我们是先卡住上线，就是一个项目他们开发好了要生产打包之前，必须Merge到生产分支，这个环节先做。整个研发从后往前推，IDE插件目前只是试用没有全面铺开。IDE插件式最后一个推的环节。A13：开发测试形态下还是研发干预多一些比较好，投产运行形态下安全主导比较好，当然这是我们这里的情况。A14：对，所以我们SCA部署到jenkens中进行发布制品的开源组件检测，做上线前的开发安全把控。流程职能分工方面都还好说，就是整改是得费些心思。也可以在发布系统加个node扫描节点。
由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将【君哥的体历】加为星标或每次看完后点击一下页面下端的“在看”“点赞”。
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
