AWS WAF Security requirmeents
AWS – Ensure WebACL in the AWS WAF to determine access based on geo-location and whitelisted IPs
You can use geo match conditions with other AWS WAF Classic conditions or rules to build sophisticated filtering. For example, if you want to block certain countries, but still allow specific IP addresses from that country, you could create a rule containing a geo match condition and an IP match condition. Configure the rule to block requests that originate from that country and do not match the approved IP addresses.
Implement the steps discussed below
To create a geo match condition:
Sign in to the AWS Management Console and open the AWS WAF console at https://console.aws.amazon.com/wafv2/.
In the navigation pane, choose Geo match.
Choose Create condition.
Enter a name in the Name field. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: _-!”#`+*},./ . You can’t change the name of a condition after you create it.
Choose a Region.
Choose a Location type and a country. Location type can currently only be Country.
Choose Add location.
Choose Create.
References:
Working with geographic match conditions
2. AWS ALB
Security requirements
- AWS – Enable Access Logs
- AWS – Ensure communication to global resources is only through VPC endpoints or Privatelink
- AWS – Configure the security groups for your load balancers
- AWS – Use AWS WAF to allow or block requests based on the rules in a web access control list
- AWS – Configure an Application Load Balancer to securely authenticate users as they access your applications
Threats
| AWS – Confidential Data Exposure | Cloud environments face many of the same threats as traditional corporate networks, but due to the vast amount of data stored on cloud servers, providers become an attractive target. The severity of potential damage tends to depend on the sensitivity of the data exposed. Exposed personal financial information tends to get the headlines, but breaches involving health information, trade secrets, and intellectual property can be more devastating. When a data breach occurs, companies may incur fines, or they may face lawsuits or criminal charges. Breach investigations and customer notifications can rack up significant costs. Indirect effects, such as brand damage and loss of business, can impact organizations for years. Cloud providers typically deploy security controls to protect their environments, but ultimately, organizations are responsible for protecting their own data in the cloud. The CSA has recommended organizations use multifactor authentication and encryption to protect against data breaches. |
| AWS – Weak Identity, Credential and Access Management | Data breaches and other attacks frequently result from lax authentication, weak passwords, and poor key or certificate management. Organizations often struggle with identity management as they try to allocate permissions appropriate to the user’s job role. More importantly, they sometimes forget to remove user access when a job function changes or a user leaves their organization. Multifactor authentication systems such as one-time passwords, phone-based authentication, and smartcards, protect cloud services because they make it harder for attackers to login with stolen passwords. The Anthem breach, which exposed more than 80 million customer records, was the result of stolen user credentials. Anthem had failed to deploy multifactor authentication, so once the attackers obtained the credentials, it was game over. Many developers make the mistake of embedding credentials and cryptographic keys in source code and leaving them in public-facing repositories such as GitHub. Keys need to be appropriately protected, and a well-secured public key infrastructure is necessary, the CSA said. They also need to be rotated periodically to make it harder for attackers to use keys they’ve obtained without authorization. Organizations planning to federate identity with a cloud provider need to understand the security measures the provider uses to protect the identity platform. Centralizing identity into a single repository has its risks. Organizations need to weigh the trade-off of the convenience of centralizing identity against the risk of having that repository become an extremely high-value target for attackers. |
| AWS – Malicious Insiders | The insider threat has many faces: a current or former employee, a system administrator, a contractor, or a business partner. The malicious agenda ranges from data theft to revenge. In a cloud scenario, a hellbent insider can destroy whole infrastructures or manipulate data. Systems that depend solely on the cloud service provider for security, such as encryption, are at greatest risk. The CSA recommends that organizations control the encryption process and keys, segregating duties and minimizing access given to users. Effective logging, monitoring, and auditing administrator activities are also critical. As the CSA notes, it’s easy to misconstrue a bungling attempt to perform a routine job as “malicious” insider activity. An example would be an administrator who accidentally copies a sensitive customer database to a publicly accessible server. Proper training and management to prevent such mistakes becomes more critical in the cloud, due to greater potential exposure. |
| AWS – System and Application Vulnerability | System vulnerabilities, or exploitable bugs in programs, are not new, but they’ve become a bigger problem with the advent of multitenancy in cloud computing. Organizations share memory, databases, and other resources in close proximity to one another, creating new attack surfaces. Fortunately, attacks on system vulnerabilities can be mitigated with “basic IT processes,” says the CSA. Best practices include regular vulnerability scanning, prompt patch management, and quick follow-up on reported system threats. According to the CSA, the costs of mitigating system vulnerabilities “are relatively small compared to other IT expenditures.” The expense of putting IT processes in place to discover and repair vulnerabilities is small compared to the potential damage. Regulated industries need to patch as quickly as possible, preferably as part of an automated and recurring process, recommends the CSA. Change control processes that address emergency patching ensure that remediation activities are properly documented and reviewed by technical teams. |
| AWS – Insecure Communication | Failure to encrypt sensitive communications, means that an attacker who can sniff traffic from the network will be able to access the conversation, and including any credentials or sensitive information transmitted. Different networks are more or less susceptible to sniffing, but is important to realize that eventually the host network will be compromised, and attackers will quickly install a sniffer to capture the credentials of other systems. Using SSL for communications with end users is critical, as they are very likely to be using insecure networks to access applications. Because HTTP includes authentication credentials or a session token with every single request, all authenticated traffic needs to go over SSL, not just the actual login request. Encrypting communications with backend servers is also important. Although these networks are likely to be more secure, the information and credentials they carry is more sensitive and more extensive. Therefore using SSL on the backend is quite important. Encrypting sensitive data, such as credit cards and social security numbers, has become a privacy and financial regulation for many organizations. Neglecting to use SSL for connections handling such data creates a compliance risk. |
| AWS – Insecure Interfaces and APIs | Practically every cloud service and application now offers APIs. IT teams use interfaces and APIs to manage and interact with cloud services, including those that offer cloud provisioning, management, orchestration, and monitoring. The security and availability of cloud services — from authentication and access control to encryption and activity monitoring — depend on the security of the API. Risk increases with third parties that rely on APIs and build on these interfaces, as organizations may need to expose more services and credentials, the CSA warned. Weak interfaces and APIs expose organizations to security issues related to confidentiality, integrity, availability, and accountability. APIs and interfaces tend to be the most exposed part of a system because they’re usually accessible from the open internet. The CSA recommends adequate controls as the “first line of defence and detection.” Threat modelling applications and systems, including data flows and architecture/design, become important parts of the development life-cycle. The CSA also recommends security-focused code reviews and rigorous penetration testing. |
| AWS – Insufficient Due Diligence | Organizations that embrace the cloud without fully understanding the environment and its associated risks may encounter a “myriad of commercial, financial, technical, legal, and compliance risks,” the CSA warned. Due diligence applies whether the organization is trying to migrate to the cloud or merging (or working) with another company in the cloud. For example, organizations that fail to scrutinize a contract may not be aware of the provider’s liability in case of data loss or breach. Operational and architectural issues arise if a company’s development team lacks familiarity with cloud technologies as apps are deployed to a particular cloud. The CSA reminds organizations they must perform extensive due diligence to understand the risks they assume when they subscribe to each cloud service. |
| AWS – Shared Technology Issues | Vulnerabilities in shared technology pose a significant threat to cloud computing. Cloud service providers share infrastructure, platforms, and applications, and if a vulnerability arises in any of these layers, it affects everyone. “A single vulnerability or misconfiguration can lead to a compromise across an entire provider’s cloud,” the report said. If an integral component gets compromised — say, a hypervisor, a shared platform component, or an application — it exposes the entire environment to potential compromise and breach. The CSA recommended a defense-in-depth strategy, including multifactor authentication on all hosts, host-based and network-based intrusion detection systems, applying the concept of least privilege, network segmentation, and patching shared resources. |
| AWS – Account Hijacking | Phishing, fraud, and software exploits are still successful, and cloud services add a new dimension to the threat because attackers can eavesdrop on activities, manipulate transactions, and modify data. Attackers may also be able to use the cloud application to launch other attacks. Common defense-in-depth protection strategies can contain the damage incurred by a breach. Organizations should prohibit the sharing of account credentials between users and services, as well as enable multi-factor authentication schemes where available. Accounts, even service accounts, should be monitored so that every transaction can be traced to a human owner. The key is to protect account credentials from being stolen, the CSA says. |
| AWS – Advanced Persistant Threats | The CSA aptly calls advanced persistent threats (APTs) “parasitical” forms of attack. APTs infiltrate systems to establish a foothold, then stealthily exfiltrate data and intellectual property over an extended period of time. APTs typically move laterally through the network and blend in with normal traffic, so they’re difficult to detect. The major cloud providers apply advanced techniques to prevent APTs from infiltrating their infrastructure, but customers need to be as diligent in detecting APT compromises in cloud accounts as they would in on-premises systems. Common points of entry include spear phishing, direct attacks, USB drives preloaded with malware, and compromised third-party networks. In particular, the CSA recommends training users to recognize phishing techniques. Regularly reinforced awareness programs keep users alert and less likely to be tricked into letting an APT into the network — and IT departments need to stay informed of the latest advanced attacks. Advanced security controls, process management, incident response plans, and IT staff training all lead to increased security budgets. Organizations should weigh these costs against the potential economic damage inflicted by successful APT attacks. |
| AWS – Cloud Services Abuse | Cloud services can be commandeered to support nefarious activities, such as using cloud computing resources to break an encryption key in order to launch an attack. Other examples including launching DDoS attacks, sending spam and phishing emails, and hosting malicious content. Providers need to recognize types of abuse — such as scrutinizing traffic to recognize DDoS attacks — and offer tools for customers to monitor the health of their cloud environments. Customers should make sure providers offer a mechanism for reporting abuse. Although customers may not be direct prey for malicious actions, cloud service abuse can still result in service availability issues and data loss. |
3. AWS EC2 Attack vectors and security requriements
| AWS – Allow SSH and or RDP port only to required IPs and VPN Network | It is recommended to restrict access to the SSH and RDP ports to the required IP(s) and VPN network. In addition, it is highly recommended that this access be limited to these ports as required and not include any other ports. Access to other ports should be handled separately as required.This can be implemented using security policies.To create a new security group using the console:1. Open the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/”>https://console.aws.amazon.com/ec2/</a>.2. In the navigation pane, choose Security Groups.3. Choose Create Security Group.4. Specify a name and description for the security group.5. For VPC, choose the ID of the VPC.6. Add Rules and Click on Create.Resource:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#security-group-rules”>Creating Security Group rules</a> |
| AWS – Protect against accidental termination | By default, you can terminate your instance using the Amazon EC2 console, command line interface, or APIIf you want to prevent your instance from being accidentally terminated using Amazon EC2, you can enable termination protection for the instance.The DisableApiTermination attribute controls whether the instance can be terminated using the console, CLI, or API.To enable termination protection for an instance at launch timeOpen the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/”>https://console.aws.amazon.com/ec2/</a>.On the dashboard, choose Launch Instance and follow the directions in the wizard.On the Configure Instance Details page, select the Enable termination protection check box.Select the instance, and choose Actions, Instance Settings, Change Termination Protection.Choose Yes, EnableResource:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/terminating-instances.html#Using_ChangingDisableAPITermination”>Instance Termination</a> |
| AWS – Ensure detailed monitoring is enabled on EC2 instances | By default, your instance is enabled for basic monitoring. You can optionally enable detailed monitoring. After you enable detailed monitoring, the Amazon EC2 console displays monitoring graphs with a 1-minute period for the instance.You can enable detailed monitoring on an instance as you launch it or after the instance is running or stopped. Enabling detailed monitoring on an instance does not affect the monitoring of the EBS volumes attached to the instance.Steps to Implement:To enable detailed monitoring for an existing instance:Open the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/”>https://console.aws.amazon.com/ec2/</a>.In the navigation pane, choose Instances.Select the instance and choose Actions, CloudWatch Monitoring, Enable Detailed Monitoring.In the Enable Detailed Monitoring dialog box, choose Yes, Enable.Choose Close.To enable detailed monitoring when launching an instance:When launching an instance using the AWS Management Console, select the Monitoring check box on the Configure Instance Details page.Resource:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html”>Enable detailed monitoring for EC2</a> |
| AWS – Ensure communication to global resources is only through VPC endpoints or Privatelink | A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic. There are two types of VPC endpoints: interface endpoints and gateway endpoints. Steps to Implement:To create an interface endpoint to an AWS service using the consoleOpen the Amazon VPC console at <a href=”https://console.aws.amazon.com/vpc/”>https://console.aws.amazon.com/vpc/</a><a href=”https://console.aws.amazon.com/vpc/”></a>In the navigation pane, choose Endpoints, Create Endpoint.For the Service category, ensure that AWS services are selectedFor Service Name, choose the service to which to connect. For Type, ensure that it indicates InterfaceComplete the following information and then choose Create endpoint: VPC: Select VPC in which to create the endpoint; Subnets: select the subnets (Availability Zones) in which to create the endpoint network interfaces; DNS: To enable private DNS for the interface endpoint, for Enable Private DNS Name, select the check box; Security group: select the security groups to associate with the endpoint network interfaces; Tags: (Optional) add any tags.Resources:<a href=”https://docs.aws.amazon.com/AmazonS3/latest/dev/security-best-practices.html#end-points”>S3 Bucket</a> <a href=”https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html”>Cloudwatch</a> <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-vpc-endpoints.html”>ELB </a><a href=”https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb-tutorial.html”>DynamoDB</a> <a href=”https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html”>ECS</a> <a href=”https://docs.aws.amazon.com/amazonglacier/latest/dev/network-isolation.html”>Glacier </a><a href=”https://docs.aws.amazon.com/sns/latest/dg/sns-vpc-create-endpoint.html”>SNS</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.html#consider-using-vpc-endpoints-access-sqs”>SQS</a> <a href=”https://docs.aws.amazon.com/athena/latest/ug/interface-vpc-endpoint.html”>Athena </a><a href=”https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html”>ECR</a><a href=”https://docs.aws.amazon.com/emr/latest/ManagementGuide/interface-vpc-endpoint.html”>EMR</a> <a href=”https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html”>Elastic Beanstalk</a> <a href=”https://docs.aws.amazon.com/codebuild/latest/userguide/security-traffic-privacy.html”>CodeBuild </a><a href=”https://docs.aws.amazon.com/sagemaker/latest/dg/interface-vpc-endpoint.html”>SageMaker</a><a href=”https://docs.aws.amazon.com/datasync/latest/userguide/datasync-in-vpc.html”>DataSync</a><a href=”https://docs.aws.amazon.com/app-mesh/latest/userguide/vpc-endpoints.html”>App Mesh</a> <a href=”https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-internetwork-traffic-privacy.html”>SQS</a><a href=”https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-vpc-endpoints.html”>AWS EC2 Auto Scaling</a><a href=”https://docs.aws.amazon.com/config/latest/developerguide/config-VPC-endpoints.html”>Config</a><a href=”https://docs.aws.amazon.com/efs/latest/ug/efs-vpc-endpoints.html”>EFS</a><a href=”https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html”>KMS</a> |
| AWS – Ensure host OS is built from pre-approved AMI | The integrity of the EC2 instance is, fundamentally, dependent upon the integrity of the AMI (Amazon Machine Image) used for the EC2 launch. Consequently, it is imperative to:Establish that the built or chosen image can be trusted andHave a means to validate the integrity of the image at any point in time.Recommendations for Implementation:Use a golden Amazon Machine ImageIf you are building your own image or adding applications/libraries, analyze code for application-specific vulnerabilities, remove unneeded libraries and packages, restrict functions, and scan for vulnerabilities.Use Amazon Inspector to <a href=”https://aws.amazon.com/blogs/security/how-to-set-up-continuous-golden-ami-vulnerability-assessments-with-amazon-inspector/”>set up</a> continuous vulnerability assessment scans of your golden AMIs.Ensure trust with signing and author/publisher verification. Restrict and monitor access to trusted registries and deployment tools.Host your AMIs in a private VPC registry with restricted access.Reference:<a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/usingsharedamis-finding.html”>Finding shared AMIs</a> |
| AWS – Enable continuous vulnerability checks | EC2 Amazon Inspector performs security assessments of Amazon EC2 instances by using AWS managed rules packages such as the Common Vulnerabilities and Exposures (CVEs) package. The steps below schedule an Amazon CloudWatch Events rule to run the golden AMI vulnerability assessments on a regular basis. LambdaAWS Lambda provides runtimes that run your function code in an Amazon Linux–based execution environment. Lambda is responsible for keeping software in the runtime and execution environment up to date, releasing new runtimes for new languages and frameworks, and deprecating runtimes when the underlying software is no longer supported. If you use additional libraries with your function, you’re responsible for updating the libraries. You can include additional libraries in the deployment package, or in layers that you attach to your function. You can also build custom runtimes and use layers to share them with other accounts. Lambda deprecates runtimes when the software on the runtime or its execution environment reaches the end of life. When Lambda deprecates a runtime, you’re responsible for migrating your functions to a supported runtime for the same language or framework.Steps to deploy continuous golden AMI vulnerability assessments in your AWS account, follow these steps: Tag your golden AMIs – Tagging your golden AMIs lets you search assessment result findings based on tags after Amazon Inspector completes an assessment. Store your golden AMI metadata in the Systems Manager Parameter Store – Prepare and store the golden AMI metadata in the Systems Manager Parameter Store. The StartContinuousAssessment Lambda function reads golden AMI metadata and starts assessing for vulnerabilities.Run the supplied AWS CloudFormation template and subscribe to an SNS topic to receive assessment results – Set up the infrastructure required to run vulnerability assessments and subscribe to an SNS topic to receive assessment results via email.Test golden AMI vulnerability assessments – Ensure you have successfully set up the required resources to run vulnerability assessments.Set up a CloudWatch Events rule for triggering continuous golden AMI vulnerability assessments – Schedule the execution of vulnerability assessments on a regular basis.References <a href=”https://aws.amazon.com/blogs/security/how-to-set-up-continuous-golden-ami-vulnerability-assessments-with-amazon-inspector/”>https://aws.amazon.com/blogs/security/how-to-set-up-continuous-golden-ami-vulnerability-assessments-with-amazon-inspector/</a>Lambda: <a href=”https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html”>https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html</a> |
| AWS – Maintain the health and availability of your compute instances | The AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through 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. Availability Zones are more highly available, fault-tolerant, and scalable than traditional single or multiple data center infrastructures. In addition to the AWS global infrastructure, Amazon EC2 offers the following features to support your data resiliency: •Copying AMIs across Regions •Copying EBS snapshots across Regions •Automating EBS snapshots using Amazon Data Lifecycle Manager •Maintaining the health and availability of your fleet using Amazon EC2 Auto Scaling •Distributing incoming traffic across multiple instances in a single Availability Zone or multiple Availability Zones using Elastic Load Balancing The health status of an Auto Scaling instance is either healthy or unhealthy. All instances in your Auto Scaling group start in a healthy state. Instances are assumed to be healthy unless Amazon EC2 Auto Scaling receives notification that they are unhealthy. This notification can come from one or more of the following sources: Amazon EC2, Elastic Load Balancing, or a custom health check. After Amazon EC2 Auto Scaling marks an instance as unhealthy, it is scheduled for replacement. If you do not want instances to be replaced, you can suspend the health check process for any individual Auto Scaling group. References: <a href=”https://docs.aws.amazon.com/autoscaling/ec2/userguide/healthcheck.html”>https://docs.aws.amazon.com/autoscaling/ec2/userguide/healthcheck.html</a> |
| AWS – Distribute incoming traffic across multiple instances in a single Availability Zone or multiple Availability Zones using Elastic Load Balancing | The AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through 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. Availability Zones are more highly available, fault-tolerant, and scalable than traditional single or multiple data center infrastructures. In addition to the AWS global infrastructure, Amazon EC2 offers the following features to support your data resiliency: Copying AMIs across RegionsCopying EBS snapshots across RegionsAutomating EBS snapshots using Amazon Data Lifecycle ManagerMaintaining the health and availability of your fleet using Amazon EC2 Auto ScalingDistributing incoming traffic across multiple instances in a single Availability Zone or multiple Availability Zones using Elastic Load BalancingReference: <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/disaster-recovery-resiliency.html”>https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/disaster-recovery-resiliency.html</a> <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html”>https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html</a> |
| AWS – Securely configure your EC2 security groups | Configure the security groups for your Amazon EC2 instances to accept traffic only from the load balancer. These security groups must allow inbound traffic from the load balancer on the listener ports and the health check ports.To allow communication between your load balancer and your instances, Create an inbound rule for the security group for your instances that allows inbound traffic only from the load balancer (using the source security group provided by Elastic Load Balancing).To lock down traffic between your load balancer and instances using the console, follow the steps mentioned below:Open the Amazon EC2 console at <a href=”https://console.aws.amazon.com/ec2/.”>https://console.aws.amazon.com/ec2/.</a>On the navigation pane, under LOAD BALANCING, choose Load Balancers.Select your load balancer.On the Description tab, copy the name of the source security group.On the Instances tab, select the instance ID of one of the instances registered with your load balancer.On the Description tab, for Security groups, select the name of the security group.On the Inbound tab, choose Edit, Add Rule.From the Type column, select the protocol type. The Protocol and Port Range columns are populated. From the Source column, select Custom IP and then paste the name of the source security group that you copied earlier (for example, amazon-elb/amazon-elb-sg).(Optional) If your security group has rules that are less restrictive than the rule that you just added, remove the less restrictive rule using its delete icon.To lock down traffic between your load balancer and instances using the AWS CLI, follow the steps mentioned <a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-classic-security-groups”>here</a>Reference:<a href=”https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-classic-security-groups”>https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-classic-security-groups</a> |
| AWS – Launch an instance in a private subnet | Launch the EC2 instance in private subnet unless it’s really required to be launched in Public subnet.You can improve the security posture of your VPC by configuring Amazon EC2 to use an interface VPC endpoint. Interface endpoints are powered by AWS PrivateLink, a technology that enables you to privately access Amazon EC2 APIs by restricting all network traffic between your VPC and Amazon EC2 to the Amazon network. With interface endpoints, you also don’t need an internet gateway, a NAT device, or a virtual private gateway.Steps to implement:1. Create an endpoint for Amazon EC2 using the following service name:com.amazonaws.region.ec2 — Creates an endpoint for the Amazon EC2 API actions.2. You can attach a policy to your VPC endpoint to control access to the Amazon EC2 API. The policy specifies:The principal that can perform actions.The actions that can be performed.The resource on which the actions can be performed.Important: When a non-default policy is applied to an interface VPC endpoint for Amazon EC2, certain failed API requests, such as those failing from RequestLimitExceeded, might not be logged to AWS CloudTrail or Amazon CloudWatch.Reference: <a href=”https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html”>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html</a> |