IT運營團隊和安全團隊一直在打仗。數據中心安全標準對使用這些系統的人會產生極大的影響。安全管得太死，會讓管理員們幾乎無法正常工作。

應用和系統程序員需要權限才能對系統進行操控、檢測和修復問題。同時，公司必須防止未經授權的信息流出，包括客戶、員工或其他機密信息。為了維持可用性，企業限制任何人進行隨意的、未經計劃的或惡意的更改。那么，公司在提適當的權限用于技術支持的同時，如何才能兼顧數據保護和可用性?

數據中心身份管理有多種實現方式，包括組登錄ID、應急Id 和備用Id(group logon IDs, firecall IDs and alternate IDs)。讓我們看看每一項安全措施和相關聯的問題。

組登錄ID：一些公司將很高的權限分配到一個功能組，任何屬于組成員的登錄ID均享有該權限。您可以對該組ID進行控制，在分配訪問權限之前要求技術員輸入批準的修改代碼。

這個方案有多個優點。首先，很容易對這些ID執行的每個操作進行記錄和審核。它還可以避免單獨的用戶獲得過多權限，并根據組ID的來實現控制，這意味著任何對系統的更改必須已經經過了深思熟慮、計劃和審查。

應急ID：應急ID和組ID類似，但是應急ID只有有限的應用范圍和使用壽命。一般情況下，一個需要非正常訪問權限的程序員必須被分配或創建一個應急ID。附加的控制條件可能包括一個一次性密碼和一個過期時間，這限制了應急ID的使用期限。

應急ID和組ID一樣可以被嚴格的審核，IT部門可以把各種各樣的控制措施附加于應急ID的獲取過程。此外，應急訪問的控制粒度可以比組ID更細。例如，一個組ID可能允許更新系統數據庫并重新組織數據庫，同時我們可以設置兩個不同的應急ID對應每個不同的功能。

備用ID：備用ID的權限仍然是針對個別用戶的。但備用ID不是在所有時間都具備完全訪問權限，安全團隊移除正常管理ID的高級別權限后，將這些權限轉移分配給備用ID。這將允許技術支持人員使用他們常用的ID監測系統，由于高權限被消除，系統被修改的風險也得以消除。于是，當管理員需要進行任何修改時，反而需要登錄到他或她自己的備用ID。

備用ID比組ID或者應急ID更靈活。它們可以更快速地訪問高級權限;當然，它們更難控制。

關于應急ID和組ID的爭議

應急ID和組DI有幾個共同缺點。第一，雖然可以盡可能地對兩個ID進行嚴格審核，仍然難以避免某些隱蔽的修改操作。例如，IBM的互動系統生產力基金(ISPF)對于更新庫目錄分區數據集(PDS)的操作，只記錄最后一個操作賬戶的ID。在這種情況下，ISPF的記錄存儲的是應急或組的ID，但誰在使用這個ID則無從知曉。

因為有時候公司會在緊急情況下用到緊急ID，此種情況下ID的獲取流程就會成為一個問題。如果獲取一個應急ID花費的時間太長，或者需要太多的文件或級別的批準，本來短時間就能解決的停機可能很容易變得漫長。

組ID也有一個類似的缺陷。想象某一天停電，唯一具備足夠高權限修復故障的ID卻被某人鎖定，而且那個人剛好當天離開了。

這里有幾個兼顧數據中心安全和可用性的最佳實踐：

允許應用程序和系統開發人員監控生產環境。就算所有最近的開發項目都處在自動化狀態，就算你有“自主”系統，仍然有必要對計算機系統進行主動監控，這樣才能實現最高的可用性級別。正確分配的只讀訪問權限肯定不會對可用性造成威脅。

如果三個選項都能實現功能，此時備用ID可能是最好的選擇。備用ID可以被日志記錄——這一點和組和應急ID登錄一樣——系統內總會留下一些可供審計追蹤的痕跡。備用ID讓支持人員在必要的時候可以快速行動。

如果一家公司希望使用應急或組ID，務必先建立完美平衡安全控制和快速實現訪問的流程。此外，部署控制應急ID的軟件應該成為企業的最高可用性目標之一。

一個部門可能要指定幾個可靠的人員，授予生產系統的完全權限，在情況要變得糟糕時能成為一支救場的奇兵。雖然這可能會成為其它控制手段的漏洞，但如果真出現狀況了，它確實會更快地解決問題。

請信任你的技術支持人員。他們也在為企業的成功而盡力，而且和管理者一樣不喜歡停機。