En översikt över fältnivåkryptering på klientsidan i MongoDB

Data kräver ofta avancerad säkerhet på nästan alla nivåer av datatransaktionen för att uppfylla säkerhetspolicyer, efterlevnad och statliga föreskrifter. Organisationens rykte kan förstöras om det finns obehörig åtkomst till känsliga uppgifter, och följaktligen underlåtenhet att följa det skisserade mandatet.

I den här bloggen kommer vi att diskutera några av de säkerhetsåtgärder du kan använda i samband med MongoDB, särskilt med fokus på klientsidan.

Scenarier där data kan nås

Det finns flera sätt som någon kan komma åt din MongoDB-data, här är några av dem...

1. Fångst av data över ett osäkert nätverk. Någon kan komma åt dina data via ett API med ett VPN-nätverk och det blir svårt att spåra dem. Data i vila är ofta boven i det här fallet.
2. En superanvändare som en administratör som har direktåtkomst. Detta händer när du misslyckas med att definiera användarroller och begränsningar.
3. Att ha tillgång till data på disken medan du läser databaser med säkerhetskopior.
4. Läser serverminnet och loggade data.
5. Oavsiktligt avslöjande av data av personalmedlem.

MongoDB-datakategorier och hur de är säkrade

I allmänhet involverar alla databassystem två typer av data: 

1. Data-at-rest :En som lagras i databasfilerna
2. Data-in-transit:En som utförs mellan en klient, server och databasen.

MongoDB har en kryptering i vila-funktion som krypterar databasfiler på disken och förhindrar därmed åtkomst till databasfiler på disken.

Data-in-transit över ett nätverk kan säkras i MongoDB genom Transport Encryption med TLS/SSL genom att kryptera data.

I händelse av att data av misstag avslöjas av en personal, till exempel en receptionist på skrivbordsskärmen, integrerar MongoDB den rollbaserade åtkomstkontrollen som tillåter administratörer att bevilja och begränsa behörighet på samlingsnivå för användare.

Data som överförs via servern kan finnas kvar i minnet och dessa tillvägagångssätt tar inte upp säkerhetsproblemet mot dataåtkomst i serverminnet. MongoDB introducerade därför fältnivåkryptering på klientsidan för att kryptera specifika fält i ett dokument som involverar konfidentiell data.

Kryptering på fältnivå

MongoDB arbetar med dokument som har definierade fält. Vissa fält kan behövas för att hålla konfidentiell information som kreditkortsnummer, personnummer, tålamodsdiagnosdata och så mycket mer.

Kryptering på fältnivå gör det möjligt för oss att säkra fälten och de kan endast nås av en auktoriserad personal med dekrypteringsnycklarna.

Kryptering kan göras på två sätt

1. Använda en hemlig nyckel. En enda nyckel används för både kryptering och dekryptering, så den måste presenteras vid källan och destinationsöverföringen men hållas hemlig av alla parter.
2. Använda en offentlig nyckel. Använder ett par nycklar där den ena används för att kryptera och den andra för att dekryptera

När du använder fältnivåkryptering, överväg att använda en ny databasinstallation istället för en befintlig.

Fältnivåkryptering på klientsidan (CSFLE)

Introducerad i MongoDB version 4.2 Enterprise för att erbjuda databasadministratörer en justering för att kryptera fält som involverar värden som behöver säkras. Det vill säga att den känsliga informationen krypteras eller dekrypteras av klienten och kommuniceras endast till och från servern i krypterad form. Dessutom kommer inte ens superanvändare som inte har krypteringsnycklarna att ha kontroll över dessa krypterade datafält.

Hur man implementerar CSFLE

För att du ska kunna implementera fältnivåkryptering på klientsidan behöver du följande:

1. MongoDB Server 4.2 Enterprise
2. MongoDB  Kompatibel med CSFLE
3. Filsystembehörigheter
4. Specifika språkdrivrutiner. (I vår blogg kommer vi att använda Node.js)

Implementeringsproceduren innefattar:

• En lokal utvecklingsmiljö med en programvara för att köra klient och server
• Genererar och validerar krypteringsnycklarna.
• Konfigurera klienten för automatisk kryptering på fältnivå
• Genomgående operationer när det gäller frågor i de krypterade fälten.

CSFLE-implementering

CSFLE använder kuvertkrypteringsstrategin där datakrypteringsnycklar krypteras med en annan nyckel som kallas huvudnyckeln. Klientapplikationen skapar en huvudnyckel som lagras i den lokala nyckelleverantören, huvudsakligen det lokala filsystemet. Denna lagringsmetod är dock osäker, så i produktionen rekommenderas man att konfigurera nyckeln i ett nyckelhanteringssystem (KMS) som lagrar och dekrypterar datakrypteringsnycklar på distans.

Efter att datakrypteringsnycklarna har genererats lagras de i valvsamlingen i samma MongoDB-replikuppsättning som den krypterade datan.

Skapa huvudnyckel

I node js måste vi generera en 96-byte lokalt hanterad huvudnyckel och skriva den till en fil i katalogen där huvudskriptet körs från: 

$npm install fs && npm install crypto

Sedan i skriptet:

const crypto = require(“crypto”)

const fs = require(“fs”)



try{

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

}catch(err){

throw err;

}

Skapa datakrypteringsnyckel

Denna nyckel lagras i en samling av nyckelvalv där CSFLE-aktiverade klienter kan komma åt nyckeln för kryptering/dekryptering. För att skapa en, behöver du följande:

• Lokalt hanterad huvudnyckel
• Anslutning till din databas, det vill säga MongoDB-anslutningssträngen
• Nyckelvalvets namnområde (databas och samling)

Steg för att generera datakrypteringsnyckeln

1. Läs den lokala huvudnyckeln som genereras innan

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

2. Ange inställningarna för KMS-leverantören som kommer att användas av klienten för att upptäcka huvudnyckeln.

const kmsProvider = {

local: {

key: localMasterKey

}

}

3. Skapa datakrypteringsnyckeln. Vi måste skapa en klient med MongoDB-anslutningssträngen och nyckelvalvets namnområdeskonfiguration. Låt oss säga att vi kommer att ha en databas som heter användare och inuti den en keyVault-samling. Du måste installera uuid-base64 först genom att köra kommandot

$ npm install uuid-base64

Sedan i ditt manus

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();

Du kommer då att få ett resultat som liknar

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

DataKeyId [base64]: 4K13FkSZSLy7kwABP4HQyD==

Klienten måste ha ReadWrite-behörigheter för det angivna nyckelvalvets namnutrymme

4. För att verifiera att datakrypteringsnyckeln skapades

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();

Du bör få något sådant resultat

{

  _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 returnerade dokumentdata innehåller:datakrypteringsnyckel-id (UUID), datakrypteringsnyckel i krypterad form, KMS-leverantörsinformation om huvudnyckel och metadata som dagen för skapande.

Ange fält som ska krypteras med JSON-schemat

En JSON Schema-tillägg används av MongoDB-drivrutinerna för att konfigurera automatisk kryptering och dekryptering på klientsidan av de angivna dokumentfälten i en samling. CSFLE-konfigurationen för det här schemat kräver:krypteringsalgoritmen som ska användas vid kryptering av varje fält, en eller alla krypteringsnycklar krypterade med CSFLE-huvudnyckeln och BSON-typen för varje fält.

Det här CSFLE JSON-schemat stöder dock inte dokumentvalidering annars kommer eventuella valideringsinstanser att orsaka att klienten skickar ett fel.

Kunder som inte är konfigurerade med lämpligt JSON-schema på klientsidan kan begränsas från att skriva okrypterade data till ett fält genom att använda JSON-schemat på serversidan.

Det finns huvudsakligen två krypteringsalgoritmer:slumpmässig och deterministisk.

Vi kommer att definiera någon krypteradMetadatanyckel på rotnivå av JSON-schemat och konfigurera den med fälten som ska krypteras genom att definiera dem i schemats egenskaper, så de kommer att kunna ärva denna krypteringsnyckel .

{

    "bsonType" : "object",

    "encryptMetadata" : {

        "keyId" : // keyId generated here

    },

    "properties": {

        // field schemas here

    }

}

Låt oss säga att du vill kryptera ett bankkontonummerfält, du skulle göra något i stil med:

"bankAccountNumber": {

    "encrypt": {

        "bsonType": "int",

        "algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic"

    }

}

På grund av hög kardinalitet och att fältet är frågebart använder vi den deterministiska metoden. Känsliga fält som blodgrupp som har låg frågeplan och låg kardinalitet kan krypteras med den slumpmässiga metoden.

Arrayfält bör använda slumpmässig kryptering med CSFLE för att förbättra autokryptering för alla element.

Mongocryptd-applikation

Installerat i MongoDB Enterprise Service 4.2 och senare, är detta en separat krypteringsapplikation som automatiserar fältnivåkryptering på klientsidan. När en CSFLE-aktiverad klient skapas, startas denna tjänst automatiskt som standard till:

• Validera krypteringsinstruktionerna som beskrivs i JSON-schemat, identifiera vilka fält som ska krypteras i genomströmningsoperationerna.
• Förhindra operationer som inte stöds från att utföras på de krypterade fälten.

För att infoga data kommer vi att göra den vanliga infogningsfrågan och det resulterande dokumentet kommer att ha exempeldata nedan med avseende på bankkontofältet.

{

…

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

…

}

När en auktoriserad personal utför en förfrågan kommer föraren att dekryptera dessa data och returnera i ett läsbart format, dvs. 

{

…

"bankAccountNumber":43265436456456456756,

…

}

Obs:  Det är inte möjligt att söka efter dokument i ett slumpmässigt krypterat fält om du inte använder ett annat fält för att hitta dokumentet som innehåller en approximation av slumpmässigt krypterad fältdata.

Slutsats

Datasäkerhet bör beaktas på alla nivåer när det gäller en i vila och transit. MongoDB Enterprise 4.2 Server erbjuder utvecklare ett fönster för att kryptera data från klientsidan med hjälp av Client-Side Field Level Encryption och därmed säkra data från databasvärdleverantörerna och osäkra nätverksåtkomst. CSFLE använder kuvertkryptering där en huvudnyckel används för att kryptera datakrypteringsnycklar. Huvudnyckeln bör därför förvaras säkert med hjälp av nyckelhanteringsverktyg som Key Management System.