Amazon Web Services ブログ

AWS IoT Core 使用時のマルチアカウントデバイスプロビジョニングと認証局登録の簡略化

この記事は、Syed Rehan によって投稿された Simplify multi-account device provisioning and certificate authority registration when using AWS IoT Core を翻訳したものです。

開発環境、ステージング環境、本番環境を分けるために、複数の AWS アカウントを管理しなければならないことがよくあります。AWS IoT Core に IoT ワークロードを展開する場合、お客様は通常、デバイスを識別するために一意の X.509 証明書を使用し、プロビジョニング中にデバイス証明書の署名を検証するために認証局（CA）を使用しています。このブログでは、AWS IoT Core で新たに提供された機能を使用して、複数のアカウントを使用するお客様のデバイスプロビジョニングと CA 登録の両方を簡略化する方法を紹介します。

従来は、開発ワークロードと本番ワークロードを区別するために異なる AWS アカウントを管理するお客様は、開発プロセスにおいて、単一のデバイスを複数のアカウントに接続するためには複数の CA を設定する必要がありました。今回のアップデートにより、複数のアカウントで同じ CA を利用できるようになり、JITP（Just-in-Time Provisioning）および JITR（Just-in-Time Registration）使用時のデバイスプロビジョニングを簡略化し、CA の数を少なくしてセキュリティ体制を向上させることができます。

このアップデートは、プロビジョニング中にデバイス証明書の署名を検証するための AWS IoT Core の CA 登録プロセスも簡略化しています。以前は、CA を登録する前に所有権を証明するために、CA の秘密鍵にアクセスする必要がありました。しかし、これらの秘密鍵は通常、デバイスベンダーまたは独自の CA を運用する組織のセキュリティチームが管理しており、開発者と共有されていないため、開発者が CA の所有権を証明することは困難でした。今回のアップデートにより、開発チームは CA の登録を直接管理することができ、デバイスのプロビジョニングプロセスを簡略化することができます。

この新機能は、AWS IoT Core への接続を最初に試みる際にデバイスを自動的にプロビジョニングする JITP および JITR プロビジョニング方式に対するもので、マルチアカウントのユースケース向けにこれらの方式を強化するものです。一方、デバイス証明書のマルチアカウント登録（MAR）は、顧客が CA を登録せずに異なる AWS アカウント間でデバイスを移動させることを可能にしますが、各アカウントの AWS IoT Core にデバイス証明書を手動で登録する必要があります。

新機能を利用しているお客様事例のご紹介

AWS IoT Core による複数のアカウントへの CA の登録と CA 登録の簡略化により、お客様の複雑さを軽減し、市場投入までの時間を短縮することができます。

iRobot: マルチアカウント環境におけるデバイス認証情報プロビジョニングの複雑さを軽減

iRobot は、人々が家庭内外でより多くのことを行うためのロボットを設計・製造しています。iRobot は、複数の AWS アカウントを使用して、開発、テスト、および本番環境を分離しています。iRobot のクラウドアーキテクト、Ben Kehoe は以下のように述べています。「複数のアカウントに CA 証明書を登録できるようにする AWS IoT Core の新機能により、開発用ロボットの ID を一度プロビジョニングすれば、再プロビジョニングを行わずに、必要に応じて承認済みの開発アカウント間を移動させることができます。これにより、開発プロセスが簡素化され、さらに、削減された CA をより厳密に管理し、CA をセキュリティ境界に関連付けることができるため、当社のセキュリティ体制の改善につながります」

WirelessCar：セキュリティ設定の簡素化により市場投入までの時間を短縮

WirelessCar は、デジタル車両サービスの世界的なイノベーターの1つです。車両データを消費者、モビリティプロバイダー、車両メーカー、社会のためのビジネスバリューに変えています。WirelessCar は、X.509 証明書ベースのアイデンティティを持つ車両のプロビジョニングを自動化するために Just-in-Time Provisioning を使用しています。WirelessCar のソリューションアーキテクトである Henrik Strömbergは「 AWS IoT Core の CA 登録が新たに簡素化されたことで、当社の開発者はセキュリティチームからの検証証明書を待たずに迅速に行動できるようになりました」と述べています。「当社のセキュリティチームは、ペースの速い開発環境においてボトルネックになることなく、強固なセキュリティ体制を維持することができます。」

開始の方法

この新機能により、CA の秘密鍵の所有権を証明することなく、同じリージョンの複数のアカウントに CA 証明書を登録することができるようになりました（もちろん、以前から可能だった、複数のリージョンにまたがる登録も可能です）。この機能は、デバイスがトランスポートレイヤーセキュリティのハンドシェイク処理の開始時に、接続しようとしているエンドポイントを伝える Server Name Indication (SNI) フィールドを送信できる場合に使用することができます。この新機能により、JITP および JITR のデバイスプロビジョニング方式が強化されます。これにより、以下の2つのモードのいずれかで CA 証明書の登録が行えるようになりました:

  • DEFAULT: 検証証明書を用いて CA を登録する
  • SNI_ONLY: 検証証明書を用いずに CA を登録する

AWS IoT Core は、SNI_ONLYモードで署名 CA を登録すると、デバイス証明書を SNI_ONLY モードで登録します。

キーポイント:

  • 1 つのリージョンで DEFAULT モードで CA を登録できるのは、1 つのアカウントのみです。
  • SNI_ONLY モードでは、複数のアカウントで同じ CA を同じリージョンで登録することができます。そのような CA が登録されたリージョンでのアカウント数の制限はありません。
  • 複数のアカウントを異なるリージョンで利用する場合、同じ CA を DEFAULT モードもしくは SNI_ONLY モードで登録することが可能です（これは以前から可能でした）。
  • CAは、アカウント間で異なるモードにすることができます。例えば、あるアカウントは DEFAULT モードで登録し、別のアカウントは SNI_ONLY モードで登録する、ということが可能です。
  • あるアカウントでは、CA は1つのモードでしか存在できません。登録されている CA のモードを変更するには、その CA を削除し、再度登録する必要があります。

この新機能をご自身のアカウントで設定し、テストしましょう。以下の手順で、複数のアカウントに同じ CA を登録できることを紹介していきます。

  • 2つの異なるアカウントで Cloud9 インスタンスをセットアップします。
  • 1つ目のアカウントで CA を DEFAULT モードでセットアップします。
  • 2つ目のアカウントに SNI_ONLY モードで CA を設定します。
  • CA が両方のアカウントに登録されていることを確認し、機能を検証します。

ソリューションアーキテクチャー

ソリューションアーキテクチャー – Figure 1

ソリューションの概要と実装

テスト環境を作成する

Get Started With IoT ワークショップを使って、AWS Cloud9 の環境を素早くセットアップしましょう。あなたのロケーションに最も近い AWS リージョンを選んでください。このブログでは、US-EAST-1 を使用します。導入した機能のマルチアカウント機能をテストするため、同じリージョンで2つの Cloud9 環境をセットアップしますが、2つの異なるアカウントを利用します。ワークショップで使用した AWS CloudFormation のテンプレートを使って設定を完了したら、証明機関の設定を始めましょう。Cloud9のターミナルを開き（ヒントはこちら）、1つ目の CA 証明書を設定しましょう。

アカウント1に CAを設定する

1つ目のアカウントに DEFAULT モードで CA を設定しましょう。DEFAULT CA 証明書を登録するために、すでに公開されれいる API ドキュメントを参照してください。

CA 証明書を作成

openssl genrsa -out rootCA.key 2048

以下のような出力が得られます。

e is 65537 (0x010001)
Generating RSA private key, 2048 bit long modulus (2 primes)
................................................................................................................................................................................+++++
..+++++

次に、OpenSSL を用いて CA 証明書を作成するための設定ファイルを作成します。以下の内容で、rootCA_openssl.conf という名前のファイルを作成します。

[ v3_ca ]
basicConstraints = CA:TRUE

この設定ファイルは明示的に生成される証明書は CA で、リーフ証明書ではないことを示しています。rootCA_openssl.conf ファイルが作成できたら、以下のコマンドを実行して rootCA.pem ファイルを作成し、適切に詳細を記入します。

openssl req -new -sha256 -key rootCA.key -nodes -out rootCA.csr
openssl x509 -req -days 1024 -extfile rootCA_openssl.conf -extensions v3_ca -in rootCA.csr -signkey rootCA.key -out rootCA.pem

ここまでで、rootCA.key と rootCA.pem の2つのファイルが作成されました。これらを以下のステップで使用します。

CA を登録

こちらの CA 証明書を登録する公式の手順に則って CA を登録します。まず、IoT Core から登録コードを取得します。このコードをプライベートキー検証の Common Name に指定します。

aws iot get-registration-code --region us-east-1

以下のような出力が得られます。

{
"registrationCode": "xxxxxxxxxxx7a60e19fxxxxxxxxxxxxxx8381dbd3457xxxxxxxxxxxxxx"
}

次に、プライベートキー検証証明書のキーペアを作成します。verificationCert.key というファイルが出力されます。

openssl genrsa -out verificationCert.key 2048

以下のような出力が得られます。

e is 65537 (0x01xxxx)
Generating RSA private key, 2048 bit long modulus (2 primes)
................................................................................................................+++++
.............................................+++++

次に、プライベートキー検証証明書の CSR を作成するために以下のコマンドを実行します。verificationCert.csr というファイルが得られます。

openssl req -new -key verificationCert.key -out verificationCert.csr

先程のステップで取得した登録コードを Common Name のフィールドに設定します。その他のフィールドはお客様の状況に合わせて適切に設定してください。

Country Name (2 letter code) [AU]:
State or Province Name (full name) []:
Locality Name (for example, city) []:
Organization Name (for example, company) []:
Organizational Unit Name (for example, section) []:
Common Name (e.g. server FQDN or YOUR name) []: XXXXXXXREGISTRATION-CODEXXXXXXX
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

プライベートキー検証証明書を作成するために CSR を使用します。このステップで出力される verificationCert.pem ファイルを CA を登録する際に使用します。

openssl x509 -req -in verificationCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out verificationCert.pem -days 500 -sha256

正しく完了した場合、以下のような出力が得られます。

Getting CA Private Key

最後に、register-ca-certificate CLI コマンドを実行し、CA 証明書を登録します。

aws iot register-ca-certificate --ca-certificate file://rootCA.pem --verification-cert file://verificationCert.pem --set-as-active --allow-auto-registration --region us-east-1

注意: 次の検証ステップで使用するため、Certificate ID をメモしておいてください。

正しく登録されると、Certificate ID と Certificate ARN が返ります。
CA 証明書を登録したあとでも UpdateCACertificate API もしくは update-ca-certificate CLI コマンドにより登録された CA を更新することも可能です。

CA を登録したので、AWS IoT Core のエンドポイント経由でコントロールプレーンの呼び出しを行い、CA が登録されていることを検証しましょう。以下のコマンドを実行します。( Certificate ID は aws iot register-ca-certificate の戻り値で置き換えてください。)

aws iot describe-ca-certificate --region us-east-1 --certificate-id <<Certificate_ID>>

以下のような JSON の出力が得られます。

{
  "certificateDescription": {
    "certificateArn": "arn:aws:iot:us-east-1:YYYYYYYYYYYY:cacert/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "certificateId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "status": "ACTIVE",
    "certificatePem": "-----BEGIN CERTIFICATE-----xxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n-----END CERTIFICATE-----\n",
    "ownedBy": "YYYYYYYYYYYY",
    "creationDate": 1655249872.319,
    "autoRegistrationStatus": "ENABLE",
    "lastModifiedDate": 1655249872.319,
    "customerVersion": 1,
    "generationId": "7xxxxxxxxxxxxxxxxxxxxxxxxxxxxe9",
    "validity": {
      "notBefore": 1655249071.0,
      "notAfter": 1743722671.0
    },
    "certificateMode": "DEFAULT"
  }
}

アカウント2 で CA を設定する

2つ目のアカウントを開き、前と同じように Cloud9 環境をセットアップします。
1つ目のアカウントで登録したのと同じ CA を2つ目のアカウントでも登録するため、SNI_ONLY モードを使用します。このモードでは1つ目のアカウントで行ったような検証のステップを行う必要はありません。
1つ目のアカウントから rootCA.pem ファイルをコピーして、以下のコマンドを実行します。

iot register-ca-certificate --ca-certificate file://rootCA.pem --certificate-mode SNI_ONLY --set-as-active --allow-auto-registration --region us-east-1

CA が登録されていることを検証する

aws iot describe-ca-certificate --region us-east-1 --certificate-id <<Certificate_ID>>

以下のような出力が得られ、証明書ののモードが SNI_ONLY になっていることが分かります。

{
  "certificateDescription": {
    "certificateArn": "arn:aws:iot:us-east-1:ZZZZZZZZZZZZ:cacert/4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0",
    "certificateId": "4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0",
    "status": "ACTIVE",
    "certificatePem": "-----BEGIN CERTIFICATE-----xxxxxxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n-----END CERTIFICATE-----\n",
    "ownedBy": "ZZZZZZZZZZZZ",
    "creationDate": 1655252314.053,
    "autoRegistrationStatus": "ENABLE",
    "lastModifiedDate": 1655252314.053,
    "customerVersion": 1,
    "generationId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "validity": {
      "notBefore": 1655249071.0,
      "notAfter": 1743722671.0
    },
    "certificateMode": "SNI_ONLY"
  }
}

DEFAULT モードのときと同じように SNI_ONLY モードの CA 証明書を使用することができます。

まとめ

2つの AWS アカウントに同じ CA 証明書を登録することを簡略化し、開発、テスト、本番など複数のアカウントを使用する際に追加の CA をプロビジョニングする必要性を軽減する新機能について説明しました。また、SNI_ONLY 証明書モードを使用して、CA の秘密鍵を必要とせずに CA 証明書を登録する方法を解説し、セキュリティ構成の簡略化と市場投入までの時間の短縮を実現しました。

CA 登録の詳細については、開発者向けドキュメントを、証明書モードの詳細については、API ドキュメントを参照してください。証明書を手動で登録する場合は、以下の開発者向けドキュメントを参照してください。SNI モードについて詳しくは、TLS extensions documentation を参照してください。

執筆者について

Syed Rehan は、Amazon Web Services のグローバル Sr. スペシャリストソリューションアーキテクトで、ロンドンを拠点としています。IoT ソリューションアーキテクトとして、世界中のお客様をサポートしています。IoT とクラウドに関する深い知識を持ち、スタートアップから企業まで幅広い顧客に対して、AWS エコシステムによる IoT ソリューションの構築を支援する役割を担っています。

Victor Lesau は、Amazon Web Servicesの Sr. テクニカルプロダクトマネージャーです。AWS IoT Core と AWS IoT Identity サービス、スマートホーム構想の製品戦略、ロードマップ計画、ビジネス分析、顧客エンゲージメント、その他の製品管理分野に注力しています。

この記事はプロフェッショナルサービス本部 IoT コンサルタントの小林が翻訳しました。