Védje SAP környezetét a migráció előtt, alatt és után

Mi az SAP programjuk biztonsági üzemeltetési és infrastruktúra-biztonsági partnere vagyunk. Nem vagyunk SAP alkalmazásbiztonsági szakértők, és érdemes gyanakodva fogadni bárkit, aki mindkettőt állítja magáról.

A basis csapatuké az, ami az SAP-n belül történik: szerepek és jogosultságok, transzportok, RFC- és gateway-beállítások, az alkalmazásszintű audit napló. A felhőszolgáltatójuké az operációs rendszer alatti platform. Az integrátoruké a konverzió.

Ami kettejük között van — és amit a három közül egyik sem vállal szerződésben —, az a biztonsági üzemeltetési réteg: a célarchitektúra és a hozzáférési útvonalak független átvizsgálása, a konfiguráció keményítése publikált benchmarkokhoz mérve, a SIEM felépítése és a bele kerülő detektálási tartalom, valamint az SAP-rendszereik alatt futó azonosítási, végponti, felhőinfrastruktúra- és hálózati telemetria 24/7-es felügyelete és a rá adott válasz.

A legtöbb migrációs programban ez valódi hézag. Egyben szűkebb állítás is annál, amit ez az oldal korábban megfogalmazott.

Nem. A naplók gyűjtése és tárolása az Önök saját Microsoft Azure környezetében történik. Önöké a munkaterület, Önöké az előfizetés, és közvetlenül a Microsoftnak fizetnek a betöltésért és a tárolásért ahelyett, hogy egy szállítónak fizetnének az adataik őrzéséért.

Az elemzők úgy férnek az adathoz, hogy delegált adminisztratív hozzáférést kapnak az Önök bérleményébe — nem úgy, hogy az adataik egy szállítói adattóba kerülnek. Ugyanez igaz a Sentinel példányra akkor is, amikor mi építjük: az Önök Azure-előfizetésében, egyetlen címtáron belül jön létre.

Ez az a része a szolgáltatásnak, amely a legkeményebb jogi átvizsgálást is kiállja, ezért érdemes pontosan fogalmazni: nem az adat mozog, hanem a hozzáférés.

Az alatta lévő infrastruktúrát, hacsak nem bővítik ezt szándékosan. Erre a kérdésre az oldal korábban rosszul válaszolt, úgyhogy itt van kertelés nélkül.

Alapesetben az azonosítás és hitelesítés, a végponti és szerveroldali telemetria, a felhőinfrastruktúra tevékenysége és a hálózati perem kerül felügyelet alá. A szolgáltatás legalább három minősülő gyűjtési forrástípust igényel ahhoz, hogy egyáltalán szolgáltatási szintet vállaljon — végponti láthatóság, felhasználói hitelesítés és hozzáférés, valamint címfeloldás —, és egy ERP alkalmazásnapló nem tartozik ezek közé. A kizárólag Microsoft-natív változatban nem Microsoft-forrás egyáltalán nem tölthető be.

Az SAP saját naplói behozhatók, egyedi forrásként: az Önök rendszerparkjára épített konnektorral és parserrel, hozzá írt detektálási tartalommal, önálló munkaként meghatározva és beárazva. És ez a lényeges rész: az a naplóforrás, amely ott ül a Sentinel munkaterületükön, de nincs felügyeletre előfizetve, kifejezetten hatókörön kívül esik a riasztás és a vizsgálat szempontjából. „Az SAP naplóik bent vannak a Sentinelben” és „az SAP-juk felügyelet alatt áll” két különböző állítás. Minden megkérdezett szállítóval mondassák ki, melyikre gondol.

A vállalásról: a szerződéses szolgáltatási szint egyetlen reagálási idő — 15 perc, minden súlyossági szintre ugyanaz —, az incidens platformon való létrejöttétől az első triázs és besorolás lezárultáig mérve, a folyamat automatizált részét is beleértve. Arra vállal kötelezettséget, hogy milyen gyorsan lesz egy riasztásból besorolt incidens; arra nem, hogy mikor szólunk, és a feltartóztatásra sem — az értesítést és az eszkalációt a megrendelésben rögzítjük, nem szerződéses szintként. Szerződéses felderítési idő sincs — ilyet tisztességgel senki nem tud eladni. A kárelhárítás és a helyreállítás végrehajtása pedig az Önöké; mi vizsgálunk, besorolunk, tanácsot adunk és végigkísérjük.

Úgy, hogy a megrendelésben ehhez igazítjuk az ütemezést, nem pedig utólag szembesülünk vele — és van egy konkrét kikötés, amelyet aláírás előtt ismerniük kell.

A felügyeleti szerződések megkövetelik, hogy a naplóforrásaik a SOC élesindulásától számított 30 napon belül bekötésre és integrálásra kerüljenek. Az a forrás, amelyhez ennél több idő kell, külön tanácsadási szerződésbe tolja a munkát. Egy egy hónapnál hosszabb fagyasztás, vagy egy jóval a cutover előtt aláírt felügyeleti szerződés tehát egyenesen ütközik ezzel az órával. Ez teljesen kezelhető, de csak akkor, ha a SOC élesindulás dátumát a megrendeléskor tudatosan az Önök fagyasztási ablakaihoz választjuk.

Amit nem fogunk tenni: mechanizmust kitalálni. Valódi cutover programtapasztalatunk van — cutover tervezés, cutover governance és felelősségi mátrix SAP core, szatellit és infrastruktúra munkafolyamokon át, nagy transzformációs programokban —, de ez programmenedzsment, nem pedig dokumentált fagyasztás alatti biztonsági eljárás. Inkább megmondjuk, hol harap a szerződés, mint hogy leírjunk egy folyamatot, amelyet soha nem fektettünk papírra.

Igen, leírjuk, és nincs előre gyártott válaszunk, amelyet még azelőtt a kezükbe nyomnánk, hogy megnéztük volna.

Amit a szerződéses szerkezet már eleve rögzít: a platformlicenceket és a felhőfogyasztást Önök biztosítják és fizetik; Önök engedélyezik a naplózást a hatókörbe vont rendszereken, és Önök végzik el a naplók továbbításához szükséges hálózati változtatásokat; a szolgáltatási szintek pedig nem vonatkoznak harmadik féltől származó SaaS- vagy felhőinfrastruktúra-szolgáltatók kiesésére. Ennek a RISE-környezetre vonatkozó közvetlen következménye, hogy bármely olyan komponens, amelynek naplóihoz nem férünk hozzá, vagy amelynek szolgáltatója maga áll le, kívül esik minden vállaláson, amelyet meg tudunk tenni. Ezt inkább kimondjuk, mint hogy egy incidens közben derüljön ki.

Az a leszállítandó, amelyhez tartjuk magunkat, egy forrásonkénti lista: mi van hatókörben és felügyelet alatt, mi az, ami betöltésre kerül, de nincs előfizetve, és mi tartozik az SAP-hoz vagy a felhőszolgáltatóhoz, nem pedig hozzánk. Megosztott felelősségű környezetben ez a lista lényegesen többet ér egy architektúraábránál, és ezt érdemes minden ajánlattevőtől elkérni.

Dokumentumokat, nem megnyugtatást. A felmérés eredményét és a hézagjegyzékét; a publikált benchmarkokhoz mért keményítési jelentéseket, amelyek megnevezik a benchmarkot és az eredményt ahelyett, hogy egy állapotot kijelentenének; a detektálási és válaszadási runbookokat; valamint az előző válaszban említett felügyeleti hatókör-nyilatkozatot, amely gyakran a dosszié legtöbbet érő lapja, mert kimondja, mi van lefedve és mi nincs.

Két alátámasztó tény. A Spirity menedzselt biztonsági szolgáltatóként ISO/IEC 27001 tanúsítással rendelkezik, tehát a szolgáltatás tanúsított működésből érkezik. Tanácsadói gyakorlatunk pedig magát a felkészítési munkát is végzi: helyzet- és megfelelőségi felmérés, szabályzatok és eljárásrendek kidolgozása, hézagfeltárás és intézkedési terv NIS2, DORA és ISO 27001 mentén.

Amit viszont nem fogunk mondani: hogy ettől az SAP-környezetük „nem lesz hézag” a bizonyítékaikban. A felügyeleti szerződés szerint a megfelelőségi és szabályozási célú naplóarchiválás az Önök felelőssége, a védett adatok elfedése a SOC felé szintén az Önöké, a szolgáltató pedig elhárítja a felelősséget az Önök naplógyűjtési és -megőrzési megfelelőségéért. Mi bizonyítékot szolgáltatunk és kontrollhézagokat zárunk be. A környezetet nem tanúsítjuk — és aki mást állít, nem olvasta el a saját szerződését.

Inkább relevánsabb. Az oldal azért a migráció köré épül, mert egy SAP-környezet olyankor változik a leggyorsabban, és a hozzáférési útvonalai olyankor a legkitettebbek — de a munkafolyamok közül valójában csak egy migráció alakú.

A keményítés, a felügyelet, az incidensfelkészültség és a megfelelőségi illesztés állandó szolgáltatások. Egy migráció utáni környezetben ráadásul külön gond, hogy a program alatt hozott ideiglenes megoldások — a plusz kiemelt jogosultságú fiókok, az átmeneti hálózati útvonalak, a cutover kedvéért megnyitott tűzfalszabályok — általában túlélik az őket létrehozó programot, és már senki nincs, aki emlékezne rá, melyiknek kellett volna ideiglenesnek lennie.

A belépési pont mindkét esetben ugyanaz: előbb a felmérés, hogy ami utána jön, az Önök környezetére legyen szabva, ne egy sablonra.