Re: Database utilities
- From: "Dan Guzman" <guzmanda@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 7 Dec 2005 08:25:18 -0600
> The script would not actually be executed by the text editor, but
> otherwise this is an example of something that would be impractical to
> remove.
You are, of course, completely correct. I should have said "write using any
text editor and execute using standard OS componenets".
> I think that perormance is not a typical security matter. Performance
> considerations such as this make the problem much more complicated. In
> those situations where elimination of possible performance problems
> require a security solution different from other security solutions, I
> think that the benefits would not justify the cost. I think that
> performance problems should not be a primary duty of security and is
> especially outside the scope of my project.
I included issues related to authorized data access because I don't know the
scope of your security project and these considerations could affect your
security analysis and design. In the broader sense, security includes
taking reasonable precautions to ensure that data are accessible by
authorized users. Some companies also include DR under the security
umbrella.
> If the application provides the ability to execute a macro during or
> immediately following an application, is it possible that the security
> context could be changed then? I realize that this might not work for this
> particular application, so I am asking only if it might work.
>
> Perhaps it is possible to write a program that changes the security
> context then executes the application, but that would be impractical if it
> requires a separate login. I need to learn about SQL Server's roles before
> deciding to use a solution such as this.
>
I'm not sure I understand what you mean by 'macro'. If you are referring to
SQL script and the script is run by the app immediately after each database
connection, such an approach might allow you to enable an application role.
AFAIK, other 'macro' techniques would require separate accounts.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Sam Hobbs" <samuel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:O8AvMGo%23FHA.272@xxxxxxxxxxxxxxxxxxxxxxx
> "Dan Guzman" <guzmanda@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:u0%23ilqQ%23FHA.4092@xxxxxxxxxxxxxxxxxxxxxxx
>> Preventing access to database utility software does not in itself provide
>> data security. One can write and execute a script like the one below
>> using only a text editor.
>>
>> Set conn = CreateObject("ADODB.Connection")
>> conn.Open _
>> "Provider=SQLOLEDB;" & _
>> "Data Source=MyServer;" & _
>> "Integrated Security=SSPI;" & _
>> "Initial Catalog=MyDatabase;"
>> conn.Execute "DELETE FROM MyTable"
>
> The script would not actually be executed by the text editor, but
> otherwise this is an example of something that would be impractical to
> remove. The actual programs would be WScript and CScript. If removal of
> possibly risky tools is done to protect thd data, then WScript and CScript
> would have to be removed also, which would make all scripts useless. HTML
> scripting capability would also have to be removed.
>
>> it is often desirable to discourage ad-hoc SQL access to production
>> databases using database tools and utilities. Consider a non-technical
>> user with the database object permissions needed in order to use an
>> application. With a separate reporting tool, the user could easily
>> access the database from outside the application and cause blocking or
>> other performance problems with a poorly formed query. This is one
>> reason why it is common to create a separate database for end-user
>> reporting and provide users with the tools needed to do their job.
>
> I think that perormance is not a typical security matter. Performance
> considerations such as this make the problem much more complicated. In
> those situations where elimination of possible performance problems
> require a security solution different from other security solutions, I
> think that the benefits would not justify the cost. I think that
> performance problems should not be a primary duty of security and is
> especially outside the scope of my project.
>
>> Applications sometimes use an application login or role to provide data
>> access under a security context other than the end user. This approach
>> provides users with the database permissions needed to use the app yet
>> prevents adhoc access from outside the context of the application unless
>> the user's own login has been granted the access and permissions.
>
> I do not know if this application's login provides a different security
> context; I am not aware of that, but it is worth investigating.
>
> If the application provides the ability to execute a macro during or
> immediately following an application, is it possible that the security
> context could be changed then? I realize that this might not work for this
> particular application, so I am asking only if it might work.
>
> Perhaps it is possible to write a program that changes the security
> context then executes the application, but that would be impractical if it
> requires a separate login. I need to learn about SQL Server's roles before
> deciding to use a solution such as this.
>
> SQL Server's roles seem to be the prefered solution and I will read the
> article you specify before I ask any questions about roles.
>
>
.
- Follow-Ups:
- Re: Database utilities
- From: Sam Hobbs
- Re: Database utilities
- References:
- Database utilities
- From: Sam Hobbs
- Re: Database utilities
- From: Dan Guzman
- Re: Database utilities
- From: Sam Hobbs
- Database utilities
- Prev by Date: Re: Automatic Update Not Working
- Next by Date: Re: Database utilities
- Previous by thread: Re: Database utilities
- Next by thread: Re: Database utilities
- Index(es):
Relevant Pages
|