-
Technisches Gebiet
-
Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Verfahren zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerkes und auf ein Verfahren zum Zugreifen auf einen Service in einem Netzwerk.
-
Hintergrund
-
Innerhalb eines Netzwerkes von Computern oder digitalen Geräten werden häufig unterschiedliche Services bzw. Funktionalitäten von mehreren Benutzern oder Clients gleichzeitig oder konkurrierend genutzt. Beispiele für solche Services oder Dienste sind der Zugriff auf Speicher, der Zugriff auf Drucker, Zugriff auf einen SMTP-Service oder dergleichen. Beispiele für Protokolle, über die ein Zugriff auf solche Services abgewickelt wird, sind Server Message Block (SMB) oder Common Internet File System (CIFS). Um einen von einem Host-Rechner oder allgemein von einer anderen Identität im Netzwerk angebotenen Service nutzen zu können, ist es meist erforderlich, dass sich der Benutzer gegenüber dem Anbieter des Service authentifiziert bzw. als zur Nutzung des Service berechtigt ausweist. Eine bekannte Möglichkeit der Authentifizierung bzw. des Nachweises der Berechtigung ist die Eingabe eines Benutzernamens und eines dazugehörigen Passworts, so dass der Anbieter des Service prüfen kann, ob das eingegebene Passwort zu dem im Netzwerk für den Benutzernamen hinterlegten Passwort passt, um dann den Zugriff auf den angebotenen Service zu gewähren.
-
Um nicht bei jedem Dateizugriff bzw. bei jedem Druckauftrag eine derartige zeitaufwendige Benutzerauthentifizierung durchführen zu müssen, haben sich Single-Sign-On-Authentifizierungsverfahren (SSO) etabliert, bei denen ein Benutzer lediglich einmal den Authentifizierungsmechanismus durchlaufen muss, wohingegen nachfolgende Authentifizierungen gegenüber den Services im Netzwerk automatisch erfolgen und dabei auf Datensätzen basieren, die eine Berechtigung des Benutzers anzeigen, auf zumindest einen Service zuzugreifen. Bei SSO-Verfahren authentifiziert sich ein Client oder Benutzer zunächst gegenüber einem SSO-Authentifizierungsdienst, der weiterhin als SAS bezeichnet wird. Die Authentifizierung gegenüber dem SAS kann durch verschiedene Authentifizierungsverfahren erfolgen, beispielsweise durch die bereits genannte Kombination aus Benutzernamen und Passwort, mittels einer Smartcard, oder über andere Authentifizierungsverfahren. Nach einer erfolgreichen Authentifizierung (im Folgenden auch als SAS AuthN bezeichnet), steht dem Client ein Authentifizierungstoken für die im Netzwerk verfügbaren Services zur Verfügung. Dieses wird folgend auch als Service-Authentifizierungs-Token (SAT) bezeichnet. Allgemein kann ein Service-Authentifizierungs-Token als ein Datensatz bezeichnet werden, das eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen. Die konkrete Information, die in dem Datensatz enthalten ist, kann sich unterscheiden. Bei einigen Authentifizierungsverfahren, wie beispielsweise LAN Manager (LM) LM oder NT LAN Manager (NTLM) enthalten die Datensätze einen Hash-Wert oder einen von dem Hash-Wert abgeleitete Information. Der Hash-Wert wird aus einem bei der Anmeldung eingegebenen Passwort oder aus Zufallszahlen erzeugt.
-
Andere Verfahren, wie beispielsweise Kerberos, können auf einem Datensatz basieren, dessen Inhalt verschlüsselt ist. Bei Kerberos umfasst beispielsweise ein Ticket-Granting-Ticket (TGT) genannter Datensatz, der verwendet wird, um sogenannte Service-Tickets zum Nutzen eines Services im Netzwerk zu erhalten, beispielsweise einen Sitzungsschlüssel zur verschlüsselten Kommunikation mit einem autorisierenden Server sowie die User-ID desjenigen Benutzers, der die Berechtigung zum Nutzen von Services im Netzwerk besitzt. Bei Kerberos ist die Information innerhalb des Datensatzes ferner mit dem Schlüssel des autorisierenden Servers, des sogenannten Key Distribution Centers (KDC), verschlüsselt.
-
Unabhängig von der konkreten Art der in dem Datensatz, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen, enthaltenen Information, ist der Client bzw. Benutzer nach der erfolgreichen Erstauthentifizierung (SAS AuthN) im Besitz eines Datensatzes bzw. Service-Authentifizierungs-Tokens, der den Zugriff auf die im Netzwerk verfügbaren Services ermöglicht. Der Datensatz wird in den nachfolgenden Abschnitten synonym auch mit Service-Authentifizierungs-Token (SAT) bezeichnet. Bei vielen Single-Sign-On-Verfahren ist der Datensatz bzw. der SAT, also der Zugriff auf den Service, nicht abgesichert. Wird dieser Datensatz von einem potentiellen Angreifer entwendet, kann er daher verwendet werden, um sich an Services bzw. deren bereitstellenden Servern innerhalb des Netzwerks unbefugt anzumelden, indem er sich durch die Verwendung des fremden Datensatzes die Rechte eines anderen tatsächlich berechtigten Benutzers verschafft. Wenngleich die konkrete Art eines möglichen Angriffs sich für die einzelnen verwendeten Protokolle unterscheiden mag, basiert die Berechtigung zur Nutzung eines Services oder Dienstes meist lediglich auf dem erzeugten Datensatz bzw. dem SAT, so dass sich ein Benutzer durch dessen Entwendung Zugriff auf Berechtigungen verschaffen kann, die diesem eigentlich nicht zustehen.
-
Die Anfälligkeit für derartige Angriffe ist unabhängig von der Sicherheit des ersten Authentifizierungsverfahrens, da auch nach einem besonders sicheren Verfahren beim Single-Sign-On ein Datensatz verwendet wird, um sich für weitere Services zu qualifizieren. Eine Zwei-Faktor-Authentifizierung, bei der beispielsweise Nutzername und Passwort sowie das Vorhandensein einer zusätzlichen Smartcard erforderlich ist, um sich zum ersten Mal zu authentifizieren (gegenüber dem SSO-Authentifizierungsdienst SAS) verringert also beispielsweise nicht dieses Sicherheitsrisiko. Beispielsweise kann also ein Nutzer, der sich bei der Erstauthentifizierung gegenüber dem SAS mit gültigen eigenen Benutzerdaten authentifiziert, danach basierend auf einem fremden Datensatz Services unter anderer Benutzerkennung benutzen bzw. sich so Zugang zu Services verschaffen, für die er über keine Berechtigung verfügt. Die Authentifizierungsdaten bei der Erstauthentifizierung und der darauf folgenden Authentifizierung gegenüber Services sind insoweit voneinander unabhängig. Die Service Authentifizierung setzt nicht einmal eine Erstauthentifizierung voraus, sofern ein Nutzer mit dem Netzwerk bereits verbunden ist. Somit könnte beispielsweise auch ein Angriff zunächst mit gestohlenen Erstauthentifizierungsdaten erfolgen, mit dem sich generell Zugriff zum Netzwerk verschafft wird. Die darauffolgenden Services könnten dann basierend auf den Datensätzen, die zu einem wiederum anderen Benutzer gehören, verwendet werden, um die Services mit der Berechtigung eines anderen Benutzers zu benutzen. Mit anderen Worten kann das Single-Sign-On mit einer anderen (gestohlenen) Identität durchgeführt werden, wie die Benutzung der Services im Anschluss an das Single-Sign-On, die mit der Berechtigung einer weiteren (gestohlenen) Identität genutzt werden könnten. Einige verwendete Betriebssysteme für Computer weisen diese Angriffsmöglichkeit seit vielen Jahren auf, die unter anderem als „Pass-The-Hash“-Angriff und als „Pass-The-Ticket“-Angriff bekannt sind.
-
Aus der Druckschrift
US 2009/0158394 A1 sind ein Super Peer basiertes Peer-to-Peer Netzwerk und ein Peer-Authentifizierungsverfahren bekannt.
-
Aus der Druckschrift
US 2006/0235796 A1 sind Protokolle und Rechensysteme bekannt, die eine Identifizierung und eine Zahlauthentifizierung ermöglichen, wobei ein mobiles Modul genutzt wird, das Einzel- oder Multistufen-Sicherheit über ein nicht-vertrautes Netzwerk herstellt.
-
Es besteht somit ein Bedürfnis, die Kontrolle des Zugriffs auf einen Service innerhalb eines Netzwerkes zu verbessern.
-
Zusammenfassung
-
Ausführungsbeispiele eines Verfahrens zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerks ermöglichen dies, indem, wenn ein Datensatz empfangen wird, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen, der berechtigte Benutzer identifiziert wird, für den der Datensatz erstellt wurde. Ferner wird überprüft, ob der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde oder ob dies nicht der Fall war. Ein Zugriff auf den Service wird nur dann gewährt oder ermöglicht, wenn der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde. Dies ermöglicht es, zu verhindern, dass nicht berechtigte Benutzer, die unberechtigt im Besitzt des Datensatzes gelangt sind, Services in fremden Namen nutzen können, was wiederum die oben beschriebene Sicherheitslücke schließt. Der Zugriff auf den Service wird verhindert, wenn der Datensatz nicht ausgehend von dem berechtigten Benutzer empfangen wurde.
-
Benutzer oder Clients innerhalb eines Netzwerkes erlangen durch Ausführungsbeispiele der vorliegenden Erfindung Zugriff auf einen Service innerhalb des Netzwerkes, indem diese zunächst einen Datensatz übermitteln, das für einen berechtigten Benutzer eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen. Im Falle eines berechtigten Zugriffs haben diese Benutzer den Datensatz bei einer ersten Authentifizierung selbst erhalten. Im Falle eines unberechtigten Zugriffs haben diese Benutzer den Datensatz bei einer ersten Authentifizierung selbst erzeugt. Weiterhin empfangen die Benutzer eine Aufforderung, eine die Identität des Benutzers anzeigende Antwort zu erstellen und übermitteln die dazugehörige Antwort, die die Identität des Benutzers anzeigt, um, bei korrekt beantworteter Aufforderung Zugriff auf den Service zu erhalten.
-
Figurenliste
-
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
- 1 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerkes;
- 2a ein Beispiel für einen Datensatz, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen;
- 2b ein weiteres Beispiel für einen Datensatz, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen;
- 3 ein Flussdiagramm eines Ausführungsbeispiels zum Erhalten eines Zugriffs auf einen Service innerhalb eines Netzwerkes;
- 4 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zum Zugreifen auf einen Service in einem Netzwerk;
- 5 ein Beispiel für eine Topologie eines Netzwerkes, in dem ein Ausführungsbeispiel gemäß 4 implementiert ist; und
- 6 eine schematische Darstellung einer Vorrichtung zum Kontrollieren eines Zugriffs auf einen Service.
-
Beschreibung
-
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
-
Bei der nachfolgenden Beschreibung der beigefügten Figuren, die lediglich einige exemplarische Ausführungsbeispiele zeigen, können gleiche Bezugszeichen gleiche oder vergleichbare Komponenten bezeichnen. Ferner können zusammenfassende Bezugszeichen für Komponenten und Objekte verwendet werden, die mehrfach in einem Ausführungsbeispiel oder in einer Zeichnung auftreten, jedoch hinsichtlich eines oder mehrerer Merkmale gemeinsam beschrieben werden. Komponenten oder Objekte, die mit gleichen oder zusammenfassenden Bezugszeichen beschrieben werden, können hinsichtlich einzelner, mehrerer oder aller Merkmale, beispielsweise ihrer Dimensionierungen, gleich, jedoch gegebenenfalls auch unterschiedlich ausgeführt sein, sofern sich aus der Beschreibung nicht etwas anderes explizit oder implizit ergibt.
-
Obwohl Ausführungsbeispiele auf verschiedene Weise modifiziert und abgeändert werden können, sind Ausführungsbeispiele in den Figuren als Beispiele dargestellt und werden hierin ausführlich beschrieben. Es sei jedoch klargestellt, dass nicht beabsichtigt ist, Ausführungsbeispiele auf die jeweils offenbarten Formen zu beschränken, sondern dass Ausführungsbeispiele vielmehr sämtliche funktionale und/oder strukturelle Modifikationen, Äquivalente und Alternativen, die im Bereich der Erfindung liegen, abdecken sollen. Gleiche Bezugszeichen bezeichnen in der gesamten Figurenbeschreibung gleiche oder ähnliche Elemente.
-
Man beachte, dass ein Element, das als mit einem anderen Element „verbunden“ oder „verkoppelt“ bezeichnet wird, mit dem anderen Element direkt verbunden oder verkoppelt sein kann oder dass dazwischenliegende Elemente vorhanden sein können. Wenn ein Element dagegen als „direkt verbunden“ oder „direkt verkoppelt“ mit einem anderen Element bezeichnet wird, sind keine dazwischenliegenden Elemente vorhanden. Andere Begriffe, die verwendet werden, um die Beziehung zwischen Elementen zu beschreiben, sollten auf ähnliche Weise interpretiert werden (z.B., „zwischen“ gegenüber „direkt dazwischen“, „angrenzend“ gegenüber „direkt angrenzend“ usw.).
-
Die Terminologie, die hierin verwendet wird, dient nur der Beschreibung bestimmter Ausführungsbeispiele und soll die Ausführungsbeispiele nicht beschränken. Wie hierin verwendet, sollen die Singularformen „einer,“ „eine“, „eines “ und „der, die, das“ auch die Pluralformen beinhalten, solange der Kontext nicht eindeutig etwas anderes angibt. Ferner sei klargestellt, dass die Ausdrücke wie z.B. „beinhaltet“, „beinhaltend“, aufweist“ und/oder „aufweisend“, wie hierin verwendet, das Vorhandensein von genannten Merkmalen, ganzen Zahlen, Schritten, Arbeitsabläufen, Elementen und/oder Komponenten angeben, aber das Vorhandensein oder die Hinzufügung von einem bzw. einer oder mehreren Merkmalen, ganzen Zahlen, Schritten, Arbeitsabläufen, Elementen, Komponenten und/oder Gruppen davon nicht ausschließen.
-
Solange nichts anderes definiert ist, haben sämtliche hierin verwendeten Begriffe (einschließlich von technischen und wissenschaftlichen Begriffen) die gleiche Bedeutung, die ihnen ein Durchschnittsfachmann auf dem Gebiet, zu dem die Ausführungsbeispiele gehören, beimisst. Ferner sei klargestellt, dass Ausdrücke, z.B. diejenigen, die in allgemein verwendeten Wörterbüchern definiert sind, so zu interpretieren sind, als hätten sie die Bedeutung, die mit ihrer Bedeutung im Kontext der einschlägigen Technik konsistent ist, und nicht in einem idealisierten oder übermäßig formalen Sinn zu interpretieren sind, solange dies hierin nicht ausdrücklich definiert ist.
-
1 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerks. Das Verfahren umfasst ein Empfangen 110 eines Datensatzes, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen. Das Verfahren umfasst ferner das Identifizieren eines berechtigten Benutzers 120, für den der Datensatz erstellt wurde. Während des Überprüfens 130, wird überprüft, ob der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde. Gewähren des Zugriffs auf den Service 140 erfolgt, wenn der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde.
-
1 zeigt ferner einen optionalen Schritt des aktiven Verhinderns des Zugriffs 150 auf den Service, wenn der Datensatz nicht ausgehend von dem berechtigten Benutzer empfangen wurde. Dieser aktive Schritt kann gemäß weiteren Ausführungsbeispielen auch entfallen, indem eine Antwort auf den empfangenen Datensatz an den sendenden Benutzer vollständig unterbleibt. Alternativ dazu kann, wie in 1 optional dargestellt, der Zugriff aktiv verhindert werden, indem beispielsweise die Datenverbindung des Benutzers aktiv beendet wird, beispielsweise indem eine zu einem Transportprotokoll korrespondierende Verbindung beendet wird, indem eine verschlüsselte Verbindung zu dem sendenden Benutzer des Datensatzes beendet wird oder dergleichen.
-
Gemäß einigen Ausführungsbeispielen wird bei dem Identifizieren eines berechtigten Benutzers eine Information, die den berechtigten Nutzer identifiziert, aus dem Datensatz selbst extrahiert. Dabei kann die Information, beispielsweise bei der Verwendung des NTLM Security Support Provider (NTLMSSP) oder des Kerberos-Protokolls, aus der Benutzerkennung (User-ID bzw. UID) selbst bestehen, die beispielsweise innerhalb eines TGT oder eines NTLMSSP Datensatzes gespeichert ist. Gemäß weiteren Ausführungsbeispielen muss es sich jedoch nicht um die Benutzerkennung handeln. Vielmehr können beliebige Informationen verwendet bzw. extrahiert werden, die eine eindeutige Zuordnung zu einem bestimmten Nutzer bzw. Client erlauben. Dabei kann die Information, die den berechtigten Nutzer identifiziert, auch aus Teilen des Datenprotokolls gewonnen werden, mit denen der Datensatz gesendet wird, beispielsweise aus Header-Informationen eines Transportprotokolls oder dergleichen. Die Information, die den berechtigten Nutzer identifiziert kann auch beliebigen anderen Metadaten gewonnen werden, beispielsweise einer Session ID oder einer IP Adresse. Gemäß einigen Ausführungsbeispielen wird zum Zweck der Identifizierung des berechtigten Benutzers der Datensatz mit einer Liste gespeicherter Datensätze verglichen, die eine Zuordnung der ursprünglich bei der Authentifizierung erzeugten Datensätze zu den sich authentifizierenden Benutzern umfasst. Der empfangene Datensatz könnte beispielsweise bitweise mit den Datensätzen der Liste verglichen werden, um bei einer Übereinstimmung den dem Datensatz in der Liste zugeordneten Benutzer als den berechtigen Benutzer zu identifizieren.
-
Wenn eine Information extrahiert bzw. erhalten ist, die eindeutig einem Benutzer bzw. einem Client zugeordnet werden kann, kann überprüft werden, ob der empfangene Datensatz tatsächlich von dem berechtigten Benutzer empfangen wurde oder möglicherweise von einem anderen Benutzer. Ein Benutzer in dem hierin verwendeten Sinne ist nicht notwendigerweise eine natürliche Person. Vielmehr ist als Benutzer jedwede Identität zu verstehen, die in der Lage ist, einen bestimmten Service zu nutzen, beispielsweise auch ein anderer Service. Ein Benutzer kann also einer natürlichen Person entsprechen, aber auch anderen Identitäten im Netzwerk, beispielsweise anderen Rechnern bzw. Clients oder Maschinen, oder aber auch Software-Modulen, die eine eigene, eine Identität definierende Funktionalität bereitstellen. Demgemäß ist als ein Netzwerk auch eine Ansammlung von Benutzern zu verstehen, die die Möglichkeit haben, innerhalb des Netzwerks miteinander zu kommunizieren. Dabei ist es unerheblich, wie die Kommunikation physikalisch erfolgt, diese kann beispielsweise schnurgebunden oder Drahtlos erfolgen, je nach Implementierung auch parallel. Auch die Art der verwendeten Kommunikationsprotokolle ist beliebig. Ebenso können beliebige Protokolle auf unterschiedlichen Ebenen des Protokoll- Stack Verwendung finden. Die unterschiedlichen Identitäten bzw. Benutzer oder Prozesse innerhalb eines Netzwerkes können unterschiedlichen oder auch derselben Hardware zugeordnet sein bzw. auf derselben Hardware ausgeführt werden, unter anderem auch auf demselben Prozessor. Ein Beispiel für ein Netzwerk ist die Gesamtheit der innerhalb einer gemeinsamen Domäne kommunizierenden Geräte, Services und Benutzer. Ebenso kann ein Datensatz jedwede Menge von Information in beliebiger Repräsentation sein, die es ermöglicht, eine Berechtigung anzuzeigen, auf einen Service zuzugreifen. Ein Datensatz kann somit unterschiedlichste logische Inhalte haben, in unterschiedlichen Repräsentierungen, beispielsweise als Binärcode oder als Hexadezimalcode. Ein Datensatz kann einem Datenpaket, das über das Netzwerk übertragen wird, entsprechen, oder auch nur einem Teil eines solche Datenpakets. Ferner kann der Datensatz auch mittels mehrerer Datenpakete innerhalb des Netzwerks übertragen werden. Der Datensatz kann aufgrund einer erfolgreichen vorhergehenden Authentifizierung eines Benutzers erstellt worden sein. Der Datensatz kann dazu geeignet sein, einem Benutzer ohne eine weitere Benutzerinteraktion Zugriff auf einen Service zu verschaffen.
-
In den nachfolgend beschriebenen Ausführungsbeispielen wird der Einfachheit halber überwiegend davon ausgegangen, dass es sich bei dem Benutzer um eine natürliche Person handelt, ohne dass dadurch die Anwendung von weiteren Ausführungsbeispielen der Erfindung auf andere Identitäten eingeschränkt werden soll.
-
Gemäß einigen Ausführungsbeispielen umfasst das Überprüfen, ob der Datensatz von dem berechtigten Benutzer empfangen wurde, ein Übermitteln einer Aufforderung an einen sendenden Benutzer, von dem der Datensatz empfangen wurde, seine Identität zu bestätigen. Das heißt, nachdem oder bevor der berechtigte Benutzer, für den der Datensatz erstellt wurde, identifiziert wurde, wird der sendende Benutzer, von dem der Datensatz empfangen wurde, aufgefordert, durch einen beliebigen Mechanismus seine Identität zu bestätigen, beispielsweise indem dieser eine erneute Authentifizierung durchführt. Sofern die Identität des sendenden Benutzers und die Identität des berechtigten Benutzers übereinstimmen, kann daraus geschlossen werden, dass der Datensatz von dem berechtigten Benutzer empfangen wurde.
-
Die Implementierung, gemäß der der sendende Benutzer seine Identität bestätigt, kann dabei frei gewählt werden. Beispielsweise kann ein Challenge- Response- Verfahren angewendet werden, bei dem an den sendenden Benutzer eine Aufgabe gestellt und an diesem übertragen wird, deren Lösung von einer die Benutzer innerhalb des Netzwerks eindeutig identifizierenden bzw. kennzeichnenden Information abhängt. Der sendende Benutzer löst die Aufgabe und die Lösung der Aufgabe wird von dem sendenden Benutzer empfangen. Stimmt die empfangene Lösung mit einer Kontrolllösung überein oder korrespondiert zu dieser, welche unter Verwendung der den berechtigten Benutzer identifizierenden Information bestimmt wurde, kann es als bestätigt gelten, dass der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde und folglich ein Zugriff auf den Service zu gewähren ist. Ein Beispiel für eine zu lösende Aufgaben durch den sendenden Benutzer wären beispielsweise das Signieren einer Zufallszahl mit der User-ID des sendenden Benutzers oder einer anderen, den sendenden Benutzer eindeutig identifizierenden Information. Wird als Kontrolllösung dieselbe Zufallszahl mit der extrahierten User-ID des berechtigten Benutzers verifiziert oder signiert und stimmen beide Lösungen überein, ist verifiziert, dass der sendende Benutzer der tatsächlich berechtigte Benutzer des Datensatzes ist. Gemäß anderen Ausführungsbeispielen kann sich die Information, die vom sendenden Benutzer zur Lösung der Aufgabe verwendet wird, von derjenigen Information, die als die den berechtigten Benutzer identifizierende Information extrahiert wurde, unterscheiden. Das heißt, die Aufgabe kann beispielsweise mittels eines anderen Merkmals gelöst werden, als das extrahierte Merkmal aus dem Datensatz, solange das extrahierte Merkmal und das zur Lösung der Aufgabe verwendete Merkmal kausal miteinander verknüpft bzw. derart korreliert sind, dass durch den Vergleich der verschiedenen Lösungen geschlossen werden kann, ob es sich bei dem sendenden Benutzer um den berechtigten Benutzer handelt.
-
Gemäß weiteren Ausführungsbeispielen wird ohne eine weitere Interaktion mit dem sendenden Benutzer eine weitere den sendenden Benutzer identifizierende Information bestimmt werden, so dass bestätigt werden kann, dass der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde, wenn die den berechtigten Benutzer identifizierende Information und die den sendenden Benutzer identifizierende weitere Information denselben Benutzer identifizieren. Beispielsweise kann die weitere den sendenden Benutzer identifizierende Information eine IP-Adresse des Benutzers sein, oder eine Sitzungsnummer bzw. Session-ID, die einem Benutzer eindeutig zugeordnet ist, wobei die Zuordnung zwischen der weiteren Information, also der IP oder der Session-ID und dem dadurch identifizierten Benutzer von anderen Services oder Identitäten im Netzwerk erhalten werden kann, beispielsweise von einem DHCP-Server oder einem Domain-Controller.
-
Wie bereits vorhergehend angesprochen, muss es sich bei der Information, die ausgelöst durch den empfangenen Datensatz gewonnen bzw. extrahiert wird und der weiteren Information, mit der diese Information verglichen wird, insoweit die beiden Informationen eindeutig miteinander korreliert sind.
-
Gemäß einigen weiteren Ausführungsbeispielen umfasst das Überprüfen der Frage, ob der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde, das Erstellen einer verschlüsselten Verbindung mit dem Benutzer, von dem der Datensatz empfangen wurde. Die aus dem Datensatz extrahierte und den berechtigten Benutzer identifizierende Information wird mit einer weiteren einen Benutzer identifizierenden Information verglichen, welche genutzt wird, um die gesicherte verschlüsselte Verbindung herzustellen. Auch hier können unterschiedliche Arten von den Benutzer eindeutig zugeordneten Informationen verglichen werden, beispielsweise einen dem Benutzer zugeordneten Hash-Wert oder Schlüssel, der zum Aufbau der verschlüsselte Verbindung verwendet wird, sowie eine dem Benutzer zugeordnete User-ID, die aus dem Datensatz abgeleitet oder extrahiert wurde.
-
Gemäß einigen Ausführungsbeispielen wird das Überprüfen, ob der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde, in vorbestimmten Zeitintervallen oder auch zufällig wiederholt. Die Zeitintervalle können, müssen jedoch nicht notwendigerweise gleich lang sein. Dies kann verhindern, dass eine die Überprüfung ermöglichende Komponente, beispielsweise eine Smartcard innerhalb eines Kartenlesers, zwischenzeitlich entfernt wurden, so dass möglicherweise nicht mehr sichergestellt ist, dass der den Service aktuell in Anspruch nehmende Benutzer tatsächlich noch der berechtigte Benutzer ist. Mit anderen Worten kann so die kontinuierliche Anwesenheit des tatsächlichen berechneten Benutzers überprüft werden.
-
Gemäß einigen Ausführungsbeispielen wird der Zugriff auf den Service nach erfolgreicher Überprüfung dadurch gewährt, dass dem Sender des Datensatzes ein weiterer Datensatz übermittelt wird, das für den berechtigten Benutzer gegenüber dem Anbieter des Service eine Berechtigung anzeigt, auf den Service zuzugreifen. Das heißt, gemäß einigen Ausführungsbeispielen wird nach erfolgreicher Authentifizierung den berechtigten Benutzer ein weiterer Datensatz übermittelt, das diesen gegenüber dem speziellen angefragten Service als berechtigt ausweist.
-
Gemäß einigen Ausführungsbeispielen wird der Datenfluss zwischen dem Service und den Benutzer kontrolliert, d.h. die Daten werden nur dann an den Service weitergeleitet, wenn und solange der Sender des Datensatzes dem berechtigten Benutzer entspricht.
-
2a zeigt schematisch und zum besseren Verständnis ein Beispiel für einen möglichen Inhalt eines Datensatzes 200, der eine Berechtigung anzeigt auf zumindest einen Service zuzugreifen. Dargestellt ist ein Inhalt eines Ticket-Granting-Tickets (TGT), das von einem Key Distribution Center eines Kerberos-Authentifizierungssystems an einen Benutzer vergeben werden kann, und welches dieser darauffolgend benutzen kann, um Berechtigungstickets für weitere Services beim Key Distribution Center zu beantragen. Wie anhand von 2 gezeigt, umfasst das Ticket-Granting-Ticket 210 zumindest die Information über einen Sitzungsschlüssel 212, mittels dessen der das Ticket beantragende Benutzer mit dem Key Distribution Center (KDC) verschlüsselt kommunizieren kann. Das TGT 210 umfasst ferner eine User-ID 214, also eine eindeutige Benutzerkennung, für den berechtigten Benutzer, für den das Ticket erstellt wurde. Im Fall von Kerberos ist die Information ferner mit dem Schlüssel 216 des KDC verschlüsselt. Gemäß weiteren Ausführungsbeispielen können Datensätze auch unverschlüsselt, also im Klartext, und mit anderem Inhalt vorliegen und übertragen werden. Anhand des in 2a gezeigten Datensatzes 200, wäre es beispielsweise während der Kontrolle des Zugriffs auf einen Service möglich, die User-ID 214 zum Identifizieren des berechtigten Benutzers, für den der Datensatz 200 erstellt wurde, direkt aus dem Datensatz zu extrahieren. Wie oben bereits eingehend dargelegt, bestehen jedoch beliebige andere Möglichkeiten, den berechtigten Benutzer zu identifizieren, diese können sich je nach konkreter Implementierung unterscheiden.
-
2b zeigt ein weiteres Beispiel für einen Inhalt eines Datensatzes 220, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen. Der Datensatz 220 basiert auf dem NTLMSSP Authentifizierungsprotokoll. Der Datensatz umfasst die Information, um welche Art von Nachricht es sich handelt, im Feld 232, als Information über den Nachrichtentyp. Ferner sind in dem exemplarisch dargestellten Datensatz der Benutzername 234, der Computername 236 des sendenden Rechners sowie der Domainname 238 enthalten. In weiteren Datensätzen kann auch nur ein beliebiger Teil dieser Information enthalten sein und die Reihenfolge der enthaltenen Information kann beliebig sein. Falls das Feld 232 den Wert 3 als Kodierung für den Nachrichtentyp enthält, handelt es sich um den Nachrichtentyp „NTLMSSP_AUTH“ der unter anderem verwendet wird, um eine Authentifizierung des sendenden Benutzers durchzuführen. Auch bei dem in 2b gezeigten Datensatz 220 wäre es beispielsweise während der Kontrolle des Zugriffs auf einen Service möglich, den Benutzernamen 234 zum Identifizieren des berechtigten Benutzers, für den der Datensatz 220 erstellt wurde, direkt aus dem Datensatz zu extrahieren. Wie auch im Fall des Beispiels der 2a können Nachrichten gemäß dem NTLMSSP Protokoll noch mehr als die dargestellten Informationen enthalten.
-
In anderen Implementierungen kann der Datensatz beispielsweise einen oder mehrere Hash-Werte umfassen, die von einem Benutzerpasswort abgeleitet sind, beispielsweise mittels bekannter Hash-Algorithmen, wie beispielsweise dem MD4- oder SHA-3 Algorithmus.
-
3 illustriert ein Ausführungsbeispiel eines Verfahrens zum Erhalten eines Zugriffs auf einen Service 300 innerhalb eines Netzwerks für einen Benutzer, also ein Ausführungsbeispiel, das auf der Seite des Benutzers durchgeführt wird, um Zugriff auf den Service zu erhalten.
-
Das Verfahren umfasst das Übermitteln eines Datensatzes 310, das für einen berechtigten Benutzer eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen. Insofern die Ausführungsbeispiele der Erfindung dazu benutzt werden, bestehende Lösungen für den Zugriff aus Services zu ergänzen, kann es sich auch um den bislang genutzte Datensatz handeln. Dies kann es ermöglichen, Ausführungsbeispiele der Erfindung dazu zu benutzen, die Sicherheit bereits existierender Netzwerke in Form einer Nachrüstlösung kosteneffizient und einfach zu erhöhen.
-
Auf das Übermitteln des Datensatzes 310 hin, wird in 320 eine Aufforderung empfangen, eine die Identität des Benutzers anzeigende Antwort zu erstellen, d.h. der Benutzer bzw. der sendende Benutzers des Datensatzes wird aufgefordert, seine Identität zu verifizieren, beispielsweise durch eine Signatur.
-
Daraufhin findet ein Übermitteln der Antwort 330 statt, welche die Identität des Benutzers anzeigt. Das heißt, benutzerseitig wird, über das Übermitteln des Datensatzes 310 hinaus, eine Aufforderung empfangen, die Identität nachzuweisen und eine Antwort übermittelt, die die Identität nachweist. Wenn der Nachweis die Identität des berechtigten Nutzers angezeigt hat, kann gemäß einigen Ausführungsbeispielen der weitere Zugriff auf den Service gemäß den bereits etablierten Mechanismen erfolgen, was die Nachrüstung von Ausführungsbeispielen der Erfindung in bestehenden großen Netzwerken effizient ermöglichen kann. 3 zeigt, unter der Annahme eines erfolgreichen Nachweises der Identität des berechtigten Benutzers, den optionalen nachfolgenden Schritt des Zugreifens auf den Service 340.
-
1 illustriert schematisch ein Ausführungsbeispiel eines Verfahrens, wie es auf einer authentifizierenden Instanz, beispielsweise auf einem Server ablaufen könnte und 3 zeigt ein Ausführungsbeispiel eines Verfahrens, das benutzerseitig ablaufen könnte.
-
Zum besseren Verständnis des Zusammenwirkens der verschiedenen Komponenten innerhalb des Netzwerks, zeigt 4 ein Flussdiagramm eines Verfahrens zum Zugreifen auf einen Service in einem Netzwerk von Beginn der Anfrage mittels eines Datensatzes bis zum tatsächlich erfolgenden Zugriff auf den Service.
-
4 illustriert schematisch auch die jeweiligen ausführenden Entitäten oder Instanzen. Ein Benutzer 410 (Client) kommuniziert mit einer authentifizierenden Instanz bzw. mit einer Vorrichtung zum Kontrollieren eines Zugriffs 412 (CAS) und diese kommuniziert mit einer Authentifizierung 414 (SRV AuthN) eines Service 416 (Dienst). Die CAS 412 führt die korrelierende, zusätzliche Authentifizierung (CAS AuthN) durch und ist folglich die auschlaggebende Instanz, welche die gesamte Service Authentisierung (SRV AuthN + CAS AuthN) und somit den Zugriff auf den Service 416 kontrolliert. Eine Vorrichtung zum Kontrollieren eines Zugriffs auf einen Service wird im Folgenden auch mit CAS bezeichnet.
-
Die erfolgreiche Absolvierung der SAS AuthN, deren Ergebnis der Erhalt eines Datensatzes ist, der eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen, wird vorausgesetzt und ist in der folgenden Abbildung nicht dargestellt. Dabei sind den einzelnen Schritten Bezugszeichen zugeteilt.
-
420: Der Client bzw. der sendende Benutzer 410 sendet eine Anfrage (AREQ), um auf einen Service zuzugreifen (dies kann z.B. die initiale Nachricht der SRV AuthN sein). Das heißt, es wird ein Datensatz gesendet, der eine Berechtigung anzeigt, auf den Service 416 zuzugreifen.
-
422: Sobald die Anfrage 420 von der CAS 412 empfangen wird, wird die UID bestimmt, z.B. anhand des SAT, extrahiert aus dem AREQ, nachgeschlagen anhand der IP, oder auf eine andere Art und Weise. Das heißt, es erfolgt ein Identifizieren eines berechtigten Benutzers, für den der Datensatz erstellt wurde. Das Ergebnis ist beispielsweise die UID.
-
424: Der CAS 412 generiert eine sogenannte Challenge, z.B. eine Zufallszahl.
-
426: Der CAS 412 stellt dem sendenden Benutzer 410 die Aufgabe, den Besitz der zusätzlichen Authentisierungsdaten nachzuweisen und sendet die Challenge an den Benutzer. 428: Der Benutzer löst die Aufgabe, indem er den Besitz der Authentisierungsdaten sowie den Empfang der aktuellen Challenge nachweist (z.B. durch Signieren der Zufallszahl mit Hilfe einer Smartcard). Als Resultat liegt die gelöste Aufgabe vor.
-
430: Der Benutzer sendet die gelöste Aufgabe an den CAS 412.
-
432: Der CAS 412 verifiziert die Antwort anhand der zur UID dazugehörigen, korrelierten Verifikationsdaten. Die Verifikationsdaten können hierbei auch den Authentisierungsdaten entsprechen, die beim Schritt 428 zur Lösung der Challenge verwendet wurden. Der CAS 412 hat den Benutzer 410 somit erfolgreich authentifiziert (CAS AuthN).
-
Durch die Schritte 424 bis 432 wird also überprüft (440), ob der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde.
-
Der CAS 412 ermöglicht den Zugriff auf den Service mittels der Authentifizierung 414 (SRV AuthN) nur dann, wenn auch die CAS AuthN erfolgreich abgeschlossen ist, das heißt, wenn verifiziert wurde, dass der Datensatz ausgehend von dem berechtigten Benutzer empfangen wurde.
-
Das Gewähren des Zugriffs auf den Service 450 bzw. die Erstauthentifizierung bei dem Service 450 umfasst bei dem Ausführungsbeispiel der 4 ein Weiterleiten 452 der Anfrage an die Authentisierung 414 des Service 416. Diese herkömmliche SRV AuthN kann vor, nach oder parallel zu den Schritten 422 bis 432 unverändert abgehandelt werden.
-
454: Das (positive) Ergebnis der SRV AuthN kann jederzeit vom CAS 412 empfangen und gepuffert werden und muss positiv vorhanden sein, bevor der Benutzer 410 tatsächlich in Schritt 474 Zugriff erlangt, wenn dieser also mit dem Service kommunizieren kann bzw. wenn dessen Anfragen den Service 416 erreichen können.
-
456: Die Antwort der SRV AuthN wird an den Benutzer weitergeleitet werden. Dies kann zu jedem Zeitpunkt erfolgen, bevorzugt jedoch, nachdem das Ergebnis der CAS AuthN vorliegt, wenn also überprüft wurde, ob der Datensatz bei 420 ausgehend von dem berechtigten Benutzer empfangen wurde. Wenn diese fehlschlägt kann im bevorzugten Fall bereits hier der Zugriff verweigert werden.
-
Im Erfolgsfall erfolgt der Zugriff auf den Service durch den Benutzer 470. Der Benutzer 410 sendet die eigentliche Service- und Daten Anfrage (REQ) 472. Der CAS 412 lässt diese Anfragen nur zum Dienst durch 474, wenn auch die CAS AuthN positiv abgeschlossen ist. Nachdem der Authentisierungsprozess durch SRV und CAS AuthN erfolgreich abgeschlossen ist, wird also der Zugriff auf den Service ermöglicht.
-
Der Service 416 bearbeitet die Anfrage 474 wie üblich, es wird eine entsprechende Antwort generiert, und an den CAS 412 weitergeleitet. Der CAS 412 leitet die Antwort an den Client weiter und der Dienst ist etabliert. Der Zugriff 470 auf den Service 416 durch den Benutzer kann wie bei herkömmlichen Implementierungen erfolgen.
-
Wenngleich in den vorhergehenden Ausführungsbeispielen nicht beschrieben, können weitere Ausführungsbeispiele zusätzliche Absicherungsmaßnamen umfassen, um die Sicherheit weiter zu erhöhen.
-
Gemäß einigen weiteren Ausführungsbeispielen ist auch der serverseitige CAS 412 dem Benutzer 410 bzw. dem gegenüber Client nachweisbar identifizierbar, beispielsweise mittels eines geeigneten Zertifikats. Dies kann bereits vor Schritt 420 überprüft werden. Mit anderen Worten umfassen weitere Ausführungsbeispiele das Bestätigen einer Identität eines Empfängers des Datensatzes, hier der CAS 412, gegenüber dem sendenden Benutzer 412.
-
Um die Datenintegrität während und nach der CAS AuthN zu gewährleisten, wird gemäß einigen Ausführungsbeispielen ein Integritätsschutz der übertragenen Daten implementiert, beispielsweise mittels des Keyed-Hash Message Authentication Code (HMAC) oder mittels des Cipher-based Message Authentication Code (CMAC). Dies verhindert die Manipulation von Daten auch nach der Anmeldung durch Man-in-the-Middle Angriffe. Mit anderen Worten wird gemäße einigen Ausführungsbeispielen zumindest eine Integrität des empfangenen Datensatzes überprüft. Es wird dadurch festgestellt, ob der empfangene Datensatz auf dem Weg von dem sendenden Benutzer 410 zu der authentifizierenden Instanz bzw. zu dem CAS 412 verändert wurde. Gemäß weiteren Ausführungsbeispielen wird die Integrität einer jeden ausgetauschten Nachricht überprüft.
-
Um das Mitlesen der Nachrichten zu unterbinden wird gemäß einigen Ausführungsbeispielen der gesamten Datenverkehr des Zugriffs auf den Service verschlüsselt, beispielsweise per VPN, IPSEC oder SSL/TLS.
-
Dauert eine Sitzung bzw. der Zugriff auf einen Service länger an, kann in regelmäßigen Abständen eine neue CAS AuthN angefordert werden, um so zum Beispiel zu verhindern, dass ein Token wie etwa eine Smartcard zur Authentifizierung entfernt werden kann oder nach der letzten Authentifizierung entfernt wurde. Mit anderen Worten wird eine kontinuierliche Präsenzprüfung durchgeführt und das Überprüfen, ob der Datensatz von dem berechtigten Benutzer empfangen wurde, wird in vorbestimmten Zeitintervallen wiederholt.
-
Gemäß einigen Ausführungsbeispielen wird, anstatt einen Token durch erneute Prüfung zu verifizieren, dieser als kryptographisches Geheimnis auf einem gesicherten Speicher abgelegt, beispielsweise auf einer Smartcard. Die Prüfung kann dann durch ein asymmetrisches Verfahren erfolgen, bei dem etwa eine Signatur den Besitz des Tokens nachweist ohne dass ein Angreifer es auslesen könnte.
-
Für die Funktionalität der Ausführungsbeispiele der Erfindung ist es nicht erforderlich, dass das Verfahren zum Kontrollieren des Zugriffs auf den Service auf einer bestimmten oder gar dedizierten Netzwerkkomponente abläuft. Während auf Seite des Benutzers eine natürliche Zuordnung gegeben ist, da dessen Verfahrensschritte auf der Identität bzw. bei dem Benutzer und dessen Client durchgeführt werden, der den Zugriff auf den Service benötigt, ergibt sich für das Verfahren zum Kontrollieren des Zugriffs eine Vielzahl von Möglichkeiten, wie und auf welchen Hardware-Komponenten bzw. Entitäten im Netzwerk dieses durchgeführt werden kann. Beispielsweise kann das Verfahren zum Kontrollieren des Zugriffs als Security-Add-On direkt auf den Servern, die auch den Dienst bzw. den Service anbieten, implementiert werden, beispielsweise als zusätzliches Software- oder Hardware-Modul.
-
Möglich ist auch eine zentralisierte Lösung, beispielsweise innerhalb einer dedizierten virtuellen Maschine, die gegebenenfalls die Anbieter von mehreren Services bzw. mehrerer Zielserver gleichzeitig schützen könnte. Alternativ könnte das Verfahren zum Kontrollieren eines Zugriffs auch als geeignetes Modul bzw. Softwarekomponente direkt auf einem Host einer Virtualisierungslösung ablaufen.
-
Als weitere Möglichkeit zeigt 5 exemplarisch das Verwenden eines eigenständigen Netzwerkgerätes bzw. einer eigenständigen Appliance, die die Kontrolle des Zugriffs auf die Services innerhalb des Netzwerks durchführt. So können beispielsweise mehrere Netzwerksegmente physikalisch getrennt werden und es können mehrere Server gleichzeitig geschützt werden. Innerhalb des Netzwerkes sind als Beispiel für unterschiedliche Services ein Druckservice 552, ein Datenservice 554 und ein weiterer Service 556 dargestellt, denen jeweils unterschiedliche IP Adressen zugeordnet sind. Ausführungsbeispiele der Erfindung umfassen, wie in 5 dargestellt, auch Vorrichtungen zum Kontrollieren eines Zugriffs auf einen Service 500. Die Vorrichtung 500 wird in der Implementierung in 5 auch als CAS bezeichnet. Die Vorrichtung bzw. CAS 500 kann vom Benutzer 510, der exemplarisch als Netzwerk-Client oder PC mit der Möglichkeit zur Smartcard-Authentifizierung angenommen wird, eindeutig identifiziert werden. Ferner ist ein sicherer Kommunikationskanal bzw. eine verschlüsselte Verbindung 520 (beispielsweise eine VPN-Verbindung) zwischen dem Benutzer und dem CAS-Gateway 500 etabliert. Bei dem in 5 gezeigten Ausführungsbeispiel wird zur Authentifizierung bei dem Aufbau des sicheren Kanals bzw. der verschlüsselten Verbindung 520 zwischen dem Benutzer 510 und dem CAS 500 eine einen Benutzer identifizierende weitere Information verwendet, beispielsweise ein dem Benutzer eindeutig zugeordneter Schlüssel. Diese weitere Information kann bei dem Verfahren zum Kontrollieren eines Zugriffs auf einen Service verwendet werden, um sie mit einer aus dem Datensatz extrahierten, den berechtigten Benutzer identifizierenden Information zu vergleichen, sobald der Benutzer 510 Zugriff auf einen Service innerhalb des Netzwerks 550 erlangen will. Mit anderen Worten wird bei dem in 5 gezeigten Ausführungsbeispiel die Authentifizierung für den sicheren Kanal bzw. die verschlüsselte Verbindung 520 als Authentifizierung für das CAS-Gateway eingesetzt (CAS AuthN) und innerhalb des etablierten, sicheren Kanals bzw. der verschlüsselten Verbindung 520 wird die SAS AuthN durchgeführt, die nur als erfolgreich gilt, wenn die Authentifizierungsdaten der SAS AuthN zu den Authentifizierungsdaten für den sicheren Kanal (CAS AuthN) passen.
-
Ein in 5 exemplarisch dargestellter potentieller Angreifer 560 kann keine Nachrichten fälschen und auch sogenannte Man-In-The-Middle-Attacken sind ausgeschlossen. Insbesondere kann er gemäß den Ausführungsbeispielen der Erfindung auch keine gestohlenen Authentifizierungsdaten (Datensätze, die eine Berechtigung anzeigen, auf zumindest einen Service zuzugreifen) verwenden, da er in diesem Fall nicht im Besitz der CAS AuthN-Daten für den sicheren Tunnel wäre, die in diesem Fall der weiteren einen Benutzer identifizierenden Information entsprechen. Folglich kann der potentielle Angriff auch nicht direkt auf die Services 552, 554 und 556 innerhalb des CAS-geschützten Servicenetzes zugreifen.
-
Mit anderen Worten wird bei dem in 5 gezeigten Ausführungsbeispiel der sichere Tunnel bzw. die verschlüsselte Verbindung 520 zuerst etabliert, bevor eine Anfrage, auf einen Service zugreifen zu dürfen, gesendet wird. Die anschließende Korrelation der SRV AuthN kann also anhand und innerhalb des sicheren Tunnels realisiert werden. Das heißt, die anschließende SRV AuthN mittels SAT wird nur akzeptiert, sofern der SAT bzw. die UID des Nutzers auch mit der Identität übereinstimmt, die beim Aufbau des sicheren Kanals verwendet wurde. Dies ist nur eine einer Vielzahl von möglichen Umsetzungsvarianten von Ausführungsbeispielen der vorliegenden Erfindung, im vorliegenden Fall eine, bei der eine weitere den Benutzer identifizierende Information in Form der CAS AuthN bestimmt wird, bevor der Datensatz, der die Berechtigung anzeigt, auf zumindest einen Service zuzugreifen, empfangen wird (SRV AuthN). Wie anhand von 5 dargestellt, kann eine Vorrichtung zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerks ähnlich einem Gateway implementiert sein.
-
Die wesentlichen Komponenten zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerkes sind in 6 schematisch anhand eines Blockdiagramms erneut dargestellt. Eine Vorrichtung zum Kontrollieren eines Zugriffs auf einen Service 600 umfasst eine Eingangsschnittstelle 610, die ausgebildet ist, um einen Datensatz zu empfangen, das eine Berechtigung anzeigt, auf zumindest einen Service zuzugreifen.
-
Der Datensatz stammt von einem sendenden Benutzer, der dieses entweder aufgrund seiner internen Konfiguration direkt an die Vorrichtung 600 sendet oder der Datensatz aufgrund von geeigneten Routing Mechanismen im Netzwerk von einer einem Anbieter eines Services zugeordneten Adresse an eine Adresse der Vorrichtung 610 umgeleitet wird.
-
Ein Informationsbearbeiter 620 ist ausgebildet, einen berechtigten Benutzer zu identifizieren, für den der Datensatz erstellt wurde. Dabei implementiert der Informationsbearbeiter 620 beispielsweise eine der in den vorangegangenen Abschnitten beschriebenen Möglichkeiten.
-
Ein Verifizierer 640 ist ausgebildet, um zu überprüfen, ob der Datensatz von dem berechtigten Benutzer empfangen wurde und eine Ausgangsschnittstelle 650 ist ausgebildet, den Zugriff auf den Service zu gewähren, wenn der Datensatz von dem berechtigten Benutzer empfangen wurde. Dies kann beispielsweise dadurch erfolgen, dass die in der Vorrichtung 600 während der Überprüfung zwischengespeicherte Anfragen an den Anbieter des Service bzw. Dienstes über die Ausgangsschnittstelle 650 erst dann weitergeleitet wird, wenn sichergestellt, dass der Datensatz von dem berechtigten Benutzer empfangen wurde.
-
Eine Vorrichtung zum Kontrollieren eines Zugriffs auf einen Service 600 kann beispielsweise eine dedizierte Hardware sein oder ein Rechner, der mit den notwendigen Schnittstellen ausgestattet ist. Die Vorrichtung kann auch einer einzelnen CPU innerhalb eines Mehrprozessorsystems entsprechen, oder in Form eines Systems on a Chip implementiert sein. Möglich sind beliebige Arten von die Funktionalität bereitstellenden Vorrichtungen, Rechnern oder Hardware, die ganz oder Teilweise zum Bereitstellen der Funktionalität genutzt wird.
-
In anderen Worten können Ausführungsbeispiele der Erfindung wie folgt zusammengefasst werden. Um eine Schwachstelle der SSO Verfahren, nämlich die Wiederverwendung des (gestohlen) SAT, netzwerkseitig zu schließen (SAT Replay Protection), wird ein weiterer Schritt in die SSO Verfahren integriert werden, um den SAT des Nutzers erneut prüfen zu können. Um zu erreichen, dass das zusätzliche Authentisierungsverfahren während der SRV AuthN nicht separat umgangen werden kann, wird dieser zusätzliche Schritt mit der Identität der SRV AuthN korreliert. Dazu kann die Identität und/oder ggf. andere (zusätzliche) Parameter, z.B. die verfügbare Sitzungskennung, aus einem bestehenden Dienst oder Protokoll extrahiert werden oder in einer Datenbank (z.B. anhand der IP) nachgeschlagen werden. Basierend auf solch einer Zuordnungsvorschrift wird die Identität ausgewählt und ein zusätzlicher Nachweis vom identifizierten Nutzer angefordert. Nur wenn dieser die zusätzliche, korrelierte Anfrage auch beantworten kann, wird davon ausgegangen, dass der SAT, der während der SRV AuthN benutzt wurde, vertrauenswürdig ist und nicht etwa von einem Angreifer stammt, der diesen aktuell missbraucht.
-
Um dies zu ermöglichen, ergeben sich Benutzer- bzw. client- seitig zumindest für einige Ausführungsbeispiele folgende Anforderungen:
- • Vorkommen eines Einzigartigen Zuordnungsmerkmals (UID) gebunden an die SRV AuthN des Ursprungsdienstes (SAT oder Nutzername/ID)
- • Besitz von zusätzlichen Authentisierungsdaten neben dem SAT, unter anderem das einzigartige Zuordnungsmerkmal.
-
Grundlegende serverseitige Anforderungen für zumindest einige Ausführungsbeispiele sind:
- • Möglichkeit die UID im Dienst oder in dessen SRV AuthN zu identifizieren.
- • Besitz von zusätzlichen Verifikationsdaten der Client-Seite.
- • Zusätzliche Authentisierungsverfahren und akkurate sowie eindeutige Zuordnung der zusätzlichen Verifikationsdaten zur UID und umgekehrt.
-
Diese Korrelation bzw. der zugriffsverwaltende Dienst wird daher hierin teilweise als Correlating Authentication Service (CAS) bezeichnet. Der CAS involviert somit seine zusätzliche Authentisierung (CAS AuthN) anhand der korrelierten UID des Dienstes bzw. der SRV AuthN. Der CAS kann weiterhin die Steuerung der Service Anfragen übernehmen, z.B. blocken des Dienstes bis die gesamte Authentisierung abgeschlossen ist, was ähnlich der Funktionsweise einer Firewall ist.
-
Ein Vorteil der Ausführungsbeispiele der Erfindung mit CAS Zugriffsverwaltung und CAS AuthN besteht in der Möglichkeit, unsichere Authentifizierungsverfahren in dem Maße nachzurüsten, dass ein Angreifer, der nicht im Besitz der CAS AuthN Daten ist, auch nicht in der Lage ist sich mit gestohlenen Authentisierungsdaten (SAT) betreffend der SRV AuthN zu authentisieren. Ein besonderer Vorteil dieser ergibt sich dadurch, dass offizielle Anwender, die legal im Besitz Ihrer CAS AuthN Daten sind, keine anderen gestohlen Authentisierungsdaten (SAT) für die SRV AuthN verwenden, und somit die SRV AuthN nicht durch Vortäuschen einer anderen Identität umgehen können (Insider Angriffe). Dies wird durch die Ausführungsbeispiele der Erfindung und mit der CAS Zugriffsverwaltung und der Korrelation der CAS AuthN zur SRV AuthN gewährleistet, so dass diese Angriffe verhindern werden können.
-
Vorteilhaft ist es hierbei, wenn die CAS AuthN die Präsenz des Nutzers und somit die Authentizität der Anmeldedaten beweisen kann. Daher sind Hardware-Tokens wie etwa Smartcards besonders geeignet. Der Verlust eines Hardware Tokens fällt sofort auf, wobei ein (weiterer) Passwortdiebstahl unbemerkt geschehen kann. Weiterhin sind Hardware Tokens wie Smartcards gegen Kopieren geschützt.
-
Auch muss durch Korrelation der CAS AuthN, die ursprüngliche SRV AuthN des Dienstes nicht modifiziert oder ausgetauscht werden, was in Bezug auf bestehende Infrastrukturen einen enormen Vorteil bringt, da Dienste wie gewohnt aufrecht erhalten werden können.
-
Ein Beispiel für den Einsatz der vorgestellten Lösung wären Single-Sign-On-Verfahren in vielen Betriebssystem-Versionen. Eine über 15 Jahre bestehende Sicherheitslücke, namens Pass-the-Hash, die bis heute Angreifern offen steht, kann durch die Lösung netzwerkseitig geschlossen werden. Bei dem Pass-the-Hash Angriff kann ein Angreifer einen gestohlenen Passwort-Hash (vgl. SAT) wieder in sein Client-System einspielen, und sich somit unbefugten Zugang zu Servern und Diensten im Netzwerk verschaffen (SRV AuthN). Hashes besitzen die Eigenschaft, dass aus ihnen das ursprüngliche Passwort nicht ohne großen rechenintensiven Aufwand zurückberechnet werden kann, aber eine Prüfung, ob die Eingabe mit einem bekannten Wert übereinstimmt, problemlos ist. Durch herkömmliche, zusätzliche Authentisierung (z.B. Passwort plus Smartcard), kann hier nur eine bedingte Sicherheit gewährleistet werden, da die zusätzlichen Verfahren anders wie die Ausführungsbeispiele der Erfindung nicht die Identität der SRV AuthN korrelieren. Das Risiko von internen Angriffen, z.B. durch Mitarbeiter, wird durch die vorgestellte Lösung aufgelöst, so dass eine fälschliche Authentifizierung durch den Pass-the-Hash Angriff nicht mehr möglich ist und diese offene Sicherheitslücke geschlossen werden kann. Weiterhin kann die Lösung auch Schutz gegen sogenannte Pass-the-Ticket Angriffe bieten, eine erweiterte Form des Pass-the-Hash Angriffs, angepasst auf das Kerberos Authentisierungsverfahren. Weiterhin schützen Ausführungsbeispiele der Erfindung auch vor dem Diebstahl von Passwörtern. Die Ausführungsbeispiele der Erfindung besitzen weitere vielfältige Verwendungsmöglichkeiten im Bereich der Authentisierung gegenüber IT-Systemen. Von den Vorteilen profitieren insbesondere Netzwerkdienste welche Lücken aufweisen, oder sogar überhaupt kein Authentisierungsverfahren (SRV AuthN) besitzen, aber eine UID. Mit anderen Worten können Ausführungsbeispiele der Erfindung auch eine fehlende SRV AuthN für Dienste generell nachrüsten (CAS AuthN = SRV AuthN), sofern eine gültige UID anhand der Dienstanfrage identifizierbar ist.
-
Die in der vorstehenden Beschreibung, den nachfolgenden Ansprüchen und den beigefügten Figuren offenbarten Merkmale können sowohl einzeln wie auch in beliebiger Kombination für die Verwirklichung eines Ausführungsbeispiels in ihren verschiedenen Ausgestaltungen von Bedeutung sein und implementiert werden.
-
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Insbesondere kann die hierin beschriebene Vorrichtung zum Kontrollieren eines Zugriffs auf einen Service sämtliche oder beliebige Schritte des hierin beschriebenen Verfahrens zum Kontrollieren eines Zugriffs auf einen Service innerhalb eines Netzwerkes durchführen.
-
Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-Ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einer programmierbaren Hardwarekomponente derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird.
-
Eine programmierbare Hardwarekomponente kann durch einen Prozessor, einen Computerprozessor (CPU = Central Processing Unit), einen Grafikprozessor (GPU = Graphics Processing Unit), einen Computer, ein Computersystem, einen anwendungsspezifischen integrierten Schaltkreis (ASIC = Application-Specific Integrated Circuit), einen integrierten Schaltkreis (IC = Integrated Circuit), ein Ein-Chip-System (SOC = System on Chip), ein programmierbares Logikelement oder ein feldprogrammierbares Gatterarray mit einem Mikroprozessor (FPGA = Field Programmable Gate Array) gebildet sein.
-
Das digitale Speichermedium kann daher maschinen- oder computerlesbar sein. Manche Ausführungsbeispiele umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem oder einer programmierbare Hardwarekomponente derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird. Ein Ausführungsbeispiel ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Programm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
-
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Programm, Firmware, Computerprogramm oder Computerprogrammprodukt mit einem Programmcode oder als Daten implementiert sein, wobei der Programmcode oder die Daten dahin gehend wirksam ist bzw. sind, eines der Verfahren durchzuführen, wenn das Programm auf einem Prozessor oder einer programmierbaren Hardwarekomponente abläuft. Der Programmcode oder die Daten kann bzw. können beispielsweise auch auf einem maschinenlesbaren Träger oder Datenträger gespeichert sein. Der Programmcode oder die Daten können unter anderem als Quellcode, Maschinencode oder Bytecode sowie als anderer Zwischencode vorliegen.
-
Ein weiteres Ausführungsbeispiel ist ferner ein Datenstrom, eine Signalfolge oder eine Sequenz von Signalen, der bzw. die das Programm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom, die Signalfolge oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, um über eine Datenkommunikationsverbindung, beispielsweise über das Internet oder ein anderes Netzwerk, transferiert zu werden. Ausführungsbeispiele sind so auch Daten repräsentierende Signalfolgen, die für eine Übersendung über ein Netzwerk oder eine Datenkommunikationsverbindung geeignet sind, wobei die Daten das Programm darstellen.
-
Ein Programm gemäß einem Ausführungsbeispiel kann eines der Verfahren während seiner Durchführung beispielsweise dadurch umsetzen, dass dieses Speicherstellen ausliest oder in diese ein Datum oder mehrere Daten hinein schreibt, wodurch gegebenenfalls Schaltvorgänge oder andere Vorgänge in Transistorstrukturen, in Verstärkerstrukturen oder in anderen elektrischen, optischen, magnetischen oder nach einem anderen Funktionsprinzip arbeitenden Bauteile hervorgerufen werden. Entsprechend können durch ein Auslesen einer Speicherstelle Daten, Werte, Sensorwerte oder andere Informationen von einem Programm erfasst, bestimmt oder gemessen werden. Ein Programm kann daher durch ein Auslesen von einer oder mehreren Speicherstellen Größen, Werte, Messgrößen und andere Informationen erfassen, bestimmen oder messen, sowie durch ein Schreiben in eine oder mehrere Speicherstellen eine Aktion bewirken, veranlassen oder durchführen sowie andere Geräte, Maschinen und Komponenten ansteuern.
-
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
