Bescherming onder druk

Waarom we dit deden

Elke AI-koppeling is een nieuwe uitgang voor je data. Een factuursamenvatting, een supportantwoord of een CRM-export kan namen, IBAN’s en telefoonnummers meenemen naar een model dat het bedrijf niet zelf draait. Penweir zit in dat pad en houdt die waarden tegen.

Voor een gateway tellen drie eigenschappen, in deze volgorde. Hij mag nooit een beschermde waarde doorlaten. Hij mag niet elk request merkbaar trager maken. En hij moet blijven werken als de providers erachter dat niet doen.

Een functionele test laat zien dat een filter op één request werkt. Hij laat niet zien wat er gebeurt met honderden gelijktijdige clients, gesprekken van twintig beurten, toolresultaten vol klantvelden en providers die time-outen. Daar zitten de sluiproutes: een detector die onder load wordt overgeslagen, een token dat in het verkeerde antwoord wordt hersteld, een fallback die het ongefilterde origineel opnieuw verstuurt. Dus duwden we Penweir expres tot het brak en keken we wat het eerst begaf.

Wat we deden

We stuurden circa 123.600 requests door tien geïsoleerde Penweir-instanties. De workloads groeiden van een pipeline van drie stappen tot zestien pipelines van 30–40 stappen met berichten van 64 KB, waarvan 30% tot 70% gestreamd. Vanaf het tweede niveau gaven de gesimuleerde providers serverfouten, rate limits, time-outs, onleesbare antwoorden en kaartnummers in antwoorden terug.

Aan de kant van de provider zat een orakel. Het legde elke ruwe gevoelige waarde vast die het ontving, ook bij fallback-pogingen naar een tweede, derde of vierde provider. Een load generator controleerde elk antwoord: was elke getokeniseerde waarde exact hersteld, en was elke gemaskeerde, geredigeerde of gehashte waarde afwezig?

Er is geen echt taalmodel en geen echte persoonsdata gebruikt. De testwaarden waren synthetisch, maar geldig waar een checksum bestaat.

Wat we vonden

Het geheugen bleef bij elke belasting tussen 116 en 206 MB, zonder groei tijdens een run.

Wat dit niet bewijst

Dit was één gedeelde laptop, dus de absolute doorvoer is pessimistisch. De providers waren gesimuleerd, met gelijkmatige latency en onafhankelijke fouten, terwijl echte providers in pieken uitvallen. Het orakel controleert letterlijke waarden en zou een waarde die door een gedeeltelijke transformatie is beschadigd niet vangen. We maten niet hoe goed detectors identifiers in realistische vrije tekst vinden en we testten de Postgres-backend niet. Elk niveau is één keer gedraaid, dus er zijn geen betrouwbaarheidsintervallen.

Penweir detecteert gestructureerde identifiers. Het garandeert niet dat namen in vrije tekst worden gevonden. De volledige lijst met beperkingen staat in hoofdstuk 9 van het rapport.

Wat we verbeteren

De test liet ook zien waar één proces ruimte tekortkomt. Vanaf ongeveer 250 tot 500 gelijktijdige clients gingen requests met interne fouten falen, door een cache-stampede bij het opzoeken van de sleutel. Daarboven bleven sommige requests zonder auditgebeurtenis. Dit raakt de juistheid van de bescherming niet, maar voor een product waarvan het auditlog een compliancefunctie is, komt dit eerst.

1. Een stampede-vrije sleutelcache en een expliciet dimensioneerde connectiepool.
2. Een auditgebeurtenis voor elk request met een geldige sleutel, ook bij interne fouten.
3. Snelle weigering met 503 en Retry-After, in plaats van wachtrijen tot 30 seconden.
4. Meerdere workerprocessen per instantie.

De harness, de rapporten per niveau en de ruwe metrics bevatten geen request- of antwoordtekst, alleen tellingen, tijden en statuscodes.