安全在任何分散式系統中都舉足輕重，物件式系統也不例外。多數物件式系統中的分散式物件就是遠端物件，其安全架構因此與一般分散式系統非常相似：每個物件都以標準的認證（authentication）與授權（authorization）機制保護。

本節先討論 Globe 的安全架構——因為 Globe 支援狀態可跨機器分散與複製的「真」分散式物件，而遠端物件只是 Globe 物件的特例，理解 Globe 的做法就能看出它如何同樣適用於較傳統的系統；之後再看傳統遠端物件的安全。

範例：Globe#

Globe 物件的狀態可實體分散與複製於多台機器，這帶來了特有的安全問題，其架構見 Popescu 等人（2002）。

總覽#

呼叫遠端物件的方法時，安全視角下至少有兩個問題：

1. 呼叫端呼叫的是正確的物件嗎？——稱為安全物件繫結（secure object binding），本質是認證問題。
2. 呼叫端有權呼叫該方法嗎？——稱為安全方法呼叫（secure method invocation），本質是授權問題。

支援複製或物件搬移的系統（如 Globe）還多了平台安全（platform security），包含兩個面向：

• 被複製進來的（本地）物件可能含惡意程式碼，平台如何自保？
• 副本伺服器可能是惡意的，物件如何自保？

物件可複製到其他主機還引出另一個問題：代管副本的物件伺服器未必完全可信，必須有機制避免每台代管伺服器都能執行物件的任何方法。例如物件擁有者可能希望更新方法只限一小群副本伺服器執行，唯讀方法則任何通過認證的伺服器皆可。這類政策的落實稱為反向存取控制（reverse access control）。

金鑰與憑證#

Globe 部署了幾種機制來建立安全性，基礎是三種公私鑰對：

• 物件金鑰（object key）：每個 Globe 物件一對。知道物件私鑰者可為使用者與伺服器設定存取政策。
• 副本金鑰（replica key）：每個副本一對，由當前代管該副本的物件伺服器產生，用來證明特定副本屬於某個分散式共享物件。
• 使用者金鑰（user key）：每位使用者一對。

存取權限以**憑證（certificate）**形式設定，逐物件發放，共三種：

• 使用者憑證：綁定特定使用者，精確指明可呼叫哪些方法。內含位元字串 U，長度等於物件的方法數；U[i] = 1 若且唯若允許呼叫方法 Mi。
• 副本憑證：指明某副本伺服器可執行哪些方法，同樣以位元字串 R 表示。
• 管理憑證（administrative certificate）：授權實體可用它簽發使用者與副本憑證；其 R 與 U 位元字串限定「可為哪些方法、哪些實體」建立憑證，另有一個位元標示是否可再委派（部分）權限。

管理者（如 Bob）簽發 Alice 的使用者憑證時，用的是自己的簽章而非物件的：Alice 的憑證必須能一路回溯到 Bob 的管理憑證、最終回溯到以物件私鑰簽署的管理憑證，形成憑證鏈。

安全繫結與驗證#

• Globe 的繫結要把 OID 解析為聯絡位址，原則上任何支援扁平名稱的系統皆可。要把物件公鑰安全地與 OID 綁定，做法是把 OID 算成公鑰的 160 位元安全雜湊——任何人都能驗證某公鑰是否屬於某 OID。這種識別碼稱為自我驗證名稱（self-certifying name），概念由 Secure File System 首創。
• 驗證副本 R 是否屬於物件 O：檢視 R 的副本憑證與簽發者；若簽發者是管理實體，再檢視其管理憑證——只要能構出最後一環以物件私鑰簽署的憑證鏈，即可確認 R 屬於 O。
• 物件與主機的互相保護採用行動碼（mobile code）的安全技術；物件是否被竄改可用特殊稽核（auditing）技術偵測。

安全方法呼叫#

從發出呼叫請求到副本實際執行操作，共 13 個依序執行的步驟：

1. 應用程式在本地呼叫對應方法發出請求，就像 RPC 呼叫程序一樣。
2. 控制子物件比對本地安全物件中的資訊檢查使用者權限（安全物件須持有效的使用者憑證）。
3. 請求被封送後傳遞下去。
4. 複製子物件請求 middleware 建立通往合適副本的安全通道。
5. 安全物件先發起副本查找——可用任何能依「可執行哪些方法」查找副本的命名服務；Globe 的定位服務已被修改以支援這類查找。
6. 找到合適副本後，安全子物件與對端建立安全通道，控制權交回複製子物件。建立過程中副本必須證明自己被允許執行該呼叫。
7. 請求交給通訊子物件。
8. 通訊子物件將請求加密並簽章後送入通道。
9. 接收端解密並認證請求。
10. 請求交給伺服器端的複製子物件。
11. 進行授權：用戶端 stub 的使用者憑證已傳給副本，可驗證請求確實可以執行。
12. 請求解封送。
13. 操作終於執行。

步驟看似繁多，但示範了安全方法呼叫如何拆解成小單元，每個單元都是「已認證的用戶端在已認證的副本上執行已授權的呼叫」所必需。幾乎所有物件式分散式系統都遵循這些步驟；Globe 的不同之處只在於需要定位合適的副本、且該副本必須證明自己可以執行該方法呼叫。

遠端物件的安全#

使用遠端物件時，物件參考本身常被實作成完整的用戶端 stub（含存取遠端物件所需的一切資訊）。最簡單的形式是參考內含確切聯絡位址、走標準封送與通訊協定；但在 Java 這類系統中，proxy 幾乎可以是任何東西——基本模式是遠端物件的開發者自己開發 proxy，註冊到目錄服務，用戶端查找物件時從目錄服務取回並安裝 proxy。這個模式有幾個嚴重問題：

• 目錄服務被劫持：攻擊者可以回傳偽造的 proxy 給用戶端，進而危及用戶端與伺服器之間的所有通訊，兩邊都受害。
• 用戶端無法認證伺服器：用戶端手上只有 proxy，所有與伺服器的通訊都必經它——等於只能單方面信任 proxy 會好好做事。
• 伺服器也更難認證用戶端：傳送敏感資訊時可能必須認證用戶端，但用戶端認證現在綁在 proxy 上，攻擊者可能冒充用戶端而傷害遠端物件。

Li 等人（2004b）提出一套通用安全架構，讓遠端物件呼叫更安全。模型假設 proxy 確實由遠端物件開發者提供並註冊於目錄服務（Java RMI 與 Jini 皆採此作法）：

• 認證遠端物件——兩步驟：
  1. 從目錄服務下載的 proxy 由遠端物件簽章，用戶端可驗證其來源。
  2. proxy 再以 TLS 伺服器認證來認證物件。確保 proxy 正確認證物件是物件開發者的責任；用戶端必須依賴這個行為，但因為它能認證 proxy，「信任物件認證」與「信任遠端物件行為端正」是同一層次的事。
• 認證用戶端——使用獨立的認證器（authenticator）：
  • 用戶端查找遠端物件時，先被導向認證器，從那裡下載認證 proxy（authentication proxy）——一個提供「讓用戶端被遠端物件認證」介面的特殊 proxy。
  • 認證成功後，遠端物件（實際上是其物件伺服器）才把真正的 proxy 交給用戶端。
  • 優點一：認證與真正 proxy 所用的協定無關，被視為重要優勢。
  • 優點二：可以發放專屬 proxy——例如某些用戶端只被允許執行唯讀方法，認證後就只拿到僅提供這些方法的 proxy；更精細的存取控制也容易想像。