Securing your data should be top of mind for any modern application. Security breaches are on the rise and the associated penalties are severe, impacting your brand and, in turn, your customer loyalty and trust.
Consider the following security practices to protect your data and the distributed system that manages it.
These practices apply to distributed system architectures that could include intercloud, hybrid, and/or multi-cloud. They can also be applied to systems with specialized compliance requirements in regulated environments; financial services; payments; health systems/HIPAA in the United States and GDPR in Europe; and a number of high-security implementations related to local police and other government bodies.
1) Secure the environment
Start by securing the environment that your application and distributed data will be in. This includes securing ports required for application access as well as securing file paths or directories used by the application that could expose sensitive data such as the temporary directories.
2) Encrypt data at rest and in flight
Encrypt the data, the communication channels, and anything that connects to and from applications. From a high level, this goes without saying. From an implementation perspective, it can be less prescriptive.
There are three main areas of concern around distributed data encryption: client-to-server communications and connections; the data itself; and the inter-node channels of communication. All three of these areas of vulnerability should be encrypted, but there are options to consider.
For encryption of the communication channels, the inter-node channels, and client-to-server connections, use TLS over SSL. While both protocols provide strong encryption algorithms, SSL is considered the predecessor to TLS.
For data at rest, there are a few ways to go about this. The typical best practice is to encrypt your entire disk volume. This is simply the safest way to encrypt data at rest because everything on the disk is encrypted. The entire volume becomes inaccessible without the encryption key(s).
Having said that, if the ability or functionality to encrypt the volume isn’t available or provides too much of a performance penalty, then at minimum encrypt the application data at rest through the application’s database by encrypting the tables or keyspaces themselves.
Encrypting these channels requires encryption keys, which you can manage and keep locally or manage off-server through a key management interoperability protocol.
3) Use an authentication and authorization layer
Use some level of authentication to ensure users who are attempting to access the system are registered and are who they say they are. Multi-factor authentication, where users have to go through multiple authentication mechanisms to ensure their identity, is quickly becoming the standard for modern applications.
But system access is only part of the story. You also need to plan which roles and users have access to which data. Data access should be authorized according to both roles and users. Depending on the tasks of the user, further restrictions may also need to be added.
LDAP is a common protocol used for communicating with backing management systems and services that define roles, groups, and permissions. Role-based access control and permissions can also be built into the application’s database by configuring the database’s authentication and authorization rules.
4) Privatize your schemas
Distributed systems typically have replicated data. This replicated data not only includes application data for availability purposes but also system data for the database to properly function. Layer in additional security logic on top of that and not only does this information have to be replicated but it may need to exist on each node (where the replication factor equals the number of nodes), which increases the chances of this information being breached.
By privatizing system schemas or further restricting access to tables that contain schema information, this can ensure that access is explicitly denied even if the role allows or grants access.
5) Assign and separate roles/duties
Enterprises typically have different teams responsible for various aspects of an application, including application developers, database administrators, operators, etc.
Each of these roles comes with its own set of rights and privileges. In order to implement an application’s usage and data access patterns into the database access layer, security administrators may need to grant others privileges on database objects that the security administrators themselves cannot access.
Without the ability to separate these duties, an administrator would need more access to the database objects to perform this task, weakening the application’s security access protocols. The ability to manage permissions on database objects without requiring access creates a stronger security paradigm.
The above is, of course, not an exhaustive list of everything you can do to protect your distributed data. For a comprehensive look into everything you can do, see our security checklist.
