|
应用和系统程序员需要权限才能对系统进行操控、检测和修复问题。同时，公司必须防止未经授权的信息流出，包括客户、员工或其他机密信息。为了维持可用性，企业限制任何人进行随意的、未经计划的或恶意的更改。那么，公司在提适当的权限用于技术支持的同时，如何才能兼顾数据保护和可用性?
数据中心身份管理有多种实现方式，包括组登录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的软件应该成为企业的**可用性目标之一。
一个部门可能要指定几个可靠的人员，授予生产系统的完全权限，在情况要变得糟糕时能成为一支救场的奇兵。虽然这可能会成为其它控制手段的漏洞，但如果真出现状况了，它确实会更快地解决问题。请信任你的技术支持人员。他们也在为企业的成功而尽力，而且和管理者一样不喜欢停机。 |
