Database Endpoints let you expose a Database to 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.

​
IP Filtering

To keep your data safe, it’s high recommended to enable IP filtering on Database Endpoints. 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.

Like App Endpoints, Database Endpoints support IP Filtering to restrict connections to your Database to a set of pre-approved IP addresses.

​
Certificate Validation

Not all Database clients will validate a Database server certificate by default.

To ensure that you connect to the Database you intend to, you should ensure that your client performs 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 and the hostname.

For MySQL and PostgreSQL, you will need to retrieve a CA certificate using the aptible environment:ca_cert command in order to perform validation. After the Endpoint has been provisioned, the Database will also need to be 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.

​
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

Was this page helpful?

Database TunnelsOverview