Integrált információbiztonsági kezelés lazán összekapcsolt információs rendszerekben

Oleg Lekshin,
Valerii Andreev

Az információvédelem összetett kérdés

A nyílt rendszerek elképzelései lendületet adtak a meglévő információs infrastruktúra elosztott számítástechnikájának biztosítására szolgáló hálózati-központú technológiák fejlesztéséhez. Itt egy egyszerű távoli eljárás útvonala az építészeti megoldások felé vezetett. Azt mondhatjuk, hogy a teremtés korona ezen a területen a szolgáltatásorientált architektúra (SOA). Azoknál a rendszerekben, amelyek fejlesztői a SOA koncepciójának elveihez ragaszkodnak, kezdetben számos szabványos probléma megoldására kerül sor. A rendszer (szolgáltatások) független, kiosztott elemei lazán kapcsolódnak egymáshoz. Feladata az, hogy biztonságosan visszaadja az eredményt a kezdeti adatoknak és a szolgáltatás alkalmazási összetevőjének megvalósításának megfelelően. Ez egyrészt nagymértékben növeli a rendszer rugalmasságát, másrészt nagyon megnehezíti az egész rendszer, és különösen a biztonsági menedzsment kezelését.

Mint ismeretes, az információvédelem egy összetett kérdés. Technikai szinten a következő feladatok megkülönböztethetők összetételében:
  • az ügyfél (felhasználó vagy ügynök) azonosítása a rendszerben;
  • a védett adatok hozzáférési jogainak ellenőrzése egy érvényes (rendszerszintű) biztonsági kontextus keretében;
  • az ügyfelek és az IS szolgáltatások közötti forgalom titkosítása;
  • az adatok integritásának biztosítása.

Webszolgáltatások szabványok csoportjai

Napjainkig a lazán összekapcsolt IP-kben az információvédelem számos problémája jól fejlett. A webes szolgáltatások technológiája, amely jelenleg valójában az egyetlen általánosan elfogadott SOA-implementáció, szinte teljesen szabványosított, beleértve az információbiztonságot is. Számos specifikációs készlet írja le, hogyan oldhatja meg a fent említett feladatokat a webes szolgáltatások tekintetében. Az első csoport a GXA (Global XML Web Services Architecture) családra vonatkozik, és tartalmazza a WS- * sorozat specifikációit. A második készlet az OASIS által kifejlesztett és a Sun Microsystems és az Oracle által támogatott szabványok SAML (Security Assertion Markup Language) és XACML (extensible Access Control Markup Language) csoportjából áll.

A felsorolt ​​szabványok két alapvető feladatot oldanak meg:
  1. Megbízható adatcsere-környezet létrehozása, amely biztosítja a továbbított információk titkosságát, integritását és hitelességét.
  2. Egyetlen biztonsági környezet elosztása lazán összekapcsolt számítástechnikai környezetben, egyfelhasználós hitelesítéssel (Single Sign-On, SSO).

A SOA szigorú biztonsági bizonyítékainak problémája

Az említett szabványosított megoldások nem terjednek ki a hozzáférés-szabályozási szabályok (APP-k) kezelése minden kérdésére a lazán összekapcsolt rendszerekben. Azt mondhatjuk, hogy általában csak az alkalmazásokhoz (szolgáltatásokhoz) és az ezekhez az információs objektumokhoz való hozzáférést ellenőrző feladatok megoldására van szükség. Azonban általában ezek az információs objektumok az alacsony szintű primer források, például a fájlok és adatbázisok, valamint esetleg egyéb információforrások összetett adatátalakulása eredményeként jönnek létre. Az ilyen átalakítások magukban foglalják az alkalmazás üzleti logikáját. Függetlenül attól, hogy a DTD IS modellje milyen tulajdonságokkal rendelkezik a másodlagos erőforrásokhoz, lehetetlen beszélni az IS biztonságának szigorú bizonyításáról anélkül, hogy bármilyen formális bizonyíték lenne arra, hogy a végrehajtás megfelel az adott információs modellnek.

A második pont, amely nem teszi lehetővé az itt leírt rendszerek biztonságosságának szigorú bizonyítékát, az, hogy egy adott rendszerhasználó nevében futó ugyanaz a folyamat (az alkalmazáskiszolgáló) elérheti a valódi elsődleges erőforrást. A biztonsági rendszer képes ellenőrizni, hogy ki küldte a kérelmet az alkalmazásnak, de a biztonsági környezetnek az elsődleges forrásokhoz való hozzáférést biztosító környezet átvitelére szolgáló mechanizmusok általában hiányoznak, azt mondják: "nem örökölnek".

Emlékezzünk vissza, hogy az IS-ben szigorúan kimutatható biztonsággal a DSP ilyen ellenőrzési rendszereit kell használni, amelyek matematikailag bizonyították, hogy a felhasználó nem tudja javítani a hozzáférési szintjét anélkül, hogy erre jogában állna. Néha a biztonság szigorú bizonyítása nem szükséges. Ezek a rendszerek az IP-t egy probabilisztikus információbiztonsági modellel (IB) foglalják magukban, amelyben a sikeres gyakorlatokon alapuló IB kockázatkezelés megvalósul.

Vannak azonban olyan rendszerek, amelyekben a feldolgozott információk kritikussága olyan magas, hogy a megfelelő védelmi eszközök maximális hatékonysága szükséges az IC működésének minden szintjén. Mindenekelőtt ez olyan információra utal, amely az Orosz Föderáció államtitkává válik, valamint bizonyos korlátozott hozzáférésű információk, például személyes adatok. Az ilyen rendszerek létrehozásánál, még a tanúsított integrációs technológiák és architektúrák használatánál is, nemcsak a be nem jelentett képességek hiányának igazolását kell elvégeznie az alkalmazott problémákban, hanem a bejelentett tulajdonságok szigorú megfeleltetését is bizonyítani kell a rendszer információs modelljéhez. Ezután, ha erős bizonyítékot szolgáltat a rendszer biztonságára, az információs modelltől és a szolgáltatások konkrét megvalósításától függetlenül jelentősen csökkentheti az alkalmazásrétegre vonatkozó biztonsági követelményeket. A probléma ilyen formában történő megoldása érdekében még mindig szükséges az IS modell komoly tanulmányozása lazán összekapcsolt információs rendszerekben.

A SOA központi eleme vállalati szervizbusz (ESB) vagy gerinchálózat

Az ESB egyúttal a szolgáltatások közötti információcsere is, valamint a rendszerben ellenőrző link, amely biztosítja az egységesített biztonsági protokoll egységes biztonsági politikájának megvalósítását.

Formázzunk követelményeket az ESB-nek, amelynek végrehajtása lehetővé teszi az információs rendszer SOA-infrastruktúrájának szigorúan bizonyítható biztonsággal történő létrehozását anélkül, hogy figyelembe vesszük az alkalmazott elemek üzleti logikájának jellemzőit:
  1. A TPS irányítási rendszerének megvalósítása, amely az elsődleges és másodlagos információs forrásokhoz való hozzáférés valamennyi alapvető eszközt magában foglalja egyetlen ellenőrző központból, a TDP egységesített bővíthető kontrollmodellje keretében. Ezenkívül szükség van a felhasználói hitelesítő adatok (a hozzáférési réteg "öröklése") szinkronizálására az ESB-ben és a hozzá kapcsolódó rendszerekben.
  2. Annak biztosítása, hogy az adatbeviteli folyamatot a folyamatot kezdeményező felhasználóhoz tartozó biztonsági környezetben végezze el, függetlenül attól, hogy a felhasználó helyi vagy távoli-e (felhasználói virtualizáció).
Az első követelmény megvalósítása az identitáskezelő rendszerek (Identity Management) széles osztályának tulajdonítható. A második követelmény teljesítése érdekében szükség van az ESB mélyreható integrálására a számítástechnikai folyamatban az információcsere során részt vevő SOA infrastruktúra valamennyi elemére.

"IVK Jupiter ™"

Sok éven át a vállalat háromlépcsős architektúrában végez kutatásokat az információvédelem területén, valamint az IVK Jupiter ™ terméken alapuló alkalmazott SOA megoldások fejlesztését.

"JVP Jupiter ™ Identity Manager"

A „CPI Jupiter ™ IM” is végrehajtották fontos lehetőség, hogy állapotának nyomon követéséhez felhasználói munkamenetek a társított alkalmazásban és befejezését az ezen ülések kijáratánál tisztviselőjének a fő kezelőszerveket, - a rendszer „CPI ™ Jupiter”.

Annak a ténynek köszönhetően, hogy az IP-k alrendszerekre való átvitele átlátható a felhasználók számára, a "JVI Jupiter ™ IM" alkalmazási szintű biztonsági szervernek tekinthető, amely korlátozza az IP-alkalmazásokhoz való hozzáférést. A hozzáférés tilalmát az a tény biztosítja, hogy a tisztviselők nem rendelkeznek információval az egyes alrendszerek IP-jéről.

Az IPC Jupiter ™ IM tárolóként szabványos DBMS-t használhat, beleértve az Oracle-t is, valamint egy JVP Jupiter ™ beépített biztonságos adattárolót.

Jelenleg munka pedig elkészült az integrációs beléptető rendszerek, „VCI Jupiter ™ IM” és a legfontosabb az egész rendszerre kiterjedő -SUBD (Oracle, stb), a Microsoft Active Directory és LDAP. A kihívásoknak lehetőséget fog biztosítani az építési termékek alapján a „CPI Jupiter ™” és „CPI Jupiter ™ IM” egy teljes integrált biztonsági politika menedzsment az egész információs rendszer és annak alkalmazása alkatrészeket.

Integrált információbiztonsági kezelés lazán összekapcsolt információs rendszerekben