Hvordan bygger dere tilgangsstyring i en kundeportal?

Vi legger tilgangsstyringen i databasen og i et eget lag for datatilgang, ikke bare i grensesnittet eller i middleware. Det betyr at reglene for hvem som får se og endre hva, håndheves der dataene ligger. En feil i en skjerm eller et API-kall skal ikke kunne gi en bruker tilgang til noe vedkommende ikke har rett til.

Hvorfor grensesnittet ikke er nok

I mange løsninger er tilgangsstyringen bygget ved at knapper og menyer skjules for brukere som ikke har rett til dem. Det ser riktig ut, men dataene bak er like tilgjengelige for den som sender forespørselen direkte. I en kundeportal der flere bedrifter deler samme løsning, betyr en slik lekkasje at én kunde kan se en annens priser, ordrer eller dokumenter.

Slik er det bygget i praksis

I en B2B-løsning vi bygger for en kunde, er tilgangsstyringen bygget slik:

• Radnivåsikkerhet i Postgres: databasen avgjør hvilke rader en innlogget bruker kan lese og endre.
• Brukerbundet klient: kundevendt kode bruker alltid en databaseklient som er bundet til den innloggede brukeren, aldri en med fulle rettigheter.
• Roller fra databasen: roller leses fra databasen, ikke fra påstander i innloggingstokenet. Et token kan være gyldig i opptil en time etter at en rolle er fjernet, og så lenge skal ingen beholde en tilgang de har mistet.
• Ansattnivåer: admin har tre nivåer, og nye kontoer opprettes med et midlertidig passord som må byttes.
• Nøkler: integrasjonsnøkler lagres kryptert med AES-256-GCM og vises bare med de fire siste tegnene.

Prosjektet er under utvikling og ikke lansert, men det er denne arkitekturen vi bygger kundeportaler etter.

Testet, ikke antatt

Tilgangsregler som ikke testes, forvitrer når løsningen endres. I samme prosjekt kjører isolasjonstester mot en lokal database som sjekker at én kunde ikke kan lese en annens data, sammen med enhetstester og ende-til-ende-tester, automatisk i CI hver gang koden endres.

Hva vi avklarer med dere

1. Hvilke roller som finnes, og hva hver av dem skal kunne gjøre.
2. Hvem hos dere som oppretter og fjerner brukere.
3. Hva som skal skje når en ansatt slutter, eller en kunde avslutter avtalen.
4. Hvilke integrasjoner som trenger nøkler, og hvem som eier dem.

Les mer om hvordan vi bygger webapplikasjoner og kundeportaler, hvordan integrasjoner håndterer nøkler og feil, og hvordan tilganger følges opp etter lansering på vedlikehold og videreutvikling.