Big picture, here’s where your data goes:

1. ConstantCare.exe connects to your SQL Server, fetches query results, and creates a zip file.
2. ConstantCare.exe sends that zip file to our servers.
3. We extract, transform, and load those files into the database.
4. We run queries, build a custom email for you, and email it to you.

Let’s look at the security and privacy of each of those steps in more detail.

1. ConstantCare.exe runs queries and creates a zip file.

Like all SQL Server applications, the initial login packets are secured, but then the rest of the queries and results go across the network without encryption.

It turns out that encrypting your connections to SQL Server is surprisingly hard work. If you want to do that, here are a few starting point resources:

• Microsoft KB 3135244 for TLS 1.2 support for SQL Server
• Aaron Bertrand’s “SQL Server support for TLS 1.2 – Read This First!”

Once we’re connected, to give you health & performance analysis, we need to collect a lot of data about your SQL Server, databases, indexes, and queries. To see the exact queries we run, go into ConstantCare\Resources\Queries where you can see every query that we run.

We’re database administrators too, so if we were you, here’s the parts that we’d be most concerned about:

• Database names – if you’re a hosting company or you have client-specific information in the database name, that would be a problem. You shouldn’t use SQL ConstantCare® – or indeed, anyone’s SaaS monitoring product, because they’re all going to collect database names. You should stick with on-premises monitoring solutions.
• Table, index, and stored proc names – sometimes these contain client-specific names too. Maybe you’ve got a table called dbo.AcmeWillDeclareBankruptcyIn2018, and that might be bad to share.
• Certificate names – which sounds intimidating, but it’s just to make sure that you’re backing up any certificates that you’re using for Transparent Data Encryption, Always Encrypted, that sort of thing.

Here’s the stuff we don’t collect, and don’t even wanna get close to:

• Passwords – we don’t do a security analysis on your server. Security is indeed really important, but it’s just not the focus of our analysis.
• Your users’ queries and their results – this is a particularly tricky area because your users could say “SELECT * FROM dbo.Patients WHERE SocialSecurityNumber = 123456789” – which means us seeing that query could potentially be very bad. For now, we’re just avoiding these pitfalls altogether by avoiding queries and execution plans. In the future, we’ll be gathering these, but it’ll be a strictly optional feature, and you’ll have to opt in manually.

If you suspect that we’re collecting anything like that, alert us immediately with any evidence you’ve got. If it turns out we’re collecting any of this, we’ll give you a reward right away to thank you for alerting us, and we’ll get to work ripping that part of the code out.

2. ConstantCare.exe sends that zip file to us.

It connects to our web services over HTTPS. Our goal there is to make sure that if someone’s sniffing your network connection, they won’t eavesdrop on the query results you send to us. (See, we’re one step ahead of SQL Server.)

The zip file lands in the United States on encrypted storage in Amazon Web Services – specifically server-side encryption with managed keys. (We do not have plans for alternate data centers at this time.)

3. We extract, transform, and load into the database.

We unzip the zip file onto encrypted storage, then load it into a database server for analysis.

(I bet you think it’s Microsoft SQL Server, right? That would sound logical since we’re SQL Server folks, but jeez, I tell you what, it turns out that SQL Server is really, really expensive. But I digress.)

The database’s files are encrypted at rest, just like your zip files and flat files. Everyone’s data lives together inside the same database – clients are not segregated into their own databases.

4. We run queries, build an email, and send it to you.

One bummer here: email is not encrypted. If someone sniffs the Internet traffic while our email servers are talking to each other, they’ll see the contents of our emails. (For more technical details, see the Stack question “Why is end to end encryption still not default?”)

This lack of email encryption influences what data we collect. After all, if we find a problem that we want to email you about, but the email would include data you wouldn’t be comfortable transmitting in public over the Internet, then we can’t really send that in email.

Whew.

We covered a lot of stuff there in refreshingly plain English because we want you to be comfortable. If you have questions, feel free to contact us. If you’re not comfortable with what we’re gathering, we don’t want you to use the product – no sense in you using something you’re not completely comfortable with.