It’s 11pm. Do you know where your credentials are?
July 30, 2014 | DevOps | Kevin O'Brien
The Cloud Credential Conundrum
We’ve all been there. You have an urgent project, and need to hire in a consultant with a specific skillset to get it done. You go through the interview and hiring process, get them onboarded, and grant them access to your systems. Keys get assigned, and since you have a top-notch DevOps team, everything is automated with Chef, SaltStack, Puppet, and Ansible
Your hired gun completes their tasks and you part ways; they pack up and head out, on to their next gig.
But wait, did you deprovision them? Can you deprovision them? Do they still have viable credentials to your system? Are those credentials still sitting in a git repo or a configuration management tool image somewhere?
Deprovisioning users and managing authn and authz, whether ex-employees, employees with role changes, or even code written by contractors and left running in your infrastructure, needs to be simple, efficient, and managed with discipline. This is a common problem area, from the tiny start up to the enterprise , but it is rarely on the security radar, even though insider access is one of the most prevalent causes for long-term compliance and security issues.
If you’ve shared credentials, you risk breaking a dozen other users’ login causing your IT team to be bombarded with emails Monday morning at 9am. If you provided their own set of credentials, you need to make sure all access to your systems is shut off.
User access control is not only good housekeeping, it is a mandated control under a number of regulatory requirements. An example of such a control can be found in HIPAA / HITECH: Identity and Access Management: User Access Revocation – IAM-11 45 CFR 164.308 (a)(4)(ii)(A) which states:
Timely de-provisioning (revocation or modification) of user access to data and organizationally-owned or managed (physical and virtual) applications, infrastructure systems, and network components, shall be implemented as per established policies and procedures and based on user’s change in status (e.g., termination of employment or other business relationship, job change or transfer). Upon request, provider shall inform customer (tenant) of these changes, especially if customer (tenant) data is used as part the service and/or customer (tenant) has some shared responsibility over implementation of control.
Of course, it should not be just the user who needs to be deprovisioned, but also their active and non-active scripts in your infrastructure. Each script should be checked and certified, before being reassigned to a different employee.
Achieving credential management visibility is vital for proper system security and proof of access control, without burdening your engineering, IT, or devops teams.