This is a quick presentation for AWS Security that I presented for a meet up group

1. AWS SECURITY
PRESENTER: CHRISTOPHER CAPLAN

2. ABOUT ME
Christopher Caplan
IT Support Technician at Ultimate Finance Group
4 Years in supporting companies with implementation with best security best
practices of AWS.
linkedin: https://www.linkedin.com/in/christopher-caplan
christopher.caplan@gmail.com

3. ▸ Introduction to AWS foundational services.
▸ AWS account security best practices.
▸ IAM basics.
▸ Introduction to EC2 security groups.
▸ Introduction to AWS SDK security
▸ Demo
▸ Review
Agenda

4. INTRODUCTION TO AWS
FOUNDATIONAL SERVICES.

5. INTRODUCTION
AWS FOUNDATION SERVICES
▸ EC2
▸ S3
▸ VPC
▸ RDS
▸ IAM

6. AWS EC2.

7. EC2
▸ Is the base of most things with in AWS.
▸ Is virtual infrastructure.
▸ Designed to use other aspects of
AWS.
▸ No restrictions to how you can set up
your instances.

8. AWS S3.

9. S3
▸ Pay As You Go Storage.
▸ Can be used to share files
▸ REST API
▸ High availability

10. AWS VPC.

11. VPC
▸ Allow you to design the
network you want.
▸ Allows to multiple
subnets, so able to create
services that are not
internet facing.
▸ Able to connect to the
certain subnets via VPN
▸ Very simple to use.

12. AWS IAM.

13. TEXT
IAM
▸ Should be the first thing you set up in AWS!
▸ Create users that are allowed to use AWS,
without exposing the root credentials.
▸ Very powerful and fine grained permissions
▸ Can assign roles to individual EC2
instances.
▸ Permissions as code (JSON)

14. AWS SECURITY BEST PRACTICES.

15. SECURITY BEST PRACTICES
▸ Avoid using the root account instead use IAM users.
▸ Ensure that a password policy has been set I.E (must be 9 characters
with 1 symbol and 1 number) or stronger.
▸ Ensure that MFA (multi factor authentication) is enabled for both your
IAM users and Root account and user accounts.
▸ Use IAM roles and policies instead of keys when possible.
▸ Ensure that passwords and API KEYS are being rotated every 90 days
or less.
▸ Ensure that SSH keys are rotated every 90 days or less.

16. AWS API
AWS SDK
▸ Do NOT use the AWS SDK with the Key and secret in code.
▸ This allows for accidental check-in to the VCS and it can get very difficult to
role the keys and secrets at a later date.
▸ The most (if not all) can check if you are using IAM roles if you are in a EC2
instance using them.
▸ If you are not using IAM roles or you are not in an EC2 instances, you can
create environment variables called AWS_ACCESS_KEY_ID and
AWS_SECRET_ACCESS_KEY
▸ If you are using the AWS CLI the SDK is smart enough to get the
credentials from the credentials file. good for a development environment.

17. USING MFA FOR ROOT AND IAM ACCOUNTS
BENEFITS OF USING MFA
▸ Increased security of every aspect of the AWS account
▸ Users will need a MFA compatible devices or software such as
google authenticator which is available on most smart phones.
▸ Users will need to know that the account is using MFA.
▸ MFA can be enabled to API calls. Could be useful for internal
tools

18. IAM BASICS.

19. IAM BASICS
IAM BASICS
▸ IAM breaks down into users and groups.
▸ We manage IAM user and groups access with polices
▸ Able to attach policies to other services.

20. IAM USERS
▸ Should be created as soon as you create an AWS account
▸ Very good for adding users to use the AWS account
▸ Can assign permissions
▸ IAM is set a a global level
▸ All users are assigned no permissions by default.
▸ Users by default get a API secret and key, but can be
disabled.
IAM BASICS

21. IAM BASICS
IAM GROUPS
▸ Used for creating groups of users.
▸ Able to use assign group permissions.

22. IAM BASICS
IAM POLICIES
▸ Are ways to create custom permissions
▸ Everything is set to deny by default.
▸ Are written in JSON.
▸ So therefore can be put into version control.
▸ Can be attached to users, groups and roles.

23. IAM BASICS
IAM ROLES
▸ Roles can be attached to AWS services
▸ Eliminated the need to having API keys stored in your
code
▸ Roles are temporary credentials what only last for 1 hour.
▸ AWS handles everything from creation to destruction.

24. IAM BASICS
CAVEAT WITH IAM ROLES
▸ Due to IAM roles being assigned on EC2 instances creation.
you will not be able to add or change the role name after the
instances is booted. you are able to change the role
permissions

25. IAM POLICIES
IAM POLICIES EXAMPLE
{
"VERSION": "2012-10-17",
"STATEMENT": [
{
"EFFECT": "ALLOW",
"ACTION": "S3:LISTALLMYBUCKETS",
"RESOURCE": "ARN:AWS:S3:::*"
},
{
"EFFECT": "ALLOW",
"ACTION": [
"S3:LISTBUCKET",
"S3:GETBUCKETLOCATION"
],
"RESOURCE": "ARN:AWS:S3:::EXAMPLE-BUCKET-NAME"
},
{
"EFFECT": "ALLOW",
"ACTION": [
"S3:PUTOBJECT",
"S3:GETOBJECT",
"S3:DELETEOBJECT"
],
"RESOURCE": "ARN:AWS:S3:::EXAMPLE-BUCKET-NAME/*"
}
]
}
‣ This allows users to view
certain S3 buckets.
‣This will only allow what
is the actions that are set
as allow. (everything else
is set to deny)

26. INTRODUCTION TO EC2 SECURITY GROUPS.

27. INTRODUCTION TO EC2 SECURITY GROUPS
EC2 SECURITY GROUPS
▸ Is a virtual firewall in front of the every instance.
▸ set to deny everything be default.
▸ Can assign other security groups within the security groups.
▸ Can attach multiple security groups to one instances.

28. DEMO.

29. DEMO
WHAT THIS DEMO IS COVERING
▸ Set up IAM for the first time.
▸ Creating users
▸ Adding MFA to the root account
▸ Attaching a policy to the user.
▸ Creating a role.
▸ Attaching the role to a EC2 instance.
▸ EC2 security groups.

30. REVIEW
REVIEW
▸ Should set up IAM as the first thing you do on any AWS
account.
▸ You should be using MFA for at least your root account.
▸ Use IAM users for your team.
▸ Using IAM Policies for custom permissions.
▸ Use IAM Roles for your instances.

31. REFERENCES
▸ EC2: https://aws.amazon.com/ec2/
▸ S3: https://aws.amazon.com/s3/
▸ VPC: https://aws.amazon.com/vpc/
▸ RDS: https://aws.amazon.com/rds/
▸ IAM: https://aws.amazon.com/iam/
▸ CIS Amazon web services foundations: https://
benchmarks.cisecurity.org/en-us/?
route=permalink.a329c371c6b8fb268a5676caa71dc22a