aws

• If your certificate is in the Pending validation state, then confirm that the CNAME record provided by ACM was added to the correct DNS configuration.
• • aws:PrincipalArn condition supports the following:IAM role, IAM user, AWS STS federated user session, AWS account root user
  • Use SourceARN to compare the (ARN) of the resource making a "service-to-service" request with the ARN that you specify in the policy.
• How AWS Network Firewall works

  • To apply traffic-filtering logic provided by AWS Network Firewall, you must route traffic symmetrically to the AWS Network Firewall endpoint. This firewall endpoint is similar to PrivateLink VPC interface endpoint. The key difference is that it can be a route table target. AWS Network Firewall endpoint is deployed into a dedicated subnet of a VPC. We call this subnet an AWS Network Firewall subnet or simply firewall subnet.
• How AWS Network Firewall works

  • Depending on the use case and deployment model, the firewall subnet could be either public or private. For high availability (HA) and Multi-AZ deployments, allocate a subnet per Availability Zone (AZ). As a best practice, do not use AWS Network Firewall subnet to deploy any other services since AWS Network Firewall is not able to inspect traffic from sources or destinations within firewall subnet.
• • Once AWS Network Firewall is deployed, you will see a firewall endpoint in each firewall subnet. As mentioned earlier, firewall endpoint is similar to interface endpoint and it shows up as vpce-id in your VPC route table target selection. Firewall endpoint capability is powered by AWS Gateway Load Balancer and therefore elastic network interface (ENI) of the endpoint is “gateway_load_balancer_endpoint” type.
• • To have your network traffic inspected by AWS Network firewall, you must direct traffic to firewall endpoint using VPC route tables. In figure 1, we insert firewall endpoint in the path between a workload subnet and internet gateway (IGW) using VPC Ingress Routing feature. We call this workload subnet a protected subnet as all traffic to the internet is now inspected and protected by AWS Network Firewall.
• • AWS Network Firewall is completely transparent to the traffic flow and does not perform network address translation (NAT). It preserves source and destination IP addresses.
  • When a network packet arrives to AWS Network Firewall, it enters rules engine and gets inspected. 
• Deployment models

  1. Distributed AWS Network Firewall deployment model: AWS Network Firewall is deployed into each individual VPC.
  2. Centralized AWS Network Firewall deployment model: AWS Network Firewall is deployed into centralized VPC for East-West (VPC-to-VPC) and/or North-South (internet egress and ingress, on-premises) traffic. We refer to this VPC as inspection VPC.
• Deployment models

  1. Combined AWS Network Firewall deployment model: AWS Network Firewall is deployed into centralized inspection VPC for East-West (VPC-to-VPC) and subset of North-South (On Premises/Egress) traffic. Internet ingress is distributed to VPCs which require dedicated inbound access from the internet and AWS Network Firewall is deployed accordingly.
• Distributed AWS Network Firewall deployment model

  
• AWS Network Firewall is deployed to protect traffic between an AWS service in a public subnet and IGW

  
• Centralized deployment model

  
• 1) East-West Traffic Inspection Model:

  
• • You can associate a Cognito user pool with a regional WAF web ACL. This can be done via CloudFormation, but you can also do it via the Cognito console
• CloudFront Security:

  • The SecurityHeadersPolicy is a managed policy provided by Amazon CloudFront that includes a set of recommended security headers to enhance the security of your website. These headers help protect against various types of attacks, including man-in-the-middle attacks. By applying the SecurityHeadersPolicy to your CloudFront distribution, the necessary security headers will be automatically added to the responses sent by CloudFront. This reduces operational overhead because you don't have to manually configure or manage the headers yourself.
• CloudFront Security:

  SimpleCORS managed response headers policy:

  • The SimpleCORS managed response headers policy is designed for Cross-Origin Resource Sharing (CORS) and focuses on allowing or restricting web applications running at one origin to make requests for resources from another origin. While CORS is essential for web security, it is not specifically geared towards protecting against man-in-the-middle attacks. Choosing this option may not provide comprehensive security measures against various attack vectors.
• CloudFront Security:

  Use a Lambda@Edge function to add the Strict-Transport-Security response header:

  • Adding the Strict-Transport-Security (HSTS) header is a good practice for enhancing security by instructing the browser to only connect to the website over HTTPS.
• CloudFront Security:

  Include the X-XSS-Protection header in a custom response headers policy:

  • The X-XSS-Protection header is used to enable or disable the browser's built-in Cross-Site Scripting (XSS) protection. While it addresses a specific type of web security threat (XSS attacks), it is not directly related to protecting against man-in-the-middle attacks.
• • When launching an EC2 instance from an encrypted AMI using a customer managed key in AWS KMS, the Lambda function's execution role needs the kms:CreateGrant and kms:Decrypt permissions for the KMS key used to encrypt the AMI. These permissions allow the Lambda function to create a grant to decrypt the key and access the encrypted AMI during the provisioning process.
• DynamoDB only caches the Table Key for 5 minutes. "If DynamoDB gets a request for the cached table key after five minutes of inactivity, it sends a new request to AWS KMS to decrypt the table key. "
• Amazon Inspector: Amazon Inspector is a security assessment service that helps analyze the behavior and configuration of applications running on EC2 instances. It can scan instances for common vulnerabilities and exposures (CVEs) and assess network exposure.
• • Delegated administrator for Amazon Inspector: By configuring a delegated administrator for Amazon Inspector at the organization level, you can centrally manage and configure Inspector assessments for all member accounts. This allows you to automate the scanning process and ensure consistent security assessments across the organization.
• Inspector:

  • Automatic scanning for new member accounts: With the delegated administrator in place, you can configure automatic scanning for new member accounts. This ensures that any new workloads that come online in the organization's accounts are automatically scanned by Amazon Inspector for vulnerabilities and network exposure.
• To set up the snapshot in us-west-1 with proper encryption, you should create a new customer managed key in the us-west-1 Region. Then, use this new key to encrypt the snapshot when copying it to the us-west-1 Region. This ensures that the snapshot remains encrypted while also allowing you to comply with the necessary encryption requirements in the target Region.
• Session Manager:

  Amazon CloudWatch logging: By configuring CloudWatch logging, the security engineer can monitor and capture session activity logs. This includes commands executed, input/output streams, and metadata associated with the session. Encrypted CloudWatch Logs log groups: By allowing only encrypted CloudWatch Logs log groups, the security engineer ensures that the session activity logs are encrypted at rest, providing an additional layer of security for the stored logs.
• NOTE: Shutting down an instance loses access to whatever is in memory
• API GW Access Logging With CloudWatch:

  1. Configure access logging for the required API stage: By enabling access logging, API Gateway will generate log files that capture detailed information about each API request. These logs can be stored in Amazon S3 or streamed to CloudWatch Logs. 2. Use Amazon CloudWatch Logs Insights to analyze API access information: With CloudWatch Logs Insights, you can run queries on the log data generated by API Gateway to gain insights into API access patterns.
• • kms:sign action is used for asymmetric keys
• A company hosts an end user application on AWS. Currently, the company deploys the application on Amazon EC2 instances behind an Elastic Load Balancer. The company wants to configure end-to-end encryption between the Elastic Load Balancer and the EC2 instances. Which solution will meet this requirement with the LEAST operational effort?

  • Import a third-party SSL certificate to AWS Certificate Manager (ACM). Install the third-party certificate on the EC2 instances. Associate the ACM imported third-party certificate with the Elastic Load Balancer. Most Voted
• • Public ACM certificates can be installed on Amazon EC2 instances that are connected to a Nitro Enclave, but not to other Amazon EC2 instances.
• AWS BackUp

  Rate schedule expression is not suitable for fixed date scheduling.
• Origin Access Control (OAC)

  • While OAI provides a secure way to access S3 origins to CloudFront, it has limitations such as not supporting granular policy configurations, HTTP and HTTPS requests that use the POST method in AWS regions that require AWS Signature Version 4 (SigV4), or integrating with SSE-KMS. To strengthen security and deepen feature integrations, today, we are introducing origin access control (OAC), a new feature that secures S3 origins by permitting access to the designated distributions only. 
• Origin Access Control (OAC)OAC is based on an AWS best practice of using IAM service principals to authenticate with S3 origins. Compared with OAI, some of the notable enhancements OAC provide include:

  • Security – OAC is implemented with enhanced security practices like short term credentials, frequent credential rotations, and resource-based policies. They strengthen your distributions’ security posture and provides better protections against attacks like confused deputy.
  • Comprehensive HTTP methods support – OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
• Origin Access Control (OAC)

  • SSE-KMS – OAC supports downloading and uploading S3 objects encrypted with SSE-KMS.
  • Access S3 in all AWS regions – OAC supports accessing S3 in all AWS regions, including existing regions and all future regions. In contrast, OAI will only be supported in existing AWS regions and regions launched before December 2022.
• • When using OAC, a typical request and response workflow will be: 1. A client sends HTTP or HTTPS requests to CloudFront. 2. CloudFront edge locations receive the requests. If the requested object is not already cached, CloudFront signs the requests using OAC signing protocol (SigV4 is currently supported.) 3. S3 origins authenticate, authorize, or deny the requests. When configuring OAC, you can choose among three signing behaviors – “Do not sign requests”, “Sign requests”, and sign requests but “Do not override authorization header” (Figure 1).
• OAC Signing with SigV4

  
• OAC “Sign requests” option

  When you configured “Sign requests” option, IAM CloudFront service principal will sign each request with SigV4. The signature will then be included, along with additional data, to form an Authorization header which will be sent to your S3 origin. When your S3 origin receives this request, it will perform the same steps to calculate the signature and compare its calculated signature to the one CloudFront sent with the request. If the signatures match, the request is processed. If the signatures don’t match, the request is denied.
• OAC “Sign requests” option

  • With “Sign requests” option, CloudFront will always sign requests received from the clients, even when an incoming request already has an Authorization header signed by your client applications. In which cases, CloudFront will drop client’s Authorization header, re-sign the request with CloudFront’s credential, and generate a new Authorization header to send to S3 origin
• OAC “Do not override authorization header” option

  If your client applications can sign requests, and your use cases involve toggling between client-signed and CloudFront-signed Authorization headers based on attributes like different cache behaviors, file directories, HTTP methods, edge computer invocations, you can use “Do not override authorization header” sub-option after selecting “Sign request.” Note that in this example, you must configure your S3 bucket policy accordingly so only your client’s Authorization will be accepted to perform uploading.
• OAC “Do not override authorization header” option

  • In addition, because CloudFront requires headers to be explicitly allow-listed to be forwarded to origin, you must allowlist Authorization header in your cache policy so that client Authorization header can be forwarded to your origin. If “Do not override authorization header” sub-option is enabled but client’s Authorization header isn’t allow listed, CloudFront will drop client’s Authorization header, re-sign the request with CloudFront’s credential, and generate an Authorization header to send to S3 origin.