Identity and Access
Management for the Cloud
What you need to know about managing access to your clouds
Organizations need to control who has access to which systems and technology within the enterprise. Establishing and maintaining that control efficiently and effectively can be a challenge — and adding cloud technologies to your IT infrastructure adds additional complexity and risk.
One of the biggest challenges in information security is identity and access management (IAM): How do you control who has access to what systems and technology within your enterprise?
Operating systems and applications all have different ways of managing access. As a result, the more applications you use, the more challenging it is to safely and securely manage your users.
This white paper explains the access management challenge, especially as it relates to clouds, and offers best practices for overcoming the challenges involved with managing your users in both public and private clouds.
Access control and the cloud IAM basics
Access control can be divided into two categories:
authentication and authorization.
• Authentication = successfully and accurately identifying users — Authentication has become easier over the past few years, since more operating systems and applications now support technologies such as Active Directory (AD), LDAP and single sign-on/federation.
It is necessary to
control which users
and groups can
do what for every
available action.
• Authorization = mapping the actions that a user is allowed to take — Examples of actions you might want to control include the ability to create other users, remove users, start or stop compute instances, or make changes to different sorts of data.
Authorization presents a larger issue than authentication because most applications aren’t leveraging directory services. Rather, they have their own built-in authorization systems. In the best cases, they can map roles to AD or LDAP groups.
Both authentication and authorization are problematic for large enterprises.
Users can end up in multiple directory servers at the same time, and tracking and managing this situation becomes exponentially more difficult with each new server added to the environment.
IAM in the public cloud
While there are definitely issues with IAM in the enterprise, those issues pale by comparison to those in the public cloud.
With enterprises subscribing to more and more cloud services, successfully managing authentication is becoming increasingly difficult, if not impossible, without some sort of centralized or federated system to manage users’
identities.
Very few cloud providers have support for third-party authentication. Those that do are almost always found in the more traditional SaaS (software as a service) market, such as Salesforce.
com. They are not typically found in the PaaS (platform as a service) or IaaS (infrastructure as a service) markets. There are even fewer options if you eliminate options that are not enterprise-friendly, such as OpenID. The providers that are left invariably support only authentication — not authorization.
Authentication solutions for the cloud Customers who deploy Dell Cloud Manager on-premises have the option to leverage LDAP or AD synchronization.
In all cases, users defined within Cloud Manager can be dynamically created on both Windows and UNIX-based guest virtual machines (VMs) for interactive logins.
Challenges of authorization With most cloud providers, granting any access means granting full access Managing authorization in the
cloud is even harder than managing authentication. One of the benefits of using a public cloud is that it exposes the inner workings of the infrastructure in ways that are usually limited to the staff at a physical data center. This is very powerful because it gives developers, and even regular users, self-service abilities so they can receive the resources they request much more quickly.
Unfortunately, however, most cloud providers don’t limit who can use that functionality. Therefore, once you grant a user access, he or she has access to all infrastructure and applications.
Although this makes access easy, it can be disastrous: Suddenly, you have a company full of sysadmins with the equivalent of root access.
Authorization capabilities differ among cloud providers
Even the cloud providers who do provide authorization tend to do so in a way that is different for each service. For example, Amazon Web Services (AWS) has some very granular access control mechanisms for services such as S3, but when it comes to their flagship product, EC2, it’s an all-or-nothing scenario.
Moreover, what can be controlled with access control rules varies dramatically from one cloud provider to another.
This makes consistent application of authorization even more difficult.
Creating a separate account for each project has serious drawbacks Some companies attempt to solve this lack of authorization by creating separate accounts with their cloud providers for each project. This way
only the relevant developers are allowed access to the cloud account. Anyone with access to the account could still do a lot of damage by mistake, but this limits the scope to just that one project.
This approach works when only a few accounts are being managed, but becomes extremely cumbersome as the number grows. Some companies have hundreds of accounts with the same cloud provider. Managing these accounts without authorization presents a number of challenges:
• Time – Managing the accounts individually becomes a full-time job. It’s even more time-consuming if the provider doesn’t have an option for consolidating all of the billing into one monthly statement.
• User management – Working with a large number of accounts makes it nearly impossible to correctly handle authorization when someone changes roles or leaves the company.
• Reliability – In many companies, some developers have access to more than one account at a time. This is not only a huge headache to manage, but also constantly switching accounts increases the chances of someone making a mistake.
For example, one company let all of its senior developers have access to an account with an external cloud provider. One developer, as part of software testing, provisioned servers and terminated test instances over the course of several days. Late one afternoon, he accidentally terminated several key development databases instead of his test instances. Fortunately for both the developer and the company, those databases were backed up.
Although recovery was relatively simple, all development work was completely halted for several hours until the databases could be recreated.
How authorization should work When you evaluate software and services, it is vital to ensure that there is a way to implement a robust, role- based access control system that allows administrators to create fine-grained
access control lists (ACLs). More specifically, it is necessary to control which users and groups can do what for every available action. Cloud providers are not making this functionality available today, so customers need to either build their own solution or engage with a third-party software product.
Using a proxy between you and the cloud provider
Essentially, what is needed is a proxy between the consumer and the cloud provider that allows you to create and maintain levels of authorization and monitoring far beyond what is currently available from most providers. Once this proxy is in place, it is very easy to log every action users are taking. Having a user action log contributes to overall security, facilitates recovery and helps you pass compliance audits.
Ways to leverage role-based access control
There are various methods for
incorporating role-based access control into public and private clouds. You can use the following methods individually or together to help your organization meet its security requirements:
• User-based – Limit login access to specific users. More specifically, limit admin access for all boxes to just the administrator groups. Further restrict users’ access to only the instance or group of instances that is necessary to perform their job functions. For example, application developers are allowed access only to systems in the application tier, and database administrators (DBAs) are allowed access only to the SQL tier.
• Filters–A well-designed system will allow you to create rules that can be applied not only to the zone or network, but also based on the metadata related to the instance. For example, in development groups, it is often useful to restrict the ability to terminate instances to only the user who started that instance. This will help prevent users from accidentally terminating a database they are not working on.
Having a user action
log contributes to
overall security,
facilitates recovery
and helps you pass
compliance audits.
• Granular controls–The most complete access control method is to provide a granular level of access to each component of the infrastructure. As an example, a company can grant a person in first-tier support the ability to reboot instances but not start, stop or terminate them. Another example is allowing a person in quality assurance (QA) access to development systems but not to production systems.
Logging and alerting
No matter which of these access control mechanisms you choose, it is important to incorporate logging and alerting into the operations of public and private clouds. With the appropriately configured logging and alerting system in place, the operations team will be able to track all activity and be notified when specific actions fail.
Authorization, logging and alerting with Cloud Manager
Cloud Manager provides a robust, role-based access control mechanism that is very fine-grained. Access controls are cloud independent, which allows for consistent deployments regardless of provider. Access controls can be applied to not only every action performed by a Cloud Manager user, but also to every single resource managed by Cloud Manager. Access rules can be mapped to individual users or assigned to groups.
Users and groups can be natively stored within Cloud Manager, or if deployed on site, can be synchronized from AD or LDAP.
Plus, with access controls by Cloud Manager, it is much easier to track user actions for compliance purposes.
All actions taken by Cloud Manager, whether via the console or the API, are logged. Alerts can be configured whenever certain actions happen (or fail to happen) and are sent via email, SMS or API calls to another application.
Cloud Manager regularly polls the cloud providers and will also create an alert when it detects discrepancies between what it thinks is happening and what the cloud provider believes its current state to be. This is ideal for detecting when users are directly accessing the cloud providers’ consoles instead of using Cloud Manager.
Example of using role-based access control
Assume your organization has both a development cloud and a production cloud. You need to grant appropriate access to a variety of users: IT architects, operations staff, DBAs, QA engineers, security administrators, finance staff and so on.
With no access controls in place, granting a user access gives that user complete access to all systems and the power to perform any action (see Figure 1).
With a role-based access control solution in place, however, you can give each user exactly the right access — just what is required to do the job (see Figure 2).
Dell Cloud Manager
provides a robust,
role-based access
control mechanism
that is very fine-
grained.
Comparing Authorization — Dell Cloud Manager
Feature AWS Dell Cloud Manager
Access control granularity Varies according to AWS product Consistent across all resources
Attribute-based access controls X
Access controls consistent across all
cloud environments X
What about directory services?
User management should be approached with caution, especially with users who have administrative responsibilities or similar levels of access to critical data. Each additional system with uniquely created users increases the likelihood that access will not be removed or updated when a user changes roles. The number of places a user appears may scale linearly, but the complexity of management scales exponentially. As a result, one of the most common security breaches is a user whose access wasn’t properly adjusted or removed when he or she changed jobs or left the organization.
The solution: using LDAP or AD for role maintenance
The chosen solution should allow synchronization with AD or LDAP to eliminate this issue. This way, users can be authenticated, and groups can be mapped to roles within the proxy. As a result, maintenance of roles will be minimal once the initial setup is complete because all changes happen within the directory server. LDAP and AD can be leveraged to dynamically create users within guest VMs.
Cloud Manager provides several options for LDAP and AD integration, such as:
• Synchronization – Set up synchronization between LDAP or AD and Cloud Manager.
Cloud Manager will sync a copy of the users and groups to its own database.
Cloud Manager pushes the users—with their keys—to the appropriate VM. This method is optimal because it requires only read-only access to LDAP/AD by Cloud Manager. Guest VMs never talk directly to your LDAP/AD infrastructure and therefore do not require you to expose your directories to resources in public clouds. When a user is removed from LDAP, Cloud Manager will automatically remove that user from each relevant VM at its next synchronization.
• Configuration management tools – Leverage our Chef or Puppet integration to configure guest VMs to authenticate directly against the LDAP servers. This requires exposing your LDAP or AD infrastructure to your cloud provider.
• Delegated authentication – In delegated authentication mode, Cloud Manager does not store user passwords in its database; instead, it points to the user’s distinguished name (DN) in LDAP or AD.
Figure 1. With no controls in place, once you grant a user access, that user has complete access to all systems and can perform any action.
The number of
places a user
appears may scale
linearly, but the
complexity of
management scales
exponentially.
Conclusion
Access control is critical for your entire IT infrastructure. Doing it right can be challenging, especially when your organization extends to the public cloud.
Cloud providers simply do not offer the robust, role-based access control system you need to create fine-grained access control lists.
Cloud Manager enables you to significantly improve your identity and access management strategy with your cloud deployments. Cloud Manager
uses the existing tools from cloud providers and expands that coverage with fine-grained, role-based access control that is cloud independent.
Cloud Manager supports a variety of authentication methods to meet the unique requirements of each enterprise and delivers auditing and logging of all user actions — something that cloud providers don’t make available. Moreover, it can integrate with your existing AD and LDAP directories to minimize complexity and require fewer points of user management.
Dell Cloud Manager
uses the existing
tools from cloud
providers and
expands that
coverage with
fine-grained, role-
based access
control that is cloud
independent.
Figure 2. With role-based access control, users are allowed access only to certain systems and can perform only certain actions — all based on their defined roles.
© 2015 Dell, Inc. ALL RIGHTS RESERVED. This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Dell, Inc. (“Dell”).
Dell, Dell Software, the Dell Software logo and products—as identified in this document—are registered trademarks of Dell, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners.
The information in this document is provided in connection with Dell products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Dell products.
EXCEPT AS SET FORTH IN DELL’S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, DELL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS
ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF DELL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Dell does not make any commitment to update the information contained in this document.
For More Information
About Dell Cloud Manager
For more information on Dell Cloud Manager, visit www.enstratius.com.
About Dell Software
Dell Software helps customers unlock greater potential through the power of technology—delivering scalable, affordable and simple-to-use solutions that simplify IT and mitigate risk. The Dell Software portfolio addresses five key areas of customer needs:
data center and cloud management, information management, mobile workforce management, security and data protection.
This software, when combined with Dell hardware and services, drives unmatched efficiency and productivity to accelerate business results. www.dellsoftware.com.
If you have any questions regarding your potential use of this material, contact:
Dell Software 5 Polaris Way Aliso Viejo, CA 92656 www.dellsoftware.com
Refer to our Web site for regional and international office information.
