Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

At the moment we are encrypting our server passwords and other important data internal via PGP. Every coworker has got his/her own private key/pass combination set up on their workstation. The problem is now, when a new coworker comes into play, we have to decrypt and encrypt everything again, including his public key. Depending on how much access the coworker gets and how often new coworkers join the team (or leave, so we may set new passwords), this process is getting heavier and heavier.

We would like to change our system in giving access to certain passwords/data (there are hundreds!) to coworkers and remove this overhead with re-encrypting all data over and over again.

But! The level of safety shall not be touched (4096 bit RSA Keys)!

All coworkers are entirely working with linux boxes, administered by themselves (mostly Ubuntu, Debian installs).

Any ideas are very much appreciated.

share|improve this question
    
How exactly are you encrypting your data? Like on filesystems? Or on access? Or both? Or what? –  Wolfer Oct 24 '13 at 16:27
add comment

4 Answers

Your current arrangement sounds like a shared password keystore.

Your problem is essentially the difference between centralised and decentralised access control:

  1. When access control is per server or service, the maintenance of the access control is centralised per service and reflects an effort of O(N) where N = amount of services for the company.
  2. When access control is per person, the maintenance of the access control is decentralised from the standpoint of ICT assets and reflects an effort of O(N) where N = amount of staff for the company.

It is likely that the amount of services you initially had grew faster than the amount of staff and hence the second option was more appealing.

But now the amount of staff or turnover of the staff is higher than the amount of services and is costing you more to maintain than server/service-based access control lists would. The tipping point being O(N).services + O(1).service versus O(N).people + O(1).people as the initial O(1) overhead of each new service or person would have masked the long term shift in effort.

So it becomes a question of security vs your company's shared work culture. You can shift across to the now possibly cheaper server and service access control approach, and you will gain additional auditing benefits in the process; but the shift will require a lot of migration effort and a hierarchical "unflattening" of your company's work culture.

If we go back to the days of physical keys and filing cabinets, the difference is between the team all sharing the same cabinet key versus just a couple of people having the cabinet key.

I don't think you have much of a choice regarding a shift towards to server/service ACLs once you have more staff or role volatility than servers - but you can reduce the ACL overhead through systematic use of client certificates:

  1. Convert their RSA key pairs into self-signed client certificates.
  2. Add or remove their public certificate from servers and services directly or from a centralised role-based LDAPS authentication service.
  3. (Optional) Convert key pairs into certificates signed by the company private Root CA to enforce routine expiration and stop people from generating access credentials you are unaware of (i.e. breaking the audit chain).

Client certificates have the benefit of being more secure than passwords and having a wide range of embedded meta-data without needing real-time access to the LDAP server.

share|improve this answer
add comment

We'd need much more details about the servers and that "important internal data" to suggest something really useful for your configuration.

But we can answer something more general:

  • use some access control for your servers: instead of having some root account with one password, create users for each one, and give the sudo ability, or something like that

  • the same to databases: each user with a login, and with admin rights

  • all that should be done using some central repository, like some LDAP, so you'll have to manage a single point.

share|improve this answer
add comment

You may just need one more level of indirection: the individual's key gives access to a store with a secret key, but that key really points to another key. The first key is used to encrypt the second, and changes every time staff changes. The second changes much more slowly, and encrypts what you want kept safe.

This was part of a plan for scalable and separate encryption of company and private data, and from what little I know*, may be a norm in schemes intended for lots of changes in staff and staff clearances.

--dave
[* Morven's metatheorem: any problem in computer science can be solved with one more level of indirection]

share|improve this answer
add comment

use some access control for your servers: instead of having some root account with one password,also each user have their login ID and access for the admin only.

laptop hard drive data recovery

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.