Service · IT security

Database security

Beneath nearly every business application sits a database, and it seldom gets attention while things run smoothly. The ERP stores its data in Microsoft SQL Server, the WooCommerce shop in MySQL or MariaDB, the home-grown client management tool in PostgreSQL. Typical findings then look like this: the application logs in as “sa”, whose password has not changed since installation; the database port is reachable from the internet because that made the software partner’s maintenance easier; and the nightly backup sits unencrypted on a network share every employee can write to. An attacker does not need to work through the application at all, he simply lifts the data straight out of the tables. We look at this layer specifically, whether the database runs on its own server, in a virtual machine or as a managed cloud service, and sort out accounts, network access, logging and backups.

No shared account
for applications, admins and reporting
No open ports
facing the internet
Encrypted
at rest, in transit and in the backup
Restore test
on a schedule, not just the backup job

Everything this covers

We cover Microsoft SQL Server, MySQL, MariaDB and PostgreSQL, on premises or in Azure, AWS and with European providers. Changes to databases behind packaged software are agreed with the vendor or software partner.

Settle the details with an engineer

Accounts and privileges

A dedicated login for each application, personal logins for administrators, read-only logins for reports and analysis. The “sa” account and similar defaults are disabled or given a strong password kept in a safe place.

Network exposure

The database is reachable only from the servers that use it. Maintenance by software partners goes through a VPN or jump host, not an open port.

Encryption

Transparent data encryption or full-disk encryption, TLS between application and database, and encrypted backup files whose key is stored separately.

Audit trail

Recording sign-ins, privilege changes and reads of especially sensitive tables such as health or payroll data, forwarded to a central store so an intruder cannot wipe the evidence.

Patching

Cumulative and security updates for the database engine on a schedule that matches the software vendor’s approvals. Unsupported versions are flagged and an upgrade is planned.

Backup and restore

Backups out of reach of ordinary users, one copy held in immutable storage, and a documented restore test in an isolated environment.

Our working method

Databases carry the business, so nothing changes without a backup, agreement and a way back.

01

Inventory

Which database instances exist, which versions, which applications depend on them and who has access. Forgotten test databases full of real customer records often turn up at this stage.

02

Assessment

Configuration, accounts, network, encryption and backups are measured against recognised hardening guidance. You receive a ranked list of findings.

03

Remediation

Changes during a maintenance window via remote access, coordinated with your software partner. Application logins are switched over without users noticing.

04

Restore drill

We restore a backup into a separate environment and time how long it takes. The result goes into your emergency documentation.

A backup that has never been restored is a hope, not a backup. Time and again we see damaged backup files, a missing key, or a restore that takes a day instead of an hour. You want to learn that during a drill, not on the morning the accounts department grinds to a halt.

Frequently asked questions

Sometimes during installation and upgrades, rarely in day-to-day operation. We clarify with the vendor which rights are really needed and, if necessary, set up a separate upgrade login that is enabled only during maintenance.

The provider takes care of the operating system and engine patches. Logins, network rules, firewall settings, encryption keys and logs remain your responsibility, and that is exactly where we find most gaps in cloud databases.

From a GDPR perspective, yes, if there is no reason for it and it is less well protected than production. We help anonymise test data or generate synthetic data, and delete old copies once you approve.

At least twice a year and after any major change to the application or the backup tool. For critical systems we recommend a quarterly drill.

Protect the layer beneath your applications

Tell us which database systems and applications you run. We will outline what a first assessment would cover.

Availability
Monday to Friday, 8:00-17:00 Austrian time (CET/CEST), reply within one working day
Meetings
By video on Microsoft Teams or Google Meet

We only use cookies that are technically required: to run the website and to remember the location you picked. There are no advertising or tracking cookies. Details are in the privacy notice.