Grunnleggende for IoT-sikkerhet – del 5: Koble sikkert til IoT-skytjenester

Redaktørens merknad: Til tross for utbredelsen av IoT-enheter, er sikring av disse enhetene fortsatt en pågående bekymring, i den grad sikkerhetsutfordringer kan være en barriere for adopsjon av tilkoblede enheter i industriell IoT (IIoT) og oppdragskritiske applikasjoner der bedrifts- og personopplysninger kan være utsatt, i tilfelle et vellykket angrep. Å sikre IoT-applikasjoner kan være skremmende, men i virkeligheten kan sikkerhet for IoT-enheter bygges på noen få enkle prinsipper som støttes av sikkerhetsenheter for maskinvare. Ved å følge veletablert sikkerhetspraksis, kan disse bekymringene løses. Denne serien bestående av flere deler gir praktisk veiledning for å hjelpe utviklere med å sikre at beste praksis følges fra begynnelsen. Del 1 diskuterer kryptografiske algoritmer som ligger til grunn for sikre design. Del 2 diskuterer rollen som private nøkler, nøkkelhåndtering og sikker lagring i sikre IoT-design. Del 3 undersøker mekanismene som er innebygd i sikre prosessorer for å dempe andre typer trusler mot IoT-enheter. Del 4 identifiserer og viser hvordan man bruker sikkerhetsmekanismer i avanserte prosessorer for å sikre isolasjonen som er nødvendig for å dempe angrep på runtime-miljøet til IoT-enheter. Her beskriver del 5 hvordan IoT-sikkerhet fortsetter fra IoT-enheter gjennom sikkerhetstiltak på høyere nivå som brukes for å koble disse enhetene til IoT-skyressurser.

Sikkerhet for tingenes internett (IoT) avhenger av flere lag av beskyttelse, som strekker seg fra IoT-enhetens maskinvaregrunnlag gjennom utførelsesmiljøet. Trusler gjenstår imidlertid for alle tilkoblede enheter, typiske krav til IoT-applikasjoner for nettskytekonnektivitet kan åpne både IoT-enheter og skytjenester for nye angrep. For å dempe disse truslene, bruker IoT-skyleverandører spesifikke sikkerhetsprotokoller og retningslinjer som, hvis de blir misbrukt, kan gjøre IoT-applikasjoner sårbare. Ved å bruke forhåndskonfigurerte utviklingskort, kan utviklere raskt få erfaring med sikkerhetsmetodene som brukes av ledende IoT-skytjenester, for å autentisere tilkoblinger og godkjenne bruk av IoT-enheter og skyressurser.

Denne artikkelen beskriver tilkoblingskravene til to ledende skytjenester, Amazon Web Services (AWS) og Microsoft Azure, og viser hvordan utviklere kan bruke utviklingssett og tilhørende programvare fra en rekke leverandører, for å raskt få kontakt med disse tjenestene.

Rollen til IoT-portaler i skytjenester

Når en IoT-enhet kobles til en ressurs som en skytjeneste eller ekstern vert, utsetter den seg potensielt – og ved utvidelse av hele IoT-nettverket – for trusler som er maskerte som legitime tjenester eller servere. I motsatt fall, møter skytjenesten selv samme trusselen om angrep fra hackere som etterligner IoT-enhetstransaksjoner, i et forsøk på å penetrere skyforsvar. For å sikre beskyttelse for både IoT-enheter og skyressurser, krever skytjenester bruk av spesifikke sikkerhetsprotokoller for gjensidig autentisering av påloggingsidentitet, samt påfølgende autorisasjon for å sikre tillatt bruk av tjenester. Disse protokollene er vanligvis inkludert i et sett med tjenester som gir en sikker portal mellom IoT-enheter og skyressurser.

Som med andre tilgjengelige IoT-skytjenesteplattformer, gir AWS og Azure hver en spesifikk inngangsportal som IoT-enheter trenger å bruke for å samhandle med hver leverandørs komplette sett alternativer av skyressurser, som virtuelle maskiner (VM-er) og programvare-som-en-tjeneste (SaaS). Ved å bruke et funksjonelt sett lignende mekanismer og muligheter, tilbyr Azure IoT Hub og AWS IoT denne portalen til sitt respektive Enterprise Cloud-tilbud.

I det minste bruker disse og andre IoT-portaler spesifikke autentiseringsprotokoller, implementert gjennom hver leverandørs programvareutviklingssett (SDK) for å opprette en sikker tilkobling. For AWS tilkobles IoT-enheter ved hjelp av gjensidig autentisering via en enhetsport (device gateway). Enhetsporten kobler IoT-enheten til andre IoT-støttetjenester, samt bruker informasjon som er lagret i et enhetsregister for å lagre en unik enhetsidentifikator, sikkerhetsinformasjon og andre metadata som er nødvendig for å administrere tilgang til AWS-tjenester (figur 1). I Azure tjener identitetsregisteret en lignende funksjon.

Figur 1: I likhet med andre nettskyleverandører gir AWS utviklere et sett med spesialiserte tjenester designet for å forbedre sikkerheten og effektiviteten til transaksjoner mellom IoT-enheter og enterprise skytjenester. (Bildekilde: Amazon Web Services)

AWS IoT og Azure IoT tilbyr hver en tjeneste som opprettholder tilstandsinformasjon i en virtuell enhet, med hver sin fysiske IoT-enhet tilknyttet. I AWS IoT gir enhetsskygger denne muligheten for AWS IoT, mens enhetstvillinger gir lignende muligheter for Azure IoT.

Denne forestillingen om en sikkerhetsportal strekker seg til IoT-edge-tjenester (IoT-inngangspunkt) som AWS Greengrass eller Azure IoT Edge. Disse edge-tjenestetilbudene bringer noen skytjenester og -funksjoner ned til det lokale nettverket, der edge-systemer er plassert fysisk nær IoT-enheter og systemer i storskala utrullinger. Utviklere kan bruke en tjeneste som Azure IoT Edge for å implementere forretningslogikk for applikasjoner eller gi andre funksjonelle funksjoner som er nødvendige for å redusere ventetid eller levere tjenester til lokale operatører, for eksempel innen industriell automatisering (figur 2).

Figur 2: For å støtte edge computing tilbyr leverandører av skytjenester spesialiserte tjenester som Microsoft Azure IoT Edge, som bringer noen Azure IoT-skytjenester nærmere de fysiske enhetene som er tilknyttet IoT-applikasjonen. (Bildekilde: Microsoft Azure)

Håndterer kravene til IoT-portaltilkobling

Enten du kobler gjennom et edge-system eller direkte med leverandørens IoT-tjeneste, IoT-enheter trenger vanligvis å tilfredsstille en rekke krav for å koble seg gjennom leverandørens IoT-portal og bruke leverandørens skytjenester. Selv om detaljene er forskjellige, må IoT-enheter gi et minimum, noen elementer som en privat nøkkel, X.509-sertifikat eller annet sikkerhetstoken. Nøkkelen, sertifikatet eller tokenet gir IoT-portalen attestering eller bevis på IoT-enhetens identitet i løpet av godkjenningsfasen av tilkoblingssekvensen for enhets-skyen. I tillegg krever IoT-skytjenester vanligvis en spesifisering av retningslinjene som brukes til å definere tilgangsrettigheter for interaksjoner mellom IoT-enheter og skytjenester.

Som med andre databehandlingsskrav for bedrifter, må attestasjonsinformasjon for autentisering og retningslinjeinformasjon for tilgangsstyring leveres ved bruk av spesifikke formater og prosedyrer, spesifisert av ledende IoT-skytjenester som AWS IoT og Azure IoT. Disse tjenestene støtter sertifikatbasert godkjenning på et minimum, men støtter også bruk av andre former for attestasjon. For eksempel kan utviklere bruke token-baserte autentiseringsmetoder basert på en JSON Web Token (JWT) for AWS IoT, eller en token for delt tilgangssignatur (SAS) for Azure IoT.

Som nevnt tidligere, bruker disse tjenestene registre for å lagre metadata for hver IoT-enhet. Sammen med sikkerhet og annen informasjon, lagrer disse registrene retningslinjer for tilgangsrettighetene som må defineres for å koble til en IoT-enhet. Selv om de er spesifisert på forskjellige måter for forskjellige skytjenester, beskriver disse definisjonene av retningslinje for tilgangsrettigheter for forskjellige kommunikasjonskanaler og enheter. For eksempel ville en enkel retningslinje for tilgangsrettigheter for AWS IoT, bruke et JSON-format for å indikere at en IoT-enhet med et bestemt «ting»-navn i AWS IoT-enhetsregisteret kan koble til og publisere meldinger bare på en kanal med samme tilknyttede ting-navn (Oppføring 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}"]
      }
    ]
}

Oppføring 1: Utviklere bruker et JSON-format for å beskrive en retningslinje for tilgangsrettigheter for AWS IoT for sine IoT-enheter. (Kodekilde: AWS)

Sky-klare utviklingssett

Selv om nettskydeleverandører tilbyr detaljerte spesifikasjoner for disse formatene og prosedyrene, er leverandørenes støtteforum vanligvis fylt med spørsmål fra utviklere som er utløst av en liten, men viktig detalj som forhindrer godkjenning og tilgangsstyring. Kanskje enda verre – ut ifra et sikkerhetsmessig synspunkt, kan utilsiktet misbruk av attestering eller ufullstendig definisjon av tilgangsretningslinjer, gjøre IoT-enheter, nettverk og applikasjoner åpne for angrep. Tilgjengeligheten av serieproduserte utviklingskort og medfølgende programvarepakker lar utviklere raskt navigere gjennom disse tilkoblingsprosedyrene ved å bruke leverandør-ga eksempler for raskt å koble seg til IoT-skyer. For eksempel, Espressif Systems sitt ESP32-Azure IoT Kit eller Så teknologi sitt AZ3166 IoT Developer Kit inkluderer Azure-sertifiserte kort som er konstruerte for å enkelt få forbindelse med Microsoft-skyen.

Microsoft tilbyr komplette trinnvise demonstrasjoner, inkludert autentiserings- og tilgangsinformasjon for støttede utviklingssett. Med AZ3166-kortet trykker for eksempel utviklere på knappene på kortet for å starte forbindelse med det lokale Wi-Fi-nettverket. Når de er tilkoblet, kan de bruke Azure IoT Device Workbench som finnes i Azure IoT Tools forlengelsespakke for Microsoft Visual Studio Code å utvikle, feilsøke og samhandle med Azure IoT Hub. Ved å bruke dette verktøysettet og dets eksempelskodepakker, oppretter utviklere et objekt for IoT-enheten i Azure IoT Hub og bruker en gitt fil for å skaffe det tilknyttede identitetsregisteret med legitimasjon og andre metadata som kreves for å koble IoT-kortet til Azure IoT Hub (Figur 3).

Figur 3: Eksempelkode og legitimasjon gitt i Microsoft Azure IoT Device Workbench hjelper utviklere med å fullføre klargjøring for å koble Seeed Technology AZ3166 IoT Developer Kit til Azure IoT Hub. (Bildekilde: Microsoft Azure)

Azure IoT Device Workbench gir ekstra støtteprogramvare og metadata som lar utviklere raskt laste AZ3166-kortet med prøvekode og begynne å overføre målinger fra styrets temperatur- og fuktighetssensor til Azure IoT Hub.

Trinnene som er involvert i å lage en representasjon for den fysiske IoT-enheten i IoT-skyen og for å skaffe det tilknyttede registeret, er kun nødvendig for å koble enheter til IoT-skyen. For å dra nytte av skytjenester, trenger Azure IoT Hub imidlertid en retningslinje for tilgangsrettigheter. For å overvåke meldinger fra enhet til sky som kommer fra AZ3166-sensoren, kan utviklere ganske enkelt bruke skjermbildene for policyer for delt tilgang for Azure, for å velge en forhåndsbygget retningslinje, som er utformet for raskt å aktivere de nødvendige tilgangsrettighetene (figur 4).

Figur 4: Utviklere kan bruke forhåndsbygde retningslinjer for å enkelt autorisere bruk av Azure skytjenester med sensordata fra Seeed Technology AZ3166 IoT Developer Kit. (Bildekilde: Microsoft Azure)

Når du jobber med AWS IoT, kan utviklere henvende seg til utviklingssett som Microchip Technology'sAT88CKECC-AWS--B XSTK Null Touch Provisioning-sett og tilhørende programvare for raskt å evaluere nettsky-tilkobling. Denne oppdaterte versjonen av det tidligere settet Microchip Zero Touch Provisioning kit leveres forhåndsinnlastet med autentiseringsinformasjon. Ved å bruke flere skript som følger med settet, kan utviklere raskt koble kortet til AWS IoT uten å håndtere private nøkler og sertifikater (se, " Ta null-touch-metoden for å låse en IoT-enhet sikkert ").

Andre utviklingssett, inkludert Renesas'RTK5RX65N0S01000BE RX65N Cloud Kit og Infineon Technologies 'KITXMC48IOTAWSWIFITOBO1 AWS IoT-sett, utvid støtte for AWS IoT-tilkobling med støtte for rask utvikling av applikasjoner basert på Amazon FreeRTOS. AWS gir detaljerte instruksjoner for registrering av kortene, oppretting av autentiseringsinformasjon og innlasting av JSON-retningslinjer som er nødvendige for å koble til AWS IoT og bruke AWS-tjenester.

Forenkle klargjøring til store IoT-utrullinger

De utviklingssettene som de som beskrives ovenfor, fungerer som effektive plattformer både for rask prototyping av IoT-applikasjoner og for å utforske IoT-skytjenestens tilkoblingsbehover. I praksis vil imidlertid utviklere typisk måtte henvende seg til mer avanserte tilnærminger, som er designet for å forenkle levering av IoT-enheter i utrustninger i det virkelige liv. Både Azure IoT og AWS IoT støtter et bredt utvalg av metoder som tillater mer automatisert tildeling av individuelle enheter, eller stort antall IoT-enheter i en storstilt utrulling.

Med AWS IoT kan utviklere for eksempel bruke en bootstrap-metode (metode for å laste inn urprogram) for sertifikatlevering. Her sender det smarte produktet et bootstrap-sertifikat tilknyttet de minimale tilgangsrettighetene som trengs for å be om og få tilgang til et nytt sertifikat (figur 5).

Figur 5: AWS IoT støtter en metode for å bootstrap-sertifikatlevering i IoT-enheter. (Bildekilde: DigiKey, fra Amazon Web Services)

Ved hjelp av bootstrap-sertifikatet kobler enheten til skyen («1» i figur 5), ber («2») om et nytt sertifikat, mottar («3») URL-en til sertifikatet generert av en AWS-serverløs Lambda-funksjon, og henter («4») sertifikatet fra en AWS Simple Storage Services (S3) -bøtte. Ved å bruke det nye sertifikatet logger enheten seg deretter tilbake til AWS IoT («5») for å fortsette med normale operasjoner.

AWS tilbyr andre skytjenester som støtter dynamisk levering av godkjenningstokener ved å bruke eksekveringsressurser som AWS Lambda-funksjoner. For eksempel kan en applikasjon for bilindustrien stole på en rekke forbigående forbindelser der bruk av et symbol er både mer praktisk og sikrere. Etter at en AWS-modul for IoT-godkjenning og autorisasjon godkjenner forespørselen om et symbol, genererer AWS Security Token Service (STS) et symbol for levering til kjøretøyets systemer. Ved hjelp av det tokenet kan disse systemene få tilgang til AWS-tjenester som er underlagt validering av AWS Identity and Access Management (IAM)-tjenesten (figur 6).

Figur 6: Ledende skytjenesteleverandører støtter andre former for attestasjon for godkjenning, for eksempel denne prosessen for dynamisk generering av sikkerhetstokener av AWS Security Token Service (STS). (Bildekilde: Amazon Web Services)

AWS gir en lignende mulighet for dynamisk tildeling av tilgangsrettigheter. Her vil andre AWS Lambda-funksjoner tilordne et sett med retningslinjer tilknyttet et gyldig token (figur 7).

Figur 7: Utviklere kan bruke skytjenester for å implementere dynamisk tildeling av tilgangsrettigheter, noe som er spesielt nyttig for applikasjoner med forbigående forbindelser eller kortvarige operasjoner. (Bildekilde: Amazon Web Services)

Andre IoT-skytjenester gir utviklere mulighet til mer effektivt å håndtere levering i storskala utrullinger. AWS IoT gir for eksempel flåteutstyrsmuligheter, inkludert støtte for en større skala for utrulling av ved bruk av en bootstrap-metode, som er beskrevet tidligere. Azure IoTs Device Provisioning Service gir en grupperegistreringsfunksjon, som støtter levering av store antall IoT-enheter som har samme X.509-sertifikat eller SAS-token.

Delt ansvar for sikkerhet

IoT-skyleverandører tilbyr en rekke effektive metoder for å forbedre den gjennomgående sikkerheten (ende-til-ende-sikkerheten) for IoT-applikasjoner. Likevel kan ikke IoT-utviklere forvente at disse metodene kan bære den fulle vekten av sikkerhetskravene for deres spesifikke IoT-applikasjon. Faktisk skisserer leverandører av skytjenester nøye sin spesifikke rolle og sitt ansvar i IoT-applikasjonssikkerhet med spesifikke modeller som AWS sin delt ansvarsmodell (figur 8).

Figur 8: I likhet med andre ledende nettskydeleverandører, beskriver AWS ansvaret den deler med skybrukerne, for å beskytte skyinfrastrukturen på den ene siden og kundeapplikasjoner på den andre. (Bildekilde: Amazon Web Services)

AWS og Microsoft Azure har hver delte ansvarsdokumenter som beskriver og forklarer leverandørens egen rolle, samt kundens rolle, i å sikre ressurser, data og applikasjoner. I sin dokumentasjon tilbyr Microsoft også en oversikt over noen av forholdene mellom delte sikkerhetskrav og krav til overholdelse. Til syvende og sist beholder skyleverandører ansvaret for sikkerheten til skyen, mens kundene fortsatt er ansvarlige for applikasjoner, data og ressurser som brukes i skyen.

Konklusjon

IoT-applikasjoner er avhengige av lag med sikkerhet, bygd opp fra maskinvarebaserte mekanismer for kryptografi, samt sikker nøkkellagring. Som med alle tilkoblede produkter, kan sikkerhetstrusler komme i alle slags interaksjoner, når IoT-enheter kobles til skytjenester. For å beskytte seg selv og kundene sine, dikterer IoT-skyleverandører spesifikke krav til godkjenning og styring av tilgangsrettigheter. Selv om leverandører tilbyr detaljert dokumentasjon på disse kravene og tilhørende spesifikasjoner, kan utviklere oppleve at deres innsats for å implementere sikker tilkobling noen ganger lar ressurser være utsatte, eller omvendt, utilgjengelige. Ved hjelp av utviklingskort og tilhørende programvare kan utviklere raskt koble seg til skytjenester og raskt prototype IoT-applikasjoner med en gjennomgående-sikkerhet (ende-til-ende-sikkerhet).