Jenkinsサーバーのセキュリティ強化：必須のベストプラクティス

Jenkinsサーバーを保護することは重要です。なぜなら、Jenkinsはソースコード、デプロイ先、認証情報、ビルド成果物にアクセスできるからです。Jenkinsが露出していたり、緩く設定されていると、攻撃者がリポジトリを読み取ったり、ビルドを改ざんしたり、シークレットを盗んだり、ビルドエージェントをネットワークへの経路として利用したりする可能性があります。

最も安全なJenkins設定は、強力なアイデンティティ、最小権限のパーミッション、暗号化されたアクセス、慎重なプラグイン管理、安全なパイプラインパターン、有用な監査ログといったレイヤーを使用します。Jenkinsを広いチームに公開したり、本番システムに接続する前に、以下のコントロールから始めてください。

ユーザー管理とアクセス制御

堅牢なユーザー管理は防御の第一線です。Jenkinsは、ユーザーが表示・実行できる内容を細かく制御できます。最小権限の原則を実装することで、ユーザーとサービスが必要なタスクを実行するために必要な権限のみを持ち、侵害されたアカウントによる潜在的な損害を最小限に抑えます。

認証

Jenkinsは複数の認証システムと統合できます。チーム環境では、Jenkinsの内部ユーザーデータベースのみに依存するのではなく、集中認証を使用してください。

LDAPまたはActive Directory統合： 既存のディレクトリグループとアカウントライフサイクル管理を活用します。
SAMLまたはOpenID Connect： Jenkinsのプラグインセットがサポートする場合、IDプロバイダーを通じてシングルサインオンを使用します。
ローカルアカウント： 慎重に保護された緊急用管理者アカウントを1つ保持しますが、共有ローカルアカウントを通常のアクセスモデルにしないでください。

認可戦略

ユーザーが認証されると、認可によってアクセスレベルが決定されます。

マトリックスベースのセキュリティ： この組み込み戦略では、ユーザーまたはグループに権限を割り当てることができます。小規模な設定には適していますが、チームが成長するにつれて監査が難しくなる可能性があります。
ロールベースの戦略： Role-Based Authorization Strategyプラグインを使用すると、Developer、Operator、Adminなどのロールを定義し、ユーザーまたはグループをそれらのロールにマッピングできます。

例：ロールベースの認可の設定

JenkinsプラグインマネージャーからRole-Based Authorization Strategyプラグインをインストールします。
Manage Jenkins > Securityに移動します。
Authorizationで、Role-Based Strategyを選択します。
developer、release-manager、jenkins-adminなどのロールを定義します。
各ロールに、Job/Read、Job/Build、Credentials/Viewなど、必要な権限のみを付与します。
可能な限り個人ではなく、ディレクトリグループをロールに割り当てます。

Jenkins通信の保護

Jenkinsサーバーとの間で送受信されるデータが暗号化されていることを確認することは、特に認証情報や機密性の高いビルド情報を扱う場合に重要です。

HTTPS設定

JenkinsがHTTPSを使用してクライアントとサーバー間のすべての通信を暗号化するように設定します。これにより、盗聴や中間者攻撃を防ぎます。

最も一般的な本番パターンは、JenkinsをNginx、Apache、HAProxy、またはクラウドロードバランサーなどのリバースプロキシの背後に配置することです。プロキシでTLSを終端し、HTTPをHTTPSにリダイレクトし、Manage Jenkins > SystemでJenkinsの公開URLを設定します。

Jenkinsの組み込みWebサーバーをHTTPSで直接実行する場合は、--httpsPort、--httpsKeyStore、--httpsKeyStorePasswordなどのJenkins起動オプション、またはパッケージ固有のサービス設定を通じて設定します。正確なファイルはインストール方法によって異なるため、変更する前にJenkinsサービスがどのように起動されるかを確認してください。

また、リバースプロキシが正しい転送ヘッダーを送信していることを確認してください。プロキシヘッダーが壊れていると、リダイレクトURLの誤り、CSRFチェックの失敗、またはプレーンHTTPを指すリンクが発生する可能性があります。

Jenkinsとプラグインのセキュリティ

プラグインによるJenkinsの拡張性は最大の強みの1つですが、慎重に管理しないと潜在的なセキュリティリスクももたらします。

Jenkinsとプラグインの更新を維持

Jenkinsコアとそのプラグインの古いバージョンは、脆弱性の一般的な原因です。既知のセキュリティ上の欠陥を修正するために、定期的に両方を更新してください。

Jenkinsコアの更新： Jenkinsのセキュリティアドバイザリをフォローし、定期的なメンテナンスウィンドウを計画します。
プラグインの更新： 更新通知を頻繁に確認します。可能であれば、重要なプラグインの更新を非本番環境のコントローラーでテストします。

プラグインのホワイトリスト化と監査

すべてのプラグインが同じように作られているわけではありません。一部のプラグインにはセキュリティ上の脆弱性があったり、メンテナンスされていない場合があります。

信頼できるプラグインを使用： Jenkins更新センターからメンテナンスされているプラグインを優先します。
プラグインのインストールを制限： 各プラグインはコントローラー内で実行されるコードを追加します。
未使用のプラグインを削除： 四半期ごと、または主要なプロセス変更後にプラグインを監査します。

プラグインのセキュリティ警告の管理

Jenkinsは、既知のセキュリティアドバイザリがあるインストール済みプラグインについて警告できます。Manage Jenkinsの下の警告に注意し、影響を受けるプラグインを更新、置換、または削除してください。

Jenkinsfileのセキュリティ

Jenkinsfileはビルドパイプラインを定義します。これらを保護することは、ビルドプロセスへの悪意のあるコードインジェクションを防ぐために重要です。

Jenkinsfileをバージョン管理に保存： パイプラインの変更は、アプリケーションコードと同じ方法でレビューします。
パイプラインコードを実行可能コードとして扱う： Jenkinsfileはシェルコマンドを実行し、成果物を公開し、認証情報を要求できます。
スクリプト承認に注意： Script Securityプラグインは、特定のGroovyメソッドやスクリプトの承認を管理者に要求する場合があります。理解しているコードのみを承認してください。
UIでのインラインパイプラインスクリプトを避ける： コードレビュー付きのリポジトリバックアップのJenkinsfileを優先します。

例：スクリプトの承認

パイプラインが未承認のGroovyシグネチャに達すると、JenkinsはそれをManage Jenkins > In-process Script Approvalの下にリストします。承認する前に、要求されたシグネチャとそれをトリガーしたジョブを確認してください。広範な承認は、複数のジョブに影響を与える可能性があります。

Jenkins認証情報管理

Jenkinsは、他のサービスにアクセスするために、APIキー、パスワード、SSHキーなどの機密性の高い認証情報を保存する必要があることがよくあります。これらを安全に管理することは重要です。

Jenkins認証情報ストレージを使用： APIトークン、パスワード、証明書、SSHキーを、ジョブ定義にプレーンテキストで保存するのではなく、認証情報として保存します。
ハードコードされたシークレットを避ける： シークレットをJenkinsfile、シェルスクリプト、ビルドログ、リポジトリ変数に入れないでください。
認証情報のスコープを厳密に設定： フォルダと権限を使用して、本番認証情報を必要としないジョブから遠ざけます。
認証情報をローテーション： 人が離職したとき、ジョブが削除されたとき、またはシークレットがログに表示された可能性があるときに、デプロイキーとサービストークンをローテーションします。

例：パイプラインでの認証情報の使用

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                withCredentials([sshUserPrivateKey(credentialsId: 'prod-deploy-key', keyFileVariable: 'SSH_KEY', usernameVariable: 'SSH_USER')]) {
                    sh 'ssh -i "$SSH_KEY" -o IdentitiesOnly=yes "[email protected]" "deploy_command"'
                }
            }
        }
    }
}

この例では、prod-deploy-keyは保存されたSSH秘密鍵認証情報のIDです。Jenkinsは、ステップの期間中、キーを一時ファイルに書き込み、サポートされているシークレット値をログでマスクします。

ネットワークセキュリティとアクセス制御

Jenkinsの内部セキュリティに加えて、ネットワークレベルでサーバーを保護することも不可欠です。

ファイアウォールルール： Jenkinsへのアクセスを信頼できるネットワーク、VPN範囲、またはアイデンティティ認識プロキシエントリポイントに制限します。
リバースプロキシ制御： TLS、HTTPからHTTPSへのリダイレクト、リクエスト制限、一貫したヘッダーにリバースプロキシを使用します。
エージェントの分離： 信頼できないビルドをコントローラーで実行しないでください。リスクの高いワークロードには、使い捨てまたは厳重に管理されたエージェントを使用します。
ネットワークセグメンテーション： ジョブが本当に必要としない限り、Jenkinsを広範な内部ネットワークアクセスから遠ざけます。

監査と監視

Jenkinsログを定期的に確認し、アクティビティを監視することで、セキュリティインシデントの検出と対応に役立ちます。

監査ログを有効にする： サインイン、権限変更、認証情報変更、ジョブ編集、管理アクションをログに記録します。Audit Trailなどのプラグインが役立ちます。
Jenkinsログを監視： 予期しない認証情報の使用、新しい管理者アカウント、異常なジョブ編集、または繰り返されるログイン失敗がないか、コントローラーログとビルドログを確認します。
設定をバックアップ： リカバリ計画に従って、Jenkinsホーム、ジョブ設定、プラグインリスト、認証情報メタデータをバックアップします。バックアップを本番シークレットと同様に保護します。

Jenkinsを退屈に保つ

目標は、アクセスが予測可能で、変更がレビューされ、プラグインが既知であり、認証情報がジョブやログに漏洩しないJenkinsサーバーです。SSO、最小権限ロール、HTTPS、プラグイン更新、安全な認証情報の使用から始めてください。その後、定期的なレビューをスケジュールして、昨日の一時的な例外が明日のインシデントにならないようにします。