none
Azure Storage - Periodic backup/Data Security/Disaster recovery?

    Întrebare

  • Let's say that I build my web application on Azure platform and use Azure Table/Blob storage. Assume that over a period of 2-years, I have built over 50-100GB of data in Azure storage. How do I mitigate the following risks:

    1. Security breach - Hackers found some vulnerability (be it through spear phishing, other virus, my application code, Azure platform vulnerability, etc.) and are able to obtain my Azure keys and delete my Azure storage account data. It is gone for good, right? 
    2. A rogue employee/ex-employee who has or had access to my Azure storage keys goes and deletes my Azure storage account data.  It is gone for good, right (prosecuting this person wouldn't get my data back, would it?)?
    3. A natural disaster destroys the Azure data center where all my data is stored/replicated. The data is gone for  good, right?
    4. A bug in my code corrupts the data over a period of time and I need before snapshot/backup of this data. 

     How do I protect myself from each of these scenarios while building for the cloud?
    5 septembrie 2011 01:18

Răspunsuri

  • Hi,

     >Security breach - Hackers found some vulnerability (be it through spear phishing, other virus, my application code, Azure platform vulnerability, etc.) and are able to obtain my Azure keys and delete my Azure storage account data. It is gone for good, right?  

    If the hacker gets the key via the security hole of your application you need to fix the issue in your code first. Then regenerate the key and manually recover data. If it's caused by Azure platform itself please refer to our storage SLA:

    http://www.microsoft.com/download/en/details.aspx?id=6656

    To see whether you can get service credit for the specific case.

    Besides, reading the below whitepaper before writing code

    http://www.microsoft.com/windowsazure/Whitepapers/SecurityBestPractices/

    would be helpful to avoid such issues in your application.


     >A rogue employee/ex-employee who has or had access to my Azure storage keys goes and deletes my Azure storage account data.  It is gone for good, right (prosecuting this person wouldn't get my data back, would it?)?

    If it happens you can regenerate the keys so that this employee will no longer be able to access your data. If you have backed up your data you can recover it. Just be sure that the person knows the key of production storage account doesn’t know the key of backup storage account.
    The most important thing I think, is to make sure the keys are well protected. You can regenerate the keys after development so that you can make sure the keys are known by few guys. If one of them exits your company you can regenerate the key, inform whomever you think should know it and change the key in the configuration file.

    >A natural disaster destroys the Azure data center where all my data is stored/replicated. The data is gone for  good, right?
    Please refer to Geo-Replication section in http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx

    >A bug in my code corrupts the data over a period of time and I need before snapshot/backup of this data. 
    Please refer to http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/30/protecting-your-blobs-against-application-errors.aspx


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.




    5 septembrie 2011 09:27

Toate mesajele

  • Hi,

     >Security breach - Hackers found some vulnerability (be it through spear phishing, other virus, my application code, Azure platform vulnerability, etc.) and are able to obtain my Azure keys and delete my Azure storage account data. It is gone for good, right?  

    If the hacker gets the key via the security hole of your application you need to fix the issue in your code first. Then regenerate the key and manually recover data. If it's caused by Azure platform itself please refer to our storage SLA:

    http://www.microsoft.com/download/en/details.aspx?id=6656

    To see whether you can get service credit for the specific case.

    Besides, reading the below whitepaper before writing code

    http://www.microsoft.com/windowsazure/Whitepapers/SecurityBestPractices/

    would be helpful to avoid such issues in your application.


     >A rogue employee/ex-employee who has or had access to my Azure storage keys goes and deletes my Azure storage account data.  It is gone for good, right (prosecuting this person wouldn't get my data back, would it?)?

    If it happens you can regenerate the keys so that this employee will no longer be able to access your data. If you have backed up your data you can recover it. Just be sure that the person knows the key of production storage account doesn’t know the key of backup storage account.
    The most important thing I think, is to make sure the keys are well protected. You can regenerate the keys after development so that you can make sure the keys are known by few guys. If one of them exits your company you can regenerate the key, inform whomever you think should know it and change the key in the configuration file.

    >A natural disaster destroys the Azure data center where all my data is stored/replicated. The data is gone for  good, right?
    Please refer to Geo-Replication section in http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx

    >A bug in my code corrupts the data over a period of time and I need before snapshot/backup of this data. 
    Please refer to http://blogs.msdn.com/b/windowsazurestorage/archive/2010/04/30/protecting-your-blobs-against-application-errors.aspx


    Allen Chen [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.




    5 septembrie 2011 09:27
  • I will mark the above response as answer as I realize that I have some homework to do to figure out how to do backups (production storage account to backup storage account and keep them in sync without affecting application performance), snapshots of my Azure storage data and geo-replication. If there are any other detailed guidelines to do this, please do respond as I don't want to spend a lot of my time coding and configuring for backup and snapshots. I would much rather spend this time on writing my application code.  
    5 septembrie 2011 21:49
  • I agree with the poster.  Can anyone suggest any best practices for backup of table services and sql azure?  Presumably given traffic, it will be most ecomonical to backup to another storage account, perhaps at a different geocenter but I wonder if there are tools available to configure this without requiring code on my part.

    Thanks

    Mark

    9 septembrie 2011 17:04
  • "if it happens you can regenerate the keys so that this employee will no longer be able to access your data. If you have backed up your data you can recover it. Just be sure that the person knows the key of production storage account doesn’t know the key of backup storage account.
    The most important thing I think, is to make sure the keys are well protected. You can regenerate the keys after development so that you can make sure the keys are known by few guys. If one of them exits your company you can regenerate the key, inform whomever you think should know it and change the key in the configuration file."

    Having the keys in configuration files is unsecured as they are in plan text. What would be the best practice to protect these keys are this seems bery vulnerable ?

    Encrypt them ? But then which algo to choose and in case of a symmetric one used how to protect the password and the salt ?

    So regerated the key is not a valid andswer for customers I'm working with.

    I will appreciate any comments from security guys.

    Thanks

    Xavier

    10 februarie 2012 12:17