4

質問がServerFaultにあるべきかどうかわからない？

サーバーにApacheクレデンシャルを使用してcouchDBをセットアップしています（ただし、気が散る場合はオフに切り替えることができます）。
さまざまなラップトップにローカルインスタンスがあります。ここで、安全な（継続的な）レプリケーションをセットアップしたいと思います。私の理解では、ユーザー名/パスワード、SSL証明書、またはOAuthを使用できます。私は情報の断片を見つけました：

このすべてのドキュメントは、予感を加えましたが、混乱ももたらしました（私は単純な心です）。

私が探しているのは、ステップバイステップの説明です。

  • OAuthまたはSSL証明書の賛否両論（オプションの説明）
  • SSLコンポーネントをセットアップする手順説明：SSLトランスポートセキュリティを探していません。これはそれほど複雑ではなく、ApacheHTTPとCouchDBの両方で十分に文書化されています。私が探しているのは、SSHでできることと同様に、証明書を使用した認証です。OAuthで発生する可能性のある問題：管理者は資格情報（？）に完全にアクセスできます。証明書アプローチでは、秘密鍵が管理者の管理下にないため、ユーザーになりすますことはできません。
  • OAuthを設定する手順
  • 各ユーザーのサンプルレプリケーションドキュメントは、いくつかのドキュメントでローカルレプリカを使用し、1行を共有します

どこで見つけられますか？

4

1 に答える 1

5

ユーザー資格情報の安全な転送は非常にデリケートな質問です。

サードパーティを検討しない場合、ほとんどの場合、SSLは、使用する可能性のあるすべてのツールで幅広くサポートされているため、最初から始めるのに適しています。SSL証明書は、暗号化（自己署名証明書も含む）だけでなく、ユーザーが適切なリソースを要求したことを保証します。サーバーのセキュリティに関心がある場合は、最後のオプションも強調する価値があります。SSL使用の主な欠点は、サーバーがデータを復号化する必要があり、クライアントが一般的な通信ルーチンに加えて証明書を検証する必要があるため、パフォーマンスの低下（使用されるアルゴリズムによって異なります）です。また、信頼できる証明書にいくらかのお金を払う必要があります（常に正しいとは限りません）。

OAuthを使用すると、実際のユーザー資格情報を開示せず、サーバー側からのアクセス制御を簡単に維持できます。また、OAuth 1.0仕様を適切に処理するライブラリが必要であり、プラットフォームがそれを見逃している場合は、独自に実装する必要があります。追加のOAuthは転送データ署名を提供するため、MiTMの場合に安全であることを目的としています。実際、彼がしているのはそれだけです。

お気づきのとおり、SSLとOAuthは2つの異なるものです。SSLはトランスポートレベル（TLS）でデータを暗号化するのに役立ちますが、OAuthは安全でない環境での資格情報の開示を処理します。それらはお互いに置き換わるものではありませんが、それぞれが他のものと同じように優れている可能性があります。

CouchDBのSSLサポートを設定するには、ドキュメントガイドに従ってください。とてもシンプルで簡単です。CouchDBの前にプロキシサーバーがある場合は、そのサーバー用にSSLを設定し、通常のHTTPプロトコルを介してローカルCouchDBインスタンスにデータをプロキシするのが賢明かもしれないことに注意してください。

OAuthを設定するには、次の手順を実行する必要があります。0.構成ファイルのセクションのオプションに{couch_httpd_oauth, oauth_authentication_handler}ハンドラーが存在することを確認します。authentication_handlers[httpd]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認証方式を使用する場合があります。ただし、このメソッドのロックを解除するには、最初にソースにパッチを適用する必要があります。デフォルトでは無効になっています。

于 2013-02-28T07:07:34.380 に答える