3.1.1. Control the Identity and Access of the IoT Device¶

ID	Priority	Best Practice
BP 3.1.1.1	Required	Assign unique identities to each IoT device
BP 3.1.1.2	Highly Recommended	Highly Recommended

Architecture Notes - BP 3.1.1.1 - Assign Unique Identities¶

When a device connects to other devices or cloud services, it must establish trust by authenticating using principals such as X.509 certificates, security tokens, or other credentials. You can find available options from the IoT solution of your choice, and implement device registry and identity stores to associate devices, metadata and user permissions. The solution should enable each device (or Thing) to have a unique name (or ThingName) in the device registry, and it should ensure that each device has an associated unique identity principal, such as an X.509 certificate or security token. Identity principals, such as certificates, should not be shared between devices. When multiple devices use the same certificate, this might indicate that a device has been compromised. Its identity might have been cloned to further compromise the system.

Recommendation 3.1.1.1.1 - Use X.509 client certificates to authenticate over TLS 1.2 We recommend that each device be given a unique certificate to enable fine-grained management, including certificate revocation. Devices must support rotation and replacement of certificates to ensure continued operation as certificates expire. For example, AWS IoT Core supports AWS IoT-generated X.509 certificates or your own X.509 certificates for device authentication.

Recommendation 3.1.1.1.2 - Choose the appropriate certificate vending mechanisms for your use case We recommend using native provisioning mechanisms to onboard devices when they already have a device certificate (and associated private key) on them. For example, you can use just-in-time provisioning (JITP) or just-in-time registration (JITR) that provisions devices in bulk when they first connect to AWS IoT.

Recommendation 3.1.1.1.3 - Use security bearer tokens for authorizing to the IoT broker If the devices cannot use X509 certificates, or you have an existing fleet of devices with a proprietary access control mechanism, that requires use of bearer tokens such as OAuth over JWT or SAML tokens, use custom auth mechanisms. For example, when a device attempts to connect to AWS IoT, it sends a JWT generated by their identity provider in the HTTP header or query string. The signature is validated by AWS IoT custom authorizer and the connection is established.

Recommendation 3.1.1.1.5 - Use a consistent naming convention that maps your device identity to the MQTT topics It is important to use a standard set of naming conventions when designing device name and MQTT topics. For example, use the same client identifier for the device as the IoT Thing Name. This will also allow to include any relevant routing information for the device in the topic namespace.

Architecture Notes - BP 3.1.1.2 - Assign Least Privilege Access to Device¶

Permissions (or policies) allow an authenticated identity to perform various control and data plane operations against the IoT Broker, such as creating devices or certificates via the control plane, and connecting, publishing, or subscribing via the data plane.

See the following for more information:

Recommendation 3.1.1.2.1 - Grant least privileged access to reduce the scope of impact of the potential events We recommend using granular device permissions to enable least privileged access, which can help limit the impact of an error or misconfiguration. Define a mechanism so that devices can only communicate with specific authorized resources, such as MQTT topics. If permissions are generated dynamically, ensure that similar practices are followed. For example, create an AWS IoT policy as a JSON document that contains a statement with the following:

Effect, which specifies whether the action is allowed or denied.
Action, which specifies the action the policy is allowing or denying.
Resource, which specifies the resource or resources on which the action is allowed or denied.

Recommendation 3.1.1.2.2 - Consider scaling granular permissions across the IoT fleet We recommend reusing permissions across principals rather than hardcoding for better manageability as it helps you avoid create redundant permissions per device. For example, an AWS IoT policy allows access based on various thing attributes such as ThingName, ThingTypeName, Thing Attributes, etc. Thus, a device can connect with a client ID (such as foo), only if the device registry contains the matched device (aka ThingName), such as arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName} rather than, arn:aws:iot:us-east-1:123456789012:client/foo.

As another example, an AWS IoT policy also allows access based on various certificate attributes such as Subject, Issuer, Subject Alternate Name, Issuer Alternate Name and Others. Thus, a device can only publish to a topic that matches with the Certificate ID associated with the device in the registry like arn:aws:iot:us-east-1:123456789012:topic/${iot:CertificateId} Rather than arn:aws:iot:us-east-1:123456789012:topic/xxxxxxxxxx

3.1.1. Control the Identity and Access of the IoT Device¶

Architecture Notes - BP 3.1.1.1 - Assign Unique Identities¶

Architecture Notes - BP 3.1.1.2 - Assign Least Privilege Access to Device¶

Additional Resources¶