Sikkerhed

De fleste tjenester lægger alle kunders oplysninger i én stor liste og kender dem fra hinanden på et mærkat på hver post. Det virker, lige indtil én forespørgsel glemmer at se efter mærkatet. MemoryAgent giver hvert arbejdsområde sit eget område i stedet: en adskillelse, du kan pege på, frem for en adskillelse, der kun holder, så længe hver eneste forespørgsel husker et filter.

Der ligger intet i det almindelige område, en forvildet forespørgsel ville lande i, og vores egne platformsregistreringer ligger et helt tredje sted. En forespørgsel, der på en eller anden måde er faret vild, finder ingenting overhovedet frem for stille og roligt at nå rigtige data, der tilhører en anden.

Et arbejdsområde er én grænse, og du bestemmer, hvad den betyder: ét pr. kunde, ét pr. miljø eller ét pr. projekt. At krydse fra det ene til det andet er ikke en tilladelse, vi holder tilbage — der findes ingen forespørgsel, der spænder over to af dem.

En API-nøgle slår på vores servere op i en konto, et arbejdsområde, en rolle og de handlinger, den må udføre. Klienten sender intet af det. En forespørgsel kan indsnævre sig selv til én app eller ét projekt, og intet, en klient kan sende, udvider det.

• Master-nøgler når hvert arbejdsområde inden for deres egen konto og intet derudover. De er til administration.
• Arbejdsområde-nøgler når præcis ét arbejdsområde og bør bære den almindelige trafik.
• Rollenøgler når ét arbejdsområde med én rolle — en læser kan læse, en skriver kan læse og skrive.

Der findes ingen legitimation, der spænder over konti, og ingen rolle, der står over dem. Det betyder også, at vi ikke har nogen måde at handle som dig på, hvilket er bevidst og ikke en forglemmelse.

Forbindelser til databasen deles og gives videre fra det ene stykke arbejde til det næste. Hvert stykke arbejde nævner det ene område, det må røre ved, og den tilladelse udløber i samme øjeblik, arbejdet er færdigt — så den kan ikke rejse videre med forbindelsen til den, der får den næste gang.

Navnene på de områder kommer fra vores eget register over arbejdsområder. Ikke ét af dem bygges nogensinde af noget, en forespørgsel indeholdt.

De tests, der beviser det, kører ved hver eneste ændring mod en rigtig delt pulje af forbindelser, bevidst holdt lille, så forbindelser genbruges hele tiden. En test mod en privat forbindelse kunne aldrig fremkalde den fejl, den findes for at fange, så det ville intet bevise at bestå den.

• API-nøgler gemmes som uigenkendelige aftryk. En nøgle vises én gang, i det øjeblik den oprettes, og kan ikke hentes frem bagefter. At udskifte en udsteder en ny og pensionerer den gamle.
• Den nøgle til en modeludbyder, du eventuelt gemmer hos os, opbevares med AES-256-GCM-kryptering og dekrypteres kun for at hente fakta ud af dit eget arbejdsområdes samtaler. En kopi af vores database alene giver ikke en brugbar nøgle.
• Adgangskoder omregnes af autentificeringsbiblioteket til et uigenkendeligt aftryk. Vi har aldrig en i en form, vi kunne læse.
• En nøgle står aldrig i en webadresse, skrives aldrig i en log og sendes aldrig til et analyse- eller session replay-værktøj. Den vises heller aldrig igen, efter den er oprettet — en liste over nøgler returnerer de første par tegn og en label.

Alt, der krydser netværket, gør det over TLS. I hvile ligger data på lagring leveret af Railway; den udbyderlegitimation, vi opbevarer for dig, krypteres oven i det af os, så de to ikke fejler samtidig.

To uafhængige mekanismer, fordi de fejler forskelligt. Kopier af hele disken er hurtige og komplette: daglige gemmes i 6 dage, ugentlige i 27 dage, månedlige i 89 dage. En natlig flytbar kopi gemmes i 30 dage.

Den flytbare kopi er den, der bliver efterprøvet. Den kontrolleres mod sin offentliggjorte kontrolsum, genskabes i en midlertidig database og bliver derefter forespurgt — for en backup, der lader sig genskabe, men ikke kan besvare en søgning, er ikke genskabt. En kopi, der kommer uden sin kontrolsum, dumper øvelsen frem for at springe kontrollen over.

En backup, ingen har genskabt, er en formodning, så øvelsen kører mod rigtige kopier frem for mod en beskrivelse af en.

At slette et arbejdsområde fjerner alt i det, helt og holdent. Det kan ikke fortrydes, og det opgiver enhver senere genbehandling af de minder. Backups taget forinden indeholder data, indtil de udløber efter planen ovenfor.

Hvad der overlever, og hvorfor

Hver ændring kører den samme række af porte: typekontrol af hele kodebasen, en kontrol af grænserne mellem dens dele, unit- og integrationstests mod en rigtig database og testene for adskillelse. Pipelinen opfinder ikke en ny opfattelse af korrekt — den fjerner antagelsen om, at nogen kørte kontrollerne i hånden.

Integrationstrinnet gengiver den lokale stak nøjagtigt, delte forbindelser inklusive. En pipeline, der delte forbindelser anderledes, ville lade testene for adskillelse bestå, mens produktet lækkede.

En udgivelse er en merge til en deployment-branch: en ændring med en forfatter og et tidspunkt, som kan gennemgås, frem for en kommando, nogen kørte på en bærbar.

De samme påstande én gang til, med mekanismen nævnt ved navn, til den, der vil have den. Ét dedikeret PostgreSQL-skema pr. kunde — ingen fælles tabel og ingen tenant_id-kolonne, en forespørgsel kan glemme. Hver forespørgsel kører inde i en transaktion, der udsteder SET LOCAL search_path for det skema, aldrig et SET på sessionsniveau, som ville overleve commit og følge en delt forbindelse videre til den næste kunde i rækken; isolationstestene kører netop derfor mod en rigtig connection pooler i transaction mode, og en direkte forbindelse kunne slet ikke fremkalde fejlen. Skemanavne kommer fra tenant-registret og aldrig fra en forespørgsel. public står tomt, og platformens tabeller ligger i platform, så en forespørgsel, der har mistet sin search path, finder ingenting frem for en andens data. Udslettelse er DROP SCHEMA: tabellerne ophører med at findes, det kan ikke fortrydes, og det opgiver for altid enhver genbehandling af de rækker. Den rutinemæssige oprydning markerer rækker frem for at slette dem. Revisionsspor overlever en udslettelse og anonymiseres i samme transaktion. TLS under transport; AES-256-GCM envelope-kryptering af den udbyderlegitimation, vi opbevarer.

Der findes ingen SOC 2-rapport og intet ISO 27001-certifikat, og vi siger det hellere ligeud end at lade et manglende mærkat antyde noget andet. Der findes heller ingen serviceaftale og intet betalt bug bounty-program.

Det, vi har, står ovenfor, og hvert punkt svarer til noget, du kan bede os om at demonstrere.

Send den via kontaktformularen, og vælg sikkerhedsemnet. Fortæl, hvad du gjorde, hvad du så, og hvad du forventede. Et request-id fra et API-svar hjælper langt mere end et skærmbillede.

Vi kvitterer for rapporten, fortæller dig, hvad vi fandt, og siger til, når den er lukket. Vi forfølger ikke retligt en undersøgelse foretaget i god tro mod din egen konto og dine egne arbejdsområder.

Test ikke mod en anden kundes data, og kør ikke belastnings- eller overbelastningstests. Mener du, at en test skal krydse den grænse, så spørg først — svaret er oftere ja, end du skulle tro.