AllegroGraph Enterprise Security and Management

AllegroGraph represents the first Semantic Technology Database with OLTP, ACID compliance and Enterprise Management functionality. AllegroGraph Enterprise Security and Management (ESM) provides the mission critical functionality that organizations need to support 24/7/365 operations. AllegroGraph has received a Certificate of Networthiness for the product to run on the Department of Defense .mil network.

This document gives and overview of security in AllegroGraph. See Security Implementation for implementation details.

Security in general

AllegroGraph is set up to maintain data security from potential threats internal and external. While the exact details of implementing the various security measures are described in the various technical documents, the following overview should provide a good introduction to AllegroGraph and data security.

We organize the discussion with five questions. But before getting to those, everyone concerned with security needs to carefully consider what the threats are and where they might come from.

Threats can be internal or external. Internal threats (typically from dishonest or disgruntled employees) are in many ways harder to guard against because trust is basic to an employer/employee relationship but AllegroGraph provides advanced tools to makes sure that damage is limited and recovery is as fast and complete as possible when a problem is discovered.

External threats are in many ways easier to understand and guard against. You want to prevent unauthorized access to and modification of your data.

  1. How do I make sure only the right user has read/write permissions for a particular repository?

    2. To begin, AllegroGraph access can be configured with your corporate LDAP/OAuth policies (see Top-level directives for external authentication in the Server Configuration and Control document) Then every user is given permissions on a repository basis, so a particular user will have read, write, or read/write permission on repos granted which the user is created in the system and modifiable at any time by the system administrator. Users not granted access to a repo will not even be able to see that the repo exists. Roles are supported, which allows defining repo access permissions which can be given to a class of people (everyone in the accounting department, for example). Using roles reduces the likelihood of permission errors caused by having permissions specified for each individual employee. Anonymous access can be enabled. Such access typically have read permission on the public repos but no write permission at all. See the Managing Users for information on repository permissions.

  2. How can I make sure that no one can listen in to the communication between server and client?

    3. In today's distributed world, it is often convenient, indeed often necessary, to allow remote access to sensitive data. Obviously this access is restricted by password and the like, but open communication can be intercepted and usernames and passwords might be extracted and then improperly used, or data can be intercepted as it passes between the legitimate user and the central system.

    This is of course a well known problem in the internet world, and for Encryption in Transit the general solution is to use SSL client certificate authentication. This is fully support by AllegroGraph. See the Transport Layer Security section below for more information and links to other documents.

    Also supported are logs of access and interactions. If you suspect there might be a problem, reference to these logs can indicate whether there are suspicious accesses and interactions. See the Auditing document.

  3. How can I encrypt my data on disk so no one can read and/or decipher it?

    4. Another concern that users have is that someone might copy the data and then decipher the contents of the database. By encrypting the data we can prevent that. We recommend that users use an encrypted file system for the storage of the AllegroGraph directories. See the Encryption At Rest section below for more on this topic.

  4. What mechanisms do you have to restrict access to triples or triple-patterns within a repository?

    5. There are several ways, with varying degrees of fineness of control.

    • Access Restrictions: Access can be restricted to specific repositories, as described in # 1 above, and this is often sufficient for many uses, particularly where data is easily categorized.

    • Security Filters: These can restrict access to triples with specific subjects or predicates or objects or graphs. They allow finer control than just by repo, but they are still fairly coarse-grained. Security filters are discussed briefly below and in the Managing Users document.

    • Triple Attributes: The above mechanisms may be too coarse for many applications. Sometimes data cannot be so easily classified, or there are too many classifications (requiring too many different repositories), so AllegroGraph provides security at the triple level, similar to Cell-Level security in a relational database.

      • AllegroGraph supports triple-level attributes, which are metadata added to each triple. Every triple can have its own set of attributes (attributes are name/value pairs associated with a triple). For example, an attribute "securityLevel" could have values of "low", "medium" and "high". Users too can have a security level. User access of triples can then be controlled by comparing the attribute/value pairs assigned to a user with the attribute/value pairs on the triples. If the user does not have access to triples with particular attribute/value pairs, it is as if, from the point of view of the user, those triples simply do not exist.

      See Triple Security for a full description of this form of triples security, with examples. Attributes are described in the Triple Attributes document.

  5. How can I protect my data from corruption?

    6. There are various ways to preserve data from loss or corruption. One way is using replication. AllegroGraph supports replica repositories on multiple servers (called Multi-master Replication or MMR), so a change to the repo on one server is propagated to replicas on the other servers. The propagation typically has minimal latency and is extremely fast so an unexpected failure of one server can result in minimal data loss. Multi-master replication provides the best mechanism for fast recovery of all data except the small amount that may have been lost due to latency.See the Multi-master Replication (MMR) document.

    A second scheme (best used in addition to MMR) is to make express backups of data to files. This is a point-in-time backup: the data is good through the time of the backup but subsequent changes are not, of course, reflected. However, a regular backup schedule, performed at all replication sites, can guarantee that data loss can be minimized. See the Repository Backup and Restore document.

    Note that backups to disk, when set up correctly and managed by workers separate from those who add and delete data, does provide protection against dishonest or malicious employees. When a problem is caused by such an employee, so long at that employee does not have access to the backup files, recovery from at least from a known starting point (the time of the last backup) is easy and quick.

General Discussion of Security

AllegroGraph ESM includes the following:

External authentication

LDAP

AllegroGraph supports using LDAP (Lightweight Directory Access Protocol, see this Wikipedia entry) for external authentication. All user data (permissions, etc) are stored locally, so in order to be able to authenticate a user externally, a user with the same name must already exist on a given AllegroGraph server. See the Managing Users document for information about creating and managing users.

Use of LDAP is enabled with several configuration directives described here in the Server Configuration and Control document.

Note that external authentication refers to a support of an external user password database, so other AllegroGraph authentication methods (tokens, certificates etc) are not affected when authentication policy is set to external-only.

OAuth and OpenID Connect

AllegroGraph suports OAuth/OIDC authentication. As with LDAP, user information (permissions, etc) is stored internally, but the authentication itself can be delegated to an external service.

OAuth/OIDC authentication can be enabled with an AllegroGraph configuration directive described here in the Server Configuration and Control document.

Transport Layer Security - Encryption in Transit

Access to an AllegroGraph database server can be obtained via AllegroGraph’s RESTful interface (for HTTP and HTTPS clients), through AllegroGraph’s built-in web interface – AGWebView, through a Lisp client application, or with other clients such as Java and Python.

All client network access to AllegroGraph occurs though the product’s HTTP and HTTPS RESTful interfaces. The AllegroGraph interface, and RESTful interfaces in general, are remarkable in that they are by definition client-server, stateless, cacheable and provide a uniform interface identifying system resources in the client request.

AllegroGraph clients can connect directly to the server via HTTP, sending and receiving clear text. AllegroGraph clients also have the ability to send and receive encrypted requests.

Connections using SSL

An AllegroGraph session can be established over Secure Sockets Layer (SSL). AllegroGraph supports TLS versions 1.0, 1.1, and 1.2.

Several AllegroGraph configuration options relate to SSL. See the Top-level directives for SSL client certificate authentication section in Server Configuration and Control document. See also the SSL/TLS Quickstart document.

AllegroGraph utilizes FIPS 140-2 compliant encryption for data in transit. Reference http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf.

X.509 Certificates

The server provides an X.509 certificate to the client during the SSL/TLS handshake when the connection is established. Therefore the client can check the contents of the certificate if desired.

Encryption At Rest

To enable data-at-rest encryption with AllegroGraph we recommend using a third party tool such as Linux LUKS disk encryption.

If running AllegroGraph using a cloud service provider, we recommend using the provider's disk encryption mechanism (such as EBS encryption on AWS). Google Cloud Services encrypts storage volumes by default.

Management Access Control

AGWebView provides a GUI management and data access interface to AllegroGraph, as we describe in Security Implementation. The web-browser based interface allows the system administrator to manage access control to individual repositories, maintain users and roles, and control the Warm Standby and Replication interfaces.

Configuration of Repositories and Catalogs

Repositories are effectively managed through AGWebView. Control over placement of the catalogs and server settings is managed during initial server configuration.

Management of JavaScript and Lisp Stored Procedures

Both JavaScript and Lisp stored procedures are supported. The user manages stored procedures through AGWebView.

User Management

The system administrator is given fine-grained control over creation and management of users, passwords and roles through the AGWebView interface.

There are several predefined user permissions, including Superuser, Start Sessions, Eval (stored procedures) and (control) Replication.

For each user and role, the administrator can manage these permissions and repository access. Access can be granted to specific repositorities in specific catalogs, all repositories in a catalog, or all repositories in the server.

Programmatic System Management

All the management functions of the product are exposed via HTTP, Java, Python, Lisp and others. Organizations can take advantage of AGWebView or provide their own custom interface to AllegoGraph security and management.

Summary:

Manage User Permissions and Access Rights

Administrative Functionality

Triple Level Security

As graph databases become more entrenched in enterprise applications, increased security and fine-grained data access control is required. To support this, AllegroGraph supports statement-level Security Filters, which are described in the Security Filters section of Security Implementation and triple attributes, described in the Triple Attributes section of Security Implementation

With Security Filters the system administrator is able to grant user access to the entire repository, or restrict access to a limited and filtered view of a repository.

Security Filters can be applied to individual repositories for all add/delete/query operations, per user and per role. You specify which values of the subject, predicate, object, or graph should be allowed or disallowed and then query responses are filtered appropriately, and attempts to add or delete filtered triples fail.

Key Security Filter Features:

Key Triple Attributes Features: