コスト制約を考慮したIOTハブ＋イベントハブの結合方法

概要
本稿では、厳格なコスト要件を満たしながら、IOTハブとイベントハブを安全に組み合わせる多数の独立したIOTデバイスの管理方法について議論したい.提案されたアーキテクチャは、テレメトリデータingestorとして雲ツー装置メッセージとイベントハブのために1つのティアIotハブを持っています.
関連するサンプルコードをここで見つけることができます.koheikawata/weather-app
コスト制約がなければ

コスト制約を考慮した最終アーキテクチャ


TOC

Context

Problem

Workaround

Option 1: Event Hubs + Iot Hub

Option 2: Event Hubs Publisher Policy

Additional workaround

Option 3: Event Hubs Publisher Policy + S1 tier IoT Hub

Conclusion

References

文脈
このプロジェクトでは、既存のデバイスからテレメトリデータを格納し、テーブルストレージに格納するAzureのクラウドベースのIOTアーキテクチャを構築しています.いくつかのアーキテクチャのオプションを考慮した後、我々はイベントコストを厳密なコスト要件を満たすためにIOTハブの代わりにイベントingestorとして使用することを決めた.以下のリンクは、イベントハブ、関数、テーブルストレージを使用するアーキテクチャを決定する方法を示しています.

先行研究リンク

問題
遠隔測定データは、異なるエンドユーザーによって所有されるデバイスから、イベントハブに送られる.各登録デバイスのユニークなアクセスキーを作成することができますiOTハブとは異なり、イベントハブは基本的に別のエンドユーザーのデバイスの数千に同じアクセスキーを提供します.これは、悪い俳優がデバイスIDをランダムに推測してシステムを攻撃する他のエンドユーザを偽装することを可能にするか、誤ってデバイスIDを誤って追加すると、システムの誤報や有害な行為を引き起こすことになります.以下の図は、Device 2が間違った(または偽)を使用する例を示しますdeviceId アクセスする.


回避策
我々は、この問題を解決する2つのオプション、イベントハブ+ IOTハブとイベントハブ発行者ポリシーを検討した.

オプション1:イベントハブ+ IOTハブ

One option of workaround for this problem is to have IoT Hub in front of Event Hubs. IoT Hub has the message routing feature that enables you to send messages to Event Hubs with IoT Hub's credential. This means each device has an unique credential created by IoT Hub so a bad actor cannot impersonate others.

オプション2:イベント抱擁出版者方針 Another option is to use Event Hubs publisher policy . イベントハブにメッセージを送るとき、それは各々の装置がユニークな識別子を持つのを許します.Azure関数はイベントハブを通してメッセージを受け取り、発行者識別子とdeviceId マッチする.

出版者方針なしで

イベントハブ発行者ポリシーを持っていない場合、異なるデバイスは同じアクセスキーを使用します.どのデバイスが与えられたかを識別する方法を考慮する必要があります.つの簡単な方法を読むことですdeviceId JSONメッセージについてこの場合、悪いアクターは偽のIDを使用して、他のデバイスを装って、潜在的に悪い/無効なデータをシステムに注入することができます.

発行者ポリシー

イベントハブは、1つのアクセスキーを生成するが、各デバイスはユニークなShared Access Signature デバイスが認証し、イベントハブに接続できるトークン.Azure関数はチェックアウトできるdeviceId SASトークンからJSONメッセージとシステムプロパティの両方に、どのデバイスが指定されたメッセージを送信したかを確認します.
イベントHUB名前空間名、イベントハブ名、共有アクセスポリシー名、共有アクセスポリシーキー、デバイスIDの情報を使用してSASトークンを生成できます.ここで重要なのは、リソースURIを発行者名(=デバイスID)で使用することです.この発行者ポリシーを使用すると、Azure関数は発行者名を識別子として受け取ることができます.
リソースURI

<Event Hubs Namespace>.servicebus.windows.net/<event hub name>/publishers/<Publisher>

このシステムを構築するには、次の3つの手順を実行します.
1 .共有アクセスポリシーを追加する
イベントHUB名前空間の下に新しいイベントハブを作成すると、イベントハブ内の共有アクセスポリシーはまだ見つかりません.イベントハブに新しい共有アクセスポリシーを追加し、Send パーミッションは、イベントハブにメッセージを送信するためのSASトークンを作成するために使用されます.以下の図は、イベントハブという名前の例を示しますtelemetry つの共有アクセスポリシーを追加します.一つはイベントハブにメッセージを送る装置です.のアクセスキーでSend 共有アクセスポリシーのアクセス許可は、異なるデバイスのSAsトークンを生成できます.別の共有アクセスポリシーListen イベントのハブを通じてメッセージを受信するAzure関数で使用されるアクセス許可.

2 . SASトークンの生成
以下の想像上の実体で、具体的なC -経線コード例を持ちましょう.

string eventHubNamespaceName = "kokawata";
string eventHubName = "telemetry";
string deviceId = "0001";
string sharedAccessPolicyName = "send1";
string sharedAccessPolicyKey = Environment.GetEnvironmentVariable("EventhubSharedAccessPolicyKey");  // Retrieve the access key 

string sasToken = CreateToken($"https://{eventHubNamespaceName}.servicebus.windows.net/{eventHubName}/publishers/{deviceId}", sharedAccessPolicyName, sharedAccessPolicyKey);

private static string CreateToken(string resourceUri, string sharedAccessPolicyName , string sharedAccessPolicyKey)
{
    TimeSpan sinceEpoch = DateTime.UtcNow - new DateTime(1970, 1, 1);
    var week = 60 * 60 * 24 * 7;
    var expiry = Convert.ToString((int)sinceEpoch.TotalSeconds + week);
    string stringToSign = HttpUtility.UrlEncode(resourceUri) + "\n" + expiry;
    HMACSHA256 hmac = new HMACSHA256(Encoding.UTF8.GetBytes(sharedAccessPolicyKey));
    var signature = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(stringToSign)));
    var sasToken = String.Format(CultureInfo.InvariantCulture, "SharedAccessSignature sr={0}&sig={1}&se={2}&skn={3}", HttpUtility.UrlEncode(resourceUri), HttpUtility.UrlEncode(signature), expiry, sharedAccessPolicyName);
    return sasToken;
}

上記の例で生成されたシグネチャ文字列は以下のようになります.

SharedAccessSignature sr=https%3a%2f%2fkokawata.servicebus.windows.net%2ftelemetry%2fpublishers%2f0001&sig=O%2fyCNybODjonBNZduHAomdx7RW22V9rNiixG7hrMX8o%3d&se=1629446016&skn=send1

それから、あなたはEventHubProducerClient イベントのハブと共有のアクセスポリシー情報を持つインスタンスは、デバイスCの経理のアプリは、接続することができますイベントハブにメッセージを送信します.

EventHubProducerClient producerClient = new ($"https://{eventHubNamespaceName}.servicebus.windows.net", $"{eventHubName}/publishers/deviceId", new AzureSasCredential(sasToken));

パーティションを
次のステップは検証することですdeviceId イベントハブに送られます.この例では、Azure関数のハブバインディングを使用して、取得する方法を示しますdeviceId デバイス識別を確認します.

イベントハブ発行者ポリシーを使用する場合.PartitionKey 値は発行者名(deviceId ). 以下のAzure関数のコード例では、deviceId SASトークン経由SystemProperties.PartitionKey . 次に、JSON本体に送信されたデバイスIDを比較することにより、デバイスの識別を確認できます.

[FunctionName("Function1")]
public static async Task Run([EventHubTrigger("telemetry", Connection = "EventHubConnectionString")] EventData[] events, ILogger log)
{
     foreach (EventData eventData in events)
     {
          string partitionKey = eventData.SystemProperties.PartitionKey;

追加回避策
上記の両方のオプションのために解決するいくつかの問題があります.
オプション1の欠点
イベントのハブに加えてiotハブを持つので、我々はこのオプションを取ることはありません.IOTハブ層がS 1ならば十分に良いでしょうが、1日につき1200万のメッセージを持つデータingestorとしてのIOTハブはS 3層を必要とします.まず第一に、私たちがイベントハブを使用することに決めた理由は、多くのメッセージのためにIoTハブをS 3層にアップグレードする必要があるということです.したがって、これは私たちのための良いオプションではありません.

オプション2の欠点
このオプションの問題はトークンリークの場合です.SASトークンが漏らされるならば、誰でもイベントハブにアクセスするためにそれを使うことができます.イベント・ハブSASトークンを無効にすることはできませんでした.あなたは、データを隔離すると同時に、漏洩SASトークンが期限切れになるまで待つ必要があります.


オプション3:イベントハブの発行者ポリシー+ S

In order to mitigate the cost problem of Option 1 and security risk of Option 2, we take Event Hubs Publisher Policy + S1 tier IoT Hub option.

• SAS token distribution: By generating SAS tokens on cloud and distributing it to devices through cloud-to-device communication, we can minimize leakage risks. With IoT Hub's Device Twin desired property, SAS tokens are automatically set in devices that connect to Event Hubs. You need to set up IoT Hub's access keys manually on devices, but IoT Hub can deal with leakage incident by disabling access keys.

• Revocation plan: We need a revocation plan if a SAS token is compromised. It would revoke the Share Access Policy and create another new policy and distribute new SAS tokens to devices again. Device Twin makes this automated operation possible.

• Cost: IoT Hub has to be S1 tier due to the cost requirement. It is used for cloud-to-device communication but not for data ingestion. Although the system expects to receive a large number of messages, the IoT Hub can stay S1 tier.

Here are key Azure resources needed for the architecture and overall workflow.

• IoT Hub (S1 tier): IoT Hub's cloud-to-device message feature enables the system to distribute SAS tokens to devices. You can send generated SAS token with Device Twin's desired property. This architecture meets the cost requirement by using S1 tier IoT Hub.

• Key Vault: During Azure resource deployment with ARM template, Shared Access policy is created and Shared Access key is stored in Key Vault.

• WebAPI: When registering a device to IoT Hub, WebAPI retrieves the Shared Access key, generate a SAS token, and add it to Device Twin property on IoT Hub.

• Device: When in device provisining, a device retrieves the SAS token on Device Twin desired property and establish a connection to Event Hubs.

Workflow

1. Azure resource deployment (Infrastructure as Code pipeline)

IOTハブデバイス登録

3 .デバイスプロビジョニング

メッセージ送信


結論
あなたが厳しいコスト要件に直面するとき、これはIOTハブとイベントハブを結合する例です.イベントハブの発行者ポリシーは、デバイスの識別に役立ちますし、IOTハブは、デバイスにSASトークンを配布することができます.我々はまだトークン取消し計画を準備して、SASトークン満了に注意を払う必要があります、しかし、このアーキテクチャはより低い運用経費を維持するのを援助することができます.

参考文献

Best practices when using SAS