Have you noticed the increasing amount of media reports, press releases and industry publication articles that headline security related breaches? If you’re like me, you probably read through the details of these attacks, are completely astonished over the specifics, and then ask yourself “how in the world do breaches like this actually happen?” Unfortunately, cyber attacks and security breaches happen in almost every type of enterprise, from huge conglomerates to small shops with lean IT groups. With the disappearance of the traditional security perimeter and widespread adoption of cloud computing, sensitive data is being distributed farther than ever across locations, devices and repositories, introducing new means through which valuable data can be attacked.
As I’ve told dozens of my clients, identity and access management (IAM) in the cloud is a full-time job. IAM protects data by ensuring that only the right people have access to the right information at the right time and for the right reasons. A successful IAM strategy requires at least one full-time “gatekeeper” (or several working part-time) to ensure complete compliance and optimal security. I’ll use AWS as the example cloud platform to help me outline a few common security challenges that many organizations find themselves dealing with. Some of this information is specific to AWS, and some of it is just considered good IT practice.
Permanent permissions to a cloud provider
A scenario I see often is where individual users are created with permissions directly attached. This practice increases the risk of accidentally granting individual users access that is above their minimum requirements. Better practice is to create groups of users, assigning defined permissions to those groups and then assigning specific users to each group. Once created, groups can also have the ability to grant temporary permissions to a specific user. In AWS, this can be done via the Security Token Service (STS), where an IAM role or identity is created with specific permissions. Following these guidelines accomplishes a few things: it enhances security by providing short-term elevated credentials for a user, it provides access to cloud using groups, and it establishes unique permissions with an extra security layer for users accessing cloud.
Role-based access control
Another good IT practice is role-based access control utilizing industry best practices around least-privilege, where only the permissions required to perform a job are granted. Unfortunately, organizations sometimes fall short when it comes to this practice, granting cloud consumers, app owners or even general business users unnecessarily high permissions to the console or API. Defining specific roles beyond just administrators is critical as the cloud program starts to take off. The task of determining job responsibilities and access needs for users, and then grouping those common users together into roles, may sound like a tedious, daunting task, but spending the time to do this correctly will save you frustration and extra work down the road.
Protect Access Keys and Secret Access Keys
AWS IAM users receive an AccessKey and a SecretAccess Key to allow for programmatic access to AWS. If you’ve studied the details around role-based access and STS, obtaining these keys is not enough to infiltrate an AWS account; hackers would also need to know the account number associated with the user and their associated role Amazon Resource Name.
Unfortunately, AWS cloud accounts do sometimes get hacked. This is usually the result of AccessKey and SecretKey information getting hardcoded into a script or program, and then committed to a public code repo. To mitigate this risk, follow the good IT practices I have touched on above, and implement a stale key and rotation policy. This ensures keys that have not been used in 30 days are made inactive, and keys that are older than 180 or 360 days are rotated. This policy has a dual benefit because it also forces the application owner or developer to update their code or config files at least once per year.
Life Cycle for IAM Users
Incomplete knowledge of roles and access permissions can lead to security blind spots, especially if your IAM gatekeeper leaves the company or changes jobs. Life cycle management helps to reduce your attack surface by preventing the compromise of an organization’s user accounts. IAM users are managed separately from Active Directory or LDAP accounts, and as a result, any life cycle policies in place must be rebuilt and reapplied for AWS IAM users. These periodic audits and account evaluations help to ensure that all users have a match with a centralized directory, be it Active Directory, LDAP, or an HR system, so that every user has an owner—including those for service accounts. A good life cycle management strategy can assist in identifying invalid shared and backdoor accounts, legacy accounts that were never terminated, and accounts owned and used by a terminated employee or contractor.
The last thing you want is to end up in the news because some credentials got out in the wild. Take steps now to prevent it. You can download the complete Amazon article on IAM Best Practices here.
For more details on how Sirius can better secure your cloud journey, contact a Sirius cloud expert today.
