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.
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
Warning 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.
You should create a new database user for which you grant the least privileges possible to the needed integration. For example, granting only "read" privileges to specific tables (such as those that do not contain your user's hashed passwords, for example) is often recommended if you are integrating a business intelligence reporting tool.
Please refer to the Deploy Database Documentation for information about user management capabilities for each database type.
You should also create a unique user for each external integration. Not only will this making auditing access easier, but will also allow you to rotate just the affect account's password, should be unfortunate enough to suffer a leak of a credential by a 3rd party.
Updated 5 months ago