AWS Security Token Service (STS): 7 Essentials to Save You Time

Sharing is caring. But when it comes to sharing security credentials, you can’t be too generous. Issuing long-term security credentials to users or clients could open the door to a litany of security problems, from data loss to malicious (and costly) attacks. 

As corroborating evidence, 82% of data breaches involve human elements related to poor access management, such as credential theft by employees (with legitimate access permission), misusing or mishandling information, or falling victim to phishing. 

Enter STS - AWS’s Security Token Service. This service dynamically creates security tokens with a short life span so that access is given only on a necessity basis, considering zero trust principles. In this article, I’ll dive into AWS STS and share essential tips on managing AWS STS more efficiently. 



What is AWS’s Security Token Service (STS)? 

AWS Security Token Service (STS) allows you to provide users with temporary access to IAM roles, each with its own permissions. The credentials (an access key, a secret access key, and a token) are dynamically produced and only valid for a short time: anything from 15 minutes to 36 hours, at the user’s discretion. If users still need their privileges after the issued set of credentials expires, they must submit a new request to STS.

AWS STS works seamlessly with the Role-Based Access Control model, which determines that permissions are given to roles instead of users (similar to STS), enabling companies to gain more control over who is accessing what. 

The benefits of AWS STS 

AWS STS makes it efficient and secure to have external personnel working on your AWS infrastructure and collaborating with your team without compromising your long-term credentials and, subsequently, your entire IAM strategy. This feature can also be helpful if you’re undergoing an audit and a third-party authority must review your infrastructure to ensure it complies with security regulations. They’ll get access to what they need for a set amount of time - and that’s the job done. 

And it’s not just about operational efficiency. AWS STS aligns with the principle of least privilege; giving users only the minimum access privileges they need to perform their tasks. This helps reduce your attack surface and close security gaps that could go unnoticed. It also helps cover some controls checked by regulatory frameworks and industry standards like the AWS FTR and SOC2.  

Jit is officially FTR-approved and available on the AWS Marketplace as an AWS partner, making it even easier to access our DevSecOps platform and start building your Minimum Viable Security Product, or enhance your current security capabilities with our vast array of open-source security tools.  

How does AWS STS work?

An STS token doesn’t require you to create a new IAM user - on the contrary, only established and identified users can request an STS token. The identification flow is simple:

1. AWS identifies the IAM user and issues a temporary security token.
2. The user uses that token to assume a new role, usually one with more access than they would usually have.    
3. The client can now use this new role and timed session to access and manipulate the requested resources. A complete log of all this is created and maintained.

Suppose the person requesting the access is not a recognized user with an AWS IAM account. In that case, they can still get that access if they have a user with permission that can be identified differently, like a Cogito-recognized third-party identity provider. 



AWS Security Token Service (STS): 7 essentials to save you time

1. Bypass the public internet when accessing your VPC

You can create a private connection between your Amazon VPC (Virtual Private Cloud) and AWS STS. Using this connection, you can bypass the public internet when connecting to the resources hosted on your VPC. This allows for both greater privacy (only people who know about it can look for it and attempt to access it) and security (STS is time-limited by nature, so even the access you choose to provide is time-sensitive and differs on a case-by-case basis).

2. Use STS to streamline cross-account access

A lot of businesses have multiple AWS accounts active. You can create user identities in one account and use those identities to access AWS resources in other accounts that are part of your business by using the roles with STS to allow cross-account access. The process is called the Temporary Access Rights Delegation (TARD) scheme, and one of its main advantages is that it helps reduce key management overhead for guest network devices. 

3. Leverage Role-Based Access Control 

Usually, in AWS, the users access level is defined by their role. This is also the premise of Role-Based Access Control (RBAC), a popular access control allow method that is policy-neutral and restricts network access based on a user’s role within an organization. Users can assume these roles based on their access needs, and roles can be assigned and revoked at any time. 

Imagine that your IT Helpdesk team needs access to a specific IT application to perform their tasks. Giving the same access controls to each user, one by one, would be an administrative nightmare (and potentially a security nightmare, too). Instead, this team could be assigned the same role with the same permissions and policies. 

STS adds another layer of security by allowing you to allocate roles for users temporarily, letting them keep that access for a limited time and on a case-by-case basis. Here’s a code example demonstrating how to create a user and assign it a role using STS.



4. Use regional STS endpoints

STS is, by default, a global service with a single endpoint for all requests. Instead of using that single global endpoint, you should use regional STS endpoints to decrease latency, add redundancy, and extend session token validity. 

For example, session tokens from Regional STS endpoints are valid in all AWS Regions. Session tokens from the global STS endpoint are valid only in AWS Regions that are enabled by default. That makes the regional tokens more versatile, but it depends significantly on your AWS infrastructure and use case.  ‍

‍

5. Monitor token usage

You can’t talk about cloud security without mentioning monitoring capabilities. Amazon offers several handy tools to monitor your AWS resources and their uses. First, CloudTrail records all console and API calls as events, including IAM and STS calls and use. CloudWatch can be used for real-time monitoring, including setting alarms when certain defined circumstances occur. 

Finally, there is also AWS IAM Access Analyzer, which helps keep track of all the resources shared with external identities. Here is an example of AWS IAM Access Analyzer’s journey in identifying, automatically resolving, and alerting your team of an active finding (external access request): 



6. Regularly rotate credentials

Rotating credentials regularly is good advice for both STS (that does it automatically, assuming the token is short-lived enough) and regular credentials. Don’t be one of those companies that use the same admin pass no matter who that admin is or who gives several people the same security token to keep down costs and make everything more 'streamlined and efficient.’ It may seem efficient - but it’s bad security hygiene. Even if you’re sure there are no IAM gaps, rotate all your passwords and tokens regularly.  ‍

Additionally, you should treat STS tokens as carefully as you would any long-term credentials. No matter how short-lived, tokens should be kept private and not made available via logs, source repositories, or plain text in conversations.

7. Use external identity providers

Why should you worry about managing your users and their identities? If you have lots of them (or hope to have them), let someone else do that for you. Companies that excel in identity management have better tools and track records than those trying to reinvent the IAM wheel. Some options are Microsoft, Okta, and Salesforce - but you need to check all your options, pricing, and features to see which service provider works best for your organization. 

Adopt a ‘security first’ outlook 

STS was designed to give you all the benefits of the AWS granular role system but with greater security. Being able to offer access to people without an AWS account (like your users) and gain the ability to track their token use better is a great bonus. Keep your access limited and only hand it to the people who need it when they need it to avoid creating security gaps in your system. 

If you want an even more granular view of your entire CI/CD security health, Jit’s DevSecOps platform takes security automation one step further by orchestrating and automating various open-source security tools. You can manage them all under one platform and identify and remediate vulnerabilities on the go with the help of enriched real-time findings. Explore more here.