[공부] SAP 프로그램 변경 개발/운영 분리, T-Code SCC4, SE06 설정값
전산 감사를 수행할 때, SAP에 관련된 프로그램 변경통제에서 개발/운영환경의 분리라는 통제가 존재합니다.
개발/검증 환경까지만 개발자가 접근이 가능하여야하고 개발자가 검증이 완료된 파일을 Change Request를 통해 검증서버에 올리게 되면, 운영 이관자가 Import 버튼을 눌러서 배포를 하게됩니다.
이 환경에서 당연하게도, 개발자는 운영환경에 Import를 수행할 수 없어야 할 것입니다. 개발자가 임의로 개발을 수행하고 아무거나 운영에 반영한다면 어떤 변경을 했는지, 개발자가 악의를 품고 몰래 불법적인 기능을 숨겨 반영을 할 수도 있을테니까요..
그래서 물리적으로 개발/운영 (혹은 개발/검증/운영)으로 분리가 되어있어야 합니다.
[CTS - Change and Transport System]
CTS는 개발서버에서 변경된 사항을 운영 서버에 반영하거나 Client 환경에 적합하도록 커스터마이징하는데 사용되는 툴 입니다. (repository 버전 관리, 구성관리 툴의 역할도 수행)
SAP는 대부분 개발 - 검증 - 운영으로 분리가 되어 구성되어 있습니다. 간간히 어떤 곳은 검증이 없이 개발 - 운영으로 되어있기도 합니다. (대부분 감사를 진행한 곳은 3단계로 구성이 되어있었습니다. ㅎㅎ)
SAP 내의 프로그램 변경(주로 ABAP 변경)이 일어날 경우에는 cts를 넘긴다고 하고 검증계로 release하는 작업을 수행합니다.
(SAP 데이터 변경의 경우 SE16N_CD_KEY, CTS의 경우는 ABAP의 변경이나 테이블 오브젝트 생성 등과 관련됨.)
개발을 완료한 SAP 개발자는 Change Request를 생성하여 검증으로 release 합니다.
(T-Code SE01을 통해서 Transport Request를 생성/관리 한다고 합니다.)
[TMS - Transport Management System]
CTS안에는 TMS라고 하는 Transport Domain을 관리, Landscape를 관리(개발-검증-운영 등의 Landscape)하는 관리 시스템이 존재합니다.
Transport Domain은, 변경사항을 적용할 수 있는 그룹을 지칭하며, 해당 도메인 안에있는 시스템 끼리만 변경사항 적용이 가능하다고 보면 됩니다.
Transport Route는 T-Code STMS를 통해서 확인이 가능하며, 아래와 같이 생겼습니다.
기본적으로 개발 -> 검증 -> 운영으로 구성이 되어있습니다.
아래의 그림은 TEP(개발) -> VIR(검증) -> PRD(운영)이며, TEP->VIR은 Transport Layer로 연결되어있고, VIR->PRD는 Delivery로 연결이 되어있습니다.
개발쪽에서 object를 변경 시, Change Request를 통해 VIR(검증)으로 넘어가게되고, SAP Standard Object면 SAP Transport Layer로, CBO Object(Customer Bulk On - 자체 개발되는 건들, ABAP 등으로 대부분 개발)라면 ZTEP Transport Layer로 가게되는 겁니다. 개발에서 검증으로 Change Request를 Release 하는 것은 사실 감사 관점에서는 크게 중요한 부분은 아닙니다.
Delivery로 되어있는 부분은 릴리즈는 따로 필요가 없지만, 회사만의 통제 - 승인 프로세스 등을 거쳐서 import처리를 하여 반영하는 것 입니다.
감사 관점으로는 요청 -> 테스트 -> 이관요청 이 세단계가 적절한 담당자에 의해서 승인되었고, 문서화되었으며 적절한 프로세스로 반영이 되었는가가 중점이 될 것입니다. (E070 테이블에서 변경 건에대해서 Vouching 방식으로 모집단 수령 후 샘플 건들을 추적해나가는 방식)
아래의 Transport Route에 Single System Configuration이라고 날짜가 찍혀있는데, 이는 문구가 매번 동일하지는 않더라고요. 그래도 뜻하는 바를 보면, 해당 Transport Route의 설정값을 언제 변경했는지에 대한 날짜가 찍히는 듯 합니다.
변경시에도 회사는 작업계획서나 품의서를 통해 승인을 거쳐 변경이 되어야 합니다.
Changeability of one ABAP object is controlled by two transactions : SE06 & SCC4
The Global Setting within the System Option Change (via SE06) opens or closes the entire system, regardless of what the Client(SCC4) setting is set to.
System Change Option in transaction SE06 provides granularity on what repository and cross-client customizing objects can be modified.
This is more of a global setting (regardless of the client) and is only for client-independent objects.
In here, Repository objects are further subdivided into different groups (software components and name spaces) so you can set only which group can be changed.
Not modifiable in Global setting in SE06 overrides all other setting in SE06 and SCC4.
That means, nothing in this system is changeable except some customizing defined as current setting.
On the contrary, with modifiable as global setting it's possible to fine set some parts of this system as modifiable some as not modifiable.
감사 입장에서는 두가지 설정 모두 '수정 불가' 로 설정되어있기를 권고하는데 아래의 이유와 같습니다.
해당 설정이 '수정 가능'으로 되어있다면 클라이언트 카피가 가능하기 때문입니다.
예를들어서, 개발/검증 환경에서 모든 인원에 SAP_ALL, SAP_NEW의 권한을 가지고 있다고 치고, 이들은 개발/검증 환경에서 구성된 인원이기에 권한 부여 등 회사의 절차나 직무분리(Segregation of Duty)를 고려하지 않은 사용자 계정일 것입니다.
만약에 개발/검증환경에서 운영환경으로 Copy를 할 경우, SAP_ALL, SAP_NEW의 권한을 가지고 있는 비인가된 인원들이 권한을 보유하게 될 것이며, 이 권한 부여 이력 또한 운영환경에는 남지 않게 될 것입니다. 이는 감사 관점에서 프로그램 변경을 우회할 수 있을 것이고, 권한 부여/회수, 개발자/이관자 직무분리, SAP 설정 불법변경 등의 issue가 생길수 있습니다. 그렇기에 관련된 설정 자체를 아예 닫아두는 것을 권고하는 것일겁니다.
혹시나 더 추가해주실 내용이 있다면 댓글 달아주시면 감사하겠습니다!
아래의 아티클에서 나오는 SCC4의 Change Logs 부분도 저희 법인에서는 보게끔 하는 부분이기도 합니다. (추후에 문제 발생 시 Log를 확인할 수 있도록 Log를 남기게끔 설정해두어야 함.)
SCC4(클라이언트 레벨)가 잘 설정되어있더라도 SE06(System Landscape 레벨)이 미비하게 설정되어있다면 소용이 없으니, SE06도 반드시 세팅을 하여야 합니다.
SE06 System Change Option 아티클 확인 : http://www.sapbasis1solution.com/se06-system-change-option/
SCC4 vs SE06 아티클 확인 : http://arthur_ong.tripod.com/xbc017.htm
[관련 아티클]
URL : https://examaroo.com/sap-tcode-scc4-settings-production-client/
SAP TCode ‘SCC4’ Settings In The Production Client
- by Priyanka Jain
- July 9, 2020
SAP T-code ‘SCC4’ setting is very critical from the audit point of view. We need to understand what is the use of this and the recommended settings for it.
T-code SCC4 is used to define the client in SAP. After creating a client in SAP, you need to define different settings in it.
SAP t-code SCC4 allows any user to make direct changes in the production client. Hence, it is important to understand the different fields defined for it.
Following are the critical parameters in SCC4 setting:
- Status of audit logging and date of last modification
- Audit logging status for table ‘T000’
- Changes logs for SCC4
Further, we will understand how to read and understand the different fields defined in this transaction code.
Changes And Transports For Client – Specific Objects
In SAP, we have 4 option for change logs settings and it is very important from audit point of view.
- Changes without automatic recording:
If you select this option in SCC4 for production client, it allows the changes in the production client without recording any change logs.
Which may lead to any fraud or unauthorized changes in the production environment.
2. Automatic recording of changes:
This setting is the best setting from an audit point of view, when any changes are done in the production client.
It allows the system to record the change logs in a transport request.
3. No changes allowed:
This option restrict the users to make any changes directly in the production client.
4. Changes without automatic recording, no transport allowed:
This setting allows changes to be made in the system without automatic recording of change logs.
It also does not allow to create a transport request manually.
There is a risk of some unauthorized changes if the system settings are defined with option 1 or 4. As this setting will bypass the recording of the changes.
Audit Logging Status Check
You also need to make sure that audit logging should be enabled for the SAP table ‘T000’.
To check this you need to follow the below steps:
- Go to T-code ‘SCC4’
- Select the production client and double click on it.
- Click on ‘Logging: Display status’.
- It will pop up a screen showing ‘Logging is active in all clients’.
- Also check that table logging for the table ‘T000’ should be ‘Active’
Change Logs For SAP SCC4
If SCC4 settings are as per the required guidelines, you can’t make sure that any unauthorized changes were not made in the production client.
You need to check the change logs for SCC4. To check the change logs follow the below path:
Go to the transaction SCC4 -> Utilities -> Change logs.
Steps to Analyze the Change Logs of T-code SCC4
During the analysis of SCC4 logs we can check the following parameters:
- Date and time stamp of the change
- SAP ID or User ID to make the changes?
- Old value of changes
- New value of changes
Further, we can check whether changes were authorized and approved or not. We need to check whether there is predefined policy by the client for which you are working.
If, there exists a policy to make direct changes to production, check the following:
- Process to make direct changes to production
- List of required approvals?
- Authority of the user to make any direct changes to the production client
Subsequently, you can analyse the change logs and see if they are in alignment as per company’s policy.
You can also ask for approval evidences and check the below:
- Date of approval is same as the date of changes
- Reason for client opening is well explained
- Approval from an authorized approver
Conclusion: SAP T-code SCC4 Settings
I hope this blog will give you an idea about the settings of SCC4.
This is really important to keep a track on the direct changes. SAP transaction code ‘SCC4’ is defined to serve this purpose with some predefined configurations.
Additionally, we can check the settings defined it transaction code ‘SE06’. This t-code provides the settings regarding the changeability of an object in SAP system. It should be set to ‘Not modifiable’.