Doesn’t quite work the same in Azure. For instance, there are three separate copies of every storage table within a data center, and then three more in a geographically separate data center (unless you opt out) and on top of that, each table may be shredded across many servers and spindles. You would need a whole box of shotgun shells and a lot of frequent flier miles. SQL stores have similar replication abilities (though at a higher price point). As for your own service code, Azure TrafficManager allows for geo-redundant failover to the network-nearest functioning server, so your services get geo-local performance and geo-redundant failover too.
For every Azure component, there is local and/or distributed redundancy and failover/load-balancing mechanisms. And you now also have hardware-encryption secured key vaults and encrypted storage tables, so even a stolen drive isn’t going to help anyone. The keys for these stores are not exportable from the vaults. Nothing is perfect, but Azure is geo-redundant and FIPS-compliant (and a few other acronyms that I don’t recall) for all infrastructure.
…and having had some experience with the Office 365 cloud services (accessing them indirectly for diagnostic purposes), I can tell you that even we, as employees and developers of the service code, are seriously fire-walled from the servers and only see scrubbed log files, and then only indirectly. It’s like typing with a 10-foot fiberglass pole. And we take extensive periodic security and ethics courses in order to retain access to that pole. I can’t go into detail, for obvious reasons, but the physical and digital security is impressive. I don’t think the company takes anything else much more seriously than data security.
I a small single developer company there is no way I could even attempt to offer the services that I do without the Cloud. Currently I use Azure. There is no way I could be competitive if I had to stand up my own servers at a data center, maintain and secure them. Certainly not at the level I get out of the box with Azure. A product that I envisioned almost 10 years ago but couldn’t be competitive with is now a reality because of Azure.
I do hear all the “what-ifs”. Some are plausible (hardware failure, hacker,etc.), some far-fetched (zombie apocalypse), others disasters (localized disaster or international conflict). The far-fetched are just that far fetched. The plausible are pretty well covered by every good Cloud provider as other posters have pointed out. Even large regional disasters are handled with geo-redundant data centers. However, I do think especially in the IoT space the question should be asked about how important is the data? Individual device control could possible be an issue when talking about connected PLC’s or other control systems to the cloud. But the data itself, how interesting are streams of sensor data to a hacker, is there any financial gain in it? I am not advocating weak security but I do sometimes wonder where the cost to benefit point is.
Data can be used and misused in plenty of ways. There is no reason why sensor data today should be sent unencrypted over any kind of network today. It does not only contain the sensor data itself, but in many cases the commands that are sent directly to a specific device or to multiple devices at once. Or other relevant data. I think we could come up with a ton of possible scenarios here.
For testing and development purposes I can live with unencrypted data-streams, or hobbyist projects, but not for sensors and devices that I use in my daily life, public spaces or at my workplace.
And I am not going to rely only on cloud-providers and their promises. A good security concept goes way beyond of what a cloud provider can offer. For me security starts with the development of your device and does not end with the connection to the cloud or selling it to potential customers. It is a philosophy that will pay off in the near future.
@ AWSOMEDEVSIGNER - To assist with that it would be nice if small devices actually supported encryption. In some cases it would eliminate the need for gateway devices to handle the encryption. Currently it seems that you need to have at least an ARM m3 or m4 minimum to support TLS/SSL. Even then its hard to find consistent examples and libraries. Rabbit Semiconductor with their 40Mhz 8bit processor supported SSL. I am not quite sure why small 32bit ARM (M0 for example) can’t.
Do you store your data encrypted or only over the wire?
I totally agree with you on this. I am disappointed as well, that many small devices are unable to support encryption today, mostly because they are lacking libraries that support encryption.
The library dilemma is everywhere. And if there is encryption available examples don’t work, or the security part has simply been abandoned and/or not updated for years.
I am encrypting in a production system everything that is possible and what makes sense to be encrypted. I also tend to divide user related data and production/system relevant data into different databases and to use guardian-like services, sitting between the services themselves and the outside world. Virtual Networks, IP/Host-Based access rules to access services within those networks, throttling request rates and more.
@ AWSOMEDEVSIGNER - I did find SharkSSL last week when looking for a secure MQTT solution but it is out of my price range right now. Its $5500 for a license. Its hard to justify that cost over less than 100 devices/year. It appears the license is per product. I could probably justify it if it was per developer.
@ skeller - Yeah, that’s really hard. There should be other, more convenient licensing options for these libraries for single-devs and startups out there.
@ skeller - If the streams of data is medical information from a person’s pace maker then yes it’s pretty valuable; at least to the person wearing the pacemaker (or Microsoft Band). One man’s trash could be another man’s treasure. Further, crackers sometimes start small, doing training on little things that don’t matter much.
The cerb family’s stm32f4’s have chip variants that accelerate encryption but they aren’t used for NETMF devices, and no one can tell me why (yea I’m throwing that to somebody). Further the Chips have support for encrypted traffic to and from the micro sd cards we’re all fond of, but again the encrypted functionality is not enabled.
Basically it’s treason for a US Citizen to export strong encryption systems.
@ Mr. John Smith - I am attending my first STM32F7 Hands-On-Lab on the 13th this month, and I am going to ask a lot of questions about security. This is my chance to see how the ST people are handling all the development stuff at first hand.
@ skeller - STM32F0 (Cortex-M0) has ST’s crypto accelerator, so SSL shouldn’t be too hard to implement there. WolfSSL supports the F2 line, and the hardware crypto in the F0 is the same, so it shouldn’t be a complex port.
This discussion of encrypted communication has been a big frustration for me the last few weeks. I am trying to develop a very small, 1.5" x 2", sensor interface board with RJ45 Ethernet for industrial use. Since it needs a frequent update time (every 30secs or less) power is required. If I have to run a wire it might was well be Ethernet with PoE. The two things I run into are encryption and network harware and drivers for hard wire ethernet. If I was willing to go down to tiny BGA devices I could get it done with M3 or M4 ARMS but at almost prototype quantities its hard to work with BGAs.
I really wish there was something in the .NETMF world that could meet the need. Currently the G120 is the smallest device to support SSL/TLS and its too big. Even the G80 is physically large (14mm x 14mm) for the application but it might work if it supported SSL/TLS. Still need to add a ENC28 to get to the network.
(yea I’m throwing that to somebody). Further the Chips have support for encrypted traffic to and from the micro sd cards we’re all fond of, but again the encrypted functionality is not enabled.
Hard to get this kind of information’s otherwise. Thanks.