1c příliš složitý požadavek, možná přetečení zásobníku. Přetečení zásobníku. Šifrování dat během přenosu mezi aplikačním serverem a MS SQL Serverem

Tento článek opět ukazuje, že jakýkoli soubor bezpečnostních opatření by měl 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 to „lidský faktor“ (včetně uživatelů), který je hlavní bezpečnostní hrozbou. Tento soubor opatření musí být přiměřený a vyvážený: nedává to smysl a je nepravděpodobné, že bude na organizaci ochrany přiděleno dostatek finančních prostředků, které převyšují náklady na data samotná.

Úvod

1C: Enterprise je nejrozšířenější účetní systém v Rusku, ale navzdory tomu až do verze 8.0 jeho vývojáři věnovali otázkám zabezpečení velmi malou pozornost. V zásadě to samozřejmě bylo dáno cenovou mezerou produktu a zaměřením na malé podniky, kde nejsou kvalifikovaní IT specialisté, a případné náklady na nasazení a udržování bezpečného systému by byly pro podnik neúměrně drahé. S vydáním verze 8.0 se muselo změnit zaměření: náklady na řešení se výrazně zvýšily, 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ázkou. Hlavní informační systém moderního podniku musí splňovat alespoň následující požadavky na zabezpečení:

Poměrně nízká pravděpodobnost selhání systému z vnitřních důvodů.
Spolehlivá autorizace uživatelů 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 takové požadavky? Neexistuje jediná odpověď. I přes významné změny v systému řízení přístupu je stále mnoho nevyřešených problémů. V závislosti na tom, jak je systém vyvíjen a konfigurován, nemusí být všechny tyto požadavky splněny nebo jsou splněny v dostatečné míře pro tuto implementaci, nicméně stojí za to věnovat pozornost (a to je významný důsledek „mládí“ platformy ) že k plnému splnění uvedených podmínek musí člověk skutečně vyvinout titánské úsilí.

Tento článek je určen vývojářům a implementátorům řešení na platformě 1C: Enterprise, jakož i správcům systému organizací, kde se používá 1C: Enterprise, a popisuje některé aspekty vývoje a konfigurace verze systému klient-server z pohledu organizace. informační bezpečnost... Tento článek nelze použít jako náhradu za dokumentaci, ale uvádí pouze některé body, které v něm dosud nebyly zohledněny. A samozřejmě ani tento článek, ani veškerá dokumentace nebude schopna odrážet složitost problému budování zabezpečeného informačního systému, který musí současně splňovat protichůdné požadavky na bezpečnost, výkon, pohodlí a funkčnost.

Klasifikace a terminologie

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

Informační hrozba- možnost situace, kdy budou data neoprávněně čtena, kopírována, upravována nebo blokována.

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

Neoprávněné zničení dat
Neoprávněná úprava ú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é. Zavolá se implementovaná informační hrozba incident... Vlastnosti systému jsou následující:

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

V zásadě se berou v úvahu pouze ty případy, jejichž pravděpodobnost je dána použitím technologické platformy 1C: Enterprise 8.0 ve verzi klient-server (dále v případech, kdy to neodporuje smyslu pouze 1C nebo 1C 8.0 ). Pojďme definovat následující hlavní role ve vztahu k používání systému:

Operátoři- uživatelé, kteří mají práva na prohlížení a úpravu dat omezených na roli 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 serveru MS SQL, práva správce pro MS SQL atd.
Správci informační bezpečnosti- uživatelé, kterým jsou v infobáze 1C delegovány určité administrativní funkce (například přidávání uživatelů, testování a oprava, záloha(nastavení aplikovaného řešení atd.)
Systémoví vývojáři- uživatelé vyvíjející aplikované řešení. Obecně nemusí mít přístup k pracovnímu systému.
Osoby bez přímého přístupu do systému- uživatelé, kterým nejsou delegována práva na přístup k 1C, ale kteří mohou tak či onak ovlivnit provoz 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 primárně určena k identifikaci potenciálně nebezpečných subjektů v systému.
Automatizované administrativní skripty- programy, na které 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é, tato klasifikace je velmi hrubá a nebere v úvahu 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 ovlivnit fungování systém, který musí být vybaven prostředky vně 1C.

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

hodnota chráněných informací;
náklady na vytvoření incidentu (v případě záměrného ohrožení);
finanční rizika v případě incidentu

Je nesmyslné a škodlivé organizovat ochranu, která je mnohem dražší než posuzovat její finanční účinnost. Existuje několik metod pro hodnocení rizik ztráty informací, ale v tomto článku nejsou zohledněny. Dalším důležitým aspektem je udržování rovnováhy často protichůdných požadavků na informační bezpečnost, výkon systému, pohodlí a jednoduchost práce se systémem, rychlost vývoje a implementace a další požadavky na informační systémy podniků.

Hlavní rysy mechanismu zabezpečení informací systému

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

Data a konfigurace jsou uloženy v souboru, který mohou číst a zapisovat všichni uživatelé systému.
Jak bude ukázáno níže, autorizaci systému lze velmi snadno obejít.
Integrita systému je zajištěna pouze jádrem na straně klienta.

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

Spolehlivější ukládání dat.
Izolace souborů z přímého přístupu.
Lepší transakční a zamykací mechanismy.

Navzdory značným rozdílům mezi souborovou a klientsko-serverovou verzí systému mají jedno 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 aktuálním uživatelem Windows.
Přiřazení rolí uživatelům systému.
Omezení provádění administrativních funkcí podle rolí.
Přiřazení dostupných rozhraní podle role.
Omezení přístupu k objektům metadat podle role.
Omezení přístupu k atributům objektu podle role.
Omezení přístupu k datovým objektům podle rolí a parametrů relace.
Omezení interaktivního přístupu k datům a spustitelným modulům.
Některá omezení při provádění kódu.

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

Velký počet fází zpracování dat a v každé fázi mohou platit různá pravidla pro přístup k objektům.

Poněkud zjednodušený diagram kroků zpracování dat, které jsou významné z hlediska zabezpečení, je znázorněno na obr. Obecným pravidlem pro 1C je omezit omezení, když se pohybujete po tomto schématu, a tedy využívat zranitelnost na jednom z nich vyšší úrovně může narušit provoz systému na všech úrovních.
Nedostatečně odladěné postupy pro ovládá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ž ladění je na jedné straně vždy časově náročnější, ale na druhé straně zodpovědnější. Tato „nemoc“ není problémem výhradně pro 1C, nachází se v mnoha serverových produktech většiny prodejců. Až v posledních letech se pozornost k těmto problémům výrazně zvýšila.
Nedostatečně vysoká průměrná kvalifikace vývojářů a správců systému zděděná z předchozí verze.

Produkty řady 1C: Enterprise byly původně zaměřeny na snadný vývoj a podporu a na práci v malých organizacích, takže není divu, že historicky významná část „vývojářů“ aplikačních řešení a „správců“ systémů ne mít dostatečné znalosti a dovednosti pro práci s mnohem složitějším produktem, kterým je verze 8.0. Problém je zhoršen praxí zavedenou ve franšízových společnostech, která cvičí „v bitvě“ na úkor klientů, aniž by k tomuto problému přistupovala systematicky. Je nutné vzdát hold společnosti 1C, že se v posledních letech tato situace postupně zlepšuje: seriózní franšízové společnosti začaly přistupovat k problému náboru a školení personálu zodpovědněji, úroveň podpory informačních technologií od 1C se zvýšila významně se objevily certifikační programy zaměřené na vysokou úroveň služeb; situaci však nelze okamžitě napravit, proto by tento faktor měl být vzat v úvahu při analýze zabezpečení systému.
Poměrně malý věk platformy.

Mezi produkty s podobným zaměřením a účelem použití se jedná o jedno z nejmladších řešení. Funkčnost platformy byla víceméně vyřízena před necelým rokem. Současně se každé vydání platformy, počínaje verzí 8.0.10 (právě v této verzi byly implementovány téměř všechny současné možnosti systému), stalo mnohem stabilnějším než předchozí. Funkčnost typických aplikačních řešení stále skokově roste, i když se využívá maximálně polovina možností platformy. V takových podmínkách můžeme samozřejmě hovořit o stabilitě spíše předběžně, ale obecně je třeba přiznat, že v mnoha ohledech řešení na platformě 1C 8.0 výrazně překonává podobná řešení na platformě 1C 7.7, pokud jde o funkčnost a výkon (a často stabilita).

Systém (a případně typické aplikační řešení) je tedy nasazen v podniku a nainstalován na počítačích. Nejprve je nutné vytvořit prostředí, ve kterém má smysl konfigurovat zabezpečení 1C, a za tímto účelem musí být nakonfigurováno tak, aby byl splněn předpoklad, že nastavení systému jsou výrazně ovlivněna nastavením systému.

Při nastavování zabezpečení dodržujte obecná pravidla.

Pokud nebudou dodrženy základní principy vytváření zabezpečených systémů, nemůže být řeč o žádné informační bezpečnosti systému. Ujistěte se, že jste splnili alespoň následující podmínky:

Přístup na servery je fyzicky omezen a je zajištěn jejich nepřetržitý provoz:
- serverové zařízení splňuje požadavky na spolehlivost, výměna vadného serverového zařízení je odladěna, v obzvláště kritických oblastech se používají redundantní obvody Hardware(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 byl vyvinut systém oznámení pro odpovědné osoby;
- je zajištěno nepřetržité napájení serverů
- je zajištěn normální klimatický režim provozu zařízení;
- v serverovně je požární poplach, není zde možnost zaplavení (zejména pro první a poslední patro);
Nastavení síťové a informační infrastruktury podniku je správné:
- všechny servery mají nainstalované a nakonfigurované brány firewall;
- všichni uživatelé a počítače jsou autorizováni v síti, hesla jsou natolik složitá, že je nelze uhodnout;
- provozovatelé systémů mají dostatečná práva, aby s nimi mohli normálně pracovat, ale nemají práva na administrativní akce;
- 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 na internet a na vyměnitelná média by měl být regulován a omezen;
- musí být nakonfigurován systémový audit bezpečnostních událostí;
Byly vyřešeny hlavní organizační problémy:
- 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ích pravidel;
- pro každý hmotný prvek informačního systému byli jmenováni finančně odpovědné osoby;
- Všechno systémové bloky zapečetěné a uzavřené;
- Věnujte zvláštní pozornost poučení a dohledu nad čističi, staviteli a elektrikáři. Tyto osoby mohou z nedbalosti způsobit škodu, která není srovnatelná s úmyslnou újmou způsobenou bezohledným uživatelem systému.

Pozornost! Tento seznam není vyčerpávající, ale pouze popisuje, co je při zavádění jakéhokoli poměrně složitého a nákladného informačního systému často přehlíženo!

MS SQL Server, aplikační server a klientská strana pracují na různých počítačích, serverové aplikace pracují pod právy speciálně vytvořených Uživatelé Windows;
Pro MS SQL Server
- je nastaven smíšený režim autorizace
- Uživatelé MS SQL zahrnutí v roli správce serveru se neúčastní práce 1C,
- pro každý IS 1C byl vytvořen samostatný uživatel MS SQL, který nemá privilegovaný přístup k serveru,
- uživatel MS SQL jedné informační bezpečnosti nemá přístup k další informační bezpečnosti;
Uživatelé nemají přímý přístup k souborům Application Server a MS SQL Server
Pracoviště obsluhy jsou vybavena Windows 2000 / XP (ne Windows 95/98 / Me)

Nezanedbávejte doporučení vývojářů systému a čtení dokumentace. Na discích ITS v části „Metodická doporučení“ jsou zveřejněny důležité materiály o ladění systému. Věnujte zvláštní pozornost následujícím článkům:

Funkce aplikace fungují se serverem 1C: Enterprise
Umístění dat 1C: Enterprise 8.0
Aktualizace 1C: Enterprise 8.0 uživateli Microsoft Windows bez práv správce
Úprava seznamu uživatelů jménem uživatele, který nemá práva správce
Konfigurace nastavení brány firewall systému Windows XP SP2 pro spuštění systému SQL Server 2000 a SQL Server Desktop Engine (MSDE)
Konfigurace parametrů COM + Windows XP SP2 pro provoz serveru 1C: Enterprise 8.0
Konfigurace parametrů brány firewall systému Windows XP SP2 pro provoz serveru 1C: Enterprise 8.0
Konfigurace nastavení brány firewall systému Windows XP SP2 pro Správce licencí HASP
Vytvoření záložní kopie informační základny pomocí serveru SQL Server 2000
Otázky instalace a konfigurace 1C: Enterprise 8.0 ve volbě „klient-server“(jeden z nejdůležitějších článků)
Zvláštnosti Nastavení systému Windows Server 2003 při instalaci serveru 1C: Enterprise 8.0
Regulace přístupu uživatelů k infobase ve verzi klient-server(jeden z nejdůležitějších článků)
Server 1C: Enterprise a SQL Server
Podrobný postup instalace 1C: Enterprise 8.0 ve verzi „klient-server“(jeden z nejdůležitějších článků)
Použití vestavěného jazyka na serveru 1C: Enterprise

Při čtení dokumentace však buďte kritičtí vůči informacím přijatým například v článku „Otázky instalace a konfigurace 1C: Enterprise 8.0 ve volbě„ klient-server “, práva, která jsou vyžadována pro uživatele USER1CV8SERVER, nejsou docela přesně popsáno. Níže budou uvedeny odkazy na níže uvedený seznam, například [ITS1] znamená článek „Zvláštnosti práce se serverem 1C: Enterprise“. Všechny odkazy na články jsou v době psaní (leden 2006) uvedeny na nejnovější vydání ITS

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

Ze dvou možných režimů autorizace uživatele: vestavěný 1C a kombinovaný s autorizací operačního systému Windows - pokud je to možné, měli byste zvolit kombinovanou autorizaci. To umožní uživatelům, aby se při práci nezaměňovali s více hesly, ale nesníží to úroveň zabezpečení systému. I pro uživatele, kteří používají pouze autorizaci systému Windows, je však velmi žádoucí při vytváření nastavit heslo a teprve poté deaktivovat autorizaci 1C pro daný uživatel... Aby byla zajištěna obnova systému v případě zničení struktury Active Directory, je nutné ponechat alespoň jednoho uživatele, který může vstoupit do systému pomocí autorizace 1C.

Při vytváření rolí řešení aplikace nepřidávejte práva „v záloze“

Každá role řešení aplikace musí odrážet minimální požadovanou sadu práv k provádění akcí definovaných touto rolí. Některé role však nemusí být použity samostatně. Například pro interaktivní spuš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žít externí zpracování.

Pravidelně kontrolujte protokoly a protokoly systému

Kdykoli je to možné, regulujte a automatizujte kontrolu 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 zjistit včas nebo jim dokonce zabránit během přípravné fáze.

Některé funkce verze klient-server

Tato část popisuje některé funkce verze klient-server a jejich dopad na zabezpečení. Pro lepší čitelnost jsou akceptována následující označení:

Pozornost! popis zranitelnosti

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

Uložení seznamu uživatelů zabezpečení informací

Všechny informace o seznamu uživatelů tohoto IS a rolích, které jsou mu k dispozici, 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, nemůže tuto skutečnost sám útočník využít, nicméně pokud je možné kód spustit v MS SQL, „otevírá to dveře“ k získání libovolného (! ) Přístup z 1C ... Stejný mechanismus (s drobnými změnami) lze použít pro souborovou verzi systému, což vzhledem ke zvláštnostem verze souboru zcela vylučuje její použitelnost při budování zabezpečených systémů.

Doporučení: V současné době neexistuje způsob, jak aplikaci před takovou změnou zcela chránit, kromě použití spouštěčů na úrovni MS SQL Serveru, což na druhou stranu může způsobovat problémy při aktualizaci verze platformy nebo změně seznamu uživatelů . Chcete -li sledovat tyto změny, můžete použít protokoly 1C (dávat pozor na „podezřelá“ přihlášení v režimu konfigurátoru bez uvedení uživatele) nebo nechat SQL Profiler neustále spuštěný (což bude mít extrémně negativní vliv na výkon systému) nebo nakonfigurovat výstrahy mechanismus (s největší pravděpodobností společně pomocí spouště)

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

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á infobase používá svůj vlastní připojovací řetězec mezi aplikačním serverem a serverem MS SQL. Informace o informačních databázích registrovaných na aplikačním serveru spolu s připojovacími řetězci jsou uloženy v souboru srvrib.lst, který je umístěn na serveru v adresáři<Общие данные приложений>/ 1C / 1Cv8 (například C: / Dokumenty a nastavení / Všichni uživatelé / Data aplikace / 1C / 1Cv8 / srvrib.lst). Pro každé zabezpečení informací je uložen kompletní připojovací řetězec včetně uživatelského hesla MS SQL při použití smíšeného autorizačního modelu 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 privilegovaný uživatel použit pro přístup alespoň k jedné databázi (například „sa“), pak kromě ohrožení jednoho IS je ohrožen celý systém využívající 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 přístupu k tomuto souboru. Klíčové negativní vlastnosti autorizace systému Windows tedy budou:

Provoz veškerého zabezpečení informací na aplikačním serveru a na serveru MS SQL pod jednou sadou práv (pravděpodobně nadbytečných)
Z procesu aplikačního serveru 1C (nebo obecně od uživatele USER1CV8SERVER nebo jeho analoga) bez zadání hesla se můžete snadno připojit k jakémukoli 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ž načíst zadaný soubor. Mimochodem, přítomnost takového souboru je dalším argumentem pro oddělení funkcí serveru na různých počítačích.

Doporučení: Soubor srvrib.lst by měl být přístupný pouze procesu serveru. Chcete -li tento soubor změnit, nezapomeňte nastavit audit.

Ve výchozím nastavení je tento soubor bohužel téměř zcela nečitelný, což je třeba vzít v úvahu při nasazení systému. Ideální možností by bylo, kdyby aplikační server zabránil čtení a zápisu tohoto souboru během provozu (včetně čtení a zápisu prostřednictvím uživatelských připojení prováděných na tomto serveru).

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

Pozornost! Chyba autorizace byla opravena ve verzi 8.0.14 platformy 1C: Enterprise. Tato verze zavádí koncept „1C: Enterprise Server Administrator“, ale přestože 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í této části je možnost přidat téměř neomezené zabezpečení informací na aplikační server, v důsledku čehož každý uživatel, který má přístup k připojení k aplikačnímu serveru, automaticky dostane příležitost spustit libovolný kód na aplikačním serveru . Podívejme se na příklad.

Systém musí být nainstalován v následující variantě

MS SQL Server 2000 (např. 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 jednomu z IB registrovaných na SRV2, ale nemá privilegovaný přístup k SRV1 a SRV2. Na situaci obecně nemá vliv kombinace funkcí uvedených počítačů. Systém byl nakonfigurován s přihlédnutím k doporučením v dokumentaci a na discích ITS. Situace se odráží 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í (dočasně povolit zápis pro přidání nového IB na server);

pro připojení k MS SQL použijte pouze protokol TCP / IP, v tomto případě můžete:
omezit připojení pomocí brány firewall;

nakonfigurovat použití nestandardního portu TCP, což zkomplikuje připojení „outsiderů“ IS 1C;

používat šifrování přenášených dat mezi aplikačním serverem a serverem SQL;

nakonfigurujte bránu firewall serveru tak, aby nebylo možné používat servery MS SQL třetích stran;

použijte nástroje zabezpečení intranetu k vyloučení možnosti, že se v něm objeví neoprávněný počítač lokální síť(IPSec, zásady zabezpečení skupiny, brány firewall atd.);

za žádných okolností neudělujte administrátorská práva USER1CV8SERVER na aplikačním serveru.

Použití kódu spuštěného na serveru

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

# If Server Then
Funkce OnServer (Param1, Param2 = 0) Export // Tato funkce je navzdory své jednoduchosti spuštěna na serveru
Param1 = Param1 + 12;
Návrat Param1;
Koncová funkce
# EndIf

Při používání kódu, který běží na serveru, mějte na paměti, že:

kód je spuštěn s právy USER1CV8SERVER na aplikačním serveru (objekty COM a soubory serveru jsou k dispozici);
všechny relace uživatelů jsou prováděny jednou instancí služby, proto například přetečení zásobníku na serveru způsobí odpojení všech aktivních uživatelů;
ladění serverových modulů je obtížné (například v ladicím programu nelze nastavit zarážku), ale musí být provedeno;
přenos řízení z klienta na aplikační server a naopak může vyžadovat značné prostředky s velkými objemy přenášených parametrů;
používání interaktivních nástrojů (formuláře, tabulkové dokumenty(dialogová okna), externí zprávy a zpracování 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 indikací „Export“) není povoleno;

Další podrobnosti viz [ITS15] a další články ITS.

Aplikační server musí mít speciální požadavky na spolehlivost. Ve správně vybudované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 server (kromě administrativních případů);
server nelze spustit programový kód obdržel od klienta;
prostředky by měly být „spravedlivě“ distribuovány mezi klientská připojení, zajišťující dostupnost serveru bez ohledu na aktuální zatížení;
při absenci datových zámků by připojení klientů nemělo navzájem ovlivňovat práci;
na serveru není žádné uživatelské rozhraní, ale měly by být vyvinuty nástroje pro monitorování a protokolování;

Systém 1C je obecně postaven tak, aby odpovídal těmto požadavkům (například není možné vynutit, aby bylo externí zpracování prováděno na serveru), ale stále existuje několik nepříjemných funkcí, proto:

Doporučení: Při vývoji provádění na straně serveru se doporučuje dodržovat 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řijímání parametrů procedur a funkcí na server je nutné parametry ověřit (zkontrolovat, zda parametry odpovídají očekávanému typu a rozsahu hodnot). To se ve standardních řešeních nedělá, ale je velmi žádoucí zavést povinné ověřování ve vašich vlastních návrzích. Doporučení: Při generování textu požadavku (a ještě více parametru příkazu Spustit) na straně serveru nepoužívejte řetězce přijaté z klientské aplikace.

Obecným doporučením by bylo seznámit se se zásadami budování bezpečí web- databázové aplikace a práce na podobných principech. Podobnost je opravdu značná: za prvé, jako webová aplikace je aplikační server mezivrstva mezi databází a uživatelským rozhraním (hlavní rozdíl je v tom, že uživatelské rozhraní tvoří webový server); za druhé, z hlediska zabezpečení nelze datům přijatým od klienta důvěřovat, protože je možné spustit externí zprávy a zpracování.

Předávání parametrů

Předání parametrů funkci (proceduře) provedené na serveru je poměrně choulostivý problém. Je to primárně kvůli potřebě jejich přenosu mezi procesem aplikačního serveru a klientem. Když je řízení přeneseno z klientské strany na serverovou stranu, 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 se proces obrátí. Zde je třeba poznamenat, že toto schéma správně zpracovává předávání parametrů podle odkazu a podle hodnoty. Při přenosu parametrů platí následující omezení:

Mezi klientem a serverem (v obou směrech) lze přenášet pouze neměnné hodnoty (tj. Jejichž hodnoty se nemohou měnit): primitivní typy, odkazy, univerzální kolekce, hodnoty systémového 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í odeslat nesprávný parametr).
Při předávání parametrů se nedoporučuje přenášet velké množství dat (například řetězce s více než 1 milionem znaků), což může negativně ovlivnit výkon serveru.
Nemůžete předávat parametry obsahující cyklický odkaz, a to ze serveru na klienta a naopak. Při pokusu o předání takového parametru dojde ke zhroucení klientské aplikace (i když se server pokusí předat nesprávný parametr).
Nedoporučuje se přenášet velmi složité kolekce dat. Při pokusu o předání parametru s velmi velkou úrovní vnoření server havaruje (!).

Pozornost! V tuto chvíli je nejnepříjemnější vlastností pravděpodobně chyba předávání složitých sbírek hodnot. Například kód: Úroveň vnoření = 1250;
M = Nové pole;
TransmittedParameter = M;
Pro MF = 1 cyklem vnořování
MVint = Nové pole;
M. Přidat (MVintr);
M = MVintr;
Konec cyklu;
ServerFunction (PassedParameter);

Způsobí pád serveru se všemi odpojenými uživateli a to se stane před tím, než se ovládací prvek přenese do kódu vloženého jazyka.

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

V kódu běžícím na aplikačním serveru nelze použít všechny funkce integrovaného jazyka, ale i mezi dostupnými nástroji existuje mnoho „problémových“ konstrukcí, které lze zhruba klasifikovat takto:

schopen poskytnout schopnost spouštět kód, který není obsažen v konfiguraci (skupina "Provádění kódu")
schopné poskytovat klientské aplikaci informace o uživatelském souboru a operačním systému nebo provádět akce, které nesouvisejí s prací s daty („Porušení práv“)
schopné způsobit nouzové zastavení serveru nebo použití velmi velkých zdrojů (skupina „Selhání serveru“)
schopné způsobit selhání v práci klienta (skupina „Selhání klienta“) - tento typ není brán v úvahu. Příklad: předání proměnné hodnoty na server.
chyby programovacích algoritmů (nekonečné smyčky, neomezená rekurze atd.) („Chyby programování“)

Níže jsou uvedeny hlavní problémové konstrukty, které jsou mi známy (s příklady):

Postup Provést (<Строка>)

Provedení kódu. Spustí kus kódu, který je mu předán jako hodnota řetězce. Při použití na serveru musíte zajistit, aby data přijatá od klienta nebyla použita jako parametr. Následující použití je například neplatné:
# If Server Then
Postup při exportu serveru (Param1)
Execute (Param1);
Konec postupu
# EndIf

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

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

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

Porušení práv a spuštění kódu. Podobně jako v předchozím případě se získá pouze objekt COM odpovídající souboru.

Procedury a funkce ComputerName (), TempFilesDirectory (), ProgramsDirectory (), Windows Users ()

Porušení práv. Umožněte po jejich provedení na serveru zjistit podrobnosti o organizaci serverového subsystému. Při použití na serveru zajistěte, aby data nebyla přenášena na klienta nebo nebyla k dispozici operátorům bez příslušného oprávnění. Zvláštní pozornost věnujte skutečnosti, že data lze předávat zpět v parametru předávaném referencí.

Postupy a funkce pro práci se soubory (CopyFile, FindFiles, CombineFiles a mnoho dalších), stejně jako typy „Soubor“.

Porušení práv. Umožněte jejich spuštěním na serveru získat obecný 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. Pokud jsou použity záměrně, je možné efektivně implementovat úkoly, jako je import / export dat na serveru.

Před použitím těchto funkcí nezapomeňte zkontrolovat uživatelská práva 1C. Chcete -li zkontrolovat uživatelská práva, můžete v modulu serveru použít následující konstrukci:
# If Server Then
Postup ExecuteWork s exportem File ()
RoleAdministrator = Metadata.Role.Administrator;
Uživatel = SessionParameters.CurrentUser;
Pokud 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 hrozí riziko, že omylem nebo záměrně způsobíte nenapravitelné poškození aplikačnímu serveru 1C, například při provádění kódu na serveru:
Cesta = "C: \ Dokumenty a nastavení \ Všichni uživatelé \ Data aplikace \ 1C \ 1Cv8 \";
MoveFile (Path + "srvrib.lst", Path + "Here'sWhereFile");
Po spuštění takového kódu na serveru, pokud má uživatel USER1CV8SERVER oprávnění jej změnit, jak je popsáno výše, a po restartování procesu serveru (standardně 3 minuty po odhlášení všech uživatelů) vyvstane VELKÁ otázka ohledně spuštění serveru . Ale je to možné a úplné odstranění soubory ...

Typy „XBase“, „BinaryData“, „Read XML“, „Write XML“, „Transform XSL“, „Write ZipFile“, „ReadZipFile“, „ReadText“, „WriteText“

Porušení práv. Jejich spuštěním na serveru umožňují přístup k místním (a umístěným v síti) souborům určitých typů a jejich čtení / zápis pod právy uživatele USER1CV8SERVER. Pokud jsou použity záměrně, je možné efektivně implementovat takové úkoly, jako je import / export dat na server, protokolování některých funkcí a řešení administrativních úkolů. Obecně jsou doporučení stejná jako v předchozím odstavci, měli byste však vzít v úvahu možnost přenosu dat těchto souborů (nikoli však objektů všech těchto typů) mezi klientskou a serverovou částí.

Typ systémových informací

Porušení práv. Umožňuje, pokud jsou data nesprávně použita a přenesena do klientské části aplikace, můžete získat data o aplikačním serveru. Při používání je vhodné omezit právo na používání.

Typy „InternetConnection“, „InternetMail“, „InternetProxy“, „HTTPConnection“, „FTPConnection“

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

Řízení parametrů při volání metod.

Kontrola uživatelských práv 1C.

Silná omezení práv uživatele USER1CV8SERVER na přístup k síti.

Správná konfigurace 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šení práv. Při nesprávném použití (v privilegovaném modulu) je možné přidávat uživatele nebo měnit autorizační parametry stávajících uživatelů.

Formát funkce

Selhání serveru. Ano! Tato zdánlivě neškodná funkce, pokud neovládáte její parametry a nespouštíte ji na serveru, může způsobit neobvyklé ukončení serverové aplikace. Chyba se projevuje například při formátování čísel a používání výstupního režimu pro úvodní nuly a velký počet znaků, například
Formát (1, "CHT = 999; CHVN =");
Doufám, že tato chyba bude opravena v dalších vydáních platformy, ale prozatím u všech volání této funkce, které lze provést na serveru, zkontrolujte parametry volání.

Procedury a funkce pro ukládání hodnot (ValueInStringInternally, ValueInFile)

Selhání serveru. Tyto funkce nezpracovávají cyklické odkazy ve sbírkách a velmi hluboké vnořování, takže mohou v některých velmi zvláštních případech selhat.

Chyby hraničních a speciálních hodnot parametrů ve funkcích. Kontrola provádění.

Jedním z problémů, se kterými se lze setkat při používání serveru, je velká „odpovědnost“ za funkce serveru (možnost abnormálního ukončení celé serverové aplikace z důvodu chyby v jednom připojení a použití jednoho „prostoru zdrojů“ pro všechna připojení). Proto je potřeba řídit hlavní parametry modulu runtime:

U vestavěných jazykových funkcí zkontrolujte jejich parametry spuštění (ukázkovým příkladem je funkce „Formát“)
Při používání smyček se ujistěte, že je spuštěna podmínka ukončení smyčky. Pokud je smyčka potenciálně nekonečná, uměle omezte počet iterací: MaximumIterationCount = 1 000 000;
Počet iterací = 1;
sbohem
Funkce, která nemůže vrátit falešnou hodnotu ()
AND (Iterační čítač<МаксимальноеЗначениеСчетчикаИтераций) Цикл
// .... tělo smyčky
Iterační čítač = Iterační čítač + 1;
Konec cyklu;
IfIterationCount> MaximumIterationCounterValue Then
// .... zvládněte událost příliš dlouhého provádění cyklu
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 HIERARCHY“ nepoužívejte prázdnou hodnotu)
Při navrhování infobáze poskytněte dostatečně velkou rezervu číslicové kapacity pro čísla (jinak se sčítání a násobení stává nekomutativní a neasociativní, což ztěžuje ladění)
V požadavcích spustitelných souborů zkontrolujte logiku práce na přítomnost Hodnoty NULL a správnou práci podmínky a výrazy dotazu pomocí NULL.
Při používání kolekcí ovládejte možnost jejich přenosu mezi aplikačním serverem a klientem.

Omezení přístupu pomocí terminálu na straně klienta

Není neobvyklé najít doporučení pro použití terminálového přístupu k omezení přístupu k datům a zvýšení výkonu spuštěním kódu na straně klienta na terminálovém serveru. Ano, pokud je správně nakonfigurován, může použití terminálového přístupu skutečně zvýšit celkovou úroveň zabezpečení systému, ale bohužel se často lze setkat s tím, že v praktickém používání zabezpečení systému pouze klesá. Pokusme se zjistit, s čím to souvisí. Nyní existují dva běžné způsoby organizace přístupu k terminálu, a to jsou Microsoft Terminal Services (protokol RDP) a Citrix Metaframe Server (protokol ICA). Nástroje Citrix obecně poskytují mnohem flexibilnější možnosti správy přístupu, ale náklady na tato řešení jsou výrazně vyšší. Budeme zvažovat pouze základní funkce společné pro oba protokoly, 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 zablokovat práci ostatních uživatelů zabavením nadměrného množství zdrojů
Přístup k údajů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í:

Zvyšte spolehlivost práce (v případě poruchy na koncovém počítači může uživatel 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 pracoviště uživatele na server terminálového přístupu
Spravujte nastavení systému centrálněji. Pro uživatele bude uložené nastavení platné bez ohledu na počítač, ze kterého se přihlásili.
V některých případech můžete pro vzdálený přístup do systému použít terminálové řešení.

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

Vzhledem k „obžerství“ klientské aplikace 1C s ohledem na zdroje 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 se aktivně využívá čas procesoru, což také nepřispívá ke stabilitě uživatelů tohoto serveru. Spolu s prevencí nadužívání serverových prostředků může toto omezení zabránit v používání účtu někoho jiného. Implementováno standardním nastavením terminálového serveru.

Nesmíte povolit, aby v jednom připojení běželo více než jedna nebo dvě klientské aplikace 1C

Diktováno stejnými důvody jako v předchozím odstavci, ale technicky náročnější na implementaci. Problém je v tom, že je téměř nemožné zabránit restartu 1C pomocí terminálového serveru (níže bude vysvětleno proč), takže tuto funkci musíte implementovat na úrovni aplikovaného řešení (což také není dobré řešení, protože v případě nesprávného ukončení aplikace mohou nastat „visící“ relace, je nutné upřesnit aplikované ř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 spustit 2 aplikace, aby mohl spouštět některé akce (například generování zpráv) v Pozadí- klientská aplikace je bohužel ve skutečnosti s jedním vláknem.

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ě náročné úlohy náročné na zdroje v 1C nebo zabránit takovému spouštění během aktivní práce ostatních uživatelů.

Samozřejmě je lepší ponechat přístup k terminálovému serveru pouze uživatelům, kteří nepoužívají takové úlohy, jako je dolování dat, geografická schémata, import / export a další úkoly, které vážně načítají klientskou stranu aplikace. Pokud je přesto potřeba tyto úkoly vyřešit, pak je nutné: upozornit uživatele, že tyto úkoly mohou ovlivnit výkon ostatních uživatelů, zaznamenat událost začátku a konce takového procesu do protokolu , povolit provedení pouze v naplánovaném čase atd.

Je nutné zajistit, aby každý uživatel mohl zapisovat pouze do přesně definovaných adresářů terminálového serveru a ostatní uživatelé k nim neměli přístup.

Za prvé, pokud neomezíte možnost zápisu do sdílených adresářů (například do adresáře, kde je nainstalován 1C), pak může útočník změnit chování programu pro všechny uživatele. Za druhé, data jednoho uživatele (dočasné soubory, soubory pro ukládání nastavení sestav atd.) By v žádném případě neměla být dostupná jinému uživateli terminálového serveru - obecně je toto pravidlo při normálním nastavení splněno. Za třetí, útočník má stále možnost „vrhnout“ oddíl tak, aby na pevném disku nezbylo místo. Vím, budou mi oponovat, že v systému Windows, počínaje Windows 2000, existuje mechanismus kvót, ale toto je poměrně drahý mechanismus a já jsem ho prakticky neviděl.

Pokud byly předchozí otázky nastavení přístupu obecně poměrně snadno implementovatelné, pak již tak (zdánlivě) jednoduchý úkol, jako je regulace přístupu uživatelů k souborům, je implementován netriviálně. Za prvé, pokud není použit mechanismus kvóty, 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 k dispozici jinému uživateli.

Vzhledem k tomu, že úkol je zcela obtížně řešitelný, doporučujeme auditovat většinu událostí souboru

Je nutné zakázat 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, portů schránky koncového počítače k serveru. Pokud existuje tato možnost, pak je téměř nemožné zakázat spuštění cizího kódu na terminálovém serveru a ukládání dat z 1C na klienta pro přístup k terminálu. Povolte tyto funkce pouze jednotlivcům s právy správce.

Přístup k síťovým souborům z terminálového serveru musí být omezen.

Pokud se tak nestane, může uživatel znovu spustit nechtěný kód nebo uložit data. Protože pravidelný protokol nesleduje události souborů (mimochodem, je to dobrý nápad pro implementaci vývojáři platformy) a je téměř nemožné konfigurovat audit systému v celé síti (na jeho obsluhu nebude dostatek zdrojů) , je lepší, když uživatel může odesílat data nebo tisknout, 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 nechávat aplikační server na terminálovém serveru.

Pokud je aplikační server spuštěn na stejném počítači jako klientské aplikace, existuje mnoho příležitostí, jak narušit jeho normální provoz. Pokud z nějakého důvodu nelze oddělit funkce terminálového serveru a aplikačního serveru, věnujte zvláštní pozornost přístupu uživatelů 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.

Jedná se o jednu z nejobtížněji realizovatelných položek přání. Nejprve je třeba správně nakonfigurovat zásady zabezpečení skupiny pro doménu. Všechny šablony pro správu a zásady omezení softwaru musí být správně nakonfigurovány. Abyste se mohli 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 ostatní aplikace omezené, je v zásadě nemožné zakázat spuštění 1C prostřednictvím systému Windows).

Zvažte omezení běžného deníku (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, pak to bude terminálový server, který bude zaznamenán v registračním protokolu. Ze kterého počítače se uživatel připojil, protokol nehlásí.

Terminálový server - zabezpečení nebo chyba zabezpečení?

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

Práce na straně klienta

Používání aplikace Internet Explorer (IE)

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

Pozornost! Za prvé, pokud je k IE připojen modul spywaru nebo adwaru, bude načten, i když v 1C zobrazíte jakékoli soubory HTML. Zatím jsem neviděl vědomé používání této funkce, ale setkal jsem se v jedné z organizací s načteným „špionážním“ modulem jedné z pornografických sítí, když běžel 1C (antivirový program nebyl aktualizován, příznaky které byly nalezeny: při nastavování brány firewall bylo jasné, že 1C se pokouší připojit k portu 80 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ů, VBScriptu v zobrazených dokumentech HTML, odesílání dat na internet, dokonce otevírání souborů PDF (!), I když v druhém případě žádá „otevřít nebo uložit“. .. obecně, cokoli si vaše srdce přeje. Příklad ne zcela rozumného využ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" prázdného dokumentu.
Smažte text (úplně).
Přejděte na kartu „Zobrazit“ v tomto dokumentu
Pomocí drag-n-drop přesuňte soubor s příponou SWF (jedná se o soubory flash filmů) z otevřeného průzkumníka do okna dokumentu, například z mezipaměti prohlížeče, i když je to možné s hračkou FLASH pro zábavu.
Jak milé! Můžete spustit hračku na 1C!

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

Při práci s polem dokumentu HTML se objeví několik dalších drobných bodů, ale hlavní dva jsou uvedeny. Ačkoli, pokud k těmto funkcím přistupujete kreativně, můžete zorganizovat skutečně úžasné možnosti rozhraní pro práci s 1C.

Použití externích sestav a zpracování.

Pozornost! Externí sestavy a zpracování - na jedné straně je to pohodlný způsob implementace dalších tiskových formulářů, rutinních hlášení, specializovaných sestav, na straně druhé je to potenciální způsob, jak obejít mnoho bezpečnostních omezení 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é výrazně zúžit okruh uživatelů kteří mohou spravovat externí tiskové formuláře, rutinní zprávy a další standardní funkce standardních řešení implementovaných pomocí externích úprav. Například ve výchozím nastavení v SCP mají všechny základní uživatelské role možnost pracovat s referenční knihou dalších tisknutelných formulářů, a to je ve skutečnosti možnost použít jakékoli externí zpracování.

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

Některé ze standardních mechanismů jsou potenciálně nebezpečné a zcela 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 v seznamech vidí, lze odesílat do externích souborů. Jediná věc, kterou lze doporučit, je uchovat protokol pro tisk dokumentů na tiskových serverech. U zvláště kritických formulářů je nutné nakonfigurovat akční panel spojený s polem chráněné tabulky tak, aby z tohoto panelu nebyla dostupná možnost zobrazení seznamu, a deaktivovat místní nabídku (viz obr. 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 přepsat více souborů, může v systému provádět neautorizované změny (i když je to časově velmi náročné). Možnost vytvořit periferní základnu při používání plánů distribuované výměny databází by běžným operátorům neměla být k dispozici.

Standardní výměna dat XML

Ve standardní výměně dat, která se používá pro výměnu mezi typickými konfiguracemi (například „Trade Management“ a „Enterprise Accounting“), je možné v pravidlech výměny specifikovat obslužné rutiny událostí pro načítání a vykládání objektů. To je implementováno získáním obslužné rutiny ze souboru a procedurou "Execute ()" pro standardní zpracování načítání a vykládání souboru (procedura "Execute ()" je spuštěna na straně klienta). Očividně 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í pro generická řešení je ve výchozím nastavení povolena výměna.

Doporučení: omezit přístup k XML-exchange pro většinu uživatelů (ponechat pouze správcům IS). Udržujte protokoly spuštění tohoto zpracování a uložte soubor pro výměnu například jeho odesláním emailem správci IB před načtením.

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

Dalším problémem je přístup uživatelů k obecným sestavám ve výchozím nastavení, zejména ke zprávě konzoly sestav. Tato zpráva se vyznačuje skutečností, že vám umožňuje splnit téměř všechny požadavky na zabezpečení informací, a i když je systém práv 1C (včetně RLS) konfigurován poměrně přísně, umožňuje uživateli získat spoustu „extra“ informací a přinutit server provést takový požadavek, který zabere všechny systémy zdrojů.

Použití režimu celé obrazovky (režim plochy)

Jedním z nejúčinnějších způsobů, jak organizovat specializovaná rozhraní s omezeným přístupem k funkcím programu, je režim hlavní (a možná i jediné) formy na celé obrazovce. V tomto případě neexistují žádné dotazy ohledně přístupnosti, například nabídka „Soubor“ a všechny akce uživatele jsou omezeny možnostmi použitého formuláře. Další podrobnosti viz „Funkce implementace režimu plochy“ na disku ITS.

Záloha

Zálohování pro verzi 1C typu klient-server lze provést dvěma způsoby: odesláním dat do souboru s příponou dt a vytvořením záloh pomocí SQL. První metoda má spoustu nevýhod: je vyžadován výhradní přístup, samotná tvorba kopie trvá mnohem déle, v některých případech (pokud je porušena struktura zabezpečení informací) vytvoření archivu není možné, ale má jednu výhodu - minimální velikost archivu. U zálohování SQL je opak pravdou: kopie je vytvořena na pozadí pomocí serveru SQL, kvůli jeho jednoduché struktuře a nedostatku komprese - to je velmi rychlý proces a pokud fyzická integrita SQL databáze není porušena, zálohování je provedeno, ale velikost kopie se shoduje s pravou velikostí IB v rozbaleném stavu (neprovádí se komprese). Vzhledem k dalším výhodám zálohovacího systému MS SQL je výhodnější jej používat (povoleny jsou 3 typy záloh: plné, rozdílové, kopie protokolu transakcí; je možné vytvářet pravidelně prováděné úlohy; rychle nasazovat záložní kopie a záložní systém; implementovala schopnost předpoví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 zvolit umístění úložiště pro zálohy tak, aby nebyly k dispozici uživatelům.
Potřeba ukládat zálohy ve fyzické vzdálenosti od serveru MS SQL (v případě přírodních katastrof, požárů, útoků atd.)
Možnost udělit práva k zahájení zálohování uživateli, který k zálohám nemá přístup.

Podrobnější informace naleznete v dokumentaci 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 (softwarové i hardwarové), ale jejich proveditelnost do značné míry závisí na správnosti použití a celkovém zabezpečení systému. Budeme zvažovat š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 hlavních chyb návrhu systému využívajícího kryptografické prostředky.

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 Serveru (datové soubory na fyzickém disku)
Šifrování dat uložených v informační bezpečnosti
Externí data (ve vztahu k zabezpečení informací)

U dat uložených na straně klienta a na aplikačním serveru (uložená uživatelská nastavení, seznam zabezpečení informací atd.) Je šifrování odůvodněno pouze ve velmi výjimečných případech, a proto se zde neuvažuje. Při používání kryptografických nástrojů nesmíme zapomenout, ž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.

Všechno bez ochrany připojení k síti 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. K šifrování dat přenášených v místní 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é kontrolu integrity pomocí hashovacích funkcí MD5 nebo SHA1. IPSec může pracovat ve dvou režimech: transportním režimu a tunelovém režimu. Transportní režim je vhodnější pro zabezpečení připojení LAN. Režim tunel lze použít k uspořádání připojení VPN mezi jednotlivými segmenty sítě nebo k zabezpečení 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 centrálně spravovat zabezpečení pomocí nástrojů Active Directory.
Možnost vyloučit neautorizovaná připojení k aplikačnímu serveru a MS SQL serveru (například je možné chránit před neoprávněným přidáním zabezpečení informací na aplikačním serveru).
Odstranění „poslechu“ síťového provozu.
Není třeba měnit chování aplikačních programů (v tomto případě 1C).
Standard takového řešení.

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

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

Podrobný popis implementace zařízení IPSec přesahuje rámec tohoto článku a vyžaduje pochopení základních principů protokolu IP. Abyste správně nakonfigurovali ochranu připojení, přečtěte si odpovídající dokumentaci.

Samostatně je nutné při organizaci připojení VPN zmínit několik aspektů licenční smlouvy s 1C. Faktem je, že navzdory absenci technických omezení je při připojení několika segmentů místní sítě nebo vzdáleného přístupu samostatného počítače k místní síti obvykle zapotřebí několik základních dodávek.

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

Kromě šifrování na síťový protokol, je možné šifrovat data na úrovni protokolu COM +, který je uveden v článku „Regulace přístupu uživatelů k infobase ve verzi klient-server“ ITS. Pro implementaci je nutné nastavit úroveň autentizace „Packet Privacy“ pro volání pro aplikaci 1CV8 ve službě Component Services. Když je tento režim nastaven, balíček je ověřen a šifrován, včetně dat, stejně jako identity a podpisu odesílatele.

Šifrování dat během 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 SSL (Secure Sockets Layer).
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ž SSL.
Pokud je použit protokol Shared Memory (k tomu dochází, pokud jsou aplikační server a MS SQL Server umístěny na stejném počítači), šifrování se v žádném případě nepoužívá.

Chcete -li stanovit potřebu šifrování všech přenášených dat pro konkrétní server MS SQL, použijte nástroj „Server Network Utility“. Spusťte jej a na kartě „Obecné“ zaškrtněte políčko „Vynutit šifrování protokolu“. Metoda šifrování je zvolena v závislosti na metodě používané klientskou aplikací (tj. Aplikačním serverem 1C). Chcete -li používat SSL, musíte ve své síti správně nakonfigurovat vydavatele certifikátů.

Aby bylo možné stanovit potřebu š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 umístěn v „C: \ WINNT \ system32 \ cliconfg.exe“). Stejně jako v předchozím případě zaškrtněte na kartě „Obecné“ zaškrtávací políčko „Vynutit šifrování protokolu“.

Je třeba mít na paměti, že použití šifrování v tomto případě může výrazně ovlivnit výkon systému, zejména při použití dotazů, které vracejí velké množství informací.

Aby byla zajištěna úplnější ochrana 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 komunikaci používat nestandardní port TCP, mějte na paměti, že:

MS SQL Server a Application Server musí používat stejný port.
Při používání bran firewall musí být tento port povolen.
Na MS SQL Server nelze nastavit port, který mohou používat jiné aplikace. Referenční informace naleznete na stránce http://www.ise.edu/in-notes/iana/assignments/port-numbers (adresa URL převzata z webu SQL Server Books Online).
Při použití více instancí MS SQL Server si přečtěte dokumentaci MS SQL pro konfiguraci (část „Konfigurace síťových připojení“).

Za druhé, v nastavení protokolu TCP / IP na serveru MS SQL můžete zaškrtnout políčko „Skrýt server“, které zakazuje odpovědi na požadavky na vysílání pro tuto instanci služby MS SQL Server.

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

Existuje poměrně velký výběr softwarových a hardwarových nástrojů pro šifrování dat umístěných na místním disku (to je standardní schopnost systému Windows používat EFS a používání klíčů eToken a programy třetích stran, jako je Jetico Bestcrypt nebo PGPDisk). Jednou z hlavních úloh prováděných těmito nástroji je ochrana dat v případě ztráty média (například při odcizení serveru). Zvláště je třeba poznamenat, že společnost Microsoft nedoporučuje ukládat databáze MS SQL na šifrovaná média, a to je docela rozumné. Hlavním problémem v tomto případě je výrazný pokles produktivity a možné problémy spolehlivost při selhání. Druhým faktorem komplikujícím život správce systému je nutnost zajistit, aby všechny databázové soubory byly k dispozici 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 znatelnému poklesu výkonu systému, můžete pomocí schopnosti MS SQL vytvářet databáze v několika souborech. Samozřejmě v tomto případě by databáze MS SQL neměla být vytvářena 1C serverem při vytváření infobase, ale měla by být vytvořena samostatně. Níže je uveden příklad skriptu TSQL s komentáři:

POUŽIJTE mistra
JÍT
- Vytvořit databázi SomeData,
VYTVOŘIT DATABÁZI SomeData
- jejichž data jsou zcela umístěna ve skupině souborů PRIMARY.
NA ZÁKLADĚ
- Hlavní datový soubor je umístěn na šifrovaném médiu ( logický pohon E :)
- a má počáteční velikost 100 MB, lze automaticky rozšířit na 200 MB pomocí
- 20 Mb kroky
(NAME = SomeData1,
FILENAME = "E: \ SomeData1.mdf",
VELIKOST = 100 MB,
MAXIMÁLNĚ = 200,
FILEGROWTH = 2),
- Druhý datový soubor je umístěn na nešifrovaném médiu (logická jednotka C :)
- a má počáteční velikost 100 MB, lze ji automaticky zvýšit na limit
- místo na disku s krokem 5% aktuální velikosti souboru (zaokrouhleno nahoru na 64 kB)
(NAME = SomeData2,
FILENAME = "c: \ program files \ microsoft sql server \ mssql \ data \ SomeData2.ndf",
VELIKOST = 100 MB,
MAXSIZE = NEOMEZENO,
FILEGROWTH = 5%)
PŘIHLÁSIT SE
- Přestože protokol transakcí lze také rozdělit na části, toto by nemělo být prováděno,
- od té doby tento soubor se mění mnohem častěji a je pravidelně čištěn (například když
- vytvoření záložní kopie databáze).
(NAME = SomeDatalog,
FILENAME = "c: \ program files \ microsoft sql server \ mssql \ data \ SomeData.ldf",
VELIKOST = 10 MB,
MAXSIZE = NEOMEZENO,
FILEGROWTH = 10)
JÍT
- Je lepší okamžitě dát vlastnictví databáze uživateli, jehož jménem
- 1C bude připojeno. K tomu musíme deklarovat aktuální základnu
- právě vytvořeno,
POUŽIJTE SomeData
JÍT
- a spusťte proceduru sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Malá odbočka k automatickému růstu velikosti datového souboru. Ve výchozím nastavení se u nově vytvořených databází zvětšují velikosti souborů v krocích po 10% aktuální velikosti souboru. Toto je naprosto přijatelné řešení pro malé databáze, ale ne příliš dobré pro velké: s velikostí databáze například 20 GB by měl soubor narůst o 2 GB najednou. Přestože k této události dojde zcela výjimečně, může trvat několik desítek sekund (všechny ostatní transakce jsou ve skutečnosti v tuto chvíli nečinné), což, pokud k ní dojde při aktivní práci s databází, může způsobit některá selhání. Druhým negativním důsledkem proporcionálního zesílení, ke kterému dochází, když je místo na disku téměř úplně plné, je pravděpodobnost předčasného selhání v důsledku nedostatečného volný prostor... Pokud je například 40 GB diskový oddíl zcela přidělen pro jednu databázi (přesněji pro jeden soubor této databáze), pak je kritická velikost databázového souboru, u které je nutné naléhavě (velmi naléhavě, až do přerušení normální práce uživatelů) na reorganizaci úložiště informací je datový soubor o velikosti 35 GB. Se sadou přírůstků 10–20 MB můžete pokračovat v práci, dokud není dosaženo 39 GB.

Přestože tedy daný výpis specifikuje nárůst velikosti jednoho ze souborů databáze v krocích po 5%, pro velké velikosti databáze je lepší nastavit pevný přírůstek 10–20 MB. Při nastavování hodnot přírůstku pro růst velikosti databázových souborů je nutné vzít v úvahu, že než jeden ze souborů ve skupině souborů dosáhne maximální velikosti, platí pravidlo: soubory jedné skupiny souborů rostou všechny současně, když jsou všechny plné. Takže ve výše uvedeném příkladu, když soubor SomeData1.mdf dosáhne maximální velikosti 200 MB, bude soubor SomeData2.ndf mít velikost přibližně 1,1 GB.

Po vytvoření takové databáze, i když budou její nechráněné soubory SomeData2.ndf a SomeData.ldf k dispozici útočníkovi, bude velmi obtížné obnovit skutečný stav databáze - data (včetně informací o logické struktuře databáze) ) budou rozptýleny do několika souborů. Navíc klíčové informace (například o tom, které soubory tvoří tuto databázi) budou v šifrovaném souboru.

Samozřejmě, pokud je použito ukládání databázových souborů pomocí kryptografických prostředků, pak by záloha (alespoň tyto soubory) neměla být prováděna na nešifrovaném médiu. K zálohování jednotlivých databázových souborů použijte příslušnou syntaxi příkazu "BACKUP DATABASE". Pamatujte, že i přes možnost ochrany zálohy databáze heslem (možnosti „PASSWORD =“ a „MEDIAPASSWORD =“ příkazu „BACKUP DATABASE“) se taková záloha nešifruje!

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

Ve většině případů nelze ukládání souborů používaných 1C: Enterprise (na straně klienta a aplikačního serveru) na šifrovaném médiu považovat za oprávněné z důvodu nepřiměřeně vysokých nákladů. Pokud však taková potřeba existuje, mějte na paměti, že aplikační server a klient straně aplikace velmi často vytváří dočasné soubory. Tyto soubory často mohou zůstat i po dokončení aplikace a je téměř nemožné zaručit jejich odstranění pomocí 1C. Zdá se tedy, že zašifruje adresář používaný pro dočasné soubory v 1C nebo jej neukládá na disk pomocí jednotky RAM (druhá možnost není vždy možná vzhledem k velikosti generovaných souborů a požadavkům na velikost paměti RAM 1C: Samotná podniková aplikace).

Šifrování dat s integrovanými nástroji 1C.

Standardní možnosti použití šifrování v 1C se omezují na používání 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 šifrované pomocí AES nejsou pro mnoho archivátorů čitelné (WinRAR, 7zip). Chcete -li vygenerovat soubor obsahující šifrovaná data, musíte zadat heslo a šifrovací algoritmus. Nejjednodušší příkladšifrovací-dešifrovací funkce založené na této schopnosti jsou uvedeny níže:

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

// Zapište data do dočasného souboru. Ve skutečnosti nelze takto uložit všechna data.
ValueInFile (TempFileName, Data);

// Zapište dočasná data do archivu
Zip = nový ZipFileWrite (TemporaryArchiveFileName, heslo, metoda šifrování);
Zip.Add (TemporaryFileName);
Zip.Write ();

// Přečíst data z přijatého archivu do RAM
EncryptedData = NewValueStore (New BinaryData (TemporaryArchiveFileName));

// Dočasné soubory - odstranit

Export funkce EndFunction DecryptData (EncryptedData, Password)

// Pozornost! Správnost předaných parametrů není monitorována

// Zapište předanou hodnotu do souboru
TempFileName = GetTempFileName ("zip");
BinaryArchiveData = EncryptedData.Get ();
BinaryArchiveData.Write (TemporaryArchiveFileName);

// Extrahujte první soubor nově zapsaného archivu
TempFileName = GetTempFileName ();
Zip = New ReadZipFile (TemporaryArchiveFileName, Password);
Zip.Extract (Zip.Elements, TemporaryFileName, ZipFilePath RecoveryMode.NotRecover);

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

// Odstranění dočasných souborů
DeleteFiles (TemporaryFileName);
DeleteFiles (TempArchiveFileName);

Návratová data;

Koncová funkce

Tuto metodu samozřejmě nelze nazvat ideální - data se zapisují do dočasné složky jasným textem, výkon metody, upřímně řečeno, není o nic horší, úložiště v databázi vyžaduje extrémně velké množství místa, ale toto je jediné způsobem, který je založen pouze na vestavěných mechanismech platformy. Navíc má výhodu oproti mnoha dalším metodám - tato metoda současně balí data š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 odkazovat na existující knihovny prostřednictvím vytváření objektů COM, například pomocí Microsoft CryptoAPI. Jako příklad uvedeme funkce pro šifrování / dešifrování řetězce na základě přijatého hesla.

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

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

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

Vrátit EncryptedString;

EndFunction // EncryptStringDES ()

Funkce DecryptStringDES (EncryptedString, heslo)

//Pozornost! Parametry nejsou kontrolovány!

Encryption Engine = Nový COMObject ("CAPICOM.EncryptedData");
Encryption Mechanism.SetSecret (heslo);
Pokus
Encryption Engine.Decrypt (EncryptedString);
Výjimka
// Špatné heslo!;
Vrácení peněz nespecifikováno;
Konec pokusů;

Return Encryption Engine.Content;

EndFunction // DecryptStringDES ()

Všimněte si toho, že předání prázdné hodnoty jako řetězce nebo hesla těmto funkcím vygeneruje chybovou zprávu. Řetězec získaný touto šifrovací procedurou je o něco delší než originál. Specifičnost tohoto šifrování je taková, že pokud zašifrujete řetězec dvakrát, výsledné řetězce NEBUDOU identické.

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

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

Podceňování snížení výkonu při používání kryptografie.

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

Podcenění moderní příležitosti o výběru hesel a klíčů.

V tuto chvíli jsou možnosti technologie takové, že klíč s délkou 40–48 bitů může vyzvednout malá organizace a klíč s délkou 56–64 bitů-velká organizace. Tito. musí být použity algoritmy, které používají klíč alespoň 96 nebo 128 bitů. Většina klíčů je však generována pomocí algoritmů hash (SHA-1 atd.) Na základě hesel zadaných uživatelem. V tomto případě nemusí pomoci ani 1024bitový klíč. Nejprve se často používá heslo, které lze snadno uhodnout. 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; pomocí známých dat, narozenin atd .; používání „šablon“ při generování hesel (například 3 písmena, pak 2 čísla, potom 3 písmena v celé organizaci). Dobré heslo by mělo být celkem náhodnou posloupností malých a velkých písmen, číslic a interpunkčních znamének. Hesla zadaná z klávesnice o délce až 7–8 znaků, i když jsou dodržována tato pravidla, lze vybrat v rozumném čase, proto je lepší, aby heslo mělo alespoň 11–13 znaků. Ideálním řešením je odmítnout generování klíče pomocí hesla, například pomocí různých čipových karet atd., Ale v tomto případě je nutné zajistit možnost ochrany před ztrátou nosiče šifrovacího klíče.

Bezpečné uložení klíčů a hesel.

Typickými příklady této chyby jsou:

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

Proč vyrábět pancéřové dveře, když je klíč pod koberečkem u dveří?

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

Při organizaci bezpečnostního systému se ujistěte, že plní svůj účel. Například jsem narazil na situaci (nesouvisející s 1C), kdy původně zašifrovaný soubor, když program běžel v otevřené podobě, byl umístěn do dočasné složky, odkud se dal snadno přečíst. Není neobvyklé, že zálohy šifrovaných dat v přehledné formě leží někde „nedaleko“ od těchto dat.

Zneužití kryptografických nástrojů

U šifrování přenášených dat nelze očekávat, že by data byla při jejich použití nedostupná. Služby IPSec například v žádném případě nebrání aplikačnímu serveru naslouchat síťovému provozu na úrovni aplikace.

Abyste se vyhnuli chybám při implementaci kryptografických systémů, měli byste před jejich nasazením (alespoň) udělat následující.

Zjistit:
- Co potřebujete chránit?
- Jaký způsob ochrany byste měli použít?
- Pro které části systému potřebujete zajistit zabezpečení?
- Kdo bude kontrolovat přístup?
- Bude šifrování fungovat na všech správných místech?
Určete, kde jsou informace uloženy, jak jsou odesílány po síti a počítačů, ze kterých budou informace přístupné. To poskytne informace o rychlosti sítě, kapacitě a využití před nasazením systému, což je užitečné pro optimalizaci výkonu.
Posuďte zranitelnost systému pro odlišné typyútoky.
Vytvořte a zdokumentujte plán zabezpečení systému.
Vyhodnoťte ekonomickou účinnost (odůvodnění) používání systému.

Závěr

Při zběžném přezkoumání samozřejmě není možné v 1C naznačit všechny aspekty související s bezpečností, ale udělejme několik předběžných závěrů. Tuto platformu samozřejmě nelze nazvat ideální - stejně jako mnoho dalších má své vlastní problémy s organizací zabezpečeného systému. To ale v žádném případě neznamená, že tyto problémy nelze obejít, naopak správným vývojem, implementací a používáním systému lze téměř všechny nedostatky odstranit. Většina problémů vzniká nedostatečným zpracováním konkrétního řešení aplikace a jeho prováděcího prostředí. Například typická řešení bez výrazných změn jednoduše neznamenají vytvoření dostatečně bezpečného systému.

Společnost Je to jedinečná služba pro kupující, vývojáře, prodejce a přidružené partnery. Navíc je to jeden z nejlepších online softwarových obchodů v Rusku, na Ukrajině, v Kazachstánu, který nabízí zákazníkům široký sortiment, mnoho platebních metod, rychlé (často okamžité) zpracování objednávky, sledování procesu plnění objednávky v osobní sekci.

Příručka programátora API Informix® DataBlade ™ API je k dispozici ke stažení na. Část Správa prostoru zásobníku popisuje, jak vytvořit vlastní funkce (UDR). Tento článek poskytuje další informace a tipy pro ladění.

Níže uvedené informace platí, ať už je UDR spuštěno na uživatelsky definovaném virtuálním procesoru (VP) nebo na VP procesoru. Zásobník vláken lze přesunout na uživatelem definovaný vCPU těsně před spuštění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 vlastní vyhrazený zásobník,

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

STACK modifikátor

Výrazy CREATE PROCEDURE nebo CREATE FUNCTION mají volitelný modifikátor STACK, který vám umožňuje určit množství místa v zásobníku v bajtech, které musí UDR provést.

Pokud při vytváření UDR použijete modifikátor STACK, server při každém spuštění UDR přidělí a uvolní místo v zásobníku. Skutečná dostupná velikost je STACK v bajtech minus nějaká režie v závislosti na počtu argumentů funkce.

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

Konfigurační parametr STACKSIZE

Konfigurační soubor onconfig obsahuje parametr STACKSIZE, který definuje 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í této UDR. Místo toho UDR používá místo zásobníku přidělené ke splnění požadavku. Dostupná velikost zásobníku bude záviset na režii provádění funkce na úrovni SQL.

Zásobník vlákna je přidělen jednou pro konkrétní vlákno, které vytváří požadavek. Výkon je lepší, když UDR sdílí jedno vlákno s jedním zásobníkem, protože server nemrhá prostředky na přidělení dalšího zásobníku pro každé volání UDR. Na druhou stranu, pokud se velikost použitého zásobníku UDR blíží hodnotě STACKSIZE, může to způsobit přetečení zásobníku při volání funkce v rámci komplexního požadavku (v tomto případě je k provedení menšího množství zásobníku k dispozici UDR).

Nezapomeňte nenastavit STACKSIZE příliš vysoko, protože to ovlivní všechna uživatelská vlákna.

Kdy potřebujete spravovat velikost zásobníku?

Y Prostor zásobníku musíte spravovat, pokud UDR provádí rekurzivní volání nebo pokud UDR vyžaduje více místa v zásobníku, než je standardně k dispozici v zásobníku vláken 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í rekurzivního volání mi_call () (příklad viz Příručka programátora API Informix DataBlade API).

Pokud pomocí STACK nezadáte velikost a pokud nepoužíváte mi_call () ke zvýšení aktuálního zásobníku a pokud UDR udělá 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 jako mi_ * přidávají nový segment zásobníku pro vlastní provádění. Tyto segmenty jsou uvolněny po návratu volajícímu UDR.

Co 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 konkrétně pro konkrétní UDR.

Sledování využití zásobníku pomocí „onstat -g sts“

Sledujte relaci provádějící dotaz SQL pomocí „onstat -g ses session_id“

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

Můžete dynamicky nastavit hodnotu STACK pro UDR. 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í dotaz a ujistit se, že nyní funguje stabilně.

Zvyšte 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 zvýšení STACKSIZE nefunguje, problémem je s největší pravděpodobností poškození paměti. Zde je několik návrhů:

Povolte čmárání paměti a kontrolu oblasti paměti. Část "Problémy s laděním" v článku Přidělení paměti pro UDRs vysvětluje, jak to provést.

Znovu zvažte použití mi_lvarchar. Věnujte zvláštní pozornost místům, kde je mi_lvarchar předán funkci, která očekává, že jako argument obdrží řetězec zakončený hodnotou null.

Snižte počet VP (nebo uživatelů) VP na jeden, aby se problém reprodukoval rychleji.

mi_print_stack () - Solaris

Informix Dynamic Server pro Solaris OC 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 nemůžete změnit, ale můžete změnit jeho umístění změnou hodnoty proměnné prostředí DBTEMP. Ujistěte se, že uživatel informix může zapisovat do adresáře $ DBTEMP. Všechny chyby, ke kterým dojde při provádění mi_print_stack (), se vytisknou na $ MSGPATH.

Tato funkce je k dispozici pouze pro Solaris OC.

Glosář

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

UDR	Rutina definovaná uživatelem
VP	Virtuální procesor

14. 4. 2016 Verze 3.22 Změněné rozhraní, opravené chyby při přenosu registrů, změněn postup při přenosu organizací a účetních zásad. Platforma 8.3.7.2027 BP 3.0.43.174
17. 3. 2016 Verze 3.24 Opravené chyby. Platforma 8.3.8.1747 BP 3.0.43.241
16. 6. 2016 Verze 3.26 Opravené chyby. Platforma 8.3.8.2088 BP 3.0.44.123
16.10.2016 Verze 4.0.1.2 Opravený převod úložiště hodnot, změněný převod účetních zásad pro verze 3.44. *. Platforma 8.3.9.1818 BP 3.0.44.164.
19. 4. 2017 Verze 4.0.2.7 Algoritmus pro přenos registrů spojených s adresáři byl změněn, opravené chyby byly opraveny, byl opraven přenos s přepisováním odkazů.
29. 5. 2017 Verze 4.0.4.5 Změněn přenos pohybů, přidáno prohlížení pohybů přenesených dokumentů, něco jiného ...
30.05.2017 Verze 4.0.4.6 Opravena chyba při vyplňování seznamu stávajících adresářů ve zdroji (díky shoy)
17. 6. 2017 Verze 4.0.5.1 Algoritmus pro přenos pohybů byl změněn.
19. 7. 2017 Verze 4.0.5.4 Převod CI z BP 2.0 byl změněn. Smilegm byl neočekávaně převeden z UT 10.3, v této verzi byl přenos pro takovou situaci mírně opraven)))
10. 10. 2017 Verze 4.0.5.5 Opravené chyby při přenosu z BP 2.0
19. 9. 2017 Verze 4.4.5.7 Kontrola pevného připojení pro 3.0.52. *
28.11.2017 Verze 4.4.5.9 Opravené chyby
12/06/2017 Verze 5.2.0.4 Algoritmus vyhledávání odkazů byl přepracován. Přidány přenosové procedury z BP 1.6, k BP již neexistuje pevná vazba - k přenosu dat můžete bezpečně použít „téměř“ identické konfigurace. Pokusím se všechny komentáře rychle opravit.
12/08/2017 Verze 5.2.1.3 Přidán algoritmus pro přenos mzdových listů z BP.2.0 do BP 3.0. Změny jsou zahrnuty pro sdílení mezi stejnými konfiguracemi.
19.12.2017 Verze 5.2.2.2 Opraven přenos nezávislých registrů informací 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řevodu z BP 1.6 na BP 3.0. Hlavní změnou je správa vyhledávání odkazovaných odkazů - v předchozích verzích bylo vyhledávání podle GUID a v této verzi můžete povolit vyhledávání „Podle požadavků“:

17. 1. 2018 Verze 5.2.2.3 Opravené chyby podřízených adresářů a pravidelných registrů informací.

19. 7. 2018 Verze 5.2.2.8 Opravené chyby.

kde můžete nastavit podrobnosti vyhledávání pro jakoukoli referenční knihu. Tento režim sám „vznikl“ na četných žádostech pracovníků, pro případ, že je nutná výměna v již existující databázi, která již data obsahuje (například ke sloučení účetnictví dvou organizací do jedné databáze).

21. 12. 2015 byla vydána platforma 8.3.7.1805 a BP 3.0.43.29 novou verzi zpracování 3.1 :-) (popis níže). Nová funkce- schopnost porovnávat zůstatky a obraty mezi dvěma základnami TK (u všech účtů, pokud se účtové osnovy shodují, nebo u samostatných odpovídajících účtů, s nebo bez analytiky).
1. 3. 2016 Verze 3.5 - změněn mechanismus pro připojení ke zdrojové databázi - uveden do souladu s BSP 2.3.2.43. Opravené drobné chyby. Platforma 8.3.7.1845, BP 3.0.43.50
16. 2. 2016 Verze 3.6 - Přidán příznak „Nastavit ruční opravu“ u dokumentů přenesených s pohyby. Opravený přenos pohybů - dokumenty s datem kratším než na začátku období jsou přenášeny bez pohybů. Platforma 8.3.7.1917, BP 3.0.43.116
22.03.2016 Verze 3.10 - Přidán příznak „Vždy přepsat odkazy“ pro povinné přepisování odkazovaných objektů (rychlost přenosu je výrazně snížena, ale někdy je to nutné). Byla přidána záložka „Příprava“, kde můžete konfigurovat korespondenci zdrojových a cílových účtových účtů (na úrovni s kódy účtů) a přenos konstant. Platforma 8.3.7.1970, BP 3.0.43.148

03.04.2016 Verze 3.11 Bylo změněno vyplňování seznamu dokumentů existujících ve zdroji: plnění bylo prováděno podle pohybů podle účtové osnovy, bylo to provedeno jednoduše pomocí odkazů za období, stejně jako v // web / public / 509628 /

Zpracování je určeno k přenosu dat za jakékoli období podobně jako „Vykládání a načítání MXL“ z ITS, pouze bez použití XML, JSON a dalších mezilehlých souborů - výměna z databáze do databáze přes COM. Ve verzi starší než 3.10 se používá připojení pomocí algoritmu z BSP, ve kterém je k dispozici registrace comcntr.dll (pokud to OS „umožňuje“), a také různé zprávy, když není možné navázat připojení , například - " Informační základna právě aktualizuje “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 normativních a referenčních informací (NSI) ze zdroje IS do přijímače IS (přenos celého NSI se provádí na žádost uživatele, potřebné referenční knihy atd. Se přenášejí odkazy pro jakékoli přenosy ).

2. Přenos dokumentů za libovolné zvolené období.

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

Funkce zpracování - informační bezpečnost přijímače a zdroje se může lišit přenos od 2,0 do 3,0 - edice jsou různé, ale přenos funguje !!! Nesouladné atributy jsou ignorovány, nebo pro ně musí být zadány přenosové algoritmy.

Komentář: Konverze dat se NEPOUŽÍVÁ! A neptejte se proč !!! Pro nejkorozivnější - BP 3.0 se mění téměř každý den, již není síla udržovat pravidla přenosu aktuální - zde je vše snazší :-).

Další funkcí zpracování je, že je spuštěn v IS přijímače (nejbližší analogy z hlediska funkčnosti fungují obráceně - od zdroje k přijímači).

Zahájení práce - musíte zadat dobu zpracování, uvést organizaci ze zdroje, bude přenesena do příjemce.

Když je organizace převedena, jsou přeneseny účetní zásady a „doprovodné“ informační registry. Proto když poprvé vyberete organizaci ve zdroji, bude nějakou dobu trvat, než se objeví v přijímači.

Zdrojová a cílová tabulka účtů musí být stejná, žádné jiné účty ve verzi 2. * nebudou přeneseny do příjemce, nastavení korespondence účtů a analytiky je plánováno do budoucna. Účty jsou přenášeny kódy, které se nenacházejí v přijímači NEVYTVÁŘEJTE !!!

Zbytek objektů je přenášen interními identifikátory (GUID), takže byste měli věnovat pozornost některým klíčovým referenčním knihám, například - měnám.

Pokud plánujete výměnu s „čistým“ základem, pak je lepší vymazat referenční knihy vyplněné při prvním startu před výměnou. K tomu je ve zpracování k dispozici stránka, kde můžete tyto prvky adresářů získat a odstranit. Přinejmenším musíte odstranit měnu „RUB“. - od té doby duplikace je téměř nevyhnutelná (v zásadě je to snadno opravitelné po výměně vyhledávání a nahrazení duplikátů integrovaných do BP 3.0).

Při zpracování se předpokládá volání stránky pro odstranění adresářů, když je otevřen počáteční vyplňovací formulář:

Po otevření zpracování se zobrazí stránka pro odstranění referenčních knih vyplněných během počátečního plnění:

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

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

Předdefinované prvky adresáře není třeba mazat - jsou přenášeny pomocí konfiguračních identifikátorů (nikoli GUID).

Objekty pro přenos můžete vybrat pomocí výběrového formuláře z adresářů a dokumentů (Informační registry přidružené k tomuto objektu budou migrovány automaticky, takže je nemusíte vybírat samostatně).Přenos registrů je dočasně deaktivován - je třeba vypracovat seznam registrů pro přenos - něco se musí přenést, něco ne, v této fázi stačí to, co je přeneseno do adresářů, seznam registrů pro přenos bude v šabloně, v budoucích verzích.

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

Seznam typů objektů lze ve verzi 3.22 vyplnit různě, je umístěn v podnabídce, změny jsou zapsány na obrázku:

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

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

Přenos dokumentů s pohyby je zajištěn, u výměn 3.0 až 3.0 a souladu účtových účtů funguje jedna k jedné, při výměně 2.0 až 3.0 jsou možné chyby, proto se doporučuje přenášet dokumenty bez pohybů a poté jednoduše repost je v přijímači. Při přenosu dokumentů s pohyby je nastaven příznak „Ruční oprava“.

Atribut "Zaúčtováno" je v dokumentech příjemce nastaven stejně jako ve zdroji, ale pohyby (pokud nebyly přeneseny) se objeví až po zaúčtování dokumentů, například pomocí zpracování integrovaného do zpracování dokumentů skupiny BP 3.0 ( doporučená možnost), nebo z tohoto zpracování (zde je tlačítko „Odeslat dokumenty“).

Pokud je zpracování plánováno k trvalé výměně, lze jej zaregistrovat v IS 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 BP 3.0.43.29 (verze 2.15 pro 3.0.43. * Nefunguje - konfigurace byla hodně změněna).

Změněno:

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

- NOVINKA FUNKČNÍ: Mechanismus pro sladění zbytků a otáček mezi základnami zdroje a přijímače v různých stupních podrobností:

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

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

V tenkém klientovi jsem nepropadl programově stisknutí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é objemy tabulek než rolování myší:

22.03.2016 Verze 3.10 - Přidán příznak „Vždy přepsat odkazy“ pro povinné přepisování odkazovaných objektů (rychlost přenosu je výrazně snížena, ale někdy je to nutné). Byla přidána záložka „Příprava“, kde můžete konfigurovat korespondenci zdrojových a cílových účtových účtů (na úrovni s kódy účtů) a přenos konstant. Platforma 8.3.7.1970, BP 3.0.43.148

- NOVINKA FUNKČNÍ: Před přenosem dokumentů doporučujeme zkontrolovat soulad účtové osnovy ve zdroji a cíli a také konzistenci stanovených konstant.

Chcete -li to provést, přidejte kartu "Příprava", ve které můžete nastavit tyto korespondence:

Algoritmus pro vyplnění tabulky korespondence účtů je jednoduchý - analyzují se obraty existující ve zdroji a každý nalezený účet se hledá podle kódu v přijímači, pokud není nalezena shoda, řádek s kód účtu je zobrazen v tabulce, pomocí které musíte vybrat účet příjemce, bude použit při převodu. Korespondence vědy je stanovena na úrovni kódů.

Ke kontrole a přenosu shody nastavených konstant slouží odpovídající tabulka:

V případě potřeby vyplníme - přeneseme. Přenášejí se pouze konstanty označené vlajkou ...

Programový zásobník je speciální oblast paměti organizovaná na základě fronty LIFO (Last in, first out - last in, first out). Název „stoh“ pochází z analogie principu jeho konstrukce se stohem desek - desky můžete položit na sebe (způsob přidávání do stohu, „tlačení“, „tlačení“) a poté jejich vyzvednutí, počínaje shora (způsob získávání hodnoty ze zásobníku, „pop“, „pop“). Programový zásobník se také nazývá zásobník volání, zásobník provádění, zásobník strojů (aby nedošlo k záměně se „zásobníkem“ - abstraktní datovou strukturou).

K čemu je stack? Umožňuje pohodlně organizovat volání podprogramů. Při volání funkce přijímá některé argumenty; také potřebuje někam uložit své lokální proměnné. Kromě toho je třeba vzít v úvahu, že jedna funkce může volat jinou funkci, která také musí předávat parametry a ukládat své proměnné. Pomocí zásobníku při předávání parametrů je stačí vložit do zásobníku, poté je volaná funkce bude moci „odtlačit“ odtamtud a použít je. Na stejné místo lze ukládat i lokální proměnné - na začátku svého kódu funkce alokuje část paměti zásobníku, když se ovládání vrátí, vyčistí ji a uvolní. Programátoři v jazycích na vysoké úrovni o takových věcech obvykle nepřemýšlejí - kompilátor jim generuje veškerý potřebný rutinní kód.

Důsledky chyby

Nyní se k problému dostáváme velmi blízko. Ve své abstraktní podobě je zásobník nekonečným úložištěm, do kterého lze nekonečně přidávat nové prvky. Bohužel v našem světě je všechno konečné - a paměť pod zásobníkem není výjimkou. Co se stane, když skončí, když jsou do zásobníku vloženy funkční argumenty? Nebo funkce alokuje paměť pro své proměnné?

Dojde k chybě nazývané přetečení zásobníku. Protože zásobník je nezbytný pro organizaci volání uživatelem definovaných funkcí (a téměř všech programů na moderní jazyky, včetně objektově orientovaných, jsou nějak postavené na základě funkcí), už je nebude možné volat. Proto operační systém převezme kontrolu, vyčistí zásobník a ukončí program. Zde můžete zdůraznit rozdíl mezi a přetečením zásobníku - v prvním případě dojde k chybě při přístupu do nesprávné oblasti paměti, a pokud v této fázi neexistuje ochrana, v tu chvíli se to neprojeví - s úspěšnou shodou okolností, program může fungovat normálně. Pokud je chráněna pouze přístupná paměť, stane se to. V případě zásobníku program skončí bez selhání.

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

Důvody chyby

Co může vést k tak nepříjemné situaci? Na základě výše popsaného mechanismu je jednou z možností příliš mnoho vnořených volání funkcí. Tento scénář je obzvláště pravděpodobný při použití rekurze. Nekonečná rekurze (při absenci mechanismu pro „líné“ hodnocení) je tímto způsobem na rozdíl od toho přerušena, což má někdy užitečnou aplikaci. S malým množstvím paměti přidělené pro zásobník (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. Není vhodné vytvářet lokální pole s milionem prvků nebo milionem lokálních proměnných (nikdy nevíte, co se stane). I jedno volání na takovou chamtivou funkci může snadno způsobit přetečení zásobníku. Chcete -li získat velké množství dat, je lepší použít mechanismy haldy paměti, které vám umožní zvládnout chybu jejího nedostatku.

Hromadná paměť je však poměrně pomalá, pokud jde o přidělení a zrušení přidělení (protože to dělá operační systém) a kdy přímý přístup musíte jej ručně přidělit a uvolnit. Paměť v zásobníku je alokována velmi rychle (ve skutečnosti stačí změnit hodnotu jednoho registru), navíc se objekty, které jsou v zásobníku přiděleny, automaticky vrátí destruktory, když se funkce vrátí a zásobník se vyčistí. Samozřejmě okamžitě vyvstane touha získat paměť ze zásobníku. Třetím způsobem přetečení je tedy alokace paměti v zásobníku programátorem. Knihovna C poskytuje funkci alloca konkrétně pro tento účel. Je zajímavé poznamenat, že pokud má funkce pro přidělování dynamické paměti malloc své „dvojče“ pro její bezplatné uvolnění, pak ji funkce alloca nemá - paměť se uvolní automaticky po návratu kontroly funkce. Možná to jen komplikuje situaci - koneckonců nebude možné uvolnit paměť před ukončením funkce. Přestože podle manuálové stránky „alloca je závislá na stroji a kompilátoru; na mnoha systémech je jeho implementace problematická a obsahuje mnoho chyb; jeho použití je velmi frivolní a odrazované“ - stále se používá.

Příklady

Jako příklad zvažte kód pro rekurzivní vyhledávání souborů umístěný na MSDN:

Void DirSearch (String * sDir) (try (// Vyhledejte podsložky ve složce, do které je předán. 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é se zavolá pro ty položky seznamu, které se ukázaly jako adresáře. V souladu s tím s dostatečně hlubokým stromem systému souborů dostaneme logický výsledek.

Příklad druhého přístupu, převzatý z otázky „Proč dochází k přetečení zásobníku?“ z webu s názvem Stack Overflow (web je souborem otázek a odpovědí na jakékoli programovací téma, nejen přetečení zásobníku, 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, v hlavní funkci je paměť na zásobníku přidělena pro pole typů int a float, každý jeden milion prvků, což celkem dává o něco méně než 8 megabajtů. Vzhledem k tomu, že ve výchozím nastavení Visual C ++ rezervuje pro zásobník pouze 1 megabajt, je 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); // .. .)

Naštěstí h.getLength () - 7 nebude příliš velký, aby se zabránilo přetečení na dalším řádku. Stojí ale čas ušetřený na alokaci paměti za „potenciální“ havárii programu?

Výsledek

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, přetečení je stále možné kvůli velkému objemu lokálních proměnných nebo chybě v ručním přidělení paměti v zásobníku. Všechna klasická pravidla zůstávají na místě: pokud existuje možnost volby, je lepší upřednostnit iteraci místo rekurze a také místo kompilátoru nedělat ruční práci.

Bibliografický seznam

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 přidělíte během provádění programu. Poslední, první (LIFO) znamená, že poslední věc, kterou vložíte, je vždy první věc, kterou vrátíte - pokud trefíte 2 položky do zásobníku, „A“ a poté „B“, pak první věc, kterou vyskočíte 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 je uložen v zásobníku a libovolném paměťovém prostoru, který lze přepsat voláním funkce. Vybraná funkce může pro své vlastní lokální proměnné využívat více zásobníků. Když je hotovo, uvolní místní proměnný prostor, který používal, a poté se vrátí k předchozí funkci.

Přetečení zásobníku

Přetečení zásobníku je, když jste pro zásobník použili více paměti, než jaký program zamýšlel použít. V integrovaných systémech můžete mít pro zásobník pouze 256 bajtů, a pokud je každá funkce 32 bajtů, pak můžete mít pouze 8 volání funkcí do funkce 2 s hlubokou funkcí 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 tím, že zavolá funkci A, která poté zavolá funkci B, která pak zavolá funkci C, která pak zavolá funkci A. Většinu času to může fungovat, ale jen jeden špatný vstup způsobí, že se bude navždy kroužit, dokud počítač zjistí, že zásobník je plný.

Rekurzivní funkce to také způsobují, ale pokud píšete rekurzivně (tj. Vaše funkce volá sama), musíte si toho být vědomi a používat statické / globální proměnné, abyste zabránili nekonečné rekurzi.

Obvykle OS a programovací jazyk, který používáte, spravují zásobník, a to je z vašich rukou. Měli byste se podívat na svůj graf volání (stromovou strukturu, která z vašeho hlavního bodu ukazuje, co která funkce volá), abyste zjistili, jak hluboká jsou vaše volání funkcí, a identifikovat smyčky a rekurze, které nejsou určeny. Úmyslné smyčky a rekurze musí být uměle zkontrolovány na chyby, pokud si navzájem volají příliš často.

Kromě osvědčených programovacích postupů, statického a dynamického testování se na těchto systémech toho moc dělat nedá. vysoká úroveň.

Vestavěné systémy

V integrovaném světě, zejména vysoce spolehlivém kódu (automobilový, letecký, vesmírný), provádíte rozsáhlé kontroly a ověřování kódu, ale také provádíte následující:

Zakázat rekurze a smyčky - dodržování zásad a testování
Udržujte kód a hromádku daleko od sebe (kód ve flashi, zásobník v RAM a nikdy se neshoduje)
Umístěte ochranné pruhy kolem hromádky - prázdnou oblast paměti, kterou vyplníte magickým číslem (obvykle program pro přerušení, ale zde je mnoho možností), a stovky nebo tisíckrát za sekundu se podíváte na ochranné proužky ujistěte se, že nebyly přepsány.
Použijte ochranu paměti (tj. Neprovádějte na zásobníku, nečtěte ani nezapisujte přímo do zásobníku)
Přerušení nevyvolávají sekundární funkce - nastavují příznaky, kopírují data a nechávají aplikaci, aby se o to postarala (v opačném případě se můžete dostat 8 hluboko do stromu volání funkcí, mít přerušení a poté některé další funkce uvnitř ukončení přerušení , způsobující hod). Máte více stromů hovorů - jeden pro hlavní procesy a jeden pro každé přerušení. Pokud se vaše přerušení mohou navzájem rušit ... existují draci ...

Jazyky a systémy na vysoké úrovni

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

Snížit místní úložiště proměnné (místní proměnné jsou uloženy v zásobníku), přestože kompilátory jsou v tomto velmi chytré a někdy vloží na hromadu velké kusy, pokud je váš strom volání malý)
Vyhněte se nebo silně omezte rekurzi
Nepřerušujte své programy příliš daleko na menší a menší funkce - i když pomineme lokální proměnné, každé volání funkce spotřebuje až 64 bytů v zásobníku (32bitový procesor, ponechání poloviny registrů procesoru, vlajky atd.).
Udržujte strom volání mělký (podobný výše)

Webové servery

Záleží na sandboxu, který máte, zda můžete stack ovládat nebo dokonce vidět. Je pravděpodobné, že webové servery zvládnete jako každý jiný jazyk na vysoké úrovni a operační systém je docela z vašich rukou, ale zkontrolujte použitý jazyk a zásobník serveru. Je například možné rozdělit zásobník na váš server SQL.