1c depășire a stivei de limbi încorporate. Depășirea stivei

14.04.2016 Versiunea 3.22 Interfața a fost schimbată, erorile la transferul registrelor au fost corectate, procedura de transfer a unei organizații și politicile contabile au fost modificate. Platforma 8.3.7.2027 BP 3.0.43.174
17.03.2016 Versiunea 3.24 Au fost corectate erorile observate. Platforma 8.3.8.1747 BP 3.0.43.241
16/06/2016 Versiunea 3.26 Erorile observate au fost corectate. Platforma 8.3.8.2088 BP 3.0.44.123
16.10.2016 Versiunea 4.0.1.2 S-a remediat transferul stocării valorii, s-a schimbat transferul politicii contabile pentru versiunile 3.44.*. Platforma 8.3.9.1818 BP 3.0.44.164.
19.04.2017 Versiunea 4.0.2.7 Algoritmul pentru transferul registrelor asociate directoarelor a fost modificat, erorile observate au fost corectate, transferul cu suprascrierea legăturilor a fost reparat.
29.05.2017 Versiunea 4.0.4.5 S-a schimbat transferul de mișcări, a adăugat vizualizarea mișcărilor documentelor transferate, altceva...
30/05/2017 Versiunea 4.0.4.6 S-a remediat o eroare la completarea listei directoarelor existente în sursă (mulțumesc shoy)
17.06.2017 Versiunea 4.0.5.1 Algoritmul de transfer al mișcărilor a fost modificat.
19.07.2017 Versiunea 4.0.5.4 Transferul CI de la BP 2.0 a fost modificat. În mod neașteptat, transferul de la UT 10.3 a fost efectuat de Smilegm, în această versiune transferul a fost ușor corectat pentru această situație)))
10.08.2017 Versiunea 4.0.5.5 S-au remediat erori la transferul de la BP 2.0
19.09.2017 Versiunea 4.4.5.7 Verificarea conexiunii fixe pentru 3.0.52.*
28.11.2017 Versiunea 4.4.5.9 S-au remediat erorile raportate
12/06/2017 Versiunea 5.2.0.4 Algoritmul de căutare a linkurilor a fost reproiectat. Au fost adăugate proceduri de transfer de la BP 1.6; nu mai există o conexiune strictă la BP - o puteți utiliza cu ușurință pentru a transfera date cu configurații „aproape” identice. Voi încerca să corectez toate comentariile prompt.
08.12.2017 Versiunea 5.2.1.3 A fost adăugat un algoritm pentru transferul declarațiilor de salariu de la BP.2.0 la BP 3.0. Au inclus modificări pentru partajarea între configurații identice.
19.12.2017 Versiunea 5.2.2.2 Transferul registrelor de informații independente pentru directoare care se află în dimensiunile acestor registre a fost ajustat.

12/06/2017 Noua versiune de procesare 5.2.0.4. Printre schimbările semnificative se numără capacitatea de a transfera de la BP 1,6 la BP 3,0. Principala modificare este gestionarea căutării link-urilor de directoare - în versiunile anterioare căutarea a fost prin GUID, dar în această versiune puteți activa căutarea „După detalii”:

17/01/2018 Versiunea 5.2.2.3 Remediată - erori observate în directoarele subordonate și registrele periodice de informații.

19.07.2018 Versiunea 5.2.2.8 Au fost corectate erorile observate.

în care puteți seta detaliile de căutare pentru orice director. Acest mod în sine „a apărut” la numeroasele solicitări ale lucrătorilor, pentru cazurile în care este necesar un schimb într-o bază de date deja existentă care are deja date (de exemplu, pentru a fuziona înregistrările contabile pentru două organizații într-o singură bază de date).

21.12.2015 Platforma 8.3.7.1805 și respectiv BP 3.0.43.29 au fost lansate o nouă versiune procesare 3.1:-) (descrierea mai jos). Noua funcționalitate - capacitatea de a compara soldurile și cifra de afaceri între două baze de date BP (pentru toate conturile, dacă planurile de conturi coincid, sau pentru conturile contabile individuale care se potrivesc, cu sau fără analize).
01/03/2016 Versiunea 3.5 - mecanismul de conectare la baza sursă a fost modificat - adus în conformitate cu BSP 2.3.2.43. S-au rezolvat erori minore. Platforma 8.3.7.1845, BP 3.0.43.50
16.02.2016 Versiunea 3.6 - A fost adăugat indicatorul „Setare corectare manuală” pentru documentele transferate cu mișcări. Transfer fix de mișcări - documentele cu o dată mai mică decât începutul perioadei sunt transferate fără mișcări. Platforma 8.3.7.1917, BP 3.0.43.116
22.03.2016 Versiunea 3.10 - S-a adăugat indicatorul „Suprascrie întotdeauna referințele” pentru rescrierea obligatorie a obiectelor la care se face referire (viteza de transfer este redusă semnificativ, dar uneori este necesară). S-a adăugat fila „Pregătire”, unde puteți configura corespondența planurilor de conturi sursă și destinație (la același nivel cu codurile de cont) și transferul constantelor. Platforma 8.3.7.1970, BP 3.0.43.148

03.04.2016 Versiunea 3.11 Completarea listei documentelor existente în sursă a fost modificată: s-a completat prin mișcări conform planului de conturi, s-a făcut simplu prin link-uri pentru perioadă, la fel ca în // site/public/509628/

Prelucrarea este destinată transferului de date pentru orice perioadă în același mod ca „Încărcarea MXL” cu ITS, numai fără a utiliza XML, JSON și alte fișiere intermediare - schimb de la bază de date la bază de date prin COM. În versiunile mai vechi de 3.10, o conexiune este utilizată folosind un algoritm de la BSP, care prevede înregistrarea comcntr.dll (dacă sistemul de operare „permite”), precum și diverse mesaje când este imposibil să se stabilească o conexiune, pt. exemplu - „Baza de informații este în curs de actualizare” etc. A fost adăugată verificarea pentru selectarea unui receptor ca sursă IS - este emis un avertisment.

Poate fi folosit pentru:

1. Transferul informațiilor de referință de reglementare (RNI) de la sursa IS la destinația IS (transferul tuturor informațiilor de referință se efectuează la cererea utilizatorului, cărțile de referință necesare etc. sunt transferate prin link-uri în timpul oricăror transferuri).

2. Transfer de documente pentru orice perioadă selectată.

3. Transferul tuturor informațiilor dintr-un sistem de securitate a informațiilor „defect” dacă este lansat în modul 1C:Enterprise, iar încărcarea datelor sau lansarea Configuratorului este imposibilă.

Caracteristica procesării - securitatea informațiilor receptorului și a sursei pot fi diferite; transfer de la 2.0 la 3.0 - edițiile sunt diferite, dar transferul funcționează!!! Detaliile nepotrivite sunt ignorate sau trebuie specificați algoritmi de transfer pentru acestea.

Cometariu: Conversia datelor NU ESTE UTILIZĂ! Și nu întrebați de ce!!! Pentru cei care sunt deosebit de pretențioși - BP 3.0 se schimbă aproape în fiecare zi, nu mai există putere să țină la zi regulile de transfer - totul este mai simplu aici :-).

O altă caracteristică a procesării este că este lansată în securitatea informațiilor receptorului (analogii cei mai apropiați în funcționalitate funcționează invers - de la sursă la receptor).

Noțiuni introductive - trebuie să specificați perioada de procesare, să specificați organizația de la sursă, aceasta va fi transferată la destinație.

La transferul unei organizații, politicile contabile și registrele de informații „conexe” sunt transferate. Prin urmare, atunci când selectați pentru prima dată o organizație în sursă, va trece ceva timp înainte ca aceasta să apară în receptor.

Planurile de conturi ale sursei și destinației trebuie să fie aceleași, nu sunt transferate conturi diferite în versiunile 2.* la destinație, este planificat să permită ajustarea conturilor de potrivire și a analizelor în viitor. Conturile sunt transferate folosind coduri care nu se găsesc în receptor NU POATE FI CREATE!!!

Obiectele rămase sunt transferate folosind identificatori interni (GUID), așa că ar trebui să acordați atenție unor directoare cheie, de exemplu - Monede.

Dacă intenționați să faceți schimb cu o bază de date „curată”, atunci este mai bine să ștergeți directoarele completate în timpul primei lansări înainte de schimb. De ce există o pagină în procesare unde puteți obține aceste elemente de director și le puteți șterge. Cel puțin, trebuie să eliminați moneda „frec”. - deoarece duplicarea este aproape inevitabilă (în principiu, aceasta este ușor de corectat după partajarea căutării și înlocuirii duplicatelor încorporate în BP 3.0).

Procesarea prevede apelarea paginii de ștergere a directorului atunci când formularul de completare inițial este deschis:

Când deschideți procesarea, va fi afișată o pagină pentru ștergerea directoarelor completate în timpul completării inițiale:

Începând cu versiunea 3.22, interfața a fost schimbată, acum toate operațiunile pregătitoare sunt filate și întotdeauna disponibile

Este important să verificați corespondența Planului de conturi al sursei și al destinatarului și asigurați-vă că indicați corespondența conturilor.

Nu este nevoie să ștergeți elementele de director predefinite - acestea sunt transferate prin identificatori de configurare (nu GUID-uri).

Puteți selecta obiecte pentru transfer folosind formularul de selecție din directoare și documente (registrele de informații asociate acestor obiecte vor fi transferate automat, deci nu este nevoie să le selectați separat).Transferul registrelor, reducerea este temporar dezactivată - trebuie să dezvoltați o listă de registre pentru transfer - ceva ar trebui să fie transferat, ceva nu ar trebui, în această etapă este suficient ceea ce este transferat în directoare, lista registrelor pentru transfer va fi în șablon în versiunile viitoare.

La schimbul cu 2.0, unele detalii (de exemplu, Informații de contact) este transferat conform algoritmului încorporat în procesare, deoarece pentru 2.0 și 3.0 sunt stocate diferit. Situația este similară cu o serie de documente (de exemplu, Ajustarea datoriilor).

Lista tipurilor de obiecte poate fi completată diferit în versiunea 3.22, aceasta este plasată într-un submeniu, modificările sunt indicate în imagine:

Există o simplificare a utilizării procesării - nu puteți selecta directoare pentru schimb, ci pur și simplu umpleți lista de tipuri din receptor doar cu acele tipuri de directoare care au cel puțin o intrare în sursă.

Procesarea are un aspect încorporat care listează directoare care nu trebuie transferate de la sursă la destinație (dispunerea „Excludeți din transfer”). Puteți adăuga (elimina) orice directoare la acest aspect. Dacă nu trebuie să transferați toate datele de referință, este suficient să transferați documentele, a căror listă poate fi obținută și fără a selecta tipuri, pur și simplu completați cu toate documentele sursă pentru care există tranzacții.

Este furnizat transferul de documente cu mișcări; pentru schimburile de la 3.0 la 3.0 și corespondența planurilor de conturi, funcționează unu la unu; la schimbul de la 2.0 la 3.0, sunt posibile erori, deci se recomandă transferul documentelor fără mișcări și apoi pur și simplu transferați-le la receptor. La transferul documentelor cu mișcări, este setat steagul „Ajustare manuală”.

Atributul „Postat” este setat în documentele destinatare în același mod ca și în sursă, dar mișcările (dacă nu au fost transferate) vor apărea numai după procesarea documentelor, de exemplu, folosind procesarea Înregistrare de grup a documentelor încorporată în BP 3.0 (opțiune recomandată), sau din această procesare (Există un buton „Postează documente” aici).

Dacă procesarea este planificată pentru a fi utilizată pentru schimb permanent, aceasta poate fi înregistrată în securitatea informațiilor destinatarului (butonul „Înregistrare”). Pentru transferuri „o singură dată”, îl puteți utiliza pur și simplu prin File - Open.

21/12/2015 - Versiunea 3.1 platforma 8.3.7.1805 și unitatea de alimentare 3.0.43.29 (versiunea 2.15 pentru 3.0.43.* nu funcționează - configurația a fost schimbată destul de mult).

Schimbat:

Dialog pentru selectarea unei opțiuni de conectare, steag-ul Client-server este întotdeauna disponibil, în funcție de setarea acestuia, fie alegerea unui folder de bază de date de fișiere, fie un câmp cu numele bazei de date de pe server și numele serverului în sine este disponibil (o eroare în versiunea de dialog 2.15 a fost remediată)

- NOUA FUNCȚIONALITATE: Un mecanism pentru reconcilierea soldurilor și cifrei de afaceri între bazele de date sursă și receptor în diferite grade de detaliu:

Cred că alegerea opțiunilor de verificare este clară din figură:

Există diferențe de utilizare în clientul subțire și gros - în clientul gros, o fereastră de comparare a fișierelor este imediat afișată:

În clientul subțire, nu m-am deranjat cu apăsarea programatică a butoanelor; sugerez o opțiune simplă pentru afișarea unei ferestre de comparație:

Comparația într-un client subțire, IMHO, este mai convenabilă, deoarece... are butoane de navigare pentru diferențe, ceea ce este mai convenabil pentru mese mari decât derularea cu mouse-ul:

22.03.2016 Versiunea 3.10 - S-a adăugat indicatorul „Suprascrie întotdeauna referințele” pentru rescrierea obligatorie a obiectelor la care se face referire (viteza de transfer este redusă semnificativ, dar uneori este necesară). S-a adăugat fila „Pregătire”, unde puteți configura corespondența planurilor de conturi sursă și destinație (la același nivel cu codurile de cont) și transferul constantelor. Platforma 8.3.7.1970, BP 3.0.43.148

- NOUA FUNCȚIONALITATE:Înainte de a transfera documentele, se recomandă verificarea planului de conturi pentru consecvența în sursă și destinație, precum și pentru conformitatea cu constantele stabilite.

În acest scop, a fost adăugată o filă „Pregătire” în care puteți seta aceste corespondențe:

Algoritmul de completare a tabelului de potrivire a conturilor este simplu - se analizează cifra de afaceri existentă în sursă, iar pentru fiecare cont găsit acolo se găsește o potrivire în receptor prin cod; dacă nu se găsește o potrivire, o linie cu contul codul este afișat în tabel, prin care trebuie să selectați contul de destinatar, acesta va fi folosit la transfer. Conformitatea Poke este stabilită la nivel de cod.

Pentru a verifica și transfera corespondența constantelor stabilite, se utilizează tabelul corespunzător:

Îl completăm și îl transferăm dacă este necesar. Sunt transferate doar constantele marcate cu steag...

Stiva de programe este o zonă specială de memorie organizată conform principiului cozii LIFO (Last in, first out). Numele „stivă” provine din analogia principiului construcției sale cu un teanc de farfurii - puteți pune farfurii una peste alta (metoda de adăugare la stivă, „împingeți”, „împingeți”) și apoi ia-le, începând de sus (metoda de a obține o valoare din stivă, „popping”, „pop”). Stiva de programe se mai numește și stiva de apeluri, stiva de execuție sau stiva de mașini (pentru a nu-l confunda cu „stiva” - o structură abstractă de date).

Pentru ce este o stivă? Vă permite să organizați convenabil apelul subrutinelor. Când este apelată, funcția primește câteva argumente; trebuie să-și stocheze și variabilele locale undeva. În plus, trebuie să ținem cont de faptul că o funcție poate apela o altă funcție, care trebuie să treacă și parametrii și să-și stocheze variabilele. Folosind stiva, atunci când treceți parametrii trebuie doar să-i puneți pe stivă, apoi funcția apelată îi poate „pop” de acolo și îi poate folosi. Variabilele locale pot fi, de asemenea, stocate acolo - la începutul codului său, funcția alocă o parte din memoria stivei, iar când controlul revine, o șterge și o eliberează. Programatorii din limbaje de nivel înalt, de obicei, nu se gândesc la astfel de lucruri - compilatorul generează tot codul de rutină necesar pentru ei.

Consecințele unei erori

Acum suntem aproape aproape de problemă. În abstract, o stivă este un magazin infinit în care articole noi pot fi adăugate la nesfârșit. Din păcate, în lumea noastră totul este finit - iar memoria stivă nu face excepție. Ce se întâmplă dacă se termină când argumentele funcției sunt împinse în stivă? Sau funcția alocă memorie pentru variabilele sale?

Va apărea o eroare numită depășire a stivei. Deoarece stiva este necesară pentru a organiza apelarea funcțiilor definite de utilizator (și aproape toate programele din limbile moderne, inclusiv cele orientate pe obiecte, sunt construite pe baza funcțiilor într-un fel sau altul), acestea nu vor mai putea a fi chemat. Prin urmare, sistemul de operare preia controlul, șterge stiva și închide programul. Aici putem sublinia diferența dintre stack overflow și stack overflow - în primul caz, apare o eroare la accesarea unei zone de memorie incorectă, iar dacă nu există protecție în această etapă, aceasta nu se manifestă în acel moment - cu un succes combinație de circumstanțe, programul poate funcționa normal. Dacă numai memoria accesată a fost protejată, . În cazul unei stive, programul se încheie cu siguranță.

Pentru a fi complet precis, trebuie remarcat faptul că o astfel de descriere a evenimentelor este valabilă numai pentru compilatoarele care compilează în cod nativ. În limbile gestionate, mașina virtuală are propria sa stivă pentru programele gestionate, a căror stare este mult mai ușor de monitorizat și vă puteți permite chiar să aruncați o excepție de la program atunci când are loc o depășire. În limbajele C și C++ nu puteți conta pe un astfel de „lux”.

Motivele erorii

Ce ar putea duce la o astfel de situație neplăcută? Pe baza mecanismului descris mai sus, o posibilitate este că există prea multe apeluri de funcții imbricate. Acest scenariu este mai ales probabil când se folosește recursiunea. Recursiunea infinită (în absența unui mecanism de evaluare leneș) este întreruptă în acest fel, spre deosebire de , care uneori are aplicații utile. Cu toate acestea, cu o cantitate mică de memorie alocată stivei (care, de exemplu, este tipică pentru microcontrolere), o simplă secvență de apeluri poate fi suficientă.

O altă opțiune sunt variabilele locale, care necesită multă memorie. A avea o matrice locală de un milion de elemente sau un milion de variabile locale (nu știi niciodată ce se întâmplă) nu este cea mai bună idee. Chiar și un apel la o astfel de funcție lacomă poate provoca cu ușurință o depășire a stivei. Pentru a obține cantități mari de date, este mai bine să utilizați mecanisme de memorie dinamică, care vă vor permite să gestionați eroarea lipsei acesteia.

Cu toate acestea, memoria dinamică este destul de lentă în ceea ce privește alocare și dealocare (deoarece sistemul de operare se ocupă de acest lucru), iar cu acces direct trebuie să o aloci și să o dealocați manual. Memoria de pe stivă este alocată foarte rapid (de fapt, trebuie doar să modificați valoarea unui registru); în plus, obiectele alocate pe stivă au destructori apelați automat atunci când controlul funcției revine și stiva este șters. Desigur, apare imediat dorința de a obține memorie din stivă. Prin urmare, a treia modalitate de depășire este alocarea propriei memorie de către programator pe stivă. Biblioteca C oferă funcția alloca special pentru acest scop. Este interesant de remarcat faptul că, dacă funcția de alocare a memoriei dinamice malloc are propriul „geamăn” pentru eliberarea acesteia, gratuit, atunci funcția alloca nu o are - memoria este eliberată automat după revenirea controlului funcției. Poate că acest lucru nu face decât să complice situația - la urma urmei, nu va fi posibil să eliberați memoria înainte de a ieși din funcție. Chiar dacă, conform paginii de manual, „funcția alloca este dependentă de mașină și de compilator; pe multe sisteme, implementarea sa este problematică și greșită; utilizarea sa este foarte frivolă și desconsiderată” - este încă folosită.

Exemple

De exemplu, să ne uităm la codul pentru căutarea recursivă a fișierelor situat pe MSDN:

Void DirSearch(String* sDir) ( try ( // Găsiți subfolderele din folderul care este transmis. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0;i< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Text); int numFiles = f->get_Length(); pentru (int j=0; j< numFiles; j++) { listBox1->Items->Add(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox::Show(e->Message); ) )

Această funcție primește o listă de fișiere din directorul specificat și apoi se autoapelează pentru acele elemente din listă care se întâmplă să fie directoare. În consecință, cu un copac suficient de adânc Sistemul de fișiere, obținem un rezultat natural.

Un exemplu al celei de-a doua abordări, luat de la întrebarea „De ce are loc depășirea stivei?” de la un site numit Stack Overflow (site-ul este o colecție de întrebări și răspunsuri pe orice subiect de programare, și nu doar Stack Overflow, așa cum ar părea):

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

După cum puteți vedea, funcția principală alocă memorie pe stivă pentru matrice de tipurile int și float, fiecare cu un milion de elemente, ceea ce oferă în total puțin mai puțin de 8 megaocteți. Dacă considerați că implicit Visual C++ rezervă doar 1 megaoctet pentru stivă, atunci răspunsul devine evident.

Și iată un exemplu luat din depozitul GitHub al proiectului Lightspark Flash player:

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

Puteți spera că h.getLength()-7 nu este un număr prea mare, astfel încât să nu existe depășire pe linia următoare. Dar timpul economisit la alocarea memoriei merită „potențialul” blocaj al programului?

Concluzie

Depășirea stivei este o eroare fatală care afectează cel mai adesea programele care conțin funcții recursive. Cu toate acestea, chiar dacă programul nu conține astfel de funcții, o depășire este totuși posibilă din cauza dimensiunii mari a variabilelor locale sau a unei erori în alocarea manuală a memoriei pe stivă. Toate regulile clasice rămân în vigoare: dacă există o alegere, este mai bine să alegeți iterația în loc de recursivitate și, de asemenea, nu faceți lucru manual în locul compilatorului.

Bibliografie

• E. Tanenbaum. Arhitectura calculatorului.
• Wikipedia. Debordarea stivei.
• Depășirea stivei. Stivă overflow C++.

Stiva, în acest context, este ultima din primul buffer pe care îl alocați în timpul execuției programului dumneavoastră. Last, First (LIFO) înseamnă că ultimul lucru pe care îl puneți este întotdeauna primul lucru pe care îl faceți înapoi - dacă puneți 2 articole pe stivă, „A” și apoi „B”, atunci primul lucru pe care îl scoateți din stivă va fi „B” și următorul lucru va fi „A”.

Când apelați o funcție din codul dvs., următoarea comandă după apelul funcției este stocată în stivă și în orice spațiu de memorie care poate fi suprascris de apelul funcției. Funcția aleasă poate folosi mai multă stivă pentru propriile variabile locale. Când se face acest lucru, va elibera spațiul variabil local pe care îl folosea și apoi va reveni la funcția anterioară.

Depășirea stivei

O depășire a stivei este atunci când ați folosit mai multă memorie pe stivă decât programul dumneavoastră intenționa să folosească. Pe sistemele încorporate, este posibil să aveți doar 256 de octeți pentru stivă, iar dacă fiecare funcție are 32 de octeți, atunci puteți avea doar 8 apeluri de funcție la funcția 2 cu funcția profundă a funcției 1, care apelează funcția 3, care apelează funcția 4. ..care apelează funcția 8, care apelează funcția 9, dar funcția 9 suprascrie memoria în afara stivei. Acest lucru poate suprascrie memoria, codul etc.

Mulți programatori fac această greșeală apelând funcția A, care apelează apoi funcția B, care apoi apelează funcția C, care apelează apoi funcția A. Poate funcționa de cele mai multe ori, dar o singură intrare greșită o va face să se rotească pentru totdeauna până când computerul fails află că stiva este plină.

Funcțiile recursive sunt, de asemenea, o cauză a acestui lucru, dar dacă scrieți recursiv (adică funcția dvs. se numește singură), atunci trebuie să fiți conștienți de acest lucru și să utilizați variabile statice/globale pentru a preveni recursiunea fără sfârșit.

În mod obișnuit, sistemul de operare și limbajul de programare pe care îl utilizați gestionează stiva și nu vă este în mâinile tale. Ar trebui să vă uitați la graficul apelurilor dvs. (o structură arborescentă care arată din punctul dvs. principal ceea ce apelează fiecare funcție) pentru a vedea cât de profunde sunt apelurile dvs. de funcție și pentru a identifica buclele și recursiunea care nu sunt intenționate. Buclele intenționate și recursiunea trebuie verificate artificial dacă se apelează reciproc de prea multe ori.

În afară de bunele practici de programare, testarea statică și dinamică, nu puteți face mare lucru în aceste sisteme de nivel înalt.

Sisteme integrate

În lumea încorporată, în special în codul de înaltă asigurare (auto, aerospațial, aerospațial), faceți teste extinse și revizuiți codul, dar faceți și următoarele:

• Dezactivați recursiunea și buclele - conformitatea cu politicile și testarea
• Păstrați codul și stiva departe (codul în flash, stiva în RAM și nu se vor potrivi niciodată)
• Plasați bare de protecție în jurul stivei - o zonă goală de memorie pe care o umpleți cu un număr magic (de obicei, rutina de întrerupere, dar există multe variații aici) și de sute sau mii de ori pe secundă vă uitați la barele de pază pentru a le face sigur că nu au fost suprascrise.
• Utilizați protecția memoriei (adică nu executați pe stivă, nu citiți sau scrieți direct în spatele stivei)
• Întreruperile nu apelează funcții secundare - ele setează steaguri, copiază datele și lasă aplicația să se ocupe de gestionarea lor (altfel ai putea ajunge la 8 adâncime în arborele de apeluri de funcții, ai avea o întrerupere și apoi mai ai câteva funcții în interior). ieșirea întreruptă, provocând o aruncare). Aveți mai mulți arbori de apeluri - unul pentru procesele principale și unul pentru fiecare întrerupere. Dacă întreruperile tale se pot întrerupe reciproc... ei bine, există dragoni...

Limbi și sisteme de nivel înalt

Dar în limbi de nivel înalt care rulează pe sisteme de operare:

• Reduceți stocarea variabilelor locale (variabilele locale sunt stocate pe stivă), deși compilatorii sunt destul de inteligenți în acest sens și uneori vor pune bucăți mari pe grămadă dacă arborele de apeluri este puțin adânc)
• Evitați sau limitați strict recursiunea
• Nu vă întrerupeți prea mult programele în funcții din ce în ce mai mici - chiar și fără a lua în considerare variabilele locale, fiecare apel de funcție consumă până la 64 de octeți pe stivă (procesor de 32 de biți, salvând jumătate din registrele procesorului, steaguri etc.).
• Păstrați arborele de apeluri superficial (similar cu descrierea de mai sus)

Servere web

Depinde de cutia de nisip pe care o ai dacă poți controla sau chiar vedea stiva. Sunt șanse să puteți gestiona serverele web ca orice altă limbă și sistem de operare de nivel înalt - este în mare parte din mâinile voastre, dar verificați limba și stiva de servere pe care o utilizați. De exemplu, puteți împărți stiva pe serverul dvs. SQL.

Ghidul programatorului API Informix® DataBlade™ este disponibil pentru descărcare. Secțiunea „Managing Stack Space” descrie crearea de funcții definite de utilizator (UDR). Acest articol oferă informații suplimentare și sfaturi de depanare.

Următoarele informații se aplică indiferent dacă UDR rulează pe un procesor virtual (VP) definit de utilizator sau pe un CPU VP. Stiva unui thread poate fi mutată într-un procesor virtual definit de utilizator imediat înainte de executarea UDR.

Ce dimensiune stivă este alocată pentru UDR?

Mărimea stivei disponibile pentru un UDR depinde de modul în care a fost creat UDR:

folosind modificatorul STACK, care permite UDR să-și folosească stiva special alocată,

fără modificatorul STACK, ceea ce înseamnă că UDR va partaja stiva alocată de server cu firul care face cererea. Dimensiunea stivei în acest caz va fi determinată de valoarea parametrului STACKSIZE din fișierul de configurare onconfig.

Modificator STACK

Instrucțiunile CREATE PROCEDURE sau CREATE FUNCTION au un modificator opțional STACK care vă permite să specificați cantitatea de spațiu de stivă, în octeți, necesară pentru a executa UDR.

Dacă utilizați modificatorul STACK atunci când creați un UDR, serverul va aloca și dezaloca spațiu de stivă de fiecare dată când UDR-ul este executat. Dimensiunea disponibilă reală este egală cu valoarea STACK în octeți minus o suprasarcină în funcție de numărul de argumente ale funcției.

Dacă valoarea STACK este mai mică decât parametrul STACKSIZE din fișierul onconfig (vezi secțiunea următoare), atunci dimensiunea stivei alocată pentru UDR va fi rotunjită automat la valoarea STACKSIZE.

Parametrul de configurare STACKSIZE

Fișierul de configurare onconfig include un parametru STACKSIZE care specifică dimensiunea implicită a stivei pentru firele de execuție ale utilizatorului.

Dacă nu specificați STACK atunci când creați un UDR, serverul nu alocă spațiu suplimentar pentru stiva pentru a executa acel UDR. În schimb, UDR utilizează spațiul de stivă alocat pentru a executa cererea. Dimensiunea disponibilă a stivei va depinde de suprasarcina de execuție a funcției la nivel SQL.

Stiva per fir este alocată o singură dată pentru firul specific care execută cererea. Performanța este mai bună atunci când UDR partajează o stivă cu un fir de execuție, deoarece serverul nu irosește resurse pentru alocarea unei stive suplimentare pentru fiecare apel UDR. Pe de altă parte, dacă dimensiunea stivei utilizată de UDR se apropie de valoarea STACKSIZE, poate provoca o depășire a stivei la apelarea funcției ca parte a unei interogări complexe (caz în care mai puțin spațiu de stivă va fi disponibil pentru execuția UDR).

Vă rugăm să rețineți că nu ar trebui să setați valoarea STACKSIZE prea mare, deoarece aceasta va afecta toate firele de discuție ale utilizatorilor.

Când este necesar să se controleze dimensiunea stivei?

YTrebuie să gestionați spațiul de stivă dacă UDR-ul efectuează apeluri recursive sau dacă UDR-ul necesită mai mult spațiu de stivă decât este disponibil implicit în stiva firului de execuție (STACKSIZE).

Există două moduri de a crește stiva pentru execuția UDR:

Specificați modificatorul STACK atunci când creați un UDR.

Utilizați mi_call() pentru a efectua apeluri recursive (consultați Ghidul programatorului API Informix DataBlade pentru un exemplu).

Dacă nu specificați o dimensiune prin STACK și dacă nu utilizați mi_call() pentru a crește stiva curentă și dacă UDR-ul face ceva care necesită mult spațiu în stivă, va provoca o supraîncărcare a stivei.

Rețineți că unele funcții mi_* adaugă un nou segment de stivă pentru propria lor execuție. Aceste segmente sunt eliberate la revenirea la funcția de apelare UDR.

Ce să faci dacă ceva nu merge bine?

Monitorizarea utilizării stivei

Scopul monitorizării este de a identifica UDR-ul specific care cauzează depășirea stivei, astfel încât să puteți modifica valoarea STACK în mod specific pentru acel UDR anume.

Monitorizarea utilizării stivei cu comanda „onstat -g sts”.

Monitorizarea unei sesiuni care execută o interogare SQL folosind „onstat -g ses session_id”

După identificarea unei interogări SQL care se termină cu o depășire a stivei, ar trebui să determinați utilizarea stivei executând separat interogările UDR care fac parte din interogarea originală.

Puteți seta dinamic valoarea STACK pentru UDR. De exemplu:

modificarea funcției MyFoo (lvarchar,lvarchar) cu (add stack=131072);

După modificarea valorii STACK, ar trebui să testați cererea inițială pentru a vă asigura că este acum stabilă.

Măriți STACKSIZE

Alternativ, încercați să măriți valoarea STACKSIZE. Verificați dacă acest lucru rezolvă problema. (Nu uitați să returnați mai târziu valoarea veche).

Dacă creșterea STACKSIZE nu ajută, problema este cel mai probabil corupția memoriei. Iată câteva sugestii:

Activați mâzgălirea memoriei și verificarea pool-ului de memorie. Secțiunea „Probleme de depanare” din articolul Alocarea memoriei pentru UDR explică cum se face acest lucru.

Reconsiderați utilizarea mi_lvarchar . O atenție deosebită ar trebui acordată locurilor în care mi_lvarchar este transmis unei funcții care se așteaptă să primească un șir terminat cu nul ca argument.

Reduceți numărul de VP CPU (sau utilizator) la unul pentru a reproduce problema mai rapid.

mi_print_stack() -- Solaris

Informix Dynamic Server pentru SO Solaris include o funcție mi_print_stack() care poate fi apelată în UDR. În mod implicit, această funcție salvează cadrul stivei în următorul fișier:

/tmp/default.stack

Nu puteți schimba numele fișierului de ieșire, dar puteți schimba locația acestuia modificând valoarea variabilei de mediu DBTEMP. Asigurați-vă că directorul $DBTEMP poate fi scris de către utilizatorul informix. Orice erori întâlnite în timpul executării mi_print_stack() sunt raportate către $MSGPATH.

Această caracteristică este disponibilă numai pentru OC Solaris.

Glosar

Termeni și abrevieri utilizate în acest articol:

UDR	Rutină definită de utilizator
V.P.	Procesor virtual

Acest articol demonstrează încă o dată că orice set de măsuri de securitate trebuie să acopere toate etapele de implementare: dezvoltare, implementare, administrare a sistemului și, bineînțeles, măsuri organizatorice. În sistemele informaționale, „factorul uman” (inclusiv utilizatorii) este principala amenințare de securitate. Acest set de măsuri trebuie să fie rezonabil și echilibrat: nu are sens și este puțin probabil ca fondurile suficiente să fie alocate pentru a organiza o protecție care depășește costul datelor în sine.

Introducere

1C:Enterprise este cel mai comun sistem de contabilitate din Rusia, dar, în ciuda acestui fapt, până la versiunea 8.0 dezvoltatorii săi au acordat foarte puțină atenție problemelor de securitate. Practic, desigur, acest lucru a fost dictat de nișa de preț a produsului și de concentrarea pe întreprinderile mici în care nu există specialiști IT calificați, iar costul posibil al implementării și menținerii unui sistem securizat ar fi prohibitiv de costisitor pentru întreprindere. Odată cu lansarea versiunii 8.0, accentul a trebuit să se schimbe: costul soluțiilor a crescut semnificativ, sistemul a devenit mult mai scalabil și mai flexibil - cerințele s-au schimbat semnificativ. Dacă sistemul a devenit suficient de fiabil și sigur este o întrebare foarte individuală. Principalul sistem informatic al unei întreprinderi moderne trebuie să îndeplinească cel puțin următoarele cerințe de securitate:

• Probabilitate destul de scăzută de defecțiune a sistemului din motive interne.
• Autorizare fiabilă a utilizatorului și protecție a datelor împotriva acțiunilor incorecte.
• Un sistem eficient de atribuire a drepturilor de utilizator.
• Sistem online de backup și recuperare în caz de defecțiune.

Soluțiile bazate pe 1C:Enterprise 8.0 îndeplinesc aceste cerințe? Nu există un răspuns clar. În ciuda schimbărilor semnificative în sistemul de control al accesului, rămân multe probleme nerezolvate. În funcție de modul în care este proiectat și configurat sistemul, toate aceste cerințe pot să nu fie îndeplinite sau îndeplinite într-o măsură suficientă pentru o anumită implementare, cu toate acestea, merită să acordați atenție (și aceasta este o consecință semnificativă a „tinereții” platformei ) că pentru a îndeplini pe deplin condițiile enumerate este necesar să se aplice eforturi cu adevărat herculeene.

Acest articol este destinat dezvoltatorilor și implementatorilor de soluții pe platforma 1C:Enterprise, precum și administratorilor de sistem ai organizațiilor în care este utilizat 1C:Enterprise și descrie câteva aspecte ale dezvoltării și configurării versiunii client-server a sistemului din punct de vedere din punctul de vedere al organizaţiei securitatea informatiei. Acest articol nu poate fi folosit ca înlocuitor pentru documentație, ci doar subliniază unele puncte care nu au fost încă reflectate în el. Și, desigur, nici acest articol și nici toată documentația nu vor putea reflecta complexitatea problemei construirii unui sistem informațional securizat, care în același timp trebuie să satisfacă cerințele conflictuale de securitate, performanță, comoditate și funcționalitate.

Clasificare și terminologie

Subiectul cheie de luat în considerare în articol este amenințările informaționale.

Amenințare informațională– posibilitatea unei situații în care datele vor fi citite, copiate, modificate sau blocate fără autorizație.

Și, pe baza acestei definiții, articolul clasifică amenințările informaționale după cum urmează:

• Distrugerea neautorizată a datelor
• Schimbarea neautorizată a datelor
• Copierea neautorizată a datelor
• Citirea neautorizată a datelor
• Indisponibilitatea datelor

Toate amenințările sunt împărțite în intenționate și neintenționate. Vom numi o amenințare informațională realizată incident. Caracteristicile sistemului sunt:

Vulnerabilități– caracteristici care duc la incidente Măsuri de protecție– caracteristici care blochează posibilitatea unui incident

Practic, sunt luate în considerare doar acele cazuri, a căror probabilitate se datorează utilizării platformei tehnologice 1C: Enterprise 8.0 în versiunea client-server (mai mult, în cazurile în care acest lucru nu contrazice sensul pur și simplu 1C sau 1C 8.0) . Să definim următoarele roluri principale în legătură cu utilizarea sistemului:

• Operatori– utilizatori care au drepturi de vizualizare și modificare a datelor limitate de un rol de aplicație, dar nu au funcții administrative
• Administratorii de sistem– utilizatorii care au drepturi administrative în sistem, inclusiv drepturi administrative în sistemele de operare ale serverului de aplicații și serverului MS SQL, drepturi administrative în MS SQL etc.
• Administratorii de securitate a informațiilor– utilizatori cărora le sunt delegate anumite funcții administrative din baza de informații 1C (cum ar fi adăugarea de utilizatori, testarea și remedierea, copierea de rezervă, configurarea unei soluții de aplicație etc.)
• Dezvoltatorii de sisteme– utilizatorii care dezvoltă o soluție de aplicație. În general, este posibil să nu aibă acces la sistemul de lucru.
• Persoane care nu au acces direct la sistem– utilizatori cărora nu le sunt delegate drepturi de acces la 1C, dar care pot, într-o măsură sau alta, să influențeze funcționarea sistemului (de obicei aceștia sunt toți utilizatori ai aceluiași domeniu Active Directory în care este instalat sistemul). Această categorie este considerată în primul rând pentru a identifica subiectele potențial periculoase din sistem.
• Scripturi administrative automatizate– programe cărora le sunt delegate anumite funcții, concepute pentru a efectua automat anumite acțiuni (de exemplu, import-export de date)

Aici trebuie remarcate două puncte: în primul rând, această clasificare este foarte grosieră și nu ia în considerare diviziunile din cadrul fiecărui grup - o astfel de diviziune va fi creată pentru unele cazuri specifice și, în al doilea rând, se presupune că alte persoane nu pot influența operațiunea. a sistemului, care trebuie asigurat prin mijloace externe 1C.

Orice sistem de securitate trebuie proiectat ținând cont de fezabilitate și costul de proprietate. În general, la dezvoltarea și implementarea unui sistem informațional, este necesar ca prețul de protecție a sistemului să corespundă cu:

• valoarea informațiilor protejate;
• costurile creării unui incident (în cazul unei amenințări deliberate);
• riscuri financiare în cazul unui incident

Este inutil și dăunător să organizezi o apărare care este mult mai costisitoare decât evaluarea eficienței sale financiare. Există mai multe metode de evaluare a riscurilor de pierdere a informațiilor, dar acestea nu sunt discutate în sfera acestui articol. Un alt aspect important este menținerea unui echilibru între cerințele adesea conflictuale pentru securitatea informațiilor, performanța sistemului, confortul și ușurința de a lucra cu sistemul, viteza de dezvoltare și implementare și alte cerințe pentru sistemele informaționale ale întreprinderii.

Principalele caracteristici ale mecanismului de securitate a informațiilor sistemului

1C:Enterprise 8.0 vine în două versiuni: fișier și client-server. Versiunea fișierului nu poate fi considerată pentru a asigura securitatea informațiilor sistemului din următoarele motive:

• Datele și configurația sunt stocate într-un fișier care poate fi citit și scris de toți utilizatorii sistemului.
• După cum va fi arătat mai jos, autorizarea sistemului este ocolită foarte ușor.
• Integritatea sistemului este asigurată doar de nucleul părții client.

În versiunea client-server, MS SQL Server este folosit pentru a stoca informații, care furnizează:

• Stocare de date mai fiabilă.
• Izolarea fișierelor de accesul direct.
• Tranzacții mai avansate și mecanisme de blocare.

În ciuda diferențelor semnificative dintre versiunile de fișier și client-server ale sistemului, acestea au o schemă unificată de control al accesului la nivel de soluție de aplicație, care oferă următoarele capabilități:

• Autorizarea utilizatorului folosind parola specificată în 1C.
• Autorizarea utilizatorului pe baza utilizatorului actual de Windows.
• Atribuirea de roluri utilizatorilor sistemului.
• Limitarea funcțiilor administrative după rol.
• Atribuirea interfețelor disponibile pe roluri.
• Restricționarea accesului la obiectele metadate în funcție de rol.
• Restricționarea accesului la detaliile obiectului în funcție de rol.
• Restricționarea accesului la obiectele de date în funcție de roluri și parametri de sesiune.
• Restricționarea accesului interactiv la date și modulele executabile.
• Unele restricții de execuție a codului.

În general, schema de acces la date utilizată este destul de tipică pentru sistemele informaționale de acest nivel. Cu toate acestea, în legătură cu această implementare a unei arhitecturi client-server pe trei niveluri, există câteva aspecte fundamentale care duc la un număr relativ mare de vulnerabilități:

1. Se pot aplica un număr mare de etape de prelucrare a datelor și în fiecare etapă se pot aplica reguli diferite pentru accesarea obiectelor.

   O diagramă oarecum simplificată a etapelor de prelucrare a datelor care sunt semnificative din punct de vedere al securității este prezentată în Fig. Regula generala pentru 1C este reducerea restricțiilor pe măsură ce treceți în jos această schemă, prin urmare, folosind o vulnerabilitate pe una dintre niveluri superioare poate perturba sistemul la toate nivelurile.

2. Proceduri insuficient stabilite pentru monitorizarea datelor transmise la trecerea de la un nivel la altul.

   Din păcate, nu toate mecanismele interne ale sistemului sunt perfect depanate, în special pentru mecanismele neinteractive, a căror depanare este întotdeauna mai laborioasă pe de o parte, dar mai responsabilă pe de altă parte. Această „boală” nu este o problemă exclusiv cu 1C; se găsește în multe produse server de la majoritatea furnizorilor. Doar în ultimii ani atenția asupra acestor probleme a crescut semnificativ.

3. Calificări medii insuficient de ridicate ale dezvoltatorilor și administratorilor de sistem, moștenite din versiunea anterioară.

   Produsele liniei 1C:Enterprise s-au concentrat inițial pe ușurința de dezvoltare și suport și pe lucrul în organizații mici, așa că nu este surprinzător faptul că istoric a dezvoltat că o parte semnificativă dintre „dezvoltatorii” de soluții de aplicații și „administratorii” de sistemele nu au cunoștințe și abilități suficiente pentru a lucra cu un produs mult mai complex, care este versiunea 8.0. Problema este agravată de practica adoptată de companiile francizate de a preda „în luptă” în detrimentul clienților, fără a aborda sistematic această problemă. Este necesar să aducem un omagiu companiei 1C că în ultimii ani această situație s-a corectat treptat: firmele francizate serioase au început să adopte o abordare mai responsabilă a problemei selecției și pregătirii personalului, nivelul de suport al tehnologiei informației de la compania 1C a crescut semnificativ, au apărut programe de certificare care vizează un nivel înalt de servicii; dar situația nu poate fi corectată instantaneu, așa că acest factor trebuie luat în considerare atunci când se analizează securitatea sistemului.

4. Platforma este relativ tânără.

   Printre produsele cu accent și scopuri de utilizare similare, aceasta este una dintre cele mai tinere soluții. Funcționalitatea platformei a fost mai mult sau mai puțin stabilită cu mai puțin de un an în urmă. În același timp, fiecare lansare a platformei, începând cu 8.0.10 (în această versiune au fost implementate aproape toate capabilitățile actuale ale sistemului) a devenit semnificativ mai stabilă decât cele anterioare. Funcționalitatea soluțiilor standard de aplicații este în continuare în creștere cu un pas rapid, deși doar jumătate din capacitățile platformei sunt utilizate. Desigur, în astfel de condiții putem vorbi despre stabilitate mai degrabă condiționat, dar în general trebuie recunoscut că, în multe privințe, soluțiile de pe platforma 1C 8.0 sunt semnificativ în avans în funcționalitatea și performanța (și adesea în stabilitate) soluțiilor similare pe 1C. platforma 7.7.

Deci, sistemul (și, eventual, o soluție de aplicație standard) este implementat în întreprindere și instalat pe computere. În primul rând, este necesar să se creeze un mediu în care configurarea securității 1C să aibă sens, iar pentru aceasta trebuie configurată astfel încât să fie îndeplinită ipoteza că securitatea sistemului este afectată semnificativ de setările sistemului.

Urmați regulile generale pentru configurarea securității.

Nu se poate vorbi despre securitatea informatică a unui sistem dacă nu sunt respectate principiile de bază ale creării sistemelor securizate. Asigurați-vă că sunt îndeplinite cel puțin următoarele condiții:

• Accesul la servere este limitat fizic și este asigurată funcționarea neîntreruptă a acestora:
  • echipamentul server îndeplinește cerințele de fiabilitate, înlocuirea echipamentelor server defecte a fost ajustată, pentru zone deosebit de critice se folosesc scheme cu duplicare hardware (RAID, putere din mai multe surse, mai multe canale de comunicație etc.);
  • serverele sunt amplasate într-o cameră încuiată, iar această cameră este deschisă doar pe durata lucrului care nu poate fi efectuat de la distanță;
  • Doar una sau două persoane au dreptul de a deschide camera serverului, în caz de urgență a fost dezvoltat un sistem de notificare pentru persoanele responsabile;
  • este asigurată alimentarea neîntreruptă a serverelor
  • sunt asigurate condițiile climatice normale de funcționare ale echipamentului;
  • exista alarma de incendiu in camera serverelor, nu exista risc de inundatii (in special pentru primul si ultimul etaj);
• Setările rețelei și infrastructurii informaționale a întreprinderii sunt completate corect:
  • Firewall-urile sunt instalate și configurate pe toate serverele;
  • toți utilizatorii și computerele sunt autorizate în rețea, parolele sunt suficient de complexe încât nu pot fi ghicite;
  • operatorii de sistem au suficiente drepturi pentru a lucra în mod normal cu acesta, dar nu au drepturi la acțiuni administrative;
  • instrumentele antivirus sunt instalate și activate pe toate computerele din rețea;
  • Este de dorit ca utilizatorii (cu excepția administratorilor de rețea) să nu aibă drepturi administrative pe stațiile de lucru client;
  • accesul la internet și mediile de stocare amovibile ar trebui reglementate și limitate;
  • auditarea de sistem a evenimentelor de securitate trebuie configurată;
• Au fost rezolvate principalele probleme organizatorice:
  • utilizatorii au suficiente calificări pentru a lucra cu 1C și hardware;
  • utilizatorii sunt informați cu privire la responsabilitatea pentru încălcarea regulilor de funcționare;
  • au fost desemnate persoane responsabile financiar pentru fiecare element material al sistemului informatic;
  • toate unitățile de sistem sunt sigilate și închise;
  • Acordați o atenție deosebită instruirii și supravegherii curățenilor, lucrătorilor în construcții și electricienilor. Aceste persoane pot cauza, din neglijență, daune care nu sunt comparabile cu daunele intenționate cauzate de un utilizator fără scrupule al sistemului.

Atenţie! Această listă nu este exhaustivă, ci descrie doar ceea ce este adesea omis atunci când implementați orice sistem de informații destul de complex și costisitor!

• MS SQL Server, serverul de aplicații și partea client rulează pe diferite computere, aplicațiile server rulează sub drepturile utilizatorilor Windows special creați;
• Pentru MS SQL Server
  • este setat modul de autorizare mixt
  • Utilizatorii MS SQL incluși în rolul serveradmin nu participă la lucrul 1C,
  • pentru fiecare IB 1C a fost creat un utilizator MS SQL separat care nu are acces privilegiat la server,
  • Utilizatorul MS SQL al unui IS nu are acces la alt IS;
• Utilizatorii nu au acces direct la fișierele serverului de aplicații și serverului MS SQL
• Stațiile de lucru ale operatorului sunt echipate cu Windows 2000/XP (nu Windows 95/98/Me)

Nu neglijați recomandările dezvoltatorilor de sistem și citiți documentația. Materiale importante privind configurarea sistemului sunt publicate pe discuri ITS în secțiunea „Recomandări metodologice”. Acordați o atenție deosebită următoarelor articole:

1. Caracteristicile aplicațiilor care lucrează cu serverul 1C:Enterprise
2. Plasarea datelor 1C: Enterprise 8.0
3. Actualizare 1C: Enterprise 8.0 de către utilizatori Microsoft Windows fără drepturi de administrator
4. Editarea listei de utilizatori în numele unui utilizator care nu are drepturi administrative
5. Configurarea setărilor paravanului de protecție Windows XP SP2 pentru a rula SQL Server 2000 și SQL Server Desktop Engine (MSDE)
6. Configurarea parametrilor COM+ Windows XP SP2 pentru rularea serverului 1C:Enterprise 8.0
7. Configurarea setărilor paravanului de protecție Windows XP SP2 pentru serverul 1C:Enterprise 8.0
8. Configurarea setărilor paravanului de protecție Windows XP SP2 pentru Managerul de licențe HASP
9. Crearea unei copii de rezervă baza de informatii folosind SQL Server 2000
10. Probleme de instalare și configurare 1C:Enterprise 8.0 în versiunea „client-server”.(unul dintre cele mai importante articole)
11. Particularități Setări Windows Server 2003 la instalarea serverului 1C:Enterprise 8.0
12. Reglarea accesului utilizatorilor la baza de informații în versiunea client-server(unul dintre cele mai importante articole)
13. Server 1C: Server Enterprise și SQL
14. Procedura detaliată de instalare pentru 1C:Enterprise 8.0 în versiunea „client-server”.(unul dintre cele mai importante articole)
15. Folosind limbajul încorporat pe serverul 1C:Enterprise

Dar când citiți documentația, fiți critic cu informațiile primite, de exemplu, articolul „Probleme de instalare și configurare 1C: Enterprise 8.0 în versiunea client-server” nu descrie cu exactitate drepturile care sunt necesare pentru utilizatorul USER1CV8SERVER. Vor exista link-uri către lista de mai jos, de exemplu [ITS1] înseamnă articolul „Features of applications working with the 1C:Enterprise server”. Toate linkurile către articole sunt oferite către cel mai recent număr al ITS la momentul redactării acestui articol (ianuarie 2006)

Utilizați capabilitățile de autorizare combinate cu autorizarea Windows pentru utilizatori

Dintre cele două moduri posibile de autorizare a utilizatorului: 1C încorporat și combinat cu autorizarea sistemului de operare Windows, dacă este posibil, ar trebui să alegeți autorizarea combinată. Acest lucru va permite utilizatorilor să nu fie confundați cu mai multe parole atunci când lucrează, dar nu va reduce nivelul de securitate a sistemului. Cu toate acestea, chiar și pentru utilizatorii care folosesc doar autorizarea Windows, este foarte recomandabil să setați o parolă la crearea acesteia și numai după aceea să dezactivați autorizarea 1C pentru acest utilizator. Pentru a asigura recuperarea sistemului în cazul distrugerii structurii Active Directory, este necesar să lăsați cel puțin un utilizator care să se poată conecta la sistem folosind autorizarea 1C.

Când creați roluri de soluție de aplicație, nu adăugați drepturi „în rezervă”

Fiecare rol de soluție de aplicație trebuie să reflecte setul minim necesar de drepturi pentru a efectua acțiunile definite de acest rol. Cu toate acestea, este posibil ca unele roluri să nu fie utilizate independent. De exemplu, pentru lansarea interactivă tratamente externe Puteți crea un rol separat și îl puteți adăuga tuturor utilizatorilor care trebuie să utilizeze procesarea externă.

Examinați în mod regulat jurnalele și protocoalele de funcționare a sistemului

Dacă este posibil, reglați și automatizați vizualizarea jurnalelor și a protocoalelor de funcționare a sistemului. Cu o configurare adecvată și o revizuire regulată a jurnalelor (filtrarea numai după evenimente importante), acțiunile neautorizate pot fi detectate din timp sau chiar prevenite în timpul fazei de pregătire.

Câteva caracteristici ale versiunii client-server

Această secțiune descrie unele dintre caracteristicile de operare ale opțiunii client-server și impactul lor asupra securității. Pentru o mai mare ușurință a citirii, se folosesc următoarele notații:

Atenţie! descrierea vulnerabilității

Stocarea informațiilor care controlează accesul la sistem

Stocarea unei liste de utilizatori de securitate a informațiilor

Toate informațiile despre lista de utilizatori ai acestei informații de securitate și rolurile disponibile pentru aceștia în ea sunt stocate în tabelul Params din baza de date MS SQL (vezi [ITS2]). Privind structura și conținutul acestui tabel, devine evident că toate informațiile despre utilizator sunt stocate într-o înregistrare cu valoarea câmpului FileName „users.usr”.

Deoarece presupunem că utilizatorii nu au acces la baza de date MS SQL, acest fapt în sine nu poate fi folosit de către un atacator, totuși, dacă este posibil să executați cod în MS SQL, aceasta „deschide ușa” pentru obținerea oricărui (! ) acces din 1C . Același mecanism (cu modificări minore) poate fi folosit și în versiunea de fișier a sistemului, care, ținând cont de caracteristicile versiunii de fișier, exclude complet aplicabilitatea acestuia în construirea de sisteme securizate.

Recomandare: Momentan, nu există nicio modalitate de a proteja complet aplicația de astfel de modificări, cu excepția utilizării declanșatoarelor la nivel de MS SQL Server, care, pe de altă parte, pot cauza probleme la actualizarea versiunii platformei sau modificarea listei de utilizatorii. Pentru a urmări astfel de modificări, puteți folosi jurnalul 1C (acordând atenție autentificărilor „suspecte” în modul configurator fără a specifica utilizatorul) sau puteți menține SQL Profiler în funcțiune constantă (ceea ce va avea un impact extrem de negativ asupra performanței sistemului) sau configura Alerte mecanism (cel mai probabil împreună folosind declanșatoare)

Stocarea informațiilor despre lista IS pe server

Pentru fiecare server de aplicații 1C, sunt stocate informații despre lista bazelor de date MS SQL conectate la acesta. Fiecare bază de informații folosește propriul șir de conexiune de la serverul de aplicații și serverul MS SQL pentru a funcționa. Informațiile despre bazele de informații înregistrate pe serverul de aplicații, împreună cu șirurile de conexiune, sunt stocate în fișierul srvrib.lst, care se află pe server în director.<Общие данные приложений>/1C/1Cv8 (de exemplu, C:/Documente și setări/Toți utilizatorii/Date aplicații/1C/1Cv8/srvrib.lst). Pentru fiecare sistem de securitate a informațiilor, este stocat un șir de conexiune complet, inclusiv parola de utilizator MS SQL atunci când se utilizează un model de autorizare MS SQL mixt. Prezența acestui fișier face posibilă teama de acces neautorizat la baza de date MS SQL, iar dacă, contrar recomandărilor, un utilizator privilegiat (de exemplu, „sa”) este folosit pentru a accesa cel puțin o bază de date, atunci în Pe lângă amenințarea la adresa securității informațiilor, există o amenințare la adresa întregului sistem folosind MS SQL.

Este interesant de remarcat faptul că utilizarea autorizației mixte și a autorizației Windows pe un server MS SQL duce la diferite tipuri de probleme la obținerea accesului la un anumit fișier. Deci, principalele proprietăți negative ale autorizației Windows vor fi:

• Operarea tuturor securității informațiilor pe serverul de aplicații și pe serverul MS SQL sub un singur set de drepturi (cel mai probabil redundante)
• Din procesul serverului de aplicații 1C (sau, în general, de la utilizatorul USER1CV8SERVER sau echivalentul acestuia) fără a specifica o parolă, vă puteți conecta cu ușurință la orice securitate a informațiilor fără a specifica o parolă

Pe de altă parte, poate fi mai dificil pentru un atacator să execute cod arbitrar din contextul utilizatorului USER1CV8SERVER decât să obțină fișierul specificat. Apropo, prezența unui astfel de fișier este un alt argument pentru distribuirea funcțiilor serverului pe diferite computere.

Recomandare: Fișierul srvrib.lst ar trebui să fie accesibil numai de către procesul serverului. Asigurați-vă că ați configurat auditarea pentru a modifica acest fișier.

Din păcate, implicit acest fișier aproape că nu este protejat de citire, ceea ce trebuie luat în considerare la implementarea sistemului. Opțiunea ideală ar fi ca serverul de aplicații să împiedice citirea și scrierea acestui fișier în timpul rulării (inclusiv citirea și scrierea de către conexiunile utilizatorilor care rulează pe acest server).

Lipsa autorizației la crearea securității informațiilor pe server

Atenţie! Eroarea de lipsă de autorizare a fost remediată în versiunea 8.0.14 a platformei 1C:Enterprise. În această versiune, a apărut conceptul „1C: Enterprise Server Administrator”, dar atâta timp cât lista de administratori este specificată pe server, sistemul funcționează așa cum este descris mai jos, așa că nu uitați de această posibilă caracteristică.

Probabil cea mai mare vulnerabilitate din această secțiune este capacitatea de a adăuga aproape nelimitat securitatea informațiilor la serverul de aplicații, drept urmare orice utilizator care obține acces la o conexiune la serverul de aplicații obține automat capacitatea de a rula cod arbitrar pe serverul de aplicații . Să ne uităm la asta cu un exemplu.

Sistemul trebuie instalat după cum urmează

• MS SQL Server 2000 (de exemplu, numele rețelei SRV1)
• Server 1C: Enterprise 8.0 (nume de rețea SRV2)
• Partea client 1C: Enterprise 8.0 (numele rețelei WS)

Se presupune că utilizatorul (denumit în continuare UTILIZATOR) care lucrează pe WS are cel puțin acces minim la unul dintre sistemele de securitate a informațiilor înregistrate pe SRV2, dar nu are acces privilegiat la SRV1 și SRV2. În general, combinația de funcții ale computerelor enumerate nu afectează situația. Sistemul a fost configurat ținând cont de recomandările din documentație și de pe discurile ITS. Situația este prezentată în Fig. 2.

• configurați securitatea COM+ pe serverul de aplicații astfel încât doar utilizatorii 1C să aibă dreptul de a se conecta la procesul serverului de aplicații (mai multe detalii [ITS12]);
• fișierul srvrib.lst trebuie să fie doar în citire pentru utilizatorul USER1CV8SERVER (pentru a adăuga o nouă securitate a informațiilor pe server, permiteți temporar scrierea);
• Pentru a vă conecta la MS SQL, utilizați numai protocolul TCP/IP, în acest caz puteți:
  • restricționați conexiunile folosind un firewall;
  • configurați utilizarea unui port TCP non-standard, ceea ce va complica conectarea IB 1C „din afară”;
  • utilizați criptarea datelor transmise între serverul de aplicații și serverul SQL;
• configurați firewall-ul serverului astfel încât utilizarea serverelor MS SQL terțe să fie imposibilă;
• utilizați instrumente de securitate intranet pentru a exclude posibilitatea apariției unui computer neautorizat în rețeaua locală (IPSec, politici de securitate de grup, firewall-uri etc.);
• Nu acordați în niciun caz utilizatorului USER1CV8SERVER drepturi administrative pe serverul de aplicații.

Utilizarea codului care rulează pe server

Când se utilizează versiunea client-server a 1C, dezvoltatorul poate distribui execuția codului între client și serverul de aplicații. Pentru ca codul (procedură sau funcție) să fie executat doar pe server, este necesar să îl plasați într-un modul general pentru care este setată proprietatea „Server” și, în cazul în care execuția modulului este permisă nu numai pe server, plasați codul în secțiunea restricționată „#If Server”:

#Dacă serverul Atunci
Funcția OnServer(Param1, Param2 = 0) Export // Această funcție, în ciuda simplității sale, este executată pe server
Param1 = Param1 + 12;
Return Param1;
EndFunction
#EndIf

Când utilizați cod care rulează pe server, trebuie să țineți cont de faptul că:

• codul rulează cu drepturi USER1CV8SERVER pe serverul de aplicații (sunt disponibile obiecte COM și fișiere server);
• toate sesiunile de utilizator sunt executate de o singură instanță a serviciului, deci, de exemplu, o depășire a stivei pe server va determina deconectarea tuturor utilizatorilor activi;
• depanarea modulelor de server este dificilă (de exemplu, nu puteți seta un punct de întrerupere în depanator), dar trebuie făcută;
• transferul controlului de la client la serverul de aplicații și înapoi poate necesita resurse semnificative cu volume mari de parametri transferați;
• utilizarea instrumentelor interactive (formulare, documente foaie de calcul, casete de dialog), rapoartele externe și prelucrarea în cod pe serverul de aplicații este imposibilă;
• nu este permisă utilizarea variabilelor globale (variabilele modulului de aplicație declarate cu indicația „Export”);

Pentru mai multe detalii, consultați [ITS15] și alte articole ITS.

Serverul de aplicații trebuie să aibă cerințe speciale de fiabilitate. Într-un sistem client-server construit corespunzător, trebuie îndeplinite următoarele condiții:

• nicio acțiune a aplicației client nu ar trebui să întrerupă funcționarea serverului (cu excepția cazurilor administrative);
• serverul nu poate executa codul de program primit de la client;
• resursele trebuie distribuite „echitabil” peste tot conexiuni client, asigurând disponibilitatea serverului indiferent de încărcarea curentă;
• în absența blocării datelor, conexiunile clientului nu ar trebui să afecteze munca celuilalt;
• nu pe server interfața cu utilizatorul, dar instrumentele de monitorizare și înregistrare trebuie dezvoltate;

În general, sistemul 1C este construit în așa fel încât să se apropie de aceste cerințe (de exemplu, este imposibil să forțați procesarea externă să fie efectuată pe server), dar mai există câteva caracteristici neplăcute, prin urmare:

Recomandare: Când dezvoltați un server de rulare, se recomandă să respectați principiul interfeței minime. Acestea. numărul de intrări în modulele server din aplicația client ar trebui să fie foarte limitat, iar parametrii ar trebui să fie strict reglementați. Recomandare: La primirea parametrilor procedurilor și funcțiilor pe server, este necesară validarea parametrilor (verificați dacă parametrii corespund tipului și intervalului de valori așteptat). Acest lucru nu se face în soluțiile standard, dar este foarte de dorit să introduceți validarea obligatorie în propriile dezvoltări. Recomandare: Când generați text de solicitare (și în special parametrul de comandă Run) pe partea serverului, nu utilizați șiruri primite de la aplicația client.

O recomandare generală ar fi să vă familiarizați cu principiile construcției sigure web-aplicații de baze de date și lucru pe principii similare. Asemănările sunt într-adevăr considerabile: în primul rând, ca o aplicație web, serverul de aplicații este un strat intermediar între baza de date și interfața cu utilizatorul (diferența principală este că serverul web formează interfața cu utilizatorul); în al doilea rând, din punct de vedere al securității, nu poți avea încredere în datele primite de la client, deoarece este posibilă lansarea de rapoarte și procesări externe.

Trecerea parametrilor

Trecerea parametrilor unei funcții (procedură) executată pe server este o problemă destul de delicată. Acest lucru se datorează în primul rând necesității de a le transfera între serverul de aplicații și procesele client. Când controlul trece din partea clientului în partea serverului, toți parametrii transmisi sunt serializați, transferați pe server, unde sunt „despacheți” și utilizați. Când treceți din partea serverului în partea clientului, procesul este invers. Trebuie remarcat aici că această schemă gestionează corect trecerea parametrilor prin referință și prin valoare. La trecerea parametrilor, se aplică următoarele restricții:

• Numai valorile nemodificabile (adică ale căror valori nu pot fi modificate) pot fi transferate între client și server (în ambele direcții): tipuri primitive, referințe, colecții universale, valori de enumerare a sistemului, stocare a valorilor. Dacă încercați să treceți altceva, aplicația client se blochează (chiar dacă serverul încearcă să treacă un parametru incorect).
• Nu este recomandat să transferați cantități mari de date atunci când treceți parametri (de exemplu, șiruri de mai mult de 1 milion de caractere), acest lucru poate afecta negativ performanța serverului.
• Nu puteți transmite parametri care conțin o referință ciclică, atât de la server la client, cât și înapoi. Dacă încercați să treceți un astfel de parametru, aplicația client se blochează (chiar dacă serverul încearcă să treacă parametrul incorect).
• Nu este recomandat să transferați colecții de date foarte complexe. Când încercați să treceți un parametru cu un nivel de imbricare foarte mare, serverul se blochează (! ).

Atenţie! Cea mai enervantă caracteristică în acest moment este probabil eroarea de a transmite colecții complexe de valori. Deci, de exemplu, codul: Nesting Level = 1250;
M = matrice nouă;
PassedParameter = M;
Pentru cont = 1 după nivelul ciclului de imbricare
MVInt = matrice nouă;
M.Add(MVInt);
M = MVint;
EndCycle;
ServerFunction(PassedParameter);

Conduce la o oprire de urgență a serverului cu deconectarea tuturor utilizatorilor, iar acest lucru are loc înainte ca controlul să fie transferat codului în limbajul încorporat.

Utilizarea funcțiilor nesigure pe partea serverului.

Nu toate instrumentele de limbaj încorporate pot fi utilizate în codul executat pe serverul de aplicații, dar chiar și printre instrumentele disponibile există multe constructe „problematice” care pot fi clasificate aproximativ după cum urmează:

• capabil să ofere capacitatea de a executa cod care nu este conținut în configurație (grupul „Execuție cod”)
• capabil să furnizeze aplicației client informații despre fișier și sistem de operare utilizator sau să efectueze acțiuni care nu sunt legate de lucrul cu date („Încălcarea drepturilor”)
• capabil să provoace o prăbușire a serverului sau să utilizeze resurse foarte mari (grupul de blocare a serverului)
• capabil să provoace o defecțiune a clientului (grup de eșecuri client) – acest tip nu este luat în considerare. Exemplu: transmiterea unei valori modificabile către server.
• erori în algoritmii de programare (bucle nesfârșite, recursivitate nelimitată etc.) („Erori de programare”)

Principalele modele problematice cunoscute de mine (cu exemple) sunt enumerate mai jos:

Executarea procedurii(<Строка>)

Cod de executare. Vă permite să executați o bucată de cod care îi este transmisă ca valoare șir. Când este utilizat pe server, trebuie să vă asigurați că datele primite de la client nu sunt folosite ca parametru. De exemplu, următoarea utilizare nu este permisă:

#Dacă serverul Atunci
Export ProcedureOnServer(Param1).
Execute(Param1);
Sfârșitul procedurii
#EndIf

Tastați „COMObject” (constructor New COMObject(<Имя>, <Имя сервера>))

Creează un obiect COM aplicație externă cu drepturi USER1CV8SERVER pe serverul de aplicații (sau pe alt computer specificat). Când este utilizat pe un server, asigurați-vă că parametrii nu sunt transferați de la aplicația client. Cu toate acestea, pe partea de server este eficient să utilizați această caracteristică atunci când se importă/exportă, se trimite date prin Internet, se implementează funcții non-standard etc.

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

Încălcarea drepturilor și executarea codului. Similar cu cel precedent, obținerea doar a obiectului COM corespunzător fișierului.

Proceduri și funcții ComputerName(), TemporaryFileDirectory(), ProgramDirectory(), WindowsUsers()

Încălcarea drepturilor. Prin executarea lor pe server, ele vă permit să aflați detaliile organizării subsistemului server. Când sunt utilizate pe un server, asigurați-vă că datele fie nu sunt transferate către client, fie că nu sunt accesibile operatorilor fără permisiunea corespunzătoare. Acordați o atenție deosebită faptului că datele pot fi transmise înapoi într-un parametru transmis prin referință.

Proceduri și funcții pentru lucrul cu fișiere (CopyFile, FindFiles, MergeFiles și multe altele), precum și cu tipuri de fișiere.

Încălcarea drepturilor. Acestea permit, prin executarea lor pe server, să obțină acces partajat la fișierele locale (și situate în rețea) accesibile sub drepturile de utilizator USER1CV8SERVER. Dacă este folosit în mod conștient, atunci este posibilă implementarea eficientă a sarcinilor precum importul/exportarea datelor pe server.

Asigurați-vă că vă verificați drepturile de utilizator 1C înainte de a utiliza aceste funcții. Pentru a verifica drepturile utilizatorului, puteți utiliza următoarea construcție în modulul server:

#Dacă serverul Atunci
Procedură PerformWorkWithFile() Export
RoleAdministrator = Metadata.Roles.Administrator;
Utilizator = SessionParameters.CurrentUser;
Dacă User.Roles.Contains(RoleAdministrator) Atunci
//Codul pentru lucrul cu fișierele este executat aici
endIf;
#EndIf

Asigurați-vă că verificați parametrii dacă utilizați aceste proceduri și funcții, altfel există riscul de a provoca accidental sau cu bună știință daune ireparabile serverului de aplicații 1C, de exemplu, atunci când executați următorul cod pe server:

Cale = „C:\Documents and Settings\All Users\Application Data\1C\1Cv8\”;
MoveFile(Cale + „srvrib.lst”, Cale + „Here’sWhereTheFileGoes”);

După executarea unui astfel de cod pe server, dacă utilizatorul USER1CV8SERVER are dreptul de a-l schimba, așa cum este descris mai sus, și după repornirea procesului serverului (în mod implicit, la 3 minute după ce toți utilizatorii părăsesc), va apărea o mare întrebare despre pornirea serverului. . Dar este și posibil să ștergeți complet fișierele...

Tipuri „XBase”, „BinaryData”, „XML Reader”, „XML Writer”, „XSL Transformation”, „ZipFile Writer”, „ZipFile Reader”, „Text Reader”, „Text Writer”

Încălcarea drepturilor. Acestea permit, prin executarea lor pe server, accesul la fișiere locale (și aflate în rețea) de anumite tipuri și le citesc/scriu sub drepturile de utilizator USER1CV8SERVER. Dacă este utilizat în mod conștient, este posibilă implementarea eficientă a unor sarcini precum importarea/exportarea datelor pe server, înregistrarea în jurnal a funcționării anumitor funcții și rezolvarea sarcinilor administrative. În general, recomandările coincid cu paragraful anterior, dar ar trebui să luați în considerare posibilitatea de a transfera date din aceste fișiere (dar nu obiecte de toate aceste tipuri) între părțile client și server.

Tastați „Informații de sistem”

Încălcarea drepturilor. Vă permite să obțineți date despre serverul de aplicație în cazul utilizării incorecte și transferul datelor către partea client a aplicației. Este recomandabil să limitați dreptul de utilizare în timpul utilizării.

Tipuri „InternetConnection”, „InternetMail”, „InternetProxy”, „HTTPConnection”, „FTPConnection”

Încălcarea drepturilor. Când este utilizat pe un server, se conectează la un computer la distanță de la un server de aplicații sub drepturile USER1CV8SERVER. Recomandări:

• Controlul parametrilor la apelarea metodelor.
• Controlul drepturilor utilizatorului 1C.
• Restricții severe privind drepturile utilizatorului USER1CV8SERVER de a accesa rețeaua.
• Configurați corect firewall-ul pe serverul de aplicații 1C.

Când este utilizat corect, este convenabil să organizați, de exemplu, trimiterea de e-mailuri de la un server de aplicații.

Tipuri „InformationBaseUserManager”, „InformationBaseUser”

Încălcarea drepturilor. Dacă este utilizat incorect (într-un modul privilegiat), este posibil să adăugați utilizatori sau să modificați parametrii de autorizare ai utilizatorilor existenți.

Formatul funcției

Blocare server. Da! Această funcție aparent inofensivă, dacă parametrii ei nu sunt controlați și executați pe server, poate cauza blocarea aplicației server. Eroarea apare la formatarea numerelor și la utilizarea modului de afișare a zerourilor inițiale și a unui număr mare de caractere, de exemplu

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

Sper ca aceasta eroare sa fie corectata in urmatoarele versiuni ale platformei, dar intre timp, in toate apelurile catre aceasta functie care pot fi executate pe server, verificati parametrii de apel.

Proceduri și funcții pentru salvarea valorilor (ValueInRowInt, ValueInFile)

Blocare server. Aceste funcții nu gestionează referințele circulare în colecții sau imbricarea foarte adâncă, așa că se pot bloca în unele cazuri foarte speciale.

Erori la limită și valorile parametrilor speciali în funcții. Controlul execuției.

Una dintre problemele pe care le puteți întâlni atunci când utilizați un server este „responsabilitatea” mare a funcțiilor serverului (posibilitatea ca întreaga aplicație server să se prăbușească din cauza unei erori la o conexiune și a utilizării unui „spațiu de resurse” pentru toate conexiunile) . De aici și necesitatea de a controla principalii parametri de rulare:

• Pentru funcțiile de limbă încorporate, verificați parametrii de lansare a acestora (un exemplu bun este funcția „Format”)
• Când utilizați bucle, asigurați-vă că condiția de ieșire a buclei este îndeplinită. Dacă bucla este potențial infinită, limitați artificial numărul de iterații: MaximumIterationCounterValue = 1000000;
  Contor de iterație = 1;
  Pa
  FunctionWhichMayNotReturnFalseValue()
  AND (Număr de iterații<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Corpul buclei
  Contor de iterații = Contor de iterații + 1;
  EndCycle;
  Dacă Iteration Counter>MaximumValue Of Iteration Counter, atunci
  //.... gestionează evenimentul unei execuții de buclă excesiv de lungă
  endIf;

• Când utilizați recursiunea, limitați nivelul maxim de imbricare.
• Când formați și executați interogări, încercați să preveniți selecțiile și selecțiile foarte lungi ale unei cantități mari de informații (de exemplu, când utilizați condiția „ÎN IERARHIE”, nu utilizați o valoare goală)
• Când proiectați o bază de informații, asigurați o rezervă suficient de mare de adâncime de biți pentru numere (în caz contrar, adăugarea și înmulțirea devin necomutative și non-asociative, ceea ce face dificilă depanarea)
• În interogările executabile, verificați logica de operare pentru prezența valorilor NULL și funcționarea corectă a condițiilor și expresiilor de interogare folosind NULL.
• Când utilizați colecții, controlați capacitatea de a le transfera între serverul de aplicații și partea client.

Utilizarea accesului la terminal la partea clientului pentru a restricționa accesul

Puteți găsi adesea recomandări de utilizare a accesului la terminal pentru a limita accesul la date și pentru a îmbunătăți performanța prin executarea codului client pe serverul terminal. Da, dacă este configurat corect, utilizarea accesului la terminal poate crește într-adevăr nivelul general de securitate a sistemului, dar, din păcate, puteți întâlni adesea faptul că, odată cu utilizarea practică, securitatea sistemului scade doar. Să încercăm să ne dăm seama cu ce se leagă asta. Acum există două mijloace comune de organizare a accesului la terminal, acestea sunt Microsoft Terminal Services (protocol RDP) și Citrix Metaframe Server (protocol ICA). În general, instrumentele Citrix oferă opțiuni de administrare a accesului mult mai flexibile, dar prețul acestor soluții este mult mai mare. Vom lua în considerare doar caracteristicile de bază comune ambelor protocoale care pot reduce nivelul general de securitate. Există doar trei pericole principale atunci când utilizați accesul la terminal:

• Abilitatea de a bloca activitatea altor utilizatori prin sechestrarea unor cantități excesive de resurse
• Acces la datele altor utilizatori.
• Copierea neautorizată a datelor de pe serverul terminal pe computerul utilizatorului

În orice caz, Serviciile terminale vă permit să:

• Creșteți fiabilitatea muncii (dacă există o defecțiune la computerul terminal, utilizatorul poate continua să lucreze ulterior din același loc)
• Restricționați accesul la aplicația client și la fișierele pe care le salvează.
• Transferați sarcina de calcul de la stația de lucru a utilizatorului pe serverul de acces la terminal
• Gestionați setările sistemului mai centralizat. Pentru utilizatori, setările salvate vor fi valabile indiferent de computerul de pe care s-au conectat la sistem.
• În unele cazuri, puteți utiliza o soluție terminală pentru accesul de la distanță la sistem.

Este necesar să se limiteze numărul de conexiuni posibile la serverul terminal pentru un utilizator

Din cauza „lăcomiei” aplicației client 1C în ceea ce privește resursele, este imperativ să se limiteze numărul maxim de conexiuni simultane ale unui utilizator (operator) la serverul terminal. O conexiune utilizată activ poate folosi până la 300 MB de memorie cu o singură instanță a aplicației. Pe lângă memorie, timpul CPU este utilizat în mod activ, ceea ce, de asemenea, nu contribuie la stabilitatea utilizatorilor acestui server. În același timp cu prevenirea utilizării excesive a resurselor serverului, o astfel de restricție poate împiedica utilizarea resurselor altcuiva. cont. Implementat prin setările standard ale serverului terminal.

Nu ar trebui să permiteți mai mult de una sau două aplicații client 1C să ruleze simultan într-o singură conexiune

Dictată de aceleași motive ca în paragraful precedent, dar mai greu de implementat din punct de vedere tehnic. Problema este că este aproape imposibil să preveniți repornirea 1C folosind instrumente de server terminal (de ce va fi explicat mai jos), așa că trebuie să implementați această caracteristică la nivelul soluției aplicației (care nu este, de asemenea, o soluție bună, deoarece sesiunile pot rămâne „atârnate” pentru o perioadă de timp Dacă aplicația este terminată incorect, este nevoie de a rafina soluția aplicației în modulul de aplicație și unele cărți de referință, ceea ce va complica utilizarea actualizărilor de la 1C). Este foarte de dorit să lase utilizatorului posibilitatea de a rula 2 aplicații pentru a putea rula unele acțiuni (de exemplu, generarea de rapoarte) în fundal - aplicația client, din păcate, este de fapt cu un singur thread.

Nu este recomandat să acordați drepturi de acces la serverul terminal utilizatorilor care au dreptul de a rula sarcini de calcul care necesită mult resurse în 1C sau să împiedicați o astfel de lansare în timp ce alți utilizatori lucrează activ.

Desigur, este mai bine să lăsați accesul la serverul terminal doar utilizatorilor care nu folosesc sarcini precum data mining, diagrame geografice, import/export și alte sarcini care încarcă serios partea client a aplicației. Dacă mai există necesitatea de a permite astfel de sarcini, atunci este necesar să: anunțați utilizatorul că aceste sarcini pot afecta performanța altor utilizatori, să înregistrați începutul și sfârșitul unui astfel de proces în jurnal, să permiteți execuția numai la un mediu reglementat. timp, etc.

Este necesar să vă asigurați că fiecare utilizator are drepturi de scriere doar pentru directoarele strict definite de pe serverul terminal și că alți utilizatori nu au acces la acestea.

În primul rând, dacă nu limitați capacitatea de a scrie în directoare partajate (cum ar fi directorul în care este instalat 1C), atunci rămâne posibil ca un atacator să schimbe comportamentul programului pentru toți utilizatorii. În al doilea rând, datele unui utilizator (fișiere temporare, fișiere pentru salvarea setărilor de raport etc.) nu trebuie în niciun caz să fie accesibile unui alt utilizator al serverului terminal - în general, în timpul configurării normale, această regulă este respectată. În al treilea rând, atacatorul are în continuare posibilitatea de a „împrăștia” partiția, astfel încât să nu mai rămână spațiu pe hard disk. Știu că mă vor obiecta că sistemul de operare Windows, începând cu Windows 2000, are un mecanism de cotă, dar acesta este un mecanism destul de scump și practic nu am văzut niciodată vreo utilizare reală a acestuia.

Dacă problemele anterioare de configurare a accesului au fost în general destul de ușor de implementat, atunci o sarcină atât de simplă (aparent) precum reglementarea accesului utilizatorilor la fișiere nu este implementată în mod trivial. În primul rând, dacă mecanismul de cotă nu este utilizat, atunci fișierele mari pot fi salvate. În al doilea rând, sistemul este construit în așa fel încât să fie aproape întotdeauna posibil să salvezi fișierul, astfel încât să fie disponibil pentru alt utilizator.

Având în vedere că sarcina este dificil de rezolvat complet, se recomandă auditarea majorității evenimentelor fișierelor

Este necesar să interziceți conectarea (matarea) dispozitivelor de disc, imprimantelor și clipboard-ului stației de lucru client.

În RDP și ICA, este posibilă organizarea conexiunii automate a discurilor, imprimantelor, porturilor com clipboard ale computerului terminal la server. Dacă această oportunitate există, atunci este aproape imposibil să previi lansarea codului străin pe serverul terminal și salvarea datelor de la 1C pe clientul de acces la terminal. Permiteți aceste funcții numai pentru cei cu drepturi administrative.

Accesul la fișierele de rețea de la serverul terminal ar trebui să fie limitat.

Dacă acest lucru nu se face, utilizatorul va putea din nou să ruleze cod nedorit sau să salveze date. Deoarece jurnalul obișnuit nu urmărește evenimentele fișierului (apropo, o idee bună pentru implementarea de către dezvoltatorii de platformă) și este aproape imposibil să configurați un audit de sistem în întreaga rețea (nu există suficiente resurse pentru a-l menține), este mai bine ca utilizatorul să poată trimite date fie la tipărire, fie prin e-mail. Acordați o atenție deosebită să vă asigurați că serverul terminal nu funcționează direct cu mediile amovibile ale utilizatorilor.

În niciun caz nu trebuie să lăsați serverul de aplicații pe serverul terminal atunci când creați un sistem securizat.

Dacă serverul de aplicații rulează pe același computer cu aplicațiile client, atunci există multe oportunități de a-i perturba funcționarea normală. Dacă dintr-un motiv oarecare este imposibil să separați funcțiile serverului terminal și serverul de aplicații, atunci acordați o atenție deosebită accesului utilizatorului la fișierele utilizate de serverul de aplicații.

Este necesar să excludem posibilitatea de a rula toate aplicațiile cu excepția 1C:Enterprise pe serverul terminal.

Aceasta este una dintre cele mai dificile dorințe de implementat. Să începem cu faptul că trebuie să configurați corect politica de securitate de grup în domeniu. Toate șabloanele administrative și politicile de restricție software trebuie configurate corect. Pentru a vă testa, asigurați-vă că cel puțin următoarele caracteristici sunt blocate:

Complexitatea implementării acestei cerințe duce adesea la posibilitatea lansării unei sesiuni 1C „extra” pe serverul terminal (chiar dacă alte aplicații sunt limitate, este fundamental imposibil să interziceți lansarea 1C folosind Windows).

Luați în considerare limitările jurnalului obișnuit (toți utilizatorii folosesc programul de pe un singur computer)

Evident, deoarece utilizatorii deschid 1C în modul terminal, atunci serverul terminal va fi înregistrat în jurnal. Jurnalul nu indică de la ce computer s-a conectat utilizatorul.

Terminal Server - Protecție sau Vulnerabilitate?

Deci, după ce luăm în considerare principalele caracteristici ale terminalului nord, putem spune că nordul terminalului poate ajuta potențial la automatizare pentru a distribui sarcina de calcul, dar construirea unui sistem securizat este destul de dificilă. Unul dintre cazurile în care utilizarea unui server terminal este cea mai eficientă este atunci când rulați 1C fără Windows Explorer în modul ecran complet pentru utilizatorii cu funcționalitate limitată și o interfață specializată.

Lucrarea părții client

Utilizarea Internet Explorer (IE)

Una dintre condițiile pentru funcționarea normală a părții client 1C este utilizarea componentelor Internet Explorer. Trebuie să fii foarte atent cu aceste componente.

Atenţie! În primul rând, dacă un modul spyware sau adware este „atașat” la IE, atunci se va încărca chiar dacă vizualizați orice fișier HTML în 1C. Până acum nu am văzut nicio utilizare conștientă a acestei caracteristici, dar am văzut într-una dintre organizații un modul „spion” încărcat de la una dintre rețelele pornografice cu 1C care rulează (programul antivirus nu a fost actualizat, simptome pentru care au fost detectate : la configurarea paravanului de protecție, era clar că 1C încerca să se conecteze portul 80 la un site porno). De fapt, acesta este un alt argument în favoarea faptului că protecția ar trebui să fie cuprinzătoare

Atenţie! În al doilea rând, sistemul 1C permite utilizarea filmelor Flash, obiectelor ActiveX, VBScript în documentele HTML afișate, trimiterea de date pe Internet, chiar deschiderea fișierelor PDF (!), deși în acest din urmă caz ​​cere „deschide sau salva”... În general, tot ceea ce îți dorește inima. Un exemplu de utilizare nu pe deplin rezonabilă a capabilităților de vizualizare și editare HTML încorporate:

• Creați un nou document HTML (Fișier -> Nou -> Document HTML).
• Accesați fila „Text” a documentului gol.
• Eliminați textul (în întregime).
• Accesați fila „Vizualizare” a acestui document
• Folosind drag-n-drop, mutați un fișier cu o extensie SWF (acestea sunt fișiere de film Flash) dintr-un Explorer deschis într-o fereastră de document, de exemplu din memoria cache a browserului, deși puteți folosi și o jucărie FLASH pentru distracție.
• Ce dragut! Puteți rula o jucărie pe 1C!

Din punct de vedere al securității sistemului, acest lucru este complet greșit. Până acum nu am văzut niciun atac special asupra 1C prin această vulnerabilitate, dar cel mai probabil va fi o chestiune de timp și de valoarea informațiilor tale.

Există și alte probleme minore care apar atunci când lucrați cu un câmp de document HTML, dar principalele sunt cele două enumerate. Deși, dacă abordați aceste funcții în mod creativ, puteți organiza capacități de interfață cu adevărat uimitoare pentru a lucra cu 1C.

Utilizarea rapoartelor externe și prelucrarea.

Atenţie! Rapoarte și procesări externe – pe de o parte – mod convenabil implementarea unor formulare tipărite suplimentare, raportări de reglementare, rapoarte specializate, pe de altă parte, o modalitate potențială de a ocoli multe restricții de securitate a sistemului și de a perturba funcționarea serverului de aplicații (de exemplu, vezi mai sus în „Parametrii de trecere”). În sistemul 1C există un parametru special în setul de drepturi pentru rolul „Deschiderea interactivă a prelucrării externe”, dar acest lucru nu rezolvă complet problema - pentru o soluție completă este necesar să restrângem cercul de utilizatori care pot gestiona formulare tipărite externe, rapoarte de reglementare și alte capabilități standard ale soluțiilor standard implementate folosind tratamente externe. De exemplu, în mod implicit în UPP, toate rolurile de utilizator principale au capacitatea de a lucra cu un director de formulare imprimate suplimentare, iar aceasta, de fapt, este capacitatea de a utiliza orice procesare externă.

Utilizarea mecanismelor standard pentru soluții și platforme standard (schimb de date)

Unele dintre mecanismele standard sunt potențial periculoase și în moduri neașteptate.

Imprimarea listelor

Orice listă (de exemplu, un director sau un registru de informații) din sistem poate fi tipărită sau salvată într-un fișier. Pentru a face acest lucru, trebuie doar să utilizați funcția standard disponibilă din meniul contextual și din meniul „Acțiuni”:

Rețineți că practic tot ceea ce vede utilizatorul în liste poate fi trimis în fișiere externe. Singurul lucru pe care îl putem sfătui este să păstrăm un jurnal al tipăririi documentelor pe serverele de imprimare. Pentru formele deosebit de critice, este necesar să configurați panoul de acțiuni asociat câmpului tabel protejat, astfel încât capacitatea de a afișa o listă să nu fie disponibilă din acest panou și să dezactivați meniul contextual (vezi Figura 6).

Schimb de date într-o bază de date distribuită

Formatul de schimb de date este destul de simplu și este descris în documentație. Dacă utilizatorul are capacitatea de a înlocui mai multe fișiere, el poate face modificări neautorizate în sistem (deși aceasta este o sarcină destul de intensivă în muncă). Capacitatea de a crea o bază de date periferică atunci când se utilizează planuri de schimb de baze de date distribuite nu ar trebui să fie disponibilă operatorilor obișnuiți.

Schimbul de date standard XML

În schimbul de date standard, care este utilizat pentru schimbul între configurațiile standard (de exemplu, „Gestionarea comerțului” și „Contabilitatea întreprinderii”), este posibil să se specifice handler-uri de evenimente pentru încărcarea și descărcarea obiectelor în regulile de schimb. Acest lucru este implementat prin obținerea unui handler din fișier și prin procedura „Run()” pentru procesarea standard a încărcării și descărcarii fișierelor (procedura „Run()” este lansată pe partea clientului). Evident, nu este dificil să creezi un astfel de fișier de schimb fals care va efectua acțiuni rău intenționate. Pentru majoritatea rolurilor de utilizator ale soluțiilor standard, partajarea este permisă în mod implicit.

Recomandare: restricționați accesul la schimbul XML pentru majoritatea utilizatorilor (lăsându-l doar administratorilor de securitate a informațiilor). Păstrați jurnalele rulărilor acestei procesări, salvând fișierul de schimb, de exemplu, trimițându-l prin e-mail administrator de securitate a informațiilor înainte de descărcare.

Utilizarea rapoartelor generice, în special a Consolei de rapoarte

O altă problemă este accesul implicit al utilizatorilor la rapoartele generice, în special raportul Report Console. Acest raport se caracterizează prin faptul că vă permite să executați aproape orice solicitări la securitatea informațiilor și, chiar dacă sistemul de drepturi 1C (inclusiv RLS) este configurat destul de strict, permite utilizatorului să obțină o mulțime de informații „în plus” și forțează serverul să execute o solicitare care va consuma toate sistemele de resurse.

Utilizarea modului ecran complet (modul desktop)

Una dintre modalitățile eficiente de organizare a interfețelor specializate cu acces limitat la funcționalitatea programului este modul ecran complet al formei principale (și, eventual, numai) a interfeței utilizate. În acest caz, nu există probleme de accesibilitate, de exemplu, meniul „Fișier” și toate acțiunile utilizatorului sunt limitate de capacitățile formularului utilizat. Pentru mai multe detalii, consultați „Caracteristicile implementării modului desktop” pe discul ITS.

Backup

Backup-ul pentru versiunea client-server a 1C poate fi efectuat în două moduri: încărcarea datelor într-un fișier cu extensia dt și crearea de copii de rezervă folosind SQL. Prima metodă are multe dezavantaje: este necesar acces exclusiv, crearea unei copii în sine durează mult mai mult, în unele cazuri (dacă structura de securitate a informațiilor este încălcată) crearea unei arhive este imposibilă, dar există un avantaj - dimensiunea minimă a arhiva. Pentru backup SQL, opusul este adevărat: crearea unei copii are loc în fundal folosind serverul SQL, datorită structurii simple și lipsei de compresie - acesta este un proces foarte rapid și atâta timp cât integritatea fizică a SQL-ului baza de date nu este spartă, se realizează backup-ul, dar dimensiunea copiei coincide cu cea adevărată dimensiunea securității informațiilor în starea extinsă (comprimarea nu se realizează). Datorită avantajelor suplimentare ale sistemului de backup MS SQL, este mai indicat să îl utilizați (sunt permise 3 tipuri de backup: copie completă, diferențială, jurnal de tranzacții; este posibil să se creeze joburi executate regulat; o copie de rezervă și o copie de rezervă. sistemul sunt implementate rapid; este posibil să se prezică dimensiunea spațiului necesar pe disc etc.). Principalele puncte ale organizării unui backup din punct de vedere al securității sistemului sunt:

• Necesitatea de a alege o locație de stocare pentru copii de rezervă, astfel încât acestea să nu fie accesibile utilizatorilor.
• Necesitatea stocării backup-urilor la distanță fizică de serverul MS SQL (în caz de dezastre naturale, incendii, atacuri etc.)
• Abilitatea de a acorda drepturi de a începe o copie de rezervă unui utilizator care nu are acces la copii de rezervă.

Pentru mai multe detalii, consultați documentația MS SQL.

Criptarea datelor

Pentru a proteja datele de accesul neautorizat, sunt adesea folosite diverse instrumente criptografice (atât software, cât și hardware), dar fezabilitatea lor depinde în mare măsură de aplicarea corectă și de securitatea generală a sistemului. Vom analiza criptarea datelor în diferite etape ale transmiterii și stocării datelor folosind cele mai comune mijloace și principalele erori în proiectarea sistemului folosind instrumente criptografice.

Există mai multe etape principale ale procesării informațiilor care pot fi protejate:

• Transfer de date între partea client a sistemului și serverul de aplicații
• Transferul de date între serverul de aplicații și MS SQL Server
• Date stocate pe MS SQL Server (fișiere de date pe disc fizic)
• Criptarea datelor stocate în securitatea informațiilor
• Date externe (în legătură cu securitatea informațiilor)

Pentru datele stocate pe partea clientului și pe serverul de aplicații (setările utilizatorului salvate, lista de securitate a informațiilor etc.), criptarea este justificată doar în cazuri foarte rare și, prin urmare, nu este luată în considerare aici. Când folosim instrumente criptografice, nu trebuie să uităm că utilizarea lor poate reduce semnificativ performanța sistemului în ansamblu.

Informații generale despre protecția criptografică a conexiunilor de rețea atunci când se utilizează protocolul TCP/IP.

Fără securitate, toate conexiunile de rețea sunt vulnerabile la supravegherea și accesul neautorizat. Pentru a le proteja, puteți utiliza criptarea datelor la nivel de protocol de rețea. Pentru a cripta datele transmise într-o rețea locală, instrumentele IPSec furnizate de sistemul de operare sunt cel mai des folosite.

Instrumentele IPSec oferă criptarea datelor transmise folosind algoritmi DES și 3DES, precum și verificarea integrității utilizând funcțiile hash MD5 sau SHA1. IPSec poate funcționa în două moduri: modul de transport și modul tunel. Modul de transport este mai potrivit pentru securizarea conexiunilor într-o rețea locală. Modul tunel poate fi folosit pentru a organiza conexiuni VPN între segmente separate de rețea sau pentru a proteja o conexiune la distanță la o rețea locală prin canale de date deschise.

Principalele avantaje ale acestei abordări sunt:

• Posibilitatea de gestionare centralizată a securității folosind instrumente Active Directory.
• Posibilitatea de a exclude conexiunile neautorizate la serverul de aplicații și serverul MS SQL (de exemplu, este posibil să se protejeze împotriva adăugării neautorizate de securitate a informațiilor pe serverul de aplicații).
• Eliminarea „ascultării” traficului de rețea.
• Nu este nevoie să schimbați comportamentul programelor de aplicație (în acest caz 1C).
• Natura standard a unei astfel de soluții.

Cu toate acestea, această abordare are limitări și dezavantaje:

• IPSec nu protejează datele de interferențe și interceptări direct pe computerele sursă și destinație.
• Cantitatea de date transferate prin rețea este puțin mai mare decât fără utilizarea IPSec.
• Când utilizați IPSec, sarcina procesorului central este puțin mai mare.

O descriere detaliată a implementării instrumentelor IPSec depășește domeniul de aplicare al acestui articol și necesită o înțelegere a principiilor de bază ale funcționării protocolului IP. Pentru a configura corect securitatea conexiunii, vă rugăm să citiți documentația relevantă.

Separat, este necesar să se menționeze mai multe aspecte ale acordului de licență cu 1C atunci când se organizează conexiuni VPN. Faptul este că, în ciuda absenței restricțiilor tehnice, atunci când conectați mai multe segmente ale unei rețele locale sau accesul de la distanță al unui computer individual la o rețea locală, sunt de obicei necesare mai multe consumabile de bază.

Criptarea datelor atunci când sunt transferate între partea client a sistemului și serverul de aplicații.

Pe lângă criptarea la nivel de protocol de rețea, este posibilă criptarea datelor la nivel de protocol COM+, care este menționat în articolul „Reglementarea accesului utilizatorilor la baza de informații în versiunea client-server” al ITS. Pentru a-l implementa, trebuie să setați nivelul de autentificare pentru apeluri la „Confidențialitate pachet” pentru aplicația 1CV8 în „Servicii componente”. Când este setat în acest mod, pachetul este autentificat și criptat, inclusiv datele și identitatea și semnătura expeditorului.

Criptarea datelor atunci când sunt transferate între serverul de aplicații și MS SQL Server

MS SQL Server oferă următoarele instrumente pentru criptarea datelor:

• Este posibil să utilizați Secure Sockets Layer (SSL) atunci când transferați date între serverul de aplicații și MS SQL Server.
• Când utilizați biblioteca de rețea Multiprotocol, criptarea datelor este utilizată la nivel RPC. Aceasta este o criptare potențial mai slabă decât utilizarea SSL.
• Dacă se folosește protocolul de schimb de memorie partajată (acest lucru se întâmplă dacă serverul de aplicații și serverul MS SQL sunt situate pe același computer), atunci criptarea nu este utilizată în niciun caz.

Pentru a stabili necesitatea criptării tuturor datelor transmise pentru un anumit server MS SQL, trebuie să utilizați utilitarul „Server Network Utility”. Rulați-l și în fila „General”, bifați caseta de selectare „Forțare criptare protocol”. Metoda de criptare este selectată în funcție de cea utilizată de aplicația client (adică, serverul de aplicații 1C). Pentru a utiliza SSL, trebuie să configurați corect serviciul de certificate în rețeaua dvs.

Pentru a seta necesitatea de a cripta toate datele transmise pentru un anumit server de aplicații, trebuie să utilizați utilitarul „Client Network Utility” (de obicei situat în „C:\WINNT\system32\cliconfg.exe”). Ca și în cazul precedent, în fila „General”, bifați caseta de selectare „Forțare criptare protocol”.

Merită să luați în considerare faptul că utilizarea criptării în acest caz poate avea un impact semnificativ asupra performanței sistemului, mai ales atunci când se utilizează interogări care returnează cantități mari de informații.

Pentru a proteja mai deplin conexiunea dintre serverul de aplicații și MS SQL Server atunci când utilizați protocolul TCP/IP, vă putem recomanda câteva modificări ale setărilor implicite.

În primul rând, puteți seta un alt port decât cel standard (portul 1433 este utilizat în mod implicit). Dacă decideți să utilizați un port TCP non-standard pentru schimbul de date, vă rugăm să rețineți că:

• Serverul MS SQL și serverul de aplicații trebuie să utilizeze același port.
• Când utilizați firewall-uri, acest port trebuie să fie permis.
• Nu puteți seta un port care poate fi utilizat de alte aplicații de pe serverul MS SQL. Pentru referință, puteți utiliza http://www.ise.edu/in-notes/iana/assignments/port-numbers (adresă preluată din SQL Server Books Online).
• Când utilizați mai multe instanțe ale serviciului MS SQL Server, asigurați-vă că citiți documentația MS SQL pentru configurare (secțiunea „Configurarea conexiunilor de rețea”).

În al doilea rând, în setările protocolului TCP/IP de pe serverul MS SQL, puteți seta marcajul „Ascunde serverul”, care interzice răspunsurile la solicitările de difuzare pentru această instanță a serviciului MS SQL Server.

Criptarea datelor MS SQL stocate pe disc

Există o selecție destul de mare de software și hardware pentru criptarea datelor aflate pe un disc local (aceasta include capacitatea standard Windows de a utiliza EFS, utilizarea cheilor eToken și programe terțe, cum ar fi Jetico Bestcrypt sau PGPDisk). Una dintre sarcinile principale îndeplinite de aceste instrumente este protejarea datelor în cazul pierderii media (de exemplu, atunci când un server este furat). Este de remarcat în special faptul că Microsoft nu recomandă stocarea bazelor de date MS SQL pe medii criptate, iar acest lucru este destul de justificat. Principala problemă în acest caz este o scădere semnificativă a productivității și posibile probleme fiabilitatea din defecțiuni. Al doilea factor care complică viața administratorului de sistem este necesitatea de a asigura disponibilitatea tuturor fișierelor de bază de date în momentul în care serviciul MS SQL le accesează pentru prima dată (adică este de dorit ca acțiunile interactive să fie excluse atunci când se conectează un mediu criptat).

Pentru a evita o scădere vizibilă a performanței sistemului, puteți utiliza capacitatea MS SQL de a crea baze de date în mai multe fișiere. Desigur, în acest caz, baza de date MS SQL nu trebuie creată de serverul 1C la crearea bazei de informații, ci trebuie creată separat. Un exemplu de script TSQL cu comentarii este dat mai jos:

USE master
MERGE
-- Creați o bază de date SomeData,
CREAȚI BAZĂ DE DATE SomeData
-- ale căror date se află în întregime în grupul de fișiere PRIMARY.
PE PRIMAR
-- Fișierul de date principal este localizat pe un suport criptat (unitatea logică E:)
-- și are o dimensiune inițială de 100 MB, poate fi mărită automat la 200 MB cu
-- în trepte de 20 MB
(NUME = SomeData1,
FILENAME = "E:\SomeData1.mdf",
DIMENSIUNE = 100 MB,
MAXSIZE = 200,
FILEGROWTH = 2),
-- Al doilea fișier de date este localizat pe un mediu necriptat (unitatea logică C:)
-- și are o dimensiune inițială de 100 MB, poate fi mărită automat până la limită
-- spațiu pe disc în trepte de 5% din dimensiunea actuală a fișierului (rotunjit la 64 KB)
(NUME = SomeData2,
FILENAME = "c:\fișiere de program\microsoft sql server\mssql\data\SomeData2.ndf",
DIMENSIUNE = 100 MB,
MAXSIZE = NELIMITAT,
CREȘTERE FIILE = 5%)
LOG ON
-- Deși jurnalul de tranzacții ar putea fi, de asemenea, împărțit în părți, acest lucru nu ar trebui făcut,
-- deoarece acest fișier se modifică mult mai frecvent și este curățat în mod regulat (de exemplu, când
-- crearea unei copii de rezervă a bazei de date).
(NUME = SomeDatalog,
FILENAME = "c:\fișiere de program\microsoft sql server\mssql\data\SomeData.ldf",
DIMENSIUNE = 10 MB,
MAXSIZE = NELIMITAT,
CREȘTERE FIȘIERE = 10)
MERGE
-- Este mai bine să acordați imediat dreptul de proprietate asupra bazei de date utilizatorului în numele căruia
-- 1C se va conecta. Pentru a face acest lucru, trebuie să declarăm baza curentă
- tocmai creat,
UTILIZAȚI SomeData
MERGE
-- și executați sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

O scurtă digresiune despre creșterea automată a dimensiunii fișierului de date. În mod implicit, dimensiunile fișierelor pentru noile baze de date sunt mărite în trepte de 10% din dimensiunea actuală a fișierului. Aceasta este o soluție complet acceptabilă pentru bazele de date mici, dar nu foarte bună pentru cele mari: cu o dimensiune a bazei de date de, de exemplu, 20 GB, fișierul ar trebui să crească imediat cu 2 GB. Deși acest eveniment va avea loc destul de rar, poate dura câteva zeci de secunde (toate celelalte tranzacții sunt efectiv inactive în acest timp), ceea ce, dacă are loc în timpul lucrului activ cu baza de date, poate provoca unele eșecuri. A doua consecință negativă a creșterii proporționale, care apare atunci când spațiul pe disc este aproape complet plin, este probabilitatea unei eșecuri premature din cauza spațiului liber insuficient. De exemplu, dacă o partiție de disc cu o capacitate de 40 GB este complet dedicată unei baze de date (mai precis, unui fișier din această bază de date), atunci dimensiunea critică a fișierului bazei de date la care este necesar să se facă urgent (foarte urgent, până la punctul de a întrerupe activitatea normală a utilizatorilor) pentru a reorganiza stocarea informațiilor este dimensiunea fișierului de date 35 GB. Cu dimensiunea incrementală setată la 10-20 MB, puteți continua să lucrați până când ajungeți la 39 GB.

Prin urmare, deși lista de mai sus specifică o creștere a dimensiunii unuia dintre fișierele bazei de date în trepte de 5%, pentru dimensiuni mari ale bazei de date este mai bine să setați un increment fix de 10-20 MB. Atunci când setați valorile de creștere pentru creșterea dimensiunii fișierului bazei de date, este necesar să luați în considerare faptul că până când unul dintre fișierele dintr-un grup de fișiere atinge dimensiunea maximă, se aplică regula: fișierele dintr-un grup de fișiere sunt mărite toate în același timp timp, când toate sunt complet umplute. Deci, în exemplul de mai sus, când fișierul SomeData1.mdf atinge dimensiunea maximă de 200 MB, fișierul SomeData2.ndf va avea o dimensiune de aproximativ 1,1 GB.

După crearea unei astfel de baze de date, chiar dacă fișierele sale neprotejate SomeData2.ndf și SomeData.ldf devin accesibile unui atacator, va fi extrem de dificil să restabiliți starea adevărată a bazei de date - datele (inclusiv informații despre structura logică a bazei de date). ) vor fi împrăștiate în mai multe fișiere, iar informațiile cheie (despre, de exemplu, ce fișiere alcătuiesc această bază de date) vor fi în fișierul criptat.

Desigur, dacă se folosește stocarea fișierelor de baze de date folosind mijloace criptografice, atunci backup-ul (cel puțin a acestor fișiere) nu ar trebui să fie efectuate pe medii necriptate. Pentru a face copii de siguranță ale fișierelor de bază de date individuale, utilizați sintaxa corespunzătoare a comenzii BACKUP DATABASE. Vă rugăm să rețineți că, deși este posibil să protejați o copie de rezervă a bazei de date cu o parolă (opțiunile „PASSWORD = ” și „MEDIAPASSWORD = ” ale comenzii „BACKUP DATABASE”), o astfel de copie de rezervă nu devine criptată!

Criptarea datelor de server și client de aplicații stocate pe discuri

În cele mai multe cazuri, nu poate fi considerată justificată stocarea fișierelor utilizate de 1C:Enterprise (partea client și server de aplicație) pe medii criptate din cauza costurilor nerezonabil de mari, totuși, dacă există o astfel de nevoie, rețineți că serverul de aplicații și partea client ale aplicației de foarte multe ori creează fișiere temporare. Adesea, aceste fișiere pot rămâne după ce aplicația a terminat de rulat și este aproape imposibil să se garanteze eliminarea lor folosind instrumente 1C. Astfel, devine necesară criptarea directorului folosit pentru fișierele temporare în 1C sau să nu-l stocați pe disc folosind o unitate RAM (aceasta din urmă opțiune nu este întotdeauna posibilă din cauza dimensiunii fișierelor generate și a cerințelor RAM ale 1C:Enterprise). aplicația în sine).

Criptarea datelor folosind instrumente 1C încorporate.

Capacitățile standard pentru utilizarea criptării în 1C se reduc la utilizarea obiectelor pentru lucrul cu fișiere Zip cu parametri de criptare. Sunt disponibile următoarele moduri de criptare: algoritm AES cu o cheie de 128, 192 sau 256 de biți și un algoritm învechit utilizat inițial în arhivatorul Zip. Fișierele Zip criptate cu AES nu pot fi citite de mulți arhivatori (WinRAR, 7zip). Pentru a genera un fișier care conține date criptate, trebuie să specificați o parolă și un algoritm de criptare. Cel mai simplu exemplu de funcții de criptare-decriptare bazate pe această caracteristică este prezentat mai jos:

Funcția EncryptData(Date, Parolă, Metodă de criptare = Nedefinit) Export

// Scrieți datele într-un fișier temporar. De fapt, nu toate datele pot fi salvate în acest fel.
ValueInFile(TemporaryFileName, Data);

// Scrieți date temporare în arhivă
Zip = New ZipFileRecord (TemporaryArchiveFileName, Password, EncryptionMethod);
Zip.Add(TemporaryFileName);
Zip.Write();

// Citiți datele din arhiva primită în RAM
EncryptedData = NewValueStorage(NewBinaryData(ArchiveTemporaryFileName));

// Fișiere temporare - ștergeți

Funcția EndFunctions DecryptData(EncryptedData, Password) Export

// Atenție! Corectitudinea parametrilor trecuți nu este monitorizată

// Scrieți valoarea transmisă într-un fișier
ArchiveTemporaryFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(ArchiveTemporaryFileName);

// Extrage primul fișier din arhiva tocmai scrisă
TemporaryFileName = GetTemporaryFileName();
Zip = New ReadZipFile (TemporaryArchiveFileName, Password);
Zip.Extract(Zip.Items, TemporaryFileName, ZIPFilePathRecoveryMode.Do NotRecover);

// Citiți fișierul scris
Date = ValueFromFile(TemporaryFileName + "\" + Zip.Items.Name);

//Ștergeți fișierele temporare
DeleteFiles(TemporaryFileName);
DeleteFiles(ArhiveTemporaryFileName);

Date de returnare;

EndFunction

Desigur, această metodă nu poate fi numită ideală - datele sunt scrise într-un folder temporar în text clar, performanța metodei, sincer vorbind, este mai proastă ca niciodată, stocarea în baza de date necesită o cantitate extrem de mare de spațiu, dar acest lucru este singura metodă care se bazează doar pe mecanismele încorporate ale platformei. În plus, are un avantaj față de multe alte metode - această metodă împachetează simultan datele împreună cu criptarea. Dacă doriți să implementați criptarea fără dezavantajele pe care le are această metodă, trebuie fie să le implementați într-o componentă externă, fie să apelați la biblioteci existente prin crearea de obiecte COM, de exemplu, folosind Microsoft CryptoAPI. Ca exemplu, vom oferi funcțiile de criptare/decriptare a unui șir pe baza parolei primite.

Funcția EncryptStringDES(UnencryptedString, Parolă)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Această constantă este din CryptoAPI

EncryptionMechanism.Content = UnencryptedString;
Motor de criptare.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

returnează EncryptedString;

EndFunction // EncryptStringDES()

Funcția DecryptStringDES(EncryptedString, Parolă)

//Atenţie! Parametrii nu sunt verificați!

Motor de criptare = New COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(Parola);
Atentat, încercare
EncryptionMechanism.Decrypt(EncryptedString);
Excepție
// Parola incorecta!;
Returnare nedefinită;
EndTempt;

ReturnEncryptionMechanism.Content;

EndFunction // DecryptStringDES()

Vă rugăm să rețineți că la transfer valoare goală introducerea unui șir sau a unei parole în aceste funcții va genera un mesaj de eroare. Șirul obținut folosind această procedură de criptare este puțin mai lung decât originalul. Specificul acestei criptări este că, dacă criptați un șir de două ori, șirurile rezultate NU vor fi identice.

Greșeli de bază la utilizarea instrumentelor criptografice.

Atunci când utilizați instrumente criptografice, se fac adesea aceleași greșeli:

Subestimarea penalizării de performanță atunci când utilizați criptografie.

Criptografia este o sarcină care necesită un număr destul de mare de calcule (în special pentru algoritmi precum DES, 3DES, GOST, PGP). Și chiar și atunci când utilizați algoritmi de înaltă performanță și optimizați (RC5, RC6, AES), nu există nicio scăpare de la transferul inutil de date în memorie și procesarea computațională. Și acest lucru aproape anulează capacitățile multor componente ale serverului (matrice RAID, adaptoare de rețea). Când utilizați criptarea hardware sau derivarea hardware a cheii de criptare, există un blocaj suplimentar de performanță posibil: viteza de transfer de date între dispozitivul suplimentar și memorie (unde performanța unui astfel de dispozitiv poate să nu fie critică). Când se utilizează criptarea unor cantități mici de date (de exemplu, un mesaj de e-mail), creșterea sarcinii de calcul a sistemului nu este atât de vizibilă, dar în cazul criptării totale a tuturor, acest lucru poate afecta foarte mult performanța sistemului. ca un intreg, per total.

Subestimarea capabilităților moderne de selectare a parolelor și a cheilor.

În prezent, capacitățile tehnologiei sunt astfel încât o cheie cu o lungime de 40-48 de biți poate fi selectată de o organizație mică, iar o cheie cu o lungime de 56-64 de biți de o organizație mare. Acestea. trebuie utilizați algoritmi care utilizează o cheie de cel puțin 96 sau 128 de biți. Dar majoritatea cheilor sunt generate folosind algoritmi hash (SHA-1 etc.) bazați pe parolele introduse de utilizator. În acest caz, o cheie cu o lungime de 1024 de biți poate să nu ajute. În primul rând, este adesea folosită o parolă ușor de ghicit. Factorii care facilitează selecția sunt: ​​utilizarea unui singur caz de litere; utilizarea cuvintelor, numelor și expresiilor în parole; utilizarea de date cunoscute, zile de naștere etc.; folosind „modele” la generarea parolelor (de exemplu, 3 litere, apoi 2 cifre, apoi 3 litere în întreaga organizație). O parolă bună ar trebui să fie o secvență destul de aleatorie de ambele litere, numere și semne de punctuație. Parolele introduse de la tastatură de până la 7-8 caractere, chiar dacă aceste reguli sunt respectate, pot fi ghicite într-un timp rezonabil, așa că este mai bine ca parola să fie de cel puțin 11-13 caractere. Soluția ideală este de a evita generarea unei chei folosind o parolă, de exemplu, folosind diferite carduri inteligente etc., dar în acest caz este necesar să se prevadă posibilitatea de a proteja împotriva pierderii media cheii de criptare.

Stocarea nesigură a cheilor și parolelor.

Exemple comune ale acestei erori sunt:

• parole lungi și complexe scrise pe note lipicioase lipite de monitorul utilizatorului.
• stocarea tuturor parolelor într-un fișier care nu este protejat (sau este protejat mult mai slab decât sistemul în sine)
• stocarea cheilor electronice în domeniul public.
• transfer frecvent de chei electronice între utilizatori.

De ce să faci o ușă blindată dacă cheia ei este sub preș?

Transferul datelor criptate inițial într-un mediu nesigur.

Când configurați un sistem de securitate, asigurați-vă că își face treaba. De exemplu, am dat peste o situație (care nu are legătură cu 1C) când un fișier criptat inițial, când programul rula în formă clară, a fost plasat într-un folder temporar, de unde putea fi citit în siguranță. Adesea, copiile de rezervă ale datelor criptate în formă clară se află undeva „nu departe” de aceste date.

Utilizarea instrumentelor criptografice în alte scopuri

Prin criptarea datelor în tranzit, nu vă puteți aștepta ca datele să fie inaccesibile acolo unde sunt utilizate. De exemplu, serviciile IPSec nu împiedică în niciun fel serverul de aplicații să „sniffe” traficul de rețea la nivel de aplicație.

Astfel, pentru a evita greșelile la implementarea sistemelor criptografice, ar trebui (cel puțin) să faceți următoarele înainte de a le implementa.

• Descoperi:
  • Ce trebuie protejat?
  • Ce metodă de protecție ar trebui să utilizați?
  • Ce părți ale sistemului trebuie securizate?
  • Cine va controla accesul?
  • Va funcționa criptarea în toate zonele potrivite?
• Determinați unde sunt stocate informațiile, cum vor fi trimise prin rețea și computerele de pe care vor fi accesate informațiile. Aceasta va oferi informații despre viteza, capacitatea și utilizarea rețelei înainte de implementarea sistemului, ceea ce este util pentru optimizarea performanței.
• Evaluați vulnerabilitatea sistemului la diferite tipuri de atacuri.
• Elaborați și documentați un plan de securitate a sistemului.
• Evaluați eficiența economică (justificarea) utilizării sistemului.

Concluzie

Desigur, într-o scurtă trecere în revistă este imposibil să indicam toate aspectele legate de securitate în 1C, dar să ne permitem să tragem câteva concluzii preliminare. Desigur, această platformă nu poate fi numită ideală - ea, ca multe altele, are propriile probleme în organizarea unui sistem securizat. Dar acest lucru nu înseamnă în niciun caz că aceste probleme nu pot fi ocolite; dimpotrivă, aproape toate deficiențele pot fi eliminate prin dezvoltarea, implementarea și utilizarea corespunzătoare a sistemului. Cele mai multe probleme apar din cauza dezvoltării insuficiente a unei soluții specifice aplicației și a mediului de execuție al acesteia. De exemplu, soluțiile standard fără modificări semnificative pur și simplu nu implică crearea unui sistem suficient de sigur.

Acest articol demonstrează încă o dată că orice set de măsuri de securitate trebuie să acopere toate etapele de implementare: dezvoltare, implementare, administrare a sistemului și, bineînțeles, măsuri organizatorice. În sistemele informaționale, „factorul uman” (inclusiv utilizatorii) este principala amenințare de securitate. Acest set de măsuri trebuie să fie rezonabil și echilibrat: nu are sens și este puțin probabil ca fondurile suficiente să fie alocate pentru a organiza o protecție care depășește costul datelor în sine.

Companie este un serviciu unic pentru cumpărători, dezvoltatori, dealeri și parteneri afiliați. În plus, acesta este unul dintre cele mai bune magazine online de software din Rusia, Ucraina și Kazahstan, care oferă clienților o gamă largă de produse, multe metode de plată, procesare promptă (adesea instantanee) a comenzii și urmărirea procesului de comandă într-o secțiune personală. .