Outboard integration - Security concept for decentralized deployment
Outboard integration - Security concept for centralized deployment
Outboard’s security concept distinguishes two borders of data flow:
- Archiving client to Outboard,
- Outboard to External Storage
Security concept of communication – Archiving client to Outboard
To prevent unauthorized access Datavard Outboard DataTiering is built to comply with the SAP authorization concepts, where each connection carries out an authorization check.
...
Level of security at this border is generally lower than at the outbound border towards external storage because its typically within internal corporate network.
Security concept of communication – Outboard to External Storage
Outbound communication with an external storage, MUST be secured. This is achieved using secured protocol that is storage platform-specific and therefore depends on API utilized by corresponding Storage Management connector implementation (e.g. HTTPS, Secured NFS, etc.). Additionally, authorized access is controlled using platform-specific authentication / authorization concept, e.g. using Kerberos, Active Directory and others together with user permission management.
Authorizations & Segregation of duties
The Outboard Service requires 2 users
- Maintenance: Administrator dialog user
- Operation on data: Service user – used in Outboard HTTP Service definition
User Type | SAP Transaction Codes | Datavard Transaction Codes | Specific Authorizations |
---|---|---|---|
Archiving Administartor dialog user | OAC0, SE38, SICF, SM59, SU53, SLG1 | /DVD/SM_SETUP, /DVD/CRP_SRC, /DVD/CRP_SRC_SM, /DVD/CRP_HAL_CERT | Authorization for debugging (for deep issue analysis) To operate Outboard --> /DVD/CRP - ACTVT = * |
System Service user | N/A | N/A | To execute commands in the Outboard --> /DVD/CRP - ACTVT = 16 To execute RFC calls to external service --> S_RFC - ACTVT = 16, RFC_TYPE = G |