S&E Domain model
Table of contents:
Domain model diagram
Entities
DeviceConfig
The device configuration (DeviceConfig) contains key references to be used for encryption and signing. It would also be possible to specify different packaging strategies here - in case there is the need to support multiple strategies or a divergence from the default strategy.
Encryption- and SigningKeyRef
The reference on secrets which is used to encrypt or sign the firmware. Note that the secret itself is not managed here (it is kept outside of the model because there are different technical solutions to deal with it). Additionally KeyRefs contain a user-friendly name and description of the referenced secret.
Signing Secrets, certificates and asymmetric key pairs
The use of signing secrets can be protected with additional security mechanisms, i.e. a four-eyes workflow and 2nd factor authentication (currently Bosch standard 2-factor auth). Signing secrets can be internally managed (like the asymmetric keys) or externally like certificates in the the Escrypt.KMS classic.
For more details about the approval flow see S&E Approval flow for signing tasks.
Audit Log / Audit Entry
For each interaction with the ACL, DeviceConfig or Task an audit entry is generated and stored in the audit log. Viewing of the audit log requires AuditEntry-Type level access (Application Right). Deletion from the audit log is not supported.
Events
The Sign & Encrypt functionality is event driven in order to de-couple parts which deal with the private secrets from public accessible APIs. All operations on tasks are tracked in the audit log.
For more details about Task, TaskStatus, and TaskResult see S&E Tasks.
Task
A task for device configurations can only be scheduled from a used who has the appropriate ACL rule. A task might need an approval (usually signing). There is a global configuration option to switch this on or of and it can be configured via an ACL rule specifying which user is allowed to approve.
TaskStatus
A task goes through a simple workflow, with the following flows:
TaskResult
The result of an Task is communicated as an event and tracked in the audit log. In case of file encryption the result will only contain a hash and a file-URL which might point to a non-existing file, as the result file itself will have only a limited time during which it is available for download.
The UI will give an indication to the user that the file is not available anymore.
User and right entities
User
The user is required to be referenced from the tasks. He needs to be authenticated via the Bosch Active Directory. For technical systems the user can also be an OAuth2 Client (managed via SuiteAuth).
Roles
Roles are consumed from Bosch.IdM but the OAuth2 token scopes must be mapped to Sign & Encrypt specific internal roles (also called resource-type level permissions) or ACL entries (see below).
ACL & entity permission (ACL entry)
The system manages one access control list (ACL) per tenant. A so called "initial admin" has the right to add additional entries to the list. These entries define how users can interact with the system.
For more details about ACLs visit S&E Access Control Lists.
ACL entries for tasks
For each task there are is a token generated which is used to execute the task in the context of a sub-set of access rights from the user who scheduled the task. This ACL entry gets cleaned up automatically after task completion but might be visible for some time in the ACL.