L’autoallotjament és el valor per defecte, no el pla B

La majoria de bases de dades són un servidor amb qui parles per xarxa. Executes un procés, obres un port, gestiones usuaris i la teva aplicació s’hi connecta com a client. Aquell model tenia sentit quan una base de dades era un mainframe compartit; en té menys quan el “servidor” és un contenidor al costat de la teva aplicació que no fa res més que atendre un sol servei.

Arkeion és diferent: és un motor encastat. cargo add arkeion i la base de dades viu dins de la teva aplicació com a biblioteca, llegint i escrivint un únic fitxer. No hi ha cap port per obrir, ni cap segon procés per vigilar, ni cap salt de xarxa entre el teu codi i les teves dades. La base de dades és a una crida de funció de distància.

Aquesta última frase és tota la història de seguretat en miniatura. Una base de dades encastada no té superfície d’atac pròpia — no hi ha res a assolir per la xarxa, perquè no hi ha xarxa. En el moment en què decideixes que altres màquines han de parlar amb les teves dades, ets tu qui obre aquella porta, deliberadament, i ets tu qui decideix qui la guarda.

El moment en què una base de dades dona la cara a internet

Molts sistemes reals sí que necessiten una base de dades accessible des de fora: una app mòbil que sincronitza amb un backend, una eina interna exposada a un equip, una API que serveix dades a socis. Tan bon punt un endpoint és públic, deixa de ser un fitxer tranquil i es converteix en un objectiu. Els atacs no són exòtics; són constants i automatitzats:

• Abús de taxa i denegació de servei — un sol client picant-te fins a tombar-te, o una botnet fent-ho expressament.
• Payloads maliciosos — intents d’injecció, cossos desmesurats, peticions malformades temptejant a la recerca d’una fallada.
• Credential stuffing — contrasenyes reutilitzades ruixades contra la teva autenticació, milers per segon.
• Scraping — recol·lecció lenta i pacient de tot el que estiguis disposat a lliurar.

Aquest és el principi de disseny al qual tornem un cop i un altre: aquesta feina defensiva no pertany a l’interior de la base de dades. La feina d’un motor de consultes és respondre consultes correctament i de pressa, no endevinar quins clients són hostils. Cargola el rate-limiting i la inspecció de payloads dins del motor i obtindràs un motor més lent i un escut més feble. L’escut va al davant, com a capa pròpia, on pot descartar trànsit dolent abans que arribi a costar-te una consulta.

quoxy posa quota al davant

Aquesta capa frontal és quota: rate-limiting, un WAF, un escut d’API, analítica i una xarxa edge — la maquinària d’un endpoint públic endurit, sense que l’hagis de construir. quoxy és la peça que uneix els dos mons: connecta el teu Arkeion autoallotjat amb quota, de manera que cada petició de fora passa primer per quota, i només el trànsit net i permès arriba a la teva base de dades per una connexió segura.

Com que l’adreça pública és la de quota i no la de la teva base de dades, el teu Arkeion no ha de ser mai directament accessible. Només escolta quoxy. El radi d’explosió d’un error s’encongeix en conseqüència: no hi ha cap port de base de dades obert a internet per trobar, només un edge construït perquè el trobin.

Què fa realment cada capa

El valor és en l’ordre en què passen les coses. Una petició fa una cursa d’obstacles, i cada etapa pot posar fi al seu viatge:

• Rate-limiting — pressupostos per clau i per ruta. Un client rep la seva part justa i no més; una allau es descarta a l’edge, lluny del teu motor, abans que pugui convertir-se en càrrega.
• WAF — inspecció de payloads. Les formes conegudes com a malicioses (cadenes d’injecció, cossos malformats, pujades desmesurades) es descarten així que es veuen.
• API shield — autenticació i validació d’esquema abans de la base de dades. Una petició sense clau vàlida, o amb un cos que no compleix el contracte, no arriba mai a ser una consulta. El teu motor només veu crides ben formades i autoritzades.
• Analítica — veus el trànsit: qui crida, amb quina freqüència, què s’està bloquejant i per què. La protecció que no pots observar és protecció en la qual no pots confiar.
• Edge — tot això corre a prop dels teus usuaris, així que l’escut afegeix un salt mesurat en mil·lisegons d’un sol dígit en comptes d’una volta al planeta.

Per què ho construïm així

Aquestes no són raons de màrqueting. Són les raons:

• És teva. La teva base de dades és un fitxer. El pots copiar, exportar, fer-ne còpia de seguretat i endur-te’l quan vulguis. No hi ha dades segrestades — res teu que només funcioni mentre ens continuïs pagant.
• Te’n pots anar. El motor és MIT/Apache. Aquesta llicència és una promesa que no podem revocar: construïm el que construïm a sobre, el que hi ha a sota continua sent teu i continua sent lliure.
• La protecció és el valor per defecte, no un extra de pagament. Exposar una base de dades sense res al davant és un tret al peu, i no creiem que el camí segur hagi de ser el car. quoxy existeix perquè “posar-la a internet” i “protegir-la” siguin la mateixa decisió, no dues.

Autoallotjament primer. Protegida per defecte. Teva, sempre. Aquesta és tota la idea — i és la mateixa idea que hi ha sota tota la resta del que fem.