IoT-beveiligingsbeginselen - deel 5: veilig verbinding maken met IoT-clouddiensten

Noot van de redactie: Ondanks de proliferatie van IoT-apparaten blijft de beveiliging van deze apparaten een voortdurende zorg, in die mate zelfs dat beveiligingsproblemen een belemmering kunnen vormen voor de adoptie van aangesloten apparaten in industriële IoT (IIoT) en missiekritische toepassingen waar bedrijfs- en persoonlijke gegevens in gevaar kunnen worden gebracht in het geval van een succesvolle aanval. Het beveiligen van ivd-toepassingen kan ontmoedigend zijn, maar in werkelijkheid kan de beveiliging van ivd-apparaten worden gebaseerd op een paar relatief eenvoudige beginselen die worden ondersteund door hardwarebeveiligingsapparaten. Door gevestigde beveiligingspraktijken te volgen, kunnen deze problemen worden aangepakt. Deze meerdelige serie biedt praktische begeleiding om ontwikkelaars te helpen ervoor te zorgen dat vanaf het begin de beste praktijken worden gevolgd. Deel 1 bespreekt de cryptografische algoritmen die aan veilige ontwerpen ten grondslag liggen. Deel 2 bespreekt de rol van private sleutels, sleutelbeheer, en veilige opslag in veilige IoT-ontwerpen. In deel 3 wordt ingegaan op de mechanismen die zijn ingebouwd in veilige processoren om andere soorten bedreigingen voor ivd-apparaten te beperken. Deel 4 identificeert en toont hoe beveiligingsmechanismen in geavanceerde processoren kunnen worden toegepast om de isolatie te helpen waarborgen die nodig is om aanvallen op de runtime-omgeving van ivd-apparaten te beperken. In deel 5 wordt beschreven hoe de beveiliging van het ivd zich uitstrekt van ivd-apparaten tot beveiligingsmaatregelen op hoger niveau die worden gebruikt om die apparaten te verbinden met ivd-cloudbronnen

De beveiliging van het internet van dingen (ivd) is afhankelijk van meerdere beschermingslagen die zich uitstrekken van de hardwarebasis van het ivd-apparaat tot de uitvoeringsomgeving. Er blijven echter bedreigingen bestaan voor elk aangesloten apparaat, en typische IoT-toepassingseisen voor cloudconnectiviteit kunnen zowel het IoT-apparaat als de clouddiensten openstellen voor nieuwe aanvallen. Om deze bedreigingen te beperken, gebruiken ivd-cloudproviders specifieke beveiligingsprotocollen en -beleidslijnen die, indien misbruikt, ivd-toepassingen kwetsbaar kunnen maken. Met behulp van voorgeconfigureerde ontwikkelboards kunnen ontwikkelaars snel ervaring opdoen met de beveiligingsmethoden die door toonaangevende IoT-clouddiensten worden gebruikt om verbindingen te verifiëren en het gebruik van IoT-apparaten en cloudresources te autoriseren.

Dit artikel beschrijft de verbindingsvereisten van twee toonaangevende clouddiensten, Amazon Web Services (AWS) en Microsoft Azure, en laat zien hoe ontwikkelaars ontwikkelkits en bijbehorende software van verschillende verkopers kunnen gebruiken om snel verbinding te maken met deze diensten.

De rol van ivd-portalen in clouddiensten

Wanneer een ivd-apparaat verbinding maakt met een bron zoals een cloudservice of host op afstand, kan het zichzelf - en daarmee het hele ivd-netwerk - blootstellen aan bedreigingen die zich voordoen als legitieme diensten of servers. Omgekeerd wordt de clouddienst zelf ook bedreigd door aanvallen van hackers die transacties van ivd-apparaten nabootsen in een poging door de cloudverdediging heen te dringen. Om de bescherming van zowel ivd-apparaten als cloudbronnen te helpen waarborgen, vereisen clouddiensten het gebruik van specifieke beveiligingsprotocollen voor wederzijdse authenticatie van identiteit voor aanmelding en daaropvolgende autorisatie om toegestaan gebruik van diensten te waarborgen. Deze protocollen zijn doorgaans opgenomen in een reeks diensten die een veilig portaal bieden tussen ivd-apparaten en cloudbronnen.

Net als andere beschikbare platforms voor IoT-cloudservices bieden AWS en Azure elk een specifiek toegangsportaal dat IoT-apparaten moeten gebruiken om te kunnen communiceren met de volledige set cloudresources van elke provider, zoals virtuele machines (VM's) en software-as-a-service (SaaS) aanbiedingen. Met behulp van een functioneel vergelijkbare reeks mechanismen en mogelijkheden, bieden Azure IoT Hub en AWS IoT dit portaal voor hun respectieve enterprise cloud-aanbiedingen.

Deze en andere ivd-portalen maken minimaal gebruik van specifieke authenticatieprotocollen die worden geïmplementeerd via de software development kit (SDK) van elke aanbieder om een veilige verbinding tot stand te brengen. Voor AWS maken ivd-apparaten verbinding via wederzijdse authenticatie met een apparaatgateway. De device gateway verbindt het IoT-apparaat met andere IoT-ondersteunende diensten, waarbij gebruik wordt gemaakt van informatie in een apparaatregister om een unieke apparaatidentificatie, beveiligingsreferenties en andere metadata op te slaan die nodig zijn om de toegang tot AWS-diensten te beheren (figuur 1). In Azure heeft het identiteitsregister een soortgelijke functie.

Figuur 1: Net als andere cloudproviders biedt AWS ontwikkelaars een reeks gespecialiseerde diensten die zijn ontworpen om de veiligheid en effectiviteit van transacties tussen IoT-apparaten en enterprise clouddiensten te verbeteren. (Bron afbeelding: Amazon Web Services)

AWS IoT en Azure IoT bieden elk een dienst die statusinformatie bijhoudt in een virtueel apparaat dat is gekoppeld aan elk fysiek IoT-apparaat. In AWS IoT bieden device shadows deze mogelijkheid voor AWS IoT, terwijl device twins soortgelijke mogelijkheden bieden voor Azure IoT.

Deze notie van een beveiligingsportaal strekt zich uit tot IoT edge-diensten zoals AWS Greengrass of Azure IoT Edge. Deze edge-diensten brengen bepaalde clouddiensten en -capaciteiten naar het lokale netwerk, waar edge-systemen fysiek dicht bij IoT-apparaten en -systemen worden geplaatst in grootschalige implementaties. Ontwikkelaars kunnen een dienst zoals Azure IoT Edge gebruiken om de bedrijfslogica van applicaties te implementeren of andere functionele mogelijkheden te bieden die nodig zijn om latentie te verminderen of diensten te leveren aan lokale operators, zoals in industriële automatisering (figuur 2).

Figuur 2: Om edge computing te ondersteunen, bieden cloud service providers gespecialiseerde diensten aan, zoals Microsoft Azure IoT Edge, die bepaalde Azure IoT-clouddiensten dichter bij de fysieke apparaten brengt die bij de IoT-toepassing horen. (Afbeelding bron: Microsoft Azure)

Omgaan met eisen voor IoT-portaalconnectiviteit

Of de verbinding nu tot stand wordt gebracht via een edge-systeem of rechtstreeks met de IoT-dienst van de aanbieder, IoT-apparaten moeten doorgaans aan een aantal eisen voldoen om via het IoT-portaal van de aanbieder verbinding te kunnen maken en gebruik te kunnen maken van de clouddiensten van de aanbieder. Hoewel de details verschillen, moet ivd-apparatuur ten minste een item zoals een privésleutel, een X.509-certificaat of een ander beveiligingstoken bevatten. De sleutel, het certificaat of het token levert het ivd-portaal een attest of bewijs van de identiteit van het ivd-apparaat tijdens de verificatiefase van de sequentie van de verbinding tussen het apparaat en de cloud. Bovendien vereisen IoT-clouddiensten doorgaans een specificatie van het beleid dat wordt gebruikt om toegangsrechten te definiëren voor interacties tussen IoT-apparaten en clouddiensten.

Net als bij andere vereisten voor enterprise computing moeten attestinformatie voor authenticatie en beleidsinformatie voor toegangsbeheer worden verstrekt aan de hand van specifieke formaten en procedures die worden gespecificeerd door toonaangevende IoT-clouddiensten zoals AWS IoT en Azure IoT. Deze diensten ondersteunen ten minste authenticatie op basis van certificaten, maar ook het gebruik van andere vormen van attestatie. Ontwikkelaars kunnen bijvoorbeeld token-gebaseerde authenticatiemethoden gebruiken op basis van een JSON Web Token (JWT) voor AWS IoT, of een shared access signature (SAS) token voor Azure IoT.

Zoals eerder vermeld, gebruiken deze diensten registers om metadata voor elk IoT-apparaat bij te houden. Samen met beveiligings- en andere informatie slaan deze registers het toegangsrechtenbeleid op dat moet worden gedefinieerd om een ivd-apparaat aan te sluiten. Hoewel op verschillende manieren gespecificeerd voor verschillende clouddiensten, beschrijven deze beleidsdefinities toegangsrechten voor verschillende communicatiekanalen en entiteiten. Een eenvoudig AWS IoT-toegangsrechtenbeleid zou bijvoorbeeld een JSON-indeling gebruiken om aan te geven dat een IoT-apparaat met een bepaalde "ding"-naam in het AWS IoT-apparaatregister alleen verbinding mag maken en berichten mag publiceren op een kanaal met dezelfde geassocieerde dingnaam (Listing 1).

Kopieer
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}

Listing 1: Ontwikkelaars gebruiken een JSON-indeling om het AWS IoT-toegangsrechtenbeleid voor hun IoT-apparaten te beschrijven. (Bron code: AWS)

Cloud-ready ontwikkelingskits

Hoewel cloudaanbieders gedetailleerde specificaties van deze formaten en procedures bieden, worden de ondersteuningsforums van de aanbieders doorgaans gevuld met vragen van ontwikkelaars die struikelen over een klein maar essentieel detail dat authenticatie en toegangsbeheer verhindert. Vanuit beveiligingsoogpunt is het misschien nog erger dat onbedoeld misbruik van attestering of onvolledige definitie van toegangsbeleid ivd-apparaten, netwerken en toepassingen open kunnen laten voor aanvallen. Dankzij de beschikbaarheid van kant-en-klare ontwikkelborden en bijbehorende softwarepakketten kunnen ontwikkelaars snel door deze verbindingsprocedures navigeren, met behulp van door de leverancier verstrekte voorbeelden om snel verbinding te maken met ivd-clouds. De ESP32-Azure IoT Kit van Espressif Systems of de AZ3166 IoT Developer Kit van Seeed Technology bevatten bijvoorbeeld Azure-gecertificeerde kaarten die ontworpen zijn om gemakkelijk verbinding te maken met de Microsoft-cloud.

Microsoft biedt complete stap-voor-stap demonstraties, inclusief authenticatie en toegangscredentials voor de ondersteunde ontwikkelkits. Met het AZ3166 bord bijvoorbeeld, drukken ontwikkelaars op knoppen op het bord om een verbinding met hun lokale Wi-Fi netwerk tot stand te brengen. Zodra ze zijn aangesloten, kunnen ze de Azure IoT Device Workbench gebruiken die deel uitmaakt van het Azure IoT Tools-uitbreidingspakket voor Microsoft Visual Studio Code om te ontwikkelen, debuggen en communiceren met de Azure IoT Hub. Met behulp van deze toolset en de voorbeeldcodepakketten maken ontwikkelaars een object voor het IoT-apparaat in Azure IoT Hub en gebruiken ze een meegeleverd bestand om het bijbehorende identiteitsregister te voorzien van de referenties en andere metadata die nodig zijn om het IoT-board te verbinden met Azure IoT Hub (figuur 3).

Figuur 3: Voorbeeldcode en referenties die in de Microsoft Azure IoT Device Workbench worden verstrekt, helpen ontwikkelaars bij het voltooien van de provisioning voor het aansluiten van de Seeed Technology AZ3166 IoT Developer Kit op Azure IoT Hub. (Afbeelding bron: Microsoft Azure)

De Azure IoT Device Workbench biedt extra ondersteunende software en metadata waarmee ontwikkelaars snel het AZ3166 bord kunnen laden met voorbeeldcode en beginnen met het verzenden van metingen van de temperatuur- en vochtigheidssensor van het bord naar Azure IoT Hub.

De stappen die nodig zijn om een voorstelling te maken van het fysieke IoT-apparaat in de IoT-cloud en om het bijbehorende register te provisioneren, zijn alleen al nodig om apparaten te verbinden met de IoT-cloud. Om te kunnen profiteren van clouddiensten heeft de Azure IoT Hub echter een toegangsrechtenbeleid nodig. Om de device-to-cloud berichten afkomstig van de AZ3166 sensor te monitoren, kunnen ontwikkelaars eenvoudig gebruik maken van het Azure gedeelde toegangsbeleid scherm om een vooraf ingesteld beleid te selecteren dat ontworpen is om snel de vereiste toegangsrechten in te stellen (figuur 4).

Figuur 4: Ontwikkelaars kunnen vooraf opgestelde beleidsregels gebruiken om eenvoudig het gebruik van Azure clouddiensten te autoriseren met sensorgegevens van de Seeed Technology AZ3166 IoT Developer Kit. (Afbeelding bron: Microsoft Azure)

Bij het werken met AWS IoT kunnen ontwikkelaars een beroep doen op ontwikkelingskits zoals de AT88CKECC-AWS-XSTK-B Zero Touch Provisioning kit en bijbehorende software van Microchip Technology om snel de cloudconnectiviteit te evalueren. Deze bijgewerkte versie van een eerdere Microchip Zero Touch Provisioning-kit wordt vooraf geladen met authenticatiereferenties. Met behulp van aanvullende scripts die bij de kit zijn geleverd, kunnen ontwikkelaars het bord snel verbinden met AWS IoT zonder zich bezig te hoeven houden met private sleutels en certificaten (zie"Neem de Zero-Touch Approach om een IoT-apparaat veilig af te sluiten").

Andere ontwikkelkits, waaronder de RTK5RX65N0S01000BE RX65N Cloud Kit van Renesas en de KITXMC48IOTAWSWIFITOBO1 AWS IoT kit van Infineon Technologies, breiden de ondersteuning voor AWS IoT-connectiviteit uit met ondersteuning voor snelle ontwikkeling van applicaties op basis van Amazon FreeRTOS. AWS geeft gedetailleerde aanwijzingen voor het registreren van de borden, het creëren van authenticatie credentials, en het laden van meegeleverde JSON policies die nodig zijn om verbinding te maken met AWS IoT en AWS services te gebruiken.

Vereenvoudiging van provisioning voor grootschalige IoT-implementaties

Ontwikkelingskits zoals die welke hierboven zijn beschreven, dienen als effectieve platforms voor zowel het snel maken van prototypes van IoT-toepassingen als voor het onderzoeken van de vereisten voor IoT-clouddienstverbindingen. In de praktijk zullen ontwikkelaars echter meestal een beroep moeten doen op meer geavanceerde benaderingen die zijn ontworpen om de levering van ivd-apparaten in reële toepassingen te vereenvoudigen. Zowel Azure IoT als AWS IoT ondersteunen een breed scala aan methoden die een meer geautomatiseerde provisioning van individuele apparaten of grote aantallen IoT-apparaten in een grootschalige inzet mogelijk maken.

Met AWS IoT, bijvoorbeeld, kunnen ontwikkelaars een bootstrap-methode gebruiken voor certificaat provisioning. In dit geval wordt het slimme product geleverd met een bootstrapcertificaat dat is gekoppeld aan de minimale toegangsrechten die nodig zijn om een nieuw certificaat aan te vragen en te openen (figuur 5).

Figuur 5: AWS IoT ondersteunt een methode voor bootstrap certificate provisioning in IoT-apparaten. (Afbeelding bron: DigiKey, van Amazon Web Services)

Met behulp van het bootstrap-certificaat maakt het apparaat verbinding met de cloud ("1" in afbeelding 5), vraagt ("2") om een nieuw certificaat, ontvangt ("3") de URL van het certificaat dat is gegenereerd door een AWS serverloze Lambda-functie, en haalt ("4") dat certificaat op uit een AWS Simple Storage Services (S3)-emmer. Met dat nieuwe certificaat logt het apparaat vervolgens weer in op AWS IoT ("5") om verder te gaan met de normale werkzaamheden.

AWS biedt andere clouddiensten die dynamische provisioning van authenticatietokens ondersteunen met behulp van uitvoeringsbronnen zoals AWS Lambda-functies. Een automobieltoepassing kan bijvoorbeeld afhankelijk zijn van een reeks kortstondige verbindingen waarbij het gebruik van een token zowel praktischer als veiliger is. Nadat een AWS-module voor IoT-authenticatie en -autorisatie het verzoek om een token heeft goedgekeurd, genereert de AWS Security Token Service (STS) een token voor levering aan de systemen van het voertuig. Met dat token kunnen die systemen toegang krijgen tot AWS-diensten, afhankelijk van validatie door de AWS Identity and Access Management (IAM)-dienst (afbeelding 6).

Figuur 6: Toonaangevende aanbieders van clouddiensten ondersteunen andere vormen van attestering voor authenticatie, zoals dit proces voor het dynamisch genereren van beveiligingstokens door AWS Security Token Service (STS). (Bron afbeelding: Amazon Web Services)

AWS biedt een soortgelijke mogelijkheid voor dynamische toewijzing van toegangsrechten. Hier zouden andere AWS Lambda-functies een set beleidsregels toewijzen die bij een geldig token horen (figuur 7).

Figuur 7: Ontwikkelaars kunnen clouddiensten gebruiken om dynamische toewijzing van toegangsrechten te implementeren, wat vooral nuttig is voor toepassingen met kortstondige verbindingen of kortstondige bewerkingen. (Bron afbeelding: Amazon Web Services)

Andere IoT-clouddiensten stellen ontwikkelaars in staat efficiënter om te gaan met provisioning bij grootschalige implementaties. AWS IoT biedt bijvoorbeeld mogelijkheden voor fleet provisioning, inclusief ondersteuning voor een grootschaliger inzet van het soort bootstrap-methode dat eerder is beschreven. Azure IoT's Device Provisioning Service biedt een groep enrollment mogelijkheid die provisioning van grote aantallen IoT apparaten ondersteunt die hetzelfde X.509 certificaat of SAS token delen.

Gedeelde verantwoordelijkheid voor veiligheid

IoT-cloudproviders bieden een aantal effectieve methoden om de end-to-end beveiliging van IoT-toepassingen te verbeteren. Toch kunnen ivd-ontwikkelaars niet verwachten dat die methoden het volle gewicht van de beveiligingseisen voor hun specifieke ivd-toepassing kunnen dragen. In feite schetsen cloud service providers zorgvuldig hun specifieke rol en verantwoordelijkheden bij de beveiliging van IoT-toepassingen met specifieke modellen, zoals het gedeelde verantwoordelijkheidsmodel van AWS (figuur 8).

Figuur 8: Net als andere toonaangevende cloudaanbieders beschrijft AWS de verantwoordelijkheden die het deelt met cloudgebruikers om enerzijds de cloudinfrastructuur en anderzijds de toepassingen van klanten te beschermen. (Bron afbeelding: Amazon Web Services)

AWS en Microsoft Azure bieden elk documenten over gedeelde verantwoordelijkheden waarin de eigen rol van de provider en die van de klant bij de beveiliging van middelen, gegevens en toepassingen wordt beschreven en toegelicht. Microsoft geeft in zijn documentatie ook een overzicht van enkele verbanden tussen gedeelde beveiliging en compliance-vereisten. Uiteindelijk blijven cloud providers verantwoordelijk voor de veiligheid van de cloud, terwijl afnemers verantwoordelijk blijven voor toepassingen, gegevens en middelen die in de cloud worden gebruikt.

Conclusie

IoT-toepassingen zijn afhankelijk van beveiligingslagen die zijn opgebouwd uit hardwarematige mechanismen voor cryptografie en veilige sleutelopslag. Zoals bij elk verbonden product kunnen veiligheidsrisico's zich voordoen in allerlei interacties wanneer ivd-apparaten verbinding maken met clouddiensten. Om zichzelf en hun klanten te beschermen, stellen IoT-cloudproviders specifieke eisen aan authenticatie en toegangsrechtenbeheer. Hoewel providers gedetailleerde documentatie over deze vereisten en bijbehorende specificaties aanbieden, kunnen ontwikkelaars ondervinden dat hun inspanningen om veilige connectiviteit te implementeren er soms toe leiden dat bronnen bloot komen te liggen, of juist ontoegankelijk worden. Met behulp van ontwikkelkaarten en bijbehorende software kunnen ontwikkelaars snel verbinding maken met cloud-diensten en snel prototypes maken van IoT-toepassingen met end-to-end beveiliging.