Security - Best Route??

[Brambojr]

My question I think is a bit odd - and yes I have read up on this - I am working on a DB at home that I hope to propose at work as a solution to Runaway Speadsheet Syndrome. SO, the problem becomes two fold, first what is the best way to implement the security? Should this be the last step, and that done at work on the network?
Second, when this is done I want the maintenance to fall to someone in an HR-type position. They are comfortable with computers, but not a "technical user." How should this be handled? I am tempted to create a table and have the security bounce off of that, but it is not as good as MS security. So, do I (or someone) train her how to add new users to the groups, pass the baton to someone in IS (I am a supervisor in a non-IS postion), or bite the bullet and claim this baby as mine?

This is not exactly covered in books, and it seems experience (of which I am a bit shallow) may be able to smooth this process over and help me to not torpedo a carreer doing what I REALLY like - working with people almost full time.

Any insights?

Thanks, Brambojr

 

[dneufarth]

From past experience (sec admin), I always try to take a completely opposite viewpoint to what I, or someone else, propose.

First and foremost, do you really need to secure the app? Very few users and supervisors understand data security. If so, WHY? (legal/governmental requirement, distribution of duties, accountability, intrusion prevention, data integrity, etc.)

If so, where in our policies is that stated, who's responsible, and and how can I make it comply?

Large businesses usally have someone in charge and data security policies, as well as support and review procedures in place. Get their help up front; don't wait to everything is built and insert security control a few days before implementation.

Suporting via a sec admin role should be easy enough to learn by someone comfortable with PC's and MS Office. Especially if the groups are well defined. Then it becomes mostly adding/changing/deleting users to/from groups. You'll also need a back up person for those pesky absences and vacations.

Second, albeit off topic, will it scale up to more users? If expected to, make sure it will and verify existing security still meets your needs.

Don't kid yourself about maint responsibility; either day-to-day or programmatically. If you build it, YOU OWN IT. You are the knowledge center -- good or bad.


Dave

 

[MichaelRed]

I would add one item to Dave's post. If you aren't REALLY omfortable in the role as "programmer" - DO NOT take this - or any other 'home grown' widget of programming into the office. IF it is a useful bit of something for the office, suggest it - in writting - to the 'geek pool', give A LOT of specifics - but NOT the forms/tables/reports/code from your 'prototype'. Give the REQUIREMENTS for the FUNCTION. Give the concept. Let them do their thing. If it is to be used within YOUR area of responsability, offer to be an 'advisor' to the group doing THEIR development, otherwise just leave it to the 'suggestion box', and hope the rest of the world sees the value in the concept.

The only other avenue is - per dave -

[red]"You build it, YOU OWN IT."[/red]



MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[Brambojr]

Thanks guys,

What you said makes perfect sense, I guess I have just been getting impatient with a process that no one seems to see as inefficient and error prone. As for the other component I am trying to learn DB and Access to a certain level in the hopes that at some point it plays to my favor. And as with fiction - write what you know. I must (begrudgingly?) admit that you two made perfect sense with your responses, and will behave myself.

FYI - the "geek pool" is all of two to three people large in our area and they are only as functional in DB as I am. In other words - a puddle.

Que Sera, Sera,

Brambojr