セキュリティに関する注意事項

資格情報

強力なクレデンシャルを使用し、慎重に使用します。

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

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

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

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

• ビルドログ — 機密情報をランダムにログに記録しないようにしてください。

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

管理者権限を持つ TeamCity ユーザーは、複雑なパスワードを持っている必要があります。

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

スーパーユーザーアクセスを無効にすることを検討する

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

TeamCity ログを外部ソースに公開する場合は、teamcity.superUser.disable=true 内部プロパティを追加してこの認証オプションを無効にし、不要な管理者アクセスを防止します。変更を適用するには、teamcity.superUser.disable プロパティを変更した後、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 への匿名でのログインは無効になっています。外部ユーザーがすべてのビルドと関連するログファイル / アーティファクトを表示できるようにする場合を除いて、インターネットに公開されている本番 TeamCity サーバーインスタンスで有効にしないでください。有効になっている場合は、ゲストとすべてのユーザーグループのユーザーロールを注意深く確認する必要があります。

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

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

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

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

ユーザーおよびユーザーグループに付与された権限を徹底的に管理します。

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

• TeamCity によって実行されるビルドで使用されるコードを変更できるユーザー（TeamCity でビルドされている場合はブランチ / プルリクエストのコミッターを含む）:

  • TeamCity エージェントが実行されているシステムユーザーが実行できるすべてのことを実行できます。ビルドを実行できるエージェントマシンにインストールされている OS リソースおよびその他のアプリケーションにアクセスできます。

  • 同じエージェントでビルドされた他のプロジェクトのソースコードにアクセスして変更したり、TeamCity エージェントコードを変更したり、エージェントで実行されたビルドのアーティファクトとしてファイルを公開したりできます（つまり、ファイルを TeamCity Web UI に表示し、Web を公開できます。脆弱性または他のビルドで使用できる）など。

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

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

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

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

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

• 1 つのプロジェクトで「プロジェクトの編集」権限 (デフォルトでは「プロジェクト管理者」 TeamCity ロール) を持つユーザーは、設定を変更することで、表示権限 (TW-39209(英語)) のみを持つ任意のビルド構成からアーティファクトを取得し、ビルドをトリガーできます。

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

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

• TeamCity サーバーログ（TeamCity サーバーのホームディレクトリ）への読み取りアクセス権を持つユーザーは、アクセスを TeamCity サーバー管理者にエスカレーションできます。

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

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

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

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

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

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

  • ビルドごとにビルド構成設定をカスタマイズできるユーザー (たとえば、バージョン管理された設定が「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 Data Directory へのアクセス許可を制限することを強くお勧めします。

サーバーマシンを保護します。

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

一般に、ビルドエージェントを実行するために TeamCity サーバーマシンを使用しないでください (少なくとも、 <TeamCity Home Directory> および <TeamCity Data Directory> の読み取りを許可されたユーザーの場合)。

TeamCity サーバー（およびエージェント）プロセスは、最小限の必要な権限を持つユーザーで実行されます。インストールディレクトリは、限られた OS ユーザーのみが読み取りおよび書き込みを行うことができます。conf\buildAgent.properties ファイルとサーバーログ、およびデータディレクトリは、サービスの管理者を表す OS ユーザーのみが読み取ることができます。これらの場所を読み取ると、エージェントまたはサーバーをそれぞれ引き継ぐことができるためです。

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

どこでも HTTPS を使用します。

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

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

DoS から保護します。

TeamCity には、DoS（サービス拒否）攻撃に対する保護機能が組み込まれていません。リクエストの割合が高いと、サーバーがオーバーロードになり、応答しなくなる可能性があります。TeamCity インスタンスがそのようなサービスの悪用を許可する環境にデプロイされている場合は、リバースプロキシレベルで保護を実装します。

データベースを保護します。

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

<TeamCity Home Directory> \conf\teamcity-startup.properties ファイルに teamcity.installation.completed=true 行を追加することを検討してください。これにより、空のデータベースで起動されたサーバーが、最初にアクセスしたユーザーにマシンへのアクセスを許可することを防ぐことができます。

安全なビルドファイル。

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

ビルドエージェント

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

エージェントのソースコードが改ざんされないように、本番ビルドにクリーンチェックアウトを適用することをお勧めします。

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

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

さまざまなプロジェクトにエージェントプールを使用します。

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

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

TeamCity エージェントを実行する OS ユーザーの権限を制御します。

必要な権限のセットのみを使用して、OS アカウントで TeamCity エージェントを実行することをお勧めします。

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

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

バージョン管理

Git の最新バージョンを使用します。

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

SSH キーを適切に管理します。

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

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

専用の VCS ユーザーを使用します。

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

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

匿名アクセスを無効にします。

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

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

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

機密データをアーティファクトに入れないでください。

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

ビルド履歴とログ

ビルド履歴を保持します。

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

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

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

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

統合

パブリックプルリクエストを作成するときは注意します。

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

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

バージョン管理された設定を使用する場合は、セキュリティへの影響に注意します。

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

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

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

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

Heartbleed、ShellShock

JetBrains が提供する TeamCity ディストリビューションにはソフトウェア / ライブラリが含まれておらず、ハートブリードとシェルショックの脆弱性の影響を受けるテクノロジーを使用していません。まだ評価が必要なのは、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 など）の影響を受けません。