Security on AWS

1. EC2 Instance Profile (IP)
   1. When you create a role in IAM using console, AWS automatically creates a EC2 instance profile with the same name and associates the role with the instance profile. Remember, the names may be same but instance profile and IAM role are two different things.
   2. When you use CLI or SDK API to create IAM Role, you have to create a Instance profile separately, with a name of your choice.
   3. You select EC2 instance profile (not a role) from a list of existing profiles to launch a EC2 (you don’t choose IAM roles)
   4. An instance profile can contain only one IAM role, although a role can be included in multiple instance profiles.
2. EC2 Security
   1. RSA 2048 SSH-2 public/private key pairs are used (don’t confuse these keys with data encryption keys such as the ones provided by S3 or those saved in KMS)
   2. Public key(s) are stored in AWS and used when launching an EC2 instance. Corresponding private key must be saved and protected by you.
   3. Linux uses public key in the EC2 and SSH client needs private key to SSH
   4. Windows: Private key used by console to decrypt admin password
3. EBS Security
   1. EBS volumes are stored redundantly in the same AZ
   2. Can be optionally encrypted using AES-256
   3. Data is encrypted/decrypted as it moves between EC2 instance and EBS storage
   4. Create Snapshot does not encrypt if source volume is not encrypted
   5. Create AMI does not encrypt if source EC2 has unencrypted volumes.
   6. Snapshots and AMIs can be encrypted (check box) while copying from unencrypted snapshots or AMIs.
4. ELB uses TLS   
5. CloudTrail logs are encrypted by default and stored in S3 buckets
6. CloudFront No encryption 
   1. You create Origin Access Identities in CF and associate these with your distributions
   2. Supports signed URLs to control who can access content
7. S3
   1. At rest optionally uses  SSE and client libraries to encrypt data
   2. In flight uses SSL
8. Glacier
   1. At rest automatically uses AES-256 to encrypt data
   2. In flight uses SSL
9. Storage gateway
   1. Asynchronous transfer from on premise software appliance to S3
   2. At rest automatically uses AES-256 to encrypt data and store in S3
   3. In flight uses SSL
10. DynamoDB: Fine grain security at row and column level. Encryption at rest can be enabled only when you are creating a new DynamoDB table. After encryption at rest is enabled, it can’t be disabled. Uses AWS KMS for key.
11. RDS
    1. RDS Security Groups (different from EC2 security groups)
    2. In flight uses SSL
    3. Optional encryption at rest for all database engines supported
12. Redshift
    1. database user permissions are allowed per cluster basis (not per table basis)
    2. uses 4 tier key based architecture to encrypt data using AES-256 at rest
       1. database key
       2. data encryption keys
       3. cluster key
       4. master key
13. Elasticache
    1. uses “Cache security groups” to control access to cache clusters
14. SQS
    1. Data is NOT automatically encrypted
    2. User can encrypt data before sending to SQS and consumer needs decrypt
15. SNS
    1. topic owners can set permission on topics and control who can publish/subscribe these topics
16. EMR
    1. Uses two EC2 security groups one for master nodes and another for slave nodes
    2. Input data can be encrypted before uploading to S3
    3. You will need to add a decryption step to the beginning of your job flow when EMR fetches data from S3
17. Kinesis
    1. Kinesis API is only accessible thru SSL endpoints
18. Workspaces
    1. uses PCoIP protocol