First steps with the db2_secured module
The scope of securing your DB2 database is enormous. The number of security controls in the CIS benchmark is huge. This might make you think that it is difficult to get started, but actually, it is very simple.
A basic start
The whole CIS benchmark is pretty extensive and also invasive. When you apply this on your database, big chance, your application doesn’t work anymore. But how can we get a quick start then?
To help you quickly start this, we have pre-defined a set of CIS security controls that you can use:
db2_secured::ensure_set {'DB1':
set => 'BASIC',
product_version => 'db19c',
doc_version => 'V1.0.0'
}
This Puppet code will apply all security controls defined in the BASIC set to your system. Check here which controls are in that set.
When you want to apply ALL controls, you can use this Puppet code:
db2_secured::ensure_set {'DB1':
set => 'ALL',
product_version => 'db19c',
doc_version => 'V1.0.0'
}
You can also define your own sets. Let’s say for example that you have defined a set called MY_SET
. You can use this Puppet code to apply these controls to your system:
db2_secured::ensure_set {'DB1':
set => 'MY_SET',
product_version => 'db19c',
doc_version => 'V1.0.0'
}
Look here to define your own set of controls.
Using CIS with exclusion lists
The approach described before is based on a mechanism of inclusion. Some security professionals rather work with exclusion lists. Apply ALL unless specified otherwise.
The db2_secured
module supports both ways.
To enable the CIS benchmark on your database with an exlusion approach , you just have to add this line to your puppet code:
db2_secured::ensure_cis {'DB1':
product_version => 'db19c',
doc_version => 'V1.0.0'
}
This will activate the CIS benchmark V1.0.0 for DB2 19c on your databases DB1. The
db2_secured` puppet module takes care of checking all of the security settings in the benchmark and ensuring they are set in a secure way.
Skipping some controls
The scope of the CIS benchmark for DB2 is pretty extensive. So extensive that enabling all controls, probably ensures that your application doesn’t work anymore. So you need to customize the controls you want to enable.
There are four ways the db2_secured
module allows you to skip controls.
- Add a list of controls to skip when calling the
db2_secured
defined type. - Add
db2_secured::controls::name_of_the_control: skip
to your hiera data. This will skip the control on ALL databases. - Add
db2_secured::controls::name_of_the_control::dbname: skip
to your hiera data. This will skip the control on the database with siddbname
. - Add an entry with the content
name_of_the_control
to the array valuedb2_secured::skip_list
in your hiera data.
Method 1 is a good way to create your own baseline based on the standard db2_secured
code.
Method 2 and 3 are a perfect way to use when you need to override the applicability of control on an individual database or set of database. Just put this data in the hiera for this node or group of databases.
Method 4 is the perfect way to setup a base level. A level you want to be skipped on all of your databases.
You can combine all of these methods to fit your use case.