1c preveč zapletena zahteva, morda pretiravanje sklada. Preobremenitev. Šifriranje podatkov med prenosom med aplikacijskim strežnikom in MS SQL strežnikom

Ta članek še enkrat dokazuje, da mora vsak niz varnostnih ukrepov zajemati vse faze izvajanja: razvoj, uvajanje, sistemsko upravljanje in seveda organizacijske ukrepe. V informacijskih sistemih je "človeški faktor" (vključno z uporabniki) glavna grožnja varnosti. Ta niz ukrepov mora biti razumen in uravnotežen: nima smisla in malo je verjetno, da bo za organizacijo zaščite namenjenih dovolj sredstev, kar presega stroške samih podatkov.

Uvod

1C: Enterprise je najbolj razširjen računovodski sistem v Rusiji, vendar so njegovi razvijalci do različice 8.0 zelo malo pozornosti namenili varnostnim vprašanjem. V bistvu je to seveda narekovala cenovna niša izdelka in osredotočenost na mala podjetja, kjer ni usposobljenih strokovnjakov za IT, možni stroški uvajanja in vzdrževanja varnega sistema pa bi bili za podjetje pretirano dragi. Z izdajo različice 8.0 se je moral fokus spremeniti: stroški rešitev so se znatno povečali, sistem je postal veliko bolj prilagodljiv in prilagodljiv - zahteve so se bistveno spremenile. Ali je sistem postal dovolj zanesljiv in varen, je zelo individualno vprašanje. Glavni informacijski sistem sodobnega podjetja mora izpolnjevati vsaj naslednje varnostne zahteve:

Precej majhna verjetnost okvare sistema zaradi notranjih razlogov.
Zanesljivo pooblastilo uporabnika in zaščita podatkov pred napačnimi dejanji.
Učinkovit sistem dodeljevanja pravic uporabnikov.
Spletni sistem za varnostno kopiranje in obnovitev v primeru okvare.

Ali rešitve, ki temeljijo na 1C: Enterprise 8.0, ustrezajo tem zahtevam? Enotnega odgovora ni. Kljub pomembnim spremembam v sistemu nadzora dostopa je še vedno veliko nerešenih vprašanj. Odvisno od tega, kako je sistem razvit in konfiguriran, vse te zahteve morda niso izpolnjene ali pa so v zadostni meri izpolnjene za to izvedbo, vendar je vredno biti pozoren (in to je pomembna posledica "mladosti" platforme ), da je za popolno izpolnitev navedenih pogojev treba uporabiti resnično titanska prizadevanja.

Ta članek je namenjen razvijalcem in izvajalcem rešitev na platformi 1C: Enterprise, pa tudi sistemskim administratorjem organizacij, kjer se uporablja 1C: Enterprise, in opisuje nekatere vidike razvoja in konfiguracije različice sistema odjemalec-strežnik od z vidika organizacije. varnost informacij... Tega članka ni mogoče nadomestiti z dokumentacijo, ampak navaja le nekatere točke, ki v njem še niso bile izražene. In seveda niti ta članek niti vsa dokumentacija ne bosta mogla odražati kompleksnosti problema izgradnje varnega informacijskega sistema, ki mora hkrati izpolnjevati nasprotujoče si zahteve glede varnosti, zmogljivosti, udobja in funkcionalnosti.

Razvrstitev in terminologija

Ključna tema tega članka so grožnje z informacijami.

Informacijska grožnja- možnost situacije, ko bodo podatki nepooblaščeno prebrani, kopirani, spremenjeni ali blokirani.

Na podlagi te definicije članek grožnje z informacijami razvršča na naslednji način:

Nepooblaščeno uničenje podatkov
Nepooblaščena sprememba podatkov
Nepooblaščeno kopiranje podatkov
Nepooblaščeno branje podatkov
Nedostopnost podatkov

Vse grožnje delimo na namerne in nenamerne. Izvedena bo grožnja z informacijami nezgoda... Značilnosti sistema so:

Ranljivosti- lastnosti, ki vodijo do incidentov Zaščitni ukrepi- funkcije, ki blokirajo možnost incidenta

V bistvu se upoštevajo le tisti primeri, katerih verjetnost je posledica uporabe tehnološke platforme 1C: Enterprise 8.0 v različici odjemalec-strežnik (v nadaljevanju v primerih, ko to ni v nasprotju s pomenom samo 1C ali 1C 8.0 ). Opredelimo naslednje glavne vloge v zvezi z uporabo sistema:

Operaterji- uporabniki, ki imajo pravice do ogleda in spreminjanja podatkov, omejenih na vlogo aplikacije, vendar nimajo administrativnih funkcij
Skrbniki sistema- uporabniki, ki imajo v sistemu upravne pravice, vključno s skrbniškimi pravicami v operacijskih sistemih aplikacijskega strežnika in strežnika MS SQL, upravnimi pravicami do MS SQL itd.
Skrbniki za varnost informacij- uporabniki, ki so v informacijski bazi 1C pooblaščeni za nekatere upravne funkcije (na primer dodajanje uporabnikov, testiranje in popravljanje, rezerva, nastavitev uporabljene rešitve itd.)
Razvijalci sistemov- uporabniki, ki razvijajo uporabno rešitev. Na splošno morda nimajo dostopa do delovnega sistema.
Osebe brez neposrednega dostopa do sistema- uporabniki, ki nimajo pooblastil za dostop do 1C, vendar lahko na tak ali drugačen način vplivajo na delovanje sistema (običajno so to vsi uporabniki iste domene Active Directory, v kateri je sistem nameščen). Ta kategorija velja predvsem za prepoznavanje potencialno nevarnih subjektov v sistemu.
Samodejni skrbniški skripti- programi, na katere so prenesene določene funkcije, namenjene samodejnemu izvajanju določenih dejanj (na primer uvoz-izvoz podatkov)

Tu je treba opozoriti na dve točki: prvič, ta razvrstitev je zelo groba in ne upošteva delitev znotraj vsake skupine - takšna razdelitev bo ustvarjena za nekatere posebne primere, in drugič, predpostavlja se, da druge osebe ne morejo vplivati na delovanje sistem, ki mora biti opremljen s sredstvi zunaj 1C.

Vsak varnostni sistem mora biti zasnovan ob upoštevanju izvedljivosti in stroškov lastništva. Na splošno je pri razvoju in izvajanju informacijskega sistema potrebno, da cena zaščite sistema ustreza:

vrednost zaščitenih podatkov;
stroški ustvarjanja incidenta (v primeru namerne grožnje);
finančna tveganja v primeru incidenta

Nesmiselno in škodljivo je organizirati zaščito, ki je veliko dražja od ocene njene finančne učinkovitosti. Obstaja več načinov za oceno tveganja izgube informacij, ki pa v tem članku niso obravnavani. Drug pomemben vidik je ohranjanje ravnovesja pogosto nasprotujočih si zahtev glede varnosti informacij, zmogljivosti sistema, udobja in enostavnosti dela s sistemom, hitrosti razvoja in implementacije ter drugih zahtev za informacijske sisteme podjetij.

Glavne značilnosti mehanizma za zaščito informacij sistema

1C: Enterprise 8.0 je na voljo v dveh različicah: datotečni in odjemalsko-strežniški. Različice datoteke ni mogoče obravnavati kot zagotavljanje informacijske varnosti sistema iz naslednjih razlogov:

Podatki in konfiguracija so shranjeni v datoteki, ki jo lahko berejo in pišejo vsi uporabniki sistema.
Kot bo prikazano spodaj, je sistemsko pooblastilo zelo enostavno zaobiti.
Celovitost sistema zagotavlja le jedro odjemalca.

V različici odjemalec-strežnik se za shranjevanje informacij uporablja MS SQL Server, ki zagotavlja:

Bolj zanesljivo shranjevanje podatkov.
Izolacija datotek od neposrednega dostopa.
Boljši transakcijski in zaklepni mehanizmi.

Kljub pomembnim razlikam med datotečno in odjemalsko-strežniško različico sistema imajo enotno shemo za nadzor dostopa na ravni aplikacijske rešitve, ki zagotavlja naslednje zmožnosti:

Avtorizacija uporabnika z geslom, navedenim v 1C.
Uporabniško pooblastilo trenutnega uporabnika sistema Windows.
Dodelitev vlog uporabnikom sistema.
Omejevanje izvajanja upravnih funkcij po vlogah.
Dodelitev razpoložljivih vmesnikov po vlogah.
Omejevanje dostopa do objektov metapodatkov glede na vlogo.
Omejevanje dostopa do atributov objekta glede na vlogo.
Omejevanje dostopa do podatkovnih objektov glede na vloge in parametre seje.
Omejevanje interaktivnega dostopa do podatkov in izvedljivih modulov.
Nekatere omejitve pri izvajanju kode.

Na splošno je uporabljena shema dostopa do podatkov precej značilna za informacijske sisteme te ravni. Vendar pa je v zvezi s to izvedbo tristopenjske arhitekture odjemalec-strežnik več temeljnih vidikov, ki vodijo v relativno veliko število ranljivosti:

Veliko število stopenj obdelave podatkov in na vsaki stopnji lahko veljajo različna pravila za dostop do predmetov.

Nekoliko poenostavljen diagram korakov obdelave podatkov, ki so pomembni z vidika varnosti, je prikazan na sliki 1. Splošno pravilo za 1C je zmanjšati omejitve, ko se premikate po tej shemi, zato izkoristite ranljivost na enem od zgornje ravni lahko moti delovanje sistema na vseh ravneh.
Nezadostno odpravljeni postopki za nadzor poslanih podatkov pri premikanju z ravni na raven.

Na žalost niso vsi notranji mehanizmi sistema popolnoma odpravljeni, zlasti pri neinteraktivnih mehanizmih, katerih odpravljanje napak je na eni strani vedno bolj dolgotrajno, na drugi pa bolj odgovorno. Ta "bolezen" ni problem izključno za 1C, najdemo jo v številnih strežniških izdelkih večine prodajalcev. Šele v zadnjih letih se je pozornost na te težave močno povečala.
Nezadostno visoka povprečna usposobljenost razvijalcev in sistemskih skrbnikov, podedovana iz prejšnje različice.

Izdelki linije 1C: Enterprise so bili sprva osredotočeni na enostavnost razvoja in podpore ter na delo v majhnih organizacijah, zato ni presenetljivo, da v preteklosti pomemben del "razvijalcev" aplikacijskih rešitev in "administratorjev" sistemov ne imeti dovolj znanja in spretnosti za delo z veliko bolj zapletenim izdelkom, ki je različica 8.0. Težavo še poslabša praksa, sprejeta v franšizijskih podjetjih, da se "v bitki" usposabljajo na račun strank, ne da bi se k temu vprašanju sistematično lotili. 1C je treba odati priznanje, da se je to stanje v zadnjih nekaj letih postopoma izboljševalo: resna podjetja, ki so pridobila franšizo, so postala bolj odgovorna pri reševanju problema zaposlovanja in usposabljanja osebja, raven podpore informacijske tehnologije s strani 1C se je znatno povečala, zdi se, da so programi certificiranja osredotočeni na visoko raven storitev; vendar situacije ni mogoče takoj popraviti, zato je treba ta dejavnik upoštevati pri analizi varnosti sistema.
Sorazmerno majhna starost platforme.

Med izdelki s podobno usmerjenostjo in namenom uporabe je to ena najmlajših rešitev. Funkcionalnost platforme je bila bolj ali manj urejena pred manj kot letom dni. Hkrati je vsaka izdaja platforme, ki se je začela v 8.0.10 (v tej izdaji so bile implementirane skoraj vse trenutne zmogljivosti sistema), postala veliko bolj stabilna kot prejšnje. Funkcionalnost tipičnih aplikacijskih rešitev še vedno narašča, čeprav je uporabljena največ polovica zmogljivosti platforme. Seveda lahko v takšnih razmerah o stabilnosti govorimo precej okvirno, vendar je na splošno treba priznati, da v mnogih pogledih rešitve, ki temeljijo na platformi 1C 8.0, glede funkcionalnosti in zmogljivosti bistveno presegajo podobne rešitve na platformi 1C 7.7 (in pogosto tudi glede stabilnosti).

Torej je sistem (in po možnosti tipična aplikacijska rešitev) nameščen v podjetju in nameščen na računalnikih. Najprej je treba ustvariti okolje, v katerem je smiselno konfigurirati varnost 1C, za to pa ga je treba konfigurirati tako, da se izpolni predpostavka, da sistemske nastavitve pomembno vplivajo na sistemske nastavitve.

Upoštevajte splošna pravila za nastavitev zaščite.

O nobeni informacijski varnosti sistema ne more biti govora, če se ne upoštevajo osnovna načela ustvarjanja varnih sistemov. Prepričajte se, da so izpolnjeni vsaj naslednji pogoji:

Dostop do strežnikov je fizično omejen in zagotovljeno je njihovo nemoteno delovanje:
- strežniška oprema izpolnjuje zahteve glede zanesljivosti, odpravlja se napaka pri zamenjavi okvarjene strežniške opreme, za posebej kritična območja se uporabljajo odvečna vezja strojna oprema(RAID, napajanje iz več virov, več komunikacijskih kanalov itd.);
- strežniki se nahajajo v zaklenjeni sobi in ta soba se odpre le za čas dela, ki ga ni mogoče opravljati na daljavo;
- le ena ali dve osebi imata pravico odpreti strežniško sobo; v nujnih primerih je bil razvit sistem obveščanja za odgovorne osebe;
- zagotovljeno je neprekinjeno napajanje strežnikov
- zagotovljeno je normalno klimatsko delovanje opreme;
- v strežniški sobi je požarni alarm, ni možnosti poplav (zlasti za prvo in zadnje nadstropje);
Nastavitve omrežne in informacijske infrastrukture podjetja so pravilne:
- vsi strežniki imajo nameščene in konfigurirane požarne zidove;
- vsi uporabniki in računalniki so pooblaščeni v omrežju, gesla so dovolj zapletena, da jih ni mogoče uganiti;
- sistemski operaterji imajo dovolj pravic za normalno delo z njim, nimajo pa pravic do upravnih ukrepov;
- protivirusna orodja so nameščena in omogočena na vseh računalnikih v omrežju;
- zaželeno je, da uporabniki (razen skrbnikov omrežja) nimajo skrbniških pravic na odjemalskih delovnih postajah;
- dostop do interneta in do odstranljivih medijev bi bilo treba urediti in omejiti;
- sistemsko revizijo varnostnih dogodkov je treba konfigurirati;
Rešena so glavna organizacijska vprašanja:
- uporabniki imajo zadostne kvalifikacije za delo z 1C in strojno opremo;
- uporabniki so obveščeni o odgovornosti za kršitev pravil delovanja;
- imenovan za finančno odgovornega za vsak pomemben element informacijskega sistema;
- vse sistemski bloki zaprto in zaprto;
- Posebno pozornost posvetite poučevanju in nadzoru čistilcev, graditeljev in električarjev. Te osebe lahko iz malomarnosti povzročijo škodo, ki ni primerljiva s namerno škodo, ki jo povzroči brezvestni uporabnik sistema.

Pozor! Ta seznam ni izčrpen, ampak opisuje le tisto, kar se pri sprejemanju katerega koli precej zapletenega in dragega informacijskega sistema pogosto spregleda!

MS SQL Server, strežnik aplikacij in stran odjemalca delujejo na različnih računalnikih, strežniške aplikacije delujejo po pravicah posebej ustvarjenih Uporabniki sistema Windows;
Za MS SQL Server
- nastavljen je mešani način avtorizacije
- Uporabniki MS SQL, vključeni v vlogo serveradmin, ne sodelujejo pri delu 1C,
- za vsak IS 1C je bil ustvarjen ločen uporabnik MS SQL, ki nima privilegiranega dostopa do strežnika,
- uporabnik MS SQL ene informacijske varnosti nima dostopa do druge informacijske varnosti;
Uporabniki nimajo neposrednega dostopa do datotek Application Server in MS SQL Server
Delovna mesta operaterja so opremljena z operacijskim sistemom Windows 2000 / XP (ne Windows 95/98 / Me)

Ne zanemarjajte priporočil razvijalcev sistema in branja dokumentacije. Na diskih ITS v razdelku "Metodološka priporočila" so objavljena pomembna gradiva o nastavitvi sistema. Posebno pozornost posvetite naslednjim člankom:

Značilnosti delovanja aplikacije s strežnikom 1C: Enterprise
Postavitev podatkov 1C: Enterprise 8.0
Uporabniki posodabljajo 1C: Enterprise 8.0 Microsoft Windows brez skrbniških pravic
Urejanje seznama uporabnikov v imenu uporabnika, ki nima skrbniških pravic
Konfiguriranje nastavitev požarnega zidu SP2 za Windows XP za zagon SQL Server 2000 in namiznega stroja SQL Server (MSDE)
Konfiguriranje parametrov SP2 COM + Windows XP za delovanje strežnika 1C: Enterprise 8.0
Konfiguriranje parametrov požarnega zidu Windows XP SP2 za delovanje strežnika 1C: Enterprise 8.0
Konfiguriranje nastavitev požarnega zidu SP2 za Windows XP za upravitelja licenc HASP
Ustvarjanje varnostne kopije zbirke podatkov z uporabo SQL Server 2000
Vprašanja o namestitvi in konfiguraciji 1C: Enterprise 8.0 v možnosti "odjemalec-strežnik"(eden najpomembnejših člankov)
Posebnosti Nastavitve sistema Windows Server 2003 pri nameščanju strežnika 1C: Enterprise 8.0
Ureditev dostopa uporabnikov do informacijske baze v različici odjemalec-strežnik(eden najpomembnejših člankov)
Strežnik 1C: Enterprise in SQL Server
Podroben postopek namestitve 1C: Enterprise 8.0 v različici "odjemalec-strežnik"(eden najpomembnejših člankov)
Uporaba vgrajenega jezika na strežniku 1C: Enterprise

Toda ko berete dokumentacijo, bodite kritični do prejetih informacij, na primer v članku "Vprašanja namestitve in konfiguracije 1C: Enterprise 8.0 v različici" odjemalec-strežnik "", pravice, ki so potrebne za uporabnika USER1CV8SERVER, niso precej natančno opisano. Na spodnji seznam bodo povezave, tako na primer [ITS1] pomeni članek »Značilnosti dela aplikacij s strežnikom 1C: Enterprise«. Vse povezave do člankov so navedene glede na zadnjo številko ITS v času pisanja (januar 2006)

Uporabite pooblastila za uporabnike v kombinaciji s pooblastilom Windows

Od dveh možnih načinov avtorizacije uporabnikov: vgrajen 1C in kombiniran s pooblastilom OS Windows - če je mogoče, izberite kombinirano pooblastilo. Tako uporabniki med delom ne bodo zamenjani z več gesli, hkrati pa ne bodo znižali ravni varnosti sistema. Vendar pa je tudi za uporabnike, ki uporabljajo samo avtorizacijo sistema Windows, pri ustvarjanju zelo zaželeno, da nastavite geslo in šele nato onemogočite avtorizacijo 1C za danega uporabnika... Za zagotovitev obnovitve sistema v primeru uničenja strukture Active Directory je potrebno pustiti vsaj enega uporabnika, ki lahko v sistem vstopi s pooblastilom 1C.

Pri ustvarjanju vlog za aplikacijske rešitve ne dodajte pravic "v rezervi"

Vsaka vloga aplikacijske rešitve mora odražati minimalno zahtevani niz pravic za izvajanje dejanj, ki jih določa ta vloga. Vendar pa nekaterih vlog ni mogoče uporabiti sami. Na primer za interaktivni zagon zunanje zdravljenje ustvarite lahko ločeno vlogo in jo dodate vsem uporabnikom, ki potrebujejo zunanjo obdelavo.

Redno pregledujte dnevnike in sistemske dnevnike

Če je mogoče, uredite in avtomatizirajte pregled dnevnikov in sistemskih protokolov. S pravilno konfiguracijo in rednim pregledom dnevnikov (filtriranje samo po pomembnih dogodkih) lahko nepooblaščena dejanja odkrijemo zgodaj ali celo preprečimo v fazi priprave.

Nekatere funkcije različice odjemalec-strežnik

V tem razdelku so opisane nekatere funkcije različice odjemalec-strežnik in njihov vpliv na varnost. Za boljšo berljivost so sprejete naslednje oznake:

Pozor! opis ranljivosti

Shranjevanje informacij, ki nadzorujejo dostop do sistema

Shranjevanje seznama uporabnikov informacijske varnosti

Vse informacije o seznamu uporabnikov tega IS in vlogah, ki so jim na njem na voljo, so shranjene v tabeli Params v zbirki podatkov MS SQL (glej [ITS2]). Če pogledamo strukturo in vsebino te tabele, postane očitno, da so vsi uporabniški podatki shranjeni v zapisu z vrednostjo polja FileName "users.usr".

Ker predpostavljamo, da uporabniki nimajo dostopa do baze podatkov MS SQL, napadalec tega dejstva samo po sebi ne more uporabiti, če pa je mogoče izvesti kodo v MS SQL, se s tem "odprejo vrata" za pridobitev katerega koli ( !) Dostop iz 1C ... Isti mehanizem (z manjšimi spremembami) je mogoče uporabiti za datotečno različico sistema, ki glede na posebnosti različice datoteke popolnoma izključuje njeno uporabnost pri gradnji varnih sistemov.

Priporočilo: Trenutno ne obstaja način za popolno zaščito aplikacije pred takšno spremembo, razen uporabe sprožilcev na ravni strežnika MS SQL Server, ki pa lahko po drugi strani povzročijo težave pri posodabljanju različice platforme ali spreminjanju seznama uporabnikov . Za sledenje takšnim spremembam lahko uporabite dnevnike 1C (bodite pozorni na »sumljive« prijave v načinu konfiguratorja, ne da bi navedli uporabnika) ali pa nastavite stalno delovanje programa SQL Profiler (kar bo imelo izjemno negativen učinek na delovanje sistema) ali pa konfigurirate opozorila mehanizem (najverjetneje skupaj s sprožilci)

Shranjevanje informacij o seznamu IS na strežniku

Za vsak aplikacijski strežnik 1C se shranijo podatki o seznamu baz podatkov MS SQL, povezanih z njim. Vsaka podatkovna baza uporablja svoj niz povezav med strežnikom aplikacij in strežnikom MS SQL. Podatki o podatkovnih bazah, registriranih na aplikacijskem strežniku, skupaj z nizi povezav so shranjeni v datoteki srvrib.lst, ki se nahaja na strežniku v imeniku<Общие данные приложений>/ 1C / 1Cv8 (na primer C: / Dokumenti in nastavitve / Vsi uporabniki / Podatki aplikacije / 1C / 1Cv8 / srvrib.lst). Za vsako informacijsko varnost je shranjen celoten niz povezav, vključno z uporabniškim geslom MS SQL pri uporabi mešanega pooblastitvenega modela MS SQL. Zaradi prisotnosti te datoteke se je mogoče bati nepooblaščenega dostopa do baze podatkov MS SQL in če se v nasprotju s priporočili za dostop do vsaj ene baze uporablja privilegiran uporabnik (na primer "sa"), potem poleg grožnje enega IS je ogrožen celoten sistem, ki uporablja MS SQL.

Zanimivo je, da uporaba mešanega pooblastila in avtorizacije sistema Windows na strežniku MS SQL vodi do različnih vrst težav pri dostopu do te datoteke. Ključne negativne lastnosti avtorizacije sistema Windows bodo torej:

Delovanje vse informacijske varnosti na aplikacijskem strežniku in na strežniku MS SQL pod enim nizom pravic (najverjetneje odveč)
Iz postopka strežnika aplikacij 1C (ali na splošno od uporabnika USER1CV8SERVER ali njegovega enakovrednega) brez določanja gesla se lahko preprosto povežete s katero koli informacijsko varnostjo, ne da bi določili geslo

Po drugi strani pa bi lahko bilo napadalcu težje izvesti poljubno kodo iz uporabnikovega konteksta USER1CV8SERVER kot pa pridobivanje podane datoteke. Mimogrede, prisotnost takšne datoteke je še en argument za ločitev strežniških funkcij na različnih računalnikih.

Priporočilo: Datoteka srvrib.lst bi morala biti dostopna samo strežniškemu procesu. Če želite spremeniti to datoteko, nastavite revizijo.

Na žalost je privzeto ta datoteka skoraj popolnoma nečitljiva, kar je treba upoštevati pri uvajanju sistema. Idealna možnost bi bila, če bi aplikacijski strežnik med delovanjem preprečil branje in pisanje te datoteke (vključno z branjem in pisanjem prek uporabniških povezav, ki se izvajajo na tem strežniku).

Pomanjkanje avtorizacije pri ustvarjanju informacijske varnosti na strežniku

Pozor! Napaka pri avtorizaciji je bila odpravljena v izdaji 8.0.14 platforme 1C: Enterprise. Ta izdaja uvaja koncept "1C: Enterprise Server Administrator", čeprav je seznam skrbnikov določen na strežniku, sistem deluje, kot je opisano spodaj, zato ne pozabite na to možno funkcijo.

Verjetno največja ranljivost tega razdelka je možnost dodajanja skoraj neomejene informacijske varnosti strežniku aplikacij, zaradi česar vsak uporabnik, ki ima dostop do povezave s strežnikom aplikacij, samodejno dobi možnost izvajanja poljubne kode na strežniku aplikacij. . Poglejmo primer.

Sistem je treba namestiti v naslednji različici

MS SQL Server 2000 (npr. Ime omrežja SRV1)
Strežnik 1C: Enterprise 8.0 (ime omrežja SRV2)
Odjemalski del 1C: Enterprise 8.0 (ime omrežja WS)

Predpostavlja se, da ima uporabnik (v nadaljevanju USER), ki dela na WS, vsaj minimalen dostop do enega od IB -jev, registriranih na SRV2, vendar nima privilegiranega dostopa do SRV1 in SRV2. Na splošno kombinacija funkcij navedenih računalnikov ne vpliva na situacijo. Sistem je bil konfiguriran ob upoštevanju priporočil v dokumentaciji in na diskih ITS. Stanje se odraža na sl. 2.

konfigurirajte varnost COM + na aplikacijskem strežniku, tako da se imajo samo uporabniki 1C pravico povezati s procesom strežnika aplikacij (za več podrobnosti [ITS12]);

datoteka srvrib.lst mora biti samo za branje uporabnika USER1CV8SERVER (začasno omogočite pisanje, če želite strežniku dodati nov IB);

za povezavo z MS SQL uporabite samo protokol TCP / IP, v tem primeru lahko:
omejite povezave z uporabo požarnega zidu;

konfigurirajte uporabo nestandardnih vrat TCP, kar bo otežilo povezavo "tujcev" IS 1C;

uporabite šifriranje posredovanih podatkov med strežnikom aplikacij in strežnikom SQL;

požarni zid strežnika konfigurirajte tako, da ni mogoče uporabljati strežnikov MS SQL drugih proizvajalcev;

uporabite varnostna orodja za intranet, da izključite možnost pojavljanja nepooblaščenega računalnika v lokalno omrežje(IPSec, varnostne politike skupine, požarni zidovi itd.);

v nobenem primeru ne dodeli skrbniku USER1CV8SERVER skrbniških pravic na strežniku aplikacij.

Uporaba kode, ki se izvaja na strežniku

Pri uporabi različice 1C odjemalec-strežnik lahko razvijalec porazdeli izvajanje kode med odjemalcem in strežnikom aplikacij. Da bi se koda (postopek ali funkcija) lahko izvedla samo na strežniku, jo je treba postaviti v skupni modul, za katerega je nastavljena lastnost "Server", in v primeru, ko je izvedba modula dovoljena ne samo na strežniku, kodo postavite v omejen razdelek "# If Server":

# Če strežnik Potem
Funkcija OnServer (Param1, Param2 = 0) Izvoz // Ta funkcija se kljub svoji preprostosti izvaja na strežniku
Param1 = Param1 + 12;
Vrnitev Param1;
EndFunction
# EndIf

Ko uporabljate kodo, ki se izvaja na strežniku, ne pozabite:

koda se izvaja na strežniku aplikacij s pravicami USER1CV8SERVER (na voljo so objekti COM in datoteke strežnika);
vse uporabniške seje izvaja en primerek storitve, zato bo na primer zaradi prelivanja sklada na strežniku prišlo do prekinitve povezave vseh aktivnih uporabnikov;
odpravljanje napak strežniških modulov je težavno (na primer, v razhroščevalniku ne morete nastaviti prelomne točke), vendar je to treba storiti;
prenos nadzora s odjemalca na strežnik aplikacij in obratno lahko zahteva znatna sredstva z velikimi količinami poslanih parametrov;
uporaba interaktivnih orodij (obrazcev, dokumenti v preglednici, pogovorna okna), zunanja poročila in obdelava kode na strežniku aplikacij niso možni;
uporaba globalnih spremenljivk (spremenljivk aplikacijskega modula, deklariranih z oznako "Izvoz") ni dovoljena;

Za več podrobnosti glejte [ITS15] in druge članke ITS.

Strežnik aplikacij mora imeti posebne zahteve glede zanesljivosti. V pravilno zgrajenem sistemu odjemalec-strežnik morajo biti izpolnjeni naslednji pogoji:

nobeno dejanje odjemalske aplikacije ne sme prekiniti strežnika (razen v upravnih primerih);
strežnik se ne more zagnati programsko kodo prejeto od stranke;
viri morajo biti "pravično" porazdeljeni po odjemalskih povezavah, kar zagotavlja razpoložljivost strežnika ne glede na trenutno obremenitev;
če ni podatkovnih ključavnic, povezave strank ne bi smele vplivati na delo drug drugega;
na strežniku ni uporabniškega vmesnika, vendar je treba razviti orodja za spremljanje in beleženje;

Na splošno je sistem 1C zgrajen tako, da ustreza tem zahtevam (na primer na strežniku ni mogoče prisiliti zunanje obdelave), vendar je še vedno nekaj neprijetnih lastnosti, zato:

Priporočilo: Pri razvoju strežniške strani izvajanja je priporočljivo upoštevati načelo minimalnega vmesnika. Tisti. število vnosov v strežniške module iz odjemalca mora biti zelo omejeno, parametri pa strogo urejeni. Priporočilo: Pri prejemu parametrov postopkov in funkcij na strežniku je treba potrditi parametre (preveriti, ali parametri ustrezajo pričakovanemu tipu in razponu vrednosti). To se ne izvaja v standardnih rešitvah, vendar je zelo zaželeno, da se v lastne zasnove uvede obvezna validacija. Priporočilo: Ko na strani strežnika ustvarjate besedilo zahteve (še bolj pa ukazni parameter Zaženi), ne uporabljajte nizov, prejetih od odjemalca.

Splošno priporočilo bi bilo, da se seznanite z načeli varne gradnje spletu- uporabo zbirk podatkov in delo na podobnih načelih. Podobnost je res velika: prvič, tako kot spletna aplikacija je strežnik aplikacij vmesni sloj med bazo podatkov in uporabniškim vmesnikom (glavna razlika je v tem, da spletni strežnik tvori uporabniški vmesnik); drugič, z vidika varnosti podatkov, prejetim od odjemalca, ni mogoče zaupati, saj možno je zagnati zunanja poročila in obdelavo.

Prenašanje parametrov

Posredovanje parametrov v funkcijo (postopek), izvedeno na strežniku, je precej občutljivo vprašanje. To je predvsem posledica potrebe po njihovem prenosu med procesom strežnika aplikacij in odjemalcem. Ko se nadzor prenese s strani odjemalca na stran strežnika, se vsi preneseni parametri serijsko prenesejo, prenesejo na strežnik, kjer se "razpakirajo" in uporabijo. Pri premikanju s strani strežnika na stranko je postopek obraten. Tu je treba opozoriti, da ta shema pravilno obravnava podane parametre glede na referenco in vrednost. Pri prenosu parametrov veljajo naslednje omejitve:

Med odjemalcem in strežnikom (v obeh smereh) je mogoče prenesti samo nespremenljive vrednosti (torej katerih vrednosti se ne morejo spremeniti): primitivne vrste, reference, univerzalne zbirke, sistemske številčne vrednosti, shranjevanje vrednosti. Če poskusite prenesti kaj drugega, se odjemalska aplikacija zruši (tudi če strežnik poskuša prenesti napačen parameter).
Pri posredovanju parametrov ni priporočljivo prenašati velikih količin podatkov (na primer nizov, večjih od 1 milijona znakov), kar lahko negativno vpliva na delovanje strežnika.
Parametrov, ki vsebujejo krožno referenco, ne morete posredovati od strežnika do odjemalca in obratno. Ko poskusite prenesti takšen parameter, se odjemalska aplikacija zruši (tudi če strežnik poskuša posredovati napačen parameter).
Prenos zelo zapletenih zbirk podatkov ni priporočljiv. Pri poskusu posredovanja parametra z zelo veliko stopnjo gnezdenja se strežnik zruši (!).

Pozor! Najbolj neprijetna lastnost v tem trenutku je verjetno napaka pri podajanju kompleksnih zbirk vrednosti. Tako je na primer koda: Nesting Level = 1250;
M = Nov niz;
TransmitParameter = M;
Za MF = 1 po ciklu gnezdenja
MVint = Nov niz;
M. Dodaj (MVintr);
M = MVintr;
Konec cikla;
ServerFunction (PassedParameter);

Povzroči zrušitev strežnika, pri čemer so vsi uporabniki odklopljeni, kar se zgodi, preden se nadzor prenese na vdelano kodo jezika.

Uporaba nevarnih funkcij na strani strežnika.

Vseh vgrajenih jezikovnih funkcij ni mogoče uporabiti v kodi, ki se izvaja na aplikacijskem strežniku, vendar je tudi med razpoložljivim orodjem veliko konstrukcij "problemov", ki jih lahko grobo razvrstimo na naslednji način:

lahko zagotovi možnost izvajanja kode, ki ni v konfiguraciji (skupina "Izvajanje kode")
ki lahko odjemalski aplikaciji posreduje podatke o uporabnikovi datoteki in operacijskem sistemu ali izvede dejanja, ki niso povezana z delom s podatki ("Kršitev pravic")
lahko povzroči zasilno zaustavitev strežnika ali uporabi zelo velike vire (skupina "Napaka strežnika")
lahko povzroči napako pri delu odjemalca (skupina "Napaka odjemalca") - ta vrsta se ne upošteva. Primer: posredovanje spremenljive vrednosti strežniku.
napake programskih algoritmov (neskončne zanke, neomejena rekurzija itd.) ("Napake pri programiranju")

Glavni problematični konstrukti, ki so mi znani (s primeri), so navedeni spodaj:

Izvajanje postopka (<Строка>)

Izvedba kode. Izvede del kode, ki mu je posredovan kot vrednost niza. Pri uporabi na strežniku se morate prepričati, da podatki, prejeti od odjemalca, niso uporabljeni kot parameter. Naslednja uporaba je na primer neveljavna:
# Če strežnik Potem
Postopek pri izvozu strežnika (Param1)
Izvedi (Param1);
Konec postopka
# EndIf

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

Ustvari objekt COM zunanje aplikacije s pravicami USER1CV8SERVER na strežniku aplikacij (ali drugem podanem računalniku). Ko uporabljate na strežniku, se prepričajte, da iz odjemalca ne prenašajo parametrov. Na strani strežnika pa je učinkovito uporabljati to funkcijo pri uvozu / izvozu, pošiljanju podatkov po internetu, izvajanju nestandardnih funkcij itd.

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

Kršitev pravic in izvajanje kode. Podobno kot prejšnji, dobimo le objekt COM, ki ustreza datoteki.

Postopki in funkcije ComputerName (), TempFilesDirectory (), ProgramsDirectory (), Uporabniki sistema Windows ()

Kršitev pravic. Po izvedbi na strežniku dovolite, da ugotovite podrobnosti o organizaciji strežniškega podsistema. Ko se uporabljajo na strežniku, se prepričajte, da se podatki ne prenašajo odjemalcu ali pa niso na voljo operaterjem brez ustreznega pooblastila. Bodite posebno pozorni na dejstvo, da je mogoče podatke poslati nazaj v parametru, ki ga posreduje referenca.

Postopki in funkcije za delo z datotekami (CopyFile, FindFiles, CombineFiles in mnogi drugi), pa tudi vrste "File".

Kršitev pravic. Z izvajanjem na strežniku omogočite splošen dostop do lokalnih (in v omrežju) datotek, dostopnih pod uporabniškimi pravicami USER1CV8SERVER. Če se uporablja namerno, je mogoče učinkovito izvajati naloge, kot je uvoz / izvoz podatkov na strežniku.

Pred uporabo teh funkcij obvezno preverite uporabniške pravice 1C. Za preverjanje uporabniških pravic lahko v strežniškem modulu uporabite naslednjo konstrukcijo:
# Če strežnik Potem
Postopek ExecuteWork z izvozom datoteke ()
RoleAdministrator = Metadata.Role.Administrator;
Uporabnik = SessionParameters.CurrentUser;
Če User.Roles.Contains (RoleAdministrator) Potem
// Tu se izvede koda za delo z datotekami
EndIf;
# EndIf
Če uporabljate te postopke in funkcije, ne pozabite preveriti parametrov, sicer obstaja nevarnost, da bi pomotoma ali namerno povzročili nepopravljivo škodo aplikacijskemu strežniku 1C, na primer pri izvajanju kode na strežniku:
Pot = "C: \ Documents and Settings \ All Users \ Application Data \ 1C \ 1Cv8 \";
MoveFile (Pot + "srvrib.lst", Pot + "HereWhereFile");
Po izvedbi takšne kode na strežniku, če ima uporabnik USER1CV8SERVER dovoljenje za njeno spremembo, kot je opisano zgoraj, in po ponovnem zagonu strežniškega procesa (privzeto 3 minute po odjavi vseh uporabnikov) se bo pojavilo VELIKO vprašanje o zagonu strežnika . Možno pa je in popolna odstranitev datoteke ...

Vrste "XBase", "BinaryData", "Read XML", "Write XML", "Transform XSL", "Write ZipFile", "ReadZipFile", "ReadText", "WriteText"

Kršitev pravic. Z izvajanjem na strežniku omogočajo dostop do lokalnih datotek (in v omrežju) določenih vrst ter branje / pisanje pod uporabniškimi pravicami USER1CV8SERVER. Če se uporablja namerno, je mogoče učinkovito izvajati naloge, kot so uvoz / izvoz podatkov na strežniku, beleženje nekaterih funkcij in reševanje upravnih nalog. Na splošno so priporočila enaka prejšnjemu odstavku, vendar morate upoštevati možnost prenosa podatkov teh datotek (ne pa tudi objektov vseh teh vrst) med odjemalcem in strežnikom.

Vrsta sistemskih informacij

Kršitev pravic. Omogoča, da v primeru napačne uporabe podatkov in prenosa v odjemalčev del aplikacije dobite podatke o strežniku aplikacij. Priporočljivo je omejiti pravico do uporabe pri uporabi.

Vrste "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Kršitev pravic. Ko se uporablja na strežniku, se poveže z oddaljenim računalnikom iz strežnika aplikacij pod pravicami USER1CV8SERVER. Priporočila:

Nadzor parametrov pri klicanju metod.

Nadzor uporabniških pravic 1C.

Hude omejitve pravic uporabnika USER1CV8SERVER do dostopa do omrežja.

Pravilna konfiguracija požarnega zidu na aplikacijskem strežniku 1C.

Pri pravilni uporabi je priročno organizirati, na primer pošiljanje e-pošte s strežnika aplikacij.

Vrste "InformationBaseUserManager", "InformationBaseUser"

Kršitev pravic.Če se uporablja nepravilno (v privilegiranem modulu), je mogoče dodati uporabnike ali spremeniti parametre avtorizacije obstoječih uporabnikov.

Oblika funkcije

Zrušitev strežnika. Ja! Ta na videz neškodljiva funkcija, če ne nadzirate njenih parametrov in jo izvedete na strežniku, lahko povzroči nenormalno prekinitev strežniške aplikacije. Napaka se pokaže na primer pri oblikovanju številk in uporabi izhodnega načina za začetne ničle in veliko število znakov
Oblika (1, "CHT = 999; CHVN =");
Upam, da bo ta napaka odpravljena v naslednjih izdajah platforme, vendar za zdaj pri vseh klicih te funkcije, ki jih je mogoče izvesti na strežniku, preverite parametre klica.

Postopki in funkcije za shranjevanje vrednosti (ValueInStringInternally, ValueInFile)

Zrušitev strežnika. Te funkcije ne obravnavajo krožnih referenc v zbirkah in zelo globokega gnezdenja, zato se lahko v nekaterih zelo posebnih primerih zrušijo.

Napake mejnih in posebnih vrednosti parametrov v funkcijah. Nadzor izvajanja.

Ena od težav, s katerimi se lahko srečate pri uporabi strežnika, je velika "odgovornost" strežniških funkcij (možnost nenormalne prekinitve celotne strežniške aplikacije zaradi napake v eni povezavi in uporabe enega "prostora virov" za vse povezave). Zato je treba nadzorovati glavne parametre časa izvajanja:

Za vgrajene jezikovne funkcije preverite njihove zagonske parametre (odličen primer je funkcija »Oblika«)
Pri uporabi zank se prepričajte, da je sprožen pogoj izhoda zanke. Če je zanka potencialno neskončna, umetno omejite število ponovitev: MaximumIterationCount = 1.000.000;
Število ponovitev = 1;
Adijo
Funkcija, ki ne more vrniti napačne vrednosti ()
AND (Števec ponavljanja<МаксимальноеЗначениеСчетчикаИтераций) Цикл
// .... telo zanke
Števec ponovitev = Števec ponovitev + 1;
Konec cikla;
IfIterationCount> MaximumIterationCounterValue Potem
// .... obravnavati dogodek predolgega cikla
EndIf;
Pri uporabi rekurzije omejite največjo stopnjo gnezdenja.
Pri oblikovanju in izvajanju poizvedb poskusite preprečiti zelo dolge izbire in izbire velike količine informacij (na primer pri uporabi pogoja "V HIERARHIJI" ne uporabljajte prazne vrednosti)
Pri načrtovanju informacijske baze zagotovite dovolj velik rob številske zmogljivosti za številke (sicer seštevanje in množenje postaneta nekomutativna in asociativna, kar otežuje odpravljanje napak)
V izvedljivih zahtevah preverite prisotnost logike dela NULL vrednosti in pravilno delo pogoji in izrazi poizvedb z uporabo NULL.
Ko uporabljate zbirke, nadzirajte njihovo prenos med strežnikom aplikacij in odjemalcem.

Uporaba terminalskega dostopa do odjemalca za omejitev dostopa

Nič nenavadnega ni, da bi našli priporočila za uporabo terminalskega dostopa za omejitev dostopa do podatkov in povečanje učinkovitosti z izvajanjem kode na strani odjemalca na terminalskem strežniku. Da, če je pravilno konfiguriran, lahko uporaba terminalskega dostopa resnično poveča splošno raven varnosti sistema, vendar se je na žalost pogosto mogoče srečati z dejstvom, da se v praksi varnost sistema le zmanjšuje. Poskusimo ugotoviti, s čim je to povezano. Zdaj obstajata dva pogosta načina organiziranja terminalskega dostopa, to sta Microsoftovi terminalski storitvi (protokol RDP) in strežnik Citrix Metaframe (protokol ICA). Na splošno orodja Citrix ponujajo veliko bolj prilagodljive možnosti upravljanja dostopa, vendar so stroški teh rešitev bistveno višji. Upoštevali bomo le osnovne značilnosti, ki so skupne obema protokoloma in lahko znižajo splošno raven varnosti. Pri dostopu do terminala obstajajo le tri glavne nevarnosti:

Sposobnost blokiranja dela drugih uporabnikov z zasegom prevelike količine virov
Dostop do podatkov drugih uporabnikov.
Nepooblaščeno kopiranje podatkov s terminalskega strežnika v uporabnikov računalnik

V vsakem primeru vam terminalske storitve omogočajo:

Povečajte zanesljivost dela (v primeru okvare na terminalnem računalniku lahko uporabnik nato nadaljuje z delom na istem mestu)
Omejite dostop do odjemalca in datotek, ki jih shrani.
Računalniško obremenitev prenesite z uporabnikovega delovnega mesta na strežnik za dostop do terminala
Sistemske nastavitve upravljajte bolj centralno. Za uporabnike bodo shranjene nastavitve veljavne ne glede na računalnik, s katerega so se prijavili.
V nekaterih primerih lahko za oddaljeni dostop do sistema uporabite terminalsko rešitev.

Omejiti je treba število možnih povezav s terminalskim strežnikom enega uporabnika

Zaradi "požrešnosti" odjemalca 1C glede virov je nujno omejiti največje število hkratnih povezav enega uporabnika (operaterja) s terminalskim strežnikom. Aktivno uporabljena povezava lahko porabi do 300 MB pomnilnika samo z enim primerkom aplikacije. Poleg pomnilnika se aktivno uporablja procesorski čas, kar prav tako ne prispeva k stabilnosti uporabnikov tega strežnika. Poleg preprečevanja prekomerne uporabe strežniških virov lahko ta omejitev prepreči uporabo računa nekoga drugega. Izvedeno s standardnimi nastavitvami terminalskega strežnika.

Ne smete dovoliti, da se v eni povezavi hkrati izvajata več kot ena ali dve odjemalski aplikaciji 1C

Diktirani iz istih razlogov kot v prejšnjem odstavku, tehnično pa težje izvedljivi. Težava je v tem, da je skoraj nemogoče preprečiti ponovni zagon 1C s pomočjo terminalskega strežnika (spodaj bo pojasnjeno, zakaj), zato morate to funkcijo implementirati na ravni uporabljene rešitve (kar tudi ni dobro rešitev, saj lahko v primeru napačne prekinitve aplikacije pride do nekaj "visečih" sej, bo treba izboljšati uporabljeno rešitev v aplikacijskem modulu in nekaterih referenčnih knjigah, kar bo otežilo uporabo posodobitev iz 1C). Zelo zaželeno je, da uporabnik pusti možnost izvajanja dveh aplikacij, da lahko izvede nekatera dejanja (na primer ustvarjanje poročil) v ozadje- odjemalska aplikacija je na žalost dejansko enonitna.

Pravice dostopa do terminalskega strežnika ni priporočljivo dodeliti uporabnikom, ki imajo pravico do izvajanja računalniških nalog, ki zahtevajo veliko sredstev, v 1C ali preprečiti tak zagon med aktivnim delom drugih uporabnikov.

Seveda je bolje pustiti dostop do terminalskega strežnika le uporabnikom, ki ne uporabljajo takih nalog, kot so rudarjenje podatkov, geografske sheme, uvoz / izvoz in druga opravila, ki resno obremenjujejo stranko odjemalca aplikacije. Če kljub temu obstaja potreba po razrešitvi takih nalog, je potrebno: obvestiti uporabnika, da lahko te naloge vplivajo na uspešnost drugih uporabnikov, v dnevnik zabeležiti dogodek začetka in konca takega procesa , dovolijo izvedbo le ob predvidenem času itd.

Zagotoviti je treba, da lahko vsak uporabnik piše samo v strogo določene imenike terminalskega strežnika, drugi uporabniki pa do njih nimajo dostopa.

Prvič, če ne omejite možnosti pisanja v imenike v skupni rabi (na primer v imenik, v katerem je nameščen 1C), lahko napadalec spremeni vedenje programa za vse uporabnike. Drugič, podatki enega uporabnika (začasne datoteke, datoteke za shranjevanje nastavitev poročila itd.) V nobenem primeru ne bi smeli biti na voljo drugemu uporabniku terminalskega strežnika - na splošno je to pravilo izpolnjeno med običajnimi nastavitvami. Tretjič, napadalec ima še vedno možnost "zasuti" particijo, tako da na trdem disku ne ostane več prostora. Vem, ugovarjali mi bodo, da v operacijskem sistemu Windows, začenši z operacijskim sistemom Windows 2000, obstaja mehanizem določanja kvot, vendar je to precej drag mehanizem in skoraj nisem videl njegove resnične uporabe.

Če bi bila prejšnja vprašanja o nastavitvi dostopa na splošno precej enostavna za izvedbo, potem se že tako (na videz) preprosto opravilo, kot je urejanje dostopa uporabnikov do datotek, izvaja ne trivialno. Prvič, če se mehanizem kvote ne uporablja, se lahko shranijo velike datoteke. Drugič, sistem je zgrajen tako, da bo datoteko skoraj vedno mogoče shraniti, da bo na voljo drugemu uporabniku.

Ker je nalogo povsem težko rešiti, je priporočljivo pregledati večino dogodkov datotek

Onemogočiti je treba povezavo (preslikavo) diskovnih naprav, tiskalnikov in odložišča odjemalske delovne postaje.

V RDP in ICA je mogoče organizirati samodejno povezavo diskov, tiskalnikov, odložišča com-port terminalskega računalnika s strežnikom. Če obstaja ta možnost, je skoraj nemogoče prepovedati zagon tuje kode na terminalnem strežniku in shranjevanje podatkov iz 1C na odjemalcu za dostop do terminala. Dovoli te funkcije samo posameznikom s skrbniškimi pravicami.

Dostop do omrežnih datotek s terminalskega strežnika mora biti omejen.

Če tega ne storite, lahko uporabnik znova zažene neželeno kodo ali shrani podatke. Ker navaden dnevnik ne sledi dogodkom v datotekah (mimogrede, to je dobra ideja za izvajanje razvijalcev platforme) in je skoraj nemogoče konfigurirati sistemsko revizijo v celotnem omrežju (ne bo dovolj sredstev za njeno servisiranje) , bolje je, da lahko uporabnik pošlje podatke ali natisne ali po elektronski pošti. Bodite posebno pozorni, da terminalski strežnik ne deluje neposredno z izmenljivimi mediji uporabnikov.

Pri ustvarjanju varnega sistema v nobenem primeru ne pustite aplikacijskega strežnika na terminalnem strežniku.

Če se aplikacijski strežnik zažene na istem računalniku kot odjemalske aplikacije, obstaja veliko možnosti za motnje v njegovem normalnem delovanju. Če iz nekega razloga ni mogoče ločiti funkcij terminalskega strežnika in aplikacijskega strežnika, potem posebno pozornost namenite uporabnikovemu dostopu do datotek, ki jih uporablja strežnik aplikacij.

Treba je izključiti možnost zagona vseh aplikacij razen 1C: Enterprise na terminalnem strežniku.

To je ena izmed najtežje izvedljivih postavk želja. Za začetek morate pravilno konfigurirati varnostni pravilnik skupine za domeno. Vse upravne predloge in politike omejevanja programske opreme morajo biti pravilno konfigurirane. Če se želite preizkusiti, se prepričajte, da so blokirane vsaj naslednje funkcije:

Kompleksnost izvajanja te zahteve pogosto vodi v možnost zagona "dodatne" seje 1C na terminalnem strežniku (tudi če so druge aplikacije omejene, načeloma ni mogoče prepovedati zagona 1C s pomočjo sistema Windows).

Upoštevajte omejitve običajnega dnevnika (vsi uporabniki uporabljajo program iz enega računalnika)

Očitno je, da uporabniki odprejo 1C v terminalnem načinu, zato bo terminalski strežnik zabeležen v dnevnik. Iz katerega računalnika se je uporabnik povezal, dnevnik ne poroča.

Terminalni strežnik - varnost ali ranljivost?

Torej, po preučitvi glavnih značilnosti severnega terminala lahko rečemo, da potencialno severni terminal lahko pomaga pri avtomatizaciji porazdelitve računalniške obremenitve, vendar je izgradnja varnega sistema precej težka. Eden od primerov, ko je uporaba terminalskega strežnika najučinkovitejša, je zagon programa 1C brez Windows Explorerja v celozaslonskem načinu za uporabnike z omejeno funkcionalnostjo in specializiranim vmesnikom.

Delo na strani odjemalca

Uporaba Internet Explorerja (IE)

Eden od pogojev za normalno delovanje odjemalca 1C je uporaba komponent Internet Explorerja. Pri teh komponentah morate biti zelo previdni.

Pozor! Prvič, če je v IE priključen vohunski ali oglasni modul, se bo naložil, tudi če si ogledate datoteke HTML v 1C. Doslej nisem videl zavestne uporabe te funkcije, vendar sem v eni od organizacij srečal naložen "vohunski" modul enega od pornografskih omrežij, ko je deloval 1C (protivirusni program ni bil posodobljen, simptomi ki so bili ugotovljeni: pri nastavitvi požarnega zidu je bilo jasno, da 1C poskuša vrata 80 povezati s pornografskim mestom). Pravzaprav je to še en argument v prid dejstvu, da mora biti zaščita celovita.

Pozor! Drugič, sistem 1C omogoča uporabo filmov flash, objektov ActiveX, VBScript v prikazanih dokumentih HTML, pošiljanje podatkov v internet, celo odpiranje datotek PDF (!), Čeprav v slednjem primeru zahteva "odpiranje ali shranjevanje". .. na splošno, kar vam srce poželi. Primer ne povsem smiselne uporabe vgrajenih zmogljivosti za ogled in urejanje HTML:

Ustvarite nov dokument HTML (Datoteka -> Novo -> Dokument HTML).
Pojdite na zavihek "Besedilo" praznega dokumenta.
Izbriši besedilo (v celoti).
Pojdite na zavihek "Pogled" tega dokumenta
Z vlečenjem in spuščanjem premaknite datoteko s pripono SWF (to so datoteke filmov z bliskavico) iz odprtega raziskovalca v okno dokumenta, na primer iz predpomnilnika brskalnika, čeprav je to mogoče z zabavo FLASH.
Kako lepo! Na 1C lahko igrate igračo!

Z vidika varnosti sistema je to popolnoma napačno. Doslej zaradi te ranljivosti nisem videl posebnih napadov na 1C, vendar se bo najverjetneje izkazalo za vprašanje časa in vrednosti vaših podatkov.

Pri delu s poljem dokumenta HTML se pojavijo še nekatere manjše točke, vendar sta navedeni glavni dve. Čeprav se kreativno lotite teh funkcij, lahko organizirate resnično neverjetne zmožnosti vmesnika za delo z 1C.

Uporaba zunanjih poročil in obdelava.

Pozor! Zunanja poročila in obdelava - po eni strani je priročen način za izvajanje dodatnih obrazcev za tiskanje, rutinsko poročanje, specializirana poročila, po drugi strani pa potencialni način, da se izognete številnim varnostnim omejitvam sistema in motite delovanje strežnika aplikacij (na primer glejte zgoraj v razdelku »Prenašanje parametrov«). V sistemu 1C je v nizu pravic za vlogo »Interaktivno odpiranje zunanje obdelave« poseben parameter, ki pa s tem ne reši problema v celoti - za popolno rešitev je treba bistveno zožiti krog uporabnikov ki lahko upravljajo zunanje tiskarske obrazce, rutinska poročila in druge standardne značilnosti standardnih rešitev, ki se izvajajo z zunanjo obdelavo. Na primer, v SCP imajo vse osnovne uporabniške vloge privzeto možnost dela z referenčno knjigo dodatnih obrazcev za tiskanje, to pa je dejansko možnost uporabe kakršne koli zunanje obdelave.

Uporaba standardnih mehanizmov tipičnih rešitev in platforme (izmenjava podatkov)

Nekateri standardni mehanizmi so potencialno nevarni in na precej nepričakovane načine.

Tiskanje seznamov

Vsak seznam (na primer imenik ali register informacij) v sistemu je mogoče natisniti ali shraniti v datoteko. Če želite to narediti, je dovolj, da uporabite standardno funkcijo, ki je na voljo v kontekstnem meniju in meniju "Dejanja":

Upoštevajte, da se lahko skoraj vse, kar uporabnik vidi na seznamih, predvaja v zunanje datoteke. Edino, kar lahko svetujemo, je, da vodimo protokol za tiskanje dokumentov na tiskalniških strežnikih. Za posebej kritične oblike je treba konfigurirati akcijsko ploščo, povezano s poljem zaščitene tabele, tako da možnost prikaza seznama ni na voljo na tej plošči, in onemogočiti kontekstni meni (glej sliko 6).

Izmenjava podatkov v porazdeljeni bazi podatkov

Oblika izmenjave podatkov je precej preprosta in je opisana v dokumentaciji. Če ima uporabnik možnost preglasiti več datotek, lahko v sistemu izvede nepooblaščene spremembe (čeprav to traja precej časa). Možnost ustvarjanja periferne baze z načrti izmenjave porazdeljenih baz podatkov ne bi smela biti na voljo običajnim operaterjem.

Standardna izmenjava podatkov XML

V standardni izmenjavi podatkov, ki se uporablja za izmenjavo med tipičnimi konfiguracijami (na primer »Upravljanje trgovine« in »Računovodstvo podjetja«), je v pravilih izmenjave mogoče določiti upravljalce dogodkov za nalaganje in razkladanje predmetov. To dosežemo tako, da iz datoteke dobimo upravljavec in postopek "Execute ()" za standardno obdelavo nalaganja in razkladanja datoteke (postopek "Execute ()" se zažene na strani odjemalca). Očitno ni težko ustvariti take ponarejene datoteke za izmenjavo, ki bo izvajala zlonamerna dejanja. Za večino uporabniških vlog za splošne rešitve je privzeto omogočena izmenjava.

Priporočilo: omejiti dostop do izmenjave XML za večino uporabnikov (to prepustite samo skrbnikom IS). Vodite dnevnike izvedb te obdelave in shranite datoteko izmenjave, na primer tako, da jo pošljete po elektronski pošti pred nalaganjem administratorju IB.

Uporaba splošnih poročil, zlasti konzole za poročila

Druga težava je privzeti dostop uporabnikov do splošnih poročil, zlasti poročila konzole za poročila. Za to poročilo je značilno, da vam omogoča, da izpolnite skoraj vse zahteve glede varnosti informacij, in čeprav je sistem pravic 1C (vključno z RLS) konfiguriran precej strogo, uporabniku omogoča, da dobi veliko "dodatnih" informacij in prisiliti strežnik, da izvede takšno zahtevo, ki bo prevzela vse sisteme virov.

Uporaba celozaslonskega načina (namizni način)

Eden od učinkovitih načinov organiziranja specializiranih vmesnikov z omejenim dostopom do funkcionalnosti programa je celozaslonski način glavne (in po možnosti edine) oblike uporabljenega vmesnika. V tem primeru ni vprašanj o dostopnosti, na primer meni "Datoteka" in vsa dejanja uporabnika so omejena z zmožnostmi uporabljenega obrazca. Za več podrobnosti glejte "Značilnosti izvajanja namiznega načina" na disku ITS.

Rezerva

Varnostno kopiranje za različico 1C odjemalca in strežnika je mogoče izvesti na dva načina: nalaganje podatkov v datoteko z razširitvijo dt in ustvarjanje varnostnih kopij z uporabo SQL. Prva metoda ima precej pomanjkljivosti: potreben je izključen dostop, izdelava kopije sama traja veliko dlje, v nekaterih primerih (če je kršena struktura IB) ustvarjanje arhiva ni mogoče, vendar obstaja ena prednost - minimalna velikost arhiva. Za varnostno kopiranje SQL velja ravno obratno: kopija se ustvari v ozadju s strežnikom SQL zaradi njene preproste strukture in pomanjkanja stiskanja - to je zelo hiter postopek in dokler je fizična celovitost SQL -ja podatkovna baza ni kršena, varnostno kopiranje je izvedeno, vendar velikost kopije sovpada z resnično velikostjo IB v razširjenem stanju (stiskanje ni izvedeno). Zaradi dodatnih prednosti sistema za varnostno kopiranje MS SQL je primernejša njegova uporaba (dovoljene so 3 vrste varnostnih kopij: popolna, diferencialna, kopija dnevnika transakcij; možno je ustvarjanje redno izvajanih nalog; hitro uvajanje) varnostno kopijo in rezervni sistem; implementiral sposobnost napovedovanja velikosti zahtevanega prostora na disku itd.). Glavni vidiki organiziranja varnostnega kopiranja z vidika sistemske varnosti so:

Potreba po izbiri mesta za shranjevanje varnostnih kopij, tako da niso na voljo uporabnikom.
Potreba po shranjevanju varnostnih kopij na fizični razdalji od strežnika MS SQL (v primeru naravnih nesreč, požarov, napadov itd.)
Sposobnost podelitve pravic za zagon varnostnih kopij uporabniku, ki nima dostopa do varnostnih kopij.

Za podrobnejše informacije glejte dokumentacijo MS SQL.

Šifriranje podatkov

Za zaščito podatkov pred nepooblaščenim dostopom se pogosto uporabljajo različna kriptografska orodja (tako programska kot strojna), vendar je njihova izvedljivost v veliki meri odvisna od pravilnosti uporabe in splošne varnosti sistema. Šifriranje podatkov bomo obravnavali na različnih stopnjah prenosa in shranjevanja podatkov z uporabo najpogostejših načinov in glavnih napak pri načrtovanju sistema, ki uporablja kriptografska sredstva.

Obdelavo informacij je mogoče zaščititi na več glavnih stopnjah:

Prenos podatkov med odjemalcem sistema in strežnikom aplikacij
Prenos podatkov med strežnikom aplikacij in MS SQL Server
Podatki, shranjeni na MS SQL Server (podatkovne datoteke na fizičnem disku)
Šifriranje podatkov, shranjenih v informacijski varnosti
Zunanji podatki (v zvezi z varnostjo informacij)

Za podatke, shranjene na strani odjemalca in na strežniku aplikacij (shranjene uporabniške nastavitve, seznam varnosti informacij itd.), Je šifriranje upravičeno le v zelo redkih primerih in zato tukaj ni upoštevano. Pri uporabi kriptografskih orodij ne smemo pozabiti, da lahko njihova uporaba znatno zmanjša zmogljivost sistema kot celote.

Splošne informacije o kriptografski zaščiti omrežnih povezav pri uporabi protokola TCP / IP.

Brez zaščite vse omrežne povezave občutljivi na nepooblaščen nadzor in dostop. Za njihovo zaščito lahko uporabite šifriranje podatkov na ravni omrežnega protokola. Za šifriranje podatkov, poslanih v lokalnem omrežju, se najpogosteje uporabljajo orodja IPSec, ki jih ponuja operacijski sistem.

Orodja IPSec omogočajo šifriranje poslanih podatkov z algoritmi DES in 3DES ter preverjanje integritete z uporabo razpršilnih funkcij MD5 ali SHA1. IPSec lahko deluje v dveh načinih: transportni način in način predora. Način transporta je bolj primeren za zaščito povezav LAN. Način predora lahko uporabite za organizacijo povezav VPN med posameznimi segmenti omrežja ali za zaščito oddaljene povezave z lokalnim omrežjem prek odprtih podatkovnih kanalov.

Glavne prednosti tega pristopa so:

Sposobnost centralnega upravljanja varnosti z orodji Active Directory.
Sposobnost izključitve nepooblaščenih povezav z aplikacijskim strežnikom in strežnikom MS SQL (na primer je možno zaščititi pred nepooblaščenim dodajanjem zaščite informacij na strežniku aplikacij).
Odprava "poslušanja" omrežnega prometa.
Obnašanje aplikativnih programov (v tem primeru 1C) ni potrebno spreminjati.
Standard takšne rešitve.

Vendar ima ta pristop omejitve in slabosti:

IPSec ne ščiti podatkov pred vdorom in prisluškovanjem neposredno v izvornem in ciljnem računalniku.
Količina podatkov, prenesenih po omrežju, je nekoliko večja kot brez uporabe IPSec.
Pri uporabi IPSec več več obremenitve do centralnega procesorja.

Podroben opis izvajanja zmogljivosti IPSec presega obseg tega članka in zahteva razumevanje osnovnih načel protokola IP. Če želite pravilno konfigurirati zaščito povezave, preberite ustrezno dokumentacijo.

Ločeno je treba omeniti več vidikov licenčne pogodbe z 1C pri organizaciji povezav VPN. Dejstvo je, da kljub odsotnosti tehničnih omejitev pri povezovanju več segmentov lokalnega omrežja ali oddaljenem dostopu ločenega računalnika do lokalnega omrežja običajno potrebujete več osnovnih zalog.

Šifriranje podatkov med prenosom med odjemalskim delom sistema in strežnikom aplikacij.

Poleg šifriranja pri omrežni protokol, je mogoče šifrirati podatke na ravni protokola COM +, ki je omenjen v članku "Ureditev dostopa uporabnikov do baze podatkov v različici odjemalec-strežnik" ITS. Za izvajanje je treba nastaviti nastavitve za preverjanje pristnosti "Zasebnost paketov" za klice za aplikacijo 1CV8 v komponentnih storitvah. Ko je nastavljen na ta način, je paket overjen in šifriran, vključno s podatki, pa tudi identiteto in podpisom pošiljatelja.

Šifriranje podatkov med prenosom med aplikacijskim strežnikom in MS SQL strežnikom

MS SQL Server ponuja naslednja orodja za šifriranje podatkov:

Za prenos podatkov med strežnikom aplikacij in strežnikom MS SQL je mogoče uporabiti plast zaščitenih vtičnic (SSL).
Pri uporabi omrežne knjižnice Multiprotocol se uporablja šifriranje podatkov na ravni RPC. To je potencialno šibkejše šifriranje kot SSL.
Če se uporablja protokol skupnega pomnilnika (to se zgodi, če sta strežnik aplikacij in strežnik MS SQL v istem računalniku), se šifriranje v nobenem primeru ne uporablja.

Če želite ugotoviti potrebo po šifriranju vseh poslanih podatkov za določen strežnik MS SQL, uporabite pripomoček "Server Network Utility". Zaženite ga in na zavihku "Splošno" potrdite polje "Prisilno šifriranje protokola". Način šifriranja je izbran glede na način, ki ga uporablja odjemalska aplikacija (tj. Aplikacijski strežnik 1C). Če želite uporabljati protokol SSL, morate v svojem omrežju ustrezno konfigurirati izdajatelja certifikatov.

Če želite ugotoviti potrebo po šifriranju vseh poslanih podatkov za določen aplikacijski strežnik, morate uporabiti pripomoček "Client Network Utility" (običajno se nahaja v "C: \ WINNT \ system32 \ cliconfg.exe"). Tako kot v prejšnjem primeru na zavihku »Splošno« potrdite polje »Prisilno šifriranje protokola«.

Upoštevati je treba, da lahko uporaba šifriranja v tem primeru pomembno vpliva na delovanje sistema, zlasti pri uporabi poizvedb, ki vračajo velike količine informacij.

Za popolnejšo zaščito povezave med strežnikom aplikacij in strežnikom MS SQL pri uporabi protokola TCP / IP lahko priporočamo več sprememb privzetih nastavitev.

Najprej lahko nastavite vrata, ki niso standardna (vrata 1433 so privzeto uporabljena). Če se odločite za uporabo nestandardnih vrat TCP za komunikacijo, upoštevajte:

MS SQL Server in Application Server morata uporabljati ista vrata.
Ko uporabljate požarne zidove, morajo biti ta vrata dovoljena.
Ne morete nastaviti vrat, ki jih lahko uporabljajo druge aplikacije na strežniku MS SQL. Za referenco glejte http://www.ise.edu/in-notes/iana/assignments/port-numbers (URL vzeto iz knjig SQL Server Online).
Če uporabljate več primerkov strežnika MS SQL Server, preberite dokumentacijo MS SQL za konfiguracijo (razdelek »Konfiguriranje omrežnih povezav«).

Drugič, v nastavitvah protokola TCP / IP na strežniku MS SQL lahko izberete potrditveno polje "Skrij strežnik", ki prepoveduje odzive na zahteve za oddajanje za ta primerek storitve MS SQL Server.

Šifriranje podatkov MS SQL, shranjenih na disku

Na voljo je precej velik izbor programske in strojne opreme za šifriranje podatkov, ki se nahajajo na lokalnem disku (to je standardna sposobnost sistema Windows za uporabo EFS in uporabo ključev eToken ter programe drugih proizvajalcev, kot sta Jetico Bestcrypt ali PGPDisk). Ena od glavnih nalog teh orodij je zaščita podatkov v primeru izgube medija (na primer, ko je strežnik ukraden). Posebej je treba opozoriti, da Microsoft ne priporoča shranjevanja baz podatkov MS SQL na šifriranih medijih, kar je povsem razumno. Glavni problem v tem primeru je znaten padec produktivnosti in možne težave zanesljivost zaradi napak. Drugi dejavnik, ki otežuje življenje skrbniku sistema, je potreba po zagotovitvi, da so vse datoteke zbirk podatkov na voljo ob prvem dostopu storitve MS SQL (tj. Zaželeno je, da se pri povezovanju šifriranih medijev izključijo interaktivna dejanja. ).

Da bi se izognili opaznemu padcu zmogljivosti sistema, lahko z možnostjo MS SQL ustvarite zbirke podatkov v več datotekah. Seveda v tem primeru strežnik 1C pri ustvarjanju infobaze ne bi smel ustvariti baze podatkov MS SQL, ampak bi jo bilo treba ustvariti ločeno. Primer skripta TSQL s komentarji je prikazan spodaj:

USE master
Pojdi
- Ustvarite bazo podatkov SomeData,
Ustvari bazo podatkov SomeData
- katerih podatki so v celoti v datotečni skupini PRIMARY.
PRIMARNO
- Glavna podatkovna datoteka se nahaja na šifriranem mediju ( logični pogon E :)
- in ima začetno velikost 100 MB, se lahko samodejno razširi na 200 MB z
- 20 Mb korakov
(NAME = SomeData1,
FILENAME = "E: \ SomeData1.mdf",
VELIKOST = 100 MB,
MAXSIZE = 200,
FILEGROWTH = 2),
- Druga podatkovna datoteka se nahaja na nešifriranem mediju (logični pogon C :)
- in ima začetno velikost 100 MB, se lahko samodejno poveča do meje
- prostor na disku s korakom 5% trenutne velikosti datoteke (zaokroženo na 64 Kb)
(NAME = SomeData2,
FILENAME = "c: \ programske datoteke \ microsoft sql server \ mssql \ data \ SomeData2.ndf",
VELIKOST = 100 MB,
MAXSIZE = neomejeno,
RAST FILEGA = 5%)
PRIJAVI SE
- Čeprav bi lahko dnevnik transakcij razdelili tudi na dele, tega ne bi smeli storiti,
- od ta datoteka se veliko pogosteje spreminja in redno čisti (na primer, kdaj
- ustvarjanje varnostne kopije baze podatkov).
(NAME = SomeDatalog,
FILENAME = "c: \ programske datoteke \ strežnik microsoft sql \ mssql \ data \ SomeData.ldf",
VELIKOST = 10 MB,
MAXSIZE = neomejeno,
FILEGROWTH = 10)
Pojdi
- Bolje je, da takoj prenesete lastništvo nad bazo podatkov v imenu uporabnika
- 1C bo priključen. Če želite to narediti, moramo prijaviti trenutno bazo
- pravkar ustvarjeno,
UPORABI SomeData
Pojdi
- in izvedite postopek sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Majhen odmik o samodejnem povečanju velikosti podatkovne datoteke. Privzeto se za novo ustvarjene baze podatkov velikosti datotek povečajo v korakih po 10% trenutne velikosti datoteke. To je popolnoma sprejemljiva rešitev za majhne zbirke podatkov, vendar ne zelo dobra za velike: z velikostjo zbirke podatkov na primer 20 GB bi se morala datoteka povečati za 2 GB naenkrat. Čeprav se bo ta dogodek zgodil precej redko, lahko traja nekaj deset sekund (vse druge transakcije so trenutno v mirovanju), kar lahko, če se pojavi med aktivnim delom z bazo podatkov, povzroči nekaj napak. Druga negativna posledica sorazmernega dobička, ki se pojavi, ko je prostor na disku skoraj popolnoma poln, je verjetnost prezgodnje okvare zaradi nezadostnega prostega prostora... Na primer, če je 40 GB diskovna particija v celoti dodeljena eni bazi podatkov (natančneje, eni datoteki te baze podatkov), potem kritična velikost datoteke zbirke podatkov, pri kateri je treba nujno (zelo nujno, do prekinitve običajno delo uporabnikov) za reorganizacijo shranjevanja podatkov je podatkovna datoteka velikosti 35 GB. Z nastavljenim korakom 10-20 MB lahko nadaljujete z delom, dokler ne dosežete 39 GB.

Čeprav je naveden seznam navaja povečanje velikosti ene od datotek zbirke podatkov v korakih po 5%, je za velike velikosti zbirk podatkov bolje nastaviti fiksni prirastek 10-20 MB. Pri nastavljanju vrednosti prirasta za povečanje velikosti datotek zbirke podatkov je treba upoštevati, da preden ena od datotek v datotečni skupini doseže največjo velikost, velja pravilo: datoteke ene datotečne skupine vsi rastejo hkrati, ko so vsi polni. Torej, v zgornjem primeru, ko datoteka SomeData1.mdf doseže največjo velikost 200 MB, bo datoteka SomeData2.ndf velika približno 1,1 GB.

Po ustvarjanju takšne zbirke podatkov, tudi če njene nezaščitene datoteke SomeData2.ndf in SomeData.ldf postanejo na voljo napadalcu, bo izredno težko obnoviti pravo stanje baze podatkov - podatke (vključno z informacijami o logični strukturi baze podatkov). ) bodo razpršene po več datotekah, poleg tega pa bodo ključne informacije (o na primer, katere datoteke sestavljajo to zbirko podatkov) v šifrirani datoteki.

Seveda, če se uporablja shranjevanje datotek zbirk podatkov s kriptografskimi sredstvi, potem varnostnega kopiranja (vsaj teh datotek) ne bi smeli izvajati na nešifriranem mediju. Za varnostno kopiranje posameznih datotek zbirke podatkov uporabite ustrezno sintakso ukaza BACKUP DATABASE. Upoštevajte, da kljub možnosti zaščite varnostne kopije baze podatkov z geslom (možnosti »PASSWORD =« in »MEDIAPASSWORD =« ukaza »BACKUP DATABASE«) takšna varnostna kopija ne postane šifrirana!

Šifriranje aplikacijskega strežnika in odjemalčevih podatkov, shranjenih na diskih

V večini primerov se ne more šteti za upravičeno shranjevanje datotek, ki jih uporablja 1C: Enterprise (odjemalski del in aplikacijski strežnik) na šifriranem mediju zaradi neprimerno visokih stroškov, če pa obstaja takšna potreba, upoštevajte, da strežnik aplikacij in Odjemalski del aplikacije zelo pogosto ustvarja začasne datoteke. Pogosto lahko te datoteke ostanejo po končani aplikaciji, zato je skoraj nemogoče zagotoviti njihovo odstranitev s pomočjo 1C. Tako se zdi, da šifrira imenik, ki se uporablja za začasne datoteke v 1C, ali ga ne shrani na disk z RAM-pogonom (slednja možnost ni vedno mogoča zaradi velikosti ustvarjenih datotek in zahtev glede količine RAM-a Sama aplikacija 1C: Enterprise).

Šifriranje podatkov z vgrajenimi orodji 1C.

Standardne možnosti uporabe šifriranja v 1C so zmanjšane na uporabo predmetov za delo z datotekami Zip s parametri šifriranja. Na voljo so naslednji načini šifriranja: AES algoritem s ključem 128, 192 ali 256 bitov in zastarel algoritem, prvotno uporabljen v arhivarju Zip. Zip datotek, šifriranih z AES, mnogi arhivarji ne berejo (WinRAR, 7zip). Če želite ustvariti datoteko, ki vsebuje šifrirane podatke, morate določiti geslo in algoritem šifriranja. Najpreprostejši primer funkcije šifriranja in dešifriranja, ki temeljijo na tej sposobnosti, so navedene spodaj:

Funkcija EncryptData (podatki, geslo, metoda šifriranja = nedefinirano) Izvozi

// Zapišite podatke v začasno datoteko. Pravzaprav na ta način ni mogoče shraniti vseh podatkov.
ValueInFile (TempFileName, Data);

// Zapišite začasne podatke v arhiv
Zip = nov zapis ZipFile (začasno ime datoteke arhiva, geslo, metoda šifriranja);
Zip.Add (TemporaryFileName);
Zip.Write ();

// Branje podatkov iz prejetega arhiva v Oven
EncryptedData = NewValueStore (New BinaryData (TemporaryArchiveFileName));

// Začasne datoteke - brisanje

Funkcija EndFunction DecryptData (EncryptedData, Password) Izvoz

// Pozor! Pravilnost prenesenih parametrov se ne spremlja

// Posredovano vrednost zapišite v datoteko
TempFileName = GetTempFileName ("zip");
BinaryArchiveData = EncryptedData.Get ();
BinaryArchiveData.Write (TemporaryArchiveFileName);

// Izvlecite prvo datoteko na novo napisanega arhiva
TempFileName = GetTempFileName ();
Zip = Novo ReadZipFile (TemporaryArchiveFileName, Password);
Zip.Extract (Zip.Elements, TemporaryFileName, ZipFilePath RecoveryMode.NotRecover);

// preberite zapisano datoteko
Data = ValueFromFile (TemporaryFileName + "\" + Zip.Elements.Name);

// Brisanje začasnih datotek
DeleteFiles (TemporaryFileName);
DeleteFiles (TempArchiveFileName);

Vrnite podatke;

EndFunction

Seveda te metode ni mogoče imenovati idealna - podatki so zapisani v začasno mapo v čistem besedilu, učinkovitost metode, odkrito povedano, ni nikjer slabša, shranjevanje v bazi zahteva izjemno veliko prostora, vendar je to edino način, ki temelji le na vgrajenih mehanizmih platforme. Poleg tega ima prednost pred mnogimi drugimi metodami - ta metoda hkrati pakira podatke s šifriranjem. Če želite uporabiti šifriranje brez pomanjkljivosti, ki jih ima ta metoda, jih morate implementirati v zunanjo komponento ali pa se sklicevati na obstoječe knjižnice z ustvarjanjem objektov COM, na primer z uporabo Microsoft CryptoAPI. Kot primer bomo podali funkcije šifriranja / dešifriranja niza na podlagi prejetega gesla.

Funkcija EncryptStringDES (UnencryptedString, Password)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Ta konstanta je iz CryptoAPI

Encryption Engine.Content = Nešifriran niz
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = Motor za šifriranje.Encrypt ();

Return EncryptedString;

EndFunction // EncryptStringDES ()

Funkcija DecryptStringDES (EncryptedString, Password)

// Pozor! Parametri niso preverjeni!

Encryption Engine = nov COMObject ("CAPICOM.EncryptedData");
Mehanizem šifriranja.SetSecret (geslo);
Poskus
Encryption Engine.Decrypt (EncryptedString);
Izjema
// Napačno geslo!;
Vračilo kupnine nedefinirano;
Konec poskusov;

Engine Encryption Engine.Content;

EndFunction // DecryptStringDES ()

Upoštevajte, da bo pošiljanje prazne vrednosti kot niza ali gesla tem funkcijam ustvarilo sporočilo o napaki. Niz, pridobljen s tem postopkom šifriranja, je nekoliko daljši od izvirnika. Posebnost tega šifriranja je taka, da če niz šifrirate dvakrat, dobljeni nizi NE bodo enaki.

Glavne napake pri uporabi kriptografskih orodij.

Pri uporabi kriptografskih orodij se zelo pogosto zgodijo enake napake:

Podcenjevanje poslabšanja zmogljivosti pri uporabi kriptografije.

Kriptografija je naloga, ki zahteva precej veliko izračuna (zlasti za algoritme, kot so DES, 3DES, GOST, PGP). Tudi v primeru uporabe učinkovitih in optimiziranih algoritmov (RC5, RC6, AES) se ne da izogniti nepotrebnemu prenosu podatkov v pomnilniku in računalniški obdelavi. In to skoraj izniči zmogljivosti številnih strežniških komponent (nizov RAID, omrežni adapterji). Pri uporabi šifriranja strojne opreme ali izpeljave ključev strojne opreme za šifriranje obstaja dodatno ozko grlo glede zmogljivosti: hitrost prenosa podatkov med dodatno napravo in pomnilnikom (in zmogljivost takšne naprave morda ne bo imela odločilne vloge). Pri uporabi šifriranja majhnih količin podatkov (na primer poštnih sporočil) povečanje računalniške obremenitve sistema ni tako opazno, a v primeru popolnega šifriranja vsega in vse to lahko močno vpliva na delovanje sistema kot celota.

Podcenjevanje sodobne priložnosti o izbiri gesel in ključev.

Trenutno so zmogljivosti tehnologije takšne, da lahko ključ z dolžino 40-48 bitov prevzame majhna organizacija, ključ z dolžino 56-64 bitov pa velika organizacija. Tisti. uporabiti je treba algoritme, ki uporabljajo ključ najmanj 96 ali 128 bitov. Večina ključev pa je ustvarjenih z uporabo algoritmov razpršitve (SHA-1 itd.), Ki temeljijo na geslih, ki jih vnese uporabnik. V tem primeru tudi 1024-bitni ključ morda ne bo pomagal. Prvič, pogosto se uporablja geslo, ki ga je enostavno uganiti. Dejavniki, ki olajšajo izbiro, so: uporaba samo ene črke; uporaba besed, imen in izrazov v geslih; z uporabo znanih datumov, rojstnih dni itd.; uporaba "predlog" pri ustvarjanju gesel (na primer 3 črke, nato 2 številki, nato 3 črke po vsej organizaciji). Dobro geslo mora biti precej naključno zaporedje črk, številk in ločil. Gesla, vnesena s tipkovnice, dolga do 7-8 znakov, tudi če se upoštevajo ta pravila, je mogoče izbrati v razumnem času, zato je bolje, da je geslo dolgo vsaj 11-13 znakov. Idealna rešitev je zavrniti generiranje ključa z geslom, na primer z uporabo različnih pametnih kartic itd., Vendar je v tem primeru treba zagotoviti možnost zaščite pred izgubo nosilca šifrirnega ključa.

Nezanesljivo shranjevanje ključev in gesel.

Tipični primeri te napake so:

dolga in zapletena gesla, napisana na nalepkah, prilepljenih na uporabnikov monitor.
shranjevanje vseh gesel v nezaščiteno datoteko (ali zaščiteno precej šibkeje kot sam sistem)
shranjevanje elektronskih ključev v javni domeni.
pogost prenos elektronskih ključev med uporabniki.

Zakaj bi naredili oklepna vrata, če je ključ pod preprogo pri vratih?

Prenos prvotno šifriranih podatkov v negotovo okolje.

Pri organizaciji varnostnega sistema se prepričajte, da izpolnjuje svoj namen. Na primer, naletel sem na situacijo (ki ni povezana z 1C), ko je bila prvotno šifrirana datoteka, ko je program tekel v odprti obliki, postavljena v začasno mapo, od koder jo je bilo mogoče zlahka prebrati. Ni nenavadno, da varnostne kopije šifriranih podatkov v čisti obliki ležijo nekje "nedaleč" od teh podatkov.

Zloraba kriptografskih orodij

Pri šifriranju poslanih podatkov ni mogoče pričakovati, da bodo podatki nedosegljivi tam, kjer se uporabljajo. Storitve IPSec na primer na noben način ne preprečujejo, da bi aplikacijski strežnik poslušal omrežni promet na ravni aplikacije.

Da bi se torej izognili napakam pri izvajanju kriptografskih sistemov, morate pred njegovo uvedbo (vsaj) narediti naslednje.

Ugotovite:
- Kaj morate zaščititi?
- Kakšen način zaščite bi morali uporabiti?
- Za katere dele sistema morate zagotoviti varnost?
- Kdo bo nadzoroval dostop?
- Ali bo šifriranje delovalo na vseh pravih mestih?
Določite, kje so shranjeni podatki, kako so poslani po omrežju in računalniki, iz katerih bo dostop do informacij. To bo zagotovilo informacije o hitrosti, zmogljivosti in uporabi omrežja pred uvedbo sistema, kar je koristno za optimizacijo zmogljivosti.
Ocenite ranljivost sistema za različni tipi napadi.
Razviti in dokumentirati varnostni načrt sistema.
Ocenite ekonomsko učinkovitost (upravičenost) uporabe sistema.

Zaključek

Seveda pri bežnem pregledu ni mogoče navesti vseh vidikov, povezanih z varnostjo v 1C, vendar naredimo nekaj predhodnih zaključkov. Seveda te platforme ni mogoče imenovati idealna - ima, tako kot mnoge druge, svoje težave pri organizaciji varnega sistema. A to nikakor ne pomeni, da se teh težav ni mogoče izogniti, nasprotno, skoraj vse pomanjkljivosti je mogoče odpraviti s pravilnim razvojem, izvajanjem in uporabo sistema. Večina težav nastane zaradi nezadostne izdelave posebne aplikacijske rešitve in njenega okolja za izvajanje. Tipične rešitve na primer brez bistvenih sprememb preprosto ne pomenijo vzpostavitve dovolj varnega sistema.

Podjetje Je edinstvena storitev za kupce, razvijalce, trgovce in pridružene partnerje. Poleg tega je ena najboljših spletnih trgovin s programsko opremo v Rusiji, Ukrajini, Kazahstanu, ki strankam ponuja širok izbor, številne načine plačila, hitro (pogosto takojšnjo) obdelavo naročil, sledenje postopku izpolnitve naročil v osebnem razdelku.

Navodila za programerje Informix® DataBlade ™ API so na voljo za prenos na. V razdelku Upravljanje prostora za sklad je opisano, kako ustvariti funkcije po meri (UDR). Ta članek vsebuje dodatne informacije in nasvete za odpravljanje napak.

Spodnje informacije veljajo, ali UDR deluje na uporabniško določenem navideznem procesorju (VP) ali na VP CPU. Niz niti lahko premaknete v uporabniško definiran navidezni procesor tik pred izvajanjem UDR.

Kakšen sklad velikosti je dodeljen UDR?

Velikost sklada, ki je na voljo za UDR, je odvisna od tega, kako je bil UDR ustvarjen:

z uporabo modifikatorja STACK, ki UDR omogoča uporabo lastnega namenskega sklada,

brez modifikatorja STACK, kar pomeni, da bo UDR delil sklad, ki ga dodeli strežnik, z nitjo, ki poda zahtevo. Velikost sklada bo v tem primeru določena z vrednostjo parametra STACKSIZE v konfiguracijski datoteki onconfig.

Modifikator STACK

Izrazi CREATE PROCEDURE ali CREATE FUNCTION imajo izbirni modifikator STACK, ki vam omogoča, da določite količino prostora sklada v bajtih, ki ga mora izvesti UDR.

Če pri ustvarjanju UDR uporabite modifikator STACK, bo strežnik vsakič, ko se izvede UDR, dodelil in odpravil prostor sklada. Dejanska razpoložljiva velikost je STACK v bajtih minus nekaj režijskih stroškov, odvisno od števila argumentov funkcije.

Če je vrednost STACK manjša od vrednosti STACKSIZE v datoteki onconfig (glejte naslednji razdelek), bo velikost sklada, dodeljenega za UDR, samodejno zaokrožena na vrednost STACKSIZE.

Konfiguracijski parameter STACKSIZE

Konfiguracijska datoteka onconfig vključuje parameter STACKSIZE, ki določa privzeto velikost sklada za uporabniške niti.

Če pri ustvarjanju UDR -ja ne podate STACK, strežnik ne dodeli dodatnega prostora sklada za izvajanje tega UDR. Namesto tega UDR uporablja prostor sklada, dodeljen za izpolnitev zahteve. Razpoložljiva velikost sklada bo odvisna od stroškov izvajanja funkcije na ravni SQL.

Niz niti je enkrat dodeljen določeni niti, ki poda zahtevo. Uspešnost je boljša, če UDR deli eno nit z enim nizom, saj strežnik ne zapravlja virov za dodelitev dodatnega sklada za vsak klic UDR. Po drugi strani pa, če se velikost uporabljenega sklada UDR približa vrednosti STACKSIZE, lahko pri klicu funkcije kot del kompleksne zahteve povzroči preliv sklada (v tem primeru je za izvajanje UDR na voljo manj prostora za sklad).

Ne pozabite, da STACKSIZE ne nastavite previsoko, saj bo to vplivalo na vse uporabniške niti.

Kdaj morate upravljati velikost sklada?

Y Če UDR izvaja rekurzivne klice ali če UDR zahteva več prostora v skladu, kot je privzeto na voljo v nizu zahtev (STACKSIZE), morate upravljati prostor sklada.

Obstajata dva načina za povečanje sklada za izvajanje UDR -jev:

Pri ustvarjanju UDR določite modifikator STACK.

Za rekurzivne klice uporabite mi_call () (za primer glejte Navodila za programerje API Informix DataBlade).

Če velikosti ne podate s funkcijo STACK in če za povečanje trenutnega sklada ne uporabite mi_call () in če UDR naredi nekaj, kar zahteva veliko prostora v nizu, bo to povzročilo preliv sklada.

Upoštevajte, da nekatere funkcije, kot je mi_ *, dodajo nov segment sklada za lastno izvedbo. Ti segmenti se sprostijo ob vrnitvi klicatelja UDR.

Kaj pa če gre kaj narobe?

Spremljanje uporabe sklada

Namen spremljanja je identificirati določen UDR, ki povzroča preliv sklada, tako da lahko vrednost STACK spremenite posebej za določen UDR.

Opazovanje uporabe sklada z "onstat -g sts"

Opazujte sejo, ki izvaja poizvedbo SQL z "onstat -g ses session_id"

Po identifikaciji Poizvedba SQL ki ima za posledico preliv sklada, morate določiti uporabo sklada z ločenim izvajanjem UDR -jev, ki so del prvotne zahteve.

Vrednost STACK za UDR lahko dinamično nastavite. Na primer:

spremeni funkcijo MyFoo (lvarchar, lvarchar) z (dodaj sklad = 131072);

Ko spremenite vrednost STACK, morate preizkusiti izvirno poizvedbo in se prepričati, da zdaj deluje stabilno.

Povečajte STACKSIZE

Druga možnost je, da poskusite povečati vrednost STACKSIZE. Preverite, ali je to rešilo težavo. (Ne pozabite pozneje vrniti stare vrednosti).

Če povečanje STACKSIZE ne deluje, je težava najverjetneje okvara pomnilnika. Tukaj je nekaj predlogov:

Omogoči pisanje pomnilnika in preverjanje pomnilniškega področja. V razdelku »Težave pri odpravljanju napak« v članku o dodelitvi pomnilnika za UDR je razloženo, kako to storiti.

Ponovno razmislite o uporabi mi_lvarchar. Bodite posebno pozorni na mesta, kjer se mi_lvarchar posreduje funkciji, ki pričakuje, da bo kot argument prejela niz, ki se konča z ničlo.

Zmanjšajte število podpredsednikov procesorja (ali uporabnika) na enega, da se težava hitreje reproducira.

mi_print_stack () - Solaris

Informix Dynamic Server za Solaris OC vključuje funkcijo mi_print_stack (), ki jo je mogoče poklicati v UDR. Ta funkcija privzeto shrani okvir sklada v naslednjo datoteko:

/tmp/default.stack

Imena izhodne datoteke ne morete spremeniti, lahko pa spremenite njeno lokacijo s spremembo vrednosti spremenljivke okolja DBTEMP. Prepričajte se, da lahko uporabnik informix piše v imenik $ DBTEMP. Vse napake, ki se pojavijo pri izvajanju mi_print_stack (), se natisnejo v $ MSGPATH.

Ta funkcija je na voljo samo za Solaris OC.

Slovarček

Izrazi in okrajšave, uporabljeni v tem članku:

UDR	Uporabniško definirana rutina
Podpredsednik	Virtualni procesor

14.04.2016 Različica 3.22 Spremenjen vmesnik, odpravljene napake pri prenosu registrov, spremenjen postopek prenosa organizacij in računovodske politike. Platforma 8.3.7.2027 BP 3.0.43.174
17.03.2016 Različica 3.24 Odpravljene napake. Platforma 8.3.8.1747 BP 3.0.43.241
16.06.2016 Različica 3.26 Odpravljene napake. Platforma 8.3.8.2088 BP 3.0.44.123
16.10.2016 Različica 4.0.1.2 Fiksni prenos shrambe vrednosti, spremenjen prenos računovodske politike za izdaje 3.44. *. Platforma 8.3.9.1818 BP 3.0.44.164.
19.04.2017 Različica 4.0.2.7 Algoritem za prenos registrov, povezanih z imeniki, je bil spremenjen, opažene napake odpravljene, prenos s prepisovanjem povezav odpravljen.
29.05.2017 Različica 4.0.4.5 Spremenjen prenos premikov, dodan ogled premikov prenesenih dokumentov, nekaj drugega ...
30.05.2017 Različica 4.0.4.6 Odpravljena je napaka pri izpolnjevanju seznama obstoječih imenikov v viru (zahvaljujoč shoy)
17.06.2017 Različica 4.0.5.1 Algoritem za prenos gibov je bil spremenjen.
19.7.2017 Različica 4.0.5.4 Spremenjen je bil prenos CI iz BP 2.0. Nepričakovano je bil Smilegm prenesen iz UT 10.3, v tej različici je bil prenos za takšno situacijo nekoliko popravljen)))
10.08.2017 Različica 4.0.5.5 Odpravljene napake pri prenosu iz BP 2.0
19.09.2017 Različica 4.4.5.7 Preverjanje fiksne povezave za 3.0.52. *
28.11.2017 Različica 4.4.5.9 Odpravljene napake
06.12.2017 Različica 5.2.0.4 Algoritem iskanja povezav je bil preoblikovan. Dodani postopki prenosa iz BP 1.6, ni več toge vezave na BP - za prenos podatkov lahko varno uporabite "skoraj" enake konfiguracije. Vse komentarje bom poskušal takoj popraviti.
08.12.2017 Različica 5.2.1.3 Dodan je algoritem za prenos plačilnih listov iz BP.2.0 v BP 3.0. Spremembe so vključene za skupno rabo med istimi konfiguracijami.
19.12.2017 Različica 5.2.2.2 Popravljen je prenos neodvisnih registrov informacij za imenike, ki so v razsežnostih teh registrov.

06.12.2017 Nova različica obdelave 5.2.0.4. Med pomembnimi spremembami je možnost prehoda z BP 1.6 na BP 3.0. Glavna sprememba je upravljanje iskanja referenčnih povezav - v prejšnjih različicah je iskanje potekalo po GUID -u, v tej različici pa lahko omogočite iskanje »Po zahtevah«:

17.1.2018 Različica 5.2.2.3 Odpravljene napake podrejenih imenikov in periodičnih registrov informacij.

19.7.2018 Različica 5.2.2.8 Odpravljene napake.

kjer lahko nastavite podrobnosti iskanja po katerem koli priročniku. Ta režim je "nastal" na številne zahteve delavcev, za primer, ko je potrebna izmenjava v že obstoječi zbirki podatkov, ki že vsebuje podatke (na primer za združitev računovodstva dveh organizacij v eno zbirko podatkov).

21.12.2015 sta bili izdani platforma 8.3.7.1805 oziroma BP 3.0.43.29 nova različica obdelava 3.1 :-) (opis spodaj). Nova funkcionalnost- zmožnost primerjave stanj in obratov med dvema osnovama BP (za vse račune, če se kontni načrti ujemajo, ali za ločene ujemajoče se račune z analitiko ali brez nje).
03/03/2016 Različica 3.5 - spremenjen mehanizem za povezavo z izvorno bazo podatkov - usklajeno z BSP 2.3.2.43. Odpravljene manjše napake. Platforma 8.3.7.1845, BP 3.0.43.50
16.02.2016 Različica 3.6 - Dodana je zastavica "Nastavi ročno popravljanje" za dokumente, prenesene s premiki. Fiksni prenos premikov - dokumenti z datumom, manjšim od začetka obdobja, se prenesejo brez premikov. Platforma 8.3.7.1917, BP 3.0.43.116
22.03.2016 Različica 3.10 - Dodana je zastavica "Vedno prepiši povezave" za obvezno prepisovanje referenčnih objektov (hitrost prenosa se znatno zmanjša, včasih pa je to potrebno). Dodan je zavihek "Priprava", kjer lahko konfigurirate korespondenco izvornega in ciljnega grafikona računov (na ravni s kodami računov) ter prenos konstant. Platforma 8.3.7.1970, BP 3.0.43.148

04/03/2016 Različica 3.11 Zapolnjeno je bilo polnjenje seznama dokumentov, ki obstajajo v viru: polnjenje je bilo opravljeno v skladu s premiki v kontnem načrtu, preprosto s povezavami za obdobje, pa tudi v // spletna stran / javna / 509628 /

Obdelava je namenjena prenosu podatkov za katero koli obdobje, podobno kot "Raztovarjanje in nalaganje MXL" iz ITS, samo brez uporabe XML, JSON in drugih vmesnih datotek - izmenjava iz baze podatkov v bazo podatkov prek COM -ja. V različici, starejši od 3.10, se uporablja povezava z algoritmom iz BSP, v kateri je zagotovljena registracija comcntr.dll (če OS "dovoljuje"), pa tudi različna sporočila, ko povezave ni mogoče vzpostaviti. na primer - " Informacijska baza je v postopku posodabljanja "itd. Dodano je preverjanje izbire sprejemnika za vir IS - izda se opozorilo.

Lahko se uporablja za:

1. Prenos normativnih in referenčnih informacij (NSI) iz vira IS v sprejemnik IS (prenos celotnega NSI se izvede na zahtevo uporabnika, potrebne referenčne knjige itd. Se prenesejo s povezavami za vse prenose) .

2. Prenos dokumentov za poljubno izbrano obdobje.

3. Prenos vseh informacij iz "pokvarjenega" IB -ja, če se zažene v načinu 1C: Enterprise in nalaganje podatkov ali zagon konfiguratorja ni mogoč.

Funkcija obdelave - informacijska varnost sprejemnika in vira je lahko različna. Prenos od 2.0 do 3.0 - različice so različne, vendar prenos deluje !!! Neujemajoči se atributi se prezrejo ali pa jim je treba določiti algoritme prenosa.

Komentar: Pretvorba podatkov se NE UPORABLJA! In ne sprašujte zakaj !!! Za najbolj jedke - BP 3.0 se spreminja skoraj vsak dan, ni več moči za posodabljanje pravil o prenosu - tukaj je vse lažje :-).

Druga značilnost obdelave je, da se zažene v sprejemnikovi IS (najbližji analogi glede funkcionalnosti delujejo obratno - od vira do sprejemnika).

Začetek dela - določiti morate obdobje obdelave, navesti organizacijo iz vira, ta bo prenesena na prejemnika.

Ko se organizacija prenese, se prenese računovodska politika in "spremljajoči" registri informacij. Zato, ko prvič izberete organizacijo v viru, bo minilo nekaj časa, preden se prikaže v sprejemniku.

Izvorni in ciljni kontni načrt morata biti enaki, različni računi v različicah 2. * se ne prenesejo na prejemnika, nastavitev korespondence računov in analitike naj bi bila vključena v prihodnosti. Računi se prenašajo s kodami, ki jih ni v sprejemniku NE Ustvarjajte !!!

Preostale predmete prenašajo notranji identifikatorji (GUID), zato bodite pozorni na nekatere ključne referenčne knjige, na primer - Valute.

Če nameravate zamenjati s "čisto" osnovo, je bolje, da pred izmenjavo izbrišete referenčne knjige, napolnjene ob prvem zagonu. Za to je na voljo stran za obdelavo, kjer lahko dobite te elemente imenikov in jih izbrišete. Vsaj morate odstraniti valuto "RUB". - od podvajanje je skoraj neizogibno (načeloma se to zlahka popravi po izmenjavi iskanja in zamenjave dvojnikov, vgrajenih v BP 3.0).

Pri obdelavi je bil predviden klic na stran za brisanje imenikov, ko je odprt začetni obrazec za izpolnjevanje:

Ko se obdelava odpre, se prikaže stran za brisanje imenikov, ki so bili izpolnjeni med začetnim polnjenjem:

Od različice 3.22 je bil vmesnik spremenjen, zdaj so vse pripravljalne operacije zaznamovane in so vedno na voljo

Pomembno je, da preverite skladnost kontnega načrta vira in prejemnika ter obvezno navedete korespondenco računov.

Vnaprej določenih elementov imenika ni treba izbrisati - prenesejo jih konfiguracijski identifikatorji (ne GUID).

Objekte za prenos lahko izberete z izbirnim obrazcem iz imenikov in dokumentov (Registri informacij, povezani s tem objektom, se bodo samodejno preselili, zato vam jih ni treba izbrati ločeno).Prenos registrov je začasno onemogočen - morate izdelati seznam registrov za prenos - nekaj je treba prenesti, nekaj ni, na tej stopnji je dovolj, kar je preneseno v imenikih, seznam registrov za prenos bo v predlogi, v prihodnjih različicah.

Pri izmenjavi z 2.0 nekatere podrobnosti (npr. Kontaktni podatki) se prenese v skladu z algoritmom, vgrajenim v obdelavo, od različno so shranjeni za 2.0 in 3.0. Podobno je s številnimi dokumenti (na primer Popravek dolga).

Seznam vrst objektov je mogoče v različici 3.22 napolniti na različne načine, postavljen je v podmeni, spremembe so zapisane na sliki:

Obstaja poenostavitev uporabe obdelave - ne morete izbrati imenikov za izmenjavo, ampak preprosto napolnite seznam vrst v sprejemniku le s tistimi vrstami imenikov, ki imajo v viru vsaj en zapis.

Obdelava ima vgrajeno postavitev, ki navaja imenike, ki jih ni treba prenesti iz vira v cilj (postavitev »Izključi iz prenosa«). Na to postavitev lahko dodate (izbrišete) vse sklice. Če vam ni treba prenesti celotnih referenčnih podatkov, je dovolj, da prenesete dokumente, katerih seznam lahko dobite tudi brez izbire vrst, samo izpolnite vse izvorne dokumente, za katere obstajajo transakcije.

Zagotovljen je prenos dokumentov s premiki, za izmenjave 3,0 do 3,0 in v skladu s kontnimi načrti deluje ena proti ena, pri menjavi 2,0 do 3,0 so možne napake, zato je priporočljivo, da dokumente prenesete brez premikov, nato pa jih preprosto ponovno objavite v sprejemniku. Pri prenosu dokumentov z gibi je nastavljena zastavica "Ročni popravek".

Atribut "Posted" je v dokumentih prejemnika nastavljen enako kot v viru, vendar se premiki (če niso bili preneseni) pojavijo šele po objavi dokumentov, na primer z obdelavo, vgrajeno v obdelavo dokumentov skupine BP 3.0 ( priporočena možnost) ali iz te obdelave (tukaj je gumb "Objavi dokumente").

Če se obdelava načrtuje za trajno izmenjavo, jo je mogoče registrirati v IS prejemnika (gumb "Register"). Za "enkratne" prenose ga lahko preprosto uporabite prek Datoteka - Odpri.

21.12.2015 - Platforma različice 3.1 8.3.7.1805 in BP 3.0.43.29 (različica 2.15 za 3.0.43. * Ne deluje - konfiguracija je bila precej spremenjena).

Spremenjeno:

Dialog za izbiro možnosti povezave, zastavica odjemalca in strežnika je vedno na voljo, odvisno od njene nastavitve, ali je na voljo izbira mape z datotečno bazo, ali polje z imenom baze na strežniku in imenom strežnika sama (napaka pogovorne različice 2.15 je odpravljena)

- NOVI FUNKCIONALNI: Mehanizem usklajevanja ostankov in vrtljajev med osnovami vira in sprejemnika v različnih stopnjah podrobnosti:

Mislim, da je izbira možnosti usklajevanja jasna iz slike:

V tankem in debelem odjemalcu obstajajo razlike v uporabi - v debelejšem se takoj prikaže okno za primerjavo datotek:

V tankem odjemalcu nisem sprevrgel s programskimi pritiski na gumbe, predlagam preprosto možnost prikaza okna za primerjavo:

Primerjava v tankem odjemalcu, IMHO, je od takrat bolj priročna ima navigacijske gumbe za razlike, kar je bolj primerno za velike količine tabel kot drsenje z miško:

22.03.2016 Različica 3.10 - Dodana je zastavica "Vedno prepiši povezave" za obvezno prepisovanje referenčnih objektov (hitrost prenosa se znatno zmanjša, včasih pa je to potrebno). Dodan je zavihek "Priprava", kjer lahko konfigurirate korespondenco izvornega in ciljnega grafikona računov (na ravni s kodami računov) ter prenos konstant. Platforma 8.3.7.1970, BP 3.0.43.148

- NOVI FUNKCIONALNI: Pred prenosom dokumentov je priporočljivo preveriti skladnost kontnega načrta glede vira in cilja ter skladnost ugotovljenih konstant.

Če želite to narediti, je dodan zavihek "Priprava", v katerem lahko nastavite te korespondence:

Algoritem za izpolnjevanje tabele korespondence računov je preprost - analizirajo se obtoki, ki obstajajo v viru, in vsak račun, ki je bil tam najden, poišče ujemanje s kodo v sprejemniku, če ujemanja ni, pa vrstico z koda računa je prikazana v tabeli, s katero morate izbrati račun prejemnika, ki bo uporabljen pri prenosu. Dopisovanje znanosti je vzpostavljeno na ravni kod.

Za preverjanje in prenos ustreznosti ugotovljenih konstant se uporablja ustrezna tabela:

Izpolnimo, če je potrebno - prenesemo. Prenesene so samo konstante, označene z zastavico ...

Programski sklad je posebno področje pomnilnika, organizirano na podlagi čakalne vrste LIFO (Last in, first out - last in first out). Ime "sklad" izhaja iz analogije načela njegove konstrukcije s kupom plošč - plošče lahko postavite eno na drugo (način dodajanja v sklad, "potiskanje", "potiskanje") in nato pobiranje, začenši od vrha (način pridobivanja vrednosti iz sklada, "pop", "pop"). Programski sklad se imenuje tudi klicni sklad, sklad izvajanja, strojni sklad (da ga ne bi zamenjali s »skladom« - abstraktno podatkovno strukturo).

Čemu služi kup? Omogoča vam priročno organiziranje klica podprogramov. Ob klicu funkcija prejme nekaj argumentov; nekje mora shraniti tudi svoje lokalne spremenljivke. Poleg tega je treba upoštevati, da lahko ena funkcija pokliče drugo funkcijo, ki mora tudi prenesti parametre in shraniti svoje spremenljivke. Z uporabo sklada jih morate pri posredovanju parametrov le postaviti na sklad, nato jih bo klicana funkcija lahko od tam »potisnila« in jih uporabila. Lokalne spremenljivke so lahko shranjene tudi na istem mestu - na začetku kode funkcija razporedi del pomnilnika sklada, ko se vrne, ga počisti in sprosti. Programerji v jezikih na visoki ravni o teh stvareh običajno ne razmišljajo - prevajalnik zanje ustvari vso potrebno rutinsko kodo.

Posledice napake

Zdaj se problemu približamo zelo blizu. V svoji abstraktni obliki je sklad neskončen prostor za shranjevanje, v katerega lahko neskončno dodajamo nove elemente. Na žalost je v našem svetu vse dokončno - in spomin pod skladom ni izjema. Kaj se zgodi, če se konča, ko so argumenti funkcije potisnjeni v sklad? Ali funkcija dodeljuje pomnilnik svojim spremenljivkam?

Prišlo bo do napake, imenovane preliv sklada. Ker je sklad potreben za organiziranje klica uporabniško določenih funkcij (in skoraj vseh programov vklopljenih sodobni jeziki, vključno z objektno usmerjenimi, so nekako zgrajene na podlagi funkcij), jih ne bo več mogoče klicati. Zato operacijski sistem prevzame nadzor, počisti sklad in zaključi program. Tukaj lahko poudarite razliko med in prelivanjem sklada - v prvem primeru pride do napake pri dostopu do napačnega pomnilniškega območja in če na tej stopnji ni zaščite, se v tem trenutku ne pokaže - z uspešnim naključjem, program lahko normalno deluje. Če je zaščiten samo pomnilnik, do katerega dostopate, se to zgodi. V primeru sklada se program brezhibno konča.

Če smo natančni, je treba opozoriti, da ta opis dogodkov velja le za prevajalnike, ki prevajajo v izvorno kodo. V upravljanih jezikih ima navidezni stroj lasten sklad za upravljane programe, katerega stanje je veliko lažje spremljati in si lahko celo privoščite izjemo programa, ko pride do prelivanja. V jezikih C in C ++ na takšno "razkošje" ni mogoče računati.

Vzroki za napako

Kaj lahko pripelje do tako neprijetne situacije? Na podlagi zgoraj opisanega mehanizma je ena možnost preveč klicev ugnezdenih funkcij. Ta scenarij je še posebej verjeten pri uporabi rekurzije. Neskončna rekurzija (v odsotnosti mehanizma za "leno" vrednotenje) se v nasprotju s tem prekine, kar ima včasih koristno uporabo. Vendar pa lahko z majhno količino pomnilnika, namenjenega svežnju (kar je na primer značilno za mikrokrmilnike), zadostuje preprosto zaporedje klicev.

Druga možnost so lokalne spremenljivke, ki zahtevajo veliko pomnilnika. Ustvariti lokalno paleto z milijoni elementov ali milijonom lokalnih spremenljivk (nikoli ne veste, kaj se zgodi) ni dobra ideja. Že en sam klic tako pohlepne funkcije lahko zlahka povzroči preliv sklada. Za pridobivanje velikih količin podatkov je bolje uporabiti mehanizme kopnega pomnilnika, ki vam bo omogočil, da odpravite napako njegovega pomanjkanja.

Vendar je pomnilnik kopice precej počasen v smislu dodeljevanja in odprave (ker operacijski sistem to počne), in ko neposreden dostop morate ga ročno dodeliti in sprostiti. Pomnilnik v nizu je dodeljen zelo hitro (pravzaprav morate samo spremeniti vrednost enega registra), poleg tega pa se samodejno pokličejo destruktorji za predmete, dodeljene v nizu, ko se funkcija vrne in se sklad počisti. Seveda se takoj pojavi želja po pridobivanju spomina iz sklada. Zato je tretji način prelivanja programerjeva samorazporeditev v sklad. Knjižnica C ponuja funkcijo alokacije posebej za ta namen. Zanimivo je omeniti, da če ima funkcija za dodeljevanje dinamičnega pomnilnika malloc svojega "dvojčka", ki ga osvobodi, ga funkcija alloca nima - pomnilnik se samodejno sprosti po vrnitvi nadzora nad funkcijo. Morda to samo otežuje situacijo - navsezadnje pred izhodom iz funkcije ne bo mogoče osvoboditi pomnilnika. Čeprav je v skladu z man strani "alloca odvisna od stroja in prevajalnika; pri mnogih sistemih je njeno izvajanje problematično in vsebuje veliko hroščev; njena uporaba je zelo neresna in odvračana" - še vedno se uporablja.

Primeri

Kot primer razmislite o kodi za rekurzivno iskanje datotek na MSDN:

Void DirSearch (String * sDir) (try (// Poiščite podmape v mapi, ki jo posredujete. 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->Besedilo); int numFiles = f-> get_Length (); za (int j = 0; j< numFiles; j++) { listBox1->Postavke-> Dodaj (f [j]); ) DirSearch (d [i]); )) catch (System :: Exception * e) (MessageBox :: Show (e-> Message);))

Ta funkcija dobi seznam datotek v določenem imeniku, nato pa pokliče tiste elemente seznama, ki so se izkazali za imenike. V skladu s tem bomo z dovolj globokim drevesom datotečnega sistema dobili naraven rezultat.

Primer drugega pristopa, vzet iz vprašanja "Zakaj pride do prelivanja sklada?" s spletnega mesta, imenovanega Stack Overflow (spletno mesto je zbirka vprašanj in odgovorov na katero koli programsko temo, ne le prelivanje skladov, kot se morda zdi):

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

Kot lahko vidite, je v glavni funkciji v nizu dodeljen pomnilnik za matrike vrst int in float, po milijon elementov, kar skupaj daje nekaj manj kot 8 megabajtov. Glede na to, da Visual C ++ privzeto rezervira le 1 megabajt za sklad, postane odgovor očiten.

In tukaj je primer iz skladišča GitHub projekta Lightspark Flash player:

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

Upajmo, da h.getLength () - 7 ne bo prevelik, da bi se izognili prelivanju v naslednji vrstici. Toda ali je čas, prihranjen pri dodeljevanju pomnilnika, vreden "potencialnega" zrušitve programa?

Izid

Preliv sklada je usodna napaka, ki najpogosteje prizadene programe, ki vsebujejo rekurzivne funkcije. Kljub temu, da program ne vsebuje takšnih funkcij, pa je zaradi velike količine lokalnih spremenljivk ali napake pri ročni dodelitvi pomnilnika v nizu še vedno možen preliv. Vsa klasična pravila ostajajo v veljavi: če obstaja izbira, je bolje, da namesto rekurzije raje ponovite, namesto prevajalnika pa tudi ne ročno delati.

Bibliografski seznam

E. Tanenbaum. Računalniška arhitektura.
Wikipedija. Preobremenitev.
Preobremenitev. Preklapljanje sklada C ++.

V tem kontekstu je sklad zadnji v prvem medpomnilniku, ki ga dodelite med izvajanjem programa. Nazadnje, prvo (LIFO) pomeni, da je zadnja stvar, ki jo vnesete, vedno prva stvar, ki jo vrnete - če v nizu zadenete 2 elementa, "A" in nato "B", bo prva stvar, ki jo spustite iz sklada " B "in naslednja stvar bo" A ".

Ko pokličete funkcijo v kodi, se naslednji ukaz po klicu funkcije shrani v sklad in kateri koli pomnilniški prostor, ki ga lahko klic funkcije prepiše. Izbrana funkcija lahko uporabi več skladov za svoje lokalne spremenljivke. Ko konča, bo sprostil prostor lokalne spremenljivke, ki ga je uporabljal, in se nato vrnil na prejšnjo funkcijo.

Preobremenitev

Preklapljanje sklada je, ko ste za sklad uporabili več pomnilnika, kot ga namerava uporabiti vaš program. V vgrajenih sistemih lahko imate samo 256 bajtov za sklad, in če je vsaka funkcija 32 bajtov, potem lahko imate samo 8 klicev funkcije 2 z globoko funkcijo 1, ki kliče funkcijo 3, ki kliče funkcijo 4 ... ki kliče funkcijo 8, ki kliče funkcijo 9, vendar funkcija 9 prepiše pomnilnik zunaj sklada. To lahko prepiše pomnilnik, kodo itd.

Mnogi programerji naredijo to napako, tako da pokličejo funkcijo A, ki nato pokliče funkcijo B, ki nato pokliče funkcijo C, ki nato pokliče funkcijo A. Večino časa lahko deluje, vendar le en napačen vnos povzroči, da kroži večno, dokler računalnik ne izve, da je sklad poln.

To povzročajo tudi rekurzivne funkcije, če pa pišete rekurzivno (tj. Vaša funkcija kliče sama), se morate tega zavedati in uporabiti statične / globalne spremenljivke, da preprečite neskončno ponovitev.

Običajno operacijski sistem in programski jezik, ki ga uporabljate, upravljata sklad in to vam ni v rokah. Oglejte si graf klicev (drevesna struktura, ki od vaše glavne točke prikazuje, kaj kliče vsaka funkcija), da vidite, kako globoki so klici funkcije, in ugotovite zanke in rekurzijo, ki niso predvidene. Namerne zanke in rekurzijo je treba umetno preveriti glede napak, če se prevečkrat pokličejo.

Poleg dobrih programskih praks, statičnega in dinamičnega testiranja, v teh sistemih ne morete storiti veliko. visoka stopnja.

Vgrajeni sistemi

V vgrajenem svetu, zlasti kodi z visoko zanesljivostjo (avtomobilska, letalska, vesoljska), izvajate obsežna preverjanja in preverjanja kode, hkrati pa naredite tudi naslednje:

Onemogoči ponavljanje in zanke - skladnost s politikami in testiranje
Kodo in sklad držite daleč narazen (koda v bliskavici, sklad v RAM -u in se nikoli ne ujemata)
Okrog sklada postavite prazne pasove - prazno območje pomnilnika, ki ga napolnite s čarobno številko (ponavadi program za prekinitev, vendar je tukaj veliko možnosti) in sto ali tisočkrat na sekundo pogledate zaščitne trakove, da poskrbite, da niso prepisani.
Uporabite zaščito pomnilnika (tj. Ne izvajajte na nizu, ne berite in ne pišite neposredno na sklad)
Prekinitve ne kličejo sekundarnih funkcij - nastavijo zastavice, kopirajo podatke in pustijo, da aplikacija poskrbi za njihovo ravnanje (sicer lahko pride do 8 globoko v drevesu klicev funkcij, prekinitev in nato še nekaj funkcij v prekinitvi izhod, ki povzroči razpok). Imate več dreves klicev - eno za glavne procese in eno za vsako prekinitev. Če se lahko vaše prekinitve medsebojno prekinjajo ... no, obstajajo zmaji ...

Jeziki in sistemi na visoki ravni

Toda v jezikih na visoki ravni, ki delujejo v operacijskih sistemih:

Zmanjšajte lokalno shranjevanje spremenljivke (lokalne spremenljivke so shranjene v nizu), čeprav so prevajalniki glede tega precej pametni in bodo včasih na koš postavili velike kose, če je drevo klicev majhno)
Izogibajte se ali močno omejite ponovitev
Ne prekinjajte svojih programov predaleč v manjše in manjše funkcije - tudi če ne upoštevate lokalnih spremenljivk, vsak klic funkcije porabi do 64 bajtov v nizu (32 -bitni procesor, vodi polovico registrov procesorja, zastavice itd.).
Držite klicno drevo plitvo (podobno kot zgoraj)

Spletni strežniki

Od peskovnika, ki ga imate, je odvisno, ali lahko nadzirate ali celo vidite sklad. Verjetno lahko s spletnimi strežniki ravnate kot z vsemi drugimi jeziki na visoki ravni in operacijski sistem, je precej v vaših rokah, vendar preverite uporabljeni jezik in kup strežnikov. Na primer, na vašem strežniku SQL je mogoče razdeliti sklad.