OneDev運用で見落としがちな権限設計の落とし穴（271件調査から）

OneDevというGitホスティング兼CI/CDツール（ソースコード管理・課題管理・パッケージ配布・ビルド実行を1つにまとめた統合プラットフォーム）を自社運用している方に向けた内容です。ログイン画面のセキュリティ対策だけに目が行きがちですが、実際の露出リスクはアクセストークンやジョブシークレットといった権限設計の内側に潜んでいます。

2026年11月2日時点でのZoomEye（インターネット上に公開されている機器やサービスを検索できるサーチエンジン）の調査では、app="OneDev"条件で271件の資産がヒットしています。これはあくまで製品の特徴（フィンガープリント）が一致した件数であり、全てが脆弱という意味ではありません。ただしこの数字は、OneDevがGitリポジトリの置き場所にとどまらず、ビルド実行権限やパッケージ書き込み権限まで含む「権限の束」として外部に露出しうることを示す起点になります。

何が起きるか：ログイン画面の先にある権限の多層構造

OneDevは単なるソースコードサーバーに見えても、裏側ではアクセストークン・ジョブシークレット（ビルド定義に機密情報を直書きせず保管する仕組み）・パッケージ書き込み権限・ビルド実行環境という4つの権限レイヤーが連動しています。

たとえば、公開リポジトリの閲覧だけを想定して認証設定を緩めていたとします。そのプロジェクトに紐づくトークンがコード書き込みやパッケージ公開の権限を同時に持っていると、閲覧用のつもりだった入口が内部パッケージレジストリへの書き込み口に変わってしまいます。

これはログイン画面の堅牢性とは別問題です。認証をどれだけ強化しても、トークンやシークレットのスコープ設計が緩ければ、権限の射程がプロジェクトの想定を超えて広がります。

なぜ起きるか：権限とスコープの境界があいまいになる3つの段階

段階1: トークンのプロジェクト権限が広すぎる

OneDevのアクセストークンはユーザーメニューから作成・編集・削除できますが、トークンが持つ権限（コード書き込み、パッケージ書き込みなど）はプロジェクト単位で付与されます。ブランチ保護やタグ保護が設定されていないと、本来は限定的なはずのビルドジョブ用トークンが、意図しないブランチへの書き込みを許してしまいます。

段階2: ジョブシークレットがログや他のトークン経由で漏れる

ジョブシークレットはビルド仕様に機密情報を埋め込まないための仕組みですが、プロジェクトの閲覧者がログから値を読み取れたり、権限範囲の広いトークンで取得できたりすると、保護の意味がなくなります。どのジョブがどのシークレットを使えるか、どのブランチでそのジョブが実行できるかを確認しないまま運用すると、信頼できない外部コントリビューターのプルリクエストビルドから、本番環境用のシークレットに到達するリスクが生まれます。

段階3: パッケージ権限がリポジトリ権限と同じ仕組みで管理されている

OneDevのパッケージ読み書き権限は、ロールとプロジェクト権限という同一の仕組みで付与されます。つまり公開されたリポジトリの先に、内部パッケージレジストリへの経路が存在する可能性があります。ソースコードと同じ丁寧さで、パッケージの名前空間と公開用アイデンティティも棚卸しする必要があります。

自分のプロジェクトが該当するかの確認方法

以下の観点で、自組織のOneDevインスタンスを棚卸ししてみてください。

プロジェクトを作成できるアカウント、ユーザー管理権限を持つアカウント、認証ソースを管理できるアカウントの一覧を洗い出す
各アクセストークンの所有者・作成日・付与権限・最終利用日時を確認する（製品がこれらの情報を提供している場合）
ジョブごとに、どのシークレットを使用でき、どのブランチで実行可能かをビルド仕様ファイルで確認する
匿名ユーザーに付与されている権限を明示的に確認する（公開リリース成果物は意図的に公開でも、ソースコードやビルドログは非公開であるべき）
リバースプロキシ経由で公開している場合、別オリジンや古いDNSレコード、認証を迂回するポートが露出していないか確認する

加えて、公開DNSレコードとTLS証明書の名前を、想定しているイングレス（外部からのアクセス経路）構成と突き合わせることも有効です。想定外のホスト名や証明書が見つかった場合は、まず所有権の証拠を確認してから対応を検討してください。

対策の手順

まず、どのアカウントがどの操作をできるか棚卸しした上で、以下を実施します。

# ZoomEyeなどの外部調査ツールで自組織のOneDevインスタンスが
# 意図せず公開されていないか定期的に確認する（クエリ例のイメージ）
# app="OneDev" のような製品フィンガープリントで検索し、
# 得られたホスト名・証明書・IPを自組織の資産台帳と突き合わせる

1. トークンの棚卸し: ジョブや外部連携に紐づかないトークンは削除し、リポジトリファイル・ビルドログ・コンテナイメージ・公開成果物に紛れ込んだトークンがあればローテーション（再発行）する

2. シークレット権限の見直し: ジョブがシークレットの値を環境変数として出力できないか、外部サービス呼び出し時にトークンを渡していないかを確認する

3. CIランナーの個別評価: ビルド実行環境はネットワークアクセス権とマウントされた認証情報を持つ「高価値な実行環境」として、Webアカウントとは切り離して審査する

4. 匿名権限の明文化: 汎用的な匿名ロールに依存せず、公開すべき範囲を設定として明示的に表現する

5. 継続的な監視の仕組み化: ZoomEyeのようなクエリを定期実行し、新しいホスト名・証明書・製品マッチが自組織ドメインに関連していないかを比較する。クエリ条件・スコープ・実行時刻・件数は記録として保存しておく

OneDevのセキュリティはログイン画面の強度ではなく、トークン・シークレット・パッケージ権限という3層のスコープ設計で決まります。

まとめ

OneDevのようにGit・CI/CD・パッケージ管理を1つに統合したプラットフォームは、運用効率が高い一方で権限設計の複雑さも引き受けることになります。

確認すべきは次の3点です。

アクセストークンがプロジェクト単位でどこまでの権限を持っているか、ブランチ・タグ保護と合わせて点検する
ジョブシークレットが信頼できないビルド（外部コントリビューターのプルリクエストなど）からアクセス可能になっていないか確認する
パッケージ権限がリポジトリ権限と同じ仕組みで管理されている点を踏まえ、パッケージ名前空間も棚卸し対象に含める

まずは自組織のアクセストークン一覧を開き、最終利用日時が古いものや所有者が不明なものから見直してみてください。件数の増減だけでなく、権限のスコープそのものを定期的に点検する運用に落とし込むことが、露出リスクを減らす近道です。