Stored Procedure -> Sicherheit

Question

Hallo,

wir wollen eine Zeiterfassung entwickeln. Die Daten sollen auf einem SQL Server 2008 liegen.

Es sollen natürlich nicht alle Nutzer auf alle Daten zugreifen dürfen. Nun gibt es die Möglichkeit den Zugriff auf die Tabellen zu sperren und dem Nutzer nur ausgewählte Ergebnisse von Stored Procedure zu zeigen.

Mir fiel bei einem Test mit einer Access.adp auf, dass es hier die Möglichkeit gibt die Übergabeparameter einzusetzen. Eigentlich war geplant, dass der Nutzer durch das Frontend gesteuert nur die für ihn zulässigen Daten sehen darf.

Der Mitarbeiter Müller sitzt am Frontend und soll nur die Daten des Mitarbeiter Müller sehen. Wenn jetzt aber der Mitärbeiter Müller durch Nutzung einer Access.adp oder anderer Programmierwerkzeuge die Möglichkeit hat die Daten das Mitarbeiter Schulz zu sehen wäre das mehr als schlecht. Es stehen natürlich die Daten aller Mitarbeiter in den Tabellen.

Wie kann man verhindern, dass ein Zugriff mit anderen Werkzeugen als dem Frontend auf die Daten erfolgt? Oder gibt es zumindest die Möglichkeit einen fremden Zugriff zu protokolieren?

Oder muss eine Zwischenschicht zwischen Frontend und SQL Server gezogen werden in dem die Anfrage des Frontend an die Zwischenschicht gestellt wird und dann von der Zwischenschicht die Anfrage mit einer SQL User Kennung an den SQL Server weitergeleitet wird.

.Vielen Dank für die Hilfe

Björn

Answer 1

Hallo Björn,

auf eine Prozedur kannst Du mit unterschiedlichsten Anwendungen zugreifen,
nicht nur mit einer Access ADP, auch mit Excel uvm.
Und mit etwas Kreativität kann jeder die möglichen Parameter durchprobieren.

Weitere Schichten bringen i. a. nicht automatisch ein mehr an Sicherheit,
denn auch einen Web Service etc. kann man auf diese Weise "durchprobieren"
(nur die erforderlichen technischen Kenntnisse mögen teilweise höher sein).

Eine Möglichkeit solche Eingriffe zu unterbinden, wäre eine Filterung der Daten
anhand des angemeldeten Kontos, Rolle usw. Beschrieben wird das umfassender in:
Implementing Row- and Cell-Level Security in Classified Databases Using SQL Server 2005

Dort wird auch gezeigt, wie man die Verschlüsselungsmöglichkeiten des SQL Servers einsetzen kann.
Eine Alternative wäre dabei, die Ver/Entschlüsselung durch das Programm selbst vorzunehmen.
Womit aber wieder die Frage der (sicheren) Schlüsselablage zu klären wäre.

Eine Variation zeigt der (ältere) Artikel: http://vyaskn.tripod.com/row_level_security_in_sql_server_databases.htm
wo ein zusätzliches Kennwort (könnte z. B. eine PIN sein) verwendet wird.

Allesverhindert natürlich nicht, das sich Mitarbeiter Müller an den Arbeitsplatz von Mitarbeiter Meier setzt
und dort die Informationen abruft. Das müsste dann mit weiteren Massnahmen sichergestellt werden,
z. B. das Abruf nur mit eingelegter ID-Karte etc. erfolgen kann.
Dort könnte auch ein Schlüssel hinterlegt werden - ähnlich wie es der neue Personalausweis vorsieht.

Gruß Elmar

 

Answer 2

Hallo Elmar,

nun ist meine geschriebene Antwort weg:-( Ich hatte vor dem Versenden dummerweise Deine Antwort als hilfreich bewertet, danach war meine Antwort weg.

Vielen Dank für Deine Antwort. Das sie für mich mehr als unbefriedigend ist, ist nicht Deine Schuld. Schließlich heißt sie, ein Großteil des bisher Erstellten in die Tonne:-( Wobei dies aber vorwiegend das Frontend betrifft. Die Stored Procedure können ja weiterhin genutzt werden.

Es soll nicht verhindert werden, dass sich Müller an Meiers Platz setzt. Aber selbst dann solle Müller nur Meiers Daten verändern dürfen.

Das Frontend ermittelt lediglich aus den Systemvariabeln den Domänen-Anmeldename. Diese Systemvariabel zu verändern, dass sich der Mitarbeiter mit einer fremden Identität anmelden kann dürfte schwierig sein.

Bei den Stored Procedure braucht der Mitarbeiter nix probieren. Es sieht die kompletten SQL Prozeduren nebst Aufrufparameter. Der Mitarbeiter muss sich nur die Prozeduren so zusammenstellen, dass er weiß wie er an die gewünschte Information kommt.

Das Buch ist doch etwas umfangreicher und nicht mal schnell gelesen. Um das zu verdauen werde ich wohl ein Weilchen brauchen. Allerdings wird es wohl für die direkte Nutzug (2-Tier) der Storage Procedure keine besseren Erkenntnisse geben.

Wir werden wohl auf 3-Tier umsteigen müssen. Hier hätte der Mitarbeiter keinen direkten Zugriff auf die DB mehr, könnte also auch nix probieren. Der Mitarbeiter sitzt vor seinem Frontend und kann entweder Button klicken oder benötigte Eingaben tätigen. Er darf natürlich das SQL Konto nebst Passwort nicht kennen.

Kriminelle Energien a la Hacking, Netzwerk Sniffing oder ähnlichem lassen wir außen vor. Insofern sollte die Nutzung einer Zwischenschicht doch höchstmögliche Sicherheit bringen.

Gruss Björn

 

Answer 3

Hallo Björn,

man muss sich grundsätzlich klarmachen, dass eine Prozedur sich nicht zum "Verstecken" eignet.
Wie man allgemein "Verstecken" von Informationen nicht als Lösung ansehen kann.

Das hindert bestenfalls unbedarfte Leute daran, sich die Informationen zu verschaffen.
Solche Probleme verursachen i. a. nicht die Mitarbeiter wie Müller, Meier, Schulze -
sondern Leute mit mehr krimineller Energie (und dem notwendigen technischen Know-How)
und die Schrecken auch nicht vor Identitätsdiebstahl (über neudeutsch Social Engineering) zurück.
(Vernachlässigen sollte man das heutzutage nicht mehr - denn entsteht auf diese Weise
Vertrauensverlust, ist das später nur schwer wieder herzustellen).

Eine Prozedur ist nur ein Weg (komplexere) Verarbeitungsschritte zusammenzufassen.
Sie kann (wie auch alle anderen SQL Server Objekte, Tabellen, Sichten usw.)
durch Zugriffsrechte gesichert werden, nicht mehr und nicht weniger.

Auch andere Massnahmen wie z. B. Web Services (als heute oft genutzte Lösung)
benötigen eine Absicherung, sonst können sie auf gleiche Weise "ausgespäht" werden.
Kurz: Egal wieviel Schichten man dazwischenschaltet, das Identifikationsproblem bleibt.

Solange man Windows Sicherheit einsetzt, ist die Identität des Zugreifenden ermittelbar.
Nur nicht, ob die richtige Person vor dem Bildschirm sitzt, dafür wäre weitere Massnahmen
wie Smartcard Identifikation etc. notwendig.

Bei SQL Server Sicherheit werden die Anwender mit einem weiteren Kennwort konfrontiert -
was leichter zu unterlaufen ist und zusätzliche Komplexität für den Normalfall bedeutet,
was wiederum Unmut bei der täglichen Nutzung mit sich bringen kann.

Von einem SQL Server Konto für alle kann nur ganz abraten - und in Verbindung mit einer
zusätzlichen Schicht käme hinzu das Problem, wie man die Identitäten weiterreicht.

Ich will aufs Rechtliche nicht weiter eingehen - das ist dafür das falsche Forum (und ich der falsche Ansprechpartner)
In Deutschland sind Zeitdatenerfassungen mitbestimmungspflichtig und da sollte man
qualifizierte Leute einschalten, um sich dort keine Probleme einzuhandeln.
So gibt es auch beim BSI gibt dazu weitere Informationen, z. B.:
https://www.bsi.bund.de/cln_156/DE/Themen/ITGrundschutz/ITGrundschutzDatenschutz/itgrundschutzdatenschutz_node.html
(und weiteres mehr)

Gruß Elmar

P.S.: Das mit dem Wegklicken neiner Antwort passiert mir auch gelegentlich, 
natürlich immer bei den längeren - leider ist das etwas unbefriedegend gelöst ;-)

Answer 4

Hallo Elmar,

in diesem Fall sehe ich meine Probleme auf einer ganz unteren Ebene.

Wenn in einer Garderobe die Schlüssel alle in den Umkleidekabinen stecken sollte sich keiner beschweren wenn etwas fehlt. Zumindest das Entfernen des Schlüssels als ein geringer Schutz sollte gewährleistet sein.

Das Leute mit Dietrichen oder gar hochgerüsteten Einbruchswerkzeugen versuchen einzubrechen, wollte ich nicht betrachten. Das ist eine andere Baustelle. Hier müssen sicher für den Aufbau eines Schutzes Spezialisten werkeln.

Da durch den Einsatz von Stored Procedure die Tabellen für den Zugriff gesperrt werden können veranlasste mich dies zu dem trügerischen Schluss, dass durch den Einsatz von Stored Procedure auch die Logikschicht von 3-Tier wegfallen könnte, also eine zwei Schichten Architektur möglich wäre. Nun scheint dies nicht so zu sein, also alles zurück auf Anfang und 3-Tier.

Der Einsatz von Windows Sicherheit soll nicht geändert werden. Die Leute brauchen also keinen zusätzlichen Zettel mit einem weiteren Passwort an ihren Bildschirm kleben;-)

Noch einmal Dank für die vielen Informationen.

Gruss Björn

Answer 5

Guten Morgen Björn,

obwohl ja Elmar Deine Fragen schon hinreichend beantwortet hat, hier doch noch mal ein wenig Senf von meiner Seite dazu.

Ähnliche Probleme, wie Du sie beschreibst, haben wir auch in unseren Systemen gehabt. Hier kann eigentlich nur die von Dir bereits erkannte Sicherheitsmethode des Zugriffs auf Daten über eine zweite Schicht (views / stored procedures) helfen.

Da du ja - wie beschrieben - mit Integrated Security arbeitest, wäre es m. E. ein Leichtes, tatsächlich nur die Daten anzeigen zu lassen, die für einen Benutzer zugänglich sein dürfen.

Nehme ich an, dass ich z. B. Gehaltsdaten in einer Tabelle hinterlege, dann kann ich - abhängig von der Angehörigkeit einer bestimmten Rolle - diese Daten anzeigen oder nicht:

CREATE VIEW dbo.view_Gehaelter
AS
SELECT f.Vorname,
  f.Nachname,
  CASE WHEN IS_MEMBER('FINANZ') = 1
    THEN f.Gehalt
    ELSE NULL
  END AS Gehalt
FROM dbo.tblMitarbeiter

Das Beispiel ist natürlich recht primitiv aber ich habe dazu auf der SEK 2 einen Fachvortrag gehalten. Codings und Präsentation dazu findest Du hier:

http://www.donkarl.com/SEK/SEKDownloads/SEK2_Mehrschichtige.zip

Vielleicht kannst Du ja mit den Scripten etwas anfangen und als Denkanstoss verwenden ;-)

Ein schönes Weihnachtsfest...

---

Uwe Ricken
Microsoft Certified Database Administrator SQL Server 2005
db Berater GmbH
http://www-db-berater.de

Answer 6

Hallo Uwe,

so ist das mit der neuen Technik;-) Da ich die Foren nur bei Bedarf besuche und der Meinung war ich bekäme bei neuen Antworten eine E-Mail habe ich die Antwort erst jetzt entdeckt. Jetzt habe ich hoffentlich die richtigen Schalter gedreht, um zukünftig benachrichtigt zu werden.

Deinen Artikel werde ich mir am Wochenende zu Brust nehmen. Sicher werde ich Dinge finden, welche mich veranlassen wieder Einiges umzustricken:-(

Aber besser ständig nachstricken als eine löchrige Software.

Gruss Björn