如果我一直在组织的安全工程师一职，那么我肯定会制定一项政策，只允许使用公司计算机。这确实是有道理的，不仅可以保护公司数据，而且还可以保护员工的责任。初级开发人员，我是说中高级开发人员）可能会在他的工作计算机上使用：
17个数据库引擎；
20个Docker容器；
10个测试虚拟机（比方说使用类似
qemu的东西）。这是在启动和启动后（启动成功存活了几年的启动公司）中非常普遍的情况。此外，该开发人员每周都会更换他的docker容器和虚拟机，因为他可能正在测试新技术。
要求该开发人员每次都请安全工程师来安装新软件是完全可以的。不切实际的。此外，由于一家公司将拥有不止一个这样的开发人员，因此，为每个人使用典型的公司管理的计算机都会带来一些缺点：
维护例如六个这样的开发人员的计算机是一个完整的过程。
那些开发人员的经理会非常生气，因为他的团队在50％的工作时间里正在等待安全工程师。
另一方面，允许开发人员自由使用机器是危险的：一个恶意docker容器或虚拟机，您就有了内部人员。我什至会说这些开发人员的计算机比普通用户（例如，具有电子表格软件的经理）的计算机更危险。
您如何为有能力的开发人员制定明智的政策？
以下是我想到的（或在过去看到的）其他一些解决方案，其中大多数都非常糟糕：
禁止从开发机访问Internet：
您需要访问Internet才能阅读文档；
您需要访问存储库，这些存储库通常位于Internet。
给开发人员两台计算机，一台用于Internet，一台用于开发计算机：
关于生产力下降的投诉：键入
Alt+2获取浏览器的速度比切换到另一台计算机的速度快； 存储库访问很麻烦：在一个地方下载然后复制到另一个地方。
鼓励开发人员规避安全性并建立基于USB的连接在两台计算机之间进行操作，因此他可以在一台计算机上工作（看到多次发生）。
将开发移至服务器（即不在台式机上进行开发） ：
这只是使同一个问题更深层次了，现在流氓容器在服务器上了。
比允许开发人员在自己的计算机上完成自己喜欢的事情更糟。
必须有更好的方法。
#1 楼
分开的开发和生产通常的做法是为开发人员在其工作站上提供本地admin / root权限。但是，开发人员应该只能访问开发环境，而不能访问实时数据。有权访问生产环境的系统管理员应该拥有更多受控制的工作站。理想情况下，系统管理工作站应该没有Internet访问权限，尽管这种访问实践上很少见。
我看到的一个变化是，开发人员拥有固定的公司架构，但可以在其中进行所需的任何操作虚拟机。但是，这对开发人员来说很烦人，因为VM降低了性能，并且安全性并不是那么好。因此，更常见的是，开发人员仅拥有对自己工作站的完全访问权限。
评论
我们使用并推荐一种使用所谓的PAW（特权访问工作站）或SAW（安全访问工作站）的方法。需要访问产品的用户可以使用一个工作站/笔记本电脑来日常使用和工作，而使用第二个锁定工作站/笔记本电脑来进行日常使用和工作。生产访问。
– Xander
16年8月30日在17:21
@Xander-因此，您是这种“实践中罕见”方法的真实示例。对你好！我能问一下你在哪个部门吗？我在政府供应商和航空航天业中经常看到这种情况。
–paj28
16年8月30日在18:45
@ paj28我在Microsoft工作。是的，我们不仅教书，而且在这里也已完全实施它。 :-)
– Xander
16年8月30日在18:51
我想知道。如果开发工作与sysadmin工作由同一个人执行（在启动中的另一种常见情况），该怎么办。我猜每个开发人员都应该获得一个PAW和一个SAW。
–grochmal
16年8月31日在2:18
@JonathanPullano：没有实际的方法可以防止坚定的开发人员放弃源代码。您将必须切断所有互联网访问，甚至执行X射线身体搜索（从内到外），以防止驱动器被偷运。您将不得不禁止所有打印-并观看垃圾桶等。接下来，您需要禁止所有拍照方式。这意味着没有电话，照相机等，同时也使用摄像机来主动监视每个人的活动。这将创建一个很少有开发人员愿意工作的环境。
–NotMe
16年9月2日在20:56
#2 楼
所以这个答案是从开发者的角度出发的。记在脑子里。首先，在我自己的计算机上没有“本地管理员”权限，这表明我应该在其他地方找工作。如果每次需要更新（或测试）新的依赖项或工具时都要征求许可，几乎不可能编写代码，摆弄东西并维护工具链。因此，这是我需要的权限级别。请记住，可以这么说，我通常在梯子上很高。
通过我的本地计算机进行全面而完整的管理
对所有开发和测试硬件进行全面而完整的管理
对生产服务器具有一定级别的管理员访问权限（这可以棘手的我不需要或不想要所有东西，但是我需要足够的诊断和修复生产中出现的问题，以及足够实际部署代码（假设我是必须监督代码部署的人）。访问随着时间的推移而发展，但从日志文件开始。
那么少了，您就可以找到新的开发人员。
这就是说，涉及很多风险因此，我通常建议的是一个单独的网络，将所有开发人员的“东西”放在自己的网络中，自己的广告，自己的文件托管，自己的所有东西，并且永远不要让它与生产网络交谈（但是，请务必将其发布到互联网上）
是的，这意味着重复的硬件（或VPS），但是无论如何您都需要进行测试。是的，这意味着有点升级或管理时的矿石开销，但再次需要进行测试。您还需要一个位置来查看“如果升级AD服务器，X软件会发生什么？”看一下，您已经准备好用于这种测试的整个测试机器网络。
我已经成功实施了（在一个优秀的IT团队的帮助下），它是适用于所有开发人员“资料”的单独VLAN，以及单个VPS主机，开发人员可以完全访问它并进行所需的处理。在该主机上是一台由IT部门设置为看起来像公司的AD服务器的较小版本的AD服务器。然后是一组文档和准则，例如关于Web服务器应运行什么的内容。什么DNS服务器应该运行，什么xyz服务器应该运行。然后，“开发”的一部分就是安装和配置供我们使用的VPS。该VLAN上的所有内容都与生产完全隔离，并被视为公司外部。最后，为我们确实需要访问的资产（如电子邮件）创建了一组“打孔”。通常，这就像我们在外部一样进行处理，并且这些工具的列表很小。
评论
抱歉，您不能具有“对生产服务器的某些级别的管理员访问权限”。我要带给您的最好的是，您与我一起上WebEx（等等）或在我的办公桌前冲浪，然后告诉我您想要什么，然后我把它交给您。开发人员无法接触质量检查或生产服务器。您向我们的管理员提供代码，然后将其部署到质量检查部门，然后让测试人员在进行生产变更之前彻底解决问题。如果我让开发人员接触我的QA或Prod服务器之一，他可能会做出我无法复制的未记录的更改。
– Monty Harder
16年8月31日在17:00
之所以将其扩展到QA，是因为QA环境必须尽可能接近于Prod环境，以便在Dev中可以正常工作但在Prod中失效的任何硬编码ASS | U | ME-tions在QA中首先失效这样我就可以告诉您修复该问题，然后再将其提交给Prod ..
– Monty Harder
16年8月31日在17:04
蒙蒂的理念是保持原始生产环境的关键。他使用的关键词是“复制”-很多时候，开发人员（我认识开发人员：十年来我一直受开发困扰，虽然我偶尔会复发，但我正在慢慢接受这种治疗，尽管我偶尔会复发），会发现它已经坏掉并修复了。是的，他们解决了！但是，您如何解决呢？你还打破了什么？嗯尽快进行备份将使我们付出比制定已定义的变更计划更为昂贵的代价。诚然，这些做法仅与“安全性”相关，但是它们仍然非常重要。
– corsiKa
16年8月31日在18:46
@corsiKa我可以认为角色分离是安全问题。仅仅因为开发人员不是恶意攻击者，并不意味着他不能以与该攻击者相同（或更糟）的规模破坏我的生产服务器。中心点在于，它可以实现从开发人员到管理员的真正知识转移。他不能“只是知道该怎么办”；他必须以书面形式记录下来，以便我们团队中的任何成员都可以阅读“该做什么”。
– Monty Harder
16年8月31日在20:52
我相信PCI-DSS规范说开发人员无法访问生产。我们有一个单独的团队来访问生产并将更改提交回代码库。如果您在PCI-DSS环境中（例如，处理信用卡付款），则可能无法获得产品访问权限。
–lsd
16年9月1日在11:52
#3 楼
从开发人员的角度来看：您的工作是防止更改（已知的bug和漏洞比未知的要好，对吗？），但我的是更改事物。这使我们陷入僵局。我的工作是创建/更改事物。如果您的政策阻止了这种情况，那么就像其他障碍一样，我的工作的一部分就是找到解决该问题的方法。
您认为更大的危险是您授予的开发人员访问他完成工作所需的事物，还是通过学习如何规避所有防御措施而获得访问权限的人？为什么当您应该一起工作时，您的公司为什么要付钱给您和您的开发人员在这场战争中相互抗衡呢？
简单的答案是，使开发人员可以访问他们需要做的工作。与他们交谈。在少数情况下（无尘室进行反向工程会产生重大法律后果，或处理绝密机密的政府数据），您需要更复杂的政策。但在大多数情况下，这没什么大不了的。如果您发动战争并使您的开发人员成为敌人，那么他们将离开或变得比您与他们合作更加危险。
明智的措施包括不允许在开发型便携式计算机上转储生产数据库（仅测试数据库）虚假数据）。这样，如果笔记本电脑被盗，则不会丢失任何机密数据。但是，如果开发人员需要调试东西，他们仍然需要在受控环境中某个地方访问生产数据库的副本。
限制Internet访问是荒谬的。您可能还需要所有开发人员用羽毛笔和墨水在纸上编写代码。
与开发人员进行交谈，找到一种方法，在保持维护的同时为他们提供完成工作所需的一切保证重要数据安全所需的安全性。详细信息将取决于您的公司以及正在处理的数据。但这不太可能需要严厉的措施。
评论
除了业务定义您的角色并根据其需求和目标限制您的工具。如果他们要您使用笔和纸，那就是他们的要求。
– schroeder♦
16年9月1日在6:25
@schroeder-如果您想找另一份工作，那是您的电话。
–超级照明
16年9月1日在10:33
@schroeder是的。企业有权拥有自己想要的愚蠢程度，但是愚蠢的企业除了愚蠢的开发人员和大量损坏的软件外，别无所求。
– jpmc26
16 Sep 1'在23:24
如果笔记本电脑被盗，是否应该对磁盘进行加密？
–安迪
16年3月3日在1:08
@Andy是的，磁盘加密绝对是另一种明智的措施。
–雷
16-9-5'3:29
#4 楼
安全工程师不维护计算机，这是服务台要做的。在您的情况下，您将要求他安装三个工具：hypervisor
数据库软件
从那里他可以添加并尽可能多地删除用于开发的机器（不需要秒工程师干预）。关于您的“流氓容器”。通常，您不将容器部署到另一台服务器，而是部署docker文件，这些文件从代码存储库中提取代码或下载经过签名的已编译代码的二进制文件（甚至更安全）。
就流氓而言，我只能想象攻击者获得了访问权并添加了更多代码。这就是为什么您需要在SDLC的每个步骤中都嵌入安全性，以确保在将所有代码推上前至少要由另一位开发人员检查或检查所有代码。此外，您还可以集成代码扫描器以自动扫描可疑或易受攻击的代码存根。
第三点实际上取决于。像Riot Games这样的公司正是这样做的。他们发现限制聪明人将导致这些人规避控制。因此，他们决定使用简单的规则和有效的意识培训来确保将安全性放在首位，并赋予他们充分的管理特权。他们分发了一些小卡片，上面写着他们应该注意和注意的事项。
评论
我必须说，我真的很喜欢提供培训而不是锁定计算机的想法。优秀的开发人员对技术很感兴趣，而对安全威胁如何影响其计算机的良好培训可能只是吸引他们的兴趣的正确选择。棘手的部分是如何构建此培训，它肯定不能与提供给公司其他部门的培训相同。
–grochmal
16年8月31日，1：12
您对Riot Games的评论有引用吗？我怀疑会在他们的工程博客中
–丹
16年8月31日在11:15
签名的容器二进制文件？哈哈，我想知道实际上有多少人这样做。我敢打赌，大多数容器都涉及通过纯文本HTTP从随机第三方网站下载shell脚本，以设置某种新型的node.js混乱。
–马蒂（Matti Virkkunen）
16年8月31日在11:22
他们在Brucon发表的@DanPantry演讲的一部分
–卢卡斯·考夫曼（Lucas Kauffman）
16年8月31日在13:02
@MattiVirkkunen更好，从SO复制/粘贴。
– jpmc26
16/09/1在23:20
#5 楼
我们为开发人员提供在其计算机上的管理员访问权限，并让他们知道规则是什么。大多数运行Linux，但我们在Windows上也有一些开发人员。他们都知道将文档，设计等存储在我们的文件共享中（具有更具体的权限），并将其源代码推送到我们的Git服务器。他们还知道我不会花很多钱是时候解决他们的操作系统的问题了。如果他们的计算机出现故障，我们通常会擦拭它并重新安装操作系统。常见的应用程序和设置是通过Puppet自动安装的，剩下的事情他们自己来做。他们中的大多数人都有一个包含点文件（其环境的设置和首选项）的Git存储库。
在这种情况下，他们失去的时间对于他们中的大多数来说是足够的动力。他们喜欢完成工作，而不是花时间去修复操作系统。如果他们因为重要的工作只存储在本地而丢失了重要的工作，那么他们将遭到同事和老板的皱眉。
我们不会阻止任何网站或应用程序（基于DNS的反恶意软件除外）过滤器），但对于诸如非法软件之类的事情有一些公司政策规则。大多数情况下，我们都依靠同伴的压力。在Facebook上度过时光的人效率低下，持续时间不长。我们的许多政策都是建立在荣誉制度的基础上的，而且效果很好。
评论
我希望更多的人对他们的开发人员有如此大的信心，因为信心是两方面的关系。当然，这需要一个非常好的招聘流程，您根本无法负担不起无能的开发人员。再说一次，您应该始终以只聘请合格的开发人员为目标。
–grochmal
16年9月1日在22:11
#6 楼
这从根本上取决于上下文。考虑以下两个设置，我在野外都遇到了这两个设置：开发人员在自己拥有或拥有完全访问权限的机器上工作，甚至包括安装自己的操作系统系统。他们如何编写应用程序没有任何限制。只要将它们连接到网络（包括VPN），他们就可以通过SSH访问生产系统。
所有开发都在一个有空隙的开发实验室中完成，不允许开发人员将电子设备带入其中。所有计算机均已预安装所有允许的软件。可部署的工件通过物理介质安全地传递给另一个负责部署的团队。
这两种设置都适合于上下文-考虑到组织面临的威胁和项目的需求。
这里有一个基本的权衡。从第一种可能性转向第二种可能性都会降低生产率。对应用程序有任何控制权的任何人都处于受信任的位置。您不信任他们做的任何事情，要么是您要么必须做，要么创建一个移交过程供他人去做。您不能在不降低生产力的情况下撤消信任。
#7 楼
这取决于您要开发的软件类型和组织的规模。对于小公司中单个Rockstar开发人员的工作站，我会使用执行级安全例外。风险（包括IT人员，管理人员和开发人员的烦恼）必须加以讨论，但最终，如果摇滚明星不能如愿以偿，他可能会搬到另一家公司。这些人不容忍摩擦，如果遇到摩擦，他们可以轻松找到更多有趣的工作场所。
比超级工作站更典型的场景是拥有一个开发集群，由运营来管理生活由于VM的故障，将通过IDS / IPS监视环境，并且（在开发群集上）Internet访问受到限制，但可以根据需要打开。例如，对于“文档...”，将与您的开发工作相关的每个技术来源都列入白名单没有错。开发人员无论如何都不会随意插入代码。他们需要记录其来源并验证怪异的许可证。
如果您能引起摇滚明星的注意，他可以帮助将要求推向运营和执行人员，并设计集群和流程，并对开发进行教育需要帮助的团队。
如果有预算，并且开发人员不愿意……那么恕我直言，您不是在与摇滚明星打交道，但歌剧女主角和他们的抱怨应该一直延续到那个时候。高管风险标志。
困难的部分变成管理机器的寿命，并确保开发人员的想法不会变成“类似操作的”开发人员-生产系统。但这比开发人员工作站上的VM容易得多。
评论
“将与您的开发工作相关的每个技术来源都列入白名单没错” ...您将花费所有时间将网站添加到白名单中，直到开发人员决定寻找一个摩擦较小的地方。
–卢卡斯Trzesniewski
16年8月31日在14:19
给您的rockstar一个单独的管理员帐户，该帐户仅用于管理他的工作站。这样，它就与他用来浏览SE的帐户隔离了（上帝知道其他哪些网站，其中一些网站可能携带恶意软件）。
– Monty Harder
16年8月31日在17:06
@LucasTrzesniewski-如果开发人员不必费心去记录他们的代码源，我很高兴看到他们继续前进。与我合作过的优秀开发人员倾向于更喜欢知道他们的同龄人没有从带有可疑历史和未发布许可证的随机git仓库中获取信息。顺便说一句，我在这里谈论的是开发平台，而不是他们的工作站。
– mgjk
16年8月31日在21:01
话虽这么说，开发人员往往会为任何不重要的项目使用大量的库，（重要的是）在选择最终要使用的库之前，他们必须尝试更多的库。我全都明确定义和审查了代码依赖关系，但是根据情况访问开发资源将是主要的PITA，并且会阻碍开发周期。
–卢卡斯Trzesniewski
16年8月31日在23:46
“开发人员通常不使用对这些机器的GUI访问权限”这仅适用于Linux世界。
– jpmc26
16 Sep 2 '16 at 0:03
#8 楼
这个问题提出了许多有趣的问题和挑战。作为从事开发人员很多年，然后进入安全领域的人，我
可以理解
响应和评论中表达的许多论点和观点。不幸的是，没有一个明确的答案，因为
正确的解决方案取决于上下文，风险暴露和组织的风险承受力。
您无法衡量安全性绝对每当您遇到
安全专家时，总是无所事事，并坚持执行特定政策，无论其他情况如何，这都是没有经验或没有能力的。安全工程师的作用是促进业务流程，而不是阻碍业务流程，并确保根据相关的安全风险来制定业务决策。优秀的安全工程师会知道，任何阻止员工工作的策略都将不可避免地失败，因为员工会找到解决该策略的方法。这些
解决方法通常会更加不安全。安全经理的职责是了解组织内的各种角色并确保
以一种不仅支持角色所需的方式，而且鼓励他们的方式来组织政策。好的做法，劝阻坏的做法。这可能非常困难，尤其是在大型组织中。同时，开发人员
和组织中的其他人员也需要认识到他们可能没有所有相关信息，以了解为什么需要某些政策的原因。
经常会解决这些问题的方法是通过交流。我
经常让开发人员感到沮丧，因为他们认为一些毫无意义的政策正在阻碍他们。一旦我们坐下来讨论这个问题，通常会发生许多事情；
开发人员要么误解了政策，要么已经读懂了政策
是不正确的，并且给人以政策可避免的印象
它不会阻止的事情。这通常会导致对策略进行审查，以提高清晰度
安全工程师意识到合法的业务需求，而这种需求必须以维持足够安全性的方式得到满足
控件。这很可能导致对该政策的审查。
开发人员会意识到一些其他需求或风险，这些需求或风险最初并不是显而易见的。这通常会导致开发人员确定
替代解决方案以满足他们的要求
识别出一个问题，而该问题不能以各方公认的风险承受能力范围内的任何一种方式得到满足。组织（即可接受的风险水平）。这种情况通常会导致该问题升级为执行级别的决策。
这样做的困难将取决于组织的规模和结构。一旦做出决定，开发人员和安全工程师
都需要在执行人员设置的参数内工作，以找到他们可以找到的最佳解决方案。
许多对政策产生批评的回应，这些政策对他们的生产力水平产生不利影响。尽管任何开发人员都应该提出此类问题，但归根结底，他们要么必须接受高管做出的任何决定，要么要寻找替代雇主。假设您
知道更好，或者您有忽略该政策的特殊权利是自大的
对您和您的雇主都是危险的。如果您确信自己是对的，那么您应该能够说服管理层。如果您不能做到，或者您的
不如您想像的那样，缺乏足够的沟通技巧来表达令人信服的论点，不具备所有信息或正在为不称职的员工工作雇主。在行业工作了35年之后，尽管Dilbert
可能会引起您的思考，但后者并不像您期望的那样普遍。该领域最常见的冲突根源是由于沟通不畅和缺乏信息。
开发人员之间的一个常见失败（也是我所犯的错误）是
过多地专注于您的特定任务或目标，以至于错过了更大的图片，而团队负责人，经理和执行人员也需要进行管理
。赋予开发人员很多自由和信任的环境，虽然这导致了高水平的生产力，但是又导致了其他问题-关键开发人员离开或病了很长一段时间，没有人
其他人无法上班，因为它们全都在他们独特配置和托管的台式机上，或者试图调试很难解决的难题
由于缺乏标准的设置/配置而被复制，或者由于开发人员意外离开某些正在运行且缺乏标准安全控制措施的服务而导致的
安全漏洞。
专注于特定领域或技术的开发人员也不能保证在其他所有方面的专业知识。在安全性和/或环境管理方面，我曾与之合作过的一些最优秀的开发人员表现最差。这可能部分是由于对特定问题的关注
，而更可能仅仅是由于能力。我们谁都没有能力
我们需要认识到有时候，重要的是
向那些擅长我们不擅长的领域的人致敬。
不断变化的环境
政策限制在桌面上可以执行的操作的主要原因之一是由于以下基本假设：本地计算机中的桌面与
网络外部的台式机相比，
网络具有更高的信任度。传统上，它们位于防火墙和其他外围防御之内，并且可以移动访问信息资源。这意味着它们构成更高的风险，因此需要更多的安全控制措施。
限制策略/实践的其他原因包括环境的标准化，
可以减少支持成本并提高一致性（尤其是当有更多应用程序依赖于平台/操作系统时，这一点尤其重要
-记住
需要AtiveX或特定版本的
IE）的所有可怕应用程序。
虚拟机和容器，云服务以及商品IT的增长
网络容量的增加导致许多更改
，这很可能使此线程中提出的许多问题不相关。特别是，向零信任网络的过渡可能会发生重大变化。在零信任网络中，与网络外部的设备相比，网络内部的设备不被视为具有任何特殊的附加信任级别。由于您拥有正确的IP地址，因此无法简单地访问资源
。相反，信任更多地基于用户和设备信息的组合。决定您可以访问的内容的策略由您的凭据和所连接的设备决定。该设备所在的位置无关紧要。这也是一个模型，它
与BYOD的增长和移动性的增加非常吻合
劳动力和基于门槛/能力而不是地理位置的雇用员工的需求不断增长。
一旦删除了与设备关联的“信任”级别，您就不会
要求您控制可应用于设备的内容。您可能仍然需要
设备来支持特定的配置文件-例如，如果他们的设备运行的是Windows XP等，则可能拒绝允许任何人访问您的资源。但是，您不必担心设备。同样，您将
直接在设备上做的工作不多。在某种程度上，该设备将更像瘦客户端。您将使用远程托管的VM和容器。这
本身并不能解决所有问题，并且可能只是将其中的一些
从本地桌面移至远程VM或容器。但是，一旦您将其与各种DevOps样式编排结合起来，开发人员可能需要增强特权的许多原因就被删除了。例如，您可能
不需要访问生产系统。新代码的推广将
通过精心设计的持续集成系统来处理，并且当您需要调试问题时，将为您提供VM或容器，该VM或容器是
确切的克隆生产系统。
这些更改都不能神奇地解决任何问题，但它们可以提供更广泛的，更灵活的工具和解决方案，而其复杂性可能更低。降低复杂性将使安全管理更加轻松。轻松的安全管理将减少对工作职责的无意或不必要的限制或障碍。但是，归根结底，关键的要求是
对所有尺寸的识别并不适合所有尺寸。一切都必须在组织的范围内进行评估。
将组织的需求放在首位的意愿。
双向通讯良好。
各方愿意努力寻求双方都可以接受的解决方案，并且
各方愿意妥协的解决方案
愿意在系统内工作并调整您的工作流程或首选的
工作方式符合组织要求的事物
评论
而且，我们甚至不开始讨论在物联网设备存在时零信任网络的重要性。 “鸣叫的杯子”通常构造得很糟，以至于破坏了任何明智的安全措施。我只是想知道如何管理用户和设备信息以授予对系统的访问权限。被动指纹识别（可能是openBSD的PF的伪装？）
–grochmal
16年9月2日在16:01
是的，物联网是一个问题，并且肯定会加速向零信任网络的发展。挑战是用户身份验证-我们如何使它既可用又安全，并避免“蜜罐”中的宝贵数据。几乎可以肯定某种生物识别输入。就像电力存储是太阳能一样，Authn是ICT的圣杯。一旦我们破解了这些坚果，很多事情都会改变。
– Tim X
2016年9月4日，1：14
#9 楼
我也是一名开发人员，这是我的看法：问题比您想象的还要严重
没有汤匙
开发与软件无关。开发是指制造或改善产品，服务和流程。软件是重要的工具，但不是唯一的工具。优秀的开发人员将在更广泛的意义上定义流程，以了解要创建哪些软件组件以及要建议的人力，后勤，风险管理流程。开发依赖于未实施的人力，后勤和书面流程的软件系统没有任何意义。
开发没有规则，因为开发正在定义规则。这就是使开发成为最不安全的环境的原因。
工程过程
有一些公司主张在自上而下的过程中将业务与技术分开。这实际上很受欢迎，因为这表明没有技术知识的商人应该居于首位。懒惰的人喜欢。但是在工程中，自上而下的设计根本行不通。费曼（1985）在分析挑战者爆炸事件的总统委员会上发表了一篇不错的文章。从根本上讲，自上而下的工程设计最终会使公司破产。而且我的市场经验进一步加强了这种理解。
挑战者爆炸就是一个很好的例子。美国国家航空航天局的经理在调查委员会的镜头上作证说，他们开发了一种橡胶，该材料在冰点以下60度下仍能保持柔韧性。由一位专员进行的一项简单的高中物理实验（将橡胶成分放入钳中压入冰水中）与这一事实相矛盾。这是一个很好的例子，因为这种橡胶成分需要柔软，以使助推器不爆炸。由于这样做需要夏季温度，因此增压器仅在夏季工作。单个组件的特征定义了整个产品的可见特征，这是非常有限的。
工程应该自下而上进行，因为您需要了解每个组件的局限性和弱点，以简化流程来减轻它们。缓解过程通常不是软件，并且会影响产品的成本。这意味着各个组件的特征和局限性将定义产品，服务和过程的特征。
从上至下的过程从根本上被打破了。在纸上采用这种哲学的许多公司仍然在市场上取得成功。但是，当您深入研究他们最大的，最成功的项目时，就会发现它们是在公司正常规则范围之外进行的。拥有深厚的工程知识和对市场有远见的人得到非正式授权后，就会获得最大的成功。由于这是非正式的，因此管理层认为自上而下的过程是有效的。他们认为所有其他团队都不称职。对最初的项目大纲离开“顶级阶段”时被完全忽略，并且没有描述所构建的产品，服务和过程的事实视而不见。
您的经理可以定义您在月底之前设计一个远程传输设备，因为他得出结论认为，这将使旅行业务获得高额利润……但那不会实现。自上而下的项目就是这样，设定了技术上不合理的期望。
不要误会我的意思，很高兴能从多个角度看到问题。自下而上，自上而下，SWOT等等对于分析是健康的，但是真正的工程工作是自下而上的。没有技术可行性就没有真正的目标。
开发安全性
我们要记住，软件开发人员将定期更改公司软件，并且他们可以：更改屏幕上显示的内容可以向所有人（包括他们自己）发送自动电子邮件，也可以打开后门来完成他们想要的事情。这意味着聘请为开发人员的罪犯会对公司造成重大损害。
最糟糕的是，许多公司没有强制执行源代码存储库证明，然后聘请的开发人员可以提供与给定的来源不同。这使犯罪的开发人员可以劫持公司系统，如果不雇用他们，系统很快就会停止工作。
对我来说，开发安全性应集中在：
源代码版本控制：确保将所需的源代码和第三方组件存储在安全的位置。
战略分工：初级和临时开发人员必须对源代码和数据具有有限的访问权限。他们只需要访问要更改的组件即可避免初级开发人员能够理解所有系统的内部工作原理并能够利用它们。
信任核心开发人员：高级/核心开发人员将必须了解所有内容，可以访问所有内容，计划和分发任务以及诊断严重问题。这个核心必须在开发和生产中都可以访问整个事物。他们是您制定安全策略的合作伙伴。我们必须接受核心开发者拥有公司的所有权。我的老老板曾经说过：“我们很幸运，卢卡斯站在我们这边，另一方面他会摧毁我们”。核心开发人员如果愿意的话，可能会造成很大的损失，并且没有防火墙和生产控制措施可以防止这种情况发生。
通过防火墙隔离环境：将您的开发网络与测试网络，您的网络分开生产网络。在一家公司中，我定义了网络10.1。作为发展，10.2。作为测试和10.3。作为生产。 10.2和10.3网络仅通过公司CVS接收代码，并根据admin命令自动构建它们。尽管这是一家小型初创公司，并且我在生产和开发团队中工作，但我还是做了一些官僚机构来避免自己的错误（开发人员可以是您最好的盟友）。我还通过网络更改了终端颜色：在生产服务器中连接时，终端背景为红色，测试为黄色，开发为绿色。由于我所有的服务器都使用相同的配置，因此如果打开提示，很容易将它们混淆。以我的经验，大多数问题来自未经测试的软件和新软件的安装。明确说明：我认为您在哪里是一项强大的安全功能。它与访问无关，但它是安全性。
雇用熟练的测试开发人员：测试的关键方面是拥有大量对公司面临的问题有意义的良好模拟数据。蒙特卡洛（Monte-Carlo）模拟非常适合生成对其他开发人员有意义的大型数据集，并且可以带来更强大，更灵活的软件和流程。对我而言，没有“生产”失败，开发人员总是要怪罪。必须编写维护任务和意外事件。软件必须具有弹性。
源代码审查：请人们在接受修改之前先审查源代码。所有项目都应在源代码控制上进行分支，并应检查合并。源代码审查仅应考虑恶意软件检测，访问升级，访问配置文件以及对源代码含义和作用的良好解释。代码的质量将通过测试而不是源代码审查来保证。您可以在大多数开源项目中看到这一点。
测试策略测试更多是一种企业文化，而不是框架。一些公司采用市场框架，进行一些测试，但是其代码质量很差。发生这种情况是因为您需要能够进行有意义的测试的人员。实际上，开发必须成为测试驱动的。我不知道其他安全的开发方式。令人奇怪的是，人类，采购和咨询服务也都必须经过测试。供应商经常声称他们的产品性能完美无缺，但我还没有发现完美的产品。
如果不加以监控，政策是毫无意义的。我知道一家公司有一个官僚机构，即每个数据库表都应该在属性级别上有描述。 95％的属性被描述为“ $ {table name}的$ {attribute name}”。它没有解释属性的真正含义，值可能包含的内容和内容。
适当的补偿和工作环境。要拥有技能和个性上都不错的开发人员，您必须有良好的薪酬政策。金钱固然重要，但还远远不够。您还需要具有远见/稳定性，真实的认识和良好的工作环境。例如，您可以选择一个较小的城市，而在纽约，该开发办公室中人们居住在小型公寓中，而相同的报酬可以使房屋更大，更靠近工作地点。更大的计算机，良好的实验室对于技术爱好者来说也是一个加分。
数据安全许多活动需要敏感的生产数据，应在专门的实验室中进行访问。除非您的信息是公开的或不敏感的，否则最好的策略可能是将实验室放置在物理访问受控的良好社区中。只允许将一些模拟数据放在不敏感的个人笔记本电脑和组件上。那是可能的。例如，我为一家公司开发了45亿条记录的访问量很大的数据存档。我当时在家中工作，因此完全不使用公司数据。当我提交代码时，它在第一次尝试中就按预期工作了。除了硬件故障和生产环境的迁移，我们在10年内具有100％的可用性。开发人员随身携带源代码的风险不相关。这个特殊的系统花了我3个月的时间进行开发，这次大部分时间是为了了解组件的性能限制。现在，这就是我内心的知识。即使没有源代码，我也可以在大约一周的时间内重新开发此解决方案。
强大的日志对于了解每个人所做的事情都很重要。最好的办法是由框架生成日志，记录短时间的详细屏幕，更长的访问和活动时间，甚至更长的公司日志。每当访问屏幕（包括屏幕设计）时，我的关键系统都会记录日志。一些关键资源应该由触发器本身记录在数据库本身上，并且应该标记关键表或资源以进行源代码审核。
-手工进行日志筛选很困难。了解如何在日志上进行过滤以查看关键事件。一种非常有用的过滤器是使投诉报告与用户访问权限和活动交叉。如果您有足够的日志，则会发现巧合。例如：在问题1之前用户1总是登录。
关于不访问生产系统
要求开发人员不访问生产系统的规则是因为用户在那里，以避免开发人员提交代码以显示给他/她自己的用户特权信息。我认为这是一个非常非常弱的安全措施，很容易在源代码审核中检测到。有几种简单的方法可以避免这种情况：
开发人员加一名低薪雇员；
给自己发送一封电子邮件；
在系统中打开后门。 br />
寻找后门，访问升级和恶意软件的源代码审核似乎更有效率。它允许您在测试漏洞利用程序时将其识别出来并予以解雇。当然，熟练的开发人员可以将漏洞隐藏起来，因此使用清晰明了的语言和变量名很重要。仅在需要特殊性能或混淆性的应用程序的书面证明中使用奇怪的解决方案。例如，1 << 4与1 * 16相同。仅当语言本身没有进行此优化并且发生性能瓶颈是性能瓶颈时，这才有意义。出于同样的原因，太多的符号语言也是不好的。源代码应该是任何怪胎都能读取的。
问题比您想象的要严重
开发人员可能造成的最容易和最严重的损害与工具安装无关。即使开发环境是托管的，如果公司没有强大的防火墙，源代码存储库，仅基于源代码存储库进行构建并进行代码审查，也不会有太大变化。
评论
编写该代码需要付出很大的努力（+1表示努力），但我需要指出，您很幸运，我精通葡萄牙语。我一遍又一遍地看到这种一致性错误，我可能会修复大多数错误。答案一开始很好，但随后在源代码方面走下坡路，最后有所改善。但是，最重要的是，您忘记了人们使用公司提供的计算机的主要问题：如果开发人员得到了木马该怎么办？在这种情况下，10.1、10.2、10.3子网肯定不会保护您免受有能力的攻击者的侵害。
–grochmal
16-09-22在2:11
谢谢。这也发生在葡萄牙语中，我的初稿在某些地方有些混乱，因为我写得太快了。感谢您的修改。
–卢卡斯
16-09-22在8:46
除IP的第二个数字外，两个网络的网络分隔应完全相同。可预测性允许更好的防火墙规则和更好的脚本来移动事物。如果将sort与Linux服务器和策略结合使用，可以避免测试和生产网络中的木马，从而避免使用外部组件。
–卢卡斯
16-09-22在8:49
特洛伊木马程序不是特定于开发的风险，如果开发人员可以访问您的应用程序的屏幕，则特洛伊木马程序将具有此风险。与任何其他用户相同。为了减轻木马的风险，我亲自在虚拟机中进行组件检测。
–卢卡斯
16-09-22在9:07
#10 楼
作为顾问，我曾在许多不同的公司工作过，其中只有两家没有授予开发人员对其机器的管理员访问权限；一个是小公司，另一个是非常大的公司。在这个小公司，我请求管理员访问权限，解释了大约60秒的原因，并立即得到了它。
在一家大公司，我请求管理员访问权限，并被告知，即使他们同意我应该拥有该权限，但公司政策禁止该权限，因此他们无法更改。因此，有一个IT人员过来在我的机器上创建了一个本地管理员帐户，并让我为其设置了密码。从那时起，无论何时我需要成为管理员，我都可以以本地管理员身份登录到计算机，或者仅使用runas来启动Visual Studio或需要与管理员用户（例如IIS）一起运行的任何服务/应用程序。这并不比选择内置的“以管理员身份运行”更糟糕。只是稍微慢一点，尽管幸运的是它不会经常出现。
评论
这显然是专为白痴规则制定者设计的“法律文书”解决方案。好消息是您可以完成工作，坏消息是，如果白痴获得线索，就会有人被解雇。
– ddyer
16年9月1日，下午3:33
我的工作很短暂，您根本没有管理员访问计算机的权限。要安装任何软件，您必须先放入一张票，希望它已在其批准的清单上，或者如果没有，请以某种方式对其进行辩解，然后等待其安全团队远程登录并为您安装。
–lsd
16年9月1日在11:57
我听说有这样一种环境的谣言，即devops中的标准过程是立即购买更多RAM，然后在其内部P2V原始系统映像。内部机器仅用于公司电子邮件；其他一切都在外部机器上。他们在小隔间之间为自己的LAN铺设电缆。
–约书亚
16年9月2日在21:43
#11 楼
请记住，这里更大的安全问题是IP的渗透，而不是恶意软件。希望您已经拥有IDS / IPS来处理后者，这应该不会成为问题。只要具备以下条件，您就可以摆脱对开发设备的管理员访问权限：
反eDLP（网络，USB等）
IDS / IPS
MITM NTLM认证的公司代理，您可以通过它强制所有连接并监视DLP违规情况
拒绝桌面上的所有虚拟化软件。如果需要VM，请从托管云中配置一个VM，从而使所有VM都可以使用上述工具运行相同的过时的标准化映像。
在网络级别阻止对外部软件存储库的访问（这会削弱pip，git ，maven，apt，yast，zypper以及其他所有内容）
在网络级别阻止访问github，codeplex和所有其他150个代码共享站点
在网络级别阻止访问所有9000+文件共享站点网络级别
阻止访问P2P ...等...
我的雇主做了所有这些以及更多工作。无论如何，很多同事最终在下班后在家中用自己的个人设备进行开发，然后通过侧通道将其扔回到篱笆上，以避开受损的基础设施。就我个人而言，我宁愿度过一个晚上喝酒，梦见服用过量的狗用镇静剂，也不愿浪费额外的20小时未做的事情来做会令我反感被解雇的事情。工程）一门科学。在无菌条件下进行科学实验，以控制变量。在残缺的环境中进行开发是不科学的，在这种环境中，由于环境因素而无法达到预期的效果。我可以从经验中告诉您，您不会从中获得精心设计的软件...内部开发的所有内容都被破坏了，这导致了第三方解决方案上的更多支出。
开发人员绝对必须要有一个无菌的环境才能开发。我无法告诉您各种安全控件将gremlins引入开发和生产体系结构的次数了-因此，托管的，无菌的，基于云的开发环境确实是唯一的方法。走。 “它在实验室工作，问题一定是外部的。”
您只需要确保让他们进行调配的VM不会过时，就需要自动执行OpenStack或AWS的调配流程，因此开发人员无需等待几天即可满足扩展需求。将它们全部集中管理可以为您提供大量的审计控制权，并且坦率地说，使开发人员的性能比他们自己使用设备要好。
评论
废话，那些雇主的规定是疯狂的。
–丹
16年9月2日在19:35
@Dan Pantry是的，别开玩笑...我希望我能说这是因为我像NSA一样在很酷的地方工作，但是不，我们只是在生锈的创新边缘。
–伊凡
16年4月4日在14:14
#12 楼
我是选择＃2的粉丝：拥有单独的计算机。允许具有专有信息的公司计算机进行互联网连接为黑客打开了大门。它还使员工更容易出于非法目的窃取公司数据。
如果员工必须使用特殊的机器来访问Internet资源，它将为数据的渗透和渗透创建受控路径。非常安全。同样，它也阻止员工像我现在那样闲着浏览网页或浪费时间在互联网论坛上。
评论
老实说，我发现没有给开发人员自己的计算机提供完全的管理员访问权限是完全不合逻辑的，而且大多数大公司似乎都明白这一点。我当然不会为没有的公司工作。只是不要雇用完全没有能力的人。那是我所听说过的最糟糕的安全工程师。听起来更像是疯狂的锡箔纸。我希望这只是一个极端的例子，现在还没有真正发生。实际上，以可用性为代价的安全不是安全。阻碍业务发展，阻碍人才发展并不是安全。查看CIA三合会，尤其是“可访问性”部分。
祝您好运，愿意在无法管理的计算机上工作。
容器和VM的巨大不受控制的空间必须完成任何开发；这是完全控制主机的合理选择。包含网页浏览通常可以。开发人员希望完全控制机器的地方是，在容器中运行IDE或在VM中运行速度太慢的情况。只将白名单二进制文件执行和打开端口的想法与开发人员需要的相反。在那儿，对控制的需求（通常与安全性混淆）造成了不可能的情况。
在发现该公司不允许开发人员访问互联网后，我拒绝了一份工作。当您一天中的大部分时间都是“研究为什么x会执行或不执行y”时，没有互联网是一个荒谬的障碍。