Security has been taken into account starting with the design
stage: server-side configuration lets admins specify strong
authentication and security rules in order to ensure SQL database
Three-Tier Architecture to Protect your SQL Databases
Your SQL database will never be exposed directly to the Internet,
because AceQL HTTP uses a three-tier architecture. All SQL client calls
are analyzed and filtered by a configurable Servlet, the AceQL HTTP
Manager. Only this Servlet can access the SQL database directly. Access
to the database is granted only if the client call matches the
rules defined in the Servlet.
Strong Client Authentication for Access to the SQL databases
Each client must be logged in with a username and password to
gain access to an AceQL Session. The username and password are
verified by the AceQL HTTP Manager, using your injected Java code
to authenticate the username-password pair. Once the client is
logged in, an authentication session ID is built using strong
cryptography. The authentication session ID is then reused at each
client call to verify that the request is legitimate. A default
authentication session IS builder algorithm is provided, but you
may define and code your own implementation.
Security Manager - Configuring SQL Security Rules in Java
You can configure your security rules in Java to reinforce
the protection of your databases. These rules:
- Allow filtering IP, SQL request types, tables, Prepared
Statement parameters and client usernames.
- Enable fine granularity analysis of SQL calls before
allowing effective server side execution.
- Allow running code if a SQL call is discarded (example:
allow immediately discarding and revoking a client login or IP
address when an unauthorized SQL call is detected.)
SQL Data Transport Security - SSL/TLS Support -
All HTTP communications between the client side and the
server can be encrypted with SSL/TLS.
Java Client Side Obfuscation
AceQL HTTP supports obfuscation of the Java code distributed
on the client side.