Security

AWS S3 Security Introduction and Access management

Omid

General Security Concepts | Good to know!

    • protecting data while
      • in-transit (as it travels to and from Amazon S3)  , 2 ways:
        • by using SSL
      • at rest (while it is stored on disks in Amazon S3 data centers) 2 ways:
        • Server Side encryption. (SSE)
        • client-side encryption.
      • In use:
        • Hashing…. (dictionary attack?)
        • Hashing with key
        • Any Encryption

 

S3 Encryption Types  

  • Server Side
    • encrypt your object before saving it on S3 disks
    • decrypt it when you download the objects from S3.
  • Client Side
    • Client-side encryption refers to encrypting data before sending it to Amazon S3
      • Use an AWS KMS-managed customer master key
      • Use a client-side master key (you can use AWS JAVA SDK)
      • Disadvantage: Less matching the AWS ecosystem. You need to manage keys.

 

Client side master key

  • Your client-side master keys and your unencrypted data are never sent to AWS
  • manage your own encryption keys
  • If you lose them, you won’t be able to decrypt your data.
  • When uploading an object
    • You provide a client-side master key to the Amazon S3 encryption client
    • for each object,encryption client locally generates a one-time-use symmetric key
    • The client uploads the encrypted data key and its material description as part of the object metadata
    • The material description helps the client later determine which client-side master key to use for decryption
    • The client then uploads the encrypted data to Amazon S3 and also saves the encrypted data key as object metadata
  • When downloading an object
    • The client first downloads the encrypted object from Amazon S3 along with the metadata
    • Using the material description in the metadata, the client first determines which master key to use to decrypt the encrypted data key.

Server Side Encryption (SSE)

    • Server-side encryption is about data encryption at rest
      • Amazon S3 encrypts your data at the object level as it writes it to disks
      • decrypts it for you when you access it.
      • As long as you authenticate your request and you have access permissions
      • You can’t apply different types of server-side encryption to the same object simultaneously.

3 methods for SSE

  • Server-Side Encryption with Customer-Provided Keys (SSE-C)
  • You manage the encryption keys and Amazon S3 manages the encryption, as it writes to disks, and decryption, when you access your objects
    • S3-Managed Keys (SSE-S3)
    • AWS KMS-Managed Keys (SSE-KMS)

S3-Managed Keys (SSE-S3)

  • Each object is encrypted with a unique key employing strong multi-factor encryption
  • it encrypts the key itself with a master key that it regularly rotates
  • 256-bit Advanced Encryption Standard (AES-256), to encrypt
  • most compatible with ecosystem solutions, and provides strong encryption mechanism.
  • No limitations on velocity and free of charge

 

AWS KMS-Managed Keys (SSE-KMS)

  • Similar to SSE-S3
  • There are separate permissions for the use of an envelope key (that is, a key that protects your data’s encryption key)
  • provides you with an audit trail of when your key was used and by whom
  • you have the option to create and manage encryption keys yourself, or use a default key that is unique to you, the service you’re using, and the region you’re working in.

Limited in velocity : http://docs.aws.amazon.com/kms/latest/developerguide/limits.html

 

Client Side KMS–Managed Customer Master Key (CMK)

  • you provide only an AWS KMS customer master key ID (CMK ID)
  • you don’t have to worry about providing any encryption keys to the Amazon S3 encryption client (for example, the AmazonS3EncryptionClient in the AWS SDK for Java). 2options
    • A plain text version
    • A cipher blob
  • unique data encryption key for each object it uploads.

Additional AWS s3 Safeguards

  1. VPN (site to site)
  2. Identity based policy (IAM)
  3. IP
  4. resource based policy , e.g. :Write Only permissions.

 

Resource Based Policy on s3 

Adding Bucket level permission (not object level) policy example

{

     “Effect”: “Allow”,

     “Principal”: {

               “AWS”: “arn:aws:iam::21111111:root”

           },

     “Action”: [“s3:ListBucket“],

     “Resource”: [“arn:aws:s3:::bucketName“]

   },

Deny Headers of unencrypted objects policy example

{
                “Sid”: “DenyUnEncryptedObjectUploads“,
                “Effect”: “Deny“,
                “Principal”: “*”,
                “Action”: “s3:PutObject“,
                “Resource”: “arn:aws:s3:::<bucket_name>/*”,
                “Condition”: {
                        “Null”: {
                               “s3:x-amz-server-side-encryption“: true
                        }
               }
           }

Deny non AWS s3 SSE encryption policy example

{
                “Sid”: “DenyIncorrectEncryptionHeader”,
                “Effect”: “Deny“,
                “Principal”: “*”,
                “Action”: “s3:PutObject“,
                “Resource”: “arn:aws:s3:::<bucket_name>/*”,
                “Condition”: {
                        “StringNotEquals”: {
                               “s3:x-amz-server-side-encryption”: “AES256“
                         }
                }
           },

Deny non KMS objects policy example

{
                “Sid”: “DenyIncorrectEncryptionHeader“,
                “Effect”: “Deny“,
                “Principal”: “*”,
                “Action”: “s3:PutObject“,
                “Resource”: “arn:aws:s3:::<bucket_name>/*”,
                “Condition”: {
                    “StringNotEquals”: {
                          “s3:x-amz-server-side-encryption”: “aws:kms“
                             }
                   }
           },

 

Identity based policy via IAM on s3

allow s3 read only on all buckets

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

allow s3 write only on spesific buckets

 {
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::myBucekt1",
 "arn:aws:s3:::myBucekt1/*",
 "arn:aws:s3:::myBucekt2",
 "arn:aws:s3:::myBucekt2/*",
 ]
 }
 ]
}

Protecting s3 bucket from accidental delete (protect bucket delete, and policy delete)

{

    “Version”: “2012-10-17”,

    “Statement”: [

        {

            “Sid”: “Stmt1503850588772”,

            “Effect”: “Deny”,

            “Principal”: “*”,

            “Action”: “s3:DeleteBucket”,

            “Resource”: “arn:aws:s3:::walla-mail-bigfiles-eu-west-1-sse”,

            “Condition”: {

                “StringNotLike”: {

                    “aws:userId”: [

                        “xxxxxx:*”,

                        “12345”

                    ]

                }

            }

        },

        {

            “Effect”: “Deny”,

            “Principal”: “*”,

            “Action”: “s3:PutBucketPolicy”,

            “Resource”: “arn:aws:s3:::walla-mail-bigfiles-eu-west-1-sse”,

            “Condition”: {

                “StringNotLike”: {

                    “aws:userId”: [

                        “xxxxxxxx:*”,

                        “12345”

                    ]

                }

            }

        }

    ]

}

Policy to Deny put / delete of s3 policy from anyone but the admin

{
“Sid”: “Stmt1503999310000”,
“Effect”: “Deny”,
“NotPrincipal”: {
“AWS”: “arn:aws:iam::506754145427:user/omid”
},
“Action”: [
“s3:PutBucketPolicy”,
“s3:DeleteBucketPolicy”
],
“Resource”: “arn:aws:s3:::walla-anagog-eu-west-1”
}

Note : json validator to help debug syntax errors in jso

https://jsonformatter.curiousconcept.com/

 

A quick note about  life cycle policy + no delete bucket policy

I would like to confirm that if you have a policy that denies any user/principle the ability to delete an object or it’s version, you can still have a lifecycle rule to expire these objects and the policy will not prevent the lifecycle rule to execute. Lifecycle policy works from backend to process objects and will not engage API calls. So that it is not affected by bucket policy. In your scenario, even if bucket policy is defined to deny all delete operations, lifecycle policy will delete objects after it expires in 120 days and not before the set lifecycle time of 120days

 

Conclusion

  • you have many ways to protect your data
  • we covered all the encryption options in AWS.
  • resource based policy and identity based policy are great, but you can also read about account segregation to have some more flexibility in terms of Data governance.

 

Need to learn more about aws big data (demystified)?



——————————————————————————————————————————

I put a lot of thoughts into these blogs, so I could share the information in a clear and useful way. If you have any comments, thoughts, questions, or you need someone to consult with, feel free to contact me:

https://www.linkedin.com/in/omid-vahdaty/



Leave a Reply