Rámec zabezpečení: Ověřování | Zmírnění rizik
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 | Sestavit |
| 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:
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 | Sestavit |
| 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í:
Test pro:
|
Povolení krokování nebo adaptivního ověřování
| Nadpis | Detaily |
|---|---|
| Součást | Webová aplikace |
| Fáze SDL | Sestavit |
| 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 | Sestavit |
| 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 | Sestavit |
| 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 | Sestavit |
| 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:
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 | Sestavit |
| 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 | Sestavit |
| 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í do služby SQL Database
| Nadpis | Detaily |
|---|---|
| Součást | Databáze |
| Fáze SDL | Sestavit |
| Použitelné technologie | SQL Azure |
| Atributy | Verze SQL – V12 |
| Odkazy | Připojení do služby 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 | Sestavit |
| 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 | Sestavit |
| 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 | Sestavit |
| 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 azure Správa istrátory
| 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í:
|
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átů typu klient-uzel Service Fabric Připojení do zabezpečeného 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í:
|
Použití standardních scénářů ověřování podporovaných serverem identit
| Nadpis | Detaily |
|---|---|
| Součást | Server identit |
| Fáze SDL | Sestavit |
| Použitelné technologie | Obecná |
| Atributy | – |
| Odkazy | IdentityServer3 – velký obrázek |
| Kroky | Níže jsou uvedené typické interakce podporované serverem identit:
|
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ů:
|
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 | Sestavit |
| 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 | Sestavit |
| 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 | Sestavit |
| 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 | Sestavit |
| 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:
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 | Sestavit |
| 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 Připojení. Níže je uvedeno pět primárních scénářů aplikací podporovaných ID Microsoft Entra:
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 | Sestavit |
| 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 | Sestavit |
| 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 Připojení 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 | Sestavit |
| 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 | Sestavit |
| 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 | Sestavit |
| 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 |
|
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 | Sestavit |
| 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 | Sestavit |
| 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:
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 | Sestavit |
| 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é. |
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro