James Thew - Fotolia
5 security oversights to avoid with IAM configurations
IAM provides the granularity organizations need to secure their cloud workloads, but only if it's properly implemented. Refrain from making these common IAM mistakes.
Public cloud resources can be extremely secure when permissions are configured properly, but doing so requires careful consideration and forethought. Mistakes could expose sensitive workloads and data, placing a business at risk.
Cloud security revolves around the notion of permissions -- the mechanisms used to assign granular approval to entities that access cloud resources. These entities can include users, customers, partners, services and applications. Permissions are typically assigned and managed through vital cloud services such as AWS Identity and Access Management (IAM), Microsoft Azure Active Directory and Google IAM.
Let's examine five of the biggest oversights in IAM configurations -- sometimes called user access management or UAM -- and consider ways to avoid them.
1. Incomplete provisioning
Organizations invest considerable resources to streamline and automate the provisioning process so each new entity can access the appropriate cloud resources. However, providing access to resources is only half of the puzzle. De-provisioning is equally important, even though most organizations treat it as an afterthought or ignore it entirely.
For example, it's alarmingly common for employees to use and share a former coworker's account because the account had the "right" permissions and everyone knew the password. It doesn't matter whether anything untoward is taking place, the account should be de-provisioned because it creates a gaping security flaw. And this risk can multiply as more employees or other users leave over time.
The answer is often a matter of process -- not tools. Just as one process would be used to onboard and configure an entity, another process must be created in order to off-board with equal attention to detail. This is true regardless of the degree of automation. The entity could be a retired application, a dismissed employee, an idle customer or business partner, and so on. Enterprises should periodically audit accounts to identify and lock down unneeded access.
2. Poor process automation
Unlike traditional perimeter security, IAM is designed to protect a business from the inside out. Access and permissions are managed across the enterprise, and while it can be effective, it also adds complexity.
Successful IAM is more than just managing usernames and passwords for employees in the building or on the network. Organizations need to identify assets and categorize users to determine resource access, which must be performed quickly and at scale. To exacerbate matters, this must be implemented across varied user models, such as:
- temporary, contract and remote users;
- high-volume user models, such as customer and business partner access;
- access through a proliferation of mobile devices -- often BYOD; and
- vast deployments of IoT device environments.
Automation is vital to handling the speed and complexity associated with this process -- but only after the process has been properly conceived and proven. An organization can deploy an automation platform to handle IAM provisioning, only to discover that the process is too complex, too inflexible or cannot meet the demands of scale. Don't force-fit a poor process into a tool that nobody really knows how to fix. It can lead to security flaws and a failed IAM initiative.
Address these issues through a combination of planning and testing. Administrators and business leaders must collaborate to identify the best process for the business, and then test it through automation tools in proof-of-principle deployments. For each test, gauge how effectively you've achieved the desired IAM result, how easy it is to adjust the process as business needs change and how well the deployment scales.
3. Inadequate scope
IAM is intended to manage credentials for a wide range of entities. Enterprises should approach IAM implementations across a wide spectrum of use cases, but it is often employed for only a subset of entities -- such as employees.
IAM can be used in this way, but it's not recommended because it demands additional or duplicate processes to manage the entities not already handled. For example, if IAM is only used to manage permissions for local employees, other processes may be required to handle permissions for customers, outside partners, internal services or applications and so on. The result is duplicated -- and possibly divergent -- processes using different tools and policies that virtually guarantee that security efforts will be more difficult than necessary. Oversights in process differences could create security vulnerabilities.
Embrace IAM's entire scope from the start to focus on a single identity and permission system. This will simplify the security environment, reduce errors and oversights and create a stronger overall security posture.
Be sure to also consider how IAM handles the actual volume of each entity. For example, organizations may need to contend with vast numbers of end users or IoT devices, so it's extremely important for the business to be able to properly provision, search and audit those entities.
4. Insufficient reviews
Security is not a one-time process. A sound IAM security posture demands careful and frequent review by IT administrators and business leaders. Unfortunately, IAM policies and configurations are often implemented and forgotten -- only to be reviewed and assessed when an incident or audit occurs. With administrators' focus elsewhere, the organization's evolving security needs may be ignored, which results in security vulnerabilities that can compromise the business.
For example, an IAM review might reveal that a new application is used by a unique assortment of employees, which then justifies the creation of a new user group or category in order to simplify provisioning. This can be faster and more effective than manually granting access for each user. It also helps to avoid granting access to an existing user category that includes some employees who don't need -- or shouldn't have -- access to the app.
Periodically revisit and adjust IAM configurations, because change is inevitable across a busy enterprise. Larger businesses with significant or active IAM deployments will benefit from more frequent reviews.
5. Overlooking authorization
When it comes to security, granularity matters. IAM is ideal for this, but organizations often don't take full advantage of their IAM technologies and services. IT and business leaders make extensive investments in mechanics such as authentication, two-factor technologies and biometrics to implement IAM. But organizational leadership can get distracted with competing priorities. In fact, IAM is really only useful when granularity is utilized, and a lack of focus can lead to overlooking important details -- such as meaningful security groups and suitable password policies.
A business might implement IAM, but put all employees in the same security group and give them access to the same applications and data. This could create serious vulnerabilities for sensitive data about HR, payroll, accounting and more.
Similarly, independent software contractors might be given access to the entire company software repository along with other in-house developers. This could expose some intellectual property to non-employees. Instead, allow outside contractors into a single isolated or dedicated repository for contractors only.
Take the time to create and manage meaningful organizational entities within the IAM system in order to align security groups with appropriate applications, data, business units and user types. It's the best way to ensure solid security best practices such as least privilege.
