CSA Talk May 2018

From Federal Burro of Information
Jump to navigationJump to search

Abstract

AWS introduces many new capabilities for provisinf IT services. They do so in a software defined way and give you lots of options.

All of the services provided by AWS take se


A Grab Bag of Security Practices

Tools

NTP


MFA

  • root mfa
  • using roles to access account from a central place.
  • using peering to central manage.
    • Diagram
  • using config rules

IAM

  • IAM policy best practices.

Auditing and forensics

    • the cloudtrail -> s3 -> cloudwatch trinity
    • s3 replication
    • s3 imutablity
    • Anomaly detection datadog
  • anti patterns
    • egress backhaul
  • Partners and Vendor: what can my vendor do?

AWS Get Key

You can see all sorts of api calls you can do to “get key” for various services that AWS offers. Google "aws api get key". Here is a summary.

AWS uses keys in a couple of places:

ACM – AWS Certificate Manager – For doing TLS

AWS IAM Keypairs – ssh keys that are the first key that get installed on instances in the case of linux servers, or are used to encrypt the administrator password for windows instances.

AWS API Keys – Keys that users and application uses to make API calls to AWS

AWS KMS - Key Management Service – for encrypting data at rest i.e disks – I’m not skilled on this.

There are a couple of different way they are dealt with.

ACM

Two ways you can use keys here:

1. You make the private and public yourself and upload them to AWS. Then you can use them with AWS services, like databases, and load balancers. You cannot get the private key back once you give it to AWS. Better make sure you don’t loose your copy if you intend to use it somewhere else.

2. Tell AWS to generate both public and private. Then go and use those keys with AWS services. You can never get the private key out of AWS, ergo you can _only_ use this key with AWS services.

Keypairs

There are two ways here as well but slightly different than ACM

1. You make the private and public yourself and upload only the public key to AWS. Now AWS puts the public key “into” new linux instance as they get lit up so you can login. Don’t loose the private key you have or you can’t get into that instance without some major work, (downing the server, unmounting the root disk and mounting is as data disks on a different instance. )

2. Generate the key pair “in” aws, aws gives you the private key , which you store safely, and it retains the public key. You can never get the private key again from aws ( I think it doesn’t keep it ).

AWS API Keys

This is “fully managed” application layer stuff.

AWS _always_ generates these for you.

It always makes an access key and a secret key.

Once the access key and secret are generated and given to you, you can never again get the secret key from AWS. But you can “lookup” the pair by their access key.

You should rotate these as you would passwords.

In all cases it is impossible to ask AWS for the secret key itself.


10 AWS security blunders and how to avoid them | InfoWorld

https://www.infoworld.com/article/3132023/security/10-aws-security-blunders-and-how-to-avoid-them.html

Mistake 1: Not knowing who is in charge of security
Mistake 2: Forgetting about logs
Mistake 3: Giving away too many privileges
Mistake 4: Having powerful users and broad roles
Mistake 5: Relying heavily on passwords
Mistake 6: Exposed secrets and keys
Mistake 7: Not taking root seriously
Mistake 8: Putting everything in one VPC or account
Mistake 9: Leaving wide open connections
Mistake 10: Skimping on encryption