AWS Security Operations Infrastructure Services

Overview

by scmGalaxy.com

About Me

DevOps@RajeshKumar.XYZ

AWS Security Operations: Securing Core AWS Infrastructure Services

MANAGING ACCESS CONTROL

Why have a course focused on AWS security?

Securing is still 25/7 in the cloud

Companies spend milions of dollers on firewalls and secure access devices, and it's money wasted because none of these measures address the weakest link in the security chain: the people who use, administer and operate computer systems.

This course will help you with all things in AWS infrastructure security.

A working knowledge of AWS services is a bonus but not essential

AWS Security Operations

• Part 1: Designing for Acceptable Risk and Compliance
• Part 2: Securing Core AWS Infrastructure Services
• Part 3: Securing Access to Object Storage
• Part 4: Securing Managed Services

Topics

• Identity and Access Management
• IAM Users and Groups
• Controlling Access to Resources
• Understanding Access Keys
• IAM Policies
• Delegation and Federation
• Best Practices when Planning Access Control

Identity and Access Management

Identity and Access Management Goals

Access granted based on least privilege

Control access to resources

Required by most credible security and compliance standards:

• HIPPA, NIST, FEDRAMP, ITAR, and ISO

The SOC-2 audit of AWS re-affirms that current security controls are in

IAM Defines

Security Policy for Authentication

• Users
• Groups (of Users)
• Implementing Password Policy

Authorization Levels

• For Users
• For Groups (of Users)
• For Resources

Authentication Options

Defining Security Credentials

Controlling Root Account Security

AWS Account Creation

During initial Singh-up to AWS

• Email address
• Password

Your first AWS account is the "root account"

• Full access to all account resources
• This account can't be disabled

DO NOT use this account for daily operation!

• Root-level privileges are assigned to all users that use this account
• Root account are outside IAM control

Root Account Management

• Root account credential should be stored in a physical safe
• Multi-factor authentication should also be enabled on the root account (MFA)
• Both hardware and virtual devices are supported
• Virtual devices must support TOTP standard (time-based one time password)
• Virtual device: Google Authenticator
• Hardware device: Gemalto
• SMS MFA devices not compatible with Root Account

Best Practice for Root Account

When do I Need the Root Account?

Managing Root Account Security

Managing Multiple Accounts

AWS Account Details

• Each AWS account has two unique IDs assigned at creation; both of these IDs can't be changed
• Account ID: 12 digit number
• Canonical ID: Much longer string
• IDs are displayed in User Account properties as a "Account Identifier"

Managing Multiple Accounts

Multiple account can be handy for the organization of users:

• Account for development, test, production, or separate business departments

Account separate for specific needs:

• Security requiremnts
• Location
• Governance

Cross account access:

• Allows an IAM user to access resources created by another account
• Must be manuallye enabled

Best practice: Multiple account should have consolidated billing enabled

AWS Account Design

AWS Account Design

Management Through Governance

Managing Multiple Accounts

IAM Users and Security Controls

Defining Access

Identity and Access Management (IAM)

After creation of the initial root user; all additional users must be created using the IAM web service

IAM controls authentication and authorized access to AWS resources

IAM provides central management of user access:

• User and groups
• Roles
• Managed, Inline, or custom policies

IAM Users

Access to the Management Console?

Assign a Password

Access to AWS resources via script or automation?

Create an access key

Allow (Control) Access to AWS Resources?

Attach a Policy to the user?

Add the user to an IAM group (Best Practice)

Extra Security?

Add Multi-Factor Authentication

IAM @ Work for Access

• Access to S3 Bucket
• E2 access to DB
• Access to folder in S3
• Access via Cognito SSO
• DB access when user name matches
• Password Management
• Group membership
• Manage other IAM Users
• Set Account Policy
• Creating Security Reports

IAM policy is checked every time access is requested

Every. Time.

Defining IAM Policy for the User

Controlling Access to Resources

AWS Access to Resources

Resource Access Outside of IAM

Access Keys and Password

Access Keys

• All access to AWS resources utilizes an API call
• Using programs (automation, scripts) requires an active access key
• Each user can have a secret access key
• Default after creation: Access key is "active"
• The access key ID and the secret key are linked together like a public/ private key pair
• If a secret access key is lost; create new key in the IAM console

Access Key Management

• Perform access key management
• Best practice: rotate access keys for all IAM users
• Each user can have two active access keys
• Access key deleted: access is revoked
• Once deleted, key is gone forever

Rotating Access Keys

Password Management

• Minimum password lenght?
• Users can set their password?
• Password expiration?
• Password reuse?
• Complexity rules?
• Password expiration procedure

Password Tools

• IAM Console
• AWS CloudTrail
• Credential Report
• Access Advisor
• SNS
• CloudWatch

Credentials: Best Practice

Security Tools

IAM Groups

IAM Groups

• Groups can contain numerous users
• Permissions apply to all group members
• Groups can't be nested
• There are no default groups
• Users can belong to multiple groups
• Single user needs should be defined using groups

IAM Policies: The Basic

Common Elements in a Policy

• Resource
• Actions
• Effect
• Principal

IAM Policy Rules

• Deny by Default
• An IAM policy lists permission to allow or deny
• IAM policy logic:
• Explicit deny
• Explicit allow
• Implicit deny
• If a conflict is created during evaluation; the most restrictive policy wins
• Explicit deny "trumps" all allows
• Policies can be attached to either user, group, role, or resource

IAM Policy Rules

Best Practice:

Follow the least-privilege priciple

Living by the Least Privilege

• Grant permission that are required
• Start with the absolute minimum

IAM Policy Creation

IAM Policy Types

IAM Policies

Managed Policy

May be attached to multiple users, groups and roles

Each policy has its Amazon Resource Name (ARN)

Managed policies are applied to identities

• Users, Groups, and Roles

AWS managed policies: created and maintained by AWS

• Deployed by customers
• Are read-only
• Designed for common use cases, and job functions
• Ex: Administrator access, security audit, read-access, power user

Customer managed policies: created and managed by the customer

Up to 10 managed policies per user, group, or role

Inline Policy

• Policies that are linked directly one-to-one
• To a priciple(User, Group, or Role)
• If the priciple are deleted; the policy is revoked
• Inline policies are created and managed by the customer
• Inline policies are imbedded in the selected priciple; the policy copy is not shared
• Used to managed and maintain a strict on-to-one relationship between a policy and a selected principal

Tag-based Policy

Tag-based access control

• Restrict permissions based on tag value
• Ex: Detach Volumes from EC2 Instances

Enforce permissions when any new resources are created with the same tag

Tag-based access control is supported by:

• EC2, VPC, EBS, RDS, Simple Workflow Services, Data Pipeline
• Ex: Assign permissions to Susan granting her permission to perform any EC2 action on all resource tagged with Dev A

Resource Policies

Are attached to a resource

Resource policies are supported by:

• S3 Buckets, Glacier Vaults, SNS Topics, and SQS (Queues)

Use resource-policies when you need to:

• Control access to a specific resource

Policy Attachment

Policy Enforcement

Policy Enforcement

Amazon S3 supports policies both for IAM users and for resources.

S3 resource policies are called "bucket policies"

Creating Inline and Resource Policy

Delegation and Federation

Federating External Users

Users that already authenticate to a corporate network can be linked to AWS resources through federation

Existing user identities can be federation into AWS

Federation is useful when:

Users have corporate credentials (AD DS)

• AWS Directory Service is used to establish trust between corporate network and AWS account

Users have Internet Identities

• Users using a mobile app can identify themselves using an identity provider such as Facebook, Google, OpenID

IAM Roles

• Federated users will not have permanent identities
• Delegated access to an AWS resource provides temporary access
• Permissions are defined using IAM roles
• Permissions are attached to the role, but not to an IAM user or group
• When a role is assumed, temporary security credential are provided for access to requested AWS resources
• No long term security credentials are shared

Creating an IAM Role

Identity Federation Using Identity Providers

• Provide permission to external user identities without the need to create a IAM user account
• Management of the external identities is carried out using the external identity provider
• Corporate example: Active Directory Domain Services
• Well known identity providers include Google, Facebook, and Amazon Cognito
• Create an IAM identity provider "entity" to establish trust between your AWS account and the external identity provider
• SAML 2.0 and OpenID Connect are also supported
• For mobile applications best practice: use Amazon Cognito

Identity Federation Using AWS Directory Services

AWS directory services is a managed AWS service

Two option to connect your AWS resources:

• Using existing on premise AD DS
• Create a standalone directory service in AWS

AWS managed service provides all patches, backups, and upgrades

The managed directory infrastructure is replicared across multiple availability zones within your region

AWS Security Token Services (STS)

• The AWS Security Token Service (STS) provides federated users with temporary security credentials
• AWS STS is a globel service with a single endpoint
• You can choose to send STS requests to a specific region endpoint to reduce latency, or for additional redundancy
• Temporary security credentials use a short-lived access key, a secret access key, and a session token
• Customers can specify how long the credentials are valid
• By default credentials expire after one hour when using a SAML connection; the minimum duration credentials is 15 minutes
• When using a federation token, or session token; the minimum is 15 minutes the maximum is 36 hours, and the default is one hour

AWS STS Features

• Provide secure access without requiring an AWS identity
• Removes the need to distribute AWS security credentials
• Support single sign-on
• Support MFA
• All calls are logged in CloudTrail

Best Practices for Planning Access Control

Create Individual Users

• Unique credentials per user
• Credential rotation per user
• Each individual has unique permissions
• Always start by granting least privilege

Permissions

• Manage permission through groups
• Much easier to assign the same permission to multiple users
• Easier to reassign permission as responsibilities change
• One change updates multiple users

Conditions

• Restrict privilege access further with conditions
• Restrict access FROM a specific IP address
• Restrict database creation using a specific engine
• Create only specific EC2 instances

Auditing

• Get visibility into your users activity
• Enable CloudTrail to get logs of API calls
• Log call to S3 bucket in your account

Configure Strong Password

Ensure you and your data is protected

Configure a strong password policy

• Password expiration?
• Password strength?
• Reuse policy?

Password policy does not apply to Root user

Rotate Credentials

• Rotate your security credentials on a fixed schedule
• Use Credential Reports to identify credentials that should be rotated, or deleted
• IAM console displays when password was last used
• Grant IAM user permission to rotate credentials
• IAM roles for EC2 instances rotate credentials automatically

MFA

Enable MFA for all privileged users

Require a one-time code during authentication

• Virtual MFA
• Hardware
• SMS

Sharing

Only use IAM roles to share access

There is no need to share security credentials

There is no need to store long-term credentials

Analyze and implement based on use case:

• Cross account access
• Account delegation
• Federation

IAM Roles

• Use IAM Roles for Amazon EC2 instances
• Access keys are stored on EC2 instances
• Automatic key rotation
• Automatically assign least privilege to the application
• Fully integrated with SDK's, and CLI

Root Account

• Reduce or restrict the root account
• Remove the potential for misuse of credentials

Wrap Up

• Identity and Access Management
• IAM Users and Groups
• Controlling Access to Resources
• Understanding Access Keys
• IAM Policies
• Delegation and Federation
• Best Practices when Planning Access Control

Up Next:

Securing Core Infrastructure

Securing Core Infrastructure

Why have a course focused on AWS Security?

Security is still 25/7 in the cloud

The user is going to pick dancing pigs over security every time

This course will help you with AWS infrastructure core security

A working knowledge of AWS services is a bonus but not essential

Topics

• Securing EC2 instances
• Dedicated Instances and Hosts
• Amazon Machine Instances
• Security choices for Instances
• Securing EBS volumes
• VPC Security
• VPC Design Criteria
• Best practices when planning Core Infrastructure

Securing EC2 Infrastructure

EC2 Design

Isolation Security

Xen hypervisor runs the Guest OS in Ring 1

Applications runs in Ring 3 providing security separation

Each virtual instance Operations System has security features that can be enabled

• Instances are fully isolated from each other
• Security Groups (Firewall) protect ingress and egress access
• Additional AWS Firewall located in the Hypervisor layer

All Instances use Virtual Disks

Automatic storage reset, and memory scrub

EC2 Security Options

Amazon Machine Instances

Instance Choices

Ephemeral Storage

AMI Storage Choices and Key Pairs

Storage Choices

Amazon EC2 Key Pairs

• Public-key cryptography is used to decrypt and encrypt logon information
• Log into your instance you must create a key pair
• The name of the key pair must be linked to your instance at boot
• Linux instance use the key pair to login via SSH
• Windows instances use the key pair to decrypt the Administrator password and login via RDP

If you lose the private key for an instance store-backed instance you can't access the instance. Ever.

EC2 keys used are 2048-bit SSH-2 RSA keys

EC2 Security Options

Interfaces and Addressing

Network Interfaces

Network interfaces are available for instances running in the VPC

Attributes include:

A primary private IPv4 address:

• Default network interface (ethO)
• Cannot be detached from the instance

One or more secondary private IPv4 address

• 1 public IPv4 address
• 1 or more IPv4 addresses
• MAC address

Network interfaces inherit addressing attributes from the associated subnet

EC2 IP Addresses

Elastic Network Interface

When a network interface moves from one instance to another, network traffic is redirected to the new interface location

Elastic IP Addresses

Static IPv4 address linked to your AWS account

• Allocate the address to your account
• Associate the address with a network interface

Public IPv4 address (reachable from the Internet)

Hide the failure of an instance by remapping the address to another instance

A disassociated Elastic IP address remains assigned to your account until deleted

A public IP address auto-assigned by AWS could be considered more secure

Placement Groups

• Logical grouping of instances within a single availability zone
• Connected on the same 10 Gbps network
• For applications that will benefit from low network latency and high network throughput
• Choose an instance type that supports enhanced networking
• SR-IOV Provides higher I/O performance

Network Interfaces and Addresses

Dedicated Instances and Hosts

Dedicated Instances

• EC2 instances running in a VPC dedicated to a single customer
• Dedicated instances are physically isolated at the hardware level of the host
• Dedicated instances may share hardware with other instances from the same AWS account
• Tenancy of an instance can't be changed from multitenant to dedicated after launch
• Tenancy can change from dedicated instance to dedicated host after launch

Dedicated Host

• Physical server with dedicated instance capacity
• Solves potential compliance issues
• Existing per socket, per core, or approved VM software licenses can be used
• Examples: Windows Server, SQL Server, Linux Enterprise Server

Dedicated Host Verses Dedicated Instances

Dedicated Instances

Securing EBS Volumes

EBS Data Volumes

Unformatted block device; wiped just before being made available for use

Customer creates the file system on the EBS volume

Access restricted to:

• AWS account that created the volume
• IAM users granted access

Snapshots can be created and made publicly available to other AWS accounts

Sharing snapshots, does not allow other AWS accounts, the ability to alter or delete the original snapshot

Snapshot Location

Snapshots are not directly accessible in the S3 console

Accessible through the management console or command-line interface (CLI)

Best Practice: Setup schedule for manual replication of important snapshots to a different region for safekeeping

EBS Security

Data stored in the EBS volumes is redundantly stored in multiple physical locations within the same availability zone, not across multiple zones

Best practice:

• Save snapshots to Amazon S3
• Replicate your data across multiple availability zones
• Encrypt your data in transit and at rest

Choices for encryption:

• Operating system
• Amazon EBS encryption
• Third-party products

When encrypted EBS volumes are attached to a supportive instance: the data stored at rest in the volume, the disk I/O, and the snapshots created from the volume are all encrypted.

EBS Volume and Snapshot Security

VPC Architecture

Virtual Private Cloud

• Virtual network for your AWS account
• Isolated network within the AWS cloud
• IP address ranges are chosen by customers
• Can span multiple AZs; However each subnet must reside in one AZs
• Best practice: Use 2 subnets in different AZs for each network layer
• Choose VPC to isolate workloads based on your governance and compliance requiremnts

Multiple VPCs

Choosing Subnets

• Subnets define the range of IP address
• Subnets can be either public or private
• Each subnet is associated with a routing table
• The routing table determines the destination
• Subnets within a VPC can route to each other by default

Public and Private Subnets

Subnet Considerations

Public Subnets:

All public subnets will have a routing table entry point into the Internet gateway

Private Subnets:

A private subnet will have a routing table entry to a Proxy / NAT instance or NAT service

• Protected Subnets (PCI Workloads)
• No access to the Internet

Route Tables

• Each route table has a set of rules (routes) that determine network traffic flow
• The initial route table contains a single rule for local traffic within the VPC
• All instance launched into a VPC will be controlled by their IP address / subnet / route table relationship
• Each subnet in a VPC must be associated with route table
• Best Practice: For best security create custom route tables for your subnets

VPC Peering

Connection between two VPCs

A VPC peering connection does not rely on a single piece of the physical hardware

• Uses private IP addresses to route traffic
• Can also be established with VPCs in other accounts
• All VPCs must be within a single region
• No overlapping of network addresses allowed
• No transitive peering allowed

VPC Setup Options

VPC Security: Part A

VPC Security Components

VPC Security Levels

Security Groups

Security Group Operation Rules

Best Practice: Security Groups

Separate inbound and outbound traffic rules

Multi-Tier Security Groups

VPC Security and Connectivity: Part B

Three Tier Architecture: Security Groups

Network Access Control Lists

• Stateless subnet firewall (optional)
• Inbound and Outbound rules
• Seperate allow and deny of traffic
• Rules are processed in order
• Default NACL allows all traffic to flow both ways
• Best Practice: Number rules by 10's

Gateway Devices

Common external access choices:

• Attaching an Internet Gateway (IGW)
• Attaching a virtual Private Gateway (IGW)

IGW allows you to connect instance located in the VPC to the Internet

The IGW is added as a target to the route table for Internet routable traffic

The VGW allows you to connect your VPC to your on premise data center creating a hybrid design

The VGW enables private connectivity between the Amazon VPC and your on premise network

VPC Access

VPC with Multiple Subnets and HW VPN Access

VPC Security Considerations

Best Practice: Planning Core Infrastructure

Plan Your VPC Architecture

• How many VPCs?
• What are your present and future needs?
• Public or Public / Private?
• Private/HW VPN or Private/SW VPN?
• What external connection type is needed?

Plan Your CIDR blocks

• How many IP addresses are needed?
• Do we need connectivity with a external data center?
• Does your CIDR range overlap with your on premise data center?

Isolate According to Use Case

Seperate VPC for production, staging, and development?

Create one Amazon VPC with separate subnets with security and isolated networking groups for production, staging, and development?

Deploy VPC using CloudFormation

Secure your VPC Components

• Use a firewall virtual appliance you know
• Add intrusion prevention virtual appliances to your VPC
• Encrypt Root and additional EBS volumes
• Configure IAM management policies
• Use Cloud Trail to monitor the VPC environment
• Install antivirus software on EC2 instances hosted on the VPC
• Deploy security groups and NACLs

Check VPC Limits

• Understand hard and soft limits for VPCs
• Limitations are in effect for security groups route tables and subnets
• Ensure your design will not be affected by the limitations
• Request increases in soft limits if limitations will affect your long-term design

Apply IAM to all VPCs

• Ensure IAM policies are attached only to groups or roles
• Design with least access principal

Design Security Wisely

• Design security group for the EC2 instance level
• Use security groups for white listing
• Use NACLs for blacklisting
• Create different security groups for different tiers of your insfrastructure
• (Web, App, DB)
• Standardize security group naming conventions to avoid errors
• Enable VPC flow logging in all VPCs

Everything in Private Subnets

Only ELB or monitoring solutions in public subnets

Secure Internet Gateway Usage

• Don't add IGW to main routing table
• Minimize use of IGW through custom route tables
• Minimize subnet size utilizing NAT or Internet facing proxy services

Use VPC Peering

• For large enterprise running multiple VPCs in single region with interconnected applications; peering allows easy interconnection
• Large enterprise with different AWS accounts for different departments
• Peering with external partners and suppliers
• Peering with cloud brokers providing monitoring and management of AWS resources
• Ensure routing tables for VPC peering are designed for "least access"

Wrap Up

• Securing EC2 instances
• Dedicated Instances and Hosts
• Amazon Machine Instances
• Security Choices for Instances
• Securing EBS volumes
• VPC Security
• VPC Design Criteria
• Best practices when planning Core Infrastructure

Up Next:

Securing Access to Edge Locations

AWS Security Operations: Securing Access to Edge Locations

Why have a course focused on AWS security?

Security is still 25/7 in the cloud

We are never more in danger than when we think ourselves most secure...

Nor in reality more secure than when we seem to be most in danger

This course will help you with AWS edge location security

A working knowledge of AWS services is a bonus but not essential

Topics

• Elastic Load Balancing
• Traffic encryption
• Security policies
• Route 53
• AWS Web Application Firewall
• AWS Shield
• Best practices for Securing Access

Elastic Load Balancing

Elastic Load Balancing distributes incoming traffic across multiple EC2 instances.

Across one, or multiple Availability Zones

Elastic Load Balancing Choices

The classic Load Balancer is designed for web tier load balancing integrated with Auto Scaling Groups

The Application Load Balancer is designed for microservices or container-based architectures

(Think Docker)

(Classic) Load Balancer

Classic ELB Operation

Classic ELB is deployed in a subnet providing a front-end to your web servers providing a first line of defense

• Optionally, application servers, hosted in a private subnet

EC2 instances can be configured to accept traffic only from your load balancer

• When installed in a VPC can use to 5 security groups

Classic ELB Operation

CloudWatch metrics provide operational monitoring of Classic ELB

• Access logs for ELB capture requests made to your load balancer are stored in S3; published every 5 minutes

Cloud Trail can track calls made to your ELB's

Up to 20 load balancer can be created per region for different clients needs (desktop, mobile)

Classic ELB Routing

• The node of an Internet facing load balancer has a public EIP address
• Clients resolve the load balancer's domain name using AWS DNS (Route 53)
• The ELB listener sends request from clients to a healthy registered instance on its private IP address
• DNS round-robin routing is used for TCP listeners
• Least outstanding requests routing is used for HTTP and HTTPS listeners
• Default idle timeout value is 60 seconds - timeout applies to both the front end and backend connection

The classic load balancer routes request to your instances on the private subnet.

Instances do not need public IP addresses to receive public requests

Elastic Load Balancer Operation

Classic ELB Operation

ELB Features

Health Checks

• Unhealthy instances stop receiving traffic

Security Features

• Managed by security groups and NACLs when hosted in a VPC

Supported End-to-End traffic encryption

• HTTP/TLS

SSL Offloading

• SSL termination support

Stricky Sessions

• Associate user session with specific instances using cookies

Encryption and Decryption

ELB provide central management of both encryption and decryption of traffic sent to all instances

• End-to-end traffic encryption is performed using HTTP/TLS
• Centrally manage client security; terminate client connections with TLS certificates

SSL Offload enables encrypted HTTPS sessions between your client to the load-balancer, and to your backend instances

• SSL security policies require the installation of an SSL certificate on the load balancer
• Custom security policies can be used

Classic ELB Security Features

ELB Security Features

ELB Security Policies

Supported ciphers and protocols using SSL/TLS negotiations

Predefinedn Security Policy

• Provided by AWS
• Created according to best AWS security practices
• TLS 1.1, and 1.2, server order preference, high-security ciphers

Custom security policy

• Defined by customers needs
• Matches needed security compliance standards

Application Load Balancer

Application Load Balancer Overview

Supports containerized applications hosted by EC2 container service

Route requests based on target groups selected by the customer

• Traffic is sent to any healthy target in the "target group"
• Makes decisions based on the content of the application traffic (content based routing)

Supports Web Sockets and HTTP/2

• Supports path based routing; listeners forword requests based on the URL (HTTP/HTTPs)
• Supports routing requests to multiple services running on a single instance(container or micro-services)

Application Load Balancer Features

• Access logs for detailed flow
• Up to 1000 targets per load balancer
• Deletion protection can be enabled
• Track request from clients to target via Request Tracing
• Supports IPv6 for Internet ALB hosted in VPC
• Migrate C-ELB configuration to ALB

ALB Operations

Rules can be configured for each listener

• Rules include a Condition, and corresponding Action if condition is satisfied
• EX: Path pattern = /IMG/*
• Action = forword request to S3 bucket

ALB can be integrated with AWS WAF

• Web Application Firewall

ALB is integrated with AWS Certificate Management

• Simple process to bind certificate

Collect metrics on a port basis

• Health checks defined at the target group
• Attach a target group to Auto Scaling group

Elastic Load Balancer Setup

Route 53

Route 53 Overview

• World-wide redundant "Anycast" network
• 100% Availability SLA
• Advanced routing; LBR, Geo DNS, WRR, DNS failover
• Changes are updated within 60 seconds
• API calls monitored via CloudTrail

Route 53 Operation

Provides the location of entry to your service at AWS

• EC2 instances
• Elastic load-balancer

Edge location service

• S3 buckets
• CloudFont (CDN)

Route 53 Operation

Domain registration

• Route 53 can register domain names and automatically configure DNS settings

DNS Service

• Translates domain names into IP address

Health check integration

• Monitors health of your resources

Route 53 Monitoring

Health Checks

• Configured with CloudWatch metrics
• Web applications, endpoints
• Health checks enabled on Alias records

DNS Failover

• Associate a health check with any Resource record set
• Active / Passive failovers

Route 53 Traffic Flow

• Global traffic management service for application access
• Based on latency, geography, and endpoint health
• Create policies to route traffic based on constraints
• Build policies using the visual policy builder
• Rule sets route user requests to your application end points
• No charge for creating a Traffic Policy

Route 53 can also utilize routing policies for global load-balancing between AWS regions

Route 53 Overview

AWS Web Application Firewall

Web Application Firewall

Monitor HTTP and HTTPS requests that are forworded:

• To an Application Load Balancer
• To Amazon CloudFront

Access is based on conditions controlling content access

• Requested content is delivered
• Or HTTP status code (Forbidden)
• CloudFront can return a custom error page

Three basic behaviors can be chosen:

Web Application Firewall

Allow all requests except the ones that you specify

• Block requests from attackers

Block all requests except the ones that you specify

• Serve content for a restricted website to specific users

Count the requests that match the properties that you specify

Protection by Defined Conditions

• IP addresses where requests originate
• Strings that appear in requests
• Length of requests
• Values in request headers
• Presence of malicious SQL code
• Presence of Cross-site scripting

AWS Shield

AWS Shield Overview

Advanced DDoS protection service

AWS Shield Standard: Web applications

• Network and transport layer DDoS attacks
• Configure control of Web ACLs that match the DDoS request patterns
• Configured by Wed Application Firewall service

AWS Shield Advanced: ELB, CloudFront, Route 53

Intelligent attack detection and mitigation for:

• Network layer 3 and 4
• UDP reflection, SYN flood, DNS query flood attacks

• Application layer 7
• HTTP flood / cache-brusting attacks

AWS Shield Advanced

• 24x7 DDoS Response Team for assistance
• Advanced real-time metrics and reports
• Visibility into attacks on your AWS resources
• Cost protection features provided by ELB, CF, and Route 53
• Protection up to 100 CloudFront distros, Route 53 zones, and ELB resources in total
• Self Managed or AWS Managed Service option

Best Practices for Securing Access

AWS Web Application Firewall

Web Application Firewall

Consider Prewarming

Configure the load balancer to have the appropriate level of capacity based on expected traffic

Contact AWS to have your load balancer pre-warmed

• These are some of the questions you will need to have answers for:
• Request rate expected
• Are "keep-alives" used on the backend?
• Percent of traffic using SSL termination on the ELB
• Average amount of data passing through the ELB per request / response
• Number of availability zones that will be used
• Is the backend scaled up and down

Monitor ELB with CloudWatch

Use CloudWatch to monitor the following ELB metrics:

• Latency
• Request count
• Healthy hosts
• Unhealthy hosts
• Backend response (2xx- 5xx)
• Elastic load-balancing response count (2xx- 4xx)

Let ELB perform SSL Termination

Plan to SSL terminate your applications at the ELB

This saves time, CPU processing time for your instances

This also saves administrative overhead

Use Cross Zone Load Balancing

• Plan on placing your instances into multiple availability zones
• Take advantage of cross zone load-balancing
• This provides application availability and resiliency

Rely on Health Checks

Health checks for ELB, and our instances of course!

ELB outage - requests are routed away from the unhealthy ELB

Instance failure - solved by auto scaling groups and ELB integration

Route 53 health checks results are published to all DNS Servers

Do not use A records for domain names; this means hardcoded IP addresses; instead use Alias or CNAME records

Protect your Web App

Place your application behind a load balancer (ELB)

• ELB only accepts well-formed TCP connections
• SYN floods or UDP reflection attacks are not accepted
• ELB detection of attacks prompts scaling to absorb the additional traffic

Use AWS WAF to create mitigation strategy rules

• Block known IP addresses with rules / actions
• Create rules with conditions that block

Use ELB and Auto Scaling groups for horizontal scale of your applications

• Monitor and respond with Cloud Watch alarms

Wrap Up

• Elastic Load Balancing
• Traffic encryption
• Security policies
• Route 53
• AWS Web Application Firewall
• AWS Shield
• Best practices for Securing Access

Up Next: Securing Access to S3 Object Storage

Questions

Thank You..!