Prerequisite: Network Guardrails for AWS
Security Group Guardrails builds on the definitions and capabilities outlined in Network Guardrails for AWS. Please read that document first and use it as a reference throughout this guide.
Introduction to AWS Security Groups
Security groups act as virtual firewalls for instances launched within an AWS VPC. Instances can be associated with up to 5 security groups and because security groups act at the instance level and not the subnet level, different sets of security groups can be applied to instances inside the same subnet – allowing creation of resource zones.
Security group characteristics:
- Security groups specify allow rules, but not deny rules.
- Security groups specify separate rules for inbound and outbound traffic.
- By default, a security group has no inbound rules. Therefore, no inbound traffic is allowed until inbound rules are added to the security group.
- If a security group has no outbound rules, no outbound traffic is allowed. (Warning: AWS adds a default egress all rule to all new security groups.)
- Security groups are stateful — when a request is sent from an instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to approved inbound traffic are allowed to flow out, regardless of outbound rules.
- Instances associated with a security group can't talk to each other unless rules are added allowing it.
- Security groups are associated with network interfaces. Changing the security groups associated with the instance changes the security groups associated with the primary network interface (eth0). Instances can also be associated with additional network interfaces with separate sets of security groups.
Security Group Automation & Control in Turbot Guardrails
Control requirements over security groups vary widely between customers, applications and even application environments. In some cases, they are strictly controlled with no modification available to application teams. Other times, security groups are managed by the application team directly within guardrails defined centrally.
To support these cases, Turbot Guardrails offers multiple degrees of automation:
Turbot Guardrails Security Group Architecture
Overview
Common, simple security groups are intended to provide a secure, easily understood starting point for boundary protection and dynamic isolation of application components. Common security groups do not aim to solve every scenario, applications are expected to create specific, custom security groups according to their specific application requirements & security needs.
Turbot Guardrails security group model should make it simple to implement core security design goals:
- Full application isolation, even inside the intranet.
- Within-application security across outward and inward facing subnets.
- Bastion level access by administrators.
- Trusted sub-networks.
Security Groups – Purpose
Turbot Guardrails provides standard security groups to meet common purposes – e.g. web, app and database patterns. This flexible, best practice core suits many application teams and provides a great balance between security and ease of use.
Note that the Purpose is consistent with Subnet Purpose as covered in Turbot Network Guardrails for AWS. This relationship allows Turbot Guardrails to make appropriate automation and guardrail decisions both in the creation and use of security groups – e.g. web_* security groups can only be used with resources in subnets with a web purpose.
Turbot Guardrails encourages the use of standard ports by default – this reduces application complexity and the learning curve for developers. Here is our recommendation which covers most use cases:
Custom security groups can be highly specific, but standard security groups should be simple and flexible enough to understand. Otherwise users reduce security through arbitrary application of rules.
Security Groups – Source
The Purpose maps out functionality, but to be effective security groups need to carefully manage the source of access. For standard security groups, Turbot Guardrails uses the Network Security Zones as defined in Turbot Network Guardrails for AWS:
- Public – CIDR ranges for the Internet
- Intranet – CIDR ranges for the organizations Intranet
- Trusted – Dynamically calculated list of CIDR ranges for Subnets in this VPC and it’s peered VPCs that are not publicly accessible (see Private below)
- Private – Dynamically calculated list of CIDR ranges for Subnets in the VPC that are not publicly accessible (i.e. all except DMZ and Public Subnet Types).
- Bastion – CIDR ranges for trusted bastion servers
- Pair – Security group reference, allowing paired resources to communicate
Turbot Guardrails Security Groups – {purpose}_{source}
Turbot Guardrails automatically manages a standard set of security groups for the VPC.
By combining the Purpose and the Source, and considering the Subnet Types used in the VPC, a standard set of security groups is calculated and applied. For example:
- web_intranet: Access to web ports (80/443) from within the intranet.
- web_public: Access to web ports (80/443) from the Internet.
- db_private: Access to the database from within the VPC.
Application stacks can then use combinations of these to create secure configurations. For example, a common Intranet application:
- Intranet facing load balancer: web_intranet
- Intranet facing web server: web_intranet
- Application server only accessed within a VPC: app_private
- Database server only accessed within a VPC: db_private
Turbot Guardrails Security Groups – {purpose}_pair
In some cases, we wish to pair servers for access, making them more specifically connected than the functional groups provide. For example, a DMZ based Elastic Load Balancer can be paired with an Intranet based Web server for specific access.
Turbot Guardrails provides pair security groups for this purpose:
- web_pair: All resources with the web_pair security groups allow inbound access to web ports (80,443) from other instances in the web_pair security group.
- db_pair: e.g. All Oracle databases sharing db_pair can communicate with each other on port 1521.
- app_pair: e.g. Would allow an application load balancer to talk to all app server instances sharing the app_pair security group.
The pair security group is defined with ingress & egress rules to itself for the specific function. For example, web_pair is defined as:
- Allow ingress on TCP-80 from the web_pair security group.
- Allow ingress on TCP-443 from the web_pair security group.
- Allow egress on TCP-80 to the web_pair security group.
- Allow egress on TCP-443 to the web_pair security group.
An outward facing web site can make use of pairing to allow communication across the DMZ. Note that without the web_pair connection this outward facing load balancer has no access to any resources in the VPC.
- Public facing load balancer in outward facing subnets: web_public & web_pair.
- Web server in inward facing subnets: web_pair.
- App server in inward facing subnets: app_private.
- DB server in inward facing subnets: db_private.
Pairs can be used throughout the stack to prevent any unwanted access. For example, to prevent the Web server having any possible access to the DB server use this model:
- Public facing load balancer in outward facing subnets: web_public & web_pair.
- Web server in inward facing subnets: web_pair & app_pair.
- App server in inward facing subnets: app_pair & db_pair.
- DB server in inward facing subnets: db_pair.
Pairs are simple, yet powerful. This functionality is enabled by the Turbot Guardrails best practice of separating each application into their own VPCs.
Turbot Guardrails Security Group Policies
Per the architecture above, Turbot Guardrails defines and manages common, best practice security groups. These groups are:
- Continuously enforced, preventing any drift from desired state.
- Defined centrally and automatically configured across accounts and VPCs.
- Automatically managed according to the subnet purpose.
- Connected with Turbot Guardrails for use by appropriate resources only.
Policies – Turbot Guardrails Security Groups
Turbot Guardrails Managed Security Groups are managed per:
- AWS > VPC > Security Group Standard Rules
Policies – Advanced Definitions
Turbot Guardrails Security Group definitions are built into Turbot Guardrails, no policies are available to modify them.
Policies – Advanced Security Group Management
Optionally, to help prevent conflicts and clarify management, each security group managed by Turbot Guardrails can have a defined prefix. By default, the prefix is empty to produce standard, short form names.
- AWS > VPC > Security Group Turbot Guardrails Name Prefix
The security group templates in Turbot Guardrails leverage keywords for both traffic sources and destinations – e.g. vpc, internet, intranet, bastion. Turbot Guardrails automatically interprets and expands these keywords into CIDR ranges or Security Group sources relative to the location of the security group. For example, vpc may become 10.1.0.0/24 in account aab while vpc may become 172.28.0.0/16 in account aac. As with the VPC policies, CIDR Range definitions default back to the Turbot > Network settings, but they can be set specifically in advanced cases with:
- VPC > Security Group Bastion CIDR Ranges
- VPC > Security Group Internet CIDR Ranges
- VPC > Security Group Intranet CIDR Ranges
Policies – Purpose Types
Customization of the ports for each Purpose is made available in
- {purpose} > Ports – Ingress ports to open.
- {purpose} > Sources – List of Subnet Types to enable for this Purpose.
Turbot Guardrails Managed Security Group Policies
Security Groups defined by the Customer can be automatically managed by Turbot Guardrails – providing extensibility to the Turbot Guardrails Security Groups model above.
Policies – Turbot Guardrails Managed Security Groups
Turbot Guardrails Managed Security Groups are managed per:
- AWS > VPC > Security Groups
Turbot Guardrails provides a simple YAML format to define security groups and manage them by policy. Customers may add as many rules as required, and they will be automatically adjusted and deployed by Turbot Guardrails for each VPC:
- VPC > Security Group Extended Rules
Policies – Advanced Security Group Management
Please see Turbot Guardrails Security Groups, Policies – Advanced Security Group Management. The process and rules for managed security groups are shared.
Security Group Policies
Security groups can be used and managed like any other resource. Application teams are granted permission to use security groups, with their configuration subject to guardrails defined in Turbot Guardrails.
Policies – Permissions for Security Group Management
Please see Managing Security Groups at Account level with VPC/* Rights below.
The “default” Security Group
So far in this guide we have focused on security groups with a specific purpose – e.g. web_intranet to allow web traffic from the intranet.
The default security group is created by AWS and cannot be deleted. Turbot Guardrails recommends it is carefully configured to act as a true default security group for your VPC resources. In many environments, it’s enforced as a required security group for EC2 servers.
In our tightly restricted network model, the default security group provides:
- Common egress rules (e.g. Active Directory, web).
- Security based ingress rules (e.g. security scanners, SSH, RDP).
Turbot Guardrails provides guardrails to ensure that the default security groups are always used appropriately, for example:
- EC2 instances in inward facing subnets MUST have the default security group.
Policies – Default Security Group
The default security group rules are initially defined by Turbot Guardrails, but usually require customization to the specific customer environment using:
- VPC > Security Group Default Rules
- VPC > Security Group Rules Manage Default
Managing Security Groups at Account level with VPC/* Rights
Policies – Permissions for Security Group Management
Security Groups are a difficult resource to define. Sometimes they are managed with resources (e.g. EC2 instances); and sometimes they are centrally controlled (e.g. Network Team).
Permission management for VPC Security Groups is defined by:
- AWS > VPC > Enabled
- AWS > VPC > Rights
- AWS > VPC > Security Group Management
But, because Security Groups are a subset of VPC, it’s also important to consider the impact of these policies on other VPC resource types. Management policies for other VPC resources must also be considered and reviewed:
- AWS > VPC > {resource} Management
Policies – Permissions if VPC & SG are both centrally managed
Block all VPC management by the application team, including management of security groups. Security groups can be used by the application team for their resources but cannot create or edit them. For this scenario, a best practice setup is:
- AWS > VPC > Enabled – Required: Disabled
- AWS > VPC > Rights – Required: Enabled if AWS > VPC > Enabled
Although the Management policies for the VPC are not used in this case (Rights is effectively disabled), it’s good practice to set them to match the AWS > VPC > Enabled posture:
- AWS > VPC > {resource} Management – Required: Enabled if AWS > VPC > Enabled
Policies – Permissions if VPC centrally managed, but SG managed by app team
This case requires all VPC management to be denied to the application team, except for security groups. To achieve this, we need to enable rights management but deny most resources from being managed.
- AWS > VPC > Enabled – Required: Disabled
- AWS > VPC > Rights – Required: Enabled
- AWS > VPC > Security Group Management – Required: Enabled
All other VPC resources must be denied management. As above, this is simplified through the reference to AWS > VPC > Enabled (which is set to Disabled):
- AWS > VPC > {resource} Management – Required: Enabled if AWS > VPC > Enabled
Policies – VPC & SG managed by app team
Per the definition in Network Guardrails for AWS, VPC permissions can be granted at Account level with:
- AWS > VPC > Enabled – Required: Enabled
- AWS > VPC > Rights – Required: Enabled if AWS > VPC > Enabled
- AWS > VPC > {resource} Management – Required: Enabled if AWS > VPC > Enabled
Approved Security Groups
Guardrails for customer managed Security Groups are defined with standard Turbot Guardrails resource policies and guardrails.
Note: All Turbot Guardrails Security Groups and Turbot Guardrails Managed Security Groups are skipped for the Approved guardrails. They are managed exactly through their definition instead.
Policies – Approved
Existence of the actual security group is subject to:
- VPC > Security Group Approved
- VPC > Security Group Approved Usage
Rules within the security group are subject to:
- VPC > Security Group Rules Approved
- VPC > Security Group Rules Approved Egress Blacklisted Ports
- VPC > Security Group Rules Approved Egress Minimum Bitmask
- VPC > Security Group Rules Approved Egress Restrict Maximum Port Range
- VPC > Security Group Rules Approved Egress Restrict To Sources
- VPC > Security Group Rules Approved Ingress Blacklisted Ports
- VPC > Security Group Rules Approved Ingress Minimum Bitmask
- VPC > Security Group Rules Approved Ingress Restrict Maximum Port Range
- VPC > Security Group Rules Approved Ingress Restrict To Sources
Tag management
Policies - Tags
As usual, Turbot Guardrails provides a standard model for automatic tagging of Security Group resources:
- VPC > Security Group Tags Template: Define the tags to be set on the resource.
- VPC > Security Group Tags: Skip, Check or Enforce the Template.
If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!