Amazon Web Services ブログ
AWS IoT で最新のコネクテッドカープラットフォームを保護する
運用証明書のライフサイクル管理
図 1: AWS コネクテッド・ビークルのリファレンスアーキテクチャ – 運用証明書のライフサイクル管理。このリファレンスアーキテクチャは、運用証明書を大規模に管理する方法の概要を提供します。番号付けされたステップの詳細については、このリンクを参照してください。
運用証明書のライフサイクル・リファレンス・アーキテクチャは、車両の電子制御ユニット(ECU)の アイデンティティに関する運用証明書のプロビジョニングと管理に焦点を当てています。車両には複数の ECU が搭載されている場合があり、その多くはクラウド上のサービスに接続して車両機能を提供します。クラウドに接続する各 ECU には、これらの機能を有効にするためのサービスの認証と認可に使用される固有の アイデンティティ が必要です。一般的に使用される ECU アイデンティティは、通常は TPM(Trusted Platform Module)や HSM(Hardware Security Module)などのセキュアなソフトウェアまたはハードウェア・モジュールに格納される非対称秘密鍵と、信頼できる認証局(CA)が発行する秘密鍵に対応する X.509 証明書です。これらの証明書は、このリファレンス・アーキテクチャで説明するように、ライフサイクルを通じて安全に管理する必要があります。
証明書のプロビジョニング・プロセスは、ECU メーカーが認証証明書(出生証明書と呼ばれることもある)をプロビジョニングする工場で開始されます。このステップでは、ECU に搭載された TPM や HSM で秘密鍵を安全に生成するといったオンボード・メカニズムを使用することも、ECU 外部の HSM で鍵を生成するといったオフボード・メカニズムを使用することもできます。このステップの結果、秘密鍵と認証証明書が ECU に安全に保管されます。認証証明書がプロビジョニングされると、AWS のサービスを使用して運用証明書をプロビジョニングでき、安全でスケーラブルかつ自動化された方法でクラウドへの接続が可能になります。
秘密鍵および運用証明書の証明書署名要求(CSR)はセントラル・ゲートウェイ ECU で生成され、認証証明書は証明書ブローカーへの要求の認証と認可に使用されます。証明書ブローカは AWS プライベート認証局(AWS Private CA)を呼び出し、ECU に返される運用証明書を発行します。AWS プライベート CA は、ルート認証局や下位認証局を含むプライベートな認証局(CA)階層を、オンプレミス CA の運用にかかる投資や保守コストをかけずに作成できます。また、AWS Private CA は、証明書を失効させるための API を提供し、証明書失効リスト(CRL)やオンライン証明書ステータスプロトコル(OCSP)を介して失効を確認する仕組みを提供します。
ECU は運用証明書を使用して、TLS クライアント認証を使用して AWS IoT Core などのクラウドサービスに接続できるようになります。AWS IoT Core は、デバイスの X.509 証明書を登録するためのいくつかのメカニズムを提供しており、その詳細はホワイトペーパー「Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core」に記載されています。車載 ECU に推奨されるのは、ECU の証明書を初回接続時に AWS IoT Core に登録するジャストインタイム登録(JITR)です。AWS IoT Core は、予約された MQTT トピックに JITR メッセージを発行し、証明書を登録する前に追加のチェックを実行できるようにします。リファレンスアーキテクチャでは、予約済み MQTT トピック上の AWS IoT ルールを使用して Lambda 関数を呼び出し、OCSP を使用して証明書が失効していないことを確認し、証明書をアクティブにし、ポリシーを作成して証明書にアタッチし、AWS IoT Core で ECU を表す Thing を作成します。
何百万台もの車両がある状況では、それぞれがクラウドに接続された複数の ECU を搭載しているため、登録された証明書とポリシーを監視するのは困難な場合があります。AWS IoT Device Defender は、過度に寛容なポリシー、ID を共有するデバイス、失効した証明書や期限切れの証明書などを特定する監査チェックを実行することで支援できます。
AWS IoT Device Defender は、これらの監査結果を AWS Security Hub に送信します。AWS Security Hub は、アカウント、AWS サービス、およびサポートされているサードパーティのパートナープロバイダ全体でセキュリティイベントの発見を集約します。Amazon EventBridge を使用すると、Security Hub で特定の発見に対する自動アクションを定義できるカスタムルールを作成できます。例えば、Amazon EventBridge ルールは、AWS Step Functions ワークフローをトリガーして、証明書のローテーション、過度に寛容なポリシーの修正、アラート通知の送信、チケットの作成などのアクションを自動化できます。
暗号化とモニタリング
図2:AWS Connected Vehicle リファレンスアーキテクチャ – 暗号化とモニタリング。このリファレンスアーキテクチャは、車両データの暗号化とモニタリングの概要を提供します。番号付けされたステップの詳細については、このリンクを参照してください。
暗号化とモニタリングのリファレンスアーキテクチャは、モバイルアプリから車両にリモートコマンド(リモートスタート、車両の検索、ドアロック/アンロック、ウィンドウのアップ/ダウンなど)を送信するユースケースに焦点を当て、AWS で利用可能な暗号化とモニタリングのオプションを説明します。ユーザーは、Amazon Cognito のような ID サービスを使用してモバイルアプリを認証し、アプリを使用して Amazon API Gateway の API にリモートコマンドリクエストを送信します。API リクエストは、ユーザーの ID トークンを検証し、ユーザーがリモートコマンドを実行する権限を持っていることをチェックする Lambda オーソライザーによって認証されます。API が認証・認可されると、API Gateway は Lambda 関数を呼び出してリモートコマンドメッセージを生成します。クラウドからのリモートコマンドメッセージは、AWS IoT Core のようなクラウド内の中間サービスを通過するため、署名(真正性を証明するため)と暗号化(機密性を確保するため)が必要になる場合があります。Lambda 関数は AWS Key Management Service(AWS KMS)を呼び出し、AWS KMS に保存されている RSA または ECC 秘密鍵を使用してメッセージに署名します。さらに、関数は AWS KMS を呼び出して、AWS KMS に保存されている共通鍵を使用してメッセージを暗号化します。Lambda 関数は、AWS IoT Core の MQTT トピックを使用して、暗号化および署名されたメッセージを ECU に送信します。
ECU は MQTT トピックからリモートコマンドメッセージを受信し、AWS KMS を呼び出してメッセージを復号化する必要があります。ECUは、AWS IoT Core のクレデンシャルプロバイダーから一時的な AWS クレデンシャルを要求し、そのクレデンシャルを使用してAWS KMS への復号化コールに署名と認証を行います。次に ECU は、メッセージの署名に使用された秘密鍵に対応する公開鍵を使用して、復号化されたリモートコマンドメッセージの署名を検証します。ECUは、リモートコマンドが成功すると、機密性の高い遠隔測定データ(車両の状態や位置情報など)をクラウドに応答します。AWS IoT Core の MQTT トピックに送信する前に、AWS KMS を使用してクライアント側で機密データを暗号化することができます。データは、AWS KMS を呼び出してデータを復号化する権限を持つ Lambda 関数に到達するまで、AWS IoT Core とクラウド内の中間サービスを流れる際に暗号化されたままとなります。この関数は、AWS KMS を使用して暗号化されたテレメトリデータを Amazon DynamoDB に保存します。
AWS IoT Device Defender Detect は、接続された ECU の動作を監視することで、侵害されたデバイスを示す可能性のある異常な動作を検出します。接続された ECU データに基づいて、ルールベースまたは機械学習(ML)ベースの異常動作の検出を構成できます。例えば、AWS IoT Device Defender は、ECU の認証失敗の異常な割合(クラウド側のメトリクス)または異常なトラフィックフロー(デバイス側のメトリクス)を検出すると、検出結果を生成できます。AWS IoT Device Defender は、是正アクションのトリガーとなるファインディングを Security Hub に送信します。例えば、Step Functions ワークフローを使用して、ECU の Thing を権限のない Thing group にアタッチすることで ECU の権限を制限したり、AWS IoT Core の証明書を無効化して既存の接続を切断し、今後の接続試行を拒否したりするなどのアクションを自動化できます。
まとめ
本ポストでは、自動車業界のお客様が コネクテッドビークル・プラットフォームのセキュリティを確保する際に使用する、2つの新しい AWS リファレンスアーキテクチャについて説明しました。これらのアーキテクチャは、車両セキュリティのすべての側面をカバーすることを意図しているわけではなく、車両からクラウドへの通信を保護し、データを保護・監視し、車両データに基づいて異常な動作を検出するために、AWS サービスをどのように使用できるかに焦点を当てています。AWS 上でコネクテッドビークル・プラットフォームを設計し、セキュリティを確保するための出発点として、これらのリファレンスアーキテクチャを使用することをお勧めします。詳しくは、AWS for Automotive、AWS Security、IoT Security のブログをご覧ください。
この記事は Maitreya Ranganath と Omar Zoma によって書かれた Securing modern Connected Vehicle platforms with AWS IoT の日本語訳です。