Protecția sistemelor de management al bazelor de date. Protecția informațiilor din baze de date

LA ;

Schema de control al accesului obligatorie

Metodele obligatorii de control al accesului sunt aplicate acelor baze de date în care informațiile stocate au o structură destul de statică și rigidă, ceea ce este tipic, de exemplu, unor organizații militare sau guvernamentale. Ideea de bază este că fiecărui obiect de date i se atribuie un anumit nivel de clasificare (sau clasificarea de securitate necesară, de exemplu „Top Secret”, „Secret”, „Pentru uz oficial”, etc.), iar fiecărui utilizator i se acordă o securitate gradată. nivel de autorizare, similar nivelurilor de clasificare existente. Se presupune că aceste niveluri formează un sistem ierarhic strict (de exemplu, „Top Secret” > „Secret” > „Pentru uz oficial”, etc.). Apoi, pe baza acestor prevederi, se pot formula două reguli foarte simple, propuse mai întâi de Bell și La Padula.

• 1. Utilizatorul i poate eșantiona date din obiectul j numai dacă nivelul său de securitate este mai mare sau egal cu nivelul de clasificare al obiectului j (proprietatea de securitate simplă).
• 2. Utilizatorul i poate modifica obiectul j numai dacă nivelul său de degajare este egal cu nivelul de clasificare al obiectului j (proprietatea stea).

Prima regulă este destul de evidentă, în timp ce a doua necesită explicații suplimentare. În primul rând, trebuie menționat că o altă modalitate de a formula a doua regulă este: „Prin definiție, orice informație înregistrată de utilizatorul i dobândește automat un nivel de clasificare care este egal cu nivelul de autorizare al utilizatorului i”. O astfel de regulă este necesară, de exemplu, pentru a preveni înregistrarea datelor secrete de către un utilizator cu nivel de acces

„Secret”, la un fișier cu un nivel de clasificare inferior, care va încălca întregul sistem de secretizare.

Criptarea datelor

Anterior, se presupunea că un utilizator rău intenționat încerca să pătrundă ilegal în baza de date folosind instrumentele de acces normale disponibile pe sistem. Acum ar trebui să luăm în considerare cazul în care el încearcă să pătrundă ocolind baza de date sistem, adică mutarea fizică a mediilor de stocare externe sau conectarea la o linie de comunicație. Cea mai eficientă metodă de combatere a unor astfel de amenințări este criptarea datelor, adică. stocarea și transmiterea de date deosebit de importante în formă criptată.

Pentru a învăța conceptele de bază ale criptării datelor, trebuie să introduceți câteva concepte noi. Datele originale (necriptate) se numesc text simplu.

Textul simplu este criptat folosind un algoritm de criptare special. Intrarea unui astfel de algoritm este textul simplu și cheia de criptare, iar rezultatul este o formă transformată a textului simplu, numită text cifrat. Detaliile algoritmului de criptare pot fi publicate, dar cheia de criptare nu este niciodată dezvăluită. Este textul criptat, de neînțeles pentru oricine nu deține cheia de criptare, care este stocat în baza de date și transmis prin linia de comunicare.

Exemplul 5.1. Să fie dat următorul șir ca text simplu.

ÎN CUM PENTRU PĂSCĂRII PĂSCĂRII (Pentru o prezentare ușoară, se presupune că datele de aici constau doar din spații și caractere majuscule.) În plus, să presupunem că cheia de criptare este următorul șir.

Algoritmul de criptare utilizat este descris mai jos.

1. Împărțiți textul simplu în blocuri a căror lungime este egală cu lungimea cheii de criptare.

AS+KI NGFIS HERS+ CATCH +FIRE

• (Aici spațiile sunt indicate prin semnul „+”.)
• 2. Înlocuiți fiecare caracter text simplu cu un număr întreg în intervalul 00-26, folosind 00 pentru spațiu, 01,... pentru A și 26 pentru Z. Rezultatul este următorul șir de numere.
• 0119001109 1407060919 0805181900 0301200308 0006091805
• 3. Repetați pasul 2 pentru cheia de criptare, rezultând următorul șir de numere.
• 0512091520
• 4. Acum însumați valorile plasate pentru fiecare caracter în fiecare bloc de text simplu cu valorile corespunzătoare înlocuite cu caracterele cheii de criptare și pentru fiecare sumă a acestor două valori, determinați și scrieți restul diviziunii pana la 27.
• 5. Înlocuiți fiecare număr din linia de jos a pasului 4 cu simbolul text corespunzător.

FDIZB SSOXL MQ+GT HMBRA ERRFY

Dacă cheia de criptare este cunoscută, atunci procedura de decriptare din acest exemplu poate fi efectuată destul de simplu. Întrebarea este cât de dificil este pentru un utilizator ilegal să determine cheia de criptare având în vedere textul simplu și textul cifrat. În acest exemplu simplu, acest lucru nu este foarte greu de realizat, dar este clar că pot fi dezvoltate scheme de criptare mai complexe. În mod ideal, schema de criptare ar trebui să fie astfel încât efortul depus pentru decriptarea acesteia să fie de multe ori mai mare decât beneficiul obținut. (De fapt, această observație se aplică tuturor aspectelor problemei de securitate, și anume, costul încercării de a sparge sistemul de securitate ar trebui să fie semnificativ mai mare decât beneficiul potențial de pe urma acestui fapt.) Trebuie luat în considerare scopul final al căutării unor astfel de scheme. o schemă pentru care însuși dezvoltatorul său, având variante deschise și criptate ale aceleiași părți a textului, nu poate determina cheia și, prin urmare, decriptează o altă parte a textului cifrat.

Managementul securității se realizează de obicei la trei niveluri:

• * nivelul bazei de date;
• * nivel de sistem de operare;
• * nivel de rețea.

La nivel de sistem de operare, administratorul bazei de date (DBA) trebuie să aibă drepturi pentru a crea și șterge fișierele legate de bazele de date. Dimpotrivă, utilizatorii obișnuiți nu ar trebui să aibă astfel de drepturi. Consultați documentația standard Oracle pentru informații de securitate la nivel de sistem de operare. În multe organizații mari, DBA sau administratorul de securitate a bazei de date lucrează îndeaproape cu administratorii de sisteme informatice pentru a coordona eforturile de dezvoltare a cerințelor și practicilor de securitate.

Cerințele de securitate a bazei de date descriu procedurile pentru acordarea accesului la baza de date prin atribuirea fiecărui utilizator a unei perechi nume utilizator/parolă. Cerințele pot limita, de asemenea, cantitatea de resurse (spațiu pe disc și timp CPU) alocate unui utilizator și pot prevedea necesitatea auditării acțiunilor utilizatorului. Securitatea la nivel de bază de date oferă, de asemenea, controlul accesului la anumite obiecte ale schemei bazei de date.

Lucrarea examinează unele dintre cele mai importante cerințe legale pentru protecția datelor cu caracter personal (PD). Sunt prezentate abordări generale pentru protejarea bazelor de date gestionate de un SGBD. Este prezentat un exemplu de protecție PD ținând cont de cerințele legale pentru platforma Oracle - una dintre cele mai utilizate pe scară largă în sistemele informaționale medii și mari.

Legea cu privire la protecția datelor cu caracter personal nu este implementată. De ce?

Pentru început, să reamintim câteva prevederi ale Legii federale nr. 152 „Cu privire la datele cu caracter personal”.

Potrivit articolului 3 din lege, „operator este un organism de stat, un organ municipal, persoană juridică sau persoană fizică care organizează și (sau) desfășoară prelucrarea datelor cu caracter personal, precum și determinarea scopurilor și conținutului prelucrării datelor cu caracter personal. date." Astfel, ajungem la concluzia de la care vom proceda: aproape toate persoanele juridice ale Federației Ruse sunt potențiali operatori PD.

Legea mai precizează în mod explicit că prelucrarea datelor cu caracter personal înseamnă aproape tot ceea ce se poate face cu acestea, de la primirea datelor până la depersonalizarea și distrugerea acestora: „prelucrarea datelor cu caracter personal - acțiuni (operațiuni) cu date personale, inclusiv colectare, sistematizare, acumulare. , stocare, clarificare (actualizare, modificare), utilizare, distribuire (inclusiv transfer), depersonalizare, blocare, distrugere a datelor cu caracter personal.”

În plus, cerințele Legii „Cu privire la protecția datelor cu caracter personal” nr. 152-FZ conțin câteva, pentru a spune ușor, proceduri neobișnuite pentru organizațiile ruse, cum ar fi:

• obținerea consimțământului cetățenilor pentru prelucrarea datelor lor personale, inclusiv (dacă este necesar) transferul către terți;
• determinarea compoziției datelor cu caracter personal pentru fiecare sistem informatic care prelucrează date cu caracter personal (ISPD);
• clasificarea ISPD după volumul de date și caracteristicile de securitate în funcție de evaluarea posibilelor daune aduse persoanelor vizate;
• pregătirea și organizarea de sesizări periodice cu privire la prelucrarea datelor cu caracter personal către organismul abilitat.

Să remarcăm că marea majoritate a organizațiilor rusești nu au practica de a îndeplini astfel de cerințe. Nu există reguli stabilite pentru relațiile de încredere reciprocă; de exemplu, este extrem de rar ca un acord de ofertă să fie întocmit pentru consimțământul de utilizare a datelor personale ale cetățenilor. Dar această abordare a fost practicată cu succes în țările dezvoltate de destul de mult timp. Și încă un lucru: chiar dacă un astfel de acord ar defini în mod clar ce tipuri de prelucrare a datelor cu caracter personal sunt permise de o anumită organizație, precum și cine ar fi considerat responsabil pentru încălcarea tipurilor convenite de prelucrare și compromiterea datelor cu caracter personal, puţini cetăţeni ar decide să încheie un asemenea acord. Având în vedere caracterul vag al formulării legislației, este evident că, chiar dacă un cetățean și-ar da consimțământul pentru prelucrarea datelor sale cu caracter personal, în orice caz ar fi complet dependent de cât de înțelept și conștiincios ar interpreta operatorul prevederile din lege.

Merită adăugat că, potrivit unor date, clasificarea menționată și cerințele corespunzătoare fiecărei clase, conform Decretului Guvernului nr. 781, au fost deja elaborate de FSTEC, FSB și Ministerul Informațiilor și Comunicațiilor din Rusia și vor să fie publicată în viitorul apropiat. Acest document mult așteptat va pune în lumină aceste și alte aspecte ale aplicării practice a Legii federale-152. Dar principalele speranțe asociate cu acesta constă în primirea de instrucțiuni practice despre cum să implementeze cerințele legii pentru organizațiile guvernamentale care prelucrează datele personale ale cetățenilor.

În general, structurile comerciale protejează de mult datele esențiale pentru afaceri (de exemplu, registrul acționarilor și alte informații comerciale), inclusiv datele personale. Cu toate acestea, puține organizații respectă cerințele legii federale privind secretele comerciale, dar acesta este un subiect larg care depășește domeniul de aplicare al acestui articol.

La rândul lor, organizațiile guvernamentale așteaptă instrucțiuni și metode specifice pentru sistemele de protecție a clădirilor, în funcție de clasa sistemului informațional și de natura datelor prelucrate de acest sistem. Aș dori să sper că în viitorul apropiat vor fi finalizate și publicate toate documentele necesare, iar acest lucru va da un impuls începerii lucrărilor reale privind protecția datelor cu caracter personal.

Legea este aspră, dar corectă

Nu mai puțin interesante sunt oportunitățile oferite de lege pentru cetățenii înșiși - subiecții datelor cu caracter personal. Pe lângă cele de mai sus, să reamintim și alte prevederi ale legii. Potrivit părții 4 a articolului 14 din Legea federală nr. 152, subiectul datelor cu caracter personal are dreptul de a primi, atunci când aplică sau primește o solicitare, informații privind prelucrarea datelor sale cu caracter personal, inclusiv care să conțină: confirmarea faptului că prelucrarea datelor cu caracter personal de către operator, precum și scopul acestei prelucrări; metode de procesare PD utilizate de operator; informații despre persoanele care au acces la date cu caracter personal; lista datelor cu caracter personal prelucrate și sursa primirii acestora; termenii de prelucrare a PD, inclusiv termenii de stocare a acestora; informații despre consecințele juridice pe care le poate implica pentru subiectul datelor cu caracter personal prelucrarea datelor sale cu caracter personal. De fapt, aceasta este și o sarcină dificilă pentru operator, deoarece nimeni nu a abrogat articolul 137 din Codul penal al Federației Ruse „Încălcarea vieții private” din 13 iunie 1996. Articolul, în special, precizează că răspunderea penală este antrenată de: colectarea sau difuzarea ilegală de informații despre viața privată a unei persoane, constituind secretul său personal sau de familie, fără consimțământul acesteia, sau diseminarea acestor informații într-un discurs public, în mod public. munca afișată sau mass-media, dacă aceste acte au fost comise din interes egoist sau din alt interes personal și au cauzat prejudicii drepturilor și intereselor legitime ale cetățenilor.

Conform articolului 17 din Legea federală-152, în cazul în care subiectul datelor cu caracter personal consideră că operatorul prelucrează datele sale cu caracter personal încălcând cerințele prezentei legi federale sau îi încalcă în alt mod drepturile și libertățile, subiectul datelor cu caracter personal are dreptul de a contesta acțiunile sau inacțiunea operatorului la organul abilitat pentru apărarea drepturilor subiecților PD sau în instanță. În acest caz, persoanele vinovate de încălcarea cerințelor poartă răspunderea administrativă, civilă, penală și de altă natură prevăzute de lege.

Pare foarte semnificativ faptul că dezvoltatorii sunt responsabili pentru implementarea cerințelor de securitate în sistemele de securitate a informațiilor.

Iată principalele componente ale sistemului de control și supraveghere de stat asupra asigurării securității datelor cu caracter personal în timpul prelucrării acestora în sistemul informațional:

• Rossvyazohrankultura este organismul autorizat pentru protecția drepturilor subiecților datelor cu caracter personal;
• FSB - Organ executiv federal autorizat în domeniul asigurării securității statului și al utilizării instrumentelor de criptare;
• FSTEC - serviciul federal de control tehnic și export și contracarare a informațiilor externe - organismul autorizat în domeniul controlului mijloacelor tehnice de protecție utilizate;
• Ministerul Tehnologiilor Informaționale și Comunicațiilor al Federației Ruse - procedura de clasificare a sistemelor informaționale care conțin date cu caracter personal.

Astfel, se creează un sistem bine gândit de control de stat al operatorilor care prelucrează date cu caracter personal.

Cum să protejăm corect bazele de date?

Măsurile de protecție a datelor cu caracter personal diferă puțin de abordarea general acceptată a protecției informațiilor cu acces limitat. Deci, o abordare integrată a protecției bazei de date constă din etape succesive, inclusiv:

• determinarea unui model de amenințare adecvat;
• evaluare a riscurilor;
• dezvoltarea unui sistem de protecție bazat pe acesta folosind metodele prevăzute pentru clasa corespunzătoare de sisteme informatice (IS);
• verificarea gradului de pregătire a sistemelor de securitate a informațiilor (IPS) cu pregătirea documentației relevante (descrierea sistemului, reguli de funcționare, reglementări etc.), inclusiv concluziile privind posibilitatea de funcționare a acestui IPS;
• instalarea și punerea în funcțiune a echipamentelor de protecție a informațiilor;
• contabilizarea sistemelor de securitate a informațiilor utilizate, documentația tehnică a acestora, precum și media PD;
• contabilitatea persoanelor autorizate să lucreze cu PD în SI;
• elaborarea unei descrieri complete a sistemului de protecție a datelor cu caracter personal;
• controlul asupra utilizării securității informațiilor.

În același timp, sunt utilizate în mod tradițional două componente ale construirii unui sistem de protecție a informațiilor: efectuarea unui inventar al resurselor informaționale, identificarea proprietarilor acestora, clasificarea informațiilor (inclusiv acces limitat, dacă este necesar, introducerea unui regim de secret comercial), pregătirea și semnarea unui ordin. pentru implementarea măsurilor de protecție organizaționale dezvoltate, justificați și obțineți un buget, selectați și pregătiți personalul, îl instruiți, organizați recalificarea și... asta nu este tot.

Toate aceste activități ar trebui descrise și aprobate în documentația de reglementare și administrativă. În același timp, suportul managerial este foarte important pentru implementarea consecventă a politicii de securitate dezvoltate. Evident, cea mai bună practică este ca fiecare angajat să semneze un acord separat pentru lucrul cu informații restricționate. În ultimă instanță, angajații trebuie instruiți, ceea ce, la rândul său, trebuie confirmat prin semnătura „cunoștință” cu numele complet și funcția angajatului în toate ordinele și instrucțiunile.

Să trecem la analiza mai detaliată a mijloacelor tehnice de protejare a unei baze de date care conține date cu caracter personal.

Componentele principale ale unui sistem de securitate a bazelor de date

Schema clasică de protecție a bazei de date este împărțită în următoarele proceduri obligatorii:

• Controlul accesului- fiecare utilizator, inclusiv administratorul, are acces doar la informațiile de care are nevoie conform funcției sale.
• protectie acces - accesul la date poate fi obtinut de catre un utilizator care a trecut de procedura de identificare si autentificare.
• Criptarea datelor- este necesară criptarea atât a datelor transmise prin rețea pentru a proteja împotriva interceptării, cât și a datelor scrise pe media pentru a proteja împotriva furtului media și a vizualizării/modificării neautorizate prin alte mijloace ale sistemului de management al bazei de date (DBMS).
• Auditul accesului la date- acțiunile cu date critice trebuie înregistrate. Utilizatorii asupra cărora este întreținut nu ar trebui să aibă acces la protocol. În cazul aplicațiilor care utilizează o arhitectură multi-nivel, se aplică și funcțiile de protecție de mai sus, cu excepția protecției datelor pe suport - această funcție rămâne în baza de date.

Aplicațiile DBMS și Oracle sunt echipate într-o măsură sau alta cu toate funcțiile de securitate enumerate, ceea ce le diferențiază de produsele concurenților. Să luăm în considerare aceste proceduri mai detaliat.

Controlul accesului

Urmărind scopul de a proteja baza de date împotriva amenințărilor interne, pentru a asigura controlul accesului în DBMS versiunea 10g Release 3, Oracle a lansat un nou produs Database Vault, conceput pentru a preveni accesul neautorizat la informații de către utilizatori, inclusiv cei cu puteri speciale, de exemplu , administratori de baze de date. Setul de reguli din Database Vault care restricționează accesul este destul de larg. De exemplu, conducerea unei organizații poate defini reguli care necesită ca doi angajați să fie prezenți în același timp pentru a finaliza sarcinile care necesită acces la informații critice. Astfel, Database Vault rezolvă următoarele probleme:

• restricționarea accesului la date de către administratorul bazei de date și alți utilizatori privilegiați;
• prevenirea manipulării bazei de date și a accesului la alte aplicații de gestionare a aplicațiilor;
• oferind control asupra cine, când și unde poate accesa aplicația.

Protecția accesului

Autentificarea în contextul Oracle înseamnă verificarea identității cuiva sau a ceva - un utilizator, o aplicație, un dispozitiv - care sau ce are nevoie de acces la date, resurse sau aplicații. După o procedură de autentificare reușită, urmează procesul de autorizare, care presupune atribuirea anumitor drepturi, roluri și privilegii subiectului de autentificare.

Oracle oferă o varietate de metode de autentificare și vă permite să utilizați una sau mai multe dintre ele în același timp. Ceea ce toate aceste metode au în comun este faptul că numele de utilizator este folosit ca subiect de autentificare. Unele informații suplimentare, cum ar fi o parolă, pot fi solicitate pentru a confirma autenticitatea acesteia. Autentificarea administratorilor DBMS Oracle necesită o procedură specială, care este determinată de responsabilitățile specifice postului și gradul de responsabilitate al acestui angajat. Software-ul Oracle criptează, de asemenea, parolele utilizatorilor pentru transmisie sigură prin rețea.

Deci, să aruncăm o privire mai atentă asupra metodelor de autentificare din Oracle DBMS.

Autentificare folosind sistemul de operare

O serie de sisteme de operare permit SGBD-ului Oracle să utilizeze informații despre utilizatorii gestionați de sistemul de operare însuși. În acest caz, utilizatorul computerului are acces la resursele bazei de date fără a specifica suplimentar un nume și o parolă - sunt utilizate acreditările sale de rețea. Acest tip de autentificare este considerat nesigur și este folosit în principal pentru autentificarea administratorului DBMS.

Autentificare folosind servicii de rețea

Acest tip de autentificare este oferit de opțiunea de server Oracle Advanced Security. Oferă următoarele servicii:

1. SSL - autentificare utilizează protocolul SSL (Secure Socket Layer) - un protocol de nivel de aplicație. Poate fi folosit pentru autentificare în baza de date și în cazul general (dacă apoi autentificarea utilizatorului este utilizată folosind DBMS) nu depinde de sistemul global de gestionare a utilizatorilor furnizat de serviciul de directoare Oracle - Oracle Internet Directory.

2. Autentificare prin servicii terțe.

Bazat pe Kerberos. Utilizarea Kerberos ca sistem de autentificare cu un terț de încredere se bazează pe utilizarea așa-numitului. secret împărtășit. Acest lucru asigură securitatea și fiabilitatea părții de încredere și face posibilă utilizarea Single Sign-On, stocarea centralizată a parolelor, autentificarea transparentă prin legături la baze de date și securitatea îmbunătățită pe stațiile de lucru.

Bazat pe PKI. Utilizarea PKI pentru autentificare presupune emiterea de certificate digitale pentru utilizatori (aplicații), care sunt utilizate pentru autentificarea directă pe serverele de baze de date din cadrul unei organizații. Acest lucru nu necesită utilizarea unui server de autentificare suplimentar. Oracle definește următoarele componente pentru utilizarea PKI:

• Protocolul SSL
• un set de funcții OCI (Oracle Call Interface - interfață aplicație pentru accesarea bazei de date) și funcții PL/SQL
• certificate de încredere, pentru a verifica autenticitatea certificatelor prezentate de utilizatori (aplicații)
• Portofelele Oracle sunt containere de chei care conțin cheia privată a utilizatorului, certificatul acestuia și lanțurile de certificate de încredere.
• Oracle AS Certificate Authority - componentă a Oracle Application Server, concepută pentru emiterea de certificate și gestionarea lor în continuare
• - Oracle Wallet Manager (OWM) - o componentă DBMS pentru gestionarea portofelelor

Bazat pe RADIUS. Oracle DBMS acceptă protocolul RADIUS (Remote Authentication Dial - In User Service) - un protocol standard pentru autentificarea utilizatorilor de la distanță. În acest caz, devin disponibile servicii și dispozitive de autentificare terță parte cu care serverul RADIUS poate interacționa (de exemplu, dispozitive de generare a parolelor unice, dispozitive biometrice etc.).

Bazat pe serviciul de director LDAP. Utilizarea unui serviciu de director LDAP face gestionarea autentificării și gestionarea contului de utilizator (aplicație) foarte eficientă. În infrastructura Oracle DBMS, serviciul de director este reprezentat de următoarele componente:

• Oracle Internet Directory (OID) vă permite să stocați și să gestionați central informații despre utilizatori (așa-numiții utilizatori enterprise). Vă permite să aveți un singur cont de utilizator pentru mai multe baze de date. Este posibilă integrarea cu servicii de directoare terțe, cum ar fi MS Active Directory sau iPlanet. OID vă permite să gestionați în mod flexibil atributele și privilegiile de securitate ale fiecărui utilizator, inclusiv cele autentificate cu certificate digitale. Pentru a crește securitatea în timpul procesului de autentificare, este posibil să utilizați protocolul SSL.
• Oracle Enterprise Security Manager este un utilitar pentru gestionarea utilizatorilor, grupurilor, rolurilor și privilegiilor.

3. Autentificare în aplicații cu mai multe niveluri

Metodele de autentificare de mai sus pot fi aplicate și în aplicații cu mai multe niveluri. De regulă, pentru a accesa aplicațiile de pe Internet, se folosește autentificarea folosind un nume și o parolă (inclusiv folosind protocolul RADIUS) sau folosind protocolul SSL. Alte metode sunt folosite pentru ca utilizatorii să lucreze într-o rețea locală.

Criptarea datelor

Pentru a proteja datele transmise prin rețea în DBMS Oracle, începând cu versiunea 8i, sunt folosite optiunile Oracle Advanced Security, care asigură funcția Criptarea rețelei, care vă permite să criptați întregul flux de date. Securitatea informatiilor este asigurata de secretul cheii cu care sunt criptate datele.

Criptarea rețelei vă permite să atingeți un nivel ridicat de securitate. Sunt acceptați următorii algoritmi de criptare: AES (doar 10g/11g). DES, 3 DES, RC 4 (doar 10g/11g).

Protecția datelor transmise prin rețea în aplicațiile Oracle este asigurată de protocolul SSL folosind algoritmi care sunt suportați de serverul de aplicații, de regulă, acesta este serverul WEB Oracle.

Protecția datelor pe mass-media este asigurată de două componente ale Oracle DBMS - pachete care implementează algoritmi de criptare și o opțiune Criptare transparentă a datelor (T DE).Începând cu versiunea 8i, Oracle DBMS oferă dezvoltatorilor de aplicații pachete de proceduri stocate care implementează următorii algoritmi: DES cu o lungime a cheii de 56 de biți, Triplu DES cu lungimea cheii 112 și 168 biți ,AES cu lungimi de cheie de 128, 192 și 256 de biți RC 4(doar 10g/11g).

Opțiune T DE a apărut în Oracle DBMS versiunea 10g Release 2 ca parte integrantă Securitate avansată. Vă permite să criptați selectiv coloanele de tabel folosind algoritmi Triple DES (cu o lungime a cheii de 168 de biți), AES (cu o lungime a cheii de 128, 192 sau 256 de biți). Gestionarea cheilor de criptare este preluată de nucleul bazei de date, iar utilizarea unei astfel de criptări nu necesită reelaborarea software-ului aplicației client și server. În versiunea DBMS 11g și ulterioară, a devenit posibilă criptarea întregului spațiu de tabelă.

Auditul accesului la date

SGBD Oracol are instrumente puternice pentru auditarea acțiunilor utilizatorului, inclusiv accesul la date și evenimentele de înregistrare/deconectare și modificări ale structurii bazei de date. Începând cu versiunea 9i, SGBD este echipat cu o opțiune de audit detaliată (Fine Grained Audit Control), care vă permite să auditați accesul în condiții determinate de reguli personalizabile destul de flexibile. Cu toate acestea, aceste instrumente de audit nu vă permit să monitorizați acțiunile efectuate de administratorul bazei de date și, de asemenea, nu îl împiedică să modifice jurnalul de audit, să șterge orice rând și să nu lase nicio urmă a unor astfel de acțiuni. Nevoia emergentă de a audita activitățile și de a proteja datele de audit de la utilizatorii privilegiați, inclusiv administratorii de baze de date, a fost solicitată Oracol dezvolta un nou concept de audit. Se bazează pe ideea pe care se bazează funcționalitatea Seif pentru baze de date: Administratorul bazei de date este izolat de managementul auditului, care din motive evidente oferă un nivel mai ridicat de securitate a bazei de date. Ca si in cazul Seif pentru baze de date reguli de atribuire a auditurilor către Seif de audit foarte flexibil.

Sunt suficiente protecțiile încorporate?

Scurta noastră prezentare a instrumentelor de securitate a informațiilor pe care Oracle Corporation le-a integrat în produsele și tehnologiile sale demonstrează o bază solidă pentru construirea de sisteme informatice cu diferite niveluri de securitate care îndeplinesc cele mai recente cerințe de securitate. Cu toate acestea, chiar și o privire superficială asupra sistemelor de securitate ale diferitelor programe care utilizează un server de aplicații DBMS sau Oracle va arăta că, cu rare excepții, instrumentele de securitate încorporate fie nu sunt utilizate deloc, fie sunt înlocuite cu dezvoltări proprietare cu funcționalități similare. sau dezvoltări gata făcute oferite pe piață, sau instrumente încorporate sunt completate de software terță parte.

În esență, avem de-a face cu trei abordări ale companiilor naționale cu privire la problema securității informațiilor în general și la protejarea bazelor de date de amenințările tot mai mari în special.

Din păcate, merită să recunoaștem că prima abordare este cea mai comună și implică utilizarea unei simple autentificări prin parolă, autorizare și criptare a datelor.

Următoarele argumente pot fi auzite cel mai adesea de la susținătorii acestei abordări în dezvoltarea și operarea sistemelor informaționale:

• cel mai simplu și, prin urmare, mai fiabil în ceea ce privește funcționarea;
• cost scăzut de proprietate;
• nu este necesar un nivel mai ridicat de protecție.

Desigur, protecția cu parolă nu necesită costuri suplimentare nici în etapa de dezvoltare, nici în etapa de funcționare a IS - toate „preocupările” pentru deservirea utilizatorilor și parolele acestora sunt preluate de DBMS sau de serverul de aplicații. De asemenea, nu există costuri pentru hardware suplimentar (servere de autentificare, servicii de directoare, dispozitive de stocare a informațiilor cheie etc.) și software (licențe, software terță parte etc.). Este important ca cerințele pentru calificările administratorilor de baze de date și administratorilor de securitate în acest caz să fie mult mai mici, iar aceasta este și o chestiune de economie. Cel de-al treilea argument pare să fi fost păstrat istoric din acele vremuri în care problemele de securitate nu erau abordate serios.

Sistemele de protecție construite conform celei de-a doua abordări sunt puțin mai puțin frecvente. Parțial, sistemele din prima opțiune le sunt transferate, atunci când, de exemplu, clienții unui astfel de sistem, obosiți de costul „scăzut” al deținerii protecției cu parole, comandă dezvoltatorilor sau cumpără un sistem de gestionare a parolelor gata făcut. Se întâmplă că scandalurile periodice cu furtul de date ne obligă să facem „patch-uri” software pe un sistem gata făcut pentru a implementa criptarea, folosind adesea propriii algoritmi „super-puternici”.

Argumentele pentru această abordare sunt aproximativ următoarele: măsurile de securitate încorporate sunt în mod clar insuficiente și sunt pline de vulnerabilități;

• Este mai bine să ai de-a face cu o echipă de dezvoltare „locală” decât să te bazezi pe suportul furnizorului;
• sistemul funcționează în mod normal cu protecție prin parolă și este mai bine să nu o atingeți; este suficient să implementați software suplimentar de gestionare a parolelor.

Cele două opțiuni de utilizare a măsurilor de securitate discutate mai sus sunt tipice pentru sistemele informaționale dezvoltate și implementate în principal la sfârșitul anilor 90 ai secolului trecut. Un exemplu tipic sunt sistemele de facturare, care sunt dezvoltate independent de zeci de companii. Exemple nu mai puțin frapante sunt bazele de date ale agențiilor de asistență medicală și de aplicare a legii. Dar ele conțin cantități impresionante de informații confidențiale și, în special, date personale, pe care legislația rusă obligă să le protejeze în mod fiabil. O astfel de atitudine neglijentă față de protejarea bazei de date cu date personale ale cetățenilor este motivul apariției constante a colecțiilor de baze de date privind persoanele fizice și juridice printre copiile piratate ale filmelor? Răspunsul la această întrebare ar trebui căutat, în primul rând, pe baza deficiențelor abordărilor descrise. Să încercăm să analizăm susținătorii acestor abordări.

Este suficientă autentificarea prin parolă?

Într-adevăr, ușurința în utilizare a protecției cu parolă este dincolo de orice îndoială. Dar simplitatea și fiabilitatea protecției în acest caz sunt incompatibile. În ceea ce privește siguranța și ușurința în utilizare, această tehnologie devine învechită. Puterea unei parole și, prin urmare, siguranța utilizării acesteia depinde direct de calitatea acesteia (caracterele folosite, cazul lor, diferența față de cuvintele cu sens). Și ușurința de utilizare scade rapid chiar și cu o ușoară creștere a „securității” parolei, deoarece amintirea unei combinații de caractere imposibil de citit este destul de dificilă. Să ne uităm la cifre și fapte. Parolele utilizatorului sunt stocate în DBMS Oracle ca valori hash și sunt citite de utilizatorii privilegiați. Algoritmul pentru calcularea unui hash de parole este cunoscut de mult. Cel mai cuprinzător studiu al puterii parolei în Oracle a fost realizat de Red - Baza de date - Security GmbH - cel mai mare expert mondial în domeniul securității produselor Oracle. Iată câteva date despre puterea parolei pentru versiunile DBMS 7-10g:

Pe un computer cu un Pentium 4 3 GHz, timpul necesar este (atac de forță brută):

• 10 secunde toate cele 5 combinații de caractere
• 5 minute toate cele 6 combinații de caractere
• 2 ore toate combinațiile de 7 caractere
• 2,1 zile toate cele 8 combinații de caractere
• 57 de zile toate cele 9 combinații de caractere
• 4 ani toate combinațiile de 10 caractere

Și acest lucru este atunci când utilizați departe de cel mai puternic computer. Pe măsură ce performanța crește, un atac de dicționar este efectuat și mai rapid. Acest lucru nu înseamnă că Oracle nu răspunde la această stare de lucruri - în versiunea DBMS 11g situația s-a îmbunătățit semnificativ. Algoritmul de generare a hashului și calitatea generării parolelor au fost consolidate. Ca urmare, cifrele de mai sus au crescut de 2,5-3 ori. Dar, în ciuda unor astfel de îmbunătățiri, Oracle recomandă utilizarea unor instrumente de autentificare îmbunătățite, care au fost și ele îmbunătățite în bine, de exemplu, a devenit posibilă utilizarea HSM (Hardware Security Module) pentru autentificare și stocare a cheilor de criptare.

Astfel, concluzionăm: fiabilitatea și securitatea utilizării parolelor pentru protejarea IP în prezent nu mai îndeplinește cerințele companiilor cărora, pe de o parte, le pasă de reputația lor, iar pe de altă parte, sunt obligate să respecte cerințele legislației în vigoare. .

Cost scăzut de proprietate - un mit?

Concepție greșită larg răspândită. Statisticile confirmă costurile semnificative pentru întreținerea, să zicem, parolele uitate. Companiile suferă pierderi și mai semnificative din cauza fiabilității scăzute și a securității protecției cu parolă.

Sunt vulnerabilități de securitate încorporate?

Și în această chestiune, ne confruntăm din nou cu opinia comună că măsurile standard de securitate sunt insuficiente. Cum putem explica apariția unei astfel de opinii, mai ales ținând cont de faptul că măsurile de securitate încorporate de cele mai multe ori nu sunt folosite la 100%. T

În ceea ce privește vulnerabilitățile măsurilor de securitate încorporate în Oracle, situația de aici este exact aceeași ca și în alte sisteme complexe. Oracle Corporation a adoptat în mod tradițional o abordare responsabilă pentru identificarea și eliminarea vulnerabilităților găsite. Actualizările CPU (Critical Patch Update) sunt lansate în mod regulat (de 4 ori pe an), eliminând defecte descoperite atât de Oracle însuși, cât și de alte zeci de companii, dintre care cea mai cunoscută este deja menționată Red - Database - Security GmbH. De exemplu, în CPU în octombrie 2007, 27 de vulnerabilități au fost eliminate în DBMS, 11 în serverul de aplicații, 13 în diverse aplicații. Având în vedere numărul de produse Oracle, versiunile acestora și platformele software și hardware pentru acestea, acest lucru nu este atât de mult.

Dezvoltare proprie vs suport furnizor

Există multe păreri despre această problemă. Unele organizații preferă să aibă propriile departamente de dezvoltare, altele nu. Poate cel mai convingător argument în favoarea suportului furnizorilor este că nu orice companie își poate permite să aibă specialiști în securitatea informațiilor în departamentul său de dezvoltare.

Cu toate acestea, chiar dacă există astfel de resurse, merită să rețineți că un sistem „scris acasă” depinde în mare măsură de echipa de dezvoltatori care a luat parte la proiectarea și crearea acestuia. Aceasta înseamnă nivelul lor de profesionalism, calificările lor sunt decisive în ceea ce privește calitatea dezvoltării, absența marcajelor încorporate în software și vulnerabilitățile care pot fi exploatate de atacatorii externi. În plus, soluțiile „scrise acasă” sunt pline de faptul că plecarea unuia sau mai multor „autori” cheie ai acestor soluții poate implica riscuri asociate cu sprijinirea și dezvoltarea corectă a infrastructurii create anterior de către noi specialiști.

Deci, să rezumam rezultatele intermediare. Principalele argumente prezentate de apologeții abordărilor pe care le-am enumerat - măsurile de securitate încorporate nu sunt utilizate și mijloacele „fabricate în casă” sunt mai fiabile decât cele standard - de fapt nu au o bază serioasă. Și companiile care urmăresc aceste opțiuni pentru a-și proteja bazele de date expun de fapt informațiile confidențiale conținute în baza de date la riscul de furt și scurgere.

Posibilități de îmbunătățire a funcțiilor de securitate: când este necesar?

Exemplul pe care l-am dat mai sus despre protejarea bazelor de date ale diferitelor instituții sociale este de fapt foarte orientativ. Până la urmă, vorbim de o întreprindere de stat, care are legătură directă cu respectarea, pe de o parte, cu interesele statului și, pe de altă parte, cu interesele cetățenilor. În consecință, problema protecției datelor stocate și prelucrate care circulă în infrastructura informațională a acestei instituții devine prioritatea numărul unu. Și în acest caz, utilizarea maximă a capabilităților instrumentelor standard de protecție în soluții de la furnizori de încredere poate fi încă insuficientă. Cerința de a întări protecția întreprinderilor de stat este legată, pe de o parte, de introducerea de tehnologii cu un nivel superior de securitate și, pe de altă parte, de îndeplinirea cerințelor legale, în special de utilizarea exclusivă a mijloace de protectie certificate.

Acesta este motivul pentru care a treia abordare „mixtă” a protecției sistemelor informaționale a început recent să capete amploare. Dacă analizăm cerințele tipice pentru protecția IP și capacitățile care pot fi implementate folosind instrumentele Oracle încorporate, putem identifica imediat ce trebuie suplimentat:

Algoritmi de criptare rusești (PKI, semnătură digitală, criptare în rețea și pe media)

Implementarea criptării atunci când scrieți pe medii fără a utiliza TDE

Depozitarea materialelor cheie.

Din motive evidente, dezvoltatorii Oracle nu au oferit o implementare universală a acestor două puncte, deși au oferit câteva abordări generale.

Aplicarea algoritmilor criptografici interni

Algoritmii criptografici pot fi utilizați în procesul de autentificare, generarea semnăturii digitale (GOST R 34.10-2001), pentru a proteja canalul de comunicație (GOST 28147-89, GOST R 34.11-94) și criptarea datelor (GOST 28147-89). Instrumentele încorporate ale Oracle nu implementează acești algoritmi nici în DBMS, nici în serverul de aplicații, nici în aplicații. Implementarea criptografiei sub formă de biblioteci, furnizori standard de criptografie (CSP), kituri de dezvoltare (SDK) este oferită de mai mulți producători ruși - CryptoPro, Signal-Com, Infotex, Lissy, CryptoCom, CryptoEx etc. Cu toate acestea, obținerea produselor Oracle a lucra cu bibliotecile propuse este destul de problematic . Ideea nu este că aceste instrumente nu sunt compatibile la nivel de software și hardware - încorporarea criptografiei în produsele Oracle nu ar trebui să încalce acordul de licență al furnizorului privind integritatea software-ului. Dacă, de regulă, problemele de încorporare nu apar cu IS construit pe baza serverului de aplicații Oracle sau a întregului set de aplicații Oracle, atunci cu un DBMS situația este mai complicată. Datorită faptului că nucleul SGBD nu are o interfață software pentru operațiuni criptografice (autentificare, criptare), trebuie utilizate soluții. De exemplu, utilizați protocolul de autentificare Kerberos sau generatoarele de parole unice cu protocolul RADIUS și protejați canalul de comunicație folosind software certificat.

Criptați datele fără a utiliza TDE

În ciuda simplității extreme a opțiunii Oracle TDE, este adesea necesar să renunțați la utilizarea acesteia. Există două motive principale:

Unele tipuri de date nu sunt acceptate

Nu există posibilitatea de a aplica în mod obișnuit criptoalgoritmi ruși

Nu există o protecție reală împotriva utilizatorilor privilegiați.

Prima problemă poate fi rezolvată în principiu folosind produse terțe - DbEncrypt pentru Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R.D.), The Encryption Wizard pentru Oracle (Relational Database Consultants, Inc.). A doua problemă este rezolvată în mod fundamental în același mod, dar aici există mai puține opțiuni - eToken SafeData sau Expertul de criptare pentru Oracle. Mai mult, pentru primul produs este necesar un ansamblu de versiune suplimentară (în funcție de producătorul certificat de criptografie utilizat), dar pentru al doilea produs, pur și simplu nu a fost posibil să se găsească informațiile necesare. A treia problemă ar putea fi, în principiu, rezolvată prin partajarea opțiunilor TDEȘi Oracle Database Vault dar, în acest caz, puterile administratorului SGBD curg fără probleme către administratorul va u lt bazei de date, adică. rămâne problema protecţiei faţă de utilizatorii privilegiaţi.

Depozitarea materialelor cheie

Materialul cheie (certificate, chei private, chei de criptare) utilizat de instrumentele de securitate încorporate Oracle pentru a autentifica sau cripta datele este stocat în containere de chei (numite portofele) ca fișierele obișnuite. Este necesară o parolă pentru a accesa informațiile din portofel. Adesea, această metodă de stocare nu îndeplinește cerințele de securitate, în special pe stațiile de lucru ale clienților. Oracle DBMS, începând cu versiunea 10g, vă permite să stocați chei private pe dispozitive hardware care acceptă standardul PKCS#11. În același timp, Oracle nu garantează în niciun fel funcționarea dispozitivelor hardware, altele decât cele de producție nCipher (nCipher Corporation Ltd.). Acest lucru nu este întotdeauna acceptabil, de exemplu, dacă se intenționează să se utilizeze doar hardware certificat. Și în acest caz, problema stocării cheilor și certificatelor poate fi rezolvată folosind soluții terțe. Pe piața rusă, poate singurul produs din clasa sa este eToken SecurLogon pentru Oracle (Aladdin Software Security R.D.).

Concluzie

În ciuda înțelegerii conștiente a problemei ridicate atât de legiuitori, cât și de organizațiile guvernamentale și comerciale, datele cu caracter personal sunt încă susceptibile la scurgeri de informații, a căror pagubă este uneori estimată la cifre foarte impresionante. Lipsa precedentelor de mare profil poate fi explicată prin latența crimelor în acest domeniu. Cu toate acestea, scurgerile apar în mod constant și mai devreme sau mai târziu o luptă la scară largă împotriva furtului bazelor de date va fi lansată la nivel de stat. Desigur, puteți folosi soluții necertificate, puteți folosi software fără licență și puteți reinventa singur roata, ignorând soluțiile industriale dovedite... Dar numai în acest caz, organizațiile ar trebui să fie conștiente de faptul că toate riscurile suplimentare - de la financiar până la reputațional - asociat cu utilizarea unor astfel de produse, își asumă, de asemenea, întreaga responsabilitate. Există amenințări și există consecințe. Adoptând una sau alta abordare pentru asigurarea securității resurselor informaționale, organizațiile fie își asumă riscuri, fie își creează cele mai sigure condiții.

În prezent, cerințele de securitate din partea consumatorilor sunt destul de ridicate, iar soluția optimă este să folosiți pe deplin instrumentele de securitate încorporate și să le completați cu înțelepciune cu produse și soluții de la dezvoltatori terți. Cu toate acestea, deseori dorința de a construi o protecție IP fiabilă se confruntă cu o lipsă banală de personal calificat - dezvoltatori, analiști, ingineri de suport tehnic, consultanți. Consecința acestui lucru este o cunoaștere slabă a capabilităților caracteristicilor de securitate încorporate ale Oracle și ale altor sisteme și utilizarea corectă a acestora. O altă consecință este aceeași situație, dar în legătură cu produsele altor producători de software și hardware pentru securitatea informațiilor și utilizarea acestora împreună cu tehnologiile și produsele Oracle. Drept urmare, sistemele existente continuă să folosească sisteme de protecție cu parolă învechite, dobândind modificări inutile și grămezi de reglementări suplimentare și, și mai rău, sunt dezvoltate noi sisteme informatice cu tehnologii de protecție vechi. Ieșirea din această situație, în primul rând, este formarea personalului care are cunoștințe experte în securitatea informațiilor în sine, în linia de produse Oracle și care sunt capabili să integreze evoluțiile companiilor rusești cu măsuri de securitate încorporate. O astfel de formare ar trebui să înceapă în universități specializate, iar specialiștii în acest domeniu ar trebui să aibă posibilitatea de a-și acumula experiență și abilități în centrele de formare. Aș dori să văd sprijin în această problemă atât de la Oracle, cât și de la alți producători care operează pe piața rusă de securitate a informațiilor.

În acest sens, o tendință foarte încurajatoare, în opinia noastră, este apariția unor soluții, metode și abordări reale de organizare a sistemelor de securitate a informațiilor, dezvoltate de companiile autohtone împreună cu reprezentanțele rusești ale corporațiilor occidentale. O astfel de cooperare face posibilă asigurarea nu numai a performanței stabile a mecanismelor de protecție ca parte a sistemului informațional, ci și a conformității acestor soluții cu cerințele legislației ruse.