現在90を超える複数のサーバーを管理し、Ansibleを介して3つの開発を行っています。すべてがうまく機能していますが、現在、巨大なセキュリティ問題があります。各devopは独自のローカルsshキーを使用して、サーバーに直接アクセスします。各devopはラップトップを使用しており、各ラップトップが侵害される可能性があるため、製品サーバーのネットワーク全体が攻撃を受ける可能性があります。
アクセスを一元管理して、特定のキーのアクセスをブロックするソリューションを探しています。キーがbitbucketまたはgithubに追加される方法と似ています。
私の頭の上では、解決策は1つのマシン、ゲートウェイから目的の製品サーバーへのトンネルであると思います...ゲートウェイを渡す間、リクエストは新しいキーを取得し、製品へのアクセスを取得するために使用しますサーバ。その結果、ゲートウェイへのアクセスを拒否するだけで、devopのアクセスを数秒以内にすばやく効率的に強制終了できます。
これは良いロジックですか?誰かがすでにこの問題を阻止するための解決策を見たことがありますか?
これは複雑すぎます(キーが特定の製品サーバーにアクセスできるかどうかを確認する)。ゲートウェイサーバーをすべての有効なキーを受け入れるジャンプホストとして使用します(ただし、特定のキーへのアクセスを簡単に削除して、すべてのサーバーへのアクセスを順番に削除できます)。次に、許可されたキーのみを各サーバーに追加します。その後、ジャンプホスト経由でのみすべてのサーバーのSSHポートにアクセスできることを確認します。
これが標準的なアプローチです。
これが開発/テスト環境でない限り、エンジニアはラップトップから直接ansibleを実行しないでください。
代わりに、Runbookをgitからプルする中央サーバーを用意します。これにより、追加のコントロール(4つの目、コードレビュー)が可能になります。
これを要塞またはジャンプホストと組み合わせて、アクセスをさらに制限します。
OneIdentity(ex-Balabit)SPS は、このシナリオで必要なものです。このアプライアンスを使用すると、基本的にすべてのマシンでユーザーIDを管理し、ユーザーの行動を追跡し、監視してアラートを出し、ユーザーが後のレビューのために何をしていてもインデックスを作成できます。
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アクセスを禁止することです。
代わりに
サンプル実行モデル、
OR
サーバーリソースが限られている場合は、同じJenkinsサーバーがGit(scm-manager)をホストすることもできますが、開発者のマシンの1つが感染している場合は、追加のセキュリティリスクがあります。 Jenkinsサーバーをインターネットから切断してこれを軽減し、Ansibleの依存関係をローカルで解決できる場合があります。