Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

What if TDE was available in Standard Edition? Expand / Collapse
Author
Message
Posted Monday, July 05, 2010 11:33 PM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, December 19, 2013 2:03 PM
Points: 62, Visits: 379
Comments posted to this topic are about the item What if TDE was available in Standard Edition?
Post #947706
Posted Tuesday, July 06, 2010 1:13 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: 2 days ago @ 7:44 AM
Points: 76, Visits: 379
We've been here with Steve Jones not long ago. I agree TDE would be a great feature to have on standard versions, but a lot of people remarked on how involved it is to set up, and how much it complicates restores. Realistically, I think TDE is probably overkill for most small-medium businesses.
Previously, the discussion was about how without TDE it is impossible to protect a database backup file. Anyone with admin privs on their local machine (ie. almost everyone who owns a computer) can restore the database and take command of it by reassigning all privs as they wish.

How about a less comprehensive encryption that's NOT end to end, but just encrypts the static MDF/LDF data and backup-file-contained data, but strongly with a serious AES-256 algorithm.
That would be a useful medium between the two protection options at present, which are (1) nothing, and (2) truly enterprise strength (and enterprise TCO)

How many small businesses do you know who change IT techs regularly and have trouble keeping track of their passwords, let alone encryption certificates.

Ben
Post #947738
Posted Tuesday, July 06, 2010 1:43 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 31, 2013 3:11 AM
Points: 171, Visits: 444
Very good point Ben. A lot of small businesses simply wont have tech guys at all - they'll hire someone to come in and set things up for them and show them what to do. Having a complex backup/restore process therefore will just put them off, leaving them open to data loss when something less sinister such as a disk failure occurs.
Post #947747
Posted Tuesday, July 06, 2010 1:46 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, April 15, 2013 2:01 AM
Points: 39, Visits: 25
Ideally everyone would use ideal solutions like PostgreSQL 9, and pay for added-value services.

If we don't agree with microsoft prices, or business-class-products categories.. we just have to set up our customers with alternative softwares.

Crying or praying is just not enough.

Yours truly.
Post #947749
Posted Tuesday, July 06, 2010 1:53 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, November 21, 2013 4:45 AM
Points: 11, Visits: 48
Involved? That doesn't make any sense. You create a cert, backup the cert, and alter the database. It's a three step process that is actually simpler than creating a database, table, or any object within a database. It adds exactly 1 step to a restore process - restore the cert first.

I thought making backup compression an Enterprise Edition only feature was just plain stupid. After all, backup compression was on the feature request list for several versions of Sybase, LONG before the very first version of Microsoft SQL Server was licensed. I know it has been requested by hundreds of people for every single version of SQL Server since it has existed as a Microsoft product. My response to the "feature hype" item in the marketing literature was "It's about #&$^ time!"

TDE is another feature that falls into my category of "It's about $&^# time!" and should be available in every edition of SQL Server. I can create a certificate, obfuscate code ("encrypt"), enforce password policies, sign code modules, create logins/users, associate to roles, deal with ownership chains, fill in the blank for security features in every edition. TDE and Extensible Key Management are the only security features that I can think of that are not available in every edition. I can understand EKM being an Enterprise edition only feature. Making TDE an Enterprise edition only feature, in my opinion, is just plain stupid.


Michael Hotek
President - Champion Valley Software, Inc.
http://www.ChampionValleySoftware.com
Post #947755
Posted Tuesday, July 06, 2010 4:18 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, July 08, 2013 5:04 AM
Points: 10, Visits: 154
Is there a workaround for this that is similar to the workaround from before we had backup compression in Standard Edition? Back then it was:
* Backup the database
* Compress the .bak file to .7z or something
* Delete the .bak file
* Let the .7z file be the one that goes onto the tape or whatever your backup medium is

So if people getting stuff off your backup tapes is the issue for you (as per the article):
* Backup the database
* Squish it into some sort of encrypted file, with a strong password
* Send that off to the tape

Or even just turn on your encryption option for the tape.

That doesn't cover you for everything (is still en clair on the disk in Sql Server's working files), but will do for the stolen backup tape scenario in the article.
Post #947801
Posted Tuesday, July 06, 2010 5:55 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 02, 2013 12:15 PM
Points: 1,443, Visits: 711
this would be awesome for us - we end up using a 3rd party tool, instead of buying EE- it's cheaper and achieves the same result.

It would save us quite a bit....
Post #947840
Posted Tuesday, July 06, 2010 6:22 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 06, 2014 1:05 PM
Points: 1,334, Visits: 3,068
What I don't understand is why Mickeysoft would include two new features like TDE and Backup Compresion that are not mutually compatible with each other. If you don't believe this then just try using TDE to encypt a database, then back it up using COMPRESSION and notice how the compression ratio is bascially nullified on an encpyted database using TDE. Great! so, you can encrypt a very large database using TDE with no problem, but you can't take advantage of the new backup compression of that database, so you are out of luck there, at least for now anyway. :)

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #947864
Posted Tuesday, July 06, 2010 6:36 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, April 10, 2014 11:06 AM
Points: 733, Visits: 1,869
TravisDBA (7/6/2010)
What I don't understand is why Mickeysoft would include two new features like TDE and Backup Compresion that are not mutually compatible with each other. If you don't believe this then just try using TDE to encypt a database, then back it up using COMPRESSION and notice how the compression ratio is bascially nullified on an encpyted database using TDE. Great! so, you can encrypt a very large database using TDE with no problem, but you can't take advantage of the new backup compression of that database, so you are out of luck there, at least for now anyway. :)


Because encryption changes the entropy of the data, you need to always compress FIRST (whether database or any other) then encrypt. It does not work well the other way.


...

-- FORTRAN manual for Xerox Computers --
Post #947872
Posted Tuesday, July 06, 2010 6:49 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 06, 2014 1:05 PM
Points: 1,334, Visits: 3,068
I am talking about compressing the backup, not compressing the database then encrypting it,, But anyway, I don't remember seeing that anywhere in SQL 2008 BOL? That would be nice if that little important detail was in there, but what else is new. :)

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #947887
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse