问题描述
是否有记录有关如何为银行和其他不希望用户从可能不安全的位置下载二进制文件的计算机运行自定义 Ubuntu 的流程和方法(从安装到日常使用)？
那么 apt-get 的更新等是否仅从少数几个受信任的互联网或内联网位置发生？
更新：在第一个答案之后添加了这个。这些用户是支持人员、系统新手用户和银行软件开发人员……因此其中一些需要 sudo 权限。有没有现成的方法来监视他们，以便快速捕获任何异常(例如添加源列表)，但其他操作(例如从已知存储库安装东西)则不报告。
目标是确保安全，使用 Ubuntu 或其风格，让开发人员和其他 sudo 用户尽可能提高工作效率。\n(并减少对 Windows 和 Mac 电脑的依赖)
.2. IT 人员可以向用户指定策略，这样他们就无法执行某些操作，例如共享文件夹，即使是 sudo 用户？有完整的解决方案吗？
最佳方法
在您的内部网中设置您自己的 debian repository proxy。
Customize the ubuntu installation 以便您的 debian 存储库代理是 /etc/apt/sources.list 中唯一的条目。
瞧：您可以完全控制客户端上安装的软件(只要没有用户拥有超级用户权限)。
\\n
Update : Added this after the first answer. These users are support, novice users of systems and developers of the bank software… so some of them need sudo privileges. Is there a ready way to monitor them so that any exceptions are caught quickly (like adding the sources list) but other actions like installing stuff from known repos goes unreported.
\\n
在您的自定义安装中，您可以修改 /etc/sudoers 文件，以便允许您的用户运行 sudo apt update 和 sudo apt install，但不允许运行以 apt 开头的其他命令。当然，您还必须限制 sudo bash (或任何其他 shell)。
次佳方法
到目前为止，在我见过的几乎每家商店中，开发人员都可以完全访问开发机器，但这些机器只能访问互联网和源代码存储库。
源代码在受信任的机器(开发人员通常没有或不需要管理权限)上进行签入和编译，然后从那里部署到可以访问内部网络的测试系统。
这些机器是由开发人员还是单独的测试团队使用取决于您的组织 – 但通常，受信任和不受信任的机器之间的边界是在单独的机器之间，它们之间的接口是可验证的(例如源代码提交)。
前台员工永远没有管理权限。当我们将 Solitaire 部署到所有这些机器上时，关于此政策的投诉几乎停止了。
第三种方法
这是一个非常好的问题，但是回答起来却很难。
首先，@Timothy Truckle 有一个很好的起点。您可以运行自己的 apt repo，您的安全团队可以验证每个软件包。但这只是一个开始。
接下来，您需要实现组。您希望用户能够做他们需要做的事情，而无需太多支持帮助。但在银行业，您确实希望锁定一切。事实上，在许多公司结构中，您希望锁定一切。因此，在任何级别授予普通用户 sudo 权限可能都不合适。
您可能会做的是进行设置，使得某些群体不需要提升权限即可完成其工作。
再次强调，在大多数公司环境中，安装软件可能会让你被解雇，所以这是不行的。如果你需要软件，你可以调用 IT 部门，他们会帮你安装，或者有一个申请链或类似的东西。
理想情况下，您永远不需要普通员工安装任何东西，也不需要提升权限。
现在对于开发人员来说，问题有点不同。也许他们需要安装，也许他们需要 sudo。但他们的机器在 “danger network” 上，永远无法直接连接到关键系统。
IT/支持人员将需要 sudo。但您可以通过命令、流程(文书工作)或其他方式限制 sudo 访问。关于“双眼原则”及其实施方法，可能会有整本书的内容。但审计日志是存在的，可以配置以满足大多数需求。
那么，回到你的问题。Timothy Truckle 的回答 100% 正确，但你的问题的前提是错误的。保护 Linux 操作系统更多的是关于选择特定用例所需的设置，而不是关于如何保护事物的一般想法。