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.
john@sqrrl.com

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
*sad trombone*
Scan with JohnsLabel

FIRST TRY
*sad trombone*
Scan with JohnsLabel
uuid1 {"field1@[JohnsLabel]": "Value”}

SECOND TRY
uuid1 {"field1@[JohnsApplication]": "Value”}

SECOND TRY
What does my label even mean?

THIRD TRY
uuid1 {"field1@[application1|application2]": "Value”}
uuid2 {"field1@[application1]": "Value”}

THIRD TRY
What about application4?
application5? 6?
uuid1 {"field1@[application1|application2]": "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”}
uuid5 {"field1@[org1&org2]": "Value”}

FOURTH TRY
Organizations are big!
uuid1 {"field1@[org1|org2]": "Value”}
uuid5 {"field1@[org1&org2]": "Value”}

FIFTH TRY
What about if subOrgs change?
uuid1 {"field1@[subOrg1|subOrg2]": "Value”}
uuid2 {"field1@[subOrg1]": "Value”}
uuid5 {"field1@[subOrg1&subOrg2]": "Value”}

FIFTH TRY
What about if subOrgs change?
Why do these orgs have permission?
uuid1 {"field1@[subOrg1|subOrg2]": "Value”}
uuid5 {"field1@[subOrg1&subOrg2]": "Value”}

SIXTH TRY
Looks good!
uuid1 {"field1@[accountsReceivable|payroll]":
"Value”}
uuid2 {"field1@[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”}
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!
User1->HR
User3->Payroll
User4->Taxes

SEVENTH TRY
One less system to maintain!
But our orgs are hierarchical!
User1->HR
User3->Payroll
User4->Taxes

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!
"Value”}

REMEMBER

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

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

ELEVENTH TRY
But I still want the managers to know
that uuid5 field1 exists!
"Value”}
"Value”}

TWELTH TRY
uuid5 {"field1": "Value”}
"Value”}
"Value”}

TWELTH TRY
How can root look at everything?
"Value”}
"Value”}

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

THIRTEENTH TRY
I don’t like that...
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
john@sqrrl.com
SQRRL VISIBILITY LABELS AND PLUGGABLE
AUTHORIZATION:
A LOVE STORY

Sqrrl June Webinar: An Accumulo Love Story

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (6)

Similar to Sqrrl June Webinar: An Accumulo Love Story

Similar to Sqrrl June Webinar: An Accumulo Love Story (20)

More from Sqrrl

More from Sqrrl (18)

Recently uploaded

Recently uploaded (20)

Sqrrl June Webinar: An Accumulo Love Story