Sanity check: developers storing ad-hoc production backups on their workstations

  • Our team of eight developers stores ad-hoc production database backups on their workstations. Some in default-ACL folders. Some unencrypted. I see this as extremely high risk, but our manager sees this as an inconvenient necessity. I can't stop them from taking these backups, but I can encourage policy to reduce the risk these ad-hoc backups pose.

    I'm considering requesting that if they are to take these backups, they need to use encryption and store these only on a designated per-server network share with tightened ACL permissions. I would then be able to configure a scheduled task to check the backups on the share were encrypted.

    I could use a sanity check on whether this really is a valid improvement to the security, and warrants the inconvenience of requiring the developers to stick to mandated locations to store these ad-hoc backups.

    Edit: reduced the length of this post.

  • I guess it depends where you are and the privacy laws, whether there is recognisable customer data etc. If you are in certain states or within the EU, quote the relevant laws as to the reason this should not be done. So, for example, here in the EU, GDPR laws mean that outside of production, any data that could identify a customer needs to be handled with extreme care and even in production, should be encrypted and those who have access to this data need to be audited, failure to comply with this can lead to massive fines for the company.

  • Yeah, that's absolutely a violation of the GDPR, if you have EU citizens data in that. It's also a violation of HIPAA if there is private health information in it. If you have credit card information, it's a PCI violation as well. In 2020 it will be a violation of the California Privacy and Protection law (2020 is when enforcement starts) if you have a California citizen's data in it. There are more GDPR-style laws coming out around the world that will absolutely impact your organization with this process.

    In short, they are absolutely doing it wrong and you need to change the process. Bring this up with management. Don't fight the developers. They're doing what management lets them. This is a fundamental security flaw. Yeah, it's going to inconvenience the developers by not having exact copies of production to test against, but I wouldn't take any chance, especially not in this day & age. One developer loses their laptop and all the data owned by the company is exposed? That's not good.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • scareddba - Monday, January 28, 2019 12:31 AM

    Our team of eight developers stores ad-hoc production database backups on their workstations. Some in default-ACL folders. Some unencrypted. I see this as extremely high risk, but our manager sees this as an inconvenient necessity. I can't stop them from taking these backups, but I can encourage policy to reduce the risk these ad-hoc backups pose.

    I'm considering requesting that if they are to take these backups, they need to use encryption and store these only on a designated per-server network share with tightened ACL permissions. I would then be able to configure a scheduled task to check the backups on the share were encrypted.

    I could use a sanity check on whether this really is a valid improvement to the security, and warrants the inconvenience of requiring the developers to stick to mandated locations to store these ad-hoc backups.

    Edit: reduced the length of this post.

    What sort of data is on the database? If it's public data and not affected by GDPR then there might be nothing wrong with storing copies on local drives. You have to ask yourself if someone put the database somewhere where anyone in the world could download a copy would that be ok? If the answer is no they should not be allowed to have a copy on their laptops.

  • I'd send an email with the observation and recommendation to my manager and keep a copy. Then let them decide what to do.

    Ensure you've  met your obligations, but it's up to the manager to ensure the company is compliant. There's no fundamental reason this affects the company if the data stays secure, but an audit or breach will have consequences.

  • scareddba - Monday, January 28, 2019 12:31 AM

    Our team of eight developers stores ad-hoc production database backups on their workstations. Some in default-ACL folders. Some unencrypted. I see this as extremely high risk, but our manager sees this as an inconvenient necessity. I can't stop them from taking these backups, but I can encourage policy to reduce the risk these ad-hoc backups pose.

    I'm considering requesting that if they are to take these backups, they need to use encryption and store these only on a designated per-server network share with tightened ACL permissions. I would then be able to configure a scheduled task to check the backups on the share were encrypted.

    I could use a sanity check on whether this really is a valid improvement to the security, and warrants the inconvenience of requiring the developers to stick to mandated locations to store these ad-hoc backups.

    Edit: reduced the length of this post.

    Having been a Developer in the past, I understand their plight.  However, what are the safeguards in place that would prevent the "angry employee" from just grabbing a copy of all the production databases and selling it to the highest bidder?  If management is so sure of things, ask them to accurately enter their own PII in the database(s) as a sign of good faith that "everything is just fine".

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I agree with Steve's and Jeff's advice, but if this is HIPAA applicable PHI data, I'd stop providing that information right now. If you knowingly supply PHI data to unauthorized people, you can be held criminally liable (as in prison).

    I love my job. I love my co-workers and my boss. However, I'm not going to prison for them.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply