What info is uploaded and kept on your server(s)?
For Drop Guard to operate, two components are required:
- The connection to a client website via the Drop Guard module (optional)
- The connection to a user’s Git repository
In the first case, we do not store any information apart from a list of enabled modules and their versions. We keep no historical data whatsoever, so once you disable a module or delete a project - all the data is wiped immediately.
Speaking of Git connection - we do require read/write access to the repository to process updates. Before performing a module update, a local cache gets created in a temporary Docker container, which purpose is to handle this specific update only (run composer update commands, apply patches etc.). After the operation is finished (either with failure or success result), the container gets destroyed immediately.
If you don’t want to grant Drop Guard access to your full codebase, you can create a separate repository with just the composer.lock and composer.json files, which is enough for Drop Guard to work in Composer mode.
You can also grant Drop Guard access to a separate codebase containing only contributed modules and core.
Is the information encrypted in transit from my site, using the Drop Guard module, to your server(s) and if so, what methods are used?
For encryption of the data coming from the client module, we use openssl extension from PHP and aes128 cipher method. Then we use the public key generated by Drop Guard server (you use it to connect to a client website) to generate the base64 encoded string, which is transferred via a secured protocol (in case of the client website uses https). To see how it works, you can inspect the dropguard.module file.
What happens to my data if I delete my account?
If you delete the account your data is fully wiped from the database. In about a week or two the last remaining backup with the information about your account will be deleted as well from our servers.
Who in your company has access to the data? Is there role separation between developers and sysadmins?
Only two persons have full access and knowledge on how to access the data - the Lead Developer and the team lead. The rest of the team, including management, marketing, other developers in the company do not have access to any of the applications behind Drop Guard - the front end (interface visible to a user), and the backend (separate servers performing updates).
The logs and debugging data which may be visible for other developers are impersonated - they contain a project ID, type or operation and the status. If the problem requires direct communication with a user and checking his project status using a “master” Drop Guard account, it can be done only by a team lead, who is responsible for all further communications. A regular developer is not given permission to see the user project in full or “masquerade” as a regular user.
Regarding the role separation - the same people who work on the code work also on infrastructure.
Are on-premises options available if a client cannot use a cloud service?
We can offer our client on-premise solutions. Please contact us for your individual case.
Do you have monitoring in place to prevent and detect intrusion that would allow using the connection back to my Drupal servers as a vector?
We monitor the system 24/7 both manually and using automated tools, continuously analyzing suspicious traffic and connected clients behavior. In case something unusual is detected we disconnect a client from a system immediately, ban the IP and do a post-mortem review. We also keep our internal systems (open source libraries, modules, components used) always up to date and constantly monitor them for all possible security flaws.