Overraskelse! Internet of Things inkluderer ikke nødvendigvis internettet

Når det allerede er kendt koncept Internet of Things (IoT) var nyt, var det, vi virkelig forestillede os, masseudbredelsen af ​​”ting”, dybest set sensorer forbundet direkte til internettet og, ligesom internettet, tilgængelige for mange virksomheder for at danne grundlag for nye applikationer. Hverken forretningsmodellen eller privatlivs-/sikkerhedsproblemerne ved denne tilgang er let blevet testet, så vi er tilbage til det, der stort set fortrænger internettet fra IoT.

Men hvad erstatter det?

Svar: The Web of Things eller IKKE, og hvis du aldrig har hørt om dette koncept, er du på det første trin i at forstå problemet.

Et rigtigt NEJ falder i to hovedkategorier. Den første er forbruger og bruges også af små og mellemstore virksomheder og endda fjerntliggende kontorer i virksomheder. I denne model Trådløst internet bruges til at forbinde enheder til en udbyders hjemmeside, som derefter giver brugerne adgang til deres teknologier til at overvåge og administrere dem. Den anden metode, som sandsynligvis vil blive vedtaget af virksomheder, bruger forskellige højt specialiserede protokoller designet kun til IoT. Det er disse protokoller, der skaber det sande net af ting, og de fleste netværkere ved lidt om dem.

Ægte IoT-protokoller er en blanding af proprietære og standardteknologier. Langt de fleste af dem er designet til at fungere i det ulicenserede trådløse spektrum over en meget kort afstand, højst et par hundrede fod. De arbejder efter samme opdagelsesprincip som routernetværk, idet de vælger den bedste rute ved at opdage netværkstopologien, men implementeringen er meget anderledes. For det første er dette et kortsigtet problem. Routernetværk fungerer over en global afstand, mens IoT-netværk fungerer på stedet.

Behovet for overvågning

Det store problem er, at disse trådløse IoT-netværk ikke har en sniffer til at registrere signaler og afkode beskeder, så netværksteknikere kan faktisk ikke overvåge netværket for at se, hvad der foregår. De er nødt til at stole på, hvad IoT-hubben ser, hvilket betyder, at hvis en sensor eller andet element ikke kan nå navet, er det lige uden for alfarvej et sted. For det første skal du have hubben og IoT-enhederne til i det mindste at tale, og hvis du gør det, kan du se, hvad ruten er, og hvor stærkt signalet er.

Dette betyder, at NoT-planlæggere skal finde ud af, hvor langt fra hinanden de kan placere enheder. De skal være særligt forsigtige med batteridrevne, fordi de ikke kan gentage signaler for at udvide deres rækkevidde. Den bedste strategi er at placere en hub et sted i midten, og derefter tilføje forlængere/repeatere, der bare forstærker signalerne ved at starte i nærheden af ​​hub’en og arbejde udad, og derefter kontrollere en af ​​dem, mens du tilføjer den for at sikre, at den faktisk er forbundet før end at tilføje Ellers andet. . Med alle repeaterne installeret, tilføjer du derefter vekselstrømsdrevne elementer, igen starter med repeaterne og arbejder dig ud. Batteridrevne elementer tilføjes sidst, og hvis noget ikke forbinder, bliver du nødt til at tilføje et par flere repeatere, indtil alt er oppe at køre.

Når først NoT-elementgitteret er på plads, har det en tendens til at slå sig ned og virke, i hvert fald så længe alt er på plads. Hver IoT-enhed vil have sin egen strømsvigtsadfærd. De fleste kontakter og sensorer husker deres tilstand under et nedbrud og genopretter til den samme tilstand, men hvis det ikke er det, du ønsker, skal du programmere din applikation til at genoprette tilstanden mere smidigt. Du skal muligvis også være særlig opmærksom på hubbens strømforsyning, fordi det er en simpel enhed, der kan blive beskadiget af strømstød eller pludselige strømafbrydelser/gendannelser. Sæt UPS’en på alle hubs og vær sikker.

Sikkerhed for tilsluttede enheder

Det næste spørgsmål er sikkerheden af ​​hubs. Det er klart, at disse små billige plastikbokse ikke er supercomputere med alle mulige ressourcer til rådighed for at sikre forbindelser. De bedste IoT-protokoller vil tilbyde krypterede beskeder, men denne mulighed er af begrænset værdi, hvis din hub er sikker, da enheder eksplicit skal tilføjes netværket, så en tredjepart ikke nemt kan hacke. IoT-protokoller er også meget begrænsede i, hvad de kan gøre, hvilket gør det svært for en angriber at vinde meget ved at kompromittere en enhed.

Det reelle sikkerhedsproblem kommer ved grænsen mellem dit NoT-netværk og resten af ​​dit netværk, det vil sige internettet eller din VPN. En hub giver ofte en forbindelse mellem disse to meget forskellige verdener, og en hub er ikke meget mere kraftfuld end IoT-enheder. En hub kan være på størrelse med et sæt kort, hvilket betyder, at den har sine egne upstream-sikkerhedsfunktioner. VPNfor eksempel er begrænset. Hvis nogen bryder ind i hubben, kan de ikke kun tilføje deres enheder til dit NoT eller fjerne din, men også bryde ind i din VPN fra hubben.

Moralen her er, at det ud fra et sikkerhedsmæssigt synspunkt er ekstremt vigtigt at sikre forbindelsen mellem navet og det, der er så godt som muligt. Hubbens fysiske sikkerhed er vigtig, ligesom forbindelsen mellem hubben og resten af ​​dit netværk er. Prøv at bruge Ethernet til denne forbindelse, hvor det er muligt i stedet for Wi-Fi, og hvis du bruger Wi-Fi, så prøv at konfigurere et separat netværk til din hub og eventuelle Wi-Fi IoT-enheder for at sikre, at IoT-hacket ikke åbner op. hele din virksomhed.

IoT-sensor trafikforsinkelse

Det sidste problem er den frygtede kontrolsløjfe, vejen mellem den besked, der formodes at indlede et trin i processen, og logikken i den softwareapplikation, der udstedte kommandoerne. Mange IoT-applikationer er meget latensfølsomme. Forestil dig en stor lastbil, der ruller hen mod en port, hvor en RFID-sensor skal læse lastbilens ID og sende en forespørgsel for at tjekke, om køretøjet forventes, og hvor det skal hen. Hvis lågen åbner, mens lastbilen bliver inspiceret, fortsætter chaufføren højst sandsynligt med at køre langsomt og venter på, at lågen åbner. Hvis kontrolsløjfen er lang, hvilket betyder, at den har meget forsinkelse, så forvent, at lastbiler passerer gennem et par uåbnede porte. Ikke et lykkeligt resultat.

Problemet med NoT-kontrolsløjfer er, at de spænder over NoT, VPN og skyen eller datacentret. Al denne forsinkelse skal opsummeres, og delen i NoT er svær at måle på grund af de allerede nævnte begrænsninger. Den eneste måde at få pålidelig information om kontrolsløjfen på er at køre test, ikke kun når applikationen er installeret, men også når en del af den ændres. Selv tilføjelse af sensorer til din NoT kan ændre latens i en anden del af netværket.

NoT er ikke for tøser og ikke for traditionelle netværksprofessionelle. Vejen til NoT-succes ligger i at indse, hvor anderledes det er, og så lære detaljerne i NoT, før du begynder at sætte gear i og sætte det sammen. Gør det rigtigt, og alle de porte og lastbiler vil takke dig.

Deltag i Network World Communities på facebook såvel som LinkedIn kommentere de hotteste emner.

© 2022 IDG Communications, Inc.

Leave a Comment