How to provide improved data isolation for tenant robots

Introduction

Robots are used in various industries and use cases, such as medical robotics for surgeries, material movement robots for industrial automation, security robots for surveillance and monitoring, fruit picking robots for agriculture, and many more. Depending on the application, these robots create large amounts of data, which may contain sensitive information such as personally identifiable information (PII) or video feeds from restricted locations, and may be subject to compliance or regulatory requirements that impose strict isolation rules.

Overview

Business models such as Robot-as-a-Service (RaaS) and lease/rent options increase robot usage in organizations. RaaS and some lease/rent robots integrate with cloud-based services. These cloud-based services are multi-tenant and must provide isolation between tenant workloads. Strategies to provide tenant isolation include silo and pool isolation (see the SaaS Tenant Isolation Strategies whitepaper). Silo isolation completely segments tenants within their isolation boundary, versus pool isolation which shares infrastructure between tenants. Vendors that use AWS IoT Core to connect their robots are guided towards pool isolation as AWS IoT Core Things are attached to an AWS account. Compliance or regulatory rules for a use case or industry can impose strict constraints on tenants. AWS account-based silo isolation is appealing in these scenarios, since the data resides in different accounts to begin with and leverages the AWS account as an isolation boundary.

In this post, you’ll learn how to enable the highest level of customer data isolation by deploying AWS account-based silo isolation for your robotics application. You will understand how this approach allows centralized management while providing a compelling story to customers regarding the possibility of cross-tenant access.

Centralized account management and robot provisioning

A siloed environment relies on a shared identity and operational experience. These identity and operational features are hosted in a separate AWS account with AWS account-based silo isolation. This core account stores information related to the robots, robot tenancy, users, end-customers, and the AWS account for each customer.

The vendor must be able to assign robots to different tenants as part of normal operations. As mentioned previously, AWS IoT Core Things are connected to an AWS account. With AWS account-based silo isolation, robots are connected to the dedicated tenant account and another AWS service must be connected to the core account to configure the AWS IoT Core Thing when the robot changes tenant. AWS Systems Manager is a secure end-to-end management solution for hybrid cloud environments. Robots connect to the core account using Systems Manager. This allows the core account to update, manage, and configure robots so that tenancy can be altered as needed. Robots connect to the core account by installing the AWS Systems Manager Agent and using hybrid activation. Systems Manager provisions (and de-provisions) AWS IoT Greengrass on the robot, assigning robots to tenants. The following diagram illustrates changing robot tenancy:

1. Initiate robot tenancy change. A vendor administrator makes an API call to assign a robot to a tenant.
2. Amazon API Gateway invokes AWS Lambda. AWS Lambda is a serverless, event-driven computing service.
3. Invoke provisioning cross-account. The API Handler invokes the provisioning AWS Lambda function in the tenant account.
4. Create resources in the tenant AWS account. The provisioning Lambda creates the necessary resources in the customer account. The provisioning Lambda also makes AWS IoT Greengrass deployments that could be customized per customer and/or robot. The provisioning Lambda returns the certificate, private key, and other needed information to the API Handler.
5. Call run command. The API handler uses AWS Systems Manager Run Command to remove any existing AWS IoT Greengrass Core installation and then install Greengrass Core on the robot with the new configuration.
6. Execute commands on robot. The AWS Systems Manager agent executes the commands on the robot.
7. AWS IoT Greengrass Core on the robot connects to the tenant account.
8. The API Handler saves the robot assignment into the database.

Figure 1. The architecture of the AWS account-based silo isolation approach highlighting the service calls in response to a vendor administrator assigning a robot to a tenant.

Tenant data must stay in the dedicated AWS account to support challenging compliance or regulatory requirements. Interactions with the robot must occur through the dedicated tenant account. Figure 2 illustrates how a tenant user interacts with the robot:

1. Initiate request. The tenant user makes a request to control or receive data from the robot to an Amazon API Gateway in the tenant account.
2. Amazon API Gateway invokes AWS Lambda API Handler.
3. Request identity and robot assignment data from the core account. The API handler in the tenant account invokes the gateway handler AWS Lambda in the core account to handle these requests.
4. Retrieve identity and robot assignment data from the database.
5. Send the request via AWS IoT Core.
6. The robot receives the message and replies appropriately.

Figure 2. The architecture of the AWS account-based silo isolation approach highlighting the service calls in response to a tenant user interacting with a robot.

As mentioned previously, AWS account-based silo isolation keeps all tenant data in the tenant AWS account. No access will be possible between customer accounts and the core account will only have access to invoke the provisioning Lambda in the robot end-user account. To meet the strictest compliance or regulatory requirements the vendor should not be able to access the tenant account. In these cases, it would be possible to use an AWS account owned by the tenant.

AWS Accounts as silos for customer data

The previous sections described how AWS account-based silo isolation meets tenant’s challenging compliance or regulatory requirements. As shown in Figure 3, each tenant account has the tenant infrastructure deployed. This has pros and cons when compared to pool isolation.

Figure 3. AWS account-based silo isolation requires that the tenant infrastructure is deployed in each tenant account.

The pros of silo isolation, in addition to supporting challenging compliance models, include removing noisy neighbour concerns, reduced scope of impact of outages or events, and tenant cost tracking (see the AWS Well-Architected Framework SaaS Lens for more details).

The trade-offs of silo isolation are scaling issues, cost, agility, onboarding automation, and decentralized management and monitoring. You will need to add services/infrastructure to minimize these trade-offs (see the Managing the account lifecycle in account-per-tenant SaaS environments on AWS blog post for examples of agility and onboarding automation). The architecture shown in Figure 3 does address the cost trade-off. Silo isolation does not benefit from sharing infrastructure and maximizing infrastructure usage. Choosing serverless services (in this case Amazon API Gateway, AWS Lambda and AWS IoT Core) mitigates this trade-off. You pay only for usage with the services deployed in the tenant account, minimizing cost inefficiencies due to unused infrastructure.

Conclusion

In this post, you learned the benefits of using AWS account-based silo isolation for robots provided under RaaS, lease, or rent business models. This strategy is most appropriate for situations where the tenants are subject to challenging compliance or regulatory environments. Using an AWS account per tenant provides a compelling story for customers. The described solution offers centralized management for the robot vendor yet provides easy access to robot functionality for tenants.