Sqrrl June Webinar: An Accumulo Love Story

Securely explore your data

Sqrrl Visibility Labels and

Pluggable Authorization Systems: A Love Story

John Vines Engineer Sqrrl Data, Inc. [email protected]

WHAT MAKES ACCUMULO SPECIAL WHEN IT COMES TO SECURITY?

© 2014 Sqrrl | All Rights Reserved

CELL-LEVEL SECURITY



tldr;

visibilities are like ACLs

CELL-LEVEL SECURITY


tldr;

visibilities are like ACLs

...sort of

CELL-LEVEL SECURITY

SQRRL


What does this mean with sqrrl?

SQRRL


What does this mean with sqrrl?

Sqrrl uses these labels within hierarchical documents for the same

effect

SQRRL JSON


{"children@[FAM|IRS]": {"current": [{ "name": "Johnny" }], "expecting@[FAM]": [{ "name": "Baby Girl"}] } } Only the family and IRS care about

children. Only the family cares about expecting

THAT’S GREAT!


What does it get me?

THAT’S GREAT!


What does it get me?

Amalgamating data sources that are segregated

THE SCENARIO:


I am a first time Sqrrl/Accumulo user I want to use its nifty features I have no idea what I’m doing

FIRST TRY


Scan without JohnsLabel

FIRST TRY


Scan without JohnsLabel *sad trombone*

Scan with JohnsLabel

FIRST TRY


Scan without JohnsLabel *sad trombone*

Scan with JohnsLabel

uuid1 {"field1@[JohnsLabel]": "Value”} uuid2 {"field1@[JohnsLabel]": "Value”} uuid3 {"field2@[JohnsLabel]": "Value”} uuid4 {"field2@[JohnsLabel]": "Value”} uuid5 {"field1@[JohnsLabel]": "Value”}

SECOND TRY


uuid1 {"field1@[JohnsApplication]": "Value”} uuid2 {"field1@[JohnsApplication]": "Value”} uuid3 {"field2@[JohnsApplication]": "Value”} uuid4 {"field2@[JohnsApplication]": "Value”} uuid5 {"field1@[JohnsApplication]": "Value”}

SECOND TRY


What does my label even mean?

uuid1 {"field1@[JohnsApplication]": "Value”} uuid2 {"field1@[JohnsApplication]": "Value”} uuid3 {"field2@[JohnsApplication]": "Value”} uuid4 {"field2@[JohnsApplication]": "Value”} uuid5 {"field1@[JohnsApplication]": "Value”}

THIRD TRY


uuid1 {"field1@[application1|application2]": "Value”} uuid2 {"field1@[application1]": "Value”} uuid3 {"field2@[application1]": "Value”} uuid4 {"field2@[application2]": "Value”} uuid5 {"field1@[application3]": "Value”}

THIRD TRY


What about application4? application5? 6?

uuid1 {"field1@[application1|application2]": "Value”} uuid2 {"field1@[application1]": "Value”} uuid3 {"field2@[application1]": "Value”} uuid4 {"field2@[application2]": "Value”} uuid5 {"field1@[application3]": "Value”}

BACK TO THE DRAWING BOARD


What am I trying to accomplish? Why am I segregating my data?

FOURTH TRY


uuid1 {"field1@[org1|org2]": "Value”} uuid2 {"field1@[org1]": "Value”} uuid3 {"field2@[org1]": "Value”} uuid4 {"field2@[org2]": "Value”}

uuid5 {"field1@[org1&org2]": "Value”}

FOURTH TRY


Organizations are big!

uuid1 {"field1@[org1|org2]": "Value”} uuid2 {"field1@[org1]": "Value”} uuid3 {"field2@[org1]": "Value”} uuid4 {"field2@[org2]": "Value”}

uuid5 {"field1@[org1&org2]": "Value”}

FIFTH TRY


What about if subOrgs change?

uuid1 {"field1@[subOrg1|subOrg2]": "Value”} uuid2 {"field1@[subOrg1]": "Value”} uuid3 {"field2@[subOrg1]": "Value”} uuid4 {"field2@[subOrg2]": "Value”}

uuid5 {"field1@[subOrg1&subOrg2]": "Value”}

FIFTH TRY


What about if subOrgs change? Why do these orgs have permission?

uuid1 {"field1@[subOrg1|subOrg2]": "Value”} uuid2 {"field1@[subOrg1]": "Value”} uuid3 {"field2@[subOrg1]": "Value”} uuid4 {"field2@[subOrg2]": "Value”}

uuid5 {"field1@[subOrg1&subOrg2]": "Value”}

SIXTH TRY


Looks good!

uuid1 {"field1@[accountsReceivable|payroll]": "Value”}

uuid2 {"field1@[accountsReceivable]": "Value”} uuid3 {"field2@[accountsReceivable]": "Value”}

uuid4 {"field2@[payroll]": "Value”} uuid5 {"field1@[accountsReceivable&payroll]":

"Value”}

SIXTH TRY


Looks good! But now I need to manage users!

uuid1 {"field1@[accountsReceivable|payroll]": "Value”}

uuid2 {"field1@[accountsReceivable]": "Value”} uuid3 {"field2@[accountsReceivable]": "Value”}

uuid4 {"field2@[payroll]": "Value”} uuid5 {"field1@[accountsReceivable&payroll]":

"Value”}

PLUGGABLE SECURITY TO THE RESCUE




okay… what is this?



tserver scan

Pluggable Authorizor

getAuths() scan



tserver scan

Pluggable Authorizor

getAuths() scan

What does this mean to Sqrrl?

POLICY ENGINE


Sqrrl uses Apache Shiro to expose configurable security

POLICY ENGINE


Sqrrl uses Apache Shiro to expose configurable security

Less work needed to use existing security architecture

SEVENTH TRY


LDAP’s role-based access says: User1->HR

User2->InternalConflicts User3->Payroll User4->Taxes

SEVENTH TRY


One less system to maintain!



SEVENTH TRY


One less system to maintain! But our orgs are hierarchical!



EIGHTH TRY


Policy Engine Says: InternalConflicts->InternalConflicts,HR

Payroll->Payroll,Finance Taxes->Finance,AccountsReceivable

EIGHTH TRY


But what if I don’t want a certain org to get a piece of data?

Policy Engine Says: InternalConflicts->InternalConflicts,HR

Payroll->Payroll,Finance Taxes->Finance,AccountsReceivable

NINTH TRY


uuid5 {"field1@[designer&!manager]": "Value”}

NINTH TRY


Accumulo and Sqrrl do not support NOTs



Visibility labels have been a core piece of Accumulo for almost 6 years.

Last thing we want is people to inadvertently leak

data because of change in our security story (adding NOTs)

Accumulo has always supported downgrading

authorizations and this behavior will break NOTs

WHY NO NOTS?

NINTH TRY


Accumulo and Sqrrl do not support NOTs

What are we trying to accomplish?


TENTH TRY


uuid5 {"field1@[designer&(worker&contractor)]": "Value”}

TENTH TRY


But I want others to know some part of uuid5 field1!


REMEMBER


REMEMBER


{"children@[FAM|IRS]": {"current": [{ "name": "Johnny" }], "expecting@[FAM]": [{ "name": "Baby Girl"}] } }

ELEVENTH TRY



uuid5 {"field1@[engineer&(worker&contractor)]": "Value”}

ELEVENTH TRY


But I still want the managers to know that uuid5 field1 exists!


uuid5 {"field1@[engineer&(worker&contractor)]": "Value”}

TWELTH TRY


uuid5 {"field1": "Value”} uuid5 {"field1@[designer&(worker&contractor)]":

"Value”} uuid5 {"field1@[engineer&(worker&contractor)]":

"Value”}

TWELTH TRY


How can root look at everything?

uuid5 {"field1": "Value”} uuid5 {"field1@[designer&(worker&contractor)]":

"Value”} uuid5 {"field1@[engineer&(worker&contractor)]":

"Value”}

THIRTEENTH TRY


uuid5 {"field1": "Value”} uuid5 {"field1@[root|(designer&(worker&contractor))]":

"Value”} uuid5 {"field1@[root|(engineer&(worker&contractor))]":

"Value”}

THIRTEENTH TRY


I don’t like that...

uuid5 {"field1": "Value”} uuid5 {"field1@[root|(designer&(worker&contractor))]":

"Value”} uuid5 {"field1@[root|(engineer&(worker&contractor))]":

"Value”}

THIRTEENTH TRY 2


Remember the policy engine!

LDAP knows all roles root->all roles

THIRTEENTH TRY 2


All of my bases are covered!

Except...


LDAP knows all roles root->all roles

GETTING CRAFTY


What if I want to: ●  Allow authorizations based on time ●  Allow authorizations based on location ●  Make data more available ●  Make data less available

BEING CRAFTY



If you have the data available, you can use it!

COARSE ACCESS CONTROLS


Accumulo Tables have Read permissions for coarse access.

These can be used to restrict access to an

entire table for a user.

This is also exposed through a pluggable mechanism.



Looks familiar… what is this?



tserver scan

Pluggable PermissionHandler

hasTablePermission() scan

DATA-CENTRIC SECURITY


Sqrrl promotes Data-Centric Security.

Sqrrl encourages amalgamation of data for improved analytics. Coarse access breaks

this.

RECAP


●  Label for the data, not the users ●  Label with the highest granularity

possible ●  Let the policy engine do the rest of the

work ●  Need to rely on external services or

special processes for tracking labels ●  These can manage users authorizations

and general access

RECAP


Cell level security boils down to two separate components ●  Data labels ●  User granted labels They are the two halves that establish cell level security.

RECAP


Cell level security boils down to two separate components ●  Data labels ●  User granted labels They are the two halves that establish cell level security. Put the two together, and magic happens.


QUESTIONS?

@ohshazbot

[email protected]

SQRRL VISIBILITY LABELS AND PLUGGABLE AUTHORIZATION:

A LOVE STORY

Sqrrl June Webinar: An Accumulo Love Story

Data & Analytics

Transcript of Sqrrl June Webinar: An Accumulo Love Story