Vor etwa zwei Jahren sitze ich bei einem Maschinenbauer, 180 Mitarbeitende, irgendwo zwischen Augsburg und Ingolstadt. Der CTO — eigentlich der einzige echte .NET-Entwickler im Haus — zeigt mir stolz seine Lösung: Kundendaten werden beim Schreiben in die Datenbank verschlüsselt, beim Lesen entschlüsselt, alles transparent, alles sauber. Der Key liegt in einer appsettings.json, committed ins Git-Repository, wo er seit 2019 schlummert. Inclusive Produktions-Key. Inclusive dem Key für die Testdatenbank, die dieselben echten Kundendaten enthält wie Produktion, weil "das einfacher war".
Das ist kein Einzelfall. Das ist der Mittelstands-Standard.
Was Steve Gordon baut — und er baut es wirklich gut
Steve Gordon zeigt in seinem Artikel, wie man mit dem IJsonTypeInfoResolver und einem Contract-Modifier einzelne Properties einer Klasse beim Serialisieren automatisch verschlüsselt und beim Deserialisieren entschlüsselt. Der Mechanismus ist eleganter als ein Custom JsonConverter: Man markiert Properties mit einem [EncryptedData]-Attribut, und der Resolver kümmert sich transparent um die Konvertierung. Teil 1 baut nur das Grundgerüst, die echte Verschlüsselung und Azure Key Vault kommen in Folgebeiträgen. Der Anwendungsfall ist konkret: OAuth-Tokens sicher in Elasticsearch ablegen, ohne die Serialisierungs-Pipeline zu verändern.
Technisch ist das sauber. Der Contract-Modifier-Ansatz ist seit .NET 7 der richtige Weg — performant, cachefähig, testbar. Wer in einer .NET-Umgebung PII oder Tokens in einem Document Store ablegt, sollte sich das genau anschauen.
Wie das im KMU wirklich landet
Lass mich direkt sein: Der Artikel richtet sich an .NET-Entwickler in Umgebungen, wo jemand weiß, was Azure Key Vault ist, warum man ihn braucht, und wer die Kosten trägt. Das sind vielleicht 20 % meiner Mandate.
Der typische .NET-Mittelstandskontext sieht anders aus:
Wer schreibt den Code, der das eines Tages warten muss? In einem Unternehmen mit 30 bis 300 Mitarbeitenden gibt es oft einen oder zwei .NET-Entwickler. Wenn der eine in Elternzeit geht und der andere kündigt, sitzt die nächste Person — vielleicht ein Junior, vielleicht ein externer Dienstleister — vor einem TypeInfoResolver Modifier und googelt erstmal zwanzig Minuten, was das überhaupt ist. Ein Custom JsonConverter wäre dümmer und langsamer, aber in drei Jahren noch verständlich.
Das ist kein Argument gegen Gordons Ansatz. Das ist ein Argument dafür, ihn nur einzusetzen, wenn das Team die Abstraktion trägt.
Die echte Schwachstelle ist nie der Serialisierungs-Code. In allen Mandaten, wo ich Verschlüsselung auf Property-Ebene gesehen habe, war der Code-Teil das geringste Problem. Das Problem war immer: Wo liegt der Key, wer hat Zugriff, wie rotiert man ihn, und was passiert beim nächsten Deployment? Gordon kündigt Azure Key Vault für Folgebeiträge an — das ist richtig und notwendig. Aber für ein KMU ohne Azure-Erfahrung und ohne dediziertes Ops-Team ist Key Vault kein Nachmittagsprojekt. Das sind zwei bis drei Tage Einarbeitung, laufende Kosten, und jemand muss verstehen, was ein Managed Identity ist.
Das Crypto-Shredding-Argument ist im KMU meist akademisch. Gordon nennt Event Sourcing und DSGVO-konformes "Vergessen" durch Key-Deletion als Szenario. Das ist konzeptionell brilliant. Aber ich habe in vier Jahren Mittelstandsberatung exakt null Unternehmen unter 500 Mitarbeitenden gesehen, die Event Sourcing produktiv betreiben und gleichzeitig Crypto Shredding brauchen. Wenn du DSGVO-konformes Löschen implementieren willst, lösch die Daten. Das ist weniger elegant, aber für dein Rechtsteam nachvollziehbar und für deinen Anwalt erklärbar.
Was sich wirklich lohnt — und was nicht
Hier ist meine Einschätzung für drei typische Mittelstands-Szenarien:
Szenario 1: Startup oder wachsendes Tech-Unternehmen, 30–80 Mitarbeitende, eigenes Dev-Team mit .NET-Erfahrung. Gordons Ansatz ist hier der richtige. Sauber implementieren, Azure Key Vault von Anfang an einplanen, den Contract-Modifier-Ansatz dokumentieren. Investition: drei bis fünf Tage für eine solide Erstimplementierung inklusive Key-Management. Return: ihr spart euch später den schmerzhaften Refactor, wenn der nächste Compliance-Audit kommt.
Szenario 2: Klassischer Mittelständler, 100–300 Mitarbeitende, ein bis zwei .NET-Entwickler, keine Cloud-Strategie.
Hier würde ich zunächst eine einfachere Lösung empfehlen: Verschlüsselung auf Datenbankebene (Transparent Data Encryption in SQL Server ist ein Klick und kostet nichts extra) oder Application-Level-Verschlüsselung mit einer zentralen EncryptionService-Klasse, die einen Key aus einem simplen Secret Store wie dem Windows Certificate Store oder einem KeePass-kompatiblen Secret-Manager zieht. Gordons Attribut-Mechanismus kannst du später darüberlegen, wenn das Team gewachsen ist.
Szenario 3: Kein eigenes Dev-Team, Lösung wurde von einem Dienstleister gebaut. Finger weg von Property-Level-Encryption im Code, solange du keinen Dienstleister hast, der das langfristig supportet. Die Datenbank-Level-Verschlüsselung ist dein Freund. Sie ist transparent, braucht keinen Applikations-Code, und dein nächster Dienstleister muss nichts Besonderes wissen.
Eine konkrete Zahl, damit das nicht abstrakt bleibt
Ich habe letztes Jahr bei einem Mandanten — Software-Verleih, 60 Mitarbeitende — einen Verschlüsselungs-Refactor begleitet. Ausgangszustand: AES-verschlüsselte Properties, Custom Converter, Key in der Datenbank (ja, wirklich). Zielzustand: Gordons Ansatz mit Key Vault. Dauer bis Production-Ready inklusive Key-Migration, Testing und Deployment-Pipeline: acht Wochen, zwei Entwickler, plus meine Begleitung. Kosten außen vor.
Das ist kein Argument dagegen — die Lösung ist jetzt deutlich besser. Aber es ist ein Argument dafür, vorher zu kalkulieren, ob das euer nächstes Projekt sein soll oder ob es einen kürzeren Weg gibt, der 80 % der Sicherheit für 20 % des Aufwands bringt.
Fazit
Steve Gordons Artikel ist technisch ausgezeichnet. Der TypeInfoResolver Modifier-Ansatz ist die richtige Antwort auf "wie verschlüssle ich Properties in .NET sauber und wartbar". Ich empfehle dir, ihn zu lesen — auch wenn du ihn im Moment nicht direkt umsetzt.
Was der Artikel naturgemäß nicht liefert: die organisatorische Realität des Mittelstands. Wer schreibt das, wer wartet das, wer verwaltet den Key nach dem nächsten Mitarbeiterwechsel? Das sind die Fragen, die über Erfolg oder Fail dieser Implementierung entscheiden — nicht die Code-Qualität.
Property-Level-Encryption ist das richtige Werkzeug für bestimmte Probleme. Stell sicher, dass du das richtige Problem hast, bevor du anfängst.
Der vollständige Original-Beitrag von Steve Gordon: Encrypting Properties with System.Text.Json and a TypeInfoResolver Modifier (Part 1)
Wenn du gerade vor der Entscheidung stehst, wie ihr sensitive Daten in eurer .NET-Anwendung absichert, und nicht in drei Monaten feststellen willst, dass ihr die falsche Ebene gewählt habt: → 30 Min Klartext-Sparring
— Bernhard