web-dev-qa-db-ja.com

APIキーなどの秘密情報をソース管理外に保つための戦略？

ユーザーがOAuth Twitter、Googleなどの認証情報を使用してログインできるようにするWebサイトに取り組んでいます。これを行うには、これらのさまざまなプロバイダーに登録して取得する必要があります。さまざまな体の部分に対する誓約で保護しなければならない超秘密のAPIキーです。私のキーが壊れている場合、その部分はヤンクされます。

APIキーは、認証リクエストを実行するために実行時に使用されるため、私のソースと一緒に移動する必要があります。私の場合、キーはアプリケーション内の構成ファイル内またはコード自体内に存在する必要があります。 1台のマシンで構築して公開する場合は、問題ありません。ただし、ソースコントロールを混在させると、状況はさらに複雑になります。

私は安価なろくでなしなので、クラウドやGitHubでTFSなどの無料のソース管理サービスを使用したいと思います。これは私に少し難問を残します：

APIキーがコード内にあり、コードがパブリックリポジトリで利用できる場合、どうすれば体をそのまま保つことができますか？

これを処理する方法はいくつも考えられますが、どれも満足できるものはありません。

  • コードからすべての個人情報を削除し、展開後に編集することができます。これは、実装するのが大変な苦痛であり（多くの方法については詳しく説明しません）、オプションではありません。
  • 暗号化できました。しかし、私はそれを解読しなければならないので、ソースを持っている人なら誰でも、それを行う方法を見つけることができます。無意味。
  • 私は個人的なソース管理にお金を払うことができました。 LOL j/kはお金を使いますか？お願いします。
  • 言語機能を使用して、残りのソースから機密情報を分離し、ソース管理から除外することができます。これは私が現在行っていることですが、秘密ファイルを誤ってチェックインすることで簡単に失敗する可能性があります。

私は、開発、デバッグ、展開を通じてスムーズに機能し、誰にでもできるように、プライベートを世界（スナップチャットを除く）と共有しないことを保証する保証された方法を本当に探しています。これは完全に非現実的です。 それで、現実的に私は何ができますか？

技術詳細：VS2012、C＃4.5、ソース管理はTFサービスまたはGitHubのいずれかになります。現在、部分クラスを使用して、機密性の高いキーを、ソース管理に追加されない別の.csファイルに分割しています。 .gitignoreを使用して部分クラスファイルがチェックインされないようにすることができるので、GitHubには利点があると思いますが、以前にそれを台無しにしました。 「ああ、よくある問題、これはあなたがそれを行う方法です」を望んでいますが、私は「それができるだけ多くを吸わない」ために解決しなければならないかもしれません：/

project-managementversion-controldevelopment-processapi
219
Ripped Off

コードに秘密情報を入れないでください。起動時にコードによって読み取られる構成ファイルに入れます。構成ファイルは、「工場出荷時のデフォルト」でない限り、バージョン管理の対象にしないでください。また、個人情報を含めないでください。

これをうまく行う方法については、質問 バージョン管理と個人設定ファイル も参照してください。

130
Philipp

すべての秘密キー/保護キーをシステム環境変数として設定できます。構成ファイルは次のようになります。

private.key=#{systemEnvironment['PRIVATE_KEY']}

これがこれらのケースを処理する方法であり、コードには何も入りません。さまざまなプロパティファイルやプロファイルと組み合わせると、非常にうまく機能します。環境ごとに異なるプロパティファイルを使用します。ローカル開発環境では、ローカルセットアップを簡略化するために、プロパティファイルに開発キーを配置します。

private.key=A_DEVELOPMENT_LONG_KEY
29
Ioannis Tzikas

純粋なGitの方法

  • .gitignoreプライベートデータを含むファイル
  • TEMPLATEをDATAに置き換えるローカルブランチを使用する
  • （ローカル）フィルターのスクリプトが双方向の置換を実行するsmudge/cleanフィルターを使用するTEMPLATE <-> DATA

Mercurial way

  • TEMPLATEをDATAに置き換えるダミーコードの上にあるMQパッチ（変更セットはパブリック、パッチはプライベート）
  • 特別に設計されたキーワードを使用したキーワード拡張（作業ディレクトリでのみ展開されます）

SCMに依存しない方法

  • ビルド/デプロイプロセスの一部としてキーワードを置き換える
27
Lazy Badger

暗号化されたファイルにシークレットを入れ、それをコミットします。パスフレーズは、システムの起動時に提供されるか、私がコミットしない小さなファイルに保存されます。 Emacsがこれらの暗号化されたファイルを陽気に管理するのは素晴らしいことです。たとえば、emacs initファイルには次のものが含まれます：（load "secrets.el.gpg"）、これは機能します-エディターを起動すると、これらのまれな作業でパスワードの入力を求められます。誰かが暗号を破る心配はありません。

14
Ben Hyde

これはAndroid/Gradle固有ですが、gradle.propertiesにあるグローバルuser home/.gradle/ファイルでキーを定義できます。これは、buildTypeまたはフレーバーに応じて異なるプロパティを使用できるため、つまり、開発用のAPIとリリース用の異なるAPIを使用できるので便利です。

gradle.properties

MY_PRIVATE_API_KEY=12356abcefg

build.gradle

buildTypes {
        debug{
            buildConfigField("String", "GOOGLE_VERIFICATION_API_KEY", "\"" + MY_PRIVATE_API_KEY +"\"")
            minifyEnabled false
            applicationIdSuffix ".debug"
            }
        }

あなたはこのように参照するコードで

String myAPI = BuildConfig.GOOGLE_VERIFICATION_API_KEY;
14
scottyab

そのキーをアプリケーションと一緒に配布したり、ソースコードリポジトリに格納したりすることは想定していません。この質問は、それを行う方法を尋ねていますが、それは通常行われることではありません。

モバイルWebアプリケーション

Android/iPhoneの場合、アプリが最初に実行されるときに、デバイスは独自のWebサービスにKEYを要求する必要があります。その後、鍵は安全な場所に保管されます。キーが変更されたか、発行者によって取り消された場合。 Webサービスは新しいキーを公開できます。

ホストされたWebアプリケーション

ソフトウェアのライセンスを使用しているお客様は、ソフトウェアを最初に構成するときにキーを手動で入力する必要があります。全員に同じ鍵を与えることも、異なる鍵を与えることもできます。

公開されたソースコード

ソースコードは公開リポジトリに保存しますが、KEYは保存しません。ファイルの設定で、行*place key here*を追加します。開発者がソースコードを使用すると、sample.cfgファイルのコピーが作成され、独自のキーが追加されます。

開発または本番で使用するyourconfig.cfgファイルをリポジトリに保存しません。

11
Reactgular

サーバーごとに変化する秘密のものに環境変数を使用します。

http://en.wikipedia.org/wiki/Environment_variable

それらの使い方は言語に依存します。

5
Filipe Giusti

これは、ある時点で誰もが問題を抱えている問題だと思います。

これが私が使用したワークフローです。ひねりを加えた.gitignoreを使用します。

  1. すべての構成ファイルは特別なフォルダーに格納されます（サンプル構成ファイル付き-オプション）
  2. すべての構成ファイルは.gitignoreに含まれているため、公開されません
  3. プライベートボックスにgitoliteサーバー（またはお気に入りのgitサーバー）をセットアップする
  4. プライベートサーバー内のすべての構成ファイルを含むリポジトリを追加する
  5. スクリプトを追加して、構成ファイルをメインリポジトリの特別なフォルダーにコピーします（オプション）。

これで、構成リポジトリを任意の開発およびデプロイメントシステムに複製できます。スクリプトを実行してファイルを正しいフォルダーにコピーするだけで完了です。

すべてのGitHubキャンディーを引き続き入手し、コードを世界と共有します。機密データはメインリポジトリに存在しないため、公開されません。それらは、依然として、デプロイメントシステムから離れたプルとコピーにすぎません。

私はプライベートgitサーバーに年間15ドルのボックスを使用していますが、cheapskateの要件に応じて自宅でセットアップすることもできます;-)

PS：gitサブモジュール（ http://git-scm.com/docs/git-submodule ）を使用することもできますが、私は常にコマンドを忘れているので、ルールは素早く簡単です。

4
Kostas

暗号化を使用しますが、起動時にマスターキーをコンソールのパスワードとして、プロセスのユーザーのみが読み取ることができるファイルで、またはMac OSキーチェーンやWindowsキーストアなどのシステム提供のキーストアから提供します。

継続的に配信するには、さまざまなキーをどこかに記録する必要があります。構成はコードから区別する必要がありますが、リビジョン管理下に置くことは非常に理にかなっています。

2
erickson

まだ言及されていない3つの戦略（？）

チェックイン時またはVCSの事前チェックインフック

  • エントロピーの高い文字列を検索します。例- detect-secrets
  • よく知られているAPIキーパターンの正規表現検索。 AWSのAKIA *キーは一例であり、 git-secrets はそれに基づくツールの1つです。また、定数が割り当てられた「password」などの変数名。
  • 既知の秘密を検索-あなたはあなたの秘密を知っており、それらのテキストを検索します。または、ツールを使用して、これを書いた 概念実証 。

すでに述べた戦略

  • ソースツリー外のファイルに保存
  • ソースツリーにありますが、VCSにそれを無視するように伝えます
  • 環境変数は、ソースツリーの外にデータを保存することのバリエーションです
  • 開発者に貴重な秘密を与えないでください
1
MatthewMartin

ソース管理から個人情報を守ります。ロードされていない配布用のデフォルトを作成し、VCSに実際のデフォルトを無視させます。インストールプロセス（手動、構成/ビルド、ウィザード）は、新しいファイルの作成と入力を処理する必要があります。必要に応じて、ファイルの権限を変更して、必要なユーザー（webserver？）だけがファイルを読み取れるようにします。

利点：

  • 開発エンティティ==生産エンティティを想定していません
  • すべての共同編集者/コードレビュー担当者が信頼されているとは限りません
  • バージョン管理の対象外とすることで、簡単な間違いを防ぎます
  • QA /ビルドのカスタム構成でインストールを自動化するのは簡単

既にこれを行っていて、誤ってチェックインしている場合は、プロジェクトの.gitignoreに追加してください。これにより、再度行うことができなくなります。

そこにはareプライベートリポジトリを提供する無料のGitホストがたくさんあります。資格情報をバージョン管理することはできませんが、安価でプライベートリポジトリを持つこともできます。 ^ _ ^

0
Adrian Schneider