Jenkinsのsudoを使用するのは悪いことですか？

Publish Over SSHプラグインを使用して、アプリJenkinsをさまざまな環境にデプロイします。一部のデプロイジョブは、環境の準備や、アプリサーバーシステムサービスの停止や再起動などを行います。これらのコマンドの一部にはが必要ですsudo。

リモートのパブリッシュおよび実行のJenkinsジョブ内でsudoを要求することがセキュリティ上の悪い習慣になる可能性があるかどうか、私は興味があります。ターゲットホストのセキュリティポリシーを変更して、sudoなしで必要な機能を実行できるようにする必要がありますか？

いいえ、より高いレベルの特権が必要な場合にsudoを実行することは、実際には非常に優れたセキュリティ対策です。これが、ほとんどのディストリビューションがデフォルトのログインを禁止し、実際にsudo su入力する代わりにあなたに強制する理由ですsu-彼らは、セキュリティ上の利点のためにsudoを使用することを勧めています。理由はいくつかあります。

• 監査。sudoを実行すると、システムはsudo を実行したユーザーと実行したコマンドの記録を保持します。これは、戻って何が起こったのかを理解する必要がある場合に法医学的に大きな影響を与えます-非難を割り当てたり、悪意のある活動をキャッチしたり、トラブルシューティングの目的でだけです（このサーバーがAWOLになる前の午後7時に何が起こったのですか？）

• Sudoルール。ユーザーがエスカレートされた特権で何かを実行する必要があるからといって、エスカレートされた特権ですべてを実行する必要があるわけではありません。suを使用するか、ホイールにユーザーを追加すると、ユーザーはすべてを行うことができます。ただし、sudoを使用すると、ワイルドカードの使用を許可するコマンドエイリアスを使用してユーザーが実行できることと実行できないことを指定できるため、ユーザーに特定のコマンドの使用のみを許可する特権を付与する柔軟なルールを許可できます。

• 硬化。ルートを無効にすることが可能です。同様に、すべての意図と目的のために、それは存在せず、シングルユーザーモードでのみ有用/使用可能です-サーバーの再起動が必要です（これが許可される唯一の理由は、パスワードの回復のためです）。sudo su動作しなくなりました。これは、ルートのシェルを/ bin / nologinに設定することによって行われます。これは、多くのルートエスカレーションの脆弱性を防ぐ優れた方法です。もちろん、これは上記の箇条書きを適切に使用していることを前提としています（特定の管理者ユーザーにすべての権限を付与することもできますが、これによりセキュリティスタンスが損なわれます）。

もちろん、これらはセキュリティモデルの一部にすぎません。たとえば、完全な管理者権限を持つユーザーがいない限り（そして場合によってはその場合でも）、ユーザーはログと履歴を削除できる可能性があります（おそらく可能です）。ログサーバーとsyslogを使用してオフボックスでログを出荷しない限り、その後、その猫をバッグに戻す方法はありません。もちろん、中央認証ディレクトリ構造を使用している場合は、これが有効になります。1つのアカウントを侵害すると、組織内のすべてのサーバー（おそらくログサーバーを含む）で侵害されます。

つまり、セキュリティは複雑ですが、sudoは安全な環境を構築するための優れたツールであり、より多くの人々がそれを最大限に使用する必要があります。

sudoリモートアクセスを許可するか、リモートアクセスを許可するかに関係SUID rootなく、非常によく似た攻撃面があります。sudoコマンドを簡単に制限できるようになり、後で監査する必要がある場合に重要になるログが記録されるので、私はチェーンを維持します。 sudoまた、生産の歴史ははるかに長いです。他のことをすると、履歴が少なくなり、不愉快な驚きの変化が大きくなります。

これをより安全にするためにできることは他にもあります：

• 締め付ける ssh
• jenkinsを含む一部の特定のユーザーのみに再起動コマンドを許可する
• すべての内部IPまたはjenkinsとジャンプボックスIPからの特定のユーザーのログインのみを許可する
• リモートのボックスにログを保存して、それらを操作できないようにする