Should you use AWS access keys? Mechanisms, risks, and secure IAM design

In many workplaces, AWS access keys tend to be treated as something that is "issued on a whim." Because they are sometimes needed for CLI or external service integration, they are often used without much consideration. However, access keys are long-term valid authentication credentials. Mismanaging them can lead to unauthorized access and data breaches.

The problem isn't the mechanism, but the decision-making. If you incorporate it into the design without considering whether it should be used, you'll be left with risks such as excessive privileges, reuse, and failure to rotate access keys. What you should be thinking about is not the access key itself, but the overall design of IAM.

This article outlines the role and risks of access keys, and, considering their relationship to alternative solutions, presents criteria for design decisions.

What is an access key?

In AWS, access keys are authentication credentials used to access AWS resources from a program. When operating through the CLI or SDK, this information is used to verify the legitimacy of the request.

The configuration consists of two parts: an access key ID and a secret access key. This combination is used to sign API requests, and authentication and authorization are performed on the AWS side. In IAM, it is treated as long-term credentials associated with the IAM user. It does not expire unless explicitly invalidated. This property is a prerequisite for the design.

Note that AWS officially deprecates the use of root user access keys. When handling access keys, you should limit their use to IAM users or temporary authentication.

Why are access keys not recommended?

The problem with access keys isn't that they're difficult to handle. They're long-term authentication credentials, meaning their leakage has a significant impact, and their structure makes them prone to a breakdown in control.

This is long-term authentication information and will not expire.

Access keys do not expire automatically. They remain even after they are no longer needed, making neglected keys a risk. Managing them becomes more difficult over time.

The impact of a leak is widespread.

Access keys are used for API operations themselves. Depending on the permissions, it's possible to delete resources and retrieve data. Once authentication information is exposed, there's little room to prevent damage.

Difficult to manage and control, prone to becoming dependent on individuals.

It becomes easy to become ambiguous as to who is using which key, and rotation and separation of uses are often put on the back burner. As a result, control remains only in name.

Typical leakage patterns

Access keys are not leaked due to special incidents, but rather as an extension of everyday life.

• Hardcoded into source code
• Accidental commit to a public repository
• Exposure to CI/CD configuration and logs

AWS officially advises against including access keys in code or shared files.

Cases where an access key is required

Access keys are an exceptional measure. The premise is "use only when there are no alternatives."

Local development environment

While access keys may be used temporarily, they should not be the default for permanent operation. For manual user interaction (CLI), IAM Identity Center integration is the primary option. Configurations that distribute long-term keys to devices should be avoided.

External services and SaaS integrations

Some external tools may require access keys. However, even for workloads outside of AWS, temporary authentication can sometimes be replaced with IAM Roles Anywhere.

Legacy operations

This is a case where access keys remain due to constraints of the existing system. It needs to be handled with migration in mind, rather than maintaining the current system.

Access key alternatives

The design premise is "to not store long-term authentication information."

IAM role

This grants permissions directly to AWS resources, allowing access without requiring authentication credentials to be stored.

STS (Temporary Authentication System)

We issue authentication credentials with an expiration date. They are primarily intended to be used in conjunction with roles.

IAM Identity Center

This is a platform for managing user access. It eliminates the need to distribute access keys, including for CLI operations.

Organization of authentication methods

To summarize, it looks like this.

• Human intervention → IAM Identity Center
• AWS workloads → IAM role
• AWS external workloads → STS / Roles Anywhere

Access keys are an exception for cases that do not fall under any of the above categories.

Design principles when using access keys

Access keys should only be used in exceptional circumstances.

At the time of issuance, it is necessary to incorporate into the design the limits of its usability and whether it can be stopped if a problem occurs. Maintaining control cannot be achieved by relying on operational adjustments.

Granting least privilege

The permissions associated with access keys should be limited to what is necessary for their intended use. Administrator privileges should be avoided. Services, resources, and actions should be restricted to limit the scope of impact. If this is not done properly, the damage in the event of a data breach will be uncontrollable.

Regular rotation

Access keys do not expire automatically. If they are not designed to be renewable, the system is flawed. When using long-term authentication credentials, rotation should be assumed, with a maximum rotation period of 90 days. This requires not just establishing rules, but designing a mechanism that reliably executes the switching and deactivation processes.

Separation by purpose

We do not share access keys. They are separated by purpose. Using one key for multiple purposes makes it impossible to determine which system to shut down in the event of a problem. Sharing keys offers convenience during normal operation but sacrifices control in the event of an emergency.

Restrictions on the source of use (IP address, environment)

Instead of relying solely on permissions for protection, we restrict the terms of use themselves.

Condition keys such as aws:SourceIp and aws:sourceVpce are used to reject access from routes other than specific ones. However, the applicability of condition keys varies depending on the service and connection type, so it is necessary to design them with an understanding of the underlying assumptions.

Audit logs and visualization

Access key usage must always be trackable. In addition to CloudTrail recording, unused keys and unnecessary credentials should be continuously detected using tools such as Access key last used, credential report, and IAM Access Analyzer.

Access keys are not meant to be "securely used," but rather to "ensure they can only be used within certain constraints." Purpose, permissions, source of use, updates, and auditing—if these five elements are not fixed in the design, the access key should not be issued.

Common design flaws

The problem with access keys isn't the leak itself, but the fact that they create a situation where, even if a leak occurs, it can't be stopped, and it's impossible to track what happened. The cause is often not a specific mistake, but rather a design flaw where control conditions aren't defined at the time of issuance.

Reusing a single key

Sharing a single access key across multiple applications or uses expands the scope of the impact. When a problem occurs, it becomes impossible to identify where it was used and determine the extent of the downtime. If the keys are not assigned to specific uses, the situation becomes uncontrollable.

Excessive granting of authority

Prioritizing convenience and expanding permissions will directly lead to a wider range of damage in the event of a data breach. It is not uncommon for systems to be operated with administrator privileges only. The consequences of neglecting permission design directly impact the scale of the incident.

Rotation not implemented

Continuing to use access keys without updating them means you lose track of where they are stored. Furthermore, there's no guarantee you can securely switch them out if a problem occurs. When rotation isn't built into the design, you're not in control of long-term credentials.

The user is unclear.

The system is currently in a state where it's unclear who is using which access key. This problem is unavoidable with shared accounts and common keys. Without identifying the user, neither auditing nor incident response can be performed.

These are not problems that can be absorbed through operational adjustments. Unless access keys are "stopped" and "traceable" at the time of issuance, adding rules afterward will not restore control.

Judgment criteria

The decision of whether or not to use access keys should be based not on whether they are necessary, but on whether they can be replaced by other means. Choosing them for convenience introduces the risk of long-term authentication information into the design phase. The starting point is to not assume the use of access keys.

The first thing you should check is whether it can be replaced with an IAM role. For integration between AWS services and application execution environments, in many cases, it can be configured with roles in mind. If there is a reason why you have no choice but to use access keys here, you should reconsider the premise itself.

Next, in cases where users are operating the system, we will check if it is possible to configure the system without distributing access keys using tools such as IAM Identity Center. Designs that distribute long-term authentication information to each device should be avoided, especially in local environments or when using the CLI.

Next, we'll look at whether temporary credentials can be used as an alternative. Using STS (Security Token Service), it's possible to configure the system using credentials with expiration dates. If it's possible to avoid using permanent keys, we'll prioritize that option. Even for workloads running outside of AWS, there's room to replace them with temporary authentication depending on the requirements.

Only if an access key is still required after considering all of the above should we verify the scope of permissions. Are the permissions to be granted clear and consistent with their purpose? Are there any excessive permissions included? If any ambiguity remains at this stage, the design is not valid.

Finally, verify that the rotation frequency, responsible party, scope of use, and deactivation procedures are defined. Since long-term authentication credentials are used, it's essential that they can be controlled, including renewal and deactivation. If access keys are issued without these details, it will be impossible to control them later.

Access keys shouldn't be used simply because they're available. Alternatives should be considered in the following order: role-based authentication, user authentication infrastructure, and temporary authentication. Access keys should only be chosen as a last resort. Maintaining this order is crucial when making decisions.

Summary

Access keys are one of the authentication methods in AWS, but they should not be the sole basis of the design. As they are authentication information that will remain valid for a long time, mishandling them will solidify risks.

The real question isn't how to manage access keys, but whether you can create a configuration that doesn't require them in the first place. AWS workloads should be handled by IAM roles, human operations by IAM Identity Center, and external environments should rely on temporary authentication as much as possible. Designing in this order will virtually eliminate the need to distribute long-term authentication credentials.

Access keys should only be used when other alternatives are unavailable. Even then, it is essential that they allow control over their purpose, permissions, source, updates, and auditing. If these aspects are unclear when issuing an access key, the key is not designed correctly.

Access keys are not something you "use," but rather something that you "design with the assumption that you won't use them, and only allow as an exception." Maintaining this order is the standard for secure AWS operations.