Best Practice 1.2 – Assign least privilege access to devices - IoT Lens Checklist

Best Practice 1.2 – Assign least privilege access to devices

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 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:

  1. Effect, which specifies whether the action is allowed or denied.

  2. Action, which specifies the action the policy is allowing or denying.

  3. Resource, which specifies the resource or resources on which the action is allowed or denied.

Recommendation 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/xxxxxxxxxxx