30 Sessions, 11 Speakers, ALL SQL Server
No Travel, No Hotel, Just technical content. Direct to your computer.
The SSWUG.ORG Virtual SQL Server Conference
Featured Article(s)
Troubleshooting SQL Server 2005 jobs (Part 1)
In this article, Alexander Chigrik explains some problems you can have with SQL Server 2005 jobs. He also tells how you can resolve these problems.
Two Keys, And Two To Watch the Two Keys, And…
Ralph writes: "I have been seriously concerned for a long time about this very concept. (And, when I say "a long time" I am talking about approximately 3 decades. 😉
As with any information access that is tightly controlled, whether for private, corporate, or national security reasons, there is always going to be a weak spot somewhere in the system. Essentially it boils down to, "Who watches the watchers of the owner of the keys to the kingdom? And, once they are known, who watches them?"
There are the classic non-personal flaws in the concepts of he Watchers of the Keepers of the Keys, e.g. insufficient payment for services rendered, that make those individuals subject to economic pressures and temptations. There are also the classic personal flaws, e.g. greed, ambition, vindictiveness. However, these boil down to the question, "How do determine the moral integrity and personal ethics of a person, especially on a long term basis, and, thereby, determine the suitability of a person for entrusting them with sensitive data and data access?" At some point, one needs to place a level of trust in those who are in the position to "shop-lift" the data; however, we would be well advised to follow a maxim from the intelligence agencies, "Trust but verify".
Perhaps, what is needed is not so much the Two Keys approach but the Unique Key approach. Instead of having a master Sys Admin access (the classic "sa" access), each DBA/Developer/whatever should have a uniquely identifiable access that winds up in the log files along with what they were doing. perhaps there should also be some sort of notification if certain tables are modified (or accessed?).
Of course, this still means that there is someone in the organization who will have to set up these accesses (and thus will know the User Names and Passwords) and who will have to set up the notifications (and thus will know how to defeat them, if by no other means than removing and reinstalling them).
So . . . who watches this Keeper of the Keys? And who watches the watchers of this person?"
"Trust but Verify" is probably the most often cited suggestion that people have written with on this issue…
Video: SelectViews #105: Login Audits, Accidental DBA Quick Performance Checks, SQL Injection and Upcoming Events. Also, Find Out About Noise and News in the DB World and the 60-Second SQL Server Tip of the Day.
> Watch The Show
Other Video Programs/Shows available:
[Watch] SQLonCall – Staying on Top as a DBA
[Watch] SelectViews – Accidental DBAs, 60-second tip of the day, More
Featured White Paper(s)
Migrate, Manage, Monitor: Top 10 Tips for a Successful Move to SQL Server 2005
Effective planning and management enables a smooth migration and ensures that your new SQL Server 2005 environment will be ru… (read more)
SQL Server 2005: Deployments and Tests in an iSCSI SAN
iSCSI SANs offer an alternative for building Storage Area Networks. Consolidating storage in a SAN offers storage management … (read more)