Hi, I'm Steve Krems. Welcome to 'Back to Basics'.
Today we're going to discuss IoT,
specifically how to secure communications, ingest data
and take actions on the data based on your desired business outcomes.
I've designed architectures in the past
where securing individual data streams was not a high priority.
That would not be considered best practice in today's internet-connected world.
I'm going to show you how to build policies that scale and are secure.
You're going to see how identity and authorization
are the foundation for designing your architecture
while keeping your device telemetry data and command and control messaging
restricted to only devices, services, applications
or identities that you have authorized.
We will look at how you could scale this to support
a large number of devices, customers and work streams.
MQTT is a publish-subscribe lightweight network protocol.
MQTT topic structure represents a hierarchy of information separated by the forward slash.
You need to consider what should be publishing to those topics
and what should be subscribing to those topics.
How do you create an authorization policy to allow for meaningful topic design
while adhering to best practices and the principles of least privilege?
Let's start by looking at a device.
Each device should have a unique name that will be used as the MQTT client ID.
Each device should have a unique identity attached,
such as the x.509 certificate that is registered in IoT Core registry.
And finally, we need to attach an IoT policy
that has been appropriately scoped down to grant access
to only what is required to perform the desired functions.
To say this another way, the credentials authenticate the identity,
the IoT policy document then authorizes what that identity can access.
By defining the ThingName variable
as part of the "iot:Connect" resource in the policy document,
only the device presenting the client ID
and credentials matching those registered IoT Core
will be able to connect as that client ID.
When creating policy documents,
you should also be thinking about the MQTT topic design and hierarchy.
If a device is sending temperature, CO2 and humidity levels
for a particular greenhouse that might publish to data, air sample, greenhouse three.
Part of this policy document that would allow this action is displayed here.
Let's consider an application that subscribes to this topic
so it can display this information on a dashboard.
The IoT policy for the application would include authorization to subscribe to that same topic.
If you would deploy these sensors to multiple farms of multiple greenhouses,
how would you design the IoT policy to do this?
How about multiple customers?
You will not want to create a unique policy for each device,
and we should not create an overly permissive policy
allowing publishing or subscribing to any topic.
Here we show multiple devices publishing telemetry data to the same end point,
but on separate topics.
We need to ensure that 'customer one'
can only publish and subscribe to topics authorized by 'customer one'
and the same for all other customers.
You'll notice there is a wild card at the end of the resource.
This allows you to publish on the secured topic
with a scoped and secure topic structure,
but flexibility to publish on separate subtopics as needed.
You may want to publish air sample data to 'airsample'
soil acidity to 'soilPH' and so on, each to a separate subtopic.
The IoT policy shown would allow this.
By utilizing IoT policy variables,
we can use the same policy for devices
that will be performing similar functions.
By replacing the Customer ID, Farm ID and Greenhouse ID for policy variables,
we can use the same IoT policy for all of these devices
while still appropriately restricted to the topics as designed.
The policy variables are attributes that are stored in the IoT Core registry.
By creating separate top level topic identifiers,
you can separate command and control messaging
from telemetry and ingest path.
You could create the IoT policies the same way for customer mobile applications,
but again using policy variables to restrict the identities to their own devices
by 'customerID', 'farmID', or 'deviceID'.
Shown here is an example of authenticated users from 'customer40'
that are authorized to publish to a topic that the device is subscribed to
but restricted to only 'customer40'.
What actions do you want to take on the data being published by your devices?
AWS IoT rules allow your devices to interact with AWS services.
Rules are analyzed based on the MQTT topic
and one or more actions can be configured to run.
We talked about lower level subtopic identifiers previously,
so you can create separate work streams or actions based on these subtopics.
UV data is published to a separate UV sub topic.
Data published here could trigger a couple of actions,
publish the metrics to AWS Timestream
and run a Lambda function to determine if shutters should be activated
to increase or decrease light in the greenhouses.
These actions would only trigger rule match
when data is published to the UV sub topic.
Telemetry data being published on the soil acidity topic
may have a completely different workflow,
so the rule will only match when data is published to that topic.
This will help to optimize costs by only evaluating rules
when relevant data is published.
It is important to note that multiple rules can subscribe to the same topics.
In this example, the device is publishing air quality, soil and UV information.
One rule has a wildcard and will match on all data written to these topics.
This data has been passed by the rule to AWS IoT Analytics.
The same message is matching the rule that has subscribed to the 'soilPH' subtopic
and will trigger the actions defined by that rule.
One anti-pattern to avoid is creating a rule that matches many topics
that may not contain relevant data.
This will cause a rule match with no action taken.
Today we explored IoT Core variables
and how to use them to build secure policies at scale.
Please check the links below for more details and resources.
Thanks for joining me today on 'Back to Basics'.
See you next time.