AWS brings agility to your business because you no longer have to wait for days for IT to spin up new servers. AWS enables organizations to quickly respond to business needs and rapidly add value to their clients. However, the speed doesn’t need to come at the expense of compromised security.
Security is even more important in the cloud: it’s not just IT provisioning resources, but also developers, plus whoever else has access to launch resources—and nowadays, far more people have access. Also the rate of storing sensitive and confidential data is ever increasing. It’s vital for organizations to take steps to ensure full control of AWS security.
Some of these measures are as simple as enabling security services, but some measures require better training or even leveraging third party tools like ours: nOps.io. The end goal should be to make security part of the operation—not an afterthought.
Let’s talk about ten measures you can take to secure your environment.
Understand the security responsibility
AWS offers a variety of different infrastructure and platform services. Everyone should read AWS security best practices. AWS dividessecurity best practices into three categories: infrastructure, container, and abstracted services. Each category comes with a slightly different security ownership model based on how you interact and access the functionality.
Infrastructure services, such as Amazon EC2, Amazon EBS, and Amazon VPC, run on top of the AWS global infrastructure. Building on the AWS secure global infrastructure, you install and configure your
operating systems and platforms in the AWS cloud just as you would on-premises in your own data centers. In the shared responsibility model, you own the operating system credentials, but AWS helps you bootstrap the initial access to the operating system
For abstracted services, you are responsible for managing your data (including classifying your assets) and for using IAM tools to apply ACL-type permissions to individual resources at the platform level or permissions based on user identity or user responsibility at the IAM user/group level. For some services, such as Amazon S3, you can also use platform-provided encryption of data at rest or platform-provided HTTPS encapsulation for your payloads for protecting your data in transit to and from the service.
For AWS Container services, you are responsible for the data and firewall rules for access to the container service. For example, Amazon RDS provides RDS security groups, and Amazon EMR allows you to manage firewall rules through Amazon EC2 security groups for Amazon EMR instances.
Lock down the root account
AWS strongly recommends you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user and then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Some organizations go as far as adding physical MFA on the root account and then locking it in the Safe.
Enable audit trail
Having audittrail on your AWS environment is important. It’s one of the services that should be enabled by default, but it’s not. CloudTrail is an AWS service that provides valuable log data for organizations, but unfortunately, many admins end up creating AWS instances without turning this service on. If correctly utilized, CloudTrail maintains a history of all AWS API calls, including the identity of the API caller, the time of the call, the caller’s source IP address, the request parameters, and the response elements returned by the AWS service. It can also be used for change tracking, resource management, security analysis, and compliance audits.
If you find you have deleted CloudTrail, the data cannot be retroactively turned on. If you don’t turn it on before you create AWS instances, you will lose the ability to see all virtual instance activity during any future investigations. Although Cloudtrail is regional service, it’s easy to enable CloudTrail across all your regions.While it does take some time, enabling CloudTrail will be well worth it.
In addition to audit trail, you should enable Config on your AWS account. Config is a service that allowsyou to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations. With Config, you can review changes in configurations and relationships between AWS resources, dive into detailed resource configuration histories, and determine your overall compliance against the configurations specified in your internal guidelines.Note Config is a regional service, so you should ensure you enable it across all the regions where you have resources.
Grant Least Privileges
When you create IAM policies, follow the standard security advice of granting least privilege—that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks.
Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.
AWS Multi-Factor Authentication (MFA) is a simple best practice that adds an extra layer of protection on top of your username and password. With MFA enabled, when users sign into an AWS website, they will be prompted for their usernames and passwords (the first factor—what they know), as well as for an authentication code from their AWS MFA device (the second factor—what they have). Taken together, these multiple factors provide increased security for your AWS account settings and resources. You can enable MFA for your AWS account and for individual IAM users you have created under your account. MFA can also be used to control access to AWS service APIs.
Avoid secret keys
You should always avoid use access and secret keys because if keys are compromised, hackers can have the same level of access to your AWS resources that you do. Fortunately, AWS has support for IAM roles; you can assign the roles to ec2 instances for making API calls. Roles are much more secure, so you don’t have to worry about securing the keys. AWS automatically dynamically regenerate the keys.
Use VPC to isolate your resources logically
Amazon Virtual Private Cloud (Amazon VPC) lets you provision a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define. VPC allowsyou to create an isolated network for each environment, like Dev, Stage, and Prod. As a result, you can protect production data by isolating it from other environments.
One of the easiest ways to keep your organization’s sensitive and confidential data secure is through Key Management Services (KMS). KMS are managed services that allow you to easily create and control the keys used to encrypt and decrypt your data. If you are a company that must follow certain protocols, such as HIPAA, the importance of this ability exponentially increases.
Combined with other AWS services, KMS can help you protect all the data you store while injecting secure credentials into automated instances. While this is advantageous, there are many other benefits of KMS for your organization.
Control security groups access
The most common mistake made by many admins is enabling global permissions to instances. By using
0.0.0.0/0 in your public subnets, you are leaving your connection wide open, giving every machine the ability to connect to your AWS resources.
It is vital to give your security groups the narrowest focus possible. When possible, it’s best not to use CIDR; you should instead reference security group IDs to allow traffic.For instance, you can allow web server security access to talk to RDS.
These security measures are necessary steps in protecting your AWS infrastructure, but by no means is this a complete list. There are numerous security best practices you must follow for each AWS service. For instance, the s3 bucket shouldn’t have a public access policy,and production ELB should have logs enabled. For complete AWS security, you should leverage solutions like nOps.io to ensure you are following best practices across all these services, so your organization can go fast and stay secure!