ideeën voor oplossing
In dit artikel wordt een oplossingsidee beschreven. Uw cloudarchitect kan deze richtlijnen gebruiken om de belangrijkste onderdelen te visualiseren voor een typische implementatie van deze architectuur. Gebruik dit artikel als uitgangspunt om een goed ontworpen oplossing te ontwerpen die overeenkomt met de specifieke vereisten van uw workload.
In dit artikel wordt beschreven hoe u een particulier netwerk gebruikt om bestanden te uploaden naar een Azure Storage-account.
Voor typische Azure IoT-implementaties moeten de IoT-clientapparaten rechtstreeks communiceren met het opslagaccount om bestanden te uploaden. IoT-clientapparaten worden doorgaans gedistribueerd op verschillende locaties en maken geen deel uit van een particulier netwerk, zodat ze verbinding maken via het openbare internet. U kunt deze apparaten niet integreren in een particulier netwerk, dus het opslagaccount vereist dat u binnenkomend internetverkeer toestaat.
Maar als u strengere netwerksegmentatievereisten hebt, kunt u de toegang tot het opslagaccount beperken vanuit een particulier netwerk. Met deze oplossing wordt internetverkeer naar het opslagaccount geblokkeerd, zodat het opslagaccount alleen verkeer accepteert dat via het binnenkomende Azure-toepassing Gateway-exemplaar gaat. Als u een sternetwerktopologie implementeert, moet Azure Firewall doorgaans verkeer inspecteren, wat een extra beveiligingslaag biedt.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Workflow
De volgende werkstroom komt overeen met het voorgaande diagram.
Een hub-spoke-netwerktopologie heeft een virtueel hubnetwerk dat is gekoppeld aan elk virtueel resourcenetwerk, ook wel een spoke genoemd. Al het verkeer gaat via Azure Firewall voor verkeersinspectie.
Een Azure Blob Storage-account weigert openbare internettoegang. Hiermee kunnen alleen verbindingen van andere virtuele netwerken worden toegestaan. Met een regel voor een resource-exemplaar kan een gekozen Azure IoT Hub-service verbinding maken via een beheerde identiteit. Het Blob Storage-account ondersteunt alleen op rollen gebaseerd toegangsbeheer (RBAC) van Azure voor toegang tot het gegevensvlak.
De toepassingsgateway heeft aangepast DNS (Domain Name System) en beëindigt TRANSPORT Layer Security -verkeer (TLS). Deze bevindt zich in een virtueel netwerk. Dit virtuele netwerk is gekoppeld aan het virtuele netwerk dat door de privékoppeling van het Blob Storage-account wordt gebruikt. Met een geforceerde tunnel via het virtuele hubnetwerk wordt de verbinding tot stand gebracht.
Het IoT-clientapparaat dat gebruikmaakt van de IoT Hub SDK vraagt een SAS-URI (Shared Access Signature) aan voor bestandsuploads naar IoT Hub. Het IoT-clientapparaat verzendt de aanvraag via het openbare internet.
IoT Hub verwerkt deze aanvraag voor het apparaat. Het maakt rechtstreeks verbinding met het Blob Storage-account via verificatie van beheerde identiteit, met machtigingen voor inzender voor opslagblobgegevens voor aanvragen van gebruikersdelegeringssleutels.
IoT Hub vraagt een sleutel voor gebruikersdelegering aan bij het Blob Storage-account. Een KORTdurende SAS-token verleent het apparaat lees-/schrijfmachtigingen voor de aangevraagde blob in de blobcontainer.
IoT Hub verzendt de URI van het openbare Blob Storage-account en het SAS-token naar het IoT-clientapparaat, samen met een correlatie-id.
Het IoT-clientapparaat heeft logica om de openbare Blob Storage-URI te vervangen door een aangepast domein, bijvoorbeeld een apparaatdubbel. Het IoT-apparaat maakt gebruik van een standaard Blob Storage SDK om het bestand te uploaden via de aangepaste Blob Storage DNS.
Application Gateway ontvangt de HTTP POST van het clientapparaat en verzendt het naar het Blob Storage-account via Azure Private Link.
Wanneer het uploaden van het bestand is voltooid, gebruikt het IoT-clientapparaat de Azure IoT SDK om IoT Hub op de hoogte te stellen.
Het IoT-clientapparaat werkt de uploadstatus van het bestand bij, zodat IoT Hub een melding voor het uploaden van bestanden naar back-endservices kan activeren als de melding is geconfigureerd. Het clientapparaat publiceert ook resources die zijn gekoppeld aan het uploaden van bestanden in IoT Hub.
Onderdelen
Application Gateway is een paaS-oplossing (Platform as a Service) die u kunt gebruiken om uiterst veilige, schaalbare en maximaal beschikbare front-ends te bouwen. In deze architectuur verwerkt Application Gateway het binnenkomende INTERNET HTTPS-verkeer, past TLS-beëindiging toe, onderhandelt TLS met het Blob Storage-account en stuurt verkeer via een privénetwerk door naar het Blob Storage-account.
Azure Firewall biedt beveiliging voor uw Azure Virtual Network-resources. In deze architectuur filtert en routeert Azure Firewall verkeer tussen het perimeternetwerk en spoke-netwerken.
IoT Hub is een door PaaS beheerde oplossing die fungeert als een centrale berichtenhub voor bidirectionele communicatie tussen een IoT-toepassing en de apparaten die worden beheerd. In deze architectuur is IoT Hub het centrale eindpunt waarmee IoT-clientapparaten verbinding maken voor besturings- en gegevensvlakbewerkingen.
Private Link biedt privétoegang tot services die worden gehost op het Azure-platform terwijl u uw gegevens op het Microsoft-netwerk bewaart. In deze architectuur biedt Private Link privécommunicatie tussen Application Gateway en het Blob Storage-account.
Opslag biedt een duurzame, maximaal beschikbare en zeer schaalbare cloudopslagoplossing. Het bevat mogelijkheden voor object-, bestands-, schijf-, wachtrij- en tabelopslag. In deze architectuur gebruiken apparaten Blob Storage om bestanden te uploaden naar de cloud via kortdurende SAS-tokens die IoT Hub biedt via gebruikersdelegering.
Privé-DNS zones bieden een betrouwbare, verbeterde beveiliging DNS-service voor het beheren en omzetten van domeinnamen in een virtueel netwerk zonder dat hiervoor een aangepaste DNS-oplossing nodig is. In deze architectuur biedt een privé-DNS-zone een privé-DNS-vermelding voor Blob Storage, zodat het storage-blob-eindpunt wordt omgezet in het privé-IP-eindpunt binnen het netwerk.
Virtual Network is de fundamentele bouwsteen voor uw privénetwerk in Azure. Met deze service kunnen veel soorten Azure-resources, zoals virtuele Azure-machines, met elkaar communiceren, internet en on-premises netwerken met verbeterde beveiliging. Deze architectuur maakt gebruik van Virtual Network om een privénetwerktopologie te bouwen, waardoor openbare interneteindpunten voor Azure-services worden vermeden.
Scenariodetails
Voor reguliere implementaties moet een Azure IoT-clientapparaat rechtstreeks communiceren met een opslagaccount om een bestand te uploaden. Door internetverkeer op het opslagaccount uit te schakelen, kunnen alle client-IoT-clientapparaten geen bestanden uploaden. De uploadfunctionaliteit van het IoT Hub-bestand fungeert alleen als een gebruikersdelegering voor het genereren van een SAS-token met lees-/schrijfmachtigingen voor een blob. Het uploaden van het bestand zelf passeert niet via IoT Hub. Een IoT-clientapparaat maakt gebruik van de normale Blob Storage SDK voor de daadwerkelijke upload.
In dit scenario loopt de communicatie tussen IoT Hub en het opslagaccount nog steeds via het openbare eindpunt. Deze uitzondering is mogelijk via opslagnetwerkconfiguraties voor resource-exemplaren. U kunt openbare internettoegang tot het Opslagaccount uitschakelen en Azure-services en specifieke exemplaren van resources toestaan om verbinding te maken via de Azure-backbone. Deze netwerkperimeter is gekoppeld aan een op Microsoft Entra ID gebaseerde identiteitsperimeter die gebruikmaakt van Azure RBAC om de toegang tot het gegevensvlak te beperken.
Met deze architectuur wordt een beheerde identiteit toegewezen aan IoT Hub. Aan de beheerde identiteit wordt de rol van Inzender voor opslagblobgegevens toegewezen aan het opgegeven opslagaccount. Met deze machtiging kan IoT Hub een sleutel voor gebruikersdelegering aanvragen om een SAS-token te maken. Het IoT-clientapparaat ontvangt het SAS-token voor het proces voor het uploaden van bestanden.
Application Gateway fungeert als het toegangspunt voor aanvragen die naar het privé-eindpunt van het opslagaccount gaan, dat is geconfigureerd als de enige back-end. Application Gateway maakt gebruik van een openbaar IP-adres. Een aangepaste DNS-provider kan worden geconfigureerd om het openbare IP-adres toe te wijzen aan een A-record of CNAME-record .
Als u interne beveiligingsvereisten hebt voor het gebruik van privé-eindpunten voor veel Azure PaaS-services, kunt u dit scenario implementeren om kortere validatiecycli te bieden voor het implementeren van uw IoT-oplossingen in productie.
Potentiële gebruikscases
Deze architectuur kan van toepassing zijn op elk scenario dat gebruikmaakt van apparaten die moeten communiceren met een opslagaccount dat niet openbaar wordt weergegeven.
Een leverancier van industriële automatisering biedt bijvoorbeeld beheerde verbonden edge-controllers en sensoren. Deze sensoren moeten communiceren met de Azure-cloud via het openbare internet, maar het beveiligingsteam van de leverancier vereist dat het opslagaccount openbare internettoegang wordt geweigerd. Deze architectuur voldoet aan deze vereiste.
Alternatieven
Als u de hub-spoke-netwerktopologie die azure Firewall-verkeersinspectie heeft niet nodig hebt, kunt u een vereenvoudigde netwerktopologie implementeren om te profiteren van deze aanpak. U kunt één virtueel netwerk met afzonderlijke subnetten gebruiken om te voorzien in Application Gateway, Private Link en de privé-DNS-zone. Het opslagaccount en ioT Hub kunnen dezelfde configuraties gebruiken als de oorspronkelijke architectuur.
De voordelen van een vereenvoudigde architectuur zijn lagere complexiteit en kosten. Als u geen specifieke bedrijfs- of bedrijfsvereisten voor een stertopologie hebt, gebruikt u de vereenvoudigde architectuur om openbare interneteindpunten uit het Opslagaccount te elimineren. Deze aanpak zorgt er ook voor dat IoT-toepassingen die gebruikmaken van de functionaliteit voor uploaden van IoT Hub-bestanden correct werken.
Zie Uploaden van IoT Hub-bestanden naar Storage instellen via een privé-eindpunt voor een voorbeeld waarmee een vergelijkbare architectuur wordt geïmplementeerd. In dit voorbeeld wordt een gesimuleerd IoT-clientapparaat geïmplementeerd en worden apparaatdubbels gebruikt om de aangepaste domeinnaam voor het opslagaccount te vervangen.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
- Katrien De Graeve | Software Engineer
- Vincent Misson | Cloud Solution Architect
Andere inzender:
- Nacim Allouache | Cloud Solution Architect
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stap
Meer informatie over het uploaden van bestanden met IoT Hub.