Laboratories are capable of creating mounds of data, and they all face the challenge of securing that data. The recent blog Introduction to Cloud Data Security covered several key considerations for labs relying on (or thinking about relying on) cloud-based data sharing. This discussion will examine five important principles within the broader topic of information security.
Computer security is a process, a continuous evaluation of risks that result in concrete steps for safeguarding computer systems and the data they generate, wherever those systems may live. However, whether housed locally behind a company firewall or remotely within Amazon’s data centers, principles and best practices can help to guide that process and yield steps that minimize the risks we face.
Cloud infrastructure is rented, which means the ultimate key to the security of any cloud-hosted computer system is the administration account that is set up with a provider. All account authentication information, including passwords, should be stored securely and shared among a very small set of administrators, if it is shared at all. This is the principle of least privilege: only the access required to perform a certain task should be granted, and no more.
Every user in the scenarios above will need his or her own username and password, and this is unlikely to be the only password they’ll need. Databases and applications hosted in the cloud will likely also need to be set up with one or more username/password combinations.
Role-based access and strong passwords are excellent, well-understood tools, but we can go a step further: not all services need to be exposed to the entire Internet. In fact, some may not even need to be exposed to the Internet at all.
Let’s assume we have a three-tier software application:
The client only needs one network port open in order to access the web server: port 443, the secure HTTP port. This port can be opened in the cloud provider’s firewall while all of the other ports remain closed. If other services, such as the Remote Desktop service on Windows, need to be used, those services don’t have to be exposed to the entire Internet – a whitelist can restrict network access. The whitelists in a firewall are a list of network addresses that have permission to access a certain network port. For the Remote Desktop service (port 3389, for the curious), only the company’s network address can be added to the whitelist.
This is another example of the principle of least privilege: instead of open, unfettered access to a system, only those services required are exposed, and only to those users (the company’s employees) who need them.
Even behind a cloud provider’s firewall, an application can be further secured. Firewall software is often already installed on operating systems, providing yet another layer of network security. Once again, by exposing only those network ports that are required, cloud systems are further isolated within a cloud service provider’s own network.
The web server will need to talk to a database in order to provide any useful information, but most databases have their own built-in “firewall.” SQL Server, PostgreSQL, and MySQL, for example, can all be configured to listen only for connections from a specific network address. If it’s possible for a web server and database to co-exist on the same computer (that is, if neither will require so many computational resources that they jeopardize the other’s performance), the database can even be configured to listen *only* to the machine on which it lives.
Once we have taken all of the steps we can to minimize system exposure, we must still keep an eye on those systems for unexpected behavior or suspicious activity.
In the context of a robust security process, it’s important that auditing system notifications trigger a well-known sequence of follow-up steps. In a major data breach at a well-known retailer, occurring within the retailer’s own data center, a notification of suspicious activity was sent, and then … nothing happened. The greatest safeguards in the world won’t do any good without a solid process for following up.
Co-founder and Principal at StackWave and Co-founder of LabGauge, Daniel Goldman has over a decade of experience building software, primarily focused on database and server design and development. Mr. Goldman is particularly interested in software systems that can be rapidly adjusted to facilitate the changes in workflow and data models so essential to keeping systems current with R&D processes. In his words, “software should make it easier to do great science.”