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

  • Artikel

I den här artikeln kan du dra nytta av vår erfarenhet av att arbeta med stora kunder. Du kan överväga dessa rekommendationer för utformning och implementering av dina tjänster.

Microsoft-autentiseringsbibliotek

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

Utvecklare kan använda 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. Använd i stället väletablerade bibliotek.

Optimera katalogläsningar och skrivningar

Azure AD B2C-katalogtjänsten stöder miljarder autentiseringar per dag, med 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: Undvik att köra 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. Kräver ingen skrivning vid varje inloggning. Förhandsvillkor för en användarresa är:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Förstå begränsning: Katalogen implementerar begränsningsregler på program- och klientnivå. Det finns fler hastighetsbegränsningar för åtgärderna Läs/GET, Skriv/POST, Uppdatera/PUT och Ta bort/TA BORT. Varje åtgärd har olika gränser.

    • En skrivning under inloggningen faller under en POST för nya användare eller PUT för aktuella användare.
    • En anpassad princip som skapar eller uppdaterar en användare vid varje inloggning kan 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). Testa Azure AD B2C-systemet och ditt program för högsta trafik. 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 tiden för att slutföra användarmigreringen. 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. Se till att den förblir 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 säkerställa att ingen begränsning på klientorganisationsnivå och resurssvält för ditt liveprogram. 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 AD B2C-tjänsten.

Livslängd för token

Om Azure AD B2C-autentiseringstjänsten inte kan slutföra nya registreringar och inloggningar kan du åtgärda problemet för användare som är inloggade. Med konfigurationen kan användare som är inloggade använda programmet utan avbrott tills de loggar ut från programmet eller sessionen överskrider tidsgränsen för inaktivitet.

Dina affärskrav och slutanvändarupplevelsen avgör frekvensen för tokenuppdatering för webb- och ensidesprogram (SPA).

Utöka livslängden för token

  • Webbprogram: För webbprogram där autentiseringstoken verifieras vid 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 förnyas baserat på användaraktivitet. Om det uppstår ett långvarigt tokenutfärdande kan dessa sessionstider ökas 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. För SPA:er rekommenderar vi att du använder auktoriseringskodflödet med PKCE-flödet (Proof Key for Code Exchange) som ett alternativ för att tillåta att användaren fortsätter att använda programmet. Om ditt SPA använder implicit flöde kan du överväga att migrera till auktoriseringskodflödet med PKCE. Migrera ditt program från MSAL.js 1.x till MSAL.js 2.x för att realisera återhämtning för webbprogram. Det implicita flödet resulterar inte i en uppdateringstoken. SPA kan använda en dold iframe för att utföra nya tokenbegäranden mot auktoriseringsslutpunkten om webbläsaren har en aktiv session med Azure AD B2C. För SPA:er finns det några alternativ för att tillåta att användaren fortsätter att använda programmet.
    • Utöka varaktigheten för åtkomsttokens giltighet.
    • 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 auktoriseringskodbeviljande, baserat på en princip, och autentiserar användaren. Autentiseringssessionen mellan API-gatewayen och klienten underhålls med hjälp av en autentiseringscookie. API-gatewayen servar API:erna med hjälp av den token som hämtas av API-gatewayen eller en annan direktautentiseringsmetod, till exempel certifikat, klientautentiseringsuppgifter eller API-nycklar.
    • Växla till det rekommenderade alternativet. 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).
    • För mobila program utökar du livslängden för uppdaterings- och åtkomsttoken.
  • Serverdels- eller mikrotjänstprogram: Serverdelsprogram (daemon) är icke-interaktiva och är inte i användarkontext, därför minskar risken för tokenstöld. Vår rekommendation är att hitta en balans mellan säkerhet och livslängd och ange en lång tokenlivslängd.

Enkel inloggning

Med enkel inloggning (SSO) loggar användarna in en gång med ett konto och får åtkomst till program: en webb, mobil eller ett ensidesprogram (SPA), oavsett plattform eller domännamn. När användaren 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. 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.

Konfigurera enkel inloggning

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

Säkra distributionsmetoder

De vanligaste tjänststörningarna är kod- och konfigurationsändringar. Implementering av processer och verktyg för kontinuerlig integrering och kontinuerlig leverans (CICD) möjliggör distribution i stor skala och minskar mänskliga fel under testning och distribution. Anta CICD för felminskning, effektivitet och konsekvens. Azure Pipelines är ett exempel på CICD.

Skydd mot robotar

Skydda dina program mot kända sårbarheter, till exempel DDoS-attacker (Distributed Denial of Service), SQL-inmatningar, skript mellan webbplatser, fjärrkörning av kod och andra som dokumenteras i OWASP Top-10. Distribuera en brandvägg för webbaserade program (WAF) för att skydda mot vanliga sårbarheter och sårbarheter.

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) refererar till tidsintervallet för nyckelauktorisering, som används av legitima entiteter, som en kryptoperiod. Välj den nödvändiga längden på kryptoperioder. Ange förfallodatum och rotera hemligheter innan de upphör att gälla.

Implementera 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 nycklar och certifikat som konfigurerats i Azure AD B2C. Den här listan kan innehålla nycklar som används i anpassade principer, API:er, signerings-ID-token och certifikat för SAML (Security Assertion Markup Language).
  • Använd CICD och rotera hemligheter som 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 autentiseringsuppgifterna för API-åtkomst, till exempel lösenord och certifikat.

REST API-testning

För återhämtning måste REST API:er-testning inkludera verifiering av HTTP-koder, svarsnyttolast, huvuden och prestanda. Använd inte bara test av lyckade sökvägar och bekräfta att API:et hanterar problemscenarier på ett korrekt sätt.

Testplan

Vi rekommenderar att testplanen innehåller omfattande API-tester. För ökningar på grund av en befordran, eller semestertrafik, ändrar du belastningstestning med nya uppskattningar. Utför API-belastningstestning och Content Delivery Network (CDN) i en utvecklarmiljö, inte i produktion.

Nästa steg