In Brian Kelly's recent blog post, he makes an excellent case outlining why there are few options but to 'Trust' SQL Server Administrators. And then he goes into excellent detail explaining that it may be impossible to completely 'prohibit' disruptive behavior, and that one should establish a robust auditing of security events.

And it is not just the SQL Server Administrators, or the network administrators that require ‘trust’. It is anyone that has access to the ‘wire’.

A while back I was working on a project that had to meet a HS/FIPS standards that mandated that all data in transit be encrypted. I recall sitting in a meeting where, in response to my request for the establishment of encryption, (possibly IPSec) between the web farm and the data cluster, the director of the infrastructure teams bluntly stated that it would not happen because 'we trust our people'. There was continued resistance to finding any alternatives to meet the encryption requirement. The network administrators were firmly opposed to having packets on ‘their wires’ that they could not ‘look into’. There were attempts to find some manner of ‘waiver’ from the standards. My arguments about the difficulty involved in discovering passive sniffers, or that anyone with access inside the firewall could easily install an ‘unknown sniffer’ were summarily dismissed as ‘overly concerned’. My team continued moving ahead in preparation to the time when encryption deadline became inescapable.

A few months later, all IT infrastructure staff were required to undergo new background security checks. I was not surprised that some of the 'trusted people' abruptly resigned or were terminated. (I've noticed that about 15% of IT staff seem to either refuse to submit to, or fail security checks. Sometime termination is for issues that would not have prevented the initial hire, but became mandated since the issues were not disclosed on the application. Sometimes just 'youthful indiscretions'...

And the data in transit was finally encrypted.