Tải bản đầy đủ
3 Case Study: access controls on key-value store— Amazon S3

3 Case Study: access controls on key-value store— Amazon S3

Tải bản đầy đủ

Case Study: access controls on key-value store—Amazon S3


Finally, the headers are constructed and the call to retrieve the object is made. As you
can see in listing 11.4, the encrypted signature is combined in the header with your S3
access key and the call is made.
Listing 11.4

XQuery for REST HTTP GET with the AWS security credentials

let $headers :=

let $url := concat($amazon-s3:endpoint, $bucket, '/', $object)
let $results := httpclient:get($url, false(), $headers)

In addition to the security for retrieving objects, S3 provides additional access-control
mechanisms (ACMs) that allow others to view, download, and update your buckets and
objects. For example:
 Identity and Access Management (IAM)
 Access-control lists (ACLs)
 Bucket policies

11.3.1 Identity and Access Management (IAM)
IAM systems allow you to have multiple users within an AWS account, assign credentials to each user, and manage their permissions. Generally, IAM systems are found in
organizations where there’s a desire to grant multiple employees access to a single
AWS account. To do this, permissions are managed using a set of IAM policies that are
attached to specific users.
For example, you can allow a user dan to have permission to add and delete images
from your web-site-images bucket.

11.3.2 Access-control lists (ACL)
Access-control lists can be used to grant access to either buckets or individual objects.
Like IAM systems, they only grant permissions and are unable to deny or restrict at an
account level. In other words, you can only grant other AWS accounts access to your
Amazon S3 resources.
Each access-control list can have up to 100 grants, which can be either individual
account holders or one of Amazon’s predefined groups:
 Authenticated Users group—Consists of all AWS accounts
 All Users group—Consists of anyone, and the request can be signed or unsigned

When using ACLs, a grantee can be an AWS account or one of the predefined Amazon
S3 groups. But the grantee can’t be an IAM User.



Security: protecting data in your NoSQL systems

11.3.3 Bucket policies
Bucket policies are the most flexible method of security control, because they can
grant as well as deny access to some or all objects within a specified bucket at both
account and user levels.
Though you can use bucket policies in conjunction with IAM policies, bucket policies can be used on their own and achieve the same result. For example, figure 11.10
demonstrates how two users (Ann and Dan) have been granted authority to put
objects into a bucket called bucket_kma.
Perhaps you’re wondering when to use a bucket policy versus an ACL. The answer
is that it depends on what you’re trying to accomplish. Access-control lists provide a
coarse-grained approach to granting access to your buckets/objects. Bucket policies
have a finer-grained approach. There are times when using both bucket policies and
ACLs make sense, such as
 You want to grant a wide variety of permissions to objects but you only have a

bucket policy.
 Your bucket policy is greater than 20 KB in size. The maximum size for a bucket
policy is 20 KB. If you have a large number of objects and users, you can grant
additional permissions using an ACL.
There are a few things to keep in mind when combining bucket policies and ACLs:
 If you use ACLs with bucket policies, S3 will use both to determine whether the

account has permissions to access an object.
 If an account has access to an object through an ACL, it’ll be able to access the
requested bucket/object.
...bucket policy
Allow Who

IAM policy...

...is the same as...





Figure 11.10 You can
use a bucket policy to
grant users access to your
AWS S3 objects without
using IAM policies. On the
left, the IAM policy allows
the PutObject action for
bucket_kma in an AWS
account, and then gives
the users Ann and Dan
permission to access that
account/action. On the
right, the bucket policy is
attached to bucket_kma
and like the IAM gives Ann
and Dan permission to
access PutObject on
the bucket.


Case study: using key visibility with Apache Accumulo

 When using a bucket policy, a deny statement overrides a grant statement and

will restrict an account’s ability to access a bucket/object, essentially making the
bucket policy a superset of the permissions you grant an ACL.
As you can see, S3 offers multiple mechanisms for keeping your data safe in the cloud.
With that in mind, is it possible to grant fine-grained security on your tabular data
without impacting performance? Let’s look at how Apache Accumulo uses roles to
control user access to the confidential information stored in your database.

11.4 Case study: using key visibility with Apache Accumulo
The Apache Accumulo project is similar to other column family architectures, but with
a twist. Accumulo has an innovative way of granting fine-grained security to tabular
data that’s flexible and doesn’t have a negative performance impact for large datasets.
Accumulo’s method of protecting fine-grained data in the database layer is to
place role, permissions, or access list information directly in the key of a key-value
store. Since organizations can have many different models of access control, this
could make the size of keys unwieldy and take considerable disk space. Instead of putting multiple security models into multiple fields of a key, Accumulo adds a single general field, called Visibility, that’s evaluated for each query and returns true or false each
time the key is accessed. This is illustrated in figure 11.11.
The format of the Visibility field isn’t restricted to a single user, group, or role.
Because you can place any Boolean expression in this field, you can use a variety of
different access-control mechanisms.
Every time you access Accumulo, your query context has a set of Boolean authorization tokens that are associated with your session. For example, your username, role,
and project might be set as authorization tokens. The visibility of each key-value is calculated by evaluating the Boolean AND (&) and OR (|) combinations of authorization
strings that must return true for a user to view the value of a key-value pair.
For example, if you add the expression (admin|system)&audit, you’d need either
admin OR system authorization AND the audit to be able to read this record.
Although putting the actual logic of evaluation within the key itself is unusual, it
allows many different security models to be implemented within the same database.

Row ID





Figure 11.11 Apache Accumulo adds a Visibility field to the column portion of each
key. The Visibility field contains a Boolean expression composed of authorization tokens
that each return true or false. When a user tries to access a key, the Visibility
expression is evaluated, and if it returns true, the value is returned. By restricting the
Visibility expression to be only Boolean values, there’s a minimal performance penalty
even for large datasets.



Security: protecting data in your NoSQL systems

As long as the logic is restricted to evaluating simple Boolean expressions, there’s a
minimal impact on performance.
In our last case study, we’ll look at how to use MarkLogic’s role-based, accesscontrol security model for secure publishing.

11.5 Case study: using MarkLogic’s RBAC model
in secure publishing
In this case study, we’ll look at how role-based access control (RBAC) can protect
highly sensitive documents within a large organization and still allow for fine-grained
status reporting. Our example will allow a distributed team of authors, editors, and
reviewers to create and manage confidential documents and yet prevent unauthorized
users from accessing the text of the confidential documents.
Let’s assume you’re a book publisher and you have a contract to create a new book
on a hot, new NoSQL database that’s being launched in a few months. The problem is
that the company developing the database wants assurances that only a small list of
people will be able to access the book’s content during its development. Your contract
specifically states that no employees other than the few listed in the contract can have
access to the text of the documents. Your payments are contingent on the contents of
the book staying private. The contract only allows high-level reports of book metrics to
be viewed outside the small authoring team.
Your publishing system has four roles defined: Author, Editor, Publisher, and
Reviewer. Authors and Editors can change content, but only users with the Publisher
role can make a document available to reviewers. Reviewers have collections configured so that they can add comments in a comment log, but they can’t change the
main document content.

11.5.1 Using the MarkLogic RBAC security model to protect documents
MarkLogic has built-in, database-layer support for role-based access control, as
described in “Using roles to calculate access control” in section 11.2.2. The MarkLogic
security model uses many of these same RBAC concepts as well as implements some
enhanced functionality.
MarkLogic applies its security policy at the collection and the document levels and
allows users to create functions that have elevated permissions. This feature enables
element-level control of selected documents without compromising performance.
This case study will first review the MarkLogic security model and then show how it
can be applied in a secure publishing example. Finally, we’ll review the business benefits of this model.
A logical diagram of how MarkLogic security models work is shown in figure 11.12.
Here are some of the interesting points of the MarkLogic RBAC security model:
 Role hierarchy—Roles are configured in a hierarchy, so a lower-level role will

automatically inherit the permissions of any parent roles.