The most common reason for Enterprises looking to migrate from legacy Btrieve or DataFlex databases is the urgent need to address security and compliance. Regulatory frameworks, such as GDPR, HIPAA, and PCI DSS, mandate rigorous safeguards for sensitive data, encompassing both data protection during transmission and while it is stored.
Mertech’s Flex2SQL (for DataFlex users) and BTR2SQL (for Btrieve, Pervasive, and Actian users) are engineered to leverage the native security capabilities of your chosen relational database. This includes TLS/SSL encryption for data in transit, robust authentication protocols, and data-at-rest protections—all designed to meet modern compliance standards. In this blog post, you’ll discover how Mertech’s solutions utilize vendor-supported encryption, what security options are available across supported databases, and best practices to ensure your migration is secure, compliant, and seamless.
Native Database Libraries: Mertech’s Security Advantage
Unlike other migration tools that rely on custom connectivity layers, Mertech depends on native database client libraries. This approach extends vendor-supplied security protocols directly to your applications.
Advantages of this approach include:
- Inherited Security Features: Always benefit from the latest vendor updates, patches, and encryption protocols.
- Reduced Vulnerabilities: Minimize risks associated with third-party encryption layers.
- Simplified Security Management: Continue using your established database security policies, including certificate management and authentication rules.
In short, Mertech acts as a secure bridge, ensuring that your applications communicate with the database exactly as the vendor intended.
The table below illustrates how the relational database management systems supported by Mertech products handle security and provides guidance on configuring them in each of the supported DBMS.
Supported DBMS
|
DBMS Specific Settings
|
Action Required
|
|
Microsoft SQL Server
|
SQL Server uses Transport Layer Security (TLS) for encrypted connections. When a client requests encryption, SQL Server and the client perform a TLS handshake; the server sends its certificate, which the client must trust and verify. Microsoft recommends migrating to TLS 1.2 because older SSL protocols are no longer considered secure.
|
For both BTR2SQL and Flex2SQL, encryption is turned on by default. To have the highest level of security, install a signed certificate on Microsoft SQL Server.
|
|
PostgreSQL
|
PostgreSQL has native SSL/TLS support. Setting ssl=on in PostgreSQL.conf enables TLS; the server will then listen for encrypted and unencrypted connections and negotiate with clients. On the client side, the libpq library uses an sslmode parameter: require enforces encryption, while verify-ca or verify-full also validates the server certificate.
|
To ensure all traffic is encrypted, set ssl to on and configure certificates. Avoid NULL ciphers; PostgreSQL allows administrators to specify acceptable ciphers via ssl_ciphers.
|
|
Oracle
|
Oracle Net Services provides native network encryption using algorithms such as AES and DES. Administrators configure SQLNET.ENCRYPTION_SERVER and SQLNET.ENCRYPTION_CLIENT in sqlnet.ora; values like REQUIRED force encryption. The `SQLNET.ENCRYPTION_TYPES_[SERVER
|
CLIENT] parameters define allowed algorithms (e.g.A ES256), and separate parameters control data‑integrity algorithms (SHA‑2, MD5).
|
|
MySQL (and MariaDB)
|
The client and server communicate over TLS/SSL. MySQL’s native libraries support --ssl to enable TLS. Setting require_secure_transport=ON forces clients to use encrypted connections; the server certificate and key files are specified by ssl_ca, ssl_cert, and ssl_key, respectively. Administrators can restrict protocols and ciphers through tls_version and tls_ciphersuites variables.
|
To secure connections, install server certificates and enable TLS. The MariaDB equivalent uses the same options; administrators add ssl-ca, ssl-cert, and ssl-key to my.cnf and can require users to REQUIRE SSL to enforce encryption. Enabling TLS typically incurs only 2–5 % CPU overhead.
|
Leveraging Database Encryption Capabilities of your DBMS
Flex2SQL and BTR2SQL do not encrypt data stored in the database; they rely on features of the target DBMS. For example, Oracle offers Transparent Data Encryption (TDE), SQL Server has ALTER DATABASE … SET ENCRYPTION ON, and MySQL/MariaDB provides tablespace encryption. When migrating from Btrieve or DataFlex to SQL, these features become available; enabling them is a database‑administration task.
Column and Row-level Security in DBMS
Mertech solutions are fully compatible with advanced database security features, including row-level permissions, column-level encryption, and Transparent Data Encryption (TDE). These capabilities are crucial for ensuring compliance with GDPR and other data protection regulations, enabling IT teams to enforce fine-grained access controls and robust encryption standards directly within their preferred relational database platforms.
Encrypting Password in .INI/.INT Files
To further enhance credential security during migration, Mertech products offer multiple methods for encrypting database user passwords stored in .INI or .INT files. Because these configuration files use ASCII format, encryption is essential to prevent unauthorized access to plaintext credentials.
Mertech provides the MdsEncryptPassword utility, enabling developers to easily encrypt database user passwords before saving them in .INT or .INI files for use by our database drivers. Both Flex2SQL and BTR2SQL drivers are designed to automatically decrypt and utilize these passwords securely at runtime.
BTR2SQL supports advanced encryption options, including strong AES encryption alongside legacy encryption for backward compatibility. Additionally, BTR2SQL integrates with Windows Credential Manager, allowing passwords to be encrypted and managed at the operating system level. Detailed instructions are available in the BTR2SQL online documentation.
Flex2SQL also fully supports password encryption, ensuring secure credential storage aligned with modern security standards. For implementation details and best practices, please refer to the Flex2SQL documentation.
Best Practices for Keeping Your Data Secure
To maximize security after migrating from DataFlex and Btrieve / Actian, make sure that you:
- Keep software updated – Always run the latest versions of Flex2SQL/BTR2SQL and vendor libraries.
- Enable TLS at the database server – Client settings alone are insufficient without server-side TLS.
- Use strong certificates and ciphers – Avoid NULL ciphers and outdated SSL protocols.
- Encrypt stored credentials – Never keep plaintext passwords in configuration files.
- Test for overhead – TLS adds only a minimal performance cost (2–5%).
Conclusion
Flex2SQL and BTR2SQL are engineered to leverage the security architecture of your chosen relational database, rather than introducing separate encryption or transport protocols. These solutions utilize native client APIs and vendor-supplied libraries, which deliver robust TLS/SSL encryption and advanced protection mechanisms. Administrators are responsible for configuring the underlying database to mandate encrypted connections and enforce strong cipher suites, ensuring that standards-compliant protocols secure data in transit.
Migrating to a modern relational database further unlocks powerful data-at-rest encryption options and granular access controls, supporting regulatory compliance and security best practices.
Flex2SQL and BTR2SQL seamlessly work with the security options provided by the DBMS vendor. By following recommended configurations, organizations can maintain compliance with evolving data protection standards and safeguard sensitive information.
Riaz Merchant: Oct 28, 2024 6:12:41 AM
