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?

CELL-LEVEL SECURITY

visibilities are like ACLs

CELL-LEVEL SECURITY

visibilities are like ACLs

...sort of

CELL-LEVEL SECURITY

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

{"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

●  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

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

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

rights reserved

rights reserved

rights reserved

rights reserved

rights reserved

rights reserved

rights reserved

authorizations

Data & Analytics

sqrrl enterprise: integrate, explore, analyze

sqrrl february webinar: breaking down data silos

accumulo summit 2015: apache accumulo at bloomberg [keynote]

accumulo summit 2015: tracing in accumulo and hdfs...

sqrrl 2.0 launch webinar

sqrrl - matt...

accumulo summit 2014: accismus -- percolating with accumulo

accumulo summit 2015: ambari and accumulo: hdp 2.3 upcoming...

accumulo design

accumulo summit 2014: accumulo on yarn

accumulo summit 2014: data-center replication with apache...

accumulo summit 2015: event-driven big data with accumulo -...

aws sqrrl · sqrrl reveals connections between alerts,...

hortonworks sqrrl webinar v5.pptx

accumulo summit 2015: zookeeper, accumulo, and you...

april 2015 webinar: cyber hunting with sqrrl

sqrrl real time_big_data_20130411

accumulo summit 2015: real-time distributed and reactive...

sqrrl may webinar: data-centric security

sqrrl - the apache software...