October 2, 2018 at 8:17 pm
Comments posted to this topic are about the item Cloud Backup
October 3, 2018 at 4:41 am
Being in the Cloud is not the issue, not for Backups neither for Applications running fully on S3 or something like that. The problem is rather that secure configuration of such solutions might end up not being that well designed.
Recently I read from a swiss tax income app which was running on S3, that's no problem. The problem was that the bucket storing scanned Documents was publicly readable from anyone who knew which bucket it was.
Still no argument against the Cloud there, just that your strategies should be adopted where possible. Secure your Cold Storage and if possible use encrypted Backups - just in case...
October 3, 2018 at 7:48 am
I think cloud storage is a great option for those that are facing disk space issues in an already constrained server or fileshare...OpEx vs. Capex
If you have never done anything cloud, try following along with a super basic video tutorial I made (do this on a test box, of course):
https://youtu.be/yPVr8GgtAxk
It's Azure, and you will need to go get your own free account set up if you don't already have one. I would imagine some of the SQL-side steps work for AWS as well, but honestly don't know.
Kevin3NF
------------------------------------------------------------------------------------------------Standing in the gap between Consultant and ContractorKevin3NFDallasDBAs.com/BlogWhy is my SQL Log File HUGE?!?![/url]The future of the DBA role...[/url]SQL Security Model in Plain English[/url]
October 3, 2018 at 8:18 am
I would argue the first statement you made about security being the second thing to worry about. Let me say that for you, I am pretty comfortable you take security seriously. So my next comment is assuredly not about you, and probably not most of the people that frequent this site. It is simply about human nature, and the industry as a whole, and mostly about bad management.
Security should be our first concern. Treating it as a lower priority, even if it only follows data integrity, ends up being an excuse for a lot of people to ignore security altogether. "I didn't have time, I had to work on (insert whatever inane excuse you like here)." How often do we hear that people simply didn't have time or resources to work on security? I believe that is probably the number one excuse behind every failure. The number two excuse is to blame the people breaking in, and third is probably blaming Microsoft. My view is we should look at ourselves first. Did we really do everything we could do?
Yes, sometimes the powers that be set artificial limits on us. Therefore, if we start with security first, it is part of what we build. We don't have to get approval to add it later. I know the numbers will vary, but my guess is that adding security on top of a complete project might double the amount of time to delivery, while adding it in from the start might add 5-10%. Regardless, it is always quicker to build it in from the start. Safer too.
Dave
October 3, 2018 at 8:29 am
yesterday...true story
Me: what permissions do they need to do the thing?
Dev: give them sysadmin, its only a dev box
Me: No...we can't do that in prod, so what do they actually need?
Guy that pays my invoices: give them sysadmin
Me: sure...but we're back here in this same conversation next week about prod.
------------------------------------------------------------------------------------------------Standing in the gap between Consultant and ContractorKevin3NFDallasDBAs.com/BlogWhy is my SQL Log File HUGE?!?![/url]The future of the DBA role...[/url]SQL Security Model in Plain English[/url]
October 3, 2018 at 10:13 am
Kevin3NF - Wednesday, October 3, 2018 8:29 AMyesterday...true storyMe: what permissions do they need to do the thing?
Dev: give them sysadmin, its only a dev box
Me: No...we can't do that in prod, so what do they actually need?
Guy that pays my invoices: give them sysadmin
Me: sure...but we're back here in this same conversation next week about prod.
It is so frustrating when that happens! I can't tell you how frequently some support resource wants to start with, not try later, but first thing they want to try, is to open up security completely! OK, in fairness, sometimes if you determine you have security causing an issue, opening it up to confirm that, and then locking it back down, might be OK. As long as you ONLY do that to confirm security is the cause, fine. The belief that fully open security is acceptable while building, is just a bad idea.
Dave
October 3, 2018 at 11:31 am
DinoRS - Wednesday, October 3, 2018 4:41 AMBeing in the Cloud is not the issue, not for Backups neither for Applications running fully on S3 or something like that. The problem is rather that secure configuration of such solutions might end up not being that well designed.Recently I read from a swiss tax income app which was running on S3, that's no problem. The problem was that the bucket storing scanned Documents was publicly readable from anyone who knew which bucket it was.
Still no argument against the Cloud there, just that your strategies should be adopted where possible. Secure your Cold Storage and if possible use encrypted Backups - just in case...
We need to better secure all places where we're putting live data. Cloud, on premise, prod, dev, if it's got real data, secure it well.
October 3, 2018 at 11:34 am
We do need to bake security in from the beginning. This should be a part of all teaching for coding, as well as early on for setting up systems. I get that it's a pain, I agree, but it is incredibly hard to implement later.
I never want devs with sysadmin on anything other than their box. On any development effort, they should not be using sysadmin. I almost think that we ought to have an AppRole role added into the model database, so this exists everywhere and can be used to set security. Make this a part of table designers, of proc snippets, etc. Always set security.
October 3, 2018 at 11:57 am
Perhaps the biggest potential issue I see to cloud backups is the problem of a mis-configured storage bucket (or whatever term the provider uses.) We've all read the various stories of companies that have put data of some sort into a cloud storage area that was mis-configured and had no security set, allowing anyone on the internet to grab themselves a copy of the data.
Obviously, backing up / storing your backups in the cloud have some fairly massive advantages. You can get disaster-resistant storage (in California? Store your backups in a data center in the Midwest or East coast so when the big one hits, you still have a way to recover,) you can get at your data a lot faster than if it's in a warehouse somewhere, etc. But, and it's a big but, you also better make sure that cloud storage is secure so you don't find your company on the news as having had a data leak with you playing the role of the sacrificial goat.
My preference, if I were backing up to a cloud storage, would be to automatically assume that the cloud storage *IS* setup insecurely and then to take measures to protect the backups as much as *I* can from my end. I would take every possible precaution I could so that if / when my backups leaked out to the world, they'd still be non-restorable, at least without using whatever method I used to protect them initially to "in-protect" them. Arguably, you'd even want to do this with a 3rd party application / device, because who's to say *they* don't make a mistake?
I do see the advantages of cloud backups, but you do need to be aware of the potential pitfalls as well, just as with anything else...
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply