2

In one of my mysql slave servers I have written a daily run script, which 1) stops slave, 2) takes a db dump, 3) starts slave again, 4) encrypts it, 5) copies it to my s3-bucket.

I am using aws-cli to copy the dump to s3-bucket. The issue here is that in case someone gets access to the server he can delete the dumps from the bucket as well, because the aws-cli grants update/delete access for a bucket.

How do I copy the dump to some place (preferably s3) from where if someone gets access to the db server can-not delete the dumps.

When thinking about it what I can come up is, I need a service on a different server which accepts the dump as input and then in turn saves it to s3. This service does not accept any other type of requests. This way I add an extra layer of security to the db backups. The problem is I dont know any such system.

More general question, how do people usually secure their data. If someone gets access to my master database, even by sql injection, he can cause all replications to truncate or delete. There needs to be some sort of regular backup to go back to, in any such case. In case of injection the backups are safe, but in case of access to server its not.

Rajat Singhal
  • 123
  • 4
  • 2
    What about "don't grant delete object permissions to the IAM user or role that's creating the backups?" I don't know what you mean by *" the aws-cli grants update/delete access for a bucket."* The credentials used by the backup server should not have those permissions. – Michael - sqlbot Sep 18 '15 at 03:02
  • Hi @Michael-sqlbot thnx for the hint, I was able to give only putObject permission, and the user used from server, can only put a file there, nothing else.. There is one more issue still there, he can still upload dummy files with same names and override the actual files and corrupt the data.. I tried it and it happened.. Is there any way to stop it, other than attach random string to the name? And plz post this as an answer so that I can accept.. – Rajat Singhal Sep 18 '15 at 08:51
  • I used the versioning to avoid my issue from prev comment.. Plz post an answer.. – Rajat Singhal Sep 18 '15 at 09:10
  • If u don't Sumit it as an Answer in 24 hrs I'll have to accept the given answer... – Rajat Singhal Sep 20 '15 at 19:25

1 Answers1

2

The Principle of least privilege suggests that the first thing you should do would be to remove any unnecessary privileges from the IAM user that is making the backups.

The granularity of the s3:PutObject permission, however, is such that overwriting an existing object is still possible by an account holding only that one privilege, which leaves open the possibility for a malicious user to "delete" your backups by replacing them with empty files.

Enabling object versioning is one remaining piece of the puzzle, since versioning prevents a user with s3:PutObject but without the s3:DeleteObject permission from permanently deleting an object by overwriting it. A user with s3:DeleteObjectVersion permission can still remove versioned objects.

A final step that may be desirable is enabling MFA delete on the bucket. This configuration, which also requires the bucket be versioning-enabled, requires multi-factor authentication for deletion of any version of any object in the bucket.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86