运维安全

#### 操作风险

操作风险，要引入双人复核机制，业务部门的关键参数修改的风险控制，关于人的失误有如下几点基本理念：

人失误是很难完全避免的，即便是很优秀的人也会犯错误；失误通常不是本人的主观愿望；可能发生失误的情景是可以预测、控制和防范的；个人行为受到组织、制度和管理水平的深刻影响；理解并消除导致失误的因素，通过培训从以往的事件中汲取教训，可有效避免人因失误的发生。

操作流程，itil，多重复核，仅双人复核一条，对很多中小企业都不太适用，人也不够，流程长了也不利于企业发展效率不高

传统观念认为个人是“引起”事故的原因，对犯错人员进行点名批评、责备，使其羞愧。假定过失或错误的原因是疏忽、精力不集中、不仔细、缺乏知识或技能、态度不积极或者许多其他过失之一。利用对纪律的强调和敬畏来提高安全程度。

认识到整个体制对错误的形成都有贡献，承认组织文化、人－系统接口的设计以及环境要素会为“潜在失误”创造条件，“潜在失误条件”会诱发人员犯错，认识到个人的局限性，个人犯错是不可避免的，因此，构建体制时应当预见到个人犯错的可能性并努力减轻其引起的后果，关键参数修改应该有双重确认机制，关键参数的修改监测。用更多的制度和流程可以减少发生此类事件

Resmussen & Jensen 于1974年提出的关于人因失误分类的理论：技能型失误，程序型失误以及知识型失误。

#### 黄金法则

不能依赖于人，而应该依赖于技术控制，所有生产变更都要遵守以下黄金法则：

1. 在非生产环境尽可能充分的进行测试，由于特殊原因无法进行测试的，写特批申请。以上测试方案应记录在变更中；
2. 变更实施的时候，先从一个系统，一个设备开始，搞定一个在搞其他。充分利用冗余 failover机制；
3. 一定要确保能回滚到上一个正确配置，并且把回滚脚本记录好；
4. 高风险，高复杂的变更，必须引入第二双眼睛。两个人互相签对方的操作。对于特殊应用，引入第三双眼睛，第三双眼睛需要是开发；
5. 评估最坏情况，做好最坏情况的修复计划；
6. 做完变更后，要第一时间尽可能的充分并且独立的测试。测试计划要包含谁什么时候什么地点把这个变更结果移交出去，做测试的人必须经过资格认证！
7. 业务运营数据，填入之前，需要申请，发布之前，需要双人操作。

devops，关键就是确保审批通过的payload自动执行，手敲命令，先不说可以干审批之外的事，还容易犯错，比如迷失在shell窗口中，双人复核、金库模式属于兜底方案，你实在没办法，可以扑人啊，在事故面前没人讲困难，没人讲要方便要轻松

我觉得现在很多的要求都忽视了企业发展的自然阶段，一些要求应该是发展到一定程度才能成为必须要求，遗憾的是，企业科技发展的阶段与各阶段的发展要求现在没有明确的现行标准。等保对系统重要性的定级无形中鄙视了很多中小企业～～这些企业系统故障只会让自己倒闭，基本不会对大范围的公民和社会造成影响，而公安推行等保时却往往强制让报送三级系统，也变了味道

#### 配置安全

其实配置不当，说穿了就是导致没权限的有了权限，安全平时公网口监测好，es、S3、mongodb这些都能第一时间发现，手伸得太长，你得定义什么才是“异”动。。。比如sftp，我给a用户了b目录权限，这到底是业务需要呢，还是异动呢，安全能把“公开无授权”的收住，至少影响就控制住了，不管是漏洞服务还是配置失误都能管上，roi极高，比如服务器配置，有基线，这个就可以检查，业务配置，今天这样明天那样，安全很难去定义，配置不当导致的运维事件，我个人建议由变更经理/IT经理/运维经理去兜，安全别兜这个

其实是这样的思路：1、在站安全角度，配置管理需要有安全基线或标准的介入，当然业务需求变化大，是个问题，只能特殊处理，但是为防范这类配置不当事件，安全需要有感知监测、预警能力；2、配置不当导致的运维事件或安全事件也好，需要有后续追溯的能力。

很多场景下，可以以数据为中心，检测数据的异常流动。我们给xx移动的一个case：他内部不许可外包账号访问boss系统上的敏感数据，我们监控boss系统几天，获得所有获取过boss系统敏感数据的账号，和他外包账号做个交集，发现2个外包账号从boss上获取过敏感数据，对方再根据链路调查发现是一个系统没有做访问控制

可以多找一些开源软件配置错误（或默认配置）导致的入侵案例，然后做个攻防演示案例，不枯燥效果也可能会更佳。很多案例可以搜索乌云漏洞历史库

web（apache、tomcat、nginx、weblogic、Jboss等）、数据库（Oracle、MySQL、Redis、MongoDB、elasticsearch等）、容器（docker等）、其他的如jenkins、jira、confluence、zabbix等。

1、代码根据规则扫描，若出现问题，不是说不发，需要核实其存在的风险是否当前可接受，敲定下一次发版之前修复；2、上线前执行代码自动化扫描，这个效率问题确实需要解决（①、时间上做好充分沟通，事务上保持联动），否则，影响安全工作的开展（很可能成为安全的坑点）。

这种身份信息冒用似乎很容易，在于审核信息环节，未特别注重唯一性特征信息校验，所以生物特征（个人基因、指纹、声纹、掌纹、耳廊、虹膜、面部特征等）标识相当重要。

#### 云安全

金融机构采用估计国内还需要一段时间，主要是想讨论下容器、Service Mesh、K8s、Istio的安全防护、检测经验，基于 ip 的和 iptables 的防护手段力度太粗了

K8S 上之后，POD 的启动、分配什么 IP 是 K8S 自己控制的，如果定期导出也可以，如果要想得到即时的更新，有两种方法，一，分析日志，看哪个 pod 启动了，哪个停了，再处理，这样麻烦；二，跟软件系统一样，引入服务注册和注销的机制，只是这里是 pod 注册和注销，这样就能在 zookeeper 上得到一些约定好的信息更新。至于新的需求，可能要通过下发新脚本触发执行，这块还没想太清楚，等我们有机会实践了，会分享，也可能想的根本不对，也就当认真思考和尝试的代价了。

我们在调研基于 SPIEE 的认证和基于 Namespace 的认证方式，还需要跟企业内部 AD 打通，跟Kubernetes RBAC 打通，云环境下更加复杂

跟云上的 IAM 结合，同时逃逸也是重要的风险需要 gVisor 类似的沙箱，还要考虑细粒度的访问控制，例如基于 pod 的，多租户问题等等

个人认为：谨慎原则是安全原则之一。“你猜不出结果，却能防止想不到事情的发生。”比如说，在今年的XX行动中，我猜不到齐治堡垒机可能存在远程命令执行漏洞，但是我绝不会把堡垒机开放到外网。

#### 单点登录

**单点登录系统，除了以下风险，大家有补充的吗？**

1、单点登录系统故障或身份认证功能失效，导致批量系统无法登录使用，可能带来大面积业务连续性风险。

2、单点登录系统账号密码泄露，导致其他系统权限无法把控。

3、单点登录系统与应用系统之间明文传输令牌、口令等敏感信息。

4、单点登录系统无超时自动退出机制，导致他人盗用，危害可单点登录系统。

5、单点登录系统安全性不足，被攻击得手后导致其他系统沦陷。

6、单点登录系统密码未设置复杂度或未强制修改初始化密码，导致简单密码存在。

系统本身、系统设置、密码相关等等，与单点登录系统相关的，概要上都可以认为是其或引入的风险

1，2，5算是单点登录集中引入的风险；3，4，6不算是引入的风险，是用的有问题或者设计的有问题。5的风险需要与独立实现登录比较，一般倾向于认为单点登录设计实现和使用好的话，比每个系统单独实现登录的风险更加可控。

但是3可以修改一下，把明文去掉，就是说由于单点登录导致登录认证信息需要传递，也算是引入了风险。

1、容灾+核心业务 bypass SSO 可以规避；

2、 取消静态密码，改 OTP 认证；

3、 走HTTPS；

4、 SSO 增加session 空闲超时、总登录时间超时机制；

5、 核心业务系统增加鉴权，做二次验证；

6、 同2，取消静态密码