Az 1c felhasználó ib egynél több elemnek felel meg. Felhasználói lista felállítása. A lemezen tárolt MS SQL adatok titkosítása

Ez a cikk ismét bemutatja, hogy minden biztonsági intézkedésnek le kell fednie a megvalósítás minden szakaszát: a fejlesztést, a telepítést, a rendszeradminisztrációt és természetesen a szervezeti intézkedéseket. Az információs rendszerekben az „emberi tényező” (beleértve a felhasználókat is) jelenti a fő biztonsági fenyegetést. Ennek az intézkedéscsomagnak ésszerűnek és kiegyensúlyozottnak kell lennie: nincs értelme, és nem valószínű, hogy elegendő forrást különítenek el olyan védelem megszervezésére, amely meghaladja magának az adatnak a költségeit.

Bevezetés

Az 1C:Enterprise a legelterjedtebb számviteli rendszer Oroszországban, de ennek ellenére a fejlesztői a 8.0-s verzióig nagyon kevés figyelmet fordítottak a biztonsági kérdésekre. Alapvetően persze ezt a termék árrés, illetve a kisvállalkozásokra való fókuszálás diktálta, ahol nincs képzett informatikus, a biztonságos rendszer kiépítésének és fenntartásának esetleges költsége pedig megfizethetetlenül költséges lenne a vállalkozás számára. A 8.0-s verzió megjelenésével a hangsúlyoknak megváltozniuk kellett: a megoldások költsége jelentősen megnőtt, a rendszer sokkal skálázhatóbb és rugalmasabb lett - a követelmények jelentősen megváltoztak. Az, hogy a rendszer kellően megbízható és biztonságos lett-e, az nagyon egyéni kérdés. Egy modern vállalkozás fő információs rendszerének legalább az alábbi biztonsági követelményeknek meg kell felelnie:

• Meglehetősen kicsi a valószínűsége a rendszer meghibásodásának belső okok miatt.
• Megbízható felhasználói jogosultság és adatvédelem a helytelen műveletek ellen.
• Hatékony rendszer a felhasználói jogok kiosztására.
• Online biztonsági mentési és helyreállítási rendszer meghibásodás esetén.

Az 1C:Enterprise 8.0-n alapuló megoldások megfelelnek ezeknek a követelményeknek? Nincs egyértelmű válasz. A beléptető rendszer jelentős változásai ellenére számos megoldatlan probléma maradt. A rendszer kialakításától és konfigurálásától függően előfordulhat, hogy egy adott megvalósításhoz mindezek a követelmények nem, vagy kellő mértékben teljesülnek, azonban érdemes odafigyelni (és ez a platform „fiatalságának” jelentős következménye ), hogy a felsorolt ​​feltételek maradéktalan teljesítéséhez valóban herkulesi erőfeszítésekre van szükség.

Ez a cikk az 1C:Enterprise platformon található megoldások fejlesztőinek és megvalósítóinak, valamint az 1C:Enterprise-t használó szervezetek rendszergazdáinak szól, és leírja a rendszer kliens-szerver verziójának fejlesztésének és konfigurálásának néhány szempontját. információbiztonság megszervezésének szemszögéből. Ez a cikk nem helyettesítheti a dokumentációt, csak rámutat néhány olyan pontra, amelyek még nem tükröződnek benne. És természetesen sem ez a cikk, sem az összes dokumentáció nem fogja tudni tükrözni a biztonságos információs rendszer felépítésének problémájának összetettségét, amelynek ugyanakkor meg kell felelnie a biztonság, a teljesítmény, a kényelem és a funkcionalitás egymásnak ellentmondó követelményeinek.

Osztályozás és terminológia

A cikk legfontosabb megfontolandó témája az információs fenyegetés.

Információs fenyegetés– annak a helyzetnek a lehetősége, amikor az adatokat engedély nélkül olvassák, másolják, módosítják vagy zárolják.

És e meghatározás alapján a cikk a következőképpen osztályozza az információs fenyegetéseket:

• Az adatok jogosulatlan megsemmisítése
• Az adatok jogosulatlan megváltoztatása
• Az adatok jogosulatlan másolása
• Adatok jogosulatlan beolvasása
• Adatok elérhetetlensége

Minden fenyegetés szándékos és nem szándékos fenyegetésre osztható. Megvalósult információs fenyegetésnek fogjuk nevezni incidens. A rendszer jellemzői a következők:

Sebezhetőségek– eseményekhez vezető jellemzők Védelmi intézkedések– olyan funkciók, amelyek blokkolják az incidens lehetőségét

Alapvetően csak azokat az eseteket veszik figyelembe, amelyek valószínűsége az 1C: Enterprise 8.0 technológiai platform kliens-szerver verzióban történő használatából adódik (továbbá olyan esetekben, amikor ez nem mond ellent egyszerűen az 1C vagy 1C 8.0 jelentésének) . Határozzuk meg a következő főbb szerepeket a rendszer használatával kapcsolatban:

• Üzemeltetők– olyan felhasználók, akik jogosultak az alkalmazási szerepkör által korlátozott adatok megtekintésére és módosítására, de nem rendelkeznek adminisztratív funkcióval
• Rendszergazdák– a rendszerben adminisztrátori jogokkal rendelkező felhasználók, beleértve az alkalmazásszerver és az MS SQL szerver operációs rendszerében adminisztrátori jogokat, az MS SQL rendszergazdai jogokat stb.
• Információbiztonsági rendszergazdák– olyan felhasználók, akikre az 1C információs bázis bizonyos adminisztratív funkciói delegálva vannak (például felhasználók hozzáadása, tesztelés és javítás, biztonsági mentés, alkalmazásmegoldás beállítása stb.)
• Rendszerfejlesztők– alkalmazásmegoldást fejlesztő felhasználók. Általában előfordulhat, hogy nem férnek hozzá a működő rendszerhez.
• Olyan személyek, akiknek nincs közvetlen hozzáférésük a rendszerhez– olyan felhasználók, akiknek nincs delegált hozzáférési joguk az 1C-hez, de valamilyen szinten befolyásolhatják a rendszer működését (általában mindannyian ugyanannak az Active Directory-tartománynak a felhasználói, amelybe a rendszer telepítve van). Ez a kategória elsősorban a potenciálisan veszélyes alanyok azonosítására szolgál a rendszerben.
• Automatizált adminisztrációs szkriptek- olyan programok, amelyekre bizonyos funkciókat delegálnak, és amelyek bizonyos műveletek automatikus végrehajtására szolgálnak (például adatok importálása-exportálása)

Itt két dolgot kell megjegyezni: egyrészt ez a besorolás nagyon durva, és nem veszi figyelembe az egyes csoportokon belüli megosztottságokat – bizonyos esetekben ilyen felosztást hoznak létre, másrészt feltételezzük, hogy más személyek nem tudják befolyásolni a műveletet. 1C-n kívüli eszközökkel kell biztosítani.

Minden biztonsági rendszert a megvalósíthatóság és a birtoklási költségek szem előtt tartásával kell megtervezni. Általánosságban elmondható, hogy egy információs rendszer fejlesztése és bevezetése során szükséges, hogy a rendszer védelmének ára megfeleljen:

• a védett információ értéke;
• incidens létrehozásának költségei (szándékos fenyegetés esetén);
• pénzügyi kockázatok incidens esetén

Értelmetlen és káros olyan védekezést szervezni, amely sokkal drágább, mint annak pénzügyi eredményessége. Számos módszer létezik az információvesztés kockázatának felmérésére, de ezeket a cikk nem tárgyalja. Egy másik fontos szempont az információbiztonság, a rendszerteljesítmény, a rendszerrel való munka kényelme és egyszerűsége, a fejlesztési és megvalósítási sebesség, valamint a vállalati információs rendszerekkel szemben támasztott egyéb követelmények egyensúlyának fenntartása a gyakran egymásnak ellentmondó követelmények között.

A rendszer információbiztonsági mechanizmusának főbb jellemzői

Az 1C:Enterprise 8.0 két verzióban érhető el: fájl és kliens-szerver. A fájlverzió a következő okok miatt nem tekinthető a rendszer információbiztonságát biztosítónak:

• Az adatok és a konfigurációk egy fájlban tárolódnak, amely a rendszer összes felhasználója számára olvasható és írható.
• Amint az alább látható lesz, a rendszerengedélyezés nagyon könnyen megkerülhető.
• A rendszer integritását csak a kliens rész kernelje biztosítja.

A kliens-szerver verzióban az MS SQL Server szolgál információ tárolására, amely a következőket nyújtja:

• Megbízhatóbb adattárolás.
• Fájlok elkülönítése a közvetlen hozzáféréstől.
• Fejlettebb tranzakciós és zárolási mechanizmusok.

A rendszer fájl és kliens-szerver változatai közötti jelentős különbségek ellenére alkalmazásmegoldás szinten egységes hozzáférés-vezérlési sémával rendelkeznek, amely a következő képességeket biztosítja:

• Felhasználó engedélyezése az 1C-ben meghatározott jelszóval.
• Felhasználói jogosultság az aktuális Windows-felhasználó alapján.
• Szerepkörök hozzárendelése a rendszerfelhasználókhoz.
• Az adminisztratív funkciók szerepkör szerinti korlátozása.
• Az elérhető interfészek szerepkörök szerinti hozzárendelése.
• A metaadat-objektumokhoz való hozzáférés korlátozása szerepkör szerint.
• Az objektum részleteihez való hozzáférés korlátozása szerepkör szerint.
• Az adatobjektumokhoz való hozzáférés korlátozása szerepkörök és munkamenet-paraméterek szerint.
• Az adatokhoz és a végrehajtható modulokhoz való interaktív hozzáférés korlátozása.
• Néhány kódvégrehajtási korlátozás.

Általában az alkalmazott adatelérési séma meglehetősen jellemző az ilyen szintű információs rendszerekre. A háromszintű kliens-szerver architektúra megvalósításával kapcsolatban azonban számos alapvető szempont van, amelyek viszonylag sok sebezhetőséghez vezetnek:

1. Számos adatfeldolgozási szakasz, és minden szakaszban eltérő szabályok vonatkozhatnak az objektumok elérésére.

   A biztonsági szempontból jelentős adatfeldolgozási szakaszok némileg leegyszerűsített diagramja az 1. ábrán látható. Az 1C általános szabálya a korlátozások csökkentése a sémában lejjebb haladva, ezért az egyik felső szinten lévő sebezhetőség megzavarhatja a rendszer működését minden szinten.

2. Nem kellően kidolgozott eljárások az átvitt adatok figyelésére a szintről szintre való váltáskor.

   Sajnos a rendszer nem minden belső mechanizmusa tökéletesen debuggolt, főleg a nem interaktív mechanizmusok esetében, amelyek hibakeresése egyrészt mindig munkaigényesebb, másrészt felelősségteljesebb. Ez a „betegség” nem kizárólag az 1C esetében jelent problémát, a legtöbb gyártó számos szervertermékében megtalálható. Csak az utóbbi években nőtt jelentősen a figyelem ezekre a problémákra.

3. A fejlesztők és rendszergazdák nem kellően magas átlagos képzettsége, az előző verzióból örökölt.

   Az 1C:Enterprise termékcsalád termékei kezdetben a könnyű fejlesztésre és támogatásra, valamint a kis szervezetekben való munkavégzésre helyezték a hangsúlyt, így nem meglepő, hogy történelmileg kialakult, hogy az alkalmazásmegoldások „fejlesztőinek” és „adminisztrátorainak” jelentős része. rendszerek nem rendelkeznek elegendő tudással és készségekkel ahhoz, hogy egy sokkal összetettebb termékkel dolgozzanak, amely a 8.0-s verzió. A problémát súlyosbítja a franchise társaságok által elfogadott gyakorlat, hogy „harcban” tanítanak az ügyfelek kárára, anélkül, hogy szisztematikusan közelítenék ezt a kérdést. Az 1C cég előtt tisztelegni kell, hogy az elmúlt néhány évben ez a helyzet fokozatosan korrigálódott: a komoly franchise-vállalkozások elkezdtek felelősségteljesebben hozzáállni a személyzet kiválasztásának és képzésének problémájához, az információs technológiai támogatás mértékéhez. az 1C cég jelentősen megnövekedett, megjelentek a magas szintű szolgáltatást célzó tanúsítási programok; de a helyzet nem korrigálható azonnal, ezért ezt a tényezőt figyelembe kell venni a rendszer biztonságának elemzésekor.

4. A platform viszonylag fiatal.

   A hasonló fókuszú és felhasználási célú termékek között ez az egyik legfiatalabb megoldás. A platform funkcionalitása nagyjából egy évvel ezelőtt alakult ki. Ugyanakkor a platform minden egyes kiadása a 8.0.10-től kezdve (ebben a kiadásban valósult meg a rendszer szinte minden jelenlegi képessége) lényegesen stabilabbá vált, mint a korábbiak. A szabványos alkalmazásmegoldások funkcionalitása még mindig ugrásszerűen növekszik, bár a platform képességeinek csak a felét használják ki. Természetesen ilyen körülmények között meglehetősen feltételesen beszélhetünk stabilitásról, de általánosságban el kell ismerni, hogy az 1C 8.0 platform megoldásai sok tekintetben jelentősen megelőzik funkcionalitásban és teljesítményben (és gyakran stabilitásban is) az 1C hasonló megoldásait. 7.7 platform.

Tehát a rendszert (és esetleg egy szabványos alkalmazásmegoldást) telepítik a vállalatban, és telepítik a számítógépekre. Először is létre kell hozni egy olyan környezetet, amelyben az 1C biztonság beállításának van értelme, és ehhez úgy kell konfigurálni, hogy teljesüljön az a feltételezés, hogy a rendszer biztonságát jelentősen befolyásolják a rendszerbeállítások.

Kövesse a biztonság beállításának általános szabályait.

Szó sem lehet egy rendszer információbiztonságáról, ha nem tartják be a biztonságos rendszerek létrehozásának alapelveit. Győződjön meg arról, hogy legalább a következő feltételek teljesülnek:

• A szerverekhez való hozzáférés fizikailag korlátozott és zavartalan működésük biztosított:
  • a szerver berendezések megfelelnek a megbízhatósági követelményeknek, a hibás szerverberendezések cseréjét kiigazították, különösen kritikus területeken a hardver megkettőzésével járó sémákat alkalmaznak (RAID, tápellátás több forrásból, több kommunikációs csatorna stb.);
  • a szerverek zárt helyiségben vannak elhelyezve, és ez a helyiség csak a távolról nem végezhető munkavégzés idejére van nyitva;
  • A szerverszobát vészhelyzet esetére csak egy-két embernek van joga kinyitni, a felelős személyek értesítési rendszere kidolgozásra került;
  • a szerverek megszakítás nélküli áramellátása biztosított
  • a berendezés normál éghajlati működési feltételei biztosítottak;
  • a szerverszobában tűzjelző van, nincs árvízveszély (főleg az első és az utolsó emeleten);
• A vállalat hálózati és információs infrastruktúrájának beállításai megfelelően elkészültek:
  • A tűzfalak minden kiszolgálón telepítve és konfigurálva vannak;
  • minden felhasználó és számítógép jogosult a hálózaton, a jelszavak elég összetettek ahhoz, hogy ne lehessen kitalálni;
  • a rendszerüzemeltetőknek elegendő joguk van ahhoz, hogy normálisan dolgozhassanak vele, de nincs joguk adminisztratív lépésekre;
  • a víruskereső eszközök telepítve vannak és engedélyezve vannak a hálózat összes számítógépén;
  • kívánatos, hogy a felhasználók (a hálózati rendszergazdák kivételével) ne rendelkezzenek rendszergazdai jogokkal az ügyfél munkaállomásokon;
  • az internethez és a cserélhető adathordozókhoz való hozzáférést szabályozni és korlátozni kell;
  • konfigurálni kell a biztonsági események rendszerauditálását;
• A főbb szervezési kérdéseket sikerült megoldani:
  • a felhasználók megfelelő képesítéssel rendelkeznek az 1C és a hardver használatához;
  • a felhasználókat az üzemeltetési szabályok megsértése miatti felelősségről értesítjük;
  • az információs rendszer minden lényeges eleméhez pénzügyileg felelős személyeket jelöltek ki;
  • minden rendszeregység le van zárva és le van zárva;
  • Különös figyelmet kell fordítani a takarítók, építőmunkások és villanyszerelők oktatására és felügyeletére. Ezek a személyek gondatlanságból olyan kárt okozhatnak, amely nem hasonlítható össze a rendszer gátlástalan felhasználója által okozott szándékos károkozással.

Figyelem! Ez a lista nem kimerítő, csak azt írja le, mi az, ami gyakran kimarad egy meglehetősen bonyolult és költséges információs rendszer telepítése során!

• Az MS SQL Server, az alkalmazásszerver és a kliens rész különböző számítógépeken fut, a szerveralkalmazások speciálisan létrehozott Windows felhasználók jogai alatt futnak;
• MS SQL Serverhez
  • vegyes engedélyezési mód van beállítva
  • A szerveradmin szerepkörbe tartozó MS SQL felhasználók nem vesznek részt az 1C munkában,
  • minden IB 1C-hez külön MS SQL felhasználót hoztak létre, amely nem rendelkezik kiváltságos hozzáféréssel a szerverhez,
  • Az egyik IS MS SQL felhasználója nem fér hozzá a másik IS-hez;
• A felhasználóknak nincs közvetlen hozzáférésük az alkalmazáskiszolgáló és az MS SQL szerver fájljaihoz
• A kezelői munkaállomásokon Windows 2000/XP (nem Windows 95/98/Me)

Ne hagyja figyelmen kívül a rendszerfejlesztők ajánlásait és a dokumentáció elolvasását. A rendszer beállításával kapcsolatos fontos anyagokat ITS lemezeken a „Módszertani ajánlások” részben közöljük. Különös figyelmet kell fordítani a következő cikkekre:

1. Az 1C:Enterprise szerverrel működő alkalmazások jellemzői
2. Adatelhelyezés 1C:Enterprise 8.0
3. Az 1C:Enterprise 8.0 frissítést rendszergazdai jogosultságokkal nem rendelkező Microsoft Windows felhasználók végezték
4. Felhasználói lista szerkesztése olyan felhasználó nevében, aki nem rendelkezik rendszergazdai jogokkal
5. A Windows XP SP2 tűzfal beállításainak konfigurálása az SQL Server 2000 és az SQL Server Desktop Engine (MSDE) futtatásához
6. COM+ Windows XP SP2 paraméterek konfigurálása az 1C:Enterprise 8.0 szerver futtatásához
7. A Windows XP SP2 tűzfal beállításainak konfigurálása az 1C:Enterprise 8.0 kiszolgálóhoz
8. A Windows XP SP2 tűzfal beállításainak konfigurálása a HASP licenckezelőhöz
9. Biztonsági másolat készítése egy információs bázisról SQL Server 2000 használatával
10. Telepítési és konfigurációs problémák 1C:Enterprise 8.0 a "kliens-szerver" verzióban(az egyik legfontosabb cikk)
11. A Windows Server 2003 beállításának jellemzői az 1C:Enterprise 8.0 szerver telepítésekor
12. Felhasználói hozzáférés szabályozása az információs bázishoz kliens-szerver verzióban(az egyik legfontosabb cikk)
13. 1C szerver: Vállalati és SQL szerver
14. Az 1C:Enterprise 8.0 részletes telepítési eljárása a "kliens-szerver" verzióban(az egyik legfontosabb cikk)
15. A beépített nyelv használata az 1C:Enterprise szerveren

A dokumentáció olvasásakor azonban kritikusan kell kezelni a kapott információkat, például az „1C: Enterprise 8.0 telepítésével és konfigurálásával kapcsolatos problémák a kliens-szerver verzióban” című cikk nem írja le pontosan a USER1CV8SERVER felhasználóhoz szükséges jogokat. Az alábbi listára hivatkozások lesznek, például az [ITS1] az „1C:Enterprise szerverrel működő alkalmazások jellemzői” című cikket jelenti. Minden cikkre mutató link az ITS legfrissebb számához tartozik a cikk írásakor (2006. január)

Használja az engedélyezési képességeket a felhasználók Windows-engedélyezésével kombinálva

A két lehetséges felhasználói engedélyezési mód közül: a beépített 1C és a Windows OS jogosultsággal kombinálva, ha lehetséges, a kombinált engedélyezést kell választania. Ez lehetővé teszi, hogy a felhasználókat ne keverjék össze több jelszóval munka közben, de nem csökkenti a rendszerbiztonság szintjét. Azonban még azoknak a felhasználóknak is, akik csak Windows-engedélyt használnak, nagyon tanácsos jelszót beállítani annak létrehozásakor, és csak ezután tiltani az 1C jogosultságot ennél a felhasználónál. Az Active Directory struktúra megsemmisülése esetén a rendszer helyreállítása érdekében legalább egy olyan felhasználót kell hagyni, aki 1C jogosultsággal bejelentkezhet a rendszerbe.

Alkalmazásmegoldási szerepkörök létrehozásakor ne adjon hozzá jogokat „tartalékban”

Minden alkalmazásmegoldási szerepkörnek tükröznie kell a szerepkör által meghatározott műveletek végrehajtásához szükséges minimális jogosultságkészletet. Egyes szerepek azonban nem használhatók önállóan. Például a külső processzorok interaktív futtatásához külön szerepkört hozhat létre, és hozzáadhatja az összes olyan felhasználóhoz, akinek külső processzort kell használnia.

Rendszeresen tekintse át a naplókat és a rendszer működési protokolljait

Ha lehetséges, szabályozza és automatizálja a naplók és a rendszerműködési protokollok megtekintését. Megfelelő konfigurációval és a naplók rendszeres áttekintésével (csak a fontos események szűrésével) a jogosulatlan tevékenységek korán észlelhetők, vagy akár az előkészítési szakaszban megelőzhetők.

A kliens-szerver verzió néhány funkciója

Ez a rész a kliens-szerver opció néhány működési jellemzőjét és azok biztonságra gyakorolt ​​hatását ismerteti. A könnyebb olvashatóság érdekében a következő jelöléseket használjuk:

Figyelem! sebezhetőség leírása

A rendszerhez való hozzáférést szabályozó információk tárolása

Információbiztonsági felhasználók listájának tárolása

Az információbiztonság felhasználóinak listájáról és a benne elérhető szerepkörökről minden információ az MS SQL adatbázis Params táblájában van tárolva (lásd [ITS2]). A táblázat szerkezetét és tartalmát tekintve nyilvánvalóvá válik, hogy az összes felhasználói információ egy rekordban van tárolva, amelynek FileName mező értéke „users.usr”.

Mivel feltételezzük, hogy a felhasználók nem férnek hozzá az MS SQL adatbázishoz, ezt a tényt önmagában nem használhatja fel a támadó, azonban ha lehetséges kódot futtatni MS SQL-ben, ez „megnyitja az ajtót” bármely(! ) hozzáférés az 1C-ből. Ugyanez a mechanizmus (kisebb változtatásokkal) alkalmazható a rendszer fájlverziójában is, ami a fájlverzió sajátosságait figyelembe véve teljesen kizárja annak alkalmazhatóságát a biztonságos rendszerek felépítésében.

Ajánlást: Jelenleg nincs mód az alkalmazás teljes körű védelmére az ilyen változásoktól, kivéve az MS SQL Server szintű triggerek használatát, amelyek viszont problémákat okozhatnak a platform verziójának frissítése vagy a lista módosítása során. felhasználókat. Az ilyen változások nyomon követésére használhatja az 1C naplót (figyelve a „gyanús” bejelentkezésekre a konfigurátor módban a felhasználó megadása nélkül), vagy folyamatosan futva tarthatja az SQL Profilert (ami rendkívül negatív hatással lesz a rendszer teljesítményére), vagy konfigurálhatja a riasztásokat. mechanizmus (valószínűleg együtt, triggerek használatával)

Információk tárolása az IS listáról a szerveren

Minden 1C alkalmazásszerver esetében a rendszer információkat tárol a hozzá kapcsolódó MS SQL adatbázisok listájáról. Mindegyik infobázis saját kapcsolódási karakterláncot használ az alkalmazáskiszolgálótól és az MS SQL szervertől a működéshez. Az alkalmazáskiszolgálón regisztrált információs bázisokkal kapcsolatos információk a kapcsolati karakterláncokkal együtt az srvrib.lst fájlban tárolódnak, amely a kiszolgálón a könyvtárban található.<Общие данные приложений>/1C/1Cv8 (például C:/Dokumentumok és beállítások/Minden felhasználó/Alkalmazásadatok/1C/1Cv8/srvrib.lst). Minden információbiztonsági rendszerhez egy teljes kapcsolati karakterlánc kerül tárolásra, beleértve az MS SQL felhasználói jelszót is, ha vegyes MS SQL engedélyezési modellt használ. Ennek a fájlnak a jelenléte teszi lehetővé az MS SQL adatbázishoz való jogosulatlan hozzáféréstől való félelmet, és ha az ajánlásokkal ellentétben egy privilegizált felhasználót (például „sa”) használnak legalább egy adatbázis eléréséhez, akkor Az egyetlen információbiztonságot fenyegető veszély mellett az MS SQL használatával az egész rendszert fenyegeti.

Érdekes megjegyezni, hogy a vegyes jogosultság és a Windows jogosultság használata egy MS SQL szerveren különböző típusú problémákhoz vezet az adott fájlhoz való hozzáférés során. Tehát a Windows-engedélyezés legfontosabb negatív tulajdonságai a következők:

• Az összes információbiztonság működése az alkalmazáskiszolgálón és az MS SQL szerveren egy jogcsoport alatt (valószínűleg redundáns)
• Az 1C alkalmazáskiszolgáló folyamatból (vagy általában a USER1CV8SERVER vagy annak megfelelő felhasználótól) jelszó megadása nélkül könnyedén csatlakozhat bármilyen információbiztonsághoz jelszó megadása nélkül

Másrészt a támadó számára nehezebb lehet tetszőleges kódot futtatni a USER1CV8SERVER felhasználó környezetéből, mint a megadott fájl beszerzése. Mellesleg, egy ilyen fájl jelenléte egy másik érv a szerverfunkciók különböző számítógépeken való elosztása mellett.

Ajánlást: Az srvrib.lst fájlt csak a szerverfolyamat érheti el. Ügyeljen arra, hogy konfigurálja a naplózást a fájl módosításához.

Sajnos alapértelmezés szerint ez a fájl szinte nincs védve az olvasástól, amit a rendszer üzembe helyezésekor figyelembe kell venni. Az ideális megoldás az lenne, ha az alkalmazásszerver futás közben megakadályozná ennek a fájlnak az olvasását és írását (beleértve a kiszolgálón futó felhasználói kapcsolatok általi olvasást és írást is).

Jogosultság hiánya a szerver információbiztonságának létrehozásakor

Figyelem! Az engedélyezési hiba hiányát az 1C:Enterprise platform 8.0.14-es kiadásában javították. Ebben a kiadásban megjelent az „1C:Enterprise Server Administrator” koncepció, de amíg a rendszergazdák listája meg van adva a szerveren, a rendszer az alábbiakban leírtak szerint működik, ezért ne feledkezzünk meg erről a lehetséges szolgáltatásról.

Valószínűleg a legnagyobb sérülékenység ebből a részből az, hogy szinte korlátlanul bővíthető az alkalmazáskiszolgáló információbiztonsága, aminek eredményeként minden felhasználó, aki hozzáfér az alkalmazásszerverhez, automatikusan képes tetszőleges kód futtatására az alkalmazáskiszolgálón. . Nézzük ezt egy példával.

A rendszert az alábbiak szerint kell telepíteni

• MS SQL Server 2000 (például hálózatnév SRV1)
• Szerver 1C: Enterprise 8.0 (hálózatnév SRV2)
• 1C kliens rész: Enterprise 8.0 (hálózatnév WS)

Feltételezzük, hogy a WS-en dolgozó felhasználó (a továbbiakban: FELHASZNÁLÓ) legalább minimális hozzáféréssel rendelkezik az SRV2-n regisztrált információbiztonsági rendszerek egyikéhez, de nem rendelkezik kiváltságos hozzáféréssel az SRV1-hez és az SRV2-höz. Általánosságban elmondható, hogy a felsorolt ​​számítógépek funkcióinak kombinációja nem befolyásolja a helyzetet. A rendszer konfigurálása a dokumentációban és az ITS lemezeken található ajánlások figyelembevételével történt. A helyzet az ábrán látható. 2.

• konfigurálja a COM+ biztonságot az alkalmazáskiszolgálón úgy, hogy csak az 1C felhasználóknak legyen joga csatlakozni az alkalmazáskiszolgáló folyamatához (további részletek [ITS12]);
• az srvrib.lst fájlnak csak olvashatónak kell lennie a USER1CV8SERVER felhasználó számára (új információbiztonság hozzáadásához ideiglenesen engedélyezze az írást);
• Az MS SQL-hez való csatlakozáshoz csak a TCP/IP protokollt használja, ebben az esetben:
  • korlátozza a kapcsolatokat tűzfal segítségével;
  • konfigurálja a nem szabványos TCP-port használatát, ami megnehezíti a „kívülállók” IB 1C csatlakozását;
  • az alkalmazásszerver és az SQL szerver között átvitt adatok titkosítása;
• állítsa be a kiszolgáló tűzfalát úgy, hogy ne lehessen harmadik féltől származó MS SQL-kiszolgálókat használni;
• használjon intranet biztonsági eszközöket, hogy kizárja annak lehetőségét, hogy illetéktelen számítógépek jelenjenek meg a helyi hálózaton (IPSec, csoportos biztonsági szabályzatok, tűzfalak stb.);
• Semmilyen körülmények között ne adjon adminisztrátori jogokat a USER1CV8SERVER felhasználónak az alkalmazáskiszolgálón.

A szerveren futó kód használata

Az 1C kliens-szerver verziójának használatakor a fejlesztő megoszthatja a kódvégrehajtást az ügyfél és az alkalmazáskiszolgáló között. Ahhoz, hogy a kód (eljárás vagy funkció) csak a szerveren fusson le, egy általános modulba kell elhelyezni, amelyhez a „Server” tulajdonság be van állítva, és abban az esetben, ha a modul végrehajtása nem csak a szerveren engedélyezett. a szerveren, helyezze el a kódot a korlátozott „#If Server” szakaszban:

#Ha Szerver Akkor
Funkció OnServer(Param1, Param2 = 0) Export // Ez a függvény egyszerűsége ellenére a szerveren fut
Param1 = Param1 + 12;
Vissza Param1;
EndFunction
#EndIf

A szerveren futó kód használatakor figyelembe kell vennie, hogy:

• a kód USER1CV8SERVER jogokkal fut az alkalmazáskiszolgálón (COM objektumok és szerverfájlok elérhetők);
• az összes felhasználói munkamenetet a szolgáltatás egy példánya hajtja végre, így például a verem túlcsordulása a kiszolgálón az összes aktív felhasználó megszakadásához vezet;
• a szervermodulok hibakeresése nehézkes (például nem lehet töréspontot beállítani a hibakeresőben), de meg kell tenni;
• a vezérlés átadása a kliensről az alkalmazáskiszolgálóra és vissza jelentős erőforrásokat igényelhet nagy mennyiségű átvitt paraméter mellett;
• interaktív eszközök (űrlapok, táblázatkezelő dokumentumok, párbeszédpanelek), külső jelentések használata és kódban történő feldolgozása az alkalmazásszerveren lehetetlen;
• globális változók használata (az alkalmazásmodul változói, amelyeket "Export" jelzéssel deklaráltak) nem megengedettek;

További részletekért lásd az [ITS15] és más ITS cikkeket.

Az alkalmazásszervernek különleges megbízhatósági követelményekkel kell rendelkeznie. Egy megfelelően felépített kliens-szerver rendszerben a következő feltételeknek kell teljesülniük:

• az ügyfélalkalmazás semmilyen művelete nem szakíthatja meg a szerver működését (kivéve az adminisztratív eseteket);
• a szerver nem tudja végrehajtani a klienstől kapott programkódot;
• az erőforrásokat „méltányosan” kell elosztani az ügyfélkapcsolatok között, biztosítva a szerver elérhetőségét az aktuális terheléstől függetlenül;
• adatblokkolás hiányában a klienskapcsolatok nem befolyásolhatják egymás munkáját;
• a szerver nem rendelkezik felhasználói felülettel, de figyelő és naplózó eszközöket kell fejleszteni;

Általánosságban elmondható, hogy az 1C rendszert úgy építik fel, hogy közelebb kerüljön ezekhez a követelményekhez (például lehetetlen külső feldolgozást kényszeríteni a szerveren), de számos kellemetlen funkció továbbra is fennáll, ezért:

Ajánlást: Futóidejű szerver fejlesztésekor ajánlatos betartani a minimális interfész elvét. Azok. az ügyfélalkalmazásból a szerver modulokba történő belépések számát nagyon korlátozni kell, a paramétereket pedig szigorúan szabályozni kell. Ajánlást: Az eljárások és funkciók paramétereinek fogadásakor a szerveren szükséges a paraméterek érvényesítése (ellenőrizve, hogy a paraméterek megfelelnek-e az elvárt típusnak és értéktartománynak). Ez a szabványos megoldásokban nem történik meg, de nagyon kívánatos a kötelező érvényesítés bevezetése a saját fejlesztésekben. Ajánlást: A kérés szövegének (és különösen a Run parancs paraméterének) szerveroldali generálásakor ne használjon az ügyfélalkalmazástól kapott karakterláncokat.

Általános javaslat az lenne, hogy ismerkedjen meg a biztonságos építés alapelveivel web-adatbázis-alkalmazások és hasonló elvek alapján működnek. A hasonlóságok valóban jelentősek: egyrészt a webalkalmazásokhoz hasonlóan az alkalmazásszerver egy köztes réteg az adatbázis és a felhasználói felület között (a fő különbség az, hogy a webszerver alkotja a felhasználói felületet); másodszor, biztonsági szempontból nem lehet megbízni az ügyféltől kapott adatokban, mert lehetőség van külső riportok és feldolgozás indítására.

Paraméterek átadása

A paraméterek átadása a szerveren végrehajtott függvénynek (eljárásnak) meglehetősen kényes probléma. Ez elsősorban az alkalmazáskiszolgáló és a kliens folyamatok közötti átvitelük szükségességéből adódik. Amikor a vezérlés átkerül a kliens oldalról a szerver oldalra, minden továbbított paraméter sorba rendeződik, átkerül a szerverre, ahol „kicsomagolják” és felhasználják. A szerver oldalról a kliens oldalra való áttéréskor a folyamat fordított. Itt meg kell jegyezni, hogy ez a séma megfelelően kezeli a paraméterek referencia és érték szerinti átadását. A paraméterek átadásakor a következő korlátozások érvényesek:

• A kliens és a szerver között (mindkét irányban) csak nem módosítható értékek vihetők át (azaz amelyek értéke nem módosítható): primitív típusok, hivatkozások, univerzális gyűjtemények, rendszerfelsorolási értékek, értéktár. Ha valami mást próbál átadni, az ügyfélalkalmazás összeomlik (még akkor is, ha a kiszolgáló helytelen paramétert próbál átadni).
• Nem ajánlott nagy mennyiségű adat átvitele paraméterek átadásakor (például 1 millió karakternél hosszabb karakterláncok), ez negatívan befolyásolhatja a szerver teljesítményét.
• Nem adhat át ciklikus referenciát tartalmazó paramétereket a kiszolgálóról a kliensre és vissza sem. Ha megpróbál egy ilyen paramétert átadni, az ügyfélalkalmazás összeomlik (még akkor is, ha a szerver megpróbálja átadni a helytelen paramétert).
• Nagyon összetett adatgyűjtemények átvitele nem javasolt. Amikor egy nagyon nagy beágyazási szinttel rendelkező paramétert próbál átadni, a szerver összeomlik (! ).

Figyelem! A legbosszantóbb jelenség jelenleg valószínűleg az összetett értékgyűjtemények átadásának hibája. Tehát például a kód: Nesting Level = 1250;
M = új tömb;
PassedParameter = M;
Számla esetén = 1 a beágyazási ciklus szintje szerint
MVInt = Új tömb;
M.Add(MVInt);
M = MVint;
EndCycle;
ServerFunction(PassedParameter);

A kiszolgáló vészleállításához vezet az összes felhasználó kapcsolatának megszakadásával, és ez akkor következik be, mielőtt a vezérlés átkerülne a kódra a beépített nyelven.

Nem biztonságos funkciók használata a szerver oldalon.

Nem minden beépített nyelvi eszköz használható az alkalmazáskiszolgálón végrehajtott kódban, de még a rendelkezésre álló eszközök között is sok „problémás” konstrukció található, amelyek nagyjából a következőképpen osztályozhatók:

• képes biztosítani a konfigurációban nem szereplő kód végrehajtását ("Kódvégrehajtás" csoport)
• képes a kliens alkalmazást a felhasználó fájljairól és operációs rendszeréről információkkal ellátni, vagy az adatokkal nem összefüggő műveleteket végrehajtani („Jogsértés”)
• képes szerver összeomlást okozni, vagy nagyon nagy erőforrásokat használ fel ("Szerver összeomlás" csoport)
• képes kliens meghibásodását okozni (klienshiba csoport) – ezt a típust nem veszik figyelembe. Példa: változó érték átadása a szervernek.
• hibák a programozási algoritmusokban (végtelen hurkok, korlátlan rekurzió stb.) („Programozási hibák”)

Az alábbiakban felsoroljuk az általam ismert főbb problémás terveket (példákkal):

Eljárás végrehajtása(<Строка>)

Kód végrehajtása. Lehetővé teszi egy olyan kódrészlet végrehajtását, amelyet karakterlánc-értékként ad át neki. Ha a szerveren használja, gondoskodnia kell arról, hogy a klienstől kapott adatok ne legyenek paraméterek. Például a következő használat nem megengedett:

#Ha Szerver Akkor
ProcedureOnServer(Param1) Export
Végrehajtás(Param1);
Vége eljárás
#EndIf

Írja be a "COMObject" (konstruktor Új COMObject(<Имя>, <Имя сервера>))

Létrehoz egy külső alkalmazás COM objektumot USER1CV8SERVER jogokkal az alkalmazáskiszolgálón (vagy más megadott számítógépen). Ha szerveren használja, győződjön meg arról, hogy a paraméterek nem kerülnek átadásra az ügyfélalkalmazásból. Szerver oldalon azonban hatékony ezt a funkciót használni importálásnál/exportálásnál, interneten keresztüli adatküldésnél, nem szabványos funkciók megvalósításánál stb.

Függvény GetCOMObject(<Имя файла>, <Имя класса COM>)

Jogok megsértése és kódvégrehajtás. Az előzőhöz hasonlóan csak a fájlnak megfelelő COM objektumot kapja meg.

Eljárások és függvények Számítógépnév(), IdeiglenesFileDirectory(), ProgramDirectory(), WindowsUsers()

Jogok megsértése. A szerveren való végrehajtásukkal lehetővé teszik a szerver alrendszer felépítésének részleteinek megismerését. Szerveren történő felhasználáskor ügyeljen arra, hogy az adatok vagy ne kerüljenek át a kliensre, vagy megfelelő engedély nélkül ne férhessenek hozzá az üzemeltetők számára. Különös figyelmet kell fordítani arra, hogy egy hivatkozással átadott paraméterben vissza lehet adni az adatokat.

Eljárások és funkciók a fájlokkal (CopyFile, FindFiles, MergeFiles és sok más), valamint fájltípusokkal való munkavégzéshez.

Jogok megsértése. Lehetővé teszik, hogy a kiszolgálón végrehajtva megosztott hozzáférést kapjanak a USER1CV8SERVER felhasználói jogokkal elérhető helyi (és a hálózaton található) fájlokhoz. Ha tudatosan használjuk, akkor hatékonyan lehet végrehajtani olyan feladatokat, mint az adatok importálása/exportálása a szerveren.

A funkciók használata előtt feltétlenül ellenőrizze 1C felhasználói jogait. A felhasználói jogok ellenőrzéséhez a következő konstrukciót használhatja a szerver modulban:

#Ha Szerver Akkor
Eljárás PerformWorkWithFile() Exportálás
RoleAdministrator = Metadata.Roles.Administrator;
Felhasználó = SessionParameters.CurrentUser;
Ha User.Roles.Contains(RoleAdministrator) Akkor
//A fájlokkal való munkavégzés kódja itt fut le
endIf;
#EndIf

Ügyeljen arra, hogy ellenőrizze a paramétereket, ha ezeket az eljárásokat és funkciókat használja, különben fennáll annak a veszélye, hogy véletlenül vagy tudatosan helyrehozhatatlan károkat okoznak az 1C alkalmazásszerverben, például a következő kód futtatásakor a szerveren:

Elérési út = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
MoveFile(Path + "srvrib.lst", Path + "Here'sWhereTheFileGoes");

Az ilyen kód kiszolgálón való végrehajtása után, ha a USER1CV8SERVER felhasználónak van joga megváltoztatni a fent leírtak szerint, és a szerver folyamat újraindítása után (alapértelmezés szerint 3 perccel az összes felhasználó kilépése után), akkor egy NAGY kérdés fog felmerülni a szerver indításával kapcsolatban. . De lehetséges a fájlok teljes törlése is...

Típusok: "XBase", "BinaryData", "XML Reader", "XML Writer", "XSL Transformation", "ZipFile Writer", "ZipFile Reader", "Text Reader", "Text Writer"

Jogok megsértése. Lehetővé teszik, hogy a szerveren végrehajtva bizonyos típusú helyi (és a hálózaton található) fájlokhoz hozzáférjenek, és a USER1CV8SERVER felhasználói jogok alatt olvassák/írják azokat. Tudatos használat mellett olyan feladatokat is hatékonyan megvalósíthatunk, mint adatok importálása/exportálása a szerveren, egyes funkciók működésének naplózása, adminisztrációs feladatok megoldása. Általánosságban elmondható, hogy az ajánlások egybeesnek az előző bekezdéssel, de fontolóra kell vennie az adatok átvitelének lehetőségét ezekből a fájlokból (de nem az összes ilyen típusú objektumból) a kliens és a szerver részek között.

Írja be a "SystemInformation" parancsot

Jogok megsértése. Lehetővé teszi adatok beszerzését az alkalmazásszerverről helytelen használat és az adatok átvitele az alkalmazás kliens részére. Használatkor célszerű korlátozni a használati jogot.

Típusok: "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Jogok megsértése. Szerveren való használat esetén egy alkalmazáskiszolgálóról csatlakozik egy távoli számítógéphez a USER1CV8SERVER jogokkal. Javaslatok:

• Paraméterek vezérlése metódusok hívásakor.
• Az 1C felhasználói jogok ellenőrzése.
• Súlyos korlátozások a USER1CV8SERVER felhasználó hálózathoz való hozzáférési jogaiban.
• A tűzfal helyes beállítása az 1C alkalmazáskiszolgálón.

Megfelelő használat esetén kényelmes megszervezni például az e-mailek küldését egy alkalmazáskiszolgálóról.

Típusok "InformationBaseUserManager", "InformationBaseUser"

Jogok megsértése. Helytelen használat esetén (kiváltságos modulban) lehetőség van felhasználók hozzáadására vagy a meglévő felhasználók jogosultsági paramétereinek módosítására.

Funkció formátum

Szerver összeomlás. Igen! Ez a látszólag ártalmatlan funkció, ha paraméterei nincsenek szabályozva és nem hajtják végre a szerveren, a szerveralkalmazás összeomlását okozhatja. A hiba a számok formázásakor és a kezdő nullák és nagyszámú karakter megjelenítési mód használatakor lép fel, pl.

Formátum(1, "CHZ=999; CHVN=");

Remélem ezt a hibát a következő platformkiadásokban kijavítják, de addig is ennek a függvénynek a szerveren végrehajtható összes hívásánál ellenőrizze a hívási paramétereket.

Eljárások és funkciók az értékek mentéséhez (ValueInRowInt, ValueInFile)

Szerver összeomlás. Ezek a funkciók nem kezelik a körkörös hivatkozásokat a gyűjteményekben és a nagyon mély egymásba ágyazási mélységekben, így egyes nagyon különleges esetekben összeomolhatnak.

Határhibák és speciális paraméterértékek a függvényekben. Végrehajtás ellenőrzése.

Az egyik probléma, amellyel a szerver használata során találkozhat, a szerverfunkciók nagy "felelőssége" (a teljes kiszolgálóalkalmazás összeomlásának lehetősége egy kapcsolat hibája miatt, és egy "erőforrásterület" használata az összes kapcsolathoz) . Ezért szükség van a fő futásidejű paraméterek vezérlésére:

• A beépített nyelvi funkcióknál ellenőrizze az indítási paramétereiket (jó példa erre a „Formátum” funkció)
• A hurkok használatakor győződjön meg arról, hogy a hurok kilépési feltétele teljesül. Ha a ciklus potenciálisan végtelen, mesterségesen korlátozza az iterációk számát: MaximumIterationCounterValue = 1000000;
  Iterációs számláló = 1;
  Viszlát
  Függvény, amely nem térhet visszaFalseValue()
  ÉS (Iterációszám<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... A hurok törzse
  Iterációs számláló = Iterációs számláló + 1;
  EndCycle;
  Ha az Iterációs számláló > Az iterációs számláló maximális értéke, akkor
  //.... kezeli a túl hosszú ciklusvégrehajtás eseményét
  endIf;

• Rekurzió használatakor korlátozza a maximális beágyazási szintet.
• Lekérdezések létrehozásakor és végrehajtásakor próbálja meg elkerülni a nagyon hosszú kijelöléseket és a nagy mennyiségű információ kiválasztását (például a "HIERARCHIABAN" feltétel használatakor ne használjon üres értéket)
• Az információs bázis tervezésekor kellően nagy bitmélységi tartalékot kell biztosítani a számok számára (különben az összeadás és szorzás nem kommutatív és nem asszociatív lesz, ami megnehezíti a hibakeresést)
• A végrehajtható lekérdezésekben ellenőrizze a műveleti logikát a NULL értékek jelenlétére, valamint a lekérdezési feltételek és kifejezések helyes működésére a NULL használatával.
• Gyűjtemények használatakor szabályozza azok átvitelének lehetőségét az alkalmazáskiszolgáló és a kliens oldal között.

Terminál hozzáférés használata a kliens oldalon a hozzáférés korlátozására

Gyakran találhat javaslatokat a terminálhozzáférés használatára az adatokhoz való hozzáférés korlátozására és a teljesítmény javítására az ügyféloldali kód végrehajtásával a terminálkiszolgálón. Igen, helyesen konfigurálva a terminálhozzáférés használata valóban növelheti a rendszerbiztonság általános szintjét, de sajnos gyakran találkozhatunk azzal, hogy a gyakorlati használat során a rendszer biztonsága csak csökken. Próbáljuk meg kitalálni, hogy ez mihez kapcsolódik. A terminálhoz való hozzáférés megszervezésének két gyakori módja van, ezek a Microsoft Terminal Services (RDP protokoll) és a Citrix Metaframe Server (ICA protokoll). Általánosságban elmondható, hogy a Citrix eszközök sokkal rugalmasabb hozzáférési adminisztrációs lehetőségeket biztosítanak, de ezeknek a megoldásoknak az ára jóval magasabb. Csak azokat az alapvető jellemzőket vesszük figyelembe, amelyek mindkét protokollban közösek, amelyek csökkenthetik az általános biztonsági szintet. Csak három fő veszély fenyeget a terminálhozzáférés használatakor:

• Képes blokkolni más felhasználók munkáját túlzott mennyiségű erőforrás lefoglalásával
• Hozzáférés más felhasználók adataihoz.
• Adatok jogosulatlan másolása a terminálkiszolgálóról a felhasználó számítógépére

A Terminálszolgáltatások minden esetben lehetővé teszik, hogy:

• Növelje a munkavégzés megbízhatóságát (ha a terminál számítógép meghibásodik, a felhasználó ezután ugyanonnan folytathatja a munkát)
• Korlátozza a hozzáférést az ügyfélalkalmazáshoz és az általa mentett fájlokhoz.
• Vigye át a számítási terhelést a felhasználó munkaállomásáról a terminálhozzáférési kiszolgálóra
• A rendszerbeállításokat központilag kezelheti. A felhasználók számára az elmentett beállítások attól függetlenül érvényesek, hogy melyik számítógépről jelentkeztek be a rendszerbe.
• Bizonyos esetekben terminálmegoldást is használhat a rendszer távoli eléréséhez.

Egy felhasználóra korlátozni kell a terminálkiszolgálóhoz fűződő lehetséges kapcsolatok számát

Az 1C kliens alkalmazás erőforrásokkal kapcsolatos „falánksága” miatt feltétlenül korlátozni kell egy felhasználó (operátor) egyidejű kapcsolatainak maximális számát a terminálkiszolgálóhoz. Egy aktívan használt kapcsolat akár 300 MB memóriát is használhat az alkalmazás egyetlen példányával. A memória mellett a CPU-időt is aktívan használják, ami szintén nem járul hozzá a szerver felhasználóinak stabilitásához. A szervererőforrások túlzott használatának megakadályozásával egyidejűleg egy ilyen korlátozás megakadályozhatja valaki más fiókjának használatát. A terminálkiszolgáló szabványos beállításaival valósítják meg.

Ne engedje meg, hogy egy vagy két 1C ügyfélalkalmazás egyidejűleg fusson egy kapcsolaton belül

Ugyanazok az okok diktálják, mint az előző bekezdésben, de technikailag nehezebb megvalósítani. A probléma az, hogy szinte lehetetlen megakadályozni az 1C újraindítását terminálszerver eszközökkel (miért az alábbiakban lesz elmagyarázva), ezért ezt a funkciót az alkalmazásmegoldás szintjén kell megvalósítani (ami szintén nem jó megoldás, mivel A munkamenetek egy ideig „lógva” maradhatnak. Ha az alkalmazást helytelenül zárják le, akkor az alkalmazásmodulban és néhány referenciakönyvben finomítani kell az alkalmazásmegoldást, ami megnehezíti az 1C-ből származó frissítések használatát. Nagyon kívánatos meghagyni a felhasználónak 2 alkalmazás futtatásának lehetőségét, hogy bizonyos műveleteket (például jelentések generálását) a háttérben lehessen futtatni - az ügyfélalkalmazás sajnos valójában egyszálú.

Nem ajánlott hozzáférési jogokat adni a terminálkiszolgálóhoz azoknak a felhasználóknak, akiknek joguk van erőforrás-igényes számítási feladatokat futtatni az 1C-ben, vagy megakadályozni az ilyen indításokat, miközben más felhasználók aktívan dolgoznak.

Természetesen jobb, ha a terminálkiszolgálóhoz való hozzáférést csak azoknak a felhasználóknak hagyjuk meg, akik nem használnak olyan feladatokat, mint például az adatbányászat, a földrajzi diagramok, az import/exportálás és más olyan feladatok, amelyek komolyan terhelik az alkalmazás kliens részét. Ha továbbra is szükség van ilyen feladatok engedélyezésére, akkor: értesíteni kell a felhasználót, hogy ezek a feladatok befolyásolhatják más felhasználók teljesítményét, rögzíteni a naplóban egy ilyen folyamat kezdetét és végét, csak szabályozott helyen engedélyezni a végrehajtást. idő stb.

Gondoskodni kell arról, hogy minden felhasználó csak a terminálkiszolgáló szigorúan meghatározott könyvtáraihoz rendelkezzen írási jogokkal, és más felhasználók ne férhessenek hozzájuk.

Először is, ha nem korlátozza az írás lehetőségét megosztott könyvtárakra (például arra a könyvtárra, ahol az 1C telepítve van), akkor a támadó továbbra is módosíthatja a program viselkedését az összes felhasználó számára. Másodszor, az egyik felhasználó adatai (ideiglenes fájlok, jelentésbeállítások mentésére szolgáló fájlok stb.) semmilyen körülmények között nem férhetnek hozzá a terminálszerver másik felhasználója számára - általában a normál konfiguráció során ezt a szabályt betartják. Harmadszor, a támadónak továbbra is lehetősége van „szemetetni” a partíciót, hogy ne maradjon hely a merevlemezen. Tudom, hogy kifogásolják, hogy a Windows operációs rendszernek a Windows 2000-től kezdve van kvótamechanizmusa, de ez egy meglehetősen drága mechanizmus, és gyakorlatilag soha nem láttam érdemi hasznát.

Ha a hozzáférés beállításának korábbi kérdései általában meglehetősen könnyen megvalósíthatók, akkor az olyan (látszólag) egyszerű feladat, mint a felhasználói hozzáférés szabályozása a fájlokhoz, nem triviálisan valósul meg. Először is, ha nem használja a kvóta mechanizmust, akkor nagy fájlok menthetők. Másodszor, a rendszer úgy van felépítve, hogy szinte mindig el lehet menteni a fájlt, hogy az elérhető legyen egy másik felhasználó számára.

Tekintettel arra, hogy a feladatot nehéz teljesen megoldani, ajánlatos a legtöbb fájleseményt auditálni

Meg kell tiltani a lemezeszközök, nyomtatók és a kliens munkaállomás vágólapjának csatlakoztatását (leképezését).

Az RDP-ben és ICA-ban lehetőség van a terminál számítógép lemezeinek, nyomtatóinak, vágólap com portjainak a szerverhez való automatikus csatlakozásának megszervezésére. Ha ez a lehetőség fennáll, akkor szinte lehetetlen megakadályozni az idegen kód elindítását a terminálkiszolgálón és az adatok mentését az 1C-ből a terminálhozzáférési kliensen. Ezeket a funkciókat csak rendszergazdai jogokkal rendelkezők engedélyezik.

A terminálkiszolgálóról érkező hálózati fájlokhoz való hozzáférést korlátozni kell.

Ha ez nem történik meg, a felhasználó ismét képes lesz nem kívánt kód futtatására vagy adatok mentésére. Mivel a normál napló nem követi a fájleseményeket (egyébként jó ötlet a platformfejlesztők számára), és szinte lehetetlen rendszerauditot beállítani a teljes hálózaton (nincs elegendő erőforrás a karbantartásához), jobb, ha a felhasználó nyomtatni vagy e-mailben is küldhet adatokat. Különös figyelmet fordítson annak biztosítására, hogy a terminálkiszolgáló ne működjön közvetlenül a felhasználók cserélhető adathordozójával.

Biztonságos rendszer létrehozásakor semmilyen körülmények között ne hagyja az alkalmazáskiszolgálót a terminálkiszolgálón.

Ha az alkalmazáskiszolgáló ugyanazon a számítógépen fut, mint az ügyfélalkalmazások, akkor számos lehetőség van a normál működés megzavarására. Ha valamilyen okból nem lehet szétválasztani a terminálkiszolgáló és az alkalmazásszerver funkcióit, akkor fordítson különös figyelmet az alkalmazásszerver által használt fájlok felhasználói hozzáférésére.

Ki kell zárni annak lehetőségét, hogy az 1C:Enterprise kivételével minden alkalmazás futhasson a terminálkiszolgálón.

Ez az egyik legnehezebben megvalósítható kívánság. Kezdjük azzal, hogy helyesen kell konfigurálnia a csoport biztonsági házirendjét a tartományban. Minden felügyeleti sablont és szoftverkorlátozási szabályzatot megfelelően kell konfigurálni. A teszteléshez győződjön meg arról, hogy legalább a következő funkciók le vannak tiltva:

E követelmény végrehajtásának összetettsége gyakran egy „extra” 1C munkamenet indításának lehetőségéhez vezet a terminálkiszolgálón (még ha más alkalmazások korlátozottak is, alapvetően lehetetlen megtiltani az 1C elindítását a Windows használatával).

Vegye figyelembe a normál napló korlátait (minden felhasználó egy számítógépről használja a programot)

Nyilvánvaló, hogy mivel a felhasználók terminál módban nyitják meg az 1C-t, a terminálkiszolgáló rögzítésre kerül a naplóban. A napló nem jelzi, hogy a felhasználó melyik számítógépről csatlakozott.

Terminálkiszolgáló – védelem vagy sebezhetőség?

Az északi terminál főbb jellemzőit átgondolva tehát azt mondhatjuk, hogy az északi terminál potenciálisan segíthet az automatizálásban a számítási terhelés elosztásában, de egy biztonságos rendszer felépítése meglehetősen nehéz. Az egyik olyan eset, amikor a terminálkiszolgáló használata a leghatékonyabb, amikor az 1C-t Windows Intéző nélkül, teljes képernyős módban futtatja korlátozott funkcionalitású és speciális felülettel rendelkező felhasználók számára.

A kliens rész munkája

Internet Explorer (IE) használata

Az 1C kliens rész normál működésének egyik feltétele az Internet Explorer összetevőinek használata. Nagyon óvatosnak kell lennie ezekkel az összetevőkkel.

Figyelem! Először is, ha egy spyware vagy adware modul „csatolva” van az IE-hez, akkor az akkor is betöltődik, ha 1C-ben tekint meg HTML fájlokat. Eddig nem tapasztaltam ennek a funkciónak a tudatos használatát, de az egyik szervezetben láttam, hogy az egyik pornográf hálózatról betöltött „kém” modul fut 1C-vel (a vírusirtó program nem frissült, ennek tüneteit észlelték : a tűzfal beállításakor egyértelmű volt, hogy az 1C a 80-as porton próbált csatlakozni egy pornóoldalhoz). Valójában ez egy újabb érv amellett, hogy a védelemnek átfogónak kell lennie

Figyelem! Másodszor, az 1C rendszer lehetővé teszi Flash filmek, ActiveX objektumok, VBScript használatát a megjelenített HTML dokumentumokban, adatküldést az internetre, akár PDF fájlok megnyitását (!), bár ez utóbbi esetben „nyissa meg vagy mentse”... Általában mindent, amire a szíved vágyik. Példa a beépített HTML-megtekintési és -szerkesztési lehetőségek nem teljesen ésszerű használatára:

• Hozzon létre egy új HTML-dokumentumot (Fájl -> Új -> HTML-dokumentum).
• Lépjen egy üres dokumentum "Szöveg" lapjára.
• Távolítsa el a szöveget (teljesen).
• Lépjen a dokumentum "Nézet" lapjára
• A drag-n-drop segítségével vigyen át egy SWF kiterjesztésű fájlt (ezek a Flash-filmfájlok) egy nyitott Explorerből egy dokumentumablakba, például a böngésző gyorsítótárából, bár szórakozásból használhat FLASH játékot is.
• Milyen kedves! 1C-n futtathatsz játékot!

Rendszerbiztonsági szempontból ez teljesen rossz. Eddig nem láttam különleges támadást az 1C ellen ezen a sérülékenységen keresztül, de valószínűleg ez idő és az Ön információi értékének kérdése lesz.

Vannak más kisebb problémák is, amelyek a HTML-dokumentummezőkkel való munka során merülnek fel, de a legfontosabbak a felsorolt ​​kettő. Bár, ha kreatívan közelíti meg ezeket a funkciókat, valóban lenyűgöző interfész-képességeket szervezhet az 1C-vel való munkavégzéshez.

Külső jelentések és feldolgozás használata.

Figyelem! A külső jelentések és feldolgozás - egyrészt kényelmes módot jelentenek a további nyomtatott űrlapok, a hatósági jelentések és a speciális jelentések megvalósítására, másrészt lehetőség nyílik számos rendszerbiztonsági korlátozás megkerülésére és az alkalmazás működésének megzavarására szerver (példát lásd fent a „Paraméterek átadása” részben). Az 1C rendszerben van egy speciális paraméter a jogkészletben a „Külső feldolgozás interaktív megnyitása” szerepkörhöz, de ez nem oldja meg teljesen a problémát - a teljes megoldáshoz szűkíteni kell a kezelni tudó felhasználók körét. külső nyomtatott űrlapok, hatósági jelentések és a külső kezelésekkel megvalósított szabványos megoldások egyéb szabványos képességei. Például az UPP-ben alapértelmezés szerint minden fő felhasználói szerepkör képes további nyomtatott űrlapok könyvtárával dolgozni, és ez valójában bármilyen külső feldolgozás használatának képessége.

Szabványos mechanizmusok használata szabványos megoldásokhoz és platformokhoz (adatcsere)

Egyes szabványos mechanizmusok potenciálisan veszélyesek, és váratlan módon.

Listák nyomtatása

A rendszer bármely listája (például könyvtár vagy információs regiszter) kinyomtatható vagy fájlba menthető. Ehhez használja a helyi menüből és a „Műveletek” menüből elérhető standard szolgáltatást:

Ne feledje, hogy gyakorlatilag minden, amit a felhasználó a listákban lát, kiírható külső fájlba. Csak azt tudom javasolni, hogy vezessen naplót a nyomtatószervereken történő dokumentumnyomtatásról. A különösen kritikus űrlapoknál be kell állítani a védett táblamezőhöz tartozó műveleti panelt úgy, hogy a lista megjelenítésének lehetősége ne legyen elérhető erről a panelről, és le kell tiltani a helyi menüt (lásd 6. ábra).

Adatcsere elosztott adatbázisban

Az adatcsere formátuma meglehetősen egyszerű, és a dokumentációban le van írva. Ha a felhasználónak lehetősége van több fájl cseréjére, akkor jogosulatlan változtatásokat hajthat végre a rendszeren (bár ez meglehetősen munkaigényes feladat). A perifériás adatbázis létrehozásának lehetősége elosztott adatbáziscsere-tervek használatakor nem állhat rendelkezésre a hétköznapi operátorok számára.

Szabványos XML adatcsere

A szabványos adatcserében, amelyet a szabványos konfigurációk közötti cserére használnak (például „Trade Management” és „Enterprise Accounting”), lehetőség van eseménykezelők megadására az objektumok be- és kirakodásához a csereszabályokban. Ezt úgy valósítjuk meg, hogy a fájlból egy kezelőt kapunk, és a „Run()” eljárást a fájlok be- és kirakodásának szabványos feldolgozásához (a „Run()” eljárás a kliens oldalon indul el). Nyilvánvalóan nem nehéz létrehozni egy ilyen hamis cserefájlt, amely rosszindulatú műveleteket hajt végre. A szabványos megoldások legtöbb felhasználói szerepkörénél a megosztás alapértelmezés szerint engedélyezett.

Ajánlást: korlátozza az XML adatcseréhez való hozzáférést a legtöbb felhasználó számára (csak az információbiztonsági rendszergazdákra hagyja). Vezessen naplót a feldolgozás indításairól, mentse el a cserefájlt, például küldje el e-mailben az információbiztonsági rendszergazdának a letöltés előtt.

Általános jelentések használata, különösen a Reports Console

Egy másik probléma az alapértelmezett felhasználói hozzáférés az általános jelentésekhez, különösen a Jelentéskonzol jelentéshez. Ezt a jelentést az a tény jellemzi, hogy lehetővé teszi szinte bármilyen információbiztonsági kérés végrehajtását, és még ha az 1C jogrendszer (beleértve az RLS-t is) meglehetősen szigorúan van konfigurálva, lehetővé teszi a felhasználó számára sok „extra” információ megszerzését. és arra kényszeríti a szervert, hogy olyan kérést hajtson végre, amely az összes erőforrásrendszert felemészti.

Teljes képernyős mód használata (asztali mód)

A programfunkciókhoz korlátozott hozzáféréssel rendelkező speciális felületek szervezésének egyik hatékony módja a használt interfész fő (és esetleg egyetlen) formájának teljes képernyős módja. Ebben az esetben nincs akadálymentesítési probléma, például a „Fájl” menü és az összes felhasználói művelet korlátozva van a használt űrlap képességei miatt. További részletekért lásd az "Asztali mód megvalósításának jellemzői" című részt az ITS lemezen.

biztonsági mentés

Az 1C kliens-szerver verziójának biztonsági mentése kétféleképpen hajtható végre: adatok feltöltése egy dt kiterjesztésű fájlba, és biztonsági másolatok létrehozása SQL használatával. Az első módszernek számos hátránya van: kizárólagos hozzáférés szükséges, maga a másolat létrehozása sokkal tovább tart, bizonyos esetekben (ha az információbiztonsági struktúra sérül) lehetetlen archívum létrehozása, de van egy előnye - a minimális méret az archívum. Az SQL biztonsági mentésnél ennek az ellenkezője igaz: a másolat létrehozása a háttérben történik az SQL szerver segítségével, az egyszerű felépítés és a tömörítés hiánya miatt – ez egy nagyon gyors folyamat, és mindaddig, amíg az SQL fizikai integritása megtörténik. adatbázis nem törik, a biztonsági mentés megtörténik, de a másolat mérete egybeesik a valódi méretével az információbiztonság méretével kibontott állapotban (tömörítés nem történik meg). Az MS SQL biztonsági mentési rendszer további előnyei miatt célszerűbb használni (3 féle mentés megengedett: teljes, differenciális, tranzakciós naplómásolat; lehetőség van rendszeresen végrehajtott feladatok létrehozására; biztonsági másolat és biztonsági mentés a rendszer gyorsan üzembe helyezhető, megjósolható a szükséges lemezterület mérete stb.). A biztonsági mentés megszervezésének főbb pontjai rendszerbiztonsági szempontból a következők:

• A biztonsági mentések tárolási helyét úgy kell kiválasztani, hogy azok ne legyenek elérhetők a felhasználók számára.
• A biztonsági mentések fizikai távolságban való tárolásának szükségessége az MS SQL szervertől (természeti katasztrófák, tűzesetek, támadások stb. esetén)
• Lehetőség a biztonsági mentés elindításához szükséges jogok megadására olyan felhasználónak, aki nem fér hozzá a biztonsági másolatokhoz.

További részletekért tekintse meg az MS SQL dokumentációját.

Adat titkosítás

Az adatok jogosulatlan hozzáféréssel szembeni védelmére gyakran alkalmaznak különféle kriptográfiai eszközöket (szoftvert és hardvert egyaránt), de ezek megvalósíthatósága nagymértékben függ a helyes alkalmazástól és a rendszer általános biztonságától. Megvizsgáljuk az adattitkosítást az adatátvitel és -tárolás különböző szakaszaiban a leggyakoribb eszközökkel, valamint a kriptográfiai eszközökkel történő rendszertervezés főbb hibáit.

Az információfeldolgozás több fő szakasza védhető:

• Adatátvitel a rendszer kliens része és az alkalmazásszerver között
• Adatátvitel az alkalmazásszerver és az MS SQL Server között
• MS SQL Serveren tárolt adatok (adatfájlok a fizikai lemezen)
• Az információbiztonságban tárolt adatok titkosítása
• Külső adatok (információbiztonsággal kapcsolatban)

A kliens oldalon és az alkalmazásszerveren tárolt adatoknál (mentett felhasználói beállítások, információbiztonsági lista stb.) a titkosítás csak nagyon ritka esetekben indokolt, ezért itt nem vesszük figyelembe. A kriptográfiai eszközök használata során nem szabad megfeledkeznünk arról, hogy használatuk jelentősen csökkentheti a rendszer egészének teljesítményét.

Általános információk a hálózati kapcsolatok kriptográfiai védelméről a TCP/IP protokoll használatakor.

Biztonság nélkül minden hálózati kapcsolat ki van téve a jogosulatlan felügyeletnek és hozzáférésnek. Védelmük érdekében hálózati protokoll szintű adattitkosítást használhat. A helyi hálózaton továbbított adatok titkosításához leggyakrabban az operációs rendszer által biztosított IPSec-eszközöket használják.

Az IPSec eszközök biztosítják a továbbított adatok titkosítását DES és 3DES algoritmusok segítségével, valamint integritás-ellenőrzést MD5 vagy SHA1 hash függvényekkel. Az IPSec két üzemmódban működhet: szállítási módban és alagút üzemmódban. A szállítási mód alkalmasabb a helyi hálózaton történő kapcsolatok biztosítására. Az alagút mód használható VPN-kapcsolatok megszervezésére külön hálózati szegmensek között, vagy nyílt adatcsatornákon keresztül a helyi hálózat távoli kapcsolatának védelmére.

Ennek a megközelítésnek a fő előnyei a következők:

• Központosított biztonságkezelés lehetősége Active Directory eszközökkel.
• Az alkalmazáskiszolgálóhoz és az MS SQL szerverhez való jogosulatlan kapcsolatok kizárásának képessége (például lehetőség van az információbiztonság jogosulatlan kiegészítése elleni védelemre az alkalmazáskiszolgálón).
• A hálózati forgalom "hallgatásának" megszüntetése.
• Nincs szükség az alkalmazási programok (jelen esetben az 1C) viselkedésének megváltoztatására.
• Egy ilyen megoldás standard jellege.

Ennek a megközelítésnek azonban vannak korlátai és hátrányai:

• Az IPSec nem védi meg az adatokat közvetlenül a forrás- és célszámítógépeken az interferenciától és a lehallgatástól.
• A hálózaton keresztül továbbított adatmennyiség valamivel nagyobb, mint az IPSec használata nélkül.
• IPSec használatakor a központi processzor terhelése valamivel nagyobb.

Az IPSec-eszközök megvalósításának részletes leírása túlmutat e cikk keretein, és megköveteli az IP-protokoll működésének alapelveinek megértését. A kapcsolat biztonságának megfelelő beállításához olvassa el a vonatkozó dokumentációt.

A VPN-kapcsolatok szervezésekor külön meg kell említeni az 1C-vel kötött licencszerződés több szempontját. A tény az, hogy a műszaki korlátozások hiánya ellenére a helyi hálózat több szegmensének csatlakoztatásakor vagy egy számítógép távoli elérésekor a helyi hálózathoz általában több alapvető kellékre van szükség.

Az adatok titkosítása a rendszer kliens része és az alkalmazáskiszolgáló között.

A hálózati protokoll szintű titkosítás mellett lehetőség van az adatok COM+ protokoll szintű titkosítására is, amelyről az ITS „Az információs bázis felhasználói hozzáférésének szabályozása kliens-szerver verzióban” című cikkében van szó. A megvalósításhoz be kell állítania a hívások hitelesítési szintjét a „Csomagvédelem” értékre az 1CV8 alkalmazáshoz az „Összetevő szolgáltatásokban”. Ebben az üzemmódban a csomag hitelesítése és titkosítása történik, beleértve az adatokat, valamint a feladó személyazonosságát és aláírását.

Adatok titkosítása az alkalmazásszerver és az MS SQL Server között

Az MS SQL Server a következő eszközöket kínálja az adatok titkosításához:

• Lehetőség van Secure Sockets Layer (SSL) használatára az alkalmazáskiszolgáló és az MS SQL Server közötti adatátvitel során.
• A Multiprotocol hálózati könyvtár használatakor az adattitkosítás RPC szinten történik. Ez potenciálisan gyengébb titkosítás, mint az SSL használata.
• Ha a Shared Memory Exchange protokollt használják (ez akkor történik, ha az alkalmazáskiszolgáló és az MS SQL Server ugyanazon a számítógépen található), akkor a titkosítás semmi esetre sem kerül alkalmazásra.

Annak megállapításához, hogy egy adott MS SQL-kiszolgálóhoz szükséges-e az összes továbbított adat titkosítása, a "Server Network Utility" segédprogramot kell használnia. Futtassa, és az "Általános" lapon jelölje be a "Protokoll titkosítás kényszerítése" jelölőnégyzetet. A titkosítási módszer kiválasztása az ügyfélalkalmazás (azaz az 1C alkalmazásszerver) által használt módszertől függően történik. Az SSL használatához megfelelően konfigurálnia kell a tanúsítványszolgáltatást a hálózaton.

Annak beállításához, hogy az összes továbbított adatot titkosítani kell egy adott alkalmazáskiszolgálóhoz, a "Client Network Utility" segédprogramot kell használnia (amely általában a "C:\WINNT\system32\cliconfg.exe" fájlban található). Az előző esethez hasonlóan az "Általános" lapon jelölje be a "Protokoll titkosítás kényszerítése" jelölőnégyzetet.

Érdemes megfontolni, hogy a titkosítás használata ebben az esetben jelentős hatással lehet a rendszer teljesítményére, különösen nagy mennyiségű információt visszaadó lekérdezések esetén.

Az alkalmazásszerver és az MS SQL Server közötti kapcsolat teljesebb védelme érdekében TCP/IP protokoll használatakor több változtatást is javasolhatunk az alapértelmezett beállításokon.

Először is beállíthat a szabványostól eltérő portot (alapértelmezés szerint az 1433-as portot használja). Ha úgy dönt, hogy nem szabványos TCP portot használ az adatcseréhez, vegye figyelembe, hogy:

• Az MS SQL szervernek és az alkalmazásszervernek ugyanazt a portot kell használnia.
• Tűzfalak használatakor ezt a portot engedélyezni kell.
• Nem állíthat be olyan portot, amelyet más alkalmazások használhatnak az MS SQL szerveren. Referenciaként használhatja a http://www.ise.edu/in-notes/iana/assignments/port-numbers címet (az SQL Server Books Online-ból vett cím).
• Ha az MS SQL Server szolgáltatás több példányát használja, feltétlenül olvassa el az MS SQL dokumentációját a konfigurációhoz ("Hálózati kapcsolatok konfigurálása" szakasz).

Másodszor, az MS SQL szerveren a TCP/IP protokoll beállításaiban beállíthatja a "Szerver elrejtése" jelzőt, amely megtiltja az MS SQL Server szolgáltatás ezen példányára vonatkozó üzenetszórási kérésekre adott válaszokat.

A lemezen tárolt MS SQL adatok titkosítása

A helyi lemezen található adatok titkosítására szolgáló szoftverek és hardverek meglehetősen nagy választéka áll rendelkezésre (ez magában foglalja a Windows szabványos EFS-használati képességét, az eToken kulcsok használatát és a harmadik féltől származó programokat, mint például a Jetico Bestcrypt vagy a PGPDisk). Ezeknek az eszközöknek az egyik fő feladata az adatok védelme adathordozó elvesztése esetén (például egy szerver ellopásakor). Különösen érdemes megjegyezni, hogy a Microsoft nem javasolja az MS SQL adatbázisok titkosított adathordozón való tárolását, és ez meglehetősen indokolt. Ezzel a fő probléma a teljesítmény jelentős csökkenése és a meghibásodások miatti esetleges megbízhatósági problémák. A második, a rendszeradminisztrátor életét megnehezítő tényező az, hogy biztosítani kell az összes adatbázisfájl elérhetőségét, amikor az MS SQL szolgáltatás először hozzáfér hozzájuk (azaz kívánatos, hogy az interaktív műveletek ne legyenek kizárva titkosított adathordozó csatlakoztatásakor).

A rendszerteljesítmény észrevehető visszaesésének elkerülése érdekében az MS SQL segítségével több fájlban is létrehozhat adatbázisokat. Természetesen ebben az esetben az MS SQL adatbázist nem az 1C szervernek kell létrehoznia az infobázis létrehozásakor, hanem külön kell létrehozni. Az alábbiakban látható egy példa egy megjegyzésekkel ellátott TSQL-szkriptre:

USE mester
MEGY
-- Hozzon létre egy adatbázist SomeData,
ADATBÁZIS LÉTREHOZÁSA SomeData
-- melynek adatai teljes egészében a PRIMARY fájlcsoportban találhatók.
AZ ELSŐDLEGES
-- A fő adatfájl titkosított adathordozón található (E logikai meghajtó:)
-- és a kezdeti mérete 100 MB, automatikusan 200 MB-ra növelhető
-- 20 MB lépések
(NAME = SomeData1,
FILENAME = "E:\SomeData1.mdf",
MÉRET = 100 MB,
MAXSIZE = 200,
FÁJNÖVEKEDÉS = 2),
-- A második adatfájl titkosítatlan adathordozón található (C logikai meghajtó:)
-- és a kezdeti mérete 100 MB, automatikusan a korlátig növelhető
-- lemezterület az aktuális fájlméret 5%-os lépésekben (64 KB-ra kerekítve)
(NAME = SomeData2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
MÉRET = 100 MB,
MAXSIZE = KORLÁTALAN,
FÁJNÖVEKEDÉS = 5%)
BEJELENTKEZNI
-- Bár a tranzakciós napló részekre is osztható, ezt nem szabad megtenni,
-- mert ez a fájl sokkal gyakrabban változik, és rendszeresen megtisztítják (például amikor
-- adatbázis biztonsági másolat készítése).
(NAME = SomeDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
MÉRET = 10 MB,
MAXSIZE = KORLÁTALAN,
FÁJNÖVEKEDÉS = 10)
MEGY
-- Jobb, ha azonnal átadja az adatbázis tulajdonjogát annak a felhasználónak, akinek a nevében
-- 1C fog csatlakozni. Ehhez deklarálnunk kell az aktuális bázist
- most jött létre,
HASZNÁLJON SomeData
MEGY
-- és futtassa az sp_changedbowner parancsot
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Egy rövid kitérő az adatfájl méretének automatikus növekedéséről. Alapértelmezés szerint az új adatbázisok fájlmérete az aktuális fájlméret 10%-ával nő. Ez egy teljesen elfogadható megoldás kis adatbázisokhoz, de nem túl jó a nagyokhoz: például 20 GB-os adatbázisméret esetén a fájlnak azonnal 2 GB-tal kell növekednie. Bár ez az esemény meglehetősen ritkán fordul elő, több tíz másodpercig is eltarthat (ez alatt az idő alatt az összes többi tranzakció gyakorlatilag tétlen), ami, ha az adatbázissal való aktív munka során történik, hibákat okozhat. Az arányos növekmény második negatív következménye, amely akkor fordul elő, ha a lemezterület majdnem teljesen megtelt, az idő előtti meghibásodás valószínűsége az elégtelen szabad hely miatt. Például, ha egy 40 GB kapacitású lemezpartíció teljesen egy adatbázishoz (pontosabban ennek az adatbázisnak egy fájljához) van dedikálva, akkor az adatbázisfájl kritikus mérete, amelynél sürgősen (nagyon sürgősen, a felhasználók normál munkájának megszakításáig) az információtárolás átszervezéséhez az adatfájl mérete 35 GB. A 10-20 MB-ra beállított növekedési mérettel addig folytathatja a munkát, amíg el nem éri a 39 GB-ot.

Ezért, bár a fenti felsorolás az egyik adatbázisfájl méretének növelését írja elő 5%-os lépésekben, nagy adatbázisméretek esetén jobb, ha fix 10-20 MB-os növekményt állít be. Az adatbázis fájlméret-növekedési értékeinek beállításakor figyelembe kell venni, hogy amíg egy fájlcsoport egyik fájlja el nem éri a maximális méretét, addig a szabály érvényes: az egy fájlcsoportban lévő fájlok egyszerre növekednek. időben, amikor mindegyik teljesen megtelt. Tehát a fenti példában, amikor a SomeData1.mdf fájl eléri a 200 MB-os maximális méretét, a SomeData2.ndf fájl mérete körülbelül 1,1 GB lesz.

Egy ilyen adatbázis létrehozása után, még ha a nem védett SomeData2.ndf és SomeData.ldf fájljai is elérhetővé válnak egy támadó számára, rendkívül nehéz lesz visszaállítani az adatbázis valódi állapotát - az adatokat (beleértve az adatbázis logikai szerkezetére vonatkozó információkat is). ).

Természetesen, ha az adatbázisfájlokat titkosítással tárolják, akkor (legalábbis ezekről a fájlokról) nem szabad titkosítatlan adathordozóra biztonsági másolatot készíteni. Az egyes adatbázisfájlok biztonsági mentéséhez használja a megfelelő BACKUP DATABASE parancs szintaxisát. Kérjük, vegye figyelembe, hogy bár lehetséges jelszóval védeni egy adatbázis-mentést (a "BACKUP DATABASE" parancs "PASSWORD = " és "MEDIAPASSWORD = " beállításai), az ilyen biztonsági mentés nem válik titkosítottá!

A lemezeken tárolt alkalmazáskiszolgáló és kliens adatok titkosítása

A legtöbb esetben nem tekinthető indokoltnak az 1C:Enterprise által használt fájlok (kliens rész és alkalmazásszerver) titkosított adathordozón való tárolása az indokolatlanul magas költségek miatt, azonban ha ilyen igény fennáll, vegye figyelembe, hogy az alkalmazásszerver és a kliens rész az alkalmazás nagyon gyakran hoz létre ideiglenes fájlokat. Ezek a fájlok gyakran az alkalmazás futásának befejezése után is megmaradhatnak, és szinte lehetetlen garantálni az eltávolításukat az 1C eszközökkel. Így szükségessé válik az ideiglenes fájlokhoz használt könyvtár titkosítása az 1C-ben, vagy ne tárolja a lemezen RAM-meghajtó segítségével (az utóbbi lehetőség nem mindig lehetséges a generált fájlok mérete és az 1C:Enterprise RAM-igényei miatt maga az alkalmazás).

Adattitkosítás a beépített 1C eszközökkel.

Az 1C-ben a titkosítás használatának szabványos lehetőségei a titkosítási paraméterekkel rendelkező Zip-fájlok használatához szükséges objektumok használatán alapulnak. A következő titkosítási módok állnak rendelkezésre: AES algoritmus 128, 192 vagy 256 bites kulccsal és egy elavult, eredetileg a Zip archiválóban használt algoritmus. Az AES-sel titkosított ZIP-fájlokat sok archiváló nem tudja elolvasni (WinRAR, 7zip). Titkosított adatokat tartalmazó fájl létrehozásához meg kell adnia egy jelszót és a titkosítási algoritmust. Az alábbiakban látható a legegyszerűbb példa az ezen a funkción alapuló titkosítási-dekódolási funkciókra:

Funkció EncryptData (Adat, Jelszó, Titkosítási módszer = Undefined) Export

// Írja be az adatokat egy ideiglenes fájlba. Valójában nem minden adat menthető így.
ValueInFile(IdeiglenesFájlnév, Adat);

// Ideiglenes adatok írása az archívumba
Zip = New ZipFileRecord(IdeiglenesArchiveFileName, Password,Titkosítási módszer);
Zip.Add(TemporaryFileName);
Zip.Write();

// Adatok beolvasása a fogadott archívumból a RAM-ba
EncryptedData = ÚjÉrtékTárolás(ÚjBinárisAdat(Archív IdeiglenesFájlnév));

// Ideiglenes fájlok – törlés

EndFunctions függvény DecryptData (titkosított adatok, jelszó) Exportálás

// Figyelem! Az átadott paraméterek helyességét a rendszer nem ellenőrzi

// Írja be az átadott értéket egy fájlba
ArchívumTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinárisArchiveData.Write(ArchiveTemporaryFileName);

// Az éppen írt archívum első fájljának kibontása
TemporaryFileName = GetTemporaryFileName();
Zip = New ReadZipFile(IdeiglenesArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Olvassa el az írott fájlt
Data = ValueFromFile(IdeiglenesFileName + "\" + Zip.Items.Name);

//Ideiglenes fájlok törlése
DeleteFiles(IdeiglenesFájlnév);
DeleteFiles(ArchiveTemporaryFileName);

Adatok visszaküldése;

EndFunction

Természetesen ez a módszer nem nevezhető ideálisnak - az adatok egy ideiglenes mappába íródnak tiszta szöveggel, a módszer teljesítménye őszintén szólva rosszabb, mint valaha, az adatbázisban való tárolás rendkívül nagy helyet igényel, de ez az egyetlen módszer, amely csak a platform beépített mechanizmusain alapul. Ezenkívül számos más módszerrel szemben előnye van - ez a módszer egyszerre csomagolja az adatokat a titkosítással együtt. Ha a titkosítást ennek a módszernek a hátrányai nélkül kívánja megvalósítani, akkor vagy külső komponensben kell megvalósítania, vagy COM-objektumok létrehozásával, például a Microsoft CryptoAPI segítségével meglévő könyvtárakhoz kell fordulnia. Példaként adjuk meg a kapott jelszó alapján egy karakterlánc titkosítási/visszafejtési funkcióit.

Funkció EncryptStringDES (titkosítatlan karakterlánc, jelszó)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Ez az állandó a CryptoAPI-ból származik

EncryptionMechanism.Content = UnencryptedString;
Titkosítási motor.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

return EncryptedString;

EndFunction // EncryptStringDES()

Funkció DecryptStringDES (titkosított karakterlánc, jelszó)

//Figyelem! A paraméterek nincsenek ellenőrizve!

Titkosítási motor = New COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Password);
Kísérlet
EncryptionMechanism.Decrypt(EncryptedString);
Kivétel
// Hibás jelszó!;
Return Undefined;
EndAttempt;

ReturnEncryptionMechanism.Content;

EndFunction // DecryptStringDES()

Kérjük, vegye figyelembe, hogy ha egy üres értéket karakterláncként vagy jelszóként ad át ezeknek a függvényeknek, az hibaüzenetet generál. Az ezzel a titkosítási eljárással kapott karakterlánc valamivel hosszabb, mint az eredeti. Ennek a titkosításnak az a sajátossága, hogy ha kétszer titkosít egy karakterláncot, a kapott karakterláncok NEM lesznek azonosak.

Alapvető hibák a kriptográfiai eszközök használatakor.

A kriptográfiai eszközök használatakor gyakran ugyanazokat a hibákat követik el:

A teljesítménybüntetés alábecsülése kriptográfia használatakor.

A kriptográfia meglehetősen sok számítást igénylő feladat (különösen az olyan algoritmusok esetében, mint a DES, 3DES, GOST, PGP). És még nagy teljesítményű és optimalizált algoritmusok (RC5, RC6, AES) használata esetén sem kerülhet el a szükségtelen adatátvitel a memóriában és a számítási feldolgozásban. Ez pedig szinte semmivé teszi számos szerverkomponens (RAID tömbök, hálózati adapterek) képességeit. Hardveres titkosítás vagy a titkosítási kulcs hardveres származtatása esetén egy további lehetséges szűk keresztmetszet a teljesítményben: a kiegészítő eszköz és a memória közötti adatátvitel sebessége (ahol az ilyen eszköz teljesítménye nem feltétlenül kritikus). Kis mennyiségű adat (például e-mail üzenet) titkosítása esetén a rendszer számítási terhelésének növekedése nem annyira észrevehető, de minden teljes titkosítása esetén ez nagyban befolyásolhatja a rendszer teljesítményét. mint egész.

A jelszavak és kulcsok kiválasztásához szükséges modern képességek alábecsülése.

Jelenleg a technológia adottságai olyanok, hogy kis szervezetnél 40-48 bites kulcsot, nagy szervezetnél 56-64 bites kulcsot tud kiválasztani. Azok. legalább 96 vagy 128 bites kulcsot használó algoritmusokat kell használni. De a legtöbb kulcsot hash algoritmusokkal (SHA-1 stb.) állítják elő a felhasználó által beírt jelszavak alapján. Ebben az esetben egy 1024 bites kulcs nem biztos, hogy segít. Először is, gyakran használnak könnyen kitalálható jelszót. A kiválasztást elősegítő tényezők: csak egy betűbetű használata; szavak, nevek és kifejezések használata jelszavakban; ismert dátumok, születésnapok stb. használata; „minták” használata a jelszavak generálásakor (például 3 betű, majd 2 szám, majd 3 betű a szervezeten belül). A jó jelszónak meglehetősen véletlenszerű sorozatból kell állnia kis- és nagybetűkből, számokból és írásjelekből. A billentyűzetről beírt, legfeljebb 7-8 karakter hosszúságú jelszavak a szabályok betartása mellett is ésszerű időn belül kitalálhatók, így jobb, ha a jelszó legalább 11-13 karakterből áll. Az ideális megoldás az, hogy elkerüljük a kulcs generálását jelszó használatával, például különféle intelligens kártyák használatához stb., de ebben az esetben biztosítani kell a titkosítási kulcs adathordozójának elvesztése elleni védelem lehetőségét.

A kulcsok és jelszavak nem biztonságos tárolása.

Gyakori példák erre a hibára:

• hosszú és összetett jelszavak, amelyeket a felhasználó monitorára ragasztott cetlikre írtak.
• az összes jelszó tárolása olyan fájlban, amely nem védett (vagy sokkal gyengébb, mint maga a rendszer)
• elektronikus kulcsok nyilvános tárolása.
• az elektronikus kulcsok gyakori átadása a felhasználók között.

Miért csináljunk páncélajtót, ha a kulcs a lábtörlő alatt van?

Az eredetileg titkosított adatok átvitele nem biztonságos környezetbe.

A biztonsági rendszer felállításakor ügyeljen arra, hogy az elvégzi-e a feladatát. Találkoztam például olyan (nem 1C-vel kapcsolatos) helyzettel, amikor egy kezdetben titkosított fájl, amikor a program tiszta formában futott, egy ideiglenes mappába került, ahonnan biztonságosan ki lehetett olvasni. Gyakran előfordul, hogy a titkosított adatok tiszta formájú biztonsági másolatai valahol „nem messze” találhatók ezektől az adatoktól.

Titkosító eszközök használata egyéb célokra

Az átvitel közbeni adatok titkosításával nem számíthat arra, hogy az adatok elérhetetlenek lesznek ott, ahol használják. Például az IPSec-szolgáltatások semmilyen módon nem akadályozzák meg az alkalmazáskiszolgálót abban, hogy az alkalmazás szintjén "szippantsa" a hálózati forgalmat.

Ezért, hogy elkerülje a hibákat a kriptográfiai rendszerek megvalósítása során, (legalább) a következőket kell tennie a telepítés előtt.

• Kitalál:
  • Mit kell védeni?
  • Milyen védekezési módot érdemes alkalmazni?
  • A rendszer mely részeit kell biztosítani?
  • Ki fogja felügyelni a hozzáférést?
  • Működni fog a titkosítás minden megfelelő területen?
• Határozza meg, hol tárolják az információkat, hogyan küldjék el azokat a hálózaton keresztül, és melyik számítógépről érik el az információkat. Ez információkat nyújt a hálózat sebességéről, kapacitásáról és használatáról a rendszer bevezetése előtt, ami hasznos a teljesítmény optimalizálásához.
• Mérje fel a rendszer sebezhetőségét a különféle típusú támadásokkal szemben.
• Rendszerbiztonsági terv kidolgozása és dokumentálása.
• Értékelje a rendszer használatának gazdasági hatékonyságát (indokoltságát).

Következtetés

Természetesen egy gyors áttekintésben lehetetlen feltüntetni az 1C biztonságával kapcsolatos összes szempontot, de engedjük meg magunknak, hogy levonjunk néhány előzetes következtetést. Természetesen ez a platform nem nevezhető ideálisnak - sok máshoz hasonlóan ennek is megvannak a maga problémái a biztonságos rendszer megszervezésében. De ez semmiképpen sem jelenti azt, hogy ezeket a problémákat ne lehetne megkerülni, ellenkezőleg, a rendszer megfelelő fejlesztésével, bevezetésével és használatával szinte minden hiányosság kiküszöbölhető. A legtöbb probléma egy adott alkalmazásmegoldás és végrehajtási környezetének elégtelen fejlesztése miatt merül fel. Például a standard megoldások jelentős változtatások nélkül egyszerűen nem jelentik egy kellően biztonságos rendszer létrehozását.

Ez a cikk ismét bemutatja, hogy minden biztonsági intézkedésnek le kell fednie a megvalósítás minden szakaszát: a fejlesztést, a telepítést, a rendszeradminisztrációt és természetesen a szervezeti intézkedéseket. Az információs rendszerekben az „emberi tényező” (beleértve a felhasználókat is) jelenti a fő biztonsági fenyegetést. Ennek az intézkedéscsomagnak ésszerűnek és kiegyensúlyozottnak kell lennie: nincs értelme, és nem valószínű, hogy elegendő forrást különítenek el olyan védelem megszervezésére, amely meghaladja magának az adatnak a költségeit.

Vállalat egyedülálló szolgáltatás vásárlók, fejlesztők, kereskedők és kapcsolt partnerek számára. Ezen kívül ez az egyik legjobb online szoftverbolt Oroszországban, Ukrajnában és Kazahsztánban, amely széles termékválasztékot, számos fizetési módot, gyors (gyakran azonnali) rendelésfeldolgozást és a megrendelés folyamatának nyomon követését egy személyes részben kínálja. .

A „Felhasználók” könyvtár célja a felhasználók listájának tárolása. Ezek főként a konfigurációval dolgozó felhasználók (információs biztonsági felhasználók).

Az IS-felhasználó azonosítása egy címtárfelhasználóval az IS-felhasználónév és a címtár-felhasználó nevének egyeztetésével történik.

A további információk szerkesztése a "További információk" almenüben történik.

További információk csak a normál alkalmazásban érhetők el.

Felhasználói beállítások – lehetővé teszi a felhasználói beállítások módosítását

• Kapcsolattartási adatok - lehetővé teszi a kapcsolattartási adatok módosítását, amelyeket akkor használ, amikor a felhasználó az ügyfelekkel dolgozik, és amikor a beépített e-mailekkel dolgozik



Felhasználói csoportok - lehetővé teszi, hogy módosítsa a csoportokat, amelyekhez a felhasználó tartozik




További jogok – lehetővé teszi a további felhasználói jogok módosítását

Csak a felhasználói adminisztrátor hozhat létre, szerkeszthet és törölhet felhasználókat.

Információbiztonsági felhasználók létrehozása

Az információbiztonsági felhasználók konfigurátor módban vagy vállalati módban hozhatók létre.

Az információbiztonsági felhasználók tulajdonságainak vállalati módban történő kezelése előnyösebb, mint a felhasználók közvetlen kezelése a konfigurátoron keresztül.

A felhasználók jogosultságait szerepei és további jogai határozzák meg.

Az engedélyek profilok segítségével rendelhetők hozzá.

A rekordszintű hozzáférési jogokat azok a felhasználói csoportok határozzák meg, amelyekhez a felhasználó tartozik.

Vállalkozások, intézmények és szervezetek – tulajdonformájuktól függetlenül – számára kulcskérdés az információforrások védelmének biztosítása, beleértve a számviteli információkat és a beszámolókészítést is. Az „1C: Public Institution Accounting 8” 2. kiadású program megfelel a modern információbiztonsági követelményeknek. Az 1C szakértői a cikkben beszélnek az információvédelmi program képességeiről.

Az információs források védelmének biztosításának jelentősége

Egy szervezet, intézmény, vállalkozás információbiztonságának biztosítása érdekében olyan feltételeket kell teremteni, amelyek mellett a szervezet állapotára vonatkozó információk – beleértve a számviteli és pénzügyi információkat is – a szervezet alkalmazottai vagy külső személyek általi felhasználása, elvesztése vagy eltorzulása felhasználók) nagy valószínűséggel nem vezetnek belátható időn belül a szervezet tevékenységét megszakító veszélyek megjelenéséhez.

Az információbiztonsági problémák állami szintű relevanciáját megerősíti az Orosz Föderáció információbiztonsági doktrínájának elfogadása (az Orosz Föderáció elnöke által 2000. szeptember 9-én, Pr-1895 sz. jóváhagyva). Az Orosz Föderáció nemzeti érdekeinek egyik összetevője az információs szférában az információs erőforrások védelme a jogosulatlan hozzáféréstől, biztosítva a már telepített és az Oroszországban létrehozandó információs és távközlési rendszerek biztonságát.

Az Orosz Föderáció nemzetbiztonságának biztosításában kulcsszerepet játszik az Orosz Föderáció információbiztonságának biztosítása a gazdasági szférában. A következők a leginkább érzékenyek az Orosz Föderáció információbiztonságát fenyegető veszélyekre a gazdasági szférában:

• állami statisztikai rendszer;
• hitel- és pénzügyi rendszer;
• a szövetségi végrehajtó hatóságok részlegeinek automatizált információs és számviteli rendszerei, amelyek biztosítják a társadalom és az állam tevékenységét a gazdasági szférában;
• számviteli rendszerek vállalkozások, intézmények és szervezetek számára, függetlenül azok tulajdonformájától;
• pénzügyi, tőzsdei, adózási, váminformációk, valamint az állam, valamint a vállalkozások, intézmények és szervezetek – tulajdonosi formától függetlenül – külgazdasági tevékenységére vonatkozó információk gyűjtésére, feldolgozására, tárolására és továbbítására szolgáló rendszerek.

Egy vállalkozás, intézmény, szervezet számvitelhez és jelentéskészítéshez kapcsolódó információbiztonságát fenyegető veszélyek a következők:

• a számviteli információk és a jelentéstétel integritása;
• a számviteli információk és a jelentéstétel titkosságának megsértése;
• a számviteli információk és jelentéstétel hozzáférhetőségének (blokkolásának) megsértése;
• a számviteli információk és jelentéstétel megbízhatósága;
• a számviteli információk és jelentéstétel tartalma a személyzet és más személyek cselekedetei miatt;
• a rossz minőségű számviteli információk és beszámolók használata okozta.

Információbiztonság az "1C: Közintézményi számvitel 8"-ban

Az „1C: Közintézményi számvitel 8” 2. kiadású program (a továbbiakban: Program) megfelel a modern információbiztonsági követelményeknek. A Programban tárolt információkhoz való jogosulatlan hozzáférés elleni védelem szintjének növelése érdekében a következő szolgáltatások állnak rendelkezésre:

• hitelesítés;

Nézzük meg közelebbről a Program ezen funkcióit.

Hitelesítés

A hitelesítési mechanizmus az egyik adminisztrációs eszköz. Lehetővé teszi annak meghatározását, hogy a rendszerfelhasználók listájában felsorolt ​​felhasználók közül melyik csatlakozik jelenleg a Programhoz, és megakadályozza a Programhoz való jogosulatlan hozzáférést.

Az "1C: Közintézményi számvitel 8" 2. kiadásában háromféle hitelesítés támogatott, amelyek az információsbázis-adminisztrátor konkrét feladataitól függően használhatók:

• hitelesítés 1C:Enterprise- hitelesítés a Programban létrehozott felhasználó és jelszó használatával;
• operációs rendszer hitelesítés- a Programban az operációs rendszer egyik felhasználója van kiválasztva a felhasználónak. A Program elemzi, hogy melyik operációs rendszer felhasználó nevében történik a csatlakozás a Programhoz, és ez alapján meghatározza a Program megfelelő felhasználóját;
• OpenID hitelesítés- a felhasználói hitelesítést egy külső OpenID szolgáltató végzi, amely a felhasználók listáját tárolja.

Ha egy felhasználóhoz nincs megadva hitelesítés típusa, a program megtagadja az ilyen felhasználó hozzáférését a Programhoz.

Ha a felhasználónak be kell lépnie a Programba egy jelszóval, amelyet ellenőrizni fog, akkor a jelzőt engedélyezni kell Hitelesítés 1C:Enterprise(lásd 1. ábra). Alapértelmezés szerint a zászlóval együtt engedélyezve van A programba való bejelentkezés engedélyezett.

Az 1C:Enterprise hitelesítési állapot a zászló alatt jelenik meg.

Rizs. 1

Amikor új felhasználó jön létre, a Program automatikusan hozzárendel egy üres jelszót. A módosításhoz használja a parancsot Állítsd be a jelszót a felhasználói kártyán (lásd 1. ábra).

Az alakban Jelszó beállítása be kell írni új jelszó a Programba való belépéshez írja be újra a mezőbe Megerősítés.

A jó jelszónak legalább nyolc karakter hosszúságúnak kell lennie, tartalmaznia kell nagy- és kisbetűket, latin betűket, számokat, szimbólumokat (aláhúzás, zárójel stb.), és homályosnak kell lennie. Nem kívánatos, hogy a jelszó egybeessen a felhasználónévvel, teljes egészében számokból álljon, érthető szavakat vagy váltakozó karaktercsoportokat tartalmazzon. Példák jó jelszavakra: "nj7(jhjibq*Gfhjkm, F5"njnGhkmNj;t(HI. Példák rossz jelszavakra: Ivanov, qwerty, 12345678, 123123123. További részletekért tekintse meg az "1C:Enterprise's 8.3. útmutató") dokumentációt.

A program lehetőséget ad automatikus jelszó-bonyolultság-ellenőrzés.

Alapértelmezés szerint biztonsági okokból a jelszó nem jelenik meg beíráskor. A beírt karakterek megtekintéséhez engedélyeznie kell a zászlót Új jelszó megjelenítése.

A jelszó automatikus generálásához használja a gombot Hozzon létre egy jelszót. A jelszót a Program generálja.

Jelszava elmentéséhez kattintson a gombra Állítsd be a jelszót.

Ezt követően az 1C:Enterprise hitelesítési állapot a következőre változik Jelszó beállítva. A felhasználói kártyán a gomb értékét erre módosítja Jelszó módosítása.

Az adminisztráció és a biztonság megkönnyítése érdekében minden felhasználó rendelkezik zászlóval , amelyre azért van szükség, hogy a felhasználó az adminisztrátor által beállított jelszót a sajátjára módosítsa. Ha ez a jelző engedélyezve van, a felhasználónak meg kell adnia a saját jelszavát, amelyet senki más nem fog tudni.

Ha a zászló Bejelentkezéskor jelszómódosítás szükséges nincs engedélyezve, és a korábban beállított jelszó valamiért nem felel meg Önnek, azt a felhasználói kártyán bármikor megváltoztathatja.

Engedélyezett jelző A felhasználónak tilos a jelszó megváltoztatása megtiltja, hogy a teljes jogokkal nem rendelkező felhasználó önállóan állítson be és módosítson jelszót.

Kellékek Bejelentkezéskor jelszómódosítás szükségesÉs Érvényesség a felhasználói kártyán és a jelentésben látható Felhasználói információ (Információk a külső felhasználókról).

Program bejelentkezési beállítások

Az alakban Bejelentkezési beállítások(fejezet Adminisztráció, navigációs sáv parancsát Felhasználói és jogosultsági beállítások) külön a Program belső és külső felhasználói számára a következő paramétereket konfigurálhatja:

• a jelszó összetettségének beállítása és vezérlése;
• a jelszó ütemezett vagy manuális megváltoztatásának követelménye. Jelszó módosítása - időszakonként vagy kérésre;
• jelszóismétlés beállítása és vezérlése;
• korlátozza a számlák érvényességi idejét.

A 2. ábra a belső felhasználók beállítását mutatja.

Rizs. 2

Hasonló beállítás érhető el a külső felhasználók számára.

Jelszó bonyolultságának ellenőrzése

Amikor a zászlót felállítják A jelszónak meg kell felelnie a bonyolultsági követelményeknek a program ellenőrzi, hogy az új jelszó:

• legalább 7 karakterből állt,
• 4 karaktertípus közül 3-at tartalmazott: nagybetűk, kisbetűk, számok, speciális karakterek,
• nem egyezik a névvel (a bejelentkezéshez).

A minimális jelszóhossz módosítható az azonos nevű mező melletti négyzet bejelölésével és a szükséges jelszóhossz megadásával (3. ábra).

Rizs. 3

Jelszó módosítása

A jelszó megváltoztatásának két beállítása van: időszakos vagy a rendszergazda kérésére.

A jelszó rendszeres megváltoztatásához korlátoznia kell a jelszó lejárati dátumát a beállítások segítségével A jelszó minimális érvényességi idejeÉs A jelszó maximális érvényessége. A megadott időszak lejárta után a Program felszólítja a felhasználót a jelszó megváltoztatására.

A jelszó maximális érvényességi ideje az első új jelszóval történő bejelentkezést követő időszak, amely után a felhasználónak meg kell változtatnia a jelszót, alapértelmezés szerint 30 nap.

A jelszó minimális érvényességi ideje az első új jelszóval történő bejelentkezést követő időszak, amely alatt a felhasználó nem tudja megváltoztatni a jelszót, alapértelmezés szerint 1 nap.

A jelszó kérésre történő megváltoztatásához a rendszergazdának be kell állítania a jelzőt Bejelentkezéskor jelszó kérése a felhasználói kártyában. Amikor először lép be a Programba, meg kell változtatnia a rendszergazda által beállított jelszót a sajátjára.

Ismételhetőség ellenőrzése

Ha meg szeretné akadályozni, hogy a felhasználók ismétlődő jelszavakat hozzanak létre, engedélyeznie kell a beállítást Akadályozza meg a legutóbbi jelszavak ismétlődésétés állítsa be a legutóbbi jelszavak számát, amellyel az új jelszót össze kell hasonlítani.

Felhasználói bejelentkezési korlátozások

A Programhoz való jogosulatlan hozzáférés elleni védelem érdekében korlátozást állíthat be azon felhasználók számára, akik bizonyos ideig nem dolgoznak a Programban, például 45 napig.

A megadott időszak lejárta után a program nem engedi be a felhasználót a Programba. A nyitott felhasználói munkamenetek automatikusan leállnak legfeljebb 25 perccel a Programba való bejelentkezés megtagadása után.

A Felhasználói kártyán, amely a Program személyes beállításaiban, a hiperhivatkozáson keresztül érhető el Állítson be korlátozásokat A Programba való belépéshez további korlátozásokat is megadhat (4. ábra).

Rizs. 4

A kapcsoló segítségével korlátozást állíthat be a Programba való belépéshez:

• Az általános bejelentkezési beállítások szerint- alapértelmezés szerint telepítve;
• Nincs időkorlát;
• ig engedélyezett a belépés(határidőt kell beállítani - kézzel írja be a dátumot, vagy válasszon a naptárból a gombbal). A Programhoz való jogosulatlan hozzáférés elleni védelem érdekében minden felhasználó rendelkezik egy érvényességi idővel, amely lehetővé teszi a felhasználó automatikus megszakítását egy meghatározott dátum elérésekor;
• Tiltsa meg a belépést, ha már nem működik(a napok számát meg kell adni) - ha a felhasználó a megadott számú napon túl nem lép be a Programba, akkor a Programba való belépés lehetetlenné válik. Ebben az esetben a felhasználónak kapcsolatba kell lépnie az adminisztrátorral, hogy folytathassa a munkát a Programban.

Felhasználói adatok jelentés

Jelentés Felhasználói információ(5. ábra) a Program felhasználóira vonatkozó információk megtekintésére szolgál, beleértve a bejelentkezési beállításokat (infobase felhasználói tulajdonságok). Jelentés szükségessége akkor merül fel, ha csoportos elemzést kell végezni a bejelentkezési beállításokról (bejelentkezési név, hitelesítési típusok stb.).

A jelentés megnyílik a listából Felhasználók (Külső felhasználók) parancsra Minden művelet – Felhasználói információk (Minden művelet-A külső felhasználókról). A lista típusától függően a Program automatikusan kiválasztja a kívánt jelentés opciót.

A belső és külső felhasználókkal kapcsolatos információk egy jelentésben a szakasz műveleti paneljén keresztül nyithatók meg Adminisztráció parancsra Felhasználói információ.

Jelentés szükségessége akkor merül fel, ha csoportos elemzést kell végezni a bejelentkezési beállításokról (bejelentkezési név, hitelesítési típusok stb.).

Rizs. 5

A gomb segítségével Beállítások... Megnyithatja a mezők listáját, és szükség esetén hozzáadhatja a kötelező mezőket a jelentéshez. Például hozzáadhat mezőket a jelentéshez Bejelentkezéskor jelszómódosítás szükségesÉs Érvényesség.

A személyes adatok védelmének biztosítása

Összefoglalva, meg kell jegyezni, hogy a Programhoz való hozzáférés szabályozása csak egy a Program által biztosított adatvédelmi elemek közül.

Az Orosz Föderáció kormányának 2012. november 1-i 1119. számú rendelete jóváhagyta a személyes adatok védelmére vonatkozó követelményeket a személyes adatok információs rendszerekben történő feldolgozása során, amelyek meghatározzák a személyes adatok biztonsági szintjeit a személyes adatokban történő feldolgozásuk során az adatok biztonságát fenyegető veszélyektől függően. E követelményeknek megfelelően az orosz FSTEC 2013. február 18-i rendelete alapján. A 21. szám részletezi a személyes adatok biztonságát biztosító szervezési és technikai intézkedések összetételét és tartalmát azok személyesadat-információs rendszerekben történő kezelése során.

A személyes adatokra vonatkozó hatályos jogszabályok előírásai további követelményeket támasztanak a szoftvertermékekkel, különösen az információvédelmet szolgáló szoftverekkel szemben.

A személyes adatok védelmének biztosítása érdekében az „1C:Enterprise, 8.3z verzió” védett szoftvercsomagot (ZPK) tervezték, amely az orosz FSTEC által tanúsított általános célú szoftver, amely beépített eszközökkel védi az információkat az illetéktelenektől. hozzáférés (NSD) olyan információkhoz, amelyek nem tartalmaznak államtitkot.

A ZPK "1C:Enterprise 8.3z" lehetővé teszi a következők blokkolását:

• COM objektumok elindítása, külső feldolgozás és jelentések, az 1C:Enterprise szerverre telepített alkalmazások;
• külső 1C:Vállalati összetevők használata;
• hozzáférés az internetes forrásokhoz.

A szabványos „1C: Közintézményi számvitel” 2. kiadás és a ZPK „1C: Enterprise 8.3z” együttes használata lehetővé teszi, hogy minden biztonsági szintű személyes adatokat tartalmazó információs rendszert hozzon létre, és ennek az alkalmazási megoldásnak nincs szükség további tanúsítására.

A ZPK "1C:Enterprise 8.3z" használata FSTEC-tanúsítvánnyal rendelkező operációs rendszerekkel, DBMS-sel és más tanúsított eszközökkel együtt lehetővé teszi, hogy teljes mértékben megfeleljen a fenti szabályozási dokumentumok követelményeinek.

Mivel az „1C: Public Institution Accounting” biztosítja az adatcserét a szövetségi kincstári hatóságokkal, az adóhatóságokkal, az állami és önkormányzati fizetési információs rendszerekkel (GIS GMP), a szövetségi ingatlanok elszámolásával (ASUFI), a kifizetések nyilvántartásával és elhatárolásával (IS RNIP), stb. az interneten keresztül, a biztonsági követelmények teljesítése érdekében a létesítményt tanúsított tűzfaleszközökkel kell ellátni.

Természetesen naponta ellenőrizni kell azokat a számítógépeket, amelyekre a Program telepítve van, rosszindulatú számítógépes programok jelenlétére az oroszországi FSTEC tanúsítási rendszerben tanúsított vírusvédelmi eszközök segítségével.

INFORMÁCIÓS BÁZIS KEZELÉS (IS)

Ezt a cikket három körülmény kényszerített megírni: kommunikáció ismerős könyvelőkkel, a főkönyvelő cikke, anekdotagyűjtemény.

Egy barátom főkönyvelőként dolgozik, és folyékonyan beszéli az 1C-t. Nemrég azonban egy új szervezethez költözött, ahol nincs információtechnológiai (IT) szakember, és olyan kérdéseket kezdett feltenni nekem, mint „Szeretnék otthon dolgozni egy programban, hogyan tudom átvinni az otthoni számítógépemre?”

Hivatásos könyvelőkkel kommunikálva rájöttem, hogy szakmailag nincs kérdésük. Kérdések merülnek fel az információs báziskezelés területén.

Másodszor, emlékszem a nemrég megjelent cikkre: „Miért van szüksége egy könyvelőnek az Infostartra?” . Szerző: Alla (bux 2).

A harmadik körülmény a korántsem új viccek gyűjteménye „Utasítások könyvelőknek az 1C programozóval való kommunikációhoz”. Valójában ezek a történetek anekdotáknak nevezhetők, minden számvitelhez kötődő informatikus valós történetei.

Ha alaposan elemzi ezeket az anekdotákat, önkéntelenül arra a következtetésre jut, hogy a konfliktus a felelősség határterületén történik, amely nem tartozik sem az alkalmazás felhasználójához, sem az informatikushoz.

Jelenleg több mint 80 000 felhasználó van regisztrálva az Infostart honlapján. Nem valószínű, hogy ezek mind 1C programozók, valószínűleg „haladó” felhasználók, akiknek problémái voltak az 1C rendszerekkel.

Számomra úgy tűnik, hogy a webhely összes felhasználója három fő kategóriába sorolható:

• 1C programozók, akik nárcisztikusan részt vesznek a rangsoroló versenyeken
• „Haladó” felhasználók, akik fejlettebb eszközöket keresnek az 1C-vel való munkához
• Kezdőknek, akiknek problémái vannak az 1C működtetésével, és választ keresnek a „Mit tegyenek?” kérdésre.

Ez a cikk az utolsó két felhasználói kategória számára készült. Itt az 1C információs bázisok kezeléséről szeretnék beszélni. A vita ellentmondásos, és kizárólag személyes tapasztalatokon alapul.

Ha elemezzük a legtöbbet „értékelt” cikkeket, akkor láthatjuk, hogy az információbiztonság-menedzsment általános kérdéseiről szóló, meglehetősen egyszerű cikkek sikeresek. Ezek a kérdések érthetőek az informatikusok számára, de az 1C alkalmazások felhasználói számára szinte kinyilatkoztatás.

Ez különösen igaz azokra a kis cégekre, amelyek nem engedhetik meg maguknak, hogy 1C programozót vagy akár csak informatikust alkalmazzanak. Ebben az esetben minden probléma a felhasználókra hárul.

Leggyakrabban egy ilyen vállalkozás a „könyvelés” és a „fizetés” konfigurációkat használja. Ez annak köszönhető, hogy az 1C gyorsan tükrözi konfigurációiban a jogszabályok változásait. A vállalkozások számára ez fiskális jelentési szempontból fontos.

Tipikus kisvállalkozás. 1C felhasználók: rendező; könyvelő, egyben fő; titkár, aki egyben az OK vezetője is; több menedzser (valamiért így hívják az értékesítési specialistákat).

Minden felhasználó „kezeli” az információbiztonság saját részét, de senki sem felelős a teljes adatbázis egészéért. És ha problémák merülnek fel, nincs kitől megkérdezni. Raikinhez hasonlóan: „Személyesen varrtam a gombokat. Kérdése van a gombokkal kapcsolatban? Nem, halálra vannak varrva, nem tudod letépni őket!" De általában senki sem felelős az öltönyért.

A rendszer normál működéséhez valakinek át kell vennie az általános információbiztonsági ellenőrzés funkcióit. Ilyen funkciók például a másolatok eltávolítása a könyvtárakból. Ez egyrészt alkalmazási terület, másrészt ezt informatikusnak kell elvégeznie. Ezek a funkciók a „határterületen” vannak, mind az informatikusok (ha vannak), mind az 1C-felhasználók megtagadják a végrehajtásukat.

Ez a kérdés nem csak a kisvállalkozásokat érinti. Nemrég frissítettem a munkaköri leírásokat, és nagy nehézségek árán tudtam hasonló feladatokat elosztani az alkalmazottak között. És most nagyon komoly a munkaköri leírások megközelítése, mert... ezek képezik a különféle közigazgatási szankciók alapját, beleértve az elbocsátást is.

A rendszergazda dühösen visszautasította az ajánlatot, az 1C programozó büszkén jelentette ki, hogy „kódol” és nem takarítja el a felhasználók szemetét. Röviden: egy rendes vállalkozásban nincs olyan szakember, aki az információbiztonságban az információk integritásáért felelne. Ezt a pozíciót nehéz feltételesen meghatározni, így nevezhetjük „Information Security Manager”-nek.

Ezek a funkciók eltérnek az adminisztrátor funkcióitól. Az 1C Company az adminisztrációs feladatokat a következőképpen határozza meg:

• Rendszer telepítés és frissítés
• Felhasználói lista vezetése
• Hozzáférési jogok konfigurálása a szerepmechanizmus alapján
• Felhasználói műveletek és rendszeresemények figyelése
• biztonsági mentés
• Az információs bázis tesztelése, javítása
• Területi beállítások megadása
• Konfigurációk frissítése
• Információs adatbázis betöltése és eltávolítása fájlba
• Napló vezetése, felállítása

Valójában az 1C „Konfiguráció és adminisztráció” dokumentáció „Adminisztráció” fejezete ennek szentelt.

A valóságban ezek az adminisztrációs feladatok nem elegendőek az adatbázis zökkenőmentes működéséhez. Az adatbázis „helyes” működéséhez szélesebb és változatosabb intézkedésekre van szükség. Az „adatbázis-kezelés” sokkal tágabb, mint az „adminisztráció” fogalma.

A nagyvállalatoknál ezeket az információbiztonság-kezelési funkciókat főállású szakemberre kell bízni. Kisvállalkozásoknál ezek a funkciók nagy valószínűséggel a főkönyvelőre hárulnak, mert teljesebb ellenőrzése van az információk felett, ellenőriznie kell a dokumentumok bevitelét, sorrendjét, adatok feltöltését és letöltését stb.

Az információbiztonság menedzsment funkciói általában az információbiztonság „helyességének” biztosítására vonatkoznak.

Értelmezésem szerint a „helyes” 1C információs adatbázisnak bármilyen konfigurációban meg kell felelnie legalább a következő elveknek:

• Nem tartalmazhat törlésre megjelölt objektumokat. Minden megjelölt objektumot törölni kell
• Az adatbázisban nem lehetnek fel nem könyvelt dokumentumok
• Bármely időszakra vonatkozó dokumentumok újbóli feladásakor az eredmények nem változhatnak

Az adatbázis-kezelésnek ezekhez az eredményekhez kell vezetnie. Az adatbázissal való megszakítás nélküli munkához a következő műveleteket kell végrehajtani szabványos 1C konfigurációkban (a ZUP példájával):

• 1. biztonsági mentés
     • Minden adatbázisról naponta, minden nap végén másolatot kell készíteni. Ebben az esetben „felülírhatja” az előző napi másolatokat;
     • Frissítés előtt másolatot kell készíteni az adatbázisról. Ezeket a másolatokat célszerű egyedi néven menteni.
     • Az adatbázis másolatait a hónap vége után kötelező elmenteni, egyedi néven is.

A webhelyen számos cikk és kezelés található a biztonsági mentéssel kapcsolatban.

• 1. Hetente ellenőrizze a segédkönyveket, hogy vannak-e másolatok. Ha ismétlődések fordulnak elő, törölje azokat. Az ismétlődések eltávolítása
  2. Hetente törölje a törlésre megjelölt elemeket. Ha az objektumok nem törlődnek, az azt jelenti, hogy vannak hivatkozások ezekre az objektumokra. Ki kell deríteni, hogy ki és miért jelölte meg őket törlésre. Ha szükséges, ezeket az objektumokat vissza kell állítani. Az eltávolítás univerzális kezelésekkel történhet//site/blogs/1313/ A hatósági jelentéstétel előtt - Technológiai ellenőrzés
  3. Express adatbázis elemzés//site/public/21332/
  4. A hónap lezárását követő hónap végén tagadja meg az adatokhoz való hozzáférést

Esetleg tudtok ajánlani valamit a tapasztalatokból?

Információ biztonság Az információvédelemhez hasonlóan egy komplex, a biztonság biztosítását célzó feladat, amelyet egy biztonsági rendszer megvalósításával valósítanak meg. Az információbiztonság problémája sokrétű és összetett, és számos fontos feladatot takar.

Az információbiztonsági problémákat folyamatosan súlyosbítja az adatfeldolgozás és -továbbítás technikai eszközeinek a társadalom minden szférájába való behatolása, ez a probléma különösen a pénzügyi számviteli rendszerek területén éles. A legnépszerűbb könyvelési, értékesítési és CRM-folyamatrendszer Oroszországban az 1C Enterprise rendszer.

Tekintsük a lehetséges biztonsági fenyegetéseket az 1C program használatakor.

	1C használata fájlformátumú adatbázisokkal. Az 1C fájladatbázisok a legsebezhetőbbek a fizikai hatásokkal szemben. Ez az ilyen típusú adatbázisok architekturális jellemzőinek köszönhető – annak szükségessége, hogy az összes konfigurációs fájlt és magukat a fájladatbázisokat nyitva kell tartani (teljes hozzáféréssel) az operációs rendszer összes felhasználója számára. Ennek eredményeként bármely felhasználó, akinek joga van egy 1C fájladatbázisban dolgozni, elméletileg két egérkattintással másolhat vagy akár törölhet egy 1C információs adatbázist.
	1C használata DBMS formátumú adatbázisokkal. Ez a fajta probléma akkor merül fel, ha egy DBMS-t (PosgreSQL, MS SQL) használnak az 1C adatbázisok tárolójaként, és egy vállalati 1C szervert használnak közbenső kommunikációs szolgáltatásként az 1C és a DBMS között. Ez egy példa – sok cég gyakorolja az 1C konfigurációk igényeinek megfelelő módosítását. A finomítás során, a projekt „felhajtás”, az új, továbbfejlesztett funkcionalitás folyamatos tesztelése mellett a felelős szakemberek gyakran figyelmen kívül hagyják a hálózatbiztonsági szabályokat. Ennek eredményeként néhány személy, aki közvetlen hozzáféréssel rendelkezik a DBMS-adatbázishoz, vagy rendszergazdai jogokkal rendelkezik az 1C Enterprise szerveren, akár ideiglenes tesztidőre is, biztonsági másolatot készíthet külső erőforrásokra, vagy teljesen törölheti az adatbázist a DBMS-ben.
	A szerverberendezések nyitottsága és hozzáférhetősége. Ha jogosulatlanul hozzáférnek a szerverberendezéshez, a vállalat alkalmazottai vagy harmadik felek felhasználhatják ezt a hozzáférést információk ellopására vagy megrongálására. Egyszerűen fogalmazva, ha egy támadó közvetlen hozzáférést kap egy 1c szerver törzséhez és konzoljához, képességei tízszeresére bővülnek.
	A személyes adatok lopásának és kiszivárgásának kockázata. Itt a személyes adatok biztonságát fenyegető aktuális fenyegetések alatt olyan feltételek és tényezők összességét értjük, amelyek a személyes adatokhoz való jogosulatlan, ideértve a véletlenszerű hozzáférés veszélyét is megteremtik az információs rendszerben történő feldolgozás során, például felelős alkalmazottak, PC által. operátorok, számviteli osztályok stb. Ez a személyes adatok megsemmisítését, módosítását, zárolását, másolását, szolgáltatását, terjesztését, valamint a felelős személyek egyéb jogellenes cselekményét eredményezheti.
	Hálózati biztonság. A GOST, a biztonsági követelmények, ajánlások megsértésével vagy a megfelelő informatikai támogatás hiányával épített vállalati információs rendszer tele van lyukakkal, vírusokkal és kémprogramokkal, valamint számos hátsó ajtóval (jogosulatlan hozzáférés a belső hálózathoz), ami közvetlenül befolyásolja a vállalati adatok biztonságát 1C. Ezáltal a támadó könnyen hozzáférhet a kereskedelmi szempontból érzékeny információkhoz. A támadó például használhatja a biztonsági másolatokhoz való ingyenes hozzáférést, illetve a biztonsági másolatok archívumainak jelszó hiányát személyes haszonszerzés céljából. Nem beszélve arról, hogy a vírusaktivitás alapvetően károsítja az 1C adatbázist.
	Az 1C és a külső objektumok közötti kapcsolat. Egy másik lehetséges veszély az 1C számviteli adatbázis szükségessége (és néha egy speciális marketingfunkció is), hogy kommunikáljon a „külvilággal”. Ügyfélbankok fel-/letöltése, információcsere fiókokkal, rendszeres szinkronizálás vállalati weboldalakkal, portálokkal, egyéb jelentéskészítő programokkal, ügyfél- és értékesítéskezelés és még sok más. Mivel az 1C ezen a területén nem ösztönzik a biztonsági szabványok betartását és a hálózati információcsere egységességét, a szivárgás az útvonal bármely pontján valós. A folyamatautomatizálás nem szabványos fejlesztéseinek szükségessége vagy a forgalom védelmét szolgáló intézkedések költségvetésének csökkentése következtében azonnal megnő a sebezhetőségek, lyukak, nem biztonságos kapcsolatok, nyitott portok, könnyen elérhető, titkosítatlan cserefájlok stb. száma. a számviteli rendszerben. Nyugodtan elképzelheti, hogy ez mihez vezethet - az 1C adatbázis bizonyos időre történő elemi letiltásától a több milliós fizetési megbízás hamisításáig.

Mit lehet javasolni az ilyen problémák megoldására?

1. Amikor 1C fájladatbázisokkal dolgozik A bázisok biztonságának biztosítása érdekében számos intézkedést kell végrehajtani:

• Az NTFS hozzáférési korlátozások használatával csak azoknak a felhasználóknak adja meg a szükséges jogokat, akik ezzel az adatbázissal dolgoznak, ezzel megvédve az adatbázist a gátlástalan alkalmazottak vagy támadók általi ellopástól vagy sérüléstől;
• Mindig használjon Windows jogosultságot a felhasználói munkaállomásokba való bejelentkezéshez és a hálózati erőforrásokhoz való hozzáféréshez;
• Használjon titkosított lemezeket vagy titkosított mappákat, amelyek lehetővé teszik a bizalmas információk mentését még akkor is, ha eltávolítja az 1C adatbázist;
• Automatikus képernyőzárolási szabályzat létrehozása, valamint felhasználói képzés biztosítása a profilzárolás szükségességének ismertetésére;
• A hozzáférési jogok 1C szintű differenciálása lehetővé teszi a felhasználók számára, hogy csak azokhoz az információkhoz férhessenek hozzá, amelyekhez megfelelő jogokkal rendelkeznek;
• Az 1C konfigurátor elindítását csak azoknak az alkalmazottaknak kell engedélyezni, akiknek szükségük van rá.

2. Amikor DBMS 1C adatbázisokkal dolgozik Kérjük, vegye figyelembe a következő ajánlásokat:

• A DBMS-hez való csatlakozáshoz szükséges hitelesítő adatok nem rendelkezhetnek rendszergazdai jogokkal;
• Meg kell különböztetni a hozzáférési jogokat a DBMS-adatbázisokhoz, például minden információs bázishoz hozzon létre saját fiókot, amely minimalizálja az adatvesztést, ha valamelyik fiókot feltörik;
• Javasoljuk, hogy korlátozza a fizikai és távoli hozzáférést a vállalati adatbázisokhoz és az 1C szerverekhez;
• Javasoljuk, hogy az adatbázisokhoz titkosítást használjon, ez akkor is megmenti a bizalmas adatokat, ha a támadó fizikailag hozzáfér a DBMS-fájlokhoz;
• Ezenkívül az egyik fontos döntés az adatmentések titkosítása vagy jelszó beállítása;
• Kötelező adminisztrátorokat létrehozni az 1C fürthöz, valamint az 1C szerverhez, mivel alapértelmezés szerint, ha nem jön létre felhasználó, akkor a rendszer minden felhasználója teljes hozzáféréssel rendelkezik az információs bázisokhoz.

3. A szerverberendezések fizikai biztonságának biztosítására vonatkozó követelmények:
(a GOST R ISO/IEC TO – 13335 szerint)

• Az olyan területekhez való hozzáférést, ahol érzékeny információkat dolgoznak fel vagy tárolnak, ellenőrizni kell, és csak arra jogosult személyekre kell korlátozni;
• Hitelesítési vezérlők, például beléptetőkártya és személyi azonosító szám , a hozzáférés engedélyezésére és megerősítésére kell használni;
• Az összes hozzáférés ellenőrzési nyomvonalát biztonságos helyen kell tartani;
• A harmadik felek támogató személyzetének csak szükség esetén szabad korlátozott hozzáférést biztosítani a biztonsági területekhez vagy az érzékeny információfeldolgozó létesítményekhez;
• ezt a hozzáférést mindenkor engedélyezni kell és ellenőrizni kell;
• A biztonsági területekhez való hozzáférési jogokat rendszeresen felül kell vizsgálni és frissíteni kell, és szükség esetén vissza kell vonni;
• Figyelembe kell venni a vonatkozó biztonsági és egészségügyi előírásokat és szabványokat;
• A kulcsfontosságú létesítményeket úgy kell elhelyezni, hogy a nagyközönség ne férhessen hozzájuk;
• Adott esetben az épületeknek és helyiségeknek szerénynek kell lenniük, és minimális jelzést kell adniuk rendeltetésükről, anélkül, hogy az épületen kívül vagy belül feltűnő jelzések szerepeljenek, jelezve az információfeldolgozási tevékenységek jelenlétét;
• Az érzékeny információfeldolgozó létesítmények helyét jelző táblákat és belső telefonkönyveket nem szabad könnyen hozzáférhetővé tenni a nagyközönség számára.

4. A személyes adatok bizalmas kezelése. A személyes adatok védelmének megszervezésében a fő cél az információs rendszerben aktuális fenyegetések semlegesítése, meghatározott A személyes adatokról szóló, 2006. július 27-i 152-FZ szövetségi törvény , a nemzetközi IT biztonsági tanúsítványok állami szabványainak és követelményeinek listája (GOST R ISO/IEC 13335 2-5, ISO 27001) . Ezt úgy érik el, hogy az információhoz való hozzáférést típusok szerint korlátozzák, az információhoz való hozzáférést felhasználói szerepkörök szerint korlátozzák, az információfeldolgozás és -tárolás folyamatát strukturálják.
Íme néhány kulcsfontosságú pont:

• A személyes adatok feldolgozását meghatározott, előre meghatározott és jogszerű célok elérésére kell korlátozni;
• A személyes adatok kezeléséhez való hozzájárulásnak konkrétnak, tájékozottnak és tudatosnak kell lennie;
• A személyes adatok gyűjtésének céljaival összeegyeztethetetlen személyes adatok kezelése nem megengedett;
• Csak olyan személyes adatok kezelhetők, amelyek megfelelnek az adatkezelés céljainak;
• Az üzemeltetők és a személyes adatokhoz hozzáféréssel rendelkező egyéb személyek kötelesek a személyes adatokat harmadik félnek kiadni vagy terjeszteni a személyes adatok alanyának hozzájárulása nélkül, hacsak a szövetségi törvény másként nem rendelkezik;
• Fénykép-, videó-, audio- vagy egyéb rögzítőberendezések, például kamerák a mobileszközökön engedély nélkül nem engedélyezhetők;
• A cserélhető adathordozóval rendelkező meghajtók csak akkor engedélyezhetők, ha üzleti igény van rá;
• Annak biztosítása érdekében, hogy a bizalmas információkat ne hamisítsák meg, a papírt és az elektronikus adathordozókat megfelelően zárt szekrényekben és/vagy más biztonságos bútorokban kell tárolni, amikor nem használják őket, különösen a munkaidőn kívül;
• A fontos vagy érzékeny, védett információkat tartalmazó adathordozókat el kell helyezni, és ha nem szükséges, be kell zárni (például tűzálló széfbe vagy szekrénybe), különösen akkor, ha a terület üres.

5. Hálózati biztonság- ez a vállalat számítógépes hálózatának infrastruktúrájára és az abban történő munkavégzésre vonatkozó követelmények összessége, amelyek végrehajtása biztosítja a hálózati erőforrások védelmét a jogosulatlan hozzáféréstől. A hálózat biztonságának megszervezéséhez és biztosításához javasolt műveletek részeként az alapvető műveletek mellett a következő funkciókat is figyelembe veheti:

• A vállalatnak mindenekelőtt egységes információbiztonsági szabályozást kell végrehajtania megfelelő utasításokkal;
• A felhasználóktól a lehető legnagyobb mértékben meg kell tagadni a nemkívánatos webhelyekhez való hozzáférést, beleértve a fájltárolási szolgáltatásokat is;
• Csak azok a portok legyenek nyitva a külső hálózatról, amelyek a felhasználók megfelelő működéséhez szükségesek;
• Létre kell hozni egy rendszert a felhasználói lépések átfogó nyomon követésére és minden nyilvánosan elérhető erőforrás normál állapotának megsértésének azonnali bejelentésére, amelyek működése a Társaság számára fontos;
• Központi vírusirtó rendszer és szabályzatok rendelkezésre állása a rosszindulatú programok tisztítására és eltávolítására;
• Központi rendszer elérhetősége a vírusirtó szoftverek kezeléséhez és frissítéséhez, valamint házirendek az operációs rendszer rendszeres frissítéséhez;
• A cserélhető flash adathordozók futtatásának lehetőségét a lehető legnagyobb mértékben korlátozni kell;
• A jelszónak legalább 8 karakter hosszúnak kell lennie, számokat, valamint kis- és nagybetűket kell tartalmaznia;
• Biztosítani kell a kulcsfontosságú információcsere-mappák védelmét és titkosítását, különösen az 1c cserefájlokat és az ügyfélbanki rendszert;
• Az információfeldolgozó létesítményekbe beépített áram- és távolsági kommunikációs vezetékeknek lehetőség szerint a föld alatt kell lenniük, vagy megfelelő alternatív védelem alatt kell állniuk;
• A hálózati kábeleket védeni kell az illetéktelen elfogástól vagy sérüléstől, például vezeték használatával vagy a nyilvánosan hozzáférhető területeken átvezető útvonalak elkerülésével.

Összegezve a fentieket, szeretném megjegyezni, hogy az információ védelmének fő szabályai a felhasználók jogainak és lehetőségeinek korlátozása, valamint az információs rendszerek használata során az ezek feletti ellenőrzés. Minél kevesebb joga van a felhasználónak az információs rendszerrel való munka során, annál kisebb az esélye annak, hogy az információ rosszindulatú szándékból vagy hanyagságból kiszivárogjon vagy megsérüljön.

Egy átfogó megoldás a vállalati adatok védelmére, beleértve az 1C adatbázisokat is, a „Server in Israel” megoldás, amely naprakész eszközöket tartalmaz az információk magas szintű titkosságának biztosítására.

Rendszerintegráció. Tanácsadó