Staying secure with open access: a guide
Open access technology has numerous benefits, such as being able to share information and data with the world, but it’s not without its share of difficulties.
By inviting the world in to share your files and knowledge, you also warrant unwanted intrusions and data theft. This is something professional businesses, such as e-commerce websites, have firsthand knowledge of but something that is lacking in open source communities.
Since many groups, such as scientists and researchers, use the internet for collective purposes, this is a risk that needs to be countered.
A perfect example of this is Heartbleed, which recently made the headlines as a latent, previously unknown flaw in Open SSL. Put simply, SSL, or secure sockets layer, is a protocol for encrypting communications across the internet. It’s what stops private or sensitive data from being readable to anyone else listening in.
Open SSL is an open source and Heartbleed is a now-known flaw in the system using the memory of the web server in question. As a result, data thieves could gather private information from that server, including important documents and research.
Since then, patches and fixes have been made for Open SSL but it has nonetheless made a target for itself. The best option here, arguably, is to switch from just Open SSL to a private, professional version. This gives you added support and protection from Heartbleed.
Likewise, all passwords should be changed to ensure further protection.
Another issue with working opening online is the need to restrict access in certain areas. For instance, when a group of people are working on a project online, most data is often stored on some form of server.
A server doesn’t need numerous administrators, as only one or two will do. This will limit access to the workings of the server, such as the memory that lead to Heartbleed, while still allowing others to access the information freely.
Likewise, protocols should be in place for storing and saving back-ups, such as partitioned servers, as well as set restrictions for each person if it is necessary. Does a person in one department need to access another department’s data but does not need to change it?
In this instance, ensuring they can access but not edit the data inside would be ideal, as it removes a potential risk.