中央のソースリポジトリをどこに維持しますか?


10

ソースコードへのアクセスのセキュリティ保護に関する業界のベストプラクティスは何ですか?Apacheを介したSSLのみの接続が、他と競合しない不明瞭なポートでサーバーに許可されていると考えています。面倒なのは、ソースコードをパブリックサーバーに保存することです。つまり、LAN経由でのみアクセスできるわけではありません。さらに、このサーバーにはいくつかの用途があります。Apacheはすでに他の社内Webサイトを提供しています。正しい資格情報を持っている限り、誰もがどこからでも(自宅、空港など)ソースコードにアクセスできるようにしたいと思います。提案?

回答:


13

公開サーバー上にあることに懸念があるが、どこからでもアクセスしたい場合は、開発者にクライアントベースのVPNを使用してリモートでネットワークにログインし、内部のソース管理サーバーにアクセスすることを検討する必要があります。


1
VPNがSSL / TLSベースのサーバーよりも安全であると考える理由について、どちらも「公開」である必要があるという理由で説明できますか?VPNは、SSL / TLSに使い慣れた暗号化を使用します。したがって、VPNをハッキングできれば、すべてが手に入ります。
Matt

1
@マットリポジトリをパブリックセグメントに配置する理由がなければ、なぜそこに置くのでしょうか。さらに、VPNには彼の開発者にとって他の利点があるかもしれません。また、「VPNはSSL / TLSよりも安全である」とはどこにも言わなかったので、口の中に言葉を入れないでください。)
phoebus

1
そうだね。私の声明ではセキュリティが暗示されていると感じました。多分あなたはこれを修飾することができます:「あなたがそれが公に面しているサーバー上にあるのが心配なら」
Matt

私の意見では、VPNの背後にプライベートサーバー/サービスを配置することは、階層化アプローチの一部です。ソースを公開する可能性のある構成エラーから保護するのに役立ちます。必須ではありませんが、スマートです。
Martijn Heemels 2011

4

なぜ人々がVPNアプローチが最善であると考えているのか、私にはあまりわかりません。それは必ずしも安全である必要はなく、私が考えることができる1つの利点のみを提供します。

たとえば、PPTPはセキュリティが理想的とは言えないことが知られていますが、最初に導入されてから多少改善されていると思います...使用するVPNソリューションに注意してください。OpenVPNまたはIPSECを使用します。

ただし、VPNがなければSSL / TLSの利便性を打ち負かすことはできません(下をお読みください)。そして、それをさらに安全にするために、証明書のみにすることができます。

ただし、ソース管理以外の他のサービスを提供すると思われる場合は、VPNソリューションを検討してください。VPNソリューションは、他のサービスをトンネリングするためです。

VPNを使用する場合の不利な点は、PCが接続先のネットワークの一部になることです。それも利点になり得ます。しかし、家から100万マイル離れた場所にいて、ホームベースへのネットワーク接続があまり速くない場合は、差分を作成したり、コードをチェックインまたはチェックアウトしたりするたびに、VPNの接続と切断を行うことがあります。

私は開発者であるため、ここで個人的な経験から話すことができます。これを行うのは、お尻が本当に苦痛でした!!! 理想的には、両方のオプションが推奨されます。

したがって、ウェブなどを閲覧する場合は、ニュースなどを読むのが遅くなる可能性があります。しかし、少なくともあなたは電子メールに安全にアクセスできます。最初にそれをどのように使用するかを検討してください...もし私があなただったら、両方を実装することを検討します。


3

実際、私はあなたの提案が好きです。SSL / TLSを介してのみソースコードリポジトリにアクセスできるようにし、開発者がブルートフォースが簡単なパスフレーズを使用しないことを確認した場合(さらには、証明書を使用すること)、それは何よりも安全なはずです。 。

代わりに、LAN内でサーバーを非表示にして、開発者にVPNを使用してアクセスを強制することもできますが、これは、開発者がユーザー名/パスワード(および/または証明書)を別のログインボックスに入力する必要があることを意味します。単一のサービスへのアクセスを許可するためだけに、セキュリティへの影響が常に明らかであるとは限らないネットワークにエントリポイントを作成しないことをお勧めします。VPNがすでに構成され、他の用途のために保護されている場合は、間違いなく簡単です。先に進んでそれを使用してください。それ以外の場合は、SSL / TLSを介してサービス自体を直接利用できるようにする方が簡単で安全です。


3

業界標準はおそらくあなた(またはあなたの顧客)の業界が何であるかに依存します:-)

実際には、誰にアクセス権を与えたいか、そして彼らが何を処理できるかを考える必要があります。あなたがアクセスしたい/必要とするかもしれない一部の人々は、ユーザー名/パスワード以上のものを処理することができません。他の人はsshに首を突っ込むことができるかもしれませんが、秘密鍵はあなたが安全に鍵を手に入れることができれば悪くありません。TortoiseSVNクライアントはssh + svnを処理でき、少しひねって秘密鍵をサポートします。私の目的にはそれで十分です。

VPNトンネルも公平な提案ですが、多くの場所では、ネットワーク全体ではなく、ソースコントロールだけに外部の人々にアクセスを許可することができます。


2

他の人と同じように、私はVPNを好みます。別の方法としては、SSHトンネルを使用します。これは、実際のところ、VPNの一種だと思います。


0

内部専用にして、リモートユーザーVPNソリューションを実装します。/ Doh-重複。


0

どこからでもアクセスしたい場合は、公開サーバーが必要です—それだけは明らかです。

そのサーバーでは、できるだけ公開しないようにします。できればMercurial / Subversionだけを公開し、それ以外は何も公開しないようにします。これは、セキュリティの侵害がソ​​ース管理から社内の他の部門に広がるのを防ぐためです。そのため、VPNは危険である可能性があるとマットが言ったとき、私は同意ます。VPNは必要以上に広いアクセスを提供します。

Mercurialの場合、を使用hg-sshして、SSH経由で接続するクライアントが使用できるコマンドを制限することで、問題を厳しくロックできます。SSHを使用することで、クライアントがパスワードではなく公開鍵認証を使用することを簡単に要求できます。これにより、ブルートフォースログイン攻撃からサーバーが保護されます。

SSHキーが危険にさらされている場合(おそらく、パスフレーズが脆弱で、それを格納しているラップトップが盗まれた可能性があります)、攻撃者が行うことができる最悪の被害は、Mercurialにガベージ履歴を追加することです。使用されるプロトコルは本質的に追加専用であるため、で削除できるものはありませんhg push

HTTPSの場合、認証はフロントエンドウェブサーバーによって行われます。つまり、必要に応じてクライアントサイトの証明書を要求し、上記のSSH公開鍵認証のようなセキュリティを確保できます。

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