Would encrypting a database protect against a compromised admin account?How to store keys in a web app which I want to be able to edit via a web page?Encrypting Fields in DatabaseAnonymiszing sensitive data in MySQL DB while retaining searchabilityAny ways to protect my user data on company computers?Proper credit card encryption for use in a blacklistIs this a sensible way to encrypt user data?Securely storing bank account details in databaseSecuring administration networkMost secure way to deliver web app for offline accessEncrypting unique fields in a DatabaseWould removing spaces in a string protect against SQL injection?
What information exactly does an instruction cache store?
White foam around tubeless tires
Is it safe to use two single-pole breakers for a 240v circuit?
Can you pick an advanced rogue talent with the Extra Rogue Talent feat?
Source of the Wildfire?
Why weren't the bells paid heed to in S8E5?
Why was my Canon Speedlite 600EX triggering other flashes?
The meaning of the Middle English word “king”
Single word that parallels "Recent" when discussing the near future
Unexpected Netflix account registered to my Gmail address - any way it could be a hack attempt?
Substring join or additional table, which is faster?
Was the dragon prowess intentionally downplayed in S08E04?
Why are solar panels kept tilted?
Resize before convert or convert before resize?
Is there an academic word that means "to split hairs over"?
Alias for root of a polynomial
Would life always name the light from their sun "white"
Problem in downloading videos using youtube-dl from unsupported sites
OSPF increase bandwidth with load-balancing
How to continually let my readers know what time it is in my story, in an organic way?
A case where Bishop for knight isn't a good trade
Where to find every-day healthy food near Heathrow Airport?
Do Grothendieck universes matter for an algebraic geometer?
How to cope with regret and shame about not fully utilizing opportunities during PhD?
Would encrypting a database protect against a compromised admin account?
How to store keys in a web app which I want to be able to edit via a web page?Encrypting Fields in DatabaseAnonymiszing sensitive data in MySQL DB while retaining searchabilityAny ways to protect my user data on company computers?Proper credit card encryption for use in a blacklistIs this a sensible way to encrypt user data?Securely storing bank account details in databaseSecuring administration networkMost secure way to deliver web app for offline accessEncrypting unique fields in a DatabaseWould removing spaces in a string protect against SQL injection?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I was discussing with someone ways to prevent data disclosure from a compromised admin account on a database server. The other person proposed encrypting the data at rest within the database. It sounds like a good idea, but I wasn't sure if that would protect the data in this scenario.
My thinking is if the attacker has an admin account, they'll also have the ability to access the encryption key. In a typical configuration, would this be the case? Could the system be engineered so that it wouldn't, while still being practical to administer and use? I could see having the admin provide the key when they log in, but I am ignorant on the security implications of that...
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
Now I realize this would definitely come down to implementation specific details, however I am not super familiar with database administration, so I'm struggling to provide a detailed setup for a hypothetical system.
encryption databases system-compromise
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
add a comment |
I was discussing with someone ways to prevent data disclosure from a compromised admin account on a database server. The other person proposed encrypting the data at rest within the database. It sounds like a good idea, but I wasn't sure if that would protect the data in this scenario.
My thinking is if the attacker has an admin account, they'll also have the ability to access the encryption key. In a typical configuration, would this be the case? Could the system be engineered so that it wouldn't, while still being practical to administer and use? I could see having the admin provide the key when they log in, but I am ignorant on the security implications of that...
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
Now I realize this would definitely come down to implementation specific details, however I am not super familiar with database administration, so I'm struggling to provide a detailed setup for a hypothetical system.
encryption databases system-compromise
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
7
A subtle point to be made here is that you're using "admin" in the sense of "a single, all powerful role' whereas, in organizations that are large and sensitive enough, it's very common to segregate duties very strictly around sensitive data, such that the damage done by one single set of credentials is narrow.
– dwizum
May 9 at 17:05
Just wanted to add: your threat model is a bit narrow. I mean, if the DB Admin's account gets hacked, it's not like stuff like Application Level Encryption or User Provided Keys will save the day. You're still getting Ransomware'd, or DOS'ed, or Rooted, etc.
– Kevin
May 9 at 18:18
If you're interested in looking at some bleeding edge research on the topic: Patent 8504876 B2 Aug 6 2013 The thumbnail is that it uses machine learning to define normal use and can block or notify abnormal use, such as attempting to get everything, even by an admin. Anomaly detection for database systems
– user10216038
May 9 at 20:50
Related, see Homomorphic Encryption and Semi-Homomorphic Encryption. Using HE or SHE you can [theoretically] encrypt the fields in the database tables and still compute on them, like SELECT and ORDER BY. The data would be safe from admins at Amazon, Dropbox, Salesforce, etc. The cloud would only have the encrypted data. The data would likely be breached by an admin within the organization, however. A local admin with access to private key can decrypt the query results.
– jww
May 9 at 21:04
add a comment |
I was discussing with someone ways to prevent data disclosure from a compromised admin account on a database server. The other person proposed encrypting the data at rest within the database. It sounds like a good idea, but I wasn't sure if that would protect the data in this scenario.
My thinking is if the attacker has an admin account, they'll also have the ability to access the encryption key. In a typical configuration, would this be the case? Could the system be engineered so that it wouldn't, while still being practical to administer and use? I could see having the admin provide the key when they log in, but I am ignorant on the security implications of that...
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
Now I realize this would definitely come down to implementation specific details, however I am not super familiar with database administration, so I'm struggling to provide a detailed setup for a hypothetical system.
encryption databases system-compromise
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
I was discussing with someone ways to prevent data disclosure from a compromised admin account on a database server. The other person proposed encrypting the data at rest within the database. It sounds like a good idea, but I wasn't sure if that would protect the data in this scenario.
My thinking is if the attacker has an admin account, they'll also have the ability to access the encryption key. In a typical configuration, would this be the case? Could the system be engineered so that it wouldn't, while still being practical to administer and use? I could see having the admin provide the key when they log in, but I am ignorant on the security implications of that...
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
Now I realize this would definitely come down to implementation specific details, however I am not super familiar with database administration, so I'm struggling to provide a detailed setup for a hypothetical system.
encryption databases system-compromise
encryption databases system-compromise
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
edited May 9 at 15:09
Kevin Mirsky
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
asked May 9 at 14:41
Kevin MirskyKevin Mirsky
408112
408112
7
A subtle point to be made here is that you're using "admin" in the sense of "a single, all powerful role' whereas, in organizations that are large and sensitive enough, it's very common to segregate duties very strictly around sensitive data, such that the damage done by one single set of credentials is narrow.
– dwizum
May 9 at 17:05
Just wanted to add: your threat model is a bit narrow. I mean, if the DB Admin's account gets hacked, it's not like stuff like Application Level Encryption or User Provided Keys will save the day. You're still getting Ransomware'd, or DOS'ed, or Rooted, etc.
– Kevin
May 9 at 18:18
If you're interested in looking at some bleeding edge research on the topic: Patent 8504876 B2 Aug 6 2013 The thumbnail is that it uses machine learning to define normal use and can block or notify abnormal use, such as attempting to get everything, even by an admin. Anomaly detection for database systems
– user10216038
May 9 at 20:50
Related, see Homomorphic Encryption and Semi-Homomorphic Encryption. Using HE or SHE you can [theoretically] encrypt the fields in the database tables and still compute on them, like SELECT and ORDER BY. The data would be safe from admins at Amazon, Dropbox, Salesforce, etc. The cloud would only have the encrypted data. The data would likely be breached by an admin within the organization, however. A local admin with access to private key can decrypt the query results.
– jww
May 9 at 21:04
add a comment |
7
A subtle point to be made here is that you're using "admin" in the sense of "a single, all powerful role' whereas, in organizations that are large and sensitive enough, it's very common to segregate duties very strictly around sensitive data, such that the damage done by one single set of credentials is narrow.
– dwizum
May 9 at 17:05
Just wanted to add: your threat model is a bit narrow. I mean, if the DB Admin's account gets hacked, it's not like stuff like Application Level Encryption or User Provided Keys will save the day. You're still getting Ransomware'd, or DOS'ed, or Rooted, etc.
– Kevin
May 9 at 18:18
If you're interested in looking at some bleeding edge research on the topic: Patent 8504876 B2 Aug 6 2013 The thumbnail is that it uses machine learning to define normal use and can block or notify abnormal use, such as attempting to get everything, even by an admin. Anomaly detection for database systems
– user10216038
May 9 at 20:50
Related, see Homomorphic Encryption and Semi-Homomorphic Encryption. Using HE or SHE you can [theoretically] encrypt the fields in the database tables and still compute on them, like SELECT and ORDER BY. The data would be safe from admins at Amazon, Dropbox, Salesforce, etc. The cloud would only have the encrypted data. The data would likely be breached by an admin within the organization, however. A local admin with access to private key can decrypt the query results.
– jww
May 9 at 21:04
7
7
A subtle point to be made here is that you're using "admin" in the sense of "a single, all powerful role' whereas, in organizations that are large and sensitive enough, it's very common to segregate duties very strictly around sensitive data, such that the damage done by one single set of credentials is narrow.
– dwizum
May 9 at 17:05
A subtle point to be made here is that you're using "admin" in the sense of "a single, all powerful role' whereas, in organizations that are large and sensitive enough, it's very common to segregate duties very strictly around sensitive data, such that the damage done by one single set of credentials is narrow.
– dwizum
May 9 at 17:05
Just wanted to add: your threat model is a bit narrow. I mean, if the DB Admin's account gets hacked, it's not like stuff like Application Level Encryption or User Provided Keys will save the day. You're still getting Ransomware'd, or DOS'ed, or Rooted, etc.
– Kevin
May 9 at 18:18
Just wanted to add: your threat model is a bit narrow. I mean, if the DB Admin's account gets hacked, it's not like stuff like Application Level Encryption or User Provided Keys will save the day. You're still getting Ransomware'd, or DOS'ed, or Rooted, etc.
– Kevin
May 9 at 18:18
If you're interested in looking at some bleeding edge research on the topic: Patent 8504876 B2 Aug 6 2013 The thumbnail is that it uses machine learning to define normal use and can block or notify abnormal use, such as attempting to get everything, even by an admin. Anomaly detection for database systems
– user10216038
May 9 at 20:50
If you're interested in looking at some bleeding edge research on the topic: Patent 8504876 B2 Aug 6 2013 The thumbnail is that it uses machine learning to define normal use and can block or notify abnormal use, such as attempting to get everything, even by an admin. Anomaly detection for database systems
– user10216038
May 9 at 20:50
Related, see Homomorphic Encryption and Semi-Homomorphic Encryption. Using HE or SHE you can [theoretically] encrypt the fields in the database tables and still compute on them, like SELECT and ORDER BY. The data would be safe from admins at Amazon, Dropbox, Salesforce, etc. The cloud would only have the encrypted data. The data would likely be breached by an admin within the organization, however. A local admin with access to private key can decrypt the query results.
– jww
May 9 at 21:04
Related, see Homomorphic Encryption and Semi-Homomorphic Encryption. Using HE or SHE you can [theoretically] encrypt the fields in the database tables and still compute on them, like SELECT and ORDER BY. The data would be safe from admins at Amazon, Dropbox, Salesforce, etc. The cloud would only have the encrypted data. The data would likely be breached by an admin within the organization, however. A local admin with access to private key can decrypt the query results.
– jww
May 9 at 21:04
add a comment |
3 Answers
3
active
oldest
votes
Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.
The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data. The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk. It makes abuse of the decrypted data harder to perform and easier to detect.
There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database. Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
3
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
1
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select thesumof the column and the expect the decrypted value to be correct.
– JimmyJames
May 9 at 17:53
1
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
|
show 3 more comments
On a database server, two different admin accounts can exist: the system admin account(s) and the database admin accounts. @gowenfawr's answer already addresses the database admin case, so I will focus on the system admin one.
In that case, you have lost. It is not possible to protect a machine from its administrator, because they have a full access on any file on the system. As a server normally supports unattended reboots, the application will have to be able to extract the database decryption key, and someone with admin priviledges should be able to extract that key too, because it could impersonate the application user.
There are some possible mitigation ways. One is when the data is encrypted client side. In that case, the application only processes encrypted data with no possible access to the clear text one, so even with full access to the machine and to the database it is not possible to decrypt anything. This is a very secure but rather inconvenient way: if users lose their key, the data is definitely lost. Because of that, system admins are generally very reluctant to a security model that ignores them.
Any other way can only be obfuscation: the key or at least the decrypting procedure has to be accessible to the machine. It can be made very complex to find it so that you can hope being able to close the door before the attacker could really extract any clear text data, but it only make sense if you have a global security system which analyses even apparently legitimate accesses to raise warning when an account is used in an unusual way. You end in the classical threat-risk/mitigation-cost question...
The best way would be to separate machines and admins for the database server and the application server. That way the database machine does not know the decryption key hence the database admin cannot extract it. And an application admin has no way to extract everything from the database. But it can still access any data the application can access. Simply having different admin groups has a cost and here again the threat-risk/mitigation-cost question applies.
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
3
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
add a comment |
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database.
Any remote connection to your network should be protected by 2FA (Especially any admin connection). This would mitigate your threat here. Furthermore, depending on the business needs I would like to dissallow access from the VPN VLAN to any VLAN which contains sensitive data such as the DB in question...this may be impossible if you are a virtual company.
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
As for the use of encryption...one could store encryption keys in a secure vault which gives role-based access on a need to know basis. This would mitigate the risk for the specific DB in question if this admin isn't the admin of this DB.
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
1
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
1
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f209857%2fwould-encrypting-a-database-protect-against-a-compromised-admin-account%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.
The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data. The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk. It makes abuse of the decrypted data harder to perform and easier to detect.
There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database. Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
3
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
1
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select thesumof the column and the expect the decrypted value to be correct.
– JimmyJames
May 9 at 17:53
1
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
|
show 3 more comments
Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.
The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data. The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk. It makes abuse of the decrypted data harder to perform and easier to detect.
There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database. Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
3
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
1
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select thesumof the column and the expect the decrypted value to be correct.
– JimmyJames
May 9 at 17:53
1
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
|
show 3 more comments
Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.
The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data. The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk. It makes abuse of the decrypted data harder to perform and easier to detect.
There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database. Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.
The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data. The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk. It makes abuse of the decrypted data harder to perform and easier to detect.
There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database. Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
edited May 9 at 16:40
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
answered May 9 at 15:28
gowenfawrgowenfawr
55.7k11117165
55.7k11117165
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
3
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
1
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select thesumof the column and the expect the decrypted value to be correct.
– JimmyJames
May 9 at 17:53
1
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
|
show 3 more comments
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
3
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
1
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select thesumof the column and the expect the decrypted value to be correct.
– JimmyJames
May 9 at 17:53
1
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
Good point and could be the best solution in the right situation...but I hope it is a small dataset and you don't have a large number of different applications that need to access it.
– DarkMatter
May 9 at 15:33
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
@DarkMatter I've seen it done successfully with a large dataset and multiple applications; it depends on the usage profile. It would be completely inappropriate for, say, data mining. But for transactional data or anything where there's sufficient non-sensitive metadata to use to address the sensitive data, it works just fine.
– gowenfawr
May 9 at 16:40
3
3
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
A benefit to application level encryption is that it allows you to be selective. You can choose to encrypt something sensitive (a field containing SSNs) but not encrypt things that are less sensitive. So - @DarkMatter - you get the flexibility to work around performance or access needs vs security.
– dwizum
May 9 at 17:02
1
1
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select the
sum of the column and the expect the decrypted value to be correct.– JimmyJames
May 9 at 17:53
@a Cvn Most indexes in a DB allow for range searches to be optimized. For example if I want to be able to select all the people in the DB who's name starts with "Wa", an sorted index will make that fast. The encrypted form of "Walen" and "Watkins" would not be expected to be similar. And if an amount column is encrypted, I can't select the
sum of the column and the expect the decrypted value to be correct.– JimmyJames
May 9 at 17:53
1
1
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
@JimmyJames a sorted index would not work, but you could have something akin to a hash index, where you have 26 buckets each assigned to a letter of the alphabet that retain the ID number of the row where the decrypted value starts with that letter. That way, you won't have to decrypt every entry (on average around 5% accounting for letter popularity) while sacrificing only minimal security. it's similar to how Troy Hunt set up his HIBP Azure Table Storage system, but instead of the first X characters of the password hash or the email domain, it's grouped by the first letter.
– Nzall
May 10 at 12:53
|
show 3 more comments
On a database server, two different admin accounts can exist: the system admin account(s) and the database admin accounts. @gowenfawr's answer already addresses the database admin case, so I will focus on the system admin one.
In that case, you have lost. It is not possible to protect a machine from its administrator, because they have a full access on any file on the system. As a server normally supports unattended reboots, the application will have to be able to extract the database decryption key, and someone with admin priviledges should be able to extract that key too, because it could impersonate the application user.
There are some possible mitigation ways. One is when the data is encrypted client side. In that case, the application only processes encrypted data with no possible access to the clear text one, so even with full access to the machine and to the database it is not possible to decrypt anything. This is a very secure but rather inconvenient way: if users lose their key, the data is definitely lost. Because of that, system admins are generally very reluctant to a security model that ignores them.
Any other way can only be obfuscation: the key or at least the decrypting procedure has to be accessible to the machine. It can be made very complex to find it so that you can hope being able to close the door before the attacker could really extract any clear text data, but it only make sense if you have a global security system which analyses even apparently legitimate accesses to raise warning when an account is used in an unusual way. You end in the classical threat-risk/mitigation-cost question...
The best way would be to separate machines and admins for the database server and the application server. That way the database machine does not know the decryption key hence the database admin cannot extract it. And an application admin has no way to extract everything from the database. But it can still access any data the application can access. Simply having different admin groups has a cost and here again the threat-risk/mitigation-cost question applies.
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
3
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
add a comment |
On a database server, two different admin accounts can exist: the system admin account(s) and the database admin accounts. @gowenfawr's answer already addresses the database admin case, so I will focus on the system admin one.
In that case, you have lost. It is not possible to protect a machine from its administrator, because they have a full access on any file on the system. As a server normally supports unattended reboots, the application will have to be able to extract the database decryption key, and someone with admin priviledges should be able to extract that key too, because it could impersonate the application user.
There are some possible mitigation ways. One is when the data is encrypted client side. In that case, the application only processes encrypted data with no possible access to the clear text one, so even with full access to the machine and to the database it is not possible to decrypt anything. This is a very secure but rather inconvenient way: if users lose their key, the data is definitely lost. Because of that, system admins are generally very reluctant to a security model that ignores them.
Any other way can only be obfuscation: the key or at least the decrypting procedure has to be accessible to the machine. It can be made very complex to find it so that you can hope being able to close the door before the attacker could really extract any clear text data, but it only make sense if you have a global security system which analyses even apparently legitimate accesses to raise warning when an account is used in an unusual way. You end in the classical threat-risk/mitigation-cost question...
The best way would be to separate machines and admins for the database server and the application server. That way the database machine does not know the decryption key hence the database admin cannot extract it. And an application admin has no way to extract everything from the database. But it can still access any data the application can access. Simply having different admin groups has a cost and here again the threat-risk/mitigation-cost question applies.
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
3
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
add a comment |
On a database server, two different admin accounts can exist: the system admin account(s) and the database admin accounts. @gowenfawr's answer already addresses the database admin case, so I will focus on the system admin one.
In that case, you have lost. It is not possible to protect a machine from its administrator, because they have a full access on any file on the system. As a server normally supports unattended reboots, the application will have to be able to extract the database decryption key, and someone with admin priviledges should be able to extract that key too, because it could impersonate the application user.
There are some possible mitigation ways. One is when the data is encrypted client side. In that case, the application only processes encrypted data with no possible access to the clear text one, so even with full access to the machine and to the database it is not possible to decrypt anything. This is a very secure but rather inconvenient way: if users lose their key, the data is definitely lost. Because of that, system admins are generally very reluctant to a security model that ignores them.
Any other way can only be obfuscation: the key or at least the decrypting procedure has to be accessible to the machine. It can be made very complex to find it so that you can hope being able to close the door before the attacker could really extract any clear text data, but it only make sense if you have a global security system which analyses even apparently legitimate accesses to raise warning when an account is used in an unusual way. You end in the classical threat-risk/mitigation-cost question...
The best way would be to separate machines and admins for the database server and the application server. That way the database machine does not know the decryption key hence the database admin cannot extract it. And an application admin has no way to extract everything from the database. But it can still access any data the application can access. Simply having different admin groups has a cost and here again the threat-risk/mitigation-cost question applies.
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
On a database server, two different admin accounts can exist: the system admin account(s) and the database admin accounts. @gowenfawr's answer already addresses the database admin case, so I will focus on the system admin one.
In that case, you have lost. It is not possible to protect a machine from its administrator, because they have a full access on any file on the system. As a server normally supports unattended reboots, the application will have to be able to extract the database decryption key, and someone with admin priviledges should be able to extract that key too, because it could impersonate the application user.
There are some possible mitigation ways. One is when the data is encrypted client side. In that case, the application only processes encrypted data with no possible access to the clear text one, so even with full access to the machine and to the database it is not possible to decrypt anything. This is a very secure but rather inconvenient way: if users lose their key, the data is definitely lost. Because of that, system admins are generally very reluctant to a security model that ignores them.
Any other way can only be obfuscation: the key or at least the decrypting procedure has to be accessible to the machine. It can be made very complex to find it so that you can hope being able to close the door before the attacker could really extract any clear text data, but it only make sense if you have a global security system which analyses even apparently legitimate accesses to raise warning when an account is used in an unusual way. You end in the classical threat-risk/mitigation-cost question...
The best way would be to separate machines and admins for the database server and the application server. That way the database machine does not know the decryption key hence the database admin cannot extract it. And an application admin has no way to extract everything from the database. But it can still access any data the application can access. Simply having different admin groups has a cost and here again the threat-risk/mitigation-cost question applies.
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
edited May 10 at 7:37
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
answered May 9 at 15:52
Serge BallestaSerge Ballesta
17.9k33062
17.9k33062
3
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
add a comment |
3
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
3
3
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
This is only really relevant if the app is residing on the same server. You can be system admin of the host holding the DB... but if you're not admin of the box holding the apps that interface in with it, you won't be able to decrypt the DBs contents. For example, if I have \HostDB and \HostApp, and the \HostDB's admin creds were compromised, if all the encrypting/decrypting was done on \HostApp, then the breach wouldn't expose any unencrypted data - because the attacker doesn't have any code/apps/etc that can read the data.
– Kevin
May 9 at 18:01
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
@Kevin: you are absolutely right. In that case the higher risk could come from the application server admin. I have edited my post.
– Serge Ballesta
May 10 at 7:37
add a comment |
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database.
Any remote connection to your network should be protected by 2FA (Especially any admin connection). This would mitigate your threat here. Furthermore, depending on the business needs I would like to dissallow access from the VPN VLAN to any VLAN which contains sensitive data such as the DB in question...this may be impossible if you are a virtual company.
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
As for the use of encryption...one could store encryption keys in a secure vault which gives role-based access on a need to know basis. This would mitigate the risk for the specific DB in question if this admin isn't the admin of this DB.
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
1
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
1
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
add a comment |
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database.
Any remote connection to your network should be protected by 2FA (Especially any admin connection). This would mitigate your threat here. Furthermore, depending on the business needs I would like to dissallow access from the VPN VLAN to any VLAN which contains sensitive data such as the DB in question...this may be impossible if you are a virtual company.
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
As for the use of encryption...one could store encryption keys in a secure vault which gives role-based access on a need to know basis. This would mitigate the risk for the specific DB in question if this admin isn't the admin of this DB.
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
1
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
1
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
add a comment |
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database.
Any remote connection to your network should be protected by 2FA (Especially any admin connection). This would mitigate your threat here. Furthermore, depending on the business needs I would like to dissallow access from the VPN VLAN to any VLAN which contains sensitive data such as the DB in question...this may be impossible if you are a virtual company.
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
As for the use of encryption...one could store encryption keys in a secure vault which gives role-based access on a need to know basis. This would mitigate the risk for the specific DB in question if this admin isn't the admin of this DB.
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database.
Any remote connection to your network should be protected by 2FA (Especially any admin connection). This would mitigate your threat here. Furthermore, depending on the business needs I would like to dissallow access from the VPN VLAN to any VLAN which contains sensitive data such as the DB in question...this may be impossible if you are a virtual company.
My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.
As for the use of encryption...one could store encryption keys in a secure vault which gives role-based access on a need to know basis. This would mitigate the risk for the specific DB in question if this admin isn't the admin of this DB.
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
edited May 9 at 15:26
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
answered May 9 at 15:04
DarkMatterDarkMatter
2,4011121
2,4011121
1
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
1
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
add a comment |
1
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
1
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
1
1
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
"Any remote connection to your network should be protected by 2FA" -- Ah, I should've noted that in the question. I edited it to clarify. I'm aware of other ways to defend against compromised accounts, but I'm mostly curious as to whether the suggestion of encryption was a valid defense. Still, those answers are helpful to those who might come across this.
– Kevin Mirsky
May 9 at 15:19
1
1
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
@KevinMirsky I edited to reflect the new threat model as well.
– DarkMatter
May 9 at 15:26
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f209857%2fwould-encrypting-a-database-protect-against-a-compromised-admin-account%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
7
A subtle point to be made here is that you're using "admin" in the sense of "a single, all powerful role' whereas, in organizations that are large and sensitive enough, it's very common to segregate duties very strictly around sensitive data, such that the damage done by one single set of credentials is narrow.
– dwizum
May 9 at 17:05
Just wanted to add: your threat model is a bit narrow. I mean, if the DB Admin's account gets hacked, it's not like stuff like Application Level Encryption or User Provided Keys will save the day. You're still getting Ransomware'd, or DOS'ed, or Rooted, etc.
– Kevin
May 9 at 18:18
If you're interested in looking at some bleeding edge research on the topic: Patent 8504876 B2 Aug 6 2013 The thumbnail is that it uses machine learning to define normal use and can block or notify abnormal use, such as attempting to get everything, even by an admin. Anomaly detection for database systems
– user10216038
May 9 at 20:50
Related, see Homomorphic Encryption and Semi-Homomorphic Encryption. Using HE or SHE you can [theoretically] encrypt the fields in the database tables and still compute on them, like SELECT and ORDER BY. The data would be safe from admins at Amazon, Dropbox, Salesforce, etc. The cloud would only have the encrypted data. The data would likely be breached by an admin within the organization, however. A local admin with access to private key can decrypt the query results.
– jww
May 9 at 21:04