Hi Lisa,
I think the best thing is to baby step your way through. Document
EVERTHING you do and let the users know before you do it. You may want to
request information from each user (send them a form perhaps) that
documents what they do with the application on a daily basis. This will
help you establish roles and point you in the general direction.
HTH
Rocky
- Ron Rogers <RROGERS_at_galottery.org> wrote:
> Lisa,
> Good Luck on your quest.. The company I work for has been in existence
> for 7 years and I started working for them 2 years age. There was no
> documentation at all about the database or applications when I started.
> The databases are now documented (I still request documentation for the
> applications but not yet. I can still hope) and I am trying to implement
> security options via roles and privileges. over 3 months ago I asked the
> developers, VP of development, Vp of IS for a list of which user needs
> what type of access to what table. No luck to date. I took it upon
> myself to create roles that accessed the tables I thought that were tied
> to the different applications. One by one I am moving the users to the
> role. If some one complains I then know what table I have to add to what
> role.
> The first step was to remove the resource privilege from the users as
> they run client applications and are select options only. The
> application that need other than select are given an id and the id is
> given a role with the additional privileges. Only the role has the
> ability to change any data. That puts the responsibility on the network
> group to only deploy the application to the users that need id. The
> development group uses a user table in the code to verify the user has
> the privilege to use the application.
> The second step was to remove the connect option and grant create
> session instead. So far it has worked and I have the majority of the
> "public" permissions revoked.
> Hope this gives some insite.
> ROR ª¿ª
>
> >>> lkoivu_at_qode.com 09/21/00 05:01PM >>>
> I inherited a database and application that was developed using the
> famous
> 'smear' method of privileges. In other words, everybody has access to
> anything to do whatever they please.
>
> It's time I cleaned this up. I have no guidelines to work from and
> quite
> honestly don't know the application too well - I have written a minute
> amount of code for this app. I'm thinking I could sift through
> dba_source
> as a starting point, to see whose procedures are accessing stuff outside
> their schema, etc. Man, this is going to be a big, tedious, messy
> trial-and-error nightmare.
>
> If anyone has done anything similar and has any suggestions I would be
> very
> happy to hear them.
>
> Thanks
>
> Lisa Rutland Koivu
> Oracle Database Administrator
> Qode.com
> 4850 North State Road 7
> Suite G104
> Fort Lauderdale, FL 33319
>
> V: 954.484.3191, x174
> F: 954.484.2933
> C: 954.658.5849
> http://www.qode.com
>
> "The information contained herein does not express the opinion or
> position
> of Qode.com and cannot be attributed to or made binding upon Qode.com."
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Ron Rogers
> INET: RROGERS_at_galottery.org
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
Rocky Welch
Oracle DBA Consultant
rockyw_99_at_yahoo.com
Do You Yahoo!?
Received on Fri Sep 22 2000 - 10:02:18 CDT
