Client-side-encryptie versus server-side-encryptie voor uploads

Waarom encryptiekeuzes belangrijk zijn voor geüploade documenten

Als je app mensen bestanden laat uploaden, sla je niet zomaar “documenten” op. Vaak bewaar je een tweede identiteit van de gebruiker: ondertekende contracten, paspoort- of rijbewijsfoto’s, medische formulieren en laboratoriumresultaten. De bestanden zijn klein. Het risico dat eraan verbonden is, is dat niet.

Een gelekt contract kan juridische en financiële gevolgen hebben: prijzen worden openbaar, handtekeningen worden gekopieerd en geschillen escaleren snel. Een gestolen ID-scan kan leiden tot identiteitsfraude en overname van accounts. Medische documenten kunnen privégezondheidsgegevens blootleggen die mensen nooit hadden verwacht te delen buiten een kleine kring. Eén fout kan jarenlange schade aan vertrouwen veroorzaken.

Teams zeggen vaak “versleutelde opslag” terwijl ze verschillende dingen bedoelen. Soms bedoelen ze dat de uploadverbinding versleuteld is (HTTPS). Soms bedoelen ze dat het bestand op schijf versleuteld is (encryptie at rest). Soms bedoelen ze dat het bestand versleuteld is voordat het het apparaat van de gebruiker verlaat, zodat de server nooit plaintext ziet (client-side encryptie). Dit is niet hetzelfde. Ze beschermen tegen verschillende fouten.

Beveiligingskeuzes bepalen ook het dagelijkse gebruik en de ondersteuning. Meer privacy kan meer frictie betekenen: extra stappen om een bestand te bekijken, moeilijker delen, beperkte zoek- en preview-mogelijkheden en pijnlijke herstelprocedures bij verlies van een apparaat of sleutel. Gemakkelijkere toegang maakt indexering, antiviruscontrole, previews en wachtwoordresets mogelijk, maar vergroot ook wat je server (en iedereen die die server compromitteert) kan zien.

Stel je een kleine kliniek voor die verzekerings-ID’s en medische PDF’s uploadt. Het personeel moet snel het juiste bestand vinden, maar de kliniek wil ook de schade beperken als een admin-account wordt gehackt. Het “juiste” model hangt af van welke fout het meeste kwaad kan doen en welke onhandigheid gebruikers zullen accepteren.

Korte definities: client-side vs server-side encryptie

De praktische vraag is eenvoudig: wanneer is het bestand versleuteld en wie kan het later ontsleutelen?

Server-side encryptie betekent dat het bestand in leesbare vorm je backend bereikt en je server het versleutelt voordat het wordt opgeslagen. Dit is encryptie at rest: als iemand een schijf steelt of rauwe toegang krijgt tot een storage-bucket, zien ze onleesbare data. Je server kan het bestand desgewenst nog ontsleutelen.

Client-side encryptie betekent dat het bestand op het apparaat van de gebruiker (browser of mobiel) wordt versleuteld vóór upload. Je server slaat alleen ciphertext op. In normale werking kan de server het document niet lezen tenzij hij ook toegang heeft tot de ontsleutelingssleutel.

Sleutelbeheer is de echte scheidslijn:

• Bij server-side encryptie worden sleutels beheerd door je backend (vaak via een key management service) en de backend ontsleutelt bestanden voor gemachtigde gebruikers.
• Bij client-side encryptie worden sleutels gecontroleerd door de gebruiker, hun apparaat of een clientgeheime waarde, en handhaaft de backend vooral opslag- en toegangsregels.

In beide modellen heb je nog steeds authenticatie en permissies nodig. Encryptie vervangt geen toegangscontrole.

Mensen gebruiken ook “end-to-end encryptie” om aan te geven: het bestand is versleuteld op het apparaat van de verzender, blijft versleuteld op de server en wordt alleen ontsleuteld op het apparaat van een goedgekeurde ontvanger. Dat kan de vertrouwelijkheid verbeteren, maar het maakt server-side preview, full-text search, virusscanning en gemakkelijk herstel veel lastiger tenzij je bereid bent het dreigingsmodel aan te passen.

Dreigingsmodellen: tegen wat probeer je je eigenlijk te beschermen

Encryptie helpt alleen als je duidelijk hebt welke risico’s je wilt verminderen. “Niemand behalve de bedoelde gebruiker kan het bestand lezen” leidt tot andere keuzes dan “verminder de schade als opslag gelekt wordt.”

Veelvoorkomende bedreigingen voor apps die contracten, ID’s of medische documenten opslaan omvatten:

• Gestolen of hergebruikte wachtwoorden (accountovername)
• Insider-toegang die ruimer is dan zou moeten (support, admins, aannemers)
• Een gecompromitteerd cloudaccount of verkeerd geconfigureerde storage-bucket
• Een bug of lek dat databases of back-ups blootlegt
• Malware op het apparaat van een gebruiker

Het helpt ook om te scheiden waar blootstelling kan gebeuren:

• Tijdens transport: het bestand dat van apparaat naar server beweegt
• In rust: objectstorage, datarijen, back-ups, logs
• Tijdens bekijken/verwerken: previews, OCR, zoekindexen, conversies

Hier is het kernverschil. Met server-side encryptie kan je systeem ontsleutelen, dus het kan previews maken, scannen en indexeren. Met client-side encryptie slaat de server ciphertext op en kan de inhoud niet lezen zonder dat gebruikerssleutels worden verstrekt. Dat verkleint doorgaans de impact van servercompromis en insider-toegang.

Encryptie voorkomt niet alles. Als een apparaat geïnfecteerd is, kan malware het bestand grijpen vóór encryptie of na ontsleuteling. Als iemand een document kan bekijken, kan diegene het nog steeds screenshotten, opnieuw delen of afdrukken.

Wat elk model beschermt (en wat niet)

Een nuttige vergelijkingsvraag is: wie kan het bestand op enig moment in plaintext zien? Dat bepaalt de impact van een inbreuk, insider-risk en de veiligheid van back-ups.

Bij server-side encryptie kan een serverinbreuk nog steeds veel blootleggen. De backend heeft doorgaans toegang tot ontsleutelingssleutels (of kan ze opvragen) omdat hij previews moet genereren, antiviruscontroles moet uitvoeren, zoekfuncties moet ondersteunen of delen moet afhandelen. In het ergste geval kan een aanvaller die zowel opgeslagen data als sleuteltoegang heeft alles ontsleutelen.

Bij client-side encryptie steelt een aanvaller die je infrastructuur binnendringt meestal alleen versleutelde blobs. Zonder door de gebruiker beheerde sleutels zijn die blobs veel minder nuttig.

Insider-toegang is waar het verschil het duidelijkst wordt. Met server-side encryptie kan een geprivilegieerde medewerker, cloud-admin of gecompromitteerd supportaccount vaak documenten bekijken door de app na te bootsen of storage te bevragen. Met client-side encryptie kan je infrastructuur bestanden verplaatsen en opslaan, maar niet lezen tenzij sleutels worden verstrekt.

Client-side encryptie lost geen gehackt apparaat op. Voor uploads met hoog risico zoals ID’s en medische PDF’s zijn apparatuursecuriteit en accountbescherming net zo belangrijk als opslagencryptie.

Let ook op lekken buiten de “bestandopslag.” Veel incidenten gebeuren via:

• Back-ups en snapshots die ontsleutelde bestanden of sleutels bevatten
• Logs die bestandsnamen, metadata of geëxtraheerde tekst vastleggen
• Miniaturen, previews en zoekindexen
• Exports naar e-mail, chat of ticketingtools
• Tijdelijke bestanden die tijdens upload of conversie worden aangemaakt

UX-afwegingen die gebruikers meteen merken

Het grootste verschil is niet de wiskunde. Het is wat gebruikers gemakkelijk kunnen doen en wat moeilijk wordt.

Server-side encryptie voelt vaak onzichtbaar. Gebruikers loggen in, uploaden en zien direct een preview. Support kan toegang resetten. Begeleiders kunnen meestal rechten herverdelen als iemand ziek is.

Client-side encryptie verandert onboarding en dagelijks werk. Gebruikers hebben mogelijk een sterkere wachtwoordzin, een lokale sleutel op het apparaat of een extra ontgrendelstap nodig. Apparaten wisselen, de browser wissen of de app opnieuw installeren kan toegang breken tenzij je een plan voor sleutelbackup en herstel hebt.

Accountherstel is waar teams verrast raken. Als alleen de gebruiker de ontsleutelsleutel bezit, kan “wachtwoord vergeten” veranderen in “toegang kwijt.” Je kunt een herstel- of escrowflow toevoegen, maar je moet eerlijk zijn over wat dat betekent en het duidelijk uitleggen.

Delen wordt ook ingewikkelder. Bij server-side encryptie gaat delen meestal via permissies. Bij client-side encryptie gaat delen vaak gepaard met sleuteluitwisseling en vragen zoals intrekking en wat er met oude kopieën gebeurt.

Zoek- en gebruiksgemakfuncties kunnen ergens ontsleuteling vereisen. Full-text search, previews en OCR zijn het gemakkelijkst wanneer de server het bestand kan lezen. Als je end-to-end privacy wilt, heb je client-side OCR, lokale indexering of beperkte zoekmogelijkheden nodig (bijv. alleen bestandsnamen en tags).

Voorbeeld: een kliniek uploadt lab-PDF’s en wil OCR om patiëntnamen in scans te vinden. Server-side encryptie ondersteunt snelle OCR en zoeken. Client-side encryptie legt dat werk bij gebruikersapparaten, wat trager kan zijn en lastiger om web en mobiel uniform te ondersteunen.

Document-specifieke behoeften: contracten, ID’s en medische dossiers

De beste keuze hangt minder af van het bestandstype en meer van de workflow: wie het moet lezen, hoe snel, hoe vaak en hoe lang.

Contracten

Contracten omvatten vaak review, redlining, goedkeuringen en audit-trails. Teams willen ook betrouwbare zoekfuncties, delen en bewaarbeleid.

Als je app collaboratieve review binnen het product ondersteunt, is server-side encryptie vaak de praktische standaard omdat het systeem previews kan renderen, zoeken kan uitvoeren en rolgebaseerde toegang kan afdwingen zonder dat gebruikers sleutels moeten beheren.

Client-side encryptie kan passen als de app vooral een kluis is, bijvoorbeeld voor definitieve ondertekende PDFs voor een klein directieteam. De afweging is dat ingebouwde gebruiksgemak verminderd wordt tenzij je client-side tooling toevoegt.

ID’s (paspoort, rijbewijs)

ID’s zijn hoog risico maar vaak van korte duur. Veel teams hebben ze alleen nodig om iemand te verifiëren en verwijderen ze daarna. De workflow is snel bekijken en strikte omgangsregels, niet samenwerken.

Een gebruikelijke aanpak is server-side encryptie gecombineerd met strikte toegangscontrole, sterke auditlogs en korte retentie. Client-side encryptie past als supportmedewerkers echt nooit ID’s mogen bekijken, maar dan heb je een andere manier nodig om verificatie te voltooien.

Medische documenten

Medische dossiers hebben sterkere privacyverwachtingen. Gebruikers gaan ervan uit dat alleen de minimaal noodzakelijke personen ze kunnen zien.

Client-side encryptie kan blootstelling verkleinen bij een serverinbreuk of misbruik van admin-toegang. Maar het kan ook echte UX- en operationele problemen veroorzaken: wachtwoordresets, apparaatwissels en noodtoegang worden dan ingewikkeld.

Voordat je kiest, koppel elk documenttype aan de workflow:

• Wie moet het lezen (en vanaf waar)
• Hoe snel moet het laden
• Hoe lang bewaar je het
• Welke productfeatures zijn belangrijk (preview, zoeken, automatische verwijdering)

Hoe kiezen: een stapsgewijs besluitvormingsproces

Begin met het opschrijven van wat je opslaat en wie erbij betrokken is. Een map “uploads” is geen beleid.

Stap 1: breng toegang in kaart, niet alleen “gebruikers”

Maak een lijst van rollen en beantwoord twee vragen: wie moet het bestand kunnen openen en wie mag het nooit openen (inclusief admins)? Neem ook retentie mee.

Stap 2: kies je dreigingsaanname

Wees eerlijk over wat je verdedigt.

• Als insider-risk topprioriteit heeft, wordt client-side encryptie aantrekkelijker.
• Als apparaatverlies en wachtwoordresets vaak voorkomen, betaal je daarvoor in herstelcomplexiteit.

Test dan de ervaring:

1. Herstel en support: Wat gebeurt er als iemand een wachtwoord vergeet of een telefoon verliest? Als je toegang moet herstellen, past pure client-side encryptie misschien niet.

2. Must-have features: Heb je previews, zoeken, OCR, e-signing of API-gebaseerde verwerking nodig? Veel van deze functies zijn eenvoudiger als de server ergens kan ontsleutelen.

3. Audit en compliance: Heb je duidelijke logs nodig van wie wat wanneer heeft bekeken? Beide modellen kunnen loggen, maar client-side ontwerpen vragen extra zorg om te voorkomen dat je eindigt met “we kunnen je niet helpen.”

De meeste teams kiezen een hybride aanpak: server-side encryptie voor de meeste documenten en client-side encryptie voor een klein aantal uploads die “nooit door personeel gelezen mogen worden.”

Veelgemaakte fouten en valkuilen om te vermijden

De grootste valkuil is encryptie als het hele verhaal behandelen. Privacy en compliance hangen ook af van wie toegang heeft, hoe toegang wordt goedgekeurd, wat er wordt gelogd, hoelang bestanden worden bewaard en hoe verwijderverzoeken worden afgehandeld.

Een tweede grote fout is client-side encryptie bouwen zonder herstelplan. Als een gebruiker een apparaat verliest, een wachtwoordzin vergeet of het bedrijf verlaat, kun je dan de toegang herstellen zonder je veiligheidsbelofte te breken? “We kunnen je niet helpen” is acceptabel voor een persoonlijke kluis, maar faalt meestal in zakelijke apps.

Deze fouten leiden tot echte lekken en workaround-gedrag:

• Admins een verborgen “bekijk alles”-pad geven of support gebruikers laten imiteren zonder strikte logs en tweepersoonsgoedkeuring.
• Ontsleutelen in de browser of app en kopieën achterlaten (gecached previews, tijdelijke downloads, gesynchroniseerde mappen).
• “Veilige” documenten later via onveilige kanalen sturen (pdf’s e-mailen, screenshots in chat plakken, bestanden aan tickets hangen).
• De beveiligde workflow zo onhandig maken dat gebruikers naar persoonlijke schijven migreren of foto’s van het scherm nemen.
• Aannemen dat “encrypted at rest” automatisch voldoet aan toestemmings-, toegangsgeschiedenis-, retentie- en meldplichtvereisten.

Voorbeeld: een kliniek versleutelt intakeformulieren, waarna personeel een factureringsrapport exporteert dat een lokale onbeveiligde map aanmaakt. Die map wordt geback-upt naar een gedeelde drive. Het lek gebeurt in de workflow, niet in de crypto.

Snelle checklist voordat je besluit

Schrijf één eenvoudige zin: wie zou deze bestanden mogen lezen en wie zou het nooit mogen lezen, zelfs als iemand toegang krijgt tot je servers.

Controleer daarna:

• Wie kan ontsleutelen en wanneer? Noem rollen en condities exact. Als je beleid zegt “alleen de uploader,” voeg dan niet stiekem een achterdeur toe via gedeelde sleutels.
• Kun je toegang snel intrekken? Offboarding is de ware test. Bepaal of toegang aan een account, apparaat of groep is gekoppeld.
• Wat gebeurt er na apparaatverlies of wachtwoordresets? Als je herstel nodig hebt, bescherm het met strikte goedkeuringen.
• Heb je previews, virus-scanning of OCR nodig? Zo ja, plan waar ontsleuteling gebeurt en wie die kan starten.
• Zijn je auditlogs specifiek genoeg? Definieer wat telt als “bekeken” versus “gedownload” en leg gebruiker, tijd, apparaat en reden vast.

Voorbeeldscenario: een klein team dat ID’s en medische PDFs opslaat

Een kleine kliniek heeft een app waar personeel verwijzingen (PDF’s) en foto’s van verzekerings-ID’s uploadt. Het doel is documenten snel naar de juiste mensen te krijgen en tegelijk de schade te verkleinen van verloren apparaten, gecompromitteerde accounts of cloudfouten.

Eén werkbare aanpak is server-side encryptie met strikte rollen. Bestanden zijn versleuteld in rust en toegang wordt gecontroleerd door permissies: de balie kan uploaden, de administratie kan ID’s bekijken en clinici kunnen verwijzingen zien. Dit is vaak makkelijker in het dagelijks gebruik omdat personeel documenten op desktop of mobiel kan openen zonder extra stappen en supervisors tijdens afwezigheid toegang kunnen herverdelen.

Een andere aanpak gebruikt client-side encryptie voor de meest gevoelige items. Het bestand wordt op het apparaat versleuteld vóór upload, zodat de server alleen ciphertext opslaat. Dit kan de impact van serverlekken en insider-toegang verkleinen, maar verandert de operatie:

• Wachtwoordresets kunnen normaal toegang herstellen met server-side encryptie; met client-side encryptie kunnen resets gebruikers uitsluiten tenzij sleutels veilig zijn geback-upt.
• Personeelswisselingen zijn eenvoudiger met server-side encryptie; met client-side encryptie moet je een manier hebben om sleutels over te dragen of te escroquer zodat documenten toegankelijk blijven.

Gebruikers ervaren wrijving bij delen, mobiel gebruik en herstel na een verloren telefoon. Die details wegen even zwaar als het encryptiemodel zelf.

Volgende stappen: beslis, documenteer beleid en implementeer

Begin met je dreigingsaanname in klare taal op te schrijven. Kies de eenvoudigste aanpak die aan je risico voldoet en verscherp die alleen waar documenten het echt rechtvaardigen.

Leg de beslissing vast in een korte interne regels:

• Welke bestandstypen zijn toegestaan en waar ze mogen worden opgeslagen
• Wie ze mag openen en delen, en hoe toegang wordt goedgekeurd
• Bewaar- en verwijderregels
• Hoe herstel werkt na wachtwoordresets en apparaatverlies
• Hoe exports (downloads, e-mail, messaging) worden afgehandeld en wanneer ze worden geblokkeerd

Ontwerp de implementatie rond die regels: rolcontroles, gelogde acties (bekijken, downloaden, delen), veilige previews en zorgvuldig sleutelbeheer.

Als je bouwt op een no-code platform zoals AppMaster (appmaster.io), helpt het om rollen en goedkeuringsstromen vroeg te modelleren en vervolgens aan te passen als requirements veranderen zonder de hele app te herschrijven. Het belangrijkste is dat de veilige route de gemakkelijke route wordt voor echte gebruikers.