{"id":28943,"date":"2026-07-14T15:55:44","date_gmt":"2026-07-14T13:55:44","guid":{"rendered":"https:\/\/performance-msg-life-sk.rucolabs.sk\/glossary\/proxy-authentifizierung\/"},"modified":"2026-07-14T15:55:44","modified_gmt":"2026-07-14T13:55:44","slug":"proxy-authentifizierung","status":"publish","type":"glossary_intl","link":"https:\/\/performance-msg-life-sk.rucolabs.sk\/de\/glossar\/cybersecurity\/proxy-authentifizierung\/","title":{"rendered":"Proxy-Authentifizierung"},"content":{"rendered":"

Proxy-Authentifizierung<\/strong> ist ein Verfahren, bei dem ein Proxy-Server Zugangsdaten von Nutzern anfordert, bevor er deren HTTP- oder HTTPS-Anfragen an Zielserver weiterleitet. Der Proxy fungiert als Kontrollpunkt zwischen Client und Internet, \u00fcberpr\u00fcft die Identit\u00e4t des Anfragenden und gew\u00e4hrt oder verweigert Zugriff basierend auf konfigurierten Berechtigungen. Organisationen nutzen diesen Mechanismus, um Netzwerkressourcen zu sch\u00fctzen, Aktivit\u00e4ten zu protokollieren und richtlinienbasierte Zugriffskontrolle durchzusetzen.<\/p>\n

Wie Proxy-Authentifizierung funktioniert<\/h2>\n

Ein Client sendet eine HTTP-Anfrage, die vom Proxy-Server abgefangen wird. Der Proxy antwortet mit HTTP-Statuscode 407 (Proxy Authentication Required)<\/strong> und f\u00fcgt einen Proxy-Authenticate<\/code>-Header hinzu, der die unterst\u00fctzten Authentifizierungsmethoden spezifiziert. Der Client muss daraufhin die Anfrage mit einem Proxy-Authorization<\/code>-Header wiederholen, der die kodierten Zugangsdaten enth\u00e4lt. Nach erfolgreicher Verifikation leitet der Proxy die urspr\u00fcngliche Anfrage an den Zielserver weiter und behandelt die Antwort transparent.<\/p>\n

Dieser Ablauf unterscheidet sich fundamental von direkter Server-Authentifizierung, die Statuscode 401 verwendet. Beide Mechanismen k\u00f6nnen gleichzeitig auftreten<\/strong> \u2013 ein Nutzer authentifiziert sich zun\u00e4chst beim Proxy (407), dann separat bei der Zielwebsite (401), wodurch zwei unabh\u00e4ngige Sicherheitsebenen entstehen. Browser und HTTP-Clients handhaben diese Sequenz automatisch, sofern Anmeldedaten verf\u00fcgbar sind.<\/p>\n

Authentifizierungsablauf bei verschl\u00fcsselten Verbindungen<\/h3>\n

HTTPS-Anfragen erfordern besondere Behandlung, weil der Proxy den verschl\u00fcsselten Inhalt nicht modifizieren darf. Der Client sendet zun\u00e4chst eine CONNECT<\/code>-Anfrage an den Proxy, um einen TCP-Tunnel zu etablieren. Die Proxy-Authentifizierung findet vor dem Tunnelaufbau statt<\/strong> \u2013 der Proxy fordert Zugangsdaten mittels 407-Antwort auf die CONNECT-Anfrage an. Nach erfolgreicher Authentifizierung wird der Tunnel ge\u00f6ffnet, und der Client f\u00fchrt den TLS-Handshake direkt mit dem Zielserver durch, w\u00e4hrend der Proxy verschl\u00fcsselte Daten weiterleitet, ohne sie zu entschl\u00fcsseln.<\/p>\n

Einsatzgebiete der Proxy-Authentifizierung<\/h2>\n

Unternehmensumgebungen setzen Proxy-Authentifizierung prim\u00e4r ein, um Internetzugriffe nach Nutzeridentit\u00e4t zu filtern und zu protokollieren.<\/strong> Ein Administrator kann Regeln definieren, die bestimmten Nutzergruppen Zugriff auf spezifische Websites gew\u00e4hren oder verweigern. Marketing-Mitarbeiter erhalten beispielsweise Zugang zu sozialen Medien, w\u00e4hrend Produktionsmitarbeiter ausschlie\u00dflich auf technische Dokumentationsseiten zugreifen k\u00f6nnen. Der Proxy identifiziert jeden Nutzer anhand seiner Anmeldedaten und wendet die entsprechende Richtlinie an.<\/p>\n

Sicherheitsteams nutzen authentifizierende Proxys zur Erkennung kompromittierter Konten. Wenn ein Nutzerkonto ungew\u00f6hnliche Zugriffsmuster zeigt<\/strong> \u2013 etwa Verbindungen zu bekannten Command-and-Control-Servern \u2013, kann der Proxy diese Anfragen blockieren und Alarme ausl\u00f6sen. Die Zuordnung von Netzwerkaktivit\u00e4ten zu individuellen Konten erm\u00f6glicht forensische Analysen bei Sicherheitsvorf\u00e4llen, weil Protokolle pr\u00e4zise dokumentieren, welcher Nutzer wann auf welche Ressourcen zugegriffen hat.<\/p>\n

Bandbreitenmanagement und Kostenkontrolle<\/h3>\n

Authentifizierende Proxys erm\u00f6glichen nutzerspezifische Bandbreitenlimitierung. Eine Organisation kann F\u00fchrungskr\u00e4ften h\u00f6here \u00dcbertragungsraten zuweisen, w\u00e4hrend Praktikanten niedrigere Limits erhalten. Diese Granularit\u00e4t ist ohne Authentifizierung nicht erreichbar<\/strong>, weil IP-basierte Beschr\u00e4nkungen nicht zwischen Nutzern unterscheiden k\u00f6nnen, die denselben Gateway verwenden. Service-Provider in Regionen mit getakteten Internetverbindungen nutzen Proxy-Authentifizierung, um Nutzungsquoten durchzusetzen und Abrechnungen zu generieren.<\/p>\n

Authentifizierungsmethoden bei Proxy-Servern<\/h2>\n

Proxy-Server unterst\u00fctzen mehrere Authentifizierungsverfahren, die unterschiedliche Kompromisse zwischen Sicherheit und Kompatibilit\u00e4t bieten. Die Wahl der Methode beeinflusst sowohl das Sicherheitsniveau als auch die Nutzerfreundlichkeit.<\/strong><\/p>\n\n\n\n\n\n\n\n\n
Methode<\/th>\nSicherheit<\/th>\nVorteil<\/th>\nNachteil<\/th>\n<\/tr>\n<\/thead>\n
Basic<\/strong><\/td>\nNiedrig<\/td>\nUniverselle Client-Unterst\u00fctzung<\/td>\nZugangsdaten nur Base64-kodiert, nicht verschl\u00fcsselt<\/td>\n<\/tr>\n
Digest<\/strong><\/td>\nMittel<\/td>\nPasswort wird gehasht \u00fcbertragen<\/td>\nAnf\u00e4llig f\u00fcr Replay-Angriffe ohne zus\u00e4tzliche Ma\u00dfnahmen<\/td>\n<\/tr>\n
NTLM<\/strong><\/td>\nHoch<\/td>\nWindows-Integration, Challenge-Response-Verfahren<\/td>\nPropriet\u00e4res Protokoll, komplex zu implementieren<\/td>\n<\/tr>\n
Kerberos<\/strong><\/td>\nSehr hoch<\/td>\nMutual Authentication, Single-Sign-On-F\u00e4higkeit<\/td>\nErfordert Active Directory oder KDC-Infrastruktur<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Basic-Authentifizierung: Verbreitung trotz Schw\u00e4chen<\/h3>\n

Basic-Authentifizierung kodiert Nutzername und Passwort lediglich mit Base64 und sendet sie im Proxy-Authorization<\/code>-Header. Jeder Angreifer mit Netzwerkzugriff kann diese Werte dekodieren und wiederverwenden.<\/strong> Dennoch bleibt Basic weit verbreitet, weil nahezu alle HTTP-Clients diese Methode unterst\u00fctzen und die Implementierung trivial ist. Organisationen, die Basic einsetzen, m\u00fcssen zwingend TLS\/SSL f\u00fcr die Proxy-Verbindung erzwingen, um Anmeldedaten w\u00e4hrend der \u00dcbertragung zu verschl\u00fcsseln.<\/p>\n

Integrierte Windows-Authentifizierung<\/h3>\n

NTLM und Kerberos erm\u00f6glichen transparente Authentifizierung in Windows-Dom\u00e4nen. Der Client sendet kein Passwort, sondern kryptografische Nachweise, die aus der bestehenden Betriebssystem-Sitzung abgeleitet werden.<\/strong> Ein Mitarbeiter meldet sich morgens an seinem Windows-PC an; alle nachfolgenden Proxy-Authentifizierungen nutzen diese Anmeldung, ohne erneute Passwortabfrage. Kerberos bietet zus\u00e4tzlich Mutual Authentication \u2013 der Client verifiziert die Identit\u00e4t des Proxy-Servers, was Man-in-the-Middle-Angriffe verhindert.<\/p>\n

H\u00e4ufige Probleme und L\u00f6sungsans\u00e4tze<\/h2>\n

Anwendungskompatibilit\u00e4t stellt die h\u00e4ufigste Herausforderung bei Proxy-Authentifizierung dar.<\/strong> Legacy-Software, mobile Apps und IoT-Ger\u00e4te unterst\u00fctzen oft keine Authentifizierung oder nur Basic. Ein Netzwerkdrucker kann beispielsweise Firmware-Updates von einem Hersteller-Server abrufen m\u00fcssen, besitzt jedoch keine M\u00f6glichkeit, Proxy-Anmeldedaten zu konfigurieren. Organisationen l\u00f6sen dies durch IP-basierte Ausnahmeregeln, dedizierte authentifizierungsfreie Proxys f\u00fcr solche Ger\u00e4te oder durch Proxy-Auto-Config-Dateien (PAC), die bestimmte Ziele direkt routen.<\/p>\n

Anmeldedaten-Caching und Session-Management<\/h3>\n

Browser und HTTP-Clients cachen validierte Proxy-Anmeldedaten \u00fcblicherweise f\u00fcr die Dauer einer Sitzung. Probleme entstehen, wenn Passw\u00f6rter w\u00e4hrend aktiver Sitzungen ge\u00e4ndert werden<\/strong> \u2013 die Anwendung sendet weiterhin alte Zugangsdaten, was zu wiederholten 407-Antworten f\u00fchrt. Der Proxy kann Konten nach mehreren Fehlversuchen tempor\u00e4r sperren, wodurch legitime Nutzer ausgesperrt werden. L\u00f6sungen umfassen l\u00e4ngere \u00dcbergangsperioden, in denen sowohl alte als auch neue Passw\u00f6rter akzeptiert werden, oder Mechanismen zur sofortigen Invalidierung gecachter Credentials.<\/p>\n

Performance-Auswirkungen<\/h3>\n

Jede Authentifizierungsmethode f\u00fcgt Latenz hinzu. Basic und Digest erfordern einen zus\u00e4tzlichen Request-Response-Zyklus (407 \u2192 wiederholte Anfrage mit Credentials). NTLM ben\u00f6tigt drei Round-Trips<\/strong>: Challenge-Request vom Client, Challenge vom Proxy, Response mit kryptografischem Beweis. Kerberos reduziert dies auf einen Round-Trip, wenn ein g\u00fcltiges Service-Ticket verf\u00fcgbar ist. Hochfrequente API-Aufrufe \u00fcber authentifizierende Proxys k\u00f6nnen messbare Performance-Einbu\u00dfen erfahren; Organisationen sollten Connection-Pooling und Credential-Reuse konfigurieren, um Round-Trips zu minimieren.<\/p>\n

Risiken bei unverschl\u00fcsselten Proxy-Verbindungen<\/h3>\n

Angriffe auf Proxy-Authentifizierung zielen prim\u00e4r auf Credential-Diebstahl durch Netzwerk\u00fcberwachung ab.<\/strong> Wenn die Verbindung zwischen Client und Proxy unverschl\u00fcsselt ist, k\u00f6nnen Angreifer mit Zugriff auf das lokale Netzwerk (etwa \u00fcber kompromittierte WLAN-Access-Points) Authentifizierungs-Header abfangen. Basic-Authentifizierung ist besonders gef\u00e4hrdet, weil Base64-Dekodierung trivial ist. Digest und NTLM bieten besseren Schutz, sind jedoch gegen Replay-Angriffe anf\u00e4llig, wenn keine zus\u00e4tzlichen Sicherheitsma\u00dfnahmen implementiert sind. Best Practice ist, die Client-zu-Proxy-Verbindung selbst \u00fcber TLS zu verschl\u00fcsseln, unabh\u00e4ngig von der Authentifizierungsmethode.<\/p>\n","protected":false},"featured_media":0,"template":"","glossary_intl_set":[],"glossary_intl_cluster":[392],"glossary_intl_theme":[],"class_list":["post-28943","glossary_intl","type-glossary_intl","status-publish","hentry","glossary_intl_cluster-cybersecurity"],"acf":{"card_description":"Proxy-Authentifizierung ist ein Verfahren, bei dem ein Proxy-Server Zugangsdaten anfordert, bevor er Anfragen weiterleitet. Dieses Sicherheitsmechanismus wird prim\u00e4r in Unternehmensnetzwerken eingesetzt, um Internetzugriffe zu kontrollieren.","nav_theme":"","nav_subtheme":"","dataset_version":"","term_inline":"","term_plural":false,"heading_overrides":null,"synonyms":[{"value":"Proxy-Authentisierung"},{"value":"Proxy-Auth"}],"lead_definition":"Proxy-Authentifizierung ist ein Sicherheitsverfahren, bei dem ein zwischengeschalteter Proxy-Server die Identit\u00e4t eines Nutzers \u00fcberpr\u00fcft, bevor dessen HTTP- oder HTTPS-Anfragen an Zielserver weitergeleitet werden. Der Proxy fordert Zugangsdaten an und gew\u00e4hrt oder verweigert den Zugriff basierend auf konfigurierten Berechtigungen, wodurch Organisationen zentrale Kontrolle \u00fcber ausgehende Netzwerkverbindungen erhalten.","at_a_glance":[{"bullet":"Proxy-Server fordern Zugangsdaten mittels HTTP-Statuscode 407 an, bevor sie Anfragen durchlassen \u2013 im Gegensatz zu Statuscode 401, der von Zielservern f\u00fcr direkte Authentifizierung genutzt wird."},{"bullet":"Unternehmen setzen Proxy-Authentifizierung ein, um Internetzugriffe nach Nutzern oder Gruppen zu filtern, Bandbreite zu regulieren und Aktivit\u00e4ten zu protokollieren."},{"bullet":"G\u00e4ngige Authentifizierungsmethoden umfassen Basic, Digest, NTLM und Kerberos, wobei Basic trotz schwacher Sicherheit wegen seiner breiten Kompatibilit\u00e4t weiterhin verbreitet ist."}],"intro_answer":"","steps_answer":"","steps":null,"examples":[{"example":"Ein Mitarbeiter versucht, von seinem Arbeitsplatzrechner eine Website aufzurufen. Der Unternehmens-Proxy f\u00e4ngt die Anfrage ab, sendet eine 407-Antwort und fordert Windows-Anmeldedaten an. Nach erfolgreicher NTLM-Authentifizierung leitet der Proxy die Anfrage weiter und protokolliert den Zugriff mit Nutzernamen und Zeitstempel."},{"example":"Eine Bildungseinrichtung konfiguriert ihren Proxy-Server so, dass Sch\u00fclerkonten nur auf bildungsrelevante Websites zugreifen k\u00f6nnen, w\u00e4hrend Lehrkr\u00e4fte nach Authentifizierung unbeschr\u00e4nkten Zugang erhalten. Der Proxy identifiziert Nutzer anhand ihrer Zugangsdaten und wendet gruppenspezifische Filterregeln an."},{"example":"Ein Softwareentwickler arbeitet remote und muss sich mit dem Unternehmens-Proxy verbinden, um interne API-Dokumentation abzurufen. Seine Entwicklungsumgebung sendet Proxy-Anmeldedaten automatisch bei jeder HTTP-Anfrage mit, sodass der verschl\u00fcsselte Tunnel zum Firmennetzwerk authentifiziert aufgebaut wird."}],"misconception":null,"faq":[{"q":"Warum fordert mein Browser wiederholt Proxy-Zugangsdaten an, obwohl ich sie bereits eingegeben habe?","a":"Dieses Problem tritt auf, wenn der Browser die Anmeldedaten nicht speichert oder der Proxy-Server sie ablehnt. H\u00e4ufige Ursachen sind falsche Schreibweise des Nutzernamens, abgelaufene Passw\u00f6rter oder eine Proxy-Konfiguration, die Anmeldedaten-Caching deaktiviert. Bei dom\u00e4nengebundenen Systemen muss der Nutzername oft das Format DOMAINBenutzername oder benutzername@domain.com aufweisen."},{"q":"Kann ich Proxy-Authentifizierung in einer URL einbetten, um manuelle Anmeldung zu vermeiden?","a":"Das Format http:\/\/nutzername:passwort@proxy.example.com:8080<\/code> ist zwar technisch m\u00f6glich, wird aber von modernen Browsern aus Sicherheitsgr\u00fcnden zunehmend blockiert. Organisationen sollten stattdessen integrierte Windows-Authentifizierung (NTLM\/Kerberos) nutzen oder Anwendungen so konfigurieren, dass sie Anmeldedaten aus sicheren Credential-Stores abrufen."},{"q":"Welche Authentifizierungsmethode sollte ich f\u00fcr meinen Proxy-Server w\u00e4hlen?","a":"Kerberos bietet die st\u00e4rkste Sicherheit in Windows-Umgebungen mit Single-Sign-On-Unterst\u00fctzung, erfordert jedoch Active-Directory-Integration. NTLM ist eine praxisnahe Alternative mit breiter Kompatibilit\u00e4t, w\u00e4hrend Digest-Authentifizierung einen Kompromiss zwischen Sicherheit und Einfachheit darstellt. Basic-Authentifizierung sollte nur \u00fcber verschl\u00fcsselte Verbindungen verwendet werden, da Zugangsdaten lediglich Base64-kodiert \u00fcbertragen werden."},{"q":"Wie wirkt sich Proxy-Authentifizierung auf automatisierte Prozesse und API-Aufrufe aus?","a":"Automatisierte Systeme m\u00fcssen Proxy-Anmeldedaten in ihren HTTP-Clients konfigurieren, typischerweise \u00fcber Umgebungsvariablen oder Konfigurationsdateien. Viele Programmiersprachen und Tools unterst\u00fctzen Proxy-Authentifizierung nativ \u2013 beispielsweise akzeptieren curl, wget und HTTP-Bibliotheken Anmeldedaten \u00fcber Parameter oder Environment-Variablen wie http_proxy<\/code> mit eingebetteten Credentials. Organisationen m\u00fcssen sicherstellen, dass Service-Accounts ausreichende Berechtigungen besitzen."}],"compare_answer":"","compare":null,"variants":[{"title":"Transparente Proxy-Authentifizierung","inline_description":"Authentifizierung ohne explizite Nutzerinteraktion durch Integration mit Betriebssystem-Anmeldedaten.","description":"Transparente Proxy-Authentifizierung ist eine Form der Proxy-Authentifizierung, bei der Zugangsdaten automatisch vom Betriebssystem oder Browser \u00fcbermittelt werden, ohne dass Nutzer manuell Anmeldedaten eingeben m\u00fcssen. Diese Methode nutzt typischerweise Kerberos oder NTLM in Windows-Dom\u00e4nenumgebungen, wo bereits authentifizierte Sitzungen wiederverwendet werden.","source":"","key":""},{"title":"Upstream-Proxy-Authentifizierung","inline_description":"Authentifizierung zwischen Proxy-Servern in hierarchischen Proxy-Architekturen.","description":"Upstream-Proxy-Authentifizierung ist eine Form der Proxy-Authentifizierung, bei der ein Proxy-Server sich gegen\u00fcber einem vorgelagerten Proxy authentifizieren muss, bevor er Anfragen weiterleiten kann. Diese Konfiguration findet sich in mehrstufigen Proxy-Hierarchien, wo regionale Proxys zentrale Gateway-Proxys nutzen.","source":"","key":""}],"signals_answer":"","signals":null,"protect_answer":"","prevent":null,"incident":null,"related_terms":null,"pillar_link":null,"sources":[{"publisher":"","name":"RFC 7235 - HTTP Authentication","url":"https:\/\/tools.ietf.org\/html\/rfc7235","doc_type":"","group":"used"},{"publisher":"","name":"RFC 7617 - HTTP Basic Authentication","url":"https:\/\/tools.ietf.org\/html\/rfc7617","doc_type":"","group":"used"}],"reviewer":{"name":"M. Kubascikova","qualification":"SEO director","date":"2026-07-01"},"disclaimer":""},"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t