1c vestavěný přetečení jazykového zásobníku. Přetečení zásobníku

14.04.2016 Verze 3.22 Bylo změněno rozhraní, opraveny chyby při přenosu registrů, byl změněn postup při převodu organizace a účetní zásady. Nástupiště 8.3.7.2027 BP 3.0.43.174
17.03.2016 Verze 3.24 Zjištěné chyby byly opraveny. Nástupiště 8.3.8.1747 BP 3.0.43.241
16.06.2016 Verze 3.26 Zjištěné chyby byly opraveny. Nástupiště 8.3.8.2088 BP 3.0.44.123
16. 10. 2016 Verze 4.0.1.2 Opravený převod uložení hodnoty, změna převodu účetní politiky pro vydání 3.44.*. Nástupiště 8.3.9.1818 BP 3.0.44.164.
19.04.2017 Verze 4.0.2.7 Algoritmus pro přenos registrů spojených s adresáři byl změněn, byly opraveny zaznamenané chyby, opraven přenos s přepisováním odkazů.
29.05.2017 Verze 4.0.4.5 Změněn přenos pohybů, přidáno prohlížení pohybů přenášených dokladů, něco jiného...
30.05.2017 Verze 4.0.4.6 Opravena chyba při vyplňování seznamu existujících adresářů ve zdroji (díky shoy)
17.06.2017 Verze 4.0.5.1 Algoritmus pro přenos pohybů byl změněn.
19.07.2017 Verze 4.0.5.4 Převod CI z BP 2.0 byl změněn. Převod z UT 10.3 nečekaně provedl Smilegm, v této verzi byl převod pro tuto situaci mírně opraven)))
8. 10. 2017 Verze 4.0.5.5 Opravené chyby při přenosu z BP 2.0
19.09.2017 Verze 4.4.5.7 Kontrola pevného připojení pro 3.0.52.*
28.11.2017 Verze 4.4.5.9 Opraveny hlášené chyby
12/06/2017 Verze 5.2.0.4 Algoritmus vyhledávání odkazů byl přepracován. Byly přidány přenosové procedury z BP 1.6, již neexistuje striktní napojení na BP - můžete jej snadno použít k přenosu dat „téměř“ identických konfigurací. Všechny komentáře se pokusím neprodleně opravit.
12/08/2017 Verze 5.2.1.3 Přidán algoritmus pro přenos mzdových výkazů z BP.2.0 do BP 3.0. Zahrnuty změny pro sdílení mezi identickými konfiguracemi.
19.12.2017 Verze 5.2.2.2 Upraven převod nezávislých informačních registrů pro adresáře, které jsou v rozměrech těchto registrů.

12.06.2017 Nová verze zpracování 5.2.0.4. Mezi významné změny patří možnost přechodu z TK 1,6 na TK 3,0. Hlavní změnou je správa vyhledávání odkazů na adresář - v předchozích verzích bylo vyhledávání podle GUID, ale v této verzi můžete povolit vyhledávání "Podle podrobností":

17.01.2018 Verze 5.2.2.3 Opraveno - zjištěné chyby v podřízených adresářích a periodických informačních registrech.

19.07.2018 Verze 5.2.2.8 Zjištěné chyby byly opraveny.

ve kterém můžete nastavit podrobnosti vyhledávání pro libovolný adresář. Tento režim sám „vznikl“ na četné požadavky pracovníků pro případy, kdy je potřeba výměna do již existující databáze, která již data má (např. pro sloučení účetních záznamů dvou organizací do jedné databáze).

21.12.2015 byly vydány platformy 8.3.7.1805 a BP 3.0.43.29, resp. novou verzi zpracování 3.1:-) (popis níže). Nová funkcionalita - možnost porovnávat zůstatky a obraty mezi dvěma databázemi BP (pro všechny účty, pokud se účetní osnovy shodují, nebo pro jednotlivé spárované účetní účty, s analytikou nebo bez ní).
01.03.2016 Verze 3.5 - byl změněn mechanismus připojení ke zdrojové základně - uveden do souladu s BSP 2.3.2.43. Opraveny drobné chyby. Nástupiště 8.3.7.1845, BP 3.0.43.50
16.02.2016 Verze 3.6 - Přidán příznak "Nastavit ruční opravu" pro doklady přenášené s pohyby. Pevný převod pohybů - doklady s datem menším než začátek období se převádějí bez pohybů. Nástupiště 8.3.7.1917, BP 3.0.43.116
22.03.2016 Verze 3.10 - Přidán příznak "Vždy přepisovat reference" pro povinné přepisování odkazovaných objektů (přenosová rychlost je výrazně snížena, ale někdy je to nutné). Přibyla záložka "Příprava", kde lze konfigurovat korespondenci zdrojové a cílové účtové osnovy (na stejné úrovni jako kódy účtů) a přenos konstant. Nástupiště 8.3.7.1970, BP 3.0.43.148

4. 3. 2016 Verze 3.11 Změněno plnění seznamu dokladů existujících ve zdroji: vyplňovalo se pohyby podle účtového rozvrhu, provádělo se jednoduše pomocí odkazů za období, stejně jako v // web/veřejné/509628/

Zpracování je určeno pro přenos dat za libovolné období stejným způsobem jako „Nahrávání MXL“ s ITS, pouze bez použití XML, JSON a dalších mezisouborů - výměna z databáze do databáze přes COM. Ve verzích starších než 3.10 se používá připojení pomocí algoritmu z BSP, který zajišťuje registraci comcntr.dll (pokud to OS „umožňuje“) a také různé zprávy, když nelze navázat spojení, např. příklad - „Informační základna je v procesu aktualizace“ atd. . Přidána kontrola výběru přijímače jako zdroje IS - je vydáno varování.

Lze použít pro:

1. Přenos regulačních referenčních informací (RNI) ze zdroje IS do cíle IS (přenos všech referenčních informací se provádí na žádost uživatele, potřebné referenční knihy atd. jsou přenášeny prostřednictvím odkazů při jakýchkoli přenosech).

2. Převod dokladů za libovolné zvolené období.

3. Přenos všech informací z „rozbitého“ systému zabezpečení informací, pokud je spuštěn v režimu 1C:Enterprise a nahrání dat nebo spuštění konfigurátoru není možné.

Vlastnost zpracování - informační zabezpečení přijímače a zdroje se může lišit, přenos z 2.0 na 3.0 - edice jsou různé, ale přenos funguje!!! Neodpovídající podrobnosti jsou ignorovány nebo pro ně musí být specifikovány přenosové algoritmy.

Komentář: Konverze dat se NEPOUŽÍVÁ! A neptejte se proč!!! Pro ty, kteří jsou obzvlášť vybíraví - BP 3.0 se mění téměř každý den, už není síla udržovat pravidla převodu aktuální - tady je vše jednodušší :-).

Dalším znakem zpracování je, že se spouští v informační bezpečnosti přijímače (analogy, které jsou funkčně nejbližší, fungují naopak - od zdroje k přijímači).

Začínáme - je třeba zadat období zpracování, uvést organizaci ze zdroje, bude přenesena do cíle.

Při převodu organizace se převádějí účetní zásady a „související“ informační registry. Když tedy poprvé vyberete organizaci ve zdroji, uplyne nějaký čas, než se objeví v přijímači.

Účtové osnovy zdroje a cíle musí být stejné, do cíle se nepřenášejí žádné různé účty ve verzích 2.*, do budoucna je plánováno umožnit úpravu spárovaných účtů a analytiky. Účty se převádějí pomocí kódů, které se nenacházejí v přijímači NELZE VYTVOŘIT!!!

Zbývající objekty jsou přenášeny pomocí interních identifikátorů (GUID), takže byste měli věnovat pozornost některým klíčovým adresářům, například - Currencies.

Pokud plánujete výměnu s „čistou“ databází, pak je lepší smazat adresáře vyplněné při prvním spuštění před výměnou. Proč je ve zpracování stránka, kde můžete získat tyto prvky adresáře a odstranit je. Minimálně musíte odstranit měnu „rub“. - protože duplikace je téměř nevyhnutelná (v zásadě se to snadno opraví po sdílení vyhledávání a nahrazení duplikátů zabudovaných v BP 3.0).

Zpracování umožňuje vyvolání stránky pro odstranění adresáře, když je otevřen počáteční formulář pro vyplňování:

Po otevření zpracování se zobrazí stránka pro smazání adresářů vyplněných při počátečním plnění:

Od verze 3.22 bylo rozhraní změněno, nyní jsou všechny přípravné operace v záložkách a jsou vždy dostupné

Je důležité zkontrolovat soulad Účtové osnovy zdroje a příjemce a nezapomeňte uvést souvztažnost účtů.

Předdefinované prvky adresáře není nutné mazat – přenášejí se pomocí konfiguračních identifikátorů (nikoli GUID).

Objekty k přenosu můžete vybrat pomocí výběrového formuláře z adresářů a dokumentů (informační registry spojené s těmito objekty se přenesou automaticky, takže je není potřeba vybírat samostatně).Převod registrů, redukce je dočasně zakázána - je třeba vypracovat seznam registrů pro převod - něco by se mělo přenést, něco ne, v této fázi stačí, co se přenese v adresářích, seznam registrů pro převod bude v šabloně v budoucích verzích.

Při výměně s 2.0 se některé detaily (např. Kontaktní informace) se přenáší podle algoritmu zabudovaného do zpracování, protože pro 2.0 a 3.0 jsou uloženy odlišně. Podobně je tomu u řady dokumentů (například Úprava dluhu).

Seznam typů objektů lze ve verzi 3.22 vyplnit různě, je umístěn v podmenu, změny jsou vyznačeny na obrázku:

Dochází ke zjednodušení použití zpracování - nelze vybírat adresáře pro výměnu, ale jednoduše naplnit seznam typů v přijímači pouze těmi typy adresářů, které mají alespoň jeden záznam ve zdroji.

Zpracování má vestavěné rozložení, které uvádí adresáře, které není třeba přenášet ze zdroje do cíle (rozvržení „Vyloučit z přenosu“). Do tohoto rozložení můžete přidat (odebrat) libovolné adresáře. Pokud nepotřebujete přenést všechna referenční data, postačí přenést dokumenty, jejichž seznam lze získat i bez výběru typů, jednoduše vyplnit všechny zdrojové dokumenty, pro které existují transakce.

Převod dokladů s pohyby je zajištěn, u výměn 3.0 až 3.0 a korespondence účtových rozvrhů funguje jedna ku jedné, při výměně 2.0 až 3.0 jsou možné chyby, proto se doporučuje převádět doklady bez pohybů a poté jednoduše je přeneste do přijímače. Při přenosu dokladů s pohyby je nastaven příznak „Ruční úprava“.

Atribut „Zaúčtováno“ je v dokladech příjemce nastaven stejně jako ve zdroji, ale pohyby (pokud nebyly převedeny) se objeví až po zpracování dokladů, např. pomocí zpracování zabudovaného v BP 3.0 Skupinové zaúčtování dokumentů (doporučená volba), nebo z tohoto zpracování (zde je tlačítko „Zaúčtovat dokumenty“).

Pokud je zpracování plánováno pro trvalou výměnu, lze jej zaregistrovat do informačního zabezpečení příjemce (tlačítko „Registrovat“). Pro „jednorázové“ převody jej můžete jednoduše použít přes Soubor - Otevřít.

21.12.2015 - Verze 3.1 platforma 8.3.7.1805 a napájecí jednotka 3.0.43.29 (verze 2.15 pro 3.0.43.* nefunguje - konfigurace je poměrně hodně změněna).

Změněno:

Dialog pro výběr možnosti připojení, příznak Klient-server je k dispozici vždy, v závislosti na jeho nastavení buď volba složky databáze souborů, nebo pole s názvem databáze na serveru a názvem samotného serveru. k dispozici (chyba v dialogovém okně verze 2.15 byla opravena)

- NOVÁ FUNKČNOST: Mechanismus pro sladění zůstatků a obratu mezi zdrojovou a přijímající databází v různé míře podrobnosti:

Myslím, že výběr možností ověření je jasný z obrázku:

Existují rozdíly v použití u tenkého a tlustého klienta - u tlustého klienta se okamžitě zobrazí okno pro porovnání souborů:

V tenkém klientovi jsem se neobtěžoval programovým mačkáním tlačítek, navrhuji jednoduchou možnost zobrazení porovnávacího okna:

Srovnání v tenkém klientovi, IMHO, je pohodlnější, protože... má navigační tlačítka pro rozdíly, což je pohodlnější pro velké tabulky než rolování pomocí myši:

22.03.2016 Verze 3.10 - Přidán příznak "Vždy přepisovat reference" pro povinné přepisování odkazovaných objektů (přenosová rychlost je výrazně snížena, ale někdy je to nutné). Přibyla záložka "Příprava", kde lze konfigurovat korespondenci zdrojové a cílové účtové osnovy (na stejné úrovni jako kódy účtů) a přenos konstant. Nástupiště 8.3.7.1970, BP 3.0.43.148

- NOVÁ FUNKČNOST: Před převodem dokladů se doporučuje zkontrolovat účetní osnovu na konzistenci ve zdroji a určení a také na dodržování stanovených konstant.

Za tímto účelem byla přidána záložka „Příprava“, ve které můžete nastavit tyto korespondence:

Algoritmus pro vyplnění párovací tabulky účtů je jednoduchý – analyzuje se obrat existující ve zdroji a pro každý tam nalezený účet je v přijímači nalezena shoda podle kódu; pokud shoda není nalezena, řádek s účtem v tabulce se zobrazí kód, pomocí kterého je třeba vybrat účet příjemce, použije se při převodu. Soulad s poke je stanoven na úrovni kódu.

Pro kontrolu a přenos korespondence stanovených konstant se používá odpovídající tabulka:

Vyplníme a případně přeneseme. Přenášejí se pouze konstanty označené příznakem...

Zásobník programů je speciální paměťová oblast organizovaná podle principu fronty LIFO (Last in, first out). Název „stack“ pochází z analogie principu jeho konstrukce se stohem talířů – talíře můžete pokládat na sebe (metoda přidávání do stohu, „push“, „push“), a pak odeberte je, začněte odshora (metoda získání hodnoty ze zásobníku, "popping", "pop"). Zásobník programu se také nazývá zásobník volání, zásobník provádění nebo zásobník stroje (aby nedošlo k záměně s "zásobníkem" - abstraktní datovou strukturou).

K čemu je zásobník? Umožňuje pohodlně organizovat volání podprogramů. Při volání funkce přijímá některé argumenty; také musí někde ukládat své lokální proměnné. Kromě toho musíme vzít v úvahu, že jedna funkce může volat jinou funkci, která také potřebuje předat parametry a uložit své proměnné. Pomocí zásobníku je při předávání parametrů stačí vložit do zásobníku a volaná funkce je odtud může „vytáhnout“ a použít. Mohou tam být uloženy i lokální proměnné - na začátku svého kódu funkce alokuje část paměti zásobníku a po návratu řízení ji vyčistí a uvolní. Programátoři v jazycích na vysoké úrovni o takových věcech obvykle nepřemýšlejí - kompilátor pro ně generuje veškerý potřebný rutinní kód.

Následky chyby

Nyní jsme téměř blízko problému. Stručně řečeno, zásobník je nekonečný obchod, do kterého lze donekonečna přidávat nové položky. Bohužel v našem světě je vše konečné – a zásobníková paměť není výjimkou. Co se stane, když skončí, když jsou argumenty funkce vloženy do zásobníku? Nebo funkce alokuje paměť pro své proměnné?

Dojde k chybě zvané přetečení zásobníku. Vzhledem k tomu, že zásobník je potřebný k organizaci volání uživatelsky definovaných funkcí (a téměř všechny programy v moderních jazycích, včetně objektově orientovaných, jsou tak či onak postaveny na základě funkcí), nebudou již moci být nazván. Operační systém tedy převezme kontrolu, vyčistí zásobník a ukončí program. Zde můžeme zdůraznit rozdíl mezi přetečením zásobníku a přetečením zásobníku - v prvním případě dojde k chybě při přístupu na nesprávnou paměťovou oblast a pokud v této fázi není ochrana, v tu chvíli se neprojeví - při úspěšném kombinace okolností může program fungovat normálně. Pokud byla chráněna pouze paměť, ke které se přistupuje, . V případě zásobníku se program určitě ukončí.

Abychom byli úplně přesní, je třeba poznamenat, že takový popis událostí platí pouze pro kompilátory, které kompilují do nativního kódu. Ve spravovaných jazycích má virtuální stroj vlastní zásobník pro spravované programy, jejichž stav je mnohem snazší sledovat a dokonce si můžete dovolit vyhodit programu výjimku, když dojde k přetečení. V jazycích C a C++ s takovým „luxusem“ počítat nemůžete.

Důvody chyby

Co by mohlo vést k tak nepříjemné situaci? Na základě výše popsaného mechanismu je jednou z možností, že existuje příliš mnoho vnořených volání funkcí. Tento scénář je zvláště pravděpodobný při použití rekurze. Nekonečná rekurze (při absenci líného vyhodnocovacího mechanismu) je tímto způsobem přerušena, na rozdíl od , který má někdy užitečné aplikace. S malým množstvím paměti přidělené zásobníku (což je například typické pro mikrokontroléry) však může stačit jednoduchá sekvence volání.

Další možností jsou lokální proměnné, které vyžadují hodně paměti. Mít lokální pole s milionem prvků nebo milionem lokálních proměnných (nikdy nevíte, co se stane) není nejlepší nápad. I jedno volání takové chamtivé funkce může snadno způsobit přetečení zásobníku. Pro získání velkého množství dat je lepší použít dynamické paměťové mechanismy, které vám umožní zvládnout chybu jejího nedostatku.

Dynamická paměť je však poměrně pomalá, pokud jde o alokaci a dealokaci (protože to řeší operační systém), a s přímým přístupem ji musíte ručně alokovat a uvolnit. Paměť na zásobníku je alokována velmi rychle (ve skutečnosti stačí změnit hodnotu jednoho registru), navíc objekty alokované na zásobníku mají destruktory automaticky volány, když se vrátí ovládání funkce a zásobník se vyčistí. Samozřejmě se okamžitě objeví touha získat paměť ze zásobníku. Třetím způsobem přetečení je tedy vlastní alokace paměti programátora na zásobníku. Knihovna C poskytuje funkci alloca speciálně pro tento účel. Je zajímavé poznamenat, že pokud má funkce pro alokaci dynamické paměti malloc své vlastní „dvojče“ pro její uvolnění, volné, pak jej funkce alloca nemá - paměť se uvolní automaticky po návratu ovládání funkce. Snad to situaci jen zkomplikuje – přece jen nebude možné uvolnit paměť před ukončením funkce. I když je podle manuálové stránky "funkce alloca závislá na stroji a kompilátoru; na mnoha systémech je její implementace problematická a chybná; její použití je velmi frivolní a odsuzované" - stále se používá.

Příklady

Jako příklad se podívejme na kód pro rekurzivní vyhledávání souborů umístěný na MSDN:

Void DirSearch(String* sDir) ( try ( // Najít podsložky ve složce, která je předána. 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->Text); int numFiles = f->get_Length(); pro (int j=0; j< numFiles; j++) { listBox1->Položky->Přidat(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox::Show(e->Message); ) )

Tato funkce získá seznam souborů v zadaném adresáři a poté sama zavolá ty prvky seznamu, které jsou náhodou adresáři. Podle toho s dostatečně hlubokým stromem souborový systém, dostaneme přirozený výsledek.

Příklad druhého přístupu, převzatý z otázky "Proč dochází k přetečení zásobníku?" ze stránky s názvem Stack Overflow (stránka je sbírka otázek a odpovědí na jakékoli téma programování, nejen Stack Overflow, jak by se mohlo zdát):

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

Jak vidíte, hlavní funkce alokuje paměť na zásobníku pro pole typu int a float, každé s milionem prvků, což dává dohromady o něco méně než 8 megabajtů. Pokud uvážíte, že ve výchozím nastavení Visual C++ rezervuje pouze 1 megabajt pro zásobník, pak bude odpověď zřejmá.

A zde je příklad převzatý z úložiště GitHub projektu Lightspark Flash player:

DefineSoundTag::DefineSoundTag(/* ... */) ( // ... unsigned int soundDataLength = h.getLength()-7; unsigned char *tmp = (unsigned char *)alloca(soundDataLength); // .. .)

Můžete doufat, že h.getLength()-7 není příliš velké číslo, aby nedošlo k přetečení na dalším řádku. Stojí však čas ušetřený na alokaci paměti za „potenciální“ zhroucení programu?

Sečteno a podtrženo

Přetečení zásobníku je závažná chyba, která nejčastěji postihuje programy obsahující rekurzivní funkce. I když však program takové funkce neobsahuje, stále je možné přetečení z důvodu velké velikosti lokálních proměnných nebo chyby v ručním přidělování paměti na zásobníku. Všechna klasická pravidla zůstávají v platnosti: pokud je na výběr, je lepší zvolit iteraci místo rekurze a také nedělat ruční práci místo kompilátoru.

Bibliografie

• E. Tanenbaum. Počítačová architektura.
• Wikipedie. Přetečení zásobníku.
• Přetečení zásobníku. Přetečení zásobníku C++.

Zásobník je v tomto kontextu poslední v první vyrovnávací paměti, kterou alokujete během provádění vašeho programu. Last, First (LIFO) znamená, že poslední věc, kterou vložíte, je vždy první věc, kterou vrátíte zpět – pokud na hromádku vysypete 2 položky, „A“ a poté „B“, pak první věc, kterou vytáhnete ze zásobníku. bude "B" a další věc bude "A".

Když zavoláte funkci v kódu, další příkaz po volání funkce se uloží do zásobníku a do libovolného paměťového prostoru, který lze voláním funkce přepsat. Zvolená funkce může používat více zásobníku pro své vlastní lokální proměnné. Když to uděláte, uvolní místo lokálních proměnných, které používala, a poté se vrátí k předchozí funkci.

Přetečení zásobníku

Přetečení zásobníku nastane, když v zásobníku použijete více paměti, než váš program zamýšlel použít. Na vestavěných systémech můžete mít pouze 256 bajtů pro zásobník, a pokud každá funkce trvá 32 bajtů, můžete mít pouze 8 volání funkce 2 s funkcí hluboké funkce 1, která volá funkci 3, která volá funkci 4. kdo volá funkci 8, která volá funkci 9, ale funkce 9 přepíše paměť mimo zásobník. To může přepsat paměť, kód atd.

Mnoho programátorů dělá tuto chybu voláním funkce A, která pak volá funkci B, která pak volá funkci C, která pak volá funkci A. Může to fungovat většinu času, ale jen jeden špatný vstup způsobí, že bude kroužit navždy, dokud počítač fails zjistí, že zásobník je plný.

Příčinou jsou také rekurzivní funkce, ale pokud píšete rekurzivně (tj. vaše funkce volá sama sebe), musíte si toho být vědomi a používat statické/globální proměnné, abyste předešli nekonečné rekurzi.

Obvykle operační systém a programovací jazyk, který používáte, spravuje zásobník a je mimo vaše ruce. Měli byste se podívat na váš graf volání (stromová struktura, která z vašeho hlavního bodu ukazuje, co každá funkce volá), abyste viděli, jak hluboká jsou vaše volání funkcí, a identifikovali smyčky a rekurze, které nejsou zamýšleny. Záměrné smyčky a rekurze musí být uměle zkontrolovány, pokud se navzájem volají příliš často.

Kromě správných programovacích postupů, statického a dynamického testování toho v těchto systémech na vysoké úrovni nemůžete moc dělat.

Vestavěné systémy

Ve vestavěném světě, zejména v kódu s vysokou jistotou (automobilový, letecký a kosmický průmysl), provádíte rozsáhlé testování a kontrolu kódu, ale také provádíte následující:

• Zakázat rekurzi a smyčky – zásady a testování souladu
• Udržujte kód a zásobník daleko od sebe (kód ve flashi, zásobník v paměti RAM a nikdy se nebudou shodovat)
• Umístěte ochranné mříže kolem zásobníku - prázdnou oblast paměti, kterou vyplníte magickým číslem (obvykle rutina přerušení, ale existuje mnoho variant) a stovky nebo tisícekrát za sekundu se podíváte na ochranné mříže, abyste vytvořili určitě nebyly přepsány.
• Používejte ochranu paměti (tj. nespouštějte na zásobníku, nečtěte ani nezapisujte přímo za zásobník)
• Přerušení nevolají sekundární funkce – nastavují příznaky, kopírují data a nechají aplikaci, aby se s nimi postarala (jinak byste mohli skončit 8 hluboko ve stromu volání funkcí, mít přerušení a pak mít uvnitř několik dalších funkcí výstup přerušení způsobující házení). Máte několik stromů volání – jeden pro hlavní procesy a jeden pro každé přerušení. Pokud se vaše vyrušení mohou navzájem vyrušit... no, jsou tu draci...

Jazyky a systémy na vysoké úrovni

Ale v jazycích na vysoké úrovni běžících na operačních systémech:

• Snižte ukládání lokálních proměnných (místní proměnné jsou uloženy v zásobníku), i když kompilátory jsou na to docela chytré a někdy dají velké kusy na hromadu, pokud je váš strom volání mělký)
• Vyhněte se nebo přísně omezte rekurzi
• Nepřerušujte své programy příliš daleko do stále menších funkcí – i bez zohlednění lokálních proměnných spotřebuje každé volání funkce až 64 bajtů na zásobníku (32bitový procesor, úspora poloviny registrů procesoru, příznaky atd.).
• Udržujte strom volání mělký (podobný popisu výše)

webové servery

Záleží na sandboxu, který máte, zda můžete zásobník ovládat nebo dokonce vidět. Je pravděpodobné, že můžete pracovat s webovými servery jako s jakýmkoli jiným jazykem a operačním systémem na vysoké úrovni – je to z velké části mimo vaše ruce, ale zkontrolujte, jaký jazyk a serverový zásobník používáte. Můžete například rozdělit zásobník na vašem serveru SQL.

Informix® DataBlade™ API Programmer's Guide je k dispozici ke stažení. Část "Správa prostoru zásobníku" popisuje vytváření uživatelsky definovaných funkcí (UDR). Tento článek poskytuje další informace a tipy pro ladění.

Následující informace platí bez ohledu na to, zda UDR běží na uživatelem definovaném virtuálním procesoru (VP) nebo na VP CPU. Zásobník podprocesu lze přesunout do uživatelem definovaného virtuálního procesoru bezprostředně před provedením UDR.

Jaká velikost zásobníku je přidělena pro UDR?

Velikost zásobníku dostupného pro UDR závisí na tom, jak byl UDR vytvořen:

pomocí modifikátoru STACK, který umožňuje UDR používat svůj speciálně přidělený zásobník,

bez modifikátoru STACK, což znamená, že UDR bude sdílet zásobník přidělený serverem s vláknem, které odesílá požadavek. Velikost zásobníku bude v tomto případě určena hodnotou parametru STACKSIZE v konfiguračním souboru onconfig.

Modifikátor STACK

Příkazy CREATE PROCEDURE nebo CREATE FUNCTION mají volitelný modifikátor STACK, který vám umožňuje zadat množství místa v zásobníku v bajtech, které je nutné ke spuštění UDR.

Pokud při vytváření UDR použijete modifikátor STACK, server alokuje a uvolní místo v zásobníku pokaždé, když se UDR spustí. Skutečná dostupná velikost se rovná hodnotě STACK v bajtech mínus určitá režie v závislosti na počtu argumentů funkce.

Pokud je hodnota STACK menší než parametr STACKSIZE v souboru onconfig (viz další část), bude velikost zásobníku přidělená pro UDR automaticky zaokrouhlena nahoru na hodnotu STACKSIZE.

Konfigurační parametr STACKSIZE

Konfigurační soubor onconfig obsahuje parametr STACKSIZE, který určuje výchozí velikost zásobníku pro uživatelská vlákna.

Pokud při vytváření UDR nezadáte STACK, server nepřidělí další místo v zásobníku pro provedení tohoto UDR. Místo toho UDR používá vyhrazený prostor zásobníku k provedení požadavku. Dostupná velikost zásobníku bude záviset na režii provádění funkce na úrovni SQL.

Zásobník na vlákno je přidělen jednou pro konkrétní vlákno, které provádí požadavek. Výkon je lepší, když UDR sdílí jeden zásobník s vláknem, protože server neplýtvá prostředky na přidělování dalšího zásobníku pro každé volání UDR. Na druhou stranu, pokud se velikost zásobníku používaná UDR blíží hodnotě STACKSIZE, může to způsobit přetečení zásobníku při volání funkce jako součást komplexního dotazu (v takovém případě bude pro provádění UDR k dispozici méně místa v zásobníku).

Pamatujte, že byste neměli nastavovat hodnotu STACKSIZE příliš vysoko, protože to ovlivní všechna uživatelská vlákna.

Kdy je nutné kontrolovat velikost zásobníku?

YMusíte spravovat prostor zásobníku, pokud UDR provádí rekurzivní volání nebo pokud UDR vyžaduje více místa v zásobníku, než je standardně dostupné v zásobníku podprocesu požadavku (STACKSIZE).

Existují dva způsoby, jak zvýšit zásobník pro provádění UDR:

Při vytváření UDR zadejte modifikátor STACK.

Pomocí mi_call() provádějte rekurzivní volání (příklad naleznete v Příručce programátora rozhraní API Informix DataBlade).

Pokud neurčíte velikost pomocí STACK a pokud nepoužijete mi_call() ke zvýšení aktuálního zásobníku a pokud UDR provede něco, co vyžaduje hodně místa v zásobníku, způsobí to přetečení zásobníku.

Všimněte si, že některé funkce mi_* přidávají nový segment zásobníku pro vlastní spuštění. Tyto segmenty se uvolní při návratu k volající funkci UDR.

Co dělat, když se něco pokazí?

Monitorování využití zásobníku

Účelem monitorování je identifikovat konkrétní UDR, které způsobuje přetečení zásobníku, abyste mohli změnit hodnotu STACK specificky pro tento konkrétní UDR.

Monitorování využití zásobníku pomocí příkazu "onstat -g sts".

Monitorování relace provádějící SQL dotaz pomocí "onstat -g ses session_id"

Po identifikaci dotazu SQL, který končí přetečením zásobníku, byste měli určit využití zásobníku samostatným spuštěním dotazů UDR, které jsou součástí původního dotazu.

Hodnotu STACK pro UDR můžete nastavit dynamicky. Například:

změnit funkci MyFoo (lvarchar,lvarchar) pomocí (přidat zásobník=131072);

Po změně hodnoty STACK byste měli otestovat původní požadavek, abyste se ujistili, že je nyní stabilní.

Zvětšete STACKSIZE

Případně zkuste zvýšit hodnotu STACKSIZE. Zkontrolujte, zda se tím problém vyřešil. (Nezapomeňte později vrátit starou hodnotu).

Pokud nepomůže zvýšení STACKSIZE, problém je pravděpodobně poškození paměti. Zde je několik návrhů:

Povolit kontrolu čmáranic a paměťového fondu. V části "Problémy ladění" v článku alokace paměti pro UDR je vysvětleno, jak to provést.

Znovu zvažte použití mi_lvarchar . Zvláštní pozornost je třeba věnovat místům, kde je mi_lvarchar předán funkci, která očekává, že jako argument obdrží řetězec zakončený nulou.

Snižte počet CPU (nebo uživatelských) VP na jeden, abyste problém reprodukovali rychleji.

mi_print_stack() -- Solaris

Informix Dynamic Server for Solaris OS obsahuje funkci mi_print_stack(), kterou lze volat v UDR. Ve výchozím nastavení tato funkce uloží rámeček zásobníku do následujícího souboru:

/tmp/default.stack

Název výstupního souboru nelze změnit, ale můžete změnit jeho umístění změnou hodnoty proměnné prostředí DBTEMP. Ujistěte se, že do adresáře $DBTEMP může uživatel informix zapisovat. Jakékoli chyby zjištěné při provádění mi_print_stack() jsou hlášeny $MSGPATH.

Tato funkce je dostupná pouze pro OC Solaris.

Glosář

Termíny a zkratky použité v tomto článku:

UDR	Uživatelsky definovaná rutina
V.P.	Virtuální procesor

Tento článek opět ukazuje, že jakýkoli soubor bezpečnostních opatření musí pokrývat všechny fáze implementace: vývoj, nasazení, správu systému a samozřejmě organizační opatření. V informačních systémech je hlavní bezpečnostní hrozbou „lidský faktor“ (včetně uživatelů). Tento soubor opatření musí být rozumný a vyvážený: nedává smysl a je nepravděpodobné, že bude přidělen dostatek finančních prostředků na organizaci ochrany, která převyšuje náklady na samotná data.

Úvod

1C:Enterprise je nejběžnějším účetním systémem v Rusku, ale navzdory tomu až do verze 8.0 jeho vývojáři věnovali velmi malou pozornost bezpečnostním problémům. V zásadě to bylo samozřejmě diktováno cenovým výklenkem produktu a zaměřením na malé podniky, kde nejsou kvalifikovaní IT specialisté, a případné náklady na nasazení a údržbu zabezpečeného systému by byly pro podnik neúměrně drahé. S vydáním verze 8.0 se důraz musel změnit: náklady na řešení výrazně vzrostly, systém se stal mnohem škálovatelnějším a flexibilnějším - požadavky se výrazně změnily. Zda se systém stal dostatečně spolehlivým a bezpečným, je velmi individuální otázka. Hlavní informační systém moderního podniku musí splňovat minimálně tyto bezpečnostní požadavky:

• Poměrně nízká pravděpodobnost selhání systému z interních důvodů.
• Spolehlivá autorizace uživatele a ochrana dat před nesprávnými akcemi.
• Efektivní systém pro přidělování uživatelských práv.
• Online systém zálohování a obnovy v případě selhání.

Splňují řešení založená na 1C:Enterprise 8.0 tyto požadavky? Jednoznačná odpověď neexistuje. I přes významné změny v systému kontroly přístupu zůstává mnoho nevyřešených problémů. V závislosti na tom, jak je systém navržen a konfigurován, nemusí být všechny tyto požadavky splněny nebo splněny v dostatečné míře pro danou implementaci, nicméně stojí za to věnovat pozornost (a to je významný důsledek „mládí“ platformy ), že pro plné splnění uvedených podmínek je nutné vyvinout skutečně herkulovské úsilí.

Tento článek je určen vývojářům a implementátorům řešení na platformě 1C:Enterprise a také systémovým administrátorům organizací, kde se 1C:Enterprise používá, a popisuje některé aspekty vývoje a konfigurace klient-server verze systému od začátku. z pohledu organizace informační bezpečnost. Tento článek nelze použít jako náhradu za dokumentaci, pouze upozorňuje na některé body, které v něm dosud nebyly zohledněny. A samozřejmě ani tento článek, ani veškerá dokumentace nebudou schopny reflektovat složitost problému budování bezpečného informačního systému, který zároveň musí splňovat protichůdné požadavky na bezpečnost, výkon, pohodlí a funkčnost.

Klasifikace a terminologie

Klíčovým předmětem úvahy v článku jsou informační hrozby.

Informační hrozba– možnost situace, kdy dojde k neoprávněnému čtení, kopírování, změně nebo blokování dat.

A na základě této definice článek klasifikuje informační hrozby následovně:

• Neoprávněné zničení dat
• Neoprávněná změna údajů
• Neoprávněné kopírování dat
• Neoprávněné čtení dat
• Nedostupnost dat

Všechny hrozby jsou rozděleny na úmyslné a neúmyslné. Nazveme realizovanou informační hrozbu incident. Vlastnosti systému jsou:

Zranitelnosti– vlastnosti vedoucí k incidentům Ochranná opatření– funkce, které blokují možnost incidentu

V zásadě se berou v úvahu pouze případy, jejichž pravděpodobnost je způsobena použitím technologické platformy 1C: Enterprise 8.0 ve verzi klient-server (dále v případech, kdy to není v rozporu s významem jednoduše 1C nebo 1C 8.0) . Definujme následující hlavní role ve vztahu k používání systému:

• Operátoři– uživatelé, kteří mají práva prohlížet a měnit data omezená rolí aplikace, ale nemají administrativní funkce
• Správci systému– uživatelé, kteří mají administrátorská práva v systému, včetně administrátorských práv v operačních systémech aplikačního serveru a MS SQL serveru, administrátorských práv v MS SQL atd.
• Správci informační bezpečnosti– uživatelé, kterým jsou delegovány určité administrativní funkce v informační základně 1C (jako je přidávání uživatelů, testování a opravy, zálohování, nastavení aplikačního řešení atd.)
• Vývojáři systému– uživatelé vyvíjející aplikační řešení. Obecně nemusí mít přístup k pracovnímu systému.
• Osoby, které nemají přímý přístup do systému– uživatelé, kteří nemají delegovaná přístupová práva k 1C, ale kteří mohou v té či oné míře ovlivňovat chod systému (obvykle se jedná o všechny uživatele stejné domény Active Directory, ve které je systém nainstalován). Tato kategorie je určena především k identifikaci potenciálně nebezpečných subjektů v systému.
• Automatizované administrativní skripty– programy, kterým jsou delegovány určité funkce, určené k automatickému provádění určitých akcí (například import-export dat)

Zde je třeba poznamenat dva body: za prvé je tato klasifikace velmi hrubá a nezohledňuje rozdělení v rámci každé skupiny - takové rozdělení bude vytvořeno pro některé konkrétní případy a za druhé se předpokládá, že jiné osoby nemohou operaci ovlivnit systému, který musí být zajištěn prostředky mimo 1C.

Jakýkoli bezpečnostní systém musí být navržen s ohledem na proveditelnost a náklady na vlastnictví. Obecně platí, že při vývoji a implementaci informačního systému je nutné, aby cena ochrany systému odpovídala:

• hodnotu chráněných informací;
• náklady na vytvoření incidentu (v případě úmyslného ohrožení);
• finanční rizika v případě incidentu

Je nesmyslné a škodlivé organizovat obranu, která je mnohem dražší než posuzování její finanční efektivity. Existuje několik metod pro hodnocení rizik ztráty informací, ale nejsou diskutovány v rámci tohoto článku. Dalším důležitým aspektem je udržení rovnováhy často protichůdných požadavků na informační bezpečnost, výkon systému, pohodlí a snadnost práce se systémem, rychlost vývoje a implementace a další požadavky na podnikové informační systémy.

Hlavní rysy mechanismu informační bezpečnosti systému

1C:Enterprise 8.0 se dodává ve dvou verzích: souborová a klient-server. Verzi souboru nelze považovat za zajištění informační bezpečnosti systému z následujících důvodů:

• Data a konfigurace jsou uloženy v souboru, který je čitelný a zapisovatelný pro všechny uživatele systému.
• Jak bude ukázáno níže, autorizaci systému lze velmi snadno obejít.
• Integritu systému zajišťuje pouze jádro klientské části.

Ve verzi klient-server se k ukládání informací používá MS SQL Server, který poskytuje:

• Spolehlivější úložiště dat.
• Izolace souborů z přímého přístupu.
• Pokročilejší transakční a zamykací mechanismy.

Navzdory významným rozdílům mezi souborovými a klient-server verzemi systému mají jednotné schéma řízení přístupu na úrovni aplikačního řešení, které poskytuje následující možnosti:

• Autorizace uživatele pomocí hesla uvedeného v 1C.
• Autorizace uživatele na základě aktuálního uživatele Windows.
• Přidělování rolí uživatelům systému.
• Omezení administrativních funkcí podle rolí.
• Přiřazení dostupných rozhraní podle rolí.
• Omezení přístupu k objektům metadat podle role.
• Omezení přístupu k detailům objektu podle role.
• Omezení přístupu k datovým objektům pomocí rolí a parametrů relace.
• Omezení interaktivního přístupu k datům a spustitelným modulům.
• Některá omezení spouštění kódu.

Obecně je použité schéma přístupu k datům zcela typické pro informační systémy této úrovně. Ve vztahu k této implementaci třívrstvé architektury klient-server však existuje několik základních aspektů, které vedou k relativně velkému počtu zranitelností:

1. Může platit velký počet fází zpracování dat a v každé fázi mohou platit jiná pravidla pro přístup k objektům.

   Poněkud zjednodušené schéma etap zpracování dat, které jsou významné z hlediska bezpečnosti, je na obr. 1. Obr. Obecné pravidlo pro 1C je snížit omezení při přechodu dolů v tomto schématu, a proto použít zranitelnost na jednom z horní úrovně může narušit systém na všech úrovních.

2. Nedostatečně zavedené postupy pro sledování přenášených dat při přechodu z úrovně na úroveň.

   Bohužel ne všechny vnitřní mechanismy systému jsou dokonale odladěny, zejména u neinteraktivních mechanismů, jejichž odlaďování je vždy na jednu stranu pracnější, ale na druhou stranu zodpovědnější. Tato „nemoc“ není problém výhradně s 1C; nachází se v mnoha serverových produktech od většiny prodejců. Teprve v posledních letech se pozornost k těmto problémům výrazně zvýšila.

3. Nedostatečně vysoká průměrná kvalifikace vývojářů a systémových administrátorů, zděděná z předchozí verze.

   Produkty řady 1C:Enterprise byly zpočátku zaměřeny na snadný vývoj a podporu a na práci v malých organizacích, takže není divu, že se historicky vyvinulo, že významná část „vývojářů“ aplikačních řešení a „správců“ systémy nemají dostatečné znalosti a dovednosti pro práci s mnohem složitějším produktem, kterým je verze 8.0. Problém ještě zhoršuje praxe franšízových společností, která učí „v boji“ na úkor klientů, aniž by k této problematice systematicky přistupovala. Je třeba vzdát hold společnosti 1C, že v posledních letech se tato situace postupně napravovala: seriózní franšízové ​​společnosti začaly přistupovat zodpovědněji k problému výběru a školení personálu, úrovně podpory informačních technologií ze strany společnost 1C výrazně vzrostla, objevily se certifikační programy zaměřené na vysokou úroveň služeb; ale situaci nelze napravit okamžitě, takže tento faktor by měl být zohledněn při analýze bezpečnosti systému.

4. Platforma je poměrně mladá.

   Mezi produkty podobného zaměření a účelu použití se jedná o jedno z nejmladších řešení. Funkčnost platformy byla víceméně zavedena před necelým rokem. Zároveň se každé vydání platformy počínaje 8.0.10 (v tomto vydání byly implementovány téměř všechny současné schopnosti systému) stalo výrazně stabilnější než předchozí. Funkčnost standardních aplikačních řešení stále roste mílovými kroky, přestože je využívána pouze polovina možností platformy. Samozřejmě v takových podmínkách můžeme mluvit o stabilitě spíše podmíněně, ale obecně je třeba uznat, že v mnoha ohledech jsou řešení na platformě 1C 8.0 výrazně napřed ve funkčnosti a výkonu (a často ve stabilitě) podobných řešení na 1C. Platforma 7.7.

Systém (a případně i standardní aplikační řešení) je tedy nasazen v podniku a instalován na počítačích. V první řadě je potřeba vytvořit prostředí, ve kterém má nastavení zabezpečení 1C smysl, a k tomu je třeba ho nakonfigurovat tak, aby byl naplněn předpoklad, že zabezpečení systému je výrazně ovlivněno nastavením systému.

Dodržujte obecná pravidla pro nastavení zabezpečení.

O nějaké informační bezpečnosti systému nemůže být řeč, pokud nejsou dodržovány základní principy tvorby bezpečných systémů. Ujistěte se, že jsou splněny alespoň následující podmínky:

• Přístup k serverům je fyzicky omezen a je zajištěn jejich nepřetržitý provoz:
  • serverové zařízení splňuje požadavky na spolehlivost, byla upravena výměna vadného serverového zařízení, pro zvláště kritické oblasti se používají schémata s duplicitním hardwarem (RAID, napájení z více zdrojů, více komunikačních kanálů atd.);
  • servery jsou umístěny v uzamčené místnosti a tato místnost je otevřena pouze po dobu práce, kterou nelze provádět na dálku;
  • Pouze jedna nebo dvě osoby mají právo otevřít serverovnu, v případě nouze je vyvinut systém upozornění pro odpovědné osoby;
  • je zajištěno nepřetržité napájení serverů
  • jsou zajištěny normální klimatické podmínky provozu zařízení;
  • v serverovně je požární poplach, nehrozí zaplavení (zejména v prvním a posledním patře);
• Nastavení síťové a informační infrastruktury podniku jsou správně dokončena:
  • Firewally jsou nainstalovány a konfigurovány na všech serverech;
  • všichni uživatelé a počítače jsou v síti autorizováni, hesla jsou dostatečně složitá, že je nelze uhodnout;
  • provozovatelé systému mají dostatek práv, aby s ním mohli normálně pracovat, ale nemají práva na administrativní úkony;
  • antivirové nástroje jsou nainstalovány a povoleny na všech počítačích v síti;
  • Je žádoucí, aby uživatelé (kromě správců sítě) neměli administrátorská práva na klientských pracovních stanicích;
  • přístup k internetu a vyměnitelným paměťovým médiím by měl být regulován a omezen;
  • musí být nakonfigurováno systémové auditování bezpečnostních událostí;
• Hlavní organizační problémy byly vyřešeny:
  • uživatelé mají dostatečnou kvalifikaci pro práci s 1C a hardwarem;
  • uživatelé jsou upozorněni na odpovědnost za porušení provozního řádu;
  • pro každý věcný prvek informačního systému jsou určeny finančně odpovědné osoby;
  • všechny systémové jednotky jsou utěsněny a uzavřeny;
  • Zvláštní pozornost věnujte instruování a dozoru u uklízečů, stavebních dělníků a elektrikářů. Tyto osoby mohou z nedbalosti způsobit škodu, která není srovnatelná s úmyslnou škodou způsobenou bezohledným uživatelem systému.

Pozornost! Tento výčet není vyčerpávající, popisuje pouze to, co často chybí při nasazování jakéhokoli poměrně složitého a drahého informačního systému!

• MS SQL Server, aplikační server a klientská část běží na různých počítačích, serverové aplikace běží pod právy speciálně vytvořených uživatelů Windows;
• Pro MS SQL Server
  • je nastaven režim smíšené autorizace
  • Uživatelé MS SQL uvedení v roli serveradmin se neúčastní práce 1C,
  • pro každý IB 1C byl vytvořen samostatný uživatel MS SQL, který nemá privilegovaný přístup k serveru,
  • uživatel MS SQL jednoho IS nemá přístup k jinému IS;
• Uživatelé nemají přímý přístup k souborům aplikačního serveru a MS SQL serveru
• Pracovní stanice operátora jsou vybaveny Windows 2000/XP (ne Windows 95/98/Me)

Nezanedbávejte doporučení vývojářů systému a čtení dokumentace. Důležité materiály k nastavení systému jsou publikovány na discích ITS v sekci „Metodická doporučení“. Věnujte zvláštní pozornost následujícím článkům:

1. Vlastnosti aplikací pracujících se serverem 1C:Enterprise
2. Umístění dat 1C:Enterprise 8.0
3. Aktualizace 1C:Enterprise 8.0 uživateli Microsoft Windows bez administrátorských práv
4. Úprava seznamu uživatelů jménem uživatele, který nemá práva správce
5. Konfigurace nastavení brány firewall systému Windows XP SP2 pro spuštění SQL Server 2000 a SQL Server Desktop Engine (MSDE)
6. Konfigurace parametrů COM+ Windows XP SP2 pro spuštění serveru 1C:Enterprise 8.0
7. Konfigurace nastavení brány firewall systému Windows XP SP2 pro server 1C:Enterprise 8.0
8. Konfigurace nastavení brány firewall systému Windows XP SP2 pro Správce licencí HASP
9. Vytvoření zálohy informační základna pomocí SQL Server 2000
10. Problémy s instalací a konfigurací 1C:Enterprise 8.0 ve verzi "klient-server".(jeden z nejdůležitějších článků)
11. Zvláštnosti Nastavení Windows Server 2003 při instalaci serveru 1C:Enterprise 8.0
12. Regulace přístupu uživatelů k informační základně ve verzi klient-server(jeden z nejdůležitějších článků)
13. Server 1C: Enterprise a SQL server
14. Podrobný postup instalace pro 1C:Enterprise 8.0 ve verzi "klient-server".(jeden z nejdůležitějších článků)
15. Použití vestavěného jazyka na serveru 1C:Enterprise

Při čtení dokumentace však buďte kritickí k obdrženým informacím, například článek „Problémy s instalací a konfigurací 1C: Enterprise 8.0 ve verzi klient-server“ přesně nepopisuje práva, která jsou vyžadována pro uživatele USER1CV8SERVER. Budou zde odkazy na níže uvedený seznam, například [ITS1] znamená článek „Funkce aplikací pracujících se serverem 1C:Enterprise“. Všechny odkazy na články jsou uvedeny na nejnovější vydání ITS v době psaní (leden 2006)

Využijte možnosti autorizace v kombinaci s autorizací Windows pro uživatele

Ze dvou možných režimů autorizace uživatele: vestavěný 1C a kombinovaný s autorizací OS Windows, pokud je to možné, byste měli zvolit kombinovanou autorizaci. To umožní uživatelům, aby nebyli zmateni více hesly při práci, ale nesníží to úroveň zabezpečení systému. I pro uživatele, kteří používají pouze autorizaci Windows, je však velmi vhodné nastavit heslo při jeho vytváření a teprve poté tomuto uživateli zakázat autorizaci 1C. Pro zajištění obnovy systému v případě zničení struktury Active Directory je nutné ponechat alespoň jednoho uživatele, který se může do systému přihlásit pomocí 1C autorizace.

Při vytváření rolí aplikačního řešení nepřidávejte práva „do rezervy“

Každá role aplikačního řešení musí odrážet minimální požadovanou sadu práv k provádění akcí definovaných touto rolí. Některé role však nelze používat samostatně. Například pro interaktivní spouštění vnější ošetření Můžete vytvořit samostatnou roli a přidat ji všem uživatelům, kteří potřebují používat externí zpracování.

Pravidelně kontrolujte protokoly a protokoly provozu systému

Pokud je to možné, regulujte a automatizujte prohlížení protokolů a protokolů provozu systému. Při správné konfiguraci a pravidelné kontrole protokolů (filtrování pouze podle důležitých událostí) lze neoprávněné akce včas odhalit nebo jim dokonce během přípravné fáze zabránit.

Některé funkce verze klient-server

Tato část popisuje některé provozní funkce volby klient-server a jejich dopad na zabezpečení. Pro snadnější čtení se používají následující zápisy:

Pozornost! popis zranitelnosti

Ukládání informací, které řídí přístup do systému

Ukládání seznamu uživatelů zabezpečení informací

Veškeré informace o seznamu uživatelů tohoto informačního zabezpečení a rolích, které jsou v něm dostupné, jsou uloženy v tabulce Params v databázi MS SQL (viz [ITS2]). Při pohledu na strukturu a obsah této tabulky je zřejmé, že všechny informace o uživateli jsou uloženy v záznamu s hodnotou pole Název souboru „users.usr“.

Vzhledem k tomu, že předpokládáme, že uživatelé nemají přístup k databázi MS SQL, tuto skutečnost sám o sobě nemůže útočník využít, pokud je však možné spustit kód v MS SQL, „otevře se tím dveře“ k získání any(! ) přístup z 1C . Stejný mechanismus (s drobnými změnami) lze použít i v souborové verzi systému, což s přihlédnutím k vlastnostem souborové verze zcela vylučuje její použitelnost při budování bezpečných systémů.

Doporučení: V tuto chvíli neexistuje žádný způsob, jak aplikaci před takovými změnami zcela ochránit, kromě použití triggerů na úrovni MS SQL Server, které na druhou stranu mohou způsobit problémy při aktualizaci verze platformy nebo změně seznamu uživatelů. Ke sledování takových změn můžete použít protokol 1C (dávat pozor na „podezřelá“ přihlášení v režimu konfigurátoru, aniž byste specifikovali uživatele) nebo nechat SQL Profiler neustále spuštěný (což bude mít extrémně negativní dopad na výkon systému) nebo nakonfigurovat upozornění mechanismus (nejspíše společně pomocí spouštěčů)

Ukládání informací o seznamu IS na serveru

Pro každý aplikační server 1C jsou uloženy informace o seznamu databází MS SQL, které jsou k němu připojeny. Každá infobáze využívá k provozu svůj vlastní připojovací řetězec z aplikačního serveru a MS SQL serveru. Informace o infobázích registrovaných na aplikačním serveru jsou spolu s připojovacími řetězci uloženy v souboru srvrib.lst, který je umístěn na serveru v adresáři<Общие данные приложений>/1C/1Cv8 (například C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst). Pro každý informační bezpečnostní systém je uložen kompletní připojovací řetězec včetně uživatelského hesla MS SQL při použití smíšeného modelu autorizace MS SQL. Právě přítomnost tohoto souboru umožňuje obávat se neoprávněného přístupu k databázi MS SQL, a pokud je v rozporu s doporučeními pro přístup alespoň k jedné databázi použit privilegovaný uživatel (například „sa“), pak v kromě ohrožení jedné informační bezpečnosti existuje ohrožení celého systému pomocí MS SQL.

Je zajímavé poznamenat, že použití smíšené autorizace a autorizace Windows na serveru MS SQL vede k různým typům problémů při získávání přístupu k danému souboru. Klíčové negativní vlastnosti autorizace Windows tedy budou:

• Provoz veškeré informační bezpečnosti na aplikačním serveru a na MS SQL serveru pod jednou sadou práv (s největší pravděpodobností redundantní)
• Z procesu aplikačního serveru 1C (nebo obecně od uživatele USER1CV8SERVER nebo jeho ekvivalentu) bez zadání hesla se můžete snadno připojit k libovolnému zabezpečení informací bez zadání hesla.

Na druhou stranu může být pro útočníka obtížnější spustit libovolný kód z kontextu uživatele USER1CV8SERVER než získat zadaný soubor. Mimochodem, přítomnost takového souboru je dalším argumentem pro distribuci funkcí serveru na různé počítače.

Doporučení: Soubor srvrib.lst by měl být přístupný pouze procesu serveru. Nezapomeňte nakonfigurovat auditování pro změnu tohoto souboru.

Bohužel standardně tento soubor není téměř chráněn před čtením, s čímž je nutné počítat při nasazení systému. Ideální možností by bylo, aby aplikační server zabránil čtení a zápisu tohoto souboru za běhu (včetně čtení a zápisu uživatelskými připojeními běžícími na tomto serveru).

Nedostatek autorizace při vytváření zabezpečení informací na serveru

Pozornost! Chyba nedostatku autorizace byla opravena ve verzi 8.0.14 platformy 1C:Enterprise. V této verzi se objevil koncept „1C:Enterprise Server Administrator“, ale pokud je na serveru uveden seznam správců, systém funguje tak, jak je popsáno níže, takže na tuto možnou funkci nezapomeňte.

Pravděpodobně největší zranitelností z této části je schopnost téměř neomezeně přidávat zabezpečení informací na aplikační server, v důsledku čehož každý uživatel, který získá přístup k připojení k aplikačnímu serveru, automaticky získá možnost spouštět na aplikačním serveru libovolný kód. . Podívejme se na to na příkladu.

Systém musí být nainstalován následovně

• MS SQL Server 2000 (například název sítě SRV1)
• Server 1C:Enterprise 8.0 (název sítě SRV2)
• Klientská část 1C:Enterprise 8.0 (název sítě WS)

Předpokládá se, že uživatel (dále jen UŽIVATEL) pracující na WS má alespoň minimální přístup k některému ze systémů zabezpečení informací registrovaných na SRV2, ale nemá privilegovaný přístup k SRV1 a SRV2. Obecně platí, že kombinace funkcí uvedených počítačů nemá na situaci vliv. Systém byl nakonfigurován s ohledem na doporučení v dokumentaci a na discích ITS. Situace je znázorněna na Obr. 2.

• nakonfigurujte zabezpečení COM+ na aplikačním serveru tak, aby pouze uživatelé 1C měli právo se připojit k procesu aplikačního serveru (další podrobnosti [ITS12]);
• soubor srvrib.lst musí být pro uživatele USER1CV8SERVER pouze pro čtení (pro přidání nového zabezpečení informací na server dočasně povolte zápis);
• Pro připojení k MS SQL použijte pouze protokol TCP/IP, v tomto případě můžete:
  • omezit připojení pomocí firewallu;
  • nakonfigurujte použití nestandardního portu TCP, který bude komplikovat připojení „outsiderů“ IB 1C;
  • používat šifrování přenášených dat mezi aplikačním serverem a SQL serverem;
• nakonfigurovat firewall serveru tak, aby nebylo možné používat MS SQL servery třetích stran;
• používat nástroje zabezpečení intranetu k vyloučení možnosti výskytu neoprávněného počítače v místní síti (IPSec, zásady zabezpečení skupiny, firewally atd.);
• Za žádných okolností neudělujte uživateli USER1CV8SERVER administrátorská práva na aplikačním serveru.

Pomocí kódu běžícího na serveru

Při použití klient-server verze 1C může vývojář distribuovat spouštění kódu mezi klientem a aplikačním serverem. Aby se kód (procedura nebo funkce) spouštěl pouze na serveru, je nutné jej umístit do obecného modulu, kterému je nastavena vlastnost „Server“ a v případě, že je spouštění modulu povoleno nejen na serveru, umístěte kód do omezené sekce „#If Server“:

#If Server Then
Function OnServer(Param1, Param2 = 0) Export // Tato funkce se i přes svou jednoduchost spustí na serveru
Param1 = Param1 + 12;
Návrat Param1;
EndFunction
#EndIf

Při použití kódu, který běží na serveru, musíte vzít v úvahu, že:

• kód běží s právy USER1CV8SERVER na aplikačním serveru (k dispozici jsou objekty COM a soubory serveru);
• všechny uživatelské relace jsou prováděny jednou instancí služby, takže například přetečení zásobníku na serveru způsobí odpojení všech aktivních uživatelů;
• ladění modulů serveru je obtížné (například nemůžete nastavit bod přerušení v ladicím programu), ale musí být provedeno;
• přenos řízení z klienta na aplikační server a zpět může vyžadovat značné zdroje s velkými objemy přenášených parametrů;
• použití interaktivních nástrojů (formuláře, tabulkové dokumenty, dialogová okna), externí reporty a zpracování v kódu na aplikačním serveru není možné;
• použití globálních proměnných (proměnné aplikačního modulu deklarované s označením "Export") není povoleno;

Další podrobnosti naleznete v [ITS15] a dalších článcích ITS.

Aplikační server musí mít speciální požadavky na spolehlivost. Ve správně sestaveném systému klient-server musí být splněny následující podmínky:

• žádné akce klientské aplikace by neměly přerušit chod serveru (kromě administrativních případů);
• server nemůže spustit programový kód přijatý od klienta;
• zdroje musí být rozděleny „spravedlivě“. připojení klientů, zajištění dostupnosti serveru bez ohledu na aktuální zatížení;
• při absenci blokování dat by klientská připojení neměla vzájemně ovlivňovat práci ostatních;
• ne na serveru uživatelské rozhraní, ale musí být vyvinuty nástroje pro monitorování a protokolování;

Obecně je systém 1C postaven tak, aby se přiblížil těmto požadavkům (například není možné vynutit provedení externího zpracování na serveru), ale stále existuje několik nepříjemných funkcí, proto:

Doporučení: Při vývoji runtime serveru se doporučuje dodržet zásadu minimálního rozhraní. Tito. počet vstupů do serverových modulů z klientské aplikace by měl být velmi omezen a parametry by měly být přísně regulovány. Doporučení: Při příjmu parametrů procedur a funkcí na server je nutné parametry validovat (zkontrolovat, zda parametry odpovídají očekávanému typu a rozsahu hodnot). To se u standardních řešení nedělá, ale je velmi žádoucí zavést povinné ověřování ve vašem vlastním vývoji. Doporučení: Při generování textu požadavku (a zejména parametru příkazu Run) na straně serveru nepoužívejte řetězce přijaté z klientské aplikace.

Obecným doporučením by bylo seznámit se s principy bezpečného budování web-databázové aplikace a fungují na podobných principech. Podobnosti jsou skutečně značné: za prvé, stejně jako webová aplikace, je aplikační server mezivrstvou mezi databází a uživatelským rozhraním (hlavní rozdíl je v tom, že webový server tvoří uživatelské rozhraní); za druhé, z bezpečnostního hlediska nemůžete důvěřovat datům přijatým od klienta, protože je možné spustit externí reporty a zpracování.

Předávání parametrů

Předávání parametrů funkci (proceduře) prováděné na serveru je poměrně delikátní záležitost. Důvodem je především nutnost jejich přenosu mezi aplikačním serverem a klientskými procesy. Při přechodu řízení ze strany klienta na stranu serveru jsou všechny přenášené parametry serializovány, přeneseny na server, kde jsou „rozbaleny“ a použity. Při přechodu ze strany serveru na stranu klienta je proces obrácený. Zde je třeba poznamenat, že toto schéma správně zpracovává předávání parametrů odkazem a hodnotou. Při předávání parametrů platí následující omezení:

• Mezi klientem a serverem (v obou směrech) lze přenášet pouze neměnitelné hodnoty (tj. jejichž hodnoty nelze měnit): primitivní typy, odkazy, univerzální kolekce, systémové hodnoty výčtu, ukládání hodnot. Pokud se pokusíte předat něco jiného, ​​klientská aplikace se zhroutí (i když se server pokusí předat nesprávný parametr).
• Při předávání parametrů se nedoporučuje přenášet velké množství dat (například řetězce delší než 1 milion znaků), může to negativně ovlivnit výkon serveru.
• Nemůžete předávat parametry obsahující cyklický odkaz ze serveru na klienta a zpět. Pokud se pokusíte předat takový parametr, klientská aplikace se zhroutí (i když se server pokusí předat nesprávný parametr).
• Nedoporučuje se přenášet velmi složité kolekce dat. Když se pokusíte předat parametr s velmi velkou úrovní vnoření, server se zhroutí (!).

Pozornost! Nejotravnější funkcí je v současnosti asi chyba při předávání složitých kolekcí hodnot. Takže například kód: Úroveň vnoření = 1250;
M = Nové pole;
PassedParameter = M;
Pro účet = 1 podle úrovně vnořovacího cyklu
MVInt = Nové pole;
M.Add(MVInt);
M = MVint;
EndCycle;
ServerFunction(PassedParameter);

Vede k nouzovému zastavení serveru s odpojením všech uživatelů, k čemuž dochází dříve, než je řízení přeneseno do kódu ve vestavěném jazyce.

Používání nebezpečných funkcí na straně serveru.

Ne všechny vestavěné jazykové nástroje lze použít v kódu spouštěném na aplikačním serveru, ale i mezi dostupnými nástroji existuje mnoho „problematických“ konstrukcí, které lze zhruba klasifikovat takto:

• schopný poskytnout možnost spouštět kód, který není obsažen v konfiguraci (skupina "Spuštění kódu")
• schopný poskytnout klientské aplikaci informace o souboru a operační systém uživatel nebo provádět akce nesouvisející s prací s daty („Porušení práv“)
• může způsobit zhroucení serveru nebo použít velmi velké prostředky (skupina „Zhroucení serveru“)
• schopný způsobit selhání klienta (skupina selhání klienta) – tento typ není uvažován. Příklad: předání měnitelné hodnoty serveru.
• chyby v programovacích algoritmech (nekonečné smyčky, neomezená rekurze atd.) („chyby programování“)

Hlavní problematické návrhy, které znám (s příklady), jsou uvedeny níže:

Proveď proceduru(<Строка>)

Provádění kódu. Umožňuje spustit část kódu, která je mu předána jako řetězcová hodnota. Při použití na serveru musíte zajistit, aby data přijatá od klienta nebyla použita jako parametr. Není například povoleno následující použití:

#If Server Then
Export ProcedureOnServer(Param1).
Execute(Param1);
Konec procedury
#EndIf

Zadejte "COMObject" (konstruktor New COMObject(<Имя>, <Имя сервера>))

Vytvoří externí aplikační COM objekt s právy USER1CV8SERVER na aplikačním serveru (nebo jiném určeném počítači). Při použití na serveru se ujistěte, že parametry nejsou předávány z klientské aplikace. Na straně serveru je však efektivní tuto funkci využít při importu/exportu, odesílání dat přes internet, implementaci nestandardních funkcí atd.

Funkce GetCOMObject(<Имя файла>, <Имя класса COM>)

Porušení práv a provádění kódu. Podobně jako v předchozím, pouze získáváte objekt COM odpovídající souboru.

Procedury a funkce ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()

Porušování práv. Jejich spuštěním na serveru vám umožní zjistit podrobnosti o organizaci serverového subsystému. Při použití na serveru se ujistěte, že data nejsou přenášena na klienta nebo nejsou přístupná operátorům bez příslušného povolení. Věnujte zvláštní pozornost skutečnosti, že data lze předat zpět v parametru předávaném odkazem.

Postupy a funkce pro práci se soubory (CopyFile, FindFiles, MergeFiles a mnoho dalších), stejně jako typy souborů.

Porušování práv. Umožňují jejich spuštěním na serveru získat sdílený přístup k místním (a umístěným v síti) souborům přístupným pod uživatelskými právy USER1CV8SERVER. Při vědomém použití je možné efektivně implementovat úkoly, jako je import/export dat na server.

Před použitím těchto funkcí si nezapomeňte zkontrolovat svá uživatelská práva 1C. Chcete-li zkontrolovat uživatelská práva, můžete použít následující konstrukci v modulu serveru:

#If Server Then
Procedura PerformWorkWithFile() Export
RoleAdministrator = Metadata.Roles.Administrator;
User = SessionParameters.CurrentUser;
If User.Roles.Contains(RoleAdministrator) Then
//Zde se spustí kód pro práci se soubory
endIf;
#EndIf

Pokud tyto postupy a funkce používáte, nezapomeňte zkontrolovat parametry, jinak existuje riziko náhodného nebo vědomého způsobení nenapravitelného poškození aplikačního serveru 1C, například při provádění následujícího kódu na serveru:

Cesta = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
MoveFile(Cesta + "srvrib.lst", Cesta + "Here'sWhereTheFileGoes");

Po spuštění takového kódu na serveru, pokud má uživatel USER1CV8SERVER práva jej změnit, jak je popsáno výše, a po restartování procesu serveru (ve výchozím nastavení 3 minuty po ukončení všech uživatelů), vyvstane VELKÁ otázka o spuštění serveru. . Ale je také možné zcela smazat soubory...

Typy "XBase", "BinaryData", "XML Reader", "XML Writer", "XSL Transformation", "ZipFile Writer", "ZipFile Reader", "Text Reader", "Text Writer"

Porušování práv. Umožňují jejich spuštěním na serveru přístup k místním (a umístěným v síti) souborům určitého typu a jejich čtení/zápis pod uživatelskými právy USER1CV8SERVER. Při vědomém použití je možné efektivně implementovat takové úkoly, jako je import/export dat na server, protokolování provozu určitých funkcí a řešení administrativních úkolů. Obecně se doporučení shodují s předchozím odstavcem, ale měli byste zvážit možnost přenosu dat z těchto souborů (nikoli však objektů všech těchto typů) mezi klientskou a serverovou částí.

Zadejte "SystemInformation"

Porušování práv. Umožňuje získat data o aplikačním serveru v případě nesprávného použití a přenosu dat do klientské části aplikace. Při užívání je vhodné omezit oprávnění k užívání.

Typy "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Porušování práv. Při použití na serveru se připojuje ke vzdálenému PC z aplikačního serveru pod právy USER1CV8SERVER. Doporučení:

• Kontrola parametrů při volání metod.
• Kontrola uživatelských práv 1C.
• Přísná omezení práv uživatele USER1CV8SERVER pro přístup k síti.
• Správné nastavení brány firewall na aplikačním serveru 1C.

Při správném použití je vhodné organizovat například odesílání e-mailů z aplikačního serveru.

Typy "InformationBaseUserManager", "InformationBaseUser"

Porušování práv. Při nesprávném použití (v privilegovaném modulu) je možné přidávat uživatele nebo měnit parametry oprávnění stávajících uživatelů.

Formát funkce

Zhroucení serveru. Ano! Tato zdánlivě neškodná funkce, pokud její parametry nejsou řízeny a prováděny na serveru, může způsobit pád serverové aplikace. K chybě dochází například při formátování čísel a použití režimu pro zobrazení úvodních nul a velkého počtu znaků

Format(1, "CHZ=999; CHVN=");

Doufám, že tato chyba bude opravena v příštích verzích platformy, ale mezitím ve všech voláních této funkce, která lze na serveru provést, zkontrolujte parametry volání.

Postupy a funkce pro ukládání hodnot (ValueInRowInt, ValueInFile)

Zhroucení serveru. Tyto funkce nezpracovávají cyklické odkazy v kolekcích nebo velmi hluboké vnoření, takže v některých velmi zvláštních případech mohou selhat.

Chyby v hodnotách hranic a speciálních parametrů ve funkcích. Kontrola provedení.

Jedním z problémů, se kterými se můžete při používání serveru setkat, je vysoká „odpovědnost“ serverových funkcí (možnost pádu celé serverové aplikace kvůli chybě v jednom připojení a použití jednoho „prostoru zdrojů“ pro všechna připojení) . Proto je potřeba ovládat hlavní parametry běhu:

• U vestavěných jazykových funkcí zkontrolujte jejich spouštěcí parametry (dobrý příklad je funkce „Format“)
• Při použití smyček se ujistěte, že je splněna podmínka ukončení smyčky. Pokud je smyčka potenciálně nekonečná, uměle omezte počet iterací: MaximumIterationCounterValue = 1000000;
  Iteration Counter = 1;
  sbohem
  FunctionWhichMayNotReturnFalseValue()
  AND (počet iterací<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Tělo smyčky
  Iteration Counter = Iteration Counter + 1;
  EndCycle;
  If Iteration Counter>MaximumValue Of Iteration Counter Then
  //.... zpracuje událost příliš dlouhého provádění smyčky
  endIf;

• Při použití rekurze omezte maximální úroveň vnoření.
• Při vytváření a provádění dotazů se snažte zabránit velmi dlouhým výběrům a výběrům velkého množství informací (například při použití podmínky „IN HIERARCHIE“ nepoužívejte prázdnou hodnotu)
• Při navrhování informační báze zajistěte dostatečně velkou rezervu bitové hloubky pro čísla (jinak se sčítání a násobení stanou nekomutativními a neasociativními, což ztěžuje ladění)
• Ve spustitelných dotazech zkontrolujte provozní logiku na přítomnost hodnot NULL a správné fungování podmínek dotazu a výrazů pomocí NULL.
• Při používání kolekcí řiďte možnost jejich přenosu mezi aplikačním serverem a klientskou stranou.

Použití terminálového přístupu na stranu klienta k omezení přístupu

Často můžete najít doporučení použít terminálový přístup k omezení přístupu k datům a zlepšení výkonu spuštěním kódu na straně klienta na terminálovém serveru. Ano, při správné konfiguraci může použití terminálového přístupu skutečně zvýšit celkovou úroveň zabezpečení systému, ale bohužel se často můžete setkat s tím, že praktickým používáním bezpečnost systému pouze klesá. Zkusme přijít na to, s čím to souvisí. Nyní existují dva běžné způsoby organizace terminálového přístupu, a to Microsoft Terminal Services (RDP protokol) a Citrix Metaframe Server (ICA protokol). Obecně nástroje Citrix poskytují mnohem flexibilnější možnosti správy přístupu, ale cena těchto řešení je mnohem vyšší. Budeme uvažovat pouze základní vlastnosti společné oběma protokolům, které mohou snížit celkovou úroveň zabezpečení. Při používání terminálového přístupu existují pouze tři hlavní nebezpečí:

• Schopnost blokovat práci ostatních uživatelů zabavením nadměrného množství zdrojů
• Přístup k datům ostatních uživatelů.
• Neoprávněné kopírování dat z terminálového serveru do počítače uživatele

V každém případě vám Terminálové služby umožňují:

• Zvýšit spolehlivost práce (pokud dojde k poruše na terminálovém počítači, uživatel může následně pokračovat v práci ze stejného místa)
• Omezte přístup ke klientské aplikaci a souborům, které ukládá.
• Přeneste výpočetní zátěž z pracovní stanice uživatele na server pro přístup k terminálu
• Spravujte nastavení systému centrálněji. Pro uživatele budou uložená nastavení platná bez ohledu na to, ze kterého počítače se do systému přihlásili.
• V některých případech můžete použít terminálové řešení pro vzdálený přístup do systému.

Je nutné omezit počet možných připojení k terminálovému serveru pro jednoho uživatele

Z důvodu „obžerství“ klientské aplikace 1C ohledně zdrojů je nutné omezit maximální počet současných připojení jednoho uživatele (operátora) k terminálovému serveru. Aktivně používané připojení může využívat až 300 MB paměti pouze s jednou instancí aplikace. Kromě paměti je aktivně využíván procesorový čas, což také nepřispívá ke stabilitě uživatelů tohoto serveru. Současně se zabráněním nadměrného využívání zdrojů serveru může takové omezení zabránit použití prostředků někoho jiného účet. Implementováno standardním nastavením terminálového serveru.

Neměli byste dovolit, aby více než jedna nebo dvě klientské aplikace 1C běžely současně v jednom připojení

Diktováno stejnými důvody jako v předchozím odstavci, ale technicky obtížněji proveditelné. Problém je v tom, že je téměř nemožné zabránit restartování 1C pomocí nástrojů terminálového serveru (proč bude vysvětleno níže), takže tuto funkci musíte implementovat na úrovni aplikačního řešení (což také není dobré řešení, protože relace mohou nějakou dobu zůstat „viset“ Pokud je aplikace ukončena nesprávně, je potřeba doladit aplikační řešení v aplikačním modulu a některých referenčních knihách, což zkomplikuje používání aktualizací od 1C). Je velmi žádoucí ponechat uživateli možnost spouštět 2 aplikace, aby bylo možné některé akce (například generování reportů) spouštět na pozadí - klientská aplikace je bohužel ve skutečnosti jednovláknová.

Nedoporučuje se udělovat přístupová práva k terminálovému serveru uživatelům, kteří mají právo spouštět výpočetní úlohy náročné na zdroje v 1C, nebo bránit takovému spouštění, zatímco ostatní uživatelé aktivně pracují.

Samozřejmě je lepší ponechat přístup k terminálovému serveru pouze uživatelům, kteří nevyužívají úlohy jako dolování dat, geografické diagramy, import/export a další úlohy, které vážně zatěžují klientskou část aplikace. Pokud stále existuje potřeba takové úlohy povolit, pak je nutné: upozornit uživatele, že tyto úlohy mohou ovlivnit výkon ostatních uživatelů, zaznamenat začátek a konec takového procesu do protokolu, povolit provádění pouze při regulovaném čas atd.

Je nutné zajistit, aby každý uživatel měl práva zápisu pouze do přesně definovaných adresářů na terminálovém serveru a aby do nich ostatní uživatelé neměli přístup.

Za prvé, pokud neomezíte možnost zápisu do sdílených adresářů (jako je adresář, kde je nainstalován 1C), pak je pro útočníka stále možné změnit chování programu pro všechny uživatele. Za druhé, data jednoho uživatele (dočasné soubory, soubory pro uložení nastavení reportů atd.) by za žádných okolností neměla být přístupná jinému uživateli terminálového serveru - obecně se při běžné konfiguraci toto pravidlo dodržuje. Za třetí, útočník má stále možnost „rozházet“ oddíl tak, aby na pevném disku nezbylo místo. Vím, že mi budou namítat, že operační systém Windows, počínaje Windows 2000, má kvótový mechanismus, ale to je dost drahý mechanismus a prakticky jsem nikdy neviděl jeho reálné využití.

Pokud byly předchozí problémy s nastavením přístupu obecně poměrně snadno implementovatelné, pak tak (zdánlivě) jednoduchý úkol, jako je regulace přístupu uživatelů k souborům, není triviálně implementován. Za prvé, pokud není použit mechanismus kvót, lze uložit velké soubory. Za druhé, systém je postaven tak, že téměř vždy bude možné soubor uložit tak, aby byl dostupný dalšímu uživateli.

Vzhledem k tomu, že úkol je obtížné úplně vyřešit, doporučuje se auditovat většinu událostí souboru

Je nutné zakázat připojení (mapování) diskových zařízení, tiskáren a schránky klientské pracovní stanice.

V RDP a ICA je možné organizovat automatické připojení disků, tiskáren, schránkových komunikačních portů terminálového počítače k ​​serveru. Pokud tato příležitost existuje, je téměř nemožné zabránit spuštění cizího kódu na terminálovém serveru a uložení dat z 1C na klientovi terminálového přístupu. Povolit tyto funkce pouze uživatelům s právy správce.

Přístup k síťovému souboru z terminálového serveru by měl být omezen.

Pokud tak neučiníte, uživatel bude opět moci spustit nežádoucí kód nebo uložit data. Vzhledem k tomu, že běžný protokol nesleduje události souborů (mimochodem, dobrý nápad pro implementaci vývojáři platforem) a je téměř nemožné nastavit systémový audit v celé síti (není dostatek prostředků na jeho údržbu), je lepší, aby uživatel mohl odesílat data buď k tisku, nebo e-mailem. Věnujte zvláštní pozornost tomu, aby terminálový server nepracoval přímo s vyměnitelnými médii uživatelů.

Při vytváření zabezpečeného systému byste za žádných okolností neměli nechat aplikační server na terminálovém serveru.

Pokud aplikační server běží na stejném počítači jako klientské aplikace, existuje mnoho příležitostí k narušení jeho normálního provozu. Pokud z nějakého důvodu není možné oddělit funkce terminálového serveru a aplikačního serveru, věnujte zvláštní pozornost uživatelskému přístupu k souborům používaným aplikačním serverem.

Je nutné vyloučit možnost spouštění všech aplikací kromě 1C:Enterprise na terminálovém serveru.

Toto je jedno z nejobtížněji realizovatelných přání. Začněme tím, že je potřeba správně nakonfigurovat zásady zabezpečení skupiny v doméně. Všechny šablony pro správu a zásady omezení softwaru musí být správně nakonfigurovány. Chcete-li se otestovat, ujistěte se, že jsou blokovány alespoň následující funkce:

Složitost implementace tohoto požadavku často vede k možnosti spuštění „extra“ relace 1C na terminálovém serveru (i když jsou jiné aplikace omezené, je v zásadě nemožné zakázat spuštění 1C pomocí Windows).

Zvažte omezení běžného protokolu (všichni uživatelé používají program z jednoho počítače)

Je zřejmé, že protože uživatelé otevírají 1C v terminálovém režimu, bude terminálový server zaznamenán v protokolu. Protokol neuvádí, ze kterého počítače se uživatel připojil.

Terminálový server – ochrana nebo zranitelnost?

Po zvážení hlavních rysů terminálu sever tedy můžeme říci, že terminál sever může potenciálně pomoci v automatizaci distribuce výpočetní zátěže, ale vybudovat bezpečný systém je poměrně obtížné. Jedním z případů, kdy je použití terminálového serveru nejúčinnější, je spuštění 1C bez Průzkumníka Windows v režimu celé obrazovky pro uživatele s omezenou funkčností a specializovaným rozhraním.

Práce klientské části

Používání prohlížeče Internet Explorer (IE)

Jednou z podmínek běžného provozu klientské části 1C je použití komponent internet Explorer. S těmito součástmi musíte být velmi opatrní.

Pozornost! Za prvé, pokud je k IE „připojen“ modul spyware nebo adware, načte se, i když si prohlížíte jakékoli soubory HTML v 1C. Zatím jsem nezaznamenal žádné vědomé použití této funkce, ale v jedné z organizací jsem viděl načtený „špionážní“ modul z jedné z pornografických sítí se spuštěnou 1C (antivirový program nebyl aktualizován, byly zjištěny příznaky : při nastavování firewallu bylo jasné, že 1C se snažil na portu 80 připojit k porno stránce). Ve skutečnosti je to další argument ve prospěch skutečnosti, že ochrana by měla být komplexní

Pozornost! Za druhé, systém 1C umožňuje použití Flash filmů, ActiveX objektů, VBScript v zobrazovaných HTML dokumentech, odesílání dat na internet, dokonce otevírání PDF souborů (!), i když v druhém případě se ptá „otevřít nebo uložit“... Obecně vše, po čem vaše srdce touží. Příklad ne zcela rozumného použití vestavěných možností prohlížení a úprav HTML:

• Vytvořte nový dokument HTML (Soubor -> Nový -> Dokument HTML).
• Přejděte na kartu "Text" v prázdném dokumentu.
• Odstraňte text (úplně).
• Přejděte na kartu "Zobrazit" tohoto dokumentu
• Pomocí drag-n-drop přesuňte soubor s příponou SWF (jedná se o soubory filmů Flash) z otevřeného Průzkumníka do okna dokumentu, například z mezipaměti prohlížeče, i když pro zábavu můžete použít i hračku FLASH.
• Jak milé! Na 1C můžete spustit hračku!

Z hlediska zabezpečení systému je to zcela špatně. Zatím jsem nezaznamenal žádné speciální útoky na 1C prostřednictvím této zranitelnosti, ale s největší pravděpodobností to bude otázka času a hodnoty vašich informací.

Při práci s polem dokumentu HTML se objevují některé další drobné problémy, ale hlavní jsou dva uvedené. I když, pokud k těmto funkcím přistoupíte kreativně, můžete uspořádat skutečně úžasné možnosti rozhraní pro práci s 1C.

Použití externích reportů a zpracování.

Pozornost! Externí reporty a zpracování – na jedné straně – pohodlný způsob implementace dalších tištěných formulářů, regulační výkazy, specializované výkazy, na druhou stranu potenciální způsob, jak obejít mnohá omezení zabezpečení systému a narušit provoz aplikačního serveru (příklad viz výše v části „Předávání parametrů“). V systému 1C je v sadě práv speciální parametr pro roli „Interaktivní otevření externího zpracování“, ale to problém zcela neřeší - pro úplné řešení je nutné zúžit okruh uživatelů, kteří mohou spravovat externí tištěné formuláře, regulační zprávy a další standardní možnosti standardních řešení realizovaných pomocí externích úprav. Například ve výchozím nastavení v UPP mají všechny hlavní uživatelské role možnost pracovat s adresářem dalších tištěných formulářů, a to je ve skutečnosti možnost použít jakékoli externí zpracování.

Použití standardních mechanismů pro standardní řešení a platformy (výměna dat)

Některé ze standardních mechanismů jsou potenciálně nebezpečné a neočekávaným způsobem.

Tisk seznamů

Jakýkoli seznam (například adresář nebo registr informací) v systému lze vytisknout nebo uložit do souboru. K tomu stačí použít standardní funkci dostupnou z kontextové nabídky a nabídky „Akce“:

Mějte na paměti, že prakticky vše, co uživatel vidí v seznamech, lze odeslat do externích souborů. Jediné, co můžeme poradit, je vést protokol o tisku dokumentů na tiskových serverech. U zvláště kritických formulářů je nutné nakonfigurovat panel akcí spojený s chráněným polem tabulky tak, aby z tohoto panelu nebyla dostupná možnost zobrazení seznamu, a zakázat místní nabídku (viz obrázek 6).

Výměna dat v distribuované databázi

Formát výměny dat je poměrně jednoduchý a je popsán v dokumentaci. Pokud má uživatel možnost nahradit několik souborů, může v systému provádět neoprávněné změny (ačkoli je to poměrně pracný úkol). Možnost vytvořit periferní databázi při použití plánů výměny distribuovaných databází by běžným operátorům neměla být dostupná.

Standardní výměna dat XML

Při standardní výměně dat, která se používá pro výměnu mezi standardními konfiguracemi (např. „Řízení obchodu“ a „Podnikové účetnictví“), je možné v pravidlech výměny specifikovat obsluhu událostí pro načítání a vykládání objektů. To je realizováno získáním handleru ze souboru a procedurou „Run()“ pro standardní zpracování načítání a vyjímání souboru (procedura „Run()“ se spouští na straně klienta). Je zřejmé, že není obtížné vytvořit takový falešný výměnný soubor, který bude provádět škodlivé akce. U většiny uživatelských rolí standardních řešení je sdílení ve výchozím nastavení povoleno.

Doporučení: omezit přístup k výměně XML pro většinu uživatelů (ponechat jej pouze správcům informační bezpečnosti). Uchovávejte protokoly o průběhu tohoto zpracování, ukládejte výměnný soubor, například jej odešlete emailem správce zabezpečení informací před stažením.

Používání obecných sestav, zejména Konzole sestav

Dalším problémem je výchozí přístup uživatelů k obecným přehledům, zejména k přehledu Konzole přehledů. Tato zpráva se vyznačuje tím, že vám umožňuje provádět téměř jakékoli požadavky na zabezpečení informací, a i když je systém práv 1C (včetně RLS) nakonfigurován poměrně přísně, umožňuje uživateli získat mnoho „extra“ informací. a vynutíte server, aby provedl požadavek, který spotřebuje všechny systémy zdrojů.

Použití režimu celé obrazovky (režim počítače)

Jedním z efektivních způsobů, jak organizovat specializovaná rozhraní s omezeným přístupem k funkčnosti programu, je celoobrazovkový režim hlavní (a možná jediné) formy použitého rozhraní. V tomto případě neexistují žádné problémy s přístupností, například nabídka "Soubor" a všechny akce uživatele jsou omezeny možnostmi použitého formuláře. Další podrobnosti najdete v části „Funkce implementace režimu plochy“ na disku ITS.

Záloha

Zálohování pro verzi klient-server 1C lze provést dvěma způsoby: nahráním dat do souboru s příponou dt a vytvořením záložních kopií pomocí SQL. První způsob má mnoho nevýhod: je nutný výhradní přístup, samotné vytvoření kopie trvá mnohem déle, v některých případech (při porušení struktury zabezpečení informací) je vytvoření archivu nemožné, ale má jednu výhodu - minimální velikost archiv. U zálohování SQL je tomu naopak: vytvoření kopie probíhá na pozadí pomocí SQL serveru, kvůli jednoduché struktuře a absenci komprese - jde o velmi rychlý proces a pokud je zachována fyzická integrita SQL databáze není porušena, záloha se provádí, ale velikost kopie se shoduje se skutečnou velikostí zabezpečení informací v rozbaleném stavu (neprovádí se komprese). Vzhledem k dalším výhodám zálohovacího systému MS SQL je vhodnější jej používat (jsou povoleny 3 typy záloh: plná, rozdílová, kopie transakčního protokolu; je možné vytvářet pravidelně prováděné úlohy; záložní kopie a záloha systémy jsou rychle nasazeny, je možné předvídat velikost požadovaného místa na disku atd.). Hlavní body organizace zálohování z hlediska zabezpečení systému jsou:

• Potřeba vybrat místo úložiště pro zálohy tak, aby nebyly přístupné uživatelům.
• Nutnost ukládat zálohy ve fyzické vzdálenosti od MS SQL serveru (pro případ přírodních katastrof, požárů, útoků atd.)
• Možnost udělit práva ke spuštění zálohování uživateli, který nemá přístup k zálohám.

Další podrobnosti naleznete v dokumentaci k MS SQL.

Šifrování dat

K ochraně dat před neoprávněným přístupem se často používají různé kryptografické nástroje (jak softwarové, tak hardwarové), ale jejich proveditelnost do značné míry závisí na správné aplikaci a celkové bezpečnosti systému. Podíváme se na šifrování dat v různých fázích přenosu a ukládání dat pomocí nejběžnějších prostředků a na hlavní chyby v návrhu systému pomocí kryptografických nástrojů.

Existuje několik hlavních fází zpracování informací, které lze chránit:

• Přenos dat mezi klientskou částí systému a aplikačním serverem
• Přenos dat mezi aplikačním serverem a MS SQL Serverem
• Data uložená na MS SQL Server (datové soubory na fyzickém disku)
• Šifrování dat uložených v informační bezpečnosti
• Externí data (ve vztahu k informační bezpečnosti)

U dat uložených na straně klienta a na aplikačním serveru (uložená uživatelská nastavení, seznam zabezpečení informací atd.) má šifrování opodstatnění jen ve velmi ojedinělých případech, a proto zde není uvažováno. Při používání kryptografických nástrojů nesmíme zapomínat, že jejich použití může výrazně snížit výkon systému jako celku.

Obecné informace o kryptografické ochraně síťových připojení při použití protokolu TCP/IP.

Bez zabezpečení jsou všechna síťová připojení zranitelná vůči neoprávněnému sledování a přístupu. K jejich ochraně můžete použít šifrování dat na úrovni síťového protokolu. Pro šifrování dat přenášených v lokální síti se nejčastěji používají nástroje IPSec poskytované operačním systémem.

Nástroje IPSec poskytují šifrování přenášených dat pomocí algoritmů DES a 3DES a také ověřování integrity pomocí hašovacích funkcí MD5 nebo SHA1. IPSec může fungovat ve dvou režimech: transportní režim a tunelový režim. Transportní režim je vhodnější pro zabezpečení připojení v místní síti. Tunelový režim lze použít k organizaci připojení VPN mezi samostatnými segmenty sítě nebo k ochraně vzdáleného připojení k místní síti přes otevřené datové kanály.

Hlavní výhody tohoto přístupu jsou:

• Možnost centralizované správy zabezpečení pomocí nástrojů Active Directory.
• Schopnost vyloučit neoprávněná připojení k aplikačnímu serveru a MS SQL serveru (např. je možné chránit před neoprávněným přidáváním zabezpečení informací na aplikačním serveru).
• Eliminace „naslouchání“ síťovému provozu.
• Není potřeba měnit chování aplikačních programů (v tomto případě 1C).
• Standardní povaha takového řešení.

Tento přístup má však svá omezení a nevýhody:

• IPSec nechrání data před rušením a odposlechem přímo na zdrojovém a cílovém počítači.
• Množství dat přenesených po síti je o něco větší než bez použití IPSec.
• Při použití IPSec je zatížení centrálního procesoru o něco vyšší.

Podrobný popis implementace nástrojů IPSec přesahuje rámec tohoto článku a vyžaduje pochopení základních principů fungování protokolu IP. Chcete-li správně nakonfigurovat zabezpečení připojení, přečtěte si příslušnou dokumentaci.

Samostatně je nutné zmínit několik aspektů licenční smlouvy s 1C při organizaci VPN připojení. Faktem je, že i přes absenci technických omezení je při připojení více segmentů lokální sítě nebo vzdáleného přístupu jednotlivého počítače k ​​lokální síti obvykle vyžadováno několik základních dodávek.

Šifrování dat při přenosu mezi klientskou částí systému a aplikačním serverem.

Kromě šifrování na úrovni síťového protokolu je možné šifrovat data na úrovni protokolu COM+, což je zmíněno v článku „Regulace přístupu uživatelů k informační bázi ve verzi klient-server“ ITS. Chcete-li ji implementovat, musíte pro aplikaci 1CV8 v části „Služby komponent“ nastavit úroveň ověřování pro volání na „Packet Privacy“. Při nastavení do tohoto režimu je paket ověřen a zašifrován, včetně dat a identity a podpisu odesílatele.

Šifrování dat při přenosu mezi aplikačním serverem a MS SQL Serverem

MS SQL Server poskytuje následující nástroje pro šifrování dat:

• Při přenosu dat mezi aplikačním serverem a MS SQL Serverem je možné použít Secure Sockets Layer (SSL).
• Při použití síťové knihovny Multiprotocol se používá šifrování dat na úrovni RPC. Toto je potenciálně slabší šifrování než použití SSL.
• Pokud je použit protokol pro výměnu sdílené paměti (k tomu dochází, pokud jsou aplikační server a MS SQL Server umístěny na stejném počítači), pak se šifrování v žádném případě nepoužívá.

Chcete-li vytvořit potřebu šifrování všech přenášených dat pro konkrétní MS SQL server, musíte použít nástroj "Server Network Utility". Spusťte jej a na kartě „Obecné“ zaškrtněte políčko „Vynutit šifrování protokolu“. Metoda šifrování se vybírá v závislosti na metodě používané klientskou aplikací (tj. aplikačním serverem 1C). Chcete-li používat SSL, musíte správně nakonfigurovat certifikační službu ve vaší síti.

Chcete-li nastavit nutnost šifrování všech přenášených dat pro konkrétní aplikační server, musíte použít nástroj "Client Network Utility" (obvykle se nachází v "C:\WINNT\system32\cliconfg.exe"). Stejně jako v předchozím případě na kartě „Obecné“ zaškrtněte políčko „Vynutit šifrování protokolu“.

Stojí za zvážení, že použití šifrování v tomto případě může mít významný dopad na výkon systému, zejména při použití dotazů, které vracejí velké množství informací.

Pro lepší ochranu spojení mezi aplikačním serverem a MS SQL Serverem při použití protokolu TCP/IP můžeme doporučit několik změn výchozího nastavení.

Nejprve můžete nastavit jiný než standardní port (standardně se používá port 1433). Pokud se rozhodnete pro výměnu dat použít nestandardní TCP port, mějte na paměti, že:

• MS SQL server a aplikační server musí používat stejný port.
• Při použití firewallů musí být tento port povolen.
• Na MS SQL serveru nelze nastavit port, který mohou používat jiné aplikace. Pro referenci můžete použít http://www.ise.edu/in-notes/iana/assignments/port-numbers (adresa převzata z SQL Server Books Online).
• Při používání více instancí služby MS SQL Server si nezapomeňte přečíst dokumentaci k MS SQL pro konfiguraci (část „Konfigurace síťových připojení“).

Za druhé, v nastavení TCP/IP protokolu na MS SQL serveru můžete nastavit příznak "Skrýt server", který zakáže odpovědi na broadcast požadavky pro tuto instanci služby MS SQL Server.

Šifrování dat MS SQL uložených na disku

K dispozici je poměrně velký výběr softwaru a hardwaru pro šifrování dat umístěných na lokálním disku (to zahrnuje standardní možnost Windows používat EFS, použití klíčů eToken a programy třetích stran, jako je Jetico Bestcrypt nebo PGPDisk). Jedním z hlavních úkolů těchto nástrojů je ochrana dat v případě ztráty média (například při krádeži serveru). Zvláště stojí za zmínku, že Microsoft nedoporučuje ukládat databáze MS SQL na šifrovaná média, a to je zcela oprávněné. Hlavním problémem je v tomto případě výrazný pokles produktivity a možné problémy spolehlivost z poruch. Druhým faktorem komplikujícím život systémovému administrátorovi je nutnost zajistit dostupnost všech databázových souborů v době, kdy k nim služba MS SQL poprvé přistupuje (tj. je žádoucí, aby při připojení šifrovaného média byly vyloučeny interaktivní akce).

Abyste se vyhnuli citelnému poklesu výkonu systému, můžete využít schopnosti MS SQL vytvářet databáze v několika souborech. V tomto případě by samozřejmě databáze MS SQL neměla být vytvořena serverem 1C při vytváření infobáze, ale měla by být vytvořena samostatně. Příklad TSQL skriptu s komentáři je uveden níže:

USE master
JÍT
-- Vytvořte databázi SomeData,
VYTVOŘIT DATABÁZI SomeData
-- jehož data jsou celá umístěna ve skupině souborů PRIMARY.
PRIMÁRNĚ
-- Hlavní datový soubor je umístěn na šifrovaném médiu (logický disk E:)
-- a má počáteční velikost 100 MB, lze ji automaticky zvýšit na 200 MB
-- v krocích po 20 MB
(NAME = SomeData1,
FILENAME = "E:\SomeData1.mdf",
VELIKOST = 100 MB,
MAXIMÁLNÍ VELIKOST = 200,
FILEGROWTH = 2),
-- Druhý datový soubor je umístěn na nezašifrovaném médiu (logická jednotka C:)
-- a má počáteční velikost 100 MB, lze ji automaticky zvětšit na limit
-- místo na disku v krocích po 5 % aktuální velikosti souboru (zaokrouhleno na 64 kB)
(NAME = SomeData2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
VELIKOST = 100 MB,
MAXIMÁLNÍ VELIKOST = NEOMEZENÁ,
FILEGROWTH = 5 %)
PŘIHLÁSIT SE
-- Ačkoli lze protokol transakcí také rozdělit na části, nemělo by se to dělat,
-- protože tento soubor se mění mnohem častěji a pravidelně se čistí (například když
-- vytvoření zálohy databáze).
(NAME = SomeDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
VELIKOST = 10 MB,
MAXIMÁLNÍ VELIKOST = NEOMEZENÁ,
RŮST SOUBORU = 10)
JÍT
-- Je lepší okamžitě předat vlastnictví databáze uživateli, jehož jménem
-- 1C se připojí. K tomu musíme deklarovat současnou základnu
- právě vytvořeno,
POUŽÍVEJTE SomeData
JÍT
-- a spustit sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Krátká odbočka o automatickém růstu velikosti datového souboru. Ve výchozím nastavení se velikosti souborů pro nové databáze zvyšují v krocích po 10 % aktuální velikosti souboru. Pro malé databáze je to zcela přijatelné řešení, pro velké však nepříliš dobré: při velikosti databáze například 20 GB by se měl soubor okamžitě zvětšit o 2 GB. I když k této události dochází poměrně zřídka, může trvat několik desítek sekund (všechny ostatní transakce jsou po tuto dobu efektivně nečinné), což, pokud k ní dojde při aktivní práci s databází, může způsobit selhání. Druhým negativním důsledkem proporcionálního přírůstku, ke kterému dochází při téměř úplném zaplnění místa na disku, je pravděpodobnost předčasného selhání z důvodu nedostatku volného místa. Pokud je například diskový oddíl o kapacitě 40 GB zcela vyhrazen pro jednu databázi (přesněji pro jeden soubor této databáze), pak kritická velikost databázového souboru, na kterou je nutné urgentně (velmi naléhavě), až k přerušení běžné práce uživatelů) k reorganizaci úložiště informací je datový soubor o velikosti 35 GB. S velikostí přírůstku nastavenou na 10–20 MB můžete pokračovat v práci, dokud nedosáhnete 39 GB.

Proto, i když výše uvedený výpis určuje zvýšení velikosti jednoho z databázových souborů v krocích po 5 %, pro velké velikosti databází je lepší nastavit pevný přírůstek 10-20 MB. Při nastavování hodnot přírůstku pro růst velikosti databázového souboru je nutné vzít v úvahu, že dokud jeden ze souborů ve skupině souborů nedosáhne své maximální velikosti, platí pravidlo: soubory v jedné skupině souborů se zvětšují všechny současně čas, kdy jsou všechny zcela naplněny. Takže ve výše uvedeném příkladu, když soubor SomeData1.mdf dosáhne své maximální velikosti 200 MB, bude mít soubor SomeData2.ndf velikost přibližně 1,1 GB.

Po vytvoření takové databáze, i když se její nechráněné soubory SomeData2.ndf a SomeData.ldf stanou přístupné útočníkovi, bude extrémně obtížné obnovit skutečný stav databáze – data (včetně informací o logické struktuře databáze ) budou rozptýleny v několika souborech a klíčové informace (například o tom, které soubory tvoří tuto databázi) budou v zašifrovaném souboru.

Samozřejmě, pokud se používá ukládání databázových souborů pomocí kryptografických prostředků, pak by zálohování (alespoň těchto souborů) nemělo být prováděno na nešifrovaná média. Chcete-li zálohovat jednotlivé soubory databáze, použijte příslušnou syntaxi příkazu BACKUP DATABASE. Upozorňujeme, že ačkoli je možné chránit zálohu databáze heslem (možnosti "PASSWORD = " a "MEDIAPASSWORD = " příkazu "BACKUP DATABASE"), taková záloha se nezašifruje!

Šifrování dat aplikačního serveru a klienta uložených na discích

Ve většině případů nelze považovat za oprávněné ukládat soubory používané 1C:Enterprise (klientská část a aplikační server) na šifrovaná média kvůli nepřiměřeně vysokým nákladům, pokud však taková potřeba existuje, mějte na paměti, že aplikační server a klientská část aplikace velmi často vytváří dočasné soubory. Tyto soubory mohou často zůstat po dokončení aplikace a je téměř nemožné zaručit jejich odstranění pomocí nástrojů 1C. Je tedy nutné zašifrovat adresář používaný pro dočasné soubory v 1C nebo jej neukládat na disk pomocí jednotky RAM (druhá možnost není vždy možná kvůli velikosti generovaných souborů a požadavkům RAM 1C:Enterprise samotná aplikace).

Šifrování dat pomocí vestavěných nástrojů 1C.

Standardní možnosti pro použití šifrování v 1C se týkají použití objektů pro práci se soubory Zip s parametry šifrování. K dispozici jsou následující režimy šifrování: Algoritmus AES s klíčem 128, 192 nebo 256 bitů a zastaralý algoritmus původně používaný v archivátoru Zip. Soubory ZIP zašifrované pomocí AES nejsou čitelné mnoha archivátory (WinRAR, 7zip). Chcete-li vygenerovat soubor obsahující šifrovaná data, musíte zadat heslo a šifrovací algoritmus. Nejjednodušší příklad funkcí šifrování a dešifrování založených na této funkci je uveden níže:

Funkce EncryptData(data, heslo, metoda šifrování = nedefinováno) Export

// Zapíše data do dočasného souboru. Ve skutečnosti nelze tímto způsobem uložit všechna data.
ValueInFile(TemporaryFileName, Data);

// Zápis dočasných dat do archivu
Zip = New ZipFileRecord(NázevSouboru TemporaryArchive, Password, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Write();

// Načtení dat z přijatého archivu do RAM
EncryptedData = NewValueStorage(NewBinaryData(ArchiveTemporaryFileName));

// Dočasné soubory - smazat

EndFunctions Funkce DecryptData(EncryptedData, Password) Export

// Pozornost! Správnost předávaných parametrů není sledována

// Zapíše předávanou hodnotu do souboru
ArchiveTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);

// Rozbalte první soubor právě zapsaného archivu
TemporaryFileName = GetTemporaryFileName();
Zip = New ReadZipFile(TemporaryArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Přečte zapsaný soubor
Data = ValueFromFile(TemporaryFileName + "\" + Zip.Items.Name);

//Odstranit dočasné soubory
DeleteFiles(TemporaryFileName);
DeleteFiles(ArchiveTemporaryFileName);

Návratová data;

EndFunction

Tuto metodu samozřejmě nelze nazvat ideální - data se zapisují do dočasné složky v čistém textu, výkon metody, upřímně řečeno, je horší než kdy jindy, uložení v databázi vyžaduje extrémně velké množství místa, ale toto je jedinou metodou, která je založena pouze na vestavěných mechanismech platformy. Oproti mnoha jiným metodám má navíc výhodu – tato metoda současně sbaluje data spolu se šifrováním. Pokud chcete implementovat šifrování bez nevýhod, které tato metoda má, musíte je buď implementovat do externí komponenty, nebo se obrátit na existující knihovny prostřednictvím vytváření objektů COM, například pomocí Microsoft CryptoAPI. Jako příklad uvedeme funkce šifrování/dešifrování řetězce na základě přijatého hesla.

Funkce EncryptStringDES(NešifrovanýString, Heslo)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Tato konstanta pochází z CryptoAPI

EncryptionMechanism.Content = UnencryptedString;
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

return EncryptedString;

EndFunction // EncryptStringDES()

Funkce DecryptStringDES(šifrovaný řetězec, heslo)

//Pozornost! Parametry se nekontrolují!

Encryption Engine = New COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Heslo);
Pokus
EncryptionMechanism.Decrypt(EncryptedString);
Výjimka
// Nesprávné heslo!;
Návrat Nedefinováno;
EndPokus;

ReturnEncryptionMechanism.Content;

EndFunction // DecryptStringDES()

Vezměte prosím na vědomí, že při převodu prázdná hodnota zadáním řetězce nebo hesla do těchto funkcí se vygeneruje chybová zpráva. Řetězec získaný pomocí tohoto šifrovacího postupu je o něco delší než původní. Specifikem tohoto šifrování je, že pokud zašifrujete řetězec dvakrát, výsledné řetězce NEBUDOU identické.

Základní chyby při používání kryptografických nástrojů.

Při používání kryptografických nástrojů se často dělají stejné chyby:

Podcenění penalizace výkonu při používání kryptografie.

Kryptografie je úloha, která vyžaduje poměrně velké množství výpočtů (zejména pro algoritmy jako DES, 3DES, GOST, PGP). A ani při použití vysoce výkonných a optimalizovaných algoritmů (RC5, RC6, AES) není úniku před zbytečným přenosem dat v paměti a výpočetním zpracováním. A to téměř neguje možnosti mnoha serverových komponent (pole RAID, síťové adaptéry). Při použití hardwarového šifrování nebo hardwarového odvození šifrovacího klíče existuje další možné omezení výkonu: rychlost přenosu dat mezi přídavným zařízením a pamětí (kde výkon takového zařízení nemusí být kritický). Při použití šifrování malého množství dat (například e-mailové zprávy) není nárůst výpočetní zátěže systému tak patrný, ale v případě úplného šifrování všeho to může výrazně ovlivnit výkon systému jako celek.

Podcenění moderních možností pro výběr hesel a klíčů.

V tuto chvíli jsou možnosti technologie takové, že klíč o délce 40-48 bitů může vybrat malá organizace a klíč o délce 56-64 bitů velká organizace. Tito. musí být použity algoritmy, které používají klíč o délce alespoň 96 nebo 128 bitů. Většina klíčů je však generována pomocí hashovacích algoritmů (SHA-1 atd.) na základě hesel zadaných uživatelem. V tomto případě klíč o délce 1024 bitů nemusí pomoci. Za prvé, často se používá snadno uhodnutelné heslo. Faktory, které usnadňují výběr, jsou: použití pouze jednoho případu písmen; používání slov, jmen a výrazů v heslech; použití známých dat, narozenin atd.; používání "vzorů" při generování hesel (například 3 písmena, pak 2 čísla, pak 3 písmena v celé organizaci). Dobré heslo by mělo být poměrně náhodnou posloupností velkých a malých písmen, číslic a interpunkčních znamének. Hesla zadávaná z klávesnice o délce do 7-8 znaků i při dodržení těchto pravidel lze uhodnout v rozumném čase, proto je lepší, aby mělo heslo alespoň 11-13 znaků. Ideálním řešením je vyhnout se generování klíče pomocí hesla např. pomocí různých čipových karet apod., ale v tomto případě je nutné zajistit možnost ochrany před ztrátou média šifrovacího klíče.

Nezabezpečené ukládání klíčů a hesel.

Běžné příklady této chyby:

• dlouhá a složitá hesla napsaná na poznámkách nalepených na monitoru uživatele.
• ukládání všech hesel do souboru, který není chráněn (nebo je chráněn mnohem méně než samotný systém)
• ukládání elektronických klíčů ve veřejné doméně.
• časté předávání elektronických klíčů mezi uživateli.

Proč vyrábět pancéřové dveře, když je klíč k nim pod rohožkou?

Přenos původně zašifrovaných dat do nezabezpečeného prostředí.

Při nastavování bezpečnostního systému se ujistěte, že dělá svou práci. Narazil jsem například na situaci (nesouvisející s 1C), kdy byl původně zašifrovaný soubor, když program běžel v přehledné podobě, umístěn do dočasné složky, odkud jej bylo možné bezpečně číst. Záložní kopie zašifrovaných dat v čisté podobě se často nacházejí někde „nedaleko“ od těchto dat.

Použití kryptografických nástrojů pro jiné účely

Šifrováním dat při přenosu nemůžete očekávat, že data budou nedostupná tam, kde jsou použita. Například služby IPSec žádným způsobem nebrání aplikačnímu serveru „čichat“ síťový provoz na úrovni aplikace.

Abyste se vyhnuli chybám při implementaci kryptografických systémů, měli byste před jejich nasazením (minimálně) provést následující.

• Zjistit:
  • Co je potřeba chránit?
  • Jakou metodu ochrany byste měli použít?
  • Které části systému je potřeba zabezpečit?
  • Kdo bude kontrolovat přístup?
  • Bude šifrování fungovat ve všech správných oblastech?
• Určete, kde jsou informace uloženy, jak budou odesílány po síti a počítače, ze kterých bude k informacím přistupováno. To poskytne informace o rychlosti sítě, kapacitě a využití před implementací systému, což je užitečné pro optimalizaci výkonu.
• Vyhodnoťte zranitelnost systému vůči různým typům útoků.
• Vypracujte a zdokumentujte plán zabezpečení systému.
• Vyhodnotit ekonomickou efektivitu (opodstatněnost) používání systému.

Závěr

Samozřejmě, v rychlém přehledu není možné uvést všechny aspekty související s bezpečností v 1C, ale dovolme si vyvodit nějaké předběžné závěry. Tuto platformu samozřejmě nelze nazvat ideální - stejně jako mnoho jiných má své vlastní problémy s organizací bezpečného systému. To ale v žádném případě neznamená, že tyto problémy nelze obejít, ba naopak, téměř všechny nedostatky lze odstranit správným vývojem, implementací a používáním systému. Většina problémů vzniká z důvodu nedostatečného vývoje konkrétního aplikačního řešení a jeho exekučního prostředí. Například standardní řešení bez výrazných změn jednoduše neznamenají vytvoření dostatečně bezpečného systému.

Tento článek opět ukazuje, že jakýkoli soubor bezpečnostních opatření musí pokrývat všechny fáze implementace: vývoj, nasazení, správu systému a samozřejmě organizační opatření. V informačních systémech je hlavní bezpečnostní hrozbou „lidský faktor“ (včetně uživatelů). Tento soubor opatření musí být rozumný a vyvážený: nedává smysl a je nepravděpodobné, že bude přidělen dostatek finančních prostředků na organizaci ochrany, která převyšuje náklady na samotná data.

Společnost je jedinečná služba pro kupující, vývojáře, prodejce a affiliate partnery. Kromě toho se jedná o jeden z nejlepších online obchodů se softwarem v Rusku, na Ukrajině a v Kazachstánu, který zákazníkům nabízí širokou škálu produktů, mnoho platebních metod, rychlé (často okamžité) zpracování objednávek a sledování průběhu objednávky v osobní sekci .