In this video on AWS cloud security, Jeff Winesett introduced how to setup and use AWS Security Groups, which act as firewalls for AWS applications.
- [Instructor] AWS Security Groups are the virtual firewalls in the cloud that allowed control of the inbound and outbound traffic on certain resources. Security groups determine who can communicate with resources that belong to that group. Traffic rules can be set up once and then applied to multiple resources. Resources can be assigned to multiple security groups, allowing the flexibility to mix and match security groups with resources to fit differing business security management needs.
Security groups are required for those resources that use them. And as such, AWS will define a default security group if no other security group is specified for the resource. By default, these security groups are initially configured with the most restrictive rules allowing no access. Many AWS resource types make use of security groups. Security groups are specified for most all resources that can take in direct ingress traffic.
A security group is a set of rules created to control the inbound and outbound traffic to a resource. These rules are composed of a traffic type, underlying protocol, a port or range of ports, and a source. The traffic type is the primary traffic protocol that is open to the network traffic such as SSH, RDP, or HTTPS. The actual underlying protocol is usually fixed by the traffic type chosen.
For example, choosing traffic type of HTTP fixes the protocol to TCP. There are additional choices for custom ICMP rules. Port ranges can be used to specify one or more ports that are open for the traffic. The source of the traffic can be set by specifying either an IP address or another security group which allows traffic to be restricted to other resources that are in that security group. When specifying an IP address for the source, the classless internet domain routing notation is used, referred to as CIDR or pronounced cedar.
It is a notification for specifying IP addresses and their associated routing prefix by appending a slash character followed by the number of leading bits of the routing prefix. Here are some examples of this notation, ranging from the most restrictive to the least restrictive and how the prefix determines the matched set on the IP address. This is a typical web-based application with a web server layer, an app server layer, and a database layer.
The requirements for this application are to limit inbound traffic as much as possible to each resource, but allow an admin from a specific IP address to externally access the resources for maintenance purposes. Here is a visual representation of one solution. The solution has made use of a bastion host which is a fairly well-known security practice that uses a special hardened server solely for the purpose of allowing the good guys into the network but keeping the bad guys out.
All HTTP traffic to port 80 is being allowed on the web server. Only one specific IP address is allowed access to port 22 via the SSH protocol and only from the bastion host. This host then allows SSH access on port 22 to the other resources. Each resource is allowed to connect to each other, but only via the allowed ports 6081 on the app server and 3306 on the DB server.
Otherwise, all other inbound traffic should be denied and blocked by a security group. Now, all of this needs to be translated to security group rules. Starting at the top, we are allowing one specific IP address access to port 22 over SSH on the bastion host. And from there, all other resources allow port 22 over SSH from the bastion host. The DB allows TCP traffic on port 3306 from the app server and the app server allows TCP traffic over 6081 from the web server.
And the web server allows traffic over HTTP into port 80 from everyone. So, keeping things secure lesson number three. Use security groups to control the inbound and outbound traffic to AWS resources and follow the principle of least privilege when defining your rules.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures