ソース管理における機密情報のベストプラクティス


8

このトピックはかなり取り上げられていますが、自分の特定の状況に対する答えを見つけることができません。

現在、私は.gitignore機密コンテンツを除外し、それ(構成ファイルなど)を個別に保持するために使用しています。私のコードベースがますます多くのプロジェクトに拡大するにつれて、これは管理が非常に難しくなり、変更を追跡したり、ファイルを適切にバックアップしたりする実際の方法もありません。

そこにこの問題のためのいくつかのツールのような、ではないgit-secretHashicorp Vaultgit-crypt私は(さまざまな理由のために)私の開発のすべてを行うのWindows、これらの作品のどれも。

現在、私は自社内で作業する唯一の開発者であり、拡張する予定はありません。ソース管理(Gitlab)は、主に自分の参照と変更を記録する機能に使用されます。いくつかの接続文字列または構成ファイルをソース管理にプッシュすることは、大きな問題またはリスクになるでしょうか?その情報は現在、セキュリティで保護されていないネットワークドライブにあります(NTFSアクセス許可を除く)

私は、ベストプラクティスはこのようなものをソース管理にプッシュすることではないという考えを得ますが、ローカルネットワークの外部ではアクセスできないプライベートにホストされたGitlabインスタンスがあります-これはリスクが少ないことを意味しますか?


WindowsでHashicorp Vaultを使用できないのはなぜですか?公式ダウンロードページには、Windows用のバイナリが含まれています:vaultproject.io/downloads.html
VaaChar

git-secretはWindows bashもサポートしています:github.com/sobolevn/git-secret/pull/123
VaaChar

メインのgit-secret Webサイトにはありませんでした。私はそれをやってみます
構文エラー

機密性の高い構成に具体的に何を含めていますか?パスワードの場合は、パスワードをまったく必要としないようにオプションを確認する必要があります。
Berin Loritsch

1
AWSに$ 14kが請求された男性キーをプライベートバージョン管理に保存したが、友達と共有するためにgithubに10分間公開して公開したという話があります。
カールビーレフェルト

回答:


5

これを総合的に考えると、考慮すべき点がいくつかあります。

  • GitLabサーバーはターゲット環境と同じネットワークでホストされていますか?
  • 設定ファイルにユーザー名とパスワードがありますか?
  • セキュリティ構成を通常のアプリケーション構成から分離できますか?

最初の懸念は政策に関係しています。ソフトウェアを別のネットワークに展開する場合、構成が暗号化されていても、ポリシーの問題が発生する可能性があります。

機密情報の回避

デリケートなものについて具体的に説明します。たとえば、サーバーのドメイン名は重要ではないかもしれませんが、IPアドレスは重要かもしれません(または2つの関連付け)。通常、ユーザー名とパスワードは機密情報であり、clientIdと秘密鍵(OAuth2)も同様です。

あなたの最良のオプションは:

  • ユーザー名/パスワードを必要としない接続文字列を使用します(以下を参照)
  • 機密情報をメインのWeb.configから分離する
  • AppSettingsfile属性を使用して外部構成ファイルを読み取る

一部のデータベースでは、ユーザー名とパスワードがコンテンツの一部ではない接続文字列を使用できます。たとえば、ドメインサービスアカウントでアプリを実行して、統合セキュリティを使用してSQL Serverに接続できます。または、Oracleのウォレットを使用して、ターゲットマシンでユーザー名/パスワードを秘密に保つことができます。一部のOAuth2サービスでは、マシンの標準の場所に保存されている.csvまたは.jsonファイルを使用できます。

つまり、機密情報が属していない場所に保管しないように、できることは何でもしてください。機密ビットを読み取るためにディスク上の場所を調べるためにアプリを変更する必要がある場合は、各ターゲットサーバーで一度設定して、アプリから読み取ることができます。

構成サーバー

Steeltoeは特定のSpring統合ライブラリをC#に移植しており、Spring Cloud Configサーバーもサポートしています。Spring Cloud Configサーバーでは、デプロイネットワークに Gitリポジトリが必要ですが、必要に応じて構成をカスタマイズできます。アプリケーションが十分に複雑な場合(つまり、マイクロサービス)、サーバーが配置されているのと同じ環境でサーバー名を保護し続けるには、これを検討する価値があります。

ボトムライン

機密情報の必要性をできる限り避けたいが、機密性の低い構成はソース管理で維持したいだけです。設定ファイルのユーザー名/パスワード(つまり、統合セキュリティに相当するものがない別のデータベース)を回避できない場合は、外部ファイルからその少しだけをロードします。


2

機密情報を保存するのに最適な場所は、Hashicorp VaultWindowsをサポートするような目的に基づいて構築されたストアです。

(何らかの理由で)これを使用できない場合はgit-secret、Windowsをサポートするものも使用できます。Windowsのサポートgit-secretがこのPR に追加されました:https : //github.com/sobolevn/git-secret/pull/123

git-crypt Windowsの実験的サポートもあります。

https://github.com/AGWA/git-crypt/wiki/Installation

/programming/43040370/how-to-install-git-crypt-in-windows

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.