In the past, many NoSQL systems came with minimal security features and put security functions in the application layer. However, some newer NoSQL databases are supporting fine-grain security policy management. In this webinar we will discuss the trends in NoSQL security and the ability for new releases of some NoSQL databases to address in-database security concerns. We will see how security policies can be migrated from SQL to NoSQL systems.
Gen AI in Business - Global Trends Report 2024.pdf
NoSQL Now! Webinar Series: Migrating Security Policies from SQL to NoSQL
1. Migrating Security Policies from SQL
to NoSQL
Dan
Adam
November 26, 2013
With Panelist Adam Retter and Michael Allen
Michael
2. Summary
• In the past, many NoSQL systems came with
minimal security features and put security
functions in the application layer. However, some
newer NoSQL databases are supporting fine-grain
security policy management. In this webinar we
will discuss the trends in NoSQL security and the
ability for new releases of some NoSQL databases
to address in-database security concerns. We will
see how security policies can be migrated from
SQL to NoSQL systems. We will also be
interviewing NoSQL vendors that have added
security to the database layer and discuss their
experiences with security conscious customers.
M
D
Copyright Kelly-McCreary & Associates
2
3. Four Areas of DB Security
Are users and requests from the
people they claim to be?
Do users have read or/write access
to the appropriate data?
Authentication Authorization
Audit
Encryption
Can we track who read or updated
data and when they did it.?
Can we convert data to a form that can
not be used by unauthorized viewers?
M
D
Copyright Kelly-McCreary & Associates, LLC
3
4. Security Policies
• Written statements, usually in English
language text, that describes how your data
is protected
• Examples of policy statements
– Passwords must contain at least 6 characters
(Authentication)
– Only "managers" can approve travel requests
(Authorization)
– All transactions that change data must be audited
(Audit)
– All credit card information must be stored in
encrypted fields (Encription)
M
D
Copyright Kelly-McCreary & Associates
4
6. Enterprise Security Requrments
Must have
Need for in
database
security
enterprise wide
regulated
Nice to have
multiple projects
multi-division reporting
single project
Not required
role-based access control
Enterprise rollout timeline
M
D
6
7. Review of RDBMS Security
• Authentication is usually done using
– external client
– internal database login/password
• Authorization is done on tables using DDL
–
–
–
–
SQL "GRANT" statements
Read, write, update, delete
Views allow fine-grain control rows/columns
Stored procedures allows "amplified" permissions
• Most RDBMS products have mature audit tools
• Most RDBMS systems use applications to encrypt data
M
D
Copyright Kelly-McCreary & Associates
7
8. Review of Analytical Security
• Focus on who can access what "cubes"
• Some portions of fact tables (dimensions)
can be restricted by user or group
• Minimal cell size restrictions in reports to
prevent inference
• Example:
– What is the average math score of female Asian
children in the 4th grade at this school?
– If there is only a single person in this set the
privacy rules will not show any results
M
D
Copyright Kelly-McCreary & Associates
8
9. Most New NoSQL Products
• Did not focus on security in the database
• Focused on application-level security
• Only more mature "release 2.0" systems
tend to add security
• Many regulated business (healthcare,
finance) could not use early NoSQL
systems but are not starting to adopt
NoSQL systems
M
D
Copyright Kelly-McCreary & Associates
9
10. Implementing Security
Firewalls and application servers protect
databases from unauthorized access
Internet
Firewall
Reporting tools run directly on a database so
the database may need its own security layer
App Server
Reporting
Tools
Database
• Many projects can put security at the application
level
• Reporting tools frequently go directly against a
database
M
D
10
11. Simple Circles, Simple Policies
general public
intranet users
authenticated users
database
administrators
•
•
Simple authorization security policies can be drawn as Venn Diagrams
Complex security policies have 100s of overlapping circles
M
D
11
12. Implementing Auth and Auth
Authentication
Database
Request
Authorization
Y
Id in
header?
N
Company
Directory
Deny access
Login
OK
Role has
access to
data?
Y
Get/Put
data
Return
result
N
Login
N
Lookup
groups or
roles
Return error
Database
Y
M
D
12
13. Security Grain
Database
Course grain access control
– little performance impact
Collection
Document
Element
Fine grain access control
– large performance impact
• Version "1.0" of many NoSQL databases only control
access based on collections
• Fine-grain access control can limit performance on
distributed systems
M
D
13
14. Collections, Document and Elements
Database
database root collection
department collection
application collection
document
element
• Applies to some types of NoSQL systems
M
D
14
15. The UNIX file system model
Your own permissions
Your group's permissions
owner
The letters RWX are
for Read, Write and
Execute Permissions
group
others
RWX
RWX
RWX
110
110
100
Everyone else
The permissions for anyone
outside your group are
Read=true, Write=false and
Execute=false
• HDFS and eXist-db both support the UNIX security model
M
D
15
17. Simplified RBAC Model
Each user has one or more
roles in the database.
User
Role
Resources are associated with a
permission for each role.
Permission
(read, write)
Resource
(collection, document)
Roles are associated with
one or more permissions.
• Role based access control models
decouple the user from the resource
M
D
17
18. MarkLogic Security Model
Amplified Permission (AMP)
Users and roles both have default
permissions for documents and
collections.
Execute Privilege
Multiple roles can be associated with
special privileges on functions,
queries and URIs.
URI Privilege
Document
User
Role
Permission
Collection
Roles exist in a hierarchy and lower roles
inherit permissions from upper roles.
Each permission record , stored with a
document or collection, associates a single
capability(read, write, update or execute)
with a single role.
Each
document
and
collection is
associated
with a URI
and
permissions.
• Sample RBAC model in MarkLogic
M
D
18
19. Apache Accumulo
Key
Row ID
Column
Family
Qualifier Visibility
Timestamp
Value
• Visibility is a 64-bit field that holds authorization
information. Only users that have the right
visibility settings can see the value
M
D
19
20. Amazon S3 Security Models
IAM Policy
Bucket Policy
Allow Who
Ann
Dan
Allow
Actions:
PutObject
Is the same as
Resource
aws:s3:::bucket_kma/*
Ann
M
D
Actions:
PutObject
Resource
Aws:s3::bucket_kma/*
Dan
20
22. Migrating Security Policies from SQL
to NoSQL
Dan
Adam
November 26, 2013
With Panelist Adam Retter and Michael Allen
Michael
23. Sample Slides
•
•
•
•
Encryption and Security in Accumulo
Michael Allen
Sqrrl Data Inc.
http://www.slideshare.net/DonaldMiner/acc
umulo-oct2013bofpresentation
M
D
Copyright Kelly-McCreary & Associates
23