实用Linux系统之安全性事项
安全性是一个庞大和具有挑战性的主题，但每个负责服Linux务器端工作的人都应当知道基本步骤。Cameron 概括了一些使您的用户帐户清洁和安全的方法。
Linux安全性是一大难题。它不会一成不变，而且很难知道它需要扩展到多大程度：如果您不小心的话，当您的老板真正想要的是不让看门人看到他的年度预算时，您才会最终相信他需要理解安全性的好处。
不管在计算安全性的所有方面跟上潮流是多么的具有挑战性，毕竟有几个领域已经足够成熟，值得进行系统地学习。对于任何使用 Linux 服务器的人，我建议他学习的第一个领域是帐户管理。
注意您的用户
在第一批专门介绍 Linux 管理和编程的书籍中，许多都包括关于“用户管理”或“帐户管理”的一章。它们的意思非常明确：怎么样为使用您主机的人设置和维护计算帐户和组关系。
在那时，“使用”必然意味着“登录”。帐户管理的全部工作就是：使用诸如 useradd 、 chsh 等命令来配置 Linux 帐户，以便于由同部门开发人员占多数的用户群使用。/etc/passwd 及其 API 是 Linux 专家的关注重点。
那个时代早已成为过去，我对大多数服务器提出的第一个建议就是清除 /etc/passwd 的大部分内容。我的意思是：由于历史原因，大多数电子邮件服务器、Web 服务器、文件服务器等，都用 /etc/passwd 管理它们的用户访问。我认为这通常都是一个错误。在早些时候，当可能有十几个或二十几个工程师共享一台高端工作站时，这是一种明智方式。但是，当一台电子邮件服务器可能要处理几万名用户（他们中的大多数只是把计算当成和饮水器或电话系统一样的公用设施）的邮箱时，传统的 /etc/passwd 方式就是一个错误。
依靠 /etc/passwd 当然是可能的。它经历了足够的修补和调整，足以应付令人惊讶的工作量。但不是必须如此。如果您将用户帐户移到专门的数据存储，如 LDAP（轻量级目录访问协议）甚至 RDBMS（关系数据库管理系统）数据存储，您可以在可伸缩性、安全性和维护方面受益。将 /etc/passwd 限制为只供少数真正需要登录的开发人员和管理员使用。
这一实践在安全性方面有很大好处，因为服务（电子邮件和 Web 等）用户的忙闲度与开发人员的完全不同。一旦您已设置好了一台新的服务器，它的 /etc/passwd 就不应经常更改。监控它是否被更新 — 特别是篡改 — 是一项简单的任务。但是，如果您正在运行一个较大的服务器，那么每天都会有几个新的和过期的电子邮件帐户更改。需要将这些帐户从 /etc/passwd 赋予的更大的访问权隔离开来。
构建一个替代性帐户数据存储是一个认真而严肃的建议吗？的确如此，这确实令人惊讶。为了使由无需登录的用户占多数的非常庞大的 /etc/passwds 正常工作，过去几年已经投入了大量的工作。如果您确实决定编写自己的帐户认证，并且依靠象 sendmail 这样的传统电子邮件程序，那么您很可能发现自己正在为 SMTP、POP3 和 IMAP4 服务器编写更改。
那些障碍常常使开发人员倾向于使用现成的软件。我的习惯是使用别人已编写好而我可以重用的解决方案。但是，与这些业界使用的服务器不同的一点在于：我还是常常需要定制它们 — 例如，设置特殊消息目录、日志记录信息或使用记帐。对我来说最重要的一点是使安全性考虑事项模块化。我希望能够将开发人员和管理员帐户与最终用户服务完全分开地加以管理。通过将后者从 /etc/passwd 清除，我可以很容易地锁定一方而不会影响另一方。
使策略自动化
和将开发人员帐户与用户服务分开几乎同样重要的是使策略自动化。为创建和删除帐户 — 既包括开发人员（/etc/passwd）的也包括最终用户（电子邮件、Web 和数据库等）的 — 建立明确而详细的过程。尽管将这些纳入可执行文件是很好的规定，但并不完全有必要。重要的是过程是可理解的和明确的。不小心的帐户创建和删除 总是会留下安全性漏洞。应当与人力资源、客户支持或其它相关部门一起检查您的过程。如果不亲身体验替代方案，那么您很难认识到这是多么关键。
当您没有为添加和除去用户帐号编写过程时，则总会出现这样的结果：假定新员工周一报到，那么他或她可能到周五仍不能访问其公司文件。或者，某人辞职，在假日聚会做了道别，可在二月份开始时仍在检索特殊用途的公司资产。
帐户自动化一个附带的好处是它鼓励更加彻底的验证。如果开发人员没有用不同特性配置帐户的方便办法，他们很可能不会执行那些预计将使配置发生变化的应用程序。
我最近亲身经历了这样的情况。我因某个紧急事件而被召来，当时实现小组实际上在“正确地”允许经理查看雇员业绩评审 — 甚至包括那些不属于他们管理的雇员！尽管听起来可笑，但这是典型的安全性问题。它甚至在分析和设计评审期间被指出过几次。虽然每次都向决策者反映了这个问题，但由于它是巨大而混乱的问题集合的一部分，所以它每次都在没有明确决议的情况下被忽略。
只有当一位支持专家最终建立起一个一般实例的具体示例（在该示例中有几位经理，每位经理有多份雇员报告）时，错误才得到应有的注意。不要临阵磨枪；要定期对所有种类的用户帐户的配置进行彻底的测试。