セキュリティノート

資格情報

強力な資格情報を使用し、慎重に扱う。

TeamCity サーバーだけでなく、ビルドに関係する、またはソフトウェアが本番環境で必要とするその他すべてのサービスにも、強力な資格情報を使用することをお勧めします。

特に、クレデンシャルを次の場所に入れないようにしてください。

• GitHub や GitLab などのリポジトリ。

• 多くの場合、ログに記録されるか、サードパーティの監視システムと共有されるため、環境変数。

• ビルドログ — 機密情報を無作為にログへ記録しないようにしてください。

• バージョン管理された設定 (Kotlin DSL または XML 形式) を使用している場合は、構成ファイルに資格情報を保存しないでください。 代わりに、 トークンを使用してください。

管理者権限を持つ TeamCity ユーザーには、複雑なパスワードを設定してください。

ユーザーパスワードのストレージをより安全にするため、TeamCity は BCrypt ハッシュアルゴリズムを使用します。

スーパーユーザーアクセスの無効化を検討する。

TeamCity の スーパーユーザーアクセス 機能を有効化すると、 <TeamCity_server_home>/logs/teamcity-server.log ファイルにあるトークンを使用して、システム管理者としてログインできます。

TeamCity ログを外部ソースに公開する場合は、 teamcity.superUser.disable=true 内部プロパティを追加して、この認証オプションを無効化し、不要な管理者アクセスを防止します。 変更を適用するには、 teamcity.superUser.無効化 プロパティを変更した後に TeamCity サーバーを再起動します。

"パスワード"型のパラメーターを使用してセキュアデータを保存する。

パスワードやその他のセキュアなデータを TeamCity 設定に保存するには、 型付きパラメーターを使用することを強くお勧めします。 これにより、機密性の高い値が Web UI に表示されず、ビルドログでアスタリスクでマスクされるようになります。 パスワードがパスワード型のパラメーターとして保存されていることを確認してください。

シークレット管理ツールを使用する。

パスワードパラメーターは UI でマスクされ、REST で暗号化され、プレーンテキストとしてビルドログに公開されないように保護されていますが、これでは十分なレベルのセキュリティが提供されないことがよくあります。

HashiCorp Vault のようなツールの使用を検討できます。これにより、ビルドで使用する機密性の高い資格情報をすべて管理およびローテーションでき、 TeamCity ともよく統合できます。

外部認証を使用する。

該当する場合は、LDAP および Windows ドメインの統合から、GitHub、GitLab などによる認証に至るまで、 外部認証モジュールの 1 つを構成します。 その後、 TeamCity の組み込み認証を無効化することで、TeamCity がハッシュ化されたパスワードを内部データベースに保持しないようにできます。

サーバーで OAuth 認証モジュール (Bitbucket Cloud、GitHub.com、GitHub Enterprise、GitLab.com、GitLab CE/EE) のいずれかが有効化されていて、 および 特定の Bitbucket ワークスペース、GitHub 組織、または GitLab グループのメンバーに認証を制限している場合は、次の点に注意してください:
外部アカウントで TeamCity サーバーにサインインすると、ユーザーはパスワードまたはトークンを作成でき、それにより VCS ホスティングプロバイダーの検証をバイパスして、このサーバーに直接サインインできるようになります。 ワークスペース/組織/グループからユーザーを削除する場合は、TeamCity でもそのユーザーのアクセスを制限するか、ユーザープロファイルを削除することを忘れないでください。

カスタム暗号化鍵を使用する。

外部システム (VCS、課題トラッカーなど) での認証に必要なパスワードは、 TeamCity データディレクトリにスクランブル形式で保存され、データベースにも保存できます。 ただし、値はスクランブルされているだけであり、サーバーのファイルシステムまたはデータベースにアクセスできるユーザーが取得できることを意味します。

このデフォルトのスクランブル戦略の代わりに、 カスタム暗号化キーを有効にすることを検討してください。 この場合、TeamCity はデフォルトのスクランブルメカニズムの代わりに、固有のカスタム鍵を使用してすべてのセキュアな値を暗号化します。

暗号化された SSH 鍵を使用する。

秘密 SSH 鍵をアップロードして TeamCity サーバーに配置する場合、追加の暗号化なしでプレーンテキストとしてディスクに保存されることに注意してください。 パスフレーズですでに暗号化されている SSH キーのみを使用することを強くお勧めします。

権限

定義済みロールを使用する。

初期状態で、TeamCity には複数の事前定義された ロールが用意されています：

• システム管理者

• プロジェクト管理者

• プロジェクト開発者

• プロジェクトビューアー

組織構造に一致するユーザーグループを作成し、それらのグループに上記のロールを割り当てることができます。 次に、ユーザーをそれぞれのグループに追加して、日常業務に必要な最低レベルの特権をユーザーに付与します。

また、少し多くの権限が必要な人にプロジェクト管理者のロールをすぐに割り当てるのではなく、追加の権限を持つ新しいロールを作成することを強くお勧めします。 (プロジェクトごとの権限を無効にすると、これは機能しません。)

プロジェクトごとの認可を使用する。

セキュリティをさらに強化するために、 プロジェクトごとの承認を利用することもできます。 このようにして、たとえば、開発者はビルドチェーンのコンパイル部分にのみアクセスでき、DevOps はデプロイ部分にアクセスして実行できます。

ゲストログインを有効化しない。

デフォルトでは、 TeamCity への匿名ログインは無効になっています。 外部ユーザーにすべてのビルドと関連するログファイル/アーティファクトを表示させたい場合を除き、インターネットに Exposed されている本番 TeamCity サーバーインスタンスでは有効化しないようにしてください。 有効になっている場合は、ゲストと すべてのユーザーグループのユーザーロールを注意深く確認する必要があります。

REST リクエスト用に別のユーザーを作成する。

外部スクリプトまたはプログラムから TeamCity REST API にアクセスする場合は、権限の数を制限した専用ユーザーを作成することをお勧めします。 また、ユーザー名 / パスワードを使用して API にアクセスする代わりに、 自動期限切れのアクセストークンを作成することも賢明です。

デプロイビルド権限を制限する。

デプロイビルドチェーンが個人ビルドを許可していないことを確認してください。 それらのビルドをトリガーし、それらのビルドにクリーンエージェントの個別のプールを使用できる 開発者の数を制限します。

ユーザーとユーザーグループに付与された権限を徹底的に管理する。

次のニュアンスに注意してください。

• TeamCity で実行されるビルドで使用されるコードを変更できるユーザー (TeamCity でビルドされる場合は、任意のブランチ/プルリクエストのコミッターを含む)：

  • TeamCity エージェントを実行しているシステムユーザーができることはすべて実行でき、自分のビルドを実行できるエージェントマシン上の OS リソースやその他のインストール済みアプリケーションにアクセスできます。

  • 同じエージェントでビルドされた他のプロジェクトのソースコードにアクセスして変更したり、TeamCity エージェントコードを変更したり、エージェントで実行されるビルドのアーティファクトとして任意のファイルを公開したりできます (つまり、そのファイルが TeamCity ウェブ UI に表示されてウェブの脆弱性を露出させたり、他のビルドで使用されたりする可能性があります) など。

  • TeamCity エージェントになりすますことができます (TeamCity サーバーから同じように見える新しいエージェントを実行します)。

  • サーバー上のすべてのプロジェクトに対する「ビルド構成設定の表示」権限を持つユーザーが実行できることはすべて実行できます (以下を参照)。

  • パスワードフィールドの値を含む、ビルドが実行されるビルド構成の設定を取得できます。

  • サーバー上の任意のビルドからアーティファクトをダウンロードできます。

• 「ビルド構成設定の表示」権限を持つユーザー (デフォルトではプロジェクト開発者ロール) は、 ビルドレベルの認証パラメーターの値を取得し、それを利用して通常はアクセスできないサーバー上のすべてのプロジェクトを表示できます。 これを防ぐには、 teamcity.buildAuth.enableStrictMode=true 内部プロパティを使用します。

• あるプロジェクトで "Edit project" 権限 (デフォルトでは "Project Administrator" TeamCity ロール) を持つユーザーは、設定を変更することで、表示権限のみを持つ任意のビルド構成からアーティファクトを取得し、ビルドをトリガーできます (TW-39209)。

• "Change server settings" 権限を持つユーザー (デフォルトでは "System Administrator" TeamCity ロール): ユーザーは、サーバープロセスの実行に使用されるユーザーアカウントで TeamCity サーバーが実行されているコンピューターにもアクセスできると想定されます。 ユーザーはその OS ユーザーアカウントでマシンへのフルアクセス (ファイルシステムの参照、ファイルの変更、任意のコマンドの実行など) を取得できます。

• TeamCity サーバーコンピューターの管理者: TeamCity に保存されたデータへのフルアクセス権を持ち、TeamCity が実行するプロセスに影響を与えることができます。 外部システム (VCS、課題トラッカーなど) での認証に必要なパスワードは、 TeamCity データディレクトリにスクランブル形式で保存され、データベースにも保存できます。 ただし、値はスクランブルされているだけであり、サーバーのファイルシステムまたはデータベースにアクセスできる任意のユーザーが取得できることを意味します。

• TeamCity サーバーログ (TeamCity サーバーホームディレクトリ) への読み取りアクセス権を持つユーザーは、TeamCity サーバー管理者へアクセス権を昇格できます。

• <TeamCity データディレクトリ> への読み取りアクセス権を持つユーザーは、構成されたパスワードを含むサーバー上のすべての設定にアクセスできます。

• <TeamCity データディレクトリ>/system/artifacts のビルドアーティファクトへの読み取りアクセス権を持つユーザーには、「ビルドランタイムパラメーターとデータの表示」権限を持つユーザーと同じ権限が付与されます (特に、ビルドで使用されるすべてのパスワードパラメーターの値にアクセスできます)。

• TeamCity エージェントコンピューターの管理者: "TeamCity で実行されるビルドで使用されるコードを変更できるユーザー" と同じです。

• VCS での設定の保存が有効になっている場合:

  • 設定のリポジトリにアクセスできるすべてのユーザー (同じ VCS ルートを使用するビルド構成の「ファイルコンテンツの表示」権限を持つユーザーを含む) は設定を表示し、保存されているスクランブルされたフォームに基づいて実際のパスワードを取得できます。

  • サーバー上に構築された単一のビルド構成の VCS の設定を変更できるユーザーは、設定を変更することでアーティファクトを取得し、表示権限のみを持つ任意のビルド構成からビルドをトリガーできます（TW-39192(英語)）。

  • ビルドごとにビルド構成設定をカスタマイズできるユーザー (たとえば、バージョン設定が "use settings from VCS" に設定されている場合に個人ビルドを実行できるユーザー) は、ビルド内の設定を変更することで、表示権限のみを持つ任意のビルド構成からアーティファクトを取得し、ビルドをトリガーできます (TW-46065)。

サーバーとデータ

TeamCity サーバーを定期的に更新する。

TeamCity を 最新のリリースバージョンへ定期的に更新することを強くお勧めします。

新しいアップデートが利用可能になると、TeamCity は UI 経由で自動的に通知します。 TeamCity 自体については サーバー管理 | 更新 で、利用可能なプラグイン更新については サーバー管理 | プラグイン で、新しい TeamCity バージョンを手動で確認することもできます。

技術的な観点から、同じメジャー / マイナーバージョン内のバグ修正リリース間のアップグレードは下位互換性があり（たとえば、2021.1.1 → 2021.1.2）、比較的単純なロールバックをサポートします。 他のすべての主要なアップグレードについては、可能な限りスムーズに実行されるように最善を尽くしますが、 簡単にロールバックできるようにバックアップを強くお勧めします。

ライセンスの観点から、バグ修正リリース間のアップグレードも安全です。 ライセンスが 2021.2 を対象としている場合は、任意の 2021.2.x バージョンにアップグレードできます。

TeamCity データディレクトリを保護する。

TeamCity データディレクトリへの読み取りアクセス権を持つユーザーは、構成済みのパスワードを含む、サーバー上のすべての設定にアクセスできます。 このディレクトリが実際にサービスの管理者である OS ユーザーだけが読み取れるようにする必要があります。

TeamCity Windows インストーラーは、 TeamCity インストールディレクトリの権限を変更して継承可能な権限を使用しないようにし、Administrators ユーザーグループとサービスの実行が構成されているアカウントに対して、ディレクトリへのアクセスを明示的に許可します。 同様に、 TeamCity データディレクトリ へのアクセス許可を制限することを強くお勧めします。

サーバーマシンを保護する。

TeamCity サーバーが実行されているマシンへのアクセスを制限します。 アクセスログを有効にして、定期的に確認してください。

一般に、 ビルドエージェントの実行に TeamCity サーバーマシンを使用しないでください (少なくとも、 <TeamCity ホームディレクトリ> および <TeamCity データディレクトリ> の読み取りを許可されたユーザーでは使用しないでください)。

TeamCity サーバー (およびエージェント) のプロセスは、必要最小限の 権限を持つユーザーで実行されます。 インストールディレクトリの読み取りと書き込みは、限定された OS ユーザー設定でのみ実行できます。 conf\buildAgent.properties ファイル、サーバーログ、および データディレクトリは、サービスの管理者を表す OS ユーザーのみが読み取れるようにしてください。これらの場所を読み取ることで、それぞれエージェントまたはサーバーを乗っ取れる可能性があるためです。

サーバーにインストールされているエージェントプラグインのバイナリは、サーバーの URL にアクセスできるすべてのユーザーが利用できることに注意してください。

すべての場所で HTTPS を使用する。

TeamCity ウェブインターフェースへのアクセスは、 HTTPS で保護されています (たとえば、NGINX のような プロキシサーバーを使用します)。 TeamCity ウェブインターフェースには、ウェブアプリケーションを保護するためのベストプラクティスが適用されていることを確認してください。たとえば、HTTP プロトコルを使用してサーバーへアクセスできないようにします。 リバースプロキシは Referer リクエストヘッダーを削除しません。

TeamCity エージェントと TeamCity サーバー間の接続を構成する方法については、 このセクションを参照してください。

DoS から保護する。

TeamCity には DoS (Denial-of-service) 攻撃に対する組み込み保護はありません。高頻度のリクエストによりサーバーがオーバーロードされ、応答しなくなる可能性があります。 TeamCity インスタンスがこのようなサービス悪用を許す環境にデプロイされている場合は、リバースプロキシレベルで保護を実装してください。

データベースを保護する。

TeamCity サーバーのデータベーススキーマには、強力な資格情報を持つ専用のデータベースユーザーアカウントを必ず使用してください。 サポートされている場合は、データベースの暗号化を検討してください。

teamcity.installation.completed=true 行を <TeamCity ホームディレクトリ>\conf\teamcity-startup.properties ファイルに追加することを検討してください — これにより、空のデータベースで起動されたサーバーが、最初に来たユーザーにマシンへのアクセス権を付与するのを防げます。

ビルドファイルを保護する。

TeamCity 開発チームは、重大な脆弱性 (クロスサイトスクリプティングの可能性など) が明らかになり次第、修正するために合理的な努力を行います。 ビルドファイルに影響を与えられる任意のユーザー ("TeamCity で実行されるビルドで使用されるコードを変更できるユーザー" または "TeamCity エージェントコンピューターの管理者") は、悪意のあるファイルをビルドアーティファクトとして利用可能にし、それによってクロスサイトスクリプティング脆弱性を悪用できることに注意してください。

ビルドエージェント

クリーンな本番ビルドを実行する。

エージェント上のソースコードの改ざんを防ぐため、本番ビルドでは クリーンチェックアウトを強制することをお勧めします。

使い捨てで、ネットワーク保護されたビルドエージェントを使用する。

同じビルドエージェント上で実行されるビルドは分離されておらず、互いに影響を及ぼす可能性があるため、悪意のあるアクションを実行する機会を与える可能性があることに注意してください。
可能であれば、使い捨ての一回限りのビルドエージェントを使用してみてください。 エージェントの存続期間が短いほど、侵害される可能性は小さくなります。 また、OS 依存のファイアウォールルールを使用して、クラウドエージェントへの受信ネットワークアクセスを無効化してください。

プロジェクトごとに別々のエージェントプールを使用する。

一般に、TeamCity エージェントが、開発者や管理者が互いのプロジェクトにアクセスすべきでない複数のプロジェクトのビルドを実行しないように、プロジェクトをエージェント間で配布することをお勧めします。

同じマシン上で複数のエージェントを実行し、 クリーンチェックアウトを有効にしていない場合は、侵害されたエージェントまたは信頼できないプロジェクトによって、「隣接」作業ディレクトリ内のソースコードが変更される可能性があることに注意してください。 このリスクを軽減するには、マシンごとにエージェントを 1 つだけ実行し、異なる (プライベート / パブリック) プロジェクトに異なる エージェントプールを使用することを検討してください。 特定の再構成後 (つまり、プロジェクトが割り当てられている他のプールがない場合) にプロジェクトをデフォルトプールに割り当てることができるため、「デフォルト」エージェントプールにエージェントがないことを確認してください。

TeamCity エージェントを実行する OS ユーザーの権限を管理する。

TeamCity エージェントは、 必要な権限設定のみを持つ OS アカウントで実行することをお勧めします。

エージェントは信頼できるサーバーにのみ接続する。

TeamCity エージェントは TeamCity サーバーによって完全に制御されます。TeamCity エージェントはサーバーからの自動アップデートダウンロードをサポートしているため、エージェントは信頼できるサーバーにのみ接続してください。 サーバーコンピューターの管理者は、接続されたエージェント上で任意のコードの実行を強制できることに注意してください。

バージョン管理

新しいバージョンの Git を使用する。

ビルドエージェントでは常に最新の安定したオペレーティングシステムと Git バージョンを使用するようにしてください。 定期的に更新してください。

SSH 鍵を適切に管理する。

SSH キーを使用してリポジトリにアクセスしている場合は、ビルドエージェントに保存しないでください。 代わりに、TeamCity の SSH 鍵管理を使用して、TeamCity サーバーへアップロードしてください。

既知のホストチェックを無効にする代わりに、サーバー上で .ssh/既知のホスト ファイルを維持し、接続しているすべてのホストのエージェントを構築するようにしてください。

専用の VCS ユーザーを使用する。

Kotlin DSL のような高度な機能を使用していない場合、または一般に、ビルドプロセスの一部としてリポジトリへコミットする必要がない場合は、リポジトリに接続するための書き込み権限のない専用 VCS ユーザーを維持することをお勧めします。

アーティファクトストレージ

匿名アクセスを無効化する。

ビルドアーティファクト （S3 など）を保存する場所に関係なく、保存場所への匿名アクセスを無効にしてください。

適切なアクセスポリシーを使用する。

適切なアクセスポリシーを使用して、S3 またはその他のストレージの場所 / リポジトリをアーティファクトから保護します。 また、可能であれば暗号化を使用してください。 保管場所のアクセスログを確認、監視、定期的に確認します。

機密データをアーティファクトに含めない。

クレデンシャルやその他の機密情報をビルドのアーティファクトにプレーンテキストとして保存しないでください。

ビルド履歴とログ

ビルド履歴を保持する。

プロジェクトに対応する クリーンアップ規則を指定することで、特に重要なデプロイを実行するビルドの場合、ビルド履歴とログを長期間保存します。 また、アーカイブが妨げられる可能性があるため、開発者に「ビルドの削除」 権限を付与しないようにしてください。

どちらの方法も、悪意のあるアクティビティがかなり前に発生した場合でも、その追跡に役立つ可能性があります。

サーバーとエージェントのログをアーカイブする。

TeamCity サーバーと ビルドエージェントログをアーカイブに収集し、適切に保護されたストレージに配置します。

統合

公開プルリクエストをビルドするときは注意する。

不明なユーザーまたは組織外のユーザーからプルリクエストをビルドする場合、プルリクエストには、ビルドエージェントで実行される悪意のあるコードが含まれている可能性があることに注意してください。

パブリックプルリクエストの作成を禁止するか、分離された隔離された使い捨てエージェントを使用します。 TeamCity は、プルリクエストビルドを検出して報告する 組み込みヘルスレポートも提供します。

バージョン管理された設定を使用するときのセキュリティ上の影響に注意する。

バージョン管理された設定 (Kotlin DSL、XML) を使用し、それらの設定をソースコードと同じリポジトリに配置すると、悪意のある開発者がプロジェクト構成設定を変更して漏洩する可能性があります。 これは、たとえば、パスワードを印刷したり、パスワードをファイルとしてどこかに送信したりするビルドステップを追加することで実行できます。

オプションとして、バージョン管理された設定に対して、限られた数のユーザーのみがコミットできる別のリポジトリを使用できます。

サードパーティプラグインに注意する。

プラグインをインストールするときは、信頼できるソースからのものであり、ソースコードが利用可能であることを確認してください。 プラグインは、機密情報を含む TeamCity サーバー上のすべての情報にアクセスできる可能性があります。

Heartbleed、ShellShock

JetBrains が提供する TeamCity ディストリビューションにはソフトウェア/ライブラリは含まれておらず、Heart bleed および Shell shock の脆弱性の影響を受けるテクノロジーも使用していません。 まだ評価が必要になる可能性があるのは、JetBrains が提供/推奨するものの背後にあるコンポーネントを使用する可能性があり、前述のエクスプロイトに対して脆弱である可能性がある、特定の TeamCity インストール実装です。

POODLE (プードル)

TeamCity サーバーへの HTTPS アクセスを構成している場合は、HTTPS に使用されているソリューションを確認してください。それが影響を受ける可能性があります (たとえば、Tomcat は 影響を受けるようです)。 現時点では、TeamCity ディストリビューションのいずれもデフォルトで HTTPS アクセスを含んでおらず、HTTPS 関連の脆弱性の調査/排除は TeamCity のスコープ外です。

使用される設定に応じて、TeamCity サーバー (およびエージェント) は他のサーバー (Subversion など) への HTTPS 接続を確立できます。 サーバーの設定によっては、これらの接続が SSL 3.0 プロトコルの使用にフォールバックする場合があります。 推奨されるソリューションは TeamCity 固有のものではなく、ターゲット SSL サーバー側で SSLv3 を無効化することです。

GHOST (ゴースト)

CVE-2015-0235 の脆弱性は、TeamCity コードで直接使用されていない glibc ライブラリに見つかっています。 これは、*nix プラットフォームで TeamCity が使用する Java/JRE によって使用されます。 Java は TeamCity Unix ディストリビューションにバンドルされていないため (Docker イメージはより新しい glibc バージョンを使用します)、使用している Java のベンダーが推奨するセキュリティ対策を適用してください。 現時点では、関連する Java 固有のセキュリティアドバイザリはリリースされていないため、OS を更新するだけで、脆弱性が悪用されるリスクを排除できます。

FREAK (フリーク)

CVE-2015-0204 の脆弱性は OpenSSL の実装に見られます。 TeamCity は OpenSSL 製品のどの部分もバンドルしていないため、脆弱ではありません。 脆弱性を軽減するための手順として、TeamCity サーバーとエージェントが設定されている環境、および TeamCity に加えてインストールされているツールを確認する必要がある場合があります。

Apache Struts

TeamCity は、Apache Struts 1.x と Apache Struts 2.x の両方の JAR を含む IntelliJ IDEA をダウンロードできます。 これらの JAR は、IntelliJ IDEA が TeamCity エージェント上のプロジェクト用にインスペクションを収集する際に、IntelliJ IDEA Struts プラグインによってのみ使用されます。

TeamCity は、HTTP リクエスト処理に Apache Struts を使用していません。 そのため、TeamCity サーバーも TeamCity エージェントも、関連する Struts の脆弱性 (CVE-2016-1181、CVE-2017-5638、CVE-2023-50164 など) の影響を受けません。