Database Endpoints let you expose a Database to the public internet. They can be created via the Dashboard. Below are some security controls and best-practices you should consider implementing in order to protect your data if it must traverse the public internet.
The underlying AWS hardware that backs Database Endpoints has an idle connection timeout of 60 minutes. If clients need the connection to remain open longer they can work around this by periodically sending data over the connection (i.e. a "heartbeat") in order to keep it active.
It's optional, but enabling IP filtering on Database Endpoints is strongly recommended to keep your data safe. If you do not enable filtering, your database will be left open to the entire public internet, and it may be subject to potentially malicious traffic.
Just like App Endpoints, Database Endpoints support IP Filtering to restrict connections to your database to a set of pre-approved IP addresses.
IP Filtering can be configured via the Dashboard when you create or edit an Endpoint.
Not all database clients will validate a database server certificate by default!
In order to assure that you're connecting to the Database you intend to, you should ensure that your client is performing full verification of the server certificate. Doing so will prevent Man-in-the-middle attacks of various types, such as address hijacking or DNS poisoning. You should consult the documentation for your client library to understand how to ensure it is properly configured to validate the certificate chain as well as the host name.
For MySQL and PostgreSQL, you will need to retrieve a CA certificate the using the
aptible environment:ca_cert command in order to perform validation. After the Endpoint has been provisioned, the Database will also need restarted in order to update the Database's certificate to include the Endpoint's hostname. See the Database Encryption in Transit page for more details.
If the remote service is not able to validate your database certificate, please contact support for assistance.
After provisioning a new Database Endpoint, restarting the Database is required to update it's certificate to include the Endpoint's hostname
Least Privileged Access
The provided Database Credential has the full set of privileges needed to administer your database, and we recommend that you do not provide this user/password to any external services.
Create database users with the least privileges needed to use for integrations. For example, granting only "read" privileges to specific tables, such as those that do not contain your user's hashed passwords, is recommended when integrating a business intelligence reporting tool.
Please refer to database-specific documentation for guidance on user and permission management.
Create a unique user for each external integration. Not only will this making auditing access easier, it will also allow you to rotate just the affected user's password in the unfortunate event of credentials being leaked by a third party.
Updated about 2 months ago