Received MVP Award for SQL Server // Ausgezeichnet mit dem MVP-Award

Ausgezeichnet mit dem MVP-Award für SQL Server

(de)
Gestern, am 1. April 2014 erhielt ich die frohe Botschaft: Für meine Beiträge zur Community bin ich von Microsoft mit dem MVP Award (MVP=Most Valuable Professional) ausgezeichnet worden (zum MVP-Profil).

(en)
Yesterday, on 1 April 2014, I got great news:
I have been awarded with the MVP Award by Microsoft (MVP=Most Valuable Professional) for my contributions to the community (click here for MVP profile).

 

 

MVP_Award_SQL_Server

 

 

 

Ich freue mich riesig über diese Anerkennung meiner zahlreichen Konferenz-Beiträge, Usergroup-Meetings und anderen Aktivitäten!

So bin ich seit 2009 bis Stand heute auf 27 Konferenzen als Redner zu verschiedenen SQL Server Themen, von Sicherheit über Performance & Indexdesign bis hin zu Reporting Services aufgetreten und habe auf weiteren 34 Usergroup-Meetings Vorträge gehalten.

2013 hat sich meine Aktivität noch einmal gesteigert, so dass ich allein in diesem Jahr auf 11 Konferenzen, von Istanbul/Türkei bis Charlotte/USA, und 14 PASS Regionalgruppentreffen (Liste) als Sprecher angetreten bin.
Und auch 2014 habe ich bereits 2 Konferenzen und 4 Regionalgruppentreffen (Liste) hinter mir – weitere werden folgen: Portugal, England und wenn es hoffentlich? klappt zum 6. Mal in den USA :-)

Damit bin ich fast so viel auf Konferenzen unterwegs wie drei weitere deutsche MVP-Kollegen, die diese Auszeichnung bereits hochverdient für ihren Einsatz für die deutsche SQL Server Community PASS Deutschland e.V. erhalten haben: Tillmann Eitelberg, Oliver Engels – beide im Vorstand der PASS – und Constantin Klein, der unter anderem den Just Community e.V. und die .NET User Group Frankfurt leitet. – Ich freue mich, zu dieser illustren Runde dazustoßen zu können!

Dieser Award ist für mich daher eine tolle Anerkennung und ein Ansporn weiterzumachen – was natürlich nicht heißt, dass ich es nicht auch ohne diesen tun würde, denn die Interaktion mit der Community ist für sich gesehen schon eine echte Bereicherung, von der alle profitieren.

An dieser Stelle möchte ich einigen Personen persönlich meinen Dank aussprechen, die meine Nominierung zum MVP auf verschiedene Weise unterstützt haben:

I am very excited about this recognition of my many contributions to conferences, usergroup meetings, and other activities!

In fact, since 2009 till today, I have appeared as a speaker in 27 conferences, speaking on different SQL Server topics from security to performance & index design to reporting services, and have given presentations in 34 usergroup meetings.

2013 saw yet another boost in my activities: That year alone I was speaker at 11 conferences, from Istanbul/Turkey to Charlotte/USA, and at 14 PASS regional group meetings (list).
In 2014, too, I can already look back on 2 conferences and 4 regional group meetings (list) – with more to come: Portugal, England, and – hopefully it will work out – USA for the 6th time. :-)

Thus, I am participating in conferences to an almost similar extent as three other German MVP colleagues who have already been awarded, quite deservedly, the very award for their commitment to the German SQL Server Community PASS Deutschland e.V.: Tillmann Eitelberg, Oliver Engels – both of them in the chair of the PASS – and Constantin Klein who heads the Just Community e.V. and the .NET User Group Frankfurt, among others. – I am honored to be joining this illustrious circle!

This award is indeed a fantastic acknowledgement and incentive to continue – of course, this doesn’t mean I wouldn’t do so without this award, because the interaction with the community is in itself already an enrichment from which everyone is benefiting.

I would like to express my personal thanks to the following people who have supported my nomination to MVP in various ways:

 

Anna Feth (Microsoft MVP Programmkoordinator Region DACH), @AnnaFeth), Constantin Klein (MVP, Blog, @KostjaKlein), Daniel Weinmann (Product Marketing Manager - SQL Server/ BI Microsoft GmbH), Florian Endres (Community Program Manager, @senorf), Heike Ritter (Technical Evangelist Microsoft Deutschland GmbH, @HeikeRitter), Jack Richins (Principal Development Lead Microsoft SQL Server Security), Katrin Letzel (Microsoft MVP Community Program Manager, @katko), Niko Neugebauer (MVP, Blog, @NikoNeugebauer), Oliver Engels (MVP, @oengels), Scott Klein (SQL Server Evangelist, Microsoft, @SQLScott), Tillmann Eitelberg (MVP, Blog, @_Tillmann) and the Team of the datafino GmbH, to which I have a strong partnership as well as all anonymous supporters and technical sparring partners.

 

So bin ich mindestens genauso dankbar für all die wertvollen Kontakte, die Gesprächsmöglichkeiten und den Austausch untereinander wie für den Award selber.

Thus, I am at least equally grateful for all the valuable contacts, opportunities for dialogue and mutual exchange as for the award itself.

 

Andreas

MCSM, MCM and MVP :-)

DISABLE and DENY LOGIN, DENY USER & Effect on Impersonation and Permissions

DISABLE und DENY LOGIN, DENY USER & Effekt auf Impersonierung und Berechtigungen

(de)
Ein kurzer Artikel zu den Effekten – oder fehlenden Effekten – in Bezug auf das Deaktivieren & Verbieten von Connect für Logins und Users auf Impersonierung und Berechtigungen.

(en)
A short article on the effects - or missing effects - regarding the disabling & denying connect of Logins & Users on impersonation and permission.

Immer mal wieder kann man beobachten, dass Logins oder Usern die Connect-Berechtigung verboten bekommen wurde, oder ein Login deaktiviert wurde.

Die richtige Erwartung und Verständnis kann daher kritisch sein.

Sehen wir uns also eine einfache Demo an:
Wir werden das eingebaute sa-Konto, welches von vielen unter anderem als Datenbankbesitzer (mehr dazu bald in einem anderen Artikel – zwischenzeitlich lade ich Sie dazu ein, noch Daten zu der Umfrage zu diesem Thema einzusenden), ein weiteres frisch angelegtes Konto und eine Datenbank, genannt ImpersonateLogin mit dem entsprechenden User + einem weiteren User ohne Login: SQLUser.

Every once in a while one can observe that Logins or Users have been denied the Connect permission or a Login has been disabled.

Therefore a correct expectation and understanding can be critical.

So let’s see a simple demo:
We will use the built-in sa-Account, which is used by many as database owner among other (more on that soon in another article - meanwhile I do invite you to still send in data for the survey on that topic), another freshly created Account DeniedLogin and a database called ImpersonateLogin with the according User + another User without Login: SQLUser.

 DisabledPrincipals_Script

Ich deaktiviere also das sa-Konto ebenso wie das „DeniedLogin“-Konto – letzterem verbiete ich außerdem die Connect-Berechtigung (Erinnern wir uns daran: „Berechtigungen können nicht für sa, dbo, Entitäts-Besitzer, information_schema, sys oder für den Benutzer selbst erteilt, verweigert oder aufgehoben werden.“)

Der Datenbank-User „SQLUser“ bekommt die Connect-Berechtigung auf die Datenbank verboten.
In der GUI sieht das Ergebnis so aus:

So I am disabling the sa-account as well as the “DeniedLogin”-Account – the latter I also Deny the Connect permission (Remember we “Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.”)

The Database-User “SQLUser” gets denied the Connect permission on the database.

In the GUI the result looks like this:

 DisabledPrincipals_Setup_Disabled_Login

DisabledPrincipals_Setup_Disabled_sa

Nun führen wir 4 Tests durch:

Now let’s run 4 tests.

 DisabledPrincipals_Test1

Was diese Abfragen im Wesentlichen machen, ist, zu versuchen, den entsprechenden Login oder User zu impersonieren – und den Erfolg dadurch belegen, dass sie die dann jeweils aktiven Rollen-Mitgliedschaften zurückgeben.
Ergebnisse:

So essentially what those queries do, is trying to impersonate the respective Login or User – and proofing success by returning the then respective active role-memberships.

Results:

 DisabledPrincipals_Result

DeniedLogin: Impersonierung funktioniert + kein Verlust an Berechtigungen.
In other words: Denying Connect to a Login does not disallow Impersonation.
Impersonation is actually another permission which one can use and is not affected even by Disabling the Login!

DeniedLogin: Impersonation works + No loss of permissions.
In other words: Denying Connect to a Login does not disallow Impersonation.
Impersonation is actually another permission which one can use and is not affected even by Disabling the Login!

 DisabledPrincipals_Result

Dasselbe gilt für den sa: Impersonierung funktioniert + kein Verlust a Berechtigungen.

Im Folgenden ein Test für den User, dem die Connect-Berechtigung auf die Datenbank entzogen worden ist – und nicht als Login verwendet werden kann.

Same applies for sa: Impersonation works + No loss of permissions.

In the following test for the User which has been denied the Connect-permission onto the database – and cannot be used as a Login.

 DisabledPrincipals_Test2

Ergebnisse:

Msg 15517, Level 16, State 1, Line 3

Die Ausführung als Datenbankprinzipal ist nicht möglich, weil der Prinzipal 'DeniedLogin' nicht vorhanden ist,
für diesen Typ von Prinzipal kein Identitätswechsel möglich ist, oder Sie nicht die erforderliche Berechtigung haben.

 

Msg 916, Level 14, State 1, Line 3

Der Serverprinzipal 'S-1-9-3-4049223906-1289824279-1154161590-488313048.'
kann unter dem aktuellen Sicherheitskontext nicht auf die ImpersonateLogin-Datenbank zugreifen.

Results:

Msg 15517, Level 16, State 1, Line 3

Cannot execute as the database principal because the principal "DeniedLogin" does not exist,
this type of principal cannot be impersonated, or you do not have permission.

 

Msg 916, Level 14, State 1, Line 3

The server principal "S-1-9-3-4049223906-1289824279-1154161590-488313048."
is not able to access the database "ImpersonateLogin" under the current security context.

 

Das Ergebnis ist für beide Datenbank-User effektiv das gleiche.

Die GUID repräsentiert keinen reellen Server-Prinzipal, denn der User SQLUser hat keinen entsprechenden Login.
Daher sagt es uns, dass die User nicht innerhalb der Datenbank impersoniert werden können.

Der Unterschied für den 2. User ist, dass dieser User nur innerhalb der Datenbank existiert, aber zugleich expliziert verboten wurde, sich mit ihr zu verbinden Das hat im Endeffekt dasselbe Resultat, wie ihn zu deaktivieren – genau wie der Guest-User es ist.

The GUID does not represent a real server-principal, because the User SQLUser does not have a matching Login.
So it tells us, that the users cannot be impersonated inside the database.

The difference for the second user is, that this user only exists inside the database but at the same time has been explicitly denied to connect to it. This has essentially the same result as “disabling” it – just as the guest-user is.

 

Damit wäre gezeigt, dass das Deaktivieren von Logins keinerlei Sicherheit gegenüber Angriffen von Innen gibt. Und sogenannte Privilegien Erweiterung findet in aller Regel z.B. von innen heraus statt.

Auch der alte „Trick“, die Standard-Datenbank des Logins zu löschen, ist da keine Hilfe.

Für Datenbank-User hat es durchaus Effekt und verhindert das Anmelden an der jeweiligen Datenbank – auch „von Innen heraus“.

 

Thereby it is shown, that disabling of Logins does not give any security against attacks from inside. And so-called privilege elevation (/-escalation) usually takes part from internal.

Also the old “trick”, to drop the default-database of a Login, is of little help.

For database-users is indeed does have an effect and prevents logon/connect to the respective database – also “from inside”.

 

Konsequenterweise bleiben alle Berechtigungen (natürlich abgesehen von dem jeweiligen Deny) der jeweiligen Logins und User absolut unbeeinflusst von einer Deaktivierung jeglicher Weise.

Das gilt auch im Zusammenhang mit „External Access“-Berechtigung für Logins basierend auf asymmetrischen Schlüsseln.
(Hier ein Forum-Thread, in dem die Frage auftauchte: “SQL Login "disabled" flag does not work with asymmetric key??”)

ALTER LOGIN ist auch hier in BOL erklärt: technet.microsoft.com/en-us/library/ms189828.aspx

 

Ich hoffe, diese Dinge erklären einiges und speziell Empfehlungen in Sicherheits-Aspekten.

Consequentially all permissions (besides the one denied of course) of the respective Login and User stay totally unaffected by and method of deactivation.

This is also true in the context of “external access”-permission for Logins based on asymmetric keys.
(Here a forum-thread where the question appeared: “SQL Login "disabled" flag does not work with asymmetric key??”)

ALTER LOGIN is also explained in BOL here: technet.microsoft.com/en-us/library/ms189828.aspx

 

I hope those things clarified some things and especially recommendations in security-matters

 

Happy securing

Andreas

Upcoming Conferences: SQLSaturdays in Denmark and Portugal. – Presenting In-Memory OLTP Deep-Dive for Administrators

 

(de)
Im März und April finden 2 europäischen SQLSaturdays statt, die Potential zu einem Geheimtipp haben:

Am 29. März in Kopenhagen, Dänemark
ind am 12. April in Lissabon, Portugal.

Da ich auch letztes Jahr bereits in Kopenhagen als Sprecher dabei war, kann ich aus erster Hand für die exzellente Organisation und Sprecherauswahl verbürgen.

Und für Portugal verbürgt mein sehr geschätzter Kollege Niko Neugebauer (Blog, Twitter:@NikoNeugebauer) – nach allem, was bisher „geleaked“ ist, wird es wieder ein Kongeniales Event. Würdig der ersten SQLSaturday-Location in Europa überhaupt.

(en)
In March and April, 2 European SQLSaturdays take place, which have the potential for a real insiders’ tip:

On March 29th in Copenhagen, Denmark
and April 12th in Lisbon, Portugal.

Since I already participated as a speaker in Copenhagen last year, I can avouch from “insider information” for the excellent organization and speaker choice.

And my much valued collegue Niko Neugebauer (Blog, Twitter:@NikoNeugebauer) vouches for Portugal – after all what has “leaked” in th emeantine, it will be another congenial event. Condign to the first SQLSaturday-Location in Europe ever.

SQLSaturday275_Denmark

Ich möchte zumindest einige, mir persönlich bekannte Sprecher namentlich erwähnen, aber gleich betonen, dass auch alle anderen Sessions definitiv einen Blick Wert sind(!):

In Dänemark sind dabei:

Die vollständige Agenda befindet sich hier: www.sqlsaturday.com/275/schedule.aspx

I would like to at least name some speakers, which I personally know, by name, but I would also like to stress immediately, that also all other sessions are definitely worth looking at just as well:

In Denmark there will be:

I am excited to see all of you again soon!

The complete Agenda can be found here: www.sqlsaturday.com/275/schedule.aspx

I am excited to see all of you again soon in Copenhagen!

SQLSaturday267_Portugal

In Portugal sind dabei:

Die vollständige Agenda befindet sich hier:

www.sqlsaturday.com/267/schedule.aspx

In Portugal there will be:

The complete Agenda can be found here: www.sqlsaturday.com/267/schedule.aspx

I am excited to see all of you again soon in Lisbon!

Und meine Wenigkeit, was präsentiere ich?
Nachdem ich mich nun seit November 2013, wo ich die neue Technologie in Deutschland erstmalig öffentlich präsentierte, eingehend mit eXtreme Transactional Processing, der neuen, integrierten, In-Memory Engine des SQL Server beschäftige, gibt es nun den Deep-Dive für Administratoren:

And my humble self, what am I presenting?
After I have been engaged deeply with eXtreme Transactional Processing, the new, integrated, In-Memory Engine of SQL Server, since November 2013, where I presented this new technology for the first time publically in Germany, I will now give a Deep-Dive for Administrators:

 

SQL Server 2014 In-Memory OLTP / XTP Management Deep Dive
@SQLSaturday Denmark & Portugal

You have heard about Hekaton, respectively the new acronym XTP (eXtreme Transactional Processing) and you want to know how it works under the cover? In this session we will take a closer look at the architecture, where the performance benefits come from and how it works in detail. What kind of files is SQL Server using for transactional consistency, what happens when you delete data inside the log and inside the data files. We will see the Merge-Process and the Garbage Collector in action, see how memory management works for XTP enabled databases, and thereby get an in-depth understanding of how this completely new storage engine works and how to optimize for it.

 

CU in Copenhagen, Lisbon.. or at another conference soon :-)

 

Andreas

Spezialrabattaktionen: 22% zum Jubiläumsjahr der PASS Deutschland e.V für Sicherheits- XEvent Tracing, sowie SQL Server 2014 Seminare + 10% Microsoft TechNet Aktion für alle

Damit auch alle, die vor 2 Wochen nicht auf der SQL Konferenz in Darmstadt (www.sqlkonferenz.de) waren, oder nicht regelmäßig bei TechNet vorbeischauen, eine Chance haben, poste ich es hier einmal öffentlich:

1)       Zum Jubiläumsjahr der PASS Deutschland e.V erhalten alle Mitglieder den „Jubiläums-Rabatt“ von 22 Prozent (!) auf die folgenden SQL Server Master-Classes:

birthday-cake

(SES) SQL Server Security Essentials für Entwickler & Administratoren – am 3. April 2014 in Düsseldorf
- Dieses Seminar ist für alle Einsteiger geeignet, die hier alle Grundlagen für die Sicherheitsverwaltung & Architektur von SQL Server erlernen.

(SIA) Securityworkshop for SQL Server Administrators (advanced) – 4. April 2014 in Düsseldorf
- In diesem Workshop werden sicherheitsrelevante Internas der Authentifizierung, das Konzept der Contained Databases, Daten- & Backupverschlüsselung mit Transparent Data Encryption (TDE) bis hin zu Überwachungstechniken in SQL Server erlernt.

(XE1) Einsteiger-Workshop Tracing mit Extended Events in SQL Server - am 7. März 2014 in Frankfurt am Main
- Das Grundlagentraining für alle, die den Nachfolger von SQL Trace & Profiler von Grund auf beherrschen möchten.

(XE3) FastTrack to Tracing with Extended Events for SQL Server - am 1. April 2014 in Frankfurt am Main
- Für Einsteiger, die die Funktionalitäten und Einsatzmöglichkeiten der Extended Events von A-Z an einem verlängerten Tag kennenlernen möchten.

(UP2014) Aktualisierung der Kenntnisse von SQL Server 2012 auf SQL Server 2014 - am 15. Mai 2014 in Frankfurt am Main
- Der neue SQL Server 2014 steht vor der Tür. Von Buffer-Pool Erweiterungen bis zu In-Memory OLTP enthält dieser viele wichtige neue Technologien, die an diesem Tag praxisnah kennengelernt werden.

(XTC) Workshop In-Memory OLTP & ColumnStore - New Storage Engines in SQL Server 2014 - am 16. Mai 2014 in Frankfurt am Main
- An diesem eintägigen Workshop werden die neuen und verbesserten In-Memory Technologien XTP für extrem performantes OLTP und Clustered Columnstore Indexes für DataWarehousing in aller Tiefe praktisch kennengelernt.

Und das ist der Gutschein-Code (exklusiv für Mitglieder der PASS Deutschland e.V.):
10PASSDE2014 *1 *2

Tipp: jeder kann sich jederzeit noch schnell und kostenlos(!) als Mitglied bei der PASS Deutschland e.V. anmelden – Details dazu auf der Webseite der PASS: www.sqlpass.de/Mitgliedschaft/Mitgliedwerdenistkostenlos.aspx

 

2)       Außerdem freue ich mich, noch auf eine andere Aktion, und zwar in Zusammenarbeit mit der  Microsoft Technet IT Pro Academy hinweisen zu können. Für ausgewählte Seminare gibt es einen speziellen Rabattcode *1, der hier über die TechNet-Seite zu finden ist: technet.microsoft.com/de-de/bb291022?it_product=sql-server&it_topic=zertifizieren, für 10% auf weitere Seminare:


(PAT) Workshop Performance und Analyse, Techniken & -Tools
- 17./18. März 201

(SHA) Workshop Hochverfügbarkeit für SQL Server - 6./7. Mai 2014


*1  Rabatt-Codes können nicht mit anderen Codes kombiniert werden
*2 Dieser Code ist gültig bei Verwendung bis zum bis 30.4.2014


Und hier findet Ihr die Gesamtübersicht der SQL Server Master-Classes und Links zur Anmeldung:
www.sarpedonqualitylab.com/SQL_Master-Classes.htm



Viel Spaß beim Lernen wünscht

Der Andreas

 

Microsoft Certified Solutions Master Data Platform (SQL Server 2012)
Microsoft Certified Master SQL Server 2008
Microsoft Certified Trainer

SQL Server Row- and Cell-Level Security – Disclosure vulnerability // Schwachstellen in Zeilen-basierter Sicherheit

 

(de)
Es ist Zeit für einen weiteren Artikel zum Thema Sicherheit.
Und durch einen Forum Thread zu „Datengesteuerter Sicherheit“ mittels der IS_MEMBER(), USER_NAME(), SUSER_SNAME() – Funktionen kam ich auf die Idee, ein kurzes Beispiel zu zeigen, wie sich solche Konstrukte leicht umgehen lassen und die geschützten/verborgenen Daten offengelegt werden können, wenn sie nicht mit weiteren Mitteln gesichert werden.
Sehen wir uns ein Beispiel an.

(en)
It’s time for another post on security matters.
And through a forum-thread on data-driven security by the means of views using the IS_MEMBER(), USER_NAME(), SUSER_SNAME() – functions, I came up with the idea of giving a short example how such constructs can easily be circumvented and the protected/hidden data become disclosed, when not being secured by further means.
So let’s look at an example.

Im Folgenden werden wir ein recht verbreitetes Szenario sehen, wie Sicherheit auf Zeilenebene / Row-Level Security (und auch Zellenebene/Cell-Level Security) implementiert werden kann.

Die Architektur ist recht einfach:
Eine Tabelle enthält Datenzeilen, von welchen einige von einer bestimmten Gruppe Personen gelesen werden darf, und andere Zeilen von anderen Personen – jeweils exklusiv.
Um das zu erreichen, wird eine Sicht angelegt. Diese Sicht muss natürlich denselben Besitzer haben, so dass der Prinzipal Berechtigungen auf die Sicht alleine erhalten kann, und durch die Besitzerkette an die Daten gelangt.
Innerhalb der Sicht ist eine Where-Klause, die einen Filter auf ein bestimmtes Attribut in der Tabelle enthält, durch das der Benutzer der aktuellen Sitzung erkannt wird und ausschließlich die Daten zurückgeliefert werden, die seiner Rollen-Mitgliedschaft entsprechen.
Natürlich gibt es auch komplexere Designs mit Zwischentabellen und mehrfachen Rollenmitgliedschaften/Rechten, aber am Ende teilen alle dieselbe Schwachstelle, die ich demonstrieren werde.
Im Folgenden zunächst ein Diagramm der Architektur.

In the following we will see a quite common scenario of how Row-Level Security (and also Cell-Level Security) can be implemented.

The architecture is quite simple:
A table is holding rows of data, some of which are supposed to be readable by a certain group of people, and other rows by other people – in each case exclusively.
In order to achieve this, a view is created. This view naturally must have the same owner, so the principal can be granted permissions on nothing but the view and get to the data by means of the ownership-chain.
Within the view there is a Where-clause which contains a filter on a certain attribute in the table, by which the user of the current session is detected and returned solely the data which matches his role-membership.

Of course there are also more complex designs with intermediate tables and multi-role-memberships/permissions, but it all comes down sharing the same vulnerability which I am about to demonstrate.

First of all here's a diagram of the high-level architecture:

 SQL_Row_Level_Security_Schema

 

Sehen wir uns das ganze also an.
Die Einrichtung Tabelle und der Sicht, inklusive 2er Beispieldatensätze:

So let’s see it in action.
The Setup of the Table and the View including 2 sample data rows:

 SQL_Row_Level_Security_Table_View_Setup

Die Spalte „Role“ wird von der Sicht verwendet, um die jeweilige Zeile, unter Verwendung der IS_MEMBER()-Funktion nur Mitgliedern der jeweils hinterlegten Datenbankrolle durchzureichen.

The column “Role” is used by the view to return the respective row by using the IS_MEMBER()-function only to members of the respectively stored database-role.

 SQL_Row_Level_Security_Table_View

Benutzer, Rollen und Berechtigungen:

User(s), Roles and Permissions:

 SQL_Row_Level_Security_User_Roles_Permissions

Erinnern wir uns, was die Tabelle enthält:

Now, remember what our table contains:

 SQL_Row_Level_Security_Data

In einer heilen Welt, vor dem Sündenfall, wäre dies ausreichend.
(Nachdem wir uns als „Andreas“, der Mitglied der Datenbankrolle RoleAlpha ist, einloggen) würden unsere Abfragen wie folgt aussehen, und lediglich die Zeilen zurückliefern, die der RoleAlpha „gehören“:

So in an innocent world, before the fall of mankind, this would be sufficient.
(After logging in as “Andreas”, who is member of the RoleAlpha database-role) our queries would look like this and only return the rows which “belong” to RoleAlpha:

 SQL_Row_Level_Security_Query

- Natürlich wird die Funktion User_Name() nur für Demo-Zwecke eingesetzt.
Ergebnis:

- Of course the function User_Name() is only used for demo-purposes.
Result:

 SQL_Row_Level_Security_Filtered_Data

Angriff
Aber Andreas spielt nicht fair. Er ist neugierig, was sonst noch in der Tabelle stehen könnte.
Also schreibt er eine Abfrage wie diese:

Attack
But, Andreas does not play nice.  He is curious on what else might be in the table.
So he crafts a query like this:

 SQL_Row_Level_Security_Attack

Und das Ergebnis ist:

And the result is:

 SQL_Row_Level_Security_Disclosure

Nicht „schön“, aber wir haben, was wir wollten: die „geschützten“ Daten.

Der bereits geschulte Leser erkennt diese Form des Angriffs vielleicht aus einem anderen Bereich wieder: SQL Injection.
Es ist eine Form des alten Freundes „Error Based Attack“ oder „Error Disclosure“, die auch bei schlecht geschriebenen Webanwendungen zum Zuge kommt. Das habe ich u.a. 2013 auf diversen Konferenzen gezeigt (Vortragsreihe).
Der Kontext ist ein wenig anders, aber die Idee dahinter ist dieselbe.

Not exactly “pretty”, but we got what we want: the “protected” data.

The well-educated reader may remember this kind of attack from a different area as well: SQL Injection.
It’s a form of the old fried “error based attack” or “error-disclosure”, which can also be used for badly written web-applications. I have also shown that amongst others in 2013 at several conferences (series of sessions).
The context is a little bit different, but the idea is the same.

 Security-Gate-Fail

Einigen kommt das Bild vielleicht schon bekannt vor :-)

Stellt sicher, dass das nicht Euer "Vorgarten" ist!

Wo wir davon reden:

To some, this picture may already look familiar :-)

Make sure it’s not your "front-yard"!

Speaking of which:

 

Schutzmaßnahmen

Was kann man gegen solche Angriffe tun?
Im Wesentlichen stehen einem 3 bekannte Möglichkeiten zur Verfügung:

1) Einsatz von gespeicherten Prozeduren, die alle Fehler abfangen, oder, wenn man unbedingt mit Sichten Arbeiten möchte, der Einsatz einer dazwischengeschalteten Multi-Statement-Tabellenwertfunktion

2) Datenverschlüsselung (Nicht TDE!)

3) Ähnlich wie 1, Aufbau einer Mittelschicht in der Anwendung, die derartiges unterbindet.

Und schlussendlich sollte man für kritische Daten auch über eine Überwachungslösung nachdenken.

Security-measures

What can prevent such forms of attack?
Essentially there are 3 well-known methods at hand:

1) The use of stored procedures which catch all errors, or, if one really wants to use views for some reason, using of a multi-statement table valued function which will be put between.

2) Data encryption (Not TDE!)

3) Similar to 1, implementation of a mid-tier in the application which prohibits such actions.

Finally one should also think about an Auditing solution for critical data.

Die hier gezeigte Technik der Row-Level Disclosure ist nicht wirklich etwas Neues, wird aber gerne immer mal vergessen.
Nachlesen kann man darüber zum Beispiel auch in diesem (alten, aber immer noch zutreffenden) Whitepaper:

The technique of Row-Level Disclosure shown above isn’t really new, but frequently forgotten about.
One can read about this, for example, in this (old, but still applicable) whitepaper:

Implementing Row- and Cell-Level Security in Classified Databases Using SQL Server 2005

 

Happy securing,

Andreas

 

Wer sich ermuntert fühlt, nun einmal richtig in das Thema „Sicherheit mit SQL Server“ einzusteigen, für den habe ich auch 3 erstklassige Trainings im Angebot:

If you now feel encouraged to really dive into the subject of “Security with SQL Server”, I do have 3 first-class Trainings on offer:

Für Beginner, die hier einen guten Überblick erhalten und Grundlegende Kenntnisse erlernen:

For Starters, who gain a good overview and learn essential knowledge in the basics:

(SES) SQL Server Security Essentials for Developers & Administrators (1 day)
3. April 2014 in Düsseldorf

Für Administratoren, die fortgeschrittene Sicherheitskonzepte umsetzen müssen:

For Administrators that have to implement advanced security concepts:

(SIA) Securityworkshop for SQL Server Administrators (advanced) (1 day)
4. April 2014 in Düsseldorf

Für Entwickler, die fortgeschrittene Sicherheitskonzepte umsetzen müssen:

For Developers that have to implement advanced security concepts:

(SID) Securitysworkshop for SQL Server Developers (advanced) (1 day)
24. April 2014 in Düsseldorf