The question is simple, and really interesting at the same time.

How would you keep your data secure in case of a total compromise of your infrastructure? This should NEVER happen, but as we all know, bad things happen, and I'm preparing for the worst.

I have two types of data:

  • Log data (access logs from the application itself, security logs etc.)
  • MySQL backups

We already have a system in place where the MySQL backup and all logs including is getting transferred periodically to Amazon S3 storage.

This will protect us in case of a total crash (should never happen either - Doomsday prepping!)

But what if a malicious hacker were to compromise the entire system? What would be the best solution? He can easily take out our API key and misuse it to delete data from Amazon S3. We have expire rules in places so versioning is a no-go.

I'm thinking of some kind of write-only service running on an entirely different system? Maybe something like Rollbar.com for logs and an entirely different server which pull down the database periodically, for completely off limits storage?

What's your thoughts on my proposed solutions? Do you have any ideas? Comments? Is this secure enough? Any alternatives?

1 Answer 1

  1. Write additional backups to media (DVD/Blu-ray/Tape or a hard disk) and store them offline. This place has to be save from theft, physical damage, ...
  2. Write your logs to another server using rsyslog. This should be a hardened server and remote login must be disabled.

You should also think about encrypting your backups. So if someone gains access (remote @S3 or physical with your backup data) he can not take advantage of your data. Asymmetric encryption has the benefit of allowing you to keep the private key of your system.

  • Thanks! I appreciate the input. We will also do the offline backup, but less frequently. The rsyslog demon is a nice idea, I will add that. I forgot it in my original post: Our backups is already AES-256 encrypted. We thought about it, and "the bad guys" already has full system read-access if they compromise the AES256 key, as this is stored on the database server itself. We decided to keep it simple, we are still a startup. We will however rotate the key periodically just to be safe.
    – Henrik
    Commented May 9, 2014 at 16:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .