GreenSQL has introduced an enterprise edition of its database activity monitoring (DAM)/database firewall product, as it looks to compete beyond its initial SMB/SME target market. The new release features data masking and high availability, in addition to other features available in the GreenSQL Pro product, including reporting, auditing, user rights management and support for multiple database instances.
DAM/DB firewall products, which are typically deployed on the network or, in some cases, on the database server itself, monitor and analyze traffic to flag and, depending on policy, block anomalous queries that may indicate an attack or unauthorized use. This might include, for example, an administrator accessing credit card numbers or a sales rep making queries on an HR database. These products will also watch for familiar attacks, such as SQL injection.
Companies are showing a great deal of interest in deploying DAM products or expanding their use, says Adrian Lane, analyst and CTO for Securosis.
"It’s definitely an untapped market," he says. "A lot of companies who originally had deployed on just an internal financial database or some production servers for activity monitoring are pushing across most of the organization."
As software, GreenSQL can be deployed on premise or in cloud infrastructures. It sits inline in front of the database as a reverse proxy and therefore is able to perform caching to improve performance and limit access to the database itself by policy.
"High-performance caching is a differentiator," says Lane. "They are able to do blocking and return results very, very fast." GreenSQL’s aggressive pricing should also help in the midmarket and in making inroads into the enterprise.
In addition to performance advantages, the reverse proxy allows GreenSQL companies to restrict access to sensitive information on the database itself to authorized users. Routine queries to other data can be served up by the cache. The cache also helps with data masking. While the
initial masking is typically performed by changing the query in some way initially, the masked data can sit on the cache for subsequent queries, relieving the database of the repeated burden.