Best Practices to counter ransomware

With the popularity of cloud native applications architecture, cloud security is gaining traction. In this article, we will explore AWS STS service which finds a place in AWS recommended best security practices guidelines.

AWS STS (Security Token service) is a free web-based service which is used to generate temporary security credentials with limited privilege to access AWS resources by trusted and authenticated entities. By default, it is available as a global service at endpoint https://sts.amazonaws.com but AWS recommends usage of regional endpoints for build in redundancy, low latency, and increased session token validity benefits. As the credentials generated by this service are temporary – they are valid for a limited duration. This duration can range from 15 minutes to 36 hours. Default value is 12 hours.

Common use cases for AWS STS are-

• Identity Federation – AWS STS can be used to provide users access to AWS resources in cases where identities are stored outside of AWS either in customer data-center or in third party web-based applications.

Enterprise Identity Federation– It is also known as single-sign-on where users can be authenticated against your organizations in-house authentication system (like Active directory) and then provide them access to AWS resources using STS. AWS STS can use either custom federation broker or Federation using SAML 2.0.

Web Identity Federation– Here users can sign in using a third-party identity provider like Google, Facebook, Amazon or any other OpenID Connect (OIDC)2.0 compatible provider. In this case you do not need to create custom sign-in-code or manage user identities for your mobile or web applications. As your application is not storing/distributing your long-term security credentials, it enhances the security of your environment.

• Cross Account delegation and sharing of resources via IAM role –

The organisation can create multiple AWS accounts like separate accounts for dev, production, and testing environments but the user creation/administration can be done from a single account. This delegation approach to temporary access not only saves your administration effort but also keeps your cloud environment secure. It can also be used to share resources among different organisations. One use case scenario can be one of your clients need to push enormous amounts of data from their AWS account to a S3 bucket in your account in an automated and secured manner for processing on your end.

.

• Amazon EC2 Instance profile –

If your amazon EC2 instance is running an application which needs access to any AWS resource like S3, you can provide temporary security credentials to your instance when you launch IAM role. Once you launch your EC2 instance with these credentials, they become available to any application running on that instance and there is no need for long term storage of credentials which could be a security risk.

• Access other AWS services–

Temporary credentials generated with STS can be used to access most of AWS services that work with IAM.

• Regular credential rotation in automated processes–

Regular credential rotation as per an organisations policy can prove to be a challenge for automated processes. In STS, there is no need for storing credentials in environmental variables or inject any access key. The credentials are generated on-demand and expire automatically when not needed.

Various available command to use in AWS STS call are-

• assume-role
• assume-role-with-saml
• assume-role-with-web-identity
• decode-authorization-message
• get-access-key-info
• get-caller-identity
• get-federation-token
• get-session-token