安全復制的分步說明？

Question

不確定問題是否應該在ServerFault上 ？

我在我的服務器上使用Apache憑據進行了一個couchDB設置（但如果分散注意力，我可以關閉它）。
我在各種筆記本電腦上都有本地實例。 現在我想設置安全（連續）復制。 根據我的理解，我可以使用用戶名/密碼，SSL證書或OAuth。 我發現了一些信息：

• 關於serverFault的SSL問題
• 復制時的WIKI條目
• 如何在wiki中進行復制
• 關於1.2復制的要點
• 復制algorythm

所有這些文件都增添了預感，但也讓人感到困惑（我只是一個簡單的想法 ）。

我正在尋找的是一步一步的指導：

• 適用於OAuth或SSL證書的Pro和con（可選討論）
• 設置SSL組件的步驟澄清 ：我不是在尋找SSL傳輸安全性 - 對於Apache HTTP和CouchDB來說，這並不是很復雜並且記錄得很好。 我正在尋找的是使用證書進行身份驗證 ，類似於您在SSH中可以執行的操作。 我在OAuth中看到的潛在問題：管理員可以完全訪問憑據（？）。 使用證書方法，他不能冒充用戶，因為私鑰不受管理員控制。
• 設置OAuth的步驟
• 每個用戶的示例復制文檔使用具有一些文檔的本地副本並共享一個oneline

我在哪里可以找到它？

Answer 1

安全傳輸用戶憑據是一個非常棘手的問題。

如果我們不想第三方，在大多數情況下，SSL是更好的開始方式，因為它可能會被您使用的每個工具廣泛支持。 SSL證書，不僅提供加密（甚至是自簽名的加密），還提供用戶請求正確資源的保險。 如果您關心服務器安全性，最后一個選項也值得強調。 SSL使用的主要缺點是性能下降（因使用的算法而異），因為服務器必須解密數據，並且除了常見的通信例程之外，客戶端還需要驗證證書。 此外，你必須為可靠的證書支付一些錢（ 並非總是如此 ）。

使用OAuth可以不泄露真實的用戶憑據，並且可以輕松地從服務器端維護其訪問控制。 此外，您需要一些能夠正確處理OAuth 1.0規范的庫，如果您的平台錯過了 - 您必須自己實現它。 另外OAuth提供傳輸數據簽名，因此它旨在為MiTM案例提供安全保障。 這實際上就是他所做的一切。

如您所知，SSL和OAuth有兩個不同的東西：SSL有助於在傳輸級別（TLS）上加密數據，而OAuth會在非安全環境中處理憑據泄露。 它們不是彼此的替代品，但是它們中的每一個都可以替代其他的。

要為CouchDB設置SSL支持，請按照文檔指南進行操作 。 這很簡單易行。 請注意，如果CouchDB前面有一些代理服務器，那么為他設置SSL並通過常規HTTP協議將代理數據代理到本地CouchDB實例可能是明智之舉。

要設置OAuth，需要執行以下步驟：0。確保{couch_httpd_oauth, oauth_authentication_handler} [httpd]部分的authentication_handlers選項的{couch_httpd_oauth, oauth_authentication_handler}處理程序存在於default.ini配置文件中：

[httpd] authentication_handlers = {couch_httpd_oauth，oauth_authentication_handler}，{couch_httpd_auth，cookie_authentication_handler}，{couch_httpd_auth，default_authentication_handler}

之后，您需要以下一種方式編輯local.ini文件：

1. 設置消費者秘密：

[oauth_consumer_secrets] 
example.org = sekr1t

1. 設置令牌機密：

[oauth_token_secrets] 
token1 = tokensekr1t

1. 將令牌映射到已存在的CouchDB用戶：

[oauth_token_users] 
token1 = joe

就這樣！ 如果您有CouchDB 1.2或更高版本，您還可以在_users數據庫中的用戶文檔中定義OAuth憑據：

{
    "_id": "org.couchdb.user:joe",
    "type": "user",
    "name": "joe",
    "password_sha": "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
    "salt": "4e170ffeb6f34daecfd814dfb4001a73"
    "roles": ["foo", "bar"],
    "oauth": {
        "consumer_keys": {
            "example.org": "sekr1t",
            "consumerKey2": "key2Secret"
        },
        "tokens": {
            "token1": "tokensekr1t",
            "token2": "token2Secret"
       }
    }
}

現在，當我們為用戶joe設置OAuth憑據時，讓我們開始復制。 要讓CouchDB使用OAuth憑據，我們需要擴展source或target字段，具體取決於哪一方將授權我們的用戶：

{
    "source": "mailbox",
    "target": {
        "url": "https://secure.example.org/mailbox",
        "auth": {
            "oauth": {
                "consumer_secret": "sekr1t", 
                "consumer_key": "example.org", 
                "token_secret": "tokensekr1t", 
                "token": "token1" 
            }
        } 
    } 
}

並將此數據POST到_replicate資源或為_replicator數據庫創建文檔。 復制將使用SSL協議加密從本地服務器啟動到遠程secure.example.org ，所有操作都將通過登錄joe進行遠程用戶操作。

總結：SSL和OAuth的組合不僅可以保護傳輸的數據（不僅是用戶憑證），還可以保證目標服務器不是偽造的，還可以保護真實用戶登錄名和密碼免於意外泄露，控制消費者來源（例如，如果example.org將被泄露，我們只能刪除他的消費者令牌，但不能強迫用戶更改他的密碼）並簽署針對MiTM攻擊的額外保護請求。

更新 ：對於您的情況，常規SSL證書例程是可以的：您需要創建自己簽名的個人證書，並讓客戶設置以便與CouchDB進一步協作。 CouchDB方面唯一需要的是在處理連接之前驗證證書。 但請注意，自定義個人SSL證書安裝可能並非易事，特別是對於移動客戶端。

對於OAuth方面，CouchDB 可能會使用RSA-SHA1身份驗證方法，該方法使用某種個人證書進行保密。 但是，您需要首先修補源以解鎖此方法 - 默認情況下禁用它。