Sdílet prostřednictvím

Doporučení ke zmírnění 10 hrozeb zabezpečení rozhraní API OWASP s využitím služby API Management

PLATÍ PRO: Všechny úrovně služby API Management

Poznámka:

Tento článek byl aktualizován tak, aby odrážel nejnovější seznam OWASP API Security Top 10 pro 2023.

Nadace OWASP (Open Web Application Security Project) pracuje na zlepšení zabezpečení softwaru prostřednictvím svých opensourcových softwarových projektů, stovek kapitol po celém světě, desítek tisíc členů a hostování místních a globálních konferencí.

Projekt zabezpečení rozhraní API OWASP se zaměřuje na strategie a řešení pro pochopení a zmírnění jedinečných ohrožení zabezpečení a rizik zabezpečení rozhraní API. V tomto článku probereme nejnovější doporučení ke zmírnění 10 hlavních hrozeb rozhraní API identifikovaných OWASP v seznamu 2023 pomocí služby Azure API Management.

I když služba API Management poskytuje komplexní ovládací prvky zabezpečení rozhraní API, další služby Microsoft poskytují doplňkové funkce pro detekci nebo ochranu před hrozbami rozhraní API OWASP:

Chybná autorizace na úrovni objektu

Objekty rozhraní API, které nejsou chráněné odpovídající úrovní autorizace, můžou být ohroženy únikem dat a neoprávněnou manipulací s daty prostřednictvím slabých identifikátorů přístupu k objektům. Útočník může například zneužít celočíselný identifikátor objektu, který se dá itestrovat.

Další informace o této hrozbě: Autorizace na úrovni poškozených objektů API1:2023

Doporučení

  • Nejlepším místem pro implementaci autorizace na úrovni objektu je samotné back-endové rozhraní API. V back-endu je možné provést správná rozhodnutí o autorizaci na úrovni požadavku (nebo objektu), pokud je to možné, pomocí logiky použitelné pro doménu a rozhraní API. Představte si scénáře, kdy daný požadavek může v odpovědi přinést různé úrovně podrobností v závislosti na oprávněních a autorizaci žadatele.

  • Pokud se v back-endu nedá změnit aktuální zranitelné rozhraní API, může být služba API Management použita jako záložní. Příklad:

    • K implementaci autorizace na úrovni objektu použijte vlastní zásadu, pokud není implementována v back-endu.

    • Implementujte vlastní pravidlo, které mapuje identifikátory z požadavku na backend a z backendu do klienta, aby interní identifikátory neodhalovaly.

      V těchto případech může být vlastní politika vyjádřená výrazem s vyhledáváním (například slovníkem) nebo integrací s jinou službou prostřednictvím politiky odeslání žádosti.

  • Ve scénářích GraphQL vynucujte autorizaci na úrovni objektu prostřednictvím politiky validate-graphql-request pomocí elementu authorize.

Přerušené ověřování

Mechanismus ověřování pro web nebo rozhraní API je zvlášť ohrožený, protože je otevřený anonymním uživatelům. Prostředky a koncové body vyžadované pro ověřování, včetně zapomenutého hesla nebo resetování toků hesel, by měly být chráněné, aby se zabránilo zneužití.

Další informace o této hrozbě: Přerušené ověřování rozhraní API2:2023

Doporučení

  • K implementaci ověřování rozhraní API použijte Microsoft Entra. Microsoft Entra automaticky poskytuje chráněné, odolné a geograficky distribuované koncové body přihlášení. Pomocí zásad validate-azure-ad-token ověřte tokeny Microsoft Entra v příchozích požadavcích rozhraní API.
  • Pokud se vyžaduje ověřování, služba API Management podporuje ověřování tokenů OAuth 2, základní ověřování, klientských certifikátů a klíčů rozhraní API.
    • Zajistěte správnou konfiguraci metod ověřování. Například nastavte require-expiration-time a require-signed-tokens na true při ověřování tokenů OAuth2 pomocí zásady validate-jwt.
  • Omezení rychlosti je možné využít ke snížení účinnosti útoků hrubou silou.
  • Filtrování IP adres klienta se dá použít ke snížení prostoru útoku. Skupiny zabezpečení sítě je možné použít u virtuálních sítí integrovaných se službou API Management.
  • Pokud je to možné, ověřte se u back-endů ze služby API Management prostřednictvím zabezpečených protokolů a spravované identity nebo správce přihlašovacích údajů pro ověřování v back-endech.
  • Ujistěte se, že se tokeny nebo klíče předávají v hlavicích a ne v adresách URL příchozích požadavků do služby API Management a odchozích požadavků na back-endy.
  • K zabezpečení přístupu k portálu pro vývojáře služby API Management použijte Microsoft Entra.

Autorizace na úrovni narušených vlastností objektu

Dobrý návrh rozhraní API je velmi náročný. Často, zejména u starších rozhraní API, která se v průběhu času vyvíjejí, rozhraní požadavků a odpovědí obsahují více datových polí, než vyžadují aplikace využívající, což umožňuje útoky prostřednictvím injektáže dat. Útočníci můžou také zjistit nezdokumentovaná rozhraní. Tato ohrožení zabezpečení by mohla útočníkovi přinést citlivá data.

Další informace o této hrozbě: Autorizace na úrovni vlastnosti poškozeného objektu API3:2023

Doporučení

  • Nejlepším přístupem k zmírnění tohoto ohrožení zabezpečení je zajistit, aby byla externí rozhraní definovaná v back-endovém rozhraní API navržena pečlivě a ideálně nezávisle na trvalosti dat. Měly by obsahovat pouze pole požadovaná uživateli rozhraní API. Rozhraní API by se měla často kontrolovat a starší pole by měla být označena jako zastaralá a poté odstraněna.
  • Ve službě API Management používejte revize k řádnému řízení neprolomných změn, například přidání pole do rozhraní a verzí k implementaci zásadních změn. Měli byste také verzovat backendová rozhraní, která mají obvykle jiný životní cyklus než rozhraní API určená pro spotřebitele.
  • Oddělení externích rozhraní API od implementace interních dat Vyhněte se vazbám kontraktů rozhraní API přímo na datové kontrakty v back-endových službách.
  • Pokud není možné změnit návrh back-endového rozhraní, a nadměrné množství dat představuje problém, použijte zásady transformace služby API Management k přepsání datových částí odpovědí a maskování nebo filtrování dat. Ověření obsahu ve službě API Management je možné použít se schématem XML nebo JSON k blokování odpovědí s nezdokumentovanými vlastnostmi nebo nesprávnými hodnotami. Odeberte například nepotřebné vlastnosti JSON z textu odpovědi. Blokování požadavků s nezdokumentovanými vlastnostmi snižuje riziko útoků a blokování odpovědí s nezdokumentovanými vlastnostmi znesnadňuje zpětné analýzy potenciálních vektorů útoku. Zásady ověření obsahu také podporují blokování odpovědí překračujících zadanou velikost.
  • Pomocí zásad ověření stavu kódu můžete blokovat odpovědi s chybami nedefinovanými ve schématu rozhraní API.
  • Pomocí zásad validate-headers můžete blokovat odpovědi s hlavičkami, které nejsou definovány ve schématu nebo nevyhovují jejich definici ve schématu. Odeberte nežádoucí hlavičky pomocí zásady set-header.
  • Ve scénářích GraphQL použijte zásadu validate-graphql-request k ověření požadavků GraphQL, autorizaci přístupu ke konkrétním cestám dotazů a omezení velikosti odpovědi.

Neomezená spotřeba prostředků

Rozhraní API vyžadují, aby běžely prostředky, jako je paměť nebo procesor, a můžou zahrnovat podřízené integrace, které představují provozní náklady (například služby s průběžnými platbami za žádosti). Použití limitů může pomoct chránit rozhraní API před nadměrnou spotřebou prostředků.

Další informace o této hrozbě: API4:2023 Neomezená spotřeba prostředků

Doporučení

  • Pomocí zásad rate-limit-by-key nebo rate-limit lze použít omezení v kratších časových intervalech. Na citlivých koncových bodech použijte přísnější zásady omezování rychlosti, jako je resetování hesla, přihlášení nebo operace registrace nebo koncové body, které spotřebovávají významné prostředky.
  • Pomocí zásad kvót podle klíče nebo omezení kvóty můžete řídit povolený počet volání rozhraní API nebo šířku pásma pro delší časové rámce.
  • Optimalizujte výkon pomocí integrovaného ukládání do mezipaměti, čímž se snižuje spotřeba procesoru, paměti a síťových prostředků pro určité operace.
  • Použijte zásady ověřování.
    • Použití atributu max-sizev zásadách ověření obsahu k vynucení maximální velikosti požadavků a odpovědí
    • Ve specifikaci rozhraní API definujte schémata a vlastnosti, jako je délka řetězce nebo maximální velikost pole. Použijte validate-content, validate-parameters a validate-headers k vynucení těchto schémat pro požadavky a odpovědi.
    • Použijte zásadu validate-graphql-request pro rozhraní GraphQL API a nakonfigurujte max-depth a max-size parametry.
    • Nakonfigurujte upozornění ve službě Azure Monitor pro nadměrné využití dat uživateli.
  • Pro generativní API umělé inteligence
  • Minimalizujte dobu, po které back-endová služba reaguje. Čím déle back-endová služba reaguje, tím déle je připojení obsazené ve službě API Management, čímž se snižuje počet požadavků, které je možné obsložovat v daném časovém rámci.
  • Použijte zásadu CORS pro řízení webů, které mají povoleno načítat prostředky obsluhované prostřednictvím rozhraní API. Abyste se vyhnuli příliš permisivním konfiguracím, nepoužívejte v zásadách CORS zástupné kóty (*).
  • I když má Azure ochranu na úrovni platformy i rozšířenou ochranu před útoky DDoS (Distributed Denial of Service), ochranu aplikací (vrstvy 7) pro rozhraní API je možné vylepšit nasazením služby ochrany proti botům před službou API Management – například Azure Application Gateway, Azure Front Door nebo Azure DDoS Protection. Při použití zásad firewallu webových aplikací (WAF) s Azure Application Gateway nebo Azure Front Door zvažte použití Microsoft_BotManagerRuleSet_1.0.

Rozbitá autorizace na úrovni funkce

Složité zásady řízení přístupu s různými hierarchiemi, skupinami a rolemi a nejasné oddělení mezi správou a běžnými funkcemi vedou k chybám autorizace. Když tyto problémy zneužijete, útočníci získají přístup k prostředkům jiných uživatelů nebo funkcím správy.

Další informace o této hrozbě: API5:2023 rozbitá autorizace úrovně funkce

Doporučení

  • Ve výchozím nastavení můžete chránit všechny koncové body rozhraní API ve službě API Management pomocí klíčů předplatného nebo zásad autorizace na úrovni všech rozhraní API. Pokud je to možné, definujte další zásady autorizace pro konkrétní rozhraní API nebo operace rozhraní API.
  • Ověřte tokeny OAuth pomocí zásad.
    • K ověření tokenů Microsoft Entra použijte zásadu validate-azure-ad-token. Zadejte všechny požadované nároky a v případě potřeby zadejte povolené aplikace.
    • Pro ověřování tokenů nevydávaných společností Microsoft Entra definujte zásadu validate-jwt a vynucujte požadované deklarace identity tokenů. Pokud je to možné, vyžadovat čas vypršení platnosti.
    • Pokud je to možné, použijte pro přístup šifrované tokeny nebo vypsat konkrétní aplikace.
    • Monitorujte a kontrolujte žádosti zamítnuté kvůli nedostatečné autorizaci.
  • Ke skrytí koncových bodů rozhraní API z internetu použijte virtuální síť Azure nebo Private Link. Přečtěte si další informace o možnostech virtuální sítě pomocí služby API Management.
  • Nedefinujte API operace se zástupnými znaky (to znamená "catch-all" API s * cestou). Zajistěte, aby služba API Management obsluhovala pouze požadavky na explicitně definované koncové body a požadavky na nedefinované koncové body byly odmítnuty.
  • Nepublikujte rozhraní API s otevřenými produkty , které nevyžadují předplatné.
  • Pokud jsou IP adresy klientů známé, použijte zásadu filtru IP, která povoluje provoz jenom z autorizovaných IP adres.
  • Pomocí zásad validate-client-certificate vynucujte, aby certifikát předaný klientem instanci služby API Management odpovídal zadaným ověřovacím pravidlům a deklaracím identity.

Neomezený přístup k citlivým obchodním tokům

Rozhraní API můžou uživatelům zpřístupnit širokou škálu funkcí. Je důležité, aby autoři rozhraní API porozuměli obchodním tokům, které rozhraní API poskytuje, a související citlivost. Existuje větší riziko pro firmu, pokud rozhraní API, která zveřejňují citlivé toky, neimplementují odpovídající ochranu.

Další informace o této hrozbě: API6:2023 Neomezený přístup k citlivým obchodním tokům

Doporučení

  • Omezte nebo zablokujte přístup na základě otisků prstů klienta. Například použijte zásadu návratové odpovědi spolu se zásadou výběru k blokování provozu z prohlížečů bez rozhraní na základě hlavičky User-Agent nebo konzistence jiných hlaviček.
  • Pomocí zásad validate-parameters vynucujte, aby hlavičky požadavků odpovídaly specifikaci rozhraní API.
  • Pomocí zásad filtru IP můžete povolit žádosti pouze ze známých IP adres nebo odepřít přístup z konkrétních IP adres.
  • Pomocí funkcí privátní sítě omezte externí připojení k interním rozhraním API.
  • Pomocí zásad omezování rychlosti podle klíče omezte špičky ve spotřebě rozhraní API na základě identity uživatele, IP adresy nebo jiné hodnoty.
  • Front API Management s Azure Application Gateway nebo službou Azure DDoS Protection, za účelem detekce a blokování botů.

Padělání požadavků na straně serveru

K zranitelnosti podvržení požadavku na straně serveru může dojít, když API načte podřízený prostředek na základě hodnoty URL, kterou předal volající API bez odpovídajících kontrol ověření.

Další informace o této hrozbě: Padělání požadavků na straně serveru API7:2023

Doporučení

  • Pokud je to možné, nepoužívejte adresy URL zadané v datových částech klienta, například jako parametry pro back-endové adresy URL, zásady odesílání požadavků nebo zásady přepisování adresy URL .
  • Pokud služba API Management nebo backendové služby používají adresy URL uvedené v datové části požadavku pro obchodní logiku, definujte a vynucujte omezený seznam názvů hostitelů, portů, typů médií nebo jiných atributů pomocí zásad ve službě API Management, například pomocí zásady choose a výrazů zásad.
  • timeout Definujte atribut v zásadách forward-request a send-request.
  • Ověření a sanitizace dat požadavků a odpovědí pomocí zásad ověřování V případě potřeby použijte zásadu set-body ke zpracování odpovědi a vyhněte se vrácení nezpracovaných dat.
  • K omezení připojení použijte privátní sítě. Pokud například rozhraní API nemusí být veřejné, omezte připojení z internetu, abyste snížili prostor pro útok.

Chybná konfigurace zabezpečení

Útočníci se mohou pokusit zneužít chyby zabezpečení při chybné konfiguraci, například:

  • Chybějící posílení zabezpečení
  • Zbytečně povolené funkce
  • Síťová připojení jsou zbytečně otevřená k internetu
  • Použití slabých protokolů nebo šifer

Další informace o této hrozbě: Chybná konfigurace zabezpečení rozhraní API8:2023

Doporučení

  • Správně nakonfigurujte protokol TLS brány. Nepoužívejte zranitelné protokoly (například TLS 1.0, 1.1) nebo šifry.
  • Nakonfigurujte rozhraní API tak, aby přijímala šifrovaný provoz jenom prostřednictvím protokolů HTTPS nebo WSS. Toto nastavení můžete auditovat a vynutit pomocí služby Azure Policy.
  • Zvažte nasazení služby API Management za privátním koncovým bodem nebo připojeného k virtuální síti nasazené v interním režimu. V interních sítích lze přístup řídit z privátní sítě (prostřednictvím brány firewall nebo skupin zabezpečení sítě) a z internetu (přes reverzní proxy server).
  • Použití zásad služby Azure API Management:
    • Vždy dědit nadřazené zásady prostřednictvím značky <base> .
    • Pokud používáte OAuth 2.0, nakonfigurujte a otestujte zásadu validate-jwt , abyste před dosažením back-endu zkontrolovali existenci a platnost tokenu. Automaticky zkontrolujte čas vypršení platnosti tokenu, podpis tokenu a vystavitele. Vynucujte deklarace identity, cílové skupiny, vypršení platnosti tokenu a podpis tokenu prostřednictvím nastavení zásad. Pokud používáte Microsoft Entra, zásady validate-azure-ad-token poskytují komplexnější a jednodušší způsob ověřování tokenů zabezpečení.
    • Nakonfigurujte zásady CORS a nepoužívejte zástupný znak * pro žádnou možnost konfigurace. Místo toho explicitně vypisovat povolené hodnoty.
    • Nastavte zásady ověřování v produkčních prostředích tak, aby ověřily schémata JSON a XML, hlavičky, parametry dotazu a stavové kódy a vynutily maximální velikost požadavku nebo odpovědi.
    • Pokud je služba API Management mimo hranici sítě, je ověření IP adresy klienta stále možné pomocí zásad omezení IP adres volajícího. Ujistěte se, že používá seznam povolených, ne seznam blokovaných.
    • Pokud se mezi volajícím a službou API Management používají klientské certifikáty, použijte zásadu validate-client-certificate . Ujistěte se, že všechny atributy validate-revocation, validate-trust, validate-not-before a validate-not-after jsou nastaveny na true.
  • Mezi službou API Management a back-endem je možné použít také klientské certifikáty (vzájemné tls). Back-end by měl:
    • Mějte nakonfigurované autorizační údaje
    • Ověřte řetěz certifikátů tam, kde je to možné.
    • Ověřte název certifikátu, pokud je to možné.
    • Pro scénáře GraphQL použijte zásadu validate-graphQL-request . Ujistěte se, že jsou nastaveny element authorization a atributy max-size a max-depth.
  • Neukládejte tajné kódy do souborů zásad ani do správy zdrojového kódu. Vždy používejte pojmenované hodnoty služby API Management nebo načtěte tajné kódy za běhu pomocí výrazů vlastních zásad. Pojmenované hodnoty by měly být integrované se službou Azure Key Vault nebo šifrované ve službě API Management tím, že je označíte jako tajné. Tajné kódy nikdy neukládejte do pojmenovaných hodnot ve formátu prostého textu.
  • Publikujte rozhraní API prostřednictvím produktů, které vyžadují předplatná. Nepoužívejte otevřené produkty , které nevyžadují předplatné.
  • Ujistěte se, že vaše rozhraní API vyžadují klíče předplatného, i když jsou všechny produkty nakonfigurované tak, aby vyžadovaly klíče předplatného. Další informace
  • Vyžaduje schválení předplatného pro všechny produkty a pečlivě zkontrolujte všechny žádosti o předplatné.
  • Ke správě všech certifikátů použijte integraci služby Key Vault. To centralizuje správu certifikátů a může pomoct usnadnit úlohy správy operací, jako je obnovení certifikátu nebo odvolání. Použijte spravovanou identitu k ověření v trezorech klíčů.
  • Pokud používáte samostatně hostovanou bránu, zajištěte, aby byl v provozu proces pravidelné aktualizace image na nejnovější verzi.
  • Představte služby back-endu jako entity back-endu. Pokud je to možné, nakonfigurujte autorizační přihlašovací údaje, ověřování řetězu certifikátů a ověření názvu certifikátu.
  • Pokud je to možné, použijte správce přihlašovacích údajů nebo spravovanou identitu k ověření v back-endových službách.
  • Při použití portálu pro vývojáře:
    • Pokud se rozhodnete samoobslužně hostovat portál pro vývojáře, ujistěte se, že existuje proces, který pravidelně aktualizuje místní portál na nejnovější verzi. Aktualizace výchozí spravované verze jsou automatické.
    • Pro registraci a přihlášení uživatele použijte Microsoft Entra ID nebo Externí ID Microsoft Entra . Zakažte výchozí ověřování pomocí uživatelského jména a hesla, což je méně bezpečné.
    • Přiřaďte skupiny uživatelů k produktům, abyste mohli řídit viditelnost rozhraní API na portálu.
  • Použijte Azure Policy k vynucení konfigurace na úrovni prostředků a oprávnění řízení přístupu na základě rolí (RBAC) ve službě API Management ke kontrole přístupu k prostředkům. Udělte každému uživateli minimální požadovaná oprávnění.
  • Použijte proces DevOps a přístup typu infrastruktura jako kód mimo vývojové prostředí, abyste zajistili konzistenci obsahu a změn konfigurace služby API Management a minimalizovali lidské chyby.
  • Nepoužívejte žádné zastaralé funkce.

Nesprávná správa inventáře

Mezi ohrožení zabezpečení související s nesprávnou správou prostředků patří:

  • Nedostatek správné dokumentace k rozhraní API nebo informací o vlastnictví
  • Nadměrný počet starších verzí rozhraní API, u kterých můžou chybět opravy zabezpečení

Další informace o této hrozbě: Rozhraní API9:2023 – Nesprávná správa inventáře

Doporučení

  • Jako zdroj pro import rozhraní REST API použijte dobře definovanou specifikaci OpenAPI. Specifikace umožňuje zapouzdření definice rozhraní API, včetně samodokumentujících metadat.
  • Rozhraní API můžete používat s přesnými cestami, schématy dat, hlavičkami, parametry dotazu a stavovými kódy. Vyhněte se operacím se zástupnými znaky. Zadejte popis jednotlivých rozhraní API a operací a uveďte kontaktní a licenční informace.
  • Vyhněte se koncovým bodům, které přímo nepřispívají k obchodnímu cíli. Zbytečně zvětšují prostor pro útok a znesnadní vývoj rozhraní API.
  • Ke správě změn rozhraní API použijte revize a verze ve službě API Management. Mít silnou strategii verzování backendu a zavázat se k maximálnímu počtu podporovaných verzí rozhraní API (například 2 nebo 3 předchozí verze). Naplánujte si rychlé vyřazení a nakonec odebrání starších, často méně zabezpečených verzí rozhraní API. Ujistěte se, že jsou implementované kontrolní mechanismy zabezpečení napříč všemi dostupnými verzemi rozhraní API.
  • Samostatná prostředí (například vývoj, testování a produkční prostředí) s různými službami API Management. Zajistěte, aby se každá služba API Management připojovala ke svým závislostem ve stejném prostředí. Například v testovacím prostředí by se testovací prostředek služby API Management měl připojit k testovacímu prostředku služby Azure Key Vault a testovacím verzím back-endových služeb. Používejte automatizaci DevOps a postupy infrastruktury jako kódu, které pomáhají udržovat konzistenci a přesnost mezi prostředími a snižovat lidské chyby.
  • Izolujte oprávnění správce k rozhraním API a souvisejícím prostředkům pomocí pracovních prostorů.
  • Pomocí značek uspořádejte rozhraní API a produkty a seskupte je pro publikování.
  • Publikujte rozhraní API ke spotřebě prostřednictvím portálu pro vývojáře. Ujistěte se, že je dokumentace k rozhraní API aktuální.
  • Objevte nedokumentovaná nebo nespravovaná rozhraní API a zpřístupněte je prostřednictvím API Management pro lepší kontrolu.
  • Azure API Center umožňuje udržovat komplexní centralizovaný inventář rozhraní API, verzí a nasazení, i když se rozhraní API nespravují ve službě Azure API Management.

Nebezpečná spotřeba rozhraní API

Prostředky získané prostřednictvím podřízených integrací mají tendenci být více důvěryhodné než vstup rozhraní API od volajícího nebo koncového uživatele. Pokud nejsou použity vhodné sanitizace a standardy zabezpečení, rozhraní API může být zranitelné, i když je integrace poskytována prostřednictvím důvěryhodné služby.

Další informace o této hrozbě: API10:2023 Nebezpečná spotřeba API

Doporučení

  • Zvažte použití služby API Management k tomu, aby fungovalo jako fasáda pro podřízené závislosti, se kterými se back-endová rozhraní API integrují.
  • Pokud jsou podřízené závislosti zajištěny prostřednictvím služby API Management nebo pokud jsou podřízené závislosti využívány s politikou odeslání žádosti v API Management, využijte doporučení z ostatních částí této dokumentace k zajištění bezpečné a kontrolované spotřeby, včetně:
    • Ujistěte se, že je povolený zabezpečený přenos, a vynucujte konfiguraci protokolu TLS/SSL.
    • Pokud je to možné, ověřte se pomocí správce přihlašovacích údajů nebo spravované identity.
    • Řízení spotřeby pomocí zásad omezení rychlosti podle klíče a omezení kvóty podle klíče.
    • Protokolujte nebo blokujte odpovědi, které nedodržují specifikaci rozhraní API, pomocí zásad validate-content a validate-header.
    • Transformace odpovědí pomocí zásad těla sady, například odebrání nepotřebných nebo citlivých informací
    • Konfigurace časových limitů a omezení souběžnosti

Související obsah

Přečtěte si další informace: