Database Security and KVKK Technical Measures

The technical questions put in a KVKK audit are answered at the database layer: is the data encrypted on disk, who accessed personal data, is real data present outside production, and were records past their retention period destroyed?

Sinan Alyuruk Founder β€” MySQL and PostgreSQL consultant

We build the KVKK technical measures end to end

Encryption, audit logging, data masking and destruction are asked about together in an audit, not one at a time. We design all four as a single architecture across MySQL and PostgreSQL.

Encryption (TDE)

Data is stored encrypted on disk. On the MySQL side we configure InnoDB encryption and keyring management; on the PostgreSQL side, the pg_tde component. Key management is integrated with your corporate key server.

Audit logging

Who accessed personal data, when, and with which query is recorded. We use Percona Server audit log on the MySQL side and pgaudit on the PostgreSQL side. Retention of the records and access control over them are configured under the same scope.

Data masking

Real personal data is not copied into test, development or analytics environments. Using Percona Server data masking on MySQL and PostgreSQL Anonymizer on PostgreSQL, we feed non-production environments with realistic but de-identified data.

Retention and destruction

Personal data past its retention period is removed from the system together with its related records, in a verifiable way. On the MySQL side we run that process with our own product, GoArchive.

Technical measures are not the whole of compliance

Turkey’s Personal Data Protection Law no. 6698 (KVKK) obliges the data controller to take technical and administrative measures to protect personal data. The guidance published by the Personal Data Protection Board covers the two groups of measures separately. This page covers only the part of the technical measures that falls to the database layer.

We state the scope up front because of the mistaken assessment we meet most often in the field: assuming compliance has been achieved because encryption has been enabled. Encryption alone does not make an organisation compliant. But when the technical questions are put in an audit, most of the answers are given at the database layer; an organisation that walks into that layer unprepared collects a finding even when every other process is complete.

How the four technical measures are applied

Encryption

On the MySQL side InnoDB encryption is in the core, so the work focuses on getting key management right. An installation where the encryption key is stored on the database server itself largely defeats the purpose of encrypting at all.

The PostgreSQL side needs a different approach: the PostgreSQL core does not include TDE (Transparent Data Encryption) support. The capability is provided by the pg_tde component, and pg_tde is part of the Percona Server for PostgreSQL distribution. So a request to “enable encryption on the PostgreSQL side” corresponds in most scenarios to a distribution migration project. We carry that migration out end to end.

Audit logging

The question put in an audit is not “do you keep records” but “who accessed this person’s data”. To be able to answer, records have to be kept at the query level and stored in a readable form. We configure the audit log component of Percona Server on the MySQL side and the pgaudit extension on the PostgreSQL side. Where the records are written, how long they are kept and who can reach them are designed under the same scope; audit records themselves contain personal data and therefore need protection of their own.

Data masking

Opening a production backup in a test environment is the most common route by which personal data is copied uncontrolled, and it is usually not assessed as a risk. Using the masking functions of Percona Server on the MySQL side and the PostgreSQL Anonymizer extension on the PostgreSQL side, we feed non-production environments with realistic but de-identified data. The basic requirement of a masking design is that the data distribution is preserved and the test processes are not broken.

Retention and destruction

The Regulation on the Deletion, Destruction or Anonymisation of Personal Data imposes a periodic destruction duty for data past its retention period. At the database layer the difficulty lies not in the deletion itself but in the data being deleted together with its related records and with verification: when a record is deleted while the rows attached to it are left in the system, the result is both orphaned data and an incomplete destruction process.

On the MySQL side we run the archiving of data past its retention period with our own product, GoArchive. It moves related records together, verifies that they reached the target system complete, and deletes from the source only once verification has succeeded. The auditable trail the destruction duty calls for comes out of that verification step. We have no equivalent product on the PostgreSQL side; there we build the retention processes with the existing tools.

Technical measures on the MongoDB side

The same four headings apply on MongoDB installations, but the tools differ. Audit logging and encryption at rest are not present in MongoDB Community Edition; both are configured through the Percona Server for MongoDB distribution. That distribution is built on the same core, and the change requires nothing on the application side.

We build access control on a role basis, following the principle of least privilege. The finding we meet most often in the field is the application connecting to the database with administrative privileges; where no authorisation is done at collection level, the audit records can no longer distinguish who did what. We make TLS mandatory on both inter-node and client connections.

On retention and destruction, MongoDB’s document model makes the work easier in one respect: in designs where related data is embedded in the document, a single delete covers the whole record. In designs separated by reference, deleting the related records together and with verification needs planning as careful as in a relational database.

Why a distribution migration comes up

Some of the technical measures above are not present in MySQL Community Edition or in a standard PostgreSQL installation. Encryption, audit logging and data masking capabilities are mostly provided by the open source components of the Percona distributions, or by community extensions such as pgaudit and PostgreSQL Anonymizer.

A significant part of the work is therefore the migration itself: from MySQL Community Edition to Percona Server, from standard PostgreSQL to Percona Distribution for PostgreSQL, or from MongoDB Community Edition to Percona Server for MongoDB. We carry these migrations out on production systems without data loss, in planned maintenance windows, and with a rollback scenario defined. On version migrations our MySQL 8.0 to 8.4 migration page may also be relevant.

We have no commercial relationship with the maker of any component we use. All of the components carry open source licences; what our firm provides is placing them correctly into a running system and keeping them operable afterwards.

The backup files of an encrypted database have to be encrypted too. One of the findings raised most often in audits is that backups are stored unprotected while the production database is encrypted: Database Backup and Recovery

Encryption and audit logging configurations have to be applied consistently across every node of a cluster: High Availability and Cluster Solutions

Our database support services

On the databases where we apply these technical measures, we provide the full range of our support and consulting services.

MySQL Support

Performance, clustering, backup and security under one scope, including the move to Percona Server.

PostgreSQL Support

Patroni cluster installation and management, backup with pgBackRest, query and configuration tuning.

MongoDB Support

Replica set and sharding installation, index and schema design, monitoring stack and maintenance.

Frequently asked questions

No. Compliance with KVKK is not made up of technical measures alone; the data inventory, the duty to inform, consent management, administrative measures and organisational processes are all inseparable parts of it. Our firm builds and operates the part of the technical measures that falls to the database layer. The assessment of compliance is the responsibility of the data controller and its legal counsel. Our firm is not a law office and does not provide legal advice.

The PostgreSQL core does not include TDE (Transparent Data Encryption) support. The capability is provided by the pg_tde component, and that component is not attached to an existing installation as an extension β€” it comes as part of the Percona Server for PostgreSQL distribution. So on the PostgreSQL side, encryption usually means a distribution migration project. On the MySQL side InnoDB encryption is in the core, so no comparable migration step is needed.

No. We have no commercial relationship with any software vendor. The Percona components and community extensions such as pgaudit carry open source licences; our firm installs, configures and integrates those components into the customer's running system. What we provide is the integration and the operational support that follows.

The operational cost differs for each measure. Audit logging and data masking can usually be put in place without an outage. Encryption and a distribution migration need planning; in most scenarios it is possible to proceed through the replicas and hand the load over, keeping the outage inside a maintenance window. We do not commit to a downtime figure without examining your topology first.

Yes. Most projects start with a single audit finding; the ones we meet most often are the absence of audit logging and the storage of real personal data outside production. Putting all four measures in place at once is not required.

Which finding did the audit raise?

Let's examine your current installation together, and set out how much work each technical measure needs and how the priorities should be ordered.

Get in touch