Security Architecture
Last updated
Last updated
DBSync Cloud Replication provides a fast and easy way to replicate Source applications in your local database.
DBSync Cloud Replication is a 100% Java application.
The application can be downloaded and installed from mydbsync.com product site. The installation is available for Windows (.exe) or Unix/Linux (.zip) files.
The application is built to run its user interface on top of Tomcat.
The application does not provide any built-in User Security model. End users can implement security based on Security (http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html) or Spring Security (http://projects.spring.io/spring-security/)
All configuration for profiles are stored in local file system <<install-dir>>/dbsync-repl/WEB-INF/db directory
All passwords stored are encrypted using industry-standard encryption algorithms. The encryption seed can be changed once installed.
The following are the entities and passwords that are encrypted – Local license file (*.lic)
http Proxy Password
Salesforce Password
Database Password
All Web communications with Source applications comply with Source HTTP/S 256-bit encryption standards.
All communication with the local database is performed using JDBC protocol and supported JDBC drivers.
DBSync License check occurs every run using HTTP/S 256-bit calls to DBSync License servers. This call can be avoided by installing a local license file.
The application can run standalone or embedded along with other applications. The most common operating model is to use a Batch Interface in Solaris/Unix environment and/or Web App on Windows/Linux/Unix environment.
Where is dbsync running? On the database server at our IT center? Separate/dedicated server at our IT center? Other?
DBSync runs in your IT Center. While it is recommended that you create a virtual machine to run the application, it can co-exist with other applications. The application runs on Java in its virtual Java process space and will not interfere with other applications.
Does DBSync transfer and/or storage of SFDC credentials? If true, this is a security issue.
DBSync does not transfer client data or store any of their SFDC credentials. The only communication it has with its servers is for license checks. These checks can be avoided by installing a local license key.
DBSync configuration must prevent the transfer of data to other databases, including unrelated organs at SOURCEDC or other servers inside or outside of our centers. How is this accomplished?
The end user sets up a connection to its database. The Engine reads data from one source, maps it, and translates it into memory to push it to the target or destination. At no point, the data is written to disk or routed to another destination.
How does DBSync authenticate to SOURCEDC? Confirm SSL/HTTPS is enforced for authentication/data transfer?
DBSync uses Source applications SOAP services to authenticate and communicate with Source apps. It uses the required HTTP/s and encryption required as required by Source API's.
How is DBSync secured to prevent tampering or other unauthorized modification of its configuration?
DBSync is built on Tomcat and Spring framework. While out of the box, it does not come with user management; one can quickly implement Tomcat Realm Security or Spring Security to implement their security. It is also recommended that this server be accessible only through approved IP ranges to further protect access to the server. If you are running the application in batch mode, you do not need the Tomcat Server to be running once it's set up. This will further secure any web access to your installation.
Is there any information about the Client instance (rules, login credentials, etc.) stored elsewhere besides the Client's server running DBSync processing?
DBSync does not store any information about the client Source configuration or data in any other server than the ones installed or connected.
DBSync Audit trails - Where are they? What is logged? How are logs protected? Is any confidential data contained in the logs?
DBSync generates configuration-specific logs (Profiles) under a "log" directory and Tomcat log files. The "log" file is under the install directory but can be switched to another location through setup. The information logged is related to the progress and errors. No confidential data is written in the logs.