Data security has never been more important than it is today. Considering the amount of data collection most modern apps require, it’s imperative to keep private and proprietary data safe and secure — and with measures like HIPAA, PCI DSS and the European Union’s GDPR, it’s also the law. Keeping databases secure from existing and emerging threats is crucial.

While there are many risks associated with operating a database, security is one risk that stands out significantly above the rest. According to a recent 451 Research survey, 68% of enterprise respondents said that security is their number one concern when it comes to database risks, while 50% of respondents reported financial risks as a major concern as well. And for good reason. Database systems are nearly universally accepted as the technology for holding an organization’s systems of record. This data may consist of customer data, product data, sales data from products sold and services rendered, employee data, project and development data, and financial data, such as payables and receivables.

The 451 report notes: “Security lapses can break trust with customers, sever partnerships, cause legal issues, spur governmental compliance incidents, and generally compromise business operations, resulting in penalties and fines.”

While the database management system (DBMS) – whether proprietary or open source – comes with enterprise-grade security functionality, it is also important that database security is set up correctly and security patches are applied in a timely manner.

 451 advises:

 – Protect the data: With concerns about data breaches and loss, the first action for enterprises is to ensure that the primary data is protected. Perimeter security is necessary, of course, but more importantly, granular security is necessary at both the table level and the row level, including the ability to ensure granular access for certain kinds of commands on rows.

– Implement the highest levels of security: There can be wide variances of security capabilities among the numerous DBMSes, both proprietary and open source. The reasons for this variance often include immature databases and lack of developmental talent. Regardless, taking security shortcuts in the short run could have severe long-term consequences if not dealt with properly.

– Tooling needs to match the security: Enterprise-grade database security requires that the tooling should have easy to navigate interfaces for administering access policies, monitoring and tuning, as well as tooling for failover and for backup and recovery tasks 

– Prioritize database administration: An enterprise can have the best database security in the world with the associated tooling, but all databases need some administration, and overlooking can expose the enterprise to significant risk. Administrators ought to be well trained and qualified and able to functionally administer the database, but they should also have to be knowledgeable about the enterprise’s security policies and strategy.

And, one thing is for sure, as attacks become more sophisticated and targeted, database security will continue to evolve.

With the increased use of open source DBMSes such as Postgres, let’s look at how organizations can implement measures that will minimize their security risk.

Creating a multi-layered security architecture for your Postgres databases
Our approach to data security uses a multi-layered security architecture. Think of data security as a set of bank vaults, opening one door by key to reveal another that requires the unlocking of a safe combination. It’s not enough to simply encrypt or password-protect the information stored in your database: To keep your data truly safe, you must employ security anywhere it could potentially be accessed. 

Controlling access to every possible entry point means granting the least amount of database access possible for any job or role, blocking unnecessary access at the earliest opportunity. In a database like Postgres, access control can be applied to tables, columns, rows and views, and access can be limited through security barriers and security definers. But data security requires a holistic approach, and with a multi-layer security architecture, it’s important to limit who can access information even down to the hardware level. 

Broadly speaking, multi-layer security architecture typically contains five components:

– Secure physical access to the host (perhaps the most important)
– Limited access to your general corporate network
– Limited access to the database host
– Limited access to the database application
– Limited access to the data contained within

Incorporating layers of security across all levels means you’ll know who has access to what, adding transparency and accountability to your data security operations. We define our security approach based on the AAA model developed for network and computer security:

  •     Authentication: to verify the user is who here or she claims to be
  •     Authorization: to verify the user is allowed access
  •     Auditing: to record all database activity, including the username and the time in the log files

While not all features fit into the AAA model, we consider it a useful framework to measure data security methods.

We recommend going above and beyond typical data security offerings to implement an 11-layer security approach. 

  1. Physical access (locks on doors, cameras, etc.): Let’s start with actual security of the data center. If a data center is not physically protected, all other data security measures become significantly less valuable.
  2. Host access (Operating System controls): Securing access at the host-level by stringent user access controls like authorization and authentication mechanisms such as Active Directory, Kerberos and LDAP or hardware keys to enable multi-factor authentication. These ensure no users have unfettered access to the database host.
  3. File system encryption (through native Linux or others): Encrypting the file system protects the files on the drive if the drive is stolen or compromised in some way. Other solutions like Vormetric can also be used for this purpose.
  4. Database server network access: In the case of Postgres, the configuration file ‘hba.conf’ is used to control authentication connections to the database server. It consists of a set of records that specify a connection type, a client IP address range (if relevant for the connection type), a database name, a user name, and the authentication method to be used for connections matching these parameters.
  5. Encryption in transit and host authentication (SSL): All data — including passwords and usernames — should be encrypted on the network using SSL and certificates ensure the user communicates with the intended host machine.
  6. SQL injection attack prevention: Make sure your DBMS has this feature and use it to block corruption or co-opting of a database, including unauthorized relations, utility commands, SQL tautology, and unbounded DML.
  7. Database authentication: Users should be authenticated using passwords, LDAP, Keberos, certificates or using operating systems credentials. Database authentication should be tied with overall user management to make sure access credentials get revoked when users move to another assignment, leave the enterprise or any other reason.
  8. Database authorization and access control: Users must be granted permissions to view and work with data in the database. Privileges should only be granted in order for a user to perform a job. Shared or group login credentials should be avoided. A principle of least privilege should be applied.
  9. Data encryption (pgCrypto): If a user gets past file system encryption, they can access a database that’s been logged into. Encrypting data at the column level keeps the database information secure.
  10. Auditing: Make sure your DBMS has this feature and use its auditing capabilities so that database administrators, auditors, and operators can track and analyze database activities, like the creation, changing, or deletion of data. This makes it possible to closely monitor what those with permissions are doing. We recommend auditing based on user connections, DDL changes, data changes, and data views.
  11. Data redaction: Make sure your DBMS has this feature which can be used to shield (or mask) certain data elements from certain types of users, like Social Security numbers, for example.

Using a multi-layered security architecture for your Postgres databases makes it possible for your organization to leverage the power of open source while taking control over the destiny of your data security to minimize risk.