<\/p>\n
Bernd Jungbluth – Horn<\/b><\/p>\n
Die aktuelle Rechtevergabe der Beispielapplikation erlaubt den Anwendern eine Anmeldung am SQL Server und den Zugang zur Datenbank WaWi_SQL. Innerhalb der Datenbank ist ihnen das Lesen und Schreiben der Daten sowie das Ausführen von Gespeicherten Prozeduren erlaubt. Ein solch pauschales Berechtigungskonzept beinhaltet viel zu viele Rechte. Den Anwendern stehen alle Daten zur Verfügung – sogar die Daten, die sie besser nicht lesen oder ändern sollten. Um das zu verhindern, bedarf es einer detaillierteren Rechtevergabe. Eine mögliche Variante zeigt Ihnen dieser Beitrag.<\/b><\/p>\nWarnung<\/h2>\n
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!<\/p>\n
Das derzeitige Berechtigungskonzept basiert auf der SQL Server-Anmeldung WaWiMa<\/b>. Mit dieser Anmeldung stellt die Access-Applikation WaWi <\/b>die Verbindung zur SQL Server-Datenbank WaWi_SQL <\/b>her. Ob nun eine Mitarbeiterin aus dem Vertrieb oder ein Mitarbeiter aus der Personalabteilung mit der Access-Applikation WaWi <\/b>arbeitet, der Datenzugriff erfolgt immer über die gleiche Anmeldung. Die Zugriffsrechte werden folglich nicht über den Anwender, sondern über die Applikation gesteuert.<\/p>\n
Welcher Anwender in der Applikation mit welchen Daten arbeiten darf, wird beim Start der Applikation bestimmt. Im Start-Formular ermittelt die VBA-Funktion fBerechtigungen <\/b>den aktuellen Windows-Benutzer und aktiviert entweder die Schaltflächen für den Vertrieb oder die für die Personalverwaltung.<\/p>\n
Auf diese Weise wird verhindert, dass ein Mitarbeiter des Vertriebs die Funktionen der Personalverwaltung nutzen kann. Allerdings schränkt dies nur den Zugriff auf die Funktionen ein, nicht aber den auf die Daten. Die Zugriffssteuerung findet ausschließlich im Start-Formular statt. Umgeht ein Anwender dieses Formular, stehen ihm alle Daten der Datenbank WaWi_SQL <\/b>zur Verfügung. Dazu gehören auch die Daten der Personalverwaltung. <\/p>\n
Das gilt es zu vermeiden. Dazu wird das Berechtigungskonzept um eine weitere Anmeldung im SQL Server ergänzt. Das Ziel ist eine Rechtevergabe auf Abteilungsebene.<\/p>\n
Das neue Berechtigungskonzept enthält zwei SQL Server-Anmeldungen, eine für die Installationen der Access-Applikation WaWi<\/b> im Vertrieb und eine weitere für die Installationen in der Personalabteilung. Zur Umsetzung des neuen Berechtigungskonzepts ist zuerst eine Anmeldung im SQL Server anzulegen und der Datenbank WaWi_SQL <\/b>zuzuordnen.<\/p>\n
Der dabei erstellte Benutzer erhält in der Datenbank pauschale Lese- und Schreibrechte sowie das Recht zum Ausführen aller gespeicherten Prozeduren. Auf den Rechnern der Personalabteilung wird dann in den bestehenden ODBC-Datenquellen die neue Anmeldung eingetragen. Abschließend sind in der Access-Applikation die Tabellen neu einzubinden und die Verbindungseigenschaften der Pass-Through-Abfragen sowie die der ADO-Zugriffe anzupassen. <\/p>\n
Auf den Rechnern des Vertriebs sind keine Änderungen notwendig. Die Verbindung von der Access-Applikation zur SQL Server-Datenbank erfolgt dort weiterhin über die Anmeldung WaWiMa<\/b>. Allerdings wird diese in ihren Rechten eingeschränkt. Die Zugriffe auf die für die Personalverwaltung relevanten Tabellen und gespeicherten Prozeduren werden verweigert. Das Einschränken dieser Rechte findet im SQL Server statt.<\/p>\n
Doch der Reihe nach. Als Erstes erstellen Sie die Beispielumgebung mit der SQL Server-Datenbank WaWi_SQL<\/b>, der gleichnamigen ODBC-Datenquelle und der Access-Applikation WaWi<\/b>. Die hierzu notwendigen Schritte sehen Sie in der Installationsanleitung am Ende dieses Beitrags.<\/p>\n
Danach legen Sie die neue SQL Server-Anmeldung an. Öffnen Sie dazu das SQL Server Management Studio und verbinden Sie sich mit Ihrem SQL Server. Im Objekt-Explorer erweitern Sie den Ordner Sicherheit <\/b>und wählen im Kontextmenü des Unterordners Anmeldungen <\/b>den Eintrag Neue Anmeldung <\/b>(siehe Bild 1). Im Dialog Anmeldung – Neu <\/b>geben Sie der Anmeldung den Namen WaWiPersonal <\/b>und aktivieren die Option SQL Server-Authentifizierung<\/b>.<\/p>\n
<\/p>\n
Bild 1: Der Weg zur neuen Anmeldung<\/span><\/b><\/p>\n Das Kennwort zur Anmeldung tragen Sie in den beiden Eingabefeldern Kennwort <\/b>und Kennwort bestätigen <\/b>ein. Vergeben Sie ein gutes Kennwort. Eines, das nicht leicht zu erraten ist. Immerhin soll es die Daten der Personalverwaltung vor unbefugtem Zugriff schützen. Stellen Sie sich nur einmal die Diskussionen vor, wenn unerlaubterweise die Gehälter der Mitarbeiter veröffentlicht würden!<\/p>\n Die Option Kennwortrichtline <\/b>unterstützt Sie bei der Vergabe des Kennworts. Ist die Option aktiviert, muss das Kennwort den in Ihrem Unternehmen gültigen Richtlinien zur Vergabe von Kennwörtern entsprechen. Sollten Sie keine Kennwortrichtlinien definiert haben, können Sie das Kennwort nach einem Muster erstellen oder Sie lassen sich eines in einem Passwort-Safe generieren. Ein mögliches Muster wie die Vor- und Nachteile beider Vorgehensweisen wurden im dritten Teil dieser Beitragsreihe beschrieben. <\/p>\n Kennwörter sollten Sie regelmäßig ändern. Bei aktivierter Option Ablauf des Kennworts erzwingen <\/b>erinnert Sie der SQL Server gemäß Ihrer Kennwortrichtlinien an diese Empfehlung.<\/p>\n Diese Art der Erinnerung kann sich jedoch schnell kontraproduktiv auswirken. Ist das Kennwort abgelaufen, verlangt der nächste Anmeldeversuch die Vergabe eines neuen Kennworts. Ein neues Kennwort ist schnell vergeben.<\/p>\n Das ist aber nur ein Teil der Aufgabe. Danach sind noch alle Client-Applikationen, die diese Anmeldung verwenden, an das neue Kennwort anzupassen. Je nach Anzahl der Client-Applikationen ist das schnell ein größerer Aufwand. Am besten deaktivieren Sie die Option Ablauf des Kennworts erzwingen<\/b>. Das spart Ihnen unangenehme Überraschungen. Legen Sie sich stattdessen besser einen Termin an, der Sie an die Vergabe eines neuen Kennworts erinnert.<\/p>\n Das Entfernen des Häkchens in der Option Ablauf des Kennworts erzwingen <\/b>deaktiviert sinnvollerweise ebenso die Option Benutzer muss das Kennwort bei der nächsten Anmeldung ändern<\/b>.<\/p>\n Es macht keinen Unterschied, ob das Kennwort beim Ablauf oder bei der nächsten Anmeldung geändert werden muss. Mit der Kennwortänderung alleine ist es nicht getan. Es hat immer eine Anpassung der abhängigen Client-Applikationen zur Folge.<\/p>\n Als Nächstes legen Sie die Standarddatenbank der Anmeldung fest. Die Standarddatenbank wird verwendet, wenn beim Aufbau der Verbindung die Datenbank nicht explizit angegeben ist. Wählen Sie in der Auswahlliste Standarddatenbank <\/b>den Eintrag WaWi_SQL<\/b>.<\/p>\n Die Konfiguration der neuen Anmeldung wäre damit soweit abgeschlossen (siehe Bild 2). Dennoch sollten Sie nicht auf OK <\/b>klicken. In der Seite Benutzerzuordnung <\/b>können Sie jetzt nämlich direkt den zugehörigen Benutzer in der Datenbank WaWi_SQL <\/b>anlegen und ihm die entsprechenden Rechte geben.<\/p>\n Bild 2: Die Anmeldung WaWiPersonal<\/span><\/b><\/p>\n Wechseln Sie zur Seite Benutzerzuordnung <\/b>und wählen Sie im oberen Bereich die Datenbank WaWi_SQL <\/b>aus. Durch diese Auswahl wird der Benutzer WaWiPersonal <\/b>in der Datenbank erstellt. Im unteren Bereich geben Sie dem Benutzer die Zugriffsrechte.<\/p>\n Aktivieren Sie hierzu die Systemdatenbankrollen db_datareader <\/b>und db_datawriter <\/b>plus die Benutzerdatenbankrolle edb_execute <\/b>(siehe Bild 3). Diese Datenbankrolle wurde im vorheigen Beitrag dieser Reihe eingeführt (SQL Server-Security, Teil 4: Schutz mit Datenbankrollen<\/b>, www.access-im-unternehmen.de\/1274<\/b>).<\/p>\n Bild 3: Der Benutzer WaWiPersonal<\/span><\/b><\/p>\n Sie beinhaltet die Rechte zur Ausführung aller gespeicherten Prozeduren. Um die Datenbankrolle public <\/b>müssen Sie sich vorerst nicht kümmern. Hierbei handelt es sich um eine Standardzuordnung. Die Vorteile und vor allem die Nachteile dieser Datenbankrolle lernen Sie in einem der nächsten Beiträge kennen.<\/p>\n Ein Klick auf OK <\/b>erstellt zuerst die Anmeldung WaWiPersonal <\/b>und dann in der Datenbank WaWi_SQL <\/b>den zugehörigen Benutzer. Die Anmeldung sehen Sie im Unterordner Anmeldungen <\/b>des Ordners Sicherheit<\/b>. Den Benutzer finden Sie in der Datenbank WaWi_SQL<\/b>. Dort gibt es ebenfalls einen Ordner namens Sicherheit<\/b>. Dieser listet die Benutzer der Datenbank im Ordner Benutzer <\/b>auf.<\/p>\n Das Berechtigungskonzept ist nun um eine Anmeldung reicher. Mit dieser Anmeldung authentifiziert sich der Anwender am SQL Server. Die Anmeldung ist in der Datenbank WaWi_SQL <\/b>fest mit dem gleichnamigen Benutzer verbunden.<\/p>\n Diese Zuordnung autorisiert die Anmeldung und somit den Anwender für den Zugang zur Datenbank. Die Rechte für den Datenzugriff sind am Benutzer definiert. Dieser ist aktuell den Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute <\/b>zugeordnet. Der Anwender darf mit diesen Rechten in der Datenbank jegliche Daten lesen und schreiben sowie alle gespeicherten Prozeduren ausführen.<\/p>\n Soweit in Kurzform die Beschreibung der Anmeldung WaWiPersonal <\/b>innerhalb der mehrstufigen Sicherheitsarchitektur von SQL Server.<\/p>\n Das ist aber noch nicht alles. Schließlich erfolgt der Anmeldevorgang am SQL Server aktuell nicht durch den Anwender, sondern automatisch in der Access-Applikation WaWi<\/b>. Die muss jetzt noch an die neue Anmeldung angepasst werden.<\/p>\n In der Realität würden Sie nun in die Personalabteilung gehen und dort auf den einzelnen Rechnern die Access-Applikation mitsamt der ODBC-Datenquelle anpassen.<\/p>\n Um dieses Szenario nachzustellen, kopieren Sie die Access-Applikation WaWi <\/b>und geben der Kopie den Namen WaWi Personal<\/b>. Als nächstes ändern Sie die ODBC-Datenquelle WaWi_SQL<\/b>. Den ODBC-Datenquellen-Administrator starten Sie am besten über die Windows-Suche. Dazu drücken Sie die Windows-Taste und tippen ODBC<\/b>. Das Suchergebnis liefert Ihnen zwei Einträge. Wählen Sie je nach installierter Access-Version den Eintrag ODBC-Datenquellen (32-Bit) <\/b>oder ODBC-Datenquellen (64-Bit)<\/b>.<\/p>\n Im ODBC-Datenquellen-Administrator wechseln Sie zur Registerkarte System-DSN<\/b>, markieren dort die ODBC-Datenquelle WaWi_SQL <\/b>und klicken auf Konfigurieren<\/b>. Den ersten Schritt des Assistenten überspringen Sie mit der Schaltfläche Weiter<\/b>.<\/p>\n Im zweiten Schritt passen Sie die Anmeldedaten an. Geben Sie im Eingabefeld Anmelde-ID <\/b>den Namen der neuen Anmeldung und im Feld Kennwort <\/b>das zugehörige Kennwort ein (siehe Bild 4). Danach bestätigen Sie diesen sowie den nächsten Schritt des Assistenten mit einem Klick auf Weiter <\/b>und beenden die Konfiguration im letzten Schritt mit der Schaltfläche Fertig stellen<\/b>. <\/p>\n Bild 4: Ändern der ODBC-Datenquelle<\/span><\/b><\/p>\n Es folgt eine Zusammenfassung der Konfiguration und die Möglichkeit, die neuen Anmeldedaten zu testen. Sollte das Ergebnis nach einem Klick auf Datenquelle testen <\/b>nicht erfolgreich sein, haben Sie sich vielleicht beim Kennwort vertippt. In diesem Fall wiederholen Sie die eben beschriebenen Schritte. Nach einem erfolgreichen Test ist die Änderung der ODBC-Datenquelle abgeschlossen. <\/p>\n Soweit so gut. Die ODBC-Datenquelle verwendet nun die Anmeldung WaWiPersonal<\/b>. Jetzt passen Sie noch die Access-Applikation an die neue Anmeldung an. In der Realität wäre dies auf jedem Rechner der Personalabteilung erforderlich. In der Beispielumgebung öffnen Sie dazu die eben kopierte Access-Applikation WaWi Personal<\/b>. Dort sind die Tabellen noch mit der Anmeldung WaWiMa <\/b>eingebunden.<\/p>\n Aus diesem Grund entfernen Sie alle eingebundenen Tabellen und binden diese neu ein. Starten Sie über Externe Daten – Neue Datenquelle – Aus Datenbank – Aus SQL Server <\/b>den Dialog Externe Daten – ODBC-Datenbank <\/b>und aktivieren Sie dort die zweite Option.<\/p>\n Mit einem Klick auf OK <\/b>kommen Sie zum nächsten Dialog, in dem Sie in der Registerkarte Computerdatenquelle <\/b>die ODBC-Datenquelle WaWi_SQL <\/b>per Doppelklick auswählen. Nun geben Sie das Kennwort zur Anmeldung WaWiPersonal <\/b>ein und schließen den Vorgang mit OK <\/b>ab.<\/p>\n Als Ergebnis sehen Sie im Dialog Tabellen verknüpfen <\/b>alle Tabellen der SQL Server-Datenbank WaWi_SQL<\/b>. Aktivieren Sie die Option Kennwort speichern <\/b>und markieren Sie die Tabellen mit dem Präfix dbo<\/b>.<\/p>\n Ein Klick auf OK <\/b>übernimmt die Auswahl und liefert Ihnen vor dem Einbinden jeder Tabelle eine Meldung (siehe Bild 5). Bestätigen Sie diese Meldungen mit der Schaltfläche Kennwort speichern<\/b>, um die Anmeldedaten für den Datenzugriff in der Access-Datenbank zu hinterlegen. <\/p>\n Bild 5: Speichern des Kennworts<\/span><\/b><\/p>\n Die frisch eingebundenen Tabellen sind nun im Navigationsbereich zu sehen. Allerdings enthalten die Tabellen den Präfix dbo_<\/b>, was nicht den ursprünglich eingebundenen Tabellen entspricht. Dies korrigieren Sie mit der VBA-Funktion fTabellenUmbenennen<\/b>. Öffnen Sie mit der Tastenkombination Strg + G <\/b>den VBA-Direktbereich und führen Sie dort die Funktion aus. <\/p>\n Die zwei Pass Through-Abfragen der Access-Applikation verwenden aktuell noch die Anmeldung WaWiMa<\/b>. Mit der VBA-Funktion fPassThroughVerbindungen <\/b>übertragen Sie die Anmeldedaten der eingebundenen Tabellen in die Verbindungszeichenfolgen der Pass Through-Abfragen. Führen Sie diese VBA-Funktion ebenfalls über den VBA-Direktbereich aus.<\/p>\n Es fehlt noch die Konfiguration für den Datenzugriff per ADO. Die hierzu notwendigen Daten sind in der lokalen Tabelle ADO <\/b>gespeichert. Diese Tabelle ist als Systemtabelle deklariert.<\/p>\n Um die Daten der Tabelle ändern zu können, müssen Sie die Deklaration zunächst entfernen. Dies übernimmt die VBA-Funktion fTabelleAlsSystemObjekt<\/b>, die Sie im VBA-Direktbereich wie folgt ausführen:<\/p>\n Der Navigationsbereich enthält jetzt die Tabelle ADO<\/b>. Öffnen Sie die Tabelle und passen Sie die Anmeldedaten in den Feldern Benutzer <\/b>und Kennwort <\/b>an die Anmeldung WaWiPersonal <\/b>an. Um die Tabelle wieder zu verstecken, ändern Sie im VBA-Direktbereich den Parameterwert False <\/b>in True <\/b>und führen Sie die VBA-Funktion erneut aus.<\/p>\n Mit dem Formular Start <\/b>können Sie die neue Anmeldung testen. Ein Klick auf die Schaltfläche Mitarbeiter <\/b>liefert ein Formular mit den Personaldaten. So soll es sein. Jetzt öffnen Sie noch das Formular Ansprechpartner<\/b>. Es zeigt Ihnen wie erwartet die Kontaktinformationen der Ansprechpartner. Der Test ist erfolgreich.<\/p>\n Mit den Rechten der Anmeldung WaWiPersonal <\/b>dürfen Sie in der Datenbank WaWi_SQL <\/b>die Daten aller Tabellen lesen und ändern sowie alle gespeicherten Prozeduren ausführen. <\/p>\n Somit wäre es den Mitarbeitern der Personalabteilung möglich, mit ihrer Version der Access-Applikation WaWi <\/b>auf die Daten des Vertriebs zuzugreifen. Natürlich könnte man dies mit einer weiteren Rechtevergabe verhindern. Warum aber sollte man den Aufwand betreiben Es ist bestimmt kein Sicherheitsrisiko, wenn ein Mitarbeiter der Personalabteilung die Kontaktinformationen der Ansprechpartner lesen kann.<\/p>\n Diese Argumentation sollten Sie mal mit Ihrem Datenschutzbeauftragten diskutieren. Er wird einige Einwände haben. Als Stichpunkte seien hier Zweckbindung und Privacy By Default genannt. Doch das ist ein Thema für einen späteren Beitrag. <\/p>\n <\/p>\n Bis jetzt bringt die Anmeldung WaWiPersonal <\/b>noch keine Vorteile. Schließlich unterscheiden sich die Rechte dieser Anmeldung nicht von denen der Anmeldung WaWiMa<\/b>. Ziel ist es, den Mitarbeitern des Vertriebs den Zugriff auf die Personaldaten zu verweigern. Dazu ändern Sie die Rechtevergabe zur Anmeldung WaWiMa<\/b>.<\/p>\n Die jetzt anstehenden Änderungen der Rechtevergabe sind überschaubar. Sie müssen weder die installierte Access-Applikation noch die ODBC-Datenquelle anpassen. Alle erforderlichen Schritte finden im SQL Server statt. Öffnen Sie dazu das SQL Server Management Studio.<\/p>\n Die Rechte für den Datenzugriff werden nicht an der Anmeldung WaWiMa<\/b>, sondern an dem zugehörigen Benutzer in der Datenbank WaWi_SQL <\/b>definiert. Diesen finden Sie im Objekt-Explorer unter Datenbanken – WaWi_SQL – Sicherheit – Benutzer<\/b>. Mit einem Doppelklick auf den Eintrag WaWiMa <\/b>öffnen Sie den Dialog Datenbankbenutzer<\/b>. <\/p>\n Aktuell ist der Benutzer WaWiMa <\/b>den Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute <\/b>zugeordnet. Dies erlaubt ihm den lesenden und schreibenden Zugriff auf alle Daten der Datenbank sowie das Ausführen aller gespeicherten Prozeduren.<\/p>\n Sie sehen diese Rechtevergabe auf der Seite Mitgliedschaft<\/b>. Um die relevanten Tabellen und gespeicherten Prozeduren für die Personaldaten von diesem pauschalen Zugriff auszuschließen, müssen Sie diesen Datenbankobjekten gesonderte Rechte vergeben.<\/p>\n Die Rechtevergabe an einzelnen Datenbankobjekten findet in der Seite Sicherungsfähige Elemente <\/b>statt. Dort legen Sie mit der Schaltfläche Suchen <\/b>zunächst eine Vorauswahl fest. Ein Klick auf diese Schaltfläche liefert Ihnen den Dialog Objekte hinzufügen<\/b>. Hier aktivieren Sie die Option Alle Objekte des Typs <\/b>und klicken auf OK<\/b>.<\/p>\n Im nächsten Dialog entscheiden Sie sich für die Objekttypen Tabellen <\/b>und Gespeicherte Prozeduren<\/b>. Nach Bestätigen dieser Auswahl sind Sie wieder zurück im Dialog Datenbankbenutzer <\/b>und sehen im oberen Bereich alle Tabellen und gespeicherten Prozeduren der Datenbank. <\/p>\n Markieren Sie die Tabelle Bewerber <\/b>und aktivieren Sie im unteren Bereich die Option Verweigern <\/b>in den Zeilen Aktualisieren<\/b>, Auswählen<\/b>, Einfügen <\/b>und Löschen <\/b>(siehe Bild 6). Durch diese Auswahl wird dem Benutzer WaWiMa <\/b>der lesende und schreibende Zugriff auf die Tabelle Bewerber <\/b>verweigert.<\/p>\n Bild 6: Verweigerter Zugriff auf eine Tabelle<\/span><\/b><\/p>\n Seine Mitgliedschaft in den Datenbankrollen db_datareader <\/b>und db_datawriter <\/b>erlaubt es dem Benutzer weiterhin alle Daten der Datenbank zu lesen und zu ändern – mit Ausnahme der Tabellen, bei denen ihm dies explizit verweigert wird. Das Recht Verweigern <\/b>steht über allen anderen Rechten. <\/p>\n Mit dieser Rechtevergabe ist sichergestellt, dass die Daten der Tabelle Bewerber <\/b>vom Benutzer WaWiMa <\/b>weder gelesen noch geschrieben werden können.<\/p>\n Dabei ist es egal, mit welcher Konstellation in Zukunft eine Erlaubnis für den Datenzugriff auf diese Tabelle erteilt wird. Solange der Benutzer das Recht Verweigern <\/b>in der oben beschriebenen Art und Weise besitzt, ist der Zugriff auf die Daten nicht erlaubt. <\/p>\n Es sei denn, Sie ordnen die zugehörige Anmeldung WaWiMa <\/b>der Serverrolle sysadmin <\/b>zu. Mit dieser Zuordnung geben Sie der Anmeldung administrative Rechte. Für Anmeldungen mit solchen Rechten gibt es im SQL Server keine Grenzen. Das Sie mit der Serverrolle sysadmin <\/b>sehr vorsichtig umgehen sollten, haben Sie bereits im dritten Beitrag erfahren.<\/p>\n Das Recht Verweigern <\/b>lässt sich auch bei den gespeicherten Prozeduren anwenden. Dazu markieren Sie im oberen Bereich die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>und aktivieren im unteren Bereich die Option Verweigern <\/b>in der Zeile Ausführen (siehe Bild 7). <\/p>\n Bild 7: Verweigertes Ausführen einer Gespeicherten Prozedur<\/span><\/b><\/p>\n Bei einer Rechtevergabe an Datenbankobjekten kommen je nach Anzahl der Tabellen und gespeicherten Prozeduren recht viele Klicks auf Sie zu.<\/p>\n Um diesen Aufwand zu reduzieren, bestätigen Sie den Dialog jetzt nicht mit OK<\/b>, sondern klicken auf die Schaltfläche Skript <\/b>in der Kopfzeile des Dialogs (siehe Bild 8).<\/p>\n Bild 8: Erstellen eines T-SQL-Skripts<\/span><\/b><\/p>\n Fast alle Eintragungen in den Dialogen des SQL Server Management Studios lösen beim Bestätigen entsprechende T-SQL-Anweisungen aus. Die Schaltfläche Skript <\/b>liefert Ihnen genau diese Anweisungen als SQL-Skript in einer Registerkarte. Hier können Sie die Anweisungen anpassen und erweitern. Doch vorher beenden Sie den Dialog Datenbankbenutzer <\/b>mit einem Klick auf Abbrechen<\/b>. <\/p>\n Die Registerkarte zeigt Ihnen fünf T-SQL-Anweisungen mit dem Befehl DENY<\/b>. DENY <\/b>steht für Verweigern. Ganz so detailliert müssen die T-SQL-Anweisungen allerdings nicht sein. Die vier Anweisungen zur Tabelle Bewerber <\/b>lassen sich in einer zusammenfassen:<\/p>\n Diese T-SQL-Anweisung verweigert dem Benutzer WaWiMa <\/b>an der Tabelle Bewerber <\/b>das Lesen der Daten per SELECT <\/b>und das Ändern der Daten per INSERT<\/b>, UPDATE <\/b>und DELETE<\/b>. Die ursprünglichen einzelnen Anweisungen zur Tabelle Bewerber <\/b>können Sie löschen.<\/p>\n Neben der Tabelle Bewerber <\/b>gibt es mit Mitarbeiter und Stellen noch zwei weitere Tabellen mit relevanten Personaldaten. Kopieren Sie die Zeile von oben und fügen Sie diese zweimal ein. Dann ändern Sie in der einen Zeile den Tabellennamen in Mitarbeiter <\/b>und in der anderen in Stellen<\/b>: <\/p>\n Das Skript enthält nun mit den drei Tabellen und der gespeicherten Prozedur pSelectGeburtstagsliste <\/b>alle relevanten Objekte.<\/p>\n Sie können das Skript mit Kommentaren zu dieser Rechtevergabe ergänzen und es in Ihrer Dokumentation speichern. Auf diese Weise haben Sie jederzeit die Information, wann und warum Sie die Rechte vergeben haben (siehe Bild 9).<\/p>\n Bild 9: T-SQL-Skript zum Ändern der Rechte<\/span><\/b><\/p>\n Mit einem Klick auf die Schaltfläche Ausführen <\/b>werden die Berechtigungen gemäß den T-SQL-Anweisungen erweitert. Ab jetzt ist der Anmeldung WaWiMa <\/b>der lesende und schreibende Zugriff auf die Daten der Tabellen Bewerber<\/b>, Mitarbeiter <\/b>und Stellen <\/b>sowie das Ausführen der gespeicherten Prozedur pSelectGeburtstagsliste <\/b>nicht mehr erlaubt. Für alle anderen Tabellen und gespeicherten Prozeduren gilt diese Einschränkung nicht. <\/p>\n Testen Sie es einmal. Starten Sie die Access-Applikation WaWi <\/b>und öffnen Sie das Formular Ansprechpartner<\/b>. Wie eben sehen Sie die Kontaktinformationen der Ansprechpartner. Das war zu erwarten.<\/p>\n Schließen Sie das Formular und klicken Sie auf die Schaltfläche Mitarbeiter<\/b>. Hier wird der Zugriff verweigert (siehe Bild 10). Dies entspricht den neuen Rechten. Die Mitarbeiter des Vertriebs sind nicht mehr in der Lage, die Personaldaten zu lesen oder zu ändern. <\/p>\n Bild 10: Verweigerter Zugriff auf die Tabelle Mitarbeiter<\/span><\/b><\/p>\n Sie wundern sich über das Ergebnis Ihre ODBC-Datenquelle enthält doch die Anmeldung WaWiPersonal<\/b>. Müssten dann nicht alle Daten lesbar sein Nein. Der Datenzugriff in der Access-Applikation WaWi <\/b>erfolgt über die Anmeldung WaWiMa<\/b>. Die Anmeldedaten dieser Anmeldung sind im Access-Frontend gespeichert.<\/p>\n Doch wie kommen diese Anmeldedaten in das Access-Frontend Wenn Sie der Installationsanleitung gefolgt sind, haben Sie als erstes die ODBC-Datenquelle WaWi_SQL <\/b>mit der Anmeldung WaWiMa <\/b>erstellt. Anhand dieser ODBC-Datenquelle folgte das Einbinden der Tabellen in die Access-Applikation WaWi<\/b>. Erinnern Sie sich an die Meldungen mit der Schaltfläche Kennwort <\/b>speichern Durch Bestätigen dieser Meldungen wurden die Anmeldedaten im Access-Frontend hinterlegt. Nach dem Ausführen der VBA-Funktionen war die Installation der Access-Applikation WaWi <\/b>abgeschlossen.<\/p>\n Erst danach kamen die Anpassungen für die Personalabteilung. In der ODBC-Datenquelle haben Sie die Anmeldung in WaWiPersonal <\/b>geändert, um sie dann in dem kopierten Access-Frontend WaWi Personal <\/b>einzusetzen.<\/p>\n Das Ändern der Anmeldedaten in der ODBC-Datenquelle hat auf die bereits gespeicherten Anmeldedaten der Access-Applikation WaWi <\/b>keine Auswirkung. Das ist jetzt kein Grund, die ODBC-Datenquelle zu löschen. Sie ist weiterhin ein wichtiger Bestandteil der Verbindungszeichenfolge. Unter anderem enthält sie den Namen des SQL Servers. <\/p>\n Im ersten Moment mag das etwas verwirrend sein, aber eigentlich ist es recht einfach. Beim Zugriff auf eine eingebundene Tabelle werden die im Access-Frontend gespeicherten Anmeldedaten verwendet. Die Anmeldedaten der ODBC-Datenquelle spielen in diesem Moment keine Rolle. Das gilt ebenso für Pass Through-Abfragen. Auch hier erfolgt der Datenzugriff über die dort gespeicherten Anmeldedaten. <\/p>\n „Es ist mal wieder Zeit für eine Gehaltserhöhung.“ freut sich Frau Bienlein und startet ihre Access-Datenbank. Sie öffnet die eingebundene Tabelle Mitarbeiter<\/b>, erhält aber anstelle der Daten nur eine Fehlermeldung. Das ist nicht unbedingt etwas Neues für Frau Bienlein. Mit Fehlermeldungen hatte sie an dieser Stelle schon öfter zu tun. Meist hat ein erneutes Einbinden der Tabelle das Problem gelöst.<\/p>\n Zuversichtlich löscht Sie die Tabelle Mitarbeiter <\/b>und öffnet über Externe Daten – Neue Datenquelle – Aus Datenbank – Aus SQL Server <\/b>den Dialog Externe Daten – ODBC-Datenquelle<\/b>. Dort aktiviert sie die zweite Option und klickt auf OK<\/b>. In den nächsten beiden Dialogen wählt sie zuerst die ODBC-Datenquelle WaWi_SQL <\/b>aus und gibt dann das Kennwort zur Anmeldung WaWiMa <\/b>ein.<\/p>\n Als Ergebnis sieht sie im Dialog Tabellen verknüpfen <\/b>alle Tabellen der Datenbank WaWi_SQL<\/b>. Alle Nein, auf den ersten Blick fehlt die Tabelle Mitarbeiter<\/b>. Frau Bienlein durchsucht die gesamte Auflistung, doch sie findet weder die Tabelle Mitarbeiter <\/b>noch die Tabelle Bewerber <\/b>(siehe Bild 11).<\/p>\n Bild 11: Fehlende Tabellen Mitarbeiter und Bewerber<\/span><\/b><\/p>\n Ob es am Kennwort liegt Das kann nicht sein. Es gab keine Fehlermeldung bei der Eingabe des Kennworts und die Auswahl von Tabellen ist ja grundsätzlich möglich. Aber wo sind die Tabellen Mitarbeiter <\/b>und Bewerber<\/b> Warum werden sie nicht aufgelistet Frau Bienlein beendet den Dialog mit Abbrechen <\/b>und klickt doppelt auf die noch eingebundene Tabelle Bewerber<\/b>.<\/p>\n Wieder erscheint eine Fehlermeldung (siehe Bild 12). Jetzt schaut sie sich die Fehlermeldung genauer an. Sie versteht allerdings nur das letzte Wort. Verweigert<\/b>. „Das war“s dann wohl mit meinen Gehaltserhöhungen.“ kapituliert Frau Bienlein und schließt enttäuscht ihre Access-Datenbank.<\/p>\n Bild 12: Verweigerter Zugriff für Frau Bienlein<\/span><\/b><\/p>\n Als Entschädigung braucht sie erst mal einen Kaffee. In der Küche trifft sie zwei Kollegen aus der Personalabteilung. Die beiden tauschen ihren Frust über die Access-Applikation WaWi <\/b>aus. Gestern wurde eine neue Version installiert und erst seit einer Stunde lässt sich die Applikation wieder starten.<\/p>\n Angeblich lag es an einer neuen Anmeldung. Eine Anmeldung speziell für die Personalverwaltung. Für die beiden Kollegen unverständlich, startet die Applikation doch ohne Eingabe irgendwelcher Anmeldedaten. Frau Bienlein wartet scheinbar teilnahmslos auf ihren Kaffee. Insgeheim aber hört sie sehr aufmerksam zu. Eine neue Version mit einer eigenen Anmeldung Ist das der Grund, warum sie die Tabelle Mitarbeiter <\/b>nicht mehr findet Aber wieso hat sie die neue Version nicht erhalten <\/p>\n Zurück an ihrem Arbeitsplatz ruft sie in der IT-Abteilung an. Sie erklärt dem IT-Mitarbeiter, dass sie eben von den Problemen mit der neuen Version gehört hat und bittet ihn mit der Auslieferung dieser Version noch etwas zu warten.<\/p>\n Sie hätte aktuell viel zu viel zu tun und kann sich keine Verzögerungen erlauben. Der IT-Mitarbeiter beruhigt Frau Bienlein. Die neue Version ist nur für die Personalabteilung. Außerdem hat sich in der Applikation selbst nichts geändert. Es gibt lediglich eine neue Anmeldung. <\/p>\n Frau Bienlein bedankt sich und beendet das Gespräch. Es scheint tatsächlich an der neuen Anmeldung zu liegen. Doch wie soll sie nur an das Kennwort dieser Anmeldung kommen Die Mitarbeiter der Personalabteilung braucht sie nicht zu fragen. Deren Version der Access-Applikation verlangt ebenso wenig die Eingabe eines Kennworts wie ihre Version im Vertrieb.<\/p>\n Ob die Anmeldung automatisch erfolgt Dann müssten die Anmeldedaten doch irgendwo gespeichert sein. Vielleicht in der Applikation selbst Es hilft alles nichts. Sie braucht diese neue Access-Applikation der Personalabteilung – und sie braucht einen Vorwand.<\/p>\n Die Idee für einen Vorwand liefert ihr die Schaltfläche Geburtstagsliste <\/b>im Start<\/b>-Formular der Access-Applikation. Die Funktionen der Personalabteilung mögen für Frau Bienlein zwar nicht aktiviert sein, die zugehörigen Schaltflächen sind aber dennoch sichtbar (siehe Bild 13).<\/p>\n Bild 13: Start-Formular für Frau Bienlein<\/span><\/b><\/p>\n Frau Bienlein ruft in der Personalabteilung an und fragt nach einer Geburtstagsliste. Sie möchte gerne das obligatorische Beschenken der Geburtstagskinder übernehmen. Eine zeitaufwendige Angelegenheit, muss sie doch jeden Kollegen gegen eine kleine Spende auf einer Geburtstagskarte unterschreiben lassen und dann noch ein passendes Geschenk besorgen. Herr Stromberg von der Personalabteilung ist von der Idee begeistert, hat aber aktuell keine Zeit zum Erstellen der Liste. Frau Bienlein bietet ihre Hilfe an. Sie kommt gerne in die Personalabteilung und druckt die Liste selbst. Ein Vorschlag, den der Kollege Stromberg sehr gerne annimmt.<\/p>\n In der Personalabteilung darf Frau Bienlein den Arbeitsplatz von Herrn Stromberg übernehmen. Dieser geht derweil Kaffee für alle Beteiligten holen.<\/p>\n Die Mitarbeiter der Personalabteilung sehen darin kein Problem. Es sind ja nur die Geburtstage der Kollegen. Die sind kein Geheimnis. Meist ist es kaum zu überhören, wenn jemand Geburtstag hat. Außerdem ist Frau Bienlein mit der Applikation WaWi <\/b>vertraut. Schließlich arbeitet der Vertrieb ebenfalls mit dieser Access-Applikation.<\/p>\n Frau Bienlein öffnet die Access-Applikation WaWi<\/b>. Die Benutzersteuerung der Funktion fBerechtigungen <\/b>erkennt den immer noch am Betriebssystem angemeldeten Anwender Stromberg <\/b>und bietet das Start<\/b>-Formular mit den Einstellungen für die Personalabteilung an (siehe Bild 14).<\/p>\n Bild 14: Start-Formular für Herrn Stromberg<\/span><\/b><\/p>\n Sie erstellt die Geburtstagsliste und öffnet vorsorglich den Druckdialog. Jetzt wechselt Sie zum Desktop. Hier klickt sie die Verknüpfung zur Access-Applikation WaWi <\/b>mit der rechten Maustaste an und öffnet den Eigenschaften-Dialog. Schnell kopiert sie mit der Tastenkombination Strg + C <\/b>den bereits markierten Inhalt der Eigenschaft Ziel <\/b>(siehe Bild 15) und beendet den Dialog mit der Taste Esc<\/b>.<\/p>\n Bild 15: Eigenschaft der Desktop-Verknüpfung<\/span><\/b><\/p>\n Die Zwischenablage enthält nun den Pfad zur Access-Applikation. Sie öffnet den Windows-Explorer und fügt den Inhalt der Zwischenablage per Strg + V <\/b>in die Adresszeile ein. Dort entfernt sie die Anführungszeichen sowie den Namen der Access-Datenbank (siehe Bild 16) und drückt die Eingabe<\/b>-Taste.<\/p>\n Bild 16: Der Weg zum Access-Frontend<\/span><\/b><\/p>\n Frau Bienlein ist im Verzeichnis der Access-Applikation angekommen. Sie markiert das Access-Frontend, drückt erneut Strg + C <\/b>und fügt die Kopie in das allgemein gültige Transfer-Verzeichnis im Netzwerk ein. Dieses Verzeichnis dient dem Austausch von Dateien im Unternehmen. Jeder Mitarbeiter hat hier volle Zugriffsrechte.<\/p>\n Frau Bienlein schließt den Windows-Explorer und kehrt zur Access-Applikation WaWi <\/b>zurück. Im noch offenen Druckdialog wählt sie den Drucker der Personalabteilung aus und druckt die Geburtstagsliste. Mit großer Geste holt sie die Geburtstagliste vom Drucker und bedankt sich bei den Kollegen. Doch so einfach will man Frau Bienlein nicht gehen lassen. Der Kaffee ist eingetroffen. Ungeduldig trinkt Frau Bienlein mit den Kollegen der Personalabteilung ihren Kaffee.<\/p>\n Zurück an ihrem Arbeitsplatz verschiebt Frau Bienlein das Access-Frontend auf ihr lokales Laufwerk. Mit einem Doppelklick öffnet sie die Access-Applikation. Enttäuscht sieht sie im Start<\/b>-Bildschirm die deaktivierten Schaltflächen zu den Funktionen der Personalverwaltung. Das Formular zeigt jetzt auch wieder ihren Namen.<\/p>\n Eben in der Personalabteilung stand dort noch der Name Stromberg<\/b>. Irgendetwas muss beim Start der Access-Applikation den Namen ermitteln. Wie war das nochmal in der Access-Schulung Wie konnte man den Navigationsbereich einblenden Frau Bienlein drückt die Taste F11<\/b>. Nichts. Keinerlei Auswirkung. Sie schließt die Access-Applikation und startet sie erneut. Dieses Mal hält sie dabei die Umschalt-Taste gedrückt. Voila. Anstelle des Start<\/b>-Formulars sieht sie den Navigationsbereich. Dort entdeckt sie die Tabelle Mitarbeiter<\/b>. Gespannt öffnet sie die Tabelle mit einem Doppelklick – und sieht die Personaldaten. <\/p>\n Der Weg zur Gehaltserhöhung wäre wieder frei. Doch Frau Bienlein möchte das Access-Frontend der Personalabteilung so schnell wie möglich wieder loswerden. Ihre eigene kleine Access-Datenbank ist ihr einfach lieber. Aber wo sind die Anmeldedaten zu dieser ominösen Anmeldung Sie müssen doch irgendwo in dem Access-Frontend gespeichert sein.<\/p>\n Frau Bienlein erinnert sich an die Meldung Kennwort speichern <\/b>beim Einbinden der Tabellen. Ob das Kennwort in den Tabellen hinterlegt ist Mit einem Rechtsklick öffnet Sie die Tabelle Mitarbeiter <\/b>in der Entwurfsansicht. Die darauffolgende Meldung ignoriert sie mit einem Klick auf Ja<\/b>. Im Entwurf der Tabelle aktiviert sie das Eigenschaftenblatt und schaut sich die einzelnen Einstellungen genau an. Dort fällt ihr in der Eigenschaft Beschreibung <\/b>der Eintrag WaWi_SQL <\/b>auf.<\/p>\n Diesen Begriff kennt Frau Bienlein vom Einbinden der Tabelle Mitarbeiter<\/b>. Sie liest weiter und bemerkt den Eintrag UID=WaWiPersonal<\/b>. Das könnte eine Spur sein. Die Applikation heißt WaWi <\/b>und schließlich geht es hier um die Personal-Abteilung. Gespannt durchsucht sie den Rest der Beschreibung, findet aber keinen Hinweis zu einem Kennwort.<\/p>\n Frau Bienlein denkt an ihre Pass Through-Abfrage zum Löschen der Tabelle Bewerber. Gab es da nicht ebenfalls eine Meldung zum Speichern des Kennworts Sie öffnet die Pass Through-Abfrage ptSelectGeburtstagsliste <\/b>in der Entwurfsansicht und geht direkt zu den Einstellungen im Eigenschaftenblatt.<\/p>\n In der Eigenschaft ODBC <\/b>entdeckt sie wieder den Begriff WaWi_SQL<\/b>. Moment mal. Was ist das denn Direkt hinter dem Eintrag UID=WaWiPersonal <\/b>steht PWD=SicherIn2021!<\/b> (siehe Bild 17). Ob das die Anmeldedaten sind Aber was bedeutet UID <\/b>und PWD<\/b> Steht PWD <\/b>möglicherweise für Password Ein kurzer Blick ins Internet bestätigt ihre Vermutung. UID <\/b>zeigt den Anmeldenamen und PWD <\/b>das Kennwort.<\/p>\n Bild 17: Eigenschaften einer Pass Through-Abfrage<\/span><\/b><\/p>\n Frau Bienlein öffnet ihre eigene kleine Access-Datenbank. Routiniert klickt sie sich über den Menüpunkt Externe Daten<\/b> durch die Dialoge bis hin zur Kennworteingabe. Im Feld Anmelde-ID <\/b>trägt sie den Wert des Parameters UID <\/b>und im Feld Kennwort <\/b>den Wert des Parameters PWD <\/b>ein.<\/p>\n Gespannt klickt sie auf die Schaltfläche OK <\/b>und tatsächlich, der Dialog Tabellen verknüpfen <\/b>bietet wieder die Tabellen Mitarbeiter <\/b>und Bewerber <\/b>an. Sie markiert beide Tabellen, aktiviert die Option Kennwort speichern <\/b>und übernimmt die Auswahl mit OK<\/b>. Nachdem sie die Meldungen mit der Schaltfläche Kennwort speichern <\/b>bestätigt hat, sieht sie im Navigationsbereich die eingebundenen Tabellen dbo_Mitarbeiter <\/b>und dbo_Bewerber<\/b>.<\/p>\n Ein Doppelklick auf die Tabelle dbo_Mitarbeiter <\/b>liefert ihr die Personaldaten. Schmunzelnd schaut sie über die Spalte Geburtsdatum<\/b>, navigiert zu ihrem Datensatz und erhöht den Betrag in der Spalte AktuellesGehalt <\/b>um 5 Euro. Danach öffnet sie die Tabelle dbo_Bewerber<\/b>. „Rache muss sein.“ denkt sich Frau Bienlein und löscht alle Daten der Tabelle. <\/p>\n Mit der SQL Server-Anmeldung WaWiPersonal <\/b>wurde das Berechtigungskonzept um eine weitere Anmeldung ergänzt. Die neue Anmeldung wird speziell auf den Rechnern der Personalabteilung eingesetzt.<\/p>\n Im Vertrieb erfolgt die Verbindung zum SQL Server wie bisher über die Anmeldung WaWiMa<\/b>. Allerdings wird dieser Anmeldung der lesende und schreibende Zugriff auf die Daten der Personalverwaltung verweigert. Das Lesen und Schreiben der Personaldaten ist nur der Anmeldung WaWiPersonal <\/b>erlaubt. <\/p>\n Die Verwendung unterschiedlicher Anmeldungen im Vertrieb und in der Personalverwaltung ermöglicht eine detailliertere Rechtevergabe und erhöht somit den Grad der Sicherheit um eine weitere Stufe.<\/p>\n Die Rechtevergabe ist eng mit der installierten Access-Applikation WaWi <\/b>verbunden. Nicht der Anwender, sondern die Access-Applikation meldet sich am SQL Server an. Die dazu notwendigen Anmeldedaten sind im zugehörigen Access-Frontend gespeichert.<\/p>\n Mit nur wenig Mühe lassen sich dort der Name der Anmeldung und das Kennwort ermitteln. Natürlich können Sie noch mehr Maßnahmen zur Absicherung des Access-Frontends treffen. Aber bereits im ersten Beitrag dieser Reihe haben Sie gesehen, dass viele dieser Maßnahmen recht einfach zu umgehen sind. <\/p>\n Eine weitere Gefahr stellt die vermeintliche Bedeutung der ODBC-Datenquelle dar. Die dort hinterlegten Anmeldedaten spielen für den eigentlichen Datenzugriff in der Access-Applikation keine Rolle. Sie müssen nicht einmal mit denen übereinstimmen, die in der Access-Applikation gespeichert sind.<\/p>\n So kann ein Blick in die ODBC-Datenquelle schnell zu einem falschen Schluss führen. Möglicherweise fühlt man sich in Sicherheit, da dort eine Anmeldung mit geringen Rechten hinterlegt ist. In Wahrheit aber nutzt das Access-Frontend für den Datenzugriff eine andere Anmeldung mit weitaus höheren Rechten. Aus diesem Grund sollten Sie sich nicht auf die Anmeldedaten der ODBC-Datenquelle verlassen. <\/p>\n Am besten verzichten Sie auf den Einsatz der ODBC-Datenquellen und speichern die Verbindungsdaten direkt in der Access-Applikation. Diese als DSN-less bekannte Variante lernen Sie im nächsten Beitrag dieser Reihe kennen.<\/p>\n SQL Server – Wechsel in den Gemischten Modus<\/p>\n Sollte diese Option bereits aktiviert sein, können Sie die Änderung hier abbrechen. Die folgenden Schritte müssen Sie dann nicht ausführen.<\/p>\n Installation der Beispieldatenbank WaWi_SQL<\/b><\/p>\n ODBC-Datenquelle WaWi_SQL<\/b><\/p>\n Beispielapplikation WaWi<\/b><\/p>\n Enthaltene Beispieldateien:<\/p>\n Rechtevergabe – DENY f\u00fcr WaWiMa.sql<\/p>\n WaWi.accdb<\/p>\n WaWi_SQL.sql<\/p>\n<\/p>\n
<\/p>\n
Eine Anmeldung für die Personalabteilung<\/h2>\n
<\/p>\n
<\/p>\n
fTabelleAlsSystemObjekt \"ADO\", False<\/span> <\/pre>\nEine Anmeldung für den Vertrieb<\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\n
DENY SELECT, INSERT, UPDATE, DELETE ON dbo.Bewerber TO WaWiMa;<\/pre>\n
DENY SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO WaWiMa;\r\nDENY SELECT, INSERT, UPDATE, DELETE ON dbo.Stellen TO WaWiMa;<\/pre>\n
<\/p>\n
<\/p>\n
Der Fall Bienlein<\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Fazit und Zusammenfassung<\/h2>\n
Installationsanleitung der Beispielumgebung<\/h2>\n
\n
\n
\n
\n
\n
Downloads zu diesem Beitrag<\/h2>\n