patternsqlMinor
SQL Server data confidentiality in case of intrusion of machine host
Viewed 0 times
casesqlintrusionconfidentialityhostmachineserverdata
Problem
I have to premit that i am a programmer, and i am trying to learn a bit about DBA even if i don't have the same background.
I am trying to understand what security provide, and how to use, encryption of data at rest, on SQL Server.
My question is, how that encryption will protect data in case of unauthorized access of the machine that host the SQL Server instance?
My guess is not at all.
I mean, assume SQL Server run on a virtual machine placed into a datacenter, and "connected" to internet. If an attacker will gain control of the virtual machine, then i think that data at rest protection can do very little.
In fact, the attacker can, gained admin privilege (as OS user), reset SQL Server credential and log in as 'sa', then even if the SQL Servr file are normally encrypted he can export them in plain text.
In such scenario is there any way to secure SQL Server or in case of breach at OS level the SQL Server is to be considered "lost"?
I am trying to understand what security provide, and how to use, encryption of data at rest, on SQL Server.
My question is, how that encryption will protect data in case of unauthorized access of the machine that host the SQL Server instance?
My guess is not at all.
I mean, assume SQL Server run on a virtual machine placed into a datacenter, and "connected" to internet. If an attacker will gain control of the virtual machine, then i think that data at rest protection can do very little.
In fact, the attacker can, gained admin privilege (as OS user), reset SQL Server credential and log in as 'sa', then even if the SQL Servr file are normally encrypted he can export them in plain text.
In such scenario is there any way to secure SQL Server or in case of breach at OS level the SQL Server is to be considered "lost"?
Solution
My question is, how that encryption will protect data in case of unauthorized access of the machine that host the SQL Server instance? My guess is not at all.
You are correct. Attack vectors which the bad actor can achieve control (varying amounts) of the system will render these technologies useless. For example, they don't even need to get to the VM in your hypothetical case, they just need to get access to SQL Server, so even less privileges required.
In such scenario is there any way to secure SQL Server or in case of breach at OS level the SQL Server is to be considered "lost"?
There are a few ways to accomplish this, and SQL Server does include one of these technologies "out of the box" which is called Always Encrypted (AE).
This, however, assumes a proper setup of AE and pushes the attack vector to endpoints rather than the central server itself. This means if someone would steal or gain access to your VM (same hypothetical situation you described) then they would not be able to get at the data, even as SA. Since the data is encrypted, it'll also be encrypted on disk and in memory (such as someone attaching a debugger, or doing remote process memory scanning, kernel memory scanning, etc.), backups, and in transit on the wire.
Always Encrypted was made for that very scenario, however it falls short on other scenarios. If you're worried about someone gaining access to the VM (I mean, aren't we all?) then it's a layered approach which I'm sure you know, but there are some technologies such as AE which can help stop certain attack vectors.
You are correct. Attack vectors which the bad actor can achieve control (varying amounts) of the system will render these technologies useless. For example, they don't even need to get to the VM in your hypothetical case, they just need to get access to SQL Server, so even less privileges required.
In such scenario is there any way to secure SQL Server or in case of breach at OS level the SQL Server is to be considered "lost"?
There are a few ways to accomplish this, and SQL Server does include one of these technologies "out of the box" which is called Always Encrypted (AE).
This, however, assumes a proper setup of AE and pushes the attack vector to endpoints rather than the central server itself. This means if someone would steal or gain access to your VM (same hypothetical situation you described) then they would not be able to get at the data, even as SA. Since the data is encrypted, it'll also be encrypted on disk and in memory (such as someone attaching a debugger, or doing remote process memory scanning, kernel memory scanning, etc.), backups, and in transit on the wire.
Always Encrypted was made for that very scenario, however it falls short on other scenarios. If you're worried about someone gaining access to the VM (I mean, aren't we all?) then it's a layered approach which I'm sure you know, but there are some technologies such as AE which can help stop certain attack vectors.
Context
StackExchange Database Administrators Q#321750, answer score: 6
Revisions (0)
No revisions yet.