A few months ago, I was fed up to receive complains from my teammates about security settings changed on the development (or test) server. Every week, someone was at my desk complaining with a variation of “My development was working previous week and now it’s not working anymore. Someone (not me) must have change something about security but I don’t know who and why!”.
To give you a correct picture about our SQL Server environment, we’ve one instance for the dev server and another the test server but many people are developing on a given project. Consider also that we’re developing different projects at the given moment. All team members are (full) administrators of the dev and test servers. All team members know that the rule about security is “reduce privileges to the minimum required” (definitively
db_owner is not a solution) and this rule will be checked during code reviews.
Some will consider a classical approach, supported by most DBA: we should restrict the administrator rights to less people: a kind of single-point-of-security. Well, it was probably my opinion seven years ago but my position has dramatically changed on this. This point of view is really based on my own environment … your mileage will vary but keep in mind that I’m speaking at the dev and test level not production. Main point for this position is that I’d not recommend a “single-point-of” for any agile development. The true names are not “single-point-of” but “bottleneck”, “not-shared-decisions”, “I’m-the-only-one-who-know-don’t-fire-me” and “not-my-business-ask-this-guy” … four things that I’m trying to avoid as much as possible.
I implemented a solution to track any change to “security” on the SQL Server. Not a word to my team members … I was the only one to know that something has been scripted and deployed. After a few weeks, my conclusion was clear: nobody in the team is trying to sabotage the work of others. After investigations, issues could be grouped as
- You changed the code and it’s now requiring new privileges: Script them and stop blaming others.
- During development, you manually added some privileges to the database. But the deployment script is not including all these privileges. Someone has redeployed the solution from scratch, discarding all the unscripted privileges. It’s your mistake.
- Less frequent … indeed, someone on another solution is also developing on this shared component (SSISDB) and has a different definition than yours for this shared role. Discuss together and align your needs.
So clearly it was not a question of responsibility or trust but a problem of practices:
- All privileges must be scripted (and reason to request them documented) and committed in the solution. It must be part of the deployment artefact (at least in dev/test).
- All the work performed on SSISDB (or any shared component) must be executed on a shared project
That’s not enough, practices not supported by tools are pointless and will never be applied during more than a month. We must provide a tool for people to know who has changed “security”. The following trace is doing the job:
use [master]; go create server audit [Audit Login Changes] to file ( FILEPATH = N'N:\Trace\' , MAXSIZE = 1024 MB , MAX_FILES = 10 , RESERVE_DISK_SPACE = OFF ) with ( QUEUE_DELAY = 1000 , ON_FAILURE = CONTINUE , AUDIT_GUID = '33e055a9-1924-47c3-9798-e8875a5bcd42' ); alter server audit [Audit Login Changes] with (state=on); go create server audit specification [Audit Login] for server audit [Audit Login Changes] add (DATABASE_ROLE_MEMBER_CHANGE_GROUP) , add (SERVER_ROLE_MEMBER_CHANGE_GROUP) , add (DATABASE_PERMISSION_CHANGE_GROUP) , add (SERVER_OBJECT_PERMISSION_CHANGE_GROUP) , add (SERVER_PERMISSION_CHANGE_GROUP) , add (DATABASE_PRINCIPAL_CHANGE_GROUP) , add (SERVER_PRINCIPAL_CHANGE_GROUP) , add (SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP) with (state=on); go
and the following query will help you to investigate the traces. Since this instant, I just received a few complains and it was about Windows (disk access for read/write files with SSIS) issues.
declare @LogFilePath varchar(255); select @LogFilePath=log_file_path from sys.server_file_audits where name='Audit Login Changes'; set @LogFilePath=@LogFilePath +'*.sqlaudit'; select session_server_principal_name ,database_name ,object_name ,m.class_type_desc ,statement ,convert(datetime, switchoffset( convert(datetimeoffset, event_time) , datename(TzOffset, sysdatetimeoffset()) ) ) from sys.fn_get_audit_file (@LogFilePath,default,default) f inner join sys.dm_audit_class_type_map m on m.class_type=f.class_type order by event_time;
I know that if someone wanted to hijack this trace it would be easy to stop it (and restart it), but keep in mind that I’m not trying to fix a security issue but to fix a process issue during the development.