IT-säkerhet enligt HPS

I mer eller mindre alla system som utvecklas nuförtiden ingår en databas. När säkerhet sedan kommer på tal i samband med utvecklingen kommer ofta också frågan; "borde vi kryptera databasen?". Svaret är (kanske som vanligt) att det beror på... Vem är det du skyddar dig emot och vad menar du egentligen med att "kryptera databasen"? Min uppfattning är att databaser lagrar data, vad innehållet är (utöver datatyp) ska vara egalt och är none of databasens business. På uppmaningen "ge mig kolumn k för de rader där kolumn l är lika med n" ska databasen bara returnera cellens värde, inte oroa sig över innehållet. Krypteringen av innehållet borde alltså skötas av den som förstår det, i vårt fall applikationen som lagrar data i databasen. Databasen själv ska inte ha något med krypteringen att göra.

Bruce Schneier publicerade häromdagen en gammal artikel rörande kryptering av kommunikation v. kryptering av lagrad data som är relevant i sammanhanget:

Cryptography was invented to protect communications: data in motion. This is how cryptography was used throughout most of history, and this is how the militaries of the world developed the science. Alice was the sender, Bob the receiver, and Eve the eavesdropper. Even when cryptography was used to protect stored data -- data at rest -- it was viewed as a form of communication. In "Applied Cryptography," I described encrypting stored data in this way: "a stored message is a way for someone to communicate with himself through time." Data storage was just a subset of data communication.

Historically, the reason key management worked for stored data was that the key could be stored in a secure location: the human brain. [...] In a sense, the keys were stored in a "computer" that was not attached to any network. And there they were safe. [...] This whole model falls apart on the Internet. [...] Keys can no longer be stored in people's brains. They need to be stored on the same computer, or at least the network, that the data resides on. And that is much riskier.

Argumentet är alltså att det är meningslöst att kryptera databasen eftersom nyckeln ändå måste finnas på datorn ifråga. Jag tycker att det här är en för stor förenkling av situationen, man kan enkelt tänka sig en situation där en applikation måste lagra känsliga data i en databas där man inte har kontroll över databasen. Databasen kan skötas av någon DBA du inte litar på eller den kanske delas av applikationer som är sårbara för t ex SQL injection.

 

Men, om du krypterar data i applikationslagret innan du lämnar över det till databasen så behöver du inte lita på att den kan hålla dem hemliga. Dock så kvarstår Bruces poäng; om någon får tillgång till applikationslagret så är spelet tyvärr slut. Men så hade det ju varit om du låtit bli att kryptera också plus att databasen utgör en sårbarhet.

--

Stefan Pettersson