Dela via

Säkerhetsram: Autentisering | Mitigations

  • Artikel
Produkt/tjänst Artikel
Webbprogram
Databas
Azure Event Hubs
Azure Trust Boundary
Förtroendegräns för Service Fabric
Identitetsserver
Gränsen för datorförtroende
WCF
Webb-API
Microsoft Entra ID
IoT-fältgateway
IoT Cloud Gateway
Azure Storage

Överväg att använda en standardautentiseringsmekanism för att autentisera till webbprogram

Title Details
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Ej tillämpligt
Referenser Ej tillämpligt
Details

Autentisering är den process där en entitet bevisar sin identitet, vanligtvis via autentiseringsuppgifter, till exempel användarnamn och lösenord. Det finns flera tillgängliga autentiseringsprotokoll som kan övervägas. Några av dem visas nedan:

  • Klientcertifikat
  • Windows-baserad
  • Formulärbaserade
  • Federation – ADFS
  • Federation – Microsoft Entra-ID
  • Federation – identitetsserver

Överväg att använda en standardautentiseringsmekanism för att identifiera källprocessen

Program måste hantera misslyckade autentiseringsscenarier på ett säkert sätt

Title Details
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Ej tillämpligt
Referenser Ej tillämpligt
Details

Program som uttryckligen autentiserar användare måste hantera misslyckade autentiseringsscenarier på ett säkert sätt. Autentiseringsmekanismen måste:

  • Neka åtkomst till privilegierade resurser när autentiseringen misslyckas
  • Visa ett allmänt felmeddelande när misslyckad autentisering och nekad åtkomst inträffar

Test för:

  • Skydd av privilegierade resurser efter misslyckade inloggningar
  • Ett allmänt felmeddelande visas vid misslyckad autentisering och nekad åtkomst till händelser
  • Konton inaktiveras efter ett överdrivet antal misslyckade försök

    Aktivera stegvis eller anpassningsbar autentisering

    Title Details
    Komponent Webbprogram
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Ej tillämpligt
    Details

    Kontrollera att programmet har ytterligare auktorisering (till exempel stegvis eller anpassningsbar autentisering via multifaktorautentisering, till exempel att skicka OTP i SMS, e-post osv. eller fråga om omautentisering) så att användaren utmanas innan den beviljas åtkomst till känslig information. Den här regeln gäller även för att göra viktiga ändringar i ett konto eller en åtgärd

    Detta innebär också att anpassningen av autentiseringen måste implementeras på ett sådant sätt att programmet korrekt framtvingar kontextkänslig auktorisering för att inte tillåta obehörig manipulering genom till exempel parametermanipulering

    Se till att de administrativa gränssnitten är korrekt låsta

    Title Details
    Komponent Webbprogram
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Ej tillämpligt
    Details Den första lösningen är att endast bevilja åtkomst från ett visst käll-IP-intervall till det administrativa gränssnittet. Om den lösningen inte skulle vara möjlig rekommenderar vi alltid att du framtvingar en stegvis eller anpassningsbar autentisering för att logga in i det administrativa gränssnittet

    Implementera funktioner för glömt lösenord på ett säkert sätt

    Title Details
    Komponent Webbprogram
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Ej tillämpligt
    Details

    Det första är att kontrollera att glömt lösenord och andra återställningsvägar skickar en länk, inklusive en tidsbegränsad aktiveringstoken i stället för själva lösenordet. Ytterligare autentisering baserad på mjuka token (t.ex. SMS-token, interna mobilprogram osv.) kan också krävas innan länken skickas över. För det andra bör du inte låsa användarkontot medan processen med att skaffa ett nytt lösenord pågår.

    Detta kan leda till en Denial of Service-attack när en angripare beslutar sig för att avsiktligt låsa ut användarna med en automatiserad attack. För det tredje, när den nya lösenordsbegäran har angetts bör meddelandet du visar generaliseras för att förhindra att användarnamn räknas upp. För det fjärde bör du alltid inte tillåta användning av gamla lösenord och implementera en stark lösenordsprincip.

    Se till att lösenords- och kontoprincipen implementeras

    Title Details
    Komponent Webbprogram
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Ej tillämpligt
    Details

    Lösenords- och kontoprincip i enlighet med organisationens princip och bästa praxis bör implementeras.

    För att skydda mot brute-force och ordlistebaserad gissning: Stark lösenordsprincip måste implementeras för att säkerställa att användarna skapar komplexa lösenord (t.ex. 12 tecken minsta längd, alfanumeriska och specialtecken).

    Principer för kontoutelåsning kan implementeras på följande sätt:

    • Mjuk utelåsning: Det här kan vara ett bra alternativ för att skydda användarna mot råstyrkeattacker. När användaren till exempel anger ett felaktigt lösenord tre gånger kan programmet låsa kontot i en minut för att göra det mindre lönsamt för angriparen att fortsätta. Om du skulle implementera hårda utlåsningsutjämningar för det här exemplet skulle du uppnå en "DoS" genom att permanent låsa konton. Alternativt kan programmet generera en OTP (Engångslösenord) och skicka den out-of-band (via e-post, sms osv.) till användaren. En annan metod kan vara att implementera CAPTCHA när ett tröskelvärde för antalet misslyckade försök har nåtts.
    • Hård utelåsning: Den här typen av utelåsning bör tillämpas när du identifierar en användare som attackerar ditt program och motverkar dem genom att permanent låsa ut sitt konto tills ett svarsteam hade tid att göra sina undersökningar. Efter den här processen kan du bestämma dig för att ge användaren tillbaka sitt konto eller vidta ytterligare rättsliga åtgärder mot dem. Den här typen av metod hindrar angriparen från att ytterligare penetrera ditt program och din infrastruktur.

    Om du vill skydda dig mot attacker på standardkonton och förutsägbara konton kontrollerar du att alla nycklar och lösenord är utbytbara och genereras eller ersätts efter installationen.

    Om programmet måste generera lösenord automatiskt kontrollerar du att de genererade lösenorden är slumpmässiga och har hög entropi.

    Implementera kontroller för att förhindra uppräkning av användarnamn

    Title Details
    Komponent Webbprogram
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Ej tillämpligt
    Steg Alla felmeddelanden bör generaliseras för att förhindra användarnamnuppräkning. Ibland kan du inte heller undvika att information läcker i funktioner som en registreringssida. Här måste du använda hastighetsbegränsningsmetoder som CAPTCHA för att förhindra en automatiserad attack av en angripare.

    När det är möjligt använder du Windows-autentisering för att ansluta till SQL Server

    Title Details
    Komponent Databas
    SDL-fas Skapa
    Tillämpliga tekniker Lokal
    Attribut SQL-version – alla
    Referenser SQL Server – Välj ett autentiseringsläge
    Steg Windows-autentisering använder Kerberos säkerhetsprotokoll, tillhandahåller lösenordsprincipframtvingande när det gäller komplexitetsverifiering för starka lösenord, ger stöd för kontoutelåsning och stöder lösenordsförfallotid.

    När det är möjligt kan du använda Microsoft Entra-autentisering för Anslut till SQL Database

    Title Details
    Komponent Databas
    SDL-fas Skapa
    Tillämpliga tekniker SQL Azure
    Attribut SQL-version – V12
    Referenser Anslut till SQL Database med Hjälp av Microsoft Entra-autentisering
    Steg Lägsta version: Azure SQL Database V12 krävs för att tillåta Att Azure SQL Database använder Microsoft Entra-autentisering mot Microsoft Directory

    När SQL-autentiseringsläget används kontrollerar du att konto- och lösenordsprincipen tillämpas på SQL Server

    Title Details
    Komponent Databas
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser SQL Server-lösenordsprincip
    Steg När du använder SQL Server-autentisering skapas inloggningar i SQL Server som inte baseras på Windows-användarkonton. Både användarnamnet och lösenordet skapas med hjälp av SQL Server och lagras i SQL Server. SQL Server kan använda mekanismer för Windows-lösenordsprinciper. Den kan tillämpa samma komplexitets- och förfalloprinciper som används i Windows på lösenord som används i SQL Server.

    Använd inte SQL-autentisering i inneslutna databaser

    Title Details
    Komponent Databas
    SDL-fas Skapa
    Tillämpliga tekniker Lokalt, SQL Azure
    Attribut SQL-version – MSSQL2012, SQL-version – V12
    Referenser Metodtips för säkerhet med inneslutna databaser
    Steg Avsaknaden av en tillämpad lösenordsprincip kan öka sannolikheten för att en svag autentiseringsuppgift upprättas i en innesluten databas. Utnyttja Windows-autentisering.

    Använda autentiseringsuppgifter per enhet med SaS-token

    Title Details
    Komponent Azure Event Hubs
    SDL-fas Skapa
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Översikt över Event Hubs-autentisering och säkerhetsmodell
    Steg

    Händelsehubbens säkerhetsmodell baseras på en kombination av SAS-token (Signatur för delad åtkomst) och händelseutgivare. Utgivarens namn representerar det DeviceID som tar emot token. Detta skulle hjälpa dig att associera token som genererats med respektive enheter.

    Alla meddelanden taggas med originator på tjänstsidan som möjliggör identifiering av förfalskningsförsök i nyttolast. När du autentiserar enheter genererar du en SaS-token per enhet som är begränsad till en unik utgivare.

    Aktivera Microsoft Entra-multifaktorautentisering för Azure-administratörer

    Title Details
    Komponent Azure Trust Boundary
    SDL-fas Distribution
    Tillämpliga tekniker Allmän
    Attribut Ej tillämpligt
    Referenser Vad är Microsoft Entra multifaktorautentisering?
    Steg

    multifaktorautentisering (MFA) är en autentiseringsmetod som kräver mer än en verifieringsmetod och lägger till ett kritiskt andra säkerhetslager för användarinloggningar och transaktioner. Det fungerar genom att kräva två eller flera av följande verifieringsmetoder:

    • Något du känner till (vanligtvis ett lösenord)
    • Något du har (en betrodd enhet som inte är lätt att duplicera, som en telefon)
    • Något du är (biometrisk)

      Begränsa anonym åtkomst till Service Fabric-kluster

      Title Details
      Komponent Förtroendegräns för Service Fabric
      SDL-fas Distribution
      Tillämpliga tekniker Allmän
      Attribut Miljö – Azure
      Referenser Säkerhetsscenarier för Service Fabric-kluster
      Steg

      Kluster bör alltid skyddas för att förhindra att obehöriga användare ansluter till klustret, särskilt när produktionsarbetsbelastningar körs på det.

      När du skapar ett Service Fabric-kluster kontrollerar du att säkerhetsläget är inställt på "säkert" och konfigurerar det nödvändiga X.509-servercertifikatet. Om du skapar ett "osäkert" kluster kan alla anonyma användare ansluta till det om de exponerar hanteringsslutpunkter för det offentliga Internet.

      Kontrollera att Service Fabric-certifikatet från klient till nod skiljer sig från nod-till-nod-certifikat

      Title Details
      Komponent Förtroendegräns för Service Fabric
      SDL-fas Distribution
      Tillämpliga tekniker Allmän
      Attribut Miljö – Azure, Miljö – Fristående
      Referenser Service Fabric-certifikatsäkerhet från klient till nod Anslut till ett säkert kluster med klientcertifikat
      Steg

      Säkerhet för klient-till-nod-certifikat konfigureras när klustret skapas antingen via Azure-portalen, Resource Manager-mallar eller en fristående JSON-mall genom att ange ett administratörsklientcertifikat och/eller ett användarklientcertifikat.

      De administratörsklient- och användarklientcertifikat som du anger bör skilja sig från de primära och sekundära certifikat som du anger för nod-till-nod-säkerhet.

      Använda Microsoft Entra-ID för att autentisera klienter till Service Fabric-kluster

      Title Details
      Komponent Förtroendegräns för Service Fabric
      SDL-fas Distribution
      Tillämpliga tekniker Allmän
      Attribut Miljö – Azure
      Referenser Klustersäkerhetsscenarier – Rekommendationer
      Steg Kluster som körs i Azure kan också skydda åtkomsten till hanteringsslutpunkterna med hjälp av Microsoft Entra-ID, förutom klientcertifikat. För Azure-kluster rekommenderar vi att du använder Microsoft Entra-säkerhet för att autentisera klienter och certifikat för nod-till-nod-säkerhet.

      Se till att Service Fabric-certifikat hämtas från en godkänd certifikatutfärdare (CA)

      Title Details
      Komponent Förtroendegräns för Service Fabric
      SDL-fas Distribution
      Tillämpliga tekniker Allmän
      Attribut Miljö – Azure
      Referenser X.509-certifikat och Service Fabric
      Steg

      Service Fabric använder X.509-servercertifikat för autentisering av noder och klienter.

      Några viktiga saker att tänka på när du använder certifikat i Service Fabrics:

      • Certifikat som används i kluster som kör produktionsarbetsbelastningar bör skapas med hjälp av en korrekt konfigurerad Windows Server-certifikattjänst eller hämtas från en godkänd certifikatutfärdare (CA). Ca:en kan vara en godkänd extern ca eller en korrekt hanterad intern offentlig nyckelinfrastruktur (PKI)
      • Använd aldrig några temporära certifikat eller testcertifikat i produktion som skapas med verktyg som MakeCert.exe
      • Du kan använda ett självsignerat certifikat, men bör bara göra det för testkluster och inte i produktion

      Använda standardautentiseringsscenarier som stöds av Identity Server

      Title Details
      Komponent Identitetsserver
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser IdentityServer3 – helheten
      Steg

      Nedan visas de vanliga interaktioner som stöds av Identity Server:

      • Webbläsare kommunicerar med webbprogram
      • Webbprogram kommunicerar med webb-API:er (ibland på egen hand, ibland för en användares räkning)
      • Webbläsarbaserade program kommunicerar med webb-API:er
      • Interna program kommunicerar med webb-API:er
      • Serverbaserade program kommunicerar med webb-API:er
      • Webb-API:er kommunicerar med webb-API:er (ibland på egen hand, ibland för en användares räkning)

      Åsidosätt standardcacheminnet för identitetsservertoken med ett skalbart alternativ

      Title Details
      Komponent Identitetsserver
      SDL-fas Distribution
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Distribution av identitetsserver – Cachelagring
      Steg

      IdentityServer har en enkel inbyggd minnesintern cache. Även om detta är bra för inbyggda appar i liten skala skalas det inte för program på mellannivå och serverdel av följande skäl:

      • Dessa program används av många användare samtidigt. Att spara alla åtkomsttoken i samma butik skapar isoleringsproblem och innebär utmaningar när de körs i stor skala: många användare, var och en med lika många token som de resurser som appen har åtkomst till för deras räkning, kan innebära enorma antal och mycket dyra uppslagsåtgärder
      • Dessa program distribueras vanligtvis på distribuerade topologier, där flera noder måste ha åtkomst till samma cache
      • Cachelagrade token måste överleva processåtervinnningar och inaktiveringar
      • Av alla ovanstående skäl rekommenderar vi att du åsidosätter standard-Identity Server-tokencache med ett skalbart alternativ som Azure Cache for Redis när du implementerar webbappar

      Kontrollera att det distribuerade programmets binärfiler är digitalt signerade

      Title Details
      Komponent Gränsen för datorförtroende
      SDL-fas Distribution
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Ej tillämpligt
      Steg Kontrollera att det distribuerade programmets binärfiler är digitalt signerade så att binärfilernas integritet kan verifieras

      Aktivera autentisering vid anslutning till MSMQ-köer i WCF

      Title Details
      Komponent WCF
      SDL-fas Skapa
      Tillämpliga tekniker Generic, NET Framework 3
      Attribut Ej tillämpligt
      Referenser MSDN
      Steg Programmet kan inte aktivera autentisering vid anslutning till MSMQ-köer, en angripare kan anonymt skicka meddelanden till kön för bearbetning. Om autentisering inte används för att ansluta till en MSMQ-kö som används för att leverera ett meddelande till ett annat program kan en angripare skicka ett anonymt meddelande som är skadligt.

      Exempel

      Elementet <netMsmqBinding/> i WCF-konfigurationsfilen nedan instruerar WCF att inaktivera autentisering vid anslutning till en MSMQ-kö för meddelandeleverans.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Konfigurera MSMQ för att kräva Windows-domän eller certifikatautentisering hela tiden för inkommande eller utgående meddelanden.

      Exempel

      Elementet <netMsmqBinding/> i WCF-konfigurationsfilen nedan instruerar WCF att aktivera certifikatautentisering vid anslutning till en MSMQ-kö. Klienten autentiseras med X.509-certifikat. Klientcertifikatet måste finnas i certifikatarkivet på servern.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      WCF-Ställ inte in Message clientCredentialType på ingen

      Title Details
      Komponent WCF
      SDL-fas Skapa
      Tillämpliga tekniker .NET Framework 3
      Attribut Typ av klientautentiseringsuppgifter – ingen
      Referenser MSDN, Fortify
      Steg Avsaknaden av autentisering innebär att alla kan komma åt den här tjänsten. En tjänst som inte autentiserar sina klienter ger åtkomst till alla användare. Konfigurera programmet för att autentisera mot klientautentiseringsuppgifter. Detta kan göras genom att ställa in meddelandet clientCredentialType till Windows eller Certifikat.

      Exempel

      <message clientCredentialType=""Certificate""/>

      WCF-Ställ inte in Transport clientCredentialType på ingen

      Title Details
      Komponent WCF
      SDL-fas Skapa
      Tillämpliga tekniker Generic, .NET Framework 3
      Attribut Typ av klientautentiseringsuppgifter – ingen
      Referenser MSDN, Fortify
      Steg Avsaknaden av autentisering innebär att alla kan komma åt den här tjänsten. En tjänst som inte autentiserar sina klienter ger alla användare åtkomst till dess funktioner. Konfigurera programmet för att autentisera mot klientautentiseringsuppgifter. Detta kan göras genom att ange transportklientenCredentialType till Windows eller Certifikat.

      Exempel

      <transport clientCredentialType=""Certificate""/>

      Se till att standardautentiseringstekniker används för att skydda webb-API:er

      Title Details
      Komponent Webb-API
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Autentisering och auktorisering i ASP.NET webb-API, externa autentiseringstjänster med ASP.NET webb-API (C#)
      Steg

      Autentisering är den process där en entitet bevisar sin identitet, vanligtvis via autentiseringsuppgifter, till exempel användarnamn och lösenord. Det finns flera tillgängliga autentiseringsprotokoll som kan övervägas. Några av dem visas nedan:

      • Klientcertifikat
      • Windows-baserad
      • Formulärbaserade
      • Federation – ADFS
      • Federation – Microsoft Entra-ID
      • Federation – identitetsserver

      Länkar i referensavsnittet innehåller information på låg nivå om hur vart och ett av autentiseringsschemana kan implementeras för att skydda ett webb-API.

      Använda standardautentiseringsscenarier som stöds av Microsoft Entra-ID

      Title Details
      Komponent Microsoft Entra ID
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Autentiseringsscenarier för Microsoft Entra-ID, Microsoft Entra-kodexempel, Microsoft Entra-utvecklarguide
      Steg

      Microsoft Entra ID förenklar autentiseringen för utvecklare genom att tillhandahålla identitet som en tjänst, med stöd för branschstandardprotokoll som OAuth 2.0 och OpenID Anslut. Nedan visas de fem primära programscenarier som stöds av Microsoft Entra-ID:

      • Webbläsare till webbprogram: En användare måste logga in på ett webbprogram som skyddas av Microsoft Entra-ID
      • Enkelsidigt program (SPA): En användare måste logga in på ett ensidesprogram som skyddas av Microsoft Entra-ID
      • Internt program till webb-API: Ett internt program som körs på en telefon, surfplatta eller dator måste autentisera en användare för att hämta resurser från ett webb-API som skyddas av Microsoft Entra-ID
      • Webbprogram till webb-API: Ett webbprogram måste hämta resurser från ett webb-API som skyddas av Microsoft Entra-ID
      • Daemon- eller serverprogram till webb-API: Ett daemonprogram eller ett serverprogram utan webbanvändargränssnitt behöver hämta resurser från ett webb-API som skyddas av Microsoft Entra-ID

      Se länkarna i referensavsnittet för information om implementering på låg nivå

      Åsidosätt standardcacheminnet för MSAL-token med ett distribuerat cacheminne

      Title Details
      Komponent Microsoft Entra ID
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Serialisering av tokencache i MSAL.NET
      Steg

      Standardcachen som MSAL (Microsoft Authentication Library) använder är en minnesintern cache och är skalbar. Det finns dock olika alternativ som du kan använda som ett alternativ, till exempel en distribuerad tokencache. Dessa har L1/L2-mekanismer, där L1 finns i minnet och L2 är implementeringen av distribuerad cache. Dessa kan därför konfigureras för att begränsa L1-minne, kryptera eller ange borttagningsprinciper. Andra alternativ är Redis, SQL Server eller Azure Comsos DB-cacheminnen. En implementering av en distribuerad tokencache finns i följande självstudie: Kom igång med ASP.NET Core MVC.

      Se till att TokenReplayCache används för att förhindra återuppspelning av MSAL-autentiseringstoken

      Title Details
      Komponent Microsoft Entra ID
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Modern autentisering med Microsoft Entra-ID för webbprogram
      Steg

      Egenskapen TokenReplayCache gör det möjligt för utvecklare att definiera en tokenrepriscache, ett arkiv som kan användas för att spara token i syfte att verifiera att ingen token kan användas mer än en gång.

      Det här är ett mått mot en vanlig attack, den passande kallas tokenrepjäsattack: en angripare som fångar upp token som skickas vid inloggningen kan försöka skicka den till appen igen ("spela upp" den) för att upprätta en ny session. I OIDC-kodbeviljande flöde görs en begäran till slutpunkten "/signin-oidc" för den förlitande parten efter lyckad användarautentisering med parametrarna "id_token", "code" och "state".

      Den förlitande parten validerar denna begäran och upprättar en ny session. Om en angripare samlar in den här begäran och spelar upp den igen kan han/hon upprätta en lyckad session och förfalska användaren. Förekomsten av nonce i OpenID Anslut kan begränsa men inte helt eliminera de omständigheter under vilka attacken kan genomföras. För att skydda sina program kan utvecklare tillhandahålla en implementering av ITokenReplayCache och tilldela en instans till TokenReplayCache.

      Exempel

      // ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

      Exempel

      Här är en exempelimplementering av gränssnittet ITokenReplayCache. (Anpassa och implementera ditt projektspecifika ramverk för cachelagring)

      public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

      Den implementerade cachen måste refereras i OIDC-alternativ via egenskapen "TokenValidationParameters" enligt följande.

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

      Observera att om du vill testa effektiviteten i den här konfigurationen loggar du in på ditt lokala OIDC-skyddade program och samlar in begäran till "/signin-oidc" slutpunkten i fiddler. När skyddet inte är på plats kommer en ny sessionscookie att spelas upp om den här begäran i Fiddler. När begäran spelas upp igen efter att TokenReplayCache-skyddet har lagts till utlöser programmet ett undantag på följande sätt: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      Använda MSAL-bibliotek för att hantera tokenbegäranden från OAuth2-klienter till Microsoft Entra-ID (eller lokal AD)

      Title Details
      Komponent Microsoft Entra ID
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser MSAL
      Steg

      Med Microsoft Authentication Library (MSAL) kan utvecklare hämta säkerhetstoken från Microsofts identitetsplattform för att autentisera användare och få åtkomst till skyddade webb-API:er. Det kan användas för att ge säker åtkomst till Microsoft Graph, andra Microsoft-API:er, webb-API:er från tredje part eller ditt eget webb-API. MSAL stöder många olika programarkitekturer och plattformar, inklusive .NET, JavaScript, Java, Python, Android och iOS.

      MSAL ger dig många sätt att hämta token, med ett konsekvent API för många plattformar. Det finns inget behov av att direkt använda OAuth-biblioteken eller koden mot protokollet i ditt program och kan hämta token för en användares eller programs räkning (när det är tillämpligt för plattformen).

      MSAL underhåller även en tokencache och uppdaterar token åt dig när de är nära att upphöra att gälla. MSAL kan också hjälpa dig att ange vilken målgrupp du vill att programmet ska logga in på och hjälpa dig att konfigurera programmet från konfigurationsfiler och felsöka din app.

      Autentisera enheter som ansluter till fältgatewayen

      Title Details
      Komponent IoT-fältgateway
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Ej tillämpligt
      Steg Se till att varje enhet autentiseras av Field Gateway innan du tar emot data från dem och innan du underlättar uppströmskommunikation med Cloud Gateway. Se också till att enheterna ansluter med autentiseringsuppgifter per enhet så att enskilda enheter kan identifieras unikt.

      Se till att enheter som ansluter till molngatewayen autentiseras

      Title Details
      Komponent IoT Cloud Gateway
      SDL-fas Skapa
      Tillämpliga tekniker Generic, C#, Node.JS,
      Attribut Val av nätverksgateway – Azure IoT Hub
      Referenser N/A, Azure IoT Hub med .NET, Komma igång med IoT Hub och Node JS, Skydda IoT med SAS och certifikat, Git-lagringsplats
      Steg
      • Allmänt: Autentisera enheten med TLS (Transport Layer Security) eller IPSec. Infrastrukturen bör stödja användning av i förväg delad nyckel (PSK) på de enheter som inte kan hantera fullständig asymmetrisk kryptografi. Utnyttja Microsoft Entra ID, Oauth.
      • C#: När du skapar en DeviceClient-instans skapar metoden Skapa som standard en DeviceClient-instans som använder AMQP-protokollet för att kommunicera med IoT Hub. Om du vill använda HTTPS-protokollet använder du åsidosättningen av Create-metoden som gör att du kan ange protokollet. Om du använder HTTPS-protokollet bör du också lägga till Microsoft.AspNet.WebApi.Client NuGet-paketet i projektet för att inkludera System.Net.Http.Formatting namnområdet.

      Exempel

      static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

      Exempel

      Node.JS: Autentisering

      Symmetrisk nyckel

      • Skapa en IoT-hubb i Azure
      • Skapa en post i enhetsidentitetsregistret 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Skapa en simulerad enhet 
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
var client = clientFromConnectionString(connectionString);

        SAS-token

      • Genereras internt när du använder symmetrisk nyckel, men vi kan generera och använda den explicit också
      • Definiera ett protokoll : var Http = require('azure-iot-device-http').Http;
      • Skapa en sas-token : 
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<deviceName >";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
      • Anslut med hjälp av sas-token:
        Client.fromSharedAccessSignature(sas, Http);

        Certifikat

      • Generera ett självsignerat X509-certifikat med alla verktyg som OpenSSL för att generera ett .cert- och .key-filer för att lagra certifikatet respektive nyckeln
      • Etablera en enhet som accepterar säker anslutning med hjälp av certifikat. 
        var connectionString = '<connectionString>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<deviceId>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<PrimaryThumbprint>",
    secondaryThumbprint: "<SecondaryThumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});
      • Anslut en enhet med ett certifikat
        var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

      Använda autentiseringsuppgifter per enhet

      Title Details
      Komponent IoT Cloud Gateway
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Gatewayval – Azure IoT Hub
      Referenser Säkerhetstoken för Azure IoT Hub
      Steg Använd autentiseringsuppgifter per enhet med SaS-token baserat på enhetsnyckel eller klientcertifikat, i stället för principer för delad åtkomst på IoT Hub-nivå. Detta förhindrar återanvändning av autentiseringstoken för en enhet eller fältgateway av en annan

      Se till att endast de nödvändiga containrarna och blobarna får anonym läsåtkomst

      Title Details
      Komponent Azure Storage
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut StorageType – blob
      Referenser Hantera anonym läsåtkomst till containrar och blobar, signaturer för delad åtkomst, del 1: Förstå SAS-modellen
      Steg

      Som standard kan en container och eventuella blobar i den endast nås av lagringskontots ägare. Om du vill ge anonyma användare läsbehörighet till en container och dess blobar kan man ange containerbehörigheter för att tillåta offentlig åtkomst. Anonyma användare kan läsa blobar i en offentligt tillgänglig container utan att autentisera begäran.

      Containrar tillhandahåller följande alternativ för att hantera containeråtkomst:

      • Fullständig offentlig läsåtkomst: Container- och blobdata kan läsas via anonym begäran. Klienter kan räkna upp blobar i containern via anonym begäran, men kan inte räkna upp containrar i lagringskontot.
      • Endast offentlig läsåtkomst för blobar: Blobdata i den här containern kan läsas via anonym begäran, men containerdata är inte tillgängliga. Klienter kan inte räkna upp blobar i containern via anonym begäran
      • Ingen offentlig läsåtkomst: Container- och blobdata kan endast läsas av kontoägaren

      Anonym åtkomst är bäst för scenarier där vissa blobar alltid ska vara tillgängliga för anonym läsåtkomst. För finare kontroll kan man skapa en signatur för delad åtkomst som gör det möjligt att delegera begränsad åtkomst med olika behörigheter och under ett angivet tidsintervall. Se till att containrar och blobar, som potentiellt kan innehålla känsliga data, inte får anonym åtkomst av misstag

      Bevilja begränsad åtkomst till objekt i Azure Storage med hjälp av SAS eller SAP

      Title Details
      Komponent Azure Storage
      SDL-fas Skapa
      Tillämpliga tekniker Allmän
      Attribut Ej tillämpligt
      Referenser Signaturer för delad åtkomst, del 1: Förstå SAS-modellen, signaturer för delad åtkomst, del 2: Skapa och använda en SAS med Blob Storage, Delegera åtkomst till objekt i ditt konto med hjälp av signaturer för delad åtkomst och principer för lagrad åtkomst
      Steg

      Att använda en signatur för delad åtkomst (SAS) är ett kraftfullt sätt att bevilja begränsad åtkomst till objekt i ett lagringskonto till andra klienter, utan att behöva exponera kontoåtkomstnyckeln. SAS är en URI som i sina frågeparametrar innehåller all information som krävs för autentiserad åtkomst till en lagringsresurs. För att få åtkomst till lagringsresurser med SAS behöver klienten bara skicka in SAS till lämplig konstruktor eller metod.

      Du kan använda en SAS när du vill ge åtkomst till resurser i ditt lagringskonto till en klient som inte kan lita på kontonyckeln. Dina lagringskontonycklar innehåller både en primär och sekundär nyckel, som båda ger administrativ åtkomst till ditt konto och alla resurser i det. Om du exponerar någon av dina kontonycklar öppnas ditt konto för risken för skadlig eller försumlig användning. Signaturer för delad åtkomst är ett säkert alternativ som gör att andra klienter kan läsa, skriva och ta bort data i ditt lagringskonto enligt de behörigheter som du har beviljat och utan att behöva kontonyckeln.

      Om du har en logisk uppsättning parametrar som liknar varandra varje gång är det en bättre idé att använda en SAP (Stored Access Policy). Eftersom användning av en SAS som härletts från en princip för lagrad åtkomst ger dig möjlighet att återkalla sas omedelbart, är det den rekommenderade bästa praxisen att alltid använda lagrade åtkomstprinciper när det är möjligt.