Vlákno názorů k článku Protokol MQTT: komunikační standard pro IoT od finn - Jak je to s bezpečností? Jak je zaručeno,...
-
xxxxx (neregistrovaný)
Nijak. Pokud třeba, tak se nechává až na úrovni dat, která se přeposílají. Často není nutné /typicky lokální síť oddělená od zbytku doslova fyzicky/ tak by zbytečně zabíralo prostor /jak programový - implementace, tak i datový - přenosový/ a tím i spotřebu v koncových zařízeních.
-
M. (neregistrovaný)
No, ne úplně. Je podporováno ověřování (certifikáty nebo jméno/heslo) a můžu na brooker serveru konfigurovat kdo má přístup k jakým topicům pro R/W/RW. Ale je pravda, pokud víc zařízení má zapisovat do stejných topiců nebo se používají rozsáhlejší bridge propojení, tak musí mít write práva a pak musím řešit ověřování na aplikační úrovní v těch jednotlivých zprávách (např flattened JWS, pokud si tím posíláme JSON data).
-
xxxxx (neregistrovaný)
Pokud jsem pochopil, tak certifikáty jsou externí, stojící nad protokolem (mimo, nejsou přímou součástí paketů) - nebo se pletu?. Pak už je (z low-level pohledu) totéž (tedy neřešené), jestli si udělám něco svého (a posílám v datech) či použiji framework (či naprogramuji svůj - uff) a komunikaci do toho zabalím, namísto obyčejného (u klientů často omezeného omezeného) TCP/IP stacku.
A jméno/heslo je v podstatě "plaintext", byť v binární formě. Takže OK pro případ, pokud tím chci ošetřit abych omylem neposlal něco někam, kam nemám - t.j. odchytit programátorské chyby. Ale coby ochrana proti MitM či i jen slabšímu - pouhému odposlechu - a podstrčení falešné zprávy, to není.
-
karel (neregistrovaný)
Heslo v plaintextu nevadí pokud je prenášeno po bezpečném spojení, tedy pokud chcete bezpečnost první co tak komunikovat pře tls což mqtt broukry umí a druhé využít vestavěný ACL a to včetně používání jmen a hesel.
Pokud chcete použít více broukrů tak tam už je to s oprávnění horší, musí se to dobře nakonfigurovat, ovšem každý brouker zvlášť. Jde o to, že broukry se mezi sebou syncronizují taktéž pomocí publish a subscribe, připojený brouker je pro nadřazený brouker jen clientem.
Ještě je rozdíl mezi id clenta a loginem+heslo více různých klientů může používat stejný login a heslo.
-
xxxxx (neregistrovaný)
Ach jo. Nemotat transportní vrstvu a definici protokolu. Pro jistotu jsem znovu projel dokumentaci http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718111 Mimo jiné: "As a transport protocol, MQTT is concerned only with message transmission and it is the implementer’s responsibility to provide appropriate security features" a "A conformant Server MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client [MQTT-7.1.1-1]. However conformance does not depend on it supporting any specific transport protocols. A Server MAY support any of the transport protocols listed in Section 4.2, or any other transport protocol that meets the requirements of [MQTT-7.1.1-1]"
Takže ještě jednou. MQTT jako takové nedefinuje zabezpečení z pohledu útoků, útočníků. Tedy např. mohu vydat zařízení, o kterém mohu prohlásit, že je MQTT klient či server a žádné zabezpečení (krom toho plaintext login+hesla) mít nemusí.
Odpověď na otázku "Jak je to s bezpečností? Jak je zaručeno, že zprávu X odeslalo zařízení A a ne zařízení A', které se za A vydává?" ... tedy je ... "Není nijak zaručeno", musí se to ohlídat jiným způsobem - např. fyzickým oddělením sítě či na úrovni přeposílaných dat - ať už vlastní kontrolní implementace dovnitř dat paketu nebo zabalení celého protokolu (standardizovaně ssl/tsl/... nebo zase nějaké vlastní /coby extrém/).
-
> Odpověď na otázku "Jak je to s bezpečností? Jak je zaručeno, že zprávu X odeslalo zařízení A a ne zařízení A', které se za A vydává?" ... tedy je ... "Není nijak zaručeno", musí se to ohlídat jiným způsobem
???
Na úrovni brokeru jsou ACL - tj. jde zaručit (a v praxi se to používá), že do určitého topicu můžou zapisovat jenom určití klienti. Např. klient X může zapisovat jenom do topiců client/X/#.
Samotný bezpečný kanál MQTT nijak neřeší, spolíhá na nižší vrstvy. Na tom ale není nic divnýho, třeba HTTP to dělá úplně stejně.
-
MQTT protokol bezpečnost opravdu neřeší (kromě autentizace plain text username/password, která není moc použitelná). MQTT broker zabezpečení řeší autentizací a zajištěním integrity spojení na úrovni TLS (stejně jako např. u HTTPS), autorizace řeší s pomocí ACL (Access Control List), které definují, co který klient smí a nesmí.
BigClown primárně používá uzavření MQTT brokeru a MQTT klientů do jedné bezpečnostní zóny (Linux server), kde do komunikace nevstupuje žádná strana mimo toto prostředí a toto prostředí je spravováno jedním správcem, který důvěřuje SW, který tam pouští.
Komunikace po MQTT v rámci "domácího" systému probíhá tedy jen na loopback síťovém rozhraní. Výhodou jedné bezpečnostní zóny je snadná rozšiřitelnost bez náročného řešení bezpečnostních záležitostí (o těchto detailech si povíme v dalších dílech seriálu).
I tak má uživatel možnost otevřít MQTT směrem ven a použít TLS a ACL MQTT brokeru či bezpečnostní mechanizmy předřazených systémů (např. reverzní HTTPS websocket proxy).
Komunikaci mimo bezpečnostní zónu Linux serveru (včetně bezpečnosti) řeší jednotlivé komponenty samostatně podle potřeb typu komunikace.
