Microsoft Sentinel podporuje viac účtov v konektore: čo preveriť pred centralizáciou

Microsoft 31. augusta 2026 oznámil podporu viacerých účtov pri troch konektoroch Microsoft Sentinel: Auth0, CrowdStrike Falcon a Salesforce Service Cloud. Pre bezpečnostný tím je to praktická zmena. Viac účtov rovnakého zdroja už nemusí znamenať osobitný typ konektora alebo improvizované obchádzky pre každé pripojenie.

Centralizácia však nie je jedno kliknutie bez prevádzkových dôsledkov. Každé pripojenie sa autentifikuje a dotazuje samostatne, dáta môžu smerovať do spoločnej tabuľky a rastie význam pomenovania zdroja, oprávnení, API limitov aj nákladov na ingestiu. Pred zapojením druhého účtu preto treba pripraviť návrh, podľa ktorého bude možné udalosti spoľahlivo rozlíšiť.

Čo presne pribudlo

Oznámenie sa týka konektorov Auth0, CrowdStrike Falcon a Salesforce Service Cloud. Microsoft ich uvádza ako prvé konektory s podporou multi-account vzoru. Nejde o vyhlásenie, že každý Sentinel konektor automaticky prijme ľubovoľný počet účtov. Pri ďalšom zdroji treba overiť aktuálnu dokumentáciu konkrétneho konektora.

V správcovskom rozhraní možno vytvoriť viac samostatných pripojení rovnakého typu. Každé má vlastné údaje spojenia a vlastný stav. To pomáha napríklad skupine firiem, tímu s viacerými tenantmi služby alebo organizácii, ktorá oddeľuje produkčný a ďalší účet dodávateľa.

Ako funguje multi-account vzor

Dokumentácia Content Connector Framework opisuje spoločnú definíciu konektora, dátové pravidlo, endpoint zberu a cieľovú tabuľku. Každé používateľom vytvorené pripojenie však dostane jedinečný ARM prostriedok typu dataConnectors. Táto hranica je dôležitá pre nasadenie, audit aj odstraňovanie problémov: dva účty nie sú jedna spoločná sada prihlasovacích údajov.

Jednotlivé pripojenia sa dotazujú nezávisle. Ak majú dáta spoločnú tabuľku, analytické pravidlá a hunting dotazy musia poznať pole, podľa ktorého odlíšia zdrojový účet alebo tenant. Bez toho môže prehľad vyzerať úplne, ale analytik nevie, ku ktorej organizačnej hranici udalosť patrí.

Čo novinka nerieši za vás

• nevytvorí oprávnenia v zdrojovej službe a nezvolí princíp najmenších oprávnení;
• neodstráni limity a podmienky API poskytovateľa;
• nezaručí, že spoločné detekčné pravidlo správne rozlíši všetky účty;
• nezastaví rast objemu a ceny ingestovaných dát;
• nenahradí monitoring stavu konektora, oneskorenia ani chýb autentifikácie;
• neznamená, že rovnaký postup podporuje každý iný Sentinel konektor.

Praktický postup pred druhým pripojením

1. Spíšte účty a vlastníkov. Pri každom zdroji uveďte prostredie, obchodného vlastníka, bezpečnostný tím a osobu zodpovednú za prístup.
2. Navrhnite jednoznačný identifikátor. Overte, ktoré pole v cieľovej tabuľke označuje účet, tenant alebo iný zdrojový kontext a či je vyplnené vo všetkých udalostiach.
3. Pripravte samostatné poverenia. Nepoužívajte zdieľané tajomstvo bez vlastníka. Oprávnenia obmedzte na to, čo konektor potrebuje, a zapíšte proces rotácie.
4. Otestujte jeden účet. Skontrolujte prvú a poslednú udalosť, čas ingestie, očakávané typy záznamov a prípadné medzery.
5. Zmerajte denný objem. Pilot poskytne vstup pre odhad ingestie, retencie a zaťaženia dotazov. Odhad následne porovnajte so skutočnosťou.
6. Preverte API limity. Každé pripojenie dotazuje zdroj nezávisle, preto viac pripojení môže zvýšiť počet volaní voči rovnakému API.
7. Upravte detekcie. Do hunting dotazov, analytických pravidiel a dashboardov pridajte kontext zdrojového účtu tam, kde je rozhodujúci.
8. Pripravte návratový krok. Určte, ako jedno pripojenie odstavíte bez vymazania histórie alebo prerušenia ostatných účtov.

Náklady, limity a kvalita dát

Microsoft pri vzore neuvádza osobitný pevný limit počtu pripojení pre konektor, ale výslovne odporúča overiť škálovanie v prostredí. Praktickou hranicou môže byť zdrojové API, objem dát, limity platformy alebo čas spracovania. Formulácia „bez osobitného limitu“ preto nie je prísľub neobmedzenej kapacity.

Každé pripojenie zvyšuje počet nezávislých polling operácií. Ak nový účet generuje ďalšie udalosti, rastie aj ingescia a potenciálne náklady. Pred produkciou sledujte počet záznamov podľa účtu, oneskorenie, chyby konektora a náklady za rovnaké obdobie. Spoločná tabuľka šetrí fragmentáciu schémy, ale vyžaduje disciplinované filtrovanie.

Bezpečnostné hranice

Tajomstvá, tokeny a kľúče nepatria do tiketov, wiki ani auditných súhrnov. Ukladajte ich v určenom úložisku tajomstiev, obmedzte prístup a rotujte ich podľa politiky zdrojovej služby. Pri ukončení účtu odstráňte iba príslušné pripojenie a poverenia; spoločné komponenty môžu stále používať ďalšie pripojenia.

Pre kritické zdroje testujte aj negatívny scenár: expirované poverenie, throttling API, neúplná odpoveď a oneskorené dáta. Stav „Connected“ sám osebe nedokazuje, že do tabuľky prichádzajú všetky očakávané udalosti.

Kontrolný zoznam pre správcu

• je pri každom pripojení viditeľný vlastník a zdrojový účet;
• má každé pripojenie minimálne potrebné oprávnenia a vlastnú rotáciu poverení;
• dokážete v tabuľke oddeliť udalosti podľa účtu;
• obsahujú detekcie správny kontext a neagregujú nesúvisiace tenanty;
• sledujete objem, oneskorenie, chyby, API limity a náklady;
• je zdokumentované bezpečné odpojenie jedného účtu.

Kedy zapojiť odborníka

Viac účtov v jednom pracovisku má hodnotu iba vtedy, keď zostane zrozumiteľná hranica dát a zodpovednosti. Yenwa pri kybernetickej bezpečnosti pomáha navrhnúť zdroje, detekcie a prevádzkové kontroly. Pri cloudových službách vieme pripraviť pilot, odhad ingestie a overenie, že centralizácia nepriniesla slepé miesto.

Centralizujte pohľad, nie nejasnosť. Každú udalosť musí byť možné priradiť k správnemu zdroju, vlastníkovi a pripojeniu.