|
|
|
Now and then we get questions about security for Sakai. Typically this comes from people who want to store sensitive research data.
Sakai is at the same level of security as most Rutgers central services that are done on dedicated servers. (Systems such as RCI and eden are less secure because they allow a large number of end users to login. No matter how careful the system administrators are, this involves additional risks.) The Sakai application itself has been fairly free of security issues, and the design makes it less subject to problems than many other applications. However no application of this complexity is bug-free.
However Sakai is not specifically designed to comply with regulations such as HIPAA. It's probably as good as many systems that claim that level of security, but it hasn't had the same level of formal review. For example, at higher security levels, organizations will demand background checks of staff. While we're careful about our staff, we don't do police checks. We have had a professional security firm do security testing of Sakai, and fixed the (relatively minor) problems that turned up.
Currently we encrypt any data that is sent over the network, but we don't encrypt data as it's stored (referred to as "encryption at rest.") While we don't think encryption at rest provides any real security benefit, we will be moving to new hardware in 2016 that will do it.
We can support use of smartcard authentication for users, if anyone is interested in this.
We think Sakai is sufficient for most academic and research data. However for real health data, we would prefer to see an additional level of security used, such as encryption of the data.
We would point out that if you're seriously concerned about the security of Sakai, you really need to be looking at the security of your entire system. Sakai is only a small part of that. Typically the weak point of security is not the central service such as Sakai, but your desktop systems, and procedures such as password management. Thus if you are interested in storing sensitive data, we'd suggest that you set up a meeting with OIRT staff and staff from Information Protection and Security, to look at the entire problem, and not just Sakai. Depending upon your needs, Sakai might have a role to play in storing moderately sensitive research data. But we'd like to have a chance to look at the entire system before doing that.