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.
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.
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 Postgres 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 the data 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, a 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.
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.
This blog first appeared on ITOpsTimes, October 22nd, 2019. For the full article please go to this link.
Bevor er sich EnterpriseDB anschloss, arbeitete Linster knapp vier Jahre bei Polycom, dem führenden Hersteller von Videokommunikationsausrüstung. Hauptaufgabengebiete waren Services Supply Chain, Business Intelligence, Kundendatenverwaltung und Cloud-Lösungen. Davor leitete er ein Beratungsunternehmen mit den Schwerpunkten Supply Chain und Systemintegration mit Kunden in den USA, Kanada, Frankreich, Deutschland und der Schweiz. Bei dieser Tätigkeit konnte er auf seine Fachkenntnisse zurückgreifen, die er sich während seiner sechsjährigen Tätigkeit bei der Avicon Group angeeignet hatte. Dort war er zunächst Technischer Direktor und dann Vice President of Operations. Dies verhalf ihm zu einem breiten Hintergrundwissen über Management, Unternehmensberatung, Systemintegration, Datenverwaltung und Business Intelligence. Linster hat einen Dr. rer. nat. der Universität Kaiserslautern in Deutschland in Informatik.