AWS Cloud - The way to your secure cloud datacenter

At the beginning we didn’t know much all about the fancy services in AWS and the aspect of security was unimportant for us. But for an productive environment in a cloud the security is very important for a company.
Amazon, like most cloud providers, takes care of security for its physical data centers and the server hardware the virtual machines run on, but leaves it up to the individual customer to protect its own infrastructure.
The AWS has an shared responsibilty model. So you can exactly see for which services you are responsible.
https://aws.amazon.com/compliance/shared-responsibility-model/
Our new AWS Account had only root access and no personalized user access. So you can see in the IAM of AWS what you have to do for a secure login. This is very important because i think not everyone should have access to your datacenter 🙂
Secure IAM Setup
- Your Root Account don’t need the Access and Secret Key for AWS Services. Later we added user with defined rights and they all have their own secret and access key.
- MFA ( Multifactor Authentication) is an additional secure level for the root Account. We bought an MFA Hardware Token from Gemalto for our root account and put it to a safe place.
- We created for the Administrators an IAM User with Administrator Access(Policy) to the AWS. Here we have an MFA working with the Google Authenticator app. So every Administrator has a password and MFA for login.
- Every User is in a group. In the group is the suitable policy for the users.
- In the IAM password Policy you can define your own rules.
- Define your own “IAM users sign-in link” -> https://ACCOUNT.signin.aws.amazon.com/console
After all now you have to see the following screen.
IAM Policy for Developers
Our Developers got access to their own EC2 instances for example. We set tags for all Resources.
- Developer can stop and start his own instance (Tag Project)
- Developer can create his own snapshots
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
{ "Version": "2012-10-17", "Statement": [ { "Action": "ec2:Describe*", "Resource": "*", "Effect": "Allow" }, { "Action": [ "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances" ], "Condition": { "StringEquals": { "ec2:ResourceTag/project": "PROJECTNAME" } }, "Resource": [ "arn:aws:ec2:eu-central-1:111111111:instance/*" ], "Effect": "Allow" }, { "Action": [ "ec2:CreateSnapshot", "ec2:CreateTags" ], "Effect": "Allow", "Resource": "*" } ] } |
Secure VPC Setup with VPN
VPC is the Virtual Private Cloud in AWS. It is a logically isolated section in the AWS cloud. We defined our VPC in the region of Frankfurt. Our VPC is divided in 4 subnets.
2 public and 2 private. The subnets are in different AZs (Availability Zones), so we have the opportunity of redundance for our services.
For a secure hybrid cloud environment you need a VPN connection to your VPC. We have a Sophos Firewall for our VPN connection.
Customer Gateway
You have to create one customer gateway with the IP address of the external interface of your gateway. If your gateway supports BGP you can use dynamic routing, otherwise static.
Virtual Private Gateway
On the AWS side you have to create an VGW and attach this one to your created VPC.
VPN Connection
With your CG and VGW you can create the VPN connection
After the configuration in AWS you have to setup the config file on your firewall/gateway on premise.
With “Download Configuration” you can download the right configuration for your appliance. AWS offers for known appliances the suitable config.
Now you have to upload the config to your firewall.
In Tunnel Details you can see the status:
In the route tables you have to set rules from your on premise routes to connect with the internal subnets of the AWS.
The target should be your created VGW.
It has to look like this:
In a VPC there are two security layers – “Network ACLs” and “Security Group”.
The NACLs are the first layer. In this layer you can define the port release for your VPC. SGs are the second layer in which you make the port release directly for the EC2 Instances or other services.
Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it’s applied regardless of any higher-numbered rule that may contradict it.
For example:
The created EC2 Instances get are getting a defined “Standard Security Group”. So a few ports you always need, like SSH (22) or RDP (3389) are opened per default. We defined our security group only for internal access from our on premise LAN.
This are the first steps for a secure access to your AWS cloud datacenter.
Here is an example for our first cloud native app “sprIT” in the AWS.
Be safe! 🙂
Recent posts






Comment article