展开讨论

经验与复盘经验摘录 · 机器翻译

在我看来,安全应该是一条最容易的路径

… 在我看来,安全应该是一条最容易的路径。如果它不是,那么这就是安全人员的错;不是终端用户的错。我曾供职于一家安全政策极其糟糕的公司,这几乎完全阻止了所有生产力。你可以看出谁违反了政策,因为他们完成了自己的目标。如果政策难以遵循,那么制定政策是没有意义的。

源讨论微软员工在安全疏忽中泄露了内部密码原帖 110 条评论 · 导入时统计
8

社区评论 0

还没有社区评论,来聊聊你的看法。

原讨论中的回复 8

仅展示本次导入中包含的直接回复。中文为机器翻译,可查看英文原文。

KA

让做正确的事情变得容易。你还需要出色的监控,因为不管多容易,总有人会做其他事情。 有很多人和团队只是想要一个按钮来运行他们的构建。这不难。给他们一个CI/CD系统,他们就会使用它。 问题在于那些想要使用奇怪、完全不同的构建流程的人,这些流程由十五个串在一起的shell脚本和从随机远程服务器下载任意内容组成,因为他们喜欢工程它。他们会坚持要一个空白的云租户,因为没有任何构建系统能满足他们的需求。CI/CD团队不会认真对待这种情况,也永远不会真正支持它。安全团队根本不可能有足够的人手来扩展CI/CD服务的主要功能。 可能是数据团队,他们决定想要对大量数量的数据进行挖掘…

完整原文
CO

> 是因为某个市场人员设置了一个AWS实例,把整个用户数据库都放了进去,并进行了一些数据挖掘 这到底是什么**。这严重违反了GDPR,你应该因此被解雇。 > 只是为了提高生产力 如果你在使用私有和敏感数据,这几乎应该被禁止。你只能使用一个模拟数据库进行开发,即使泄露也没关系。在完成测试后,再使用实际数据。 但那些该死的截止日期......

完整原文
AB

说得很对。作为安全人员,我公司里的市场和数据工程团队让我夜不能寐。 他们本质上渴望使用公司最珍贵的数据。他们想要无限制地访问,并且想要把整个数据仓库中一些公司最敏感的客户信息分享给其他人。而当涉及到正确地保护这些数据时,他们往往没有软件团队那样的工程能力。

完整原文
DE

> 很多次,安全措施有太多障碍,人们为了提高生产力不得不绕过它们。 我的经历就是这样。我们有个人按照所有政策设置了一个安全实例。然后他们调到了公司另一个部门,我开始每隔几周就收到发给副总裁的电子邮件违规通知,因为他们没有进行某种确认。问题是只有用户才能处理,而自动化系统没有指导如何解决这个问题或停止警报。这种情况持续了几个月才被解决。

完整原文
AC

我也相信,对于像这样愚蠢的行为,实际上存在一种不真正解雇员工的文化。 一个错误是一回事,但疏忽是另一回事。 除此之外,任何允许客户数据在这种情况下被自由访问和使用的人也应当被解雇。 开始裁掉那些工作做得不好的人,以腾出空间给那些可能能够正确完成工作的人。

完整原文
AR

> 安全必须是最容易的路径。如果不是,那就是安全人员的错;不是终端用户的错。 你说的有道理,但你责怪的是错误的人群。安全人员很少(如果有的话)是创建你所使用的工具和工具的安全功能的同一批人。在大多数情况下,作为安全工程师,我对“让安全更容易使用”是无能为力的;在这方面,我唯一能做的就是放松我们的安全要求,使我们的系统更不安全,而这也不是你想要的。 在我看来,问题更多在于在开发产品时,安全(以及安全的易用性)仍然没有被视为一个重要的功能(如果它甚至被视为一个功能,而不是产品经理必须处理的烦人的成本)。 在我们的应用安全小组中,我们实际上确实有要求,任何新产品的开发必须…

完整原文
BU

最容易的路径总是危险的,因为更容易避免做正确的事。更容易制造没有安全带的汽车。更容易避免对药物进行质量控制。更容易在油漆中加入铅。不知怎么的,计算领域还没有意识到它可能实际上需要一些专业知识。你会让任何随机的人驾驶飞机吗?当然不会。为什么我们让不合格的人编写软件?

完整原文
JO

> 我怀疑拥有某种安全的内部云设置会有帮助。 它必须是安全且功能完善的,否则人们会使用Office365或Google文档或Dropbox。 现在我想到了AI工具。目前还没有自托管的解决方案,那么泄露会是什么样子呢?

完整原文
在 Hacker News 阅读

尊重不同观点,分享具体经验。

登录后即可发帖、评论、转发和引用。