Building Secure Architectures on AWS

1. Building Secure Architectures
on AWS
Manoj Fernando

2. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

3. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

4. On-premises network architecture

5. 203.0.113.0/28
203.0.113.8/29203.0.113.0/29
> Web servers > Application server
> Database Server

6. CIDR Notation
203.0.113.0/28
Start - 203.0.113.0
Total IP Count - 2 ^ (32-28) = 2 ^ 4 = 16
End – 203.0.113.16
Range – 203.0.113.0 – 203.0.113.16

7. 203.0.113.0/28
Start - 203.0.113.0
Total IP Count - 2 ^ (32-29) = 2 ^ 3 = 8
End – 203.0.113.7
Range – 203.0.113.0 – 203.0.113.7
203.0.113.0/29 203.0.113.8/29
Start - 203.0.113.8
Total IP Count - 2 ^ (32-29) = 2 ^ 3 = 8
End - 203.0.113.16
Range – 203.0.113.8 - 203.0.113.16
Range – 203.0.113.0 – 203.0.113.16
Subnet 01 Subnet 02
Network

8. 203.0.113.0/28
203.0.113.8/29203.0.113.0/29
> Web servers > Application server
> Database Server

9. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Connecting with the On-Premises Network
• Migrating to a serverless architecture
• Securing your serverless architecture
• Review our architecture against Cloud Adoption Framework
• Next Steps…

10. Modeling On-Premises architecture on AWS cloud

11. Shared Responsibility Model
Reference : AWS

12. Web Server Backend Server

13. Setting up our private network

14. Web Server Backend Server
10.0.0.0/16

15. Divide into sub networks

16. Web Server Backend Server
10.0.0.0/16
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2

17. Web Server Backend Server
10.0.0.0/16
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2
10.0.0.1 10.0.1.1

18. Web Server Backend Server
10.0.0.0/16
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2
10.0.0.1 10.0.1.1
Ireland (eu-west-1)
Availability Zone - 01 Availability Zone - 02

19. Setting up an Internet Gateway

20. Web Server Backend Server
10.0.0.0/16
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2
10.0.0.1 10.0.1.1
Ireland (eu-west-1)
Availability Zone - 01 Availability Zone - 02
RouterInternet
Gateway
Internet

21. Web Server Backend Server
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2
10.0.0.1 10.0.1.1
Availability Zone - 01 Availability Zone - 02
RouterInternet
Gateway
(igw)
Internet
Public Subnet Private Subnet
10.0.0.0/16 local
0.0.0.0/0 Internet-gateway-id
Route Table (Subnet 1)
Destination Target

22. Web Server Backend Server
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2
10.0.0.1 10.0.1.1
Availability Zone - 01 Availability Zone - 02
RouterInternet
Gateway
(igw)
Internet
Public Subnet Private Subnet
10.0.0.0/16 local
0.0.0.0/0 Internet-gateway-id
Route Table (Subnet 1)
Destination Target
10.0.0.0/16 local
Route Table (Subnet 2)
Destination Target

23. Setting up a Nat Gateway

24. Web Server Backend Server
10.0.0.1 10.0.1.1RouterInternet
Gateway
(igw)
Internet
Public Subnet Private Subnet
10.0.0.0/16 local
0.0.0.0/0 Internet-gateway-id
Route Table (Subnet 1)
Destination Target
10.0.0.0/16 local
0.0.0.0/0 nat-gateway-id
Route Table (Subnet 2)
Destination Target
NAT Gateway

25. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

26. Securing our cloud network architecture

27. Web Server Backend Server
10.0.0.1 10.0.1.1RouterInternet
Gateway
(igw)
Internet
Public Subnet Private Subnet
10.0.0.0/16 local
0.0.0.0/0 Internet-gateway-id
Route Table (Subnet 1)
Destination Target
10.0.0.0/16 local
0.0.0.0/0 nat-gateway-id
Route Table (Subnet 2)
Destination Target
Can our web server access internet?

28. 203.0.113.0/28
203.0.113.8/29203.0.113.0/29
> Web servers > Application server
> Database Server

29. Security Groups
• Who can access me?
• Applied to AWS Resources
• Eg: EC2 instances, Databases, Load Balancers etc…
• Virtual Firewalls
• You can create inbound and outbound rules in a security group
• Follow the principle of Least Privilege
• Security Groups are stateful
• When architecting your application, list down all the resources and
decide who needs talk to whom and create security groups for your
resources

30. Web Server Backend Server
10.0.0.1 10.0.1.1RouterInternet
Gateway
(igw)
Internet
Public Subnet Private Subnet
Web-Server-SG
Type TargetType Port Source
HTTP 80 0.0.0.0/0
HTTPS 443 0.0.0.0/0

31. 10.0.0.1 10.0.1.1RouterInternet
Gateway
(igw)
Internet
Public Subnet Private Subnet
Web-Server-SG
Type TargetType Port Source
HTTP 80 0.0.0.0/0
HTTPS 443 0.0.0.0/0
Type Port Source
Custom 4000 Web-Server-SG
Backend-Server-SG
Web Server Backend Server

32. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

33. Migrating to Serverless Architecture

34. Web Server
Instance
Backend Server
Instance
www.myapp.com

35. New features can be developed in a serverless
architecture

36. Web Server
Instance
Backend Server
Instance
www.myapp.com
Amazon
CloudFront
/*
/api/*
MySQL DB
(in RDS)
API
Gateway
Lambda
(getUsers Lambda)
/api/users

37. Serverless Means...
Reference: AWS

38. API Gateway + AWS Lambda is the easiest way to
create microservices

39. AWS Lambda Programming Model
Reference: AWS

40. Web Server
Instance
Backend Server
Instance
www.myapp.com
Amazon
CloudFront
/*
/api/*
MySQL DB
(in RDS)
API
Gateway
Lambda
(getUsers Lambda)
/api/users

41. Web Server Backend Server
10.0.0.0/16
10.0.0.0/24Subnet 1 10.0.1.0/24Subnet 2
10.0.0.1 10.0.1.1
Ireland (eu-west-1)
RouterInternet
Gateway
Internet
MySQL DB
(in RDS)

42. How can getUsers lambda access the Database?

43. IAM Roles – What I can do?
• Security group – Who can access me
• IAM Role – What I can do
• Consider the backend server. What it can do?
• It can access the database
• So create an IAM role with database access permissions and attach to
backend EC2 server

44. How can getUsers lambda access the Database?
Step 01
• Run the getUsers lambda inside our VPC so that lambda executes in
our private network
Step 02
• Assign an IAM role for getUsers lambda to read from database

45. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

46. Securing your Serverless Architecture

47. Securing Lambda Function
• Use IAM roles per function and don’t be too permissive
• Leverage principle of least privilege
• Application security best practices still apply
• Mandatory code reviews, static analysis
• Environment variables and sensitive data via KMS and Lambda’s
encryption helpers

48. Encrypting Environment Variables

49. Encrypting Environment Variables

50. How to secure our Identities
(Authentication + Authorization)

51. Too many concerns…
• Need to develop a reliable user directory to manage
identities
• Handling user data and password and protecting privacy
• Prioritizing scalability of your user store
• Implementing token-based authentication
• Support for multiple social identities
• Federation with corporate directories for B2E applications

52. User Pools & Federated Identities
Reference: AWS

53. Authentication & Authorization (API Gateway)
• API Gateway can authenticate and authorize requests to backend
• (eg: Lambda, EC2 Instances, Elastic Search, S3 etc..)
• 3 Main Methods
1. Amazon Cognito User Pools – User Pool Authorizer
2. Amazon Cognito Federated Identities – AWS IAM Authorizer
3. Custom Identity Providers – Custom Authorizer
• Identity Providers
1. Web Identities – Eg: Google, LinkedIn, UserPools
2. Corporate Identities – Eg: Active Directory, LDAP

54. Authentication & Authorization (API Gateway)
• API Gateway can authenticate and authorize requests to backend
• (eg: Lambda, EC2 Instances, Elastic Search, S3 etc..)
• 3 Main Methods
1. Amazon Cognito User Pools – User Pool Authorizer
2. Amazon Cognito Federated Identities – AWS IAM Authorizer
3. Custom Identity Providers – Custom Authorizer
• Identity Providers
1. Web Identities – Eg: Google, LinkedIn, UserPools
2. Corporate Identities – Eg: Active Directory, LDAP

55. Reference: Slideshare

56. Reference: Slideshare

57. Reference: Slideshare

58. Reference: Slideshare

59. Reference: Slideshare

60. Reference: Slideshare

61. Reference: Slideshare

62. Reference: Slideshare

63. Reference: Slideshare

64. Serverless App Security
Reference: Slideshare

65. Other AWS Services for Security
• AWS WAF
• AWS Trusted Advisor
• AWS Cloud Trail
• AWS Cloud Watch
• AWS Inspector
• AWS Config

66. Web Server
Instance
Backend Server
Instance
www.myapp.com
Amazon
CloudFront
/*
/api/*
MySQL DB
(in RDS)
API
Gateway
Lambda
(getUsers Lambda)
/api/users
WAF

67. Other AWS Services for Security
• AWS WAF
• AWS Trusted Advisor
• AWS Cloud Trail
• AWS Cloud Watch
• AWS Inspector
• AWS Config
Reference: AWS

68. Other AWS Services for Security
• AWS WAF
• AWS Trusted Advisor
• AWS Cloud Trail
• AWS Cloud Watch
• AWS Inspector
• AWS Config
Reference: AWS

69. Other AWS Services for Security
• AWS WAF
• AWS Trusted Advisor
• AWS Cloud Trail
• AWS Cloud Watch
• AWS Inspector
• AWS Config

70. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

71. Connecting with On-Premises Network

72. Our AWS VPC On-Premises
Network

73. Our AWS VPC On-Premises
Network
VPN
Connection
VPN
Gateway
Customer
Gateway
10.0.0.0/16 192.168.0.0/16

74. VPN and AWS Direct Connect
• Both allow secure connections between your corporate network and
your VPC
• VPN uses encrypted IPSec tunnel over the internet
• Direct Connect is a dedicated line between the corporate network
and your VPC
• Direct Connect is not affected by uncertainties in the internet and
suitable for large data transfers at high speed

75. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

76. Cloud Adoption Framework
1. Infrastructure Security
2. Identity and Access Management
3. Data Protection
4. Detective Control
5. Incident Response

77. Cloud Adoption Framework
1. Infrastructure Security
2. Identity and Access Management
3. Data Protection
4. Detective Control
5. Incident Response

78. Agenda
• On-premises network architecture
• Modeling on-premises architecture on AWS cloud
• Securing our cloud network architecture
• Migrating to a serverless architecture
• Securing your serverless architecture
• Connecting with the On-Premises Network
• Review our architecture against Cloud Adoption Framework
• Next Steps…

79. Next Steps…
• Read about AWS Well Architected Framework Whitepaper
• Operational Excellence
• Security
• Reliability
• Performance Efficiency
• Security Pillar Whitepaper

80. Thank You!