Hi and welcome to the 10th Lecture. Today, we will discuss useful topics like the acceptable use policy compliance and the shared responsibility model. After that, we're going to close all the gaps that we may have left in our infrastructure. The acceptable use policy declares that you will not use AWS for any illegal activity or offensive use basically things like virus development and seeding child pornography and invasions of privacy are prohibited. Not big news in this topic.

Security violation things start to get more interesting for us. Things like unauthorized access and penetration testing of your system's vulnerabilities are prohibited as well. Network abuse defines that things like monitoring or crawling, denial of service, intentional interference, services like open proxies and open mail relays are prohibited as well.

This topic, like the last one, prohibits things like distributing, publishing, sending, or facilitating the sending of unsolicited mass email, A.K.A spam messages. By the way, AWS makes you request access before using their simple email service, SES. This topic is not part of the acceptable use policy but since it can be misunderstood, AWS has defined some explicit rules for how you can conduct penetration tests.

AWS has many exclusive security clearance levels to control access to their data centers. By the way, even the location of the data centers, I mean things like street name are top classified and only a very few employees are even aware of their precise locations. During an audit of your AWS environment, you just need to secure and document your side of the deal.

AWS has all the documentation for their side, and that is when the shared responsibility starts to make sense. You see, the very low level hardware parts like networking and storage are AWS responsibility. It is AWS that secures the physical infrastructure.

On the other side, you as a certified Sys-Ops candidate are responsible for securing access to and from your AWS resources, and the data that your resources are holding or processing. So with this in mind, there are a few things in our infrastructure that need to be reviewed and a few security breaches that need to be closed, and we're going to do that in this lecture.

First of all, let's go to our VPC and review our configuration. In the routing tables, we need to be sure that our private subnets have a private routing table. This means that they should not have access to an internet gateway like the default route table has by default.

Even if we didn't define a routing table for the network it would use the main routing table by default. So we need to ensure that our private route has access only to private resources located on the VPC. We could close down our subnets even more by using network ACLs. By default VPC has one that's open to the world. We could restrict the access on this level. But for me the best way to restrict access is using security groups.

I left some gaps in our infrastructure, so now it's time to close them. First of all our web servers are open to the world both via SSH and HTTP ports, and that's not desirable because anybody could access our instances via SSH. Also if someone somehow gets the IP address of one of the instances, he would be able to access the instance directly without passing through our ELB first.

Let me name the groups and show you what I'm talking about. In the RDS security group only the instances inside the web server's security group can access the RDS instances. Access is being granted via a security group identifier which is the way it should be. Our ELB is receiving HTTP and ICMP data from the world. I opened the ICMP ports to collect the custom metrics that we sent before to Cloud Watch. Since I don't want to send it anymore, I will remove this rule, and we're almost set here.

We now only need to secure access to the web server instances. We want to ensure that all traffic will come from the ELB to the instances, and that no direct access should be allowed. However, after a very basic check, we will see this flaw. Let me show you.

I will copy this URL and access it in another tab. Now let me copy the public DNS address of one of the instances to show that it's accessible as well.

Right now we are accessing the instance directly. Let's close this access down by changing the HTTP rule on the web server's security group. I will also remove the SSH rule from here. We don't need that, and in here. I will specify the ELB security group and in a few seconds this rule will be in place.

Notice that I can't access the instance directly anymore. The same doesn't happen when we access the portal via the ELB URL.

If for some reason, like troubleshooting, we want to have access to the instances via SSH or RDP in case of Windows instances. We should create a bastion host in one of the public subnets and configure a security group to allow SSH or RDP access only for this instance, and allow the web servers to communicate only with the instances of the bastion security group.

Now that I've created all the required security group entries, we could launch a new instance like we do with any other simple instance and put it in the right subnet and in the right security group.

We should leave this instance stopped and only start it when we want to see what's going on inside our instances. But as we've said before, this configuration is more common with Windows environments. I hope you enjoyed this. See you on the next lecture.

Lectures:

• AWS SysOps Administrator Roles and Responsibilities
• Initial Application Setup
• Troubleshooting
• Managing instances
• Deploying an Elastic Load Balancer
• Complete the Elastic infrastructure
• Infrastructure monitoring with CloudWatch
• Industry standards
• Application Security
• The AWS Shared Responsibility Model
• Elastic Beanstalk