How to use CaclMgr to reduce the risk of data breach on UNIX/Linux Systems
Based on a report released by Symantec (http://www.symantec.com/about/news/resources/press_kits/detail.jsp?pkid=ponemon), on average, the cost of a data breach to an organization has reached US$7.2 million in 2010, and shows no sign of levelling off.
Internally, finnancial organizations have many risks of data breach. Without right tools, to eliminate or control those data breach risks can cause significant operation cost increase.
For example, on a financial database server which contains customers' bank account info, including the account password, credit card info, how could you still allow the database administrators to maintain the health of the database, but not see the customers' secret info?
Probably, you will make the dba account dual controlled and whenever any DBA needs to work on the database, an security officer has to be there to monitor the work of the DBA to make sure he/she doesn't see any customers' secret info.
Though this will work, but the cost is too high and the efficiency is too low: originally, the work may only take the DBA 10 minutes, but now, it could the DBA more than 30 minutes (including get approval and contacting security department) and the security officer more than 20 minutes.
Using our CaclMgr, the very secure and easy to use UNIX/Linux privilege delegation software, you will be able to reduce these kind of data breach risks without sacrificing significant loss of efficiency.
Here is how you could use CaclMgr to achieve that.
1. Create several shell scripts, one for start up database, one for shutdown database, another for checking database status. These are the most used functions by DBAs.
2. Create a DBA group, say, gdba.
3. Create individual account for each DBA and put them into the group gdba.
4. Log on to the unique dba account and use CaclMgr to grant privilege for each member in the group gdba to execute the above scripts:
cacl -a @gdba /path/to/script
5. Make the unique dba account on the system dual controlled.
After these, each DBA will be able to perform daily jobs (by running "cacl -e dba script") without the need to use the dual controlled account, and not able to see the secret info. And only when need to do some other tasks that haven't been coverred by the scripts, dual controlled account will be used. Significantly reduce the operation cost.