|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, March 25, 2004 5:05 AM
Points: 5,
Visits: 1
|
|
|
|
|
|
SSChasing Mays
Group: General Forum Members
Last Login: Wednesday, May 30, 2007 4:59 PM
Points: 672,
Visits: 1
|
|
Can you check the link please
|
|
|
|
|
SSCertifiable
Group: Moderators
Last Login: Thursday, March 11, 2010 10:33 AM
Points: 6,371,
Visits: 950
|
|
|
|
|
|
SSC Eights!
Group: General Forum Members
Last Login: Yesterday @ 3:55 AM
Points: 806,
Visits: 599
|
|
There are several arguments to store SP's outside SQL Server, not 1 of them is touched in the article. The reasons mentioned here are farfetched IMO.
Kind regards,
Hans Brouwer
Kind regards,
Hans Brouwer
|
|
|
|
|
SSCommitted
Group: General Forum Members
Last Login: Today @ 12:57 PM
Points: 1,753,
Visits: 1,014
|
|
I liked the article as it clearly put forward the concept. I'm not sure I see a business need at this time but it is an idea I'll keep in mind if circumstances warranted.
Francis
|
|
|
|
|
Grasshopper
Group: General Forum Members
Last Login: Wednesday, November 05, 2003 12:00 AM
Points: 10,
Visits: 1
|
|
An interesting conceptual article with limited practical use. However, the author does caveat the baggage of EXEC commands.
Using this requires explicit permissions for users at the table level since EXEC does not maintain ownership chains.
The database design is no longer abstracted and must be continually published to a larger user community instead of a corporate data model.
Supportability by an IT department is compromised. Performance can no longer be guaged or predicted since SP behavior would change. In a DB that resides on a shared server a poorly performing user built statement could adversely impact other systems.
Not to mention all of the other benefit derived from the use of stored procs. No recompiles....
|
|
|
|
|
Keeper of the Duck
Group: Moderators
Last Login: Today @ 8:53 AM
Points: 6,266,
Visits: 1,358
|
|
Weighing in from a security perspective, a lot of what is being said here is disconcerting. I'll offer a few brief comments:
All of these cases make use of BULK INSERT. This would require users to be placed in the bulkadmin role... not typically a good idea. The reason for bulkadmin here is to avoid the use of xp_cmdshell, which has obvious security concerns.
With that said, the idea of the code existing in a file and potentially outside of the control of the DBAs makes the job of maintaining security on the SQL Server that much more difficult. What essentially is being done here is the SQL Server DBAs are being tasked with all the responsibility but none of the authority... they don't control who has access to the file.
Case 3 can be handled by creating the stored procedure and using WITH ENCRYPTION. So long as the developer has neither sysadmin rights nor the ability to CREATE PROC with the database, the encryption angle is covered.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Contributing Author of How to Cheat at Securing SQL Server 2005 and Pro SQL Server 2008 Administration
| Professional Site | Blog |  View Brian Kelley's LinkedIn profile | Twitter
|
|
|
|
|
SSCertifiable
Group: Moderators
Last Login: Thursday, March 11, 2010 10:33 AM
Points: 6,371,
Visits: 950
|
|
|
|
|
|
Keeper of the Duck
Group: Moderators
Last Login: Today @ 8:53 AM
Points: 6,266,
Visits: 1,358
|
|
Agreed. Security people are paid to say no first. It doesn't make us very popular. 
With that said, business must make the decision between security and functionality based on risk. For some environments these represent a suitable low-risk solution that off-loads work from the DBAs.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/
Edited by - bkelley on 10/27/2003 3:27:43 PM
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Contributing Author of How to Cheat at Securing SQL Server 2005 and Pro SQL Server 2008 Administration
| Professional Site | Blog | View Brian Kelley's LinkedIn profile | Twitter
|
|
|
|
|
SSChasing Mays
Group: General Forum Members
Last Login: Wednesday, May 30, 2007 4:59 PM
Points: 672,
Visits: 1
|
|
quote:
With that said, the idea of the code existing in a file and potentially outside of the control of the DBAs makes the job of maintaining security on the SQL Server that much more difficult. What essentially is being done here is the SQL Server DBAs are being tasked with all the responsibility but none of the authority... they don't control who has access to the file.
|
|
|
|
