Post reply

revoke execute rights to stored procedures in master DB

  • November 25, 2009 at 3:32 pm

    #214179

    In previous editions of SQL server I have revoked execute permissions tothe public server role for all stored procedures in the master DB (with the exection of 2 I can think of in 2005).

    This has in some cases caused more hassles than it may have been worth in the original setup, however it does (provided everthing else is done along with it) turn your database server into quite a fortress (WIN!).

    I strongly believe that every situation is different and needs to be considered on its merits (things have to work!) but what is everyones thoughts on doing this in 2008?

    a show of hands for who deems it necessary and who doesn't.

    Cheers,

    Carlton..

  • November 29, 2009 at 4:34 pm

    #1085192

    Your should consider evaluate the audit options in SQL Server 2008 instead of modify the original security settings.

    SNM

    Try Free Microsoft SQL Server Data Collector & Performance Monitor.

    http://www.analyticsperformance.com[/url]

    @nalyticsperformance - Microsoft SQL Server & Windows Server Free Data Collector

  • November 29, 2009 at 5:06 pm

    #1085203

    this practice is in 'how to do a security audit 101' so if you ever have the auditors in you will be asked to do this.

    Not a bad thing in itself but if you carte blanche deny all permissions in master most apps will hit permissions problems so you will have to loosen it up a bit again, preferable by granting to a user created role rather than public.

    ---------------------------------------------------------------------

  • November 29, 2009 at 5:42 pm

    #1085208

    Hi George,

    Thanks for the comments, I am in a position where a large portion of the servers I build/look after have the potential to be audited by an external firm.

    I realise the pitfalls (and agree 100%) and have broken many hearts (as DBA's often do) with implementing this but in my eyes many times this is a necessary evil as the team of people/person who developed the solution is not necessarily audited: I am...and in many cases they are no-where to be seen.

    If you can identify and document these as a risk before the solution goes live: the potential audit descrepancies are quantified/signed off and you are in a position to ask the question.

    I try to do this in the "build stage" I would be very sceptical of doing this on an existing server.

    Cheers,

    Cartlon..

  • November 29, 2009 at 5:45 pm

    #1085209

    ...and yes: I agree and practise the "grant to the pricipal not back to public" 😀

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply