Soluții · Instituții & administrație
O primărie sau o instituție are o listă fixă de secțiuni obligatorii, o obligație de transparență decizională și un funcționar care trebuie să publice un anunț fără să sune un programator. Construim exact asta, cu jurnal de audit care se șterge singur la termen și cu limită la încercările de autentificare.
Construit dejaDouă platforme proprii, publice și verificabile azi. Prima e site-ul oficial al unei primării de comună: Laravel 12 pe PHP 8.2 cu MySQL 8, 40 de șabloane, 32 de rute, 10 migrări, cu conținutul editorial care se schimbă rar ținut într-un singur fișier de configurare de 1.613 linii și cu cel care se schimbă des în bază, editabil din panou; autentificarea în panou e limitată la 5 cereri pe minut, iar jurnalul de audit se șterge zilnic după 12 luni, cu trimitere explicită la temeiul legal. Antetele de securitate se pot citi din exterior chiar acum. A doua e o platformă civică în producție, cu 65 de rute de interfață de programare, peste 50 de migrări, 103 fișiere de test pe partea de server și 59 de scenarii capăt-la-capăt, cu verificare de accesibilitate în teste. Ce nu trecem la „livrat”: interoperabilitatea cu serviciile de stat — codul de autentificare federată și de semnătură electronică e scris și testat, dar oprit, pentru că lipsesc contractul cu autoritatea și certificatul de sistem.
Un site de instituție publică nu se judecă după cum arată, ci după o listă. Hotărârea de Guvern 728/2023 stabilește ce secțiuni trebuie să existe: transparență decizională, proiecte și decizii, anunțuri, documente, contacte, buget. Sunt obligatorii, se verifică și nu se negociază. De aceea le construim de la început, ca structură, nu le adăugăm la final — adăugate la sfârșit ies formale și nefolositoare, iar asta se vede imediat.
A doua condiție e mai practică: instituția trebuie să poată publica singură. Un anunț de licitație, un proiect de decizie pus în consultare, o fotografie de la un eveniment — dacă fiecare trece printr-un dezvoltator, informația de interes public rămâne pe hârtie sau pe un grup de rețea socială, iar site-ul devine o vitrină moartă. Am separat intenționat două feluri de conținut: cel editorial care se schimbă rar — geografie, istoric, instituții, contacte, buget — stă într-un singur fișier de configurare citit direct de șabloane; cel care se schimbă des stă în baza de date și se editează din panou.
A treia condiție e cea despre care nu întreabă nimeni în caietul de sarcini: ce se întâmplă cu datele. Un panou de administrare publică are nevoie de limită la încercările de autentificare — la a șasea cerere într-un minut de la aceeași adresă, răspunsul e 429, iar asta e acoperit de un test automat, nu presupus. Jurnalul de audit conține adrese IP, deci e dată personală: o sarcină programată îl curăță zilnic de tot ce e mai vechi de douăsprezece luni, cu temeiul legal scris în comentariul codului, nu într-un document separat pe care nimeni nu îl deschide.
Și, în sfârșit, partea despre care preferăm să vorbim înainte de licitație: interoperabilitatea cu serviciile guvernamentale. Autentificarea federată și semnătura electronică sunt scrise și testate la noi, dar oprite dintr-un comutator, pentru că lipsesc contractul cu autoritatea și certificatul de sistem — lipsește hârtia, nu codul. Pentru platforma de plăți a statului, magistrala de interoperabilitate și cabinetul cetățeanului nu avem niciun cod, în niciun depozit, și scriem asta ca atare.
Ce cuprinde
Transparență decizională, proiecte și decizii, anunțuri, documente, contacte, buget, plus declarația de accesibilitate, informarea privind prelucrarea datelor, secțiunea de date deschise și harta site-ului. Conformitatea cu hotărârea de guvern e scrisă în cod — în șabloane și în configurație — nu doar afirmată în ofertă.
Ce se schimbă rar — date despre localitate, istoric, instituții, componența consiliului, contacte, buget — stă într-un singur fișier de configurare de 1.613 linii, citit direct de șabloane; ce se schimbă des — anunțuri, galerie, proiecte și decizii, documente, setări de transparență — stă în baza de date și se editează din panou. Separarea nu e estetică: reduce la minimum ce poate strica cineva printr-o editare greșită.
Panoul acoperă exact operațiile care se fac săptămânal într-o primărie: un anunț nou, un proiect de decizie pus în consultare, un document încărcat, câteva fotografii. Fiecare acțiune de administrare intră într-un tabel de audit — cine, ce, când — pentru că într-o instituție publică întrebarea „cine a publicat asta” are, mai devreme sau mai târziu, un răspuns care contează.
Cinci cereri pe minut de la aceeași adresă pentru formularul de autentificare; a șasea primește 429. Nu e o setare pe care o afirmăm: există un test automat care verifică exact întoarcerea codului 429. Diferența dintre o măsură configurată și una testată se vede abia când cineva schimbă o rută și uită de ea.
Pe producție se citesc din exterior: interzicerea încadrării în cadru, `nosniff`, politică de referință strictă, transport securizat impus pe un an cu subdomenii, politică de permisiuni care închide geolocația, microfonul și camera, plus o politică de conținut explicită. Le verificăm cu o cerere, nu cu o promisiune.
Jurnalele de audit conțin adrese IP. O sarcină rulează zilnic și șterge tot ce e mai vechi de douăsprezece luni, cu trimiterea la temeiul legal scrisă în comentariul codului. E diferența dintre o politică de confidențialitate care spune „păstrăm cât e necesar” și un sistem în care termenul chiar se aplică singur.
În platforma civică, verificarea rulează în testele automate pe criteriile WCAG 2.0 A și AA plus 2.1 A și AA, cu o linie de referință per pagină: orice problemă nouă oprește livrarea, chiar dacă nivelul general nu s-a schimbat. Pentru o instituție publică accesibilitatea nu e o opțiune de imagine, iar declarația de accesibilitate nu se scrie fără să fi rulat ceva.
Pagina de start publică date structurate de tip organizație guvernamentală, cu adresa poștală. Contează pentru cum apare instituția în rezultate și pentru sistemele care citesc automat; e și una dintre puținele categorii pentru care documentația motorului mai arată rezultatul îmbogățit cu întrebări frecvente — dar „binecunoscut și autoritar” nu e o casetă pe care o bifăm noi, deci nu îl vindem ca livrabil.
Nu declarăm ca livrată legătura cu platforma de plăți a statului, cu magistrala de interoperabilitate sau cu cabinetul cetățeanului: nu avem cod pentru ele în niciun depozit. Autentificarea federată și semnătura electronică le avem scrise și testate, dar oprite — lipsesc contractul cu autoritatea și certificatul de sistem. Iar găzduirea pe infrastructura de stat, unde e obligatorie, e o cerință de procedură, nu o opțiune tehnică.
Traseul
Prima livrare e lista secțiunilor obligatorii pentru tipul tău de instituție și corespondența lor cu ce publicați azi. De aici se vede ce lipsește, ce există pe hârtie și ce e publicat într-un loc care nu se poate cita. Designul vine după listă, nu invers.
Ce se schimbă rar merge în configurație, ce se schimbă des merge în bază, cu panou. Livrăm structura completată cu datele reale ale instituției — nu cu text de umplutură — pentru că un site de instituție cu conținut provizoriu nu poate fi evaluat de nimeni și, de obicei, rămâne așa.
Limita la formularul de autentificare cu test care o verifică, jurnal de audit cu ștergere programată la termen, antete de securitate verificate din exterior, pagina de informare privind prelucrarea datelor cu temeiurile numite. Livrăm rezultatul verificărilor, nu doar configurația.
Predăm depozitul, documentul de punere în funcțiune și accesele, plus o instruire pentru persoana care va publica anunțurile. Livrarea nu se consideră încheiată până când un funcționar nu a publicat singur un anunț care apare pe site.
Datele
Regulile diferă de la o industrie la alta. Acestea sunt cele care se aplică în instituții & administrație.
Un caz
Situația
Panoul de administrare al unui site de primărie ține un jurnal de audit: cine a publicat, ce și când. Jurnalul conține adrese IP, deci conține date personale. Aproape toate site-urile de acest fel rezolvă problema într-o propoziție din politica de confidențialitate — „păstrăm datele cât este necesar” — și cu asta se încheie.
Ce am construit
Am scris termenul ca sarcină programată: o rutină rulează zilnic și șterge din jurnal tot ce e mai vechi de douăsprezece luni, cu trimiterea la temeiul legal scrisă în comentariul de deasupra codului. În aceeași etapă am pus limita la formularul de autentificare — cinci cereri pe minut de la aceeași adresă — și un test automat care verifică întoarcerea codului 429, ca măsura să nu dispară tăcut la o refactorizare.
Ce a ieșit
Politica publicată și comportamentul sistemului spun același lucru, iar diferența se poate verifica: termenul e o linie de cod care rulează în fiecare noapte, nu o intenție. Antetele de securitate se citesc din exterior cu o singură cerere.
Ce nu spune cazul
Găzduirea, artefactele de publicare și configurația de server rămân informație internă. Iar conținutul — datele despre localitate, componența consiliului, bugetul — aparține instituției și e furnizat de ea: noi am construit structura și panoul, nu datele.
Întrebări
Lista vine din Hotărârea de Guvern 728/2023: transparență decizională, proiecte și decizii, anunțuri, documente, contacte, buget, plus paginile de accesibilitate și de informare privind prelucrarea datelor. Le construim ca structură de la început. În lucrarea pe care o cităm, conformitatea e scrisă în cod — în șabloane și în configurație — nu doar afirmată în ofertă.
Da, și asta e jumătate din lucrare. Anunțurile, proiectele de decizie, documentele și galeria se editează din panou. Ce rămâne în configurație e conținutul care se schimbă rar — istoric, geografie, componența consiliului — tocmai ca o editare de rutină să nu poată strica structura.
Da. Fiecare acțiune de administrare intră într-un tabel de audit, cu actorul, rolul, tipul evenimentului și momentul. Jurnalul conține și adresa IP, deci e dată personală și are termen: se șterge zilnic tot ce e mai vechi de douăsprezece luni.
La a șasea cerere într-un minut de la aceeași adresă primește 429. Nu e o afirmație: un test automat verifică exact acest cod de răspuns. Pe lângă asta, antetele de securitate din răspunsul real se pot citi din exterior — interzicerea încadrării în cadru, `nosniff`, politica de referință, transportul securizat impus și o politică de conținut explicită.
Codul e scris și testat, dar oprit dintr-un comutator, iar testul implicit verifică tocmai că starea oprită nu scurge nimic. Ce lipsește nu e codul: lipsesc contractul cu autoritatea și certificatul de sistem. Varianta care funcționează azi e ca cetățeanul să semneze pe portalul oficial și să încarce documentul semnat înapoi. Preferăm să spunem asta înainte de licitație, nu după.
Nu avem cod pentru ea, în niciun depozit — la fel pentru magistrala de interoperabilitate și pentru cabinetul cetățeanului. Am verificat asta cu o căutare pe cuvânt întreg în toate proiectele noastre. Când o instituție are nevoie de ele, e o lucrare de integrare cu propriile ei condiții și propriul ei calendar de acorduri, și așa o scriem în ofertă.
Acolo unde e obligatoriu prin hotărâre de guvern, da, și e o cerință de procedură, nu o alegere tehnică. O tratăm ca atare de la început, pentru că schimbă modul de publicare și lista de acorduri necesare, nu doar adresa serverului.
Cu o verificare care rulează în testele automate, pe criteriile WCAG 2.0 A și AA plus 2.1 A și AA, cu o linie de referință per pagină: orice problemă nouă oprește livrarea. Declarația de accesibilitate se scrie după ce verificarea rulează, nu înainte — altfel e un text care contrazice pagina pe care stă.
În platforma civică, fotografia brută rămâne probă privată; public ajunge doar varianta redactată, cu proveniența păstrată și cu aprobarea explicită a unui moderator, iar cel care redactează nu e cel care aprobă. Dacă starea unei imagini devine nesigură, dosarul se retrage automat din public. Sunt constrângeri în bază de date, nu instrucțiuni pentru operator.
Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.