Motståndskraft genom bästa praxis för utvecklare

Artikel
10/24/2023

I den här artikeln delar vi med oss av några lärdomar som baseras på vår erfarenhet av att arbeta med stora kunder. Du kan överväga dessa rekommendationer i utformningen och implementeringen av dina tjänster.

Image shows developer experience components

Använda Microsoft Authentication Library (MSAL)

Microsofts autentiseringsbibliotek (MSAL) och Microsofts webbautentiseringsbibliotek för identiteter för ASP.NET förenkla hämtning, hantering, cachelagring och uppdatering av de token som ett program kräver. Dessa bibliotek är särskilt optimerade för att stödja Microsoft Identity, inklusive funktioner som förbättrar programmets återhämtning.

Utvecklare bör anta de senaste versionerna av MSAL och hålla sig uppdaterade. Se hur du ökar motståndskraften för autentisering och auktorisering i dina program. Undvik om möjligt att implementera din egen autentiseringsstack och använda väletablerade bibliotek.

Optimera katalogläsningar och skrivningar

Azure AD B2C-katalogtjänsten stöder miljarder autentiseringar om dagen. Den är utformad för en hög läsfrekvens per sekund. Optimera dina skrivningar för att minimera beroenden och öka motståndskraften.

Så här optimerar du katalogläsningar och skrivningar

Undvik skrivfunktioner till katalogen vid inloggning: Kör aldrig en skrivning vid inloggning utan en förhandsvillkor (if-sats) i dina anpassade principer. Ett användningsfall som kräver en skrivning vid en inloggning är just-in-time-migrering av användarlösenord. Undvik alla scenarier som kräver en skrivning vid varje inloggning. Förhandsvillkor i en användarresa ser ut så här:
```
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>
```
Förstå begränsning: Katalogen implementerar begränsningsregler på både program- och klientnivå. Det finns ytterligare hastighetsbegränsningar för åtgärderna Read/GET, Write/POST, Update/PUT och Delete/DELETE och varje åtgärd har olika gränser.
- En skrivning vid tidpunkten för inloggningen kommer att omfattas av en POST för nya användare eller PUT för befintliga användare.
- En anpassad princip som skapar eller uppdaterar en användare vid varje inloggning kan potentiellt nå en PUT- eller POST-hastighetsgräns på programnivå. Samma gränser gäller vid uppdatering av katalogobjekt via Microsoft Entra-ID eller Microsoft Graph. På samma sätt undersöker du läsningarna för att hålla antalet läsningar på varje inloggning till minimum.
- Uppskatta den högsta belastningen för att förutsäga frekvensen för katalogskrivningar och undvika begränsning. Uppskattningar av högsta trafik bör innehålla uppskattningar för åtgärder som registrering, inloggning och multifaktorautentisering (MFA). Se till att testa både Azure AD B2C-systemet och ditt program för trafiktoppar. Det är möjligt att Azure AD B2C kan hantera belastningen utan begränsning, när dina underordnade program eller tjänster inte gör det.
- Förstå och planera din tidslinje för migrering. När du planerar att migrera användare till Azure AD B2C med Microsoft Graph bör du överväga program- och klientbegränsningarna för att beräkna den tid som krävs för att slutföra migreringen av användare. Om du delar upp ditt jobb eller skript för att skapa användare med två program kan du använda gränsen per program. Det skulle fortfarande behöva ligga kvar under tröskelvärdet per klientorganisation.
- Förstå effekterna av migreringsjobbet på andra program. Överväg den livetrafik som hanteras av andra förlitande program för att se till att du inte orsakar begränsning på klientorganisationsnivå och resurssvältning för ditt aktiva program. Mer information finns i Microsoft Graph-begränsningsvägledningen.
- Använd ett belastningstestexempel för att simulera registrering och inloggning.
- Läs mer om begränsningar och begränsningar för Azure Active Directory B2C-tjänsten.

Utöka livslängden för token

I en osannolik händelse, när Azure AD B2C-autentiseringstjänsten inte kan slutföra nya registreringar och inloggningar, kan du fortfarande tillhandahålla åtgärder för användare som är inloggade. Med konfigurationen kan du tillåta att användare som redan är inloggade fortsätter att använda programmet utan någon upplevd störning tills användaren loggar ut från programmet eller sessionen överskrider tidsgränsen på grund av inaktivitet.

Dina affärskrav och önskad slutanvändarupplevelse avgör hur ofta tokenuppdateringen ska uppdateras för både webb- och ensidesprogram (SPA).

Så här utökar du tokenlivslängden

Webbprogram: För webbprogram där autentiseringstoken verifieras i början av inloggningen är programmet beroende av sessionscookien för att fortsätta utöka sessions giltigheten. Gör det möjligt för användare att förbli inloggade genom att implementera rullande sessionstider som fortsätter att förnya sessioner baserat på användaraktivitet. Om det uppstår ett långvarigt tokenutfärdande kan dessa sessionstider ökas ytterligare som en engångskonfiguration i programmet. Behåll sessionens livslängd till det högsta tillåtna.
SPA: Ett SPA kan vara beroende av åtkomsttoken för att göra anrop till API:erna. Ett SPA använder traditionellt det implicita flödet som inte resulterar i en uppdateringstoken. SPA kan använda en dold iframe för att utföra nya tokenbegäranden mot auktoriseringsslutpunkten om webbläsaren fortfarande har en aktiv session med Azure AD B2C. För SPA:er finns det några alternativ som gör att användaren kan fortsätta att använda programmet.
- Utöka varaktigheten för åtkomsttoken för att uppfylla dina affärskrav.
- Skapa ditt program för att använda en API-gateway som autentiseringsproxy. I den här konfigurationen läses SPA in utan autentisering och API-anrop görs till API-gatewayen. API-gatewayen skickar användaren via en inloggningsprocess med hjälp av ett auktoriseringskodsbeviljande baserat på en princip och autentiserar användaren. Sedan underhålls autentiseringssessionen mellan API-gatewayen och klienten med hjälp av en autentiseringscookie. API-gatewayen servar API:erna med hjälp av den token som hämtas av API-gatewayen (eller någon annan direktautentiseringsmetod som certifikat, klientautentiseringsuppgifter eller API-nycklar).
- Migrera ditt SPA från implicit beviljande till auktoriseringskodbeviljande flöde med stöd för Proof Key for Code Exchange (PKCE) och CORS (Cross-origin Resource Sharing). Migrera ditt program från MSAL.js 1.x till MSAL.js 2.x för att realisera återhämtning för webbprogram.
- För mobila program rekommenderar vi att du utökar livslängden för både uppdaterings- och åtkomsttoken.
Serverdels- eller mikrotjänstprogram: Eftersom serverdelsprogram (daemon) är icke-interaktiva och inte är i användarkontext minskar risken för tokenstöld avsevärt. Rekommendationen är att hitta en balans mellan säkerhet och livslängd och ange en lång tokenlivslängd.

Konfigurera enkel inloggning

Med enkel inloggning (SSO) loggar användarna in en gång med ett enda konto och får åtkomst till flera program. Programmet kan vara en webb-, mobil- eller en enkelsidig app (SPA), oavsett plattform eller domännamn. När användaren först loggar in på ett program bevarar Azure AD B2C en cookiebaserad session.

Vid efterföljande autentiseringsbegäranden läser och validerar Azure AD B2C den cookiebaserade sessionen och utfärdar en åtkomsttoken utan att uppmana användaren att logga in igen. Om enkel inloggning har konfigurerats med ett begränsat omfång för en princip eller ett program kräver senare åtkomst till andra principer och program ny autentisering.

Så här konfigurerar du enkel inloggning

Konfigurera enkel inloggning som klientorganisation (standard) så att flera program och användarflöden i klientorganisationen kan dela samma användarsession. Konfigurationen för hela klientorganisationen ger mest återhämtning för ny autentisering.

Säkra distributionsmetoder

De vanligaste avbrotten i tjänsten är kod- och konfigurationsändringarna. Implementering av processer och verktyg för kontinuerlig integrering och kontinuerlig leverans (CICD) hjälper till med snabb distribution i stor skala och minskar mänskliga fel under testning och distribution till produktion. Anta CICD för felminskning, effektivitet och konsekvens. Azure Pipelines är ett exempel på CICD.

Skydda mot robotar

Skydda dina program mot kända sårbarheter som DDoS-attacker (Distributed Denial of Service), SQL-inmatningar, skript mellan platser, fjärrkörning av kod och många andra som beskrivs i OWASP Top 10. Distribution av en brandvägg för webbaserade program (WAF) kan skydda mot vanliga sårbarheter och sårbarheter.

Använd Azure WAF, som ger ett centraliserat skydd mot attacker.
Använd WAF med Microsoft Entra Identity Protection och villkorlig åtkomst för att tillhandahålla skydd i flera lager när du använder Azure AD B2C.
Skapa motstånd mot robotdrivna registreringar genom att integrera med ett CAPTCHA-system.

Rotering av hemligheter

Azure AD B2C använder hemligheter för program, API:er, principer och kryptering. Hemligheterna skyddar autentisering, externa interaktioner och lagring. National Institute of Standards and Technology (NIST) anropar det tidsintervall under vilket en specifik nyckel är auktoriserad för användning av legitima entiteter en kryptoperiod. Välj rätt längd på kryptoperiod för att uppfylla dina affärsbehov. Utvecklare måste manuellt ange förfallodatum och rotera hemligheter i god tid innan de upphör att gälla.

Så här implementerar du hemlig rotation

Använd hanterade identiteter för resurser som stöds för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering. När du använder hanterade identiteter kan du hantera resurser automatiskt, inklusive rotation av autentiseringsuppgifter.
Inventera alla nycklar och certifikat som konfigurerats i Azure AD B2C. Den här listan kommer sannolikt att innehålla nycklar som används i anpassade principer, API:er, signerings-ID-token och certifikat för SAML.
Använd CICD och rotera hemligheter som snart upphör att gälla inom två månader från den förväntade högsäsongen. Den rekommenderade maximala kryptoperioden för privata nycklar som är associerade med ett certifikat är ett år.
Övervaka och rotera API-åtkomstautentiseringsuppgifterna proaktivt, till exempel lösenord och certifikat.

Testa REST-API:er

När det gäller återhämtning måste testning av REST-API:er omfatta verifiering av – HTTP-koder, svarsnyttolast, huvuden och prestanda. Testning bör inte bara innehålla test av lyckade sökvägar, utan även kontrollera om API:et hanterar problemscenarier på ett korrekt sätt.

Testa API:er

Vi rekommenderar att testplanen innehåller omfattande API-tester. Om du planerar för en kommande ökning på grund av befordran eller semestertrafik måste du ändra belastningstestningen med de nya uppskattningarna. Utför belastningstestning av dina API:er och Content Delivery Network (CDN) i en utvecklarmiljö och inte i produktion.