Re: Dormant database user accounts
- From: MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
- To: Niall Litchfield <niall.litchfield@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 16 Mar 2015 12:47:38 -0400
Indeed.
Checking your "infosec" policies first would be an excellent idea.
An excellent (and not entirely uncommon) policy is that "*user accounts may
never be deleted*" -- or, perhaps more properly "*userids may never be
reused*". They're not the same thing, but in Oracle, probably not too far
off.
Lots of sites do AUDITING. Those who do feel a perverse need to attribute
audited actions to specific individuals. When accounts get deleted, or
worse, userids are reused, the attributions in the audit data will probably
stop working properly -- you either lose track of to whom to attribute an
action, or you attribute it to the wrong person.
There's a fair-to-middling chance that your security officer would prefer
the you keep dormant accounts *locked* and *expired* (and keep them that
way indefinitely), rather than deleting them.
Even if there *aren't* already policies like this in place, perhaps there
should be. You might be doing people a favour by suggesting it before you
start deleting old accounts.
On Mon, Mar 16, 2015 at 10:08 AM, Niall Litchfield <
niall.litchfield@xxxxxxxxx> wrote:
> You might well already have policies on this, and I'd definitely want to
> match your infosec requirements rather than present them with a fait
> accompli. I'd add a couple of things that haven't been touched on so far.
>
> 1. You need to make arrangements to catch the replies to the emails so
> you'll need to make sure any mail sent to the reply-to address gets to the
> right people and doesn't, for example, end up in the same place as all your
> EM notifications.
> 2. No-one seems to have remarked that it is really not at all unusual
> for people to be validly away from work for more than 3 months and that you
> probably don't want to delete such accounts, though you may well wish to
> lock them early.
>
>
> ...
Other related posts:
