Statische Anmeldedaten sind für KI immer noch der einfachste Zugang

KI hat die überprivilegierte Anmeldeinformation nicht erfunden, sie hat nur den schnellsten Weg gefunden, eine zu verwenden. Jeder Agent, jedes Skript und jede Integration in Ihrer Umgebung authentifiziert sich mit etwas, und in den meisten Umgebungen ist dieses Etwas ein Passwort, ein API-Schlüssel oder ein einmal ausgestelltes und nie wieder berührtes Token. Eine Person vergisst ein Passwort und wird schließlich ausgesperrt. Eine Maschinenidentität verwendet einfach weiter, was ihr gegeben wurde, solange niemand zusieht.

Mehr Identitäten, mehr Verstöße

Wir haben in diesem Jahr 2.317 Sicherheits- und IT-Leiter befragt, und die klarste Zahl in den Ergebnissen war diese: Organisationen, bei denen KI die Anzahl der Identitäten in ihrer Umgebung erheblich erhöht hat, berichteten über die letzten 12 Monate von einer Verletzungsrate von 43 %. Organisationen, bei denen sich die Identitätsanzahl durch KI kaum verändert hat, berichteten von 11 %. Das ist ein 4-facher Unterschied, und es liegt nicht daran, dass die KI-starke Gruppe insgesamt eine schwächere Sicherheit hatte. Unsere Daten zeigen, dass sie bei den meisten Grundlagen voraus waren.

Wo sie nicht voraus waren, war nicht-menschliche Identität Governance. Sechsundsiebzig Prozent der Organisationen sagten uns, dass sie ihre nicht-menschlichen Identitäten nicht vollständig verwalten oder überwachen, und nur 19 % sagten, dass sie es tun. Das ist die Population, durch die KI läuft: eine wachsende Anzahl von Maschinenidentitäten, von denen sich die meisten mit einem Nachweis authentifizieren, den seit dem Tag seiner Ausstellung niemand mehr überprüft hat.

Statische Anmeldeinformationen

Eine statische Anmeldeinformation läuft nicht von selbst ab, wird nicht automatisch gewechselt und ist egal, wie oft sie verwendet wird. Das macht sie gefährlich, sobald sie in etwas Automatisiertem steckt. Eine Person, die ein gestohlenes Passwort verwendet, wird irgendwann bemerkt. Ein KI-Agent oder Skript, das eine gestohlene Anmeldeinformation verwendet, läuft einfach weiter, mit der Geschwindigkeit, die der Arbeitsablauf erlaubt, bis es jemand findet.

Schritte zur Sicherung der NHI-Zugangsdaten

1. Gewölbe

Der erste Schritt besteht darin, Zugangsdaten aus Skripten, Konfigurationsdateien, Tabellenkalkulationen und Quellcode herauszuholen und in ein System zu überführen, das für deren Speicherung entwickelt wurde. Das klingt einfach und ist es selten. Ein Tresor muss über strategische und Altsystem-Anwendungen hinweg funktionieren, unterschiedliche Zugriffsmuster abdecken, je nachdem, wie jede App mit einer Zugangsdaten kommuniziert, und sowohl zentralisiertes Onboarding als auch die Realität unterstützen, dass einige Teams Zugangsdaten immer manuell hinzufügen. In der Praxis bedeutet das eine mehrstufige Architektur: eine Präsentationsschicht für Benutzer, einen Anwendungsserver, der Geschäftslogik und Berechtigungen durchsetzt, und eine Datenbankschicht, die die Geheimnisse tatsächlich speichert, mit der Option, mehrere Anwendungsserver zu skalieren, um die Last auf geografisch verteilte Teams zu verteilen. Das Vaulting ist auch der Schritt, der sich am schnellsten auszahlt, da es den Unterschied zwischen einer Zugangsdaten, die jeder finden kann, und einer, die tatsächlich kontrolliert wird, ausmacht.

2. Verschlüsselung

Sobald eine Anmeldeinformation in einem Tresor ist, muss sie verschlüsselt bleiben, wobei die Verschlüsselungsschlüssel genauso sorgfältig verwaltet werden wie die Anmeldeinformationen selbst. Das bedeutet mehr, als einfach AES einzuschalten und es für erledigt zu halten. Ein richtig gebauter Tresor sollte für die Anmeldeinformationen selbst eine authentifizierte Verschlüsselung (AES-GCM 256), starke Schlüsselableitungsfunktionen mit hoher Iterationszahl für Benutzer- und Schlüssel-Hashes sowie elliptische Kurven-Kryptographie für den öffentlichen-privaten Schlüsselaustausch verwenden. Jeder geheime Container sollte sein eigenes zufällig generiertes Salt tragen, und jedes Passwort, jeder Benutzer und jede Rolle sollte ein eigenes Schlüsselpaar haben, sodass der Zugriff hierarchisch verschlüsselt ist und nicht durch einen einzigen gemeinsamen Schlüssel gesteuert wird. Für Umgebungen, die mit Active Directory synchronisieren, sollte ein Ende-zu-Ende-Verschlüsselungsmodus verfügbar sein, bei dem der Server selbst niemals Zugriff auf den Klartext hat, als stärkste Option neben einem Master-Key-Modus für Organisationen, die eine zentrale Wiederherstellung benötigen. Der Master-Schlüssel selbst gehört in Hardware, nicht in eine Konfigurationsdatei, geschützt durch ein HSM. Ein Passwort von Klartext in einen so gebauten verschlüsselten Tresor zu verschieben, ist der häufigste Weg, wie Organisationen das Risiko von Anmeldeinformationen reduzieren, und es ist der Schritt, der Teams, die sich noch nicht mit NHI-Sicherheit beschäftigt haben, am meisten zugänglich ist.

3. Radfahren und Rotation

Das regelmäßige Rotieren von Zugangsdaten verringert das Risiko im Zusammenhang mit ausgeschiedenen Mitarbeitern, bereinigt die Exposition in altem Code und Skripten und deckt oft Abhängigkeiten auf, von denen niemand wusste. Es ist auch der schwierigste Schritt in der Umsetzung. Wenn Sie nicht jedes Skript und jede Integration kennen, die auf eine bestimmte Zugangsdaten angewiesen ist, kann das Rotieren die Produktion unterbrechen, anstatt das Risiko zu verringern.

Rotation funktioniert nur als fortlaufender, automatisierter Prozess, der eng an den Tresor gebunden ist, der die Anmeldeinformationen enthält, und nicht als manuelle Aufgabe, an die sich jemand erinnert. Das bedeutet auslösungsbasierte Zurücksetzungen, keine Kalendererinnerungen: Setzen Sie eine Anmeldeinformation eine bestimmte Anzahl von Minuten nach dem Anzeigen zurück, nachdem sie für eine definierte Anzahl von Tagen unverändert geblieben ist, oder sobald sie abgelaufen ist. Es bedeutet auch, dass der Prozess sich selbst schützen muss. Wenn ein skriptgesteuertes Zurücksetzen mitten im Prozess fehlschlägt, bei einem Active Directory-Konto, einem lokalen Windows- oder Linux-Benutzer oder einem Dienstkonto, sollte das System die Anmeldeinformation automatisch auf den zuletzt bekannten guten Wert zurücksetzen und den Fehler protokollieren, anstatt ein Dienstkonto in einem beschädigten halbveränderten Zustand zu belassen. Jede Zurücksetzung, Rückrolle und Blockierung wird aufgezeichnet, sodass eine fehlgeschlagene Rotation sofort sichtbar ist, anstatt drei Wochen später als Ausfall aufzutreten, den niemand erklären kann.

Die meisten Organisationen, die echte Fortschritte machen, beherrschen zuerst Vaulting und Verschlüsselung und bauen dann auf eine automatisierte, triggerbasierte Rotation auf, sobald sie ihre Abhängigkeiten gut genug verstehen, um sie sicher zu konfigurieren.

Lernen Sie Password Secure kennen

Jedes Dienstkonto und Anwendungskonto, das mit Active Directory verbunden ist, läuft durch dieselbe Richtlinien-Engine wie Ihre Mitarbeiter, egal ob jemand sie durchsetzt oder nicht.Netwrix Password Secure deckt alle drei Schritte direkt ab.

Es bietet Ihnen einen einzigen verschlüsselten Tresor für Benutzer-, Administrator- und Service-Anmeldeinformationen, mit FIPS-konformer Kryptographie (AES-GCM 256, PBKDF2-gehärtete Schlüsselableitung und NIST P-521 elliptischer Kurven-Schlüsselaustausch), die jedes Geheimnis schützt. Rollenbasierter Zugriff bedeutet, dass nur die Personen und Prozesse, die eine Anmeldeinformation benötigen, darauf zugreifen können, und ein vollständiges Protokollbuch zeichnet jeden Auscheckvorgang, Reset und Rollback auf, sodass Sie nachvollziehen können, wer wann eine bestimmte Anmeldeinformation verwendet hat. Darüber hinaus übernimmt die konfigurierbare, triggerbasierte Passwortzurücksetzung die Rotation: Anmeldeinformationen werden automatisch nach Zeitplan oder bei definierten Bedingungen zurückgesetzt, mit Rollback-Schutz, falls ein Zielsystem die Änderung ablehnt.

Das ist der Unterschied zwischen einem Servicekonto-Passwort, das unbegrenzt in einer Tabelle lebt, nie rotiert wird, weil niemand das Risiko eingehen will, etwas zu beschädigen, und einem Passwort, das an einem Ort gespeichert ist, an dem es verschlüsselt, zugriffskontrolliert, protokolliert und nach einem Zeitplan rotiert wird, den die Organisation tatsächlich kontrolliert.