Amazon Web Services ブログ

SysAid が AWS IoT Core を使用して、制限されたファイアウォール ルールの背後にあるエージェントを管理する方法

このブログは、Doron Bleiberg と Jonathan Yom-Tov によって書かれた How SysAid manages agents behind restricted firewall rules with AWS IoT Core を翻訳したものです。

このブログでは、SysAid が AWS IoT Core と MQTT over WebSocket セキュア通信プロトコルを大規模に使用して、リモートソフトウェアエージェントを管理し、制限されたファイアウォールルールを安全に克服安全に利用するする方法について概説します。 SysAid はグローバルで何千もの顧客に、IT サービス管理（ITSM）および資産管理ソリューションを Software as a service(SaaS) automation によって提供している企業です。

イントロダクション

SysAid ソフトウェア エージェントは、お客様のサイトにインストールされます。エージェントは、コンピューターやプリンターなどの IT リソースからテレメトリとステータスを収集し、AWS で実行されている SysAid SaaS サービスに中継します。場合によっては、SaaS バックエンドがエージェントに到達し、構成変更などの特定のアクションを実行するように指示する場合があります。

通信を有効にするための最も簡単な解決策は、エージェントが特定の許可された IP とポートでクラウドとの接続を開始し、最新の指示を定期的にポーリングすることです。ただし、この方法では大量のネットワーク トラフィックが発生します。たとえば、エージェントが 1 秒に 1 回ポーリングする場合、1 日あたり 86,400 件のリクエストになります。数千人を超える顧客から、1 か月に数十億件以上のリクエストが簡単に発生する可能性があります。さらに、95% 以上の時間、サーバーにはエージェントを待っているメッセージがないため、このトラフィックのほとんどは冗長で不要です。さらに、企業のファイアウォールは、インバウンドおよびアウトバウンドのトラフィックが狭い範囲の TCP ポートで送信されるように制限することがよくあります。これは、考えられるサイバー攻撃の攻撃面を制限するためのセキュリティ対策として行われます。HTTPS トラフィック (ポート 443) などのプロトコルの標準ポートは開いたままですが、MQTT (ポート 8883) などのあまり一般的でないプロトコルに使用されるその他のポートは、意図的にブロックされる場合があります。制御できない IT 環境で最終的に使用される IoT デバイスを製造している場合、デバイスが AWS IoT Core で実行されている IoT アプリケーションに接続できるようにするために、ファイアウォールでポート 8883 を開くように各顧客の IT 部門と個別に交渉することは、深刻な頭痛の種になる可能性があります。

AWS IoT Core は、ポート 443 での TLS クライアント認証による MQTT をサポートしていますが、一部の SysAid クライアントは、特定の IP アドレスへの送信トラフィックのみを許可します。AWS IoT Core エンドポイントは時間の経過とともに継続的に変化する IP アドレス範囲に解決されるため、SysAid はソリューションを必要としていました。さもなければ、エージェントは顧客のファイアウォールの背後で接続できません。次の原則は、ソリューションにとって重要でした：

  • 空のポーリング応答を回避することで、エージェントのトラフィックを減らします。
  • 数万のエージェントと数十億のメッセージの大規模なサポート。
  • 転送時にトラフィックを暗号化します。
  • 切断から回復する機能。
  • エージェントを認証および承認する機能により、エージェントは、エージェント専用のメッセージのみを受信できます。
  • マネージドサービスであること。インフラストラクチャを管理するという、差別化されていない重労働を回避します。

ソリューションの概要

SysAid は、サーバーのプロビジョニングや管理を必要とせずに、クラウドや他のデバイスへの任意の数のデバイスとの安全な接続を可能にするため、ソリューションに AWS IoT Core を選択しました。

AWS IoT Core を使用すると、デバイスの承認を管理し、一意の ID を大規模にプロビジョニングできます。さらに、そのメッセージブローカーにより、SysAid エージェントのフリート全体で信頼性が高く高速な MQTT 通信が可能になります。

MQTT のパブリッシャー/サブスクライバー モデルを使用すると、SysAid は冗長なポーリングを回避できます。代わりに、SysAid のサーバーは必要な場合にのみエージェントにメッセージを送信し、トラフィックを大幅に削減します。

次のようなトピック構造を使用します：

customer-id/device-id/message-subject

メッセージは、アカウント customer-b のエージェント customer-a に直接送信できます。したがって、トピックにメッセージを送信することで、構成の変更を通知できます：

customer-b/computer-a/configuration-changes

computer-a 上のエージェントは、次のようなトピックフィルタにサブスクライブすることで、エージェント宛てのすべてのメッセージを受信できます。

customer-b/computer-a/#

トピック フィルター ワイルドカードは、エージェントが複数の構成トピックをサブスクライブするために使用できます。エージェントがすべての受信メッセージを処理できない場合に、エージェントの過負荷を避けるために、これは注意して処理する必要があります。

ただし、デバイスが常に接続されるとは限りません。場合によっては、バックエンド サービスが構成の変更をデバイス トピックに送信しますが、オフラインのデバイスはそれを受け入れることができません。

AWS IoT Core には、デバイスの接続の問題を解決するのに役立つ 2 つの機能があります：

  • AWS IoT Core の retained messages – この機能を使用すると、特定の MQTT トピックごとに単一のメッセージを保存して、現在および将来のトピックサブスクライバーに配信できます。
  • AWS IoT Device Shadow サービス – Shadow は、デバイス、アプリ、およびその他のクラウド サービスがデータを共有するための信頼できるデータストアを提供します。デバイス、アプリ、その他のクラウド サービスは、デバイスの状態を失うことなく接続および切断できます。

SysAid エージェントは、保持されたメッセージを使用して、切断後にトピックを再サブスクライブするときに、初期構成メッセージを受信できます。

また、これによりセキュリティがどのように向上しますか?

セキュリティ モデルは単純です。 AWS IoT は、モノの管理に役立つモノのレジストリを提供します。モノは、特定のデバイスまたは論理エンティティの表現です。AWS IoT に接続されたすべてのデバイスは、モノのレジストリにモノの表現を持っています。

デバイスが x.509 証明書を使用して認証できるようにするには、証明書を登録し、IoT ポリシーに関連付ける必要があります。

IoT ポリシーは、デバイスに付与される承認を設定します。たとえば、特定のトピックの connect、publish、subscribe などの特定のアクションにデバイスを制限できます。

Thing-Certificate-Policy

以下は、AWS IoT Core ポリシー変数を使用して、デバイスが独自のトピックのみを publish および subscribe できるようにするポリシーの例です。

{
  "Version": "2012-10-17",
  "Statement": [
  {
      "Action": "iot:Connect",
      "Effect": "Allow",
      "Resource": "arn:aws:iot:<regoin>:<account>:client/${iot:Connection.Thing.ThingName}"
    },
    {
      "Action": [
        "iot:Receive",
        "iot:Publish"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:iot:<regoin>:<account>:topic/customer-a/${iot:Connection.Thing.ThingName}/*"
      ]
    },
    {
      "Action": [
        "iot:Subscribe"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:iot:<regoin>:<account>:topicfilter/customer-a/${iot:Connection.Thing.ThingName}/*"
      ]
    }
  ]
}

このポリシーがモノのポリシー変数を使用して、承認を簡単にできる方法に注目してください。モノごとにポリシーを生成する代わりに、モノの名前を変数として取り、そのモノを独自のトピックに制限する単一のポリシーを持つことができます。

セキュリティと規模の問題に対処した後も、SysAid は、ファイアウォールが特定の IP とポートのアウトバウンドトラフィックを制限するという課題を克服する必要がありました。

ここで、AWS IoT Core の広さと深さが役立ちます。AWS IoT Core は、エッジ デバイスを AWS に接続する際の柔軟性を可能にする多数のプロトコルと認証方法をサポートしています。

エージェントは、MQTT over WebSockets プロトコルを使用して、静的 Elastic IP アドレスに接続され、SysAid VPC で実行されているポート 443 でリッスンする Web プロキシサーバーにメッセージを中継できます。

次に、HTTP プロキシはトラフィックを AWS IoT エンドポイントに転送します。

MQTT over WebSocket プロトコルは、次の 2 つの認証方法をサポートしています：

SigV4 を使用するには、エージェントがデバイス証明書ではなく SigV4 資格情報を使用して AWS IoT Core に接続する必要があります。SigV4 認証情報を取得するために、エージェントは AWS IoT Core 認証情報プロバイダーを使用します。これにより、組み込みの X.509 証明書を一意のデバイス ID として使用して AWS リクエストを認証できます。これにより、アクセス キー ID とシークレット アクセス キーをデバイスに保存する必要がなくなります。

アーキテクチャ図:

Architecture

リクエストフロー:

  1. エージェントは正常な静的 IP を解決します。
  2. エージェントは SigV4 クレデンシャルを取得します。
  3. エージェントはリクエストに署名し、それを Web プロキシに送信します。
  4. ウェブ プロキシがリクエストを AWS IoT Core エンドポイントに転送します。

Web プロキシ DNS は、Route 53 DNS フェイルオーバー構成を使用して管理されます。単純な構成では、example.com のタイプ A の加重レコードのグループなど、すべて同じ名前とタイプを持つレコードのグループを作成します。次に、対応するリソースの正常性をチェックするように Route 53 を設定します。次に、HTTP プロキシはトラフィックを AWS IoT エンドポイントに転送します。

まとめ

この投稿では、SysAid が AWS IoT MQTT over WebSocket Secure を使用して、制限されたファイアウォール ルールの背後にある多数のソフトウェア エージェントを管理する方法の概要を説明しました。AWS IoT のモノは、物理デバイス以上のものと考えることができることを示しました。

著者について

Doron Bleiberg は、Amazon Web Services のシニア スタートアップ ソリューションアーキテクトです。彼は AWS のお客様と協力して、クラウドで安全で回復力があり、スケーラブルで高性能なアプリケーションを設計できるよう支援しています。

Jonathan Yom-Tov は SysAid Technologies Ltd のシニア アーキテクトで、ビッグデータ、データ マイニング、クラウドを専門としています。

このブログは、ソリューションアーキテクトの戸塚智哉が翻訳しました。