Security is the first question I get when speaking with developers around InterBase. Ensuring that you can keep your users data secure and compliant is a necessity in the Cybersecurity world. Whether you have sensitive health data or even just names and phone numbers, you need to be able to reassure consumers that their data is safe and secure from hackers and data breaches.

How InterBase works to protect your users

InterBase uses implements several methods for protecting your users data against unintentional and intentional risks.

InterBase Security Database

Security for InterBase is built on a central security database file for each server. This database, called admin.ib (by default), contains a record for each legitimate user who has permission to connect to the databases and services on that host server. Records contain user login and encrypted password and require logging on to the server.

SYSDBA and SYSDSO

Every server has a SYSDBA user. This user is a special account user that bypasses all the normal SQL security and performs several tasks including database backups and shutdowns. As the only active and authorized user when initially installed, the SYSDBA authorizes all other users on the server and can update the security database to add, modify or delete users.

Note: The SYSDBA default password is masterkey. You should change this as soon as possible to prevent unauthorized users.

InterBase implements a SYSDSO or System Data Security Officer separate from the SYSDBA user to implement specific encryption tasks. SYSDSO is a reserved username, similar to SYSDBA and controls a few significant steps in the process for encrypting databases:

  • Creates the System Encryption Password (SEP).
  • Creates the encryption keys.
  • Grants the database owner access to the encryption keys, which s/he then uses to encrypt the database and/or its columns.

However, the SYSDSO cannot encrypt databases or columns, nor can s/he grant or revoke access to encrypted data. Only a database owner and/or an individual table owner can actually encrypt a database or columns in a database; the SYSDSO simply creates the encryption keys that are needed to perform database encryption. This requires that multiple “users” set up and implement encryption, rather than just one which adds an additional layer of database security.

Role Based user security

Roles implement the idea of group level security. A role defines the set of SQL Privileges on any of the tables in a database and acts as a template for users, what they can and can’t do. Roles, after being created are granted privileges to database objects and upon connection to the database, users assume the rights of the role they are assigned to. InterBase Roles also add much needed flexibility to allow for altering user privileges without the extra overhead of managing each users change, via a grant or revoke statement. Roles allow users to change the privileges assigned to them by assuming different roles when connecting to the database or server.

Database and Column level Encryption

For database level encryption, InterBase encrypts all the database pages that have user information. You then encrypt the entire database using an encryption key. Typically, encrypting all of the user pages of a database takes a bit more overhead than selectively encrypting individual columns.

With column level encryption, you have far more flexibility and can be specific. When you encrypt a column, your specifying the table that contains the column, then you can choose to either encrypt all the columns in that table, or only the columns that you want. Users who need to access data in encrypted columns can be given decrypt privileges for that column.

Embedded User Authentication

Embedded User Authentication or EUA stores the database username and password directly in the database. This is a great resource for embedded database applications where you may not have access to the central server for login due to connectivity gaps.

InterBase ToGo is a flat file version of InterBase that allows you to embed the database directly into the application and know that your user’s data is protected because ToGo only allows access with the application it is embedded with. You can also encrypt this data with 256 bit encryption to further protect your data at rest.

Encryption of backup files

We go through all the trouble of adding security to the database when files are in use, but what about when backed up? Because backup files are often sent off-site for disaster recovery or long-term archival purposes, it is important that encrypted databases have their backup files encrypted as well. Encrypting your database backup files just means that your taking the security protocols one step further and InterBase has a built-in command (gbak) utility that uses a -encrypt and -decrypt switch to secure your backups.

OTW / SSL Network encryption

Data that is sent to an InterBase remote client from a database server is unencrypted during the transmission process, even when the data was encrypted prior to transmission. This creates an opportunity for security breaches. To protect against this, InterBase has support for Over-the-Wire (OTW) encryption to encrypt data during the transmission process.

Be sure to check out the links for more in depth knowledge on working with InterBase security features.

Resources

Docwiki:

     Encrypting Your Data - InterBase: http://docwiki.embarcadero.com/InterBase/2017/en/Encrypting_Your_Data

     Setup OTW/SSL and InterBase: http://docwiki.embarcadero.com/InterBase/2017/en/Setup_OTW/SSL_and_InterBase

YouTube Videos:

     User Security in InterBase: https://www.youtube.com/watch?v=R-Xyf8ngjKg

     InterBase Database Encryption: https://www.youtube.com/watch?v=u4T0qS9apqs

     Securing Data with InterBase Encryption: https://youtu.be/vhFKgF7B6Qc

     Build a Secure Multi-device application using Embedded InterBase ToGo: https://www.youtube.com/watch?v=2yOZFw_dLP4

Product Portal:

     https://www.embarcadero.com/products/interbase

     https://www.embarcadero.com/interbase-resources

Anonymous