Business Continuity from a Database Perspective
Our company has no business continuity policies that will protect the data that our software applications use. Our employee, client, supplier and account records are at risk of being stolen, corrupted, or totally lost. It may take a lot of time and resources to recover or reconstruct these, if we can reconstruct or recover these at all. Employee records help us track the whereabouts and performance of our people. Client records provide us a steady source of income. Supplier records enable us to integrate the various raw materials, supplies and services to produce our products or provide our service offerings. Account records enable us to know our payables and receivables. In this regard, please consider the following policies: a) password; b) access; c) database administration; and d) backup/restoration.
Password Policy. All employees must have unique user accounts, passwords, roles and security levels that are appropriate to their duties and responsibilities when accessing the company’s internal databases. Employees shall not share, borrow, retrieve, use, grant, cancel, archive, or revoke these authentication credentials without prior authorization. Likewise, the company’s internal databases must be distinct and separate from our software applications such as human resources & payroll; customer relationship & management; supply chain & inventory management; and accounting. These software applications shall grant access to our internal databases by processing the credentials already established. Non-employees’ will be governed by our access policy covering third parties. The company shall not allow hard coded authentication credentials in any software application. Likewise, these shall not appear in clear text at the program source code and shall not be within the easy access of any web server (SANS Institute, 2006).
Access Policy. The following factors shall limit access to the company’s internal databases: a) employee classification; b) nature of work; and c) level of trust and confidence. These employee types shall limit or expand access: a) executives; b) managers; c) technical personnel; d) production personnel; e) operations; f) marketing staff; g) administrative/ support staff; and g) rank-and-file. The nature of work and type of data needs or requirements in the line of work shall determine bulk-data or retail-data access. The level of trust and/or confidence of the company’s executives on an employee or third party shall determine access to sensitive data. The company must also follow clear standards on accountability, pursue adequate references and validate any whereabouts.
Database Administration Policy. A professional, well-experienced database administrator who will either be an employee or an outsourced consultant with validated whereabouts and references shall handle database administration. The company shall only allow bulk data access within its premises with provisions for disallowing bulk data replications or transfers outside of company servers or on any non-company resources such as mass data media, storage servers, etc. The company must clearly define accountabilities in any database administration contracts or agreements.
Backup/Restoration Policy. The company shall classify its data as archive (Wikimedia Foundation, Inc., 2007), source, or dynamic for purposes of backup and restoration. This is because data can be huge and may require hundreds of mass data storage media. Restoring a huge volume of tape backups may take days for instance (Newman, 2006). Archives shall cover static data that the company’s software applications or users do not immediately need online. For these, tapes or DVDs may be sufficient. Source data cover active records and need to be mirrored (Wikimedia, 2007) in at least two storage servers at different company sites. In cases of disasters, whether natural or man-made, multiple company branches may access a second storage server in place of the downed storage server with an acceptable maximum downtime of one day (Development Services Group, 2006). Dynamic data covers system-generated data that transactions add to a source data. For instance, a client record is a source data while we can consider the daily purchases of this same client as dynamic data. Software applications or users may mature dynamic data into archives within acceptable time periods, say, one year for quick backup and restoration purposes.
I recommend the approval of the proposed policies and your agreement in principle for detailing these into workable work instructions. Likewise, we will need sufficient information dissemination and orientation times on these policies before these shall take effect.
Development Services Group. (2006). Corporate Applications Backup Policy. Retrieved June 17, 2007, from The University of Edinburgh Information Services: Applications Division Web site: http://www.mis.ed.ac.uk/services/infrastructure/BackupPolicyV3.pdf
Newman, H. (2006). The Importance of Data Restoration. Retrieved June 17, 2007, from the Server Watch Web site: http://www.serverwatch.com/tutorials/article.php/3622731
SANS Institute. (2006). SANS DB Password Policy. Retrieved June 17, 2007, from the SANS Institute Web site: http://www.sans.org/resources/policies/DB_Credentials_Policy.pdf
Wikimedia Foundation, Inc. (2007). Backup. Wikipedia, the Free Encyclopedia
Need essay sample on "Business Continuity from a Database Perspective"? We will write a custom essay sample specifically for you for only $ 13.90/page
You are responsible for the database security. There are no business continuation policies in place and you are charged with developing policies to protect the corporate data. What policies would you implement to deal with this oversight? Give a summary of the details of each policy you would propose to implement. Remember that a policy is a statement in words that tells users, staff and operations personnel what actions are desired. See the discussion on password policies pages 45-46 in the text for an example. Consider the issue of restoring the corporate data, backup, recovery in case of a disaster, such as a hurricane. You can assume that there will be adequate hardware and software available at some other location. You need to produce policies that govern operations for business continuation from the database perspective.