Re: Database utilities



> 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.
>
>


.



Relevant Pages

  • [NEWS] IBM Informix Web DataBlade Local Root by Design
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... that ease development of "intelligent", interactive, Web-enabled database ... person who has access to change the Perl script. ...
    (Securiteam)
  • Re: Multiple Database Security - How to handle
    ... There is no 'execute as' in SQL Server but you can simplify security ... Assuming the DM database contains tables that are accessed only by ...
    (microsoft.public.sqlserver.security)
  • Executing Informix dbaccess in a Windows background environment
    ... Our main objective is to execute an Informix stored procedure that will ... to create an sql script file each day, and to execute it using dbaccess. ... connecting to the database server. ...
    (comp.databases.informix)
  • Re: script "chaining"
    ... If a task would take too long to run while attached to the browser, the current system writes the data to a database file. ... The daemon checks that file every 10 seconds and executes the task, writing the data back to database. ... If you take the A out of LAMP you can write a php script like a bash script or a perl script and execute it. ...
    (comp.lang.php)
  • Re: ASP.NET Uploading Security Issue?
    ... > Read & Execute, List Folder Contents, Read, and Write permissions, then ... > could they not upload a script and then surf to the location of that ... Assuming that you have the proper security to ...
    (microsoft.public.dotnet.security)