Comunicațiile și chestiile conectate la internet, adică IoT

După SOA și cloud, următorul buzzword este IoT (Internet of Things). Dacă ești în IT în zilele astea și nu faci IoT, atunci ești pe nicăieri. Acum adevărul e că IT-ul evoluează foarte rapid. Sau avem noi aerul ăsta să credem că celelalte industrii nu o fac? Na, nu contează, dar noi în IT alegem din când în când un trend sau două și ne adaptăm toate produsele, serviciile și mai ales marketingul la ele. Unii reușesc să fie pe val, iar ceilalți rămân cu marketingul.

La începutul acestui mileniu ne-am dat cu toții seama că IT-ul era format dintr-o mare colecție de soluții ca niște insulițe, care nu comunicau între ele. Service Oriented Architecture (SOA) venea să rezolve problema asta de integrare. Era felul nostru al furnizorilor de a le arăta clienților că ne-am învățat lecția și că de acum uite ce frumos le vom integra pe toate. Pe clienți nu îi interesa că se numește SOA sau altcumva, ei săracii doreau să scape de nebunia cu care s-au ales de-a lungul anilor.

Apoi, peste vreo 10 ani am venit cu cloud-ul, care e un alt fel de a spune că tu, stimate client, nu ai nevoie de serverele alea, fiindcă și așa nu știi să ai grijă de ele, iar noi o facem mult mai bine și, de fapt, mai bine îți ții tu infrastructura IT la noi în datacenterele astea mari și deștepte. Automatizare, capacitate cât vrei tu și plata adaptată în funcție de consum. E perfect pentru majoritatea clienților, chiar dacă îi mai sperie câte un Snowden… de parcă agențiile alea cu trei litere nu te vor urmări dacă vor, chiar dacă ai serverele la tine și dormi cu ele. Stați să vedeți cu IoT-ul ce vor putea face… dar până una alta, ia uite unde e IoT-ul pe curba de hype a lui Gartner. În vârf!

gartner hype 2014

Cum s-a ajuns la IoT? Păi de mult se vrea conectarea a cât mai multe chestii la internet. Calculatoare, telefoane, tablete, mai nou ceasuri, toate se vor conectate la internet. Și sunt conectate, direct sau indirect prin intermediul unui alt dispozitiv deja conectat. Cu IoT urmează senzori, valve, lămpi, porți, camere, bariere, de toate. Experiența căpătată din anii de SOA ne-au învățat cum să integrăm multe chestii și cum să comunicăm asincron. Apoi cloud-ul ne permite să conectăm o căruță de chestii, fără să ne doară prea mult la buzunar. Specialiștii în SCADA (supervisory control and data acquisition) se adaptează și ei, fiindcă senzorii și acționările sunt lumea lor, dar până acum comunicau prin rețele private. De acum vor comunica și ei pe bază de IP (Internet Protocol) și își vor conecta senzorii și valvele la internet. Desigur securitatea este o problemă serioasă și încă nerezolvată. Probabil vor apărea hackeri specializați în aprins lămpi, hăcuit camere și schimbat luminile semafoarelor de pe stradă, dar nu despre asta vreau să discut acum, ci despre comunicațiile de sub protocolul IP.

V-ați gândit de ce este important peste ce trec protocoalele de rutare IP și de transport TCP, esențiale pentru comunicația în internet? Cei care mai țineți minte nivelele modelului OSI știți că IP este la nivelul 3, TCP este la nivelul 4, iar dedesubt, la nivelul 1 este așa numitul nivel fizic și la nivelul 2 este data link. Aparent este indiferent dacă la aceste nivele este WiFi, sau 3G, sau LTE. De fapt ce sunt astea? Sunt modalități diferite de a transmite date prin unde radio, adică sunt tipuri de modulații, care mai de care mai deștepte. Observați că în lumea asta a IoT nu ne interesează sârmele și fibrele ci doar radio, adică wireless. Acum, tipurile astea de modulații au evoluat mai degrabă cu gândul la calculatoare, tablete și telefoane, adică chestiile pe care le avem acum conectate la internet. Adică au evoluat spre viteză, spre cât mai mulți Mbps. Deh, pozele și filmulețele alea de pe Facebook trebuie să se vadă imediat, nu-i așa? Problema e că în lumea IoT rareori ne interesează viteza, ba mai mult, ne interesează mai degrabă:

  • raza mare de acțiune;
  • consumul mic în timpul funcționării, pentru a putea alimenta senzorii cu baterii;
  • consumul foarte mic în standby, pentru a putea lăsa un senzor pe coclauri măcar câțiva ani fără schimbarea bateriei;
  • utilizarea unor frecvențe care să permită penetrarea clădirilor și subsolurilor;
  • cost redus al chip-urilor de modulație și demodulație (modem), fiindcă ne așteptăm să avem zeci de miliarde de chestii conectate la internet.

Nimic nu e încă stabilit în acest domeniu și sunt o grămadă de tehnologii candidate. Interesele sunt foarte mari la fiecare nivel, de la fizic până la aplicații. Marii jucători își marchează deja teritoriul. Furnizorii de cloud (Amazon, Microsoft, Google) vor să ne conectăm chestiile în cloud-ul lor, ceilalți (Cisco, IBM, Oracle) vor să folosim jucăriile lor pentru conectare indirectă, middleware și analiză. Cred că cel mai interesant va fi de văzut lupta dintre tehnologiile de la nivelul fizic, fiindcă dacă ești producător de chip-uri de modem și ai un potențial de zeci de miliarde de bucăți, chiar dacă le vinzi cu 2 dolari bucata, tot e un business frumușel. Vă propun să le împărțim după raza de acțiune.

În categoria sub 1km sunt:

În categoria 1-10km sunt:

Iar în categoria peste 10km sunt:

  • 2G, 3G, LTE, adică ăia cu mulți Mbps și cu consum mare
  • LoRa
  • Sigfox
  • OnRamp
  • și încă câteva mai obscure.

Doar câteva sunt standarde și niciuna nu s-a impus de facto. De fapt una din dezamăgiri este că 802.15.4g nu a decolat cum trebuia, probabil și din cauză că topologia de rețea de tip mesh produce consum mult mai mare la senzorii apropiați de gateway. Iată cum o problemă simplă de consum și baterie poate duce la neadoptarea unei tehnologii, chiar dacă e una generoasă și chiar dacă e standardizată.

Personal prevăd că Semtech va avea tracțiune în viitorul apropiat cu LoRa. LoRa (prescurtare de la long range) se bazează pe o modulație de chirp de tipul spectru împrăștiat, o topologie de rețea de tip stea și un consum fabulos de mic (18mA în funcționare și 0,001mA în standby). Patentul Semtech este la https://www.google.com/patents/US7791415 și, deși pe http://lora-alliance.org/ nu scrie cine sunt susținătorii, Cisco și IBM sunt printre ei, ceea ce este un semn important.

Vremuri interesante, din nou.

Legea securității cibernetice, serviciile secrete și găinile

sriLegea securității cibernetice a fost adoptată de deputați în septembrie 2014 și de senatori în decembrie, înainte de Crăciun. Acum este la promulgare la președinte, însă ONG-urile și-au făcut treaba și au semnalat câteva probleme, printre care și cea legată de articolul 17, care permite accesul prea ușor (fără hotărâre judecătorească) la datele prea multor posesori de calculatoare (potențial tuturor). Adoptarea în Senat a cauzat intensificarea iureșului ONG-urilor ceea ce a dus la o sesizare de neconstituționalitate depusă chiar de senatorii liberali. Înainte de a-mi începe analiza, dați-mi voie o observație de natură lexicală: nu înțeleg de ce folosim cuvântul „cibernetică” pentru a vorbi despre IT. Cibernetică înseamnă cu totul și cu totul altceva. Haideți să folosim IT, vă rog, de la tehnologia informației. Așa vor înțelege și cei cca 100000 de profesioniști IT din România că este vorba despre jucăriile lor. Puriștii ar spune că trebuie să punem IT&C pentru a include și comunicațiile, dar nu este nevoie. În acest context de securitate, comunicațiile sunt parte din IT, sunt țeava prin care curg biții. În legea asta ar trebui să fie vorba despre „securitate IT” și „infrastructuri IT”, dar să revenim.

Dacă aveți curiozitatea să citiți legea, veți vedea că este bine scrisă și are un scop generos, acela de a reduce riscurile de securitate din rețelele de calculatoare și servere de interes național (în textul legii ICIN = infrastructuri cibernetice de interes național). Bine scrisă în sens relativ, fiindcă avem multe alte legi mai stufoase și mai ambigue. Și legea asta poate fi perfecționată.

Sunt voci care susțin că articolul 17 a fost introdus premeditat de către serviciile cu 3 litere pentru a le da acces la datele posesorilor de calculatoare și servere, dar eu cred că nu e chiar așa. Din nou, dacă citiți legea, articolul 17 pare ok în contextul unei amenințări de securitate IT, însă ONG-urile au și ele dreptate: articolul, mai exact punctul (1)a), este scris neglijent și permite niște interpretări periculoase:

Art. 17. (1) Pentru realizarea securității cibernetice, deținătorii de infrastructuri cibernetice au următoarele responsabilități:
a) Să acorde sprijinul necesar, la solicitarea motivată a Serviciului Român de Informaţii, Ministerului Apărării Naţionale, Ministerului Afacerilor Interne, Oficiului Registrului Naţional al Informaţiilor Secrete de Stat, Serviciului de Informaţii Externe, Serviciului de Telecomunicaţii Speciale, Serviciului de Protecţie şi Pază, CERT-RO şi ANCOM, în îndeplinirea atribuţiilor ce le revin acestora şi să permită accesul reprezentanţilor desemnaţi în acest scop la datele deţinute, relevante în contextul solicitării.
b) să informeze, de îndată, autoritățile și instituțiile publice prevăzute la lit.a) cu privire la incidentele cibernetice identificate, conform procedurilor stabilite prin normele metodologice la prezenta lege.
(2) Deținătorii de infrastructuri cibernetice pot solicita asistență de specialitate autorităților și instituțiilor publice cu atribuții în domeniul securității cibernetice în domeniul lor de activitate.

Nu cred că SRI sau alte servicii cu 3 litere au nevoie de articolul ăsta pentru a „convinge” pe cineva că doresc acces la datele lui în cazuri de securitate națională. Mai ales dacă vin la negocieri cu mascații înarmați. Scopul articolului trebuie să rămână izolarea și remedierea incidentelor de securitate IT.

Soluția pentru corectarea Art.17 nu e chiar atît de simplă cum sugerează APTI (Asociația pentru Tehnologie și Internet, unul din ONG-urile de mai sus), cu tot respectul pentru Bogdan Manolea, fiindcă atacurile din internet se întâmplă foarte repede și răspunsul trebuie să fie și mai rapid, dacă se poate înainte ca amenințarea să se transforme într-un incident. Nu ne putem permite să așteptăm ca procurorul să întocmească cererea de „supraveghere tehnică” și apoi ca judecătorul să analizeze și să aprobe. Mărturisesc că nu știu cât de puțin poate dura asta în mod realist, dar nu cred că e vorba de minute sau ore, iar dacă e vorba de zile, atunci e prea târziu. Mai degrabă aș clarifica la ce date deținute trebuie să dea acces și cum. De fapt, aici nu ar trebui să fie vorba despre acces la date, ci despre acces la infrastructura IT cu scopul de a izola și remedia un incident de securitate IT. Veți spune că dacă se dă acces la infrastructură, se dă acces indirect și la date. Corect, însă în astfel de cazuri, de obicei se pun clauze de genul „autoritățile vor folosi accesul la infrastructura IT strict pentru a izola și a remedia incidentul de securitate IT”, eventual decorat cu „eventuale date obținute din acțiunile de izolare și remediere nu pot fi folosite de către autorități în alte scopuri, decât pentru a izola și a remedia incidentul de securitate IT”. Știm cu toții că tehnic nu ai cum să îi oprești, însă legea asta este perfectă pentru a-i ține în lesă.

gripa aviara A doua problemă semnalată de APTI este că legea se aplică tuturor persoanelor de drept public și privat, adică inclusiv firmulițele cu un calculator. Soluția propusă de APTI este ca legea să se aplice doar deținătorilor de infrastructuri IT de interes național, ceea ce are sens, însă ce ne facem cu firmulițele sau chiar persoanele fizice și XP-urile lor care îngroașă botnet-urile prin ignoranța deținătorilor (software neactualizat, lipsa măsurilor elementare de securitate sau pur și simplu pron sau porci zburători prostie). Păi putem folosi învățăminte din sănătatea publică. Cum se procedează când apare o epidemie cu un virus periculos, chiar necunoscut? Amintiți-vă de H5N1 (gripa aviară) sau HIV (SIDA). În primă fază izolezi focarele, pui bolnavii în carantină, îi tratezi și între timp studiezi virusul. Afli modul de răspândire pentru a-l izola mai eficient și cauți un antidot pentru a trata bolnavii. Apoi educi populația să nu se infecteze, să-și ardă găinile suspecte, să folosească prezervativ și ace de unică folosință. Cam așa faci și în securitatea IT. Partea cu educația e un efort de lungă durată, chiar continuu, și nu încape în această lege. Trebuie să investim în programe de educație în domeniul securității IT și să le executăm regulat.

Ceea ce merită totuși inclus într-o lege este izolarea deținătorilor de infrastructuri IT infectate, adică carantina. Știu că e radical ceea ce spun aici, dar este extrem de util și relevant în contextul securității IT. Gândiți-vă că acum, de dragul libertății și al privacy (în IT, asta înseamnă dreptul de a-ți controla datele), nu putem face mare lucru cu calculatoarele infectate ale persoanelor fizice sau juridice care, de cele mai multe ori fără voia lor, participă la rețele internaționale de infracționalitate informatică. Da, calculatoarele lor infectate sunt controlate de infractori pentru a organiza atacuri lucrative către ținte bănoase de aiurea. Posesorii de astfel de calculatoare văd doar o încetinire periodică a calculatoarelor. Atunci își ard găinile, pardon, își reinstalează calculatoarele și rămân sănătoși până la următorul sex neprotejat, pardon, până la următorul site dubios care le reinstalează rootkit-ul sau următoarea aventură printre dependenții de droguri injectabile, pardon, instalare de aplicație primită de la moștenitorul african. Ați înțeles analogia? Carantina este un concept greu de digerat și fiindcă ea trebuie să includă persoanele fizice, poate că nu încape în această lege făcută pentru persoane juridice (vezi Art.2 mai jos).

O altă problemă esențială pe care o văd în această lege este legată de ambiguitatea articolului 2 care definește deținătorii de infrastructuri IT așa:

Art.2.
Dispozițiile prezentei legi se aplică persoanelor juridice de drept public sau privat, care au calitatea de proprietari, administratori, operatori sau utilizatori de infrastructuri cibernetice, denumite în continuare deținători de infrastructuri cibernetice.

Pare ok, însă sunt mici probleme cu partea de proprietari și mari probleme cu cea de utilizatori. Proprietarii ne încurcă în scenariile de cloud public, iar utilizatorii… ei bine, ei n-au ce căuta în legea asta.

Să dăm un exemplu fictiv: să zicem că suntem AFIR (Agenția pentru Finanțarea Investițiilor Rurale) și avem infrastructura IT închiriată de la STS (Serviciul de Telecomunicații Speciale). La ei sunt serverele noastre, adică suntem într-un scenariu tipic de cloud privat. Cine este deținătorul infrastructurii IT? Conform articolului 2, amândoi, fiindcă STS este proprietar, iar noi administratori și operatori. S-ar putea să vrem să lăsăm personalul STS să administreze și noi să rămânem doar operatori, dar e ok, nu se schimbă nimic, suntem amândoi în continuare deținători de infrastructură IT. Mai departe, dacă agenția noastră anunță un val de finanțări, iar fermierii năvălesc pe portalul public să-și depună dosarele cu cereri de finanțare, atunci este mult mai eficient să închiriem vreo sută de servere dintr-un cloud public cum este Azure sau AWS pentru a găzdui portalul public pe perioada de vârf a depunerilor. În acest caz, proprietarul acelei părți a infrastructurii noastre IT va fi o corporație americană, care sub nici o formă nu ne va da acces fizic la datacenterele sale. Dar oare chiar este nevoie să includem proprietarii în această lege? În mod normal, o intervenție pe un incident de securitate se poate face la nivel de administratori. Chiar este nevoie de acces la nivel de proprietari, adică acces fizic la fiare și sârme? Cine știe, poate e nevoie să smulgi repede niște harddisk-uri, sau niște cabluri. Habar n-am. Poate ne lămurește cineva care se pricepe la asta. În orice caz, dacă lăsăm proprietarii în lege, atunci avem o problemă cu cloud-ul public. Nu spun că Microsoft sau Amazon nu ar colabora cu autoritățile române, dar trebuie să avem pretenții rezonabile, adică nu are rost să le cerem acces fizic și nu e realist să le cerem ceva fără hotărâre judecătorească. În plus, ar fi păcat ca această lege să pună piedici inutile în folosirea de cloud-uri publice.

În scenariul de mai sus vorbeam de fermierii care depun cereri pentru finanțări. Cine sunt ei? Sunt utilizatorii portalului public. Adică, conform articolului 2, sunt și ei deținători de infrastructuri IT. Complet greșit! Ei trebuie scoși din articolul 2, fiindcă doar încurcă acolo.

Nu scriu asta pentru a critica inițiatorii sau legiutorii, deși se vede că o dezbatere publică ar fi fost utilă. Vreau doar să ajut și vă indemn și pe voi să o faceți, mai ales dacă rezonați la probleme de securitate IT.

A incercat cineva sa ruleze Windows pe Amazon EC2?

Cică durează 15min instalarea. Detalii aici.
Bill Staples ne promite că va scrie despre avantajele și dezavantajele lui Windows Azure, comparativ cu Amazon Elastic Compute Cloud și Mosso.

Filed under: Web, Azure

# re: A incercat cineva sa ruleze Windows pe Amazon EC2?

Thursday, January 15, 2009 8:36 PM by matincaflorin

Am incercat eu.

Merge OK, insa din pacate nu au Windows Server 2008.