Cloud IAM: a primer
What is IAM?
IAM is a service provided by AWS that enables you to manage access to AWS resources securely.
IAM policies are a crucial part of access management, as they define permissions and actions that users or resources can perform within your AWS environment.
Where do IAM policies pop up in day-to-day operations?
Let’s think about a scenario where you have just started at a technology company as a data analyst.
Within your day-to-day role, you’re responsible for looking at Company data and informing stakeholders about different trends that inform business decision making.
You may be responsible for…
Access to data:
You might need access to specific data. This would live within something like an Amazon S3 Bucket.
Your company should create and assign an IAM policy that grants you read-only access to those buckets and their objects.
This policy could be attached to your IAM user account, allowing you to access the data without granting unnecessary permissions.
WATCH OUT! Unnecessary permissions would include allowing this analyst to modify the data as well as read the data. Why would an organization allow an individual responsible for reporting only to also modify the results they’re reporting on?
Access to EC2 Instances:
EC2 instances allow you to run applications within AWS.
If you need to perform data analysis within an EC2 instance, you can create an IAM policy that grants you access to start, stop, and terminate instances, as well as access to output of what you created.
This policy could be attached to a role that you assume when you need to perform analysis, rather than granting permanent access to all EC2 instances.
Ad-hoc data analysis
Sometimes, a data analyst may need to perform ad-hoc data analyses on a large dataset that requires more processing power than their local machine can provide. In this case, they may request temporary access to an EC2 instance that has the necessary resource capacity, such as high CPU or memory, to perform the analysis
Data Migration
If a data analyst is working on a project that involves migrating data from one system to another, they may need temporary access to an EC2 instance to run scripts or tools that facilitate the transfer. This may involve access the source and destination systems, as well as any intermediate storage or processing systems.
Data Modeling
If a data analyst is working on a project that involves testing software that interacts with AWS resources, they may need temporary access to an EC2 instance that mimics the production environment. This can help ensure that the software behaves correctly, and does not cause any unintended consequences.
Access to RDS databases
AWS provides a fully managed database service called Relational Database Service (RDS) for technologists who wish to operate and scale relational databases within their cloud environments. Relational databases are ideal for complex data operations and analyses.
If you need to query data from an RDS database, you can create an IAM policy that grants you read-only access to the database and its tables. This policy could be attached to a role that you assume when you need to perform analysis, rather than granting permanent access to the database.
Temporary Access
If you are working on a short-term project or need to provide access to an external consultant or auditor, you can create a temporary IAM user account with a time-limited access key and secret access key.
You can also create an IAM policy that grants the user access only to the resources they need for their work and expires when the project is completed.
So what does this tell me?
Similar to any on-prem technology you’ve managed, permissions need to be regularly evaluated and maintained to ensure that the right actors are accessing the right information, at the right time.
What if I realize I have access I don’t need? What if I just don’t touch things I shouldn’t?
This is still a dangerous situation because while you might not use what you don’t need, that doesn’t stop your account from being a perfectly good way to access those additional resources, and a malicious attacker would love to get their hands on them.
It’s best to always remove access you don’t need, so that if an unauthorized users gains access to your account, your access controls act as additional lines of defense to mitigate the damage that can be done.
Let’s talk more about the importance of IAM policies
So now that we’ve covered what they’re used for, let’s talk more about why IAM policies are important.
Similar to a lock on the door to your house, IAM policies have varying levels of efficacy based on how much work you put into implementing them.
IAM policies are important for several reasons…
Granular Access Control:
IAM policies allow you to define fine-grained permissions that restrict access to specific AWS resources or actions. This helps to minimize the risk of unauthorized access, data breaches, or accidental modifications.
Least privilege principle:
IAM policies enable you to apply the principle of least privilege, which means granting users and services only the permissions they need to perform their tasks.
This helps to reduce the attack surface and limit the potential damage caused by security incidents.
Compliance and Auditing:
IAM policies can help you comply with regulatory requirements and auditing standards by providing a clear and auditable record of who has access to AWS resources and what actions they performed.
Here are some of the reasons why you may be required to provide logs of access to technology systems:
Compliance with Data Privacy Regulations:
Companies may be required to maintain access logs to ensure compliance with data privacy regulations such as the EU General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA).
Financial Regulations:
Financial institutions may be required to maintain access logs for compliance with regulations such as the Sarbanes-Oxley Act (SOX) and the Payment Card Industry Data Security Standard (PCI-DSS).
Healthcare Regulations:
Healthcare providers may be required to maintain access logs for compliance with regulations such as the Health Insurance Portability and Accountability Act (HIPAA).
Government Regulations:
Government agencies may require companies to maintain access logs for compliance with regulations such as the Federal Information Security Management Act (FISMA) and the National Institute of Standards and Technology (NIST) guidelines.
Here are some examples from a few industries mentioned above…
Healthcare: HIPAA requires healthcare providers to maintain access logs to electronic protected health information (ePHI) to ensure that access is limited to authorized individuals.
Financial Services: PCI-DSS requires financial institutions to maintain access logs to cardholder data to track and monitor access to sensitive information. Additionally, the state of New York Department of Financial Services requires financial companies to maintain logs of material financial transactions for up to five years.
Technology: The GDPR requires companies to maintain access logs to personal data to ensure compliance with data protection requirements.
Government Agencies: FISMA requires federal agencies to maintain access logs to their IT systems to ensure compliance with federal cybersecurity regulations.
It's worth noting that the specific regulations and requirements vary by industry and location, and organizations should consult with legal counsel to determine their specific obligations.
Flexibility and Scalability:
IAM policies are flexible and scalable, allowing you to adapt to changing business requirements and add or remove permissions as needed. You can also use IAM policies to grant temporary access to resources, such as for contractors or temporary employees.
In summary, IAM policies can be used by employees to limit their access to AWS resources to only what is necessary for their job functions. This can help to maintain the security and integrity of the resources, while still allowing the employee to perform their work effectively.
What are the risks?
Now that we’re talked about why it’s important, let’s talk about the risks. There are several common mistakes people make when setting up IAM policies in AWS.
Overprovisioning:
One of the most common mistakes is overprovisioning, which means granting more permissions than necessary to users or services.
This can increase the risk of security incidents, such as data breaches or accidental deletions.
To avoid overprovisioning, it's important to follow the principle of least privilege and grant users only the permissions they need to perform their tasks.
Practically, this means that every leader in your organization needs to be fully aware of the technical needs of their team and adjust them continuously to follow the principles of least privilege.
Poorly Defined Policies:
Another common mistake is creating policies that are poorly defined or overly permissive.
For example, a policy that allows access to all resources in an AWS account or a policy that grants full administrative access to a user.
To avoid this, it's important to review and test IAM policies carefully before implementing them.
Lack of Testing:
IAM policies can have complex interactions with other AWS services and policies, which can make it difficult to anticipate all the possible scenarios.
A common mistake is not testing IAM policies thoroughly before deploying them to a production environment.
To avoid this, it's important to test IAM policies in a staging or test environment, and to monitor their behavior using AWS CloudTrail or other monitoring tools.
Inconsistent Policies:
Another common mistake is creating policies that are inconsistent across different AWS services or resources.
For example, granting different levels of access to the same user or role in different regions or accounts.
This can lead to confusion and make it difficult to manage permissions effectively.
To avoid this, it's important to establish consistent policies across all AWS resources and services.
Failure to Update Policies:
Finally, a common mistake is failing to update IAM policies in response to changing business requirements or security threats.
As the business grows and evolves, the IAM policies must also be updated to reflect the changing needs of the organization.
Failure to do so can result in security incidents or compliance violations.
