Join 3,523 readers in helping fund MetaFilter (Hide)


How do I secure some shared files?
February 25, 2014 8:00 AM   Subscribe

How do I secure some files that need to be shared and be editable with several employees and also be able to immediately remove access to any version of those files from a particular person?

I work for a small startup - we have to use some shared credentials to access customer VPNs.

Right now, they're in an SVN repository that means any employee can access that repository, get the information they need quickly and change things as necessary.

The problem has arisen because somebody is leaving the company under a cloud - they have all these files on their computers, including their home ones.

Whilst we can't do much about it this time (we're going to have a busy day getting clients to change passwords for us), it'd be nice to do this better in future!!

So what we need is a whole bunch of files (no, we can't just do this in a spreadsheet) to be only available to current employees, be editable, and to have no local cache of these files on an individual's computer (this rules out Dropbox and the like).

Right now I'm thinking of holding the files on some sort of NFS share on a unix box that's only accessible whilst in the office / on office VPN - but would welcome any alternative suggestions (we have linux boxes, databases, private webservers, etc. that can easily be secured) as this feels like a bit of kludgy way of doing it.
posted by BigCalm to Computers & Internet (18 answers total)
 
to have no local cache of these files on an individual's computer

If your issue is the security of the information, nothing will stop people from doing a screen shot or even copy paste (depending on the type of information/document).
posted by PuppetMcSockerson at 8:08 AM on February 25


Surely someone could get on the VPN to access the shared drive and then copy the files to their local computer? And similar points could be made about most other technological fixes to this problem?

Maybe you should rely on screening processes, contracts, separation agreements, etc., to protect the files rather than trying to lock everything down.
posted by jsturgill at 8:08 AM on February 25 [1 favorite]


The only sane way I've seen this kind of thing handled is to "simply" have an agreed-upon mechanism with all customers to quickly revoke/change access when necessary, combined with strict rules about NEVER doing client work on home computers. It doesn't magically solve the problem, but it minimizes the risk. As PuppetMcSockerson & jsturgdill point out, there's no realistic way to give people access to something but also not let them have access to it if you can't revoke their credentials at will.
posted by Tomorrowful at 8:13 AM on February 25


Unless I'm misunderstanding the question, this is exactly what Google Docs does - for any given document, you can make it either viewable or editable by any given person, and you can change or revoke that access at any time.
posted by jbickers at 8:18 AM on February 25 [1 favorite]


As others have already pointed out, there's no way to solve this problem by simply restricting who can get access to the credentials because at the end of the day someone's still reading/copying/using those credentials to gain access to a customer's VPN.

In theory, what you need is an additional layer of abstraction whereby some sort of agent holds the credentials and establishes connections to customers' VPNs only for those employees who are currently authorized so that they never have direct access to the list of usernames/passwords. Depending on the technology being used, perhaps you could set up some sort of local proxy or relay to handle this.
posted by RonButNotStupid at 8:25 AM on February 25 [1 favorite]


If they can edit it, they can save it or copy it.

The only way to secure information like you would like is by invasive policy, and that doesn't even work (see Mr. Snowden).
posted by bensherman at 8:26 AM on February 25


This is why companies use non-disclosure agreements.
posted by valkyryn at 8:26 AM on February 25


Yes, I realise that copy/paste is always the vulnerability here (as well as of course, most VPN clients simply remember the password, so the clients the employee had to deal with directly would need changing regardless). In this case somebody is leaving under a cloud, so it's simply trying to cater for that in future.

GoogleDocs / Drive has local cache so that's not going to work.
Password protected google doc also doesn't work because we have to use additional files (eg putty ppk files). These can probably be downloaded ok because they're either vpn instructions or useless without the main information)

Right now, I'm thinking of setting up a local wiki that's only accessible whilst on VPN / in the office. Copy / Paste is likely to be only ever done when you're entering credentials; it's easy to edit (and relatively easy to convert from what we have now - text documents and markdown pad-style documents), and to lock somebody out we simply change their VPN password which we'd be doing anyway.
posted by BigCalm at 8:33 AM on February 25


If you figure out a way to implement this please tell the music, movie, and publishing industries. They have been trying to implement secure DRM for many years and yet people still manage to find ways to make copies of their IP.

Seriously, what you're asking for is DRM. There may be products that allow you to apply a DRM system in an enterprise setting. Whether it is practical to implement for your company is a separate question. You may be better off starting with UI/UX engineering, i.e. make it most convenient to leave the files on the server. This won't prevent malice aforethought, but it will make it less likely that when someone leaves unexpectedly the carry the corporate jewels away with them.
posted by alms at 8:39 AM on February 25 [2 favorites]


There is no possible way to prevent a document from being locally cached on a computer. To be able to edit it, it is loaded into memory of the computer being used to edit it (albeit temporarily.) Everything has local cache, in a way. The DRM industry would be delighted if there was a possible way of doing this (there's also math research showing it's theoretically impossible to do this.)

Your only options are basically making it hard for non-technically competent people to make a copy, or restricting the computers that access it to business-owned machines.

Effective risk-mitigation I've seen in the past include remote desktop-type access to a machine physically located in your business, and all devices with remote access having remote wipe capability administered by the business. It was still absolutely possible to bypass, if someone wanted to.
posted by Ashlyth at 8:42 AM on February 25


For example.

More examples and discussion.
posted by alms at 8:42 AM on February 25


Right now, I'm thinking of setting up a local wiki that's only accessible whilst on VPN / in the office. Copy / Paste is likely to be only ever done when you're entering credentials; it's easy to edit (and relatively easy to convert from what we have now - text documents and markdown pad-style documents), and to lock somebody out we simply change their VPN password which we'd be doing anyway.

Except you still have to revoke all the credentials, because when someone leaves, you still have absolutely no way of knowing if they copy-pasted the credentials into a text file on their own computer. You still have the problem of ex-employees potentially having access to your customers' systems with no way of even tracking it.
posted by Tomorrowful at 8:49 AM on February 25


> Except you still have to revoke all the credentials, because when someone leaves, you still have absolutely no way of knowing if they copy-pasted the credentials into a text file on their own computer. You still have the problem of ex-employees potentially having access to your customers' systems with no way of even tracking it.

It's actually worse than that, because VPN credentials tend to be cached by the client computer. Each employee looks after various different clients and resetting the ones that they were looking after is going to be necessary regardless.

I think alms has it - what I really need is a DRM system but that really won't work for the size of company that we are (and probably won't work regardless); Contract terms etc are really not helpful if we have a situation with a disgruntled ex-employee who wants to create a bit of havoc; So the goal really is user interface - make it easy for people to obtain information, change stuff but don't have local copies. Wiki is the best we've come up with for now. I'm also looking at KeePass to see if I can have it authenticated with a remote certificate but that looks fiddly and I've not got it working yet.
posted by BigCalm at 9:03 AM on February 25


It sounds like, ideally, you want to build a poor man's (authenticated!) site-to-site VPN. Have a single host that makes the connections to your customers (possibly on an on-demand basis), and then your users tunnel through that router. The only person that needs to know the passwords in this scenario is the admin of the router.

If you've got Unix familiarity, this shouldn't be tremendously difficult with iptables and something like openconnect. Just create interfaces and start definining forwarding chains.

I will note that I'd make sure you are using the router to glue together two connections -- I'd run openconnect server on the router, and have your users tunnel in to a specific VPN pool that has iptables rule chains to route that pool to a specific customer VPN. That way you aren't bridging the networks. So I'd do:

user -> vpn tunnel -> router -> router's forward chain -> vpn tunnel -> customer rather than:
user -> router -> router's forward chain -> vpn tunnel -> customer

If you bridged to my network, I'd be a little pissed.

By running the openconnect server on the head end, you can tie in with PAM and auth your users to your AD infrastructure.
posted by bfranklin at 9:10 AM on February 25 [1 favorite]


Password protected google doc also doesn't work because we have to use additional files (eg putty ppk files)

If you're using SSH, you really should look into ssh-agent and keychain. One option might be to set up a local linux account that employees ssh into before ssh'ing into the remote sites. This local account has keychain running and ssh-agent preloaded with all the ssh keys they need. Access is controlled by restricting who can and can not login to this account, and once ssh-agent is running, the actual keys don't even need to be on the same system.

There's probably a better way to share an ssh-agent session amongst multiple users.
posted by RonButNotStupid at 9:10 AM on February 25


Ultimately your customers are the ones who are responsible for securing access from these accounts. They are the ones who have to ensure that the credentials cannot/willnot damage their networks. Are you being completely open with them regarding who you are sharing the credentials with? Have you told them why you need new passwords (i.e. employee leaving under a cloud)? If so, you've done what you can assuming you've vetted your people and you've limited access to the original data by storing it on a local server (like you said was plan in your update). You should be under no illusion, however, that these credentials are anything but tainted security-wise.

What sort of bad things could happen if a disgruntled employee gains access to customer VPN with these credentials? Hopefully they still couldn't touch production servers that hold *their* customers' data, could they? If the worst-case scenario is that a breech via these credentials would only cause you to lose a customer and maybe some reputation, then perhaps you can live with the current situation. If the worst-case scenario is that your ex-employee could steal the identities of your customers' customers, or other similarly bad security mojo, then you'll have to set up something where your employees *never* see/use the credentials directly (aka pay professionals to develop such a proxy system customized for your existing infrastructure and business needs).
posted by 0 at 9:10 AM on February 25


It sounds like you have at least two different problems: potentially leaky files and no good way to handle credentials. They require two different solutions, and have very little to do with each other. The files issue is doesn't have a realistic technical solution I'm aware of. The credential issue may.
posted by jsturgill at 11:26 AM on February 25


I am not sure on Egnyte's local cache -- I think it only stores your personal folders locally, not ones shared with you -- but I do know that you can revoke access to cloud links and also kill links after so many clicks/days and some other security features. Egnyte isn't perfect though. I know some of my colleagues found the syncing slow, but I don't know. I never use it.
posted by AppleTurnover at 1:03 PM on February 25


« Older Late last year I moved from Ca...   |  I am going to see a live perfo... Newer »

You are not logged in, either login or create an account to post comments