Implementation of The Secure Hospital Database
The hospital database should be implemented on a relational DBMS that are protected from user access both by the permissions on directories containing the database files and the permissions on the database files themselves. Users cannot look at the files in the database except through DBMS and its protection scheme; that is users cannot access the database at the operating system level. Additional binary files with special format are included, making decoding of any information more difficult. Moreover, DBMS has a built-in hierarchical security system. The database administrator (D.B.A.) controls the types of access allowed to various levels of users using this system.
The security labels which were defined during the secure conceptual design phase were implemented using the notions of roles and groups supported by DBMS. The user roles handled in our implementation are: doctor, normal nurse, and special nurse. The notion of user roles was implemented using the notion of user groups, provided by DMBS (a group is an identifier that can be used to apply permissions to a list of DBMS
users associated with the identifier). After performing a study on the considered users roles, the following clearances were assigned to them: clearance level 3 to the user role doctor, clearance level 2 to the user role special nurse, and clearance level 1 to the user role normal nurse.
The data sets loaded on the hospital database are: the nurse record, the doctor record, the patient record, which contains the medical information, the laboratory information, the follow-up information and the personal patient information. Being a relational database management system, DBMS stores data in tables. The labelling of the data sets was described above. However, it can change dynamically, if one of the security
constraints is satisfied, leading to upgrading and/or fragmentation. The classification level of each tuple of a table was implemented by adding at each table a column. This column contained the tuple classification; that is 1,2,3 instead of confidential, secret, top secret. Zero (0) indicates that the data contained in the tuple is cover story. Of course, the tuple class data was only visible to the D.B.A.
Apart from that, an additional column was added to the related medical data tables, containing the flag ‘h’ (history) or ‘l’ (last). This flag was automatically updated, when new relevant data was inserted. This is one of the integrity constraints that were implemented in the database.
Users were allowed to have access to the data only trough predefined forms. An DBMS form is the electronic equivalent of a paper form; it is displayed on the computer screen and is used for data input and data display. Forms consist of trim, text that provides helpful information, and fields. The latter display the data and accept data entry.
The access types supported from the secure prototype application are insert, read, update, execute, cancel. Thus, the possibility of deleting information is excluded. This was necessary, not only for reasons of better control of the information flow, but also for reducing the possibility of fatal mistakes.
The security constraints defined earlier were implemented using rules and procedures written in SQL.
The security labels which were defined during the secure conceptual design phase were implemented using the notions of roles and groups supported by DBMS. The user roles handled in our implementation are: doctor, normal nurse, and special nurse. The notion of user roles was implemented using the notion of user groups, provided by DMBS (a group is an identifier that can be used to apply permissions to a list of DBMS
users associated with the identifier). After performing a study on the considered users roles, the following clearances were assigned to them: clearance level 3 to the user role doctor, clearance level 2 to the user role special nurse, and clearance level 1 to the user role normal nurse.
The data sets loaded on the hospital database are: the nurse record, the doctor record, the patient record, which contains the medical information, the laboratory information, the follow-up information and the personal patient information. Being a relational database management system, DBMS stores data in tables. The labelling of the data sets was described above. However, it can change dynamically, if one of the security
constraints is satisfied, leading to upgrading and/or fragmentation. The classification level of each tuple of a table was implemented by adding at each table a column. This column contained the tuple classification; that is 1,2,3 instead of confidential, secret, top secret. Zero (0) indicates that the data contained in the tuple is cover story. Of course, the tuple class data was only visible to the D.B.A.
Apart from that, an additional column was added to the related medical data tables, containing the flag ‘h’ (history) or ‘l’ (last). This flag was automatically updated, when new relevant data was inserted. This is one of the integrity constraints that were implemented in the database.
Users were allowed to have access to the data only trough predefined forms. An DBMS form is the electronic equivalent of a paper form; it is displayed on the computer screen and is used for data input and data display. Forms consist of trim, text that provides helpful information, and fields. The latter display the data and accept data entry.
The access types supported from the secure prototype application are insert, read, update, execute, cancel. Thus, the possibility of deleting information is excluded. This was necessary, not only for reasons of better control of the information flow, but also for reducing the possibility of fatal mistakes.
The security constraints defined earlier were implemented using rules and procedures written in SQL.
0 comments:
Post a Comment