AWS Security Intro – 1. Access

Getting security wrong on your AWS Organisations and Accounts is one of the biggest mistakes organisations regret, it cut Revenue; Reputation or kills the Business or the Business Unit. 

Everyone is online 24 hours and your AWS accounts and platforms are accessible 24 hours to be probed and tested for exploits flaws vulnerability misconfigurations and vulnerable attack vectors.

AWS has well documented best practices supported by many products and services and a huge marketplace with many solutions available to protect, fortify and detract security threats.

When planning to write this article our focus was to make an introduction and practical article, still, security is such a BIG focus we couldn’t make it smaller than a 3 part security article, let us dive into it.

AWS Shared Responsibility Model

AWS Shared Responsibility Model sets the boundaries of responsibility between AWS and its customers, you must grasp the boundaries, connectivity; physical access and building security and safety of all the hardware inside the buildings plus the APIs and services built by AWS are Amazon Web Services responsibility, your AWS Organisation and Accounts access and security plus the platforms and applications built are your responsibility.

Your penthouse contents and access are your responsibility, and the building security access maintenance and upkeep is the management or landlord's responsibility.

Let’s break down AWS Security by Access, Observability, Network and Data Protection.

Access

AWS provides you with access points to your Organisation and Accounts, the Web Console and the API and both require you to authenticate.

Communication is done over SSL/TLS (encrypted in transit), your challenge is to ensure proper credentials management is implemented and maintained.

Compromised credentials will expose your platforms to attackers who could take control, break or encrypt (ransomware) your platforms, and that is why good practices are well known and documented, some of our suggestions.

• Enable multi/two-factor authentication for all users, this way your user’s passwords are not vulnerable to basic dictionary attacks.
• Don’t use the AWS root User, instead secure it with a strong password and MFA/2FA, make sure to delete the Access/Secret keys if they exist and leave them for “break glass” situations.
• Implement IAM Password Policies to enforce rotation and complexity, the downside is it will only apply to IAM Users' Passwords.
• Consider replacing IAM Users with a SAML/OICD solution, either your own on-permisses or commercial ex. Azure or Okta, or AWS AD. Using such a solution will enhance your security, ex. handle the onboarding and leaving of users from your company from a centralized platform.
• Access/Secret Keys are used to authenticate with AWS Api’s and you have two ways to use them:
  1. Keys assigned to the IAM User, unfortunately, these never expire and introduce security weakness to your AWS implementation, or,
  2. Access AWS resources through an IAM Role, API Access/Secret keys will be generated and valid only for a period of time (starting to an hour) this is aligned with AWS best practices and is the more secure option.

• Never ever use IAM User API Access/Secret keys in a file or environment variables for your applications or parts of your platform, this is against AWS best practices and a major security issue, these credentials will never expire and unattended and you can’t properly control who as access to them, use AWS IAM Roles instead.
• Have different levels of access based on Role and consider a multi-approval with temporary access for your production environments,
  • Ex John is a Developer who has full control of the AWS Dev Environment and needs access to a Production environment, access is granted to him with very limited and specific access so he can perform the maintenance (upload/download DB schema) and will last for only 4 days, additionally, access must be approved by his line manager and a DevOps engineer responsible for the Production environment.
• Enable MFA authentication verification for potential destructive operations through your IAM Policies, a good example is to enable MFA/2FA valid authentication from a user deleting objects on an S3 bucket or deleting Ec2 instances, this way if an Access/Secret Keys or Password was compromised the attacker must also have physical access to the MFA/2FA device (less likely). 

Let’s now look at the Observability in our next article. We will look at how to monitor and act on Security using AWS ready services and best practices in Part 2 of the AWS Security introduction.

Feel free to read more on Security from our website at https://boldlink.io/articles/