Preparing For AWS Solution Architect Certifications – Network Security
After showing the principles of AWS networking with VPC and Routing, it’s time to dive into VPC network security introducing ACL, Security Groups Flow Logging, and Best Practices.
When you start using a cloud provider it’s important to keep in mind some security concepts that must keep in mind:
- Security of the cloud: AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud
- Security in the cloud: Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/security.html
Data protection in the VPC
AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. This content includes the security configuration and management tasks for the AWS services that you use.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual user accounts with AWS Identity and Access Management (IAM). It’s recommended to secure data in the following ways:
- Use multi-factor authentication (MFA) with each account.
- Use SSL/TLS to communicate with AWS resources. (Recommend TLS 1.2 or later)
- Set up API and user activity logging with AWS CloudTrail.
- Use AWS encryption solutions, along with all default security controls within AWS services.
- Use advanced managed security services such as Amazon Macie, which assists in discovering and securing personal data that is stored in Amazon S3.
- If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command-line interface or an API, use a FIPS endpoint
AWS provides secure and private connectivity between EC2 instances of all types. In addition, some instance types use the offload capabilities of the underlying hardware to automatically encrypt in-transit traffic between instances, using AEAD algorithms with 256-bit encryption. There is no impact on network performance. ( Furthers: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit )
Source: https://docs.aws.amazon.com/vpc/latest/userguide/data-protection.html
Infrastructure Security in Amazon EC2
As a managed service, Amazon EC2 is protected by the AWS global network security procedures.
Network Isolation: A virtual private cloud (VPC) is a virtual network in your own logically isolated area in the AWS Cloud. Use separate VPCs to isolate infrastructure by workload or organizational entity. A subnet is a range of IP addresses in a VPC. When you launch an instance, you launch it into a subnet in your VPC. Use subnets to isolate the tiers of your application (for example, web, application, and database) within a single VPC. Use private subnets for your instances if they should not be accessed directly from the internet.
Isolation on physical hosts: Different EC2 instances on the same physical host are isolated from each other as though they are on separate physical hosts. The hypervisor isolates CPU and memory, and the instances are provided virtualized disks instead of access to the raw disk devices. When you stop or terminate an instance, the memory allocated to it is scrubbed (set to zero) by the hypervisor before it is allocated to a new instance. Network MAC addresses are dynamically assigned to instances by the AWS network infrastructure. IP addresses are either dynamically assigned to instances by the AWS network infrastructure, or assigned by an EC2 administrator through authenticated API requests. The AWS network allows instances to send traffic only from the MAC and IP addresses assigned to them. Otherwise, the traffic is dropped.
Controlling network traffic: Consider the following options for controlling network traffic to your EC2 instances:
- Restrict access to your instances using security groups.
- Use private subnets for your instances if they should not be accessed directly from the internet (Use a bastion host or NAT gateway for internet access from an instance in a private subnet)
- Use AWS Virtual Private Network or AWS Direct Connect to establish private connections from your remote networks to your VPCs.
- Use VPC Flow Logs to monitor the traffic that reaches your instances.
- Use AWS Security Hub to check for unintended network accessibility from your instances.
- Use EC2 Instance Connect to connect to your instances using SSH without the need to share and manage SSH keys.
- Use AWS Systems Manager Session Manager to access your instances remotely instead of opening inbound SSH ports and managing SSH keys.
- Use AWS Systems Manager Run Command to automate common administrative tasks instead of opening inbound SSH ports and managing SSH keys.
Source: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/infrastructure-security.html
Internetwork traffic privacy in Amazon VPC
Amazon Virtual Private Cloud provides features that you can use to increase and monitor the security for your virtual private cloud (VPC):
- Security groups: act as a firewall for associated Amazon EC2 instances (computing isolated instances) controlling both inbound and outbound traffic at the instance level.
- Network access control lists (ACLs): act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level.
- Flow logs: capture information about the IP traffic going to and from network interfaces in your VPC
- Traffic mirroring: copy network traffic from an elastic network interface of an Amazon EC2 instance
You can use AWS Identity and Access Management (IAM) to control who in your organization has permission to create and manage security groups, network ACLs, and flow logs.
Comparison of security groups and network ACLs:
Security group | Network ACL |
Operates at the instance level | Operates at the subnet level |
Supports allow rules only | Supports allow rules and deny rules |
Is stateful: Return traffic is automatically allowed, regardless of any rules | Is stateless: Return traffic must be explicitly allowed by rules |
We evaluate all rules before deciding whether to allow traffic | We process rules in order, starting with the lowest numbered rule when deciding whether to allow traffic |
Applies to an instance only if someone specifies the security group when launching the instance, or associates the security group with the instance later on | Automatically applies to all instances in the subnets that it’s associated with (therefore, it provides an additional layer of defense if the security group rules are too permissive) |
Security Groups
A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign up to five security groups to the instance. Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC can be assigned to a different set of security groups.
For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic. The following are the basic characteristics of security groups for your VPC:
- You can specify allow rules, but not deny rules.
- You can specify separate rules for inbound and outbound traffic.
- Security group rules enable you to filter traffic based on protocols and port numbers.
- Security groups are stateful
- When you create a new security group, it has no inbound rules
- By default, a security group includes an outbound rule that allows all outbound traffic
- There are quotas on the number of security groups that you can create per VPC, the number of rules that you can add to each security group, and the number of security groups that you can associate with a network interface
- Instances associated with a security group can’t talk to each other unless you add rules allowing the traffic
- Security groups are associated with network interfaces. After you launch an instance, you can change the security groups that are associated with the instance, which changes the security groups associated with the primary network interface (eth0). You can also specify or change the security groups associated with any other network interface
- When you create a security group, you must provide it with a name and a description. The following rules apply:
- Names and descriptions can be up to 255 characters in length
- Names and descriptions are limited to the following characters: a-z, A-Z, 0-9, spaces, and ._-:/()#,@[]+=&;{}!$*.
- When the name contains trailing spaces, we trim the spaces when we save the name.
- A security group name cannot start with sg- as these indicate a default security group.
- A security group name must be unique within the VPC.
- A security group can only be used in the VPC that you specify when you create the security group.
Your VPC automatically comes with a default security group. If you don’t specify a different security group when you launch the instance, we associate the default security group with your instance.
You can add or remove rules for a security group. A rule applies either to inbound traffic (ingress) or outbound traffic (egress). The following are the basic parts of a security group rule in a VPC:
- (Inbound rules only) The source of the traffic and the destination port or port range. The source can be another security group, an IPv4 or IPv6 CIDR block, a single IPv4 or IPv6 address, or a prefix list ID.
- Outbound rules only) The destination for the traffic and the destination port or port range. The destination can be another security group, an IPv4 or IPv6 CIDR block, a single IPv4 or IPv6 address, or a prefix list ID.
- Any protocol that has a standard protocol number
- An optional description for the security group rule to help you identify it later.
- If you add a security group rule using the AWS CLI, the console, or the API, we automatically set the source or destination CIDR block to the canonical form
When you specify a CIDR block as the source for a rule, traffic is allowed from the specified addresses for the specified protocol and port. When you specify a security group as the source for a rule, traffic is allowed from the network interfaces that are associated with the source security group for the specified protocol and port.
If your VPC has a VPC peering connection with another VPC, a security group rule can reference another security group in the peer VPC.
If the owner of the peer VPC deletes the referenced security group, or if you or the owner of the peer VPC deletes the VPC peering connection, the security group rule is marked as stale.
You can’t use the security groups that you’ve created for use with EC2-Classic with instances in your VPC. You must create security groups specifically for use with instances in your VPC. The rules that you create for use with a security group for a VPC can’t reference a security group for EC2-Classic, and vice versa.
Any VPC created using an API version older than 2011-01-01 has the 2009-07-15-default security group. This security group exists in addition to the regular default security group that comes with every VPC. You can’t attach an internet gateway to a VPC that has the 2009-07-15-default security group. Therefore, you must delete this security group before you can attach an internet gateway to the VPC.
AWS Firewall Manager simplifies your VPC security groups administration and maintenance tasks across multiple accounts and resources. With Firewall Manager, you can configure and audit your security groups for your organization from a single central administrator account.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
Network ACL
A network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets.
The following are the basic things that you need to know about network ACLs:
- Your VPC automatically comes with a modifiable default network ACL. By default, it allows all inbound and outbound IPv4 traffic and, if applicable, IPv6 traffic.
- You can create a custom network ACL and associate it with a subnet. By default, each custom network ACL denies all inbound and outbound traffic until you add rules.
- Each subnet in your VPC must be associated with a network ACL. If you don’t explicitly associate a subnet with a network ACL, the subnet is automatically associated with the default network ACL.
- You can associate a network ACL with multiple subnets.
- A network ACL contains a numbered list of rules. We evaluate the rules in order, starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL.
- A network ACL has separate inbound and outbound rules, and each rule can either allow or deny traffic.
- Network ACLs are stateless, which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).
The following are the parts of a network ACL rule:
- Rule number.
Type. (for example, SSH or a custom range). - Protocol.
- Port range.
- Source.
- Destination.
- Allow/Deny.
The default network ACL is configured to allow all traffic to flow in and out of the subnets with which it is associated. If you create a VPC with an IPv6 CIDR block or if you associate an IPv6 CIDR block with your existing VPC, we automatically add rules that allow all IPv6 traffic to flow in and out of your subnet.
If you create a custom network ACL, be aware of how it might affect resources that you create using other AWS services.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
How Amazon VPC works with IAM
Resource-based policies are JSON policy documents that specify what actions a specified principal can perform on the Amazon VPC resource and under what conditions. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. When the principal and the resource are in different AWS accounts, you must also grant the principal entity permission to access the resource. Grant permission by attaching an identity-based policy to the entity
You can attach tags to Amazon VPC resources or pass tags in a request. To control access based on tags, you provide tag information in the condition element of a policy using the
1 |
ec2:ResourceTag/key-name, aws:RequestTag/key-name |
, or
1 |
aws:TagKeys |
condition keys.
An IAM role is an entity within your AWS account that has specific permissions. You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as AssumeRole or GetFederationToken.
Logging and Monitoring
You can use the following automated monitoring tools to watch components in your VPC and report when something is wrong:
- Flow logs: Flow logs capture information about the IP traffic going to and from network interfaces in your VPC.
- Monitoring NAT gateways: You can monitor your NAT gateway using CloudWatch, which collects information from your NAT gateway and creates readable, near real-time metrics.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/logging-monitoring.html
Resilience in a VPC
AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically failover between zones without interruption. In addition to the AWS global infrastructure, Amazon VPC offers several features to help support your data resiliency and backup needs.
VPC Compliance validation
Third-party auditors assess the security and compliance of Amazon Virtual Private Cloud as part of multiple AWS compliance programs. These include SOC, PCI, FedRAMP, DoD CCSRG, HIPAA BAA, IRAP, MTCS, C5, K-ISMS, ENS-High, OSPAR, and HITRUST-CSF.
Your compliance responsibility when using Amazon VPC is determined by the sensitivity of your data, your company’s compliance objectives, and applicable laws and regulations.