【ITニュース解説】Leantime API keys are service accounts with a visible surface

Leantimeというプロジェクト管理ツールが持つAPIキーについて、特にシステムエンジニアを目指す初心者が理解すべき重要なセキュリティの視点がある。Leantimeはプロジェクト計画、タスク管理、タイムシートといった多岐にわたる機能を提供し、そのAPI（Application Programming Interface）は、他のシステムとの連携や自動化を可能にする便利な仕組みだ。しかし、このAPIを利用するための「APIキー」の扱いを誤ると、重大なセキュリティリスクにつながる可能性がある。

一般的なユーザーアカウントは、特定の人間がログインしてシステムを利用するためのものだが、LeantimeのAPIキーは「サービスアカウント」として機能すると理解すべきである。サービスアカウントとは、システムやアプリケーションが別のシステムと連携する際に使用する、人間ではない「ID」のようなものだ。このサービスアカウントとしてのAPIキーは、一度作成されると、特定の人間がログインしているかどうかにかかわらず、設定された権限に基づいてプロジェクトデータへのアクセスや変更が可能になる。つまり、単なるパスワードではなく、システムの一部として機能する永続的なアクセス権限の塊と考えるべきだ。

インターネット上に公開されているLeantimeのインスタンスの中には、ログインフォームだけでなく、このサービスアカウントの認証情報であるAPIキーが不用意に露出しているケースがある。もしこのようなAPIキーが悪意のある第三者の手に渡れば、そのキーに割り当てられた役割とプロジェクトの範囲内で、プロジェクトの機密データを読み取られたり、変更されたりする危険性がある。これは、まるで建物の正面玄関だけでなく、裏口の鍵がどこかに落ちているような状況と言えるだろう。

実際、ZoomEyeのようなインターネット検索エンジンで「Leantime」を検索すると、多数のLeantimeインスタンスが見つかることがある。これは、インターネット上にLeantimeが広くデプロイされていることを示しており、私たちが所有するLeantimeインスタンスが存在しないか、あるいは不用意な情報公開がないかを定期的に確認するためのきっかけとして利用できる。ただし、検索結果が直ちにセキュリティ上の問題を示すわけではないため、発見されたホストが本当に自社の所有物であるか、DNSや証明書などの情報で確実に確認してから、その安全性について検討する必要がある。

APIキーを安全に管理するためには、それを「サービスID」として厳格に扱うことが不可欠だ。具体的には、すべてのAPIキーについて、その名前、誰が何のために使用しているのかという目的（所有者）、割り当てられている役割、アクセス可能なプロジェクト、作成された日時、そして可能であれば最後に使用された日時を詳細に記録するべきである。テストや実験のために作成されたまま放置されているキーがあれば、直ちに削除する必要がある。例えば、レポート生成のみに使うAPIキーが、関連性のないプロジェクトのチケットを編集できるような権限を持っているべきではない。また、自動化スクリプトが使用するAPIキーであっても、それが誰の責任で運用されているかを明確にするために、所有者を設定するべきだ。

APIキーの作成や管理ができる権限を持つユーザーに対しても、厳格な管理が求められる。このような管理者権限を持つユーザーは、永続的なサービスIDであるAPIキーを作成できるため、強力な認証手段（多要素認証など）を義務付け、その役割へのアクセス経路も厳重に管理する必要がある。新しいAPIキーが作成されたり、その役割やアクセス可能なプロジェクトの範囲が変更されたりした際には、すぐにアラートが通知されるような仕組みを導入し、不正な変更を早期に検知できるようにすることが望ましい。

さらに、Leantimeにおけるプロジェクトの境界設定も、APIの視点から厳密に再確認することが重要だ。Webインターフェースを通じてユーザーやAPIキーが特定のプロジェクトを閲覧できる場合、同じ権限でAPIを通じてそのプロジェクトのチケット、コメント、ファイル、ユーザー、タイムシートといった詳細な情報を照会できてしまう可能性がある。そのため、最小限の権限を持つサービスアカウントを使用してAPIの各エンドポイントを実際にテストし、意図しない情報へのアクセスが確実に拒否されることを検証する必要がある。

Leantimeを自分でサーバーにデプロイしている場合（セルフホスト型デプロイメント）、セキュリティ設定の確認はより一層重要になる。データベースの認証情報やアプリケーションの秘密鍵が、公開されているコンテナイメージやリポジトリに誤って含まれていないかを確認する。外部の認証プロバイダー（例えばGoogle WorkspaceやOktaなど）と連携している場合は、そのプロバイダーからのグループ情報がLeantimeの適切な役割にマッピングされているか、安易に管理者権限が付与されていないかを確認することが重要だ。また、プロジェクトにアップロードされるファイルやエクスポートされたデータに対しても、個別の注意が必要である。プロジェクトメンバーがチケットを閲覧できても、すべてのアップロードファイルにアクセスできるとは限らない。ストレージバックエンドの設定とオブジェクトのアクセス権限を確認し、非公開プロジェクトのファイルが公開ストレージバケットに保存されていないかをチェックする。署名付きダウンロード機能を使用する場合は、その有効期限が短く設定されていることを確認することも忘れてはならない。

システム全体のインベントリ（棚卸し）も欠かせない。Leantimeをホストしている各サーバーについて、ホスト名、SSL証明書、IPアドレス、製品バージョン、所属組織、最初に発見された日時などの情報を記録する。それが単なるデモサイトなのか、ドキュメントサイトなのか、それとも本番環境なのかを区別する作業も重要である。初期設定ウィザードや診断パスがセットアップ後も公開されたままになっていないかを確認し、もし見つかればすぐに無効化する必要がある。リバースプロキシやTLS終端の設定を見直し、アプリケーションが正確なクライアントIPアドレスを認識できているかを確認することも、レート制限や監査ログの正確性を保つ上で重要だ。

万が一、APIキーが漏洩してしまった場合の対応計画も事前に準備しておくべきである。キーが漏洩したと判明したら、Leantime内でそのキーを直ちに失効させる。そのキーが他のシステムやサービスにアクセスするために使われていた場合は、関連するすべての認証情報もローテーション（変更）する必要がある。キーが有効だった期間に、プロジェクト内で不審な活動（チケットの変更、コメントの追加、ファイルのダウンロード、ユーザー管理操作など）がなかったかを詳細にレビューする。もし漏洩したキーが別のAPIキーを作成する権限を持っていた場合、永続的な不正アクセス経路が確立されていないかを確認し、これを排除してからシステムを通常運用に戻す必要がある。

Leantimeはプロジェクト管理を効率化し、APIは自動化を大いに支援する。しかし、その強力なAPIがあるからこそ、APIキーの適切な管理と統制（ガバナンス）が極めて重要となる。サービスアカウントとしてのAPIキーは、「数を最小限に抑え」「アクセス範囲を限定し」「所有者を明確にし」「常に監視可能である」という原則を守るべきだ。これにより、組織は正規のシステム連携と、管理外の不正なプロジェクトデータへのアクセス経路を明確に区別し、セキュリティリスクを最小限に抑えることができるのである。