Skip to main content
Clarified title. Rearranged content to reduce repetition. Removed last "ask me if you want to hear my ideas"-paragraph as it's not really part of the question. Fixed some grammar and clarified sentence structure.
Source Link

Developing a secure plan for the event of being hit How should I set up emergency access to business-critical secrets in case I am "hit by a busbus"?

I work as the primary developer and IT administrator for a small business. As a result, there are a lot of things that I need to ensure are documented and readywant to ensure thethat business keeps functioningcan continue even if something goes wrong and I amsuddenly become unavailable for some reason. AlotMuch of the thingswhat I do require that anyone stepping into my role haverequires access to a number of servers, (through key based-based ssh), cloud services, and other secure infrastructure of applications. Some of these services use MFA, either using dedicated MFA apps (like amazonAmazon) or using SMS.

How do I want to ensure that my "hit by a bus" plan and documentation, is complete and comprehensive, but that this documentation doesis not itself create a security risk.?

The documentation will be hosted on a shared file server behind our VPN, but that can also be accessed using a third party web frontend that puts a "DropBox" like-like interface on top of the base file server (iei.e. authentication, desktop syncing, file sharing, etc). The files are in a location where only I, and other file server administrators can see them.

What's the best way toHow should I manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security?

Note: I already have some ideas that I will explain in comments if desired, but I wanted to leave the question open-ended to get ensure I didn't exclude any possible approaches.

Developing a secure plan for the event of being hit by a bus

I work as the primary developer and IT administrator for a small business. As a result, there are a lot of things that I need to ensure are documented and ready to ensure the business keeps functioning if something goes wrong and I am unavailable. Alot of the things I do require that anyone stepping into my role have access to a number of servers, (through key based ssh), cloud services, and other secure infrastructure of applications. Some of these services use MFA, either using dedicated MFA apps (like amazon) or using SMS.

I want to ensure that my "hit by a bus" plan and documentation, is complete and comprehensive, but that this documentation does not itself create a security risk. The documentation will be hosted on a shared file server behind our VPN, but that can also be accessed using a third party web frontend that puts a "DropBox" like interface on top of the base file server (ie authentication, desktop syncing, file sharing, etc). The files are in a location where only I, and other file server administrators can see them.

What's the best way to manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security?

Note: I already have some ideas that I will explain in comments if desired, but I wanted to leave the question open-ended to get ensure I didn't exclude any possible approaches.

How should I set up emergency access to business-critical secrets in case I am "hit by a bus"?

I work as the primary developer and IT administrator for a small business. I want to ensure that business can continue even if I suddenly become unavailable for some reason. Much of what I do requires access to a number of servers, (through key-based ssh), cloud services, and other secure infrastructure of applications. Some of these services use MFA, either using dedicated MFA apps (like Amazon) or SMS.

How do I ensure that my "hit by a bus" plan and documentation is complete and comprehensive, but that this documentation is not itself a security risk?

The documentation will be hosted on a shared file server behind our VPN, but that can also be accessed using a third party web frontend that puts a "DropBox"-like interface on top of the base file server (i.e. authentication, desktop syncing, file sharing, etc). The files are in a location where only I, and other file server administrators can see them.

How should I manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security?

Developing a secure plan for the event of being hit by a bus plan

Tweeted twitter.com/StackSecurity/status/671416785707671552
Source Link
AndrewSwerlick
  • 1.5k
  • 2
  • 10
  • 7

Developing a secure hit by a bus plan

I work as the primary developer and IT administrator for a small business. As a result, there are a lot of things that I need to ensure are documented and ready to ensure the business keeps functioning if something goes wrong and I am unavailable. Alot of the things I do require that anyone stepping into my role have access to a number of servers, (through key based ssh), cloud services, and other secure infrastructure of applications. Some of these services use MFA, either using dedicated MFA apps (like amazon) or using SMS.

I want to ensure that my "hit by a bus" plan and documentation, is complete and comprehensive, but that this documentation does not itself create a security risk. The documentation will be hosted on a shared file server behind our VPN, but that can also be accessed using a third party web frontend that puts a "DropBox" like interface on top of the base file server (ie authentication, desktop syncing, file sharing, etc). The files are in a location where only I, and other file server administrators can see them.

What's the best way to manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security?

Note: I already have some ideas that I will explain in comments if desired, but I wanted to leave the question open-ended to get ensure I didn't exclude any possible approaches.