AWS Security Guide: 7 Best Practices to Avoid Security Risks

Insufficient Visibility

Cloud resources are mostly transient. This makes it a challenge to keep a log of assets. According to a recent research, the usual lifespan of a natural cloud resource is a little over a couple of hours.

Best Practice

Ensure you are using a cloud security solution that gives visibility into the number of type of resources you use across geographies and accounts in a single dashboard. These can include load balancers, virtual machines, users, security groups, etc. A better understanding of your environment allows for the implementation of more minute policies and inhibits risk.

Exposed Root Accounts

Root accounts are capable of doing the most damage when unauthorized individuals get access to them. Often time administrators miss disabling API root access, providing a doorway for malicious users. Here’s a quote from the AWS docs.

Best Practice

Most of the time, AWS root accounts should not be accessed by anyone, including top admins. These should not be shared with users or applications. It is imperative to protect root accounts via multi-factor authentication and should be accessed as less as possible.

Extra, Unnecessary Privileges

As mentioned earlier, misplaced and stolen credentials are among the leading causes of security breaches. AWS IAM can manage all user groups and accounts with detailed policies and permissions.

Best Practice

Similar to any other permission-based systems, the configuration of IAM should also be compliant with the underlying rule of least privilege. This translates to any groups or users should only get permissions as required to perform their regular jobs or tasks.

Rotate IAM Access Keys and Credentials

Often, IAM access keys are not rotated. This leads to weaknesses in the IAM’s ability to keep user groups and account secure and allows attackers a larger window to gain access to them. Additionally, rotating IAM, access keys ensures that old keys are not used to get access to critical services.

Best Practice

Rotating or changing your access keys a minimum of once a quarter is a good idea. In case users have the right level of access, they should be able to rotate their access keys themselves. Here’s an example policy that shows how you might create a policy that allows IAM users to rotate their own access keys:

Poor Authentication Practices

Leading cloud security incidents are down to stolen or misplaced credentials. Unfortunately, it is quite common to notice access credentials for public cloud environments on the web. A recent example would be the Uber breach. Organizations must prioritize a way to detect and close off these account compromises.

Best Practice

Robust password policies, coupled with multi-factor authentication (MFA) needs to be enforced within AWS environments. AWS suggests allowing MFA for all accounts that currently have console passwords. Users need to determine which accounts have pre-existing MFA. Then under IAM, ‘MFA Device’ needs to be checked for all users. Devices such as smartphones can also be used as an additional authentication device.

Get Rid of Unwanted Privileges

As mentioned earlier, misplaced and stolen credentials are among the leading causes of security breaches. AWS IAM can manage all user groups and accounts with detailed policies and permissions.

Best Practice

Similar to any other permission-based systems, the configuration of IAM should also be compliant with the underlying rule of least privilege. This translates to any groups or users should only get permissions as required to perform their regular jobs or tasks.

Unpatched Host Servers and Services

It is the responsibility of the organization or a dedicated team within the organization to ensure all of the latest security patches are applied to hosts within the cloud environment the organization is engaging with.

Best Practice

Ensure that the host(s) your organization uses is up to date when it comes to patches. All necessary fixes are released and applied by your OEM vendors. Third-party tools can assist with mapping the data originating from the host’s vulnerability updates. A prime example would be Amazon Inspector.

  1. Start a screen session in your shell window. Screen sessions help you reconnect to a SSH session even after being disconnected.

Broad IP Ranges for Security Groups and Unrestricted Outbound Traffic

Security groups can be imagined akin to firewalls that control and monitor traffic to AWS environments. Admins again are at fault at often assigning this security to a range of IP addresses that tend to be broader than what is necessary.

Best Practice

IP ranges should be limited when assigning them to security groups. This should be done in a way that though all systems network smoothly, systems are not left open unnecessarily. If you use 0.0.0.0/0, you enable all IPv4 addresses to access your instance using HTTP or HTTPS. To restrict access, enter a specific IP address or range of addresses.

Conclusion

It might sound like a challenge to keep your AWS cloud service secure from vulnerabilities. Many organizations commit mistakes which exposes their network and data at risk primarily due to poor configuration, lack of adequate planning and vulnerability detection and scanning methods.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Women Who Code

Women Who Code

We are a 501(c)(3) non-profit organization dedicated to inspiring women to excel in technology careers. https://www.womenwhocode.com/