In a recent blog, I mentioned we were constantly balancing the opinionated nature of the Telicent CORE platform with the need for flexibility. Just as important is the balance between being secure and the need to maximise the availability of information. In this blog I want to dig into modern access control a little — how do need-to-know and need-to-share co-exist?
Traditional systems tend to apply a blanket approach to access control — if the data is in a particular database, dataset or record it is all subject to the same access controls. Some databases are better than others, but because they all implement different approaches, it’s very hard to achieve a coherent access control policy across multiple datasets. We decided to take a slightly different approach — all data entering the security boundary of the CORE platform is tagged with labels that describe access requirements (and meta-data, retention period, etc. but more on that in another blog). Wherever the data goes in the platform, it carries its labels with it — throughout the data pipeline and into the databases. When a user wants to access the data (usually through an application) we compare the user’s credentials (attributes) with the access control labels on the data. If the data labels match the user attributes, the data can be accessed. Otherwise, it cannot cross the security boundary.
This is known as Attribute-Based Access Control (ABAC) and is a commonly used security pattern. So far so good , but where it gets interesting is that we apply the security labels at a very fine level of granularity — right down to individual fields and relationships if needed. As the CORE Platform is all about integrating data from multiple sources, you can end up with data that has a multitude of different security labels. Because we filter the data at the boundary, we redact only those parts of the data where labels don’t match the user attributes. This is the way we maximise data availability while maintaining the highest levels of security.
ABAC is not without its criticisms — it is hard to implement as an afterthought, and in some types of databases it has to be applied before the queries are executed in order to prevent leakage of data. Luckily, the database engineers at Telicent know just how to do that — we can confidently expose our query endpoints at the boundary knowing that users will only see the data they’re allowed to.
The other criticism that is often levelled at ABAC is that it is complicated to administer. There is some truth in this, but ABAC is a low-level approach and not intended to be exposed to users. Most sensible ABAC systems apply policy to control the combinations of labels that can be specified — this is sometimes known as policy-based access control (PBAC). At this point, it’s worth mentioning role-based access control (RBAC) which is usually cited as the less complex and more manageable approach — usually by companies whose systems still rely on it. The lack of flexibility in RBAC is its downfall though. It’s not unusual to end up with thousands of roles defined in even a medium-sized enterprise that cares about security— simply because you need to create a new role for every edge case. The alternative is to restrict the number of roles, and this can lead to over-protection or leakage.
The interesting thing about the data carrying its labels around with it is that we start to get opportunities to apply some really clever functionality. For example, some user attributes might be ephemeral — e.g. is the user in the building or on a number 27 bus? The opportunities are endless, but the obvious ones are around networks (open, VPN, local), location and motion sensing in mobile devices — is it a real phone or an emulation? ABAC combined with live user information is an idea that has been knocking around in the defence and government sectors for over a decade and has recently drawn the attention of the big tech companies[1]. This is where zero-trust security principles meet access control.
When we combine Telicent CORE’s ability to apply labels at any granularity with sensible policies and live user data, we can truly maximise data sharing whilst staying secure. I’ll cover more aspects around openness – our commitment to open-source software development and open data standards – in another blog soon.
