面向银行开发人员的 Ubuntu

tgk*_*rog 16 package-management security software-installation system-installation

对于不希望用户从可能不安全的位置下载二进制文件的银行和其他企业,是否记录了有关如何运行自定义 Ubuntu 计算机(从安装到日常使用)的流程和方法?

那么 apt-get、update 等只能从几个受信任的 Internet 或 Intranet 位置发生?

更新:在第一个答案之后添加了这个。这些用户是支持人员、系统新手用户和银行软件开发人员……所以他们中的一些人需要 sudo 权限。是否有现成的方法来监视它们,以便快速捕获任何异常(例如添加源列表),但其他操作(例如从已知存储库安装内容)未报告。

目标是确保安全,使用 Ubuntu 或一种风格,让开发人员和其他 sudo 用户尽可能高效。(并减少对Windows和Mac电脑的依赖)

.2. IT 人员可以向用户指定策略,这样他们就不能执行某些操作,例如共享文件夹,即使 sudo 用户?一个完整的解决方案?

小智 18

在您的内部网中设置您自己的debian 存储库代理

自定义 ubuntu 安装,以便您的 debian 存储库代理是/etc/apt/sources.list.

等等:您可以完全控制客户端上安装的软件(只要没有用户具有超级用户权限)。


更新:在第一个答案之后添加了这个。这些用户是支持人员、系统新手用户和银行软件开发人员……所以他们中的一些人需要 sudo 权限。是否有现成的方法来监视它们,以便快速捕获任何异常(例如添加源列表),但其他操作(例如从已知存储库安装内容)未报告。

在您的自定义安装中,您可以修改该/etc/sudoers文件,以便您的用户可以运行sudo apt updatesudo apt install但不允许其他以apt. 当然,您还必须限制sudo bash(或任何其他外壳)。

  • @TimothyTruckle 如果你真的有 10000 个客户,那么你周围还有一个像 Puppet 这样的管理系统,将它添加到所有客户中是微不足道的 (5认同)
  • 只要没有用户拥有超级用户权限,他们无论如何都无法安装任何软件。 (3认同)

Sim*_*ter 7

到目前为止,在我见过的几乎所有商店中,开发人员都可以完全访问开发机器,但这些机器只能访问 Internet 和源代码存储库。

源代码在受信任的机器上签入和编译(开发人员通常没有或不需要管理权限),然后从那里部署到可以访问内部网络的测试系统。

这些机器是由开发人员使用还是由单独的测试团队使用取决于您的组织——但通常受信任和不受信任机器之间的界限是在单独的机器之间,它们之间的接口是可验证的(例如源代码提交)。

前台员工永远没有管理权限。当我们将 Solitaire 部署到所有这些机器时,对这项政策的抱怨几乎停止了。


cot*_*eyr 6

这是一个很好的问题,但它的答案非常困难。

首先,为了开始,@Timothy Truckle 有一个很好的起点。您将运行自己的 apt 存储库,您的安全团队可以在其中验证每个包。但这只是开始。

接下来,您可能想要实现组。您的目标是让用户能够在没有太多支持帮助的情况下做他们需要做的事情。但是在银行业,您确实希望将事情锁定。事实上,在许多公司结构中,您都希望将事情锁定。因此,在任何级别授予普通用户 sudo 权限可能已经过时了。

您可能会做的是设置一些东西,以便某些组不需要提升权限来完成他们的工作。

同样,在大多数公司环境中,安装软件可能会让你被解雇,所以这是不可以的。如果您需要软件,您可以联系 IT,他们会为您完成,或者有一个申请链或类似的东西。

理想情况下,您永远不需要普通员工来安装任何东西,也不需要提升权限。

现在对于开发人员来说,问题有点不同。也许他们需要安装,也许他们需要 sudo。但是他们的盒子在“危险网络”上,永远不能直接连接到关键系统。

IT/支持人员将需要 sudo。但是您可以通过命令、流程(文书工作)或其他方式来限制 sudo 访问。关于“两眼原则”以及如何实施之类的事情,可以有很多卷。但是审计日志存在并且可以配置以满足大多数需求。

那么,回到你的问题。Timothy Truckle 的回答是 100% 正确的,但您的问题的前提是关闭的。保护 Linux 操作系统更多是关于选择特定用例所需的设置,而不是关于如何保护事物的一般想法。