Developer Access 2980
Wesley30 last edited by
I just join this forum and I have a question with regards to developer role having access to non production environments with power roles. We have 3 power roles Functional IT Support Role, HR IT support Role, and Developer IT Role.The roles mentioned below can do the following:
Functional IT Support Role: Performs all Functional Support and Configuration duties for all Modules outside of HR/Payroll. This role is restricted from accessing HR sensitive-data.
HR IT support Role: performs all Functional Support and Configuration duties for the HR/Payroll Module. This role can access HR sensitive-data.
Developer IT Role: The Developer engages in report and application design per the specifications and requirements of the modules and business units. Users in this role have read and write capabilities in Development and Prototype environment only. Though this role maintains access to powerful Development-related programs, its access is otherwise very limited. In order to grant these users necessary functionality for testing of Developed objects and other general administrative capabilities, users with Developer IT Role are also assigned Functional IT Support Role or HR IT support Role upon IBPS Management approval on a case-by-case basis.
Our developers has Developer IT role and from time to time they are requesting for Functional IT Support Role and HR IT support Role as an addition to their current role, If a developer wants IT Support Role and HR IT support Role to be added on their access, we just need to secure the approval of the role owners then once approved we assign it for a limited period of time with validity. This is the scenario that we have in the past.
Now we have a problem, because the owners of Functional IT Support Role and HR IT support Role starts disapproving request from Developers to add these roles to their current Developer IT role and arguing that the reason why they are disapproving it is because of SOD conflict.
Questions and my view with the issue:
Is there really an SOD conflict/audit issue? For me there is no SOD conflict that will arise because of the following points:
- Developers are working in non production environment
- Before promoting any configuration/changes done in non production environment to production environment, testing and review are being done and approval are being secured before it can be promoted to Production environments.
SciathStar last edited by
I’m in agreement, along with a few other items to be included in the change mgmt process (ie. review of change logs to ensure only authorized changes have been moved to PROD).
As with any Segregation of Duties (SoD) control, the following needs to be segregated (specifically for this question):
- Custody (programming)
- Authorization (promoting changes from DEV to PROD)
- Review (monitoring change logs)
In this case, it’s imparative the ‘Developer’ does not have access to move the changes into production (ie. access to the PROD environment or access to ‘schedule’ jobs to promote changes into production - these are obvioulsy one in the same).
It goes without saying, but it’s also necessary to have an appropriate ‘change management’ process in place (which I have somewhat eluded to above), to ensure appropriate segregation between all key elements of the change management process, with different individuals responsible for:
- requesting and approving changes,
- programming changes,
- appropriately testing changes (SIT, DIT, UAT),
- moving changes in and out of production, and
- monitoring program change logs.
Have a good one.
Jeffrey Cunningham, MBA, CPA