Security in AWS

Introduction to AWS Identity and Access Management

1. Authentication
2. Authorization 
3. Users
4. Groups
5. Password Policy
6. Multifactor Authentication

Demo: Creating a User and Group (IAM)

Demo: Creating access Keys

Permissions and Policies

1. Permissions(authorization) granted via policies
2. Policies written in JSON
3. Policy Types - Managed Policy : AWS managed, Customer managed Inline Policy
4. Create policies via - Generator, Hand written policies
5. Evaluation logic - Defaults to implicit deny, Explicit deny, Explicit allow

Amazon Resource Name:

Format Pattern:

1. arn:partition:service:region:account-id:resourceType/resource
2. arn:partition:service:region:account-id:resourceType:resource

Example ARNs

1. arn:aws:iam::123456789012:user/bsmith
2. arn:aws:s3:::mybucket/*
3. arn:aws:rds:us-west-2:123456789012:db:mysql-db

Policies are collections of statements

Statements specify

• Principal(resource-based policies) - resource-based policies
• Actions 
  • ec2:RunInstances
  • s3:ListBucket
• Resources
  • EC2 instances
  • S3 buckets (or objects)
• Conditions 
  • Time of day
  • From specific IP address
  • Resource contains particular tag
  • Etc

Demo: Creating and Attaching Policies

Understanding Roles:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

• Alternate form of authentication
• Uses temporary credenticals
• Allow access from:
  • EC2 instance
  • AWS service
  • A user
  • Separate account
    • Third party
    • One you own

What not to do

• Embed access keys in code
• Embed in environment variables
• Share with 
  • Third parties
  • Hundreds of enterprise users
  • Thousands(millions?) of web users

Demo: Creating Roles

Federated Users

• Organizational users:
  • LEverage existing user directories:
    • LDAP
    • Active Directory
  • Temporary credentials
  • Single sign on
• Web/mobile applications users:
  • Apps bypass backend APSs/proxies

Demo: managing an MFA Device

Resource Policies

• Policies applied to a resource (not limited to):
  • Amazon Simple Storage Service (S3) bucket
  • Amazon DynamoDB table
  • Amazon Simple Queue Service (SQS) queue
• Written in JSON
• Can provide cross-account resource sharing
• Can allow anonymous use

Use Case: Using Roles for Cross Account Access

Best Practices

• Leverage groups
• Grant least privilege
• Implement strong password policy
• Leverage roles for cross-account access
• Use deny statements for added security
• Never share credentials
• Never email, print, or pubilsh to repos
• Multiple accounts for isolation