In the message dated: Fri, 16 Mar 2012 08:03:37 EDT, The pithy ruminations from Edward Ned Harvey on <Re: [lopsa-tech] [LISA] how to handle 'vacation' coverage for a small shop?> w ere: => > From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] => > On Behalf Of Elizabeth Schwartz => > => > my boss had a sealed envelope with *all* the root => > and network passwords. (in a solo shop, *someone* should ALWAYS have => > an envelope like this at all times!!!) => => No, no, no, no, no! Although there are some security risks of envelope => being stolen etc, that's not my main objection. My main objection is this: => If you and your boss are authorized to have this information, then you => should share it always, encrypted, all the time. The documentation is just
Well....yes & no. In our case, the boss (and a couple of people who act as backup sysadmins) have access to and encrypted password list. The list is stored in keepass, which has the terrific advantage of being cross platform, so we've got that on a server, on laptops, etc. => as sensitive as the password list. Put all your documentation in a secured => repository somewhere (could be a file server, svn, or whatever) and store it => on your hard drive in encrypted format (maybe using WDE, or TrueCrypt, or => whatever you like) and sync to each other regularly. We don't keep sensitive documentation -- there's nothing the configuration or operation documentation that's sensitive, so all that documentation is in a Wiki. => => Hypothetical: Servers all die. In your documentation is the "startup => procedure" so the systems that are dependent on other systems (DHCP, DNS, => AD, NIS, LDAP, NFS Filesystems, iSCSI storage, etc) come up in the right => order, with the right timing, lest they don't come up correctly. But that Exactly. => documentation is stored in one of the offline servers. Your boss has the Nope. Our procedural documentation is stored in a Wiki on the servers. Of course servers die, or services don't restart, and there's a risk that the Wiki will not be available. My solution is that there's a process that crawls the "Sysadmin" section of the Wiki nightly and prints out any changed pages. Those pages go into a file folder. I'm comfortable with the risk that a server (or Wiki service, or printer) outage might have happened in the window between text changing and the nightly printout. If the text described a critical change (which was the cause of the outage), then the change would also have been discussed off-line. As I see it, an "offline server" has the disadvantages of paper (difficult to update from the definitive source), has a higher maintenance and security burden than paper, and offers few advantages. => root pass, which is a good start, but simply insufficient. => => All the documentation that's needed to recover from disaster should be => available in the event of a disaster, and the passwords are just one tiny => subset of that documentation. You can't allow it to stagnate (irrelevant Absolutely. => old versions stored offline). This means while everything's normal, it must => automatically (or semi-automatically) get updated and replicated to offline => accessible storage areas (such as your laptop) and must be encrypted... Yep. The one missing piece in our operation is that there's no automatic replication of the encrypted keepass database onto the director's phone or onto the backup sysadmin's laptops. For us, that's a relatively low vulnerability, as the most critical information (server root passwords, for example) has a very low change rate, while other keepass changes are of much less importance in an emergency (for example, the SQL db password for a particular application). => => I've worked through several incantations of this solution. Originally => truecrypt & svn. Now I'm using encfs and dropbox. Always share with my => boss and colleague. I use dropbox myself for storage of the keepass data. Unfortunately that doesn't work transparently within our environment as the corporate firewall blocks dropbox. => => Nobody's scared to update the documentation as they see fit, because we all => have replicated copies in real-time and backup copies and old versions. That's our experience as well. Mark => => _______________________________________________ => Tech mailing list => Tech@lists.lopsa.org => https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech => This list provided by the League of Professional System Administrators => http://lopsa.org/ => _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
