Privileges
Every application connects with its own minimal login, administrators use personal ones and reporting tools only read. Default superusers such as “sa” or “root” are switched off or locked down hard.
Accounts software, a web shop and a booking tool look completely different to the user. Underneath, each relies on a data store, which is what an intruder actually wants. Picture a Ljubljana accountancy practice of twelve people. Its ledger software sits on SQL Server using the built-in “sa” superuser and a password that has been shared around for years, and the SQL port was opened on the firewall during the pandemic so someone could work from her kitchen table. Nobody shut it afterwards. Elsewhere, a WooCommerce retailer accumulates database dumps in a web folder anyone could download. On screen, both businesses see nothing wrong. The weakness is a level below. That level is our focus: who connects, with what privileges and from where; whether data and logs are protected; and whether a backup can genuinely be brought back to life. Microsoft, MySQL, MariaDB and PostgreSQL engines are all familiar territory, on your own hardware or hosted. Where the database belongs to a commercial package, we agree each change with the vendor and carry it out online, outside your busy hours.
We handle the common engines wherever they run: a server cupboard, Azure, AWS or European providers such as Hetzner and OVHcloud. If the database belongs to packaged software, the supplier or reseller approves changes first.
Every application connects with its own minimal login, administrators use personal ones and reporting tools only read. Default superusers such as “sa” or “root” are switched off or locked down hard.
Only servers with a real need may reach the database. People working from home reach it only via VPN or the app server.
TDE or encrypted volumes, TLS on the connection from app to database, encrypted backup files. Encryption keys are documented and stored apart from the data.
Sign-ins, rights changes and lookups in tables holding salaries, customer accounts or medical histories are captured in a store the DBA cannot wipe single-handedly.
Engine patches follow a timetable, after checking which version your software vendor certifies. End-of-life versions receive an upgrade path.
Backup sets live where neither everyday users nor the web server can touch them, in immutable form, with written and rehearsed recovery steps.
A business stands on its databases, so every change comes with a copy, a sign-off and an exit route.
Database servers, versions, connected applications and existing logins are listed. Expect at least one abandoned test copy or leftover from an old application.
Configuration, rights, exposure, encryption and backups are compared against CIS guidance and vendor manuals; findings come sorted by severity.
Carried out remotely in an agreed window with your software partner, with a complete backup taken before each one.
We bring a backup back in an isolated environment, confirm the application starts and the data is whole, and record how long it took.
Until you have restored it, a backup is a hope rather than a plan. Attackers target backups early, and many victims only then learn that nobody remembers the recovery procedure. Regular test restores cost little and are skipped far too often.
We stay away from schemas, tables and how the application account behaves, limiting ourselves to server configuration, admin logins, network rules, encryption and backup. Each step is still shown to your software partner beforehand, since certain items, for example the application login's privileges, need their approval.
With shared hosting our reach is limited to accounts, passwords, where backups go and how the app connects. Give us a VPS or a dedicated machine and the full programme applies. The first review tells us which applies.
Set up carefully, hardly at all. We record touches on sensitive tables and privilege changes, not every query, then monitor speed for a few weeks and trim if necessary.
If it is out of vendor support, yes: newly found holes stay open. Until then, exposure is cut back even more and logging tightened. The lasting answer is upgrading, so we identify a version your software partner supports and draft a migration plan.
Tell us which database engines you run and on what infrastructure, and we will point out early warning signs and propose a review.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.