← Referenční architektury / reference-architecture / architectures

Pochopení nasazení Email Security

E-mail zůstává klíčovým způsobem komunikace mezi lidmi i organizacemi, a to z něj zároveň dělá ideální kanál, který útočníci zneužívají k převzetí účtů, krádeži dat nebo získání přístupu k interním systémům. Schopnost omezit spam a čelit phishingu i malwarovým útokům je pro zabezpečení vaší organizace klíčová. Více než 90 % bezpečnostních incidentů začíná útokem přes e-mail.

Služba Cloudflare Email security patří mezi přední řešení na trhu a lze ji nasadit několika způsoby tak, aby vyhovovala potřebám dané organizace. Tento dokument popisuje jednotlivé způsoby nasazení Email security a důvody pro volbu konkrétního modelu.

E-mail zůstává klíčovým komunikačním kanálem pro firmy všech velikostí. Zároveň je ale i hlavním cílem kybernetických útoků, včetně phishingu, spamu a malwaru. K ochraně citlivých dat a reputace vaší organizace je proto nezbytné spolehlivé řešení zabezpečení e-mailu.

Cloudflare Email security nabízí ucelenou sadu nástrojů a technologií určených k ochraně vaší e-mailové infrastruktury před širokou škálou hrozeb. Nasazením Cloudflare Email security můžete výrazně posílit úroveň zabezpečení vaší organizace a omezit rizika spojená s útoky šířenými prostřednictvím e-mailu.

Tato referenční architektura poskytuje podrobný přehled nasazení a konfigurace Cloudflare Email Security pro optimalizaci zabezpečení e-mailu. Podrobně se věnuje klíčovým komponentám a doporučeným postupům, které zajistí bezproblémové začlenění tohoto řešení do vaší stávající IT infrastruktury.

Tato referenční architektura je určena pracovníkům IT a bezpečnostních týmů, kteří zvažují využití Cloudflare k zabezpečení jednotlivých oblastí svého podnikání. Je určena širokému okruhu čtenářů, mimo jiné:

• Odborníci na IT bezpečnost: Bezpečnostní inženýři, architekti a administrátoři odpovědní za návrh, implementaci a správu řešení zabezpečení e-mailu.
• Síťoví inženýři: Síťoví inženýři, kteří spravují síťovou infrastrukturu a e-mailové brány.
• Architekti cloudu: Cloudoví architekti, kteří navrhují a implementují cloudová řešení zabezpečení e-mailu.
• Rozhodovací pracovníci v oblasti bezpečnosti a IT: Manažeři a vedoucí pracovníci, kteří potřebují porozumět technickým aspektům zabezpečení e-mailu a činit informovaná rozhodnutí.

Ať už jste zkušený bezpečnostní expert, nebo v oblasti zabezpečení e-mailu teprve začínáte, tento dokument vám poskytne informace potřebné k efektivnímu nasazení a správě Cloudflare Email Security.

Pro hlubší pochopení Cloudflare doporučujeme následující zdroje:

• Co je Cloudflare? | Web ↗ (čtení na pět minut) nebo Video ↗ (dvě minuty)
• Cloudflare Blog ↗ | Zabezpečení e-mailu ↗ a Phishing ↗
• CISA | Phishing Guidance: Stopping the Attack Cycle at Phase One ↗

Na konci této referenční architektury budete vědět, jak Cloudflare chrání vaši e-mailovou komunikaci a na co byste měli myslet při výběru způsobu nasazení. Seznámíte se s konkrétními komponentami, technologiemi a konfiguracemi, které tvoří řešení Cloudflare Email Security. Dozvíte se také, jak se toto řešení integruje se stávající e-mailovou infrastrukturou a jak využívá cloudové služby.

Cloudflare Email security představuje moderní přístup k řešení phishingových útoků. Řešení Cloudflare je postaveno na AI a strojovém učení s využitím elastických služeb a zároveň těží z rozsáhlé sítě threat intelligence Cloudflare. Cloudflare Email security bylo navrženo jako jediná skutečně cloudová elastická služba se sdílenou inteligencí a Učení s učitelem ↗ podporuje libovolnou metodu nasazení dostupnou pro e-mail. Volba správného modelu nasazení je ovšem klíčová pro maximální využití přínosů zabezpečení e-mailu.

Tento dokument popisuje následující metody nasazení a uvádí, kdy je použít:

• Inline nebo MX
• Integrace Microsoft 365 API
• Journaling nebo BCC s automatickým přesunem
• Smíšené nasazení

Než zvolíte způsob nasazení, je důležité zvážit své potřeby a požadovaný uživatelský zážitek. Podle našich osvědčených postupů je obvykle vhodné zvolit nasazení MX, pokud jsme hlavní ochranou proti phishingu. Hlavní důvody jsou následující:

• Pre-delivery náprava nám umožňuje upravit způsob doručování zpráv připojením textu k předmětu či tělu zprávy a použitím přepisování URL adres na Cloudflare Remote Browser Isolation, a doručováním zpráv do složky nevyžádané pošty nebo do navazující karantény e-mailů. Díky tomu můžete navrhnout řešení s ohledem na konkrétní uživatelský zážitek.
• Zprávy dokážeme odstranit ještě předtím, než je zpracují systémy přijímající e-maily, jako je ServiceNow nebo archivační řešení.
• Odstraňujeme riziko problémů s dobou prodlevy, tedy časovým rozdílem mezi doručením zprávy do schránky a jejím následným přesunutím ze schránky.
• Podporujeme také smíšená nasazení, například kombinaci Microsoft 365 a Microsoft Exchange nebo Microsoft 365 a Google Workspace.

Pokud pro vás tyto potřeby nejsou důležité nebo používáte vrstvené zabezpečení, které nezahrnuje další řešení založené na API, naše metoda API se nasazuje rychle a efektivně, aniž by se měnil tok vaší pošty. Pokud chcete výhody API bez rizika omezování rychlosti API (API Throttling), nejlepší volbou je Journal/BCC, protože tento způsob příjmu API volání nepoužívá. Pokud ale chcete ochranu nasazení přes MX spolu s výhodami API pro interní zprávy, ideální je naše smíšené nasazení.

Pokud se vaše potřeby změní, máte možnost kdykoli přejít na jiný způsob nasazení podle svého uvážení, aniž byste museli naše řešení znovu kupovat. Jedinou výjimkou je, že klienti s licencí Advantage a CyberSafe jsou omezeni na nasazení typu Inline, zatímco licence Enterprise nabízí všechny možnosti.

Než se rozhodnete pro konkrétní způsob nasazení, doporučuje Cloudflare projít si všechny možnosti, zvážit své potřeby a v případě potřeby se poradit se svým account týmem.

Při nasazení typu Inline se veškerá pošta určená pro jednu nebo více domén filtruje přes Cloudflare ještě předtím, než se doručí do schránky uživatele. Cloudflare lze nasadit kdekoli ve vašem řetězci zpracování pošty. Pokud je nasazený jako první hop, budete muset aktualizovat záznamy MX v DNS dané domény tak, aby směřovaly na Cloudflare. Pokud chcete, aby Cloudflare zprávy kontroloval až po vaší stávající bráně SEG (Secure Email Gateway), lze Cloudflare zařadit jako další krok ve zpracovatelském řetězci, odkud zpracované zprávy dále přeposílá na následující krok. Na základě zásad se zprávy označené jako Spam, Malicious, Bulk a další blokují nebo přesouvají do karantény.

Diagram výše popisuje následující:

1. E-mail dorazí do Cloudflare na základě Záznamy MX ↗.
2. Cloudflare kontroluje tělo, hlavičku a přílohy e-mailu a přiřazuje odpovídající klasifikaci:
   • Malicious
   • Spam
   • Bulk
   • Suspicious
   • Spoof
   • Vyčistit
3. Uplatněte libovolnou zásadu, například povolení nebo blokování konkrétních domén.
4. Karanténa e-mailů s vysokým rizikem
5. Všechny zprávy, které obdržely dispozice od Cloudflare bude mít hlavičku X-CFEmailSecurity-Disposition přidána. Tuto hlavičku mohou navazující systémy použít k vyvolání speciálního zpracování (přesměrování, externí karanténa a podobně).
6. Přeposílejte veškerý platný e-mailový provoz.
7. Zprávy lze upravit v předmětu a/nebo těle tak, aby obsahovaly viditelnou informaci pro koncového uživatele o způsobu naložení se zprávou.

Z bezpečnostního hlediska je preferovanou metodou nasazení Inline, protože kontroluje každý e-mail a zabraňuje tomu, aby se škodlivý obsah dostal do schránky uživatele. Tím se eliminují veškerá rizika expozice uživatelů.

• Zprávy jsou zpracovány a zablokovány ještě před doručením do schránky uživatele.
• Nasazení Inline umožňuje upravovat zprávu a přidávat značky do předmětu nebo těla zprávy, například připojení [SPAM] nebo [EXTERNAL SPAM] k předmětu.
• Poskytuje vysokou dostupnost a adaptivní řazení zpráv do fronty, protože Cloudflare bude nadále přijímat příchozí e-maily do fronty i v případě, že navazující služby nejsou dostupné. Jakmile se navazující služby obnoví, doručování zpráv z fronty pokračuje.
• Zprávy s přiřazeným dispozice které nejsou umístěny do karantény, obdrží X-header které lze následně použít pro pokročilé zpracování v navazujících krocích.
• Kompatibilní se všemi poštovními systémy, včetně Microsoft Exchange On-Prem, Postfix, Lotus Notes, Google Workspace, Microsoft 365 a dalších.

Před nasazením zabezpečení e-mailu přes Inline je třeba zvážit následující:

1. Nasazení, při kterém pošta nejprve prochází Microsoft Exchange nebo Microsoft 365 a teprve poté je pomocí pravidel toku pošty přesměrována do řešení pro zabezpečení e-mailu ke skenování a nápravě a následně se vrací zpět do Microsoft 365, Microsoft nepodporuje. Cloudflare je sice takové nasazení technicky schopna realizovat, ale způsobuje to problémy s atribucí (rozpoznáním původního odesílatele) a s doručováním.
2. Pokud má být Cloudflare záznamem MX, vyžaduje to změny DNS. Pokud existuje více domén, je nutné aktualizovat každou zónu DNS zvlášť.
3. Nasazení Inline může zvýšit složitost architektury SMTP, pokud Cloudflare není nasazen jako MX, například Inline za tradičním SEG (Mimecast/ProofPoint).
4. Nasazení Inline může vyžadovat duplicitní zásady napříč více řešeními a MTA. Cloudflare, SEG a MTA například zpracovávají zásady povolení výrazně odlišným způsobem, a proto může být u stejné zprávy potřeba ošetřit výjimky na všech místech zvlášť.
5. V rámci vrstveného nasazení mohou někteří poskytovatelé, například Mimecast a Barracuda, fungovat pouze jako MX. V takovém scénáři byste nakonfigurovali Cloudflare Inline za těmito poskytovateli.
6. Při používání Mimecastu doporučujeme vypnout funkci URL Rewriting, protože Cloudflare kvůli ní nemůže adresy URL dekódovat a procházet. Pokud tato funkce zůstane zapnutá, naše schopnost sledovat odkazy se omezí jen na reputaci a stáří domény.

Cisco nabízí unikátní možnost integrace s Cloudflare pomocí konektoru jako MX, nebo za Cloudflare s podporovaným nasazením Hairpin. Ve všech ostatních ohledech funguje toto nasazení stejně jako Inline. Viz Cisco jako MX Record a Cisco - Email security jako MX Record.

Alternativním přístupem je integrace přes Graph API v Microsoft 365. V tomto modelu se e-maily doručují přímo do schránky uživatele, kde je následně Cloudflare obdrží v kopii, prohledá a přesune podle konfigurace dispozice.

Provádí se to přihlášením k odběru všech uživatelských schránek v autorizovaných doménách. Během procesu autorizace si můžete zvolit, zda se má rozsah omezit pouze na Inbox, nebo zahrnout All Folders. Po doručení do schránky odběr spustí v Microsoftu 365 akci, která odešle Cloudflare kopii e-mailu ke kontrole a přiřazení stavu. Jakmile je stav přiřazen, naše řešení se podívá na auto-move zásady a proveďte požadovanou akci.

Diagram výše popisuje následující:

1. E-mail je doručen přímo do doručené pošty uživatele přes stávající trasu.
2. Cloudflare načítá zprávy ke kontrole přes API e-mailového poskytovatele. Cloudflare kontroluje tělo, hlavičku a přílohy e-mailu a přiřazuje odpovídající klasifikaci:
   • Malicious
   • Spam
   • Bulk
   • Suspicious
   • Spoof
   • Vyčistit
3. Uplatněte libovolnou zásadu, například povolení nebo blokování konkrétních domén.
4. Zprávy jsou v řešení Cloudflare přesouvány podle zásad. K dispozici jsou tyto akce:
   • Doručená pošta
   • Junk
   • Koš
   • Soft Delete (uživatelsky obnovitelné)
   • Trvalé odstranění (obnovitelné administrátorem)

Za normálních okolností tento proces obvykle proběhne za méně než 2-3 sekundy od doručení do schránky po požadavek na přesun. Google ani Microsoft 365 negarantují žádné SLA na to, jak dlouho jim provedení akce zabere. Pokud se přesun nezdaří, naše řešení jej bude opakovaně zkoušet každých pět minut.

• Jednoduchý způsob, jak přidat ochranu do složitých e-mailových architektur bez nutnosti měnit tok pošty.
• Nasazení bez agenta pro Microsoft 365.
• Microsoft 365 Defender/ATP zpracovává zprávu jako první.
• Tuto metodu lze použít pro Proof of Value, tedy pro shromažďování a vykazování e-mailů bez nutnosti měnit tok pošty. V tomto scénáři byste ponechali remediation policy nenakonfigurovanou, aby se nespouštěly žádné akce.

Před nasazením zabezpečení e-mailu přes Nasazení API, budete muset zvážit následující:

• V závislosti na API infrastruktuře prodlužují výpadky a servisní okna Microsoft 365 nebo Google dobu, po kterou zprávy zůstávají ve schránce, protože e-maily nelze skenovat ani řešit dříve, než jsou doručeny uživateli. Toto omezení se týká všech dodavatelů využívajících API.
• Microsoft 365 může omezovat počet požadavků API na Graph API po jednotlivých službách. Mail API s Graph spadá do sekce Outlook Services. Tyto limity by mohl útočník zneužít k faktickému znefunkčnění jakéhokoli nasazení založeného na API, čímž by získal další časové okno pro útok. Limity jsou následující:
  • 10 000 požadavků API za 10 minut
  • Čtyři souběžné požadavky
  • 150 megabajtů (MB) nahrávání (PATCH, POST, PUT) za pět minut
  • Viz Limity služby Outlook ↗
• Na Gmail API se vztahuje denní limit využití, který platí pro všechny požadavky z vaší aplikace, a limity četnosti požadavků na jednotlivého uživatele. Každý limit je vyjádřen v kvótových jednotkách, což je abstraktní jednotka měřící využití zdrojů Gmail. Hlavní limity požadavků jsou popsány následovně:
  • Limit rychlosti 250 kvótových jednotek na uživatele za sekundu, klouzavý průměr (umožňuje krátké špičky).
  • Využití kvóty podle metody vychází z počtu kvótových jednotek, které daný požadavek spotřebuje v závislosti na volané metodě.
  • Například messages.get a messages.attachments.get spotřebují pět jednotek kvóty. Více informací najdete v Využití kvóty podle metody ↗
• Vyžaduje přístup ke čtení a zápisu do schránek, což některé bezpečnostní nebo e-mailové týmy nemusí povolit.
• Skutečnou podporu API má pouze Microsoft 365. Google umožňuje nápravu (remediation) přes API, ale pro doručování e-mailů ke skenování přes SMTP stále vyžaduje Compliance Rule. Lokální Exchange vyžaduje PowerShell a nemá API pro automatické přesuny.
• Podle požadavků Microsoft 365/Google nelze zprávy po doručení upravovat. To znamená, že nelze provést přepis adres URL (URL Rewriting) na Cloudflare izolace odkazů v e-mailu nebo připojit text k předmětu či tělu e-mailu. Tyto funkce jsou k dispozici pouze při nasazení Inline.

Nasazení BCC/Journaling se velmi podobá nasazení přes API, liší se jen ve způsobu doručování e-mailů do Cloudflare. Stejně jako u API se e-mail doručí nejprve do schránky, zároveň se do něj ale přidá adresa specifická pro daný účet, takže se jeho kopie odešle přes SMTP do Cloudflare k vyhodnocení.

Jakmile Cloudflare e-mail přijme, prohledá ho a určí dispozice e-mailu. Jakmile má e-mail přiřazenu dispozici, naše řešení zkontroluje autorizace API a auto-move zásady a provede požadovanou akci. Tato metoda je méně náchylná k omezování rychlosti API, protože rozhraní API pro Microsoft 365 a Google se používají pouze k nápravě e-mailů.

Během fáze proof of value lze toto nasazení nakonfigurovat s jakýmkoli řešením zabezpečení e-mailu nebo poštovní platformou, která umožňuje přidat příjemce do BCC, a získat tak přehled o tom, co tato řešení přehlédnou a co by Cloudflare zablokoval.

• Jednoduchý způsob, jak přidat ochranu do složitých e-mailových architektur bez nutnosti měnit tok pošty.
• Bezagentní nasazení pro Microsoft 365. Microsoft 365 odešle e-maily po doručení do Cloudflare a autorizaci API lze nastavit tak, aby zásada Remediation přesouvala e-maily s určitým rozhodnutím mimo doručenou poštu.
• Google využívá Compliance Rules pro BCC, které lze kombinovat s API Authorization pro přesun e-mailů po doručení. Výsledek je stejný jako u nasazení API popsaného výše.
• Microsoft 365 a Google zpracovávají zprávu jako první. Díky tomu vzniká vrstvenější přístup, který kromě Cloudflare využívá i bezpečnostní schopnosti Microsoft 365/Google.
• Můžete řídit rozsah kontrolovaných zpráv (externí, interní nebo obojí)
• Tuto metodu lze použít pro Proof of Value, tedy pro shromažďování a vykazování e-mailů bez nutnosti měnit tok pošty. Nevyžaduje nastavenou autorizaci API. Pokud je API nakonfigurováno pro Microsoft 365 nebo Google, ponechte Remediation policy nenakonfigurovanou, aby se nespouštěly žádné akce.

Před nasazením zabezpečení e-mailu přes BCC/Journaling je třeba zvážit následující:

• Stejná omezení jako u API.
• Pro doručování zpráv přes SMTP závisí na Google nebo Microsoft 365.
• Může vyžadovat konektor (Connector) v Microsoft 365 pro zajištění přímé komunikace.
• Podle požadavků Microsoft 365/Google nelze zprávy po doručení upravovat. To znamená, že nelze provést přepis adres URL (URL Rewriting) na Cloudflare Email Link Isolation ani přidat text do předmětu (Subject) nebo těla (Body) e-mailu. Tyto funkce jsou dostupné pouze při nasazení Inline.

Smíšené nasazení využívá pro externí e-maily nasazení Inline a pro interní e-maily BCC/Journaling. Toho se dosahuje kombinací obou metod nasazení, přičemž Cloudflare je nakonfigurován pro dva průchody (hops) v režimu BCC/Journal. Tento scénář přináší všechny výhody doručování přes MX pro externí zprávy a zároveň umožňuje nápravu škodlivých e-mailů z interních zdrojů. Zde je několik scénářů, kdy se to hodí.

smíšené nasazení kombinuje výhody nasazení Inline pro externí e-maily a BCC/Journaling pro interní e-maily.

Pokud zvolíte smíšené nasazení, musíte vzít v úvahu, že:

• Detekce u interních e-mailů jsou omezené kvůli nedostatku informací, jako je ověření e-mailu, odesílající server a doručovací cesta. Analyzovat lze pouze obsah těla e-mailu.
• Interní e-maily mohou při použití funkce Protecting Users s registrem zosobnění vykazovat více falešně pozitivních výsledků.

Cloudflare nabízí automatizované pracovní postupy založené na průběžné analýze a odesílaných podnětech. Tyto funkce umožňují Cloudflare přesouvat zprávy pomocí API auto-move zásady po doručení. Nejlépe se kombinuje s hlášeními phishingu nebo hlášeními od uživatelů třetích stran.

Cloudflare upřednostňuje podněty administrátorů (Administrator Submissions) týkající se falešně pozitivních a falešně negativních vyhodnocení zadané přes dashboard Cloudflare. Tento přístup zkracuje dobu kontroly a pomáhá Cloudflare proaktivně odhalovat a opravovat problémy, které mohou postihnout více uživatelů, čímž se zlepšuje celkový zážitek z produktu. Administrátorům se doporučuje kontrolovat podněty uživatelů, dohledat všechny související zprávy a odeslat je jako ověřené falešně pozitivní nebo falešně negativní případy přes dashboard Cloudflare. Tyto podněty budou zkontrolovány a v budoucnu použity ke zlepšení modelů strojového učení, detekcí a enginů.

Shrnuto, Email Security nabízí tři základní modely nasazení: API, BCC/Journaling a Inline (neboli MX). Preferovaným modelem nasazení je Inline, protože filtruje a odstraňuje škodlivé zprávy dříve, než se dostanou do doručené pošty uživatele. Tím se odstraňuje riziko prodlevy a umožňují se funkce jako přepisování adres URL a úprava zpráv.

Modely API a BCC/Journaling jsou řešení uplatňovaná až po doručení zprávy, která se přímo integrují s platformami jako Microsoft 365 nebo Google Workspace a slouží ke kontrole a auto-move e-maily poté, co již dorazily do uživatelovy schránky. Tyto metody po doručení se sice snáze nasazují a nevyžadují žádné změny v toku pošty, mají ale svá omezení, například riziko omezení rychlosti API (throttling) a nemožnost upravovat obsah zprávy, třeba předmět nebo text těla.

Nakonec smíšené nasazení kombinuje výhody režimu Inline pro ochranu externí pošty (kritické pro systémy jako CRM nebo ticketing, které přijímají e-maily) s režimem BCC/Journaling pro vyhodnocování interní pošty.