Introduction

There is a general legal requirement that websites be operated safely, securely and in an accessible / non-discriminatory manner.  When personal data (i.e. data about individuals) is stored in a database, and that database is accessed by a script running on a web server, then, under the UK Data Protection Act, the data owner has a duty of care to protect the data - using either authentication, or encryption to control access. Not all technologies currently used facilitate the appropriate level of security.

The College Web Management Team has approved a policy which defines the database management systems (DBMS) which should be used in web-based applications and for the delivery of web content with an appropriate level of security.

dbms policy

Scope

The requirements of this policy are mandatory for all web pages, branded with the College templates and delivered via the ICT central web hosting facilities (both Windows/IIS and APACHE/LINUX facilities) and via the ORACLE Portal Content Management System. It is recommended that the requirements of the policy are also applied for College web pages delivered in any other way.

Objectives

  • To protect the College from the risk of legal action in the event of a breach of security on 'sensitive data'. 'Sensitive data', for the purposes of this policy, is defined as:
  1. Any personal data, i.e. data covered by the Data Protection Act including 'sensitive personal data as defined by the Act, e.g. patient-related data, including 'coded' data
  2. Commercially sensitive research data
  3. Financial data
  • To provide secure database management systems, cost effectively, for use by College websites.

Background

  1. Microsoft's ACCESS is essentially a desktop database and is not  designed as a multi-tasking/multi-user database (which is the main requirement for a web backend database). Microsoft, themselves advise that it is not designed for use as a backend database to dynamic websites.  There are associated performance problems, as well as security issues - since Access does not implement the full, robust security model, which you will find in more industry-strength database software (e.g.  Microsoft's SQL Server, Oracle).
    Find out how to keep a JEt 4.0 database in top working condition.
    ACCESS is therefore not recommended for use as a backend database to dynamic websites which are part of the College web presence.
  2. The MySQL DBMS was designed for use as a web backend, especially with PHP middleware. However, because it does not currently support internal stored procedures, similar security exposures apply if a script running on a web server accesses a MySQL database which contains 'sensitive data'. MySQL version 5, which is currently under development, supports internal stored procedures which should overcome the security risk.
  3. The College recommends, and has a proven track record with database-driven websites using MS SQL Server which implements a full, robust, industry strength security model. In general there is a migration path from ACCESS to SQL Server which is relatively easy to follow. Advice should be sought, via the ICT Service Desk to ascertain the ease of migration. In some cases and depending on the database structure, then there could be a cost of conversion. (Note that ACCESS may continue to be used as a frontend 'data client', thereby minimizing any impact on departmental database data entry and maintenance procedures).
  4. ICT use the  ORACLE DBMS in College wide systems and has an ORACLE 9i site licence. However, it must be pointed out that ORACLE is a complex DBMS which requires trained, appropriately skilled resources to set up and administer.

Policy requirements

  1. College websites which run scripts to access any data or text fields which are stored in databases containing 'sensitive data', may only access Microsoft's SQL Server, ORACLE or Postgres databases.
  2. College websites retrieving data from a DBMS should do so using stored procedures. The document 'Notes on Active Server Pages (ASP) and MS-SQL Server Integration'  provides guidelines on developing a secure database driven website and on the use of stored procedures.
  3. The MySQL DBMS may be used, when access from the web is to a database which does not contain any 'sensitive data' (see definition in 'Objectives' above), and thus there is not a security risk. If a database does contain 'sensitive data', then an extract database must first be created, which does not contain 'sensitive data' fields and the website must access the extract database only. When MySQL version 5 is available, then access to MySQL databases will be re-evaluated with a view to removing the requirement to create a 'non-sensitive' extract.
    For the interim period, pending the availability of MySQL version 5 and in alignment with general practice in other institutions, such extract databases may contain 'personal data', (e.g. a list of names), but must exclude 'sensitive personal data', (see ),  and exam results.
     
  4. ICT has a central provision which can host databases accessed by College websites, and advises departments and divisions to host databases on the central servers. These are available for both the Windows IIS environment, running MS SQL Server, and the APACHE/LINUX environment running MySQL and Postgres. Use of these central services avoids the need to purchase departmental or divisional licences. ICT supports the set up, administration and maintenance of these centrally hosted databases.
  5. If hosting a website and database outside of the centrally hosted server farm, then advice on DBMS licences should be sought from the ICT Software Shop.
  6. Owners of College websites which currently access databases containing sensitive personal data should plan website transition so as to achieve the requirements of this policy at the earliest practical opportunity.