Grundlæggende om IoT-sikkerhed – del 5: Forbind sikkert til IoT cloud-tjenester

Redaktørens note: På trods af spredning af IoT-enheder forbliver sikring af disse enheder en løbende bekymring.Sikkerhedsudfordringer kan være en barriere for vedtagelse af tilsluttede enheder i IIOT (Industrial IoT) og mission kritiske applikationer, hvor virksomheds- og personlige data kan være kompromitteret i tilfælde af et vellykket hacker-angreb. At sikre IoT-applikationer kan være skræmmende. Men i virkeligheden kan IoT-enhedssikkerhed bygges på et par relativt enkle principper, der understøttes af hardware-sikkerhedsenheder. Ved at følge veletablerede sikkerhedspraksis kan disse bekymringer løses. Denne mulltidel serie giver praktisk vejledning til at hjælpe udviklere med at sikre, at bedste praksis følges fra starten. Del 1 diskuterer de kryptografiske algoritmer, der ligger til grundlag for sikre design. Del 2 diskuterer rollen som private nøgler, nøglestyring og sikker opbevaring i sikre IoT-design. Del 3 undersøger mekanismerne, der er indbygget i sikre processorer til at modstå andre typer trusler mod IoT-enheder. Del 4 identificerer og viser, hvordan man anvender sikkerhedsmekanismer i avancerede processorer for at hjælpe med at sikre den isolering, der er nødvendig for at mindske angreb på runtime-miljøet for IoT-enheder. Del 5 beskriver hvordan IoT-sikkerhed fortsætter fra IoT-enheder gennem sikkerhedsforanstaltninger på højere niveau, der bruges til at forbinde disse enheder til IoT cloud-ressourcer.

IoT-sikkerhed afhænger af flere beskyttelseslag, der strækker sig fra IoT-enhedens hardwaregrundlag gennem dets eksekveringsmiljø. Der er dog stadig trusler for enhver tilsluttet enhed hvor typiske krav til IoT-applikationer til en cloud-forbindelse kan efterlade både IoT-enhed og cloud-tjenester åbne for nye hacker-angreb. For at afbøde disse trusler bruger IoT cloud-udbydere specifikke sikkerhedsprotokoller og politikker, som, hvis de misbruges, kan efterlade IoT-applikationer sårbare. Ved hjælp af prækonfigurerede udviklingskort kan udviklere hurtigt få erfaring med de sikkerhedsmetoder, der bruges af førende IoT cloud-tjenester til at godkende forbindelser og godkende brug af IoT-enheder samt cloud-ressourcer.

Denne artikel beskriver forbindelseskravene til de to førende cloud-tjenester, Amazon Web Services (AWS) og Microsoft Azure. Artiklen beskriver hvordan udviklere kan bruge udviklingskit og tilknyttet software fra en række leverandører til hurtigt at oprette forbindelse til disse tjenester.

IoT-portalers rolle i cloud-tjenester

Når en IoT-enhed opretter forbindelse til en ressource såsom en cloud-tjeneste eller en remote-host, udsætter den sig selv, og ved at udvide hele IoT-netværket, for trusler, der er maskerede som legitime tjenester eller servere. Omvendt står cloud-tjenesten selv på lignende måde overfor truslen om angreb fra hackere, der efterligner IoT-enhedstransaktioner i et forsøg på at penetrere cloud-forsvar. For at sikre beskyttelsen af både IoT-enheder og cloud-ressourcer kræver cloud-tjenester brug af specifikke sikkerhedsprotokoller til gensidig autentificering af identitet til login og efterfølgende godkendelse for at sikre tilladt brug af tjenester. Disse protokoller er typisk inkluderet i et sæt tjenester, der leverer en sikker portal mellem IoT-enheder og cloud-ressourcer.

Som med andre tilgængelige IoT cloud-tjeneste platforme leverer AWS og Azure hver en specifik indgangsportal, som IoT-enheder skal bruge til at interagere med hver udbyders komplette sæt cloud-ressourcer, såsom virtuelle maskiner (VM'er) og SaaS-tjenester ( software-as-a-service) tilbud. Brug af et funktionelt lignende sæt af mekanismer og kapaciteter som Azure IoT Hub og AWS IoT leverer denne portal til deres respektive enterprise cloud-tilbud.

Som et minimum bruger disse og andre IoT-portaler specifikke godkendelsesprotokoller, implementeret gennem hver udbyders softwareudviklingskit (SDK) for at skabe en sikker forbindelse. For AWS forbindes IoT-enheder ved hjælp af gensidig godkendelse med en enheds-gateway. Enheds-gateways forbinder IoT-enheden med andre IoT-supporttjenester ved hjælp af oplysninger, der er lagret i et enhedsregister til at gemme en unik enhedsidentifikator. Denne gemmer sikkerhedsoplysninger og andre metadata, der er nødvendige for at administrere adgang til AWS-tjenester (figur 1). I Azure tjener identitetsregistret en lignende funktion.

Figur 1: Som med andre cloud-udbydere, giver AWS udviklere et sæt specialiserede tjenester designet til at forbedre sikkerhed og effektiviteten af transaktioner mellem IoT-enheder og enterprise cloud-tjenester. (Billedkilde: Amazon Web Services)

AWS IoT og Azure IoT leverer hver en tjeneste, der opretholder tilstandsinformation i en virtuel enhed, der er tilknyttet hver fysisk IoT-enhed. I AWS IoT giver enhedsskygger denne mulighed for AWS IoT, mens enhedskopier giver lignende muligheder for Azure IoT.

Denne opfattelse af en sikkerhedsportal udvides til IoT-edgetjenester såsom AWS Greengrass eller Azure IoT-Edge. Disse edge-tjenesteydelser bringer nogle cloud-tjenester og -funktioner ned til det lokale netværk, hvor edge-systemer er placeret fysisk tæt på IoT-enheder og systemer i storskala implementeringer. Udviklere kan bruge en service som Azure IoT Edge til at implementere forretningslogik i applikationer eller levere andre funktioner, der er nødvendige for at reducere responstid eller levere tjenester til lokale operatører, såsom inden for industriel automatisering (figur 2).

Figur 2: For at understøtte edge-computing tilbyder cloud-tjenesteudbydere specialiserede tjenester såsom Microsoft Azure IoT Edge, som bringer nogle Azure IoT cloud-tjenester tættere på de fysiske enheder, der er tilknyttet IoT-applikationen. (Billedkilde: Microsoft Azure)

Håndtering af krav til IoT-portalforbindelse

Uanset om der er forbindelse via et edge-system eller direkte med udbyderens IoT-tjeneste, skal IoT-enheder typisk tilfredsstille en række krav for at oprette forbindelse gennem udbyderens IoT-portal og bruge udbyderens cloud-tjenester. Selvom detaljerne er forskellige, er IoT-enheder nødt til at give mindst et element, f.eks. en privat nøgle, X.509-certifikat eller anden sikkerhedstoken. Nøglen, certifikatet eller tokenet giver IoT-portalen attestation eller bevis for IoT-enhedens identitet under godkendelsesfasen af enhedens cloud-forbindelsessekvensen. Derudover kræver IoT cloud-tjenester typisk en specifikation af de politikker, der bruges til at definere adgangsrettigheder til interaktion mellem IoT-enheder og cloud-tjenester.

Som med andre beregningskrav til en virksomhed, skal attestationsoplysninger til godkendelse og politisk information til adgangshåndtering, leveres ved hjælp af specifikke formater og procedurer, der er specificeret af førende IoT cloud-tjenester som AWS IoT og Azure IoT. Disse tjenester understøtter certifikatbaseret godkendelse som et minimum, men understøtter også brug af andre former for attestering. For eksempel kan udviklere bruge token-baserede godkendelsesmetoder, der er baseret på en JSON Web Token (JWT) til AWS IoT, eller en token til delt adgangssignatur (SAS) til Azure IoT.

Som nævnt tidligere bruger disse tjenester registre til at indeholde metadata for hver IoT-enhed. Sammen med sikkerhed og anden information gemmer disse registre de rettigheder til adgang, der skal defineres for at forbinde en IoT-enhed. Selvom de er specificeret på forskellige måder for forskellige cloud-tjenester, beskriver disse politikdefinitioner adgangsrettigheder for forskellige kommunikationskanaler og enheder. For eksempel ville en simpel AWS IoT-adgangsretlig politik bruge et JSON-format til at indikere, at en IoT-enhed med et bestemt "ting" -navn i AWS IoT-enhedsregistret kun kunne forbinde og offentliggøre meddelelser på en kanal med det samme tilknyttede navn ( Liste 1).

Kopi
{
    "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}"]
      }
    ]
}

Liste 1: Udviklere bruger et JSON-format til at beskrive AWS IoT-adgangsrettighedspolitikker til deres IoT-enheder. (Kode kilde: AWS)

Cloud-ready udvikling kits

Selvom cloud-udbydere tilbyder detaljerede specifikationer for disse formater og procedurer, er udbydernes support-fora typisk fyldt med spørgsmål fra udviklere, der udløses af nogle små, men vitale detaljer, der forhindrer godkendelse og adgangsstyring. Måske endnu værre, ud fra et sikkerhedsmæssigt synspunkt, kan utilsigtet misbrug af attestering eller ufuldstændig definition af adgangspolitikker efterlade IoT-enheder, netværk og applikationer åbne for hacker angreb. Tilgængeligheden af udviklingskortet off-the-shelf og ledsagende softwarepakker giver udviklere mulighed for hurtigt at navigere gennem disse forbindelsesprocedurer ved hjælp af leverandørleverede eksempler til hurtigt at oprette forbindelse til IoT-cloud'en. F.eks. Espressif Systems' ESP32-Azure IoT Kit eller Seeed technology's AZ3166 IoT udviklingskit inkluderer Azure-certificerede kort designet til let at oprette forbindelse til Microsoft cloud.

Microsoft leverer komplette step-by-step demonstrationer, herunder godkendelses- og adgangsoplysninger til de understøttede udviklingskit. Med AZ3166-kortet, skal udviklere f.eks. trykke på knapperne på kortet for at indlede forbindelse med deres lokale Wi-Fi-netværk. Når de er tilsluttet, kan de bruge Azure IoT Device Workbench indeholdt i Azure IoT Tools udvidelsespakke til Microsoft Visual Studio Code at udvikle, debugge og interagere med Azure IoT Hub. Ved hjælp af dette værktøjskit og dets pakker med eksempekode opretter udviklere et objekt til IoT-enheden i Azure IoT Hub og bruger en leveret fil til at tilvejebringe det tilknyttede identitetsregister med de legitimationsoplysninger og andre metadata, der kræves for at forbinde IoT-kortet til Azure IoT Hub (Figur 3).

Figur 3: Eksempelkode og legitimationsoplysninger, der leveres i Microsoft Azure IoT Device Workbench, hjælper udviklere med at gennemføre klargøring til tilslutning af Seeed Technology AZ3166 IoT Developer Kit til Azure IoT Hub. (Billedkilde: Microsoft Azure)

Azure IoT Device Workbench indeholder yderligere support-software og metadata, der lader udviklere hurtigt indlæse AZ3166-kortet med eksempelkode og begynde med at overføre målinger fra kortets temperatur- og fugtighedssensorer til Azure IoT Hub.

Trinene, der er involveret i oprettelse af en repræsentation for den fysiske IoT-enhed i IoT-cloud’en samt til tilvejebringelse af det tilknyttede registreringsdatabase, er kun nødvendige for at forbinde enheder med IoT-cloud’en. For at drage fordel af cloud-tjenester har Azure IoT Hub imidlertid brug for en adgangsrettighedspolitik. For at overvåge enheder-til-cloud meddelelser, der kommer fra AZ3166-sensoren, kan udviklere skærmbillede Azure-delt adgangspolitik til at vælge en prædefineret politik designet til hurtigt at aktivere de krævede adgangsrettigheder (figur 4).

Figur 4: Udviklere kan bruge prædefineret politikker til let at godkende brugen af Azure Clkoud Services med sensordata fra Seeed Technology AZ3166 IoT Developer Kit. (Billedkilde: Microsoft Azure)

Når de arbejder med AWS IoT, kan udviklere benytte udviklingskit som f.eks Microchip-teknologiAT88CKECC-AWS-XSTK-B Nul Touch Provisioning kit og tilhørende software til hurtigt at evaluere cloud-forbindelse. Denne opdaterede version af et tidligere Microchip Zero Touch Provisioning kit leveres med prædefinerede godkendelsesoplysninger. Ved hjælp af yderligere scripts, der følger med kittet, kan udviklere hurtigt forbinde kortet til AWS IoT uden at håndtere private nøgler og certifikater (se, "Brug zero-touch metoden til sikkert at låse en IoT-enhed").

Andre udviklingskit, inkl. Renesas'RTK5RX65N0S01000BE RX65N Cloud Kit og Infineon Technologies'KITXMC48IOTAWSWIFITOBO1 AWS IoT-kit, udvide understøttelse af AWS IoT-forbindelse med support til hurtig udvikling af applikationer baseret på Amazon FreeRTOS. AWS indeholder detaljerede instruktioner til registrering af kort, oprettelse af godkendelsesoplysninger og indlæsning af de forudsatte JSON-politikker, der er nødvendige for at oprette forbindelse til AWS IoT og bruge AWS-tjenester.

Forenkling af levering til store IoT-implementeringer

Udviklingskit som dem, der er beskrevet ovenfor, fungerer som effektive platforme både til hurtig prototyping af IoT-applikationer og til at undersøge krav til IoT cloud-forbindelser. I praksis er det imidlertid typisk nødvendigt, at udviklere benytter mere avancerede tilgange designet til at forenkle levering af IoT-enheder i applikationer i den virkelige verden. Både Azure IoT og AWS IoT understøtter en lang række metoder, der tillader mere automatiseret levering af individuelle enheder eller et stort antal IoT-enheder i en storstilet udrulning.

Med AWS IoT kan udviklere f.eks. bruge en bootstrap-metode til certifikatlevering. Her sendes smart-produkter med et bootstrap-certifikat tilknyttet de minimale adgangsrettigheder, der er nødvendige for at anmode om og få adgang til et nyt certifikat (figur 5).

Figur 5: AWS IoT understøtter en metode til bootstrap-certifikat levering i IoT-enheder. (Billedkilde: DigiKey, fra Amazon Web Services)

Ved hjælp af bootstrap-certifikatet opretter enheden forbindelse til cloud’en ("1" i figur 5), anmoder om ("2") et nyt certifikat, modtager ("3") URL'en til certifikatet, der er genereret af en AWS-serverløs Lambda-funktion og henter ("4") dette certifikat fra en AWS Simple Storage Services (S3) register. Ved hjælp af det nye certifikat logger enheden sig derefter tilbage på AWS IoT ("5") for at fortsætte med normale operationer.

AWS tilbyder andre cloud-tjenester, der understøtter dynamisk levering af godkendelsestokens ved hjælp af eksekveringsressourcer som AWS Lambda-funktioner. For eksempel kan en automobil-applikation stole på en række midlertidige forbindelser, hvor brug af et token er både mere praktisk og mere sikkert. Når et AWS-modul til IoT-godkendelse og autorisation godkender anmodningen om et token, genererer AWS Security Token Service (STS) her et token til levering til køretøjets systemer. Ved hjælp af dette token kan disse systemer få adgang til AWS-tjenester, der er underlagt validering af tjenesten AWS Identity and Access Management (IAM) (figur 6).

Figur 6: Førende leverandører af cloud-tjenester understøtter andre former for attestering til godkendelse, f.eks. denne proces til dynamisk generation af sikkerhedstokens med AWS Security Token Service (STS). (Billedkilde: Amazon Web Services)

AWS giver en lignende kapacitet til dynamisk tildeling af adgangsrettigheder. Her vil andre AWS Lambda-funktioner tildele et sæt af politikker, der er knyttet til et gyldigt token (figur 7).

Figur 7: Udviklere kan bruge cloud-tjenester til at implementere dynamisk tildeling af adgangsrettigheder, hvilket er især nyttigt til applikationer med midlertidige forbindelser eller kortvarige operationer. (Billedkilde: Amazon Web Services)

Andre IoT cloud-tjenester giver udviklere mulighed for mere effektivt at håndtere levering i store udrulninger. For eksempel leverer AWS IoT levere kapacitet til levering, herunder support til en større udrulning af den type bootstrap-metode, der er beskrevet tidligere. Azure IoT's Device Provisioning Service leverer en gruppe tilmelding mulighed, der understøtter levering af stort antal IoT-enheder, der deler det samme X.509-certifikat eller SAS-token.

Delt ansvar for sikkerhed

IoT cloud-udbydere leverer en række effektive metoder til forbedring af end-to-end sikkerhed for IoT-applikationer. Ikke desto mindre kan IoT-udviklere ikke forvente, at disse metoder kan bære den fulde ansvar for sikkerhedskrav til deres særlige IoT-applikation. Faktisk skitserer udbydere af cloud-tjenester omhyggeligt deres specifikke rolle og ansvar inden for IoT-applikationssikkerhed med specifikke modeller såsom AWS' model for delt ansvar (figur 8).

Figur 8: Som med andre førende cloud-udbydere, beskriver AWS det ansvar, det deler med cloud-brugere for at beskytte cloud-infrastrukturen på den ene side og kundeprogrammer på den anden. (Billedkilde: Amazon Web Services)

AWS og Microsoft Azure leverer hver delte ansvarsdokumenter, der beskriver og forklarer udbyderens egen rolle og kundens rolle i sikring af ressourcer, data og applikationer. I sin dokumentation tilbyder Microsoft også et overblik over nogle af forholdene mellem delt sikkerhed og krav til overholdelse. I sidste ende bærer cloud-udbydere ansvaret for cloud’ens sikkerhed, mens kunder forbliver ansvarlige for applikationer, data og ressourcer, der bruges i cloud’en.

Konklusion

IoT-applikationer afhænger af lag af sikkerhed, der er opbygget fra hardwarebaserede mekanismer til kryptografi og sikker nøglelager. Som med ethvert tilsluttet produkt kan sikkerhedstrusler ankomme i alle mulige interaktioner, når IoT-enheder opretter forbindelse til cloud-tjenester. For at beskytte sig selv og deres kunder dikterer IoT cloud-udbydere specifikke krav til godkendelse og styring af adgangsrettigheder. Selvom udbydere tilbyder detaljeret dokumentation af disse krav og tilhørende specifikationer, kan udviklere finde ud af, at deres bestræbelser på at implementere sikker forbindelse til tider giver ressourcer eksponeret eller omvendt utilgængelige. Ved hjælp af udviklingskort og tilhørende software kan udviklere hurtigt oprette forbindelse til cloud-tjenester og hurtigt prototyping af IoT-applikationer med end-to-end sikkerhed.