The Dev World – Sergio Lema

Building a secure AWS infrastructure requires a lot of effort.

Still, some practices can help to prevent security breaches.

I’ve been working in many AWS projects, and all have the following practices in place to ensure an acceptable security.

Use Different VPCs

The first point is to isolate every project and every environment. I need to separate each VPC of each project and environment.

A VPC is a Virtual Private Cloud. It’s a closed network where all the AWS services are used in a project.

I don’t want my development instances read data from my production database. this sounds obvious, but a simple problem in the configuration deployment can

Use IAM Groups

Don’t handle the authorisations user by user. Create groups and assign the users to the groups.

When given permissions user by user, it’s hard to replicate the same authorizations to other users.

I used to have the following groups:

• Developers: they can watch logs, restart some EC2/ECS instances, view and put S3 content;
• Super developers: same as developers, and edit EC2/ECS instances configuration, create more EC2/ECS instances, create S3 buckets;
• DevOps: they can create any AWS service;
• Accountable: they can only view the billing resources;
• Admins: same as the DevOps, and they also can manage the users and groups.

Use A Secret Manager

Never store passwords in your services clearly. Nor in environment variables.

AWS has two services to manage passwords securely, secret manager and parameter store.

The AWS services must access only the corresponding passwords. This can be done by using some hierarchy naming strategy. This prevents everyone from being able to see all the passwords.

Enable MFA

MFA (Multi-Factor Authentication) is a strong authentication system.

Not all users have a strong password. Making the MFA mandatory makes the authentication system stronger.

At least, make it mandatory for the groups which have the highest privileges.

Use A Naming Strategy

Who created this service? For which purpose? Can I turn it down?

Not identifying a service is a big problem, because it can generate additional costs.

And if I turn it down, it may cause severe problems in production.

I always use a naming strategy for all the services. This way, I know who created a service and why.

For project-based services, I name them <project>-<subproject>-<topic>-<environment>, and for user services, I name them <user>-<reason>-<topic>.

Here are some examples :

• Project = Silver, subproject = backend, topic = microservice, environment = production. I will name my ECS cluster like this: silver-backend-microservice-production;
• User = Sergio, reason = Serverless, topic = POC. I will name my Lambda like this: sergio-serverless-poc.

The goal is to have a hierarchy from generic names to specific names that everyone understands.

Avoid Using SSH Keys

SSH keys are great to log in to a machine and perform any operation. But all those operations aren’t tracked.

If I need to replicate them in another machine, it will be difficult.

The base of DevOps is to replicate automatically a machine.

I must track those operations while creating the Docker image or the EC2 image.

I don’t need the SSH keys on those steps.

There are few cases when I’ve needed them. For debugging purposes.

To debug network errors or OS errors.

Those are hard to anticipate. However, I must track all the actions done using the SSH keys to solve the problem globally.

The Principle of Least Privileges

I’ve already talked about how to manage the users and groups, but the services also have roles assigned. Those roles define the communication between the services.

I’ve already configured many VPCs, one per project and environment to mitigate the risks of unauthorized access.

But I also need to use the principle of least privileges. Give the least privilege to a service at creation. And increase its accesses as required.

Conclusion

When building an AWS infrastructure, it can quickly become hard to navigate through all the services. And it’s harder to identify security breaches.

Using the principle of least privileges and an adequate naming strategy facilitates the task.