Et API med regulerte data sikres ved at du kartlegger hvem som kan misbruke det, sjekker autorisasjon for hvert objekt og hvert felt, samler inn og returnerer så lite data som mulig, og holder hemmeligheter og revisjonslogger under streng kontroll. Svakhetene som betyr mest i praksis, er hull i autorisasjonen og svar som eksponerer for mye data, ikke knekt kryptering.
Start med en trusselmodell for dataene, ikke for rammeverket
Før du velger verktøy, bør du skrive ned hva API-et eksponerer, og hvem som kan misbruke det. For en bank betyr det konto- og transaksjonsdata; for et energi- eller forsyningsselskap kan det bety måledata, kundekontrakter og driftsmålinger fra nettet.
En nyttig trusselmodell er kort. Den lister opp de sensitive dataene, hver aktør som kan nå dem, handlingene hver aktør skal kunne utføre, og hva som skjer hvis en av dem blir kompromittert. Dette dokumentet styrer deretter alle tiltakene nedenfor, og det forteller dem som går gjennom løsningen, hva de skal teste.
- Hvilke data som er personopplysninger, fortrolige eller regulerte, og hvor de er lagret.
- Alle som bruker API-et: interne tjenester, partnere, mobilapper og administratorer.
- Hva hver bruker har lov til å lese, endre eller utløse.
- Konsekvensene av et lekket token, en ondsinnet innsider eller et kompromittert partnersystem.
Autentiser hver aktør, og autoriser deretter hvert objekt
Bruk en standardprotokoll som OAuth 2.0 med OpenID Connect for brukere, og kortlevde tokener eller gjensidig TLS for kall mellom tjenester. Unngå langlivede, delte API-nøkler, fordi ingen kan se hvilket system som brukte dem, eller trekke dem tilbake uten å ødelegge for andre.
Autentisering beviser bare hvem som kaller. Det første punktet på OWASP API Security Top 10 er brutt autorisasjon på objektnivå (broken object level authorization): en gyldig bruker endrer en identifikator i forespørselen og leser en annens post. Sjekk eierskap eller tilhørighet på serveren for hvert objekt, hver funksjon og hvert sensitive felt, og stol aldri på en identifikator eller en rolle som klienten sender.
Gi hver klient og tjeneste minst mulig tilgang
Minste tilgang begrenser skaden når noe først går galt. Utsted egne påloggingsopplysninger per bruker av API-et, avgrens tokener til bestemte operasjoner, og hold administrative endepunkter på en egen sti med strengere kontroller.
Bruk den samme regelen under API-et. Tjenestekontoen som leser måledata, skal ikke kunne slette dem, og en rapportjobb bør koble til med en databaserolle som bare har lesetilgang. Gå gjennom tillatelsene etter en fast plan, fordi tilgang som er gitt for en engangsoppgave, har en tendens til å bli liggende for alltid.
Samle inn mindre, returner mindre og oppbevar det kortere
Dataminimering er både et prinsipp i GDPR og et sterkt sikkerhetstiltak: data du aldri lagrer, kan ikke lekke. Spør for hvert felt om tjenesten virkelig trenger det, og fjern eller pseudonymiser det den ikke trenger.
Bruk den samme disiplinen på svarene. Definer eksplisitte svarskjemaer i stedet for å serialisere hele databaseobjekter, masker identifikatorer som kontonumre der hele verdien ikke trengs, og sett oppbevaringstider slik at gamle poster slettes. Dokumenter behandlingsgrunnlaget for hvert formål, og inngå databehandleravtaler med alle leverandører som håndterer dataene. Dette er utviklingspraksis, ikke juridisk rådgivning, så involver personvernombudet eller juristen din i den juridiske vurderingen.
Valider alle inndata, og begrens hvor mye én aktør kan bruke
Behandle hver forespørsel som fiendtlig til den er validert. Håndhev et skjema for hvert endepunkt, avvis ukjente felt, og bruk parameteriserte spørringer, slik at inndata aldri blir en del av en databasekommando.
Flere av API-risikoene fra OWASP skyldes manglende grenser heller enn dårlig kode. Begrens antall forespørsler per klient, sett tak på sidestørrelse og størrelse på nyttelast, og beskytt sensitive forretningsflyter som betalinger eller kontraktsendringer mot automatisert misbruk. Hvis API-et henter eksterne URL-er på vegne av dem som kaller det, må du begrense mulige mål for å hindre server-side request forgery.
Hold hemmeligheter utenfor kode, images og logger
Databasepassord, signeringsnøkler og påloggingsopplysninger til partnere hører hjemme i et eget system for hemmeligheter, der de hentes inn ved kjøring og roteres etter en fast plan. Skann repositorier og container-images for hemmeligheter i byggepipelinen, og behandle enhver hemmelighet som havner i versjonskontrollen, som kompromittert.
Skill hemmeligheter per miljø, slik at en lekket testpålogging aldri åpner produksjonen. Begrens hvem som kan lese hemmeligheter i produksjon, og loggfør hver tilgang til dem.
Logg for revisjon, og design for færre hendelser
Regulerte miljøer må i ettertid kunne svare på et enkelt spørsmål: hvem fikk tilgang til hvilke data, når, og gjennom hvilken klient. Registrer dette for hver sensitive lesing og skriving, lagre loggene der de som drifter applikasjonen, ikke kan endre dem, og hold personopplysninger utenfor loggmeldingene.
Kombiner logging med varsler ved uvanlige mønstre, for eksempel en klient som leser langt flere poster enn vanlig, og en testet plan for hendelseshåndtering. Gjennom Sopra Steria bygde utviklerne våre sikre API-er for sensitive data fra forsyningssektoren under regulatoriske krav, og ledet et verktøy for driftsovervåking der håndhevede sikkerhetsstandarder gikk hånd i hånd med færre hendelser i produksjon. SDK Enterprises bruker den samme praksisen i kundeprosjekter i dag.
Det viktigste
- En kort, skriftlig trusselmodell for dataene bør styre alle sikkerhetstiltak i API-et.
- Sjekk autorisasjon på serveren for hvert objekt, hver funksjon og hvert sensitive felt, ikke bare ved innlogging.
- Minste tilgang gjelder for tokener, tjenestekontoer og databaseroller på samme måte.
- Dataminimering reduserer både eksponeringen etter GDPR og konsekvensene av et eventuelt brudd.
- Revisjonslogger må vise hvem som fikk tilgang til hva og når, uten at de selv lekker personopplysninger.
Spørsmål og svar
Er HTTPS nok til å sikre et API?
Nei. TLS beskytter data under overføring, men mange brudd på API-er handler om autentiserte aktører som når data de ikke skal se. Autorisasjonskontroller, validering av inndata, begrensning av forespørsler og revisjonslogging er fortsatt nødvendig.
Hva er brutt autorisasjon på objektnivå?
Det er en svakhet der API-et sjekker at den som kaller, er logget inn, men ikke at den forespurte posten tilhører vedkommende. Ved å endre en identifikator i URL-en eller innholdet i forespørselen kan man da få se andre brukeres data. Løsningen er en kontroll av eierskap eller tilhørighet på serveren for hvert objekt.
Krever GDPR bestemte sikkerhetstiltak for API-er?
GDPR krever egnede tekniske og organisatoriske tiltak ut fra risikoen, uten å påby bestemte verktøy. Tiltak som tilgangsbegrensning, minimering, pseudonymisering og logging er vanlige måter å oppfylle kravet på, og de juridiske rådgiverne dine bør bekrefte hva som gjelder i ditt tilfelle.