Exemplu de utilizare a securității obiectului privat în Delphi
Exemplu de utilizare a securității obiectului privat în Delphi
Atunci când creați aplicații server, este adesea o problemă de diferențiere a accesului diferitelor grupuri de utilizatori la funcțiile acestei aplicații. În cazul în care serverul se execută un sistem care are propria sa implementare a kontorlya de acces (server de baze de date, sistem de fișiere, etc), soluția este evident - pentru a schimba această sarcină pe sistemul țintă în sine. Cu toate acestea, în unele sluchaeh această metodă nu este aplicabilă - fie în sistemul țintă nu are propriul mecanism, fie că este necesar să se pună în aplicare algoritm de diferențiere este diferită de cea existentă. În acest caz, în general, programatorul are două moduri:
- implementați-vă singur întregul mecanism de protecție
- Utilizați mecanismul furnizat de sistemul de operare Windows "Private Object Security"
În opinia mea, a doua opțiune are următoarele avantaje importante:
- Acesta este implementat de o echipă de profesioniști în această zonă foarte delicată
- Codul de implementare a fost testat de un număr mare de utilizatori, iar erorile identificate sunt eliminate rapid de către echipa de dezvoltare, adică fără participarea noastră.
- Mecanismul sistemului este extrem de flexibil, convenabil și, cel mai important, familiarizat cu administratorii de sistem.
În acest fel va fi subiectul discuțiilor din acest articol.
Etape lungi
Nu este necesar să fim speriați :) De fapt, acest mod nu este atât de mare, iar codul scris o dată, poate fi folosit cu succes în mod repetat.
Întregul proces de punere în aplicare a protecției bazate pe „securitate Obiect privat“ destul de clar împărțit în mai multe etape separate complet, și este, în opinia mea, este un alt plus, deoarece o astfel de izolare reduce semnificativ probabilitatea de apariție a erorilor de „cruce“. Etapele sunt următoarele:
- Determinați ce funcții de server necesită controlul accesului
- Pe baza etapei anterioare, definiți un set de drepturi care oferă acces la anumite funcții sau grupurile lor și le proiectați sub forma unui set de constante.
- Determina ce specifică tu și, eventual, drepturile standard și combinația lor va îndeplini drepturile fundamentale GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE și GENERIC_ALL.
- Creați și inițializați descriptorii de securitate, apoi, dacă este necesar, salvați-le într-un magazin persistent.
- Implementați un mecanism care permite administratorului de sistem să schimbe setările protecției.
- De fiecare dată când clientul sună la funcția protejată pentru a verifica dacă clientul are setul corect de drepturi de a-l apela.
Acum este momentul să luați în considerare fiecare etapă separat. Vom face acest lucru pe baza codului exemplului atașat articolului.
Notă: Pentru a îmbunătăți claritatea citărilor codului publicate aici, întreaga gestionare a erorilor este complet omisă. În realitate, desigur, nu puteți face acest lucru, iar în exemplul atașat există o astfel de procesare.
Etapa unu. Ce vom apăra?
Pentru punerea în aplicare a exemplului la articol, am ales destul, în opinia mea, un obiect abstract. Abrazivitatea sa, pare, a fost un parametru foarte important pentru demonstrarea exactă a principiilor generale de construire a unui sistem, fără a fi legată de condiții specifice.
Deci, vom proteja un set de linii de text cele mai obișnuite. Serverul va stoca acest set de liste cu un descriptor de securitate pe disc, îl va încărca la pornire și îl va salva la sfârșitul operării. Pentru a lucra cu acest set, serverul va oferi clienților următoarele funcții:
- Obținerea numărului de rânduri.
- Citirea unei linii specifice pe index.
- Suprascrie un rând existent.
- Adăugarea unei noi linii.
- Ștergeți linia.
În plus, serverul oferă următoarele funcții pentru administrare:
- Citiți setările de securitate existente.
- Modificați setările de protecție.
Și aici răspundem la întrebarea "ce să protejăm?" - "Totul!"
Etapa a doua. Hotărât cu drepturile.
Deci, avem o listă de funcții protejate. Acum, pe baza noastră, definim un set de drepturi pentru a lucra cu aceste funcții:
În parametrul PrivilegeSet, funcția vă va întoarce setul de privilegii pe care le-a luat în considerare la luarea deciziei de acordare a accesului. În parametrul GrantedAccess, funcția vă va spune care dintre drepturile solicitate are clientul curent. Și în parametrul AccessStatus veți obține rezultatul general al testului - indiferent dacă vi se permite sau nu să efectuați toate acțiunile solicitate.
Câteva cuvinte despre exemplu
Exemplul atașat la articol include un grup de trei proiecte:
- Server AccCtrlSvc.dpr (server de dosare)
- Client AcsClient.dpr (dosarul client)
- Apletul panoului de control AcsCntl.dpr (dosarul CPL)
În plus față de acestea, arhiva include, de asemenea, DCU (pentru DCU-fișier) dosar, BIN (aici intră module ipolnyaemye), Shared (aici sunt modulele care nu sunt incluse în proiectele, dar le folosesc) și MsgLibrary, conținând un AcsMsg.dpr proiect separat, numai al cărui scop este să fie un container pentru tabela de mesaje utilizată la logarea acțiunilor serverului. Trebuie remarcat faptul că tabela de mesaje inclusă în el este destinată depanării serverului în locul informării administratorului de sistem, așa cum ar trebui să fie în practică. Acest lucru este explicat de scopul însuși al acestui server - de a servi ca instrument de formare.
Despre applet-ul a fost deja spus destul, nu este nimic de spus despre client, este prea simplu. Dar despre server este ceva mai mult de spus.
Serverul este executat ca serviciu. La instalare, acesta adaugă informațiile necesare registrului, atunci când dezinstalați-l șterge. Prima dată când serverul creează fișierul ACService.dat în directorul "Date de aplicație" al utilizatorului Localsystem. Când dezinstalați acest fișier este, de asemenea, șters. În acest fișier, serverul stochează într-o formă criptată descriptorul de protecție a volumului și datele obiectului protejat.
Ca transport, serverul folosește țevi numite. Alegerea acestora este explicată prin ușurința de implementare, combinată cu ușurința de confesiune a clientului de către server. În plus, am avut deja o implementare gata a acestui transport. Cu toate acestea, pentru a reduce codul non-articol, codul de transport a suferit o reducere foarte gravă. În primul rând, "sub cuțit" are tot ce are legătură cu optimizarea productivității. De asemenea, protocolul de schimb a fost simplificat până la limită și redus la o schemă rigidă "cerere-răspuns". Toate acestea fac ca această realizare a transportului să fie nepotrivită pentru a fi utilizată în proiecte reale, dar este destul de potrivit ca punct de plecare pentru realizarea de către dvs. a unui astfel de transport.
Dacă sunteți interesat de materialul acestui articol, atunci pentru dvs. există un sens direct pentru a extinde și aprofunda cunoștința cu acest subiect. În scopul instruirii, vă pot sugera să rezolvați următoarele sarcini:
- Adăugați capacitatea de a crea obiecte de către clienți, astfel încât serverul să accepte lucrul cu mai multe obiecte cu diferite setări de securitate.
- Adăugați suportul de audit pentru obiectele dvs.
- Adăugați suport pentru un arbore al obiectelor cu capacitatea de a moșteni setările obiectelor copil.
Trimiteți-le prietenilor: