Encrypt sechub configuration in database

[de-jcup]

Situation

Currently the user configuration is not encrypted.

With #837 we have now some security helper classes which provide a secure way to handle this.

Wanted

We want user configuration data encrypted inside database. So user credentials inside configurations will be stored encrypted inside database

Solution

• We introduce a new column inside Job table JOB_CONFIG_ENCRYPTION - per default it is NONE so we know which (old) job is NOT encrypted.
• migrationscript uses NONE as default for database
• We introduce a new configuration value for sechub server (spring value) which contains a string with a secret key
• Before writing job data the job configuration will be encrypted by secret key, also the JOB_CONFIG_ENCRYPTION will be set
• Before returning job configuration object for admin rest calls we must decrypt, so admin can directly see the origin configuration by admin REST api

[de-jcup]

Things to think about

• encryption in database versus encryption in JVM
• it must be identified where the configuration is currently stored in database. CRUD operations must be changed to use the encrypted way only
• all non crud operations must resolve the unencrypted configuration object but (if possible) always as a sealed variant
• we must terminate all on dedicated REST "give aways" of configuration
• we must introduce a new usecase for admins /and users of a project to fetch the job configuration of a job all other ways to obtain this information must be forbidden/stopped (except for TestAPI framework in special integration test rest controllers...)

Additionally

• it must be ensured that we have never the situation that inside the cluster one server encryptes data in a way the other server version cannot handle it
• roation must be possible via startup change (new password, old password)
• how to handle situation that old jobs or not encrypted, or with another password/ciper?
• it should be possible that old jobs still use the old password ?
• like initial_admin we must provide an initial_encryption to encrypt jobs always (security by default)
• handle non encrypted data (before the feature) . must still work
• do we need a conversion of old jobs (configurations) or do we provide some kind of history and store the used encryption-setup by some kind of version column in database? Otherwise we would need to have encryption update job which would stop all job processing and all job scheduling until update is done (time consuming and blocking... )