Een overzicht van versleuteling op veldniveau aan de clientzijde in MongoDB

Gegevens vereisen vaak hoogwaardige beveiliging op bijna elk niveau van de gegevenstransactie om te voldoen aan het beveiligingsbeleid, naleving en overheidsvoorschriften. De reputatie van een organisatie kan worden aangetast als er ongeautoriseerde toegang is tot gevoelige gegevens, waardoor het geschetste mandaat niet wordt nageleefd.

In deze blog bespreken we enkele van de beveiligingsmaatregelen die u kunt nemen met betrekking tot MongoDB, met name de klantzijde.

Scenario's waar toegang tot gegevens kan worden verkregen

Er zijn verschillende manieren waarop iemand toegang kan krijgen tot uw MongoDB-gegevens, hier zijn er enkele...

Het vastleggen van gegevens via een onveilig netwerk. Iemand kan toegang krijgen tot uw gegevens via een API met een VPN-netwerk en het zal moeilijk zijn om ze op te sporen. Data in rust is in dit geval vaak de boosdoener.
Een supergebruiker zoals een beheerder die directe toegang heeft. Dit gebeurt wanneer u geen gebruikersrollen en -beperkingen definieert.
Toegang hebben tot gegevens op schijf tijdens het lezen van databases met back-upbestanden.
Het servergeheugen en gelogde gegevens lezen.
Onbedoelde openbaarmaking van gegevens door personeelslid.

MongoDB-gegevenscategorieën en hoe ze worden beveiligd

Over het algemeen omvat elk databasesysteem twee soorten gegevens:

Data-at-rest :Een die is opgeslagen in de databasebestanden
Data-in-transit:Een die wordt uitgevoerd tussen een client, server en de database.

MongoDB heeft een Encryption at Rest-functie die databasebestanden op schijf versleutelt en zo voorkomt toegang tot databasebestanden op schijf.

Gegevens-in-transit via een netwerk kunnen worden beveiligd in MongoDB door middel van transportversleuteling met TLS/SSL door de gegevens te versleutelen.

In het geval dat gegevens per ongeluk openbaar worden gemaakt door een medewerker, bijvoorbeeld een receptioniste op het bureaublad, integreert MongoDB de Role-Based Access Control waarmee beheerders toestemming op collectieniveau kunnen verlenen en beperken voor gebruikers.

Gegevens die via de server worden verwerkt, kunnen in het geheugen blijven en deze benaderingen lossen op geen enkel moment het beveiligingsprobleem op tegen toegang tot gegevens in het servergeheugen. MongoDB introduceerde daarom Client-Side Field Level Encryption voor het coderen van specifieke velden van een document die vertrouwelijke gegevens bevatten.

Encryptie op veldniveau

MongoDB werkt met documenten met gedefinieerde velden. Sommige velden moeten mogelijk vertrouwelijke informatie bevatten, zoals creditcardnummer, burgerservicenummer, gedulddiagnosegegevens en nog veel meer.

Encryptie op veldniveau stelt ons in staat de velden te beveiligen en ze zijn alleen toegankelijk voor geautoriseerd personeel met de decryptiesleutels.

Encryptie kan op twee manieren worden gedaan

Een geheime sleutel gebruiken. Een enkele sleutel wordt gebruikt voor zowel codering als decodering, daarom moet deze worden gepresenteerd bij de bron- en bestemmingstransmissie, maar door alle partijen geheim worden gehouden.
Een openbare sleutel gebruiken. Gebruikt een paar sleutels waarvan de ene wordt gebruikt om te coderen en de andere om te decoderen

Overweeg bij het toepassen van versleuteling op veldniveau een nieuwe databaseconfiguratie te gebruiken in plaats van een bestaande.

Client-Side Field Level Encryption (CSFLE)

Geïntroduceerd in MongoDB versie 4.2 Enterprise om databasebeheerders een aanpassing te bieden om velden te coderen met waarden die moeten worden beveiligd. Dat wil zeggen dat de gevoelige gegevens door de client worden versleuteld of ontsleuteld en alleen in versleutelde vorm van en naar de server worden gecommuniceerd. Trouwens, zelfs supergebruikers die niet over de coderingssleutels beschikken, hebben geen controle over deze gecodeerde gegevensvelden.

CSFLE implementeren

Om de Client-Side Field Level Encryption te kunnen implementeren, hebt u het volgende nodig:

MongoDB Server 4.2 Enterprise
MongoDB Compatibel met CSFLE
Bestandssysteemmachtigingen
Specifieke taalstuurprogramma's. (In onze blog gaan we Node.js gebruiken)

De implementatieprocedure omvat:

Een lokale ontwikkelomgeving met software voor het draaien van client en server
Het genereren en valideren van de coderingssleutels.
De client configureren voor automatische versleuteling op veldniveau
Gehele bewerkingen in termen van zoekopdrachten van de versleutelde velden.

CSFLE-implementatie

CSFLE gebruikt de envelopversleutelingsstrategie waarbij gegevensversleutelingssleutels worden versleuteld met een andere sleutel die de hoofdsleutel wordt genoemd. De Client-toepassing creëert een hoofdsleutel die wordt opgeslagen in de Local Key Provider, in wezen het lokale bestandssysteem. Deze opslagbenadering is echter onveilig en daarom wordt in productie geadviseerd om de sleutel te configureren in een Key Management System (KMS) dat opslaat en ontsleutelt data-encryptiesleutels op afstand.

Nadat de gegevensversleutelingssleutels zijn gegenereerd, worden ze opgeslagen in de kluisverzameling in dezelfde MongoDB-replicaset als de versleutelde gegevens.

Hoofdsleutel maken

In node js moeten we een lokaal beheerde hoofdsleutel van 96 bytes genereren en deze naar een bestand schrijven in de map van waaruit het hoofdscript wordt uitgevoerd:

$npm install fs && npm install crypto

Vervolgens in het script:

const crypto = require(“crypto”)

const fs = require(“fs”)



try{

fs.writeFileSync(‘masterKey.txt’, crypto.randomBytes(96))

}catch(err){

throw err;

}

Gegevenscoderingssleutel maken

Deze sleutel wordt opgeslagen in een sleutelkluisverzameling waar CSFLE-compatibele clients toegang hebben tot de sleutel voor codering/decodering. Om er een te genereren, hebt u het volgende nodig:

Lokaal beheerde hoofdsleutel
Verbinding met uw database, dat wil zeggen de MongoDB-verbindingsreeks
Sleutelkluisnaamruimte (database en verzameling)

Stappen om de gegevenscoderingssleutel te genereren

Lees de lokale hoofdsleutel die eerder wordt gegenereerd

const localMasterKey = fs.readFileSync(‘./masterKey.txt’);

Geef de instellingen van de KMS-provider op die door de client worden gebruikt om de hoofdsleutel te ontdekken.

const kmsProvider = {

local: {

key: localMasterKey

}

}

De gegevenscoderingssleutel maken. We moeten een client maken met de MongoDB-verbindingsreeks en de naamruimteconfiguratie van de sleutelkluis. Laten we zeggen dat we een database hebben met de naam gebruikers en daarin een keyVault-verzameling. U moet uuid-base64 eerst installeren door het commando
. uit te voeren

$ npm install uuid-base64

Vervolgens in je script

const base64 = require('uuid-base64');

const keyVaultNamespace = 'users.keyVaul';

const client = new MongoClient('mongodb://localhost:27017', {

  useNewUrlParser: true,

  useUnifiedTopology: true,

});

async function createKey() {

  try {

    await client.connect();

    const encryption = new ClientEncryption(client, {

      keyVaultNamespace,

      kmsProvider,

    });

    const key = await encryption.createDataKey('local');

    const base64DataKeyId = key.toString('base64');

    const uuidDataKeyId = base64.decode(base64DataKeyId);

    console.log('DataKeyId [UUID]: ', uuidDataKeyId);

    console.log('DataKeyId [base64]: ', base64DataKeyId);

  } finally {

    await client.close();

  }

}

createKey();

Je krijgt dan een resultaat te zien dat lijkt op

DataKeyId [UUID]: ad4d735a-44789-48bc-bb93-3c81c3c90824

DataKeyId [base64]: 4K13FkSZSLy7kwABP4HQyD==

De client moet ReadWrite-machtigingen hebben voor de opgegeven sleutelkluisnaamruimte

Om te controleren of de gegevenscoderingssleutel is gemaakt

const client = new MongoClient('mongodb://localhost:27017', {

  useNewUrlParser: true,

  useUnifiedTopology: true,

});



async function checkClient() {

  try {

    await client.connect();

    const keyDB = client.db(users);

    const keyColl = keyDB.collection(keyVault);

    const query = {

      _id: ‘4K13FkSZSLy7kwABP4HQyD==’,

    };

    const dataKey = await keyColl.findOne(query);

    console.log(dataKey);

  } finally {

    await client.close();

  }

}

checkClient();

Je zou een soortgelijk resultaat moeten krijgen

{

  _id: Binary {

    _bsontype: 'Binary',

    sub_type: 4,

    position: 2,

    buffer: <Buffer 68 ca d2 10 16 5d 45 bf 9d 1d 44 d4 91 a6 92 44>

  },

  keyMaterial: Binary {

    _bsontype: 'Binary',

    sub_type: 0,

    position: 20,

    buffer: <Buffer f1 4a 9f bd aa ac c9 89 e9 b3 da 48 72 8e a8 62 97 2a 4a a0 d2 d4 2d a8 f0 74 9c 16 4d 2c 95 34 19 22 05 05 84 0e 41 42 12 1e e3 b5 f0 b1 c5 a8 37 b8 ... 110 more bytes>

  },

  creationDate: 2020-02-08T11:10:20.021Z,

  updateDate: 2020-02-08T11:10:25.021Z,

  status: 0,

  masterKey: { provider: 'local' }

}

De geretourneerde documentgegevens bevatten:gegevensversleutelingssleutel-ID (UUID), gegevensversleutelingssleutel in versleutelde vorm, KMS-providerinformatie van hoofdsleutel en metagegevens zoals dag van creatie.

Velden specificeren die moeten worden versleuteld met behulp van het JSON-schema

Een JSON Schema-extensie wordt gebruikt door de MongoDB-stuurprogramma's om automatische versleuteling en ontsleuteling aan de clientzijde van de gespecificeerde velden van documenten in een verzameling te configureren. De CSFLE-configuratie voor dit schema vereist:het versleutelingsalgoritme dat moet worden gebruikt bij het versleutelen van elk veld, een of alle versleutelingssleutels die zijn versleuteld met de CSFLE-hoofdsleutel en het BSON-type van elk veld.

Dit CSFLE JSON-schema ondersteunt echter geen documentvalidatie, anders zullen eventuele validatie-instanties ervoor zorgen dat de client een fout genereert.

Clients die niet zijn geconfigureerd met het juiste JSON-schema aan de clientzijde, kunnen worden beperkt in het schrijven van niet-versleutelde gegevens naar een veld met behulp van het JSON-schema aan de serverzijde.

Er zijn hoofdzakelijk twee coderingsalgoritmen:willekeurig en deterministisch.

We zullen een encryptMetadata-sleutel definiëren op rootniveau van het JSON-schema en deze configureren met de velden die moeten worden versleuteld door ze te definiëren in het eigenschappenveld van het schema, zodat ze deze versleutelingssleutel kunnen erven .

{

    "bsonType" : "object",

    "encryptMetadata" : {

        "keyId" : // keyId generated here

    },

    "properties": {

        // field schemas here

    }

}

Stel dat u een veld voor een bankrekeningnummer wilt versleutelen, u zou zoiets doen als:

"bankAccountNumber": {

    "encrypt": {

        "bsonType": "int",

        "algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic"

    }

}

Vanwege de hoge kardinaliteit en het feit dat het veld bevraagbaar is, gebruiken we de deterministische benadering. Gevoelige velden, zoals bloedgroep met een laag zoekplan en een lage kardinaliteit, kunnen worden versleuteld met behulp van de willekeurige benadering.

Arrayvelden moeten willekeurige versleuteling met CSFLE gebruiken om de automatische versleuteling voor alle elementen te verbeteren.

Mongocrypted-toepassing

Geïnstalleerd in de MongoDB Enterprise Service 4.2 en later, is dit een afzonderlijke versleutelingstoepassing die de versleuteling op veldniveau aan de clientzijde automatiseert. Telkens wanneer een CSFLE-client wordt gemaakt, wordt deze service standaard automatisch gestart om:

Bevestig de versleutelingsinstructies beschreven in het JSON-schema, detecteer welke velden moeten worden versleuteld in de doorvoerbewerkingen.
Voorkom dat niet-ondersteunde bewerkingen worden uitgevoerd op de versleutelde velden.

Om de gegevens in te voegen, voeren we de normale invoegquery uit en het resulterende document bevat hieronder voorbeeldgegevens met betrekking tot het bankrekeningveld.

{

…

"bankAccountNumber":"Ac+ZbPM+sk7gl7CJCcIzlRAQUJ+uo/0WhqX+KbTNdhqCszHucqXNiwqEUjkGlh7gK8pm2JhIs/P3//nkVP0dWu8pSs6TJnpfUwRjPfnI0TURzQ==",

…

}

Als geautoriseerd personeel een zoekopdracht uitvoert, ontsleutelt de chauffeur deze gegevens en keert terug in een leesbaar formaat, d.w.z.

{

…

"bankAccountNumber":43265436456456456756,

…

}

Opmerking: Het is niet mogelijk om te zoeken naar documenten in een willekeurig versleuteld veld, tenzij u een ander veld gebruikt om het document te vinden dat een benadering bevat van de willekeurig versleutelde veldgegevens.

Conclusie

Gegevensbeveiliging moet op alle niveaus worden overwogen met betrekking tot één in rust en transit. MongoDB Enterprise 4.2 Server biedt ontwikkelaars een venster om gegevens vanaf de client te versleutelen met behulp van de veldniveau-codering aan de clientzijde, waardoor de gegevens van de databasehostproviders en onveilige netwerktoegang worden beveiligd. CSFLE gebruikt envelopversleuteling waarbij een hoofdsleutel wordt gebruikt om gegevensversleutelingssleutels te versleutelen. De hoofdsleutel moet daarom veilig worden bewaard met behulp van sleutelbeheertools zoals het Sleutelbeheersysteem.