很多企业正试图针对他们雇员所使用的各种云应用和服务来确保用户账户的安全性，其中的原因很合理：越来越多的攻击者通过诸如网络钓鱼攻击和驱动下载等方法将云账户和登陆凭据作为攻击目标，以求获得访问企业数据的权限。虽然企业用户已经非常注意对用户账户的保护，但是如果root账户和管理员账户被攻破，那么所带来对企业的破坏性影响将是更为惊人的。
例如，让我们来看看Code Spaces的例子，这家公司的亚马逊网络服务(AWS)管理门户是在2014年被入侵的。一旦攻击者进行访问，公司的整个基础设施架构就赤裸裸地暴露在攻击者面前，这最终导致了企业的倒闭。那么，企业用户应当如何保护与其环境相关联的特权账户，并实施强大的特权用户管理呢?
在大多数的基础设施即服务(IaaS)云中，存在着若干种形式的管理员访问或root访问。在默认情况下，IaaS环境需要系统创建一个特殊的用户账号作为初始管理员，这个特殊帐户通常仅通过用户名或者带有密码的电子邮件进行身份验证。然后，这个初始管理员账户就可以配置环境并创建新的用户和组。诸如微软公司Active Directory之类的用户目录也可被链接至云访问权限，从而根据企业内部角色向众多的管理员提供云访问权限。很多IaaS系统镜像或模板也都包括了一个默认的用户账户，这个账户拥有相应的特权。在AWS Machine Images中，这个默认的用户账户就是“ec2-user”。
特权用户管理的基本概念
首先，企业组织应当重新审视特权用户管理的核心概念，其中包括了职责分离和最低权限访问模式。很多云供应商都提供了内置的身份验证和访问管理工具，这些工具允许用户组织按照实际需要为每一个用户和工作组创建不同的策略。这就让安全团队能够帮助设计出符合最低特权原则的策略，即根据用户的角色不同而赋予不同用户能够执行其操作所绝对必需的权限。
对于在其应用内部不支持粒度角色和特权模式的云供应商，也许可以通过使用一个身份验证即服务供应商来达到这一目的，这个供应商将在内部凭证存储和云供应商环境之间代理身份认证信息，它同时也可用作一个单点登录门户。
对于访问云环境的所有特权用户账户而言，使用多重因素身份验证方式应当是强制性执行的一项措施，这一强制性措施本来完全可以防止恶意攻击者对Code Spaces控制的初始损害。很多供应商都提供了各种各样不同形式的多重因素访问方法，其中包括了最终用户端点证书、来自领先多重因素解决方案供应商的软硬令牌、以及SMS代码等——虽然这些方法的安全性都不尽相同，但总是聊胜于无的。
在理想情况下，拥有管理员特权的所有用户都应在所有类型云环境中使用一个已获批准的多重因素方法来访问管理控制台和任何其他敏感IT资产或服务。对于大多数企业用户而言，软令牌和证书一定会在实践中被证明是特权用户管理中最可行且最安全的选项。
最后，控制管理员访问和root访问的一个关键方面就是它们都是通过加密密钥的管理与监控来实现的。大多数的管理员账户(尤其是那些默认系统镜像中内置的管理员账号，例如亚马逊实例中的ec2-user)都是需要使用私钥来进行访问的。这些密钥一般都是在创建用户时生成的，或者也可以独立生成密钥，用户应当非常小心地做好密钥管理以防止任何对账户的非法访问，其中尤其是管理员账户或root用户账户。
作为特权用户管理中的一部分，安全与运行团队应当确保密钥在企业内部以及在云的安全性，理想情况下应当将密钥保存在一个硬件安全模块中或者其他专门用于控制加密密钥的高度安全平台中。需要将密钥集成至部署渠道的开发人员还应当使用工程设计的成熟工具来保护这一敏感信息，例如Ansible Vault 或 Chef加密数据包。
为了确保特权用户账户不被滥用，安全团队应当在云环境中收集和监控可用的日志，并使用诸如AWS CloudTrail之类的内置工具或商用日志记录和事件监控工具与服务。
