Rámec zabezpečení: Ověřování | Zmírnění rizik

  • Článek
Produkt/služba Článek
Webová aplikace
Databáze
Azure Event Hub
Hranice důvěryhodnosti Azure
Hranice důvěryhodnosti Service Fabric
Server identit
Hranice důvěryhodnosti počítače
WCF
Webové rozhraní API
Microsoft Entra ID
IoT Field Gateway
Cloudová brána IoT
Azure Storage

Zvažte použití standardního ověřovacího mechanismu k ověření ve webové aplikaci.

Nadpis Detaily
Součást Webová aplikace
Fáze SDL Sestavení
Použitelné technologie Obecná
Atributy –
Odkazy –
Detaily

Ověřování je proces, kdy entita prokáže svou identitu, obvykle prostřednictvím přihlašovacích údajů, jako je uživatelské jméno a heslo. K dispozici je několik ověřovacích protokolů, které je možné zvážit. Některé z nich jsou uvedené níže:

  • Klientské certifikáty
  • Windows
  • Formuláře založené na formulářích
  • Federace – ADFS
  • Federace – Microsoft Entra ID
  • Federace – Server identit

Zvažte použití standardního ověřovacího mechanismu k identifikaci zdrojového procesu.

Aplikace musí bezpečně zpracovávat neúspěšné scénáře ověřování.

Nadpis Detaily
Součást Webová aplikace
Fáze SDL Sestavení
Použitelné technologie Obecná
Atributy –
Odkazy –
Detaily

Aplikace, které explicitně ověřují uživatele, musí bezpečně zpracovávat neúspěšné scénáře ověřování. Ověřovací mechanismus musí:

  • Odepření přístupu k privilegovaným prostředkům v případě selhání ověřování
  • Zobrazení obecné chybové zprávy po neúspěšném ověření a odepření přístupu

Test pro:

  • Ochrana privilegovaných prostředků po neúspěšných přihlášeních
  • Obecná chybová zpráva se zobrazí u neúspěšného ověřování a událostí odepření přístupu.
  • Účty jsou zakázané po nadměrném počtu neúspěšných pokusů.

    Povolení krokování nebo adaptivního ověřování

    Nadpis Detaily
    Součást Webová aplikace
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy –
    Detaily

    Ověřte, že aplikace má další autorizaci (například krokování nebo adaptivní ověřování, prostřednictvím vícefaktorového ověřování, jako je odeslání jednorázového hesla v SMS, e-mailu atd.) nebo výzva k opětovnému ověření, aby se uživateli zobrazila výzva před udělením přístupu k citlivým informacím. Toto pravidlo platí také pro provádění důležitých změn účtu nebo akce.

    To také znamená, že přizpůsobení ověřování musí být implementováno takovým způsobem, že aplikace správně vynucuje autorizaci citlivou na kontext, aby například nepovolila neoprávněnou manipulaci pomocí manipulace s parametry.

    Ujistěte se, že jsou rozhraní pro správu správně uzamčená.

    Nadpis Detaily
    Součást Webová aplikace
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy –
    Detaily Prvním řešením je udělit přístup pouze z určitého zdrojového rozsahu IP adres rozhraní pro správu. Pokud by toto řešení nebylo možné, doporučujeme vždy vynutit podrobné nebo adaptivní ověřování pro přihlášení k rozhraní pro správu.

    Zabezpečená implementace zapomenutých funkcí hesel

    Nadpis Detaily
    Součást Webová aplikace
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy –
    Detaily

    První věcí je ověřit, že zapomenuté heslo a další cesty obnovení odešlou odkaz, včetně časově omezeného aktivačního tokenu, a ne samotného hesla. Další ověřování založené na soft tokenech (např. token SMS, nativní mobilní aplikace atd.) je možné vyžadovat i před odesláním odkazu. Za druhé byste neměli zamknout uživatelský účet, zatímco probíhá proces získání nového hesla.

    To může vést k útoku na dostupnost služby, kdykoli se útočník rozhodne záměrně uzamknout uživatele automatizovaným útokem. Za třetí, kdykoli byla nastavena nová žádost o heslo, měla by být zobrazená zpráva zobecněna, aby se zabránilo výčtu uživatelského jména. Začtvrté, vždy nepovolte používání starých hesel a implementujte silné zásady hesel.

    Ujistěte se, že jsou implementované zásady hesel a účtů.

    Nadpis Detaily
    Součást Webová aplikace
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy –
    Detaily

    Zásady hesel a účtů v souladu se zásadami organizace a osvědčenými postupy by se měly implementovat.

    Chcete-li se bránit proti hádání na základě hrubou silou a slovníku: Musí být implementovány zásady silného hesla, aby uživatelé vytvořili komplexní heslo (např. minimální délka 12 znaků, alfanumerické a speciální znaky).

    Zásady uzamčení účtu se můžou implementovat následujícím způsobem:

    • Měkké uzamčení: Tato možnost může být dobrou volbou pro ochranu uživatelů před útoky hrubou silou. Například pokaždé, když uživatel zadá nesprávné heslo třikrát, může aplikace po dobu minuty uzamknout účet, aby zpomalil proces vynucení hesla, aby útočník mohl pokračovat. Pokud byste v tomto příkladu implementovali pevně uzamčené protichůdné opatření, dosáhli byste "DoS" trvalým uzamčením účtů. Případně může aplikace vygenerovat jednorázové heslo (jednorázové heslo) a odeslat ho uživateli mimo pásmo (prostřednictvím e-mailu, sms atd.). Dalším přístupem může být implementace CAPTCHA po dosažení prahové hodnoty počtu neúspěšných pokusů.
    • Pevné uzamčení: Tento typ uzamčení by se měl použít vždy, když zjistíte, že uživatel napadá vaši aplikaci, a čítače pomocí trvalého uzamčení účtu, dokud tým odpovědí neměl čas provést forenzní akce. Po tomto procesu se můžete rozhodnout, že uživateli vrátíte svůj účet nebo proti nim provedete další právní kroky. Tento typ přístupu brání útočníkovi v dalším průniku vaší aplikace a infrastruktury.

    Pokud chcete bránit útokům na výchozí a předvídatelné účty, ověřte, že všechny klíče a hesla se dají nahradit a generují nebo nahrazují po instalaci.

    Pokud aplikace musí automaticky generovat hesla, ujistěte se, že generovaná hesla jsou náhodná a mají vysokou entropii.

    Implementace ovládacích prvků, které zabrání výčtu uživatelského jména

    Nadpis Detaily
    Součást Webová aplikace
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy –
    Kroky Všechny chybové zprávy by měly být generalizovány, aby se zabránilo výčtu uživatelského jména. Někdy se také nemůžete vyhnout úniku informací ve funkcích, jako je například registrační stránka. Tady potřebujete použít metody omezování rychlosti, jako je CAPTCHA, aby se zabránilo automatizovanému útoku útočníkem.

    Pokud je to možné, pro připojení k SQL Serveru použijte ověřování systému Windows.

    Nadpis Detaily
    Součást Databáze
    Fáze SDL Sestavení
    Použitelné technologie Místní
    Atributy Verze SQL – Vše
    Odkazy SQL Server – Volba režimu ověřování
    Kroky Ověřování systému Windows používá protokol zabezpečení Kerberos, poskytuje vynucení zásad hesel s ohledem na ověřování složitosti silných hesel, poskytuje podporu uzamčení účtu a podporuje vypršení platnosti hesla.

    Pokud je to možné, použijte ověřování Microsoft Entra pro připojení ke službě SQL Database

    Nadpis Detaily
    Součást Databáze
    Fáze SDL Sestavení
    Použitelné technologie SQL Azure
    Atributy Verze SQL – V12
    Odkazy Připojení ke službě SQL Database pomocí ověřování Microsoft Entra
    Kroky Minimální verze: Azure SQL Database verze 12 vyžadovaná k tomu, aby služba Azure SQL Database mohla používat ověřování Microsoft Entra vůči službě Microsoft Directory

    Při použití režimu ověřování SQL se ujistěte, že se na SQL Serveru vynucují zásady účtu a hesla.

    Nadpis Detaily
    Součást Databáze
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy Zásady hesel SQL Serveru
    Kroky Při použití ověřování SQL Serveru se na SQL Serveru vytvoří přihlášení, která nejsou založená na uživatelských účtech Systému Windows. Uživatelské jméno i heslo se vytvářejí pomocí SQL Serveru a ukládají se na SQL Serveru. SQL Server může používat mechanismy zásad hesla systému Windows. Může použít stejné zásady složitosti a vypršení platnosti, které se ve Windows používají pro hesla použitá v SQL Serveru.

    Nepoužívejte ověřování SQL v databázích s omezením

    Nadpis Detaily
    Součást Databáze
    Fáze SDL Sestavení
    Použitelné technologie Místní prostředí, SQL Azure
    Atributy Verze SQL – MSSQL2012, verze SQL – V12
    Odkazy Osvědčené postupy zabezpečení s databázemi s omezením
    Kroky Absence vynucených zásad hesel může zvýšit pravděpodobnost vytvoření slabých přihlašovacích údajů v obsažené databázi. Využijte ověřování systému Windows.

    Použití přihlašovacích údajů pro ověřování jednotlivých zařízení pomocí tokenů SaS

    Nadpis Detaily
    Součást Azure Event Hubs
    Fáze SDL Sestavení
    Použitelné technologie Obecná
    Atributy –
    Odkazy Přehled ověřování a modelu zabezpečení služby Event Hubs
    Kroky

    Model zabezpečení služby Event Hubs je založený na kombinaci tokenů sdíleného přístupového podpisu (SAS) a vydavatelů událostí. Název vydavatele představuje DEVICEID, který přijímá token. To by pomohlo přidružit tokeny vygenerované k příslušným zařízením.

    Všechny zprávy jsou označené původcem na straně služby, což umožňuje detekci pokusů o falšování identity v datové části. Při ověřování zařízení vygenerujte token SaS pro každé zařízení s vymezeným jedinečným vydavatelem.

    Povolení vícefaktorového ověřování Microsoft Entra pro správce Azure

    Nadpis Detaily
    Součást Hranice důvěryhodnosti Azure
    Fáze SDL Nasazení
    Použitelné technologie Obecná
    Atributy –
    Odkazy Co je vícefaktorové ověřování Microsoft Entra?
    Kroky

    vícefaktorové ověřování (MFA) je metoda ověřování, která vyžaduje více než jednu metodu ověřování a přidává kritickou druhou vrstvu zabezpečení k přihlašování a transakcím uživatelů. Funguje tak, že vyžaduje jakékoli dvě nebo více z následujících metod ověřování:

    • Něco, co znáte (obvykle heslo)
    • Něco, co máte (důvěryhodné zařízení, které se nedá snadno duplikovat, třeba telefon)
    • Něco, co jste (biometrické údaje)

      Omezení anonymního přístupu ke clusteru Service Fabric

      Nadpis Detaily
      Součást Hranice důvěryhodnosti Service Fabric
      Fáze SDL Nasazení
      Použitelné technologie Obecná
      Atributy Prostředí – Azure
      Odkazy Scénáře zabezpečení clusteru Service Fabric
      Kroky

      Clustery by měly být vždy zabezpečené, aby se zabránilo neoprávněným uživatelům v připojení k vašemu clusteru, zejména v případě, že na něm běží produkční úlohy.

      Při vytváření clusteru Service Fabric se ujistěte, že je režim zabezpečení nastavený na zabezpečení a nakonfigurujte požadovaný certifikát serveru X.509. Vytvoření "nezabezpečeného" clusteru umožní každému anonymnímu uživateli připojit se k němu, pokud zveřejní koncové body správy pro veřejný internet.

      Ujistěte se, že se certifikát typu klient-uzel Service Fabric liší od certifikátu typu node-to-node.

      Nadpis Detaily
      Součást Hranice důvěryhodnosti Service Fabric
      Fáze SDL Nasazení
      Použitelné technologie Obecná
      Atributy Prostředí – Azure, prostředí – Samostatné
      Odkazy Zabezpečení certifikátu typu klient-uzel Service Fabric, připojení k zabezpečenému clusteru pomocí klientského certifikátu
      Kroky

      Zabezpečení certifikátu typu klient-uzel se konfiguruje při vytváření clusteru prostřednictvím webu Azure Portal, šablon Resource Manageru nebo samostatné šablony JSON zadáním klientského certifikátu správce nebo klientského certifikátu uživatele.

      Zadané klientské certifikáty klienta správce a uživatele by se měly lišit od primárních a sekundárních certifikátů, které zadáte pro zabezpečení node-to-node.

      Ověřování klientů v clusterech Service Fabric pomocí ID Microsoft Entra

      Nadpis Detaily
      Součást Hranice důvěryhodnosti Service Fabric
      Fáze SDL Nasazení
      Použitelné technologie Obecná
      Atributy Prostředí – Azure
      Odkazy Scénáře zabezpečení clusteru – Doporučení zabezpečení
      Kroky Clustery spuštěné v Azure můžou také zabezpečit přístup ke koncovým bodům správy pomocí ID Microsoft Entra kromě klientských certifikátů. U clusterů Azure se doporučuje použít zabezpečení Microsoft Entra k ověřování klientů a certifikátů pro zabezpečení mezi uzly.

      Ujistěte se, že jsou certifikáty Service Fabric získány ze schválené certifikační autority (CA).

      Nadpis Detaily
      Součást Hranice důvěryhodnosti Service Fabric
      Fáze SDL Nasazení
      Použitelné technologie Obecná
      Atributy Prostředí – Azure
      Odkazy Certifikáty X.509 a Service Fabric
      Kroky

      Service Fabric používá certifikáty serveru X.509 pro ověřování uzlů a klientů.

      Při používání certifikátů v service fabrics je potřeba vzít v úvahu několik důležitých věcí:

      • Certifikáty používané v clusterech s produkčními úlohami by se měly vytvořit pomocí správně nakonfigurované certifikační služby systému Windows Server nebo získané ze schválené certifikační autority (CA). Certifikační autoritou může být schválená externí certifikační autorita nebo správně spravovaná interní infrastruktura veřejných klíčů (PKI).
      • Nikdy nepoužívejte žádné dočasné nebo testovací certifikáty v produkčním prostředí vytvořené pomocí nástrojů, jako jsou MakeCert.exe
      • Můžete použít certifikát podepsaný svým držitelem, ale měl by to udělat jenom pro testovací clustery a ne v produkčním prostředí.

      Použití standardních scénářů ověřování podporovaných serverem identit

      Nadpis Detaily
      Součást Server identit
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy IdentityServer3 – velký obrázek
      Kroky

      Níže jsou uvedené typické interakce podporované serverem identit:

      • Prohlížeče komunikují s webovými aplikacemi
      • Webové aplikace komunikují s webovými rozhraními API (někdy samy o sobě, někdy jménem uživatele).
      • Aplikace založené na prohlížeči komunikují s webovými rozhraními API
      • Nativní aplikace komunikují s webovými rozhraními API
      • Serverové aplikace komunikují s webovými rozhraními API
      • Webová rozhraní API komunikují s webovými rozhraními API (někdy samy o sobě, někdy jménem uživatele).

      Přepsání výchozí mezipaměti tokenů serveru identit škálovatelnou alternativou

      Nadpis Detaily
      Součást Server identit
      Fáze SDL Nasazení
      Použitelné technologie Obecná
      Atributy –
      Odkazy Nasazení serveru identit – ukládání do mezipaměti
      Kroky

      IdentityServer má jednoduchou integrovanou mezipaměť v paměti. I když je to vhodné pro nativní aplikace v malém měřítku, nešupupuje se pro střední vrstvu a back-endové aplikace z následujících důvodů:

      • K těmto aplikacím přistupuje mnoho uživatelů najednou. Uložení všech přístupových tokenů ve stejném úložišti vytváří problémy s izolací a představuje výzvy při provozu ve velkém: mnoho uživatelů, každý s tolika tokeny, kolik prostředků aplikace přistupuje jejich jménem, může znamenat obrovské počty a velmi nákladné operace vyhledávání.
      • Tyto aplikace jsou obvykle nasazené v distribuovaných topologiích, kde musí mít více uzlů přístup ke stejné mezipaměti.
      • Tokeny uložené v mezipaměti musí přežít recyklace a deaktivace procesů.
      • Z výše uvedených důvodů se při implementaci webových aplikací doporučuje přepsat výchozí mezipaměť tokenů serveru identit škálovatelnou alternativou, jako je Azure Cache for Redis.

      Ujistěte se, že jsou binární soubory nasazené aplikace digitálně podepsané.

      Nadpis Detaily
      Součást Hranice důvěryhodnosti počítače
      Fáze SDL Nasazení
      Použitelné technologie Obecná
      Atributy –
      Odkazy –
      Kroky Ujistěte se, že jsou binární soubory nasazené aplikace digitálně podepsané, aby bylo možné ověřit integritu binárních souborů.

      Povolení ověřování při připojování k frontám MSMQ ve WCF

      Nadpis Detaily
      Součást WCF
      Fáze SDL Sestavení
      Použitelné technologie Obecné, NET Framework 3
      Atributy –
      Odkazy MSDN
      Kroky Program při připojování k frontám MSMQ nepovolí ověřování, útočník může anonymně odeslat zprávy do fronty ke zpracování. Pokud se ověřování nepoužívá pro připojení k frontě MSMQ sloužící k doručení zprávy do jiného programu, útočník by mohl odeslat anonymní zprávu, která je škodlivá.

      Příklad

      Element <netMsmqBinding/> konfiguračního souboru WCF níže dává WCF pokyn, aby zakázal ověřování při připojování k frontě MSMQ pro doručování zpráv.

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

      Nakonfigurujte MSMQ tak, aby pro všechny příchozí nebo odchozí zprávy vyžadovala ověřování domén nebo certifikátů systému Windows.

      Příklad

      Element <netMsmqBinding/> konfiguračního souboru WCF níže dává WCF pokyn, aby při připojování k frontě MSMQ povolil ověřování certifikátů. Klient se ověřuje pomocí certifikátů X.509. Klientský certifikát musí být v úložišti certifikátů serveru.

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

      WCF-Nenastavujte vlastnost Message clientCredentialType na žádné

      Nadpis Detaily
      Součást WCF
      Fáze SDL Sestavení
      Použitelné technologie .NET Framework 3
      Atributy Typ přihlašovacích údajů klienta – žádný
      Odkazy MSDN, Fortify
      Kroky Absence ověřování znamená, že všichni mají přístup k této službě. Služba, která neověřuje své klienty, umožňuje přístup všem uživatelům. Nakonfigurujte aplikaci tak, aby se ověřila vůči přihlašovacím údajům klienta. To lze provést nastavením clientCredentialType zprávy na Windows nebo certifikát.

      Příklad

      <message clientCredentialType=""Certificate""/>

      WCF-Nenastavujte transport clientCredentialType na žádný

      Nadpis Detaily
      Součást WCF
      Fáze SDL Sestavení
      Použitelné technologie Obecné, .NET Framework 3
      Atributy Typ přihlašovacích údajů klienta – žádný
      Odkazy MSDN, Fortify
      Kroky Absence ověřování znamená, že všichni mají přístup k této službě. Služba, která neověřuje své klienty, umožňuje všem uživatelům přístup k jeho funkcím. Nakonfigurujte aplikaci tak, aby se ověřila vůči přihlašovacím údajům klienta. To lze provést nastavením transport clientCredentialType do systému Windows nebo certifikátu.

      Příklad

      <transport clientCredentialType=""Certificate""/>

      Ujistěte se, že se k zabezpečení webových rozhraní API používají standardní techniky ověřování.

      Nadpis Detaily
      Součást Webové rozhraní API
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy Ověřování a autorizace ve webovém rozhraní API ASP.NET, externích ověřovacích službách s webovým rozhraním API ASP.NET (C#)
      Kroky

      Ověřování je proces, kdy entita prokáže svou identitu, obvykle prostřednictvím přihlašovacích údajů, jako je uživatelské jméno a heslo. K dispozici je několik ověřovacích protokolů, které je možné zvážit. Některé z nich jsou uvedené níže:

      • Klientské certifikáty
      • Windows
      • Formuláře založené na formulářích
      • Federace – ADFS
      • Federace – Microsoft Entra ID
      • Federace – Server identit

      Odkazy v části Odkazy poskytují podrobné informace o tom, jak se dají implementovat jednotlivá schémata ověřování za účelem zabezpečení webového rozhraní API.

      Použití standardních scénářů ověřování podporovaných ID Microsoft Entra

      Nadpis Detaily
      Součást Microsoft Entra ID
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy Scénáře ověřování pro Microsoft Entra ID, ukázky kódu Microsoft Entra, příručka pro vývojáře Microsoft Entra
      Kroky

      Microsoft Entra ID zjednodušuje ověřování pro vývojáře tím, že poskytuje identitu jako službu s podporou standardních protokolů, jako jsou OAuth 2.0 a OpenID Connect. Níže je uvedeno pět primárních scénářů aplikací podporovaných ID Microsoft Entra:

      • Webový prohlížeč do webové aplikace: Uživatel se musí přihlásit k webové aplikaci, která je zabezpečená pomocí Microsoft Entra ID.
      • Jednostránkové aplikace (SPA): Uživatel se musí přihlásit k jednostránkové aplikaci, která je zabezpečená pomocí Microsoft Entra ID.
      • Nativní aplikace pro webové rozhraní API: Nativní aplikace, která běží na telefonu, tabletu nebo počítači, musí ověřit uživatele, aby získal prostředky z webového rozhraní API, které je zabezpečené pomocí Microsoft Entra ID.
      • Webová aplikace na webové rozhraní API: Webová aplikace potřebuje získat prostředky z webového rozhraní API zabezpečeného id Microsoft Entra
      • Démon nebo serverová aplikace do webového rozhraní API: Aplikace démona nebo serverová aplikace bez webového uživatelského rozhraní potřebuje získat prostředky z webového rozhraní API zabezpečeného rozhraním Microsoft Entra ID.

      Podrobnosti o implementaci nízké úrovně najdete na odkazech v části s odkazy.

      Přepsání výchozí mezipaměti tokenů MSAL distribuovanou mezipamětí

      Nadpis Detaily
      Součást Microsoft Entra ID
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy Serializace mezipaměti tokenů v MSAL.NET
      Kroky

      Výchozí mezipaměť, kterou knihovna MSAL (Microsoft Authentication Library) používá, je mezipaměť v paměti a je škálovatelná. Existují však různé možnosti, které můžete použít jako alternativu, jako je například mezipaměť distribuovaných tokenů. Tyto mechanismy mají L1/L2, kde L1 je v paměti a L2 je implementace distribuované mezipaměti. Ty je možné odpovídajícím způsobem nakonfigurovat tak, aby omezovaly paměť L1, zašifrovaly nebo nastavily zásady vyřazení. Mezi další alternativy patří mezipaměti Redis, SQL Server nebo Azure Comsos DB. Implementace mezipaměti distribuovaných tokenů najdete v následujícím kurzu: Začínáme s ASP.NET Core MVC.

      Ujistěte se, že se tokenReplayCache používá k zabránění přehrání ověřovacích tokenů MSAL.

      Nadpis Detaily
      Součást Microsoft Entra ID
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy Moderní ověřování pomocí Microsoft Entra ID pro webové aplikace
      Kroky

      Vlastnost TokenReplayCache umožňuje vývojářům definovat mezipaměť pro přehrání tokenu, úložiště, které lze použít k ukládání tokenů pro účely ověření, že se žádný token nedá použít více než jednou.

      Jedná se o míru proti běžnému útoku, který se označuje jako útok na přehrání tokenu: Útočník, který zachytí token odeslaný při přihlášení, se může pokusit ho znovu odeslat do aplikace ("přehrát" ji) pro vytvoření nové relace. Například v toku udělení kódu OIDC po úspěšném ověření uživatele se vytvoří požadavek na koncový bod /signin-oidc předávající strany s parametry "id_token", "code" a "state".

      Předávající strana ověří tento požadavek a vytvoří novou relaci. Pokud nežádoucí osoba tuto žádost zachytí a přehraje ji, může navázat úspěšnou relaci a zneuživatele. Přítomnost nonce v OpenID Connect může omezit, ale nemůže zcela eliminovat okolnosti, ve kterých může být útok úspěšně přijat. K ochraně svých aplikací můžou vývojáři poskytnout implementaci ITokenReplayCache a přiřadit instanci tokenReplayCache.

      Příklad

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

      Příklad

      Tady je ukázková implementace rozhraní ITokenReplayCache. (Přizpůsobte a implementujte architekturu ukládání do mezipaměti specifickou pro váš projekt)

      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;
    }
}

      Implementovaná mezipaměť se musí odkazovat v možnostech OIDC prostřednictvím vlastnosti TokenValidationParameters následujícím způsobem.

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

      Upozorňujeme, že pokud chcete otestovat efektivitu této konfigurace, přihlaste se k místní aplikaci chráněné OIDC a zachyťte požadavek na "/signin-oidc" koncový bod ve fiddleru. Pokud ochrana není nastavená, přehrání tohoto požadavku ve fiddleru nastaví nový soubor cookie relace. Když se požadavek přehraje po přidání ochrany TokenReplayCache, aplikace vyvolá výjimku následujícím způsobem: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      Použití knihoven MSAL ke správě žádostí o tokeny z klientů OAuth2 do Microsoft Entra ID (nebo místní služby AD)

      Nadpis Detaily
      Součást Microsoft Entra ID
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy MSAL
      Kroky

      Knihovna MICROSOFT Authentication Library (MSAL) umožňuje vývojářům získávat tokeny zabezpečení z platformy Microsoft Identity Platform k ověřování uživatelů a přístupu k zabezpečeným webovým rozhraním API. Dá se použít k zajištění zabezpečeného přístupu k Microsoft Graphu, dalším rozhraním API Microsoftu, webovým rozhraním API třetích stran nebo k vlastnímu webovému rozhraní API. MSAL podporuje mnoho různých aplikačních architektur a platforem, včetně .NET, JavaScriptu, Javy, Pythonu, Androidu a iOS.

      MSAL poskytuje mnoho způsobů, jak získat tokeny s konzistentním rozhraním API pro mnoho platforem. Není nutné přímo používat knihovny OAuth nebo kód proti protokolu ve vaší aplikaci a může získat tokeny jménem uživatele nebo aplikace (pokud je to možné pro platformu).

      MSAL také udržuje mezipaměť tokenů a aktualizuje tokeny za vás, když se blíží vypršení platnosti. MSAL vám také může pomoct určit, kterou cílovou skupinu chcete, aby se vaše aplikace přihlásila, a pomoct s nastavením aplikace z konfiguračních souborů a řešením potíží s aplikací.

      Ověřování zařízení připojujících se ke službě Field Gateway

      Nadpis Detaily
      Součást IoT Field Gateway
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy –
      Kroky Před přijetím dat z těchto zařízení a před usnadněním nadřazené komunikace s cloudovou bránou se ujistěte, že je každé zařízení ověřeno službou Field Gateway. Také se ujistěte, že se zařízení připojují pomocí přihlašovacích údajů jednotlivých zařízení, aby bylo možné jedinečně identifikovat jednotlivá zařízení.

      Ujistěte se, že se ověřují zařízení, která se připojují ke cloudové bráně.

      Nadpis Detaily
      Součást Cloudová brána IoT
      Fáze SDL Sestavení
      Použitelné technologie Generic, C#, Node.JS,
      Atributy Není k dispozici, volba brány – Azure IoT Hub
      Odkazy Není k dispozici, Azure IoT Hub s .NET, začínáme se službou IoT Hub a JS uzlu, zabezpečení IoT pomocí SAS a certifikátů, úložiště Git
      Kroky
      • Obecné: Ověřte zařízení pomocí protokolu TLS (Transport Layer Security) nebo IPSec. Infrastruktura by měla podporovat použití předsdíleného klíče (PSK) na těchto zařízeních, která nemohou zpracovat úplnou asymetrickou kryptografii. Využijte Microsoft Entra ID, Oauth.
      • C#: Při vytváření instance DeviceClient ve výchozím nastavení vytvoří metoda Create instanci DeviceClient, která používá protokol AMQP ke komunikaci se službou IoT Hub. Pokud chcete používat protokol HTTPS, použijte přepis metody Create, který umožňuje určit protokol. Pokud používáte protokol HTTPS, měli byste do projektu přidat Microsoft.AspNet.WebApi.Client také balíček NuGet, aby zahrnoval System.Net.Http.Formatting obor názvů.

      Příklad

      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);

      Příklad

      Node.JS: Ověřování

      Symetrický klíč

      • Vytvoření ioT Hubu v Azure
      • Vytvoření položky v registru identit zařízení 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Vytvoření simulovaného zařízení 
        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

      • Získá interně vygenerovaný při použití symetrického klíče, ale můžeme ho vygenerovat a použít i explicitně.
      • Definování protokolu: var Http = require('azure-iot-device-http').Http;
      • Vytvoření tokenu SAS: 
        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;
      • Připojení pomocí tokenu SAS: 
        Client.fromSharedAccessSignature(sas, Http);

        Certifikáty

      • Generování certifikátu X509 podepsaného svým držitelem pomocí libovolného nástroje, jako je OpenSSL, k vygenerování souboru .cert a .key pro uložení certifikátu a klíče
      • Zřiďte zařízení, které přijímá zabezpečené připojení pomocí certifikátů. 
        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) {});
      • Připojení zařízení pomocí certifikátu 
        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);

      Použití přihlašovacích údajů pro ověřování jednotlivých zařízení

      Nadpis Detaily
      Součást Cloudová brána IoT
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy Volba brány – Azure IoT Hub
      Odkazy Tokeny zabezpečení služby Azure IoT Hub
      Kroky Místo zásad sdíleného přístupu na úrovni služby IoT Hub použijte přihlašovací údaje pro ověřování jednotlivých zařízení pomocí tokenů SaS na základě klíče zařízení nebo klientského certifikátu. Zabráníte tak opakovanému použití ověřovacích tokenů jednoho zařízení nebo brány pole jinou bránou.

      Ujistěte se, že anonymní přístup ke čtení mají jenom požadované kontejnery a objekty blob.

      Nadpis Detaily
      Součást Azure Storage
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy StorageType – objekt blob
      Odkazy Správa anonymního přístupu pro čtení ke kontejnerům a objektům blob, sdíleným přístupovým podpisům, část 1: Principy modelu SAS
      Kroky

      Ve výchozím nastavení může mít kontejner a všechny objekty blob v něm přístup jenom vlastník účtu úložiště. Pokud chcete anonymním uživatelům udělit oprávnění ke čtení kontejneru a jeho objektů blob, můžete nastavit oprávnění kontejneru tak, aby umožňovala veřejný přístup. Anonymní uživatelé můžou číst objekty blob v rámci veřejně přístupného kontejneru bez ověřování požadavku.

      Kontejnery poskytují následující možnosti pro správu přístupu ke kontejnerům:

      • Úplný veřejný přístup ke čtení: Data kontejnerů a objektů blob je možné číst prostřednictvím anonymního požadavku. Klienti můžou vytvořit výčet objektů blob v rámci kontejneru prostřednictvím anonymního požadavku, ale nemůžou vytvořit výčet kontejnerů v rámci účtu úložiště.
      • Veřejný přístup pro čtení pouze pro objekty blob: Data objektů blob v tomto kontejneru se dají číst prostřednictvím anonymního požadavku, ale data kontejneru nejsou k dispozici. Klienti nemohou vytvořit výčet objektů blob v rámci kontejneru prostřednictvím anonymního požadavku.
      • Žádný veřejný přístup ke čtení: Kontejner a data objektů blob můžou číst jenom vlastník účtu.

      Anonymní přístup je nejvhodnější pro scénáře, kdy by určité objekty blob měly být vždy dostupné pro anonymní přístup pro čtení. Pro jemně odstupňované řízení může vytvořit sdílený přístupový podpis, který umožňuje delegovat omezený přístup pomocí různých oprávnění a v zadaném časovém intervalu. Ujistěte se, že kontejnery a objekty blob, které můžou potenciálně obsahovat citlivá data, nemají neúmyslně anonymní přístup.

      Udělení omezeného přístupu k objektům v úložišti Azure pomocí SAS nebo SAP

      Nadpis Detaily
      Součást Azure Storage
      Fáze SDL Sestavení
      Použitelné technologie Obecná
      Atributy –
      Odkazy Sdílené přístupové podpisy, část 1: Principy modelu SAS, sdílených přístupových podpisů, část 2: Vytvoření a použití SAS s úložištěm objektů blob, postup delegování přístupu k objektům ve vašem účtu pomocí sdílených přístupových podpisů a uložených zásad přístupu
      Kroky

      Použití sdíleného přístupového podpisu (SAS) je účinný způsob, jak udělit omezený přístup k objektům v účtu úložiště jiným klientům, aniž byste museli vystavit přístupový klíč účtu. SAS je identifikátor URI, který zahrnuje v parametrech dotazu všechny informace potřebné pro ověřený přístup k prostředku úložiště. Pro přístup k prostředkům úložiště pomocí sdíleného přístupového podpisu musí klient předat pouze sas příslušnému konstruktoru nebo metodě.

      Sas můžete použít, když chcete poskytnout přístup k prostředkům ve vašem účtu úložiště klientovi, kterému se nedá důvěřovat klíč účtu. Klíče účtu úložiště zahrnují primární i sekundární klíč, z nichž oba uděluje přístup pro správu k vašemu účtu a všem prostředkům v něm. Vystavení některého z klíčů účtu otevře váš účet pro možnost škodlivého nebo negligentního použití. Sdílené přístupové podpisy poskytují bezpečnou alternativu, která ostatním klientům umožňuje číst, zapisovat a odstraňovat data ve vašem účtu úložiště podle udělených oprávnění a bez nutnosti klíče účtu.

      Pokud máte logickou sadu parametrů, které jsou pokaždé podobné, je lepší použít uložené zásady přístupu (SAP). Vzhledem k tomu, že použití sdíleného přístupového podpisu odvozeného ze zásad uloženého přístupu umožňuje okamžitě odvolat tento SAS, doporučuje se vždy používat uložené zásady přístupu, pokud je to možné.