Sikring av vev-API
Sikring av vev-API innebærer å autentisere programmer eller brukere som kaller et vev API.
Sammen med enkelheten med API-integrasjoner kommer kompleksiteten med å sikre riktig autentisering og autorisering. I et miljø med flerleie (multi tenant) kan sikkerhetskontroller basert på riktig autentisering og autorisering bidra til å sikre at API-tilgang begrenses til de som trenger det og har rett på dette. Passende metoder for autentisering gjør det mulig for produsenter av API-er eller tjenester å på riktig måte identifisere forbrukere (klienter eller kallende programmer) og evaluere tilgangsnivået deres (autorisering). Med andre ord hvorvidt en forbruker kan kalle en en bestemt metode (forretningslogikk) basert på den presenterte legitimasjonen.
Ifølge en publisert tekst[1] er designfeil i grensesnitt utbredt, og kan finnes blant annet i "prosessorer brukt til kryptografi, diverse innebygde systemer, antivirusprogrammer og operativsystemer."
Metoder for autentisering og autorisering[rediger | rediger kilde]
Vanlige metoder for autentisering og autorisering inkluderer.
- Statiske strenger: Disse er som passord som leveres av API-er til forbrukerne.
- Dynamiske polletter (dynamic tokens): Dette er tidsbaserte polletter gitt til den kallende fra en autentiseringstjeneste.
- Brukertildelte polletter (user-delegated tokens): Dette er polletter som for eksempel OAuth[2] som er blir gitt basert på brukerautentisering.
- Policy- og attributtbasert tilgangsstyring: Policyer bruker attributter til å definere hvordan API-er kan kalles ved hjelp av standarder som ALFA eller XACML.
De ovennevnte metodene gir forskjellige nivåer av sikkerhet og enkelhet av integrasjon. Ofte tilbyr den enkleste integrasjonsmetoden også den svakeste sikkerhetsmodellen.
Statiske strenger[rediger | rediger kilde]
I metoden med statiske strenger legger API-kalleren eller klienten inn en streng som en pollett i forespørselen. Denne metoden er ofte referert til som basic authentication ("enkel godkjenning").
Ifølge Jan Wolter[3] er denne løsningen ikke veldig tilfredsstillende med tanke på sikkerhet, ettersom det innebærer å sende brukerens passord over nettverket i klartekst (med mindre man benytter en sikker protokoll på et lavere nivå som for eksempel SSL for å kryptere alle transaksjoner). Brukeren er dermed veldig sårbar for pakkesniffere på nettet.[3]
Dynamiske polletter (dynamic tokens)[rediger | rediger kilde]
Når et API beskyttes av en dynamisk pollett gjøres dette ved å sette inn en tidsbasert nonce i polletten. Polletten har en begrenset levetid (time to live, TTL) hvoretter klienten må skaffe seg en ny pollett. Denne API-metoden har en tidskontroll-algoritme, og dersom polletten er utløpt vil forespørselen avslås (request forbidden). JSON Web Token er et eksempel på en slik pollett, og der setter exp-kravet utløpstiden (expiration time) som sier når JWT ikke lenger kan akseptere forespørsler for behandling.[4]
Brukertildelte polletter (user delegated token)[rediger | rediger kilde]
Denne typen pollett brukes i trebeinte systemer hvor en applikasjon trenger å få tilgang til et API på vegne av en bruker. Istedet for å dele bruker-ID og passord til programmet gir brukeren ut en pollett som innkapsler brukernes tillatelse til at applikasjonen kan kalle API-et.
Autorisasjonsrammeverket OAuth 2.0 gjør det mulig for et tredjepartsprogram å få begrenset tilgang til en HTTP-tjeneste, enten på vegne av en ressurseier ved å organisere en godkjenningsinteraksjon mellom ressurseieren og HTTP-tjenesten, eller ved å la tredjepartsprogrammet selv få tilgang.[5]
Finkornet autorisering for API-er[rediger | rediger kilde]
Attributtbasert tilgangskontroll[rediger | rediger kilde]
Med denne tilnærmingen er det et håndhevelsen av retninglinjer (policy) enten innenfor selve API-et, i API-rammeverket (som en avskjæringsanordning eller meldingsbehandler) eller som en API-portner (gateway) som for eksempel WSO2, Kong eller lignende, som fanger opp kallet til API-et og/eller svaret tilbake fra API-et. Den konverteres så til en autorisasjonsforespørsel (vanligvis i XACML) som sendes til et policybeslutningspunkt (Policy Decision Point, PDP), for eksempel AuthZForce eller Axiomatics. Policybeslutningspunktet er konfigurert med policyer som implementerer dynamisk tilgangskontroll som kan bruke et hvilket som helst antall bruker-, ressurs-, operasjon- og kontekst-attributter for å definere hvilken tilgang som tillates eller ikke. Policyen kan handle om:
- Ressursen (for eksempel en bankkonto)
- Brukeren (for eksempel en kunde)
- Kontekst (for eksempel tid på dagen)
- En relasjon (for eksempel kunden som kontoen tilhører).
Retningslinjene blir ofte uttrykt med pseudokodespråk for tilgangskontroll som eXtensible Access Control Markup Language (XACML) eller Abbreviated Language For Authorization (ALFA).
Referanser[rediger | rediger kilde]
- ^ «API Attacks» (PDF).
- ^ «OAuth 2.0 — OAuth». Besøkt 10. oktober 2015.
- ^ a b «A Guide to Web Authentication Alternatives: Part 2». Besøkt 10. oktober 2015.
- ^ John, Bradley. «JSON Web Token (JWT)». Besøkt 10. oktober 2015.
- ^ Hardt, Dick. «The OAuth 2.0 Authorization Framework». Besøkt 11. oktober 2015.