PII-datakryptering – Bästa praxis

Personligt identifierbar information (PII) är all data som kan användas för att unikt identifiera en individ: namn, e-postadress, telefonnummer, finansiella kontonummer, hälsojournaler och liknande attribut. Obehörig exponering av PII utlöser tre sammansatta risker: förlust av konsumentförtroende, direkt ekonomisk påverkan (IBM/Ponemon Cost of a Data Breach Report 2023 placerade den globala genomsnittliga kostnaden för dataintrång på 4.45 miljoner dollar) och rättsliga och regulatoriska påföljder enligt GDPR , HIPAA , CCPA och PCI DSS . Den rekommenderade åtgärden: klassificera all PII efter känslighet och regulatorisk kategori, kryptera vilande data med AES-256-GCM, tillämpa TLS 1.3 för all data under överföring, hantera nycklar separat från krypterad data med hjälp av ett FIPS-validerat nyckelhanteringssystem och tillämpa tokenisering för PII som inte behöver bearbetas nedströms.

Snabbt svar: Vilka är de bästa metoderna för PII-datakryptering?

Bästa praxis för kryptering av PII-data täcker tre faser av datalivscykeln. I vila: använd AES-256-GCM för kryptering på databas- och filnivå; lagra krypteringsnycklar separat från krypterad data i en FIPS 140-2 nivå 2 eller högre HSM eller KMS; rotera nycklar enligt ett definierat schema (ett till tre år för datakrypteringsnycklar enligt NIST SP 800-57); och tillämpa tokenisering för PII-värden (t.ex. betalkortsnummer) som nedströmssystem behöver referera till utan att bearbeta det faktiska värdet. Under överföring: tillämpa TLS 1.3 för all PII som överförs mellan system; validera servercertifikat från betrodda certifikatutfärdare; använd ömsesidig TLS (mTLS) för kommunikation mellan tjänster i interna miljöer. I användning: tillämpa datamaskering för icke-produktionsmiljöer; tillämpa åtkomstkontroller så att endast system och användare med ett legitimt behov kan komma åt dekrypterad PII; och logga all åtkomst till PII-datalager med tillräcklig detaljnivå för kriminalteknisk undersökning och demonstration av efterlevnad.

Vad är personligt identifierbar information (PII)?

PII är all data som kan användas för att unikt identifiera, kontakta eller lokalisera en individ, antingen ensamt eller i kombination med annan information. De flesta integritetsregler definierar två nivåer:

• Direkt PII: uppgifter som identifierar en individ på egen hand. Exempel inkluderar fullständigt namn, e-postadress, telefonnummer, fysisk adress, nationellt identifikationsnummer (personnummer, nationellt ID), passnummer, körkortnummer och finansiella kontonummer.
• Känslig personligt identifierbar information: uppgifter som kräver ökat skydd eftersom exponeringen orsakar allvarligare skada. Exempel inkluderar hälso- och medicinsk information, biometriska uppgifter, finansiella kontonummer, ras eller etniskt ursprung, sexuell läggning och religiös övertygelse. Känsliga personliga identifierbara uppgifter omfattas av de strängaste skyddskraven enligt GDPR, HIPAA, PCI DSS och liknande bestämmelser.

Det första steget i kryptering av PII-data är dataklassificering: att identifiera vilka data i organisationens system som kvalificerar som PII, vilken kategori av PII det är och vilka myndighetskrav som gäller för dem. Denna klassificering styr skyddskraven. Hälsoinformation regleras av HIPAA; betalkortsdata av PCI DSS; europeiska personuppgifter av GDPR; kaliforniska konsumenters personuppgifter av CCPA. Vissa data regleras av flera regler samtidigt.

Lokalisering av personligt identifierbar information: Dataupptäckt

När PII-kategorier har definierats är nästa steg att lokalisera all PII i hela företaget. PII-data finns sällan på ett ställe: den ackumuleras i produktionsdatabaser, applikationsloggar, säkerhetskopieringssystem, analysdatalager, utvecklings- och testmiljöer, e-postarkiv och molnlagring. Dataupptäckt innebär att man bedömer var varje kategori av PII lagras och bearbetas i alla dessa miljöer. Dataupptäcktsverktyg automatiserar skanning efter mönster som överensstämmer med PII (namn, e-postadresser, kreditkortsnummer, personnummerformat) i strukturerade databaser och ostrukturerade fillager. Resultatet av dataupptäckten är en PII-datakarta: en registrering av var varje kategori av PII finns, vilka system som bearbetar den och vilka kontroller som finns på plats.

Krypteringstekniker och algoritmval

Användningsfall	Rekommenderad algoritm	Nyckelstorlek	Vad som ska undvikas	Hänvisning
PII i vila (databas, filsystem, molnlagring)	AES-256-GCM	256-bitars	DES, 3DES, RC4, AES-ECB (inget integritetsskydd)	NIST SP 800-111; FIPS 140-3
PII under överföring (klient-server, tjänst-till-tjänst)	TLS 1.3 (ECDHE-nyckelutbyte, AES-GCM eller ChaCha20-Poly1305)	P-256 eller X25519 för nyckelutbyte	SSL 3.0, TLS 1.0, TLS 1.1; RC4; MD5; SHA-1-certifikathash	NIST SP 800-52 Rev. 2; PCI DSS-krav 4.2.1
PII som kräver sökbarhet (krypterad sökning)	Formatbevarande kryptering (FPE, NIST SP 800-38G) eller deterministisk AES-SIV	256-bitars	Randomiserad kryptering för fält som måste efterfrågas direkt	NIST SP 800-38G
Betalkortsnummer och tokens	Tokenisering (slumpmässig token + säkert valv) föredras; AES-256-kryptering som sekundär kontroll	256-bitars krypteringsnyckel för valv	Lagra råa PAN-adresser i programloggar eller okrypterade fält	PCI DSS-krav 3.3-3.5
Nyckelkryptering (omslag av datakrypteringsnycklar)	AES-256-GCM (Key Encryption Key) eller RSA-3072/ECDSA P-256 för asymmetrisk nyckelomslagning	256-bitars symmetrisk eller 3072-bitars RSA	RSA-1024; lagrar DEK:er tillsammans med krypterad data	NIST SP 800-57 Del 1

Kryptering kontra tokenisering kontra datamaskering

Tre distinkta tekniker skyddar personligt identifierbar information, var och en med olika användningsfall och egenskaper:

• kryptering: omvandlar PII till chiffertext med hjälp av en nyckel. Det ursprungliga värdet kan återställas genom dekryptering. Används när systemet som tar emot eller lagrar informationen legitimt kan behöva komma åt det ursprungliga värdet (till exempel för att visa en kunds adress för en kundtjänstrepresentant eller behandla en betalning för att verifiera ett bankkontonummer).
• tokenization: ersätter PII med en slumpmässigt genererad token utan matematiskt samband med det ursprungliga värdet. Det ursprungliga värdet lagras i ett säkert tokenvalv; endast system med åtkomst till valvet kan hämta det. Används när nedströmssystem behöver referera till data utan att bearbeta det faktiska PII-värdet (till exempel betalkortstokenisering inom detaljhandeln: tokenen färdas genom betalningsbehandlingskedjan medan det faktiska kortnumret finns kvar i valvet).
• Datamaskering: ersätter PII med obfuskerade värden som bevarar formatet men inte är det verkliga värdet och inte kan återställas. Används för icke-produktionsmiljöer (utveckling, testning, analys) där verklig PII skulle vara tillgänglig för utvecklare eller analytiker som inte har ett legitimt behov av de faktiska värdena.

Hotmodell för PII-datakryptering

Hot	Attackscenario	Krypteringskontroll	Varför det minskar påverkan
Databasintrång	Angripare får obehörig läsåtkomst till en produktionsdatabas som innehåller personligt identifierbar information (via SQL-injektion, stulna inloggningsuppgifter eller felkonfigurerade åtkomstkontroller)	AES-256-GCM-kryptering i vila med nycklar lagrade i en separat KMS/HSM	Stulen chiffertext utan krypteringsnyckeln har inget värde för angriparen; PII kan inte läsas eller användas
Nätverksavlyssning (MITM)	Angripare fångar upp personligt identifierbar information under överföring mellan en klient och en server, eller mellan interna tjänster	TLS 1.3 med validering av servercertifikat; mTLS för kommunikation mellan tjänster	Krypterad överföring säkerställer att avlyssnade paket inte kan läsas; certifikatvalidering förhindrar personifiering
Exfiltrering av säkerhetskopior	Angripare får åtkomst till okrypterade säkerhetskopior som lagras på säkerhetskopieringslagring eller media som skickats utanför webbplatsen	AES-256-GCM-kryptering av säkerhetskopior före lagring; krypteringsnycklar lagras inte i säkerhetskopian	Fysisk eller logisk åtkomst till säkerhetskopieringsmedia exponerar inte personligt identifierbar information utan krypteringsnyckeln
Insiderhot	En privilegierad anställd med databasåtkomst exporterar eller exfiltrerar personligt identifierbar information	Kryptering på fältnivå för PII-fält med högst känslighet; åtkomstloggning; åtkomstkontroller som behövs	Kryptering begränsar vad en privilegierad insider kan komma åt; loggning ger kriminaltekniska spår för upptäckt och tillskrivning
Felkonfiguration av molnet	PII som lagras i molnobjektlagring (S3, Azure Blob) görs av misstag offentligt tillgänglig	Kryptering på server- eller klientsidan med kundhanterade nycklar före uppladdning	Offentlig åtkomst till krypterade lagringsobjekt exponerar inte personligt identifierbar information utan krypteringsnyckeln
Viktig kompromiss	Krypteringsnyckeln är stulen eller läckt, vilket möjliggör dekryptering av krypterad personligt identifierbar information	HSM-lagring av krypteringsnycklar; nyckelrotationsschema; åtkomstkontroller som begränsar nyckelanvändning till auktoriserade system	HSM förhindrar nyckelexport; rotation begränsar mängden data som exponeras om en tidigare nyckel komprometteras; åtkomstkontroller begränsar vilka system som kan dekryptera

Bästa praxis för nyckelhantering för PII-kryptering

Den slutliga effektiviteten av PII-kryptering beror inte på algoritmen utan på hur väl krypteringsnycklarna hanteras. En angripare som får tag på krypteringsnyckeln kan dekryptera all PII som är krypterad med den nyckeln, oavsett hur stark algoritmen är. Krav för nyckelhantering för PII-kryptering:

1. Separera krypterad data från krypteringsnycklar: Krypteringsnycklar måste lagras på en separat plats från de data de skyddar. En databas krypterad med nycklar lagrade i samma databas ger minimalt skydd mot databasyntrång. Nycklar bör lagras i ett dedikerat nyckelhanteringssystem (KMS) eller hårdvarusäkerhetsmodul (HSM).
2. Använd HSM-baserad nyckellagring för känsliga personliga identifierbara uppgifter: En FIPS 140-2 nivå 2 eller högre HSM lagrar nycklar i manipulationssäker hårdvara och förhindrar nyckelexport. Alla kryptografiska operationer som använder nyckeln (kryptering, dekryptering) utförs inuti HSM. En angripare som komprometterar applikationsservern kan inte extrahera nyckeln från HSM. Se HSM som en tjänst för hårdvarubaserad nyckelhantering utan lokal HSM-infrastruktur.
3. Implementera nyckelrotation: Datakrypteringsnycklar (DEK) bör roteras enligt ett schema som definieras av datakänsligheten och den krypterade datamängden. NIST SP 800-57 rekommenderar krypteringsperioder på två till tre år för symmetriska innehållskrypteringsnycklar. Rotation kräver att all data krypteras om under den nya nyckeln, vilket är anledningen till att kuvertkryptering (att omsluta en DEK med en Key Encryption Key, eller KEK) används i de flesta produktionsimplementeringar: att rotera KEK är operativt mycket enklare än att kryptera om hela datamängden.
4. Tillämpa åtkomstkontroller vid nyckelanvändning: Åtkomst för att anropa nyckeloperationer (kryptering, dekryptering) bör endast beviljas auktoriserade system och processer genom identitetsbaserade åtkomstkontroller. Alla nyckelanvändningshändelser bör loggas med tidsstämplar, identiteten på det begärande systemet och den nyckelidentifierare som används.
5. Plan för hantering av nyckel efter kvantum: AES-256 är inte sårbar för kvantberäkning (symmetriska algoritmer påverkas inte av Shors algoritm). Däremot är RSA- och ECC-nyckelomslag och nyckelutbytesmekanismer som används i vissa nyckelhanteringssystem kvantsårbara. Organisationer bör bedöma sin nyckelhanteringsinfrastruktur för kvantsårbarhet som en del av PQC-migreringsplanering.

Överensstämmelsekartläggning

reglering	PII-kategori som omfattas	Krypteringskrav	Krav på nyckelhantering
GDPR (artikel 32)	Alla personuppgifter för EU-invånare	Kryptering listad som lämplig teknisk åtgärd; obligatorisk anmälan undantas vid krypteringsintrång	Riskbaserad; ENISA-riktlinjer rekommenderar AES-256 och TLS 1.3
HIPAA säkerhetsregel	Elektronisk skyddad hälsoinformation (ePHI)	Adresserbar specifikation (implementera eller dokumentera varför inte); OCR-tillämpning behandlar konsekvent misslyckande med kryptering som ett brott	Nycklar måste hanteras separat från krypterad ePHI; NIST-vägledningen (NIST SP 800-111) är standardreferensen.
PCI DSS v4.0	Kortinnehavarens uppgifter (PAN, SAD)	Krav 3.5: stark kryptografi för lagrade PAN; Krav 4.2.1: TLS för PAN under överföring	Krav 3.7: dokumenterade nyckelhanteringsrutiner inklusive generering, distribution, lagring, pensionering, rotation och åtkomstkontroll
CCPA	Personuppgifter för kaliforniska konsumenter	Inget krypteringskrav; säker hamn från privat rätt att åtgärda när intrång i data är krypterad	Inga specifika krav på nyckelhantering; bästa praxis för kryptering gäller
NYDFS cybersäkerhetsförordning (23 NYCRR 500)	Icke-offentlig information om kunder inom finansiella tjänster i New York	Kryptering krävs för icke-offentlig information i vila och under överföring	Nyckelhanteringsprogram krävs; nycklarna måste skyddas från obehörig åtkomst

Implementeringsexempel: Kryptering av PII för vårdgivare

En vårdgivare som lagrar patientjournaler inklusive namn, födelsedatum, diagnoskoder och försäkringsinformation implementerar PII-kryptering i sex steg:

1. Dataklassificering och upptäckt: PII-fält i patientjournaldatabasen klassificeras efter känslighet (namn och kontaktinformation som direkt PII; diagnoskoder och försäkringsnummer som känsliga PII/ePHI). En data discovery-skanning identifierar var patientdata också lagras i applikationsloggar, säkerhetskopieringssystem och en rapporteringsdatabas som används av analysteamet.
2. Fältnivåkryptering för ePHI: Diagnoskoder, försäkringsnummer och andra ePHI-fält i produktionsdatabasen krypteras på fältnivå med AES-256-GCM. Krypteringsnycklarna lagras i ett HSM-baserat KMS, inte i databasen eller applikationsservern.
3. Fullständig databaskryptering för säkerhetskopior: Säkerhetskopieringar av databaser krypteras i vila med AES-256-GCM innan de skrivs till säkerhetskopian. Krypteringsnyckeln för säkerhetskopian är separat från krypteringsnycklarna på fältnivå och hanteras via samma KMS med en annan åtkomstpolicy begränsad till säkerhetskopisystemet.
4. TLS 1.3 för all patientkontakt och kommunikation mellan olika tjänster: Patientportalen, mobilapplikationen och alla interna serviceanrop som hanterar patientdata är konfigurerade för att använda TLS 1.3 som lägsta protokollversion. TLS-certifikat hanteras via en livscykelhanteringsprocess för certifikat med automatisk förnyelse.
5. Datamaskering för analysmiljö: Rapporteringsdatabasen som används av analysteamet är ifylld med maskerade kopior av patientdata: verkliga diagnoskoder och inläggningsmönster bevaras för statistisk analys, men namn, födelsedatum och försäkringsnummer ersätts med syntetiska värden. Analytiker kan utföra befolkningshälsoanalyser utan att ha tillgång till verkliga patient-PII.
6. Åtkomstloggning och granskning: All åtkomst till KMS för dekrypteringsåtgärder loggas. Loggarna granskas kvartalsvis för avvikelser (oväntade system som begär dekryptering, åtkomst utanför kontorstid, åtkomst till nycklar för avaktiverade datalager) och sparas under den period som krävs enligt HIPAA (sex år).

Begränsningar för PII-kryptering

• Kryptering skyddar inte personligt identifierbar information vid aktiv användning: När en applikation dekrypterar PII för att bearbeta den (visa den för en användare, inkludera den i ett e-postmeddelande, logga den för felsökning), exponeras klartexten kortvarigt i applikationsminnet och eventuellt i loggar. Applikationsdesignen måste minimera hur länge klartext-PII finns i minnet, förhindra att den visas i loggar och undvika att skicka den till nedströmssystem som inte behöver den.
• Nyckelhantering är den svagaste länken: Säkerheten för krypterad personligt identifierbar information är bara så stark som säkerheten för krypteringsnycklarna. En felaktigt hanterad nyckel (lagrad i en konfigurationsfil bredvid databasen, tillgänglig för alla utvecklare, aldrig roterad) ger minimalt skydd. Majoriteten av PII-krypteringsfel i praktiken är nyckelhanteringsfel snarare än algoritmbrister.
• Krypterad personligt identifierbar information anonymiseras inte: Krypterad personligt identifierbar information förblir personuppgifter enligt GDPR och andra integritetsregler, eftersom den personuppgiftsansvarige innehar nyckeln och kan dekryptera den. Sann anonymisering (så att den registrerade inte kan identifieras på nytt ens av organisationen) tar bort uppgifterna från tillämpningsområdet för de flesta integritetsregler, men är svår att uppnå i praktiken utan att förlora uppgifternas nytta.
• Prestandaöverhead för kryptering på fältnivå med hög volym: Kryptering och dekryptering av enskilda PII-fält i en databas ökar latensen för läs- och skrivoperationer. För applikationer med hög dataflöde minskar hårdvaruaccelererad AES (AES-NI) denna overhead avsevärt, men kryptering på fältnivå kan fortfarande påverka frågeprestanda för storskaliga analytiska frågor på krypterade fält.

Hur krypteringskonsulting kan hjälpa

• Krypteringsrådgivningstjänster: vår Krypteringsrådgivningstjänster bedöma din organisations nuvarande PII-skyddsstatus, identifiera luckor i krypteringstäckningen (okrypterade PII-fält, säkerhetskopior som inte är krypterade i vila, äldre protokoll för data under överföring) och rekommendera en åtgärdsplan som är anpassad till GDPR, HIPAA, PCI DSS och NIST-riktlinjer.
• HSM som en tjänst: HSM som en tjänst tillhandahåller FIPS 140-3-validerad hårdvarubaserad lagring för krypteringsnycklarna som skyddar din PII, vilket säkerställer att nycklar inte kan exporteras från HSM och att alla nyckelåtgärder loggas och är granskningsbara.
• Rådgivningstjänster för efterlevnad: vår Rådgivning om efterlevnad hjälpa organisationer att utforma PII-krypteringsprogram som uppfyller de specifika kraven i deras tillämpliga föreskrifter, inklusive de dokumentations- och revisionsbeviskrav som tillsynsmyndigheter och bedömare kräver.
• CBOM-säker: CBOM-säkerhet upptäcker alla kryptografiska implementeringar i din miljö, inklusive var PII-kryptering tillämpas, vilka algoritmer och nyckelstorlekar som används och var PII-datalager saknar krypteringskontroller, vilket tillhandahåller den inventering som behövs för att täppa till luckor och planera PQC-migrering för nyckelhanteringsinfrastruktur.

Slutsats

Alla företag som hanterar PII ansvarar för att skydda dem från intrång, obehörig åtkomst och bristande efterlevnad av regelverk. Kryptering är den mest direkta tekniska kontrollen: när krypterad PII stjäls har den stulna informationen inget värde för angriparen utan krypteringsnyckeln. De tre riskerna med ett PII-intrång, förlust av konsumentförtroende, direkt ekonomisk påverkan och myndighetspåföljder, minskas alla väsentligt när ett intrång involverar korrekt krypterad data.

Effektiv PII-kryptering kräver korrekt algoritmval (AES-256-GCM för data i vila, TLS 1.3 för data under överföring), rigorös nyckelhantering (HSM-baserad lagring, rotationsscheman, åtkomstkontroller med minsta behörighet), dataupptäckt för att säkerställa täckning i alla miljöer och kompletterande kontroller (tokenisering för betalningsdata, maskering för utvecklingsmiljöer). Det vanligaste felläget är inte en svag algoritm utan svag nyckelhantering: nycklar lagras tillsammans med data, roteras aldrig eller är tillgängliga för system som inte behöver dem. Om din organisation vill bedöma sin PII-krypteringsställning mot myndighetskrav och bästa praxis i branschen, kontakta Encryption Consulting.

Vanliga frågor om partihandel med mat och dryck

Vad är personligt identifierbar information (PII)?

PII är all data som kan identifiera en individ, ensamt eller i kombination med annan information. Direkt PII inkluderar namn, e-postadress, telefonnummer och nationella ID-nummer. Känslig PII inkluderar hälsouppgifter, finansiella kontonummer och biometriska uppgifter. De flesta integritetsregler definierar de PII-kategorier de täcker och inför specifika skyddsskyldigheter för var och en.

Vilken krypteringsalgoritm ska användas för vilande PII-data?

AES-256-GCM är den rekommenderade algoritmen. Den ger 256-bitars säkerhetsstyrka (tillräcklig för data som kräver långsiktigt skydd), autentiserad kryptering (detektering av manipulering) och stöd för hårdvaruacceleration. Den rekommenderas eller krävs enligt NIST-, PCI DSS- och HIPAA-riktlinjer. Det vanligaste felläget är nyckelhantering, inte algoritmsvaghet.

Vad är skillnaden mellan kryptering, tokenisering och datamaskering för PII?

Kryptering omvandlar PII till chiffertext som kan återställas med rätt nyckel. Använd när det ursprungliga värdet kan behövas av auktoriserade system. Tokenisering ersätter PII med en slumpmässig token som lagras i ett säkert valv; använd när nedströmssystem refererar till men inte bearbetar den faktiska PII. Datamaskering ersätter PII med obfuskerade värden som inte kan återställas; använd för icke-produktionsmiljöer där verklig PII inte behövs.

Vilka regler kräver PII-kryptering?

GDPR listar kryptering som en lämplig teknisk åtgärd och undantar individuell anmälan av intrång för krypterad data. HIPAA betecknar kryptering som en adresserbar specifikation (implementera eller dokumentera varför inte); OCR-tillämpning behandlar konsekvent underlåtenhet att kryptera ePHI som ett brott. PCI DSS kräver stark kryptering av lagrade kortinnehavardata och TLS för data under överföring. CCPA erbjuder en säker hamn från privata åtgärder vid krypterade intrång. NYDFS 23 NYCRR 500 föreskriver kryptering i vila och under överföring för icke-offentlig information.

Hur ska krypteringsnycklar för personligt identifierbar information hanteras?

Nycklar måste lagras separat från de data de skyddar, i en FIPS 140-2 nivå 2 eller högre HSM eller dedikerad KMS. Åtkomst bör begränsas till endast auktoriserade system. Nycklar bör roteras enligt ett definierat schema (ett till tre år för DEK:er enligt NIST SP 800-57). All nyckelanvändning bör loggas. Använd kuvertkryptering (omsluta DEK:er med en KEK) för att göra rotation operativt praktisk utan att kryptera om hela datamängder.

Skiljer sig PII som är krypterad i vila från PII som är krypterad under överföring?

Ja. Kryptering i vila skyddar lagrad personligt identifierbar information mot obehörig åtkomst till lagringsmedia. Kryptering under överföring (TLS 1.3) skyddar personligt identifierbar information som flyttas mellan system mot nätverksavlyssning. Båda krävs: kryptering i vila skyddar inte data medan de överförs, och kryptering under överföring skyddar inte lagrad data. Alla större integritetsregler kräver båda.