CloudFront supports multiple security options. Front-end Internet-based denial-of-service protection is included at no cost when deploying a CloudFront distribution. AWS uses its Shield service in front of all edge locations. Shield will protect the edge from distributed denial-of-service (DDoS) attacks. Shield includes automatic inline attack mitigation support to protect your site from common attacks at no additional charge.
The Web Application Firewall (WAF) and many third-party firewalls can be combined with CloudFront for application-level perimeter security.
Field-level encryption for CloudFront allows sensitive user data to be uploaded to the edge location in a secure manner. Sensitive data can include medical or financial records. With field-level encryption, data will be encrypted in transit to the origin site using customer-provided keys. Field-level encryption complements SSL/TLS encryption in that it can encrypt fields in the stream such as credit card numbers that only a small group of users or microservices need to access. This prevents sensitive data from being exposed when it is decrypted after arriving to the origin over a TLS connection. The CloudFront edge locations will encrypt sensitive fields such as credit card numbers using the origin’s public key. When the origin receives the traffic from the edge, it will use its private key to decrypt the data. This allows for a granular security approach at the origin of your data.
CloudFront edge interfaces support SNI or SSL/TLS. SNI includes the domain or server name in the connection request and is an extension of the TLS specification. This allows a single IP address to support multiple domains, each with its own SSL/TLS certificate, as was described earlier. When an SSL/TLS connection request is processed at the edge, there may be many different domains associated with its IP address, and each domain will have its own SSL/TLS certificate. By using SNI, the TLS header is read, and the connection request is forwarded to the correct domain to complete the secure connection handshake.
CloudFront supports HTTP cookies to enable customized or dynamic content. CloudFront will analyze the cookies and determine if the object can be serviced from its local cache or need to be forwarded to the origin for processing. Performance is enhanced by serving objects at the edge where possible and custom content from the origin. All requests can be tracked and recorded by using the CloudFront monitoring service.
Headers can be created or modified by CloudFront before they are sent to the origin. This allows for enhanced security by validating that the information was received from CloudFront and not a bogus imposter. The origin can be configured to only accept requests from CloudFront. Custom header configurations are offered at no charge and configured using the management interface or API calls.
Dynamic content such as search results often includes the query string in the URL. These strings can be used as a key to identify objects in the local edge cache. Dynamic content can then be stored at the edge; for example, changing sports scores or short-term search values can be served from the edge cache based on the values in the URL query string. To filter up to 10 specific values in the URL parameters, the whitelisting feature is used. This narrows the match to a subset of the values in the cache key and forwards all of the parameters to the origin. Supported parameter types are between the HTTP GET after the ? character and the & delimiter character. These types are noted in RFC 3986.
When you set up CloudFront and use an S3 bucket as the origin of your content, the S3 URL may still be exposed to the Internet, allowing users to bypass CloudFront and pull data directly from S3, which can be a major security violation.
Internet users can source data directly from the S3 origin if not blocked from doing so. This can be prevented by configuring Origin Access Identity (OAI). To restrict users’ direct S3 access and require them to use only CloudFront, a signed URL can be configured. Also, by forcing all requests through CloudFront edge locations, additional features can be leveraged such as restricting access by IP address or location. Also, more detailed logging and metrics are collected in CloudWatch. Up to 100 CloudFront OAIs can be applied to any number of distributions. This feature is enabled in the CloudFront console under the S3 bucket access tab or the CreateCloudFrontOriginAccessIdentity API. S3 bucket policies can also be used to give the OAI access to the bucket. Since the OAI is attached to the CloudFront distribution and uniquely identifies it, an S3 bucket policy can be applied to allow only that OAI and deny all other connection requests. Origins such as EC2 and application load balancers do not support OAIs. The solution for this is to create a custom HTTP/HTTPS header in the origin request configured in CloudFront. If the custom header is not configured and is not received at the origin, it will refuse the connection. Another option is to use the IP address blocks used by AWS, which they publish to restrict access. Access control lists can then be defined at the availability zone level to only allow access to the content from the IP edge location address blocks.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
