4

I have a client looking to use AWS S3 buckets for file transfer to other clients. That data may have some sort of protected data in it.

I'd like to set up S3 to use 2-factor or MFA for the login/connection.

I've looked at a bunch of AWS docs, and have found how to use MFA to keep S3 data from being deleted... I've found how to protect the AWS account itself with MFA, but that is not for clients accessing S3.

I see that S3 uses an access ID which is a long and complex random string, and a private key, which is longer.

Questions
1. Can I set up S3 to use some kind of 2 factor authentication?
2. Does the Access ID count for 2 factor since it is random and not tied to a person's name or anything else?

Any other thoughts?

Anders
  • 64,406
  • 24
  • 178
  • 215
MikeP
  • 1,159
  • 7
  • 12

3 Answers3

4

MFA is not designed to prevent any file deletion or change. It's only goal is to make stealing user's credentials much more difficult.

Also, you don't setup MFA for S3 bucket (or object), you setup it for a user. Permissions to that user are specified by ACL's and policies.

So in a way you can "enable MFA for S3". Create users, enable MFA, assign policies. But signed URLs are more suitable for your client's needs.

3

Can I set up S3 to use some kind of 2 factor authentication?

No, because S3 doesn't have authentication of its own.

Does the Access ID count for 2 factor since it is random and not tied to a person's name or anything else?

No, the factors in "two-factor authentication" are different types of things; usually for 2FA it's something you know (a password, a secret key) and something you have (a hardware OTP device). The reason multi-factor auth is so oft-recommended is because it's difficult for an attacker to gain access to both types - a physical thief can steal your phone or keyfob, but won't know your password, and a remote attacker can steal your password or secret key but won't have access to your OTP device.

In addition, Amazon key/secret key pairs are the sole thing you need to access the AWS API (you don't need to know the user's name), so it is not only not a second factor, but is the only factor.


As a first step, it's a very good idea in most cases to enable S3 bucket versioning. This will store old versions of files, which increases your storage costs, but can be a lifesaver if you accidentally delete something important.

In a single Amazon account, you can create sub-accounts and manage them with IAM. This is generally how you should manage multiple users, rather than giving them all shared access to the same account. With IAM, you can add the minimum necessary permissions for each user by assigning the appropriate policies. Thus, if a client needs to be able to read protected files, but doesn't need to write to them, you can give them only read permission - and thus, any breach of their credentials will only give the attacker read access. Similarly, you can provide write access without delete. You can also scope S3 permissions by filepath, and generally have a lot of flexibility to target precisely what you need.

Xiong Chiamiov
  • 9,384
  • 2
  • 34
  • 76
3

This is now possible with AWS S3. The following policy allows users from account one, two and three to put and delete objects with MFA.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": [
      "ACCOUNT-ONE-ID",
      "ACCOUNT-TWO-ID",
      "ACCOUNT-THREE-ID"
    ]},
    "Action": [
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}

Likewise you can write your own policies to enable MFA.

  • Note that the condition only checks that the user is authenticated with MFA, but not *which* MFA. Since account-two and account-three is out of your control, if they are hacked, the hacker can replace the MFA device to his own and could access the bucket. A separate user in your account without the ability to delete its MFA device can be more secure (depending on how you assess your own security) – Tamás Sallai Aug 19 '19 at 06:37