安全性是一個龐大和具有挑戰性的主題，但每個負責服務器端工作的人都應當知道基本步驟。Cameron 概括了一些使您的用戶帳戶清潔和安全的方法。
安全性是一大難題。它不會一成不變，而且很難知道它需要擴展到多大程度：如果您不小心的話，當您的老板真正想要的是不讓看門人看到他的年度預算時，您才會最終相信他需要理解安全性的好處。
不管在計算安全性的所有方面跟上潮流是多麼的具有挑戰性，畢竟有幾個領域已經足夠成熟，值得進行系統地學習。對於任何使用 Linux 服務器的人，我建議他學習的第一個領域是帳戶管理。
注意您的用戶
在第一批專門介紹 Linux 管理和編程的書籍中，許多都包括關於“用戶管理”或“帳戶管理”的一章。它們的意思非常明確：如何為使用您主機的人設置和維護計算帳戶和組關系。
在那時，“使用”必然意味著“登錄”。帳戶管理的全部工作就是：使用諸如 useradd 、 chsh 等命令來配置 Linux 帳戶，以便於由同部門開發人員占多數的用戶群使用。/etc/passwd 及其 API 是 Linux 專家的關注重點。 //本文來自電腦軟硬件應用網www.45it.com轉載請注明
那個時代早已成為過去，我對大多數服務器提出的第一個建議就是清除 /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 和數據庫等）的 — 建立明確而詳細的過程。盡管將這些納入可執行文件是很好的規定，但並不完全有必要。重要的是過程是可理解的和明確的。不小心的帳戶創建和刪除 總是會留下安全性漏洞。應當與人力資源、客戶支持或其它相關部門一起檢查您的過程。如果不親身體驗替代方案，那麼您很難認識到這是多麼關鍵。
當您沒有為添加和除去用戶帳號編寫過程時，則總會出現這樣的結果：假定新員工周一報到，那麼他或她可能到周五仍不能訪問其公司文件。或者，某人辭職，在假日聚會做了道別，可在二月份開始時仍在檢索特殊用途的公司資產。
帳戶自動化一個附帶的好處是它鼓勵更加徹底的驗證。如果開發人員沒有用不同特性配置帳戶的方便辦法，他們很可能不會執行那些預計將使配置發生變化的應用程序。
我最近親身經歷了這樣的情況。我因某個緊急事件而被召來，當時實現小組實際上在“正確地”允許經理查看雇員業績評審 — 甚至包括那些不屬於他們管理的雇員！盡管聽起來可笑，但這是典型的安全性問題。它甚至在分析和設計評審期間被指出過幾次。雖然每次都向決策者反映了這個問題，但由於它是巨大而混亂的問題集合的一部分，所以它每次都在沒有明確決議的情況下被忽略。
只有當一位支持專家最終建立起一個一般實例的具體示例（在該示例中有幾位經理，每位經理有多份雇員報告）時，錯誤才得到應有的注意。不要臨陣磨槍；要定期對所有種類的用戶帳戶的配置進行徹底的測試。
保持警覺
安全性最困難的部分，至少對我們中的許多人而言，是如何避免犯錯。安全性是屬於“最弱環節”事件之一，一個漏洞就可以使您目前的所有投資（不管多麼龐大、計劃多麼周詳）一錢不值。要做好安全性工作，您必須對原本不會考慮的事情保持警覺。
美國政府網站常常是證明那種挑戰的嚴重程度的最好例子。常在有關“反恐”的安全問題新聞中出現的某聯邦機構維護一個網站，在那裡用戶密碼在用於更改用戶首選項的頁面上公開地顯示。相當多的組織解決頻繁發生的丟失密碼問題的方法是：根據或多或少的公共信息 指定密碼（例如，“您的密碼是您出生地的頭四個字母，加上您出生年份的後兩位數字”）。
如何能避免這樣的災難性錯誤？遺憾的是，幾乎沒有系統的方法能“聰明地”成功實現這樣的抽象目標。但是，在需要采取的有用步驟中，對 RISKS 文摘的研究和嚴格的工程檢查是有用的步驟之一。
RISKS 是 Peter G. Neumann 自 1985 年就一直在編輯的在線時事通訊（請參閱下面的 參考資料）。在思考事情（特別是 Linux 服務器上的安全性）的出錯原因方面，閱讀它是個很好的習慣。Neumann 使該文摘易讀而且有趣，當然偶爾會令人恐怖。
您還應該養成讓其他人試驗您的想法的習慣。您可能認為“軟件檢查”不過是找出開發人員的源代碼中放錯地方的標點符號的一種方法，但它實際上是非常有趣和高效的實踐。特別是，檢查是對需求文檔、網站和所有其它產品的同行評審進行組織的極佳方法。請進行檢查。通過別人的眼睛查看您的工作。您將有可能了解許多關於您服務器的安全或不安全性的信息。
