Service · Cybersecurity

Database security

Behind the ERP, the online shop and the clinic software there is a database, and it is almost never reviewed on its own. The usual reasoning is that the application already protects it, but the application only controls what passes through its screens. Directly on the engine you tend to find the SQL Server “sa” account with its installation password, a MySQL root user shared between the shop and the agency, and a full export of the database that someone left in a shared folder for testing. We work on the layer beneath the application: engine accounts and permissions, encryption, query auditing and where backups and exports end up. It applies equally to SQL Server under a3ERP or Sage 200, to MySQL or MariaDB under PrestaShop and WooCommerce, and to PostgreSQL under Odoo.

Send an enquiry Jump to what is included

SQL Server, MySQL

PostgreSQL and MariaDB

Own accounts

for every application and every person

Encryption

at rest and in backups

Synthetic data

in development and test environments

What falls within the scope of this service

Every change is tested against the application that uses the database first. One permission removed carelessly can stop a whole company invoicing, and that is not something to discover in production.

Pin down the details with one of our engineers

Engine accounts

We remove or disable generic admin accounts, give each application its own user with rights over its own databases and give each administrator a named account, ideally linked to the directory.

Network exposure

A database should not listen on the internet or be reachable from the whole office. We restrict connections to the application servers and administrators, and enforce encrypted connections.

Encryption at rest

TDE on SQL Server, table encryption on MySQL and MariaDB or volume encryption in the cloud, with keys stored away from the server itself.

Auditing

A record of access to tables holding personal or financial data: who looked at the patient file, who exported the customer table, from which machine and at what time.

Backups and exports

Backups are encrypted and kept with restricted access. We hunt for forgotten exports in shared folders, on laptops and in mailboxes.

Test environments

Anonymised copies or synthetic data for development and training, instead of the production database with real names, ID numbers and addresses sitting on a developer's laptop.

How the engagement unfolds, one stage at a time

We work in agreed maintenance windows, with a verified backup before any change to permissions or encryption.

Review

Versions, patches, accounts, permissions, network settings and backup locations for every database engine you run.

Immediate risks

Default passwords, databases reachable from the internet and exports left open. These are closed in the first few days.

Hardening

Per-application accounts, encryption and auditing, applied with application testing at each step.

Documentation

A map of databases, accounts, permissions and backups, useful for your record of processing activities and for an ENS auditor.

When the application says “no access”, the database may still say yes. A user barred from payroll in the ERP can sometimes read the very same table from Excel over an ODBC connection, if the engine allows it. The permissions that count are the engine's; the ones on screen merely tidy up the menu.

Common questions

First we check, because it is often an installation requirement rather than a day-to-day one. If it really needs those rights, we limit where the account can connect from, turn on auditing for it and rotate its password with the reseller. You cannot always remove the privilege, but you can keep an eye on it.

At SME volumes the impact of encryption at rest is small and hard to notice in daily use. Even so, we measure performance before and after in a test window so you can see it with your own data.

Yes. Health data is a special category under the GDPR and the expected safeguards are higher: access auditing, encryption, protected backups and strict control over which of the software vendor's staff can connect. We also check that the vendor has signed a data processing agreement.

Yes. The cloud changes the tooling, not the principles: identities instead of shared passwords, network rules that limit access, encryption with managed keys and auditing switched on. If the data has to stay in Spain, we pin the matching region.

Other work we do in this field

Full area overview

Service GDPR and personal data protection Records of processing, permissions, audit trails and 72-hour breach handling Service Security policies and documentation A policy, a risk analysis and procedures people actually follow Service Security tooling deployment Choose, pilot and roll out security tools remotely Service Infrastructure security Perimeter, network segmentation and secure remote access

Protect the layer underneath your applications

Tell us which database engines you use, which applications depend on them and where backups are kept. We will reply with the first checks we would make.

Email
office@apply.es

Hours
Monday to Friday, 9:00-18:00 Spanish time (CET), answers within a working day

Meetings
Video calls via Google Meet or Teams

I agree that Apply may use my details to answer this request, as set out in the privacy policy