it-swarm.com.de

Wie sollte ich einen Notfallzugriff auf geschäftskritische Geheimnisse einrichten, falls ich "von einem Bus angefahren" werde?

Ich arbeite als Hauptentwickler und IT-Administrator für ein kleines Unternehmen. Ich möchte sicherstellen, dass das Geschäft fortgesetzt werden kann, auch wenn ich aus irgendeinem Grund plötzlich nicht mehr verfügbar bin. Vieles von dem, was ich mache, erfordert den Zugriff auf eine Reihe von Servern (über schlüsselbasiertes SSH), Cloud-Dienste und andere sichere Infrastrukturen von Anwendungen. Einige dieser Dienste verwenden MFA, entweder mithilfe dedizierter MFA-Apps (wie Amazon) oder per SMS.

Wie stelle ich sicher, dass mein Plan und meine Dokumentation "von einem Bus angefahren" vollständig und umfassend sind, diese Dokumentation jedoch selbst kein Sicherheitsrisiko darstellt?

Die Dokumentation wird auf einem gemeinsam genutzten Dateiserver hinter unserem VPN gehostet. Auf diese kann jedoch auch über ein Web-Frontend eines Drittanbieters zugegriffen werden, das eine "DropBox" -ähnliche Schnittstelle über dem Basisdateiserver platziert (dh Authentifizierung, Desktop-Synchronisierung, Datei) Teilen usw.). Die Dateien befinden sich an einem Ort, an dem nur ich und andere Dateiserveradministratoren sie sehen können.

Wie soll ich die "Geheimnisse" (Passwörter, private Schlüssel, MFA-Zugriff) in dieser Dokumentation verwalten, um sicherzustellen, dass sie umfassend bleiben, ohne die Sicherheit zu beeinträchtigen?

145
AndrewSwerlick

Mein Rat wäre, die Geheimnisse aus der Dropbox zu entfernen und an anderer Stelle aufzubewahren. Ihre Anweisungen müssen für jeden leicht lesbar sein, können jedoch auch Anweisungen enthalten, wie Sie auf den ordnungsgemäß gesicherten Teil der Daten zugreifen können. Auf diese Weise können Sie die Barrierefreiheit von der Sicherheitsseite trennen.

Sobald Sie selbst über Sicherheit nachdenken können, können Sie sich die eigentliche Frage stellen, wie viel Sie zum Schutz dieser Schlüssel benötigen. Dies ist eine Frage der Geschäftslogik. Wenden Sie sich daher an Ihr Management. Sie könnten:

  • Haben Sie ein Passwort für eine Datei, die jeder kennt
  • Richten Sie eine Datei mit mehreren Kennwörtern ein, damit jede Person ihre eigene Kopie verwaltet.
  • Lassen Sie eine Datei durch einen M-out-of-N-Algorithmus sperren (das digitale Äquivalent zum Erfordernis von zwei Schlüsseln zum Entsperren eines Safes).
  • Haben Sie einen M-out-of-N-Algorithmus mit einem 'Master'-Passwort erforderlich, unabhängig davon, welche Gruppe von Personen die Datei entsperrt, und dass ein Master physisch in einem manipulationssicheren Safe aufbewahrt wird, den Sie hin und wieder überprüfen.

Nutzen Sie hier Kreativität. Was auch immer Sie tun, durch die Entkopplung von "Anweisungen" mit "vertraulichen Informationen" können Sie die Informationen ordnungsgemäß schützen und anschließend Anweisungen geben, wie Sie diese Daten später abrufen können.

Ihre Geschäftslogikentscheidungen enthalten auch Fragen zur Verfügbarkeit. Wenn in Ihrem Leben etwas schief geht, wie lange muss ein anderer Administrator Ihre Arbeit übernehmen, bevor das Geschäft beeinträchtigt wird? Überlegen Sie, wie gut diese Anweisungen und vertraulichen Informationen im Falle von Serverfehlern repliziert werden sollen. Als ich einen Server verwaltete und Anweisungen zum Wiederherstellen aus einem Backup speichern musste, habe ich das eigene Wiki des Servers verwendet, um diese Informationen für eine einfache Anzeige zu speichern, aber das wäre natürlich in einem Pannenszenario nicht so nützlich, also auch ich hatte eine Kopie auf dem dev VM dieses Computers, speicherte Kopien davon auf 3 separaten PCs und einen Ausdruck. Ich konnte nicht garantieren, dass der Ausdruck auf dem neuesten Stand bleiben würde, aber ich stellte sicher dass ich mein Bestes geben könnte.

Dies weist auch auf etwas hin, das nicht immer Teil eines Erfolgs des Busplans ist: eine anmutige Verschlechterung. Nicht in allen Szenarien, in denen der Bus ankommt, wird er von einem Bus angefahren. Einige beinhalten, dass Sie zu einem unglücklichen Zeitpunkt nur unzugänglich sind. Einige beinhalten, dass Sie das Unternehmen verlassen, aber für ein oder zwei Fragen zur Verfügung stehen. Andere ... nicht. Überlegen Sie, ob Sie den Plan überlagern möchten. Kleine Pannen können sehr gut geschützt sein, während größere Pannen immer noch zu Geschäftsverlusten führen können, während alle Dinge zusammenbringen, aber nichts Dauerhaftes. Um meinen Backup-Wiederherstellungsplan als Beispiel zu verwenden, wurde fast garantiert, dass die gedruckte Version nicht vollständig auf dem neuesten Stand ist. Aber wenn ein Blitz jeden Computer für einen Stadtblock auslöschte, war es immer noch hilfreicher als nichts. Wenn der Server jedoch nur eine Festplatte hat und ich aus dem Backup wiederherstellen musste, war die Version, die ich auf der Entwicklungsbox synchronisiert habe, mit ziemlicher Sicherheit auf dem neuesten Stand.

Beispiel für diesen Fehler: Ich war ein Benutzer in einem von KERBEROS verwalteten Netzwerk von einem Administrator, der anderen misstraute und keinen Bus-Hit-Plan hatte. Als er ... ging, hatten wir eine Hacking-Party, um zu versuchen, seinen Server zu beschädigen. Am Ende war es unser bester spontaner Plan, die Maschinen (jede einzelne) abzuwischen und von vorne zu beginnen. Beachten Sie, dass dies zwar nicht der beste Plan war (ich denke, es ist der schlechteste Plan?), Das Geschäft jedoch in Bewegung blieb. Wir haben gerade zwei Tage lang stagniert und hatten ein paar mürrische Kunden. Mit den Worten von Frank Herberts Dune : "Das Gewürz muss fließen." Selbst im schlimmsten Fall (der einen merkwürdigen Vorfall beinhalten kann, bei dem die Festplatte Ihres Servers aus dem Bus geschleudert wird und Sie auf den Kopf trifft und alle Aufzeichnungen des Planes für einen Bus zerstört), Geschäft hat eine Möglichkeit, in Bewegung zu bleiben ... aber ich bin damit einverstanden, die Messlatte ein bisschen höher zu legen!

80
Cort Ammon

Holen Sie sich ein USB-Gerät. Legen Sie alle Geheimnisse auf den USB-Stick, vorzugsweise in eine KeePass-Datei. Teilen Sie der neuen Person in der Dokumentation mit, wo sich der USB befindet und wie er entsperrt werden kann. Bewahren Sie das Gerät jedoch an einem sicheren physischen Ort auf, z. B. im Büro des Eigentümers, im Unternehmenssafe, in einem Schließfach usw. Außerhalb der Reichweite des Öffentlichkeit und weg von den neugierigen Augen anderer Mitarbeiter.

Die Vorteile dieses Plans sind:

  • Es ist nicht im Internet oder im internen Netzwerk
  • Sie können sicher sein, dass der neue Mitarbeiter es zumindest geschafft hat, die für den Lagerort verantwortliche Person davon zu überzeugen, dass sie authentisch ist (und höchstwahrscheinlich von hochrangigen Mitarbeitern flankiert wird, um sogar in die Nähe Ihres Lagerortes zu gelangen).
  • Wenn jemand versucht, an den Flashdrive zu gelangen, bevor Sie, ähm, vom sprichwörtlichen Bus angefahren werden, sollte sich jemand wahrscheinlich denken: "Hmm, Andrew lebt noch. Warum berührt jemand das?"
  • Wenn jemand Ihre Unterlagen findet, ist der Schaden, den er anrichten kann, begrenzt (insbesondere, wenn er über das Internet eingebrochen ist - nur sehr wenige Personen werden zu Ihrer Information unterwegs sein).

Um die Leckereien zu finden, benötigen sie 1) Ihre Dokumentation, 2) physischen Zugang, 3) Sie müssen sich nach den Fjorden sehnen. Der USB ist auch ein hübsches kleines Paket für die nächste Person - Plug and Play! Oder Panik, je nachdem, wie wichtig Sie für das Unternehmen sind.

74
Ohnana

Erstellen Sie Konten nur für den Notfall

Für die meisten Systeme verfügen Sie über privilegierte Konten, die in der täglichen Verwaltung verwendet werden. Diese können je nach Unternehmensrichtlinie personalisiert sein oder nicht.

Anmeldeinformationen können aus verschiedenen Gründen den Zugriff auf sie verlieren - entweder durch die Person, die weiß, dass sie von einem Bus angefahren werden, oder durch den Verlust der beabsichtigten sicheren Speicherung dieser Anmeldeinformationen (z. B. durch den Verlust eines Computers bei einem Brand) oder durch die Verwaltung ein Passwort in etwas zu ändern, das sie nicht kennen usw.

Möglicherweise können separate Konten für Schlüsselsysteme erstellt werden, die über vollständigen Zugriff verfügen, jedoch nicht für den täglichen Gebrauch vorgesehen sind. Dies impliziert:

  1. Im Moment kann niemand auf sie zugreifen - niemand kennt die erforderlichen Passwörter.
  2. Wenn jemand auf sie zugreift, sollte jeder informiert werden (da dies unter normalen Umständen nicht passieren sollte). Beispielsweise werden bei automatisierten Skripten, die bei der Anmeldung mehrere wichtige Benutzer per E-Mail benachrichtigen, alle Aktionen dieser Konten protokolliert, und Ihre tägliche Überwachung leuchtet auf, wenn von diesen Konten aus etwas ausgeführt wird.
  3. Bei Bedarf können Benutzer auf diese Konten zugreifen. Eine einfache Möglichkeit besteht darin, ein langes Kennwort oder einen langen Schlüssel zu erstellen, auszudrucken, in einen versiegelten und signierten Umschlag zu stecken und in einem Safe zu verschließen.

Geben Sie dort Ihre Sicherungsverfahren und Anmeldeinformationen ein

Wenn Sie Ihre Verfahren, den Bus-by-a-Bus-Plan und die Liste der sekundären Anmeldeinformationen auf eine für Sie geeignete Weise verwalten, stellen Sie einfach sicher, dass auf diese Dokumente oder Kennwortdatenbanken auch über das Notfallkonto zugegriffen werden kann.

29
Peteris

Vielleicht besteht eine bessere Lösung für Ihre Situation darin, das System so zu gestalten, dass selbst wenn Sie von einem Bus angefahren werden und Ihre Anmeldeinformationen für immer verloren gehen, nichts Schlimmes passiert.

Vielleicht ist es am besten, sich das Problem als zwei Probleme vorzustellen: Authentifizierung und Autorisierung.

Durch die Authentifizierung wird festgestellt, dass Sie der sind, für den Sie sich ausgeben. Einige Systeme können wissen, dass eine Anfrage wirklich von Ihnen kam, weil nur jemand mit Ihren Anmeldeinformationen die Anfrage hätte stellen können, und nur Sie die Anmeldeinformationen kennen.

Durch die Autorisierung wird festgelegt, dass Sie eine bestimmte Sache ausführen dürfen. Eine Anfrage kann authentisch, aber nicht autorisiert sein.

Wenn mindestens zwei Personen berechtigt sind, etwas zu tun, spielt es keine Rolle, ob eine von ihnen von einem Bus angefahren wird. Alice kann von einem Bus getötet werden und das Wissen über ihre Anmeldeinformationen geht für immer verloren. Aber Bob kennt seine eigenen Anmeldeinformationen und ist berechtigt, alles zu tun, was Alice tun kann.

Wenn das System so konzipiert ist, dass jeder buchstäblich von einem Bus angefahren und getötet werden kann, bedeutet dies auch, dass die Anmeldeinformationen einer Person widerrufen werden können. Ehemalige Mitarbeiter, insbesondere solche, die zu schlechten Konditionen abreisen, haften für die Sicherheit. Sie können einen ehemaligen Mitarbeiter nicht zwingen, ein Kennwort zu vergessen. Aus Sicherheitsgründen sollten Sie alle freigegebenen Kennwörter ändern, wenn ein Mitarbeiter das Unternehmen verlässt. In der Praxis ist dies zu schmerzhaft und wird nicht durchgeführt. Das Problem wird dadurch behoben, dass Passwörter überhaupt nicht freigegeben werden.

Wenn Sie niemals Passwörter teilen, bleibt auch Verantwortlichkeit erhalten. Sie können kein Unternehmen ohne Administratoren führen, möchten jedoch wissen, ob ein bestimmter Administrator seine Befugnisse missbraucht. Letztendlich hält die Androhung einer Kündigung oder eines Rechtsstreits jeden Administrator von Missbrauch ab. Wenn Passwörter geteilt werden, ist "muss einer der anderen Administratoren mit dem Passwort gewesen sein" eine plausible Verteidigung.

Manchmal stoßen Sie auf Situationen, in denen es unmöglich erscheint, das Teilen eines Passworts zu vermeiden. Aber normalerweise gibt es eine Lösung, auch wenn dies nicht sofort offensichtlich ist.

Müssen Sie Root-Passwörter teilen? Nein, Sie können überhaupt kein Root-Passwort haben und stattdessen Sudo verwenden.

Was ist mit AWS-Root-Anmeldeinformationen? Sie können stattdessen IAM verwenden.

Vielleicht haben Sie eine besonders hirntote Webanwendung, die Sie nicht vermeiden können? Möglicherweise können Sie dieses Problem nicht beheben, aber Sie können es vertuschen: Verwenden Sie einen Kennwortmanager, mit dem Sie Anmeldeinformationen für mehrere Benutzer freigeben können. (Ich weiß, dass LastPass dies kann). Während Sie das Kennwort noch freigeben, verfügen Sie zumindest über ein automatisiertes Mittel, um es zu ändern und das Wissen über das neue Kennwort zu verbreiten. Ändern Sie das Passwort mindestens, wenn ein Mitarbeiter das Unternehmen verlässt, vorzugsweise jedoch häufiger.

11
Phil Frost

Die meisten Antworten beziehen sich auf den Umgang mit Anmeldeinformationen, wahrscheinlich aufgrund dieser expliziten Frage im OP:

Wie lassen sich die "Geheimnisse" (Kennwörter, private Schlüssel, MFA-Zugriff) in dieser Dokumentation am besten verwalten, um sicherzustellen, dass sie umfassend bleiben, ohne die Sicherheit zu beeinträchtigen?

Der Titel stellt jedoch eine andere Frage, die ich nicht angesprochen sehe:

Entwicklung eines sicheren Treffers durch einen Busplan

Die Antwort auf die Frage das lautet Automatisierung.

Bei Entwicklern fällt der größte Teil der Serverseite der Position in zwei Kategorien:

  • Korrigieren Sie die Infrastruktur : Hier gibt es normalerweise nichts zu automatisieren: Jedes Problem ist anders. In diesen Fällen ist die Kenntnis der Infrastruktur (Server, Netzwerk, Interaktion der Entwickler mit den Git-Repos) von entscheidender Bedeutung.

  • Infrastruktur pflegen : Neue VM Instanzen erstellen, Apache einrichten, Entwicklerzugriff aktivieren zu Ressourcen usw. Dies ist der Ort, an dem die Automatisierung am sichtbarsten ist.

Wenn die Rolle der Automatisierung in letzterem offensichtlich ist, ist der Schlüssel zur erfolgreichen Behebung von Problemen in ersterem die Automatisierung in letzterem . Die automatisierten Skripte Python und Bash) dienen als lebende Dokumentation dessen, was erwartet ist der Server und des Netzwerks: Wenn sich der Workflow ändert, ändern sich die Skripte. Git zeichnet Änderungen auf, die möglicherweise auf ältere Server anwendbar sind, und Git-Commit-Nachrichten sind explizit.

6
dotancohen

Dies ist keine weitere Idee, wie man es per se macht, sondern ein Punkt, um etwas hervorzuheben, das noch nicht besprochen wurde, aber sehr wichtig ist. Ich gehe davon aus, dass diese Geheimnisse wirklich geschäftskritisch sind.

Testen.

Einige Disaster Recovery-Szenarien wurden aufgestellt. Einige sind einfach, andere komplexer. Je komplexer, desto mehr Grund zum Testen. Dieses Problem ist darauf zurückzuführen, wie Sie testen, ob jemand in einer geschäftskritischen Umgebung von der Szene entfernt wird. Wenn Sie während des Weihnachtshandels eine 20-mm-Runde durch Ihren Produktionsserver führen und Ihr primärer IT-Mitarbeiter ohne Kontakt zur Außenwelt ist, ist es schwierig, durch das Board Ihrer Spielzeugfabrik zu gelangen. Dies ist das Dilemma vor dem Vorstand. Wenn es wichtig ist, müssen Sie es testen. Ist es zu wichtig zu testen?

Einfache Dinge werden dich erwischen. Jemand hat erwähnt, dass Daten in Safes gespeichert werden. Großartig. Viele Leute bewahren ihre Safes im Keller auf, wo sie sicher und fern von Menschen sind. Es ist auch der Ort, der sich nach einem kleinen Brand zunächst mit Wasser füllt. Ein weiterer; Ihr zwielichtiger Angestellter hat wirklich zwielichtige Sachen mit Ihrer Gehaltsabrechnung gemacht. Die Polizei kommt herein und beschlagnahmt alle Ihre Server für die anschließenden Ermittlungen. Es dauert ein Jahr, um sie zurückzubekommen. Rollen Sie nicht mit den Augen - es passiert.

Geschäftskontinuität ist eine ziemlich etablierte Kunst. Tun Sie also genau das, was die NASA, Google, Barclays, die Armee und Atomkraftwerke tun. Redundanz machen. Es tut mir leid, das zu sagen, Andrew, aber in diesem Szenario sind Sie das Hauptrisiko für das Unternehmen. Das Board muss darauf aufmerksam gemacht werden, und Sie und zumindest ein Teil Ihres Kits müssen überflüssig gemacht werden (im Sinne der Vervielfältigung).

Lassen Sie in der Zwischenzeit Ihren Ops Director eine Versicherung für kritische Personen und/oder eine Business Continuity-Versicherung abschließen.

2
Paul Uszak

Ich bin in einer sehr ähnlichen Situation wie der einzige IT-Administrator eines mittelständischen Unternehmens mit vielen verstreuten, lose verwandten benutzerdefinierten Softwareprogrammen auf verschiedenen Plattformen. Schlimmer noch, ich habe in den letzten zehn Jahren die gesamte Software für das Unternehmen geschrieben, vom POS-System bis hin zu Online-Reservierungen, einem Homebrew-CMS, Software für Mitarbeiterschulungen usw. Zu diesem Zeitpunkt bin ich die einzige Person, die versteht oder jemals hat Ich habe sogar die Quelle für diese Dinge gesehen. Als das Unternehmen gewachsen ist, wurde ich mehr als einmal gebeten, nicht von einem Bus angefahren zu werden. Ich werde Ihnen sagen, was unsere Lösung dafür war.

  1. Verstehe, dass es zu Störungen kommen wird. Erwartungen verwalten. Wenn das Unternehmen keine entlassene Person einstellen möchte, vermutlich eine gut bezahlte, um alles zu lernen, was Sie wissen, dann muss es damit rechnen, dass es eine sehr steile Lernkurve für jeden gibt, der im Notfall eintreten muss und versuche deine Schuhe zu füllen. Dies gilt unabhängig davon, wie gut Ihre Dokumentation ist.

  2. Stellen Sie sicher, dass die Servicerechnungen an das Unternehmen gehen, nicht an Sie.

  3. Kontinuität des Geschäftsdokuments. Zu einem bestimmten Zeitpunkt wurde ich gebeten, ein Dokument zu schreiben, das in einfachem Englisch abgefasst ist und das der CEO des Unternehmens lesen kann, genau, welche Server wir haben, was sich auf jedem Server befindet, was jede Software tut und welche Passwörter für diese vorhanden sind Konten. Darin befinden sich Notizen und Tipps für alle, die mitgekommen sind und es am Laufen halten mussten. Es versteht sich jedoch, dass gemäß (1) ein Buch erforderlich ist, um die Funktionen, bekannten Probleme und Einschränkungen sowie die Struktur der gesamten Software im Detail zu erläutern. Dieses Dokument enthält also das Nötigste, mit der Hoffnung, dass jemand, sobald er sich mit dem Code befasst hat, sich mit Cron-Aufgaben befasst und Kommentare liest und einen Überblick über deren Funktionsweise erhält.

Ich aktualisiere das Kontinuitätsdokument bei Bedarf, verschlüssle es mit PGP, sodass es nur vom CEO des Unternehmens und mir geöffnet werden kann, und lade es auf den Webserver an eine ihm bekannte Adresse hoch. Der CEO ist dafür verantwortlich, seinen PGP-Schlüssel sicher aufzubewahren. Das ist alles dazu.

Und hör zu - wenn sie dich nicht einmal entspannen lassen, nachdem du tot bist, ist es Zeit, um eine Gehaltserhöhung zu bitten.

1
joshstrike