Natron Tech
Natron ist ein Berner Startup. Wir bauen und betreiben Cloud-Infrastruktur und Kubernetes-Plattformen für andere Firmen, der grösste Teil davon auf eigener Hardware in der Schweiz und nicht bloss auf fremden Hyperscalern.
Wir verantworten den ganzen Stack. Von der Hardware bis zum täglichen Betrieb, inklusive Updates, Monitoring und dem Aufräumen um drei Uhr morgens.
Alles läuft über GitOps, also als Code versioniert und nachvollziehbar statt von Hand zusammengeklickt. So können sich unsere Kunden ganz auf ihr Produkt konzentrieren.
Wer mit uns arbeitet, redet direkt mit den Leuten, die das System gebaut haben.
KONTEXT UND HINTERGRUND
Wir betreiben Infrastruktur für unsere Kundschaft, und ein Teil unseres Jobs ist, sorgfältig mit ihren Daten umzugehen.
Bei manchen Kunden geht das so weit, dass gewisse Daten die Schweiz gar nicht verlassen dürfen, und zwar so, dass ein ausländischer Anbieter sie technisch nie zu Gesicht bekommt. Nicht weil ein Gesetz das pauschal verbietet, sondern weil wir es ihnen so zugesagt haben.
Das wird unangenehm, weil viele gute Tools heute in der Cloud von Drittanbietern laufen, deren Server im Ausland stehen. Für manche gibt es zwar eine Schweizer Region, aber das deckt längst nicht alles ab, und der Anbieter bleibt am Ende ein ausländisches Unternehmen. Für ein verlässliches 'die Daten landen da nie' reicht das nicht.
Und es bleibt nicht bei einem einzelnen Tool. Besonders heikle Daten wie Kontaktinformationen, finanzielle Angaben oder Vertragsnummern können wir nicht in Dokumentationstools wie Confluence ablegen. Dasselbe bei KI-Diensten, denen wir gerne unseren Kontext geben würden, aber ohne die sensiblen Daten.
Überall dieselbe Frage, und überall fehlt uns dasselbe: eine Schicht, die genau diese Daten ersetzt, bevor sie uns verlassen.
BESCHREIBUNG DES PROBLEMS
Baut uns eine Schicht, die bestimmte Daten tokenisiert, bevor sie einen Dienst ausserhalb unserer Kontrolle erreichen, und sie für berechtigte Personen lokal wieder einsetzt. Nach aussen sind nur noch bedeutungslose Tokens sichtbar, für uns sieht alles normal aus, mit den echten Werten. Die Zuordnung von Token zu echtem Wert bleibt bei uns, auf einem Server in der Schweiz.
Das Ganze ist bewusst allgemein gedacht. Wir haben zwar konkrete Lösungen im Kopf, möchten die Challenge aber offen lassen.
Als Gedankenstütze haben wir zwei Beispiele:
Ein Cloud-Tool wie Confluence: Wir schreiben echte Namen, Adressen und Vertragsnummern hinein, beim Anbieter landen nur Tokens, im Browser sehen wir wieder die echten Werte.
Ein KI-Dienst oder MCP-Server: Ein externes Modell arbeitet mit unserem Kontext, sieht statt der echten Personendaten aber nur Tokens, und die Antwort wird bei uns wieder aufgelöst.
Wichtig ist in beiden Fällen der Zeitpunkt. Es reicht nicht, die Daten erst beim Anzeigen oder beim Empfang der Antwort wieder einzusetzen. Sie müssen ersetzt werden, bevor sie unsere Grenze überschreiten. Wenn die echten Daten weiterhin beim fremden Dienst liegen und nur lokal versteckt werden, ist die Aufgabe nicht gelöst.
Wenn das mal steht, kommen die spannenden Fragen: Wie sucht man, wenn überall nur noch Tokens stehen? Wie bleibt dieselbe Angabe über viele Dokumente oder Anfragen hinweg konsistent maskiert, damit Zusammenhänge erhalten bleiben? Was ist mit Anhängen, Kommentaren, Benachrichtigungen? Was mit Feldern, die der Dienst für sich selbst braucht, etwa die Login-Mail, die man nicht einfach durch einen Token ersetzen kann? Und wer darf überhaupt re-identifizieren?
Wie ihr das baut, ist euch überlassen. Wir haben ein paar Ideen, aber wir sind gespannt auf eure.