这背后的原因是操作系统和应用程序所依赖的那些组件可能并且通常确实具有冲突的版本要求,并且迫使应用程序维护其自己的资源使得修补操作系统变得更加容易.此外,它还确保应用程序数据和日志不会填充到基于操作系统的工具所在的位置(例如,这对于httpd尤其重要).
此外,除非存在有效且文档化的技术原因,否则应用程序进程必须以非特权用户身份运行,而不是以root身份运行.我们在Linux中有适当的解决方法,因此Web服务器等进程可以作为非特权用户运行,并接受从特权端口(80和443)转发到他们正在侦听的非特权端口的连接.
透视,我是公司Unix / Linux SA组织的安全专业人员,我与平台技术支持专家密切合作,以维护和执行我上面列出的标准.我的很大一部分职责是审查通过sudo进行特权访问的请求,这些请求是集中管理的.我们的标准Linux是Red Hat,但Ubuntu和CentOS也正在考虑用于云环境.
问题是我们目前正受到来自应用程序团队的请求的轰炸,允许他们(通过sudo)以rpm和yum安装Linux应用程序,因为供应商需要这样做,并且无法提供任何替代方法来安装应用程序.这在很多方面与我们的标准相冲突：
>必须以root权限运行rpm和yum工具.这意味着它们所做的一切都以root身份运行,因此必须经常调整生成的安装,以允许它作为非特权用户运行.
>包通常指定组件必须安装在根卷中,而不是安装在指定的卷下.如果可以指定包树的根,通常供应商坚持认为它保持不变,因为它们只在包中指定的精确环境中进行了测试.
>最后,rpm和yum从系统可用的任何存储库中提取依赖关系,虽然我们要求应用程序将我们的Satellite存储库用于Red Hat提供的任何服务,但是供应商通常会提供自己的存储库,必须包含这些存储库才能使软件正常工作.
我的问题是,如何在这样的环境中指定或限制rpm和yum的使用,以确保不会发生包冲突,并且可以安全地应用系统安全补丁,同时不禁止将这些工具完全用于应用程序软件(到目前为止我们一直在做什么,并发现这是徒劳的练习)？
解决方法
很明显,为什么他们很难合作,所以我不再说了.
至于过时,很明显他们没有考虑现代技术,如虚拟化,Linux功能,容器,SELinux等,所有这些都有助于以更优雅和可用的方式解决相同的安全问题.
举例来说,将httpd绑定到高端口,然后使用iptables将流量重定向到它,而不是简单地让它绑定然后删除权限,就像默认情况下一样,接近偏执并获得几乎没有任何东西.它还使SELinux与httpd一起使用变得复杂,因为httpd SELinux策略的设计没有考虑到这种设置.
以同样的方式,只是盲目地要求软件包将自己填入/ opt或/usr/local就没有任何收获,因为无论软件包安装在何处,RPM都已经保持了所需的分离(除非软件包被破坏,可能就是这种情况)与第三方供应商包,但这样会拒绝安装)并失去标准合规性,可能使相关的SELinux政策无法使用,并造成维护噩梦. Red Hat Software Collections是按照这些方针设计的,虽然它有一些可用性问题,但在处理真正的问题时,building your own packages by this design可能是一个权宜之计.
然而,我看到的最大问题是维护一种“大铁”服务器或服务器,每个人的应用程序并行运行.仅这就引入了自己的安全问题,这可能是这些“安全实践”的起源.此时虚拟化非常成熟,只是将应用程序分离到自己的VM中,例如,与KVM on RHEL 6 or RHEL 7,将eliminate the need为大多数这些“安全实践”.
顺便说一下,由于你几乎肯定会拥有大量的应用程序,creating a private cloud with OpenStack可能是你在中短期内最好的选择.这些将使用RHEL 7主机并运行RHEL 7,6甚至5个客人,因为你可能有一堆仍然活着和踢的人.它还为您提供了一个平台,可以安全地试验新的应用程序和操作系统,以及业务部门,部门等更轻松地分配资源.
如果虚拟化对于某些事情来说太重了,那就转移到容器(例如LXC/Docker on RHEL 7).它们的重量要轻得多,除了应用程序包本身之外几乎都可以剥离,然后用它们自己的文件系统,网络和uid / gid命名空间隔离,有效地将它们从任何其他容器中切除,除非你碰巧在各自的防火墙.将SELinux添加到KVM虚拟机或Linux容器可提供第二层保护,只需单击一下即可打开.
此外,如果您开始向他们提供OpenStack和/或Docker,您的公司将充满开发人员,他们将永远爱你.
简而言之,是时候评估现代Linux发行版及其提供的功能,并根据这些功能重新评估所有安全实践.
在许可方面,红帽现在提供无限制的虚拟化许可证,允许您运行无限制的RHEL虚拟机/容器,当然还有CentOS,它将在99.9％的时间内替代RHEL.所以那里没有任何借口.
