OPC UA 用コネクタの OPC UA 証明書インフラストラクチャを構成する
重要
Azure Arc によって実現されている Azure IoT Operations プレビューは、現在プレビュー段階です。 運用環境ではこのプレビュー ソフトウェアを使わないでください。
Azure IoT Operations の一般公開リリースが提供されたときには、新規インストールをデプロイすることが必要になります。 プレビュー インストールからのアップグレードはできません。
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
この記事では、OPC UA 用コネクタ用に OPC UA 証明書インフラストラクチャを構成する方法について説明します。 この構成により、安全にセッションを確立するための信頼できる OPC UA サーバーを決定できます。
OPC UA 用コネクタは、OPC UA サーバーとの間にセキュリティで保護された通信を確立するときに、OPC UA 仕様に基づいて単一の OPC UA アプリケーションとして機能します。 OPC UA 用コネクタは、それが OPC UA サーバーに対して開いた、セキュリティで保護されたすべてのチャネルについて、同じクライアント証明書を使用します。
詳細については、「OPC UA 用コネクタの OPC UA 証明書インフラストラクチャ」を参照してください。
前提条件
Azure IoT Operations プレビューのデプロイされたインスタンス。 デモと調査の目的で Azure IoT Operations をデプロイするには、「クイック スタート: K3s を使用して GitHub Codespaces で Azure IoT Operations プレビューを実行する」を参照してください。
自己署名アプリケーション インスタンス証明書を構成する
OPC UA 用コネクタの既定の展開では、cert-manager が必要とするすべてのリソースをインストールして、OPC UA 準拠の自己署名証明書を作成します。 この証明書は aio-opc-opcuabroker-default-application-cert
シークレットに格納されます。 このシークレットは、すべての OPC UA 用コネクタ ポッドにマップされ、OPC UA クライアントのアプリケーション インスタンス証明書として機能します。 cert-manager
は、このアプリケーション インスタンス証明書の自動更新を処理します。
デモ環境や調査環境で、OPC UA サーバーと OPC UA 用コネクタとの間で規制に準拠しセキュリティで保護された通信を行うには、この構成で通常十分です。 運用環境では、デプロイでエンタープライズ グレードのアプリケーション インスタンス証明書を使用する必要があります。
信頼できる証明書の一覧を構成する
資産に接続するには、まず、アプリケーション認証の相互信頼を確立する必要があります。 OPC UA 用コネクタに対して、次の手順を実行します。
OPC UA サーバー アプリケーションのインスタンス証明書をファイルとして取得します。 これらのファイルの拡張子は、通常 .der または .crt です。 これは公開キーのみです。
ヒント
通常、OPC UA サーバーには、アプリケーション インスタンス証明書をエクスポートできるインターフェイスがあります。 このインターフェイスは標準化されていません。 KEPServerEx などのサーバーでは、証明書を管理するための Windows ベースの構成 UI があります。 他のサーバーは、Web インターフェイスがある場合や、オペレーティング システム フォルダーを使用して証明書を格納する場合があります。 アプリケーション インスタンス証明書をエクスポートする方法については、サーバーのユーザー マニュアルを参照してください。 証明書を取得したら、それが DER または PEM でエンコードされていることを確認してください。 通常、拡張子が .der または .crt のファイルに格納されます。 証明書がこれらのファイル形式にない場合は、
openssl
などのツールを使用して、証明書を必要な形式に変換します。OPC UA サーバーのアプリケーション インスタンス証明書を信頼できる証明書の一覧に追加します。 この一覧は、Azure IoT Operations のデプロイ時に作成される aio-opc-ua-broker-trust-list という名前の Kubernetes ネイティブ シークレットとして実装されます。
./my-server.der などのファイルにある DER でエンコードされた証明書の場合は、次のコマンドを実行します。
# Append my-server.der OPC UA server certificate to the trusted certificate list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server.der=./my-server.der --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-trust-list -n azure-iot-operations -p "{\"data\": $data}"
./my-server.crt などのファイルにある PEM でエンコードされた証明書の場合は、次のコマンドを実行します。
# Append my-server.crt OPC UA server certificate to the trusted certificate list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server.crt=./my-server.crt --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-trust-list -n azure-iot-operations -p "{\"data\": $data}"
OPC UA サーバーが証明機関 (CA) によって発行された証明書を使用する場合は、その公開キー証明書を OPC UA 用コネクタの信頼できる証明書リストに追加することで、その CA を信頼できます。 これで、OPC UA 用コネクタ インスタンスが、その CA によって発行された有効な証明書を使用するすべてのサーバーを自動的に信頼するようになります。 そのため、OPC UA サーバーの証明書を OPC UA 用コネクタの信頼できる証明書の一覧に明示的に追加する必要はありません。
CA を信頼するには、次の手順を実行します。
CA 証明書の公開キーを DER または PEM 形式でエンコードしたものを取得します。 これらの証明書は、通常拡張子が .der または .crt のファイルに格納されます。 CA の CRL を取得します。 このリストは、通常 .crl を含むファイルです。 詳細については、OPC UA サーバーのマニュアルを確認してください。
CA 証明書と CRL を aio-opc-ua-broker-trust-list Kubernetes ネイティブ シークレットに保存します。
./my-server-ca.der などのファイルにある DER でエンコードされた CA 証明書の場合は、次のコマンドを実行します。
# Append CA certificate to the trusted certificate list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.der=./my-server-ca.der --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-trust-list -n azure-iot-operations -p "{`"data`": $data}" # Append the CRL to the trusted certificate list secret as a new entry data=$(kubectl create secret generic temp --from-file= my-server-ca.crl=./ my-server-ca.crl --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-trust-list -n azure-iot-operations -p "{`"data`": $data}"
./my-server-ca.crt などのファイルにある PEM でエンコードされた CA 証明書の場合は、次のコマンドを実行します。
# Append CA certificate to the trusted certificate list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.crt=./my-server-ca.crt --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-trust-list -n azure-iot-operations -p "{`"data`": $data}" # Append the CRL to the trusted certificates list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.crl=./my-server-ca.crl --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-trust-list -n azure-iot-operations -p "{`"data`": $data}"
発行者証明書の一覧を構成する
OPC UA サーバーが CA によって発行された証明書を使用しているが、CA で発行されたすべての証明書を信頼したくない場合は、次の手順を実行します。
前のセクションの最初の 3 つの手順に従って、OPC UA サーバーのアプリケーション インスタンス証明書を信頼します。
OPC UA 用コネクタは、証明書自体に加えて、OPC UA サーバーの証明書の発行者チェーンを適切に検証するための CA 証明書を必要とします。 CA 証明書とその証明書失効リスト (CRL) を、Kubernetes シークレットとして実装される aio-opc-ua-broker-issuer-list という別の一覧に追加します。
CA 証明書と CRL を
aio-opc-ua-broker-issuer-list
シークレットに保存します。./my-server-ca.der などのファイルにある DER でエンコードされた証明書の場合は、次のコマンドを実行します。
# Append CA certificate to the issuer list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.der=./my-server-ca.der --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-issuer-list -n azure-iot-operations -p "{`"data`": $data}" # Append the CRL to the issuer list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.crl=./my-server-ca.crl --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-issuer-list -n azure-iot-operations -p "{`"data`": $data}"
./my-server-ca.crt などのファイルにある PEM でエンコードされた証明書の場合は、次のコマンドを実行します。
# Append CA certificate to the issuer list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.crt=./my-server-ca.crt --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-issuer-list -n azure-iot-operations -p "{`"data`": $data}" # Append the CRL to the issuer list secret as a new entry data=$(kubectl create secret generic temp --from-file=my-server-ca.crl=./my-server-ca.crl --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-issuer-list -n azure-iot-operations -p "{`"data`": $data}"
OPC UA サーバーを構成する
アプリケーション認証の相互信頼の構成を完了するには、OPC UA サーバーが OPC UA 用コネクタのアプリケーション インスタンス証明書を信頼するように構成する必要があります。
OPC UA 用コネクタの証明書を
opcuabroker.crt
ファイルに抽出するには、次のコマンドを実行します。kubectl -n azure-iot-operations get secret aio-opc-opcuabroker-default-application-cert -o jsonpath='{.data.tls\.crt}' | base64 -d > opcuabroker.crt
多くの OPC UA サーバーでは、DER ファイル形式の証明書のみがサポートされています。 必要に応じて、次のコマンドを使用して opcuabroker.crt 証明書を opcuabroker.der に変換します。
openssl x509 -outform der -in opcuabroker.crt -out opcuabroker.der
opcuabroker.crt
またはopcuabroker.der
証明書ファイルをサーバーの信頼できる証明書の一覧に追加する方法については、OPC UA サーバーのドキュメントを参照してください。
エンタープライズ グレードのアプリケーション インスタンス証明書を構成する
運用環境については、エンタープライズ グレードのアプリケーション インスタンス証明書を使用するように OPC UA 用コネクタを構成できます。 通常、エンタープライズ CA がこの証明書を発行するため、構成には CA 証明書が必要です。 多くの場合、CA の階層があり、CA の完全な検証チェーンを構成に追加する必要があります。
次の例では、次の項目を参照しています。
アイテム | 説明 |
---|---|
opcuabroker-certificate.der | エンタープライズ グレードのアプリケーション インスタンス証明書の公開キーを含むファイル。 |
opcuabroker-certificate.pem | エンタープライズ グレードのアプリケーション インスタンス証明書の秘密キーを含むファイル。 |
subjectName |
アプリケーション インスタンス証明書に埋め込まれたサブジェクト名の文字列。 |
applicationUri |
アプリケーション インスタンスに埋め込まれているアプリケーション インスタンス URI。 |
enterprise-grade-ca-1.der | エンタープライズ グレードの CA 証明書の公開キーを含むファイル。 |
enterprise-grade-ca-1.crl | CA の CRL ファイル |
前の例と同様に、専用の Kubernetes シークレットを使用して証明書と CRL を格納します。 エンタープライズ グレードのアプリケーション インスタンス証明書を構成するには、次の手順を実行します。
次のコマンドを使用して、証明書と CRL を aio-opc-ua-broker-client-certificate シークレットに保存します。
# Create aio-opc-ua-broker-client-certificate secret # Upload OPC UA public key certificate as an entry to the secret # Upload OPC UA private key certificate as an entry to the secret kubectl create secret generic aio-opc-ua-broker-client-certificate -n azure-iot-operations \ --from-file=opcuabroker-certificate.der=./opcuabroker-certificate.der \ --from-file=opcuabroker-certificate.pem=./opcuabroker-certificate.pem
CA を使用して OPC UA ブローカーの証明書を発行する場合は、aio-opc-ua-broker-issuer-list シークレットを構成します。
kubectl
などの Kubernetes クライアントを使用して、enterprise-grade-ca-1.der シークレットと enterprise-grade-ca-1.crl シークレットを構成します。# Append CA certificate to the issuer list secret as a new entry data=$(kubectl create secret generic temp --from-file=enterprise-grade-ca-1.der=./enterprise-grade-ca-1.der --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-issuer-list -n azure-iot-operations -p "{`"data`": $data}" # Append the CRL to the issuer list secret as a new entry data=$(kubectl create secret generic temp --from-file= enterprise-grade-ca-1.crl=./enterprise-grade-ca-1.crl --dry-run=client -o jsonpath='{.data}') kubectl patch secret aio-opc-ua-broker-issuer-list -n azure-iot-operations -p "{`"data`": $data}"
次のコマンドを使用して、アプリケーション インスタンス証明書に新しい
secret
ソースを使用するように OPC UA 用コネクタの展開を更新します:az k8s-extension update \ --version 0.7.0-preview \ --name azure-iot-operations-qlll2 \ --release-train preview \ --cluster-name <cluster-name> \ --resource-group <azure-resource-group> \ --cluster-type connectedClusters \ --auto-upgrade-minor-version false \ --config connectors.values.securityPki.applicationCert=aio-opc-ua-broker-client-certificate \ --config connectors.values.securityPki.subjectName=<subjectName> \ --config connectors.values.securityPki.applicationUri=<applicationUri>
これで、OPC UA 用コネクタがエンタープライズ証明書を使用するようになったので、それが接続する必要があるすべての OPC UA サーバーの信頼できる証明書リストに新しい証明書の公開キーを追加することを忘れないでください。