Hvor den kører
- Database og login
- Supabase Postgres i eu-central-1, Frankfurt.
- API'et
- En gateway på Fly.io i Frankfurt, i samme region som databasen.
- Portaler og studiet
- Next.js på Vercel. De leverer siderne; selve data besvares af gatewayen i Frankfurt.
- Resend, til invitationer og login-links.
Hvad Kilango gemmer
Nok til at vide, hvem der må se hvad, og intet der ville gøre Kilango til en kopi nummer to af jeres forretning.
- En organisation
- Navn, CVR-nummer, maildomæne, hvilken slags modpart det er, og dens plads i en koncern, hvis den har en.
- En person
- Navn, mailadresse og sprog, plus hvilke portaler personen er medlem af, og hvad hvert medlemskab må nå.
- En kobling
- Forbindelsen mellem en af jeres kunder og den samme kunde i jeres eget system, med en note om hvad der matchede: et CVR-nummer, et domæne, et navn.
- En portal
- Jeres logo, jeres farve, jeres domæne, hvilke sider der findes, og hvilke systemer der fylder dem.
- En forbindelse
- En krypteret nøgle, der lader Kilango læse ét af jeres systemer på jeres vegne.
- Aktivitet
- Hvem der gjorde hvad, og hvornår.
Hvad Kilango ikke kan gemme
Der findes ingen tabel til jeres projekter, jeres aftaler, jeres fakturaer, jeres sager, jeres timer eller jeres medarbejdere. Ikke som en politik, der stille kunne laves om, men som et fravær i databasen.
Det fravær bliver kontrolleret af en maskine. Et script læser skemaet ved hvert build og fælder det, hvis en tabel eller en kolonne er opkaldt efter et forretningsobjekt. Den, der tilføjer en tabel ved navn Projekt eller en kolonne ved navn fakturanummer, får ikke en diskussion; de får et rødt build.
Hvad der passerer igennem, og hvad der bliver liggende
Når nogen åbner en side, spørger Kilango jeres system om svaret og viser det. Der er ingen import, ingen natlig synkronisering og ingen gemt kopi af posten. Der er tre ærlige undtagelser, og de er værd at kende:
- Et svar holdes i hukommelsen i mellem tredive sekunder og ti minutter, så den samme side ikke spørger jeres system to gange. Det når aldrig ned på en disk, og nøglen indeholder præcis den person, der spurgte, så én brugers svar kan aldrig serveres til en anden.
- Sender ét af jeres systemer en hændelse til Kilango, gemmes hændelsen, så der kan bygges en notifikation af den. Det er en besked om en ændring frem for selve posten.
- En notifikation beholder sin egen overskrift og én linje tekst, som kom fra den hændelse.
Alt andet, jeres kunde ser på en side, blev hentet, mens siden blev indlæst, og er væk, når den lukkes.
Hvordan én kunde holdes adskilt fra en anden
Hver tabel, der hører til et workspace, bærer workspacet på rækken, og databasen nægter at udlevere en række, der hører til en anden. Reglen håndhæves af Postgres frem for af, at applikationen husker at spørge rigtigt, den gælder skrivninger lige så vel som læsninger, og den konto, applikationen forbinder med, har ikke lov til at slå den fra.
Det er ikke en påstand om hensigt. Det er afprøvet mod produktionsdatabasen: spørger man efter et workspace uden at sige hvilket, kommer der intet; spørger man med det forkerte, kommer der intet; og applikationens konto bliver afvist, når den forsøger at oprette en tabel eller læse migreringshistorikken. Et selvstændigt script kontrollerer, at der ikke er kommet en ny tabel til uden reglen.
For den, der er logget ind i en portal, er der en port mere ovenpå: forespørgslen opløses på serveren til en person, en organisation og et aktivt medlemskab, browseren kan ikke påvirke noget af det, og medlemskabet læses igen ved hver eneste forespørgsel. Trækker I en adgang tilbage, holder den op med at virke med det samme frem for når et token udløber.
Nøglerne til jeres systemer
I indsætter en nøgle fra jeres eget system, og Kilango krypterer den med AES-256-GCM, før den gemmes. Den dekrypteres i det øjeblik, en forespørgsel har brug for den, den skrives aldrig i en log, og den udleveres aldrig af nogen del af produktet. Ikke maskeret, ikke delvist. Kobler I systemet fra, bliver den krypterede nøgle slettet frem for markeret som inaktiv.
Forbindelsen laver I én gang, for workspacet. Jeres kunder logger aldrig ind i jeres systemer, og det er præcis derfor, det er inde i Kilango, det afgøres, hvad en portal kan nå.
Hvordan folk logger ind
Portaler er kun ved invitation og har hverken oprettelse eller adgangskode. En person får et link og en sekscifret kode i den samme mail og bruger det, de foretrækker. Jeres eget team logger ind i studiet på samme måde og kan tilføje en adgangskode og en godkendelses-app.
At se portalen som en bruger
Jeres team kan åbne en kundes portal og se præcis den skærm, kunden ser. Det er den hurtigste vej til at svare på, hvorfor noget mangler, og det er den farligste funktion i produktet, så den er hegnet ind fra alle sider.
- Den er skrivebeskyttet, og det er det første, der tjekkes ved hver forespørgsel, frem for en rettighed, der kunne tildeles.
- Den varer et kvarter og kan ikke forlænges.
- Linket, der starter den, virker én gang og udløber efter tres sekunder.
- Det kræver en administrator at starte en, og sessionen kan ikke begynde, hvis noteringen af den ikke blev skrevet først.
- At den startes, åbnes og afsluttes bliver noteret, sammen med hvor mange gange der blev hentet data, mens den var åben.
- Åbne sessioner kan ses i studiet og afsluttes af enhver, der må starte en.
Hvad der bliver skrevet ned
Ændringer i adgang, portaler og sider, forbindelser, nøgler, medlemmer og se-som-bruger bliver noteret med hvem der gjorde det, fra hvilken adresse, og på hvad. For de handlinger, hvor en manglende notering ville betyde noget, skrives noteringen først: kan den ikke skrives, sker handlingen ikke.
Hvem andre der er involveret
- Supabase
- Database og login, i Frankfurt.
- Fly.io
- API'et, i Frankfurt.
- Vercel
- Leverer portalerne og studiet.
- Resend
- Invitationer og login-mails.
- Twilio
- Telefonbekræftelse, kun til jeres eget teams konti i studiet. Portalbrugere når den aldrig.
- Gandi
- Domænenavne.
Ud over dem kun de systemer, I selv kobler på. Der er hverken analytics, fejlrapportering eller et tredjepartsscript inde i en portal.
Hvad vi ikke har bygget
Single sign-on med jeres eget login er ikke muligt endnu, og det er det heller ikke at logge ind i et kildesystem med OAuth frem for med en nøgle. Begge dele er på vej. Vi vil hellere have, at I ved det nu, end at I opdager det midt i en implementering.
Vi har ingen certificeringer
Der findes intet ISO 27001-certifikat, ingen SOC 2-rapport og ingen pentestrapport at sende jer. At skaffe en er en beslutning om tid og penge, som ikke er truffet, og indtil den er, ville et mærke på denne side være mindre værd end den sætning, I læser nu.
Det, I kan efterprøve i stedet, er arkitekturen. Spørg hvad en tabel indeholder, spørg hvad en nøgle kan læse, spørg hvad der sker, når I slukker. De svar står på denne side, og det er dem, et certifikat ville opsummere.
Hvis jeres gennemgang kræver mere end det her
En sikkerhedsgennemgang stiller spørgsmål, denne side ikke svarer på, og nogle af dem vil vi hellere svare præcist end omtrentligt på. Skriv til os, så får I et konkret svar fra en, der har læst koden.