Open menu
-->

Create and Configure Data-Tier Security Group

Cloud Conformity allows you to automate the auditing process of this resolution page. Register for a 14 day evaluation and check your compliance level for free!

Start a Free Trial Product features
Security

Risk level: Medium (should be achieved)

Ensure there is an AWS security group created and configured for the data tier that grants inbound access from the app-tier security group on explicit TCP ports such as 3306 (MySQL, MariaDB and Amazon Aurora), 1433 (MSSQL), 1521 (Oracle SQL) and 5432 (PostgreSQL), to secure the access to your database instances. This conformity rule assumes that all AWS resources created within your data tier are tagged with <data_tier_tag>:<data_tier_tag_value>, where <data_tier_tag> is the tag name and <data_tier_tag_value> is the tag value. Prior to running this rule by the Cloud Conformity engine, the data-tier tags must be configured in the rule settings, on your Cloud Conformity account dashboard.

This rule resolution is part of the Cloud Conformity Security Package

To protect the database instances within your data tier from unauthorized access, a distinct security group must be created and configured to secure access by allowing traffic for specific database protocols and ports by referencing as source the security group associated with your app-tier.
Note 1: The database type used as example in this conformity rule is MySQL (TCP port 3306), however, depending on your AWS application design, any other database types and ports would apply.
Note 2: Make sure that you replace all <data_tier_tag>:<data_tier_tag_value> tag placeholders found in the conformity rule content with your own tag name and value created for the data tier.

Audit

To determine if there is a security group created and configured particularly for the data tier, perform the following actions:

Using AWS Console

01 Sign in to your Cloud Conformity console, access Create and Configure Data-Tier Security Group conformity rule settings and copy the tag set defined for AWS resources available within your data tier (e.g. <data_tier_tag>:<data_tier_tag_value>).

02 Sign in to the AWS Management Console.

03 Navigate to EC2 dashboard at https://console.aws.amazon.com/ec2/.

04 In the navigation panel, under NETWORK & SECURITY, click Security Groups.

05 Paste the tag set copied at step no. 1 in the Filter by tags and attributes or search by keyword box, then add a space before and after the separation colon (i.e. <data_tier_tag> : <data_tier_tag_value>) and press Enter. This filtering technique will return only the security groups tagged for the data tier. If no results are returned, there are no security groups tagged within your data tier and the audit process ends here. If the AWS console lists one or more security groups, continue the audit with the next step.

06 Select the security group that you want to examine.

07 Select the Inbound tab from the dashboard bottom panel.

08 On the Inbound panel, check the Type, Protocol, Port Range and Source attributes for each available inbound rule. For compliance, the security group must allow inbound connections from the app-tier security group on explicit TCP port 3306 (MySQL), i.e.

EC2 Inbound Tab

If there are no rules that allow inbound traffic from the app-tier security group on port 3306, the selected group does not qualify as compliant data-tier security group.

09 Repeat steps no. 6 – 8 to check other security groups, available in the selected region, for compliance.

10 Change the AWS region from the navigation bar and repeat steps no. 5 – 9 for other regions.

Using AWS CLI

01 Sign in to your Cloud Conformity console, access Create and Configure Data-Tier Security Group conformity rule settings and copy the tag set defined for AWS resources available in your data tier (e.g. <data_tier_tag>:<data_tier_tag_value>).

02 Run describe-db-instances command (OSX/Linux/UNIX) using custom query filters to list the names of all Amazon RDS database instances provisioned in the selected region:

aws rds describe-db-instances
	--region us-east-1
	--output table
	--query 'DBInstances[*].DBInstanceIdentifier'

03 The command output should return a table with the requested name(s):

----------------------------
|    DescribeDBInstances   |
+--------------------------+
|   cc-prod-app-database   |
+--------------------------+

04 Execute describe-db-instances command (OSX/Linux/UNIX) using the name of the database instance returned at the previous step as identifier and custom query filters to return the information about the security group associated with the selected instance:

aws rds describe-db-instances
	--region us-east-1
	--db-instance-identifier cc-prod-app-database
	--query "DBInstances[*].VpcSecurityGroups[]"

05 The command output should return the requested metadata (including the associated security group ID):

{
    "Status": "active",
    "VpcSecurityGroupId": "sg-aaaa1111"
}

06 Run describe-tags command (OSX/Linux/UNIX) using the ID of the security group returned at the previous step as parameter and custom query filters to describe the tags defined for the selected group:

aws ec2 describe-tags
	--region us-east-1
	--filters "Name=resource-id,Values=sg-aaaa1111"
	--query 'Tags[*].{Value:Value, Key:Key}'

07 The command request should return one of the following outputs:

  1. If the describe-tags command output returns an empty array (i.e. []), as shown in the example below, the verified security group is not tagged, therefore the audit process for the selected resource stops here:
    []
    
  2. If the command output returns a set of tags that is different than the one copied at step no. 1, as shown in the example below, the verified AWS security group does not belong to your data tier, therefore the audit process for the selected resource stops here:
    [
        {
            "Value": "Upgraded",
            "Key": "NO"
        }
    ]
    
  3. If the describe-tags command output returns a set of tags that match the one copied at step no. 1 (e.g. :), as shown in the example below, the verified Amazon security group is tagged as a data-tier resource, therefore the audit process continues with the next step:
    [
        {
            "Key": "<data_tier_tag>",
            "Value": "<data_tier_tag_value>"
        }
    ]
    

08 Run describe-security-groups command (OSX/Linux/UNIX) using the ID of the AWS security group that you want to examine as identifier and custom filtering to determine whether the selected security group is compliant or not. For compliance, the group must allow connections from the app-tier security group on explicit TCP port 3306 (MySQL):

aws ec2 describe-security-groups
	--region us-east-1
	--group-ids sg-aaaa1111
	--query 'SecurityGroups[*].IpPermissions[]'

09 The command output should return the inbound rules associated with the selected security group:

[
    {
        "IpProtocol": "-1",
        "PrefixListIds": [],
        "IpRanges": [
            {
                "CidrIp": "0.0.0.0/0"
            }
        ],
        "UserIdGroupPairs": [],
        "Ipv6Ranges": []
    }
]

If there are no rules that grant inbound traffic from the app-tier security group on TCP port 3306, i.e. the "UserIdGroupPairs" attribute value does not contain the ID of another group (e.g. GroupId": "sg-aabbccdd"), the selected AWS resource does not qualify as compliant data-tier security group.

10 Repeat step no. 4 – 9 to verify other security groups associated with the database instance (if any), available in the selected region, for compliance.

11 Change the AWS region by updating the --region command parameter value and repeat steps no. 2 – 10 to perform the entire audit process for other regions.

Remediation / Resolution

To create a compliant Amazon data-tier security group and configure it to allow inbound traffic from the app-tier security group on explicit port (in this case TCP port 3306), perform the following:

Using AWS Console

01 Sign in to your Cloud Conformity console, access Create and Configure Data-Tier Security Group conformity rule settings and copy the tag set configured for AWS resources available in your data tier (e.g. <data_tier_tag>:<data_tier_tag_value>).

02 Sign in to the AWS Management Console.

03 Navigate to EC2 dashboard at https://console.aws.amazon.com/ec2/.

04 In the navigation panel, under NETWORK & SECURITY, choose Security Groups.

05 To replace the existing security group with a compliant data-tier security group and assign it to your RDS database instance(s), you need to create and configure a new security group. To create the required data-tier security group, click Create Security Group button from the dashboard top menu.

06 Inside Create Security Group dialog box, perform the following:

  1. In the Security group name box, enter a name for your new data-tier security group. Use the naming conventions recommended for this type of AWS resource.
  2. In the Description box, provide a description to reflect the resource usage.
  3. From the VPC dropdown list, select the ID of the appropriate Virtual Private Cloud.
  4. Select the Inbound tab and click the Add Rule button to create a new inbound rule.
  5. To define the necessary inbound rule, provide the following information:
    • Choose MYSQL/Aurora from the Type dropdown list to select the predefined ingress rule configuration available for MySQL-based databases.
    • In the Source section, select Custom and enter the ID of the appropriate app-tier security group (e.g. sg-aabbccdd).
    • Provide a short description for the newly added rule within Description box.
  6. Click Create to deploy your new data-tier security group.

07 Select the newly created resource and choose the Tags tab from the bottom panel.

08 On the Tags panel, click Add/Edit Tags button to add the tags that will help organize the identity of the new security group within the data tier.

09 In the Add/Edit Tags dialog box, click Create Tag button and use the following format when you define your own tag set: <data_tier_tag>:<data_tier_tag_value> and ensure that the tag name (<data_tier_tag>) and the tag value (<data_tier_tag_value>) match the tag set used to organize your data-tier resources, copied at step no. 1. Once your tags are defined, click Save to apply the changes.

10 Once the compliant security group is created and configured, it is safe to replace the source security group with the new one within the RDS database instance(s) configuration. To replace the required resource, perform the following actions:

  1. Navigate to RDS dashboard at https://console.aws.amazon.com/rds/.
  2. In the navigation panel, under Amazon RDS section, choose Instances.
  3. Choose the RDS database instance that you want to reconfigure then click on its name (link).
  4. Scroll down to the Details section then click the Modify button.
  5. In the Network & Security configuration box, remove the noncompliant security group by clicking the x button next to its name, then select the new security group, created at step no. 6, from the Security group dropdown list.
  6. Once the security group is replaced within the instance configuration, click Continue.
  7. On Modify DB Instance: <instance_name> page, in the Scheduling of Modifications section, choose whether to apply the changes immediately or wait and apply them automatically during the next scheduled maintenance window.
  8. Click Modify DB Instance to complete the reconfiguration process.

11 If required, change the AWS region from the navigation bar and repeat the entire remediation process for other regions.

Using AWS CLI

01 Sign in to your Cloud Conformity console, access Create and Configure Data-Tier Security Group conformity rule settings and copy the tag set configured for AWS resources available in your data tier (e.g. <data_tier_tag>:<data_tier_tag_value>).

02 Run create-security-group command (OSX/Linux/UNIX) to set up the compliant AWS security group and configure it to allow ingress traffic from the app-tier security group on TCP port 3306 (MySQL). The following command example creates a security group called "security-group-us-east-1-p-data-tier", inside a VPC identified with the ID vpc-12345678, available within US East region:

aws ec2 create-security-group
	--region us-east-1
	--group-name security-group-us-east-1-p-data-tier
	--description "Data-Tier Custom Security Group"
	--vpc-id vpc-12345678

03 The command output should return the new security group ID:

{
    "GroupId": "sg-aabb1122"
}  

04 Run authorize-security-group-ingress command (OSX/Linux/UNIX) using the group ID returned at the previous step as identifier to create the required inbound rule. The following command example creates a new inbound rule that allows inbound traffic from the app-tier security group identified by the ID "sg-aabbccdd", on TCP port 3306, within the data-tier security group created at the previous step and identified by the ID "sg-aabb1122", within US East region (the command does not return an output):

aws ec2 authorize-security-group-ingress
	--region us-east-1
	--group-id sg-aabb1122
	--protocol tcp
	--port 3306
	--source-group sg-aabbccdd

05 Run create-tags command (OSX/Linux/UNIX) using the ID of the newly created data-tier security group as identifier to create tags for managing the identity of the new resource. Use the following format when you define your own tag set: <data_tier_tag>:<data_tier_tag_value> and make sure the tag name (<data_tier_tag>) and the tag value (<data_tier_tag_value>) match the tag set used to organize your data-tier resources, copied at step no. 1. Replace <data_tier_tag> and <data_tier_tag_value> (highlighted) with your own values (the command does not produce an output):

aws ec2 create-tags
	--region us-east-1
	--resources sg-aabb1122
	--tags Key=<data_tier_tag>,Value=<data_tier_tag_value>

06 Run modify-db-instance command (OSX/Linux/UNIX) using the name of the RDS database instance as identifier and the compliant data-tier security group ID as parameter to replace the existing security group with the new one created at step no. 2, in the configuration of the selected Amazon RDS instance. Use --apply-immediately parameter to apply the changes asynchronously and as soon as possible and --no-apply-immediately to apply them during the next scheduled maintenance window:

aws rds modify-db-instance
	--region us-east-1
	--db-instance-identifier cc-prod-app-database
	--vpc-security-group-ids sg-aabb1122
	--no-apply-immediately

07 The command output should return the modified database instance metadata:

{
    "DBInstance": {
        "LicenseModel": "general-public-license",
        "VpcSecurityGroups": [
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-aabb1122"
            }
        ],
        "OptionGroupMemberships": [
            {
                "Status": "in-sync",
                "OptionGroupName": "default:mysql-5-6"
            }
        ],
 
        ...
 
        "Engine": "mysql",
        "MultiAZ": false,
        "DBInstanceStatus": "available",
        "EngineVersion": "5.6.27",
        "AvailabilityZone": "us-east-1a",
        "DomainMemberships": [],
        "StorageType": "gp2",
        "CACertificateIdentifier": "rds-ca-2015",
        "StorageEncrypted": false,
        "DBInstanceClass": "db.m3.large",
        "DBInstanceIdentifier": "cc-prod-app-database"
    }
}         

08 If required, change the AWS region by updating the --region command parameter value and repeat steps no. 2 – 7 to perform the entire process for other regions.

References

Publication date Sep 5, 2016