シナリオ: mTLS証明書を使用するデジタル・ツイン・インスタンスの作成
デバイスからデータを受信する場合は、デジタル・ツイン・インスタンスで認証を使用する必要があります。このシナリオでは、証明書を使用してデバイスのデジタル・ツイン・インスタンスを認証する方法について説明します。
- 証明書を定期的にローテーションします。デジタル・ツイン・インスタンスの証明書のローテーションを参照してください。
- 証明書の有効期間を制限します。
- Vaultsを使用して秘密キーを格納します。
- 接続の試行を監視および監査します。
開始する前に
必要な権限があることを確認してください。管理者は、必要なポリシーを作成してアクセス権を付与します。詳細は、証明書に必要なポリシーについては前提条件を、IoTリソースに必要なポリシーについてはInternet of Things (IoT)プラットフォームのポリシー詳細を参照してください。
認証に証明書を使用する場合は、デジタル・ツイン・インスタンスを作成するときに、IoTドメインが証明書を読み取ることができるように、次のポリシーが必要です。
Allow any-user to {CERTIFICATE_BUNDLE_READ, CERTIFICATE_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'
Allow any-user to {CERTIFICATE_AUTHORITY_BUNDLE_READ, CERTIFICATE_AUTHORITY_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'
Allow any-user to {CABUNDLE_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'ステップ1: キーの作成
Oracle Cloud Infrastructure (OCI)には、ハードウェアで保護された対称暗号化キーが存在する必要があります。マスター暗号化キーがあるかどうかを確認するか、新しいキーを作成するには:
- 「アイデンティティとセキュリティ」に移動し、「Vault」を選択します。
- IoTリソースに使用するコンパートメントを選択します。
- キーを作成するには、「キーの作成」を選択し、マスター暗号化キーの作成の手順に従います。
- または、「Vaults」のリストから、使用するVaultの横にある「Actions」メニューを選択し、「View Vault Details」を選択します。
- 「マスター暗号化キー」を選択して、「キー」を表示します。「キー詳細の表示」を選択して「保護モード」を検索し、それがHSM (ハードウェア・セキュリティ・モジュール)であることを確認します。
ステップ2: 認証局の作成
証明書サービスを使用して、ルート認証局(CA)または下位CAを作成します。詳細は、認証局の作成を参照してください。
このタスク例では、下位CAを使用して外部で管理する秘密キーを使用して証明書を発行する方法について説明します。
従属CAを作成するには、すでにルートCAが必要です。
- 適切なポリシーを使用して管理者としてログインし、これらのアクションを実行します。CAを作成するには、適切なレベルのセキュリティ・アクセス権が必要です。
- 「認証局」リスト・ページで、「認証局の作成」を選択します。リスト・ページの検索に関するヘルプが必要な場合は、認証局のリストを参照してください。
- 「コンパートメント」を選択し、CAを作成するコンパートメントを選択します。
- 「認証局タイプ」で、「下位認証局」タイプ(他のCAを含む階層内のルートCAではないCA)を選択します。
- (オプション) CAの一意の表示名前を入力します。この名前を使用すると、管理目的でCAを識別できますが、CA証明書の一部として表示されません。機密情報を入力しないでください。ノート
テナンシ内の2つのCAは、削除保留中のCAを含め、同じ名前を共有できません。 - (オプション)タグを適用するには、「タグ付けオプションの表示」を選択します。タグの詳細は、リソース・タグを参照してください。
- 「次へ」を選択します。
- 件名情報を入力します。サブジェクト情報には、少なくともCA証明書の所有者を識別するための共通名(CN)が含まれます。証明書の使用目的に応じて、サブジェクトは個人、組織、コンピュータ・エンドポイントまたはデバイスを識別します。サブジェクト情報の形式は、RFC 5280標準に準拠している必要があります。ワイルドカードを使用して、複数のドメイン名またはサブドメイン名の証明書を発行できます。
- 「次へ」を選択します。
- 「認可構成」で、CA証明書に使用する暗号化キーを含むボールトを確認または選択します。オプションで、「コンパートメントの変更」を選択して別のコンパートメントを指定します。ボールトの作成と管理の詳細は、「ボールトの管理」を参照してください。
- 「キー」で、使用するボールト内のキーをクリックします。証明書では非対称キーのみがサポートされるため、リストにはボールト内の非対称キーのみが含まれます。Rivest-Shamir-Adleman(RSA)キーから、2,048ビットまたは4,096ビットを選択できます。また、楕円曲線IDがNIST_P384の楕円曲線暗号デジタル署名アルゴリズム(ECDSA)キーを選択することもできます。具体的に言うと、このリストには、ハードウェア・セキュリティ・モジュール(HSM)によって保護されているこれらのタイプの非対称キーのみが含まれます。証明書では、ソフトウェア保護されたキーの使用はサポートされません。キーの作成および管理の詳細は、キーの管理を参照してください。
- 「署名アルゴリズム」で、キー・アルゴリズム・ファミリに応じて、次のいずれかのオプションを選択します。
- SHA256_WITH_RSA: SHA-256ハッシュ関数を使用したRSSAキー
- SHA384_WITH_RSA: SHA-384ハッシュ関数を使用したRSSAキー
- SHA512_WITH_RSA: SHA-512ハッシュ関数を使用したRSSAキー
- SHA256_WITH_ECDSA: SHA-256ハッシュ関数を使用したECDSAキー
- SHA384_WITH_ECDSA: SHA-384ハッシュ関数を使用したECDSAキー
- SHA512_WITH_ECDSA: SHA-512ハッシュ関数を使用したECDSAキー
- 「次へ」を選択します。
- 有効期限ルールを構成します。「証明書の最大有効期間(日数)」で、このCAによって発行された証明書を有効化できる最大日数を指定します。有効期間は90日以内にすることを強くお薦めします。
- 「失効構成」ページで、証明書失効リスト(CRL)を構成しない場合は、「失効のスキップ」チェック・ボックスを選択します。
- 「次へ」を選択します。
- 情報が正しいことを確認し、「認証局の作成」を選択します。証明書関連のリソースの作成には数分かかる場合があります。
- 認証局が正常に作成された場合は、サマリーの詳細が表示されます。
ステップ3: 新規秘密キーの生成
OpenSSLを使用して、秘密キーと証明書署名リクエスト(CSR)を作成します。
セキュリティのため、キーを非公開にし、外部でキーを共有しないように、デバイスでこのステップを実行することを検討してください。
- このコマンドを使用して、新しい秘密キー
private.pemと、RSA 2048ビット暗号化を使用した証明書署名リクエストcsr.pemを生成します。この例では、パスワード保護なしで指定し、v3_req拡張子を使用する-nodesパラメータの使用方法を示します。openssl req -nodes -newkey rsa:2048 -keyout private.pem -out csr.pem -extensions v3_reqノート
Linuxを使用している場合、デフォルトでは、OpenSSL.cnfファイルが拡張子をコメント・アウトします。たとえば、OpenSSL構成ファイルに次のようなものが表示された場合:/etc/pki/tls/openssl.cnf
次に、# req_extensions = v3_req# The extensions to add to a certificate request#を削除して拡張子をコメント・アウトし、ファイルは次のようになります。req_extensions = v3_req # The extensions to add to a certificate requestOpenSSLがextensions v3_reqを使用していることを確認するために、出力に次が含まれていることを確認できます。X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE この例は、証明書リクエストの入力フィールドと値の例を示しています。証明書レポートに組み込む情報を識別名(DN)として入力します。
共通名を入力します。共通名は、「証明書の詳細」ページの「サブジェクト情報」タブ、ステップ8の「認証局の作成」を参照するか、証明書の詳細ページの検索方法については、「証明書のリスト」を参照してください。Country Name (2 letter code) []: US State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) []: Organizational Unit Name (eg, section) []: Common Name (Enter common name from the certificate details.) []:common-name Email Address [your@email.com]: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
ステップ4: 外部で管理される証明書の作成
証明書をインストールする予定のサーバーで証明書署名リクエスト(CSR)と秘密キーを生成してから、そのCSLをCAに送信し、証明書を発行することもできます。この場合、秘密キーは外部で管理します。
- コンソールで、ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」を選択します。
- 「証明書」リスト・ページに、特定のコンパートメントの認証局のリストが表示されます。
- 作業する証明書を検索し、行の最後にある「アクション」メニューを選択します。
- 「発行証明書」を選択します。
- 「証明書タイプ」で、外部のサード・パーティCAによって管理される証明書サービスのCAから証明を発行するには、「内部CAによって発行され、外部に管理」を選択します。
- 証明書の一意の表示名前を入力します。機密情報を入力しないでください。ノート
テナンシ内の2つの証明書が同じ名前(削除保留中の証明書を含む)を共有することはできません。 - (オプション) 説明を入力して、証明書を識別しやすくします。機密情報を入力しないでください。
- サードパーティCAが管理する証明書の場合、サブジェクト情報を指定する必要はありません。かわりに、「次へ」を選択します。
- 「証明書署名リクエスト」で、「ファイルのアップロード」を選択して証明書の内容を指定し、「1つ選択」を選択して証明書を
PEM形式のファイルとしてのアップロードします。 - または、「コンテンツの貼付け」を選択し、テキスト・ボックスを選択して証明書の内容を直接貼り付けます。
- 「次へ」を選択します。
- 証明書サービスで管理されない証明書の自動更新は構成できません。「次へ」を選択して続行します。
- サマリー情報が正しいことを確認し、「証明書の作成」を選択します。
- 「証明書の詳細」ページがオープンします。「バージョン」で、表示する証明書の名前を検索し、行の最後にある「アクション」メニューに移動して、「コンテンツの表示」を選択します。詳細は、証明書の詳細の表示を参照してください。
- 「ダウンロード」を選択し、「証明書PEM」ファイルを「保存」します。
- 証明書の詳細ページで、「サブジェクト情報」タブに移動し、次のステップで使用する証明書の「共通名」をコピーします。
ステップ5: 証明書を使用するデジタル・ツイン・インスタンスの作成
データを送信するデバイスを認証するには、前のステップで作成した--auth-idパラメータおよび<certificate-OCID>を使用して、デジタル・ツイン・インスタンスを作成します。
このコマンドおよびパラメータを使用して、デジタル・ツイン・インスタンスを作成します。<common-name-for-the-certificate>を置き換えます。<certificate-OCID>を環境の証明書OCIDに置き換えます。証明書の詳細でこれらの値を検索します。詳細は、証明書の詳細の表示を参照してください:
oci iot digital-twin-instance create --iot-domain-id <iot-domain-OCID> --auth-id <certificate-OCID> --external-key <common-name-from-certificate-details>
CLIパラメータの完全なリストは、oci iot digital-twin-instance createを参照し、詳細はデジタル・ツイン・インスタンスの作成を参照してください。
オプションのステップ6: デジタル・ツインのインスタンス詳細の取得
oci iot digital-twin-instance get --digital-twin-instance-id <digital-twin-instance-OCID>ステップ7: データの送信
シナリオに応じて、MQTTS、HTTPSまたはWebSocketを使用してデジタル・ツイン・インスタンスに接続できます。シナリオの例は、Connecting a Deviceを参照してください。
Curlの使用
POSIXスタイルのシェル: このcurlコマンドは、Windowsでbash、zsh、macOS Terminal、LinuxまたはGit Bashを使用して、接続をテストするサンプル・プレーン・テキスト・メッセージを送信する場合に使用します。device-cert.pemおよびdevice-key.pemを、使用している環境のファイルへのパスに置き換えます。curl --cert /path/device-cert.pem --key /path/device-key.pem \ -H "Content-Type: text/plain" \ -d "sample data 1" \ "https://<iot-domain-short-id>.device.iot.<region>.oci.oraclecloud.com/sampletopic"Windows Powershell: この
curlコマンドを使用して、device-cert.pemおよびdevice-key.pemを環境の値に置き換えます。curl.exe --cert /path/device-cert.pem --key /path/device-key.pem \ -H "Content-Type: text/plain" \ -d "sample data 1" \ "https://<iot-domain-short-id>.device.iot.<region>.oci.oraclecloud.com/sampletopic"「ステップ5: 証明書を使用するデジタル・ツイン・インスタンスの作成」に格納されている外部キーを使用します。シェルの引用符は、その値の一部として意図的に格納されていないかぎり、外部キーの一部ではありません。認証チェックについては、Troubleshooting Certificate Rotationを参照してください。
任意のMQTTクライアントを使用して、MQTTSを使用してトピックにサブスクライブします。この例では、MQTTxを使用します。
サンプル・データを送信し、接続をテストするには:
- 次のように、ホストとしてデバイスホストを入力します。
mqtts://<domain-short-id>.device.iot.<region>.oci.oraclecloud.com - ポート
8883を入力します。 - クライアントID: your-client-ID
- クリーン・スタート: True
- トグルをオンにすると、TLSが有効になります。
- オプション「CAまたは自己署名証明書」を選択します。
- 「外部で管理される証明書の作成」のステップ15から、クライアント証明書ファイルの場所を入力します:
your-certificate.pem - 「新規秘密キーの生成」のステップ1から、クライアント・キー・ファイルの場所を入力します:
your-private-key.pem - 「接続」を選択します。


- デバイスからデータを受信するには、「新規サブスクリプション」を選択します。
- 「トピック」としてエンドポイントを入力します。
- 次の例は、Quality of Service (QoS)レベル1の
/endpoints/4321トピックにパブリッシュされたメッセージを示しています。トピック:{ "pulse": 300, "s02": 400 }{ "test": 100 }
- 次のように、ホストとしてデバイスホストを入力します。
オプションのステップ8: APEXでのIoTデータの監視
select * from <domain-short-id-from-device-host>__IOT.RAW_DATA
where digital_twin_instance_id = '<digital-twin-instance-ocid>'デジタル・ツイン・インスタンスの証明書のローテーション
デジタル・ツイン・インスタンスが認証に下位認証局(CA)を使用する場合は、同じCAリソースOCIDでバージョンをローテーションして、インスタンスの認証ID (authId)を変更しないままにします。サポートされるローテーションのオーバーラップ中に、IoTは現在の下位CAバージョンと以前の下位CAバージョンの両方によって発行されたデバイス証明書を認証できます。
ルートCAは、デジタル・ツイン・インスタンスの認証IDとして使用できません。
証明書の変更を使用するデバイスと調整し、以前の資格証明をリタイアする前に、置換資格証明を使用して認証およびデータ取込みを検証します。
認証IDと一致するプロシージャとして、「デバイス認証に使用される下位CAのローテーション」または「デバイス認証に使用されるインポート済証明書のローテーション」を選択します。個々の証明書を更新すると、デバイス資格証明が置き換えられます。下位CAを更新すると、デバイス証明書に対して信頼できる発行者が変更されます。
デバイス認証に使用される下位CAのローテーション
デジタル・ツイン・インスタンスの認証IDを変更せずに、下位CAを更新し、デバイスを置換証明書に移行します。
この手順は、デジタル・ツイン・インスタンスの認証ID (authId)が証明書サービスの下位CAを参照する場合に適用されます。個々の証明書またはCAバンドルを参照する認証IDは対象外です。ルートCAは認証IDとして使用できません。
CAとその証明書を管理する権限があり、IoTドメインに読取り権限が保持されていることを確認します。前提条件およびこのトピックの証明書ポリシーを参照してください。
CAを変更する前にデバイス・ハンドオーバーを計画します。以前の資格情報に依存するすべてのデバイスを識別し、交換資格情報の安全な配布を整理し、移行されていないデバイスに必要な資格情報を保持します。証明書の有効性および失効は、サポートされているローテーションの重複中に引き続き適用されます。
デバイスは置換証明書を使用し、デジタル・ツイン・インスタンスは同じ下位CA認証OCIDを保持します。
デバイス認証に使用されるインポートされた証明書のローテーション
同じ証明書OCIDで、デバイス証明書とそれに対応する秘密キーを置き換えます。
この手順は、デジタル・ツイン・インスタンスの認証ID (authId)が証明書サービスでインポートされた個々の証明書を参照する場合に適用されます。下位CAを参照する認証IDの場合は、「デバイス認証に使用される下位CAのローテーション」を使用します。CAバンドルは、どちらのプロシージャでもカバーされません。
証明書を更新できること、およびIoTドメインがそれを読み取ることができることを確認します。アクティブ・バージョンを変更する前に、置換資格証明のセキュアな分散を計画します。
デバイスは置換証明書と秘密キーを使用し、デジタル・ツイン・インスタンスは同じ証明書認証OCIDを保持します。
証明書のローテーションに関するFAQ
OCI証明書は、CURRENT、PREVIOUS、PENDINGなどのローテーション状態を証明書バージョンに割り当てます。これらの状態とバージョン昇格の背景については、Certificate Versions and Rotation Statesを参照してください。IoT認証は、ここで説明する重複および妥当性の要件にも依存します。
- subordinate-CAプロシージャは認証IDを変更しますか。
- 番号このプロシージャは、同じ下位CAのバージョンをローテーションし、そのリソースOCIDを
authIdに保持します。そのリソースを別のCA OCIDで置き換える操作は同じではありません。「デバイス認証に使用される下位CAのローテーション」を参照してください。 - 認証IDとしてルートCAを使用できますか。
- 番号ルートCAは発行者階層の一部にできますが、デジタル・ツイン・インスタンスの
authIdにすることはできません。下位CAまたはデバイス認証に使用される証明書にルートCA OCIDを置換しないでください。 - CAを更新すると、デバイスの資格証明が更新されますか。
- 番号交換デバイス証明書とその対応する秘密キーを安全にプロビジョニングしてから、新しい接続および正常な取込みを検証します。CAバージョンの変更のみでは、デバイス資格証明は配布されません。
- 認証IDが証明書OCIDの場合、どの手順が適用されますか。
- インポートされた個々の証明書については、Rotating an Imported Certificate Used for Device Authenticationを参照してください。このプロシージャは、同じ証明書OCIDの証明書およびそれと一致する秘密キーを更新します。下位CAプロシージャは、かわりに、デバイス証明書の認証に使用される発行者を更新します。どちらの手順もCAバンドルには対応していません。
- 以前の資格証明はいつリタイアできますか。
- サポートされる重複期間および証明書の有効期間内に、リタイア前に、影響を受けるすべてのデバイスと交換用の資格を確認してください。発行者を取消しまたは削除する前に、依存関係を確認してください。オーバーラップによって、期限切れの資格証明または失効した資格証明が有効になることはなく、既存の接続では置換資格証明が機能することを証明していません。
共通の質問は、「資格証明のローテーションに関するFAQ」を参照してください。
証明書のローテーションのトラブルシューティング
デバイスは、資格証明または発行者バージョンの変更後に証明書認証に失敗します。
認証ID、アクティブな発行者バージョン、デバイス・アイデンティティ、証明書チェーンまたはクライアント資格証明が一致しない場合があります。
authIdが下位CAを参照するか、個々の証明書を参照するかを確認します。そのリソースタイプの手順に従います。ルートCAは有効な認証IDではありません。- 下位CAプロシージャの場合は、置換CAバージョンが
CURRENTであり、置換デバイス証明書が目的のバージョンによって発行されたことを確認します。証明書の有効性、失効ステータスおよび必要な発行者チェーンを確認します。 - クライアントが、失効したファイルではなく、置換証明書とそれと一致する秘密キーをロードすることを確認します。証明書の共通名をインスタンスの外部キーと照合し、目的のドメイン・エンドポイントを確認します。証明書を使用するデジタル・ツイン・インスタンスの作成を参照してください。
- 新規接続をテストし、「データの送信」を使用してデータを送信します。TLS検証を有効なままにします。既存のセッションまたは繰り返し行われる自動再接続を、資格証明の正常なハンドオーバーの証明として扱わないでください。
- 前の資格証明のみが失敗した場合は、その有効性、失効ステータス、発行者バージョンおよびサポートされている重複を確認してください。これ以上資格証明を削除しないか、再度ローテーションして調査してください。
永続的な障害の場合は、Troubleshooting Device Credential Rotationのエビデンスチェックリストを使用します。診断出力に秘密キーを含めないでください。