Set capes de seguretat
InfoCifrada no confia en una sola defensa. Per sota de tot hi ha el xifratge AES-256-GCM, però per sobre hi ha set capes més, totes verificades al codi i no només declarades en un fullet.
Capa 1 · Autenticació
Contrasenyes d'accés amb bcrypt i salt automàtic, verificació resistent a atacs de temps i mínim de 8 caràcters validat al servidor. La verificació de correu és obligatòria: un compte acabat de crear no entra fins que es prem l'enllaç del correu. I no hi ha registre públic — els comptes només els crea un administrador, així que la superfície d'alta massiva és zero. El missatge d'error és sempre el mateix, per no revelar quins comptes existeixen.
Capa 2 · Limitació d'intents
Cinc intents fallits en una finestra de quinze minuts bloquegen l'accés. El recompte va per adreça de correu i per IP, així que no s'esquiva canviant de compte ni d'usuari. Un accés correcte neteja el comptador, i cada bloqueig deixa el seu propi registre d'auditoria. Tots dos paràmetres són configurables.
Capa 3 · Sessions
Galeta de sessió amb nom propi del projecte, marcada httponly —JavaScript no la pot llegir—, amb samesite: Lax i amb l'atribut secure automàtic quan hi ha HTTPS. A cada accés correcte es regenera l'identificador de sessió, que és el que anul·la la fixació de sessió. El tancament buida la sessió, expira la galeta i la destrueix.
Capa 4 · Protecció CSRF
Un testimoni de 32 bytes aleatoris, amb quatre hores de vida i comparació resistent a atacs de temps. Tots els formularis del sistema el porten i totes les pantalles el validen, comprovat un per un. Els punts d'acció rebutgen qualsevol mètode que no sigui POST.
Capa 5 · Autorització
Cada pantalla i cada acció comença exigint el seu permís concret; sense ell, la resposta és un 403 i s'ha acabat. Els permisos es resolen contra la base de dades a cada petició i no es guarden a la sessió, així que revocar un permís té efecte immediat sense esperar que l'usuari torni a entrar. I la caixa forta va més enllà: totes les seves consultes filtren per l'usuari de la sessió, mai per un que vingui del formulari.
Capa 6 · Entrada i sortida
A la base de dades, exclusivament sentències preparades reals —no emulades—, sense ni una sola concatenació de valors d'usuari. A la pantalla, tot el text passa per l'escapament d'HTML. La validació es fa sempre al servidor, mai només al navegador: longituds, formats de correu, expressions regulars per a identificadors i comprovació d'existència real a la base de dades per a cada referència. Fins i tot l'assumpte dels correus es neteja de salts de línia, per impedir la injecció de capçaleres.
Capa 7 · Capçaleres i sistema d'arxius
S'envien capçaleres de seguretat abans de qualsevol sortida, inclosa una política de contingut que no admet JavaScript incrustat a l'HTML: tots els gestors viuen en un fitxer a part. Això neutralitza la majoria de vectors d'injecció encara que arribés a colar-se contingut maliciós. Al disc, les carpetes de codi de servidor estan bloquejades a l'accés web, igual que el llistat de directoris, els mètodes HTTP innecessaris, els fitxers sensibles i els sondejos típics de bots.
El resum, en una frase
Autenticació amb bcrypt i verificació de correu · bloqueig per intents fallits · sessions endurides · protecció CSRF a cada formulari · permisos comprovats a cada pantalla · consultes preparades i escapament total · capçaleres de política de contingut i bloqueig a nivell de sistema d'arxius. I per sota de tot, AES-256-GCM.
Què aporta davant d'una inspecció
Convé formular-ho amb precisió, perquè és on més s'exagera en aquest sector: InfoCifrada aporta mesures tècniques que ajuden a demostrar compliment. No és una certificació i no es ven com a tal. Qui et digui que un programari «et posa en compliment del RGPD» t'està venent fum.
| Exigència | Com hi respon InfoCifrada |
|---|---|
| RGPD art. 32 — xifratge de dades personals | AES-256-GCM sobre els camps sensibles |
| RGPD art. 32 — confidencialitat i integritat | Xifratge autenticat amb detecció de manipulació |
| RGPD art. 32 — capacitat de restaurar l'accés | Còpies de seguretat més procediment documentat de custòdia del salt |
| RGPD art. 30 — registre d'activitats | Auditoria de només lectura amb usuari, IP i marca temporal |
| Principi de mínim privilegi | Permisos granulars per rol, comprovats a cada pantalla |
| Traçabilitat d'accessos | Registre d'accessos correctes, fallits i bloquejats |
| Sobirania de la dada i no transferència internacional | La dada no surt del servidor del client |
| Segregació de funcions | Perfil auditor: llegeix tot, no modifica res i no accedeix a cap caixa forta |
I el que avui no fa
Un producte sense limitacions declarades no se'l creu ningú, i menys en seguretat. Aquestes són les mancances actuals, dites per endavant:
| Limitació | Què significa a la pràctica |
|---|---|
| Sense doble factor | L'accés depèn només de la contrasenya. Ho compensen el bloqueig per intents, la verificació de correu i que els comptes només els crea un administrador. És el primer del pla de desenvolupament. |
| Sense caducitat de sessió per inactivitat | La sessió dura el que duri la galeta del navegador. També és al pla. |
| Salt únic per instal·lació, no per entrada | Dos usuaris amb la mateixa contrasenya de caixa forta deriven la mateixa clau. Un atacant que tingués alhora la base de dades i el salt podria atacar per diccionari les contrasenyes febles. Avui ho mitiguen les 200.000 iteracions i que el salt viu fora del repositori. |
| Sense rexifratge massiu | Canviar la contrasenya de caixa forta obliga a editar entrada per entrada. |
| Sense adjunts | Només text: no es poden custodiar certificats ni fitxers de clau. |
A la comparativa hi ha també les columnes on InfoCifrada perd davant d'un gestor comercial. Preferim que ho sàpigues abans de comprar i no després.
Tens un responsable de seguretat que vulgui repassar això?
Encantats. És la conversa que millor se'ns dóna, i el codi hi és per auditar-lo.
Escriu-nos