☰

安全な読み取り専用セルフホスティングGitスクリプトストア

tag-icon • tag-icon security git
安全な読み取り専用セルフホスティングGitスクリプトストア

特定のユーザーがリポジトリへの読み取りおよび書き込みアクセス権を持ち、このリポジトリを使用していくつかのスクリプトを実行する管理サーバーは、gitサーバー上の同じリポジトリへの読み取り専用アクセス権を持つgitサーバーを構築する必要があります。

子サーバートポロジ

設定はできるだけ安全でなければなりません。これまで私はこれをやってきました。珪藻土devicesリポジトリの構成は次のとおりです。

repo devices
    RW     =   eng1
    RW     =   eng2
    RW     =   eng3
    R      =   graphs

ユーザーのSSHキーペアはサーバーのユーザーホームディレクトリにgraphs保存され、秘密キーはそのユーザーのみを読み書きできます。この秘密鍵はパスワードで保護されません。mgmt-svrgraphsgraphs

これを達成するためのより安全な方法はありますか？ HTTPSを使用してgitサーバーとネイティブアクセス認証のリポジトリにアクセスすることを検討しましたが、devices現在SSHベースの設定に比べて利点はありません。それでも、graphsユーザーのホームディレクトリのどこかにアクセス資格情報を保存する必要があります。 。

答え1

gitlabCIの展開に重要な機能を使用できます。この機能は、Community Edition（ce）でも使用できます。

グローバルに共有される配布キーを使用すると、GitLabインストール全体ですべてのリポジトリへの読み取り専用または読み取り/書き込み（有効な場合）アクセスを設定できます。

これは、ストレージをセキュアな共有インテリジェント統合（CI）サービスまたは他の共有サービスに統合するのに役立ちます。 GitLab管理者は、GitLabでグローバル共有配布キーを設定し、すべての共有システムに秘密鍵を追加できます。プロジェクトマネージャ（またはそれ以上）がプロジェクトで使用するグローバル共有展開キーを承認すると、個々のリポジトリはこれらのキーを使用してリポジトリを公開することを選択します。

グローバル共有鍵は、ターゲット統合システムの管理者だけが秘密鍵を知って構成する必要があるため、プロジェクトごとに鍵を配布するよりも強力なセキュリティを提供します。

GitLab 管理者は、管理領域の配布キーセクションでグローバル配布キーを設定します。キーに意味のあるタイトルがあることを確認してください。これは、プロジェクトのメンテナンス担当者と所有者が追加する正しいGlobal Deployキーを識別する主な方法であるためです。たとえば、キーがSaaS CIインスタンスへのアクセスを許可している場合は、キー名にサービス名を使用します（それがすべての場合）。グローバル共有配布キーを生成するときは、キーの粒度を考慮してください。キーの目的は、特定のサービスにのみ適用されるのと同じくらい狭くてもよく、「読み取りアクセス権が必要なすべての場所」など、より一般的な用途です。リポジトリに" "。

GitLab管理者がグローバル展開キーを追加すると、プロジェクトメンテナと所有者は展開キーセクションを展開し、[公開展開キー]の下にリストされている対応するキーの横にある[アクティブ化]をクリックしてプロジェクトの設定>リポジトリページに追加します。できます。すべてのプロジェクトで使用されます。」

https://docs.gitlab.com/ee/ssh/#deploy-keys

編集する：
gitea.と比較して、より軽量の自己ホスティングGitサービスですgitlab。依存関係のない静的単一バイナリのみがあります。 goを使用してプログラムされています（もちろん、構成ファイルとシステムサービスまたは同様のサービスを追加する必要があります）。ウェブサイトには、その機能の良い概要があります。 https://docs.gitea.io/en-us/

答え2

設定が安全なようです。しかし、十分な時間があれば、ハッカーは常に方法を見つけるでしょう。 …誰かがあなたを攻撃するならば、私を訴えないでください。 小規模な設定に適している可能性があります。これは大企業の大規模なチームには適していない可能性があります（下記の「社会工学」を参照）。

より良い製品を作るために考慮すべきいくつかの利点といくつかの点があります。

設定に関する肯定的なポイント

  • Gitolite自体は軽量で十分に機能し、継続的に更新されます。 （この記事を書いた時点で、最後のコミットは23日前でした。）かなり安全です。
  • Gitoliteはよくサポートされ、非常に安全なOpenSSHサーバーが付属しています。
  • 公開秘密鍵（SSHキーなど）は、パスワードよりはるかに安全です。
  • 設定が非常に簡単でエラーの可能性が減り、安価なソリューションです。

改善のための考慮事項

暗号化されていない鍵

一般的ですが、秘密鍵を暗号化されていない状態で保存するのは完璧ではありません。おっしゃるようにどこかに保管しなければなりません。ただし、これはバックアップや物理的に保護されていないサーバーに問題がある可能性があります。一部のオプションでは、サーバーを再起動するときに秘密鍵を手動で復号化する必要があります。おそらくその中で最も簡単なのはSSHエージェント再起動時に暗号化キーを手動で追加します。

SSHサーバーの強化

GitoliteはOpenSSHサーバーで実行されていることを覚えておいてください。あなたができることがたくさんありますSSHサーバーの強化それ自体。

次のように Gitolite を実行することも検討できます。chroot環境。 OpenSSHの設定方法に関する多くのチュートリアルがありますchroot。結果を得るにはそのプログラムへのアクセスが必要なので、多くのpythonチュートリアルで信じられるよりも技術的に複雑になります。

社会工学

すべてのシステム管理者はハッカーが侵入するための技術的な方法を探していますが、実際のハッキングはほとんど誰かに到着。

おそらくソリューションの最も弱いのはSSHキー管理です。 これは多くの企業でセキュリティ問題として広く認識されています。。 GitoliteはSSHキーのすべての管理を管理者に任せます。これには次のような重要な意味があります。

  • Single Sign-Onはサポートされていないため、システム管理者は誰かが離れるときにこの特定のボックスへのアクセスを削除する必要があることを知らないかもしれません。例：チームがこのボックスを直接実行している場合、従業員が解雇されたときに通知されますか？
  • Gitolite 構成の命名規則はあまり良くありません。間違えて誤ったキーを削除または交換するのは簡単です。自分がしていることを明確にするディレクトリ構造を自分に提供しなければなりません。
  • ユーザーは、いつキーの使用を中止したかを知らせないことがあります。彼らはこの鍵で何をしますか？次安全ではない可能性があります。 Github Enterpriseなどの他の大規模ソフトウェアには、実際には次の機能が組み込まれています。SSHキー監査一括で無効にし、ユーザーに再承認を求めます。

関連情報