Monday, March 10, 2008

Compliance: Role Separation and Audit (part I)

Depending on your geography and your business, you are probably at least well aware of the current government, legal and privacy regulations.
After some well noticed economical frauds, and also due to the constant fight between security and privacy, many companies had to increase their internal regulations and security measures, and they had to begin to comply with several national and international regulations. If you're in the USA, names like Sarbanes-Oxley Act of 2002 (SOX) and Health Insurance Portability and Accountability Act (HIPAA) have surely become part of your daily jargon. Other countries have similar national laws or must follow similar directives (EU countries). From a brief search Asian countries like Japan also have similar regulations. So, although not equal in every country, most of us have met the same or similar requirements to comply with security, accountability and privacy regulations.
The situations will vary but in general this means companies have to define, ensure and control who does what to their data. This directly implies that all IT departments must make sure they can answer their auditors (either internal or external) about the controls they implemented in their systems.

I will, in this and another article, try to explain some of the security, auditing and other control features IBM Informix Dynamic Server has to offer. In this first part I will show you how Informix can separate the various roles that are needed to install, manage and audit an Informix database instance. The second article will focus on the audit facility. I will leave out of these articles the features that allow you to control the user's access to data. This will be the privileges (database and table level) and the Label Based Access Control (LBAC). The reason for this is that both of these features are reasonable well known and also because when LBAC was introduced in Cheetah (IDS 11.10) it received a lot of coverage in several places (like IDS Experts Blog and Guy Bowerman's Blog).

The role separation and audit functionalities were traditionally covered in the Trusted Facility Manual (V7, V9, V10) , but since IDS 11.10 they were put together with LBAC and some other functionalities like encryption into a new manual, the Security Guide Manual.

If you start looking at the manuals and look for auditing facilities you'll first find references to "role separation". You may also notice that the IDS installer will ask you if you want to enable role separation. Please, don't mix up this "role" with the well known database roles that you can use to manage database and table level privileges. These "roles" in the audit facility context are different. IDS documentation identifies five roles regarding to database instance installation, administration, audit control and audit administration:
  1. Operating System Administrator(s) (OSA)
    These are responsible for the Operating System administration and they are needed for the IBM Informix Dynamic Server product installation
  2. DataBase System Administrators (DBSA)
    These are the database system administrators. They can do all maintenance tasks on the database instance (not the databases within the instance). These include starting, stopping, monitoring, executing backups etc. They cannot access the data inside the databases and they cannot control any of the auditing tasks of the instance. This means they cannot control what is audited, neither who is audited and they cannot access the audit logs. They can of course be audited!
  3. DataBase System Security Officers (DBSSO)
    These define what is audited. As you will see in the second article, they will define the audit masks. But they won't be able to manipulate the auditing facility (start, stop, configure...) or access/manipulate the audit logs
  4. Audit Analysis Officers (AAO)
    These will manage (start, stop, configure...) the auditing facility and will also be able to access the audit logs. They will not be able to define what is audited
  5. DataBase Administrators (DBA)
    These are the users with "GRANT DBA" on one or more databases inside an instance. Remember that the owner of the database is inherently a DBA of its database.
It also talks about another group or role, the instance users, which you can define in the $INFORMIXDIR/dbssodir/seccfg file. In this file you can define a group, and then only the members of that OS group will be able to connect to the instance. Unfortunately you can only define one group, and this file is not configurable per instance (as $ONCONFIG for example). So, if you have more than one instance in your server you'll need more than one $INFORMIXDIR.

Hopefully I will be able to explain the tasks of each of these roles, and it will be clear that by providing this separation ability IDS offers you tools to implement compliance that you'd have to buy in other databases. The decision to implement all these roles and to really keep them separate (by keeping each user in only one role) will depend on your organization objectives (and also the capabilities in terms of organization and staff).

I'd like to make one thing very clear: Although ideally these roles should be completely separated, organizations should be aware that they must team together. DBSSO and AAO can do certain tasks that will impact the database performance and availability. They should take this into consideration. Also, some tasks, usually attributed to DBSA can be impossible to achieve without giving them the DBA role also... So, you should really define your objectives, priorities and staff functions. Sometimes there will be a price to pay for some functionalities and this may need management approval. The good news is that everything I'll talk about here is possible to configure on the fly meaning you can dynamically change everything... from role separation to audit configuration and management. So, if as I mentioned earlier, your different departments work as a team you benefit from this ability to reconfigure without stop, if and when the need arises.

I'll focus on Unix/Linux, mainly because that's where I'm most experienced, but everything I'll talk about is possible to do on Windows. It may have to be done in a slightly different way. Please consult the manuals if I'm not specific about it here. There is also an article about it on Guy Bowerman's blog.

So, let's start by the beginning... Ideally it all starts at installation time. The installation itself needs to be done by an OSA role element. Typically this will be root on Linux/Unix and a member of Administrators group in Windows. The installation will ask you if you want to create role separation. If you answer "yes", it will ask you for OS group that will represent the DBSSO and the AAO roles. It assumes DBSA will be group informix (Linux/Unix) and Informix-Admin on Windows. I don't like to assume that DBSA will map to group informix. I'll explain it later...
So, the mapping between instance administrative roles and users will be implemented by OS groups. To be more specific, there are three directories inside your $INFORMIXDIR that will define the roles. The group owners of those directories will be the OS groups representing the roles. Specifically the mappings are:

  • DBSA
    Group owning $INFORMIXDIR/etc
  • DBSSO
    Group owning $INFORMIXDIR/dbssodir
  • AAO
    Group owning $INFORMIXDIR/aaodir
The OSA and DBA roles don't map like this. The OSA is defined by OS configuration, and DBAs are defined in each database by GRANTing privileges to specific users.

So, if you installed the product and you did not choose to create role separation, you can do it later. Let's assume we will have OS groups called ixdbsa, ixdbsso and ixaao that respectively map to DBSA, DBSSO and AAO roles. To implement role separation on an existing instance you should issue the following commands:


chgrp ixdbsa $INFORMIXDIR/etc
chgrp ixaao $INFORMIXDIR/aaodir
chgrp ixdbsso $INFORMIXDIR/ixdbsso

The directory permissions should also be changed:

chmod 770 $INFORMIXDIR/aaodir
chmod 770 $INFORMIXDIR/dbssodir
chmod g+w $INFORMIXDIR/etc

Note: Some documents may show 775 for aaodir and dbssodir, but I don't see the need for permissions in these directories outside the group they belong to.

And also you should give permissions for your DBSAs to alter $ONCONFIG file:

chgrp ixdbsa $INFORMIXDIR/etc/$ONCONFIG
chmod g+w $INFORMIXDIR/etc/$ONCONFIG


Let me make a few considerations before proceeding: As I wrote above, I personally don't like to use group informix for the DBSA role. Why? Well, you are probably aware that the IDS chunks must be owned by user informix and group informix and must have permissions 660. Now, if you use group informix as your DBSA group, then you have to include your instance administrators in this group. The problem with this is that then, theoretically, they will have read/write ability on the chunks. They could, using just OS commands, read data pages, overwrite data pages, eliminate chunks etc. Of course they would need deep technical knowledge about a chunk structure and IDS datatypes to be able to read any useful information, but it would be technically possible. The downside of having a different group for DBSA is that you must use the informix account (or an OSA) to add space to your instance. The upside would be that your team of DBSAs could do everything needed to manage the instance, but could not ever access your data. It could of course drop a chunk, but this would have to be done using IDS commands which can be (and should be) easily audited.

By now, some of you are probably thinking I'm being too though or too strict... I mean... we are DBSAs/DBAs and we are supposed to be trustworthy individuals... Yes, this is true. And yes, after the end of these two articles you'll be asking "and what about root?... He can still do rm -rf /*, can't he?"... Yes, we are trustworthy individuals, and yes, root is a problem, but when you are confronted with an auditor, you MUST prove that you can't do any harm without leaving a trace, and YOU don't have to take care of the root problem... The idea here is to show how the product can be configured to assure maximum security and accountability... then there are the implications, and organizational decisions...

So, first decision, use informix group for DBSA? Your choice... Or your organization's choice. Anyway, after putting your staff that will administer the IDS instance in the "DBSA" OS group, you should consider their access to the informix account. After doing the right configuration you can (and should) impose serious restrictions on the use of the informix account. The fact is, in general, access to it will not be needed. If you choose not to use group informix then it will be necessary for adding space to the instance, but that's the only thing I remember... everything else can be done using your individual accounts as long they belong to the DBSA group.
Some very important notes:
  1. If you choose to use a different DBSA group (not informix) your OSA must change permissions on the oninit executable file;

    chmod o+x $INFORMIXDIR/bin/oninit

    Before you shout "What?! Isn't that the most insecure thing to do?", I should say that oninit will check the identity of the invoking user, and will not run if he doesn't belong to the DBSA defined group
  2. Many customers usually have several instances in the same box, sharing the same product installation directory. IDS is prepared to do this, and most of its configuration and operation files ($ONCONFIG, MSGPATH etc.) are separated by instance. But if you're using role separation, this would mean you'd need to have the same groups/roles for all the instances. This may not be convenient. I suggest that you install your product just once, but then create separated $INFORMIXDIRs for your instances. The steps to achieve this are:
    1. Create one $INFORMIXDIR for each of your instances
    2. Inside each one, create symbolic links to the equivalent directory on the product installation directory except for $INFORMIXDIR/etc, $INFORMIXDIR/aaodir and $INFORMIXDIR/dbssodir
    3. For this three directories, copy their content from the product installation directory into each one of yours $INFORMIXDIR

      This process is well described in Jonathan Leffler's "Is your DBA paranoid enough" presentation... You can Google it...
      At the bottom of this article you can also find a link to a script called ixvirtdir that will help you in the process of creating these directories for each instance.
  3. If you're running versions 9+ and you use a specific group for AAO you may hit one problem: In these versions the majority of the oninit processes will not run as user root, but will use user informix. When you do certain audit commands the engine will try to create a file with the running user and then will try to change it's ownership (like chown...). This will fail in many, if not most platforms. There is an undocumented variable that you can use (NONROOT_OFF=1) in the server environment that will change the default behavior, and will force oninit to run as root. This has disadvantages (that's why it was changed), but may be the only way to create certain files with the desired user
By now you should have all the info needed for setting up role separation in your IBM Dynamic Server instances. This is the basic step to allow for a proper audit environment.
This will be the subject of the second article, which should be available soon.

You still have two problems to address: root and informix. These are privileged users, and you should restrict access to them. root is always a problem, because it really can do whatever he wants... and many times it's nearly impossible to completely audit its actions, because usually root will be able to circumvent all the restrictions you may implement. informix will be much easier, and you should avoid at all cost the use of this user, once you create and defined the DBSA group and you have your instances configured. There will be a few actions that you must do as informix but you should take measures like:
  • Avoid direct login as informix
  • Make it impossible to have more then one people at the same time using this login
  • Audit the actions of user informix using the audit facility
  • Audit everyone that accesses the informix account (logging su and/or sudo commands)
  • Eventually use the OS to log informix keystrokes

I recommend that you test all these steps and all the actions in test environments. A mistake or bad configuration options can really cause harm to your databases. Please note that many times functionality comes with a price... Please consider it before taking decisions.

To end this article, a few references:

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)