...
...
Info |
---|
|
Earlier In earlier CxSAST versions like v8.8.0 and v8.9.0, the user management was an internal part of CxSAST, installed together with CxSAST and utilizing the same database.
When upgrading to CxSAST v9.0.0 or v9.2.0 and up from version v8.8.0 or v8.9.0, in order to retain all the prior CxSAST data (such as authorization and authentication definitions, configurations, teams, users and permissions)9.0, you have to perform a procedure that first installs the new Access Control and then migrates the existing CxSAST data to it, followed by a manual verification of the transferred data. data in order to retain the previous CxSAST data (such as authorization and authentication definitions, configurations, teams, users and permissions), Only then, you upgrade to the new CxSAST version in a separate installation.
Info |
---|
|
Note |
---|
Any CxSAST version upgrade must be performed on the same station in order to preserve the existing CxSAST data on in the CxDB, for example when upgrading to v9.0.0 from v8.8.0 or v8.9.0. |
Describing the Upgrade Process
When upgrading to CxSAST (v9.0.0 and up) from versions 8.8.0 or 8.9.0, the procedure consists of three phases:
Phase 1: The Access Control Migration installer will install the new Access Control module – a platform-external module, using the same CxDB database in a different scheme, and different set of APIs. After successful installation, the same installer runs the Data Migration Tool – which reads the existing CxSAST user data from the SAST-internal CxDB, and then populates the CxDB database for the new Access Control with the same data.
During this phase, user notification is provided upon any errors found – in the Access Control installation as well as the data migration. This helps to mitigate damage by enabling any problems to be dealt with immediately, while the data is still accessible and retrievable from the older CxSAST version still installed.
For more information about the procedure, refer to Phase 1 – Running the Access Control Data Migration Tool Installer.
Phase 2: After the data migration has completed successfully, this next phase allows the customer to manually cross-check and verify all transferred data (viewable in the new Access Control interface) against the data in CxSAST (viewable in the CxSAST interface) – to ensure successful data migration, and if needed, to rectify any problems before installing the new CxSAST (v9.0.0 and up).
Even though the Data Migration Tool may finish running without returning an error indication, there still remains the potential for error. For example, problems could stem from data that was – for whatever reason – incorrectly or erroneously altered in CxSAST prior to the migration, which, after being migrated, could result in lost user data, or render the product inaccessible.
Performing manual verification of migrated data is extremely beneficial to preempt problems that may only become apparent after the new CxSAST version has been installed – at which stage resolution becomes much more difficult.
For more information about the procedure, refer to Phase 2 – Manually Verifying the Data after Migration.
Phase 3: After manual validation of the data migration, run the CxSAST executable file to install the new CxSAST (v9.0.0 and up).
For more information about the procedure, refer to Phase 3 – Installing the New CxSAST Version (9.0.0 and up).
Data Types Migrated
Some typical data types migrated are as follows:
- Users
- Teams
- Permissions
- Roles
- SMTP settings
- SAML settings
- LDAP settings
Info | ||
---|---|---|
| ||
In case the SMTP “From address” field is empty in v8.8/v8.9, the migration will use the SMTP user name for that field. In case the username does not contain a valid email address, the migration will use ‘noreply@checkmarx.com’ as the “From address”. This setting is located here. |
Info | ||
---|---|---|
| ||
Only domains mapped to the LDAP SSO and which are configured with a Fully Qualified Domain Name (FQDN) will be fully migrated. |
Info | ||
---|---|---|
| ||
Domains which are not associated with users will not be migrated. |
New / Replacement CxSAST/CxOSA & Access Control Roles Available after Data Migration
The following compares the prior roles available in v8.8.0 and v8.9.0 to the new / replacement roles available after performing the Access Control Data Migration procedure and upgrading to v9.0.0 and up:
Info |
---|
For more information, see CxSAST / CxOSA Roles and Permissions (v9.0.0 and up). |
Former role before data migration & upgrade to v9.0.0 (and up) | New role(s) after data migration & upgrade to v9.0.0 (and up) |
---|---|
Reviewer | Reviewer |
ReviewerWithSeverityStatus | Reviewer + Results Updater + Results Verifier |
ReviewerAudit | Reviewer + Auditor |
ReviewerWithSeverityStatusAudit | Reviewer + Results Updater + Results Verifier + Auditor |
Scanner | Scanner + Reviewer + Results Updater + Data Cleaner + Security Risk Viewer |
ScannerWithNEAndDelete | Scanner + Reviewer + Results Updater + Results Verifier + Data Cleaner |
ScannerWithNE | Scanner + Reviewer + Results Updater + Results Verifier |
ScannerWithDelete | Scanner + Reviewer + Results Updater + Data Cleaner |
ScannerAudit | Scanner + Reviewer + Results Updater + Auditor |
ScannerWithNEAndDeleteAudit | Scanner + Reviewer + Results Updater + Results Verifier + Data Cleaner + Auditor |
ScannerWithNEAudit | Scanner + Reviewer + Results Updater + Results Verifier + Auditor |
ScannerWithDeleteAudit | Scanner + Reviewer + Results Updater + Data Cleaner + Auditor |
CompanyManager | Access Control Manager (AC role) + Scanner + Reviewer + Results Updater + Result Verifier |
CompanyManagerAudit | Access Control Manager (AC role) + Scanner + Reviewer + Results Updater + Result Verifier + Auditor |
SPManager | Access Control Manager (AC role) + Scanner + Reviewer + Results Updater + Result Verifier |
SPManagerAudit | Access Control Manager (AC role) + Scanner + Reviewer + Results Updater + Result Verifier + Auditor |
ServerManager | Access Control Manager (AC role) + SAST Admin |
ServerManagerAudit | Access Control Manager (AC role) + SAST Admin + Auditor |
Default LDAP Role after Data Migration
LDAP configurations/sync settings, LDAP users, and mappings for group-to-role & group-to-team are migrated.
After migration, the former default LDAP role (in v8.8.0 / v8.9.0) will be migrated (in v9.0.0 and up) to a single default LDAP role, which will include permissions of all the role attributes (NE, delete project, etc.) - and which will be named (according to the permissions) as per one from the following examples:
Examples (2 sets of role variations):
|
|
Default SAML Role after Data Migration
SAML configurations (including certificates) are migrated.
After migration, the former default SAML role (in v8.8.0 / v8.9.0) will be migrated (in v9.0.0 and up) to a single default SAML role, which will include permissions of all the role attributes (NE, delete project, etc.) - and which will be named (according to the permissions) as per one from the following examples:
Examples (2 sets of role variations):
|
|
Future Benefits of the New Access Control Module
In the future the new Access Control module will simplify the login process by enabling Checkmarx users to perform a single login while utilizing multiple Checkmarx products, while delivering a fully featured user interface for unified access control and user management across the entire Checkmarx product offering.
Restoring Passwords
During the upgrade, the enc-credentials.properties file is overwritten and a backup is created. As a result, the password property in the credentials-enc.properties file is removed and the password reset to the default.
...