危险!安全人员和开发运维人员之间的误解

安全团队和开发运维人员团队之间的误解可将企业置于业务风险之中

从物理、金融风险,再到战略和运营风险,今日企业被种种风险所包围。企业和员工必须就这些风险进行沟通,这反而会促进企业团结一心。这种沟通需要IT人员、安全人员和开发运维人员(DevOps)的通力合作。这些团队应当清晰地认识到应用的安全性和业务风险波动之间的关联,这会让他们进一步明了自身在解决安全风险时的职责。相对的,失败的沟通也会让整个企业处于危险之中。

倾向于聘请开发运维人员的企业通常会追求高投入产出比、内部的持续创新,以及高敏感度的客户响应能力。大多数领导团队最恐惧的就是对手的创新和进步,以及疏远了本应抓住的客户而导致销售额损失。因此,安全团队的话语权远远不如开发运维团队,更不要说阻止后者了。即使在最理想的情况下,安全团队也只能对他们产生一些影响。

安全团队要想和商户以及开发运维人员进行有效沟通,就需要了解应用安全和企业面临的风险波动之间的关联。如果能实现这一目标,安全团队将会在信息风险事宜上更有话语权。然而,如果对这些风险置若罔闻,企业将会遭受各种安全问题的困扰,团队地位也会一落千丈。

避免沟通失败的第一步,就是了解开发团队不需要的安全措施。某些最佳实践指南就不尊重技术现实,比如“加密数据库中所有数据”,这样的指南显然不具备实际意义。标准应该适合应用,并且对于开发团队具有可行性。那些缺乏开发经验的安全团队常常误入这个陷阱。

除此以外,执行安全测试时漏洞信息管理的欠缺是害处多多的。检测工具会误报,虽然确定了这些漏洞,但是这些“漏洞”不能反映系统或软件的真正弱点。工具还会错报所检测到漏洞的严重程度,而导致的不合理优先级。在与开发运维团队沟通时,漏洞误报既浪费时间,也降低了安全团队的可信度。

最好的结果是:对缺乏兼容性的漏洞加以沟通,或形成未修复漏洞的日志。最坏的结果是:开发团队把时间浪费在了没用的补丁上。应用的安全性常常难以捉摸,所以许多开发团队仅凭自身是难以理解漏洞的。如果他们无法认识到这些内容,他们就无法正确评估漏洞的风险,也不会知道该如何解决它们。而兼容和支持恰恰是开发团队取得成功的关键。

开发运维团队需要和安全团队沟通哪些内容?

当安全团队与开发者沟通漏洞时,漏洞必须确实存在且被精确测评,安全团队对漏洞影响的说明会让开发运维团队更加心中有数。针对性的补救建议至关重要,它需要尽可能和开发团队所使用的语言和框架相符。这使它能更容易解决问题,漏洞可以更快也更有效地被修复,修复漏洞的时间产出比也会得以改善。目标明确的漏洞修复也更容易一次性成功。

安全团队还可以为漏洞的处理以及合规提供有价值的指导。一旦因为漏洞而导致处罚或关停服务,开发团队需要及时获得这些漏洞信息并第一时间进行修正。

除了漏洞,安全团队还可以就系统架构建议进行进一步沟通,来更好的设计应用以减少系统因为合规要求而受到的种种束缚。举例而言,将信用卡相关事宜交给可信的第三方可以避免系统需要受不符合PCI-DSS的评估。另一个例子,不进行非必要的个人身份信息存储(PII)以避免人工管理数据的风险。营销人员经常想要存储所有可访问的数据,但是系统设计师需要理解储存过多的数据对隐私和安全的影响以及相伴的风险。

安全团队和开发运维团队之间的误解会让企业面临风险。在与业务风险相关的应用安全已经对业务造成了影响时,安全团队应当出面进行沟通。如果安全团队可以从品牌、金融、战略等方面进行风险评估,那么他们就会成为开发运维团队最可靠的谏言者,并帮助开发运维团队建立和维护安全的系统。

本文转自d1net(转载)

时间: 2024-10-30 05:33:36

危险!安全人员和开发运维人员之间的误解的相关文章

资深程序员实例总结分享短网址开发运维经验

每个萝卜下都隐藏一个坑. 前段时间955短网址日重定向次数最高达400万,主要开销是重定向请求的用户数据储存与分析.分别经历了内存瓶颈.IO 瓶颈后,高峰期达到 CPU 上限,几乎榨干了机器,下文是经验总结分享. 前置条件 由于短网址很难盈利,硬件特别寒碜,带着镣铐跳舞反而别有风味,当然,人力投入,技术方面也不能和其他大网站比,所以如果要拍砖请轻下手--哎哟. 我们采用的硬件: 盛大云微型,1G内存,单核共享型 CPU. 后期追加了一个同等配置的内网机器做 MongoDB replSet. St

《Oracle性能优化与诊断案例精选》——1.6 理想实践,开发运维一体化

1.6 理想实践,开发运维一体化 在数据行业那么久,我们总希望能够通过自己的努力,将好的想法落地,渐渐地改变行业中的不合理之处,让这个技术世界变得美丽一点点. 那么这个行业里有什么迫切需要改变的? 作为资深的DBA你可能会发现,我们10年前处理的问题和今天没有什么不同.针对数据库的运维巡检日复一日,SQL优化应对全表扫描或是隐式转换,转眼就耗费了经年的时光.所以我们有一个理想,不要让DBA重复在这些无休止的工作上,或者至少能够做得更有价值,也力争能够改变用户在使用数据库的过程中,屡见不鲜的事后救

DevOps转型的柳暗花明:开发运维一体化PaaS平台建设

本文根据陈能技老师在[2016 Gdevops全球敏捷运维峰会广州站]现场演讲内容整理而成.   (点击底部"阅读原文"获取陈能技演讲完整PPT)    讲师介绍 陈能技,DBAplus社群原创专家,新炬网络首席DevOps专家.14年开发测试与质量架构经验,擅长DevOps及APM.Docker.持续集成.持续交付在企业中的落地实施.著有<软件性能测试诊断分析与优化>.<软件自动化测试成功之道>.<深入浅出性能测试与LoadRunner实战>等书.

Redis开发运维实践指南数据操作之key操作

数据操作 熟悉每个数据操作前一定要明白每个操作都是代价,以时间复杂度和对应查询集或者结果集大小为衡量.时间复杂度收敛状况如下: 2.1.1 列出key keys *user* keys * 有3个通配符 *, ? ,[] *: 通配任意多个字符 ?: 通配单个字符 []: 通配括号内的某1个字符 注:生产已经禁止.更安全的做法是采用scan,原理和操作如下: 针对Keys的改进,支持分页查询Key.在迭代过程中,Keys有增删时不会要锁定写操作,数据集完整度不做任何保证,同一条key可能会被返回

Redis开发运维实践高可用和集群架构与实践(四)

11.1.4 高可用和异常测试 11.1.4.1 测试环境介绍 sentinel的消息可以通过sentinel日志(/redis/log/sentinel.log)以及sentinel:hello订阅此频道进行查看. 11.1.4.2 手动切换测试 集群情况,2.128为主 发起主动切换: 查看sentinel日志: 在2.129上看,集群已经切换过来: 11.1.4.3 主实例宕测试 接上,此时master为2.129,找出redis实例的pid,然后kill: 此时查看sentinel日志:

Redis开发运维实践Shell提权问题

Redis安全问题 Redis是一个弱安全的组件,只有一个简单的明文密码,因此在保护上需要对其他多方面的措施,另外,很多所谓安全问题不是redis本身造成的,而是误用的结果. 9.1 Shell提权问题 问题报告:http://drops.wooyun.org/papers/3062 问题分析:Redis 安全模型的观念是: "请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的" .The Redis security model is: "

Redis开发运维实践数据操作之集合操作

2.4.1 添加元素 sadd key member 成功返回1,如果元素以及在集合中返回0,key对应的set不存在返回错误 2.4.2 移除元素 srem key member 成功返回1,如果member在集合中不存在或者key不存在返回0,如果key对应的不是set类型的值返回错误 2.4.3 删除并返回元素 spop key 如果set是空或者key不存在返回nil 2.4.4 随机返回一个元素 srandmember key 同spop,随机取set中的一个元素,但是不删除元素 2.

Redis开发运维实践开发者设计规范之典型使用场景参考

4.6 典型使用场景参考 下面是Redis适用的一些场景: 1. 取最新 N 个数据的操作 比如典型的取你网站的最新文章,通过下面方式,我们可以将最新的 5000条评论的ID放在Redis的List集合中,并将超出集合部分从数据库获取. 使用LPUSH latest.comments命令,向 list集合中插入数据 插入完成后再用 LTRIM latest.comments 0 5000 命令使其永远只保存最近5000个 ID 然后我们在客户端获取某一页评论时可以用下面的逻辑 FUNCTION

Data IDE:盘活数据,让数据发挥价值的一体化在线开发运维平台

阿里云大数据开发平台(Data IDE)是一款集数据开发.数据管理.离线调度.在线运维和数据集成工具为一体的在线大数据开发运维平台,它不仅能够解决上图中各种问题,还可以为用户节省很多的精力和资金. Data IDE的初衷,是为了帮助阿里云的客户.创业者.数据从业者,让他们能够更好的盘活自己的数据,让数据发挥价值而不是成为负担. 因此Data IDE通过数据开发.离线调度.数据管理.数据集成为用户提供一个开箱即用的b/s架构的开发IDE和在线运维平台,并且提供高安全保障的多租户模型确保用户的数据安