跳到主要內容區塊
:::
其他相關問題
    1. 『PKI-Based 應用系統對公鑰憑證處理之安全檢查表』條列出應用系統在處理X.509公鑰憑證 (一般檢簡稱「憑證」) 時應注意的基本安全事項。應用系統上線前應逐項檢查是否符合各安全事項的規定,確定安全無虞後才可上線。
    2. 『PKI-Based 應用系統對公鑰憑證處理之安全檢查表』共有十八條,詳見GPKI各CA網站之儲存庫。其中第二到第十五條可用GPKI 安全保密函式庫HiSECURE SDK 解決,第一、十六、十七及十八條可用其他方式解決。
    3. 『PKI-Based 應用系統對公鑰憑證處理之安全檢查表』主要分為兩個階段的檢查:一為CA端憑證的檢驗;另一為用戶端憑證的檢驗。主要的原因為GPKI為三層式的憑證機構架構,因此第三到第八條的檢查方 與第九到第十四條相同。
    4. 本安全事項檢查表僅列出與憑證相關的「基本」安全事項,不同的應用系統有不同的特性與複雜度,應用系統管理者應該根據系統的特性與複雜度,考慮是否有其他憑證相關的安全事項需納入檢查。
    5. 本安全事項檢查表僅列出與憑證相關的安全事項,憑證相關安全事項僅是整體系統安全的其中一個環節,其他與憑證無關的安全事項例如作業系統安全漏洞修補 (Patch) 、電腦病毒防治、防火牆設定、入侵偵測、系統安全功能的啟用、非必要服務的關閉等,應用系統管理者應該制訂一套完整的安全政策 (Security Policy) ,並實施必要的措施以符合安全政策對所有安全事項的要求。
    1. 『PKI-Based 應用系統對公鑰憑證處理之安全檢查表』條列出應用系統在處理X.509公鑰憑證 (一般檢簡稱「憑證」) 時應注意的基本安全事項。應用系統上線前應逐項檢查是否符合各安全事項的規定,確定安全無虞後才可上線。
    2. 系統應該設定所信賴的憑證保證等級,並檢查憑證之憑證政策(Certificate Policies)欄位所記載的Policy OID是否符合憑證保證等級的要求,並對於不符保證等級的憑證應該加以拒絕(例如正式上線系統應該對測試等級的憑證加以拒絕)。
    3. 系統應該檢查CA本身的憑證確實為Root CA所簽發的憑證(至少需檢查憑證的Issuer Name(DN)是否與Root CA自簽憑證的Subject Name(DN)相符,並以Root CA自簽憑證所記載的Public Key檢驗CA本身憑證的簽章)。
    4. 系統應該檢查CA本身的憑證確實為合法的CA憑證(BasicConstraints欄位標示為CA憑證)且憑證之金鑰用途(KeyUsage)欄位允許keyCerSign及cRLSign的用途。
    5. 系統應該檢查CA本身的憑證是否仍在有效期限之內(例如檢查系統時間是否仍落在憑證所記載的Validity時間範圍內)。
    6. 系統應該檢查CA本身的憑證是否已被廢止(例如定期下載Root CA簽發的CARL來檢查憑證廢止狀態)。
    7. 系統應該檢查CARL是否確實是Root CA所簽發(至少需檢查CARL的Issuer Name(DN)是否與Root CA自簽憑證的Subject Name(DN)相符,並以Root CA自簽憑證所記載的Public Key檢驗CARL的簽章)。
    8. 系統應該檢查CARL是否為最新公佈的CARL(當天公佈的CARL)。
    9. 系統應該檢查用戶的憑證確實為合法CA所簽發的憑證(至少需檢查用戶憑證的Issuer Name(DN)是否與CA憑證的Subject Name(DN)相符,並以CA憑證所記載的Public Key檢驗用戶憑證的簽章)。
    10. 系統應該檢查用戶憑證金鑰用途(KeyUsage)欄位所記載的金鑰用途符合使用目的(簽章/驗簽或加密/解密)。
    11. 系統應該檢查用戶的憑證是否仍在有效期限之內(例如檢查系統時間是否仍落在憑證所記載的Validity時間範圍內)。
    12. 系統應該檢查用戶的憑證是否已被廢止(例如定期下載CA簽發的CRL來檢查憑證廢止狀態或透過OCSP來檢查憑證廢止狀態)。
    13. 系統應該檢查CRL是否確實是合法CA所簽發(至少需檢查CRL的Issuer Name(DN)是否與CA本身憑證的Subject Name(DN)相符,並以CA本身憑證所記載的Public Key檢驗CRL的簽章)(如果使用OCSP查詢,則本項不適用)。
    14. 系統應該檢查CRL是否為最新公佈的CRL(當天公佈的CRL)(如果使用OCSP查詢,則本項不適用)。
    15. 系統應該要求用戶對傳送的訊息加簽電子簽章以驗證用戶身分。
    16. 系統應該要具備防止或偵測用戶加簽之訊息遭到非法重送(Replay)的機制(例如在加簽訊息中加入Challenge-Response或Nonce機制)。
    17. 系統傳送用戶隱私資料時應該要以強度128 bits以上的安全通道加以保護(例如使用SSL安全通道或是對傳送的訊息以數位信封加密)(若系統並不涉及傳送用戶隱私資料時,則本項不適用)。
    18. 系統應該定期校時,以保持系統時間之正確性(例如定期透過NTP自動校時)。