No arguments that database security on its own is insufficient, and I
wasn't implying that it was. What I was commenting on was the notion
that providing a data service layer improves security, or better
stated, that better security is sufficient justification for creating
a data services layer.
I did notice that my original post was missing a key "not." The lack
of a typical XML style service interface (and an actual implementation
behind it, obviously) is not the problem with securing data access.
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On Jul 7, 2008, at 4:33 PM, Michael Poulin <[EMAIL PROTECTED]> wrote:
Sorry Todd, this is off the SOA topic - a database security is not
suitable for application security any more; it was designed for
limited and not frequently changing number of uses initially.
Nowadays, Db security is good for DBA primarily.
For the applications, especially, distributed application, an
enterprise has to have separate security systems (and services).
One of the best security practices says that the threat must be
stopped before it reaches the resource (concept of 'locked door').
When intruder gets to the database with a fake (stolen) identity ,
it is not a good practice. Good Entitlement systems used to
intercept requests from applications and kill unauthorized ones to
the database or explicitly filter out access to particular (to be
protected) data fields.
I do not understand HOW service interfaces might know anything about
its implementation; even if you pass through an identity of the
consumer ( which is good thing to do), there is no mechanism in the
interface capable of relating this ID to a database, right?
- Michael
----- Original Message ----
From: Todd Biske <[EMAIL PROTECTED]>
To: "[email protected]" <[email protected]
>
Sent: Monday, July 7, 2008 6:51:14 PM
Subject: Re: [service-orientated-architecture] Re: Vandersluis on a
Data Abstraction Layer's Benefits
Regarding securing access, I'd argue that the problem is the lack of
service interfaces, but rather the inability to pass true identity
through to the database, relying on system accounts associated with
connection pools instead.
-tb
Todd Biske
http://www.biske. com/blog/
Sent from my iPhone
On Jul 7, 2008, at 9:33 AM, "Kirstan Vandersluis" <[EMAIL PROTECTED]
com>
wrote:
> --- In service-orientated- architecture@ yahoogroups. com,
Michael Poulin
> <[EMAIL PROTECTED] .> wrote:
>>
>> The DAL became a point of indirection where all needed
interceptions
> of data could happen. It was not related to any particular
> application. Moreover, it was a mandatory environment element for
> access all strategic DB.
>
> Michael, you bring up another set of benefits of a data abstraction
> layer: regulating and monitoring access to the data. I certainly
> hear consistently that this is a big issue with companies I work
> with. Most continue to use ad-hoc methods to restrict access, such
as
> allowing access to the database only through stored procs (no ad-hac
> queries).
>
> In an SO environment, it seems these requirements could be satisfied
> at a higher level by run-time governace tools like those from
> AmberPoint and Forum/XWall. Still, I see those responsible for the
> data may continue to want control, or at least monitoring of the
data
> layer.
>
> -Kirstan
>
>
>
> ------------ --------- --------- ------
>
> Yahoo! Groups Links
>
>
>
