Esiste un modello di progettazione disponibile per inviare dati dai dispositivi al cloud?

How do I make sure message delivery is success

Dipende dal tuo caso:

• È necessario mettere in coda le cose in caso di errori di trasmissione?
• Forse una semplice logica di riprogrammazione fa il trucco?
• È sufficiente che i tuoi servizi di consumo sappiano che non ci sono dati o dati correnti mancanti nella timeline

Suppongo che la domanda risponda in modo diverso a seconda che tu abbia a che fare con la domotica o con catene interessanti.

Do I need to have internal small SQL lite DB to store the messages and mark it as success if it delivered to the cloud?

Non ho familiarità con MQTT in dettaglio, ma suppongo che sia caratterizzato da pop ing e pushing messaggi. Quindi il tuo servizio di consumo sul backend apre un messaggio dalla coda del broker e, in caso di errori di trasmissione / elaborazione, potrebbe spingerlo indietro. broker dovrebbe gestire la persistenza dei suoi messaggi. Ciò significa che l'esistenza di un messaggio nella coda indica lo stato non elaborato .

Dichiarazione di non responsabilità: non sono un esperto di sicurezza, quindi è necessario leggere cum grano salis .

Secondly, Is it secure design?

A seconda della tua definizione di sicurezza si o no . Quali sono i rischi per la sicurezza che vuoi mitigare? Per esempio. Non inviare dati facilmente leggibili da tutti, TLS ti aiuterà.

What happens device landed in to wrong hands, will he/she start flooding my cloud data center? I am planning to use certificates but does it solve the needs?

I certificati sono un secondo fattore in un sistema 2FA . Hai una cosa che "conosci" - come username e password ; e un'altra cosa avere , che è il certificato.

Diciamo che uno ruba le tue credenziali, ma non avendo il tuo certificato, le credenziali sono inutili.

Per quanto riguarda il tuo scenario di rubare un dispositivo:

a) quello che ha il dispositivo, ha anche il certificato

b) Suppongo che quando è in generale possibile decodificare username e password , dovrebbe anche essere possibile estrarre il certificato.

Se vuoi mitigare i dispositivi non autorizzati , questo è quasi impossibile.

Se vuoi mitigare i dati false , anche questo è quasi impossibile.

Se vuoi mitigare solo "flooding your datacenter", devi stabilire una specie di "firewall" -sistema che consente un numero limitato di messaggi in un determinato intervallo di tempo - ovvero un filtro di pacchetti e qualche limitazione / "frode" -detection / validation a livello di applicazione.

Per ulteriori analisi approfondite / aiuto, ti consiglio di aprire una nuova discussione all'indirizzo Exchange Stack Exchange .

Alcune cose che generano bandiere rosse per me:

1. Non lascia che il tuo programma si carichi direttamente sul cloud. Dovrebbe essere caricato sul tuo server di back-end, e il tuo server di back-end si carica sul cloud, se non altro. Altrimenti sì, l'utente potrebbe potenzialmente avere il pieno controllo su tutte le risorse cloud.

2. Accetta la possibilità di fallimento. Mettiti in una posizione tale che quando si verifica un errore, sai esattamente dove non è riuscito e come risolverlo. Ad esempio, se lo stato del tuo messaggio è "PENDING", nel momento in cui stabilisci una connessione con il server prima del caricamento effettivo, cambia stato in "SENDING" in modo che se qualcosa dovesse andare storto, sai che stavi caricando al momento del fallimento .

3. Devi assolutamente avere un mezzo per sapere che il caricamento è terminato, senza il quale il tuo programma non può mai sapere che un file è stato caricato. Se non viene fornito alcun mezzo, è necessario trovare un mezzo. Un server di posta elettronica a cui non viene data una risposta dal server di posta di destinazione che una e-mail è stata consegnata con successo non sarà mai in grado di sapere se l'e-mail è stata inviata, anche se lo era!