AWS wellarchitected documentation change
Summary
Updated documentation navigation links, simplified phrasing, corrected technical references (AWS Private CA -> Amazon Root CA), standardized capitalization of services, and updated image references/descriptions
Security assessment
Changes focus on improving clarity and technical accuracy rather than addressing security vulnerabilities. The update from 'AWS Private CA' to 'Amazon Root CA' appears to correct a technical detail about certificate authorities but doesn't indicate resolution of a security flaw. Security recommendations about X.509 certificates remain present but unchanged in intent.
Diff
diff --git a/wellarchitected/latest/iot-lens/device-provisioning.md b/wellarchitected/latest/iot-lens/device-provisioning.md index cbe208427..61e55a54d 100644 --- a//wellarchitected/latest/iot-lens/device-provisioning.md +++ b//wellarchitected/latest/iot-lens/device-provisioning.md @@ -3 +3 @@ -[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](abstract-and-introduction.html) +[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](iot-lens.html) @@ -9 +9 @@ In IoT, device provisioning is composed of sequential steps. The most important -The first step to provisioning a device is to install an identity. The decisions you make in device design and manufacturing determines if the device has a production-ready firmware image, a unique client credential, or both by the time it reaches the customer. Your decisions determine whether there are additional provisioning-time steps that must be performed before a production device identity can be installed. +The first step to provisioning a device is to install an identity. The decisions you make in device design and manufacturing determines if the device has a production-ready firmware image and unique client credential by the time it reaches the customer. Your decisions determine whether there are additional provisioning-time steps that must be performed before a production device identity can be installed. @@ -11 +11 @@ The first step to provisioning a device is to install an identity. The decisions -Use X.509 client certificates for your IoT devices — they tend to be more secure and easier to manage at scale than static passwords. In AWS IoT Core, the device is registered using its certificate along with a unique thing identifier. The registered device is associated with an IoT policy. An IoT policy allows you to create fine-grained permissions per device. Fine-grained permissions ensure that only the device has permissions to interact with the right MQTT topics and messages. +Use X.509 client certificates for your IoT devices — they are more secure and easier to manage at scale than static passwords. In AWS IoT Core, the device is registered using its certificate along with a unique thing identifier. The registered device is associated with an IoT policy. An IoT policy allows you to create fine-grained permissions per device. Fine-grained permissions make sure that only the device has permissions to interact with the right MQTT topics and messages. @@ -13 +13 @@ Use X.509 client certificates for your IoT devices — they tend to be more secu -The registration process ensures that a device is recognized as an IoT asset and that the data it generates can be consumed through AWS IoT to other AWS services. One of the ways to provision a device, is through fleet provisioning. AWS IoT can generate and securely deliver device certificates and private keys to your devices when they connect to AWS IoT for the first time. AWS IoT provides client certificates that are signed by the AWS Private Certificate Authority (AWS Private CA). Fleet provisioning provides two ways to implement this: by trusted user or by claim. Let us look at the process flow for fleet provisioning by claim. +The registration process makes sure that a device is recognized as an IoT asset and that the data it generates can be consumed through AWS IoT to the rest of the AWS landscape. One of the ways to provision a device, is through Fleet Provisioning. AWS IoT can generate and securely deliver device certificates and private keys to your devices when they connect to AWS IoT for the first time. AWS IoT provides client certificates that are signed by the Amazon Root certificate authority (CA). Fleet Provisioning provides two ways to implement this: by trusted user or by claim. Let us look at the process flow for Fleet Provisioning by claim. @@ -17 +17 @@ Some devices do not have the capability to accept credentials over a secure tran -Device makers must load each device with a shared claim certificate in firmware. This claim certificate should be unique per batch of devices. The firmware containing the claim certificate is loaded by the contract manufacturer without the need to perform any customization. When the device establishes a connection with AWS IoT for the first time, it exchanges the claim certificate for a unique X.509 certificate signed by the AWS certificate authority and a private key. The device should send a unique token, such as a serial number or embedded hardware secret with its provisioning request that the fleet provisioning service can use to verify against an allow list. +Device makers must load each device with a shared claim certificate in firmware. This claim certificate should be unique per batch of devices. The firmware containing the claim certificate is loaded by the contract manufacturer without the need to perform customization. When the device establishes a connection with AWS IoT for the first time, it exchanges the claim certificate for a unique X.509 certificate signed by the AWS certificate authority and a private key. The device should send a unique token, such as a serial number or embedded hardware secret with its provisioning request that the fleet provisioning service can use to verify against an allow list. @@ -19 +19 @@ Device makers must load each device with a shared claim certificate in firmware. - + @@ -21 +21 @@ Device makers must load each device with a shared claim certificate in firmware. -_Figure 1: Registration Flow_ +_Registration flow_ @@ -23 +23 @@ _Figure 1: Registration Flow_ - 1. Device connects with claim certificate to AWS IoT Core. + 1. Device connects with claim certificate to AWS IoT Core @@ -25 +25 @@ _Figure 1: Registration Flow_ - 2. The fleet provisioning service creates a new certificate and private key assigned with AWS Private CA. + 2. Fleet Provisioning service creates new certificate and private key assigned with AWS CA. @@ -29 +29 @@ _Figure 1: Registration Flow_ - 4. With the parameters published from the device, the fleet provisioning service starts the pre-provisioning Lambda function. + 4. With the parameters published from the device, Fleet Provisioning service triggers Pre-Provisioning lambda function. @@ -31 +31 @@ _Figure 1: Registration Flow_ - 5. The Lambda function performs additional verification logic, such as checking the hardware secret against a DynamoDB table with verified devices. + 5. Lambda function performs additional verification logic such as checking the hardware secret against a DynamoDB table with verified devices. @@ -33 +33 @@ _Figure 1: Registration Flow_ - 6. The fleet provisioning service create IoT thing, policy, and activates certificate based on provisioning template and publishes this to the device. + 6. Fleet provisioning service create IoT Thing, Policy, and activates certificate based on Provisioning template and publishes this to the device. @@ -35 +35 @@ _Figure 1: Registration Flow_ - 7. Device applies the new configuration and connects with the unique private key, certificates, and configuration. + 7. Device applies the new configuration and connects with the unique private key, certificates and configuration.