1c previše složen upit moguće prelijevanje stog. Prelijevanje steka. Šifriranje podataka tijekom prijenosa između aplikacijskog poslužitelja i MS SQL Servera

Ovaj članak još jednom pokazuje da bilo koji skup sigurnosnih mjera treba pokriti sve faze implementacije: razvoj, implementaciju, administraciju sustava i, naravno, organizacijske mjere. U informacijskim sustavima upravo je "ljudski faktor" (uključujući korisnike) glavna sigurnosna prijetnja. Ovaj skup mjera trebao bi biti razuman i uravnotežen: nema smisla i malo je vjerojatno da će se izdvojiti dovoljno sredstava za organizaciju zaštite, što premašuje troškove samih podataka.

Uvod

1C:Enterprise je najčešći računovodstveni sustav u Rusiji, ali unatoč tome, prije verzije 8.0, njegovi su programeri posvećivali vrlo malo pažnje sigurnosnim pitanjima. U osnovi, naravno, to je diktirala cjenovna niša proizvoda i fokus na male tvrtke u kojima nema kvalificiranih IT stručnjaka, a mogući trošak implementacije i održavanja sigurnog sustava bio bi previsoko skup za poduzeće. Izlaskom verzije 8.0 naglasak se morao promijeniti: cijena rješenja značajno je porasla, sustav je postao mnogo skalabilniji i fleksibilniji - zahtjevi su se značajno promijenili. Je li sustav postao dovoljno pouzdan i siguran pitanje je vrlo individualno. Glavni informacijski sustav modernog poduzeća mora ispunjavati najmanje sljedeće sigurnosne zahtjeve:

Dovoljno niska vjerojatnost kvara sustava zbog unutarnjih razloga.
Pouzdana autorizacija korisnika i zaštita podataka od pogrešnih radnji.
Učinkovit sustav za dodjelu korisničkih prava.
Online sustav sigurnosnog kopiranja i oporavka u slučaju kvara.

Udovoljavaju li rješenja temeljena na 1C:Enterprise 8.0 ovim zahtjevima? Ne postoji jedinstven odgovor. Unatoč značajnim promjenama u sustavu kontrole pristupa, ostaje puno neriješenih problema. Ovisno o tome kako je sustav dizajniran i konfiguriran, svi ovi zahtjevi možda neće biti ispunjeni ili biti ispunjeni u dovoljnoj mjeri za ovu implementaciju, međutim, vrijedi obratiti pažnju (a to je značajna posljedica „mladosti“ platforme ) da kako biste u potpunosti ispunili navedene uvjete morate uložiti stvarno titanske napore.

Ovaj je članak namijenjen programerima i implementatorima rješenja temeljenih na platformi 1C:Enterprise, kao i administratorima sustava organizacija u kojima se 1C:Enterprise koristi, te opisuje neke aspekte razvoja i konfiguracije klijent-poslužitelj verzije sustava iz gledište organizacije sigurnost informacija. Ovaj članak se ne može koristiti kao zamjena za dokumentaciju, već samo ukazuje na neke točke koje se u njemu još nisu odrazile. I, naravno, ni ovaj članak, ni sva dokumentacija neće moći odraziti složenost problema izgradnje sigurnog informacijskog sustava, koji istovremeno mora zadovoljiti proturječne zahtjeve sigurnosti, performansi, praktičnosti i funkcionalnosti.

Klasifikacija i terminologija

Informacijske prijetnje ključni su predmet razmatranja u članku.

Informacijska prijetnja– mogućnost situacije u kojoj se podaci neovlašteno čitaju, kopiraju, mijenjaju ili blokiraju.

I, na temelju ove definicije, u članku su informacijske prijetnje klasificirane na sljedeći način:

Neovlašteno uništavanje podataka
Neovlaštena izmjena podataka
Neovlašteno kopiranje podataka
Neovlašteno čitanje podataka
Nedostupnost podataka

Sve prijetnje se dijele na namjerne i nenamjerne. Ostvarena informacijska prijetnja će biti pozvana incident. Značajke sustava su:

Ranjivosti– značajke koje dovode do incidenata Zaštitne mjere– značajke koje blokiraju mogućnost incidenta

Uglavnom, razmatraju se samo oni slučajevi čija je vjerojatnost posljedica korištenja tehnološke platforme 1C:Enterprise 8.0 u verziji klijent-poslužitelj (u daljnjem tekstu, u slučajevima kada to nije u suprotnosti sa značenjem jednostavno 1C ili 1C 8.0) . Definiramo sljedeće glavne uloge u odnosu na korištenje sustava:

Operateri– korisnici koji imaju ograničena prava uloge aplikacije za pregled i izmjenu podataka, ali nemaju administrativne funkcije
Administratori sustava– korisnici koji imaju administrativna prava u sustavu, uključujući administrativna prava u operativnim sustavima aplikacijskog poslužitelja i MS SQL poslužitelja, administrativna prava u MS SQL-u itd.
Administratori informacijske sigurnosti- korisnici kojima su delegirane određene administrativne funkcije u 1C infobazi (kao što su dodavanje korisnika, testiranje i popravljanje, sigurnosna kopija, postavljanje rješenja aplikacije itd.)
Programeri sustava- korisnici koji razvijaju aplikativno rješenje. Općenito, možda nemaju pristup radnom sustavu.
Osobe bez izravnog pristupa sustavu- korisnici kojima nisu delegirana prava pristupa 1C, ali koji, u jednoj ili drugoj mjeri, mogu utjecati na rad sustava (obično su to svi korisnici iste domene Active Directory u kojoj je sustav instaliran). Ova kategorija se prvenstveno smatra za identificiranje potencijalno opasnih entiteta u sustavu.
Automatizirane administrativne skripte– programi kojima su delegirane određene funkcije, dizajnirani da automatski izvode određene radnje (na primjer, uvoz-izvoz podataka)

Ovdje treba istaknuti dvije točke: prvo, ova klasifikacija je vrlo gruba i ne uzima u obzir podjele unutar svake grupe – takva će se podjela napraviti za neke specifične slučajeve, a drugo, pretpostavlja se da druge osobe ne mogu utjecati na rad sustav, koji bi trebao biti osiguran sredstvima izvan 1C.

Svaki sigurnosni sustav mora biti dizajniran imajući na umu izvedivost i troškove vlasništva. Općenito, pri razvoju i implementaciji informacijskog sustava potrebno je da cijena zaštite sustava odgovara:

vrijednost zaštićenih informacija;
trošak stvaranja incidenta (u slučaju namjerne prijetnje);
financijski rizici u slučaju incidenta

Besmisleno je i štetno organizirati zaštitu puno skuplje od procjene njezine financijske učinkovitosti. Postoji nekoliko metoda za procjenu rizika od gubitka informacija, ali one se ne razmatraju u ovom članku. Drugi važan aspekt je održavati ravnotežu često suprotstavljenih zahtjeva za informacijsku sigurnost, performanse sustava, praktičnost i jednostavnost korištenja sustava, brzinu razvoja i implementacije i druge zahtjeve za informacijske sustave poduzeća.

Glavne značajke mehanizma informacijske sigurnosti sustava

1C:Enterprise 8.0 dolazi u dvije verzije: datoteka i klijent-poslužitelj. Verzija datoteke ne može se smatrati pružanjem informacijske sigurnosti sustava iz sljedećih razloga:

Podaci i konfiguracija pohranjeni su u datoteci koja je dostupna za čitanje i pisanje svim korisnicima sustava.
Kao što će biti prikazano u nastavku, autorizaciju sustava vrlo je lako zaobići.
Integritet sustava osigurava samo jezgra klijentskog dijela.

U verziji klijent-poslužitelj, MS SQL Server se koristi za pohranu informacija, što pruža:

Sigurnija pohrana podataka.
Izolirajte datoteke od izravnog pristupa.
Napredniji mehanizmi transakcija i zaključavanja.

Unatoč značajnim razlikama između verzija sustava datoteke i klijent-poslužitelj, oni imaju jedinstvenu shemu kontrole pristupa na razini aplikacijskog rješenja, koja pruža sljedeće značajke:

Autorizacija korisnika lozinkom navedenom u 1C.
Autorizacija korisnika od strane trenutnog korisnika Windowsa.
Dodjela uloga korisnicima sustava.
Ograničenje izvršavanja administrativnih funkcija po ulogama.
Dodjela dostupnih sučelja po ulogama.
Ograničavanje pristupa objektima metapodataka po ulogama.
Ograničavanje pristupa pojedinostima objekata po ulogama.
Ograničavanje pristupa podatkovnim objektima prema ulogama i parametrima sesije.
Ograničenje interaktivnog pristupa podacima i izvršnim modulima.
Neka ograničenja izvršavanja koda.

Općenito, korištena shema pristupa podacima prilično je tipična za informacijske sustave ove razine. Međutim, u odnosu na ovu implementaciju troslojne klijent-poslužitelj arhitekture, postoji nekoliko temeljnih aspekata koji dovode do relativno velikog broja ranjivosti:

Veliki broj faza obrade podataka, a u svakoj fazi mogu se primjenjivati različita pravila za pristup objektima.

Donekle pojednostavljeni dijagram koraka obrade podataka koji su značajni sa stajališta sigurnosti prikazan je na slici 1. Opće pravilo za 1C je smanjiti ograničenja dok se krećete niz ovu shemu, dakle, iskorištavanje ranjivosti na jednom od gornje razine može poremetiti sustav na svim razinama.
Nedovoljno otklonjene procedure za kontrolu prenesenih podataka tijekom prijelaza s razine na razinu.

Nažalost, daleko od toga da su svi unutarnji mehanizmi sustava savršeno otklonjeni, posebno za neinteraktivne mehanizme, čije je otklanjanje pogrešaka s jedne strane uvijek dugotrajnije, ali s druge strane odgovornije. Ova "bolest" nije problem isključivo 1C, nalazi se u mnogim poslužiteljskim proizvodima većine dobavljača. Tek posljednjih godina pozornost na ove probleme značajno je porasla.
Nedovoljno visoka prosječna kvalifikacija programera i administratora sustava, naslijeđena iz prethodne verzije.

Proizvodi linije 1C:Enterprise u početku su bili usmjereni na jednostavnost razvoja i podrške te na rad u malim organizacijama, pa nije iznenađujuće da povijesno gledano, značajan dio "programera" primijenjenih rješenja i "administratora" sustava ne imati dovoljno znanja i vještina za rad sa mnogo složenijim proizvodom, a to je verzija 8.0. Problem pogoršava praksa usvojena u tvrtkama primateljima franšize da se treniraju "u borbi" na račun kupaca, bez sustavnog pristupa ovom pitanju. Potrebno je odati priznanje 1C za činjenicu da se u posljednjih nekoliko godina ova situacija postupno poboljšava: ozbiljni primatelji franšize počeli su odgovornije pristupati problemu zapošljavanja i osposobljavanja osoblja, razini informatičke podrške od strane 1C se značajno povećao, pojavili su se programi certificiranja usmjereni na visoku razinu usluge; ali situacija se ne može odmah ispraviti pa ovaj čimbenik treba uzeti u obzir prilikom analize sigurnosti sustava.
Relativno mala starost platforme.

Među proizvodima sličnog usmjerenja i namjene, ovo je jedno od najmlađih rješenja. Funkcionalnost platforme je više-manje riješena prije manje od godinu dana. Istodobno, svako izdanje platforme, počevši od 8.0.10 (u ovom izdanju implementirane su gotovo sve trenutne značajke sustava) postalo je mnogo stabilnije od prethodnih. Funkcionalnost standardno primijenjenih rješenja i dalje raste skokovima i granicama, iako se koristi samo polovica mogućnosti platforme. Naravno, u takvim uvjetima govor o stabilnosti može biti poprilično proizvoljan, ali općenito se mora priznati da su rješenja temeljena na platformi 1C 8.0 u mnogočemu znatno ispred u funkcionalnosti i performansama (a često i po stabilnosti). ) slična rješenja na platformi 1C 7.7.

Dakle, sustav (i, možda, tipično aplikativno rješenje) je raspoređen u poduzeću i instaliran na računala. Prije svega, potrebno je stvoriti okruženje u kojem će sigurnosna postavka 1C imati smisla, a za to se mora konfigurirati na način da se ispuni pretpostavka da postavke sustava značajno utječu na sigurnost sustava.

Slijedite opća pravila za postavljanje sigurnosti.

Ne može biti govora ni o kakvoj informacijskoj sigurnosti sustava ako se ne poštuju osnovna načela stvaranja sigurnih sustava. Provjerite jesu li ispunjeni barem sljedeći uvjeti:

Pristup poslužiteljima je fizički ograničen i osiguran je njihov nesmetan rad:
- poslužiteljski hardver zadovoljava zahtjeve pouzdanosti, zamjena neispravnog poslužiteljskog hardvera je otklonjena, redundantne sheme se koriste za posebno kritična područja hardver(RAID, napajanje iz više izvora, više komunikacijskih kanala, itd.);
- poslužitelji se nalaze u zaključanoj prostoriji, a ova prostorija je otvorena samo za vrijeme trajanja radova koji se ne mogu izvoditi na daljinu;
- samo jedna ili dvije osobe imaju pravo otvoriti poslužiteljsku sobu, u slučaju nužde razvijen je sustav obavijesti za odgovorne osobe;
- osigurano neprekidno napajanje poslužitelja
- osiguran je normalan klimatski način rada opreme;
- u poslužiteljskoj sobi postoji požarni alarm, nema mogućnosti poplave (osobito za prvi i zadnji kat);
Postavke mrežne i informacijske infrastrukture poduzeća su točne:
- vatrozidi su instalirani i konfigurirani na svim poslužiteljima;
- svi korisnici i računala su autorizirani na mreži, lozinke su dovoljno složene da se ne mogu pogoditi;
- operatori sustava imaju dovoljno prava za normalan rad s njim, ali nemaju prava na administrativne radnje;
- sva računala u mreži imaju instalirane i omogućene antivirusne alate;
- poželjno je da korisnici (osim mrežnih administratora) nemaju administrativna prava na radnim stanicama klijenata;
- pristup internetu i prijenosnim medijima za pohranu trebao bi biti reguliran i ograničen;
- mora biti konfigurirana revizija sustava sigurnosnih događaja;
Glavni organizacijski problemi su riješeni:
- korisnici su kvalificirani za rad s 1C i hardverom;
- korisnici su obaviješteni o odgovornosti za kršenje pravila rada;
- financijski odgovoran za svaki materijalni element informacijskog sustava;
- svi blokovi sustava zapečaćeno i zatvoreno;
- obratite posebnu pozornost na upute i nadzor čistača soba, građevinara i električara. Te osobe mogu nepažnjom prouzročiti štetu koja nije usporediva s namjernom štetom koju je prouzročio nesavjesni korisnik sustava.

Pažnja! Ovaj popis nije konačan, već samo opisuje ono što se često zanemaruje prilikom postavljanja bilo kojeg prilično složenog i skupog informacijskog sustava!

MS SQL Server, aplikacijski poslužitelj i klijentski dio rade na različitim računalima, poslužiteljske aplikacije rade pod pravima posebno kreiranih Korisnici Windowsa;
Za MS SQL Server
- postavljen je mješoviti način autorizacije
- Korisnici MS SQL-a uključeni u ulogu administratora poslužitelja ne sudjeluju u 1C,
- za svaki IB 1C kreiran je poseban MS SQL korisnik koji nema privilegirani pristup poslužitelju,
- MS SQL korisnik jednog IB-a nema pristup drugim IB-ovima;
Korisnici nemaju izravan pristup datotekama poslužitelja aplikacija i MS SQL poslužitelja
Radne stanice operatera opremljene su sustavom Windows 2000/XP (ne Windows 95/98/Me)

Nemojte zanemariti preporuke programera sustava i čitanje dokumentacije. Važni materijali o postavljanju sustava objavljeni su na ITS diskovima u odjeljku "Smjernice". Obratite posebnu pozornost na sljedeće članke:

Značajke rada aplikacija s poslužiteljem 1C: Enterprise
Postavljanje podataka 1C:Enterprise 8.0
Ažurirajte 1C:Enterprise 8.0 od strane korisnika Microsoft Windows bez administratorskih prava
Uređivanje popisa korisnika u ime korisnika koji nema administrativna prava
Konfiguriranje postavki vatrozida za Windows XP SP2 za SQL Server 2000 i SQL Server Desktop Engine (MSDE)
Konfiguriranje COM+ Windows XP SP2 parametara za rad poslužitelja 1C:Enterprise 8.0
Konfiguriranje postavki vatrozida za Windows XP SP2 za rad poslužitelja 1C:Enterprise 8.0
Konfiguriranje postavki vatrozida za Windows XP SP2 za HASP License Manager
Izrada sigurnosne kopije baze podataka pomoću SQL Servera 2000
Problemi instalacije i konfiguracije 1C: Enterprise 8.0 u verziji "klijent-poslužitelj"(jedan od najvažnijih članaka)
Osobitosti postavke prozora Server 2003 prilikom instaliranja poslužitelja 1C:Enterprise 8.0
Regulacija pristupa korisnika informacijskoj bazi u verziji klijent-poslužitelj(jedan od najvažnijih članaka)
Poslužitelj 1C: Enterprise i SQL Server
Detaljan postupak instalacije za 1C:Enterprise 8.0 u verziji "klijent-poslužitelj"(jedan od najvažnijih članaka)
Korištenje ugrađenog jezika na poslužitelju 1C:Enterprise

Ali, čitajući dokumentaciju, budite kritični prema primljenim informacijama, na primjer, u članku "Problemi instaliranja i konfiguriranja 1C: Enterprise 8.0 u verziji klijent-poslužitelj" prava koja su potrebna za korisnika USER1CV8SERVER nisu sasvim točna opisano. Dolje će se nalaziti veze na popis u nastavku, na primjer, [ITS1] znači članak "Osobitnosti rada aplikacija s poslužiteljem 1C:Enterprise". Sve reference na članke odnose se na posljednje izdanje ITS-a u vrijeme pisanja (siječanj 2006.)

Koristite mogućnosti autorizacije za korisnike u kombinaciji s Windows autorizacijom

Od dva moguća načina autorizacije korisnika: ugrađeni 1C i u kombinaciji s autorizacijom za Windows OS, ako je moguće, trebate odabrati kombiniranu autorizaciju. To će omogućiti da se korisnici ne zbune s nekoliko lozinki na poslu, ali u isto vrijeme neće sniziti razinu sigurnosti sustava. Međutim, čak i za korisnike koji koriste samo Windows autorizaciju, vrlo je poželjno postaviti lozinku prilikom izrade, a tek nakon toga onemogućiti 1C autorizaciju za ovog korisnika. Kako bi se osigurao oporavak sustava u slučaju uništenja strukture Active Directory, potrebno je ostaviti barem jednog korisnika koji se može prijaviti pomoću 1C autorizacije.

Prilikom kreiranja uloga aplikacijskog rješenja, nemojte dodavati "backup" prava

Svaka uloga aplikacijskog rješenja trebala bi odražavati minimalni potrebni skup prava za izvođenje radnji definiranih ovom ulogom. Međutim, neke se uloge ne mogu koristiti samostalno. Na primjer, za interaktivno pokretanje vanjska obrada možete stvoriti zasebnu ulogu i dodati je svim korisnicima koji bi trebali koristiti vanjsku obradu.

Redovito pregledavajte zapisnike sustava i zapisnike

Ako je moguće, regulirati i automatizirati pregled zapisnika i protokola rada sustava. Pravilnom konfiguracijom i redovitim pregledom dnevnika (filtriranih samo prema važnim događajima) možete pravodobno otkriti neovlaštene radnje ili ih čak spriječiti tijekom faze pripreme.

Neke značajke verzije klijent-poslužitelj

Ovaj odjeljak opisuje neke od značajki verzije klijent-poslužitelj i njihov utjecaj na sigurnost. Radi lakšeg čitanja, usvojena je sljedeća oznaka:

Pažnja! opis ranjivosti

Pohranjivanje informacija koje kontroliraju pristup sustavu

Pohranjivanje popisa IB korisnika

Sve informacije o popisu korisnika ovog IS-a i ulogama koje su im dostupne u njemu pohranjene su u tablici Params u bazi podataka MS SQL (vidi [ITS2]). Gledajući strukturu i sadržaj ove tablice, postaje očito da su sve informacije o korisnicima pohranjene u zapisu s vrijednošću polja FileName - "users.usr".

Budući da pretpostavljamo da korisnici nemaju pristup bazi podataka MS SQL, ova činjenica sama po sebi ne može biti iskorištena od strane napadača, međutim, ako je moguće izvršiti kod u MS SQL-u, to "otvara vrata" za dobivanje bilo kojeg (! ) Pristup iz 1C . Isti mehanizam (s manjim promjenama) može se koristiti i za datotečnu verziju sustava, što, uzimajući u obzir osobitosti datotečne verzije, u potpunosti isključuje njezinu primjenjivost u izgradnji sigurnih sustava.

Preporuka: Trenutno ne postoji način da se aplikacija u potpunosti zaštiti od takve promjene, osim korištenja okidača na razini MS SQL Servera, što, s druge strane, može uzrokovati probleme prilikom ažuriranja verzije platforme ili promjene popisa korisnika. Da biste pratili takve promjene, možete koristiti 1C zapisnik (obrativši pozornost na "sumnjive" prijave u načinu konfiguratora bez navođenja korisnika) ili održavati SQL Profiler stalno pokrenutim (što će imati izrazito negativan utjecaj na performanse sustava) ili konfigurirati upozorenja mehanizam (najvjerojatnije, zajedno pomoću okidača)

Pohranjivanje informacija o IB listi na poslužitelju

Za svaki 1C aplikacijski poslužitelj, informacije se pohranjuju na popisu MS SQL baza podataka povezanih s njim. Svaka infobaza koristi svoj vlastiti niz veze između poslužitelja aplikacija i MS SQL poslužitelja. Informacije o bazama podataka registriranim na aplikacijskom poslužitelju, zajedno sa nizovima veze, pohranjene su u datoteci srvrib.lst, koja se nalazi na poslužitelju u direktoriju<Общие данные приложений>/1C/1Cv8 (na primjer, C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst). Za svaki IB pohranjuje se potpuni niz veze, uključujući lozinku korisnika MS SQL-a kada se koristi mješoviti MS SQL autorizacijski model. Upravo prisutnost ove datoteke omogućuje strah od neovlaštenog pristupa bazi podataka MS SQL, a ako se, suprotno preporukama, za pristup barem jednoj bazi podataka koristi privilegirani korisnik (na primjer, "sa"), tada osim prijetnje jednog IS-a, postoji prijetnja za cijeli sustav koji koristi MS SQL.

Zanimljivo je napomenuti da korištenje mješovite autorizacije i Windows autorizacije na MS SQL poslužitelju dovodi do različitih vrsta problema prilikom pristupa ovoj datoteci. Dakle, ključna negativna svojstva Windows autorizacije bit će:

Rad sve informacijske sigurnosti na aplikacijskom poslužitelju i na MS SQL poslužitelju pod jednim skupom prava (najvjerojatnije redundantno)
Iz procesa 1C aplikacijskog poslužitelja (ili u općem slučaju od korisnika USER1CV8SERVER ili njegovog ekvivalenta) bez navođenja lozinke, možete se jednostavno povezati na bilo koju informacijsku sigurnost bez navođenja lozinke

S druge strane, stjecanje sposobnosti izvršavanja proizvoljnog koda iz korisničkog konteksta USER1CV8SERVER može biti teže za napadača od dobivanja navedene datoteke. Usput, prisutnost takve datoteke još je jedan argument za širenje funkcija poslužitelja na različitim računalima.

Preporuka: Datoteka srvrib.lst trebala bi biti dostupna samo procesu poslužitelja. Obavezno postavite reviziju da biste promijenili ovu datoteku.

Nažalost zadano datu datoteku gotovo da nije zaštićen od čitanja, što se mora uzeti u obzir pri postavljanju sustava. U idealnom slučaju, aplikacijski poslužitelj bi spriječio čitanje i pisanje ove datoteke (uključujući čitanje i pisanje od strane korisničkih veza koje se izvršavaju na ovom poslužitelju) tijekom rada.

Nedostatak autorizacije prilikom kreiranja IB-a na poslužitelju

Pažnja! Pogreška nedostatka autorizacije ispravljena je u izdanju 8.0.14 platforme 1C:Enterprise. U ovom izdanju pojavio se koncept "1C:Enterprise Server Administrator", ali sve dok je popis administratora naveden na poslužitelju, sustav djeluje kako je opisano u nastavku, stoga ne zaboravite na ovu moguću značajku.

Vjerojatno najveća ranjivost u ovom odjeljku je mogućnost gotovo neograničenog dodavanja informacijske sigurnosti aplikacijskom poslužitelju, zbog čega svaki korisnik koji je dobio pristup vezi s aplikacijskim poslužiteljem automatski dobiva mogućnost pokretanja proizvoljnog koda na aplikaciji poslužitelju. Pogledajmo ovo na primjeru.

Sustav bi trebao biti instaliran u sljedećoj verziji

MS SQL Server 2000 (na primjer, naziv mreže SRV1)
Poslužitelj 1C:Enterprise 8.0 (mrežni naziv SRV2)
Klijentska strana 1C:Enterprise 8.0 (ime mreže WS)

Pretpostavlja se da korisnik (u daljnjem tekstu KORISNIK) koji radi na WS-u ima barem minimalan pristup jednom od IB-ova registriranih na SRV2, ali nema privilegirani pristup SRV1 i SRV2. Općenito, kombinacija funkcija navedenih računala ne utječe na situaciju. Sustav je konfiguriran uzimajući u obzir preporuke u dokumentaciji i na ITS diskovima. Situacija je prikazana na sl. 2.

konfigurirati COM+ sigurnost na aplikacijskom poslužitelju tako da samo korisnici 1C imaju pravo spajanja na proces aplikacijskog poslužitelja (više detalja [ITS12]);

datoteka srvrib.lst mora biti samo za čitanje korisniku USER1CV8SERVER (da biste dodali novi IB na poslužitelj, privremeno dopustite pisanje);

za spajanje na MS SQL koristite samo TCP / IP protokol, u ovom slučaju možete:
ograničiti veze s vatrozidom;

konfigurirati korištenje nestandardnog TCP porta, što će zakomplicirati povezivanje "stranog" IB 1C;

koristiti enkripciju prenesenih podataka između aplikacijskog poslužitelja i SQL poslužitelja;

konfigurirati vatrozid poslužitelja tako da je nemoguća upotreba MS SQL poslužitelja trećih strana;

koristiti internu mrežnu sigurnost kako biste isključili mogućnost pojave neovlaštenog računala lokalna mreža(IPSec, grupne sigurnosne politike, vatrozidi itd.);

ni u kojem slučaju ne dodijelite administrativna prava korisniku USER1CV8SERVER na poslužitelju aplikacija.

Korištenje koda koji se izvodi na poslužitelju

Kada se koristi verzija klijent-poslužitelj 1C, programer može distribuirati izvršenje koda između klijenta i poslužitelja aplikacija. Da bi se kod (procedura ili funkcija) izvršavao samo na poslužitelju, potrebno ga je smjestiti u zajednički modul za koji je postavljeno svojstvo "Poslužitelj", a u slučaju kada je izvođenje modula dopušteno ne samo na poslužitelju, postavite kod u ograničeni odjeljak "#If Server ":

#Ako poslužitelj onda
Funkcija OnServer(Param1, Param2 = 0) Izvoz // Ova funkcija, unatoč svojoj jednostavnosti, izvršava se na poslužitelju
Param1 = Param1 + 12;
Vrati parametar1;
Završne funkcije
#Završi ako

Kada koristite kod koji se izvodi na poslužitelju, imajte na umu sljedeće:

kod se izvršava s pravima USER1CV8SERVER na aplikacijskom poslužitelju (dostupni su COM objekti i datoteke poslužitelja);
sve korisničke sesije pokreće jedna instanca usluge, tako da će, na primjer, prelijevanje stoga na poslužitelju uzrokovati odspajanje svih aktivnih korisnika;
otklanjanje pogrešaka u modulima poslužitelja je teško (na primjer, ne možete postaviti točku prekida u alatu za ispravljanje pogrešaka), ali to treba učiniti;
prijenos kontrole s klijenta na poslužitelj aplikacija i obrnuto može zahtijevati značajne resurse s velikim količinama prenesenih parametara;
korištenje interaktivnih alata (obrasci, dokumenti proračunske tablice, dijaloški okviri), vanjska izvješća i obrada u kodu na aplikacijskom poslužitelju nije moguća;
upotreba globalnih varijabli (varijable modula aplikacije deklarirane s "Izvoz") nije dopuštena;

Pogledajte [ITS15] i druge ITS članke za detalje.

Aplikacijski poslužitelj mora ispunjavati posebne zahtjeve za pouzdanost. U ispravno izgrađenom sustavu klijent-poslužitelj moraju biti ispunjeni sljedeći uvjeti:

nikakve radnje klijentske aplikacije ne smiju prekidati rad poslužitelja (osim u administrativnim slučajevima);
ne može raditi na poslužitelju programski kod primljeno od klijenta;
resursi bi trebali biti "pošteno" raspoređeni po klijentskim vezama, osiguravajući dostupnost poslužitelja bez obzira na trenutno opterećenje;
u nedostatku zaključavanja podataka, klijentske veze ne bi trebale utjecati na rad jedne druge;
na poslužitelju ne postoji korisničko sučelje, ali treba razviti alate za praćenje i evidentiranje;

Općenito, 1C sustav je izgrađen na način da se približi ovim zahtjevima (na primjer, nemoguće je prisiliti da se vanjska obrada izvrši na poslužitelju), ali još uvijek postoji nekoliko neugodnih značajki, stoga:

Preporuka: Prilikom projektiranja pozadinske izvedbe preporuča se pridržavati se načela minimalnog sučelja. Oni. broj ulaza u poslužiteljske module iz klijentske aplikacije trebao bi biti vrlo ograničen, a parametri strogo regulirani. Preporuka: Prilikom primanja parametara procedura i funkcija na poslužitelju, potrebno je izvršiti provjeru valjanosti parametara (provjera da parametri odgovaraju očekivanom tipu i rasponu vrijednosti). To se ne radi u standardnim rješenjima, ali je vrlo poželjno uvesti obveznu validaciju u vlastiti razvoj. Preporuka: Kada generirate tekst zahtjeva (a još više parametar naredbe Run) na strani poslužitelja, nemojte koristiti nizove primljene od klijentske aplikacije.

Opća preporuka bila bi upoznati se s načelima sigurne gradnje mreža-aplikacije za baze podataka i rad na sličnim principima. Sličnost je doista značajna: prvo, kao i web aplikacija, aplikacijski poslužitelj je međusloj između baze podataka i korisničkog sučelja (glavna razlika je u tome što web poslužitelj čini korisničko sučelje); drugo, sa stajališta sigurnosti, ne možete vjerovati podacima primljenim od klijenta, jer moguće je pokrenuti vanjska izvješća i obradu.

Prijelazni parametri

Prosljeđivanje parametara funkciji (proceduri) koja se izvodi na poslužitelju prilično je delikatan problem. To je prvenstveno zbog potrebe njihovog prijenosa između procesa aplikacijskog poslužitelja i klijenta. Kada se kontrola prenese sa strane klijenta na stranu poslužitelja, svi preneseni parametri se serijaliziraju, prenose na poslužitelj, gdje se "raspakiraju" i koriste. Prilikom prelaska sa strane poslužitelja na stranu klijenta, proces je obrnut. Ovdje treba napomenuti da ova shema ispravno obrađuje prosljeđivanje parametara prema referenci i po vrijednosti. Sljedeća ograničenja primjenjuju se prilikom prosljeđivanja parametara:

Samo nepromjenjive vrijednosti (tj. čije se vrijednosti ne mogu mijenjati) mogu se prenijeti između klijenta i poslužitelja (u oba smjera): primitivni tipovi, reference, generičke zbirke, vrijednosti nabrajanja sustava, pohrana vrijednosti. Ako pokušate poslati nešto drugo, klijentska aplikacija se ruši (čak i ako poslužitelj pokuša poslati netočan parametar).
Ne preporučuje se prijenos velikih količina podataka prilikom prosljeđivanja parametara (na primjer, nizovi duži od 1 milijun znakova), to može negativno utjecati na performanse poslužitelja.
Ne možete proslijediti parametre koji sadrže kružnu referencu, i od poslužitelja do klijenta i obrnuto. Ako pokušate proslijediti takav parametar, klijentska aplikacija se ruši (čak i ako poslužitelj pokuša poslati netočan parametar).
Ne preporučuje se prosljeđivanje vrlo složenih zbirki podataka. Ako pokušate proslijediti parametar s vrlo velikom razinom ugniježđenja, poslužitelj se ruši (!).

Pažnja! Najneugodnija značajka u ovom trenutku vjerojatno je pogreška u prosljeđivanju složenih zbirki vrijednosti. Tako, na primjer, kod: NestingLevel = 1250;
M = Novi niz;
ProšaoParametar = M;
Za N = 1 Petljom razine ugniježđenja
MVInt = Novi niz;
M.Dodaj (MVInt);
M = MVin;
EndCycle;
Funkcija poslužitelja(ProšaoParametar);

Uzrokuje pad poslužitelja, prekida vezu sa svim korisnicima, a to se događa prije nego što se kontrola prenese na 1C kod.

Korištenje nesigurnih funkcija na strani poslužitelja.

Ne mogu se sve značajke ugrađenog jezika koristiti u kodu koji se izvodi na aplikacijskom poslužitelju, ali čak i među dostupnim alatima postoje mnoge "problematične" konstrukcije koje se uvjetno mogu klasificirati na sljedeći način:

sposoban pružiti mogućnost izvršavanja koda koji nije sadržan u konfiguraciji (grupa "Izvršavanje koda")
može klijentskoj aplikaciji pružiti informacije o korisničkoj datoteci i operativnom sustavu ili izvršiti radnje koje nisu povezane s radom s podacima ("Kršenje prava")
može uzrokovati pad poslužitelja ili koristiti vrlo velike resurse (grupa za neuspjeh poslužitelja)
sposoban uzrokovati neuspjeh klijenta (grupa "Client failure") – ova vrsta se ne razmatra. Primjer: prosljeđivanje promjenjive vrijednosti poslužitelju.
pogreške u algoritmima programiranja (beskonačne petlje, neograničena rekurzija, itd.) ("Programske pogreške")

Glavne problematične konstrukcije koje su mi poznate (s primjerima) navedene su u nastavku:

Izvrši postupak (<Строка>)

Izvršenje koda. Omogućuje vam da izvršite dio koda koji mu se prosljeđuje kao vrijednost niza. Kada se koristi na poslužitelju, potrebno je paziti da se podaci primljeni od klijenta ne koriste kao parametar. Na primjer, sljedeća upotreba nije dopuštena:
#Ako poslužitelj onda
Procedura Izvoz na poslužitelju(param1).
Izvrši (param1);
EndProcedure
#Završi ako

Upišite "COMObject" (konstruktor Novi COMObject(<Имя>, <Имя сервера>))

Stvara vanjski COM objekt aplikacije kao USER1CV8SERVER na aplikacijskom poslužitelju (ili drugom navedenom računalu). Kada se koristi na poslužitelju, provjerite da se parametri ne prosljeđuju iz klijentske aplikacije. Međutim, na strani poslužitelja ovu značajku je učinkovito koristiti prilikom uvoza/izvoza, slanja podataka putem Interneta, implementacije nestandardnih funkcija itd.

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

Kršenje prava i izvršavanje koda. Slično prethodnom, samo dobivanje COM objekta koji odgovara datoteci.

Postupci i funkcijeIme računala(), TempFileDirectory(), ProgramDirectory(), WindowsUsers()

Kršenje prava. Omogućite, njihovim izvršavanjem na poslužitelju, da saznate detalje organizacije poslužiteljskog podsustava. Kada se koriste na poslužitelju, osigurajte da se podaci ili ne prenose klijentu ili da nisu dostupni operaterima bez odgovarajućeg ovlaštenja. Obratite posebnu pozornost na činjenicu da se podaci mogu proslijediti natrag u parametru proslijeđenom referencom.

Procedure i funkcije za rad s datotekama (CopyFile, FindFiles, MergeFiles i mnoge druge), kao i vrste "File".

Kršenje prava. Omogućuju, njihovim izvršavanjem na poslužitelju, dobivanje zajedničkog pristupa lokalnim (i smještenim na mreži) datotekama dostupnim pod pravima korisnika USER1CV8SERVER. Ako se koristi svjesno, tada je moguće učinkovito implementirati takve zadatke kao što je uvoz/izvoz podataka na poslužitelju.

Prije korištenja ovih funkcija svakako provjerite korisnička prava 1C. Za provjeru korisničkih prava, možete koristiti sljedeću konstrukciju u modulu poslužitelja:
#Ako poslužitelj onda
Postupak DoWorkOnFile() Izvoz
UlogaAdministrator = Metapodaci.Uloge.Administrator;
Korisnik = SessionParameters.CurrentUser;
Ako User.Roles.Contains(RoleAdministrator) Onda
//Ovdje se izvršava kod za rad s datotekama
Završi ako;
#Završi ako
Obavezno provjerite parametre ako koristite ove postupke i funkcije, inače postoji rizik od slučajnog ili svjesnog nanošenja nepopravljive štete 1C aplikacijskom poslužitelju, na primjer, prilikom izvršavanja koda na poslužitelju:
Put = "C:\Documents and Settings\All Users\Application Data\1C\1Cv8\";
Premjesti datoteku(Puta + "srvrib.lst", Put + "OvdjeGdjeFileGone");
Nakon izvršenja takvog koda na poslužitelju, ako korisnik USER1CV8SERVER ima pravo promijeniti ga, kao što je gore opisano, i nakon ponovnog pokretanja procesa poslužitelja (prema zadanim postavkama, 3 minute nakon što se svi korisnici odjave), pojavit će se VELIKO pitanje o pokretanju poslužitelju. Ali i to je moguće potpuno uklanjanje datoteke...

Vrste "XBase", "BinaryData", "XMLReader", "XMLWriter", "XSLTransformer", "ZipFileWrite", "ZipFileReader", "TextReader", "TextWriter"

Kršenje prava. Omogućuju, njihovim izvršavanjem na poslužitelju, pristup lokalnim (i lociranim na mreži) datotekama određenih tipova te ih čitati/pisati pod pravima korisnika USER1CV8SERVER. Ako se koristi svjesno, tada je moguće učinkovito implementirati takve zadatke kao što su uvoz/izvoz podataka na poslužitelju, evidentiranje rada nekih funkcija, rješavanje administrativnih zadataka. Općenito, preporuke su iste kao i prethodni paragraf, ali treba razmotriti mogućnost prijenosa podataka tih datoteka (ali ne objekata svih ovih vrsta) između klijentskog i poslužiteljskog dijela.

Upišite "Informacije o sustavu"

Kršenje prava. Omogućuje da u slučaju netočnog korištenja i prijenosa podataka u klijentski dio aplikacije možete dobiti podatke o aplikacijskom poslužitelju. Poželjno je ograničiti pravo korištenja prilikom korištenja.

Upisuje "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Kršenje prava. Kada se koristi na poslužitelju, povezuje se s udaljenim računalom s aplikacijskog poslužitelja pod pravima USER1CV8SERVER. Preporuke:

Kontrola parametara prilikom pozivanja metoda.

Kontrola korisničkih prava 1C.

Ozbiljna ograničenja prava korisnika USER1CV8SERVER na pristup mreži.

Ispravna konfiguracija vatrozida na poslužitelju aplikacija 1C.

Kada se pravilno koristi, prikladno je organizirati, na primjer, distribuciju e-pošte s poslužitelja aplikacija.

Upisuje "InfobaseUsersManager", "InfobaseUser"

Kršenje prava. Ako se koristi pogrešno (u privilegiranom modulu), moguće je dodati korisnike ili promijeniti parametre autorizacije postojećih korisnika.

Format funkcije

Kvar poslužitelja. Da! Ova naizgled bezopasna funkcija, ako se njezini parametri ne kontroliraju i ne izvode na poslužitelju, može uzrokovati pad poslužiteljske aplikacije. Pogreška se očituje pri formatiranju brojeva i korištenju načina izlaza vodećih nula i velikog broja znakova, npr.
Format (1, "HTS=999; FHN=");
Nadam se da će ova greška biti ispravljena u sljedećim izdanjima platforme, ali za sada, u svim pozivima ovoj funkciji koji se mogu izvršiti na poslužitelju, provjerite parametre poziva.

Postupci i funkcije za pohranjivanje vrijednosti (ValueToStringInt, ValueToFile)

Kvar poslužitelja. Ove funkcije ne rukuju kružnim referencama u zbirkama i vrlo dubokim ugniježđenjem, tako da se mogu srušiti u nekim vrlo posebnim slučajevima.

Pogreške u granicama i vrijednosti posebnih parametara u funkcijama. Kontrola izvršenja.

Jedan od problema na koji se može naići pri korištenju poslužitelja je velika "odgovornost" funkcija poslužitelja (mogućnost rušenja cijele poslužiteljske aplikacije zbog greške u jednoj vezi i korištenje jednog "prostora resursa" za sve veze) . Stoga je potrebno kontrolirati glavne parametre vremena izvođenja:

Za ugrađene jezične funkcije provjerite njihove parametre pokretanja (primjeran primjer je funkcija "Format")
Kada koristite petlje, provjerite je li aktiviran uvjet izlaza iz petlje. Ako je petlja potencijalno beskonačna, umjetno ograničite broj iteracija: IterationCountMaxValue = 1000000;
Broj iteracija = 1;
Zbogom
Funkcija koja možda neće vratiti False()
I (Brojanje iteracija<МаксимальноеЗначениеСчетчикаИтераций) Цикл
//.... Tijelo petlje
Broj iteracija = Broj iteracija + 1;
EndCycle;
Ako IterationCount>IterationCountMaxValue Onda
//.... obraditi događaj pretjerano dugog izvršavanja petlje
Završi ako;
Ograničite maksimalnu razinu ugniježđenja kada koristite rekurziju.
Prilikom formiranja i izvršavanja upita pokušajte spriječiti vrlo duga dohvaćanja i dohvaćanja velike količine informacija (na primjer, kada koristite uvjet "IN HIJERARHIJA", nemojte koristiti praznu vrijednost)
Prilikom dizajniranja baze podataka osigurajte dovoljno veliku marginu za brojeve (inače zbrajanje i množenje postaju nekomutativni i neasocijativni, što otežava otklanjanje pogrešaka)
U izvršnim upitima provjerite prisutnost logike operacije NULL vrijednosti I ispravan rad uvjete i izraze upita koji koriste NULL.
Kada koristite zbirke, kontrolirajte mogu li se prosljeđivati između poslužitelja aplikacija i strane klijenta.

Korištenje pristupa terminala na strani klijenta za ograničavanje pristupa

Nije neuobičajeno vidjeti preporuke za korištenje terminalskog pristupa za ograničavanje pristupa podacima i poboljšanje performansi izvršavanjem koda na strani klijenta na terminalskom poslužitelju. Da, kada je pravilno konfiguriran, korištenje terminalskog pristupa doista može povećati ukupnu razinu sigurnosti sustava, ali, nažalost, često je moguće naići na činjenicu da se u praktičnoj uporabi sigurnost sustava samo smanjuje. Pokušajmo shvatiti s čime je to povezano. Sada postoje dva uobičajena načina organiziranja pristupa terminalu, a to su Microsoft Terminal Services (RDP protokol) i Citrix Metaframe Server (ICA protokol). Općenito, Citrixovi alati pružaju mnogo fleksibilnije mogućnosti administracije pristupa, ali cijena ovih rješenja je mnogo veća. Razmotrit ćemo samo glavne značajke zajedničke za oba protokola koje mogu sniziti ukupnu razinu sigurnosti. Postoje samo tri glavne opasnosti pri korištenju pristupa terminalu:

Mogućnost blokiranja rada drugih korisnika hvatanjem prevelike količine resursa
Pristup podacima drugih korisnika.
Neovlašteno kopiranje podataka s terminalskog poslužitelja na računalo korisnika

U svakom slučaju, usluge terminala vam omogućuju:

Povećati pouzdanost rada (u slučaju kvara na terminalskom računalu, korisnik može naknadno nastaviti rad s istog mjesta)
Ograničite pristup klijentskoj aplikaciji i datotekama koje sprema.
Prenesite računalno opterećenje s radnog mjesta korisnika na poslužitelj za pristup terminalu
Upravljajte postavkama sustava centralnije. Za korisnike će spremljene postavke vrijediti bez obzira s kojeg su se računala prijavili na sustav.
U nekim slučajevima možete koristiti terminalsko rješenje za daljinski pristup sustavu.

Potrebno je ograničiti broj mogućih veza na terminalski poslužitelj jednog korisnika

Zbog "proždrljivosti" 1C klijentske aplikacije u pogledu resursa, neophodno je ograničiti maksimalni broj istodobnih veza jednog korisnika (operatora) na terminalski poslužitelj. Aktivna veza može koristiti do 300 MB memorije sa samo jednom instancom aplikacije. Osim memorije, aktivno se koristi i vrijeme procesora, što također ne pridonosi stabilnosti rada korisnika ovog poslužitelja. U isto vrijeme kao i sprječavanje prekomjernog korištenja poslužiteljskih resursa, takvo ograničenje može spriječiti korištenje tuđih račun. Implementirano standardnim postavkama terminalskog poslužitelja.

Ne smijete dopustiti da više od jedne ili dvije 1C klijentske aplikacije rade istovremeno u jednoj vezi

Diktiraju ga isti razlozi kao u prethodnom stavku, ali je tehnički teže izvediv. Problem je u tome što je gotovo nemoguće spriječiti ponovno pokretanje 1C pomoću terminalskog poslužitelja (u nastavku će biti objašnjeno zašto), pa ovu značajku morate implementirati na razini aplikativnog rješenja (što također nije dobro rješenje, jer može biti "visi" sesije neko vrijeme kada aplikacija završi netočno, postaje potrebno doraditi rješenje aplikacije u aplikacijskom modulu i nekim imenicima, što će komplicirati korištenje ažuriranja iz 1C). Vrlo je poželjno ostaviti korisniku mogućnost pokretanja 2 aplikacije kako bi mogao izvoditi neke radnje (npr. generiranje izvješća) u pozadini- klijentska aplikacija je, nažalost, zapravo jednonitna.

Ne preporuča se dodijeliti prava pristupa terminalskom poslužitelju korisnicima koji imaju pravo pokretati računalne zadatke koji zahtijevaju velike resurse u 1C ili spriječiti takvo pokretanje tijekom aktivnog rada drugih korisnika.

Naravno, bolje je pristup terminalskom poslužitelju ostaviti samo korisnicima koji ne koriste takve zadatke kao što su analiza podataka (data mining), geografske sheme, uvoz/izvoz i drugi zadaci koji ozbiljno opterećuju klijentsku stranu aplikacije. Ako ipak postoji potreba za rješavanjem takvih zadataka, tada je potrebno: obavijestiti korisnika da ti zadaci mogu utjecati na rad drugih korisnika, zabilježiti u dnevnik događaj početka i završetka takvog proces, za dopuštanje izvršenja samo u zakazano vrijeme itd.

Morate biti sigurni da svaki korisnik ima pristup za pisanje samo u strogo definirane direktorije terminalskog poslužitelja i da im drugi korisnici nemaju pristup.

Prvo, ako ne ograničite mogućnost pisanja u dijeljene direktorije (kao što je direktorij u kojem je instaliran 1C), tada napadač i dalje ima priliku promijeniti ponašanje programa za sve korisnike. Drugo, podaci jednog korisnika (privremene datoteke, datoteke za spremanje postavki izvješća, itd.) nikada ne bi smjeli biti dostupni drugom korisniku terminalskog poslužitelja - općenito se ovo pravilo poštuje tijekom normalne konfiguracije. Treće, napadač još uvijek ima priliku "zasipati" particiju tako da na tvrdom disku ne ostane mjesta. Znam da će se prigovoriti da od Windowsa 2000 Windows ima mehanizam kvote, ali ovo je prilično skup mehanizam i praktički nikad nisam vidio njegovu stvarnu upotrebu.

Ako je prijašnja pitanja postavki pristupa općenito bila prilično jednostavna za implementaciju, onda tako (naizgled) jednostavan zadatak kao što je reguliranje pristupa korisnika datotekama nije trivijalan. Prvo, ako se mehanizam kvote ne koristi, tada se velike datoteke mogu spremiti. Drugo, sustav je izgrađen na način da će gotovo uvijek biti moguće spremiti datoteku tako da bude dostupna drugom korisniku.

S obzirom da je zadatak teško riješiti u potpunosti, preporuča se revizija većine događaja u datoteci

Potrebno je zabraniti povezivanje (mapiranje) disk uređaja, pisača i međuspremnika klijentske radne stanice.

U RDP-u i ICA-u moguće je organizirati automatsko povezivanje diskova, pisača, međuspremnika com-portova terminalskog računala na poslužitelj. Ako ova mogućnost postoji, tada je praktički nemoguće zabraniti pokretanje stranog koda na terminalskom poslužitelju i spremanje podataka iz 1C na klijentu za pristup terminalu. Dopusti ove značajke samo za osobe s administrativnim pravima.

Pristup mrežnim datotekama s terminalskog poslužitelja mora biti ograničen.

Ako se to ne učini, korisnik će ponovno moći pokrenuti neželjeni kod ili spremiti podatke. Budući da obični zapisnik ne prati događaje u datotekama (usput rečeno, dobra ideja za implementaciju razvojnih programera platforme), a gotovo je nemoguće postaviti reviziju sustava u cijeloj mreži (nema dovoljno resursa za održavanje), bolje je da korisnik može poslati podatke ili ispisati, ili putem e-pošte. Obratite posebnu pozornost na činjenicu da terminalski poslužitelj ne radi izravno s korisničkim prijenosnim medijima.

Ni u kojem slučaju, kada stvarate siguran sustav, ne biste trebali ostaviti poslužitelj aplikacija na terminalskom poslužitelju.

Ako aplikacijski poslužitelj radi na istom računalu kao i klijentske aplikacije, tada postoji dosta mogućnosti za ometanje njegovog normalnog rada. Ako je iz nekog razloga nemoguće odvojiti funkcije terminalskog poslužitelja i aplikacijskog poslužitelja, obratite posebnu pozornost na korisnički pristup datotekama koje koristi aplikacijski poslužitelj.

Potrebno je isključiti mogućnost pokretanja svih aplikacija osim 1C:Enterprise na terminalskom poslužitelju.

Ovo je jedna od najtežih želja za provedbu. Počnimo s činjenicom da je potrebno ispravno konfigurirati sigurnosnu politiku grupe u domeni. Svi "Administrativni predlošci" i "Politika ograničenja softvera" moraju biti ispravno konfigurirani. Da biste se testirali, provjerite jesu li barem sljedeće opcije onemogućene:

Složenost implementacije ovog zahtjeva često dovodi do mogućnosti pokretanja "dodatne" 1C sesije na terminalskom poslužitelju (čak i ako su druge aplikacije ograničene, tada je u načelu nemoguće zabraniti pokretanje 1C pomoću Windowsa).

Uzmite u obzir ograničenja uobičajenog dnevnika registracije (svi korisnici koriste program s jednog računala)

Očito, budući da korisnici otvaraju 1C u terminalskom načinu rada, tada će terminalski poslužitelj biti taj koji će biti zabilježen u dnevniku registracije. S kojeg se računala korisnik povezao, zapisnik registracije ne izvješćuje.

Terminalni poslužitelj - zaštita ili ranjivost?

Dakle, nakon razmatranja glavnih značajki sjevera terminala, možemo reći da potencijalno sjever terminala može pomoći u automatizaciji raspodjele računalnog opterećenja, ali je prilično teško izgraditi siguran sustav. Jedan od slučajeva kada je korištenje terminalskog poslužitelja najučinkovitije je pokretanje 1C bez Windows Explorera u načinu cijelog zaslona za korisnike s ograničenom funkcionalnošću i specijaliziranim sučeljem.

Rad na strani klijenta

Korištenje Internet Explorera (IE)

Jedan od uvjeta za normalan rad klijentskog dijela 1C je korištenje komponenti Internet Explorer. S ovim komponentama morate biti vrlo oprezni.

Pažnja! Prvo, ako je špijunski ili adware modul "prikačen" na IE, tada će se učitati čak i ako se bilo koja HTML datoteka pregleda u 1C. Do sada nisam vidio svjesno korištenje ove značajke, ali sam u jednoj od organizacija vidio učitani "špijunski" modul jedne od pornografskih mreža kada je pokrenut 1C (antivirusni program nije ažuriran, simptomi od kojih je pronađeno: prilikom postavljanja vatrozida, bilo je jasno da 1C pokušava da se port 80 poveže s pornografijom). Zapravo, ovo je još jedan argument u prilog činjenici da zaštita treba biti sveobuhvatna.

Pažnja! Drugo, 1C sustav omogućuje korištenje flash filmova, ActiveX objekata, VBScript-a u prikazanim HTML dokumentima, slanje podataka na Internet, čak i otvaranje PDF datoteka (!), Istina, u potonjem slučaju traži "otvori ili spremi" .. Općenito, što god vam srce poželi. Primjer ne sasvim razumne upotrebe ugrađene HTML mogućnosti pregleda i uređivanja:

Napravite novi HTML dokument (Datoteka -> Novo -> HTML dokument).
Idite na karticu "Tekst" praznog dokumenta.
Izbrišite tekst (potpuno).
Idite na karticu "Prikaz" ovog dokumenta
Koristeći drag-n-drop, premjestite datoteku s ekstenzijom SWF (to su datoteke flash filmova) iz otvorenog istraživača u prozor dokumenta, na primjer iz predmemorije preglednika, iako je to moguće uz FLASH igračku za zabavu.
Kako ljupko! Na 1C možete pokrenuti igračku!

Sa sigurnosne točke gledišta sustava, ovo je potpuno pogrešno. Do sada nisam vidio posebne napade na 1C kroz ovu ranjivost, ali najvjerojatnije će se pokazati da je to pitanje vremena i vrijednosti vaših podataka.

Postoje još neke manje točke koje se pojavljuju pri radu s poljem u HTML dokumentu, ali dvije navedene su glavne. Iako, ako ovim značajkama pristupite kreativno, možete organizirati uistinu nevjerojatne mogućnosti sučelja za rad s 1C.

Korištenje vanjskih izvješća i obrada.

Pažnja! Eksterna izvješća i obrada - s jedne strane, prikladan je način implementacije dodatnih obrazaca za ispis, regulatornog izvješćivanja, specijaliziranih izvješća, s druge strane, potencijalni način da se zaobiđu mnoga sigurnosna ograničenja sustava i poremete aplikacijski poslužitelj (na primjer, vidi gore u "Prolasku parametara"). 1C sustav ima poseban parametar u skupu prava uloge "Interaktivno otvaranje vanjske obrade", ali to ne otklanja problem u potpunosti - za cjelovito rješenje potrebno je suziti krug korisnika koji mogu upravljati eksterne ispisne forme, rutinska izvješća i druge redovite značajke standardnih rješenja implementiranih korištenjem vanjske obrade. Na primjer, prema zadanim postavkama u SCP-u, sve glavne korisničke uloge imaju mogućnost rada s direktorijem dodatnih obrazaca za ispis, a to je, zapravo, mogućnost korištenja bilo koje vanjske obrade.

Korištenje standardnih mehanizama standardnih rješenja i platforme (razmjena podataka)

Neki od standardnih mehanizama potencijalno su opasni, i to na prilično neočekivane načine.

Ispis popisa

Bilo koji popis (na primjer, imenik ili registar informacija) u sustavu može se ispisati ili spremiti u datoteku. Da biste to učinili, dovoljno je koristiti standardnu značajku dostupnu iz kontekstnog izbornika i izbornika "Radnje":

Imajte na umu da se gotovo sve što korisnik vidi na popisima može prikazati vanjske datoteke. Jedino što se može savjetovati je vođenje protokola za ispis dokumenata na poslužiteljima za ispis. Za posebno kritične oblike potrebno je konfigurirati akcijski panel povezan sa zaštićenim poljem tablice tako da mogućnost prikaza popisa nije dostupna s ove ploče te onemogućiti kontekstni izbornik (vidi sliku 6).

Razmjena podataka u distribuiranoj bazi podataka

Format razmjene podataka prilično je jednostavan i opisan je u dokumentaciji. Ako korisnik ima mogućnost zamijeniti nekoliko datoteka, može napraviti neovlaštene promjene u sustavu (iako je ovaj zadatak prilično naporan). Mogućnost stvaranja rubne baze podataka pri korištenju planova razmjene distribuiranih baza podataka ne bi trebala biti dostupna običnim operaterima.

Standardna razmjena XML podataka

U standardnoj razmjeni podataka, koja se koristi za razmjenu između tipičnih konfiguracija (na primjer, "Upravljanje trgovinom" i "Poduzetničko računovodstvo"), moguće je u pravilima razmjene odrediti rukovatelje događaja učitavanja i rasterećenja objekata. To se provodi dobivanjem rukovatelja iz datoteke i procedurom "Execute()" standardne obrade učitavanja i izbacivanja datoteke (procedura "Execute()" se pokreće na strani klijenta). Očito, nije teško stvoriti takvu lažnu datoteku za razmjenu koja će izvoditi zlonamjerne radnje. Za većinu korisničkih uloga generičkog rješenja dijeljenje je omogućeno prema zadanim postavkama.

Preporuka: ograničiti pristup XML-razmjeni za većinu korisnika (ostaviti samo administratorima informacijske sigurnosti). Čuvajte zapise pokretanja ove obrade, spremajući datoteku razmjene, na primjer, slanjem je email IS administrator prije preuzimanja.

Korištenje generičkih izvješća, posebno konzole za izvješćivanje

Drugi je problem zadani korisnički pristup generičkim izvješćima, posebno izvješću Konzole za izvješća. Ovo izvješće karakterizira činjenica da vam omogućuje izvršavanje gotovo svih zahtjeva za informacijsku sigurnost, pa čak i ako je sustav 1C prava (uključujući RLS) postavljen prilično kruto, omogućuje korisniku da dobije puno "nepotrebnih" informacija i prisiliti poslužitelj da izvrši takav zahtjev, koji će uzeti sve resurse sustava.

Korištenje načina rada preko cijelog zaslona (način radne površine)

Jedan od učinkovite načine Organizacija specijaliziranih sučelja s ograničenim pristupom funkcionalnosti programa je način rada na cijelom zaslonu glavnog (i možda jedinog) oblika koji koristi sučelje. Istodobno, nema problema s pristupačnošću, na primjer, izbornik "Datoteka", a sve radnje korisnika ograničene su mogućnostima obrasca koji se koristi. Za detalje pogledajte "Značajke implementacije desktop načina rada" na ITS disku.

Sigurnosna kopija

Sigurnosno kopiranje za verziju klijent-poslužitelj 1C može se napraviti na dva načina: prijenos podataka u datoteku s nastavkom dt i stvaranje sigurnosne kopije pomoću SQL-a. Prva metoda ima puno nedostataka: potreban je ekskluzivni pristup, sama izrada kopije traje mnogo dulje, u nekim slučajevima (ako je narušena struktura IS-a) stvaranje arhive je nemoguće, ali postoji jedna prednost - minimalna veličina arhiva. Za SQL sigurnosnu kopiju vrijedi upravo suprotno: kopija se stvara u pozadini pomoću SQL poslužitelja, zbog jednostavne strukture i nedostatka kompresije, ovo je vrlo brz proces, a sve dok je fizički integritet SQL baze podataka nije narušena, sigurnosna kopija se izvodi, ali je veličina kopije ista kao i prava veličina IB-a u proširenom stanju (komprimiranje se ne izvodi). Zbog dodatnih prednosti sustava sigurnosnog kopiranja MS SQL, svrsishodnije ga je koristiti (dopuštene su 3 vrste sigurnosne kopije: puna, diferencijalna, kopija dnevnika transakcija; moguće je kreirati redovito izvršavane zadatke; brzo se implementira sigurnosna kopija i backup sustav; implementirana mogućnost predviđanja veličine potrebnog prostora na disku itd.). Glavne točke organizacije sigurnosnog kopiranja u smislu sigurnosti sustava su:

Potreba za odabirom mjesta za pohranu sigurnosnih kopija na način da one nisu dostupne korisnicima.
Potreba pohranjivanja sigurnosnih kopija na fizičkoj udaljenosti od MS SQL poslužitelja (u slučaju prirodnih katastrofa, požara, napada itd.)
Mogućnost davanja prava za pokretanje sigurnosnog kopiranja korisniku koji nema pristup sigurnosnom kopiranju.

Za više informacija pogledajte MS SQL dokumentaciju.

Šifriranje podataka

Za zaštitu podataka od neovlaštenog pristupa često se koriste različiti kriptografski alati (softverski i hardverski), no njihova svrsishodnost uvelike ovisi o ispravnoj primjeni i cjelokupnoj sigurnosti sustava. Razmotrit ćemo šifriranje podataka u različitim fazama prijenosa i pohrane podataka korištenjem najčešćih sredstava i glavne pogreške u dizajnu sustava korištenjem kriptografskih alata.

Postoji nekoliko glavnih faza obrade informacija koje se mogu zaštititi:

Prijenos podataka između klijentskog dijela sustava i aplikacijskog poslužitelja
Prijenos podataka između poslužitelja aplikacija i MS SQL Servera
Podaci pohranjeni na MS SQL Server (datoteke s podacima na fizičkom disku)
Šifriranje podataka pohranjenih u IB
Vanjski podaci (u vezi s informacijskom sigurnošću)

Za podatke pohranjene na strani klijenta i na aplikacijskom poslužitelju (spremljene korisničke postavke, IB lista, itd.), enkripcija je opravdana samo u vrlo rijetkim slučajevima i stoga se ovdje ne razmatra. Kada koristite kriptografske alate, ne treba zaboraviti da njihova upotreba može značajno smanjiti performanse sustava u cjelini.

Opće informacije o kriptografskoj zaštiti mrežnih veza pri korištenju TCP/IP protokola.

Sve bez zaštite mrežne veze podložni neovlaštenom nadzoru i pristupu. Da biste ih zaštitili, možete koristiti šifriranje podataka na razini mrežnog protokola. Za šifriranje podataka koji se prenose na lokalnoj mreži najčešće se koriste IPSec alati koje osigurava operativni sustav.

IPSec alati pružaju enkripciju prenesenih podataka pomoću DES i 3DES algoritama, kao i provjeru integriteta pomoću MD5 ili SHA1 hash funkcija. IPSec može raditi u dva načina: transportni i tunelski. Prijenosni način je bolji za osiguranje veza na lokalnoj mreži. Tunelski način rada može se koristiti za organiziranje VPN veza između zasebnih segmenata mreže ili za zaštitu udaljene veze s lokalnom mrežom preko otvorenih podatkovnih kanala.

Glavne prednosti ovog pristupa su:

Sposobnost centralnog upravljanja sigurnošću pomoću alata Active Directory.
Mogućnost isključivanja neovlaštenih povezivanja na aplikacijski poslužitelj i MS SQL poslužitelj (na primjer, moguće je zaštititi od neovlaštenog dodavanja informacijske sigurnosti na poslužitelju aplikacija).
Iznimka "slušanje" mrežnog prometa.
Nema potrebe za mijenjanjem ponašanja aplikacijskih programa (u ovom slučaju, 1C).
Standard takvog rješenja.

Međutim, ovaj pristup ima ograničenja i nedostatke:

IPSec ne štiti podatke od neovlaštenog pristupa i prisluškivanja izravno na izvornom i odredišnom računalu.
Količina podataka koji se prenose preko mreže nešto je veća nego bez korištenja IPSec-a.
Kada koristite IPSec, nekoliko više opterećenja na središnji procesor.

Detaljan opis implementacije IPSec je izvan dosega ovog članka i zahtijeva razumijevanje osnovnih principa IP protokola. Da biste ispravno konfigurirali sigurnost veze, pročitajte odgovarajuću dokumentaciju.

Posebno je potrebno spomenuti nekoliko aspekata licencnog ugovora s 1C-om prilikom organiziranja VPN veza. Činjenica je da je, unatoč nepostojanju tehničkih ograničenja, pri povezivanju nekoliko segmenata lokalne mreže ili udaljenom pristupu jednog računala na lokalnu mrežu obično potrebno nekoliko osnovnih zaliha.

Šifriranje podataka tijekom prijenosa između klijentskog dijela sustava i aplikacijskog poslužitelja.

Osim enkripcije na razini mrežni protokol, moguće je šifriranje podataka na razini COM+ protokola, što se spominje u članku "Reguliranje pristupa korisnika infobazi u verziji klijent-poslužitelj" ITS-a. Da biste ga implementirali, trebate postaviti "Usluge komponenti" za aplikaciju 1CV8 da postavite razinu provjere autentičnosti za pozive na "Privatnost paketa". Kada je ovaj način postavljen, paket je autentificiran i šifriran, uključujući podatke i identitet i potpis pošiljatelja.

Šifriranje podataka tijekom prijenosa između aplikacijskog poslužitelja i MS SQL Servera

MS SQL Server nudi sljedeće alate za šifriranje podataka:

Moguće je koristiti Secure Sockets Layer (SSL) prilikom prijenosa podataka između poslužitelja aplikacija i MS SQL Servera.
Kada koristite višeprotokolnu mrežnu knjižnicu, šifriranje podataka koristi se na razini RPC-a. Ovo je potencijalno slabija enkripcija nego kod SSL-a.
Ako se koristi protokol za razmjenu Shared Memory (to se događa ako se aplikacijski poslužitelj i MS SQL Server nalaze na istom računalu), tada se šifriranje ni u kojem slučaju ne koristi.

Kako biste postavili potrebu za šifriranjem svih prenesenih podataka za određeni MS SQL poslužitelj, koristite uslužni program "Server Network Utility". Pokrenite ga i na kartici "Općenito" označite okvir "Prisilno šifriranje protokola". Metoda šifriranja odabire se ovisno o onoj koju koristi klijentska aplikacija (tj. 1C aplikacijski poslužitelj). Da biste koristili SSL, morate ispravno konfigurirati uslugu izdavanja certifikata na svojoj mreži.

Kako biste postavili potrebu za šifriranjem svih prenesenih podataka za određeni poslužitelj aplikacija, trebate koristiti uslužni program "Client Network Utility" (obično se nalazi u "C:\WINNT\system32\cliconfg.exe"). Kao iu prethodnom slučaju, na kartici "Općenito" označite okvir "Prisilno šifriranje protokola".

Treba imati na umu da korištenje enkripcije u ovom slučaju može imati značajan utjecaj na performanse sustava, posebno kada se koriste upiti koji vraćaju velike količine informacija.

Kako bismo potpunije osigurali vezu između poslužitelja aplikacija i MS SQL Servera pri korištenju TCP/IP protokola, možemo preporučiti nekoliko promjena zadanih postavki.

Prvo, možete postaviti priključak koji nije standardni (port 1433 se koristi prema zadanim postavkama). Ako odlučite koristiti nestandardni TCP port za razmjenu podataka, imajte na umu sljedeće:

MS SQL Server i Application Server moraju koristiti isti port.
Kada koristite vatrozide, ovaj priključak mora biti dopušten.
Ne možete postaviti port koji mogu koristiti druge aplikacije na MS SQL Serveru. Za referencu, pogledajte http://www.ise.edu/in-notes/iana/assignments/port-numbers (adresa preuzeta iz SQL Server Books Online).
Kada koristite više instanci usluge MS SQL Server, svakako pročitajte MS SQL dokumentaciju (odjeljak "Konfiguriranje mrežnih veza") za konfiguraciju.

Drugo, u postavkama TCP/IP protokola na MS SQL poslužitelju možete postaviti potvrdni okvir "Sakrij poslužitelj" koji zabranjuje odgovore na zahtjeve za emitiranje na ovu instancu usluge MS SQL Server.

Šifriranje MS SQL podataka pohranjenih na disku

Postoji prilično velik izbor softvera i hardvera za šifriranje podataka koji se nalaze na lokalnom disku (to je uobičajena sposobnost Windowsa da koristi EFS, te korištenje eToken ključeva i programa trećih strana kao što su Jetico Bestcrypt ili PGPDisk). Jedan od glavnih zadataka koji obavljaju ovi alati je zaštita podataka u slučaju gubitka medija (na primjer, kada je poslužitelj ukraden). Posebno treba napomenuti da Microsoft ne preporuča pohranjivanje MS SQL baza podataka na kriptirane medije, a to je sasvim opravdano. Glavni problem u ovom slučaju je značajan pad performansi i mogući problemi pouzdanost kvara. Drugi čimbenik koji otežava život administratora sustava je potreba da se osigura da su sve datoteke baze podataka dostupne u trenutku prvog pristupa njima od strane MS SQL servisa (tj. poželjno je isključiti interaktivne radnje prilikom povezivanja šifriranog mediji).

Kako biste izbjegli zamjetan pad performansi sustava, možete koristiti sposobnost MS SQL-a za kreiranje baza podataka u nekoliko datoteka. Naravno, u ovom slučaju bazu podataka MS SQL ne bi trebao kreirati 1C poslužitelj prilikom izrade baze podataka, već bi se trebala kreirati zasebno. Primjer skripte u TSQL-u s komentarima je dat u nastavku:

USEmaster
IĆI
-- Napravite bazu podataka SomeData,
STVORI BAZU PODATAKA SomeData
-- čiji se cijeli podaci nalaze u PRIMARNOJ grupi datoteka.
NA OSNOVNOM
-- Glavna datoteka podataka nalazi se na šifriranom mediju ( logički pogon E :)
-- i ima početnu veličinu od 100 MB, može se automatski povećati na 200 MB s
-- korak 20 Mb
(NAME = Neki podaci1,
FILENAME = "E:\SomeData1.mdf",
VELIČINA = 100MB,
MAXSIZE=200
FILEGROWTH=2),
-- Druga podatkovna datoteka nalazi se na nekriptiranom mediju (logički pogon C:)
-- i ima početnu veličinu od 100 MB, može se automatski povećati do granice
-- prostor na disku u koracima od 5% trenutne veličine datoteke (zaokruženo na 64 KB)
(NAME = SomeData2,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
VELIČINA = 100MB,
MAXSIZE=NEOGRANIČENO,
RAST DATOTEKA = 5%)
PRIJAVITI SE
-- Iako bi se dnevnik transakcija također mogao podijeliti na dijelove, to se ne smije činiti,
-- jer ova se datoteka mijenja mnogo češće i redovito se čisti (na primjer, kada
-- stvaranje sigurnosne kopije baze podataka).
(NAME = SomeDatalog,
FILENAME = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
VELIČINA = 10MB,
MAXSIZE=NEOGRANIČENO,
FILEGROWTH=10)
IĆI
-- Bolje je odmah dati vlasništvo nad bazom podataka korisniku u čije ime
-- 1C će biti spojen. Da bismo to učinili, moramo deklarirati trenutnu bazu
- upravo stvorena
KORISTITE SomeData
IĆI
-- i pokrenite sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Mala digresija o automatskom rastu veličine podatkovne datoteke. Prema zadanim postavkama, za kreirane baze podataka, veličine datoteka povećavaju se u koracima od 10% trenutne veličine datoteke. Ovo je savršeno prihvatljivo rješenje za male baze podataka, ali ne baš dobro za velike: s veličinom baze podataka od, na primjer, 20 GB, datoteka bi se trebala povećati za 2 GB odjednom. Iako će se ovaj događaj događati rijetko, može trajati nekoliko desetaka sekundi (sve ostale transakcije su zapravo mirne tijekom tog vremena), što, ako se dogodi tijekom aktivnog rada s bazom podataka, može uzrokovati neke kvarove. Druga negativna posljedica proporcionalnog povećanja, koja se javlja kada je prostor na disku gotovo potpuno popunjen, je vjerojatnost preranog kvara zbog nedostatka prostora. slobodan prostor. Na primjer, ako je particija diska od 40 GB potpuno dodijeljena za jednu bazu podataka (točnije, za jednu datoteku ove baze podataka), tada je kritična veličina datoteke baze podataka pri kojoj je potrebno hitno (vrlo hitno, do prekida). normalnog rada korisnika) reorganizirati pohranu informacija je podatkovna datoteka veličine 35 GB. S veličinom povećanja postavljenom na 10-20 MB, možete nastaviti s radom dok ne dosegnete 39 GB.

Stoga, iako gornji popis navodi povećanje veličine jedne od datoteka baze podataka u koracima od 5%, za velike veličine baze podataka bolje je postaviti fiksni prirast od 10-20 MB. Prilikom postavljanja vrijednosti koraka rasta za veličinu datoteka baze podataka, potrebno je uzeti u obzir da prije nego što jedna od datoteka u grupi datoteka dosegne maksimalnu veličinu, vrijedi pravilo: datoteke jedne grupe datoteka rastu sve u isto vrijeme, kada su svi potpuno ispunjeni. Dakle, u gornjem primjeru, kada datoteka SomeData1.mdf dosegne svoju maksimalnu veličinu od 200 MB, datoteka SomeData2.ndf bit će velika oko 1,1 GB.

Nakon stvaranja takve baze podataka, čak i ako njezine nezaštićene datoteke SomeData2.ndf i SomeData.ldf postanu dostupne napadaču, bit će iznimno teško vratiti pravo stanje baze podataka - podatke (uključujući informacije o logičkoj strukturi baze podataka ) bit će razbacane po nekoliko datoteka, štoviše, ključne informacije (o tome, na primjer, koje datoteke čine ovu bazu podataka) bit će u šifriranoj datoteci.

Naravno, ako se datoteke baze podataka pohranjuju pomoću kriptografskih sredstava, tada sigurnosne kopije (barem ovih datoteka) ne bi trebale biti napravljene na nekriptiranim medijima. Kako biste osigurali sigurnosnu kopiju pojedinačnih datoteka baze podataka, koristite odgovarajuću sintaksu za naredbu "BACKUP DATABASE". Napominjemo da unatoč mogućnosti zaštite sigurnosne kopije baze podataka lozinkom (opcije "PASSWORD = " i "MEDIAPASSWORD = " naredbe "BACKUP DATABASE"), takva sigurnosna kopija nije šifrirana!

Enkripcija poslužiteljskih i klijentskih podataka pohranjenih na diskovima

U većini slučajeva pohranjivanje datoteka koje koristi 1C:Enterprise (klijentski dio i aplikacijski poslužitelj) na kriptirani medij ne može se smatrati opravdanim zbog nerazumno visokih troškova, međutim, ako postoji takva potreba, imajte na umu da aplikacijski poslužitelj i klijentski dio aplikacije vrlo često stvaraju privremene datoteke. Često te datoteke mogu ostati nakon završetka aplikacije, a gotovo je nemoguće jamčiti njihovo uklanjanje pomoću 1C alata. Stoga se pojavljuje šifriranje direktorija koji se koristi za privremene datoteke u 1C ili ne pohranjivanje na disk pomoću RAM-pogona (posljednja opcija nije uvijek moguća zbog veličine generiranih datoteka i zahtjeva za količinu RAM-a same aplikacije 1C:Enterprise).

Šifriranje podataka s ugrađenim 1C alatima.

Redovne mogućnosti korištenja enkripcije u 1C svode se na korištenje objekata za rad sa Zip datotekama s parametrima šifriranja. Dostupni su sljedeći načini šifriranja: AES algoritam s ključem od 128, 192 ili 256 bita i zastarjeli algoritam izvorno korišten u Zip arhiveru. Zip datoteke šifrirane AES-om nisu čitljive mnogim arhivarima (WinRAR, 7zip). Da biste generirali datoteku koja sadrži šifrirane podatke, morate navesti lozinku i algoritam šifriranja. Najjednostavniji primjer funkcije enkripcije-dešifriranja temeljene na ovoj značajki dane su u nastavku:

Funkcija EncryptData(Podaci, Lozinka, Metoda šifriranja = Nedefinirano) Izvoz

// Zapišite podatke u privremenu datoteku. Zapravo, ne mogu se svi podaci spremiti na ovaj način.
ValueToFile(TempFileName, Data);

// Upiši privremene podatke u arhivu
Zip = Novi ZipFileEntry(TempArchiveFileName, Password, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Napiši();

// Čitanje podataka iz primljene arhive u radna memorija
EncryptedData = NewValueStorage(NewBinaryData(TempArchiveFileName));

// Privremene datoteke - brisanje

EndFunction Funkcija DecryptData(EncryptedData, Password) Izvoz

// Pažnja! Ne prati se ispravnost proslijeđenih parametara

// Upisuje proslijeđenu vrijednost u datoteku
TempArchiveFileName = GetTemporalFileName("zip");
BinarniArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(TempArchiveFileName);

// Ekstrahirajte prvu datoteku novonapisane arhive
TempFileName = GetTempFileName();
Zip = NewReadZipFile(TempArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, FilePath Recovery ModeZIP.Don'tRecover);

// Pročitajte napisanu datoteku
Podaci = ValueFromFile(TempFileName + "\" + Zip.Elements.Name);

// Izbriši privremene datoteke
DeleteFiles(TempFileName);
DeleteFiles(TempArchiveFileName);

Podaci o povratu;

Završne funkcije

Naravno, ova metoda se ne može nazvati idealnom - podaci se zapisuju u privremenu mapu u čistom tekstu, izvedba metode, iskreno, nije nigdje lošija, pohrana u bazi podataka zahtijeva izuzetno veliku količinu prostora, ali ovo je jedina metoda koja se temelji samo na ugrađenim mehanizmima platforme. Osim toga, ima prednost u odnosu na mnoge druge metode - ova metoda obavlja pakiranje podataka istovremeno s enkripcijom. Ako želite implementirati enkripciju bez nedostataka koje ova metoda ima, tada ih morate implementirati u vanjsku komponentu ili se pozivati na postojeće biblioteke kroz stvaranje COM objekata, na primjer, korištenjem Microsoft CryptoAPI. Kao primjer dat ćemo funkcije šifriranja/dešifriranja niza na temelju primljene lozinke.

Funkcija EncryptStringDES (nekriptirani niz, lozinka)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Ova konstanta je iz CryptoAPI-ja

EncryptionMechanism.Content = PlainString;
EncryptionMechanism.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

Vrati EncryptedString;

EndFunction // EncryptStringDES()

Funkcija DecryptStringDES(EncryptedString, Password)

//Pažnja! Parametri se ne provjeravaju!

EncryptionMechanism = Novi COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Lozinka);
Pokušaj
EncryptionMechanism.Decrypt(EncryptedString);
Iznimka
// Netočna zaporka!;
Vrati nedefinirano;
Kraj pokušaja;

Vrati EncryptionMechanism.Content;

EndFunction // DecodeStringDES()

Imajte na umu da će prosljeđivanje prazne vrijednosti kao niza ili lozinke ovim funkcijama generirati poruku o pogrešci. Niz dobiven ovim postupkom šifriranja nešto je duži od izvornika. Specifičnosti ove enkripcije su takve da ako dvaput šifrirate niz, rezultirajući nizovi NEĆE biti identični.

Glavne pogreške pri korištenju kriptografskih alata.

Pri korištenju kriptografskih alata često se rade iste pogreške:

Podcjenjivanje degradacije performansi pri korištenju kriptografije.

Kriptografija je zadatak koji zahtijeva prilično velik broj izračuna (osobito za algoritme kao što su DES, 3DES, GOST, PGP). Čak i u slučaju korištenja visokoučinkovitih i optimiziranih algoritama (RC5, RC6, AES), nema bijega od nepotrebnog prijenosa podataka u memoriji i računalne obrade. A to gotovo negira mogućnosti mnogih komponenti poslužitelja (RAID polja, mrežni adapteri). Kada se za šifriranje koristi hardversko šifriranje ili izvođenje hardverskog ključa, postoji dodatno moguće usko grlo u izvedbi: brzina prijenosa podataka između sekundarnog uređaja i memorije (a izvedba takvog uređaja možda neće igrati odlučujuću ulogu). Pri korištenju enkripcije male količine podataka (primjerice mail poruke) povećanje računskog opterećenja sustava nije toliko primjetno, ali u slučaju totalne enkripcije svega i svačega to može uvelike utjecati na performanse sustav u cjelini.

podcjenjivanje moderne mogućnosti o odabiru lozinki i ključeva.

Trenutno su mogućnosti tehnologije takve da ključ od 40-48 bita može odabrati mala organizacija, a ključ od 56-64 bita velika organizacija. Oni. Moraju se koristiti algoritmi koji koriste ključ od najmanje 96 ili 128 bita. Ali većina ključeva se generira pomoću hash algoritama (SHA-1, itd.) na temelju lozinki koje je unio korisnik. U ovom slučaju, 1024-bitni ključ se također možda neće spremiti. Prvo, često se koristi lozinka koju je lako pogoditi. Čimbenici koji olakšavaju odabir su: korištenje samo jednog velikog slova; korištenje riječi, imena i izraza u lozinkama; korištenje poznatih datuma, rođendana itd.; korištenje "obrazaca" prilikom generiranja lozinki (na primjer, 3 slova, zatim 2 broja, zatim 3 slova u cijeloj organizaciji). Dobra lozinka trebala bi biti prilično nasumičan slijed velikih i velikih slova, brojeva i interpunkcije. Lozinke unesene s tipkovnice do 7-8 znakova, čak i ako se poštuju ova pravila, mogu se pogoditi u razumnom vremenu, pa je bolje da lozinka ima najmanje 11-13 znakova. Idealno rješenje je odbiti generiranje ključa lozinkom, na primjer, korištenjem raznih pametnih kartica i sl., ali je u tom slučaju potrebno predvidjeti mogućnost zaštite od gubitka nositelja ključa za šifriranje.

Nesigurno pohranjivanje ključeva i lozinki.

Tipični primjeri ove greške su:

duge i složene lozinke ispisane na naljepnicama zalijepljenim na korisnikov monitor.
pohranjivanje svih lozinki u datoteci koja nije zaštićena (ili je zaštićena puno slabija od samog sustava)
pohranjivanje elektroničkih ključeva u javnoj domeni.
čest prijenos elektroničkih ključeva između korisnika.

Zašto praviti blindirana vrata ako ključ od njih leži ispod tepiha pored vrata?

Prijenos početno šifriranih podataka u nesigurno okruženje.

Prilikom organiziranja sigurnosnog sustava pobrinite se da on ispunjava svoju svrhu. Na primjer, naišao sam na situaciju (koja nije vezana za 1C) kada je početno šifrirana datoteka, kada je program radio u otvorenom obliku, stavljena u privremenu mapu, odakle se mogla sigurno čitati. Vrlo često se sigurnosne kopije šifriranih podataka u čistom tekstu nalaze negdje "u blizini" ovih podataka.

Zloupotreba kriptografskih alata

Kada su podaci u prijenosu šifrirani, ne može se očekivati da podaci neće biti dostupni na mjestima gdje se koriste. Na primjer, usluge IPSec ne čine ništa kako bi spriječile sloj aplikacije da "sluša" mrežni promet na strani aplikacijskog poslužitelja.

Stoga, kako bi se izbjegle pogreške pri implementaciji kriptografskih sustava, potrebno je (u najmanju ruku) učiniti sljedeće prije njegove implementacije.

Saznati:
- Što treba zaštititi?
- Koju metodu zaštite treba koristiti?
- Koje dijelove sustava treba osigurati?
- Tko će upravljati pristupom?
- Hoće li šifriranje funkcionirati na svim pravim područjima?
Odlučite gdje se informacije pohranjuju, kako se šalju putem mreže i računala s kojih će se informacijama pristupati. To će pružiti informacije o brzini, kapacitetu i korištenju mreže prije implementacije sustava, što je korisno za optimizaciju performansi.
Procijenite ranjivost sustava za različite vrste napadi.
Razviti i dokumentirati plan sigurnosti sustava.
Ocijeniti ekonomsku učinkovitost (opravdanost) korištenja sustava.

Zaključak

Naravno, u površnom pregledu nemoguće je naznačiti sve aspekte koji se odnose na sigurnost u 1C, ali izvučemo neke preliminarne zaključke. Naravno, ova platforma se ne može nazvati idealnom - ona, kao i mnoge druge, ima svoje probleme s organiziranjem sigurnog sustava. Ali to ni na koji način ne znači da se ovi problemi ne mogu zaobići, dapače, gotovo svi nedostaci mogu se otkloniti pravilnim razvojem, implementacijom i korištenjem sustava. Većina problema nastaje zbog nedovoljne razvijenosti specifičnog aplikativnog rješenja i okoline za njegovo izvršavanje. Primjerice, tipična rješenja bez značajnih promjena jednostavno ne podrazumijevaju stvaranje dovoljno sigurnog sustava.

Društvo jedinstvena je usluga za kupce, programere, trgovce i pridružene partnere. Osim toga, ovo je jedna od najboljih internetskih trgovina softvera u Rusiji, Ukrajini, Kazahstanu, koja kupcima nudi široku paletu proizvoda, mnoge načine plaćanja, brzu (često trenutnu) obradu narudžbi, praćenje procesa ispunjenja narudžbe u osobnom dijelu.

"Informix® DataBlade™ API Programmer's Guide" dostupan je za preuzimanje na . Odjeljak "Upravljanje prostorom u stogu" opisuje stvaranje korisnički definiranih funkcija (UDR). Ovaj članak pruža dodatne informacije i savjete za otklanjanje pogrešaka.

Sljedeće informacije su važeće bez obzira radi li se UDR na korisnički definiranom virtualnom procesoru (VP) ili na VP CPU-u. Stog niti može se premjestiti u korisnički definirani virtualni procesor neposredno prije nego što se UDR izvrši.

Koja je veličina steka dodijeljena za UDR?

Veličina steka dostupna za UDR ovisi o tome kako je UDR stvoren:

s STACK modifikatorom, koji omogućuje UDR-u da koristi svoj namjenski stog,

bez modifikatora STACK, što znači da će UDR dijeliti stog dodijeljen poslužitelju s niti koja zahtijeva. Veličina stoga u ovom slučaju bit će određena vrijednošću parametra STACKSIZE u konfiguracijskoj datoteci onconfig.

STACK modifikator

Izrazi CREATE PROCEDURE ili CREATE FUNCTION imaju izborni STACK modifikator koji vam omogućuje da odredite količinu prostora stoga, u bajtovima, koja je potrebna za izvršenje UDR-a.

Ako koristite modifikator STACK kada kreirate UDR, poslužitelj će dodijeliti i osloboditi prostor stog svaki put kada se UDR izvrši. Stvarna dostupna veličina je STACK vrijednost u bajtovima umanjena za neke dodatne troškove ovisno o broju argumenata funkcije.

Ako je vrijednost STACK manja od vrijednosti parametra STACKSIZE u onconfig datoteci (pogledajte sljedeći odjeljak), tada će se veličina snopa dodijeljenog za UDR automatski zaokružiti na vrijednost STACKSIZE.

STACKSIZE konfiguracijski parametar

Konfiguracijska datoteka onconfig uključuje opciju STACKSIZE koja specificira zadanu veličinu stoga za korisničke niti.

Ako ne navedete STACK prilikom kreiranja UDR-a, poslužitelj ne dodjeljuje dodatni prostor stog za izvršenje tog UDR-a. Umjesto toga, UDR koristi prostor stog koji je dodijeljen za izvršavanje zahtjeva. Dostupna veličina stoga ovisit će o troškovima izvršavanja funkcije na SQL razini.

Stog za nit se dodjeljuje jednom za određenu nit koja izvršava zahtjev. Izvedba je bolja kada UDR dijeli jedan stog s niti, jer poslužitelj ne troši resurse na dodjeljivanje dodatnog stoga za svaki poziv UDR-u. S druge strane, ako se veličina UDR stoga približi vrijednosti STACKSIZE, to bi moglo uzrokovati prelijevanje stoga prilikom pozivanja funkcije kao dijela složenog upita (u tom slučaju bi UDR-u bilo dostupno manje prostora za izvođenje).

Imajte na umu da ne biste trebali postaviti STACKSIZE previsoko, jer će to utjecati na sve korisničke niti.

Kada trebate upravljati veličinom hrpe?

Y Morate upravljati prostorom stoga ako UDR upućuje rekurzivne pozive ili ako UDR zahtijeva više prostora u stogu nego što je prema zadanim postavkama dostupno na stogu niti zahtjeva (STACKSIZE).

Postoje dva načina da povećate stog za izvođenje UDR-a:

Navedite modifikator STACK kada kreirate UDR.

Koristite mi_call() za upućivanje rekurzivnih poziva (pogledajte Informix DataBlade API Programer's Guide za primjer).

Ako ne navedete veličinu preko STACK-a, i ako ne koristite mi_call() za povećanje trenutnog stoga, i ako UDR učini nešto što zahtijeva puno prostora na stogu, onda će to uzrokovati prelijevanje steka.

Imajte na umu da neke funkcije poput mi_* dodaju novi segment steka za vlastito izvršenje. Ovi segmenti se oslobađaju kada se vraćaju pozivatelju funkcije UDR.

Što učiniti ako nešto krene po zlu?

Praćenje korištenja steka

Svrha promatranja je identificirati određeni UDR koji uzrokuje prelijevanje steka tako da možete promijeniti vrijednost STACK posebno za taj određeni UDR.

Nadgledanje korištenja stoga pomoću "onstat -g sts"

Nadgledajte sesiju koja pokreće SQL upit s "onstat -g ses session_id"

Nakon identifikacije SQL upit, koji završava preljevom steka, trebali biste odrediti korištenje stoga odvojenim izvršavanjem zahtjeva s UDR-ovima koji su dio izvornog zahtjeva.

Možete dinamički postaviti STACK vrijednost za UDR. Na primjer:

promijeniti funkciju MyFoo (lvarchar,lvarchar) s (dodaj stack=131072);

Nakon promjene vrijednosti STACK, trebali biste testirati izvorni zahtjev kako biste bili sigurni da je sada stabilan.

Povećanje STACKSIZE

Alternativno, pokušajte povećati vrijednost STACKSIZE. Provjerite je li to riješilo problem. (Ne zaboravite vratiti staru vrijednost kasnije).

Ako povećanje STACKSIZE ne pomogne, problem je najvjerojatnije oštećenje memorije. Evo nekoliko prijedloga:

Omogućite šaranje memorije i provjerite memorijske skupine. Odjeljak "Problemi s otklanjanjem pogrešaka" u članku Dodjela memorije za UDR-ove objašnjava kako to učiniti.

Ponovno razmotrite korištenje mi_lvarchar . Posebnu pozornost treba posvetiti mjestima gdje se mi_lvarchar prosljeđuje funkciji koja očekuje niz s nultom završetkom kao argument.

Smanjite broj CPU (ili korisnika) VP-a na jedan da biste brže reproducirali problem.

mi_print_stack() -- Solaris

Informix Dynamic Server za OC Solaris uključuje funkciju mi_print_stack() koja se može pozvati u UDR-u. Prema zadanim postavkama, ova funkcija sprema okvir stog u sljedeću datoteku:

/tmp/default.stog

Ne možete promijeniti naziv izlazne datoteke, ali možete promijeniti njenu lokaciju promjenom vrijednosti DBTEMP varijable okoline. Provjerite može li korisnik informix pisati u direktorij $DBTEMP. Sve pogreške koje se pojave tijekom izvršavanja mi_print_stack() ispisuju se na $MSGPATH.

Ova je značajka dostupna samo za OC Solaris.

Glosar

Izrazi i kratice korištene u ovom članku:

UDR	Korisnički definirana rutina
VP	Virtualni procesor

14.04.2016 Verzija 3.22 Promijenjeno sučelje, ispravljene greške pri prijenosu registara, promijenjen redoslijed prijenosa organizacije i računovodstvene politike. Platforma 8.3.7.2027 BP 3.0.43.174
17.03.2016. Verzija 3.24 Ispravljene greške. Platforma 8.3.8.1747 BP 3.0.43.241
16.06.2016 Verzija 3.26 Ispravljene greške. Platforma 8.3.8.2088 BP 3.0.44.123
16.10.2016. Verzija 4.0.1.2 Popravljen prijenos pohrane vrijednosti, promijenjen prijenos računovodstvene politike za izdanja 3.44.*. Platforma 8.3.9.1818 BP 3.0.44.164.
19.04.2017 Verzija 4.0.2.7 Promijenjen algoritam za prijenos registara povezanih s imenicima, ispravljene greške, ispravljen prijenos s prepisivanjem veza.
29.05.2017 Verzija 4.0.4.5 Promijenjen prijenos kretanja, dodan pregled kretanja prenesenih dokumenata, nešto drugo....
30.05.2017. Verzija 4.0.4.6 Ispravljena je pogreška prilikom popunjavanja popisa imenika koji postoje u izvoru (hvala shoy)
17.06.2017. Verzija 4.0.5.1 Promijenjen algoritam prijenosa pokreta.
19.07.2017. Verzija 4.0.5.4 Promijenjen prijenos CI-a iz BP 2.0. Neočekivano, došlo je do prijenosa iz Smilegm UT 10.3, u ovoj verziji prijenos je malo ispravljen za ovu situaciju)))
08/10/2017 Verzija 4.0.5.5 Ispravljene pogreške pri prelasku s BP 2.0
19.09.2017. Verzija 4.4.5.7 Provjera fiksne veze za 3.0.52.*
28.11.2017. Verzija 4.4.5.9 Ispravljene greške
12/06/2017 Verzija 5.2.0.4 Algoritam za traženje poveznica je redizajniran. Dodane su procedure prijenosa iz BP 1.6, nema više krutog vezanja za BP - možete ga sigurno koristiti za prijenos podataka "gotovo" identičnih konfiguracija. Pokušat ću ispraviti sve komentare što je prije moguće.
12/08/2017 Verzija 5.2.1.3 Dodan algoritam za prijenos obračuna plaća s BP.2.0 na BP 3.0. Uključene promjene za dijeljenje između istih konfiguracija.
19.12.2017. Verzija 5.2.2.2 Ispravljen prijenos samostalnih registara podataka za referentne knjige koje su u dimenzijama ovih registara.

12/06/2017 Nova verzija obrade 5.2.0.4. Od značajnih promjena je mogućnost prelaska s BP 1.6 na BP 3.0. Glavna promjena je upravljanje pretraživanjem poveznica imenika - u prethodnim verzijama pretraživanje je bilo po GUID-u, au ovoj verziji možete omogućiti pretraživanje "Prema detaljima":

17.01.2018 Verzija 5.2.2.3 Ispravljeno - uočene pogreške u podređenim imenicima i registrima periodičnih informacija.

19.07.2018. Verzija 5.2.2.8 Ispravljene greške.

gdje možete postaviti detalje pretraživanja za bilo koji imenik. Sam je ovaj način "nastao" na brojne zahtjeve radnika, za slučaj kada je potrebna razmjena u već postojećoj bazi podataka u kojoj već postoje podaci (npr. za spajanje računovodstva za dvije organizacije u jednu bazu podataka).

21.12.2015. Objavljena je platforma 8.3.7.1805 i BP 3.0.43.29, odnosno nova verzija obrada 3.1:-) (opis u nastavku). Nova funkcionalnost- mogućnost usporedbe stanja i prometa između dvije baze podataka BP (za sve račune, ako se kontni planovi podudaraju, ili za pojedinačne računske račune koji se podudaraju, sa ili bez analitike).
03.01.2016. Verzija 3.5 - mehanizam povezivanja s izvornom bazom podataka je promijenjen - usklađena s BSP 2.3.2.43. Ispravljene manje greške. Platforma 8.3.7.1845, BP 3.0.43.50
16.02.2016. Verzija 3.6 - Dodana je oznaka "Postavi ručni ispravak" za dokumente koji se prenose pokretima. Prijenos kretanja fiksni - dokumenti s datumom manjim od početka razdoblja prenose se bez kretanja. Platforma 8.3.7.1917, BP 3.0.43.116
22.03.2016. Verzija 3.10 - Dodana je zastavica "Uvijek prepiši veze" za obvezno prepisivanje referentnih objekata (brzina prijenosa je značajno smanjena, ali ponekad neophodna). Dodana je kartica "Priprema" gdje možete postaviti korespondenciju između izvornih i odredišnih kontnih planova (na istoj razini kao i šifre računa) i prijenos konstanti. Platforma 8.3.7.1970, BP 3.0.43.148

03.04.2016 Verzija 3.11 Promijenjeno je popunjavanje popisa dokumenata koji postoje u izvoru: popunjavan je prema kretanju po kontnom planu, jednostavno putem linkova za razdoblje, kao na //site/ javno/509628/

Obrada je dizajnirana za prijenos podataka za bilo koje razdoblje slično kao "Upload MXL upload" s ITS-om, ali bez upotrebe XML, JSON, itd. međudatoteka - razmjena iz baze podataka u bazu podataka putem COM-a. U verzijama starijim od 3.10 koristi se veza prema algoritmu iz BSP-a koji omogućuje registraciju comcntr.dll (ako to OS "dopušta"), kao i razne poruke kada je nemoguće uspostaviti vezu , na primjer - " Baza podataka je u procesu ažuriranja" itd. Dodana provjera izbora prijamnika kao izvora informacijske sigurnosti - izdaje se upozorenje.

Može se koristiti za:

1. Prijenos regulatornih i referentnih informacija (RMI) od izvora IS do IS prijamnika (prijenos cjelokupnog RM se vrši na zahtjev korisnika, potrebni imenici itd. prenose se putem poveznica za bilo kakve prijenose).

2. Prijenos dokumenata za bilo koje odabrano razdoblje.

3. Prijenos svih informacija iz "pokvarenog" IB-a ako je pokrenut u načinu 1C:Enterprise, a učitavanje podataka ili pokretanje Konfiguratora nije moguće.

Značajka obrade - IS prijemnika i izvora mogu biti različiti prijenos od 2.0 do 3.0 - izdanja su različita, ali prijenos radi !!! Neusklađeni atributi se zanemaruju ili se za njih moraju navesti algoritmi prijenosa.

Komentar: Pretvorba podataka se NE KORISTI! I ne pitaj zašto!!! Za one koji su posebno korozivni - BP 3.0 se mijenja gotovo svaki dan, nema snage održavati pravila prijenosa ažurnima - ovdje je sve jednostavnije :-).

Još jedna značajka obrade je da se pokreće u IS-u prijamnika (analozi najbliži po funkcionalnosti rade obrnuto - od izvora do prijemnika).

Početak rada - morate odrediti razdoblje obrade, navesti organizaciju iz izvora, bit će prebačeno na odredište.

Prilikom prijenosa organizacije prenosi se računovodstvena politika, te "prateći" registri informacija. Stoga, kada prvi put odaberete organizaciju u izvoru, proći će neko vrijeme prije nego što se pojavi u prijemniku.

Planovi računa izvora i primatelja moraju biti isti, ne postoje različiti računi u verzijama 2. * se prenose na primatelja, u budućnosti se planira uključiti postavka za podudaranje računa i analitike. Računi se prenose kodovima koji se ne nalaze u prijamniku. NISU KREIRANI!!!

Ostali objekti se prenose internim identifikatorima (GUID), pa treba obratiti pozornost na neke ključne reference, na primjer - Valute.

Ako planirate razmjenu s "čistom" bazom podataka, tada je bolje obrisati imenike popunjene pri prvom pokretanju prije razmjene. U tu svrhu u obradi je osigurana stranica na kojoj možete dobiti te elemente direktorija i obrisati ih. U najmanju ruku, morate ukloniti valutu "trljanje". - jer dupliciranje je gotovo neizbježno (u principu, to se lako ispravlja nakon razmjene pretraživanja i zamjene duplikata ugrađenih u BP 3.0).

Obrada omogućuje pozivanje stranice za brisanje imenika, s otvorenim početnim popunjavanjem obrasca:

Kada se obrada otvori, prikazat će se stranica za brisanje imenika popunjenih tijekom početnog popunjavanja:

Od verzije 3.22 sučelje je promijenjeno, sada su sve pripremne radnje s karticama i uvijek dostupne

Važno je provjeriti korespondenciju kontnog plana izvora i primatelja i obavezno naznačiti korespondenciju konta.

Ne morate brisati unaprijed definirane elemente direktorija - oni se prenose pomoću konfiguracijskih identifikatora (ne GUID-a).

Možete odabrati objekte za prijenos pomoću obrasca za odabir iz imenika i dokumenata (informacijski registri povezani s ovim objektom automatski će se prenijeti, tako da ih ne morate posebno odabrati).Prijenos registara je privremeno onemogućen - trebate izraditi popis registara za prijenos - nešto treba prenijeti, nešto nije, u ovoj fazi dovoljno je da se prenese u referentne knjige, popis registara za prijenos će biti u predlošku, u budućim verzijama.

Prilikom razmjene s 2.0, neke pojedinosti (npr. Kontakt informacije) prenosi se prema algoritmu ugrađenom u obradu, jer za 2.0 i 3.0 pohranjuju se drugačije. Slična je situacija i s nizom dokumenata (primjerice, ispravak duga).

Popis tipova objekata može se drugačije popunjavati u verziji 3.22, nalazi se u podizborniku, promjene su prikazane na slici:

Došlo je do pojednostavljenja korištenja obrade - ne možete odabrati imenike za razmjenu, već jednostavno popunite popis tipova u prijemniku samo onim vrstama imenika koji imaju barem jedan unos u izvoru.

U obradu je ugrađen izgled koji navodi direktorije koje nije potrebno prenijeti od izvora do odredišta (izgled "Isključi iz prijenosa"). Ovom izgledu možete dodati (ukloniti) sve direktorije. Ako ne trebate prenijeti cijeli NSI, dovoljno je prenijeti dokumente, možete dobiti i popis bez odabira vrsta, samo popunite sve izvorne dokumente za koje postoje knjiženja.

Osiguran je prijenos dokumenata s kretanjima, za razmjene 3.0 do 3.0 i prema kontnim planovima radi jedan prema jedan, pri razmjeni 2.0 do 3.0 moguće su greške, stoga se preporuča prenijeti dokumente bez kretanja, a zatim ih jednostavno ponovno poslati u prijemniku. Kod prijenosa dokumenata s pokretima postavlja se zastavica "Ručno podešavanje".

Atribut "Postavljeno" postavlja se u dokumentima primatelja isto kao i u izvoru, ali će se kretanja (ako nisu prenesena) pojaviti tek nakon što se dokumenti knjiže, na primjer, korištenjem paketnog knjiženja dokumenata ugrađenog u BP 3.0 (preporučena opcija), ili iz ove obrade (gumb "Objavi dokumente" je ovdje).

Ako se obrada planira koristiti za trajnu razmjenu, može se registrirati u IB-u primatelja (gumb "Registriraj se"). Za "jednokratne" prijenose, možete ga jednostavno koristiti putem File - Open.

21.12.2015. - Verzija 3.1 platforme 8.3.7.1805 i BP 3.0.43.29 (verzija 2.15 za 3.0.43.* ne radi - konfiguracija se dosta promijenila).

Promijenjeno:

Dijalog za odabir opcije povezivanja, zastavica klijent-poslužitelj je uvijek dostupna, ovisno o njenoj postavci, dostupan je ili izbor mape baze datoteka ili polja s nazivom baze podataka na poslužitelju i nazivom sam poslužitelj (ispravljena greška u dijaloškom okviru verzije 2.15)

- NOVA FUNKCIONALNOST: Mehanizam za usklađivanje stanja i prometa između izvorne i primateljske baze podataka u različitim stupnjevima detalja:

Mislim da je izbor opcija pomirenja jasan iz slike:

Postoje razlike u korištenju kod tankog i debelog klijenta - u debelom klijentu odmah se prikazuje prozor za usporedbu datoteka:

U tankom klijentu nisam izopačio programskim pritiskom na gumb, predlažem jednostavnu opciju za prikaz prozora za usporedbu:

Usporedba u tankom klijentu, IMHO, prikladnija je, jer. ima navigacijske tipke za razlike, što je prikladnije za velike količine tablica nego pomicanje mišem:

22.03.2016. Verzija 3.10 - Dodana je zastavica "Uvijek prepiši veze" za obvezno prepisivanje referentnih objekata (brzina prijenosa je značajno smanjena, ali ponekad neophodna). Dodana je kartica "Priprema" gdje možete postaviti korespondenciju između izvornih i odredišnih kontnih planova (na istoj razini kao i šifre računa) i prijenos konstanti. Platforma 8.3.7.1970, BP 3.0.43.148

- NOVA FUNKCIONALNOST: Prije prijenosa dokumenata preporuča se provjeriti kontni plan korespondencije u izvorištu i odredištu, kao i korespondenciju postavljenih konstanti.

Da biste to učinili, dodana je kartica "Priprema" u kojoj možete postaviti ove korespondencije:

Algoritam za popunjavanje tablice korespondencije računa je jednostavan - analiziraju se prometi koji postoje u izvoru, a svaki račun koji se tamo nađe traži se podudaranje po kodu u prijemniku, ako nije pronađeno, red s računom kod je prikazan u tablici, po kojoj trebate odabrati račun primatelja, koristit će se prilikom prijenosa. Pook podudarnost se uspostavlja na razini koda.

Za provjeru i prijenos korespondencije postavljenih konstanti koristi se odgovarajuća tablica:

Ispunjavamo, po potrebi - prenosimo. Migriraju se samo označene konstante...

Programski stog je posebno memorijsko područje organizirano prema LIFO (Last in, first out) principu reda čekanja. Naziv "stog" proizašao je iz analogije principa njegove konstrukcije sa hrpom (engleski stack) ploča - možete staviti ploče jednu na drugu (metoda dodavanja u hrpu, "guranje", "guranje" ), a zatim ih pokupite, počevši od vrha (metoda dobivanja vrijednosti iz hrpe, "popping", "pop"). Programski stog se također naziva stog poziva, izvršni stog, strojni stog (ne treba ga brkati sa "stogom" - apstraktnom strukturom podataka).

Čemu služi stog? Omogućuje vam prikladno organiziranje poziva potprograma. Kada se pozove, funkcija prima neke argumente; također treba negdje pohraniti svoje lokalne varijable. Osim toga, moramo uzeti u obzir da jedna funkcija može pozvati drugu funkciju, koja također treba proslijediti parametre i pohraniti vlastite varijable. Koristeći stog, prilikom prosljeđivanja parametara, samo ih trebate staviti na stog, a zatim ih pozvana funkcija može "pop" od tamo i koristiti. Tamo se također mogu pohraniti lokalne varijable – na početku svog koda funkcija dodjeljuje dio memorije steka, a kada se kontrola vrati, briše je i oslobađa. Programeri na jezicima visoke razine obično ne razmišljaju o takvim stvarima - kompajler generira sav potreban rutinski kod za njih.

Posljedice pogreške

Sada smo se približili problemu. U svom apstraktnom obliku, stog je beskonačno skladište u koje se novi elementi mogu dodavati neograničeno. Nažalost, sve je konačno u našem svijetu - i memorija stogova nije iznimka. Što se događa ako završi kada se argumenti funkcije gurnu u stog? Ili funkcija dodjeljuje memoriju za svoje varijable?

Doći će do pogreške koja se zove prelijevanje steka. Budući da je stog neophodan za organiziranje poziva korisnički definiranih funkcija (i gotovo svih programa uključenih moderni jezici, uključujući i objektno orijentirane, nekako se grade na temelju funkcija), više se ne mogu pozvati. Dakle, operativni sustav preuzima kontrolu, briše stog i prekida program. Ovdje možete naglasiti razliku između i prekoračenja steka - u prvom slučaju dolazi do pogreške prilikom pristupa pogrešnom memorijskom području, a ako u ovoj fazi nema zaštite, ona se u ovom trenutku ne manifestira - ako su okolnosti uspješne , program može normalno raditi. Ako je zaštićena samo memorija kojoj se pristupa, . U slučaju hrpe, program će se sigurno prekinuti.

Da budemo potpuno točni, treba napomenuti da je takav opis događaja istinit samo za kompilatore koji kompiliraju u "nativni" (nativni) kod. Na upravljanim jezicima virtualni stroj postoji stog za upravljane programe, koji je mnogo lakše pratiti, a možete si čak priuštiti i izbacivanje iznimke u program kada dođe do prekoračenja. U jezicima C i C++ ne može se računati na takav "luksuz".

Razlozi pogreške

Što može dovesti do tako neugodne situacije? Na temelju gore opisanog mehanizma, jedna od opcija je previše ugniježđenih poziva funkcija. Ovaj scenarij je osobito vjerojatan kada se koristi rekurzija. Beskonačna rekurzija (u nedostatku mehanizma lijene evaluacije) prekida se na ovaj način, za razliku od , koji ponekad ima korisnu upotrebu. Međutim, s malom količinom memorije dodijeljene za stog (što je, na primjer, tipično za mikrokontrolere), jednostavan slijed poziva može biti dovoljan.

Druga opcija su lokalne varijable koje zahtijevaju puno memorije. Pokretanje lokalnog niza od milijun elemenata ili milijun lokalnih varijabli (nikad ne znate što se događa) nije najbolja ideja. Čak i jedan poziv takve "pohlepne" funkcije može lako uzrokovati prelijevanje steka. Za dobivanje velikih količina podataka, bolje je koristiti mehanizme dinamičke memorije, koji će vam omogućiti obradu pogreške njezinog nedostatka.

Međutim, dinamička memorija je dosta spora u smislu dodjele i oslobađanja (jer se operativni sustav brine o tome), osim toga, kada Direktni pristup morate ga ručno odabrati i otpustiti. Memorija na stogu se dodjeljuje vrlo brzo (zapravo, trebate promijeniti samo vrijednost jednog registra), osim toga, destruktori se automatski pozivaju za objekte dodijeljene na stog kada se funkcija vrati i stog se izbriše. Naravno, odmah postoji želja da se memorija dobije iz stog. Stoga je treći način prelijevanja samododjela memorije na stogu od strane programera. C knjižnica nudi funkciju alloca posebno za tu svrhu. Zanimljivo je primijetiti da ako malloc funkcija za dodjelu dinamičke memorije ima svog “blizanca” za oslobađanje, onda ga funkcija alloca nema – memorija se automatski oslobađa nakon što se funkcija vrati. Možda to samo komplicira situaciju - uostalom, prije nego što funkcija izađe, neće biti moguće osloboditi memoriju. Iako prema man stranici "funkcija alloca ovisi o stroju i prevodiocu; njezina implementacija je problematična i ima grešaka na mnogim sustavima; njezina upotreba je vrlo neozbiljna i mrštena" - i dalje se koristi.

Primjeri

Kao primjer, razmotrite kod za rekurzivno pretraživanje datoteka koji se nalazi na MSDN-u:

Void DirSearch(String* sDir) ( pokušajte ( // Pronađite podmape u mapi koja je proslijeđena. 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->tekst); int numFiles = f->get_Length(); za (int j=0; j< numFiles; j++) { listBox1->Stavke->Dodaj(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox::Show(e->Message); ) )

Ova funkcija dobiva popis datoteka u navedenom direktoriju, a zatim sama poziva one elemente popisa za koje se pokazalo da su direktoriji. Sukladno tome, s dovoljno dubokim stablom datotečnog sustava, dobit ćemo prirodan rezultat.

Primjer drugog pristupa, preuzet iz pitanja "Zašto dolazi do prelijevanja steka?" sa stranice pod nazivom Stack Overflow (stranica je zbirka pitanja i odgovora o bilo kojoj temi programiranja, a ne samo Stack Overflow, kako bi se moglo činiti):

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

Kao što vidite, u glavnoj funkciji, memorija se dodjeljuje na stog za nizove tipova int i float od po milijun elemenata, što ukupno daje nešto manje od 8 megabajta. Uzimajući u obzir da prema zadanim postavkama Visual C++ rezervira samo 1 megabajt za stog, odgovor postaje očigledan.

A evo primjera preuzetog iz GitHub repozitorija projekta Lightspark Flash Player:

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

Nadamo se da h.getLength()-7 nije prevelik, tako da se sljedeći redak ne prelije. Ali je li vrijeme ušteđeno na dodjeli memorije vrijedno "potencijalnog" pada programa?

Ishod

Stack overflow je fatalna pogreška koju najčešće trpe programi koji sadrže rekurzivne funkcije. Međutim, čak i ako program ne sadrži takve funkcije, prelijevanje je još uvijek moguće zbog velikog volumena lokalnih varijabli ili pogreške u ručnoj dodjeli memorije na stogu. Sva klasična pravila ostaju na snazi: ako postoji izbor, bolje je preferirati iteraciju umjesto rekurzije, a također ne raditi ručni rad umjesto kompilatora.

Bibliografski popis

E. Tanenbaum. Arhitektura računala.
Wikipedia. prelijevanje steka.
prelijevanje steka. prekoračenje steka C++.

Stog je, u ovom kontekstu, posljednji u prvom međuspremniku koji dodijelite tijekom izvođenja vašeg programa. Last, First (LIFO) znači da je posljednja stvar koju stavite uvijek prva stvar koju vratite - ako gurnete 2 stavke na hrpu, "A", a zatim "B", tada bi prva stvar koju iskočite iz hrpe bila "B" i sljedeća stvar bi bila "A".

Kada pozovete funkciju u svom kodu, sljedeća instrukcija nakon poziva funkcije pohranjuje se na stog i bilo koji memorijski prostor koji može biti prepisan pozivom funkcije. Odabrana funkcija može koristiti više stog za vlastite lokalne varijable. Kada se završi, oslobodit će prostor lokalne varijable koji je koristio, a zatim se vratiti na prethodnu funkciju.

Stack Overflow

Prelijevanje steka je kada ste za stog iskoristili više memorije nego što je vaš program trebao koristiti. U ugrađenim sustavima možete imati samo 256 bajtova za stog, a ako svaka funkcija zauzima 32 bajta, tada možete imati samo pozive funkcije 8 funkcije 2 s funkcijom dubinske funkcije 1 koja poziva funkciju 3 koja poziva funkciju 4. .tko poziva funkciju 8, koja poziva funkciju 9, ali funkcija 9 prepisuje memoriju izvan steka. To može prebrisati memoriju, kod itd.

Mnogi programeri čine ovu pogrešku pozivajući funkciju A, koja zatim poziva funkciju B, koja zatim poziva funkciju C, koja zatim poziva funkciju A. Možda će raditi većinu vremena, ali samo jedan pogrešan unos će uzrokovati da će zauvijek kružiti dok računalo sazna da je stog pun.

Rekurzivne funkcije također uzrokuju ovo, ali ako pišete rekurzivno (tj. vaša funkcija poziva samu sebe) tada morate biti svjesni toga i koristiti statičke/globalne varijable kako biste spriječili beskonačnu rekurziju.

Obično, OS i programski jezik koji koristite upravljaju stogom, a to je izvan vaših ruku. Trebali biste pogledati svoj graf poziva (strukturu stabla koja od vaše glavne točke pokazuje što svaka funkcija poziva) kako biste vidjeli koliko su duboki pozivi vaših funkcija i identificirali petlje i rekurziju koji nisu namijenjeni. Namjerne petlje i rekurziju treba umjetno provjeriti pogreškom ako se međusobno zovu previše puta.

Osim dobrih praksi programiranja, statičkog i dinamičkog testiranja, u tim sustavima ne možete puno učiniti visoka razina.

Ugrađeni sustavi

U ugrađenom svijetu, posebno u kodu visoke pouzdanosti (automobilska, zrakoplovna, svemirska), obavljate opsežne provjere i validaciju koda, ali također činite sljedeće:

Onemogućite rekurziju i petlje - provedite politiku i testiranje
Držite kod i snop daleko jedan od drugog (kod u flashu, stog u RAM-u i nikada se neće podudarati)
Postavite zaštitne trake oko hrpe - prazno područje memorije koje ispunite čarobnim brojem (obično program za prekid, ali ovdje postoji mnogo opcija) i stotine ili tisuće puta u sekundi gledate u zaštitne trake kako biste provjerite da nisu prepisani.
Koristite zaštitu memorije (tj. nemojte izvršavati na stogu, nemojte čitati ili pisati izravno iza stoga)
Prekidi ne pozivaju sekundarne funkcije – postavljaju zastavice, kopiraju podatke i puštaju aplikaciju da se pobrine za rukovanje (inače biste mogli ući 8 duboko u stablo poziva funkcije, imati prekid, a zatim izaći iz još nekoliko funkcija unutar prekinuti uzrokujući bacanje). Imate nekoliko stabala poziva - jedno za glavne procese i jedno za svaki prekid. Ako vaši prekidi mogu prekidati jedni druge... pa, postoje zmajevi...

Jezici i sustavi visoke razine

Ali u jezicima visoke razine koji rade na operativnim sustavima:

Smanjiti lokalno skladište varijable (lokalne varijable su pohranjene na stogu, iako su prevoditelji prilično pametni u vezi s tim i ponekad stavljaju velike komade na hrpu ako je vaše stablo poziva malo)
Izbjegavajte ili strogo ograničite rekurziju
Ne razbijajte svoje programe predaleko na sve manje i manje funkcije – čak i bez uzimanja u obzir lokalnih varijabli, svaki poziv funkcije troši do 64 bajta na stogu (32-bitni procesor, spremanje polovice procesorskih registara, zastavica, itd.).
Držite stablo poziva plitko (slično kao u gornjem opisu)

Web poslužitelji

Ovisi o sandboxu koji imate, možete li kontrolirati ili čak vidjeti stog. Šanse su da možete rukovati web poslužiteljima kao i svaki drugi jezik visoke razine i operacijski sustav, uglavnom ovisi o vama, ali provjerite svoj jezik i stog poslužitelja. Na primjer, možete razbiti stog na svom SQL poslužitelju.