In this video, you'll see how you can secure your AWS data architecture.
Using built-in security controls, you can manage user access to your Amazon
Redshift clusters and grant user permissions to your Amazon Simple
Storage Service (Amazon S3) data lake to safely democratize data access.
Let's begin at our Amazon Redshift dashboard.
For our purposes, we already have a Redshift cluster created in our account.
Let's review the cluster's properties.
We can see that this cluster was created within a virtual private cloud (VPC),
and within a particular subnet defined by a subnet group.
Let’s look at the subnet group.
The subnet group comprises three subnets in three Availability Zones.
Since the cluster is created within a subnet, a network access control list (ACL) can be applied.
By default, a security group is assigned for controlling inbound and outbound traffic,
and the public access option is disabled.
An AWS Identity and Access Management (IAM) role
has been assigned to control which AWS services the cluster can connect to.
We can secure the cluster by defining which users have access,
and even what tables or parts of tables they can view or modify.
We’ll look at two ways to grant user permissions: through the IAM role and with the query editor.
Let's first try with the query editor.
We'll use the built-in query data and the current connection.
If we wanted to change the connection,
we could provide information about the cluster and database here.
In this case, let’s move on.
As you can see, the dev database comprises a number of tables.
As the Redshift administrator, we'll create an analyst user and grant access to only some of the tables—
and only some of the columns in those tables.
Now that the analyst user is created, we'll grant the user SELECT access to three tables in the dev database: sales, event, and date.
We’ll also grant access to two of the four columns in the category table.
Controlling access at the column level allows us to protect personally identifiable data
while still providing analysts with the data they need.
Let's switch to the analyst user’s point of view.
Now we're logged in. Let's connect to the dev database.
We can see the three tables the analyst user has access to.
Let’s expand the date table to see the columns we can query.
Let's run a query to capture all accessible data in the date table.
Let's run another query on the two columns from the category table this user has access to.
Now let’s see what happens if the query includes a column the analyst user cannot access.
The query editor has responded with an error message.
Let's return to the admin user's account.
A second way to grant cluster permissions is by managing the IAM role that governs the Redshift cluster.
For instance, in the IAM permissions for our analyst user,
full access is granted to the Redshift query editor and Amazon Athena,
but read-only access is granted to the Redshift console.
Now that we’ve looked at how the data warehouse can be secured,
let’s look into securing the data lake.
In this example, we have an Amazon S3 bucket serving as the data lake.
It contains two objects: events and users.
As you can see here in AWS Lake Formation, we’ve registered the S3 location as our data lake.
We also created a database for our AWS Glue Data Catalog
by crawling the files in the S3 bucket and creating the corresponding metadata tables.
From here we can grant table access to specific users.
We’ll work with the events table first and permit the analyst user to query parts of the data.
We’ll give this user SELECT permissions, keeping the default for all data access.
Next, we’ll grant access to the users database table.
This time we’ll give the user SELECT permissions, but with only column-based access.
We'll exclude columns containing certain personally identifiable data.
Now that we've granted the analyst user permissions to the data lake,
let's perform some queries from that account.
With a page refresh, we see the user has access to the two tables in the database.
Let's run a query to collect 10 data results from the users table.
The query runs successfully.
From the analyst user's perspective, there is no indication that some data columns are blocked.
Let's adjust the query to apply to the events table.
The analyst user is again able to successfully run this Select query.
Often, users use more than one AWS service to connect with or query their data lake.
Accordingly, the AWS data architecture has many ways to maintain data security while democratizing access between services.
As an example, we'll bring data from outside the data lake and join it with some data in our Redshift data warehouse.
From the admin user account, we’ll run a query to create an external schema on our database.
We’ll now grant the analyst user access to the schema’s tables.
Another way to grant user access is by revising the permissions for the data lake that houses the database.
From the data lake permissions page on AWS Lake Formation,
we can search for the principal IAM role that governs the Redshift cluster and ensure it has access to all tables in the database.
In this case, the role has access to all tables in the database.
Let’s switch to the analyst user one last time.
We’ll select the schema in the dev database and perform some queries that join the data from our Redshift cluster with our data lake.
With this code, we'll join the sales table from the dev database to the users table from the external schema.
The analyst user can now view the joined data in the tables and columns the role has been granted access to.
You’ve just seen how you can secure your AWS data architecture.
You can learn more about this topic in the description and links for this video.
Thanks for watching. Now it's your turn to try.