Our expert opinion on cloud.

Opties voor data versleuteling bij AWS

Posted by Bart M. Veldhuis on 21-nov-2017 12:38:02
Find me on:

Disk encryptie van de cloud provider kan in sommige gevallen worden gebruikt om te voorkomen dat er een melding van een datalek moet worden gedaan bij de autoriteit persoonsgegevens. Nou zijn er verschillende situaties denkbaar waarbij een dergelijk incident ontstaat. In dit artikel gebruik ik er vier, maar ik realiseer me dat dit zeker geen uitputtende lijst is.

Situaties waarbij er een beveiligingsincident kan ontstaan:

  1. Een fysieke inbraak bij de cloud provider
  2. Een medewerker van de provider die bewust of onbewust een fout maakt
  3. Een opsporingsverzoek van een niet-Nederlandse overheidsinstelling
  4. Een ongespecificeerd 'datalek' bij de cloudprovider

De eerste twee situaties worden door de provider technisch en procedurematig nagenoeg onmogelijk gemaakt en van de derde is het natuurlijk maar de vraag of je er als klant ooit achter komt. Zoals in het eerdere artikel beschreven is het datalek natuurlijk dé situatie die met de hoogste frequentie zal voorkomen en ook de hoogste impact heeft. Niet zozeer omdat het zo ernstig is wat er zal gebeuren maar omdat de provider simpelweg geen uitspraak kan doen over welke data erbij betrokken is. Lees voor meer informatie het eerdere artikel nog even terug.

Bij het inrichten van encryptie voor 'data at-rest' zijn er twee voor de hand liggende scenario's om uit te kiezen. Te weten: encryptie op disk-niveau of encryptie op applicatie-niveau.

Vanwege diverse redenen zal encryptie op applicatie-niveau lastig te implementeren zijn. Om te beginnen dient dit echt in de applicatiecode te worden verwerkt en het kan bijna niet zonder impact op de applicatiefunctionaliteit worden geïmplementeerd. Als de data versleuteld wordt opgeslagen in de database is het vaak niet meer mogelijk om zoekfunctionaliteit aan te bieden. Voor dit artikel ga ik uit van het scenario encryptie op disk-niveau. Binnen dat scenario zijn er weer een aantal uitvoeringsopties te kiezen. Elk van deze opties hebben we afgewogen op:

  • De financiële impact; welke kosten zijn er aan verbonden
  • De complexiteit bij inrichting; hoeveel werk is het en hoe moeilijk is dat werk
  • De impact op de beheerorganisatie; is er speciale kennis nodig om dit te beheren
  • De mate van bescherming tegen de vier verschillende beveiligingsincident situaties

Ik heb deze encryptie opties uitgewerkt op basis van de dienstverlening van Amazon Web Services (AWS) maar Microsoft Azure (met Key Vault) en Google Compute (met Cloud Key Management) bieden vergelijkbare opties. De focus van de verschillende opties ligt op het managen van de keys.

Optie A: Native disk-encryptie in combinatie met de AWS Key Management Service

Native EBS disk encryption on AWS with KMS

Om de data voor derden onleesbaar te maken gebruiken we de door de provider aangeboden encryptietechnologie. De drie grote hyperscale providers (AWS, Azure, Google) bieden deze functionaliteit allemaal aan. We gebruiken deze technologie omdat deze standaard beschikbaar wordt gemaakt en daarmee makkelijk te implementeren en onderhouden is. Alle drie de grote providers bieden deze dienst zonder meerkosten aan, en alle drie gebruiken ze AES-256 encryptietechnologie. Deze technologie werkt met sleutels die 256bits lang zijn. Dat is op dit moment de industriestandaard en wordt momenteel gezien als onbreekbaar.  Zoals gezegd is het inrichten hiervan bijzonder eenvoudig; een simpele 'vink in de box'  onder de eigenschappen van het datavolume is voldoende. Voor het versleutelen van het opstartvolume is vaak wel een extra handeling nodig. Het beheren van de encryptiesleutels laten we in dit scenario over aan een dienst van AWS: de Key Management Service. Deze dienst vergemakkelijkt het beheren van meerdere encryptiesleutels. Iets wat handmatig al snel niet meer te doen is. De KMS is natuurlijk een beheerde dienst van de provider; dit betekent dat ondanks alle maatregelen de medewerkers van AWS nog steeds toegang zouden kunnen verkrijgen tot de sleutel. De kosten van de beheerde dienst zijn zeer laag, te weten $1 per key per maand en een $0.03 per 10.000 raadplegingen (de eerste 20.000 zijn gratis, in de praktijk is dit vaak voldoende).

Beschermt tegen situaties

1 & 4 (niet tegen 2 en 3 omdat de keys in het services domein van de provider verblijven)

Mate van bescherming

hoog (AES-256 bit, locatie van de keys)

Investeringen en/of maandelijkse kosten

$ (zeer laag)

Implementatie

1 (zeer eenvoudig)

Impact op de performance

1 (minimaal)

Impact voor de beheerorganisatie

1 (minimaal)

(schalen van lopen van 1-5, waarbij 1($) zeer laag en 5($$$$$) zeer hoog is)

Optie B: Native disk-encryptie in combinatie met de AWS Cloud-HSM

Native EBS disk encryption on AWS with CloudHSM

In deze optie gebruiken we dezelfde standaard encryptietechnologie als in de vorige optie; echter plaatsen we nu de keys in een hardwarematige oplossing bij de provider. Deze hardware appliance wordt per klant uitgegeven en de provider heeft geen toegang tot de sleutels die erin worden bewaard. Dit betekent dat er bij de gebruiker processen moeten worden ingericht om de moedersleutels te bewaren en roteren. Dit verhoogt de complexiteit bij het beheer en maakt de implementatie een stukje ingewikkelder. Daarnaast worden ook er ook hogere kosten in rekening gebracht. Een Cloud-HSM kost bij AWS ongeveer $1.400 per maand per stuk en één is géén dus we gebruiken er minimaal twee. Omdat de provider geen toegang heeft tot de sleutels beschermt deze ook tegen situaties 2 en 3.

 

 

Beschermt tegen situaties

1,2,3 en 4

Mate van bescherming

Zeer hoog (AES-256 bit, geen zorgen over de locatie van de keys)

Investeringen en/of maandelijkse kosten

$$$$ (hoog, minimaal $1.400 per maand)

Implementatie

3 (gemiddeld, vooral procesmatige inrichting)

Impact op de performance

1 (minimaal)

Impact voor de beheerorganisatie

2 (enige impact vanwege de complexe processen)

Optie C: Disk-encryptie op basis van een Crypto File-System

Disk encryption with a crypto-file-system

Bij deze gebruiken we geen diensten van de provider om data te versleutelen maar doen we dat binnen de instances (virtuele machines) door gebruik te maken van een encryptie filesystem binnen het operating system. Er zijn hier diverse varianten van verkrijgbaar waarvan Crypto-FS waarschijnlijk de bekendste is voor Linux distributies; voor Microsoft Windows servers heeft Microsoft zelf technologie aan boord (EFS) in het filesystem voor servers. Deze variant heeft veruit de hoogste complexiteit voor de beheerders bij inrichting en het beheer ervan. Daarnaast levert het beheren van de diverse encryptiesleutels in dit scenario een lastige situatie op. Het is de optie waarbij we de grootste mate van zekerheid hebben dat de provider geen toegang heeft tot onze data.

 

 

 

Beschermt tegen situaties

1,2,3 en 4

Mate van bescherming

Extreem hoog (AES-256 bit of hoger, keys in eigen beheer)

Investeringen en/of maandelijkse kosten

$(nihil)

Implementatie

5 (in verhouding de complexste inrichting)

Impact op de performance

3 (optie met de hoogste impact op de prestaties)

Impact voor de beheerorganisatie

4 (lastiger uit te voeren; zeker in combinatie met handmatig sleutelbeheer)

 

 Ons advies: Kies voor standaard disk-encryptie in combinatie met AWS KMS

Wij adviseren onze klanten om een keuze te maken uit optie A en B waarbij het zwaartepunt van het besluit moet liggen op het vertrouwen in de provider om de managed Key Service netjes uit te voeren en door middel van haar beheerprocessen ervoor te zorgen dat medewerkers geen toegang verschaffen tot de sleutels van klanten. Deze situatie is voor de meeste van onze klanten uitstekend te overzien; voor diegenen die zich nog zorgen maken over het beheer van de sleutels adviseren we optie B op basis van de Cloud-HSM oplossing te overwegen. Ondanks de hoge kosten is dit een zeer goede optie met een extreem hoge mate van zekerheid.

Topics: Cloud Security, Data Security