编辑#2 2015 年 7 月 23 日：寻找一个新的答案，可以识别以下设置中遗漏的重要安全项目，或者可以给出理由相信所有内容都已涵盖。
编辑#3 2015 年 7 月 29 日：我特别在寻找可能的错误配置，例如无意中允许某些可能被利用来规避安全限制的东西，或者更糟的是，留下一些敞开的东西。
这是多站点/共享主机设置，我们希望使用共享的 Apache 实例（即在一个用户帐户下运行），但以每个网站的用户身份运行 PHP/CGI，以确保没有站点可以访问其他站点的文件，我们希望确保没有遗漏任何内容（例如，如果我们不知道符号链接攻击预防）。
以下是我目前所掌握的信息：
- 确保 PHP 脚本作为网站的 Linux 用户帐户和组运行，并且受到限制（例如使用 CageFS）或至少使用 Linux 文件系统权限进行适当限制。
- 使用 suexec 确保 CGI 脚本不能以 Apache 用户身份运行。
- 如果需要服务器端包含支持（例如在 shtml 文件中），则使用它
Options IncludesNOEXEC来防止 CGI 在您不希望它运行的时候运行（但如果使用 suexec，这不应该是一个大问题）。 - 设置符号链接攻击保护，以便黑客无法欺骗 Apache 以纯文本形式提供其他网站的文件并泄露可利用的信息（如数据库密码）。
- 配置
AllowOverride/AllowOverrideList以仅允许黑客无法利用的任何指令。我认为如果上述事项正确完成，这个问题就不那么令人担心了。
如果 MPM ITK 速度不是太慢并且不以 root 身份运行，我会使用它，但我们特别想使用共享 Apache，但要确保它是安全的。
我发现http://httpd.apache.org/docs/2.4/misc/security_tips.html，但它对这一主题的论述并不全面。
如果了解有帮助，我们计划将 CloudLinux 与 CageFS 和 mod_lsapi 一起使用。
还有什么事情需要确保做或者了解吗？
2015 年 7 月 20 日编辑：人们已经提交了一些不错的替代解决方案，这些解决方案总体上很有价值，但请注意，这个问题仅针对共享 Apache 设置的安全性。具体来说，是否存在上述未涵盖的内容，可能导致一个站点访问另一个站点的文件或以某种方式危害其他站点？
谢谢！
答案1
我完全同意您目前提出的观点。
几年前，我曾经运行过这样的多用户设置，并且基本上发现了相同的权衡：mod_php 速度快（部分原因是所有内容都在同一进程内运行），而 suexec 速度慢但安全（因为每个请求都会分叉一个新进程）。我选择了 suexec，因为需要用户隔离。
目前，您可以考虑第三种选择：为每个用户提供自己的 php-fpm 守护进程。这是否可行取决于用户数量，因为每个用户都必须使用其用户帐户获取至少一个 php-fpm 进程（然后守护进程使用类似 prefork 的机制来扩展请求，因此进程数量及其内存使用量可能是限制因素）。您还需要一些自动配置生成，但这应该可以通过一些 shell 脚本来实现。
我没有在大型环境中使用过该方法，但恕我直言，这是一个很好的解决方案，可以提供良好的 PHP 网站性能，同时仍在流程级别隔离用户。
答案2
到目前为止，您所做的一切似乎都经过深思熟虑。我唯一能看出的问题是，大多数漏洞都试图以某种方式获得 root 访问权限。因此，即使每个站点及其相应的进程和脚本都得到正确控制，并且所有内容都有自己的用户和权限，拥有 root 权限的黑客也不会在意，他们只会避开您设置的一切。
我的建议是使用某种 VM 软件（VMware、VirtualBox、Qemu 等）为每个站点提供自己的 OS jail。这样，作为系统管理员，您就不必担心单个站点受到攻击。如果黑客通过利用站点 VM 上的 php（或任何其他软件）获得 root 权限，只需暂停 VM 并稍后对其进行剖析、应用修复或回滚到未损坏状态。这还允许站点管理员将特定软件或安全设置应用于其特定站点环境（这可能会破坏另一个站点）。
唯一的限制就是你的硬件，但只要有一台像样的服务器和正确的内核扩展，这个问题就很容易解决了。我已经在 Linode 上成功运行了这种类型的设置，前提是主机和客户机都非常非常稀疏。如果你熟悉命令行（我想你熟悉），那么你就不会遇到任何问题。
这种设置减少了您必须监控的攻击媒介的数量，并允许您专注于主机安全并逐个站点地处理其他所有问题。
答案3
我建议让每个站点在其自己的 Apache 守护程序下运行，并 chrooting Apache。所有系统 php 函数都将失败，因为 Apache chroot 环境将无法访问 /bin/sh。这也意味着 php 的 mail() 函数也将不起作用，但如果您使用外部邮件提供商从您的电子邮件应用程序发送邮件，那么这对您来说应该不是问题。
答案4
已经有很多很好的技术答案（请看这里：https://security.stackexchange.com/q/77/52572和保护 LAMP 服务器的技巧），但我还是想在这里提一下关于安全性的一个重要观点（从另一个角度来说）：安全是一个过程我相信你已经考虑过这个问题，但我仍然希望有时重新考虑一下（对其他读者也一样）会有所帮助。
例如，在您的问题中，您主要关注技术措施：“这个问题仅针对共享 Apache 设置的安全性。具体来说，在运行共享 Apache 和 PHP 时，是否有任何重要的安全步骤需要采取，但上述列表中没有列出。”
这里以及我提到的其他 2 个问题的几乎所有答案似乎也都是纯技术性的（除了建议保持更新）。从我的角度来看，这可能会给一些读者留下一个误导性的印象，即如果您按照最佳实践配置服务器一次，那么您将永远保持安全。所以请不要忘记我在答案中遗漏的要点：
首先，不要忘记安全是一个过程尤其是“计划-执行-检查-行动”循环，这是许多标准所推荐的，包括 ISO 27001（http://www.isaca.org/Journal/archives/2011/Volume-4/Pages/Planning-for-and-Implementing-ISO27001.aspx）。基本上，这意味着你需要定期修改你的安全措施，更新和测试它们。
定期更新您的系统。这不会有助于抵御利用零日漏洞的针对性攻击，但有助于抵御几乎所有的自动攻击。
监控您的系统。我在回答中确实忽略了这一点。从我的角度来看，尽早收到有关系统问题的通知非常重要。
统计数据显示：“从渗透到被发现的平均时间为 173.5 天”（http://www.triumfant.com/detection.html)、“检测前平均天数为 205 天”（https://www2.fireeye.com/rs/fireye/images/rpt-m-trends-2015.pdf）而我希望这些数字并不是我们大家想要的。
有很多解决方案（包括免费解决方案），不仅可以监控服务状态（如 Nagios），还可以监控入侵检测系统（OSSEC、Snort）和 SIEM 系统（OSSIM、Splunk）。如果太复杂，您至少可以启用“fail2ban”之类的功能和/或将日志转发到单独的 syslog 服务器，并且电子邮件通知关于重要事件。
再次强调，这里最重要的一点不是你选择哪种监控系统，最重要的是，你要根据“计划-执行-检查-行动”周期定期进行监控和修改。
注意漏洞。与监控相同。只需订阅一些漏洞列表，当发现 Apache 或其他对您的设置很重要的服务的某些严重漏洞时，即可收到通知。目标是在下次计划更新之前收到有关出现的最重要的事情的通知。
制定一个计划，以防万一发生事故（并根据“计划-执行-检查-行动”周期定期更新和修改该计划）。如果您对安全配置提出疑问，则意味着系统安全性对您来说很重要。但是，如果您的系统尽管采取了所有安全措施，但仍遭到黑客攻击，该怎么办？再次强调，我这里指的不仅仅是“重新安装操作系统”之类的技术措施：根据适用法律，您应该在哪里报告事故？您是否被允许立即关闭/断开服务器（贵公司需要花费多少费用）？如果主要负责人休假/生病，应该联系谁？
拥有备份、存档和/或替换/复制服务器。安全还意味着服务的可用性。定期检查您的备份/存档/复制，并定期测试恢复程序。
渗透测试？（再次参见“计划-执行-检查-行动”循环：）如果感觉太多，您至少可以尝试一些免费的在线工具，扫描您的网络服务以查找恶意软件和安全问题。