IoT Platform

IoTプラットフォームとは、IoTデバイスの接続管理、データ収集・分析、アプリケーション開発を統合的に提供するクラウドベースのサービス基盤です。代表的なサービスとして、AWS IoT Core、Azure IoT Hub、Google Cloud IoTがあり、デバイスの認証・認可、暗号化通信、OTA（Over-the-Air）アップデート、デバイスツイン/シャドウなどの機能を提供しています。

IoTプラットフォームのセキュリティは、数十万〜数百万台規模のデバイスを一元管理する必要があるため、従来のITシステムとは異なるスケーラブルなセキュリティアーキテクチャが求められます。デバイスのライフサイクル全体（プロビジョニング、運用、廃棄）を通じたセキュリティ管理、デバイスとクラウド間の双方向通信の保護、テレメトリデータの機密性・完全性の確保が重要な課題です。

プラットフォームの選定においては、セキュリティ機能の充実度が最も重要な判断基準の一つです。X.509証明書によるデバイス認証、IAMとの統合による細粒度のアクセス制御、通信の暗号化、監査ログ、脅威検知機能などを総合的に評価する必要があります。また、業界固有の規制（医療、自動車、産業制御）への準拠状況や、マルチクラウド・ハイブリッド環境への対応力も考慮すべきポイントです。

AWS IoT Coreのセキュリティ機能

AWS IoT Coreは、X.509クライアント証明書を用いた相互TLS認証を基本としたデバイス認証を提供しています。各デバイスに固有の証明書を割り当て、AWS IoT Device Defenderによりデバイスの異常動作を検知します。IoTポリシーによるMQTTトピックレベルの細粒度アクセス制御、AWS IAMとの統合、CloudTrailによる監査ログが利用可能です。

Device Shadow（デバイスシャドウ）は、デバイスの状態をJSON形式でクラウドに保持する仕組みで、デバイスがオフライン時でもアプリケーションからデバイスの状態を参照・更新できます。セキュリティの観点では、Device Shadowへのアクセス制御ポリシーの適切な設定と、シャドウデータの暗号化が重要です。

Azure IoT Hubのセキュリティ機能

Azure IoT Hubは、SAS（Shared Access Signature）トークンとX.509証明書の両方をサポートするデバイス認証を提供しています。Azure IoT Hub Device Provisioning Service（DPS）により、大規模なデバイスのゼロタッチプロビジョニングが可能です。Microsoft Entra ID（旧Azure AD）との統合により、ユーザーとアプリケーションのアクセス制御も統合的に管理できます。

Device Twin（デバイスツイン）は、デバイスのメタデータ、構成、状態を格納するJSONドキュメントで、desired propertiesとreported propertiesの同期メカニズムを提供します。Azure Defender for IoT（現Microsoft Defender for IoT）は、エージェントレスの資産検出、脆弱性管理、脅威検知を提供し、OT/ICS環境のセキュリティ監視にも対応しています。

Google Cloud IoTのセキュリティ機能

Google Cloud IoTは、JWT（JSON Web Token）ベースの認証とRSA/ECDSAによるデバイス認証を提供しています。Cloud IAMによるプロジェクトレベルのアクセス制御、Cloud Pub/Subを活用したスケーラブルなメッセージング、BigQueryとの連携による大規模テレメトリ分析が特徴です。

デバイスの構成管理機能により、クラウドからデバイスへの設定変更をセキュアに配信でき、デバイスの状態レポートにより継続的な監視が可能です。なお、Google Cloud IoT Coreは2023年にサービス終了となり、パートナーソリューションへの移行が推奨されていますが、Cloud IoTの設計パターンとセキュリティモデルは他のプラットフォームにも応用可能です。

デバイスツイン/シャドウのセキュリティ

デバイスツイン/シャドウは、物理デバイスの仮想的な表現をクラウド上に維持する仕組みです。この機能により、デバイスとクラウド間の状態同期、オフラインデバイスの管理、構成の一括変更が可能になりますが、セキュリティ上の考慮が必要です。

デバイスツインには、ファームウェアバージョン、ネットワーク設定、センサーキャリブレーション値など、攻撃者にとって有用な情報が含まれる場合があります。不正なデバイスツインの更新により、デバイスの設定を改ざんして誤動作を引き起こすことも理論的に可能です。デバイスツインへのアクセスは最小権限の原則に基づき厳格に制御し、変更履歴の監査ログを有効にしてください。

プラットフォーム選定のセキュリティ基準

IoTプラットフォームの選定時には、以下のセキュリティ基準を総合的に評価することが重要です。デバイス認証方式（X.509証明書、TPM連携、HSM連携）の柔軟性、通信暗号化（TLS 1.2/1.3対応）の完全性、アクセス制御の粒度（デバイス単位、トピック単位、リソース単位）、OTAアップデートのセキュリティ（署名検証、ロールバック機能）を確認しましょう。

また、セキュリティ監視・脅威検知機能の有無、コンプライアンス認証（SOC 2、ISO 27001、HIPAA、IEC 62443）の取得状況、インシデント発生時のフォレンジック支援機能、マルチテナンシーのセキュリティ分離レベルなども重要な判断材料です。ベンダーロックインのリスクと移行容易性も、長期的なセキュリティ戦略の観点から考慮が必要です。

• 01
  デバイス認証にX.509証明書を使用：共有キーやパスワード認証ではなく、デバイスごとに固有のX.509クライアント証明書を発行し、相互TLS認証を実装してください。証明書の有効期限管理と自動ローテーション、CRL/OCSPによる失効管理も必ず構築しましょう。
• 02
  最小権限のアクセスポリシー設計：各デバイスが必要とする最小限のリソース（MQTTトピック、API、Device Shadow）にのみアクセスを許可するポリシーを設計してください。AWS IoTポリシー、Azure IoT Hubの共有アクセスポリシー等を活用し、ワイルドカードの使用を最小限に抑えましょう。
• 03
  セキュアなデバイスプロビジョニング：デバイスの初期設定時に、安全な方法で認証情報を配布してください。Just-in-Timeプロビジョニング（JITP）やFleet Provisioning等の自動化メカニズムを活用し、手動での認証情報設定を排除しましょう。製造段階でのセキュアエレメント埋め込みも検討してください。
• 04
  デバイスの継続的セキュリティ監視：AWS IoT Device Defender、Azure Defender for IoT等のセキュリティ監視サービスを有効化し、デバイスの異常動作（通常と異なる通信パターン、不正なAPI呼び出し、認証失敗の急増）をリアルタイムで検知してください。
• 05
  OTAアップデートのセキュリティ確保：ファームウェアアップデートにはコード署名を必ず適用し、デバイス側で署名検証を行ってください。アップデートの段階的ロールアウト（カナリアデプロイメント）とロールバック機能を実装し、不正なアップデートによる大規模障害を防止しましょう。
• 06
  テレメトリデータの暗号化と分離：デバイスからクラウドへのテレメトリデータは、転送時の暗号化（TLS）に加え、保存時の暗号化（AES-256等）も適用してください。テナント間のデータ分離を確認し、機密データのマスキングやトークナイゼーションも検討しましょう。