[unisog] "Enterprise" SQL-based applications.

Michael Janke Michael.Janke at csu.mnscu.edu
Tue Dec 7 14:03:52 GMT 2004


This would be very useful. We typically run into vendor FUD when we
mention the possiblity of running more than one app on a server.

We'd include a specification such as this in RFP's.

--Mike


___________________________________
Michael Janke
Director, Network Services
Minnesota State Colleges and Universities
1450 Energy Park Drive Suite 300
St Paul MN 55108
Voice: 651-556-0583
Fax: 651-649-5770
Cell: 612-964-3340 

>>> derek.ethier at humber.ca 12/06/04 9:24 AM >>>
I have come across a particular situation a number of times and I was
wondering
if anyone had some innovative way of handling it.

Due to the fact that we are an "Enterprise" (ugh, I hate that term
sometimes)
environment quite often I recommend using Enterprise applications (or
versions
of..) that routinely require SQL-based services (commonly, MS-SQL). 
However,
many of these applications are developed with much smaller organizations
in
mind and naturally assume that they are the only application using a
particular
SQL instance.  Through this assumption they routinely require sa (or
root)
access, changes to the master database (embedded owner privileges on
objects oh
my!), etc. or the application will not work.

Rather than spend $$ on many different database servers (licensing,
hardware
etc.) I would like to come up with a standards' type document that
details what
a truly "Enterprise" SQL-based application really is, and what a
developer
should expect when dealing with an Enterprise environment (particularly
from a
security standpoint).

Has anyone drawn anything like this up before?  If so, is it useful?  Is
what
I'm proposing useful?

Any information would be appreciated.  Thanks.

d.

_______________________________________________
unisog mailing list
unisog at lists.sans.org
http://www.dshield.org/mailman/listinfo/unisog




More information about the unisog mailing list