TDE Enable???

  • It may be that they want to encrypt certain data to stop people viewing it

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • New Born DBA (1/16/2014)


    Well maybe to protect the data.

    From what? What threats is this going to mitigate?

    TDE isn't a general 'protect the data', it protects the data from specific threats, not all.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • I really appreciate that you guys are trying to give me the best answer possible. The problem is that I don't really know what threats we are trying to protect our data from? There are maybe more than 1000 articles on tde and how to implement it but I haven't seen even 1 article that talks about "Kind of threats tde can't protect your data from are listed below". Its not even that my team is trying to protect the column level data, They are implementing tde on DB level. I don't think that they are aware of the situation that there are many disadvantages of implementing tde on a DB level. Maybe this is the homework from my lead. He wants me to find as much as I can and all the details about tde advantages and disadvantages, so in our next meeting, I am well prepared and not staring at the wall.

    "He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]

  • TDE will protect from two main threats:

    Using the database backup files to restore somewhere else and looking at the data.

    Copying the database data files, attaching to another server, and looking at the data.

    It will not protect against unauthorized access to data via the database engine on the current server.

  • Michael Valentine Jones (1/16/2014)


    TDE will protect from two main threats:

    Using the database backup files to restore somewhere else and looking at the data.

    Copying the database data files, attaching to another server, and looking at the data.

    Exactly. It protects the data at rest. If you implement it for anything else, at best it's doing nothing at worst it's the false sense of security (no none can hack us and steal the credit card numbers, the database is encrypted)

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Well, we are storing personal private information that is confidential. The customer request this information to be encrypted both at rest and in transmission. There are not specific threats that they are worried about -- these are simply requirements imposed by their Legal team based on the nature of the information.

    "He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]

  • TDE does not meet those requirements. It may be part of meeting them or it may not, but it's not sufficient. It also doesn't stop someone from querying the data at rest (connect/hack the app and read the data via a SQL query)

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • What else can be done besides implementing tde?

    "He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]

  • if you encrypt the data at the column level you wont need TDE.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Which raises another question. Let's say if there is a DB which consist of 30 tables. All columns in those tables have to be encrypted. Why its not a good practice to implement TDE? Instead we are implementing column level encryption. In a given circumstances, what difference does it make if we do column level or DB level, at the end everything is encrypted anyway. Are there any advantages that comes with column level encryption and not with DB level encryption?

    "He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]

  • New Born DBA (1/16/2014)


    Which raises another question. Let's say if there is a DB which consist of 30 tables. All columns in those tables have to be encrypted. Why its not a good practice to implement TDE? Instead we are implementing column level encryption. In a given circumstances, what difference does it make if we do column level or DB level, at the end everything is encrypted anyway. Are there any advantages that comes with column level encryption and not with DB level encryption?

    Column level encryption encrypts the data in the table, it cannot be viewed with out first opening the encryption key (which you must have been granted permissions to use). TDE merely encrypts the databases OS files, it does not encrypt the data within the database directly, users may still query the tables and see the data all the time the database is online. What your clients have requested is to encrypt the data inside the online database so that it cannot be read.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • In favour of TDE, it does also automatically encrypt any database backups, users may not just pilfer the backups and go restore them, they'll need the certificate that encrypts the database encryption key.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • New Born DBA (1/16/2014)


    What else can be done besides implementing tde?

    A lot http://www.amazon.com/Securing-SQL-Server-Second-Edition/dp/1597499471/ref=tmm_pap_title_0?ie=UTF8&qid=1389908763&sr=8-1

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • New Born DBA (1/16/2014)


    Why its not a good practice to implement TDE?

    No one said it's not a good practice. What we said is it is not going to meet your requirements.

    at the end everything is encrypted anyway.

    No, it isn't. TDE doesn't prevent someone from connecting to the database and querying the sensitive data when they shouldn't be doing that. All it does is prevent someone from stealing backup files or database files.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Sure, you can encrypt connections to SQL Server but it only uses 40 or 128 bit and based on the client. IMHO column level encryption is better, it's likely you won't need to encrypt every column in every table, only the sensitive data

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 15 posts - 16 through 30 (of 34 total)

You must be logged in to reply to this topic. Login to reply