Data protection, privacy, and confidentiality: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 9: Line 9:


<!--T:3-->
<!--T:3-->
Our resources are all administered following best practices for academic research systems, and we devote considerable effort to ensuring data integrity, confidentiality, and availability.  However, none of the resources is formally certified as meeting specific security or privacy assurance levels which may be required for certain datasets. For the most part, we provide shared resources, shared networks, shared nodes, shared memory, and data is not guaranteed to be encrypted at rest. We offer the standard Linux file system segregation and access control to files and directories, and our sysadmins do have access to all this material when necessary or when authorized by their owners.  
Our resources are all administered following best practices for academic research systems, and we devote considerable effort to ensuring data integrity, confidentiality, and availability.  However, none of the resources is formally certified as meeting specific security or privacy assurance levels which may be required for certain datasets. For the most part, we provide shared resources, shared networks, shared nodes, shared memory, and data is not guaranteed to be encrypted at rest. We offer the standard Linux filesystem segregation and access control to files and directories, and our sysadmins do have access to all this material when necessary or when authorized by their owners.  


<!--T:4-->
<!--T:4-->
Line 22: Line 22:
Our basic principle is to have some level of duplication for most filesystems. The level of duplication depends on the risk for a potential hardware failure. For example:  
Our basic principle is to have some level of duplication for most filesystems. The level of duplication depends on the risk for a potential hardware failure. For example:  
* Local storage on compute nodes - where it exists - does not have any form of duplication.
* Local storage on compute nodes - where it exists - does not have any form of duplication.
* Scratch filesystems have high reliability to protect against multiple simultaneous disk failures but do not have a backup.
* Scratch filesystems have high reliability to protect against multiple simultaneous disk failures but do not have a backup.
* Project and home filesystems have high reliability to protect against multiple simultaneous disk failures, and also have periodic backup copies
* Project and home filesystems have high reliability to protect against multiple simultaneous disk failures, and also have periodic backup copies.
* Nearline storage provides duplicate copies of data on tape
* Nearline storage provides duplicate copies of data on tape.


== What does Compute Canada do to protect my data against unauthorized access? == <!--T:8-->
== What does Compute Canada do to protect my data against unauthorized access? == <!--T:8-->
Line 35: Line 35:


<!--T:11-->
<!--T:11-->
To protect against unauthorized access through software, all of our clusters use standard POSIX and ACL permissions on their filesystems. Each file has an owner and a group. Default permissions are such that new files created are writable by the owner and readable by the group. The default group of a file may depend on the file’s location on the filesystem. The group of a file may correspond to the research project or a single user. Ultimately, the owner of a file is responsible for ensuring that it belongs to the desired group and has the appropriate permissions.  
To protect against unauthorized access through software, all of our clusters use standard POSIX and ACL permissions on their filesystems. Each file has an owner and a group. Default permissions are such that new files created are writable by the owner and readable by the group. The default group of a file may depend on the file’s location on the filesystem. The group of a file may correspond to the research project or to a single user. Ultimately, the owner of a file is responsible for ensuring that it belongs to the desired group and has the appropriate permissions.  


<!--T:12-->
<!--T:12-->
rsnt_translations
56,430

edits

Navigation menu