Bernd Jungbluth, Horn (info@berndjungbluth.de)
Kennwörter. Sie sind ein mehr oder weniger notwendiges Übel, stellen Sie doch den Zugang zu Systemen sicher. Dennoch sind sie nicht selten eine Schwachstelle im Sicherheitskonzept, wie im aktuellen Szenario dieser Beitragsreihe. Für eine automatische Anmeldung am SQL Server wird der Anmeldename und das Kennwort in der Access-Applikation gespeichert. Dort aber lassen sich diese Informationen nicht ausreichend schützen. Dabei kann es so einfach sein. Mit der Windows-Authentifizierung sind die Anmeldedaten für den Zugang zum SQL Server nicht mehr erforderlich. In diesem Teil der Beitragsreihe lernen Sie die Vorteile der Windows-Authentifizierung kennen.
Warnung
Die beschriebenen Aktionen haben Auswirkungen auf Ihre SQL Server-Installation. Führen Sie die Aktionen nur in einer Testumgebung aus. Verwenden Sie unter keinen Umständen Ihren produktiven SQL Server!
Das aktuelle Berechtigungskonzept der Beispielumgebung basiert auf der SQL Server-Authentifizierung. Der Zugang zum SQL Server erfolgt über die Anmeldungen WaWiMa und WaWiPersonal. Ein Anwender braucht lediglich das Kennwort zu einer der beiden Anmeldungen und schon kann er mit den entsprechenden Rechten auf die Daten des SQL Servers zugreifen. Einen direkten Bezug zum tatsächlichen Anwender gibt es bei dieser Art der Authentifizierung nicht.
Das ist bei der Windows-Authentifizierung anders. Hier müssen Sie keinen Anmeldenamen mitsamt Kennwort anlegen, sondern sie verweisen lediglich auf das Windows-Benutzerkonto des Anwenders. Diese so erstellte Anmeldung ordnen Sie dann wie gewohnt der Datenbank zu. Dem dadurch in der Datenbank erstellten Benutzer erteilen Sie dort die Rechte über die Datenbankrollen. Es ändert sich also lediglich die Authentifizierung am SQL Server, die Autorisierung an der Datenbank und die darauf folgende Rechtevergabe bleibt gleich.
Nur haben Sie weniger Aufwand bei der Verwaltung der Anmeldungen und durch den Wegfall der Kennwörter erhalten Sie mehr Sicherheit. Mehr noch, denn durch den Verweis zum Windows-Benutzerkonto erfolgt der Datenzugriff immer mit direktem Bezug zum Anwender. Ein anonymer Zugriff ist nicht mehr möglich. Sie sehen, die Windows-Authentifizierung ist einfach und effektiv.
Sie kennen die Windows-Authentifizierung bereits von Ihrem Windows-Benutzerkonto. Das haben Sie bei der Installation des SQL Servers als Anmeldung zugeordnet. Sie finden es im SQL Server Management Studio unter Sicherheit|Anmeldungen. Diese Anmeldung ist Mitglied der Serverrolle sysadmin und bietet Ihnen somit alle Rechte innerhalb Ihres SQL Servers, weshalb sie sich nicht für einen adäquaten Test der Rechtevergabe eignet. Dazu benötigen Sie ein weiteres Windows-Benutzerkonto.
Ein Windows-Benutzerkonto
Möglicherweise arbeiten Sie mit Ihrem Rechner in einer Windows-Domäne und Ihr Windows-Benutzerkonto wird über ein Active Directory verwaltet. Vielleicht aber testen Sie die Beispiele dieser Beitragsreihe in einer Entwicklungsumgebung mit einem lokalen Windows-Benutzerkonto. Da das Anlegen eines Windows-Benutzerkontos im Active Directory an fehlenden Rechten oder mangelnder Bereitschaft Ihres IT-Systemadministrators scheitern könnte, legen Sie für die weitere Vorgehensweise ein lokales Windows-Benutzerkonto an. Dazu klicken Sie mit der rechten Maustaste auf das Windowslogo in der Taskleiste und wählen den Eintrag Computerverwaltung (siehe Bild 1). In der Computerverwaltung erweitern Sie auf der linken Seite den Ordner Lokale Benutzer und Gruppen.
Bild 1: Start der Computerverwaltung
Nach einem Rechtsklick auf den Unterordner Benutzer öffnen Sie mit dem Eintrag Neuer Benutzer den gleichnamigen Dialog. Hier geben Sie als Benutzernamen Bienlein ein. Anschließend sichern Sie das Benutzerkonto mit einem Kennwort in den Eingabefeldern Kennwort und Kennwort bestätigen. Eine Neuvergabe des Kennworts bei der ersten Verwendung des Windows-Benutzerkontos ist nicht erforderlich. Es handelt sich schließlich um ein Testkonto, dass Sie selbst verwenden. Daher können Sie die Option Benutzer muss Kennwort bei der nächsten Anmeldung ändern deaktivieren. Mit einem Klick auf Erstellen wird das neue Windows-Benutzerkonto angelegt (siehe Bild 2).
Bild 2: Windows-Benutzer Bienlein
Glückwunsch. Nun haben Sie auf Ihrem Rechner einen virtuellen Anwender namens Bienlein. Beenden Sie den Dialog mit der Schaltfläche Schließen.
Die Anmeldung Bienlein
Im nächsten Schritt erstellen Sie für das Windows-Benutzerkonto Bienlein eine Anmeldung in Ihrem SQL Server. Starten Sie das SQL Server Management Studio und melden Sie sich an der SQL Server-Instanz mit Ihrem Windows-Benutzerkonto oder einer anderen Anmeldung mit administrativen Rechten an.
Im SQL Server Management Studio navigieren Sie im Objekt-Explorer zum Ordner Sicherheit und erweitern dort den Unterordner Anmeldungen. Wählen Sie in dessen Kontextmenü den Eintrag Neue Anmeldung (siehe Bild 3) und klicken Sie in dem darauffolgenden Dialog auf die Schaltfläche Suchen.
Bild 3: Neue Anmeldung im SQL Server
In dem Auswahlfenster Benutzer oder Gruppe auswählen legen Sie den Verweis zu dem Windows-Benutzerkonto Bienlein fest. Der schnellste Weg ist die direkte Eingabe des Windows-Benutzerkontos und einem anschließenden Klick auf Namen überprüfen. Ist die Eingabe korrekt, wird diese durch Ihren Rechnernamen ergänzt (siehe Bild 4). Mit einem Klick auf OK übernehmen Sie die Auswahl.
Bild 4: Anmeldung mit Windows-Authentifizierung
Die Windows-Benutzerkonten Ihrer Domäne werden Sie über diesen Weg nicht finden. Hierfür müssen Sie in dem Auswahlfenster Benutzer oder Gruppe auswählen zunächst über die Schaltfläche Pfade den Suchpfad zu Ihrer Domäne festlegen. Anschließend können Sie wie oben beschrieben das Benutzerkonto aus Ihrem Active Directory auswählen.
Sie haben es bestimmt bemerkt. Die Option Windows-Authentifizierung ist im Dialog standardmäßig aktiviert. Aus gutem Grund. Schließlich empfiehlt Microsoft diese Authentifizierungsmethode. Die SQL Server-Authentifizierung hingegen sollte nur in Ausnahmefällen verwendet werden. Zum Beispiel, wenn für den Betrieb der Client-Applikation keine Windows-Benutzerkonten verfügbar sind.
Die weiteren Schritte sind Ihnen von den beiden Anmeldungen WaWiMa und WaWiPersonal bekannt. Als Erstes weisen Sie der neuen Anmeldung in der Auswahlliste Standarddatenbank die Datenbank WaWi_SQL zu. Sollte mit einer Client-Applikation eine Verbindung zum SQL Server ohne die explizite Angabe einer Datenbank erfolgen, wird bei dieser Anmeldung immer die Datenbank WaWi_SQL verwendet.
In der Seite Benutzerzuordnung autorisieren Sie die Anmeldung für den Zugriff auf die Datenbanken. Hierzu wählen Sie im oberen Bereich die Datenbank WaWi_SQL aus. Durch diese Auswahl wird in der Datenbank ein Benutzer erstellt. Den Namen dieses Benutzers sehen Sie neben der gewählten Datenbank in der Spalte Benutzer.
Zwar können Sie den Namen ändern, es ist jedoch nicht unbedingt empfehlenswert. Eines der obersten Gebote der Security ist die Einfachheit. Gestalten Sie die Vergabe und Pflege von Zugriffsberechtigungen so einfach wie möglich. Mit einem von der Anmeldung abweichenden Benutzernamen erhöhen Sie nur den Aufwand. Bei einer Änderung der Zugriffsrechte dieses Benutzers müssten Sie immer erst einmal nachschauen, zu welcher Windows-Authentifizierung er letztendlich gehört.
Ein Standardschema brauchen Sie nicht anzugeben. Ohne Angabe wird das Schema dbo verwendet. Die Bedeutung dieses Schemas sowie die Vorteile eigener Schemata ist das Thema einer der nächsten Beiträge.
Die Zugriffsrechte des neuen Benutzers legen Sie im unteren Bereich des Dialogs fest. Aktivieren Sie die Datenbankrollen db_datareader, db_datawriter und edb_execute (siehe Bild 5). Mit dieser Auswahl darf der Benutzer die Daten aller Tabellen lesen und ändern sowie alle gespeicherten Prozeduren ausführen. Die Zuordnung zur Datenbankrolle public können Sie nicht ändern. Jeder Benutzer ist hier standardmäßig Mitglied. Die Möglichkeiten und vor allem die Gefahren dieser Datenbankrolle lernen Sie im nächsten Beitrag kennen.
Bild 5: Benutzerzuordnung einer Anmeldung
Soweit so gut. Mit einem Klick auf OK legen Sie die neue Anmeldung an. Im Ordner Anmeldungen unter Sicherheit sehen Sie den neuen Eintrag Bienlein, wobei dem Namen Bienlein die Bezeichnung Ihres Rechners vorangestellt ist. Der Einfachheit halber wird im weiteren Text nur der Name des Windows-Benutzerkontos verwendet und auf den Hinweis des Rechnernamens verzichtet.
Mit der Anmeldung wurde der zugehörige Benutzer in der Datenbank WaWi_SQL erstellt. Wechseln Sie zur Datenbank WaWi_SQL und erweitern Sie dort den Ordner Sicherheit. Der Unterordner Benutzer listet nun neben den bekannten Einträgen WaWiMa und WaWiPersonal den neuen Benutzer Bienlein auf (siehe Bild 6).
Bild 6: Datenbankbenutzer Bienlein
Frau Bienlein arbeitet im Vertrieb. Daher soll sie dieselben Rechte erhalten wie der Benutzer WaWiMa. Diesem wird aktuell der Zugriff auf die Tabellen und gespeicherten Prozeduren der Personalabteilung verweigert. Um diese Einschränkungen festzulegen, öffnen Sie mit einem Doppelklick auf den Eintrag Bienlein den Dialog Datenbankbenutzer. Auf der Seite Sicherungsfähige Elemente legen Sie die Rechte für einzelne Tabellen und gespeicherte Prozeduren fest. Zur Auswahl dieser Objekte gibt es mehrere Wege. Einer dieser Wege erfolgt über das Schema. Klicken Sie auf Suchen und aktivieren Sie im Auswahlfenster Objekte hinzufügen die Option Alle Objekte, die dem Schema angehören (siehe Bild 7). Unter Schemaname wählen Sie das Schema dbo und bestätigen dies mit einem Klick auf OK.
Bild 7: Auswahl der Objekte nach Schema
Der Dialog Datenbankbenutzer listet nun unter Sicherungsfähige Elemente alle Objekte der Datenbank vom Schema dbo auf. Dort markieren Sie die Tabelle Bewerber und aktivieren im unteren Bereich in der Zeile Aktualisieren die Option Verweigern (siehe Bild 8). Mit den Rechten zur gespeicherten Prozedur pSelectGeburtstagsliste verfahren Sie ähnlich. Sie wählen die gespeicherte Prozedur im oberen Bereich aus und aktivieren dann im unteren Bereich in der Zeile Ausführen die Option Verweigern.
Bild 8: Rechtevergabe eines Benutzers
Das war noch nicht alles. Sie müssen noch weitere Zugriffsrechte verweigern. Um Ihnen die umständlichen Klicks zu ersparen und um gleichzeitig eine Dokumentation zu dieser Rechtevergabe zu erhalten, wählen Sie im oberen Teil des Dialogs unter Skript den Eintrag Skript für Aktion in Fenster “Neue Abfrage” schreiben. Das SQL Server Management Studio zeigt Ihnen danach die T-SQL-Befehle zur Rechtevergabe in einer neuen Registerkarte. Genau hier werden Sie die Rechtevergabe vervollständigen. Doch vorher beenden Sie den Dialog Datenbankbenutzer mit einem Klick auf Abbrechen.
In der Registerkarte ergänzen Sie diese Zeile mit den Befehlen SELECT, INSERT und DELETE:
DENY UPDATE ON [dbo].[Bewerber] TO [Ihr Rechnername\Bienlein]
Danach sieht die Zeile wie folgt aus:
DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Bewerber] TO [Ihr Rechnername\Bienlein]
Danach kopieren Sie die Zeile und fügen Sie zweimal in das Skript ein. Ersetzen Sie in der ersten eingefügten Zeile den Namen der Tabelle mit Mitarbeiter und in der zweiten mit Stellen:
DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Mitarbeiter] TO [Ihr Rechnername \Bienlein] DENY SELECT, INSERT, UPDATE, DELETE ON [dbo].[Stellen] TO [Ihr Rechnername \Bienlein]
Die nächsten drei Zeilen mit GO, USE WaWi_SQL und einem weiteren GO sind für das Skript nicht erforderlich. Entfernen Sie diese Zeilen und ergänzen Sie anschließend das Skript mit entsprechenden Hinweisen und Kommentaren. Heraus kommt ein T-SQL-Skript wie in Bild 9, das Sie in Ihrer Dokumentation zur Rechtevergabe speichern. Mit einem Klick auf die Schaltfläche Ausführen erweitern Sie die Zugriffsrechte des Benutzers Bienlein.
Bild 9: Rechtevergabe per T-SQL
Wobei es sich bei dem Erweitern hier eher um ein Einschränken handelt. Grundsätzlich besitzt der Benutzer Bienlein durch die Zuordnung zu den Datenbankrollen db_datareader, db_datawriter und edb_execute Lese- und Schreibrechte an allen Tabellen der Datenbank sowie das Recht zum Ausführen aller gespeicherten Prozeduren. Der Zugriff auf die Tabellen Bewerber, Mitarbeiter, Stellen und der gespeicherten Prozedur pSelectGeburtstagsliste wird ihm jedoch durch das Recht DENY explizit verweigert – und dieses Recht steht über allen anderen.
Zur Kontrolle öffnen Sie erneut den Dialog Datenbankbenutzer mit einem Doppelklick auf den Eintrag Bienlein. Dieser zeigt Ihnen nun die erteilten Rechte in der Seite Sicherungsfähige Elemente (siehe Bild 10). Die zugeordneten Datenbankrollen sehen Sie in der Seite Mitgliedschaft.
Bild 10: Verweigerter Zugriff für Bienlein
Mit der Rechtevergabe des Benutzers ist das Erstellen der Anmeldung vollständig. Die neue Anmeldung basiert auf einer Windows-Authentifizierung, in diesem Fall auf dem Windows-Benutzerkonto Bienlein. Jetzt ist noch die Beispielapplikation an die neue Authentifizierungsmethode anzupassen.
Access und die Windows-Authentifizierung
Die Authentifizierung am SQL Server findet in der Beispielapplikation mit der Funktion fTabellenEinbinden statt. Diese ermittelt über die Access-Abfrage Anmeldedaten die zum aktuellen Anwender passende SQL Server-Anmeldung. Für die Mitarbeiter im Vertrieb ist das die Anmeldung WaWiMa, für die Kollegen in der Personalabteilung die Anmeldung WaWiPersonal. Die Zuordnungen wie die Anmeldedaten sind in den Tabellen Benutzer und Datenquellen hinterlegt. Zum Schutz dieser Daten und insbesondere der dort gespeicherten Kennwörter sind beide Tabellen als Systemobjekte definiert und somit nicht ohne weiteres sichtbar.
Der ganze Aufwand ist nur zum Schutz der Kennwörter zu den Anmeldungen WaWiMa und WaWiPersonal erforderlich. Diese dürfen lediglich den Entwicklern der Applikation beziehungsweise den Datenbankadministratoren bekannt sein. Den Anwendern und vor allem möglichen Angreifern soll das unerlaubte Ermitteln und Einsetzen dieser Kennwörter so schwer wie möglich gemacht werden.
Wobei letztere wohl eher mit einem Texteditor direkt in die ACCDB schauen. Was auf diesem Weg dort alles zu sehen ist, haben Sie im letzten Beitrag erfahren.
Mit der Windows-Authentifizierung fällt der komplette Aufwand weg. Das Speichern von Kennwörtern ist nicht mehr erforderlich. Die Zugriffsrechte ergeben sich durch das aktuell verwendete Windows-Benutzerkonto des Anwenders. Frau Bienlein greift nun mit der zu ihrem Windows-Benutzerkonto eingerichteten Anmeldung auf die Datenbank WaWi_SQL zu. Damit diese Art der Anmeldung funktioniert, muss die Verbindungszeichenfolge in der Beispielapplikation angepasst werden.
Öffnen Sie die Beispielapplikation WaWi v2 und wechseln Sie zur Funktion fOdbcPerTabelle im Modul OBDC. Hier wird die Verbindungszeichenfolge zusammengesetzt. Die nun anstehenden Änderungen werden die Funktion um einiges verkürzen. Es beginnt mit der Quelle der einzelnen Bestandteile einer Verbindungszeichenfolge, der Abfrage Anmeldedaten. Diese liefert die Bezeichnung des SQL Servers, den Namen der Datenbank sowie die zum aktuellen Anwender passende Anmeldung inklusive des Kennworts. Da die Anmeldedaten nicht mehr benötigt werden, ändern Sie in der folgenden Zeile die Quelle des Recordsets von Anmeldedaten in Datenquellen.
Set rsVerbindung = CurrentDb.OpenRecordset("Datenquellen", dbOpenSnapshot)
Durch den Wegfall der Anmeldedaten sind die Variablen strBenutzer und strKennwort ebenfalls nicht mehr notwendig. Daher löschen Sie die Deklaration der Variablen sowie diese beiden Zeilen:
If IsNull(rsVerbindung("Benutzer")) Then boKomplett = False If IsNull(rsVerbindung("Kennwort")) Then boKomplett = False
Aus dem gleichen Grund trennen Sie sich auch von diesen Zeilen:
";UID=" & rsVerbindung("Benutzer") & _
";PWD=" & fKennwortLesen(rsVerbindung("Kennwort"))
Jetzt ändern Sie den Eintrag Trusted_Connection=No in Trusted_Connection=Yes. Durch diesen Parameter wird bei der Verbindung zum SQL Server die aktuelle Windows-Anmeldung des Anwenders übergeben. Das Erstellen der Verbindungszeichenfolge sieht nun so aus:
''Datenquelle ermitteln Set rsVerbindung = CurrentDb.OpenRecordset( "Datenquellen", dbOpenSnapshot) If Not rsVerbindung.EOF Then ''Inhalte prüfen If IsNull(rsVerbindung("Server")) Then boKomplett = False If IsNull(rsVerbindung("Datenbank")) Then boKomplett = False ''Anmeldedaten vollständig If boKomplett = True Then ''Connection definieren fOdbcPerTabelle = _ "ODBC;DRIVER=ODBC Driver 17 for SQL Server" _ & ";Trusted_Connection=Yes" & _ ";Server=" & rsVerbindung("Server") & _ ";Database=" & rsVerbindung("Datenbank") End If Else ''Keine Anmeldedaten gefunden boKomplett = False End If
Natürlich könnte der Name des SQL Servers und der der Datenbank direkt in der Funktion eingetragen werden. Dadurch wäre die lokale Tabelle Datenquellen ebenso hinfällig. Aber warum sollten Sie auf diesen Komfort verzichten wollen Über die beiden Werte lässt sich die Access-Applikation recht einfach auf einen anderen SQL Server oder eine andere Datenbank umschalten. So sind Sie zum Beispiel in der Lage schnell zwischen Entwicklungsumgebung und Produktivumgebung zu wechseln. Dabei kann die Datenbank zur Entwicklungsumgebung unter einem anderen Namen im gleichen SQL Server liegen oder unter dem Originalnamen in einer anderen SQL Server-Instanz.
Fehlt der Name des SQL Servers beziehungsweise der Datenbank, erhalten Sie durch die Messagebox am Ende der Funktion eine Meldung. Diese können Sie noch etwas anpassen, denn sie prüft nicht mehr die Anmeldedaten, sondern lediglich die Verbindungsdaten:
''Verbindungsdaten unvollständig If boKomplett = False Then MsgBox "Die Verbindungsdaten sind nicht vollständig erfasst." & vbCrLf & "Bitte ergänzen Sie die fehlenden Informationen.", vbCritical, CurrentDb.Properties!AppTitle End If
Soweit zum Datenzugriff per ODBC der für die eingebundenen Tabellen und die Pass Through-Abfragen relevant ist. Die Beispielapplikation nutzt zusätzlich die Datenzugriffsmethode ADO und diese wiederum verwendet OLE DB für den Zugriff auf die Daten. Es ist also eine weitere Anpassung erforderlich.
Dazu wechseln Sie zur Funktion fAdoPerTabelle im Modul ADO. Die nun anstehenden Änderungen sind ähnlich der eben durchgeführten. Als erstes ändern Sie hier ebenfalls die Quelle des Recordsets in Datenquellen.
Set rsVerbindung = CurrentDb.OpenRecordset( "Datenquellen", dbOpenSnapshot)
Danach entfernen Sie die Deklarationen der Variablen strBenutzer und strKennwort sowie die folgenden Zeilen:
";User ID=" & rsVerbindung("Benutzer") & _
";Password=" & fKennwortLesen(rsVerbindung("Kennwort"))
Anschließend ergänzen Sie den Aufbau der Verbindungszeichenfolge mit dem Parameter Integrated Security. Mit diesem Parameter findet bei OLE DB die Übergabe der aktuellen Windows-Anmeldung statt. Der Parameter akzeptiert als Wert sowohl SSPI wie auch Yes. Sie sollten an dieser Stelle SSPI verwenden, denn der Wert Yes wird nicht von allen OLE DB-Treibern unterstützt. SSPI steht für Security Support Provider Interface. Diese Schnittstelle ermöglicht die Verwendung von Funktionen verfügbarer Sicherheitsmodelle, unter anderem das Prüfen einer Authentifizierung. Mit dem Eintrag Integrated Security haben die Zeilen zu den Parametern User ID und Password keine Bedeutung mehr. Weshalb Sie die beiden Zeilen nun löschen. Danach sollte der Aufbau der Verbindungszeichenfolge so aussehen:
fAdoPerTabelle = "Provider=MSOLEDBSQL;Integrated Security=SSPI;Server=" & rsVerbindung("Server") & ";Database=" & rsVerbindung("Datenbank")
Zum Abschluss passen Sie noch die Meldung am Ende der Funktion an. Am besten nutzen Sie denselben Text wie in der Funktion fOdbcPerTabelle.
Nach diesen Änderungen wird weder der Anmeldename noch das Kennwort zum Erstellen der Verbindungszeichenfolgen verwendet. Daher werden Sie die Quelle dieser Informationen nun ebenfalls löschen. Beide sind in der Tabelle Datenquellen hinterlegt. Bevor Sie die Tabelle ändern können, müssen Sie ihr zunächst den Status der Systemtabelle entziehen. Führen Sie dazu im VBA-Direktbereich die folgende Anweisung aus:
fTabelleAlsSystemObjekt "Datenquellen", False
Wiederholen Sie die Anweisung für die Tabelle Benutzer. Hier gibt es gleich eine weitere Änderung. Danach wechseln Sie zu Access in den Navigationsbereich und öffnen die Tabelle Datenquellen im Entwurfsmodus. Entfernen Sie die nicht mehr benötigten Spalten Benutzer und Kennwort und speichern Sie die neue Struktur der Tabelle. Anschließend öffnen Sie die Datenblattansicht. Ohne die Information der Anmeldedaten sehen Sie jetzt zwei Datensätze mit gleichem Inhalt. Beide zeigen die Bezeichnung zu Ihrem SQL Server und zur Datenbank WaWi_SQL. Löschen Sie einen der Einträge. Und wenn Sie schon beim Löschen sind, entfernen Sie gleich noch die Tabelle Benutzer und die Access-Abfrage Anmeldedaten. Jegliche Information dieser Tabelle sowie der Abfrage ist für die Windows-Authentifizierung irrelevant.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
