NoFS

The contemporary file system’s organization traces its roots back to the early days of electronic computing, organized similar to the physical filing system it was intended to replace. The physical location of a file is a leaf in a hierarchical tree structure. Security is applied at the level of the container and enforced, typically, through the honor system.

These characteristics exist in order to facilitate organization and access performance.

Thus, the organization of the data, the directories you will use, has to be predetermined, before files are written and a change to the hierarchy usually results in the movement of the data itself.

The approach of a NoFS implementation is to allow the data objects themselves to exist independent of where they are “filed”, one sees this pattern best illustrated in an application accessing a database, SQL or otherwise. A query is made which limits the response set by primary key or a WHERE clause condition. Another example is a SQL View; the limit of the rows and columns provided in a given answer is specified by the View and enforced by the SQL Database. The existence of any other data outside of those limits is not disclosed.

In contrast, the existence of data within a directory in a File System is fully available and visible if any data within that directory needs to be accessed. Lateral discovery by malware relies on this to map out areas of attack without requiring elevation of privileges. Moreover, the elevation of privilege, itself, is typically enabled by the operating system or the user rather than the file system itself. If there are restrictions on access (root user enabled), these are usually applied during the mounting of the entire File System, again due to access speed concerns.

The NoFS pattern separates the “path” to the data from their physical location by using keywords and tags. This allows for multiple paths to the same object. Security is assigned and enforced on the Object itself, so the ability to access a given piece of data is consistently protected, no matter which path is used to access it.

Furthermore, adding or altering a path to the object does not move its contents. This enables new organizational structures to be put into place long after the initial content ingestion. Original organizational paths are left undisturbed. These features allow for workflow and object “state” to be expressed separately from other identifying tags.

Objects themselves can be marked as immutable or versioned, removing the ability of ransomeware to be effective.

The AsterionDB Digital Bunker is a NoFS compatible product implemented within the Oracle Database. The Digital Bunker leverages not only the inherent security provided by the Oracle Database but also the benefits of unified backup and simplified disaster and recovery policies.

Digital assets that were previously external to the database now take full advantage of the benefits already enjoyed by a company’s structured data with the unified access and security scheme provided by the AsterionDB Digital Bunker.

About the author: Tim Robertson is AsterionDB’s Vice President of Technology. Tim has over 5 decades of experience and spent 29 years serving in many senior development roles at Oracle Corporation between 1989 and 2018.