The Subnets Associations Tab – Configuring Infrastructure Security – SCS-C02 Study Guide

The Subnets Associations Tab

This section shows which subnets are associated with this NACL, and as mentioned when discussing subnets, you can have multiple subnets associated with a single NACL, but only a single NACL can be associated with a subnet:

Figure 10.20: The NACL Subnet associations screen

If you fail to associate your NACL with the correct subnets, then your subnet might not have the appropriate security safeguards in place and could allow unwanted network traffic to be processed. Additionally, your NACLs could be created and configured but not associated with any subnet, providing no security measures.

The Tags tab, as previously discussed, helps you create key-value pairs that can be associated with your NACL.

Now that you know how to control security at the subnet/network level, you are ready to move on to a layer that operates at the instance level: security groups.

The Role of Security Groups in VPC Security

Security groups are much like NACLs in that they provide a virtual firewall level of protection but at the instance level rather than the network level. Security groups are associated with instances rather than subnets and control the traffic to and from your instances within your VPC. Again, only a single security group can be applied to an instance, but the same security group can be associated with multiple instances.

Security groups allow for stateful traffic, meaning that if the traffic is allowed in via the rules, then it is returned, notwithstanding any rules in place. You can specify inbound traffic rules based on a combination of port, IP range, or another security group. There are also other subtle differences between NACLs and security groups within the rule base. The following subsections will take you through the security group tabs.

The Details Tab

The Details tab provides an overview of the security group, showing the security group ID, the name of the security group, its VPC association, and the rule counts—both inbound and outbound:

Figure 10.21: The security group Details screen

To review the security setup of a security group, examine the inbound and outbound rulesets.

The Inbound Rules and Outbound Rules Tabs

The following screenshot shows the inbound traffic rules associated with this security group:

Figure 10.22: Security group inbound rules screen

Figure 10.21 contains six fields of pertinent information:

• Security group rule ID: This is the unique ID/identifier for the security group.
• IP version: This shows if the rule only works for a particular type of IP address, such as IPv4 or IPv6.
• Type: This represents the type of protocol that you would like to open up to network traffic (for example, HTTPS).
• Protocol: This shows the protocol associated with the type.
• Port Range: This shows the port range of the protocol. If using a customer Type and Protocol, you can manually enter the port range.
• Source: Much like the Source entry with your route tables/NACL, this can be a network subnet CIDR range, a single IP address using a /32 mask, all exposure to traffic from anywhere using the 0.0.0.0/0 CIDR, or another security group ID. Security groups can give access to each other by providing another security group ID from the same VPC as the source.

Notice that there is no field for Allow or Deny as with NACLs. This is because security groups only provide Allow rules by default. Therefore, if a rule is in a security group, it is considered allowed. If a match for traffic is not found within the security group, then the traffic is simply dropped. Also, there is no Rule number field. This is because all rules are evaluated by the security group before a decision is made about whether access should or should not be allowed.