共用方式為


了解 Azure IoT Edge 如何使用憑證

適用於: IoT Edge 1.5 核取記號 IoT Edge 1.5 IoT Edge 1.4 核取記號 IoT Edge 1.4

重要

IoT Edge 1.5 LTS 和 IoT Edge 1.4 LTS 為支援的版本。 IoT Edge 1.4 LTS 於 2024 年 11 月 12 日結束生命週期。 如果您是舊版,請參閱更新 IoT Edge

IoT Edge 會針對不同目的使用不同類型的憑證。 本文將詳細說明 IoT Edge 搭配 Azure IoT 中樞和 IoT Edge 網路閘道情節使用憑證的各種方式。

重要

為求簡潔,本文使用 IoT Edge 1.2 版或更新版本。 1.1 版的憑證概念相似,但仍有幾點相異之處:

  • 1.1 版使用的裝置 CA 憑證已重新命名為 Edge CA 憑證
  • 1.1 版的工作負載 CA 憑證現已淘汰。 在 1.2 版或更新版本中,IoT Edge 模組執行階段會直接從 Edge CA 憑證中產生所有伺服器憑證,而不需要憑證鏈結內憑證之間的中繼工作負載 CA 憑證。

摘要

這些核心案例是 IoT Edge 使用憑證的所在位置。 使用連結以深入了解每個案例。

演員 目的 憑證
IoT Edge 確保其正在和正確的 IoT 中樞通訊 IoT 中樞伺服器憑證
IoT 中樞 確保該要求是來自合法的 IoT Edge 裝置 IoT Edge 身分識別的憑證
下游 IoT 裝置 確保其正在和正確的 IoT Edge 閘道通訊 由 Edge CA 發行的 IoT Edge 中樞 edgeHub 模組伺服器憑證
IoT Edge 簽署新模組伺服器憑證。 例如,edgeHub 邊緣 CA 憑證
IoT Edge 確保該要求是來自合法的下游裝置 IoT 裝置身分識別的憑證

必要條件

單一裝置情節

為有效掌握 IoT Edge 的憑證概念,請想像名為 EdgeGateway 的 IoT Edge 裝置,連線至名為 ContosoIotHub Azure IoT 中樞的情節。 在此範例中,所有驗證皆透過 X.509 憑證驗證進行,而非對稱金鑰。 為在此情節中建立信任,我們必須保證 IoT 中樞和 IoT Edge 裝置皆為真實:「這是正版且有效的裝置嗎?」以及「IoT 中樞的身分識別是否正確?」 此情節如下圖所示:

顯示IoT Edge裝置與 IoT 中樞連線的信任案例狀態圖。

我們會說明每個問題的解答,並在本文稍後幾節中擴大範例。

由裝置驗證 IoT 中樞的身分識別

EdgeGateway 要如何驗證與其通訊的 ContosoIotHub 為正版? EdgeGateway 想與雲端通訊時,會連線至 ContosoIoTHub.Azure-devices.NET 端點。 為確保端點為真,IoT Edge 需要 ContosoIoTHub 出示身分識別 (識別碼)。 識別碼必須由 EdgeGateway 信任的授權單位簽發。 為驗證 IoT 中樞的身分識別,IoT Edge 和 IoT 中樞會用 TLS 交握通訊協定驗證 IoT 中樞伺服器的身分識別。 「TLS 交握」的說明請見下圖。 本範例為求簡潔,部分細節未加詳述。 若要深入了解「TLS 交握」通訊協定,請參閱維基百科上的 TLS 交握

注意

在本範例中,ContosoIoTHub 代表 IoT 中樞主機名稱 ContosoIotHub.Azure-devices.NET

顯示從 IoT 中樞 到 IoT Edge 裝置的憑證交換,以及 IoT Edge 裝置上受信任根存放區的憑證驗證順序圖。

在此內容中,您不需要知道密碼編譯演算法的確切詳細資料。 請務必了解,演算法可確保伺服器具備與公開金鑰匹配的私密金鑰, 且驗證憑證擁有者未複製或竊取它。 若以附相片的身分證為例,即表示您的臉部與身分證上的相片相符。 即使您的身分證遭竊,竊賊也無法用以作為身分識別,因為您的臉獨一無二,無法輕易複製。 針對密碼編譯金鑰,金鑰組也是彼此關聯且唯一的。 正如臉孔要與身分證上的相片相符,密碼編譯演算法也會用金鑰組來驗證身分識別。

在我們的情節中,ContosoIotHub 會顯示下列憑證鏈結:

顯示 IoT 中樞 中繼和跟證書授權單位鏈結的流程圖。

根憑證授權單位 (CA) 是 Baltimore CyberTrust Root 憑證。 這個根憑證由 DigiCert 簽署,且於許多作業系統中廣泛受到信任與儲存。 例如,Ubuntu 和 Windows 都將其納入預設憑證存放區中。

Windows 的憑證存放區:

顯示 Windows 證書存儲中所列的 Baltimore CyberTrust 跟證書的螢幕快照。

Ubuntu 的憑證存放區:

顯示 Ubuntu 證書儲存中所列的 Baltimore CyberTrust 跟證書的螢幕快照。

裝置檢查 Baltimore CyberTrust Root 憑證時,憑證已預先安裝在作業系統中。 從 EdgeGateway 的角度來看,由於 ContosoIotHub 出示的憑證鏈結已由作業系統信任的根 CA 簽署,因此系統會視其為可信任。 此類憑證即為 IoT 中樞伺服器憑證。 若要深入了解 IoT 中樞伺服器憑證,請參閱 IoT 中樞支援的傳輸層安全性 (TLS)

總而言之,EdgeGateway 可驗證並信任 ContosoIotHub 的身分識別,因為:

  • ContosoIotHub 出示其 IoT 中樞伺服器憑證
  • 伺服器憑證在作業系統憑證存放區中受到信任
  • 透過 ContosoIotHub 公開金鑰加密的資料,可由 ContosoIotHub 證明其擁有私密金鑰後解密

透過 IoT 中樞驗證 IoT Edge 裝置身分識別

ContosoIotHub 如何驗證其與 EdgeGateway 之間的通訊? 由於 IoT 中樞支援相互 TLS (mTLS),因此其會在用戶端驗證的 TLS 交握期間檢查 EdgeGateway 的憑證。 為求簡潔,我們將跳過下圖中的部分步驟。

顯示從IoT Edge裝置到 IoT 中樞 憑證交換的循序圖,以及憑證指紋檢查驗證 IoT 中樞。

在本案例中,EdgeGateway 會提供 IoT Edge 裝置身分識別憑證。 從 ContosoIotHub 的觀點來看,其會檢查所提供憑證的指紋是否與其記錄相符,而 EdgeGateway 的私有金鑰會與其所收到的憑證配對。 在 IoT 中樞佈建 IoT Edge 裝置時,您必須提供指紋。 IoT 中樞會用這個指紋驗證憑證。

提示

註冊 IoT Edge 裝置時,IoT 中樞需要兩種指紋。 最佳做法是備妥兩種不同的裝置身分識別憑證,且二者的到期日相異。 如此一來,就算其中一個憑證到期,另一個仍為有效,您就有時間輪替到期的憑證。 不過,您也可以只使用一個憑證進行註冊。 在註冊裝置時,同時為主要和次要指紋設定相同的憑證指紋,以使用單一憑證。

例如,我們可用下列命令,在 EdgeGateway 中取得身分識別憑證的指紋:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

此命令會輸出憑證 SHA256 指紋:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

如果檢視針對 IoT 中樞中註冊之 EdgeGateway 裝置的 SHA256 指紋值,我們可以看到其符合 EdgeGateway 上的指紋:

ContosoIotHub 中 EdgeGateway 裝置指紋 Azure 入口網站 螢幕快照。

總而言之,ContosoIotHub 能信任 EdgeGateway,因為 EdgeGateway 出示有效的 IoT Edge 裝置身分識別憑證,且指紋與 IoT 中樞上註冊的指紋相符。

如需憑證建置程序的詳細資訊,請參閱使用 X.509 憑證,在 Linux 上建立和佈建 IoT Edge 裝置

注意

此範例不探討 Azure IoT 中樞裝置佈建服務 (DPS),該服務在使用註冊群組佈建時,支援使用 X.509 CA 驗證 IoT Edge。 若使用 DPS,則需上傳 CA 憑證或中繼憑證,讓憑證鏈結經過驗證,系統才會佈建裝置。 若要深入了解,請參閱 DPS X.509 憑證證明

在 Azure 入口網站中,DPS 會顯示憑證的 SHA1 指紋,而不是 SHA256 指紋。

DPS 會將 SHA256 指紋註冊或更新至 IoT 中樞。 您可使用 openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256 命令來驗證指紋。 註冊之後,IoT Edge 就會在 IoT 中樞上使用指紋驗證。 如果裝置經過重新佈建並簽發新的憑證,則 DPS 會用新的指紋更新 IoT 中樞。

目前 IoT 中樞不支援直接使用 X.509 CA 驗證 IoT Edge。

用於模組身分識別作業的憑證

在憑證驗證圖表中,您可能以為 IoT Edge 只使用憑證來與 IoT 中樞通訊。 事實上,IoT Edge 包含許多不同的模組, 因此 IoT Edge 會使用憑證來管理傳送訊息之模組的身分識別。 模組不會使用憑證來向 IoT 中樞進行驗證,而是使用由 IoT Edge 模組執行階段產生之私密金鑰所衍生的 SAS 金鑰來進行驗證。 即使裝置身分識別憑證到期,這些 SAS 金鑰也不會改變。 如果憑證到期,則 edgeHub 之類的憑證會繼續執行,只有模組身分識別作業會失敗。

模組和 IoT 中樞之間的互動相當安全,因為 SAS 金鑰衍生自祕密,且 IoT Edge 管理金鑰時不會有人為介入的風險。

以 IoT Edge 作為網路閘道的巢狀裝置階層情節

您現在充分了解 IoT Edge 和 IoT 中樞之間的簡單互動了, 但其實 IoT Edge 也可作為下游裝置或另一個 IoT Edge 裝置的網路閘道。 這些通訊通道都必須獲得加密和信任。 由於複雜度提升,我們必須擴大範例情節以納入一個下游裝置。

我們新增一個名為 TempSensor 的一般性 IoT 裝置,其連線至父代 IoT Edge 裝置 EdgeGateway,此父代裝置連線至 IoT 中樞 ContosoIotHub。 與前文類似,所有驗證都是透過 X.509 憑證驗證進行。 我們的全新情節會引發兩個新的問題:「TempSensor 裝置合法嗎?」以及「EdgeGateway 的身分識別正確嗎?」 此情節如下圖所示:

顯示 IoT Edge 裝置、IoT Edge 閘道和 IoT 中樞 之間連線的信任案例狀態圖。

提示

TempSensor 是情節中的 IoT 裝置。 如果 TempSensor 是父代 EdgeGateway 的下游 IoT Edge 裝置,則憑證概念不變。

用裝置驗證網路閘道身分識別

TempSensor 要如何驗證與其通訊的 EdgeGateway 為正版?當 TempSensor 想要與 EdgeGateway 交談時,TempSensor 需要 EdgeGateway 才能顯示識別碼。 這項識別碼必須由 TempSensor 信任的授權單位簽發。

顯示從閘道裝置到IoT Edge裝置的憑證交換使用私人跟證書授權單位進行憑證驗證的時序圖。

這與 EdgeGatewayContosoIotHub 的通訊流程相同。 TempSensorEdgeGateway 會用 TLS 交握通訊協定驗證 EdgeGateway 的身分識別。 以下兩則細節相當重要:

  • 主機名稱明確性EdgeGateway 所出示之憑證簽發的主機名稱 (網域或 IP 位址),需與 TempSensor 用以連線至 EdgeGateway 的主機名稱相同。
  • 自我簽署的根 CA 明確性EdgeGateway 所出示的憑證鏈結應該不會出現在作業系統的預設信任根存放區。

若要了解詳細資料,請先檢視 EdgeGateway 所出示的憑證鏈結。

顯示 IoT Edge 閘道證書頒發機構單位鏈結的流程圖。

主機名稱明確性

憑證通用名稱 CN = edgegateway.local 列於鏈結頂端。 edgegateway.local 是 edgeHub 的伺服器憑證通用名稱。 edgegateway.local 也是 EdgeGateway 在本地網路 (LAN 或 VNet) 上的主機名稱,TempSensor 和 EdgeGateway 即是透過此網路彼此連線。 此網路可為私人 IP 位址,例如 192.168.1.23,也可如圖表所示為一完整網域名稱 (FQDN)。 edgeHub 伺服器憑證是使用 IoT Edge config.toml 檔案中定義的 hostname 參數所產生。 請勿混淆 edgeHub 伺服器憑證與 Edge CA 憑證。 如需管理 Edge CA 憑證的詳細資訊,請參閱管理 IoT Edge 憑證

當 TempSensor 連線到 EdgeGateway 時,TempSensor 會使用主機名稱 edgegateway.local 連線到 EdgeGateway。 TempSensor 會檢查 EdgeGateway 所提供的憑證,並確認憑證通用名稱為 edgegateway.local。 如果憑證通用名稱不同,TempSensor 會拒絕連線。

注意

為求簡潔,範例以主體憑證通用名稱 (CN) 作為已經驗證的屬性。 在實務中,如果憑證擁有主體別名 (SAN),則系統會以 SAN 而非 CN 進行驗證。 一般而言,由於 SAN 可包含多個值,因此可同時包含憑證持有者的主要網域/主機名稱,以及其他替代的網域。

為什麼 EdgeGateway 還需系統告知自己的主機名稱?

EdgeGateway 沒有得知網路上其他用戶端可與其連線的可靠方式。 例如,私人網路上可能有 DHCP 伺服器或 mDNS 服務將 EdgeGateway 列為 10.0.0.2example-mdns-hostname.local。 但其他網路也可能有 DNS 伺服器將 edgegateway.local 對應至 EdgeGateway 的 IP 位址 10.0.0.2

為了解決這個問題,IoT Edge 會使用 config.toml 中設定的主機名稱值建立伺服器憑證。 要求觸達 edgeHub 模組時,便會出示具備正確憑證通用名稱 (CN) 的憑證。

IoT Edge 為什麼要建立憑證?

請注意,範例的憑證鏈結中有 iotedged workload ca edgegateway。 那是存在於 IoT Edge 裝置上的憑證授權單位 (CA),也就是 Edge CA (前身為 1.1 版的「裝置 CA」)。 與前述範例中的 Baltimore CyberTrust root CA 類似,Edge CA 可簽發其他憑證。 最重要的是 (且同時可見於範例中),此授權單位可為 edgeHub 模組簽發伺服器憑證。 不過,其也可為 IoT Edge 裝置上執行的其他模組簽發憑證。

重要

在未經設定的預設情況下,Edge CA 會於 IoT Edge 模組執行階段首次啟動時自動產生,此時稱為快速入門 Edge CA,之後便會向 edgeHub 模組簽發憑證。 這項流程容許 edgeHub 出示經簽署的有效憑證,有助加快下游裝置連線。 少了這項功能,您就必須讓自己的 CA 為 edgeHub 模組簽發憑證。 生產環境不支援使用自動產生的快速入門 Edge CA。 如需快速入門 Edge CA 的詳細資訊,請參閱快速入門 Edge CA

裝置上擁有簽發者憑證不是很危險嗎?

Edge CA 的設計是為了實現受限、不可靠、昂貴或沒有連線能力的解決方案,但同時在憑證更新上具備嚴格的規範或原則。 少了 Edge CA,IoT Edge (尤其是 edgeHub) 就無法運作。

若要在生產環境中保護 Edge CA:

  • 請將 Edge CA 私密金鑰置於受信任的平台模組 (TPM) 中,最好使用私密金鑰暫時產生且永遠不會離開 TPM 的方式。
  • 使用積存 Edge CA 的公開金鑰基礎結構 (PKI), 這可使系統停用或拒絕更新外洩的憑證。 客戶 IT 若具備相關知識,則可自行管理 PKI (成本較低),或者也可透過商業 PKI 供應商予以管理。

自我簽署根 CA 特定性

edgeHub 模組負責處理所有連入的流量,是組成 IoT Edge 的重要元件。 在本範例中,其使用 Edge CA 簽發的憑證,也就是由自我簽署根 CA 簽發的憑證。 由於根 CA 不受作業系統信任,因此讓 TempSensor 信任的唯一方法,就是在裝置上安裝 CA 憑證。 這就是所謂的「信任搭售方案」情境;其中,您需要將根發佈至需要信任鏈結的用戶端。 信任搭售方案情境有時相當麻煩,因為您必須存取裝置並安裝憑證。 安裝憑證需要預先規劃, 例如在製造期間新增指令碼,或預先安裝於作業系統映像。

注意

有的用戶端和 SDK 不使用作業系統信任的根存放區,您必須直接傳遞根 CA 檔案。

套用這一切概念後,TempSensor 就可驗證與其通訊的 EdgeGateway 為正版,因為其出示的憑證與位址相符,且憑證已由受信任的根所簽署。

若要驗證憑證鏈結,您可使用 TempSensor 裝置上的 openssl。 在此範例中,請注意連線的主機名稱與 depth 0 憑證的 CN 相符,根 CA 也相符。

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

若要深入了解 openssl 命令,請參閱 OpenSSL 文件

您也可檢查預設儲存在 /var/lib/aziot/certd/certs 中的憑證。 您會在目錄中找到 Edge CA 憑證、裝置身分識別憑證和模組憑證。 您可使用 openssl x509 命令來檢查憑證。 例如:

sudo ls -l /var/lib/aziot/certd/certs
total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

總而言之,TempSensor 可以信任 EdgeGateway,因為:

  • edgeHub 模組為 edgegateway.local 出示有效的 IoT Edge 模組伺服器憑證
  • 該憑證由 Edge CA 簽發,簽發者為 my_private_root_CA
  • 此私人根 CA 也與先前的受信任根 CA 一樣儲存在 TempSensor
  • 密碼編譯演算法驗證所有權和簽發鏈結可受信任

其他模組的憑證

其他模組可獲得由 Edge CA 簽發的伺服器憑證。 例如具備 Web 介面的 Grafana 模組, 就能獲得由 Edge CA 簽發的憑證。 系統會視模組為裝載於容器內的下游裝置。 不過,獲得 IoT Edge 模組執行階段簽發的憑證實屬特權。 模組會呼叫工作負載 API來接收與已設定 Edge CA 鏈結的伺服器憑證。

用網路閘道驗證裝置身分識別

EdgeGateway 要如何驗證其與 ContosoIotHub 通訊? EdgeGateway 會使用「TLS 用戶端驗證」來驗證 TempSensor。

顯示從IoT Edge裝置到閘道的憑證交換,以及來自 IoT 中樞憑證的憑證檢查驗證的順序圖。

這項順序與 ContosoIotHub 驗證裝置的順序相似。 不過,在網路閘道情節中,EdgeGateway 依賴 ContosoIotHub 作為憑證記錄的事實來源。 EdgeGateway 也會保留離線複本或快取,以免與雲端的連線中斷。

提示

與 IoT Edge 裝置不同的是,下游 IoT 裝置不受限於指紋 X.509 驗證, X.509 CA 驗證亦可使用。 藉此,EdgeGateway 也能檢查 TempSensor 的憑證是否根植於上傳至 ContosoIotHub 的 CA,而非只檢查指紋是否相符。

總而言之,EdgeGateway 可以信任 TempSensor,因為:

  • TempSensor 出示具有其名的有效 IoT 裝置身分識別憑證
  • 身分識別憑證的指紋與上傳至 ContosoIotHub 的指紋相符
  • 密碼編譯演算法驗證所有權和簽發鏈結可受信任

取得憑證和管理的位置

在多數案例中,您可以提供自己的憑證,或使用自動產生的憑證。 例如,Edge CAedgeHub 憑證即為自動產生。

不過,最佳做法是設定您的裝置使用「透過安全傳輸伺服器註冊 (EST)」來管理 X.509 憑證。 使用 EST 伺服器,您就不必手動處理憑證並將其安裝到裝置上。 如需使用 EST 伺服器的詳細資訊,請參閱為 Azure IoT Edge 設定透過安全傳輸伺服器註冊

您也可以使用憑證來驗證 EST 伺服器, 這些憑證是用來驗證 EST 伺服器以簽發其他憑證。 憑證服務會使用啟動程序憑證來驗證 EST 伺服器。 啟動程序憑證可長時間存留。 一旦開始驗證,憑證服務就會要求 EST 伺服器簽發身分識別憑證。 這項身分識別憑證會在未來 EST 向同樣的伺服器提出要求時使用。

如果您無法使用 EST 伺服器,則應向 PKI 供應商要求憑證。 您可在 IoT 中樞和 IoT Edge 裝置中手動管理憑證檔案。 如需詳細資訊,請參閱在 IoT Edge 裝置上管理憑證

如要進行概念證明,請建立測試憑證。 如需詳細資訊,請參閱建立示範憑證以測試 IoT Edge 裝置功能

IoT 內的憑證

憑證授權單位

憑證授權單位 (CA) 是簽發數位憑證的實體。 憑證授權單位的身分是憑證擁有者和憑證接收者之間受信任的第三方。 數位憑證會由憑證接收者認證公開金鑰的擁有權。 信任的憑證鏈結的運作方式是一開始簽發根憑證,這是授權單位所簽發之所有憑證的信任基礎。 之後,根憑證擁有者即可簽發其他中繼憑證 (下游裝置憑證)。

根 CA 憑證

根 CA 憑證是整個流程的信任根目錄。 在生產環境情節中,這項 CA 憑證需向受信任的商業憑證授權單位購買,例如 Baltimore、Verisign 或 DigiCert。 如果您對連線到 IoT Edge 裝置的裝置擁有完整控制權,則可以使用公司層級憑證授權單位。 在上述任一情況下,從 IoT Edge 到 IoT 中樞的整個憑證鏈結都會使用它。 下游 IoT 裝置必須信任根憑證。 您可以將根 CA 憑證儲存在受信任的根憑證授權單位存放區,或在應用程式程式碼中提供憑證詳細資料。

中繼憑證

在建立安全裝置的典型製造流程中,很少直接使用根 CA 憑證,主要是因為有洩漏或曝光的風險。 根 CA 憑證會建立一或多個中繼 CA 憑證並為其進行數位簽署。 可能只會有一個中繼憑證,也可能會有由數個這類中繼憑證組成的鏈結。 需要中繼憑證鏈結的情節包括:

  • 製造商的部門階層
  • 參與同款裝置生產流程的多家公司
  • 購買根 CA 並以此獲得簽署憑證的客戶,以提供給製造商簽署代客戶製造的裝置

在任何情況下,製造商都會使用此鏈結結尾的中繼 CA 憑證來簽署放在終端裝置上的 Edge CA 憑證。 這些中繼憑證會受到製造工廠嚴密保護。 它們會經歷嚴格的流程,無論是以實體或電子方式使用皆然。

下一步