SQL Firewall
Secure your data from SQL Injection and threats
In an increasingly connected world, the surface area for possible cyber threats is multiplying daily, creating a critical need for more sophisticated data security procedures. Not only is personally identifiable information at risk, but stricter regulations are now requiring more stringent data security measures for compliance.
Security threats could be internal or external. Internal threats can be something as simple as human error, or through an intentional attack by someone with access to the system intending to sabotage the organization from within. Breach by external threats often comes in the form of a malicious intrusion by an individual or group seeking to cause an organization harm, or hackers taking advantage of system vulnerabilities.
Why SQL Firewall?
SQL Firewall is an easy-to-use extension to PostgreSQL, developed by 2ndQuadrant and available to 24/7 Support customers, for statement-level whitelisting for individual users. SQL Firewall is the best choice for database level security implementation because it:
- works as an extension to PostgreSQL 9.4 & above. Working as an extension means that it is quick and easy to set up.
- provides additional security through protection at the database level.
- is completely independent of the application layer. So existing applications will not require a change in order to use it, nor will you need to design new applications to cater to SQL Firewall’s functionality.
- works with all applications as an extension to PostgreSQL, regardless of platform and language of implementation.
What does it do?
SQL Firewall works at the database layer providing the following functions:
- Firewall – Block unwanted SQL statements from executing against your database.
- Controlled access – Whitelist statements at an individual user level.
- Automated training – SQL Firewall can be trained to whitelist SQL statements simply by running your application’s test suite.
- Import/Export Whitelists – Import or export whitelists to your PostgreSQL database. This allows you to use the same whitelist across multiple servers. It also allows you to train SQL Firewall in a controlled environment and then export the resulting whitelist to your production server for the launch of a new/updated application.
- Logging & Alerts – SQL Firewall logs each blocked query, allowing you to analyze and alert on possible threats. It also allows you to retrain your whitelist if needed.
Unsure if SQL Firewall will benefit you?
A Database Security Audit from 2ndQuadrant can identify breach points in your database. Find out more.
Security Knowledge Base
Whitepaper
Security Best Practices for PostgreSQL
Learn how to harden your PostgreSQL database cluster by developing a deep understanding of security features available and a checklist of industry best practices.
Migration to PostgreSQL [Webinar]
/1 Comment/in Liaqat's PlanetPostgreSQL, Webinars /by Liaqat AndrabiAmong the many reasons to Migrate to PostgreSQL, dedicated support and seamless transition are key drivers for a business considering migration. Being open-source software, PostgreSQL provides a highly reliable, stable, scalable, and secure database migration, keeping in mind the unique needs of every business. Migration to PostgreSQL, however, can still be an extensive process as […]
Security and Compliance with PostgreSQL [Webinar]
/0 Comments/in Liaqat's PlanetPostgreSQL, Webinars /by LiaqatFor businesses handling personal data, the security of their database is a serious matter. Faced with an increasing number of attacks, organizations must improve their security and compliance policies, enhance their database infrastructure, and ensure all proper security protocols are in place. As part of the ongoing PostgreSQL Webinar Series, 2ndQuadrant hosted a webinar on […]
A tale of password authentication methods in PostgreSQL
/0 Comments/in Eisentraut's PlanetPostgreSQL, PostgreSQL /by Peter EisentrautLet’s say you want to implement a password authentication method in a client/server protocol. How would you do that and what would be the possible problems? The following is the story of how this was done in PostgreSQL. password In the beginning, PostgreSQL only had the method that is now known as "password" in pg_hba.conf. […]