1c beépített nyelvi verem túlcsordulás. Stack Overflow

2016. 04. 14. Verzió 3.22 A felület módosult, a nyilvántartások átvitelénél előforduló hibák kijavításra kerültek, módosult a szervezetátadás menete és a számviteli politika. Platform 8.3.7.2027 BP 3.0.43.174
2016.03.17. Verzió 3.24 Az észrevett hibákat kijavítottuk. Platform 8.3.8.1747 BP 3.0.43.241
2016.06.16. Verzió: 3.26 Az észlelt hibákat kijavítottuk. Platform 8.3.8.2088 BP 3.0.44.123
2016.10.16. Verzió 4.0.1.2 Rögzített értéktárolás, megváltozott számviteli politika kiadások átadása 3.44.*. Platform 8.3.9.1818 BP 3.0.44.164.
2017.04.19. Verzió 4.0.2.7 Megváltozott a könyvtárakhoz tartozó regiszterek átvitelének algoritmusa, kijavították az észlelt hibákat, javítva lett az átvitel a hivatkozások felülírásával.
2017.05.29. 4.0.4.5-ös verzió Módosította a mozgások átvitelét, hozzáadta az átvitt dokumentumok mozgásának megtekintését, valami más...
2017.05.30., 4.0.4.6-os verzió Hiba javítása a forrásban lévő meglévő könyvtárak listájának kitöltésekor (köszönöm shoy)
2017.06.17. 4.0.5.1-es verzió A mozgások átvitelének algoritmusa megváltozott.
2017.07.19. Verzió 4.0.5.4 A CI átvitele a BP 2.0-ról módosult. Váratlanul az UT 10.3-ból az átvitelt a Smilegm hajtotta végre, ebben a verzióban az átvitelt kissé korrigálták ehhez a helyzethez)))
2017.08.10. 4.0.5.5-ös verzió Javítva a BP 2.0-ról való átvitel során fellépő hibák
2017.09.19. Verzió 4.4.5.7 Fix kapcsolat ellenőrzés a 3.0.52.*
2017.11.28. Verzió 4.4.5.9 A jelentett hibák javítása
2017.12.06. 5.2.0.4-es verzió A linkkereső algoritmusát újratervezték. A BP 1.6-ból származó átviteli eljárások kerültek hozzáadásra, már nincs szoros kapcsolat a BP-vel - könnyen használható „majdnem” azonos konfigurációjú adatok átvitelére. Megpróbálok minden megjegyzést azonnal kijavítani.
2017.12.08. 5.2.1.3-as verzió Egy algoritmus hozzáadva a bérkimutatások BP.2.0-ról BP 3.0-ra történő átvitelére. Változások az azonos konfigurációk közötti megosztáshoz.
2017.12.19. Verzió 5.2.2.2 Kiigazításra került a független információs regiszterek átadása azon címtárak esetében, amelyek e regiszterek dimenzióiban vannak.

2017.12.06. Új feldolgozási verzió, 5.2.0.4. A jelentős változások közé tartozik a BP 1.6-ról a BP 3.0-ra való átállás lehetősége. A fő változás a címtárhivatkozások keresésének kezelése - a korábbi verziókban a keresés GUID alapján történt, de ebben a verzióban engedélyezheti a "Részletek szerint" keresést:

2018. 01. 17. Verzió 5.2.2.3 Javítva – észlelt hibák az alárendelt könyvtárakban és az időszakos információs nyilvántartásokban.

2018.07.19. Verzió 5.2.2.8 Az észrevett hibákat kijavítottuk.

amelyben bármely könyvtárhoz beállíthatja a keresési részleteket. Maga ez a rendszer a dolgozók számos kérésére „megjelent” olyan esetekre, amikor egy már létező, már adatokkal rendelkező adatbázisba van szükség cserére (például két szervezet számviteli nyilvántartásának összevonására egy adatbázisba).

2015.12.21. megjelent a 8.3.7.1805 platform és a BP 3.0.43.29. egy új verzió feldolgozás 3.1:-) (leírás lent). Új funkció - az egyenlegek és a forgalom összehasonlítása két BP-adatbázis között (minden számlára, ha a számlatükör egybeesik, vagy az egyes megfelelő számviteli számlákhoz, elemzéssel vagy anélkül).
2016. 01. 03. 3.5-ös verzió - a forrásbázishoz való csatlakozás mechanizmusa megváltozott - összhangba került a BSP 2.3.2.43-val. Kisebb hibák javítva. Platform 8.3.7.1845, BP 3.0.43.50
2016.02.16., 3.6-os verzió – A „Kézi javítás beállítása” jelző hozzáadva a mozgással átvitt dokumentumokhoz. Fix mozgásátadás - az időszak kezdeténél rövidebb dátumú dokumentumokat mozgás nélkül továbbítják. Platform 8.3.7.1917, BP 3.0.43.116
2016. 03. 22. Verzió 3.10 - A "Mindig felülírja a hivatkozásokat" jelzőt hozzáadva a hivatkozott objektumok kötelező újraírásához (az átviteli sebesség jelentősen csökken, de néha szükséges). Bekerült az "Előkészítés" fül, ahol konfigurálható a forrás- és célszámladiagramok megfeleltetése (a számlakódokkal azonos szinten) és a konstansok átvitele. Platform 8.3.7.1970, BP 3.0.43.148

2016.04.03. Verzió 3.11 Módosult a forrásban meglévő bizonylatok listájának kitöltése: számlatükör szerinti mozgásokkal lett kitöltve, egyszerűen az időszakra vonatkozó hivatkozásokkal történt, akárcsak a // site/public/509628/

A feldolgozás célja az adatok bármely időszakra történő átvitele, ugyanúgy, mint az „MXL feltöltése” ITS-sel, csak XML, JSON és más köztes fájlok használata nélkül - COM-on keresztüli csere adatbázisról adatbázisra. A 3.10-nél régebbi verziókban a kapcsolat a BSP algoritmusával történik, amely biztosítja a comcntr.dll regisztrációját (ha az operációs rendszer „engedi”), valamint különféle üzeneteket, amikor lehetetlen kapcsolatot létesíteni, pl. példa - „Az információs bázis frissítése folyamatban van” stb. Hozzáadott ellenőrzés a vevő IS forrásként való kiválasztásához – figyelmeztetés jelenik meg.

Használható:

1. Szabályozási referenciainformáció (RNI) átvitele az IS forrásból az IS célállomásra (az összes referenciainformáció átvitele a felhasználó kérésére történik, a szükséges referenciakönyvek stb. az átvitel során hivatkozásokon keresztül kerülnek átvitelre).

2. Dokumentumok átadása bármely kiválasztott időszakra.

3. Az összes információ átvitele egy „törött” információbiztonsági rendszerből, ha az 1C:Enterprise módban indul, és az adatok feltöltése vagy a Konfigurátor elindítása lehetetlen.

A feldolgozás sajátossága - a vevő és a forrás információbiztonsága eltérő lehet, átvitel 2.0-ról 3.0-ra - a kiadások eltérőek, de az átvitel működik!!! A nem egyező részleteket figyelmen kívül hagyja, vagy átviteli algoritmust kell megadni hozzájuk.

Megjegyzés: Az adatkonverzió NEM HASZNÁLT! És ne kérdezd miért!!! Azoknak, akik kifejezetten válogatósak - a BP 3.0 szinte minden nap változik, már nincs ereje naprakészen tartani az átigazolási szabályokat - itt minden egyszerűbb :-).

A feldolgozás másik jellemzője, hogy a vevő információbiztonságában indul (a funkcionalitásban legközelebbi analógok fordítva működnek - a forrástól a vevőig).

Kezdő lépések - meg kell adnia a feldolgozási időszakot, meg kell adnia a szervezetet a forrásból, ez átkerül a célállomásra.

Szervezet átruházásakor a számviteli politika és a „kapcsolódó” információs nyilvántartások átadásra kerülnek. Ezért amikor először választ ki egy szervezetet a forrásban, eltelik egy kis idő, mire megjelenik a vevőben.

A forrás és a rendeltetési hely számlatáblázatának meg kell egyeznie, a 2.* verziójú számlák nem kerülnek át a rendeltetési helyre, a tervek szerint a jövőben lehetővé válik az egyező számlák és az elemzések korrekciója. A számlák átvitele olyan kódokkal történik, amelyek nem találhatók a vevőben NEM LÉTREHOZHATÓ!!!

A fennmaradó objektumok átvitele belső azonosítók (GUID) használatával történik, ezért érdemes figyelni néhány kulcskönyvtárra, például - Pénznemek.

Ha „tiszta” adatbázissal tervezi a cserét, akkor jobb, ha a csere előtti első indításkor kitöltött könyvtárakat törölje. Miért van egy oldal a feldolgozás alatt, ahol beszerezheti ezeket a könyvtárelemeket és törölheti őket. Legalább el kell távolítania a "dörzsölő" pénznemet. - mert a duplikáció szinte elkerülhetetlen (ez elvileg könnyen korrigálható a BP 3.0-ba épített duplikátumok keresésének és cseréjének megosztása után).

A feldolgozás lehetővé teszi a címtártörlési oldal meghívását, amikor a kezdeti kitöltési űrlap nyitva van:

A feldolgozás megnyitásakor megjelenik egy oldal a kezdeti kitöltés során kitöltött könyvtárak törlésére:

A 3.22-es verzió óta a felület megváltozott, mostantól minden előkészítő művelet fülre kerül és mindig elérhető

Fontos, hogy ellenőrizze a forrás és a címzett Számlatáblázatának egyezését, és feltétlenül tüntesse fel a számlák megfelelőségét.

Nincs szükség előre meghatározott címtárelemek törlésére – ezeket konfigurációs azonosítók (nem GUID-k) továbbítják.

A könyvtárakból és dokumentumokból a kiválasztási űrlap segítségével kiválaszthatja az átvitelre szánt objektumokat (az ezekhez az objektumokhoz tartozó információs regiszterek automatikusan átvitelre kerülnek, így nincs szükség külön kiválasztásra).A nyilvántartások átvitele, a csökkentés ideiglenesen le van tiltva - ki kell dolgozni egy listát az átvitelhez - valamit át kell vinni, valamit nem, ebben a szakaszban elég, ami átkerül a címtárakba, az átvitelhez szükséges nyilvántartások listája a sablonban a jövőbeni verziókban.

A 2.0-val való csere során néhány részlet (pl. Elérhetőség) a feldolgozásba épített algoritmus szerint kerül átvitelre, mert a 2.0 és 3.0 esetében eltérően tárolódnak. Hasonló a helyzet számos dokumentummal (például Adósságrendezéssel).

Az objektumtípusok listája a 3.22-es verzióban másként is kitölthető, ez egy almenübe kerül, a változásokat a kép jelzi:

Leegyszerűsödik a feldolgozás használata - nem választhat ki cserére szolgáló könyvtárakat, hanem egyszerűen töltse ki a vevő típuslistáját csak azokkal a címtártípusokkal, amelyeknek legalább egy bejegyzése van a forrásban.

A feldolgozásnak van egy beépített elrendezése, amely felsorolja azokat a könyvtárakat, amelyeket nem kell átvinni a forrásból a célba ("Kizárás az átvitelből" elrendezés). Bármilyen könyvtárat hozzáadhat (eltávolíthat) ehhez az elrendezéshez. Ha nem kell az összes referenciaadatot átvinni, elég a bizonylatok átvitele, amelyek listája típusválasztás nélkül is beszerezhető, egyszerűen töltse ki az összes olyan forrásbizonylatot, amelyre tranzakciók léteznek.

Mozgásokkal járó bizonylatok átadása biztosított, a 3.0-3.0 cseréknél és a számlatükör megfeleltetésnél egytől egyig működik, 2.0-tól 3.0-ig cserénél hibák előfordulhatnak, ezért ajánlatos a bizonylatokat mozgás nélkül átvinni, majd egyszerűen vigye át őket a vevőre. Mozgásos dokumentumok átvitelekor a „Kézi beállítás” jelző be van állítva.

A „Felküldve” attribútum a címzett bizonylatokban ugyanúgy van beállítva, mint a forrásban, de a mozgások (ha nem kerültek átadásra) csak a bizonylatok feldolgozása után jelennek meg, például a dokumentumba beépített Csoportos Dokumentumfeladás feldolgozás segítségével. BP 3.0 (ajánlott opció), vagy ebből a feldolgozásból (Itt található a „Dokumentumok közzététele” gomb).

Ha a feldolgozást állandó cserére tervezik, akkor azt a fogadó információbiztonságában lehet regisztrálni (a „Regisztráció” gomb). „Egyszeri” átutaláshoz egyszerűen használhatja a Fájl - Megnyitás menüpontban.

2015.12.21. – 3.1-es verzió, 8.3.7.1805 platform és 3.0.43.29 tápegység (a 2.15-ös verzió a 3.0.43.*-hoz nem működik – a konfiguráció sokat változott).

Módosítva:

A csatlakozási opció kiválasztására szolgáló párbeszédpanel, a Client-server jelző mindig elérhető, beállításától függően, vagy egy fájl adatbázis-mappa választásától, vagy egy mezőben található a szerveren lévő adatbázis neve és magának a szervernek a neve elérhető (a párbeszédpanel 2.15-ös verziójában lévő hiba javításra került)

- ÚJ FUNKCIÓ: Mechanizmus a forrás- és vevőadatbázisok közötti egyenlegek és forgalom különböző részletességű egyeztetésére:

Úgy gondolom, hogy az ellenőrzési lehetőségek kiválasztása egyértelműen látszik az ábrán:

Különbségek vannak a vékony és vastag kliensek használatában - a vastag kliensben azonnal megjelenik egy fájl-összehasonlító ablak:

A vékonykliensben nem bajlódtam a gombok programozott megnyomásával, egy egyszerű lehetőséget javaslok az összehasonlító ablak megjelenítésére:

A vékony kliensben, az IMHO-ban való összehasonlítás kényelmesebb, mert... navigációs gombokkal rendelkezik a különbségekért, ami kényelmesebb nagy asztaloknál, mint az egérrel való görgetés:

2016. 03. 22. Verzió 3.10 - A "Mindig felülírja a hivatkozásokat" jelzőt hozzáadva a hivatkozott objektumok kötelező újraírásához (az átviteli sebesség jelentősen csökken, de néha szükséges). Bekerült az "Előkészítés" fül, ahol konfigurálható a forrás- és célszámladiagramok megfeleltetése (a számlakódokkal azonos szinten) és a konstansok átvitele. Platform 8.3.7.1970, BP 3.0.43.148

- ÚJ FUNKCIÓ: A dokumentumok átadása előtt ajánlatos ellenőrizni a számlatükröt a forrás és a cél konzisztenciája, valamint a megállapított állandók betartása szempontjából.

Ebből a célból egy „Előkészítés” fület adtunk hozzá, ahol beállíthatja a következő megfeleléseket:

A számlaegyezési táblázat kitöltésének algoritmusa egyszerű - a forrásban meglévő forgalmat elemzik, és minden ott talált számlánál egyezés található a fogadóban kód szerint; ha nem található egyezés, akkor egy sor a számlával. kód jelenik meg a táblázatban, amellyel ki kell választania a fogadó számlát, ez kerül felhasználásra az átutaláskor. A Poke-megfelelőség a kód szintjén történik.

A megállapított állandók megfelelésének ellenőrzésére és átvitelére a megfelelő táblázatot használjuk:

Kitöltjük, szükség esetén átadjuk. Csak a zászlóval jelölt állandók kerülnek átvitelre...

A programverem egy speciális memóriaterület, amely a LIFO (Last in, first out) sorelv szerint szerveződik. A "verem" elnevezés a tányérköteg felépítési elvének analógiájából származik - egymásra helyezheti a tányérokat (a kötegbe való hozzáadás módja, "nyomja", "tolja"), majd vigye el őket, felülről kezdve (a veremből érték lekérésének módja, "popping", "pop"). A programveremet hívóveremnek, végrehajtási veremnek vagy gépi veremnek is nevezik (hogy ne keverjük össze a "verem" -el - egy absztrakt adatszerkezettel).

Mire való a verem? Lehetővé teszi az alprogramok hívásának kényelmes megszervezését. A függvény meghívásakor néhány argumentumot kap; a lokális változóit is tárolnia kell valahol. Ezenkívül figyelembe kell venni, hogy egy függvény hívhat egy másik függvényt, amelynek szintén át kell adnia paramétereket és tárolnia kell a változóit. A verem segítségével a paraméterek átadásakor csak a verembe kell őket rakni, majd a meghívott függvény onnan „kipattantathatja” és használhatja. Helyi változók is tárolhatók ott - a kódja elején a függvény lefoglalja a veremmemória egy részét, a vezérlés visszatérésekor pedig törli és felszabadítja. A magas szintű nyelvek programozói általában nem gondolnak ilyen dolgokra - a fordító minden szükséges rutinkódot generál számukra.

Egy hiba következményei

Most már majdnem közel vagyunk a problémához. Absztrakt módon a köteg egy végtelen bolt, amelybe a végtelenségig lehet új elemeket hozzáadni. Sajnos a mi világunkban minden véges – és ez alól a veremmemória sem kivétel. Mi történik, ha akkor ér véget, amikor a függvény argumentumai a verembe kerülnek? Vagy a függvény memóriát foglal le a változói számára?

Veremtúlcsordulásnak nevezett hiba lép fel. Mivel a verem a felhasználó által definiált függvények hívásának megszervezéséhez szükséges (és a modern nyelveken szinte minden program, beleértve az objektumorientáltakat is, így vagy úgy függvények alapján épül fel), többé nem lesznek képesek hívják. Ezért az operációs rendszer átveszi az irányítást, törli a veremet, és leállítja a programot. Itt hangsúlyozhatjuk a verem túlcsordulás és a verem túlcsordulás közötti különbséget - az első esetben hiba lép fel egy hibás memóriaterület elérésekor, és ha ebben a szakaszban nincs védelem, akkor az abban a pillanatban nem jelentkezik - sikeres a körülmények kombinációja esetén a program normálisan működhet. Ha csak az éppen elért memória volt védett, . Verem esetén a program biztosan leáll.

Hogy teljesen pontosak legyünk, meg kell jegyezni, hogy az események ilyen leírása csak azokra a fordítókra igaz, amelyek natív kódra fordítanak. A felügyelt nyelveken a virtuális gép saját veremgel rendelkezik a felügyelt programok számára, amelyek állapota sokkal könnyebben nyomon követhető, és még azt is megengedheti magának, hogy túlcsordulás esetén kivételt dobjon a programból. A C és C++ nyelvekben nem számíthat ilyen „luxusra”.

A hiba okai

Mi vezethet egy ilyen kellemetlen helyzethez? A fent leírt mechanizmus alapján az egyik lehetőség az, hogy túl sok beágyazott függvényhívás van. Ez a forgatókönyv különösen valószínű rekurzió használatakor. A végtelen rekurzió (lusta kiértékelési mechanizmus hiányában) ilyen módon megszakad, szemben a -val, amelynek néha hasznos alkalmazásai is vannak. Azonban kis mennyiségű memóriával a veremhez (ami például a mikrokontrollerekre jellemző), elegendő lehet egy egyszerű hívássorozat.

Egy másik lehetőség a helyi változók használata, amelyek sok memóriát igényelnek. Egy millió elemből vagy egymillió helyi változóból álló helyi tömb (soha nem tudhatod, mi történik) nem a legjobb ötlet. Egy ilyen mohó függvény egyetlen hívása is könnyen veremtúlcsordulást okozhat. Nagy mennyiségű adat megszerzéséhez jobb dinamikus memóriamechanizmusokat használni, amelyek lehetővé teszik a hiánya miatti hiba kezelését.

A dinamikus memória azonban meglehetősen lassú az allokáció és a felszabadítás szempontjából (mivel az operációs rendszer kezeli ezt), közvetlen hozzáféréssel pedig manuálisan kell lefoglalni és felszabadítani. A veremben lévő memória nagyon gyorsan lefoglalható (valójában csak egy regiszter értékét kell megváltoztatni); emellett a veremben lefoglalt objektumok destruktorai automatikusan meghívódnak, amikor a függvény vezérlése visszatér, és a verem törlődik. Természetesen azonnal felmerül a vágy, hogy memóriát szerezzünk a veremből. Ezért a túlcsordulás harmadik módja a programozó saját memóriafoglalása a veremben. A C könyvtár kifejezetten erre a célra biztosítja az alloca függvényt. Érdekes megjegyezni, hogy ha a malloc dinamikus memóriát lefoglaló függvénynek van egy saját „ikerpárja” a felszabadítására, akkor az alloca függvénynek nincs meg - a memória automatikusan felszabadul, miután a függvény vezérlése visszatér. Talán ez csak bonyolítja a helyzetet - elvégre nem lehet felszabadítani a memóriát a funkcióból való kilépés előtt. Annak ellenére, hogy a man oldal szerint "az alloca függvény gép- és fordítófüggő, megvalósítása sok rendszeren problémás és hibás; használata nagyon komolytalan és rosszindulatú" - mégis használják.

Példák

Példaként nézzük meg az MSDN-en található rekurzív fájlkeresés kódját:

Void DirSearch(String* sDir) ( próbálja meg ( // Keresse meg az átadott mappában lévő almappákat. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0;i< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Szöveg); int numFiles = f->get_Length(); for (int j=0; j< numFiles; j++) { listBox1->Items->Add(f[j]); ) DirSearch(d[i]); ) ) fogás (Rendszer::Kivétel* e) ( Üzenetdoboz::Show(e->Message); ) )

Ez a függvény lekéri a megadott könyvtárban található fájlok listáját, majd meghívja magát a lista azon elemeiért, amelyek történetesen könyvtárak. Ennek megfelelően kellően mély fával fájlrendszer, természetes eredményt kapunk.

Példa a második megközelítésre, a „Miért történik veremtúlcsordulás?” kérdésből vett példa. a Stack Overflow nevű webhelyről (az oldal kérdések és válaszok gyűjteménye bármilyen programozási témáról, és nem csak a Stack Overflowról, ahogyan annak tűnik):

#define W 1000 #define H 1000 #define MAX 100000 //... int main() ( int image; float dtr; initImg(image,dtr); return 0; )

Mint látható, a fő függvény memóriát foglal le a veremben az int és float típusú tömbök számára, amelyek mindegyike egymillió elemet tartalmaz, ami összesen valamivel kevesebb, mint 8 megabájtot ad. Ha figyelembe vesszük, hogy a Visual C++ alapértelmezés szerint csak 1 megabájtot foglal le a verem számára, akkor a válasz nyilvánvalóvá válik.

És itt van egy példa a Lightspark Flash player projekt GitHub tárházából:

DefineSoundTag::DefineSoundTag(/* ... */) ( // ... unsigned int soundDataLength = h.getLength()-7; unsigned char *tmp = (előjel nélküli karakter *)alloca(soundDataLength); // .. .)

Remélhetőleg a h.getLength()-7 nem túl nagy szám, hogy ne legyen túlcsordulás a következő sorban. De megéri-e a memóriafoglalással megspórolt idő a program „potenciális” összeomlását?

A lényeg

A veremtúlcsordulás egy végzetes hiba, amely leggyakrabban a rekurzív függvényeket tartalmazó programokat érinti. Azonban még ha a program nem is tartalmaz ilyen funkciókat, a túlcsordulás továbbra is lehetséges a helyi változók nagy mérete vagy a veremben a memória kézi kiosztásának hibája miatt. Minden klasszikus szabály érvényben marad: ha van választási lehetőség, jobb az iterációt választani a rekurzió helyett, és ne végezzen manuális munkát a fordító helyett.

Bibliográfia

• E. Tanenbaum. Számítógép architektúra.
• Wikipédia. Verem túlcsordulás.
• Stack Overflow. Verem túlcsordulás C++.

Ebben az összefüggésben a verem az utolsó az első pufferben, amelyet a program végrehajtása során lefoglal. Utolsó, elsőként (LIFO) azt jelenti, hogy mindig az utolsó dolog, amit betesz, az az első, amit visszaugrasz – ha 2 elemet teszel fel a veremre, "A", majd "B"-t, akkor az első dolog, amit kipattansz a veremből. "B" lesz, a következő pedig "A".

Amikor meghív egy függvényt a kódban, a függvényhívás után következő parancs a veremben és a függvényhívás által felülírható memóriaterületen tárolódik. A kiválasztott függvény több veremet is használhat saját helyi változóihoz. Ha ez megtörtént, felszabadítja az általa használt helyi változóterületet, majd visszatér az előző függvényhez.

Stack Overflow

Veremtúlcsordulásról akkor beszélünk, ha több memóriát használtunk fel a veremben, mint amennyit a program használni szándékozott. Beágyazott rendszereken lehet, hogy csak 256 bájt áll rendelkezésre a veremhez, és ha minden függvény 32 bájtot vesz igénybe, akkor csak 8 függvényhívása lehet a 2. függvénynek az 1. mély funkcióval, amely a 3. funkciót hívja meg, amely a 4. funkciót. ...aki meghívja a 8-as függvényt, amely meghívja a 9-es függvényt, de a 9-es függvény felülírja a veremen kívüli memóriát. Ez felülírhatja a memóriát, kódot stb.

Sok programozó elköveti ezt a hibát úgy, hogy meghívja az A függvényt, amely ezután meghívja a B függvényt, amely ezután meghívja a C függvényt, amely aztán meghívja az A függvényt. Lehet, hogy legtöbbször működik, de egyetlen rossz bemenet miatt örökké körözni fog a számítógépig. a fails megtudja, hogy a verem megtelt.

A rekurzív függvények is ennek az okai, de ha rekurzívan írunk (azaz a függvény meghívja magát), akkor ennek tudatában kell lennie, és statikus/globális változókat kell használnia a végtelen rekurzió elkerülése érdekében.

Általában az Ön által használt operációs rendszer és programozási nyelv kezeli a veremet, és az nincs a kezében. Meg kell néznie a hívási grafikonját (egy fastruktúra, amely a fő ponttól kezdve megmutatja, hogy az egyes függvények mit hívnak meg), hogy lássa, milyen mélyek a függvényhívások, és azonosítsa a nem szándékolt hurkokat és rekurziót. A szándékos ciklusokat és a rekurziót mesterségesen hibaellenőrzéssel kell végezni, ha túl sokszor hívják egymást.

A jó programozási gyakorlatokon, a statikus és dinamikus tesztelésen kívül nem sok mindent lehet tenni ezekben a magas szintű rendszerekben.

Beágyazott rendszerek

A beágyazott világban, különösen a magas szintű biztonságot nyújtó kódokban (autóipar, repülőgépipar, repülőgépipar), kiterjedt tesztelést és kódellenőrzést végez, de a következőket is megteszi:

• Rekurzió és hurkok letiltása – irányelvek és tesztelés megfelelősége
• A kódot tartsa távol egymástól (a kódot a flash-ben, a RAM-ban rakja össze, és soha nem fog megegyezni)
• Helyezzen védőrúdokat a verem köré – egy üres memóriaterületet, amelyet megtölt egy varázsszámmal (általában a megszakítási rutin, de itt sok változat létezik), és másodpercenként több száz vagy ezer alkalommal nézi meg a védőrúdokat. biztos nem írták felül.
• Használjon memóriavédelmet (azaz ne futtasson a veremben, ne olvasson vagy írjon közvetlenül a verem mögé)
• A megszakítások nem hívnak meg másodlagos függvényeket – zászlókat állítanak be, adatokat másolnak, és hagyják, hogy az alkalmazás gondoskodjon a kezelésükről (ellenkező esetben előfordulhat, hogy 8 mélyre kerülhet a függvényhívási fájában, megszakítást kaphat, és akkor még néhány funkciót tartalmazhat a megszakítási kilépés, ami dobást okoz). Több hívásfája van – egy a fő folyamatokhoz és egy minden megszakításhoz. Ha a megszakításaid megzavarhatják egymást... hát vannak sárkányok...

Magas szintű nyelvek és rendszerek

De az operációs rendszereken futó magas szintű nyelveken:

• Csökkentse a helyi változók tárolását (a helyi változók a veremben vannak tárolva), bár a fordítók meglehetősen okosak ebben, és néha nagy darabokat tesznek a kupacba, ha a hívási fa sekély)
• Kerülje el vagy szigorúan korlátozza a rekurziót
• Ne szakítsa túl messzire a programjait az egyre kisebb függvényekbe – a helyi változók figyelembevétele nélkül is minden függvényhívás akár 64 bájtot is felemészt a veremben (32 bites processzor, a processzor regisztereinek felét megmentve, flagek stb.).
• Tartsa sekélyen a hívásfát (hasonlóan a fenti leíráshoz)

Webszerverek

Az Ön által használt homokozótól függ, hogy tudja-e irányítani vagy akár látni is a köteget. Valószínűleg úgy tudja kezelni a webszervereket, mint bármely más magas szintű nyelvet és operációs rendszert – ez nagyrészt az Ön kezében van, de ellenőrizze a használt nyelvet és szerververmet. Például feloszthatja az SQL-kiszolgáló veremét.

Az Informix® DataBlade™ API programozói kézikönyv letölthető. A „Veremterület kezelése” szakasz a felhasználó által definiált függvények (UDR) létrehozását írja le. Ez a cikk további információkat és hibakeresési tippeket tartalmaz.

A következő információk arra vonatkoznak, hogy az UDR felhasználó által meghatározott virtuális processzoron (VP) vagy VP CPU-n fut. Egy szál verem közvetlenül az UDR végrehajtása előtt áthelyezhető egy felhasználó által meghatározott virtuális processzorba.

Milyen méretű verem van lefoglalva az UDR-hez?

Az UDR számára elérhető verem mérete az UDR létrehozásának módjától függ:

a STACK módosító használatával, amely lehetővé teszi az UDR számára a speciálisan hozzárendelt verem használatát,

a STACK módosító nélkül, ami azt jelenti, hogy az UDR megosztja a szerver által lefoglalt veremet a kérést benyújtó szálal. A verem méretét ebben az esetben a STACKSIZE paraméter értéke határozza meg az onconfig konfigurációs fájlban.

STACK módosító

A CREATE PROCEDURE vagy a CREATE FUNCTION utasításoknak van egy opcionális STACK módosítója, amely lehetővé teszi az UDR végrehajtásához szükséges veremterület bájtokban történő megadását.

Ha az UDR létrehozásakor a STACK módosítót használja, a szerver minden egyes UDR végrehajtásakor lefoglalja és felszabadítja a veremterületet. A tényleges elérhető méret megegyezik a Bájtban megadott STACK értékkel, mínusz a függvényargumentumok számától függően némi többletköltség.

Ha a STACK érték kisebb, mint a STACKSIZE paraméter az onconfig fájlban (lásd a következő részt), akkor az UDR-hez hozzárendelt veremméretet a rendszer automatikusan felkerekíti a STACKSIZE értékre.

STACKSIZE konfigurációs paraméter

Az onconfig konfigurációs fájl tartalmaz egy STACKSIZE paramétert, amely meghatározza a felhasználói szálak alapértelmezett veremméretét.

Ha nem adja meg a VEREM értéket az UDR létrehozásakor, a szerver nem foglal le további veremterületet az UDR végrehajtásához. Ehelyett az UDR a lefoglalt veremterületet használja a kérelem végrehajtásához. Az elérhető veremméret a függvény SQL szintű végrehajtásának többletköltségétől függ.

A szálonkénti verem egyszer kerül lefoglalásra a kérést végrehajtó adott szálhoz. A teljesítmény jobb, ha az UDR egy szálon osztozik egy veremben, mivel a szerver nem pazarolja az erőforrásokat arra, hogy minden egyes UDR-híváshoz egy további veret allokáljon. Másrészt, ha az UDR által használt veremméret megközelíti a STACKSIZE értéket, az veremtúlcsordulást okozhat, amikor a függvényt egy összetett lekérdezés részeként hívják (ebben az esetben kevesebb veremterület áll majd rendelkezésre az UDR végrehajtásához).

Kérjük, vegye figyelembe, hogy ne állítsa túl magasra a STACKSIZE értéket, mivel ez minden felhasználói szálra hatással lesz.

Mikor szükséges ellenőrizni a verem méretét?

YA veremterületet kezelnie kell, ha az UDR rekurzív hívásokat hajt végre, vagy ha az UDR több veremterületet igényel, mint amennyi a kérésszál veremében alapértelmezés szerint rendelkezésre áll (STACKSIZE).

Kétféleképpen növelheti az UDR-végrehajtás veremét:

UDR létrehozásakor adja meg a STACK módosítót.

A mi_call() használatával rekurzív hívásokat indíthat (lásd az Informix DataBlade API programozói útmutatóját).

Ha nem adsz meg méretet a STACK-en keresztül, és ha nem használod a mi_call()-ot az aktuális verem növelésére, és ha az UDR olyasmit csinál, ami sok veremterületet igényel, az veremtúlcsordulást okoz.

Vegye figyelembe, hogy egyes mi_* függvények új veremszegmenst adnak hozzá saját végrehajtásuk érdekében. Ezek a szegmensek felszabadulnak, amikor visszatérünk a hívó UDR függvényhez.

Mi a teendő, ha valami elromlik?

Veremhasználat figyelése

A figyelés célja a veremtúlcsordulást okozó konkrét UDR azonosítása, így az adott UDR-hez kimondottan módosíthatja a STACK értékét.

A veremhasználat figyelése az "onstat -g sts" paranccsal

SQL lekérdezést végrehajtó munkamenet figyelése az "onstat -g ses session_id" használatával

A veremtúlcsordulással végződő SQL-lekérdezések azonosítása után meg kell határoznia a veremhasználatot az eredeti lekérdezés részét képező UDR-lekérdezések külön végrehajtásával.

Dinamikusan beállíthatja az UDR STACK értékét. Például:

funkció módosítása MyFoo (lvarchar,lvarchar) a következővel: (verem hozzáadása=131072);

A STACK érték módosítása után tesztelje az eredeti kérést, hogy megbizonyosodjon arról, hogy az immár stabil.

Növelje a STACKSIZE-ot

Alternatív megoldásként próbálja meg növelni a STACKSIZE értéket. Ellenőrizze, hogy ez megoldja-e a problémát. (Ne felejtse el később visszaadni a régi értéket).

Ha a STACKSIZE növelése nem segít, a probléma valószínűleg a memória sérülése. Íme néhány javaslat:

Engedélyezze a memóriafirkálás és a memóriatár ellenőrzését. A Memóriafoglalás UDR-ekhez cikk "Hibakeresési problémák" szakasza elmagyarázza, hogyan kell ezt megtenni.

Fontolja meg újra a mi_lvarchar használatát. Különös figyelmet kell fordítani azokra a helyekre, ahol a mi_lvarchar átadásra kerül egy függvénynek, amely egy null-végű karakterláncot vár argumentumként.

Csökkentse a CPU (vagy felhasználói) VP-k számát egyre a probléma gyorsabb reprodukálásához.

mi_print_stack() -- Solaris

Az Informix Dynamic Server for Solaris OS tartalmaz egy mi_print_stack() függvényt, amely meghívható az UDR-ben. Alapértelmezés szerint ez a funkció a veremkeretet a következő fájlba menti:

/tmp/default.stack

A kimeneti fájl nevét nem módosíthatja, de a helyét megváltoztathatja a DBTEMP környezeti változó értékének módosításával. Győződjön meg arról, hogy az informix felhasználó írhatja a $DBTEMP könyvtárat. A mi_print_stack() végrehajtása során észlelt hibákat a $MSGPATH jelenti.

Ez a funkció csak az OC Solaris esetében érhető el.

Szójegyzék

A cikkben használt kifejezések és rövidítések:

UDR	Felhasználó által meghatározott rutin
V.P.	Virtuális processzor

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 sok 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. a szervezet szemszögéből információ biztonság. 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 olvasá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és és megvalósítás sebessége, 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ó. Általános szabály Az 1C esetében csökkenteni kell a korlátozásokat, amikor lefelé halad a sémában, ezért az egyik biztonsági rését használva felsőbb szintek minden szinten megzavarhatja a rendszert.

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 rendszer (és esetleg egy szabványos alkalmazásmegoldás) üzembe kerül a vállalatban, és telepítve van 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 szerverterem megnyitására csak egy-két embernek van joga, vészhelyzet esetére kidolgozásra került a felelősök értesítési rendszere;
  • 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 (különösen 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 adminisztrátori jogokkal a kliens 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és a felhasználók által Microsoft Windows rendszergazdai jogok nélkül
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 információs bázis 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. Sajátosságok Windows beállítások Server 2003 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 interaktív indításhoz külső kezelések Létrehozhat egy külön szerepkört, és hozzáadhatja minden olyan felhasználóhoz, akinek külső feldolgozást 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 kapcsolati 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-t használó teljes 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 olvasását és írását is).

Jogosultság hiánya az információbiztonság megteremtésekor a szerveren

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 használata (űrlapok, táblázatos dokumentumokat, párbeszédpanelek), a külső jelentések és a kódban történő feldolgozás az alkalmazáskiszolgálón 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 ügyfélkapcsolatok, 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;
• nem a szerveren felhasználói felület, de felügyeleti é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 szervermodulokba 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őrizze, 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 fájl- és fájlinformációkkal ellátni operációs rendszer használjon, vagy olyan műveleteket hajtson végre, amelyek nem kapcsolódnak az adatok kezeléséhez („Jogok megsértése”)
• 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 az ügyféltő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);
Az eljárás vége
#EndIf

Gépelje be "COMObject" (konstruktor New 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, hogy adatokat szerezzen be az alkalmazásszerverről helytelen használat és adatátvitel esetén 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 távoli számítógéphez csatlakozik 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ás paramétereit.

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

Szerver összeomlás. Ezek a függvények nem kezelik a körkörös hivatkozásokat a gyűjteményekben vagy a nagyon mély egymásba ágyazást, így bizonyos 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 Iterációs számláló>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 Terminal Services minden esetben lehetővé teszi, 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 kiszolgálói erőforrások túlzott felhasználásának megakadályozásával egyidejűleg egy ilyen korlátozás megakadályozhatja, hogy valaki mást használjon fiókot. 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 szolgáltatásokat csak rendszergazdai jogokkal rendelkezők számára engedélyezze.

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 nyomon 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 házirendet 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 összetevők használata internet böngésző. 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 a 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 az ü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ő kérdése és az Ön információi értékének kérdése.

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! Külső jelentések és feldolgozás - egyrészt - kényelmes módja további nyomtatott űrlapok megvalósítása, hatósági jelentések, speciális jelentések, másrészt lehetséges mód számos rendszerbiztonsági korlátozás megkerülésére és az alkalmazásszerver működésének megzavarására (például 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. Az egyetlen, amit tanácsolhatunk, 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 társított 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 lefutásairól, mentse el például a cserefájlt, és küldje el emailben információbiztonsági rendszergazdát 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 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ása esetén). 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. A fő probléma ebben az esetben a termelékenység jelentős csökkenése és lehetséges problémákat megbízhatóság a meghibásodásoktól. 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-os lépésekben
(NÉV = 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 mentés 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éretnél 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 = Új ZipFileRecord(IdeiglenesArchívfájlnév, Jelszó, Titkosítási módszer);
Zip.Add(TemporaryFileName);
Zip.Write();

// Adatok beolvasása a fogadott archívumból ide RAM
EncryptedData = ÚjÉrtékTároló(Ú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(TemporaryFileName + "\" + 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 olyan 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 az átadáskor üres érték karakterlánc vagy jelszó beírása ezekbe a függvényekbe 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 további lehetséges szűk keresztmetszetek léphetnek fel 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ával 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 minden, a biztonsággal kapcsolatos szempontot feltüntetni az 1C-ben, 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. Ez azonban semmiképpen sem jelenti azt, hogy ezeket a problémákat nem lehet 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. Ezenkí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. .