Amazon AWS is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.
It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.
This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.
Requirements and Challenges
Identity and Access Management Requirements
- Secure Access to the Amazon Root Account
The experts at amazon will be the first to tell you.
Don't use your Amazon root account as the means for regular administration. Don't share it. Look at this account only for break-glass scenarios
- Use Role-Based Access Control
This is another best practice documented by our friends at Amazon.
However, what's not very obvious is that you may want to do this from a common identity source. We don't want AWS to become an additional identity silo, this promotes duplication of effort and increases the likelyhood of exposure.
Organizational policy and risk assessment will require that policy is enforced centrally and depending on data clasification, there will be attestation needs. We need to be able to report who can perform which actions in the Amazon Console.
The role-based access control model needs not only apply to the Amazon console, but to the systems that are running in the IaaS cloud; you must be able to enforce the least access, least privilege, separation of duties and be able to attest or report which users has access to each system, what can they do with privilege and how they got granted the access.
- Use Multifactor Authentication
Amazon recommends strong controls for the root account; however, We argue that we have to apply stronger controls like being able to access the console only from on-premises in some cases (or example, when using the amazon root account) and apply MFA across the board in cases where the user is accessing externally.
The challenge for many organizations is that Multi-factor Authentication is also a fragmented capability, because most IAM vendors until recently have not considered it a must have.
There’s also the issue of modern use cases. Physical OTP tokens are expensive and don’t provide enough information for the modern enterprise. We need more significant information and workflow-like capabilities and to be able to use that same scheme in other use cases, like when elevating to use your privileges.
Since all roads point to the mobile device in your pocket, this means strong Enterprise Mobile capabilities to secure that device as well.
Finally, wouldn't it be better to go beyond MFA and be able to apply stronger policies? Perhaps only allow access to the AWS console only from your on-premises infrastructure? Provide authentication policies that request MFA before the user's password?
- Apply a Security Policy
This is another item in the Amazon checklist, they specificaly talk about passwords.
However, organizations with mature security practices understand that using a common identity store (like Active Directory, used in 90%+ organizations) also allows for consolidating policy definition and enforcement.
Amazon systems can be integrated to the common directory for the purposes of Access Control.
This step requires the extension of your corporate IT directory to the IaaS infrastructure. This can be accomplished several ways (in the case of AD). A resource domain with a 1-way trust and a site-to-site VPN, an RODC, etc.
The benefits of this approach include less IT fragmentation and complexity, and consolidation of processes and tools, however, the solution should be ready for automation and orchestration; one of the principles of public/private clouds is elasticity, this means that if machines are spun up or down, the tools should have simple ways to satisfy these needs.
- Session Management
Systems in the Amazon cloud should be accessed in a way that allows for accountability, centralization of access and enforcement of strong policies. Although it's possible to access directly via Amazon, this tends to open itself to challenges with sessions and key management.
- Password Management
Finally, we need to eliminate the human challenge of shared credentials. Accounts like root, Administrator and any others should be brokered with a repeatable process: request/approve-check-out-check-in-rotate.
The Proposed Solution
Part III - See the Solution in Action
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.