web-dev-qa-db-ja.com

多くのサーバー用のSSHアクセスゲートウェイ

現在90を超える複数のサーバーを管理し、Ansibleを介して3つの開発を行っています。すべてがうまく機能していますが、現在、巨大なセキュリティ問題があります。各devopは独自のローカルsshキーを使用して、サーバーに直接アクセスします。各devopはラップトップを使用しており、各ラップトップが侵害される可能性があるため、製品サーバーのネットワーク全体が攻撃を受ける可能性があります。

アクセスを一元管理して、特定のキーのアクセスをブロックするソリューションを探しています。キーがbitbucketまたはgithubに追加される方法と似ています。

私の頭の上では、解決策は1つのマシン、ゲートウェイから目的の製品サーバーへのトンネルであると思います...ゲートウェイを渡す間、リクエストは新しいキーを取得し、製品へのアクセスを取得するために使用しますサーバ。その結果、ゲートウェイへのアクセスを拒否するだけで、devopのアクセスを数秒以内にすばやく効率的に強制終了できます。

enter image description here

これは良いロジックですか?誰かがすでにこの問題を阻止するための解決策を見たことがありますか?

12
John

これは複雑すぎます(キーが特定の製品サーバーにアクセスできるかどうかを確認する)。ゲートウェイサーバーをすべての有効なキーを受け入れるジャンプホストとして使用します(ただし、特定のキーへのアクセスを簡単に削除して、すべてのサーバーへのアクセスを順番に削除できます)。次に、許可されたキーのみを各サーバーに追加します。その後、ジャンプホスト経由でのみすべてのサーバーのSSHポートにアクセスできることを確認します。

これが標準的なアプローチです。

22
Sven

これが開発/テスト環境でない限り、エンジニアはラップトップから直接ansibleを実行しないでください。

代わりに、Runbookをgitからプルする中央サーバーを用意します。これにより、追加のコントロール(4つの目、コードレビュー)が可能になります。

これを要塞またはジャンプホストと組み合わせて、アクセスをさらに制限します。

11
Henk Langeveld

OneIdentity(ex-Balabit)SPS は、このシナリオで必要なものです。このアプライアンスを使用すると、基本的にすべてのマシンでユーザーIDを管理し、ユーザーの行動を追跡し、監視してアラートを出し、ユーザーが後のレビューのために何をしていてもインデックスを作成できます。

1
random

Netflixはあなたのセットアップを実装し、その状況を助けるいくつかの無料ソフトウェアをリリースしました。

このビデオ https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access または https:// speakerdeckのこのプレゼンテーションを参照してください.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-production コアポイント:

SSH要塞アーキテクチャを確認します。このコアでは、SSOを使用してエンジニアを認証し、インスタンスへの要塞のSSH認証用に有効期間の短い証明書をユーザーごとに発行します。これらの有効期間が短い資格情報は、失われることに関連するリスクを軽減します。このアプローチにより、エンジニアがアクセスを許可する前に速度を落とすのではなく、監査して事実を自動的に警告する方法について説明します。

彼らのソフトウェアはここから入手できます: https://github.com/Netflix/bless

ソリューション全体を実装していなくても、いくつかの興味深い要点があります。

  • 鍵だけでなくSSH証明書を使用します。証明書にはるかに多くのメタデータを入れることができるため、要件ごとに多くの制約が可能になり、監査がより簡単になります
  • 非常に短期間(5分など)の証明書の有効性を使用する(証明書の有効期限が切れた後もSSHセッションは開いたままです)
  • 2FAを使用してスクリプティングを困難にし、開発者に他のソリューションを見つけさせる
  • 特定のサブモジュールは、インフラストラクチャの外にあり、実行するクラウドによって提供されるセキュリティメカニズムによって適切に保護されており、証明書を動的に生成して、各開発者が任意のホストにアクセスできるようにします
1
Patrick Mevzek

私の提案は、ユーザーマシンからのSSHアクセスを禁止することです。

代わりに

  1. Gitでプレイブックをホストします。
  2. 「アクセスサーバー」をJenkinsサーバーに変換します。
  3. Devopsユーザーに必要なJenkinsアクセスのみを付与します。
  4. Execute Ansibleは、HTTP経由のビルドジョブを介してJenkinsで再生します。
  5. 追加のセキュリティ対策として、必要に応じてJenkins CLIを無効にします。

サンプル実行モデル、

  1. Jenkins Ansibleプラグイン: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

OR

  1. クラシックシェル-ジョブのタイプを実行します。ビルド手順を手動で追加します(gitチェックアウトを含む)。

サーバーリソースが限られている場合は、同じJenkinsサーバーがGit(scm-manager)をホストすることもできますが、開発者のマシンの1つが感染している場合は、追加のセキュリティリスクがあります。 Jenkinsサーバーをインターネットから切断してこれを軽減し、Ansibleの依存関係をローカルで解決できる場合があります。

0
Manu Vamadevan