Säkerhet

Transportsäkerhet

• All transport SKALL (SÄK.01) ske över HTTPS med minst TLS 1.2.
• Alla certifikat SKALL (SÄK.02) vara från SHA-2 (Secure Hash Algorithm 2) kryptografiska hashfunktioner med minsta nyckellängd på 2048.
• Alla offentligt tillgängliga endpoints SKALL (SÄK.03) använda ett digitalt certifikat som har undertecknats av en godkänd certifikatutfärdare.
• Endpoints avsedd för internt bruk KAN (SÄK.04) använda självsignerade digitala certifikat.
• Omdirigera inte HTTP-trafik till HTTPS – avvisa dessa förfrågningar.
• Oanvända HTTP-metoder BÖR (SÄK.05) inaktiveras och returnera HTTP-status 405.
• Alla requests SKALL (SÄK.06) valideras.

Beroende på säkerhetsklassificeringen av informationen i API:et KAN (SÄK.07) du behöva upprätta följande kontroller utöver standardkontrollerna:

• Ömsesidig autentisering mellan konsumenten och API-gateway.
• Ömsesidig autentisering mellan API Gateway och back-end API.
• PKI Mutual TLS OAuth-klientautentiseringsmetod.
• Vitlistning av IP-nummer för API-konsumenter som använder antingen API Gateway Policy eller brandväggskonfigurationer.
• Vitlistning av IP-nummer för API-producenter som använder antingen API Gateway Policy eller brandväggskonfigurationer.
• Kryptering av payload under överföring.
• Signering av payload för integritet och verifiering.

Autentisering och auktorisation

Om man i informationsklassningen har restriktioner till vilka som får konsumera informationen i API:et så SKALL (SÄK.08) autentisering och auktorisation användas.

• Basic- eller Digest-autentisering SKALL INTE (SÄK.09) användas.
• Authorization: Bearer header SKALL (SÄK.10) användas för autentisering/auktorisation.
• En uppdateringstoken SKALL (SÄK.11) tillhandahållas för att förlänga giltighetstiden för befintliga token utan att behöva tillhandahålla referenserna igen.
• Ställ alltid in en rimlig giltighetstid för tokens. En OIDC-åtkomsttokens livslängd BÖR INTE (SÄK.12) överstiga 5 minuter.
• Klientapplikationsidentitet BÖR (SÄK.13) etableras via en konsekvent mekanism. Detta kan vara via en API-nyckel eller via en mer robust mekanism som en OAuth-serveridentitet.
• Rotationspolicy för API-nycklar BÖR (SÄK.14) implementeras där så är tillämpligt.
• API-nycklar SKALL INTE (SÄK.15) inkluderas i URL eller querysträngen.
• API-nycklar SKALL (SÄK.16) inkluderas i HTTP-headern eftersom querysträngar kan sparas av klienten eller servern i okrypterat format av webbläsaren eller serverapplikationen.
• CORS-headers (Cross-origin resource sharing) BÖR (SÄK.17) endast användas när det är nödvändigt eftersom det kringgår de övergripande säkerhetsmekanismerna som är inbyggda i webbläsare genom att selektivt lätta på restriktioner för cross-origins, RFC 6454.
  • Använd aldrig URL-adresser med jokertecken (*) i response headers (dvs. Access-Control-Allow-Origin) såvida inte REST-resursen verkligen är offentlig och kräver liten eller ingen auktorisation för användning.
  • En request från domän A anses vara Cross-Origin när den försöker göra en request till ett API som finns på domän B.
    • Av säkerhetsskäl begränsar webbläsares HTTP-förfrågningar med flera ursprung.
    • Cross-Origin Resource Sharing-standarden fungerar genom att lägga till nya HTTP-headers (d.v.s. Access-Control-Allow-Origin) som tillåter servrar att beskriva vilka domäner som har tillåtelse att komma åt API:et

OAuth

OAuth version 2.0 eller senare BÖR (SÄK.18) användas för auktorisation. OAuth är ett auktorisationsprotokoll som säkert delegerar behörighet till en annan resurs. Det tillåter användare att godkänna applikationer att agera för deras räkning utan att dela med sig av sitt lösenord.

Abstraktion

Det finns flera abstraktionsnivåer, benämningar av abstraktionsnivån baseras till stor del på antalet konsumenter och kostnaden för att ändra systemet på grund av en API-ändring.

Som en allmän princip BÖR (SÄK.19) det finnas en abstraktionsnivå av källsystemets data- och affärslogik i din API-design för att frikoppla konsumenterna och API-tjänsteleverantörerna. Det rekommenderas att tillämpa grundläggande abstraktion på ett SaaS API (som ett Azure API). Till exempel; om det finns ändringar i SaaS-autentiseringsschemat kan det hanteras inom API:t.

En högre abstraktionsnivå skulle krävas för API:er som har flera konsumenter och kostnaden för förändring för API-konsumenterna är större än kostnaden för att byta backend-system/tjänsteleverantörer.

De olika abstraktionsnivåerna är följande:

Begränsa användandet av API:et

Tillämpa policyer för att begränsa antal requests eller systematiskt missbruk för att förhindra felaktig användning av ditt API. Se till att lämpliga varningar implementeras och svara med informativa felmeddelanden när tröskelvärdena närmar sig eller har överskridits.

Följande headers returneras vid användning av “rate limits”:

Felhantering

Felmeddelanden SKALL INTE (SÄK.24) avslöja information som kan användas för att attackera ditt system. För att undvika detta upprätta följande kontroller när du tillhandahåller felmeddelanden:

• Ett API SKALL (SÄK.25) maskera alla systemrelaterade fel bakom vanliga HTTP-statuskoder och felmeddelanden, t.ex. exponera inte information på systemnivå i ditt felmeddelande
• Ett API SKALL INTE (SÄK.26) skicka tekniska detaljer (t.ex. anropsstackar eller andra interna tips) till klienten

Loggning

En viktig aspekt av säkerheten är att bli meddelad när något fel inträffar och att kunna undersöka det. Man BÖR (SÄK.27) definiera loggningsnivåer som kan användas för att trigga lämpliga varningar och larm.

• Skriv audit-loggar före och efter säkerhetsrelaterade händelser som kan utlösa varningarna
• Sanering av loggdata för att förhindra logginjektionsattacker

Validering av ingående parametrar

Validering av ingående parametrar BÖR (SÄK.28) utföras för att säkerställa att endast korrekt formaterad data tas emot av ditt system, detta hjälper till att förhindra skadliga attacker.

• Validering av indata bör ske så tidigt som möjligt, helst så snart informationen har tagits emot från den externa parten
• Definiera exempelvis en lämplig storleksgräns för request och avvisa requests som överskrider gränsen
• Validera exempelvis: längd/intervall/format och typ
• Överväg att logga valideringsfel på indata. Anta att någon som utför hundratals misslyckade indatavalideringar per sekund har en skadlig avsikt
• Begränsa stränginmatningar med reguljärt uttryck där så är lämpligt

Validering av innehållstyp

Man BÖR (SÄK.29) respektera angiven content-type i header. Avvisa förfrågningar som innehåller oväntade eller saknade content-type headers med HTTP-status “415 Unsupported Media Type”

Gateway säkerhetsfunktioner

Det är att föredra att använda säkerhetspolicyfunktionerna som finns i API Gateway-plattformar än att implementera policyerna i ditt back-end API.