Őrjárat-ellenőrző rendszer saját szerveren: Enterprise telepítés, szerverméretezés és egyedi fejlesztés

A fontosabb kérdés:

Hogyan működik a biztonsági szolgálat, naponta mennyi adatot hoz létre, mennyi ideig kell ezeket az adatokat megőrizni, és milyen folyamatokat kell a rendszernek ellenőriznie vagy automatizálnia?

Ez azért fontos, mert két azonos számú telephelyet kezelő vállalat teljesen eltérő rendszerterhelést generálhat. Az egyiknél telephelyenként két őr dolgozik, a másiknál több tucat. Az egyik rendszerben napi néhány kép készül, a másikban több ezer.

Enterprise környezetben pedig gyakran maga a működési folyamat is egyedi.

A Trinity Guard standard szolgáltatása felhőalapú, ezért a normál használathoz nincs szükség saját szerverre. Nagyvállalati, kritikus infrastruktúrához kapcsolódó vagy speciális informatikai igények esetén azonban kialakítható saját infrastruktúrán működő Enterprise telepítés is.

Mit jelent valóban az on-premise működés?

On-premise telepítésnél a szerveroldali rendszer az ügyfél által kontrollált infrastruktúrán működik.

Ez lehet:

• saját adatközpontban lévő fizikai szerver;
• vállalati virtualizált szerverkörnyezet;
• vagy más, az ügyfél IT-részlege által felügyelt infrastruktúra.

A lényeg nem egyszerűen az, hogy hol áll a szerver.

Az a kérdés, hogy ki kontrollálja az infrastruktúrát, a hálózatot, a hozzáféréseket és a rajta tárolt adatokat.

Ez fontos lehet olyan szervezeteknél, ahol szigorú adatkezelési, kiberbiztonsági vagy belső IT-szabályok vonatkoznak a biztonsági rendszerekre.

Egy saját szerveres rendszer ugyanakkor nem lesz automatikusan biztonságos csak azért, mert az ügyfél telephelyén működik. A hozzáférés-kezelést, mentést, hálózati védelmet és változáskezelést ugyanúgy megfelelően kell kialakítani.

A szervert ne a telephelyek száma alapján méretezzük

Ez az egyik legfontosabb szabály.

A szerver tényleges terhelését sokkal inkább meghatározza:

• a napi felhasználói aktivitás;
• a járőrözések száma;
• a GPS- és QR-ellenőrzési események száma;
• az incidensek;
• a fényképek;
• a jármű-be- és kiléptetési események;
• az automatikus riasztások;
• az adatmegőrzési idő;
• az integrációk;
• és a várható jövőbeni növekedés.

A strukturált adatok – például időpontok, koordináták és eseménynaplók – viszonylag kevés tárhelyet igényelnek.

A jelentős tárhelyigényt általában a fényképek okozzák.

Egy egyszerű nagyvállalati példa

Tegyük fel, hogy egy rendszer naponta körülbelül:

Ha egy fénykép átlagosan 2–3 MB, akkor csak a képek körülbelül 3,4–5,1 GB adatot jelenthetnek naponta.

Az adatbázis, GPS-adatok, naplók és egyéb metaadatok hozzáadásával ebben a példában a napi adatmennyiség megközelítheti az:

5,6 GB / nap értéket.

Innen már könnyen látható, hogy az adatmegőrzési idő milyen jelentős tényező.

És ebben még nincs teljes egészében benne:

• a növekedési tartalék;
• az operációs rendszer;
• az adatbázis számára szükséges szabad hely;
• valamint a biztonsági mentés.

Előbb tehát az adatmegőrzési szabályokat kell meghatározni, és csak utána érdemes a tárhelyet kiválasztani.

Mekkora szerver kell egy Enterprise őrjárat-ellenőrző rendszerhez?

Nincs minden projektre érvényes univerzális Trinity Guard szerverkonfiguráció.

Egy nagyobb telepítésnél kiindulási alap lehet például:

• legalább 8 CPU-mag;
• 16–32 GB RAM;
• később bővíthető memória;
• megfelelő kapacitású SSD-tárhely;
• redundáns háttértár;
• támogatott Linux-környezet.

A végleges konfigurációt azonban mindig a tényleges projekt alapján kell meghatározni.

Ha a rendszer például napi 300 járőrözés helyett néhány év múlva napi 3000-et kezel, a korábban elegendő hardver már nem feltétlenül lesz megfelelő.

Enterprise rendszer esetében ezért nemcsak a jelenlegi terhelésre, hanem a növekedésre és a későbbi egyedi funkciókra is érdemes tartalékot tervezni.

RAID és biztonsági mentés

Redundáns háttértár használata ajánlott, mert egy őrjárat-ellenőrző rendszerben az adatok egy korábbi biztonsági esemény bizonyítékai is lehetnek.

Fontos azonban:

a RAID nem biztonsági mentés.

A RAID segíthet egy meghajtó meghibásodásakor, de nem véd például:

• véletlen törlés;
• adatbázis-sérülés;
• ransomware;
• vagy emberi hiba

ellen.

Ezért külön mentési és helyreállítási stratégiára is szükség van.

Nem minden nagyvállalatnak ugyanazt a folyamatot kell digitalizálni

Az Enterprise rendszer egyik legnagyobb előnye éppen az lehet, hogy nem feltétlenül egyetlen előre meghatározott működési modellt kell minden szervezetre ráerőltetni.

Egy vállalat klasszikus őrjárat-ellenőrzést szeretne.

Egy másik számára az a legfontosabb, hogy a diszpécser központilag lássa:

megtörtént-e a szolgálatba lépés azon a helyen és akkor, amikor annak meg kellett történnie.

Más szervezeteknél szükség lehet például:

• mobilalkalmazásos be- és kijelentkezésre;
• GPS-alapú helyszíni ellenőrzésre;
• valós idejű diszpécseri állapotokra;
• meghatározott időponthoz kötött eseményekre;
• elmaradt esemény esetén automatikus riasztásra;
• közös telephelyi készülék használatára;
• több műszak vagy 24 órás szolgálat kezelésére;
• manuális és digitális jelentési folyamatok párhuzamos kezelésére.

Ezek nem automatikusan a standard Trinity Guard rendszer funkciói, hanem olyan vállalati működési igények, amelyek egy Enterprise projekt során külön vizsgálhatók és – megfelelő műszaki feltételek mellett – egyedi megoldásként kialakíthatók.

GPS-ellenőrzés folyamatos követés nélkül

Egy szolgálati helyszín ellenőrzéséhez nem minden esetben van szükség folyamatos háttérben történő GPS-követésre.

Lehetséges eseményalapú modell is:

felhasználói művelet → GPS-helyzet ellenőrzése → esemény rögzítése.

Ilyen esemény lehet például egy járőrpont teljesítése vagy egy külön kialakított Enterprise munkafolyamatban a szolgálat kezdete.

Ebben az esetben előre meg kell határozni:

• mikor történjen helyellenőrzés;
• milyen pontosság szükséges;
• milyen távolság fogadható el;
• mi történjen hiányzó GPS-adat esetén;
• hogyan viselkedjen a rendszer gyenge hálózati kapcsolat mellett.

Ez lényegesen eltér a munkavállalók folyamatos háttérben történő helymeghatározásától.

A diszpécseri felületnek a problémát kell megmutatnia

Ha egy központ több tucat vagy akár több száz telephelyet figyel, nem elegendő egyszerűen adatokat megjeleníteni.

A rendszernek lehetőleg azt kell kiemelnie, ahol valami nem a tervek szerint történt.

Egy Enterprise diszpécseri folyamatban például megkülönböztethető:

• teljesített esemény;
• még várható esemény;
• késés;
• elmaradt jelentkezés;
• riasztást igénylő állapot.

Ha például egy adott telephelyen 18:00 órakor szolgálatkezdésnek kell történnie, meghatározható egy toleranciaidő.

Ha az esemény megtörténik, a státusz megfelelőre változik.

Ha nem történik meg, a rendszer – az adott projekt szabályai szerint – riasztást indíthat.

A cél nem az, hogy a diszpécser több száz sort figyeljen.

A rendszernek kell jeleznie, hol szükséges emberi beavatkozás.

A digitalizáció nem mindig történik egy lépésben

Nagy szervezeteknél gyakori, hogy a telephelyek nem egyszerre térnek át új működésre.

Előfordulhat, hogy:

• egyes helyszínek már mobilalkalmazást használnak;
• más helyszínek még telefonon jelentenek;
• bizonyos események automatikusan érkeznek;
• másokat a diszpécser rögzít manuálisan.

Egy Enterprise rendszer kialakításakor ezért a fokozatos átállás is fontos szempont lehet.

A cél nem feltétlenül az, hogy a meglévő működést egyik napról a másikra lecseréljük.

Sokkal inkább az, hogy a digitalizáció kontrolláltan, a szervezet valós működéséhez igazodva történjen.

Egyedi fejlesztések: nyitottak vagyunk, de nem minden ötletből lesz funkció

Enterprise projektekben szinte mindig felmerülnek olyan működési igények, amelyek nem részei a standard rendszernek.

A Trinity Guard nem zárkózik el egyedi fejlesztési ötletektől, munkafolyamatoktól vagy integrációktól.

Ezeket azonban minden esetben megvizsgáljuk.

Három kérdés különösen fontos:

Szakmailag korrekt?

A fejlesztés valódi biztonsági vagy működési problémát old meg?

Egy rosszul kialakított folyamat digitalizálása nem feltétlenül javítja magát a folyamatot.

Elfogadható?

Megfelel az adatvédelmi, biztonsági, jogosultsági és üzemeltetési követelményeknek?

Ténylegesen kivitelezhető?

Megvalósítható az adott mobilplatformon, hálózati környezetben és szerverarchitektúrán?

Fenntartható és támogatható hosszú távon?

Ezért egy egyedi fejlesztési kérésre adott válaszunk nem automatikusan igen, de nem is automatikusan nem.

Először meg kell érteni a problémát.

Ha az elképzelést szakmailag korrektnek, elfogadhatónak és – nem kevésbé fontos módon – ténylegesen kivitelezhetőnek találjuk, egyedi fejlesztési projektként megvalósítható.

Saját szerver, hálózati kontroll és hozzáférés

On-premise telepítésnél az ügyfél saját IT- és kiberbiztonsági szabályai meghatározóak.

Az ügyfél kontrollálhatja többek között:

• a tűzfalszabályokat;
• a hálózati szegmentációt;
• a VPN-hozzáférést;
• az adminisztratív jogosultságokat;
• a távoli támogatás módját.

A Trinity Guard meghatározhatja a rendszer működéséhez szükséges technikai követelményeket, de az ügyfél infrastruktúráján szerveroldali beavatkozás csak az előre meghatározott szabályok szerint történhet.

Nagyvállalati környezetben ez jelenthet:

• előzetes jóváhagyást;
• karbantartási időablakot;
• naplózott hozzáférést;
• változáskezelési folyamatot;
• visszaállítási tervet.

Működhet teljesen internet nélkül?

Az on-premise szerver elhelyezhető elkülönített vállalati hálózatban.

A teljesen izolált működés azonban külön műszaki kérdés.

Már a projekt tervezésekor tisztázni kell:

• hogyan kommunikálnak a mobil eszközök;
• mely funkciók igényelnek külső kapcsolatot;
• vannak-e külső szolgáltatások vagy integrációk;
• hogyan történnek az alkalmazásfrissítések;
• milyen hálózati korlátozások vannak.

Ha teljesen leválasztott infrastruktúra a követelmény, ezt még az architektúra kialakítása előtt meg kell vizsgálni.

Egyszeri licenc vagy előfizetés?

A Trinity Guard standard felhőalapú szolgáltatásánál az előfizetéses modell természetes.

Saját szerveres Enterprise telepítés esetén azonban más konstrukció – például egyszeri, tartós használati jogot biztosító licenc – is kialakítható.

A konkrét szerződésben egyértelműen meg kell határozni, hogy mi tartozik bele:

• a telepített verzió használata;
• támogatás;
• jövőbeni főverziók;
• új modulok;
• szerveroldali módosítások;
• migráció;
• egyedi fejlesztések.

Az egyszeri licenc tehát nem feltétlenül jelent automatikusan korlátlan jövőbeni fejlesztést vagy támogatást.

Mit kell tudnunk egy Enterprise ajánlat elkészítéséhez?

Egy pontos műszaki és kereskedelmi ajánlathoz általában az alábbi kérdésekre van szükség:

1. Hány telephely indul az első ütemben?
2. Hány felhasználó használja a rendszert?
3. Mekkora a napi járőrözési és eseményszám?
4. Körülbelül hány fénykép készül naponta?
5. Mennyi ideig kell az adatokat megőrizni?
6. Mekkora növekedés várható a következő években?
7. Szükséges-e központi diszpécseri ellenőrzés vagy egyedi riasztási logika?
8. Vannak-e speciális munkafolyamatok vagy integrációs igények?
9. Ki biztosítja és üzemelteti a szervert?
10. Milyen hálózati, hozzáférési és biztonsági korlátozások vannak?

Ezek alapján nemcsak a szerver mérete, hanem maga a megfelelő rendszerarchitektúra is meghatározható.

Gyakran ismételt kérdések