APIキーなどの秘密情報をソース管理から守るための戦略は？

私は、ユーザーがTwitter、GoogleなどのOAuth資格情報を使用してログインできるようにするWebサイトに取り組んでいます。これを行うには、これらのさまざまなプロバイダーに登録し、所有している極秘APIキーを取得する必要がありますさまざまな身体部分からの誓約で保護する。キーがギャンクされると、パーツがヤンクされます。

APIキーは実行時に認証要求を実行するために使用されるため、ソースと共に移動する必要があります。私の場合、キーはアプリケーション内の構成ファイルまたはコード内に存在する必要があります。単一のマシンからビルドして公開する場合、それは問題ではありません。ただし、ソース管理をミックスに組み込むと、事態はさらに複雑になります。

私は安っぽい野郎なので、クラウド内のTFSやGitHubなどの無料のソース管理サービスを使用することを好みます。これにより、若干の難問が残ります。

APIキーがコード内にあり、コードが公開リポジトリで利用可能な場合、どうすれば体を傷つけずに保持できますか？

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

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

開発、デバッグ、展開を通じてスムーズに動作し、同様に確実に動作するプライベートを世界と共有しないことを保証する方法を本当に探しています（snapchatを除く）。これは完全に非現実的です。 それでは、現実的に何ができますか？

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

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

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

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

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

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

private.key=A_DEVELOPMENT_LONG_KEY

Pure Gitの方法

• .gitignore プライベートデータを含むファイル
• ここであなたが置き換え、ローカルブランチを使用しTEMPLATEてDATA
• 汚れ/クリーンフィルターを使用します。（ローカル）フィルターのスクリプトは双方向の置換を実行しますTEMPLATE<->DATA

マーキュリアルウェイ

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

SCMに依存しない方法

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

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

これは非常に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;

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

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

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

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

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

公開されたソースコード

ソースコードはパブリックリポジトリに保存しますが、KEYには保存しません。ファイルの設定で、行を追加します* ここにキーを配置します *。開発者がソースコードを使用する場合、sample.cfgファイルのコピーを作成し、独自のキーを追加します。

config.cfg開発または本番用のファイルをリポジトリに保持しません。

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

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

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

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

私が使用したワークフローは次のとおりです。ひねりを加えた.gitignoreを使用します。

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

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

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

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

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

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

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

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

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

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

すでに述べた戦略

• ソースツリーの外部のファイルに保存する
• ソースツリーにあるが、VCSに無視するように指示する
• 環境変数は、ソースツリーの外部にデータを保存するバリエーションです
• 開発者に貴重な秘密を明かさないでください

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

利点：

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

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

プライベートリポジトリを提供する無料のGitホストがたくさんあります。資格情報のバージョン管理は絶対にしないでくださいが、安価でプライベートリポジトリも使用できます。^ _ ^

OAuthキーを生データとしてどこかに保存する代わりに、何らかの暗号化アルゴリズムで文字列を実行し、ソルトハッシュとして保存しませんか？次に、構成ファイルを使用して実行時に復元します。そうすれば、キーは開発ボックスに保存されているかサーバー自体に保存されているかにかかわらず、どこにも保存されません。

サーバーがリクエストごとにソルトおよびハッシュされた新しいAPIキーを自動的に生成するようにAPIを作成することもできます。この方法では、チームでさえOAuthソースを見ることができません。

編集：おそらくスタンフォードJavascript Crypto Libraryを試してみてください。かなり安全な対称暗号化/復号化が可能です。