Thursday, August 18, 2022
No menu items!
HomeDatabase ManagementFine Grained Access Control for Amazon Neptune data plane actions

Fine Grained Access Control for Amazon Neptune data plane actions

Amazon Neptune is purpose-built to store and navigate relationships. This provides advantages over relational databases for use cases like social networking, recommendation engines, and fraud detection, where you need to create relationships between data and quickly query these relationships.

At AWS, security is Job Zero. Neptune offers several security features, including network isolation, encryption, and resource-level permissions for database management through AWS Identity and Access Management (IAM) in a shared responsibility model that customers can use to deploy solutions that meet industry-specific certification requirements.

Neptune is secured via network isolation, encryption at rest & transit and resource level permission for database management. In this post, we show how users can control access to Neptune database access APIs through new Fine Grained Access Control (FGAC) data plane actions in IAM policy. These actions provide control over read, write, delete, bulk loading, and other data plane operations.

Network isolation

Neptune runs in Amazon Virtual Private Cloud (Amazon VPC), which allows you to isolate your database in your virtual network. It can also connect to your on-premises IT infrastructure using industry-standard encrypted IPsec VPNs and AWS Direct Connect. In addition, you can use the VPC configuration in Neptune to configure firewall settings and control network access to your database instances.

Encryption at rest and in transit

Neptune allows you to encrypt your databases using keys you create and control through AWS Key Management Service (AWS KMS). On a database instance running with Neptune encryption, data stored at rest in the underlying storage is encrypted, as are the automated backups, and snapshots in the same cluster.

Neptune only allows Secure Sockets Layer (SSL)/TLS 1.2 connections through HTTPS to any instance or cluster endpoint. The client should connect to Neptune endpoints through SSL to help protect customer data, using HTTPS instead of HTTP.

Resource-level permissions for database management

Neptune is integrated with IAM. It allows you to control the actions that your IAM users and groups can take on specific Neptune resources. These resources include clusters, cluster parameter groups, cluster snapshots, database instances, database snapshots, database parameter groups, database subnet groups and database event subscriptions. In addition, you can tag your Neptune resources and control the actions that your IAM users and groups can take on groups of resources that have the same tag (and tag value). For example, you can configure your IAM rules to ensure developers can modify development database instances, but only database administrators can modify and delete production database instances. The following diagram illustrates the high-level permission model for Neptune.

Before Neptune engine version 1.2.0.0, Neptune didn’t offer granular access control or tag-based access control for database access APIs also known as data plane actions (for example, querying and bulk loading), which are different from database management APIs. This is reflected in the dashed lines in the preceding figure.

New Fine Grained Access Control (FGAC) for Neptune data plane with IAM

Starting in Neptune engine version 1.2.0.0, users now have the ability to control access to database API through new FGAC data plane actions in IAM policy. These actions provide control over read, write, delete, bulk loading, and other data plane operations.

Note: The “connect” IAM action is deprecated with this change. Existing IAM policies that are based on the deprecated connect action must be adjusted to use the more granular data plane actions. See Types of Neptune data plane IAM policies.

To explain this, let’s take an example of a healthcare system. A typical hospital has patients, doctors, nurses, IT administrators, and researchers. These people have responsibilities that define what level of permission they have to create, modify, and delete patient records:

Doctor – Create, view, and edit patient records
Nurse – Create, view, and edit patient records
Researcher – Read patient records
IT administrator – Update access policies for all users

This example healthcare system uses Neptune as a graph database to store, manage, and track patients’ medical history. The following is a network/graph representation of the healthcare system.

The system needs the capability to define the different levels of permission for all personas based on their role. Neptune allows you to define security via network isolation and IAM-based access. The new set of IAM permissions extends existing IAM-based permissions to give more granular permissions to an IAM principal, including query level access to read, write, and delete.

The following policies illustrate the mappings of user personas to permissions.

Researcher (read only)

The following policy grants read access via query only permission to a Neptune database:

{
“Version”:”2012-10-17″,
“Statement”:[
{
“Action”:[
“neptune-db:ReadDataViaQuery”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”
}
]
}

Doctor and nurse (read, write, delete)

The following policy grants read, write, and delete access via query to the Neptune database data plane actions:

{
“Version”:”2012-10-17″,
“Statement”:[
{
“Action”:[
“neptune-db:ReadDataViaQuery”,
“neptune-db:WriteDataViaQuery”,
“neptune-db:DeleteDataViaQuery”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”
}
]
}

IT administrator (full access)

The following policy grants full access to the Neptune database data plane actions (minus Amazon Neptune ML actions):

{
“Version”:”2012-10-17″,
“Statement”:[
{
“Action”:[
“neptune-db:ReadDataViaQuery”,
“neptune-db:WriteDataViaQuery”,
“neptune-db:DeleteDataViaQuery”,
“neptune-db:GetEngineStatus”,
“neptune-db:GetStreamRecords”,
“neptune-db:StartLoaderJob”,
“neptune-db:GetLoaderJobStatus”,
“neptune-db:CancelLoaderJob”,
“neptune-db:ListLoaderJobs”,
“neptune-db:ResetDatabase”,
“neptune-db:GetStatisticsStatus”,
“neptune-db:DeleteStatistics”,
“neptune-db:ManageStatistics”,
“neptune-db:GetQueryStatus”,
“neptune-db:CancelQuery”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”
}
]
}

IT administrator (full access except for fast reset)

The following policy grants full access to Neptune data plane actions except for fast reset API:

{
“Version”:”2012-10-17″,
“Statement”:[
{
“Action”:[
“neptune-db:*”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”
},
{
“Action”:[
“neptune-db:ResetDatabase”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Deny”
}
]
}

Global context keys with IAM policies

Global context keys allow you to specify conditions in IAM policies that control access to Neptune resources. The policy statement then takes effect only when the conditions are true.

In a real-world application, you can combine IAM policies and global context keys to define a single policy that can be attached to multiple users or roles.

For example, if you want to allow access to various entities based on the principal tag (the tag attached to the IAM user or role), a sample policy looks like the following:

{
“Version”:”2012-10-17″,
“Statement”:[
{
“Action”:[
“neptune-db:ReadDataViaQuery”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”,
“Condition”: {
“StringEquals”: {
“aws:PrincipalTag/persona”: “researcher”
}
}
},
{
“Action”:[
“neptune-db:ReadDataViaQuery”,
“neptune-db:WriteDataViaQuery”,
“neptune-db:DeleteDataViaQuery”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”,
“Condition”: {
“StringEquals”: {
“aws:PrincipalTag/persona”: “doctor”
}
}
},
{
“Action”:[
“neptune-db:*”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Allow”,
“Condition”: {
“StringEquals”: {
“aws:PrincipalTag/persona”: “itadmin”
}
}
},
{
“Action”:[
“neptune-db:ResetDatabase”
],
“Resource”:[
“arn:aws:neptune-db:<AWSRegion>:<AWSAccountID>:<AmazonNeptuneResourceIdentifier>/*”
],
“Effect”:”Deny”
}
]
}

Conclusion

In this post, we showed you how Fine Grained Access Control (FGAC) data plane actions for Neptune enable you to grant more granular permissions to manage your existing and new Neptune clusters. To use FGAC data plane actions, create a new cluster with Neptune version 1.2.0.0 and enable IAM. Refer to the documentation to understand FGAC data plane policies in detail.

About the authors

Ankit Gupta is a Software Development Manager with the Amazon Neptune Platform Team in India and has been part of the Neptune team since product inception. He works with AWS customers and internal development teams to improve Neptune’s usability, performance, scalability, and user experience.

Abhishek Mishra is a Sr. Specialist Solutions Architect focused on Amazon Neptune at AWS. He helps AWS customers build innovative solutions using graph databases. In his spare time, he loves making the earth a greener place.

Read MoreAWS Database Blog

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments