ERP rendszerek biztonsága

Az ERP rendszerek biztonsága magában foglalja az ERP rendszereknek a rendszerhez való jogosulatlan hozzáféréstől való védelmét, valamint a rendszeradatok elérhetőségének és integritásának biztosítását szolgáló intézkedések széles körének alkalmazását . Az ERP-rendszer egy számítógépes program, amely a vállalat hatékony irányításához szükséges összes információ egyesítésére szolgál, beleértve a tevékenység olyan aspektusait, mint a termelés, az ellátási lánc menedzsment, a könyvelés, a raktárak, a szállítás, a személyzet és az ügyfélszolgálat. A legnépszerűbb ERP rendszerek az SAP , az Oracle E-Business Suite , a Microsoft Dynamics . Ezenkívül az 1C: Enterprise népszerű Oroszországban .

Áttekintés

Minden nagyvállalat magja az ERP rendszer; ez ad otthont minden üzleti szempontból kritikus folyamatnak, a beszerzéstől, a fizetéstől és a szállítástól az emberi erőforrás menedzsmentig, a termékmenedzsmentig és a pénzügyi tervezésig. Az ERP-rendszerekben tárolt összes információ rendkívül fontos, és az ezekhez való jogosulatlan hozzáférés óriási veszteségekkel járhat az üzlet leállásáig. [1] Fontos az ERP-rendszer átfogó biztonsági felmérése, amely során ellenőrizni kell, hogy az ERP-szervereken vannak-e szoftversérülékenységek, konfigurációs hibák, hatásköri ütközések, megfelelnek-e a jelenlegi szabványoknak és ajánlásoknak, beleértve a gyártói ajánlásokat is. [egy]

Az ERP-rendszerek sebezhetőségének okai

Nehézség

Az ERP rendszerek összetettsége biztonsági résekhez vezet. Az ERP rendszerek nagyszámú különböző tranzakciót dolgoznak fel, és olyan összetett mechanizmusokat valósítanak meg, amelyek különböző szintű hozzáférést biztosítanak a különböző felhasználók számára. Például az SAP R/3-ban több száz engedélyezési objektum található, amelyek lehetővé teszik a különböző felhasználók számára, hogy különböző műveleteket hajtsanak végre a rendszerben. Egy közepes méretű szervezetben körülbelül százféle tranzakció lehet, minden tranzakcióhoz általában legalább két jogosultsági objektum szükséges. Ha egy vállalatnak 200 felhasználója van, akkor körülbelül 800 000 (100*2*20*200) mód van az ERP rendszer biztonsági beállításainak konfigurálására. A komplexitás növekedésével nő a hibák és a hatalmi konfliktusok lehetősége is. [2]

Specificitás

A sebezhetőségeket havonta találják a népszerű operációs rendszerekben és alkalmazásokban, mivel ezek állandóan a hackerek látókörében vannak. Ennek eredményeként a népszerű alkalmazások biztonságosabbá válnak. A belső üzleti alkalmazások zárva vannak a kíváncsi szemek elől, és ez a "biztonságos, mert titkos" illúziójához vezet. Emiatt triviális és rendkívül veszélyes biztonsági réseket találnak bizonyos üzleti alkalmazásokban, amelyek ritkán találhatók meg a népszerű termékekben. [3]

Képzett szakemberek hiánya

A legtöbb ERP képzési program célja, hogy megtanítsa Önt a rendszer képességeinek használatára, és kevés hangsúlyt fektet az ERP biztonságra és auditálásra. [2] A legtöbb vállalatnál az ERP-rendszereket fenyegető biztonsági fenyegetések ismerete legfeljebb felületes. [4] Sok cég nem fordít kellő figyelmet az ERP rendszer biztonságára. A megvalósítási tanácsadók jellemzően csak a rendszer időbeni és költségkereten belüli üzembe helyezésével foglalkoznak. A biztonsági kérdések másodlagosnak számítanak. Emiatt a rendszer biztonsága gyenge, a biztonsági problémák azonosítása és kijavítása nehéz és költséges vállalkozás. [2]

Eszközök hiánya a biztonsági auditáláshoz

Az ERP-csomagokban található eszközök többsége nem biztosítja a rendszer biztonságának hatékony ellenőrzését. Emiatt az ERP rendszer biztonsági auditálása általában manuálisan történik. A kézi audit egy összetett és hosszadalmas folyamat, amelybe könnyű hibázni. [2]

Sok finomhangolás

A szabványos rendszerbeállításokban több ezer paraméter és finomhangolás található, beleértve a különböző objektumok, például tranzakciók és táblák jogainak megkülönböztetését. Ebben a rengeteg beállításban nem könnyű feladat egyetlen rendszer biztonságának biztosítása sem. Ráadásul az ERP rendszer beállításainak nagy része valahogy az ügyfélre van szabva, ennek következtében nincs két egyforma ERP rendszer. Emellett saját programjaik is kidolgozás alatt állnak, amelyek biztonságát is figyelembe kell venni egy átfogó értékelés során. [4] Emiatt nehéz egységes megközelítést vagy módszertant kialakítani a biztonsági auditok lefolytatására.

Biztonsági problémák az ERP-rendszerekben

Egy ERP-rendszer biztonsági problémái különböző szinteken fordulhatnak elő. [5]

Hálózati réteg

Lehetőség a forgalom elfogására és módosítására

2011-ben a Sensepost elemezte az SAP ERP által az ügyfél és az SAP szerver közötti adatátvitelre használt DIAG protokollt. Ennek eredményeként két segédprogramot tettek közzé, amelyek lehetővé teszik az érzékeny információkat tartalmazó kliens-szerver kérések teljes lehallgatását, visszafejtését és menet közbeni módosítását, ezáltal megnyílik az út a különböző emberközép támadásoknak . A második segédprogram proxyként működik, és inkább új sebezhetőségek felkutatására szolgál, lehetővé téve az ügyfelek és a kiszolgálók kérésének módosítását, valamint új sebezhetőségek keresését. [6] [7]

Az SAP ERP rendszer Telnet adminisztrációs opcióval rendelkezik , amely nem titkosítja a jelszavakat. [nyolc]

A titkosítási vagy hitelesítési protokollok biztonsági rései

A hálózati protokollok, például az SAP ERP RFC protokollja és az Oracle Net az Oracle e-Business Suite biztonsági rései. Az SAP ERP RFC (Remote Function Call) segítségével kommunikál két rendszer között TCP/IP-n keresztül. Az RFC hívás olyan függvény, amely egy másik rendszeren található funkciómodult hívhat meg és hajthat végre. Az ABAP nyelv, amelyet üzleti alkalmazások SAP-ban való írására használnak, rendelkezik RFC-hívások kezdeményezésére. Számos súlyos sebezhetőséget találtak az SAP RFC Library 6.x és 7.x verzióiban [9] :

OS szint

OS szoftver sebezhetőségei

Gyenge operációs rendszer jelszavak

Nem biztonságos operációs rendszer beállításai

DBMS sebezhetőségek [10]

Minden ERP rendszer sok adatbázist tartalmaz. Ezért az egyik ERP biztonsági probléma a DBMS-szoftver sebezhetősége.

A puffertúlcsordulás egy olyan támadás, amely azon alapul, hogy a program adatokat ír a memóriába a számukra lefoglalt pufferen kívül. Ez lehetővé teszi a támadók számára, hogy tetszőleges gépi kódot töltsenek le és hajtsanak végre a program nevében és annak a fióknak a jogaival, amelyen az fut.

A format string egyfajta sebezhetőség, amely lehetővé teszi rosszindulatú kódok futtatását. A probléma abból adódik, hogy szűretlen felhasználói bevitelt használunk formátum karakterláncként néhány C formázási függvényben, például a printf() . A támadók a %s vagy %n formátumspecifikációt használhatják tetszőleges adatok tetszőleges memóriahelyre írásához.

Az SQL-befecskendezés  az egyik legelterjedtebb módja az adatbázisokkal működő webhelyek és programok feltörésének, tetszőleges SQL-kód lekérdezésbe való beillesztésével. Az SQL-befecskendezés a használt DBMS típusától és az injektálás körülményeitől függően lehetővé teheti a támadó számára, hogy tetszőleges lekérdezést hajtson végre az adatbázisban (például beolvassa bármely tábla tartalmát, törölje, módosítsa vagy hozzáadja az adatokat), megszerezze a lehetőséget. helyi fájlok olvasásához és/vagy írásához, valamint tetszőleges parancsok végrehajtásához a támadott szerveren. Az SQL-lekérdezésekben használt bemeneti adatok helytelen feldolgozása miatt SQL-befecskendezési típusú támadás lehetséges.

Az SQL-ben a kurzor egy olyan szám, amely arra a helyre mutat a memóriában, ahol az adatbázis-kiszolgáló adatokat tárol a lekérdezésről, a lekérdezési változókról és az engedélyekről. Normál körülmények között a kurzor létrejön, és addig létezik, amíg kifejezetten meg nem semmisül. Ha hiba történik valamelyik SQL-eljárás végrehajtása során, a kurzor nem sérülhet meg. A támadó ezt a kurzorsort használhatja arra, hogy kérést tegyen a sikertelen eljárás jogával. [tizenegy]

Alkalmazás sebezhetőségei

Az ERP rendszerek egyre több funkcionalitást helyeznek át a webes alkalmazások szintjére, ahol rengeteg a sebezhetőség:

Szerep alapú hozzáférés-vezérlés

A legtöbb modern ERP-rendszerben annak érdekében, hogy a felhasználók csak szigorúan meghatározott tranzakciókat hajthassanak végre, és csak bizonyos üzleti objektumokhoz férhessenek hozzá, az RBAC-modellt (Szerep-alapú hozzáférés-vezérlés, szerep-alapú hozzáférés-vezérlés) használják. [12] Az RBAC modellben a felhasználók hozzáférésének megadásával kapcsolatos döntések a felhasználó szervezetben betöltött funkciói alapján születnek. Ezeket a függvényeket szerepeknek nevezzük. Például a bankban betöltött szerepek a pénztáros, a könyvelő, a hitelfelügyelő stb. A szerepkör alatt olyan tranzakciók összességét értjük, amelyeket egy felhasználó vagy felhasználói csoport végrehajthat egy szervezetben. A tranzakció egy eljárás a rendszerben lévő adatok átalakítására, valamint azokra az adatokra, amelyeken ez az eljárás végrehajtható. Minden szerepkör az ehhez a szerepkörhöz tartozó felhasználók egy csoportjának felel meg. Egy felhasználónak több szerepe is lehet. A szerepek lehetnek hierarchikusak, például a „pénztáros” szerepe egyben a „munkavállaló” szerepe is. Az RBAC modell egyik előnye az egyszerű adminisztráció. Miután a szerepek létrejöttek a rendszerben, az egyes szerepekhez tartozó tranzakciók ritkán változnak. A rendszergazdának csak felhasználókat kell hozzáadnia vagy eltávolítania a szerepkörökből. Amikor egy alkalmazott csatlakozik a szervezethez, az adminisztrátor tagságot ad neki egy vagy több szerepkörben. Amikor egy alkalmazott elhagyja a szervezetet, az adminisztrátor eltávolítja őt az összes olyan szerepkörből, amelyben volt. [13]

A hatáskörök szétválasztása

A hatáskörök szétválasztása (Separation / Segregation of Duties, SoD) - az a koncepció, hogy a felhasználó nem tud tranzakciót végrehajtani más felhasználók segítsége nélkül. Például egy felhasználó önmagában nem tud új beszállítót hozzáadni, számlát kiállítani vagy beszállítónak fizetni. Ez csökkenti a hiba vagy csalás kockázatát. [14] A SoD használata fontos, bár nem elégséges [3] feltétele egy ERP-rendszer biztonságának. A SoD-házirend RBAC-mechanizmusok segítségével valósítható meg. Ehhez bevezetik az egymást kizáró szerepek fogalmát. Például a szállító fizetéséhez az egyik felhasználónak kezdeményeznie kell a fizetést, a másiknak pedig meg kell erősítenie azt. Ebben az esetben a fizetés kezdeményezése és visszaigazolása egymást kizáró szerepek. A hatalmi ágak szétválasztása lehet statikus vagy dinamikus. A statikus SOD-ban egy felhasználó nem tartozhat két egymást kizáró szerepkörhöz. A hatalmi ágak dinamikus szétválasztásával (Dynamic SOD) egy felhasználó tartozhat két egymást kizáró szerepkörhöz, de nem hajthatja végre azokat ugyanazon a tranzakción belül. Az SSOD előnye az egyszerűség, a DSOD nagy rugalmasság. [15] A hatalmi ágak szétválasztását jellemzően az SoD mátrix írja le. A mátrix X és Y tengelye a rendszerben betöltött szerepeket jelenti. Ha két szerep kizárja egymást, akkor a megfelelő oszlop és sor metszéspontjában egy jelző kerül beállításra.

ERP biztonsági szkennerek

Az ERP System Security Scanner egy számítógépes program, amelyet az ERP rendszerek sebezhetőségeinek keresésére terveztek. A szkenner elemzi az ERP rendszer konfigurációját a nem biztonságos hitelesítés, hozzáférés-vezérlés, titkosítási beállítások szempontjából, ellenőrzi, hogy az összetevők legfrissebb verziói vannak-e telepítve, megkeresi az ismerten nem biztonságos rendszerelemeket. Ezenkívül a szkenner ellenőrzi a rendszerbeállításokat a gyártó ajánlásai és az ISACA ellenőrzési eljárásai alapján . A biztonsági szkenner eredménye egy jelentés, amely bemutatja az észlelt sebezhetőségeket és mindegyik kritikussági fokát. [1] Nevezetes szkennerek:

Jegyzetek

  1. 1 2 3 http://www.dsec.ru/products/erpscan Archiválva : 2012. október 10., Wayback Machine Digital Security
  2. 1 2 3 4 Archivált másolat (hivatkozás nem érhető el) . Letöltve: 2012. november 21. Az eredetiből archiválva : 2016. március 4..   Biztonsági problémák az ERP-ben
  3. 1 2 http://www.dsec.ru/press_releases/pdf/business.pdf  (elérhetetlen link)
  4. 1 2 SAP biztonság számokban / Digital Security Blog / Habrahabr . Letöltve: 2012. november 19. Az eredetiből archiválva : 2012. október 19..
  5. http://dsec.ru/press_releases/infosec2009/infosec2009_polyakov_erp.pdf  (hozzáférhetetlen hivatkozás) ERP biztonság
  6. A digitális biztonság új SAP DIAG protokoll veszélyeire figyelmeztet – ERPScan SAP Security Scanner (hivatkozás nem érhető el) . Letöltve: 2012. november 11. Az eredetiből archiválva : 2013. április 16.. 
  7. SensePost – SapCap Archiválva : 2012. október 29.
  8. Az SAP J2EE Engine adminisztrálása Telnet használatával (SAP Library – SAP NetWeaver Technical Operations Manual)
  9. Xakep Online > Az SAP RFC Library több biztonsági rése
  10. Alekszandr Poljakov (2009). Oracle biztonság egy auditor szemével. Támadás és védekezés. DMK Press. ISBN 978-5-94074-517-4
  11. Archivált másolat (a hivatkozás nem elérhető) . Letöltve: 2012. november 21. Az eredetiből archiválva : 2012. június 19.   Kurzor snarfing
  12. Archivált másolat . Letöltve: 2012. november 22. Az eredetiből archiválva : 2014. június 11.
  13. http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf Archiválva : 2011. október 18., a Wayback Machine Role-Based Access Controls- nál
  14. ComplianceTutorial.com – Hogyan építsük fel a feladatok elkülönítését Archiválva : 2013. január 11.
  15. Egyszerű keresés (nem elérhető link) . Letöltve: 2012. november 22. Az eredetiből archiválva : 2015. február 26..