Amazon Web Services ブログ

グローバルに展開されている IoT ワークロードを保護する一元化されたダッシュボードを設計する

はじめに

ドイツ鉄道Carrier などの企業は大規模なモノのインターネット(IoT)プロジェクトに投資し、世界規模の IoT プラットフォームを展開しています。企業は、 IT 運用と OT 運用の両方に対応するマルチテナントの一元化されたデバイスライフサイクルマネジメント(DLM)ダッシュボードを提供するソリューションを探しています。

このブログでは、サイバーセキュリティ体制のためのマルチテナント型の一元化された IoT プラットフォーム管理用ダッシュボードを構築する方法について、AWS Prescriptive Guidance 示すことに焦点を当てます。さまざまな業界のあらゆる形態や規模の企業が、このようなプラットフォームの恩恵を受けることができます。IT の観点から見ると、このプラットフォームは、デバイスのオンボーディング、可視性、ガバナンスなど、企業の IoT 関連のサイバーセキュリティ機能を標準化します。 OT の観点から見ると、面倒な作業(アカウント管理、ワークロード管理、セキュリティなど)はすべて初日からプラットフォームに組み込まれているため、プラットフォームは本番稼働までの時間を短縮できます。

AWS サービス

このガイダンスブログでは、いくつかの AWS サービスを参照します。これらのサービスは、一元化されたダッシュボード設計のリファレンスアーキテクチャとベストプラクティスにおいて不可欠な部分です。

AWS Organizations は、複数の AWS アカウントを、お客様が作成した組織に集約し、一元管理することができるアカウント管理サービスです。AWS Organizations には、ビジネスの予算、セキュリティ、コンプライアンスのニーズをより適切に満たすことができるアカウント管理機能と統合請求機能が備わっています。詳細については、AWS Organizations を参照してください。

AWS IoT Core を使用すると、インフラストラクチャを管理しなくても、数十億台の IoT デバイスを接続し、何兆ものメッセージを AWS サービスにルーティングできます。AWS IoT Core は、さまざまな通信プロトコルと接続方法をサポートしています。詳細については、AWS IoT Core を参照してください。

AWS IoT Device Defender は AWS IoT Core とネイティブに統合されており、デバイスの設定を監査したり、接続されたデバイスを監視して異常な動作を検出したり、セキュリティリスクを軽減したりできるセキュリティサービスです。詳細については、AWS IoT Device Defender を参照してください。

AWS Security Hub は、セキュリティのベストプラクティスチェックを行い、アラートを集約し、自動修正を可能にするクラウドセキュリティ体制管理サービスです。AWS のセキュリティ状態を包括的に把握でき、環境をセキュリティ業界の標準やベストプラクティスに照らして確認するのに役立ちます。詳細については、AWS Security Hub を参照してください。

Amazon EventBridge は、さまざまなソースからのデータとアプリケーションを接続するために使用できるサーバーレスのイベントバスサービスです。EventBridge は、アプリケーション、Software as a Service(SaaS)アプリケーション、AWS サービスのリアルタイムデータストリームを、AWS Lambda 関数、API 送信先の HTTP エンドポイント、または他の AWS アカウントのイベントバスなどのターゲットに配信します。詳細については、Amazon EventBridge をご覧ください。

ユースケース紹介

図1.ソリューションの概要を示す構成図

図1は、解決したい問題の概要を示しています。ここでは、製油所 (Refinery) 、燃料電池 (Fuel Cells) 、潤滑油 (Lubricants) の3つのワークロードの例を示しています。これらのユースケースはそれぞれ、個別の AWS リージョンに独自の IoT を展開しています。アーキテクチャ内には、ユースケースごとのビジネスユーザーと IoT プラットフォーム管理者という 2 つの異なるペルソナが表示されます。各ビジネスユーザーのペルソナは、それぞれ独立して展開された IoT ワークロードにアクセスする必要があります。この場合、製油所ビジネスユーザーは、製油所設備にアクセスするための認証と承認が必要です。潤滑油ビジネスユーザーは潤滑油の IoT ワークロードにアクセスする必要がありますが、製油所など他のワークロードにはアクセスできません。一方、リージョン、アカウント、ユースケースに関係なく、すべてのワークロードにアクセスする必要がある IoT プラットフォーム管理者がいます。さらに、IoT セキュリティ管理者は、導入されたすべてのワークロードのセキュリティ状況にアクセスして可視化する必要があります。また、証明書の有効期限切れなどにも注意する必要があります。

テナントモデル

図2.このアーキテクチャのテナントタイプ図

前述のユースケースでは、IoT ワークロードを完全に分離するテナント方式を採用することで、設計の基礎を築きたいと考えてます。高度に分離されたテナント設計により、コスト、データ、ワークロードが分離されます。これにより、AWS アカウントにデプロイされたリソースの管理が容易になり、OT ビジネスユーザーが分離した IoT ワークロードの基盤を構築できると同時に、IT プラットフォーム管理者やセキュリティペルソナにグローバルな洞察を提供できます。このテナント方式では、ビジネスユーザーとそのデバイスに各自のテナントワークロードからアクセスできるため、セキュリティの観点からも影響範囲が狭くなります。このタイプのテナントには、テナントのメッシュ化、コストの可視化、グローバルなデバイス管理のための一元化された IoT プラットフォームのダッシュボード実装に関連する独自の課題が伴います。

コントロール、データ、エッジプレーン

図3.コントロール、データ、エッジプレーンの視覚化

上の図1と図2のように、制御に関連するすべてのユースケースが IoT プラットフォームと呼ばれる単一の共通インターフェースを通じて実現されるように、コンポーネントを区分化できます。このコンポーネントは、あらゆるペルソナの一元化された IoT デバイス管理ポータルダッシュボードとして機能します。このコンポーネントは制御に関連しているため、このコンポーネントを「コントロールプレーン」と呼ばれる概念上の境界内に格納できます。

個別のテナント固有のワークロードコンポーネントは「IoT ワークロード」として指定されます。これらはデバイスが接続してテレメトリを送信する独立したワークロードであるため、これらの隔離されたテナント固有のコンポーネントは、「データ/テレメトリプレーン」と呼ばれる概念の境界内に収容できます。個々の企業が管理するすべてのデバイスを、その事業全体に展開して、「エッジプレーン」と呼ばれる概念の境界内に配置できます。

個々の IoT ワークロードは (n) 個のアクセラレータで構成できます。これらのアクセラレータは、デバイスのプロビジョニング、デバイスの制御と指示、デバイスのパッチ適用、AWS IoT Greengrass Core のプロビジョニングなどの独自の機能を実行できます。機能またはユースケース固有のアクセラレータの詳細については、AWS Connected Device Framework を参照してください。このフレームワークは、このアーキテクチャの基本的な構成要素として役立ちます。

AWS Organizationsによるアカウントの分離

図4.AWS Organizationsと組織単位 (OU) を使用したアカウントとアクセス管理

現在は、AWS 固有のサービスを使用してガイダンスを拡張しています。この場合の AWS Organizations では、お客様が組織単位 (OU) 内のアカウントに機能を提供する OU を使用することを許可しています。すべての OU は、アカウントに独自のガードレールを適用し、テナントアカウントにもガバナンスを適用します。図4では、3つの異なる OU を使用しています。

1/ 共有サービスOU

一元化されたダッシュボードは共有サービス OU 内にあります。集約されたダッシュボードをホストする独自のアカウントを持っています。この場合の OU は、独自のプラットフォームに機能を提供し、さまざまなユーザータイプに、閲覧が許可されているデータへのアクセスを許可します。

2/ ワークロードOU

ワークロード OU ホストには複数のアカウントがあり、テナントごとに 1 つのアカウントがあります。これにより、ユーザーは一元化されたダッシュボードから自分のワークロードと IoT デバイスからのアウトバウンドおよびインバウンドデータにアクセスできます。

3/ 停止中のOU

一時停止中の OU のワークロードはアクティブではなくなりますが、それでも AWS 内のセットアップの一部であるため、後で調査したり、不要になったら削除したりできます。この停止は、システム管理者が定義した基準に基づいて自動的に行われます。

イベント駆動型ソリューション

図5. Amazon EventBridge と AWS IoT Core の統合。

このセクションでは、AWS IoT Core と統合された Amazon EventBridge の使用を追加しています。このアプローチにより、コントロールペインまたは一元化されたダッシュボードとやり取りするイベント駆動型ソリューションが可能になります。コントロールプレーンアカウントには、個々のワークロード OU アカウントとの間でメッセージを送受信するように Amazon EventBridge が設定されます。この統合により、アカウント内のさまざまな IoT ワークロードを呼び出すことができます。また、個々のデバイスからデータを収集して、コントロールプレーンアカウントに集約されたビューを表示することもできます。クロスアカウントにやり取りするには特定の権限が必要です。詳細についてはサービスコントロールポリシー (SCP) のドキュメントをご覧ください。

ワークロード OU アカウントは、コントロールプレーン側からのメッセージをサブスクライブします。その逆も同様です。各ワークロードは個別のテナントアカウントによって分離されているため、コストの分離も可能になり、必要なテナントモデルを実現できます。

一元化されたアーキテクチャ

図6.マルチリージョン、マルチアカウント IoT ワークロードを監視および管理するための最終アーキテクチャ

最後に、すべての要素を含む一元化されたダッシュボードを持つアーキテクチャ図(図6)に注目しましょう。

右側から始めて、複数のデバイスが AWS IoT Core に接続されています。まず、AWS IoT Core からワークロードへの接続に注目します。ワークロードが AWS IoT Core 経由で IoT デバイスとやり取りするので、Amazon EventBridge は特定のイベントに反応するように設定できます。その後、これらのイベントは一元化されたダッシュボードを持つアカウントに渡され、ユーザーは関連するデータとアラームにのみアクセスできます。

次に、右側の AWS IoT Core から AWS IoT Device Defender への接続に注目します。AWS IoT Core とネイティブに統合された AWS IoT Device Defender は、監査とモニタリングのタスクを実行し、異常や違反があれば報告パイプラインに報告します。また、AWS IoT Device Defender は AWS Security Hub とネイティブに統合されており、監査結果をこのサービスに配信するように設定できます (ネイティブ統合の詳細については、こちらをご覧ください)。それぞれ、AWS Security Hub はクロスアカウントに統合されており、IT 管理者にアラームを配信し、必要に応じて操作を運用に委任します。

このアーキテクチャにより、セキュリティ運用チームと IoT プラットフォーム管理者が、さまざまなアカウントや地域のセキュリティに関する洞察や調査結果にアクセスできます。

AWS Security Hub を使用するセキュリティ運用チームと共有すべき異常の例としては、次のようなものがあります。

  • MQTT ベースのデータ流出:データ流出は、悪意のある攻撃者が IoT 設備またはデバイスから不正なデータ転送を行った場合に発生します。攻撃者は、MQTT を介してクラウド側のデータソースに対してこの種の攻撃を仕掛けます。
  • なりすまし:なりすまし攻撃とは、攻撃者が既知または信頼できるエンティティになりすまして AWS IoT クラウド側のサービス、アプリケーション、データにアクセスしたり、IoT デバイスの指揮統制を行ったりすることです。
  • コマンドアンドコントロール、マルウェア、ランサムウェア:マルウェアまたはランサムウェアは、デバイスに対する制御を制限し、デバイスの機能を制限します。ランサムウェア攻撃の場合、ランサムウェアが使用する暗号化によりデータアクセスが失われます。

AWS IoT Device Defender の対象となるさまざまなセキュリティユースケースについて詳しく知りたい場合は、こちらをご覧ください。

まとめ

このブログ記事では、企業全体のセキュリティ運用を検討する際に、マルチテナント IoT ワークロードを一元管理するための考慮事項について説明しました。このアプローチにより、 IT チームと OT チームはサイバーセキュリティ体制を一元管理できるだけでなく、既存のベストプラクティスや組織要件の標準化を促進できます。

AWS IoT ソリューションと環境全体のセキュリティを向上させる方法についてさらに学び、読むには、以下のブログ投稿をご覧ください。

AWS IoT 環境用のマルチテナントアーキテクチャの設計と構築について詳しく知りたい場合は、このワークショップに参加してください。

著者について

Katja-Maja Kroedel は、AWSの IoT スペシャリストソリューションアーキテクトです。彼女は AWS のお客様と協力して、IoT 分野におけるクラウドの導入、移行、戦略に関するガイダンスを提供しています。彼女はテクノロジーに情熱を注いでおり、AWS IoT Device Defender などの革新的なサービスを使って、クラウドで構築したり実験したりすることを楽しんでいます。Katja はコンピューターエンジニアリングのバックグラウンドを持ち、既に AWS でさまざまな役職を経験してきました修士論文を皮切りに、ドイツでジェネラリストソリューションアーキテクトとして、中小規模のお客様の成長とクラウドの学習を支援しています。
Leo Da Silva は AWS のセキュリティスペシャリストソリューションアーキテクトであり、その知識を活かして、お客様がクラウドサービスとテクノロジーをより安全に活用できるよう支援しています。長年にわたり、彼は大規模で複雑な環境で働き、グローバル企業向けの拡張性が高く安全なソリューションを設計、設計、実装する機会を得ました。彼はサッカー、バーベキュー、柔術に情熱を注いでいます。柔術はすべてブラジル版です。
Hassan Khokhar は、Proserve の新興技術、エンジニアリング、ロボティクスの分野で活躍するシニアIoT アーキテクトです。Hassan は、IoT の実装を加速するためのフレームワークとソリューションを設計および構築することで、顧客にとって困難な問題を解決することが大好きです。何年にもわたって、彼は中小企業から大企業まで、IoT プラットフォームの提供と導入の拡大を支援する機会を得ました。

この記事はKatja-Maja Kroedel と Leo Da Silva と Hassan Khokhar が執筆した Designing a Single Pane of Glass for Securing your Globally Deployed IoT-Workload をソリューションアーキテクトの服部が翻訳いたしました。