How to install Security Policies for your SQL Servers

I just got back from another great meeting at my local SQL Server User Group. In tonight’s meeting we had a presenter named Joe Toscano.  Here’s some info about Joe the presenter:

Joe Toscano of RDA is a SQL Server Business Intelligence consultant, instructor and speaker based near Philadelphia, Pa. He has worked extensively with SQL Server since version 6.5, as well as Sybase and Informix prior to that. Joe’s areas of expertise include Data Transformation Services (DTS), Integration Services (SSIS), Transact-SQL (T-SQL) programming, data warehousing, performance tuning, replication, high availability (mirroring), security, disaster recovery, upgrading, migration projects and lights-out DBA tasks.

Joe was an absolutely wonderful presenter.  You can really see his passion and knowledge for databases by his expressions and demeanor throughout his entire presentation.  I was intrigued by his session from the beginning and he kept me extremely interested until the very end.  I thought the information I learned from him made for a great post so that’s why I am sharing that information with you all now.  So, Policy management.  What are they all about? 

Well Policy Management is a new feature in SQL Server 2008.  It allows you to define and enforce policies for configuring and managing SQL Server across the enterprise.  It requires setting up a Central Management Server (CMS) which acts as the traffic cop that monitors the other servers in your environment.  This CMS server must be SQL Server 2008, but it can monitor lower servers, like 2005 and 2000 etc.  When using the policies in 2008 and 2005, the policies actively prevent the conditions from occurring by issuing errors via ddl triggers.  With the servers pre 2005 they didn’t have this functionality yet so it is more of an after the fact implementation.  It’s still a great mechanism to keep track of those things none the less. 

So, before we can dive deeper into the subject and see some examples there are a number of terms that we need to define and understand regarding Policy-Based Management and those terms are:

  • Target - an entity that is managed by Policy-Based management; e.g. a database, a table, an index, etc.
  • Facet – a predefined set of properties that can be managed
  • Condition – a property expression that evaluates to True or False; i.e. the state of a Facet
  • Policy – a condition to be checked and/or enforced

I found this great step by step walkthrough with screenshots from Ray Barley on how to set up Policy-Based Management

How to Audit SSAS role permissions

A while back I was very disappointed to discover that SSAS does not have any easy way to go through all of your dimensions and cubes to see which users have access to which dimensions, cubes, etc.  Sure you can go one by one in order to get the information, but I was really just looking for an easy way to view the permissions based on individual object permissions, similar to the way you can in SSMS.  I called Microsoft and unbelievably they had no solution.  What a pinch to be in when you have an important audit coming and now it is going to take an absorbant amount of time to come up with the data the auditors are going to need.

Well, fortunately for me, I ran into an incredible site today.  It’s called ASSP – Analysis Services Stored Procedure Project This site is great!  It’s an open source project and it is just what the doctor ordered.  You can download the software and open up the project in Visual Studio.  From there you just build the ASSP assembly and you are all set.  This assembly has a number of various functions built into it and it returns a number of helpful datasets in the datasets you will be looking for.  They have also have additional reports and things pre-made and built right in to the project for you as well, so you can deploy those right to SSRS.  Here is an exerpt of one of the funtion calls and documentation:

DiscoverXmlMetaData(path, restrictions)
This function executes a DISCOVER_XML_METADATA command, which returns a hierarchical resultset and then “flattens” that resultset and returns it as a datatable which can be displayed by SSMS or used in a Reporting Services report.

Unfortunately standard Xpath style queries did not prove rich enough to return data in it’s full context. That is you could return a list of all the dimensions in every cube on a given server, but you could not return a column containing the cube and database to which they belonged. So a hybrid Xpath syntax was developed which allows you to specify a list of fields to return at each level.

The easiest way to explain this is with a few examples

In order to return return a list of all the dimensions in every cube in the current database you would issue the following command.

CALL ASSP.discoverXmlMetaData("DatabaseCubesCubeDimensionsDimension");

But this returns the list without any context, If you want to report the CubeName and LastProcessed date you would put a vertical bar (|) after the Cube element in the path and then put a comma separated list of fields that you want returned

CALL ASSP.discoverXmlMetaData("DatabaseCubesCube|Name,LastProcessedDimensionsDimension");

Note: it is not entirely true that the DiscoverXmlMetadata() command returns data without context – one of the features of this function is that it automatically returns the “ID” field of any ancestor elements in the resultset.

If you want to see what sort of paths are available the easiest way is to run the following command in an XMLA query window. You basically need to skip the xsd:schema> element and look at what is returned under the <row><xars:METADATA> elements.

<Discover xmlns="urn:schemas-microsoft-com:xml-analysis">
  <RequestType>DISCOVER_XML_METADATA</RequestType>
  <Restrictions />
  <Properties />
</Discover>

The path parameter actually matches from the leaf level up, so you could do a command like

CALL ASSP.discoverXmlMetaData("Dimension");

But this would produce a bit of a mess as it would return both cube dimensions and database dimensions and other dimension references from all over the xml resultset. The function is built in such a way that it build the columns for the resultset based off the first populated node in that matches the path so you will end up with a lot of blank columns.

But what this does mean is that you can specify just the minimal path that will unquiely identify the elements you are interested in.

eg

CALL ASSP.discoverXmlMetaData("CubeDimensionsDimension");

returns the same result as

CALL ASSP.discoverXmlMetaData("DatabaseCubesCubeDimensionsDimension");

It should be noted that because this is base on Xml, the path is case sensitive and “dimension” is not the same as “Dimension”.

Role information is not exposed by any of the other schema rowsets. The following commands will extract information about roles, dimension permissions, attribute permissions and cube permissions and would allow for the complete documentation of the security settings.

CALL ASSP.DiscoverXmlMetadata("DatabaseRolesRole");

CALL ASSP.DiscoverXmlMetadata("DatabaseDimensionsDimensionDimensionPermissionsDimensionPermission");

CALL ASSP.DiscoverXmlMetadata("DatabaseDimensionsDimensionDimensionPermissionsDimensionPermissionAttributePermissionsAttributePermission")

CALL ASSP.DiscoverXmlMetadata("DatabaseCubesCubeCubePermissionsCubePermission");

 

I am so thrilled!  This is just what I was looking for.  Check it out and see for yourselves just how great this assembly is.

Obfuscation and how it can help you today

In order to dive deeper into the subject we first need to develop a firm understanding of the word itself.  Obfuscation literally means “to conceal meaning, or to make more difficult to interpret.”  So, if we are obfuscating data we are masking the true meaning of the data itself.  So how is this then useful and important to database administrators?

In today’s world we store tremendous amounts of sensitive information in our databases.  We store people’s names, addresses, email addresses, account numbers, social security numbers and even bank account numbers.  We have so much identifying information in our databases and without careful preparations to secure this information; we are heading for disaster.  Lucky for us there are many ways we can secure this data.  We can encrypt our databases entirely, delete the sensitive data, or we can buy software to hide the data for us. This, however, doesn’t always solve the problem entirely for us. 

Consider the following situation:  We have a production database environment.  Any modifications to the production database should first be implemented and tested on a development or test database.  In order to ensure the accuracy of this testing, the development database often needs to mimic production as much as possible, in terms of the data contained etc.  The problem is that the developers are now having elevated rights and can see production level data that they otherwise would not have had access to see. This is a severe and intolerable security risk to the organization and its customers. 

In order to avoid these risks we need to disguise the data.  There are ways to perform these tasks without needing any algorithm, encryption or data type change.  We can obfuscate the data just as good for most companies using the following methods.

  • Character Scrambling
  • Repeating Character Masking
  • Numeric Variance
  • Nulling
  • Artificial Data Generation
  • Truncating
  • Encoding
  • Aggregating.

John Magnabosco’s article “Obfuscating your SQL Server Data” describes these methods to obfuscate data in further detail and he also includes a lot of really great example scripts that you can use to help you get started on your own methods.