Monitorování cloudu a reakce
Tento článek je součástí série v průvodci monitorováním cloudu.
Odpověď je výsledkem definování jedné nebo více akcí na základě rozhodnutí řízených daty z monitorování, které uživatelům služeb umožní:
- Udělejte to tak, aby bylo možné reagovat: Pomocí dobře vyladěných konfigurací monitorování můžete vytvářet akční signály.
- Průběžné monitorování: Monitorování můžete použít v průběhu incidentu a řešit potíže, které vám pomůžou dál diagnostikovat problémy.
- Automatizace: Nakonfigurujte automatické šetření, diagnostiku, řešení, obnovení a nápravu na základě identifikovaných signálů.
Zde platí princip významnosti. To pomáhá s tokem procesu nebo zásadami pro akce k ladění a optimalizaci výstrah, oznámení a přehledů sestav. Monitorování cloudu je mnohem víc než upozorňování lidí, že něco není v pořádku. Jde také o poskytování signálů systémům a službám, které budou reagovat.
Monitorování hraje zásadní roli v široké škále scénářů:
- Povolení dynamického chování služeb: Dynamicky řídí systémy a služby, které reagují na základě dat monitorování a automaticky eliminují incidenty.
- Nepřetržitě vyhodnocovat signály: Neustále informovat a poskytovat telemetrii pro dynamické procesy, dodržování předpisů, automatické škálování a vizualizace.
- Organizační akce: Pomozte it organizaci reagovat na změny a spravovat je.
Upozorňování
Automatizace nahrazuje nákladnější procesy správy služeb v moderním cloudovém prostředí a eliminuje další incidenty. Výstrahy hrají zásadní roli při informovanosti, ale musí být užitečné, aby se zabránilo únavě nebo šumu výstrah.
Definování výstrah pomáhá proaktivně zajistit, aby služby a systémy zůstaly v pořádku, responzivní, spolehlivé a zabezpečené. Zajištění výkonu, dodržování cílů úrovně služeb (SLO), dostupnosti a ochrany osobních údajů vyžaduje správnou strategii upozorňování. Eskalace výstrah není pro pozorovatelnost zásadní a dnes by neměla být považována za první linii obrany. Místo toho by tady měla automatizace hrát důležitou roli.
Monitorování tradičně znamenalo vyvolání výstrahy, na které by někdo mohl reagovat, což znamená zcela reaktivní proces. Tento přístup je potřeba revidovat podle moderních postupů správy služeb nebo cloudového provozu. Tento přístup úzce sleduje tradiční cestu správy incidentů ITIL, která neodpovídá cílům efektivity cloudu prostřednictvím flexibility, minimálních nákladů a optimalizace.
Moderní přístup může mít frekvenci zjištěných podmínek, které jsou mnohem informativnější a automatizovanější, například:
| Zjištěná podmínka | Primitivní akce | Moderní akce |
|---|---|---|
| Upozornění a oznámení, webhook, nabízené oznámení, playbook, automatické škálování | Dotazování protokolů pro identifikaci komponenty pro přesměrování a aktivaci automatizace, aby se problém s komponentou pro přesměrování opravil. |
Tady je seznam relevantních prostředků pro upozorňování a automatizaci v Azure:
- Co jsou upozornění služby Azure Monitor?
- Integrace služby Azure Monitor s podporovanými produkty pro integraci IT Service Management (ITSM)
- Automatizace reakcí na hrozby v Microsoft Sentinelu pomocí pravidel automatizace
Moderní monitorování cloudu
V porovnání s monitorovacími platformami a souvisejícími nástroji, které byly v minulosti k dispozici, nabízí cloud computing:
- Mnohem větší flexibilita při navrhování možností reakce.
- Jednodušší způsoby vývoje a povolení automatizovaných odpovědí.
- Cloudové protokoly nebo metody rozhraní API se snadněji integrují se systémy správy práce, včetně DevOps.
Zvažte následující režimy pro rozsah automatizovaných akcí, ať už se jedná o šetření, rozšiřování, směrování, přiřazení, nápravu, obnovení nebo řešení:
| Metoda orchestrace | Popis |
|---|---|
| Plně automatizované | Akce se provádějí automaticky. Úplná automatizace by měla být prověřená spolehlivá, efektivní a odolná tam, kde její užitečnost není krátkodobá a je bezpečná. Úplná automatizace uvolní vaše prostředky, aby se mohly soustředit na vaše strategické iniciativy. |
| Poloautomatizované | Schválení se vyžaduje pro jakoukoli nápravnou akci. |
| Ruční | Operátor vybere příklad automatizace nebo playbook z kurátorované knihovny. |
Upozorňování závisí na instrumentovaných datech na základě událostí zabezpečení, metrik výkonu, informací o dostupnosti a protokolů. Akce řízené daty jsou výsledkem analýzy holistické, ucelené perspektivy každého monitorovaného prostředku agregací a zpracováním různých shromážděných datových typů, aby bylo možné určit dopad a jaká reakce se má provést.
Pokud chcete získat další informace o automatizaci na základě upozornění metrik a událostí zabezpečení, rozšiřte své čtení o těchto zdrojích informací:
- Začínáme s automatickým škálováním v Azure pomocí služby Azure Monitor
Nákladová efektivita
Stejně jako u ostatních pozorovatelných disciplín musí tým pochopit a uvědomit si důsledky nákladů a zjistit, jak typy odpovědí definovaných na podporu moderního řízení incidentů pomáhají řídit náklady. Přestože zastřešující cíl je zkrátit střední dobu obnovení (MTTR) rychlou reakcí a řešením problému, musíte neustále vyhodnotit potenciální náklady a dopad na datový proud výnosů IT nebo firmy.
Každý nahlášený incident má náklady. Předpokládejme, že organizace investovala do orchestrace, aby automatizovala odpověď. V takovém případě byste měli vyhodnotit nákladovou výhodu a dopad nákladů zvýšením spotřeby z cloudové služby a využít tyto služby nebo funkce, které umožňují automatizaci.
Automatizace
Cloudová automatizace nabízí významné výhody pro monitorování zabezpečení a stavu. Rychlost, flexibilita a přesnost jsou tři archetypy, které automatizace cloudu přináší do responzivních operací. Často se tomu říká orchestrace a cloud Microsoftu nabízí několik služeb.
Příklad:
- Z jednoho nebo více protokolů se detekuje hrozba řízená identitou a vyvolání výstrahy.
- Automatizace se okamžitě aktivuje, aby shromáždila další informace a korelovala další protokoly pro obohacení výstrahy.
- Operátor provede akci výběrem správné automatizace z knihovny, například zakázáním uživatelského účtu.
Příklad nebo případ použití je možné plně automatizovat.
Role automatizace pak poskytuje druh playbooku, který snižuje náklady a šetří čas:
- K provedení zdlouhavého vyšetřování, diagnostiky, řešení a obnovení nebyl potřeba žádný incident zabezpečení.
- Cyklus detekce a opravy může být v sekundách nebo minutách oproti hodinám.
Dále váš tým potřebuje vytvořit seznam nebo knihovnu příkladů automatizace, které se dají flexibilně používat – ať už z nezpracovaného materiálu na veřejných webech, nebo interně kurátorované a uložené v úložišti správy zdrojového kódu.
Tady je seznamnavrhovaných
- Automatické vytváření incidentů z výstrah zabezpečení Microsoftu pomocí služby Microsoft Sentinel
- Orchestrace zabezpečení, automatizace a reakce (SOAR) v Microsoft Sentinelu
Úspěšná strategie upozorňování
Nemůžete opravit, co nevíte, že je nefunkční.
Upozorňování na důležité věci. Základem je shromažďování a měření správných metrik a protokolů. Potřebujete také monitorovací nástroj, který umožňuje ukládat, agregovat, vizualizovat, analyzovat a inicializovat automatizovanou odpověď, když jsou splněny podmínky. Pozorovatelnost služeb a aplikací můžete zlepšit pouze v případě, že plně rozumíte jejich složení. Toto složení namapujete na podrobnou konfiguraci monitorování, kterou má platforma monitorování použít. Tato konfigurace zahrnuje předvídatelné stavy selhání (příznaky, nikoli příčinu selhání), které mají smysl upozorňovat na ně.
Informační výstrahy
Za určitých okolností mohou být některá upozornění informativní. Můžeme ho použít k tomu, abychom se dozvěděli, jak se naše systémy chovají. Můžete například chtít získat tyto informační výstrahy:
Virtuální počítač byl vypnutý: Virtuální počítač se automaticky vypnul, aby se minimalizovaly náklady na plýtvání a řízení na základě zjištěného plánu nebo nízkého využití.
V tomto příkladu se orchestrace používala na základě nativní funkce plánování a monitorovací platformy, která zjišťuje podmínku využití. Místo upozornění nebo eskalace jako jediné akce vás informuje o provedené akci a důvodech.
Nečinné prostředky: Prostředky IaaS nebo PaaS jsou nečinné po delší dobu nebo nejsou zřízené na základě doporučení Azure Advisoru.
V tomto příkladu lze orchestraci použít ke správě těchto aktivit souvisejících s infrastrukturou na základě obchodní logiky nebo pracovního postupu procesu ITSM. Dnes jsou potřeba mnohem rychlejší odpovědi a akce. Díky cloudu je upozorňování pro lidi menší než u automatizované reakce nebo průběžné orchestrace v rámci automatizovaného hodnotového toku.
Důležité informace o strategii upozorňování
Mějte na paměti, že učení je klíčové a při návrhu správných informačních upozornění vám může poskytnout mnoho přehledů o vašem cloudovém ekosystému a stavu.
Při určování, jestli je příznak vhodným kandidátem pro upozorňování, zvažte následující principy:
Je možné reagovat: Záleží na problému? Odráží skutečný problém ve stavu vaší aplikace? Můžete například chtít odeslat upozornění, když je využití procesoru příliš vysoké v průběhu trvalého období pro prostředek nebo dotaz SQL konzistentně způsobuje problémy s výkonem, ale možná nebudete chtít odeslat upozornění, když se využití procesoru během krátkého období špičky. Zredukujte falešně pozitivní výsledky a vyhněte se únavě výstrah.
Naléhavost: Potřebuje problém okamžitou pozornost? Pokud ano, příslušný tým by měl být okamžitě upozorněn.
Dopad na zákazníka: Týká se problém uživatelů služby nebo aplikace?
Dopad na závislé systémy: Existují výstrahy z vzájemně propojených závislostí, které je možné korelovat, aby se zabránilo upozorňování různých týmů na stejný problém?
S těmito počátečními aspekty můžete začít vyvíjet konfiguraci monitorování. Můžete testovat a ověřovat předpoklady napříč prostředími. Tyto aspekty a otázky například průběžně vyhodnocujte v neprodukčních i produkčních prostředích. Průběžné vylepšování je klíčem k úspěšné reakci na monitorovací signály.
Při průběžném vyhodnocování toho, co funguje, zvažte možnost položit si tyto otázky, které vám pomůžou zvýšit povědomí o efektivitě reakce na monitorování:
- Svazek upozornění: Získáte velký svazek upozornění? Je možné se vyhnout mnoha upozorněním, která se nedají použít?
- Problémy bez upozornění: Získáte sestavy nebo lístky od uživatelů, u kterých dochází k problémům, které nebyly zachyceny konfigurací monitorování?
- Falešně pozitivní: Dostáváte upozornění nebo signály, které byly nesprávně označeny?
- Upozornění nebo událost: Opravdu potřebujete odeslat upozornění, nebo můžou být některé z vyvolaných výstrah pouze události označené příznakem v systému? Pokud se signály při dotazování zobrazí na rozdíl od odeslání výstrahy, stačí, aby se zabránilo únavě výstrah a nedostupným oznámením?
Podívejte se na přehled monitorovacích platforem v této sérii článků, kde získáte hlubší přehled o možnostech řešení microsoftu pro monitorování.