Srikar Gandhi
3 min readSep 3, 2023

Enhancing AWS Health Imaging Security with Session Policies

In a multi-organization environment, ensuring secure and fine-grained access control to AWS resources can be challenging. However, AWS provides a powerful feature known as session policies that can simplify and improve access management. In this article, we’ll explore how session policies can be effectively used within the context of AWS Health Imaging services to ensure that users from different organizations can access only the data stores relevant to their organization.

Use case Overview:

Imagine an organization that hosts multiple data stores in AWS Health Imaging. These data stores contain sensitive medical images and information. To maintain data security and privacy, it is imperative to restrict access to these data stores based on the organization to which a user belongs. Traditionally, this would require the creation of numerous IAM roles, leading to a complex and unmanageable access control structure. However, with session policies, we can streamline this process and achieve a more efficient and secure access management system.

Creating a Central IAM Role:
To begin implementing session policies, the first step is to create a central IAM role with a broad policy that allows actions relevant to AWS Health Imaging services across all data stores. This central role ensures that all users, regardless of their organization, can initially assume it to request STS credentials.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"medical-imaging:ListDICOMImportJobs",
"medical-imaging:SearchImageSets",
"medical-imaging:GetImageSet",
"medical-imaging:GetImageSetMetadata",
"medical-imaging:GetImageFrame",
"medical-imaging:ListImageSetVersions",
"medical-imaging:GetDICOMImportJob",
"medical-imaging:ListDatastores",
"medical-imaging:GetDatastore"
],
"Resource": "*"
}
]
}

Creating Organization-Specific Session Policies:

The real power of session policies comes into play when we issue STS credentials to users. Based on the organization a user belongs to, we can create a specific session policy that restricts their access to only the data store(s) relevant to their organization.

For example, when User A from Organization 1 requests STS credentials, we create a session policy like the one below:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "$policyActions$" ],
"Resource": [
"$dataStoreArn$/imageset/*",
"$dataStoreArn$"
]
}
]
}

Code for creating temporary credentials using STS

[HttpGet, Route("{organizationId}/GetCreds")]
public async Task<AssumeRoleResponse> GetHealthImagingTemporaryCredentialsAsync(string organizationId)
{
// Logic to map organizationId to datastore
// For the sake of simplicity, the datastore is hardcoded as "09999999993f4b43bd57b96f062592c7"
string datastoreArn =
"arn:aws:medical-imaging:us-east-1:09999999999:datastore/09999999993f4b43bd57b96f062592c7";

// IAM role
string roleArn = "arn:aws:iam::09999999999:role/central-imaging-role";

// Session policy defined above to restrict user access.
// Load inline policy from file
string inlinePolicy = System.IO.File.ReadAllText("inlinepolicy.json");
inlinePolicy = inlinePolicy.Replace("$dataStoreArn$", datastoreArn, StringComparison.Ordinal);

var assumeRoleRequest = new AssumeRoleRequest
{
DurationSeconds = 100,
RoleArn = roleArn,
Policy = inlinePolicy,
RoleSessionName = "temporary-role"
};

using IAmazonSecurityTokenService stsClient = new AmazonSecurityTokenServiceClient();
return await stsClient.AssumeRoleAsync(assumeRoleRequest).ConfigureAwait(false);
}

Conclusion:
AWS session policies provide a flexible and efficient way to control access to AWS Health Imaging services based on the organization a user belongs to. By creating a central IAM role with a broad policy and organization-specific session policies, organizations can achieve fine-grained access control without the complexity of managing multiple IAM roles. This approach enhances security, simplifies administration, and ensures that sensitive medical data remains protected.

No responses yet