Im Allgemeinen

Es gibt nicht wirklich eine Antwort auf diese Frage, und ich würde "große Unternehmen" nicht unbedingt als etwas Besonderes mit unterschiedlichen Ansätzen betrachten. Sicherlich haben die von Ihnen genannten Unternehmen ihre eigene Vorgehensweise, aber die Personen, die am besten für sie antworten können, sind Mitarbeiter dieser Unternehmen.

Bei großen Unternehmen im Allgemeinen variieren sie ebenfalls weit verbreitet, auch für "Tech" -Unternehmen. Einige verfolgen einen sehr top-down Ansatz in Bezug auf Sicherheit und technische Nutzung, andere nicht. Einige legen großen Wert auf Sicherheit und viele nicht. Einige Unternehmen bevorzugen es, ihre eigenen Tools zu erstellen, während viele es vorziehen, Systeme von Drittanbietern zu verwenden und das Rad nicht jedes Mal neu zu erfinden.

Darüber hinaus kann es innerhalb eines Unternehmens sehr unterschiedlich sein. Verschiedene Abteilungen innerhalb der Organisation haben möglicherweise ihre eigenen Methoden, verschiedene Teams innerhalb der Abteilungen können die Dinge auch anders machen, und dann können natürlich einzelne Mitarbeiter häufig ihre eigenen Dinge tun. Auch hier hängt es stark davon ab, ob die Technologie von oben nach unten oder von unten nach oben ausgewählt wird.

Ein Beispiel

Das Unternehmen, für das ich arbeite, ist größer (~ 12.000 Mitarbeiter) ) internationales E-Commerce-Unternehmen. Wir verwenden Single Sign On (SSO) für fast alles Interne, stellen den Mitarbeitern jedoch ein Konto mit einem Online-Passwort-Manager zur Verfügung. Dies ist für alle anderen Websites vorgesehen, für die sich Mitarbeiter im Laufe ihrer Arbeit anmelden müssen und bei denen sie sich nicht mit unserem eigenen SSO (AKA, Rest des Internets) anmelden können. Das Unternehmen erwirbt außerdem für jeden Mitarbeiter eine Lizenz für ein "persönliches" Konto beim Passwort-Manager, hauptsächlich in der Hoffnung, dass die Benutzer nicht dazu ermutigt werden, persönliche Passwörter in ihrem Firmenkonto zu speichern.

In der Praxis variiert die Verwendung stark von "Abteilung" zu "Abteilung", wobei einige fast zu 100% angenommen werden, während andere Bereiche des Geschäfts sie nur sehr wenig verwenden und ihre eigenen bevorzugten Methoden zum Speichern wichtiger Geheimnisse haben.

Als ich ging, konzentrierte sich die Facebook-Authentifizierung stark auf die Multifaktor-Authentifizierung. Sowohl Facebook als auch Google investierten in den Kauf von Yubikeys, und Google entwickelte U2F, das zu FIDO wurde. Der Serverzugriff basierte auf der Ausstellung eines signierten SSH-Zertifikats. Es gab einen "Glasbruch" -Ssh-Schlüssel, der physisch in einem Safe aufbewahrt wurde, sowie einige "Super-Bastion" -Hosts, die verwendet werden konnten, falls die Website so stark ausfiel, dass die Leute anfingen, die Polizei anzurufen. IP-Bereiche und DNS-Einträge können jedoch so einfach sein wie das automatische Anwenden der Konfiguration aus einem Git-Repository. DNS-Änderungen bei Facebook sind häufig.

Fast jeder Zugriff basiert auf der regulären Benutzeridentität, normalerweise jedoch mit Ebenen. Eine VPN-Verbindung, für die ein Zertifikat in Verbindung mit einer Signaturaufforderung erforderlich ist, bei der der Schlüssel in der sicheren Enklave des Computers gespeichert ist, kann so verwendet werden, dass Sie nur dann auf ein System mit meinen Anmeldeinformationen zugreifen können, wenn ein mir zugewiesener Computer beteiligt ist.

In kleineren Unternehmen, die AWS verwenden, habe ich die AWS-Root-Zugriffskontrolle implementiert, indem ich das Kennwort und das 2FA-Geheimnis in Vault eingegeben und die in Vault integrierte SSS-Root-Schlüsselverteilung für Sicherungen verwendet habe. Jeder Zugriff wird jedes Mal überwacht, da Sie den rotierenden 2FA-Code benötigen (Vault lässt Sie nicht das Geheimnis zurücklesen, sondern nur den Token-Wert), es sei denn, Sie arbeiten zusammen, um sowohl die Backups (von einem Team verwaltet) als auch die erforderliche Absprache zu erhalten von anderen Mitarbeitern.

Ich arbeite für 1Password.

Wir haben eine Reihe großer Unternehmen, die 1Password verwenden, aber wir sprechen nicht ohne deren ausdrückliche Genehmigung über unsere Kunden. Beachten Sie auch, dass wir nicht sehen können, was wo gespeichert wird, sodass wir nicht wirklich daraus schließen können, wie sie mit einigen der von Ihnen gestellten Fragen zu sehr guten Verwaltungsfragen umgehen. Manchmal sind wir jedoch Teil von Diskussionen mit den Sicherheitsteams unserer Kunden über solche Dinge.

Einige Unklarheiten

Eine Sache, die zu beachten ist, ist, dass Sicherheit durch Unklarheiten im Allgemeinen eine schlechte Sache ist Einige der Details, die Sie erwähnen, werden am besten geheim gehalten. Wenn eine Organisation beispielsweise Shamir Secret Sharing verwendet, möchten Sie möglicherweise nicht veröffentlichen, wer Aktien hält und wie viele Aktien benötigt werden.

Ich werde Ihnen also nicht sagen, wer die Administratoren von sind unser 1Password-Konto noch wie sie ihre eigenen Master-Passwörter und geheimen Schlüssel verwalten. Ich werde auch nicht auf die Aspekte unserer Business Continuity-Pläne eingehen, die sich mit einigen dieser Personen befassen, die von einem Bus angefahren werden. Diese sind gut durchdacht und gut geschützt, aber ich möchte niemandem ein Ziel auf den Rücken legen. (Sicher können Sie raten, und einige dieser Vermutungen könnten sogar richtig sein.)

Aufteilung der Wiederherstellungsleistung

Eine Sache, die Sie möglicherweise tun möchten, wenn Sie ein Unternehmen sind, das 1Password verwendet, ist Stellen Sie sicher, dass Sie die Anzahl der Personen begrenzen, die sowohl über Wiederherstellungsbefugnisse innerhalb von 1Password als auch über die Kontrolle über E-Mails innerhalb des Unternehmens verfügen. Ich möchte nicht auf die wichtigsten Details der gesamten Schlüsselverwaltung eingehen, die für die Kontowiederherstellung verwendet wird, außer zu bemerken, dass wir bei 1Password nie die Schlüssel haben, um dies zu tun, aber wenn Alice beide die richtige Art ist Administrator für ein 1Password-Team, zu dem Bob gehört, und sie kann Bobs E-Mail lesen. Dann kann sie Bobs 1Password-Konto in diesem Team übernehmen. (Obwohl nicht auf eine Weise, die für Bob unsichtbar ist.) Beachten Sie, dass dies in unserem Sicherheitsdesigndokument dokumentiert ist.

Einige Organisationen möchten möglicherweise die Personen einschränken, die beide Befugnisse haben. Dies ist ein größeres Problem für kleinere Organisationen als für größere. In kleineren Unternehmen verfügen Sie über kleinere IT-Teams. Daher können Personen, von denen erwartet werden kann, dass sie eine Kontowiederherstellung durchführen, auch der Manager der E-Mail-Adressen des Unternehmens sein. Dies ist übrigens einer der Gründe, warum wir kostenlose Familienkonten für Mitglieder eines Geschäftskontos anbieten. Der Arbeitgeber ist nicht in der Lage, eine Wiederherstellung oder einen Zugriff auf die Daten im Familienkonto eines Mitarbeiters durchzuführen.

Feinere Verwaltungsbefugnisse

Ein Mitglied der Wiederherstellungsgruppe für ein Team zu sein, bedeutet dies Bestimmte Schlüssel wurden mit Ihrem öffentlichen Schlüssel verschlüsselt. Es gibt viele administrative Aufgaben, für die keine Mitgliedschaft in der Wiederherstellungsgruppe erforderlich ist. Ein Unternehmen kann beispielsweise die Bereitstellung und Deprovisionierung von Benutzern sicher automatisieren, ohne jemals auf Wiederherstellungsgruppenschlüssel zugreifen oder diese entschlüsseln zu können.

Im Allgemeinen versuchen wir, dies für Unternehmen einfach (oder zumindest nicht zu schmerzhaft) zu gestalten Befolgen Sie eine Richtlinie mit den geringsten Berechtigungen für die Befugnisse, die an der Verwaltung von 1Password-Benutzern beteiligt sind.

Shamir Secret Sharing, HSMs usw.

1Password bietet diese Technologie (noch?) nicht an. Aber ich habe Grund zu der Annahme, dass einige unserer Kunden dies für einige Meistergeheimnisse selbst tun. Ebenso habe ich Grund zu der Annahme, dass einige unserer Kunden HSMs zum Entschlüsseln einiger Hauptgeheimnisse verwenden.

Ich halte es für eine gute Sache, dass sie dies außerhalb des 1Password-Tools selbst tun. Wir könnten mehr tun, um Hooks bereitzustellen, um eine solche Integration zu vereinfachen, aber diese Schlüsselverwaltung sollte über ein anderes System erfolgen.

Auch ich würde gerne mehr darüber erfahren, was unsere Kunden damit machen, und Ich freue mich auf folgende Antworten. Gleichzeitig glaube ich, dass dies eine Frage von Richtlinien und Praktiken ist, bei denen eine gewisse Unklarheit nützlich ist.

Sie erwähnen private Schlüssel. Für diese ist eine bekannte Methode die Verwendung von Hardware-Sicherheitsmodulen (HSM). Wie Chip-basierte Kreditkarten bewahren sie den Schlüssel in einer Box auf, die Sie nicht öffnen können, und Sie bewahren die Box an einem sicheren Ort auf. Der Zugriff auf die Signaturfunktion der Box (natürlich ohne Offenlegung des geheimen Schlüssels) kann auch elektronisch geschützt werden, z. B. wenn Ihre Kreditkarte eine PIN-Nummer benötigt. Boxen können direkt an einen Server angeschlossen werden, wenn Sie den Schlüssel häufig verwenden müssen, oder sie können offline gespeichert werden.

HSMs sind normalerweise nur ein Teil einer größeren Infrastruktur, um Schlüssel zu schützen, während dies noch möglich ist Verwenden Sie sie, aber Unternehmen sind nicht daran interessiert, detailliert zu zeigen, wie sie es tun. IANA ist zwar kein sehr großes Unternehmen, aber diesbezüglich sehr offen. Und es "besitzt" unglaublich wichtige Schlüssel. Ihre Root Key Signing Key-Zeremonien werden per Video aufgezeichnet und die Videos werden online veröffentlicht, um Vertrauen in die Öffentlichkeit aufzubauen. HSMs werden in einem Safe gespeichert und nur mit ziemlich vertrauenswürdigen Geräten verbunden (einem schreibgeschützten Betriebssystem auf einem Computer, der auch in einem Safe gespeichert ist). Das Signieren eines Schlüssels dauert ungefähr 3 Stunden, da viele Schritte erforderlich sind, um die Daten einer Signaturanforderung, die ursprünglich auf einem USB-Stick gespeichert war, sicher zum HSM zu bringen und dann die signierten Daten wieder auf den USB-Stick zu übertragen. Schließlich erfordert der Prozess die physische Anwesenheit mehrerer Menschen, die sich nicht vertrauen sollten.

@CaffeineAddiction Danke. Ich spreche speziell über wichtige Schlüssel wie Verschlüsselungsschlüssel, Root-Passwörter usw. Wer behält sie? der CEO / CTO und einige vertrauenswürdige Mitarbeiter?

Es hängt davon ab, wer Zugriff benötigt und welche Hierarchie im Unternehmen vorhanden ist. Größere Unternehmen haben normalerweise mehrere Abteilungen, die aus mehreren Teams bestehen. Und nicht alle Mitarbeiter in jeder Abteilung benötigen dieselbe Art von Zugriff.

Es gibt mehrere Lösungen zum Speichern von Geheimnissen und zum Verwalten des Zugriffs auf diese. Ich werde eines hervorheben, mit dem ich am besten vertraut bin: HashiCorp Vault:

Sichern, speichern und kontrollieren Sie den Zugriff auf Token, Kennwörter, Zertifikate und Verschlüsselungsschlüssel zum Schutz von Geheimnissen und andere vertrauliche Daten, die eine Benutzeroberfläche, eine CLI oder eine HTTP-API verwenden.

Ich habe in der Vergangenheit auch persönlich eine Kombination von Festplatten- und Dateiverschlüsselungstechniken verwendet, um den Zugriff auf diese zu sichern, z. dm-crypt und gpg .

Technische Lösungen sind zwar großartig, aber in der Realität nutzen sie viele Unternehmen nicht. Und oft ist es eine Frage der Trägheit.

Ich habe in einer Vielzahl von Unternehmen gearbeitet, von winzigen 2-Personen-Startups bis hin zu massiven multinationalen FTSE-100-Unternehmen. Was Sie feststellen werden, ist, dass kleine, agile Unternehmen in Bezug auf technologische Lösungen in der Regel großen etablierten multinationalen Unternehmen weit voraus sind.

Die unglückliche Realität ist, dass viele große Unternehmen immer noch gemeinsame Tabellen mit Passwörtern verwenden. Viele verlassen sich immer noch auf das Gedächtnis der Menschen. In meiner derzeitigen Rolle als Mid-Senior-Management in einem großen multinationalen Unternehmen bin ich beispielsweise für Systeme verantwortlich und habe Zugang zu diesen Systemen, bei deren Missbrauch ein Unternehmen mit mehreren Milliarden Pfund vollständig zum Erliegen kommen könnte. Einige von diesen verwenden SSO und authentifizieren sich gegenüber dem LDAP des Unternehmens. Einige verlassen sich jedoch auf den gemeinsamen Zugriff, d. H. Ein Login, das von mehreren Personen gemeinsam genutzt wird. Als ich in dieser Rolle anfing, wurde mir mündlich mitgeteilt, dass ich den Benutzernamen / das Passwort nicht aufschreiben oder mit anderen teilen soll.

Seit meinem Beitritt habe ich nach Lösungen für die Verwaltung von Tresoren und Passwörtern gesucht solche Aufgaben. Leider ist die Mauer, die ich getroffen habe, unser Äquivalent zu CTO (offizieller Titel ist anders, aber hier irrelevant), der unerbittlich gegen elektronische Passwortmanager oder Tresore ist (sein Argument: "Ich vertraue ihnen nicht, bringe sie nicht mit." das wieder auf "). Daher fahren wir mit Tabellenkalkulationen für viele der Kennwörter fort.

Die spezifische Lösung, auf die ich drängen wollte, war die lokale Installation eines bekannten Open-Source-Kennwortmanagers (wird hier nicht genannt). Benutzer können Kennwörter hinzufügen und diese für andere Benutzer in derselben Installation freigeben. Auf diese Weise ist kein einziges Passwort zu merken. Freigegebene Kennwörter werden in einem namenlosen Konto gespeichert und mit anderen Benutzern geteilt, die sie benötigen.

Ausgezeichnete Frage!

Haftungsausschluss: Ich habe für große Technologieunternehmen gearbeitet, und diese Antwort basiert darauf. Es werden keine unternehmensspezifischen oder proprietären Techniken offenbart.

Authentifizierung von Personen

Ich wette, Facebook, Google, Twitter und andere Super-Big-Tech-Unternehmen Verwenden Sie solche Dienste von Drittanbietern nicht für ihre internen Kennwörter.

Tatsächlich verwenden zumindest einige Kennwortmanager von Drittanbietern - für Mitarbeiter und unkritische Dienste . Aufgrund der Art des Geschäfts müssen Mitarbeiter häufig mit Websites Dritter interagieren (Mitarbeiterinformationsmanagement, Reisebuchung, Mitarbeiterkreditkarten usw.). Beachten Sie, dass dies individuelle Anmeldeinformationen sind - sie authentifizieren eine Person, keine Ressource oder keinen Prozess.

Der größte der Dienste unterstützt SSO (Single Sign-On) von der Firma zur Verfügung gestellt. SSO ist viel sicherer, aber nicht alle Anbieter werden es unterstützen.

Eine andere in den meisten großen Technologieunternehmen angewandte Praxis ist die Verwendung von Sicherheitsschlüsseln für die Zwei-Faktor-Authentifizierung mit U2F / FIDO oder in jüngerer Zeit WebAuthn / FIDO2

TOTP (" Google Authenticator") ist ebenfalls üblich, jedoch anfälliger für MITM-Angriffe.

Ressourcen und Prozesse authentifizieren

Wie kann ein sehr großes Unternehmen einige der sensibelsten Passwörter der Welt verwalten? (Beispiel: Root-Zugriffskennwort für das Google Mail-Team!)

Das "Root-Kennwort für das Google Mail-Team" gibt es nicht. Seine Existenz wäre eine große Bedrohung für die Privatsphäre von Benutzerdaten - und damit auch für das Unternehmen.

Hier gibt es einen subtilen Unterschied zu Ihrem letzten Fall. Wir authentifizieren keine Personen - wir authentifizieren Ressourcen und Prozesse.

In diesen Fällen ist es normalerweise nicht erforderlich oder vorteilhaft, ein Kennwort zu verwenden, aber sie werden weiterhin verwendet Bequemlichkeit, einfache Implementierung oder weil es keine andere Alternative gibt.

Lassen Sie uns einige Szenarien durchgehen, die von Beispielen aus der Praxis bei großen Technologieunternehmen inspiriert wurden. :

Der 8-stellige Pin des Safes mit dem Kabel, das Sie verbindet zum Rechenzentrum

Dieser Safe kann ein Kabel

Risikomanagement und rollenbasierte Zugriffskontrolle (RBAC)

OP fragt nach technologischen Lösungen für das, was letztendlich ein Problem im Zusammenhang mit dem Risiko darstellt. Andere Antworten bieten eine gute Auswahl der Arten verfügbarer Tools (z. B. 1Password, Hashicorp Vault usw.), aber ich möchte die zugrunde liegende Frage der Risiken ansprechen. Das wird bestimmen, welche der vielen Optionen am sinnvollsten ist. Es gibt keine einheitliche Antwort, da verschiedene Unternehmen unterschiedliche Bedrohungsmodelle haben und unterschiedlichen Risikoquellen ausgesetzt sind.

OP fragt grundsätzlich nach dem Risiko von:

• Einziger Controller des Geheimnisses geht schief oder ist nicht verfügbar.
• Einer von vielen Controllern leckt das Geheimnis oder geht nicht.

Das übliche Maß für das Risiko ist die Wahrscheinlichkeit eines Verlusts x Wert des Verlustes. Zum Beispiel haben Sie eine 1% ige Chance, 1 Million Dollar pro Jahr an $ BAD_THING zu verlieren. Wenn Sie eine Versicherung für weniger als 10.000 US-Dollar gegen diesen Verlust abschließen können, lohnt es sich, dies zu tun. Sie bewerten Ihr Risiko und stellen es sicher. Wenn die Versicherung zu teuer ist und Sie sich dafür entscheiden, nichts zu tun und hoffen, dass Sie Glück haben, akzeptieren Sie das Risiko. Wenn Sie Richtlinien und Kontrollen einrichten, um das Auftreten von $ BAD_THING zu verhindern, verringern Sie das Risiko.

Unternehmen bewerten das Verlustpotenzial des Verlusts (oder Diebstahls) ihrer Kryptoschlüssel und legen einen Preis für dieses Ereignis fest und suchen Sie dann nach Steuerelementen, um die Kosten zu bewerten.

Mit "Viele Steuerelemente" der Schlüssel kann das Unternehmen ein Risiko gegen ein anderes austauschen, was möglicherweise schmackhafter ist. Ein einzelner Controller wird von einem Bus getroffen, und der einzige Schlüssel, der dem Unternehmen verweigert wird, ist eine ziemlich große existenzielle Bedrohung, wenn alles von diesem einen Schlüssel / Controller abhängt. Sie geben dem Controller also Zugriff auf mehrere Personen. Jetzt verlieren Sie nicht den Zugriff auf den Schlüssel, sondern erhöhen die Wahrscheinlichkeit, dass Sie "Schurke" werden. Wie wahrscheinlich ist das? Wähle eine Nummer. 1% Chance pro Mitarbeiter mit Zugang pro Jahr? Sie können jetzt modellieren, wie viele Personen zu einem bestimmten Zeitpunkt Zugriff haben sollen.

Dies führt Sie zu RBAC. "Jane the CTO" sollte niemals persönlichen Zugriff auf SuperSecret haben. Sie ist jedoch möglicherweise das einzige vertrauenswürdige Mitglied der Gruppe SecretAdmins. Diese Gruppe hat Zugriff auf das SuperSecret, aber die Mitgliedschaft in dieser Gruppe ist dynamisch, kann geprüft und nach Bedarf geändert werden.

Dies gibt dem Unternehmen die Möglichkeit, den Risikoappetit anzupassen und konkurrierende Interessen gegen verschiedene Quellen abzuwägen des Risikos.

Die spezifische Technologie ist fast irrelevant. Der wichtige Teil ist, dass das Design der Geheimkontrolle dem Risikoprofil entspricht.

Die sensibelsten Schlüssel sollten generiert und auf Hardware Security Modules (HSMs) gespeichert werden und dürfen niemals verlassen werden. Sicherheit wird dann zu einem physischen Zugriff auf das HSM selbst sowie zu einer Möglichkeit, das Widerrufen des Schlüssels zu verwalten, wenn das Gerät gestohlen wurde. Das offensichtlichste Beispiel dafür ist die Verwaltung der privaten Schlüssel für Webserver-TLS-Zertifikate. Wenn der HSM kaputt geht, erhalten Sie nur ein neues Zertifikat. Wenn es gestohlen wird, widerrufen Sie das Zertifikat.

Für den Fall, dass der Verlust des Schlüssels ein erhebliches Problem darstellt, besteht die Hauptidee darin, den Schlüssel in einem oder mehreren HSMs zu speichern und ihn nur zum Verschlüsseln anderer zu verwenden Schlüssel (Sie speichern die verschlüsselten Schlüssel sicher irgendwo, aber es ist nicht das Ende der Welt, wenn die verschlüsselten Schlüssel gestohlen werden), die Art und Weise, wie TLS-Stammzertifikate zum Signieren von Zwischenzertifikaten verwendet werden, und diese Schlüssel verschlüsseln dann andere und diese anderen Schlüssel Schlüssel sind weniger wertvoll und leicht zu ersetzen, und sie werden für etwas anderes als das Verschlüsseln von Schlüsseln verwendet. Mit der Kryptografie mit öffentlichen Schlüsseln ist dies viel, viel einfacher als früher mit nur symmetrischen Schlüsseln.

Der Hauptschlüssel wird aufgeteilt und verteilt, aber wie damit umgegangen wird, ist für jedes Unternehmen spezifisch. Sie können separate HSMs verwenden, um separate Schlüssel zu generieren und zu speichern und diese dann einfach durch Verkettung zum Hauptschlüssel zu kombinieren. Oder Sie können sie zusammen XOR. In vielen Fällen wird es als ausreichend angesehen, nur den Schlüssel in zwei Teile zu teilen. Jeder Schlüssel, den ich persönlich kenne, außer den Stammschlüsseln der TLS Certificate Authority, wurde nur in zwei oder drei Teile aufgeteilt, entweder durch Schneiden des Schlüssels in Stücke oder durch XOR-Verknüpfung des Schlüssels mit Zufallszahlen. Ich würde hoffen, dass die Leute Shamirs geheimes Teilen jetzt in größerem Umfang nutzen, aber ich weiß es nicht.

Der Schlüsselteil kann auf einem HSM, einem USB-Stick oder Normalpapier gespeichert werden. Es kann in einem Tresor oder einem sicheren Schrank in einer sicheren Einrichtung aufbewahrt werden (zum Beispiel ist die Art von Gebäude, in dem Banken Überweisungen verarbeiten, sicher genug, dass ein verschlossener Schrank in einem verschlossenen Raum in einem solchen Gebäude als sicher genug angesehen werden kann, um einen zu halten Schlüsselteil, wenn sich kein anderer Teil des Schlüssels im selben Gebäude befand). Oder es kann in der Brieftasche des CEO gespeichert werden.

Bei einem verteilten Schlüssel ist es wichtig, sicherzustellen, dass Diebstahl eines Teils erkannt wird, damit der Schlüssel geändert werden kann. Auf einigen Systemen sind bereits Primär- und Sekundärschlüssel bereitgestellt, sodass der Primärschlüssel im Notfall widerrufen werden kann, ohne dass zuerst ein neuer Schlüssel bereitgestellt oder installiert werden muss. So kann der CEO seinen Anteil in seiner Brieftasche behalten, damit er im Falle einer Entführung keine Probleme hat, ihn zu übergeben, anstatt zu versuchen, das zu ertragen, was die Entführer für die Ausübung von Druck im Sinn haben. Sicherheit ist immer eine Reihe von Kompromissen.

Ein erneuter Besuch lohnt sich der RSA-Hack von 2011. Die Tatsache, dass ihre privaten Token-Schlüssel (oder Seeds, die mit einem rückentwickelten Algorithmus in Schlüssel umgewandelt werden können) nicht physisch getrennt gehalten wurden, war für viele von uns ein Schock. Zu der Zeit hatte ich mehr Vertrauen, dass ich, nachdem ich in meinem mit RSA 2FA-Token gesicherten Unternehmenskonto angemeldet war, wirklich in einem sicheren Tunnel arbeitete.

Na ja, soviel dazu.

Mein Arbeitgeber hat offenbar ähnliche Bedenken, da er US-Mitarbeitern jetzt den Zugang von außerhalb der USA ohne größere Genehmigungen von vielen Ebenen aus untersagt. Es ist jetzt eine schwere Straftat, ein firmeneigenes verschlüsseltes Gerät nur außer Landes zu bringen, geschweige denn einzuschalten. (Dies hat die Expats und Mitarbeiter mit Migrationshintergrund verwüstet, die für einige Wochen zurückkehren könnten, um ihre Familie im Herkunftsland zu besuchen.)

Nach dem, was ich in den Fachmedien sehe, nehmen Unternehmen die Notwendigkeit ernst luft- (und stahlsichere), vollständig getrennte, physisch gesicherte Schlüsselaufbewahrung. Man kann hoffen, dass Maßnahmen wie die für die DNSSEC Root Signing Ceremony ergriffenen Beispiele ein Beispiel sind. Wir sind weit von den Tagen entfernt, als Jon Postel DNS übernehmen konnte, nur um einen Punkt zu verdeutlichen. (Oder sind wir?)

Aber ich wette, Facebook, Google, Twitter und andere große Technologieunternehmen verwenden solche Dienste von Drittanbietern nicht für ihre internen Passwörter und haben ihre eigenen Passwortmanager für ihre kritischsten Passwörter.

Lustig, dass Sie Twitter erwähnen. Berichten zufolge:

Hacker haben gegen Slack-Konten von Mitarbeitern verstoßen und Anmeldeinformationen für das Twitter-Backend gefunden, die in einem Slack-Kanal angeheftet sind.

Wenn dies der Fall ist ist wahr, es bedeutet, dass ziemlich wichtige Passwörter, die es ermöglichen, sich als Benutzer auszugeben, nur an einer Tafel angeheftet sind, auf die Mitarbeiter zugreifen können.

Mir sind (nicht so große) Unternehmen bekannt, die alle speichern Master-Passwörter in einem Google Sheet oder einer Textdatei. Die beste Vorgehensweise, die ich jemals im wirklichen Leben gesehen habe, ist eine gemeinsam genutzte KeePass-Datei.

Die meisten großen Kunden, mit denen ich zusammengearbeitet habe - einige mit mehr als 20.000 Unix-Hosts - vertrauen einfach keinen eigenen Passwörtern. Denken Sie an große Finanz-, Energie- und andere stark regulierte Branchen.

Sie verwenden ein Produkt wie "Powertech BoKS", um den Zugriff zu steuern, indem sie die Authentifizierung von der Autorisierung trennen. Zum Beispiel spielt es keine Rolle, ob Sie das Root-Passwort (Authentifizierung) kennen, wenn Sie keine Regel (Autorisierung) haben, mit der Sie es verwenden können. Und ja, dazu gehört auch die Konsole!

Die Integration von Token und eine starke Zugriffskontrolle ist wahrscheinlich die erste Methode zur Sicherung dieser großen Umgebungen. Sie verlassen sich nicht nur auf Kennwortkenntnisse, um den Zugriff zu bestimmen.

Beispiel: Der Zugriff auf einen Server (über SSH, Telnet, FTP, x usw.) ist nur für bestimmte Benutzer zulässig ... auch wenn viele vorhanden sind Benutzer haben Konten auf einem Host, einige dürfen möglicherweise SSH verwenden, einige dürfen SCP verwenden und andere dürfen FTP verwenden. Darüber hinaus dürfen sie nur aus identifizierten bekannten Quellen stammen.

Ein Systemadministrator kann sich möglicherweise mit seinem persönlichen Benutzernamen-Passwort bei einem Host anmelden. Um jedoch zum Root-Konto zu wechseln, er muss 2FA verwenden. Und ... selbst wenn er eine gültige 2FA-Antwort hat, muss er die Erlaubnis haben, zu root zu wechseln, oder der Zugriff wird verweigert. Der Administrator kennt das Root-Passwort nicht.

Viele dieser Unternehmen beschränken die Verwendung des Root-Kontos außerdem auf bestimmte Zeitfenster. Dies bedeutet, dass selbst wenn der Systemadministrator das Root-Passwort kennt oder eine gültige 2FA-Antwort hat, um Root zu werden, sein Zugriff verweigert wird, wenn er versucht, einen solchen Zugriff außerhalb eines Änderungssteuerungsfensters zu erhalten.

Die Der Administrator muss auch von einem bekannten Host oder Netzwerk stammen ... dh. Die Verbindung kann nicht von der DMZ stammen oder ist nur zulässig, wenn sie von einem bestimmten Jump-Host stammt.

Diese Art strenger Kontrollen ist der Schlüssel zur Sicherung dieser großen Organisationen.

Was das eigentliche Root-Passwort betrifft ... weil wir alle wissen, dass irgendwann jemand es brauchen wird ... Die Root-Passwörter werden normalerweise in einem Tresor verschlüsselt. Ein Systemadministrator kann das Root-Passwort im Notfall "auschecken". Beachten Sie, dass die Möglichkeit, dieses Passwort zu überprüfen, ebenfalls streng kontrolliert wird. In den meisten Fällen kann der Administrator es nicht auschecken, es sei denn, er verfügt über eine Regel, die ihm Zugriff auf das Tresorsystem selbst gewährt, und eine Regel, die das Auschecken des bestimmten Root-Kennworts für einen bestimmten Host ermöglicht. Er müsste auch seine 2FA verwenden, um zunächst auf den Tresor zuzugreifen. In einigen fortgeschritteneren Implementierungen kann er das Kennwort nicht auschecken, ohne die Kasse an ein gültiges Ticket für die Änderungskontrolle zu binden. Nach dem Auschecken wählt der Tresor automatisch ein neues Kennwort für das Root-Konto aus.

Diese Konzepte gelten für viele große Unternehmen, gelten jedoch auch für Unternehmen mit nur 25 Unix-Hosts. Es ist nicht so sehr ein Faktor dafür, wie groß das Unternehmen ist oder wie viele Server sie haben, sondern wie sensibel sie ihre Daten betrachten. Selbst kleine Unternehmen können an regulatorische Anforderungen gebunden sein, die sie erfüllen müssen.