Just Enough Governance for Notes Blog

1 - It's very simple if you have SOX controls implemented in your coorporation.
1) Changes are following the path from (Experimental -> Research ->) Development -> Test -> Stage -> Production
2) Developers can only update changes from Development to Test
3) Application Administrators are only allowed to update changes from Test to Stage
4) Only the trusted one can update changes from Stage to Production

2 - Craig,
Good post! This is something I've been bugging you guys for years to do something about. Ask Dana Hooker :)
I'm in a SMALL environment. I'm the developer who's also a backup admin. So I have admin access to all the servers. We also have a test domain like we should. I follow a good promotion methodology but there's nothing that PREVENTS me from changing code in production.

Currently, the only way to do this right is to give me two id's. 1 for admin and 1 for "normal". That just doesn't work well since I go back and forth between both regularly. So how do we prevent me or our main admin who also develops from modifying code in the production domain?

A LONG time ago I was interested in putting the production db's under CIAO control to prevent this. Was told it wasn't recommended to do that on a production box.
I've inquired a couple of times about maybe using Snapper for this to not necessarily prevent the changes but to at least log them. That would be almost there. But you really need to make it difficult for the admins to "Disable" this kind of monitoring or tampering with any logs.

I think what you really need is a product that get's installed on a production server. It should be rather difficult to turn off so it can't be done on a whim. And gives you an option on preventing changes or allowing them but WITH logging and notification.

To me it seems Teamstudio has all the pieces to do this... they just need to be put together for this specific purpose.

Just my 2 cents.

3 - @David - ACL will allow you to prevent someone making changes. For everyone besides admins it is relatively easy to keep people out - don't give them access. The administrators of the server are required to have an elevated level of access to the applications, so no matter what technological solution you have chosen, they are still going to be able to disable it. You have to trust someone with the keys, but with out a clear policy for what is allowed and not allowed, you have no hope of controlling things.
That being said, Teamstudio has a tool called Usage Monitor which can log all design changes on a server. Those logs can be reviewed on a regular basis and even have alerts set up so you know when a change happens. This still has the problem though of being disabled by an admin intent on making changes.
The only true solution is perform regular audits of last modified dates for all designs or possibly sign all designs with an ID that cannot be accessed without a password that is only known to a 3rd party.

4 - Developer changes in Live = P45

Its a simple mantra and one that even rhymes.

In our live env developers only have standard "user" access to our applications. If a developer needs greater access for debugging etc (although as we use openlog this is not very often) a change request needs to be raised, and as soon as they have finished their access is revoked.

We have also started to roll out the excellent (well I do have a vested interest) Audit Manager from openntf.org. We use this in out test env to monitor configuration/keyword changes.

I am looking to implement AuditManager on our live servers to monitor keywords and design changes, just incase our Admin team feel like making a "quick fix" lol