Säkra ett API med reglerade data genom att kartlägga vem som skulle kunna missbruka det, kontrollera behörigheten för varje objekt och fält, samla in och returnera så lite data som möjligt och hålla hemligheter och granskningsloggar under strikt kontroll. De svagheter som spelar störst roll i praktiken är luckor i behörighetskontrollen och svar som exponerar för mycket data, inte knäckt kryptering.
Börja med en hotmodell för data, inte för ramverket
Innan du väljer verktyg: skriv ner vad API:et exponerar och vem som skulle kunna missbruka det. För en bank handlar det om konto- och transaktionsdata; för ett energi- eller försörjningsbolag kan det handla om mätdata, kundavtal och driftvärden från nätet.
En användbar hotmodell är kort. Den listar känsliga data, varje anropare som kan nå dem, de åtgärder varje anropare ska kunna utföra och vad som händer om någon av dem komprometteras. Dokumentet styr sedan varje skydd nedan, och det talar om för granskarna vad de ska testa.
- Vilka data som är personuppgifter, konfidentiella eller reglerade, och var de lagras.
- Varje konsument av API:et: interna tjänster, partner, mobilappar och administratörer.
- Vad varje konsument får läsa, ändra eller starta.
- Följderna av en läckt token, en illasinnad insider eller ett komprometterat system hos en partner.
Autentisera varje anropare och auktorisera sedan varje objekt
Använd ett standardprotokoll som OAuth 2.0 med OpenID Connect för användare, och kortlivade tokens eller ömsesidig TLS för anrop mellan tjänster. Undvik långlivade delade API-nycklar, eftersom ingen kan avgöra vilket system som använde dem eller återkalla dem utan att andra system slutar fungera.
Autentisering bevisar bara vem som anropar. Första punkten i OWASP API Security Top 10 är bristande behörighetskontroll på objektnivå (broken object level authorization): en giltig användare ändrar en identifierare i anropet och läser någon annans post. Kontrollera ägarskap eller tillhörighet på servern för varje objekt, varje funktion och varje känsligt fält, och lita aldrig på en identifierare eller en roll som klienten skickar.
Ge varje klient och tjänst minsta möjliga behörighet
Minsta möjliga behörighet begränsar skadan när något trots allt går fel. Utfärda separata inloggningsuppgifter per konsument, begränsa tokens till specifika åtgärder och håll administrativa endpoints på en separat sökväg med strängare kontroller.
Tillämpa samma regel under API:et. Tjänstekontot som läser mätdata ska inte kunna radera dem, och ett rapportjobb ska ansluta med en databasroll som bara har läsbehörighet. Gå igenom behörigheterna enligt ett schema, eftersom åtkomst som ges för en engångsuppgift har en tendens att bli kvar för alltid.
Samla in mindre, returnera mindre och spara det kortare tid
Dataminimering är både en princip i GDPR och ett starkt säkerhetsskydd: data du aldrig lagrar kan inte läcka. Fråga för varje fält om tjänsten verkligen behöver det, och ta bort eller pseudonymisera det som inte behövs.
Tillämpa samma disciplin på svaren. Definiera uttryckliga svarsscheman i stället för att serialisera hela databasobjekt, maskera identifierare som kontonummer där hela värdet inte behövs och sätt lagringstider så att gamla poster raderas. Dokumentera den rättsliga grunden för varje ändamål med behandlingen och teckna personuppgiftsbiträdesavtal med varje leverantör som hanterar data. Det här är utvecklingspraxis, inte juridisk rådgivning, så involvera ditt dataskyddsombud eller din jurist för den juridiska bedömningen.
Validera all indata och begränsa hur mycket en anropare kan förbruka
Behandla varje anrop som fientligt tills det har validerats. Tillämpa ett schema för varje endpoint, avvisa okända fält och använd parametriserade frågor så att indata aldrig blir en del av ett databaskommando.
Flera av OWASP:s API-risker beror på saknade gränser snarare än dålig kod. Begränsa antalet anrop per klient, sätt tak för sidstorlekar och storleken på innehåll, och skydda känsliga affärsflöden som betalningar eller avtalsändringar mot automatiserat missbruk. Om API:et hämtar externa URL:er åt anroparna: begränsa vilka mål som tillåts för att förhindra server-side request forgery (SSRF).
Håll hemligheter borta från kod, avbilder och loggar
Databaslösenord, signeringsnycklar och inloggningsuppgifter till partner hör hemma i en särskild hanterare för hemligheter, där de injiceras vid körning och byts ut enligt ett schema. Sök igenom kodförråd och containeravbilder efter hemligheter i byggpipelinen, och behandla varje hemlighet som hamnar i versionshanteringen som komprometterad.
Håll hemligheterna åtskilda per miljö så att en läckt inloggningsuppgift för test aldrig öppnar produktionen. Begränsa vem som kan läsa hemligheter i produktion och logga varje åtkomst till dem.
Logga för granskning och bygg för färre incidenter
Reglerade miljöer måste i efterhand kunna svara på en enkel fråga: vem kom åt vilka data, när och via vilken klient. Registrera det för varje känslig läsning och skrivning, lagra loggarna där applikationens driftpersonal inte kan ändra dem och håll personuppgifter borta från loggmeddelandena.
Kombinera loggningen med larm vid ovanliga mönster, till exempel att en klient läser långt fler poster än vanligt, och en testad plan för incidenthantering. Via Sopra Steria byggde våra utvecklare säkra API:er för känsliga data från försörjningsbolag under regulatoriska krav, och ledde ett verktyg för driftövervakning där upprätthållna säkerhetsstandarder gick hand i hand med färre incidenter i produktion. SDK Enterprises tillämpar samma arbetssätt i kundprojekt i dag.
Det viktigaste
- En kort, skriftlig hotmodell för data bör styra varje säkerhetsskydd i API:et.
- Kontrollera behörigheten på servern för varje objekt, varje funktion och varje känsligt fält, inte bara vid inloggningen.
- Minsta möjliga behörighet gäller lika mycket för tokens som för tjänstekonton och databasroller.
- Dataminimering minskar både exponeringen enligt GDPR och följderna av ett intrång.
- Granskningsloggar ska visa vem som kom åt vad och när, utan att själva läcka personuppgifter.
Vanliga frågor
Räcker HTTPS för att säkra ett API?
Nej. TLS skyddar data under överföringen, men många intrång via API:er handlar om autentiserade anropare som når data de inte borde se. Behörighetskontroller, validering av indata, begränsning av antalet anrop och granskningsloggar behövs fortfarande.
Vad är bristande behörighetskontroll på objektnivå?
Det är en brist där API:et kontrollerar att anroparen är inloggad men inte att den begärda posten tillhör anroparen. Om man ändrar en identifierare i URL:en eller i anropets innehåll exponeras då andra användares data. Lösningen är en kontroll av ägarskap eller tillhörighet på servern för varje objekt.
Föreskriver GDPR särskilda säkerhetsskydd för API:er?
GDPR kräver lämpliga tekniska och organisatoriska åtgärder utifrån risken, utan att föreskriva särskilda verktyg. Skydd som åtkomstbegränsning, minimering, pseudonymisering och loggning är vanliga sätt att uppfylla kravet, och dina juridiska rådgivare bör bekräfta vad som gäller i ditt fall.