Aplikace a služby

Aplikace a data přidružená k nim nakonec fungují jako primární úložiště obchodních hodnot na cloudové platformě. Komponenty platformy, jako je identita a úložiště, jsou důležitými prvky prostředí zabezpečení, ale aplikace hrají v riziku pro firmu roli, protože:

  • Obchodní procesy jsou zapouzdřené a spouštěné aplikacemi a službami musí být k dispozici a poskytovány s vysokou integritou.

  • Obchodní data se ukládají a zpracovávají aplikačními úlohami a vyžadují vysoké záruky důvěrnosti, integrity a dostupnosti.

Tato část se zaměřuje na aplikace napsané vaší organizací nebo jinými uživateli jménem vaší organizace a saaS nebo komerčně dostupné aplikace nainstalované na virtuálních počítačích IaaS.

Diagram of Application Models

Moderní cloudové platformy, jako je Azure, můžou hostovat starší i moderní generace aplikací.

  • Starší verze aplikací jsou hostované na virtuálních počítačích Infrastruktura jako služba (IaaS), které obvykle zahrnují všechny závislosti včetně operačního systému, middlewaru a dalších komponent.

  • Moderní Aplikace PaaS (Platform as a Service) nevyžadují, aby vlastník aplikace spravovali a zabezpečili základní serverové operační systémy (OSes) a někdy jsou plně bezserverové a vytvářejí se primárně pomocí funkcí jako služby.

    Poznámky: Oblíbené formy moderních aplikací jsou kód aplikace hostovaný ve službě Azure App Services a kontejnerizované aplikace (i když kontejnery je možné hostovat také na virtuálních počítačích IaaS nebo v místním prostředí).

  • Hybridní – Zatímco hybridní aplikace můžou mít mnoho forem, nejběžnější je stav IaaS plus, kdy starší verze aplikací přechází na moderní architekturu s moderními službami, které nahrazují starší komponenty nebo přidávají starší verzi aplikace.

Zabezpečení aplikace vyžaduje záruky zabezpečení pro tři různé typy komponent:

  • Kód aplikace – toto je logika, která definuje vlastní aplikaci, kterou píšete. Zabezpečení tohoto kódu je zodpovědností vlastníků aplikací ve všech generacích aplikační architektury, včetně všech opensourcových fragmentů kódu nebo komponent zahrnutých v kódu. Zabezpečení kódu vyžaduje identifikaci a zmírnění rizik z návrhu a implementace aplikace a také posouzení rizika dodavatelského řetězce zahrnutých součástí. Všimněte si, že vývoj aplikací do architektur mikroslužeb rozdělí různé aspekty kódu aplikace do menších služeb a jednoho monolitického základu kódu.

  • Aplikační služby – jedná se o různé standardizované komponenty, které aplikace používá, jako jsou databáze, zprostředkovatelé identit, centra událostí, správa zařízení IoT atd. Pro cloudové služby je to sdílená odpovědnost:

    • Poskytovatel cloudu – Zabezpečení základní služby je odpovědností poskytovatele cloudu.

    • Vlastník aplikace – Vlastník aplikace zodpovídá za bezpečnostní důsledky konfigurace a provozu instancí služeb používaných aplikací včetně dat uložených a zpracovaných ve službě.

  • Platforma hostování aplikací – jedná se o výpočetní prostředí, ve kterém se aplikace skutečně spouští a spouští. V podniku s aplikacemi hostovanými místně v Azure a v cloudech třetích stran, jako je Amazon Web Services (AWS), může to mít mnoho forem s významnými variacemi na to, kdo zodpovídá za zabezpečení:

    • Starší verze aplikací obvykle vyžadují úplný operační systém (a jakýkoli middleware) hostovaný na fyzickém nebo virtualizovaném hardwaru. Virtuální hardware je možné hostovat místně nebo na virtuálních počítačích IaaS (Infrastruktura jako služba). Tento operační systém a nainstalované middleware / další komponenty jsou provozovány a zabezpečeny vlastníkem aplikace nebo jejich týmy infrastruktury.
      Odpovědnost za fyzické hardware a komponenty virtualizace operačního systému (hostitelé virtualizace, operační systémy a služby pro správu) se liší:

      • Místní – Vlastník aplikace nebo jejich organizace zodpovídá za údržbu a zabezpečení.

      • IaaS – Poskytovatel cloudu zodpovídá za údržbu a zabezpečení základní infrastruktury a organizace vlastníka aplikace zodpovídá za konfiguraci virtuálního počítače, operační systém a všechny komponenty nainstalované na něm.

    • Moderní aplikace jsou hostované v prostředích PaaS (Platform as a Service), jako je aplikační služba Azure. Ve většině typů aplikačních služeb se základní operační systém abstrahuje od vlastníka aplikace a zajišťuje poskytovatel cloudu. Vlastníci aplikací zodpovídají za zabezpečení konfigurací aplikační služby, které jsou jim poskytovány.

    • Kontejnery jsou mechanismus balení aplikací, ve kterém jsou aplikace abstrahovány z prostředí, ve kterém běží. Tyto kontejnerizované aplikace se vejdou do starších nebo moderních modelů výše v závislosti na tom, jestli jsou spuštěné ve službě kontejneru poskytovatelem cloudu (moderní aplikace) nebo na serveru spravovaném organizací (místně nebo v IaaS). Další podrobnosti najdete v části zabezpečení kontejneru níže.

Identifikace a klasifikace obchodních důležitých aplikací

Ujistěte se, že jste identifikovali a klasifikovali aplikace ve vašem portfoliu, které jsou pro obchodní funkce důležité.

Organizace obvykle mají velké portfolio aplikací, takže stanovení priorit, kde investovat čas a úsilí do ručních úloh náročných na prostředky, jako je modelování hrozeb, může zvýšit efektivitu vašeho programu zabezpečení.

Identifikujte aplikace, které mají vysoký potenciální dopad nebo vysokou potenciální expozici riziku.

  • Vysoký potenciální dopad – Identifikujte aplikaci, která by v případě ohrožení zabezpečení významně ovlivnila firmu. Může se jednat o jednu nebo více z těchto možností:

    • Důležitá obchodní data – Aplikace, které zpracovávají nebo ukládají informace, což by způsobilo významný negativní dopad na podnikání nebo poslání, pokud dojde ke ztrátě jistoty důvěrnosti, integrity nebo dostupnosti.

    • Regulovaná data – Aplikace, které zpracovávají peněžní nástroje a citlivé osobní údaje regulované standardy. Například obor platebních karet (PCI) a zákon o přenositelnosti a odpovědnosti za zdravotní informace (HIPAA).

    • Dostupnost pro důležité obchodní informace – aplikace, jejichž funkčnost je důležitá pro organizace, jako jsou výrobní linky, které generují výnosy, zařízení nebo služby důležité pro život a bezpečnost a další kritické funkce.

    • Významný přístup – aplikace, které mají přístup k systémům s vysokým možným dopadem prostřednictvím technických prostředků, například

      • Uložené přihlašovací údaje nebo klíče nebo certifikáty, které udělí přístup k datům nebo službě

      • Oprávnění udělená prostřednictvím seznamů řízení přístupu nebo jiných prostředků

  • Vysoká expozice útokům – Aplikace, které jsou snadno přístupné útočníkům, jako jsou webové aplikace na otevřeném internetu. Starší aplikace můžou být také vyšší expozice útočníkům a testerům průniku často cílí, protože znají, že tyto starší aplikace často mají chyby zabezpečení, které je obtížné opravit.

Přijetí přístupu DevOps

Organizace by se měly posunout z vývojového cyklu vodopádu na životní cyklus devOps kontinuální integrace, průběžné doručování (CI/CD) pro aplikace tak rychle, jak je praktické. DevOps je sjednocení lidí, procesů a nástrojů, které koncovým uživatelům umožňují průběžné doručování hodnot. Kontrakce vývojových a op se týká kombinování vývojových a provozních disciplín do více disciplín, které spolupracují se sdílenými a efektivními postupy a nástroji.

Model DevOps zvyšuje schopnost organizace rychle řešit problémy se zabezpečením bez čekání na delší plánovací a testovací cyklus vodopádového modelu.

Postupujte podle pokynů k zabezpečení DevOps.

Organizace by měly využívat pokyny a automatizaci pro zabezpečení aplikací v cloudu místo toho, aby začínaly od nuly.

Používání zdrojů a poznatků znalostí externích organizací, které jsou časná přijetí těchto modelů, může urychlit zlepšení stavu zabezpečení organizace s menším výdajem na úsilí a zdroje.

Použití cloudových služeb místo vlastních implementací

Vývojáři by měli místo psaní vlastních verzí používat služby dostupné od poskytovatele cloudu pro dobře zavedené funkce, jako jsou databáze, šifrování, adresář identit a ověřování.

Tyto služby poskytují lepší zabezpečení, spolehlivost a efektivitu, protože poskytovatelé cloudu pracují a zajišťují je s vyhrazenými týmy s hlubokými znalostmi v těchto oblastech. Díky těmto službám také uvolníte své vývojářské prostředky z opětovného vynalézaví příslovečné kolo, aby se mohly zaměřit na dobu vývoje na vaše jedinečné požadavky pro vaši firmu. Tento postup by měl být dodržen, aby se zabránilo rizikům při vývoji nových aplikací a aby se snížilo riziko v existujících aplikacích buď během plánovaného cyklu aktualizací, nebo s aktualizací aplikací zaměřenou na zabezpečení.

Několik možností, které by měly být upřednostněny z důvodu potenciálního dopadu na zabezpečení:

  • Identita – adresáře uživatelů a další ověřovací funkce jsou složité pro vývoj a kriticky důležité pro záruky zabezpečení. Nepoužívejte řešení ověřování homegrown a upřednostňují vyspělé funkce, jako je Azure Active Directory (Azure AD), Azure AD B2C, Azure AD B2C nebo řešení třetích stran k ověřování a udělení oprávnění uživatelům, partnerům, zákazníkům, aplikacím, službám a dalším entitám.

  • Ochrana dat – Vývojáři by měli používat zavedené funkce od poskytovatelů cloudu, jako je nativní šifrování v cloudových službách k šifrování a ochraně dat. Svět zabezpečení je vrhaný na příklady neúspěšných pokusů o ochranu dat nebo hesel, které nevydržovaly skutečné útoky na světě. Pokud je vyžadováno přímé použití kryptografie, vývojáři by měli volat dobře zavedené kryptografické algoritmy a nepokoušat se vymyslet vlastní.

  • Správa klíčů – Ideální použití identity pro ověřování místo přímého zpracování klíčů (viz Preferování ověřování identit před klíči). V situacích, kdy přístup ke službám, které vyžadují přístup k klíčům, využijte ke správě a zabezpečení těchto klíčů službu správy klíčů, jako je Azure Key Vault nebo služba AWS Key Management , a ne pokuste se bezpečně zpracovávat klíče v kódu aplikace. CredScan můžete použít ke zjišťování potenciálně vystavených klíčů v kódu aplikace.

  • Konfigurace aplikací – Nekonzistentní konfigurace pro aplikace můžou vytvářet bezpečnostní rizika. Azure App Configuration poskytuje službu pro centrální správu nastavení aplikací a příznaků funkcí, což pomáhá zmírnit toto riziko.

Použití funkcí nativního zabezpečení v aplikačních službách

Používejte nativní funkce zabezpečení integrované do cloudových služeb místo přidávání externích komponent zabezpečení (pro šifrování dat, filtrování síťového provozu, detekci hrozeb a další funkce).

Nativní bezpečnostní mechanismy jsou udržovány a podporovány poskytovatelem služeb, eliminují nebo snižují úsilí potřebné k integraci externích nástrojů zabezpečení a aktualizaci těchto integrací v průběhu času. Cloudové služby se rychle vyvíjejí, což výrazně zvyšuje zatížení údržby externího nástroje a zvyšuje riziko ztráty viditelnosti a ochrany zabezpečení z těchto nástrojů, pokud nástroj nebude držet krok s cloudovou službou.

Preferovat ověřování identit před klíči

Vždy se ověřujte pomocí služeb identit místo kryptografických klíčů, pokud jsou k dispozici.

Správa klíčů bezpečně pomocí kódu aplikace je obtížná a pravidelně vede k chybám, jako je náhodné publikování citlivých přístupových klíčů do úložišť kódu, jako je GitHub. Systémy identit nabízejí zabezpečené a použitelné prostředí pro řízení přístupu s integrovanými sofistikovanými mechanismy pro obměnu klíčů, monitorováním anomálií a dalšími funkcemi. Většina organizací má také kvalifikované týmy vyhrazené ke správě systémů identit a několika (pokud vůbec) lidí aktivně spravují klíčové systémy zabezpečení.

Pro služby, které nabízejí ověřování Azure AD, jako je Azure Storage, Azure App Service, Azure Backup, ho používají k ověřování a autorizaci. Pokud chcete dále zjednodušit používání identit pro vývojáře, můžete využít také spravované identity k přiřazování identit k prostředkům, jako jsou virtuální počítače a App Services, aby vývojáři nemuseli spravovat identity v rámci aplikace.

Přístup dolů k omezení objemu chyb zabezpečení a dopadu

image showing bottom-up approach to reduce security bug volume and impact

Snižte počet a potenciální závažnost chyb zabezpečení ve vaší aplikaci implementací postupů zabezpečení a nástrojů během životního cyklu vývoje.

Chyby zabezpečení můžou mít za následek zveřejnění důvěrných dat aplikací, což umožňuje zločincům měnit data nebo záznamy, nebo se data nebo aplikace stanou nedostupnými pro použití zákazníky a zaměstnanci. Aplikace budou mít vždy nějaké chyby logiky, které můžou vést k riziku zabezpečení, takže je důležité je zjistit, vyhodnotit a opravit, aby se zabránilo poškození reputace, výnosů nebo okrajů organizace. Je jednodušší a levnější tyto problémy vyřešit dříve v životním cyklu vývoje, než je opravit po dokončení testování aplikace, je v produkčním prostředí nebo byl porušen často označovaný jako "shift left" nebo "push left" princip.

Zmírnění rizik aplikací se dosahuje integrací postupů zabezpečení a nástrojů do životního cyklu vývoje, který se často označuje jako životní cyklus zabezpečeného vývoje (SDL nebo SDLC). Microsoft publikoval řadu doporučení v dokumentu white paper s názvem Vývoj zabezpečených aplikací v Azure na základě životního cyklu vývoje zabezpečení Microsoftu, který zmírňuje běžná rizika s ověřováním vstupu a výstupu, provádění testů fuzzů, kontrol povrchu útoku a dalších.

Přístup shora dolů prostřednictvím modelování hrozeb

image showing top-down approach through threat modeling

Modelování hrozeb můžete provádět ve svých podnikových aplikacích pro důležité obchodní informace, abyste zjistili a zmírňovali potenciální rizika pro vaši organizaci.

Modelování hrozeb identifikuje rizika pro samotnou aplikaci a také rizika, která může aplikace představovat vašemu podniku, zejména při vyhodnocování jednotlivých aplikací ve větším systému.

Modelování hrozeb se dá použít v libovolné fázi vývoje nebo produkce aplikací, ale pro fáze návrhu nových funkcí je jedinečně efektivní, protože pro tuto aplikaci zatím neexistují žádná skutečná data.

Vzhledem k tomu, že modelování hrozeb je náročné na dovednosti, doporučujeme přijmout opatření, která minimalizují časovou investici při maximalizaci hodnoty zabezpečení:

  1. Stanovení priority podle rizika – použití modelování hrozeb jako první u důležitých obchodních aplikací, které by měly v případě ohrožení zabezpečení dopad na firmu

  2. Rozsah omezení – Proveďte modelování hrozeb v progresivních fázích podrobností, abyste rychle identifikovali rychlé výhry a zmírnění rizik, která je možné provést před tím, než strávíte spoustu ručního úsilí:

    1. Začněte metodou jednoduchých otázek (viz metoda Jednoduchých otázek), která je zdokumentovaná níže, abyste rychle získali přehled o rizicích a o tom, jestli jsou zavedená základní ochrana.

    2. Postupně vyhodnocujte návrh aplikací – protože jsou k dispozici prostředky a odborné znalosti, přejděte k pokročilejší analýze pomocí metod POKROČILÉ METODY POKROČILÉ modelování hrozeb nebo jiné podobné metody, kterou už váš tým používá. Začněte návrhem na úrovni architektury a postupně zvětšete podrobnosti, jak umožňují čas a zdroje:

      1. Návrh na úrovni systému – zahrnuje aplikace a způsob vzájemné interakce

      2. Úroveň aplikace – zahrnuje komponenty aplikace a způsob vzájemné interakce

      3. Úroveň komponenty – zahrnuje, jak se jednotlivé komponenty skládají a jak jednotlivé prvky vzájemně spolupracují.

  3. Sladění s životním cyklem vývoje – Optimalizujte své úsilí sladěním aktivit modelování hrozeb s životním cyklem vývoje aplikací.

    1. Vodopád – zajistěte, aby hlavní projekty měly zahrnovat modelování hrozeb během procesu návrhu a během významných aktualizací aplikace.

    2. DevOps – Aktivujte aktivity modelování hrozeb s frekvencí, která přidává hodnotu zabezpečení bez nadměrné zátěže vývojových týmů. Dobré integrační body jsou během zavádění důležitých funkcí nebo změn aplikace a pravidelného pravidelného kalendáře plánu, například každé čtvrtletí pro důležité obchodní aplikace.

    3. Starší verze aplikací – Tyto aplikace obvykle nemají podporu, přístup ke zdrojovému kódu a/nebo odborné znalosti v organizaci, takže modelování hrozeb na základě toho, jaké znalosti a znalosti aplikací a odborné znalosti máte k dispozici, proveďte modelování hrozeb.

Metoda jednoduchých otázek

Tato jednoduchá metoda dotazování je navržená tak, aby odborníkům na zabezpečení a vývojářům začala modelovat hrozby před přechodem na pokročilejší metodu, jako je STRIDE nebo metoda OWASP (viz postup shora dolů prostřednictvím modelování hrozeb).

Pro každou aplikaci nebo komponentu položte a odpovězte na tyto otázky.

  • Ověřujete připojení pomocí Azure AD, TLS (se vzájemným ověřováním) nebo jiného moderního protokolu zabezpečení schváleného vaším bezpečnostním týmem? Tím se chrání před neoprávněným přístupem k aplikaci a datům.

    • Mezi uživateli a aplikací (pokud je to možné)

    • Mezi různými komponentami aplikací a službami (pokud je to možné)

  • Omezujete, které účty mají přístup k zápisu nebo úpravě dat v aplikaci, jenom na ty, které to vyžadují? Tím se snižuje riziko neoprávněné manipulace nebo změny dat.

  • Protokoluje se aktivita aplikace a podává ji do služby Security Information and Event Management (SIEM) prostřednictvím služby Azure Monitor nebo podobného řešení? To pomáhá týmu zabezpečení detekovat útoky a rychle je prozkoumat.

  • Jsou důležitá obchodní data chráněná šifrováním, které schválil bezpečnostní tým? To pomáhá chránit před neoprávněným kopírováním dat v době nečinnosti.

  • Je příchozí a odchozí síťový provoz šifrovaný pomocí protokolu TLS? To pomáhá chránit před neoprávněným kopírováním dat během přenosu.

  • Je aplikace chráněná před útoky DDoS (Distributed Denial of Service) pomocí služeb, jako je ochrana Azure DDoS, Akamai nebo podobná? Tím se chrání před útoky navrženými k přetížení aplikace, aby ji nebylo možné použít.

  • Ukládá aplikace přihlašovací údaje nebo klíče pro přístup k jiným aplikacím, databázím nebo službám? To pomáhá identifikovat, jestli může útok použít vaši aplikaci k útoku na jiné systémy.

  • Umožňují ovládacím prvkům aplikace splnit požadavky na zabezpečení a ochranu osobních údajů pro lokality, ve kterých pracujete? (To pomáhá chránit soukromá data uživatele a vyhnout se pokutám v dodržování předpisů)

Důležité: Zabezpečení je komplexní téma a potenciální rizika jsou omezena pouze představivostí inteligentních motivovaných útočníků. Tyto otázky jsou navržené tak, aby pomohly identifikovat snadno zjistitelné mezery, které útočníci snadno zneužívají. Při vývoji komfortu a kompetencí s touto metodou se můžete podívat, jak rozšířit schopnost modelu hrozeb tím, že postupujete k pokročilým technikám modelování hrozeb.

Pokročilé techniky modelování hrozeb

Komplexnější model hrozeb dokáže identifikovat více potenciálních rizik, dvě oblíbené techniky jsou STRIDE a OWASP.

  • Microsoft Životní cyklus vývoje zabezpečení zdokumentoval proces modelování hrozeb a vydal bezplatný nástroj, který vám pomůže s tímto procesem.

    • Tato metoda vyhodnocuje komponenty aplikací a připojení/vztahy vůči potenciálním rizikům, která se mapují na metodu STRIDE mnemonic:

      • Falšování identity

      • Manipulace

      • Popírání odpovědnosti

      • Zveřejnění informací

      • Odepření služby

      • Zvýšení oprávnění

    • Tuto metodu lze použít na libovolnou úroveň návrhu z komponent aplikací specifických pro architekturu vysoké úrovně.

  • OWASP – Projekt OWASP (Open Web Application Security Project) zdokumentoval přístup pro modelování hrozeb pro aplikace, který odkazuje na METODU STRIDE a další metody. https://www.owasp.org/index.php/Application_Threat_Modeling

Použití firewallů webových aplikací

Firewally webových aplikací (WAF) zmírňují riziko, že útočník může zneužít běžně zjištěná ohrožení zabezpečení pro aplikace. I když to není dokonalé, wafy poskytují základní minimální úroveň zabezpečení webových aplikací.

WaF jsou důležitým zmírněním rizik, protože útočníci cílí na webové aplikace pro bod příchozího přenosu dat do organizace podobné koncovému bodu klienta. WaF jsou vhodné pro obě

  • Organizace bez silného programu zabezpečení aplikací, protože se jedná o kritická bezpečnostní opatření (podobně jako padáky v letadle). Mějte na paměti, že by to neměl být jediný plánovaný bezpečnostní mechanismus, který by snížil objem a závažnost chyb zabezpečení ve vašich aplikacích. Podrobnosti najdete v tématu Snížení objemu chyb zabezpečení a dopadu.

  • Organizace, které investovaly do zabezpečení aplikací jako WAF, poskytují cenné další hloubkové zmírnění rizik ochrany. WaF v tomto případě fungují jako konečný bezpečnostní mechanismus v případě, že bezpečnostní chyba nebyla zmeškaná postupy zabezpečení v životním cyklu vývoje.

Microsoft zahrnuje funkce WAF ve službě Azure Application Gateway a mnoho dodavatelů nabízí tyto funkce jako samostatná bezpečnostní zařízení nebo jako součást bran firewall nové generace.

Postupujte podle osvědčených postupů pro zabezpečení kontejnerů.

Aplikace hostované v kontejnerech by měly dodržovat obecné osvědčené postupy pro aplikace a také některé konkrétní pokyny pro správu tohoto nového typu architektury aplikace.

Kontejnerizované aplikace čelí stejným rizikům jako každá aplikace a také přidává nové požadavky na bezpečné hostování a správu kontejnerizovaných aplikací.

Architektury kontejnerů aplikací zavedly novou vrstvu nástrojů pro abstrakci a správu (obvykle Kubernetes), které zvyšují produktivitu vývojářů a přijetí principů DevOps.

I když se jedná o nově vznikající prostor, který se rychle vyvíjí, bylo jasné několik klíčových poznatků a osvědčených postupů:

  • Použití spravované služby Kubernetes místo instalace a správy Kubernetes
    Kubernetes je velmi složitý systém a stále má řadu výchozích nastavení, která nejsou zabezpečená a několik odborníků na zabezpečení Kubernetes na marketplace. I když se to v posledních letech s každou verzí zlepšilo, stále existuje mnoho rizik, která je potřeba zmírnit.

  • Ověření kontejneru a dodavatelského řetězce kontejnerů
    Stejně jako byste měli ověřit zabezpečení libovolného opensourcového kódu přidaného do vašich aplikací, měli byste také ověřit kontejnery, které do svých aplikací přidáváte.

    • Ujistěte se, že se postupy použité při vytváření kontejneru ověřují proti vašim standardům zabezpečení, jako je aplikace aktualizací zabezpečení, kontrola nežádoucího kódu, jako jsou backdoory a nedovolené minery kryptografických mincí, kontrola ohrožení zabezpečení a použití postupů zabezpečeného vývoje.

    • Kontejnery pravidelně kontrolujte známá rizika v registru kontejneru, před použitím nebo během použití.

  • Nastavení registru známých dobrých kontejnerů
    To vývojářům ve vaší organizaci umožňuje rychle používat kontejnery ověřené zabezpečením s nízkými třeními. Kromě toho vytvořte proces pro vývojáře, který požádá a rychle získá ověření zabezpečení nových kontejnerů, aby vývojáři podporovali použití tohoto procesu a práce s ním.

  • Nespouštět kontejnery jako root nebo správce, pokud to explicitně nevyžadujete
    Dřívější verze kontejnerů vyžadují kořenová oprávnění (což usnadňuje útoky), ale u aktuálních verzí se už nevyžaduje.

  • Monitorování kontejnerů
    Ujistěte se, že nasadíte nástroje pro monitorování zabezpečení, které jsou s vědomím kontejneru pro monitorování neobvyklého chování, a povolte šetření incidentů.

Další kroky

Další pokyny k zabezpečení od Microsoftu najdete v dokumentaci k zabezpečení Microsoftu.