TeamSpirit不正アクセス：28,824件流出の原因と利用企業の確認点、開発用サーバーの認証情報を守る実装

勤怠・工数管理のクラウドサービス「TeamSpirit」を提供するチームスピリットは、2026年11月6日16時、開発用サーバーへの不正アクセスで個人情報28,824件が流出したと公表しました。第三者は開発用サーバーに不正ログインし、そこに保管されていた認証情報を使ってクラウド環境からデータを取得しています。本記事の前半は、利用企業が知りたい「自社は対象か」「何が流出したか」「何をすればよいか」に公式発表の文言で先に答える構成です。後半では、開発用サーバーに置いた認証情報が入口になる構造を実装の単位に分け、長期のアクセスキーを棚卸しして止めるコマンドと、一時認証情報へ切り替える設定を示します。

まとめ：TeamSpirit不正アクセスで判明した事実と利用企業・開発者が今週やること

判明している事実は次のとおりです。2026年10月27日に不正ログインを確認し、同日中に当該サーバーを停止して外部からの接続経路を遮断しました。流出が疑われる認証情報の無効化は概ね完了し、個人情報保護委員会への報告は10月30日付けで済んでいます。原因は未知の脆弱性ではなく、開発用サーバーの設定と情報管理の不備が重なったことだと説明されています。

利用企業が今週やることは、個別連絡の有無を確かめること、従業員の勤怠記録が含まれていた場合の社内説明を用意すること、チームスピリットを装う連絡への注意を社内に出すことです。開発する側は、開発用サーバーやリポジトリに期限のないクラウドの認証情報が残っていないかを今週中に洗い出してください。

流出した情報の範囲｜契約企業・資料請求者・従業員の3区分と28,824件の内訳

契約企業の担当者と利用ユーザーに含まれたログインIDと勤怠記録の一部

チームスピリットの公式発表は、流出した情報を3つの区分で示しています。1つ目は、TeamSpiritを契約中または過去に契約していた企業の一部です。担当者と利用ユーザーの氏名、メールアドレス、ログインID、同社が管理する識別番号とアカウント情報が含まれました。問い合わせや依頼の記録の一部、企業に関する情報も対象です。

利用企業にとって重いのは、「サービスの提供・維持のために当社が保有していた、お客様企業の従業員の方の勤怠記録の一部」が入っている点です。管理者だけでなく、TeamSpiritで打刻していた従業員本人の記録が対象になりえます。勤怠記録が人事データの中でどう扱われるかは勤怠管理システムとはで整理しています。

資料請求者は識別番号と会社名、従業員は誕生日と社内システムのID

2つ目の区分は、資料請求、問い合わせ、セミナー申込みをした人の一部です。流出したのは同社が管理する識別番号と、会社名などの企業情報とされています。3つ目は同社の従業員と退職者で、氏名、社員番号、業務用メールアドレス、入社日と退職日、誕生日（月日）、社内システムのユーザー名・ID・アカウント情報、業務管理システムの記録が挙げられました。

件数は3区分を合わせて重複を除いた数です。区分ごとの内訳は公表されていません。要配慮個人情報35件の中身も明かされておらず、対象者には個別に連絡するとしています。

本番環境の勤怠・工数データへの不正アクセスが未確認とされた理由と読み方

公式発表は、利用企業がサービス上で運用している勤怠・工数データへの不正アクセスは確認されていないとしています。流出した勤怠記録は、本番環境とは別に、サービスの提供・維持を目的として同社の管理下の環境に保管していたものです。

ここは2つに分けて読みます。本番のデータベースに侵入された形跡は、現時点では無い。一方で、本番から取り出された勤怠記録の写しは、別の環境から持ち出された。保守や問い合わせ対応のために本番データの一部を別環境へ置く運用は珍しくありません。その写しが、本番と同じ強さで守られていたかが問われています。

原因の技術的な分解｜開発用サーバーに置いた認証情報からクラウドへ至る経路

開発用サーバーへの不正ログインと、そこに置かれたクラウドの認証情報

経路は2段です。まず第三者が開発用サーバーにログインしました。次に、そのサーバーに保管されていた認証情報でクラウド環境に入り、データを取得しています。開発用サーバーそのものにデータがあったのではなく、サーバーが「クラウドへの鍵置き場」になっていた構造です。

開発用サーバーは本番より監視が薄く、外部から到達できる設定のまま運用されがちです。そこにクラウドの読み取り権限を持つ認証情報があれば、開発用サーバーへの侵入がそのまま本番に近いデータへの到達になります。同社が原因を「設定と情報管理の不備が重なった」と表現しているのは、この組み合わせを指すと読めます。

公表されていない3点｜侵入手法・クラウド事業者・認証情報の種類

11月6日時点で公表されていないことも押さえておきます。不正ログインの手法は、模倣攻撃を防ぐ観点から公表を控えるとされました。クラウド事業者名と、認証情報がアクセスキーなのか、パスワードなのか、トークンなのかも示されていません。本記事は以降、一般的な例としてAWSのコマンドを示しますが、本件がAWSだったという意味ではありません。

再発防止策は調査結果を踏まえて改めて公表するとされ、検討の中心として「セキュリティ管理体制の強化」「開発環境の再構築」「監視体制の強化」が挙がっています。開発環境の再構築が明記された点から、開発用の基盤ごと作り直す規模の対応になる見込みです。

自社の開発環境を点検するコマンド｜長期アクセスキーの棚卸しと使用履歴の確認

認証情報レポートで使われていない・更新されていないキーを洗い出す

まず、期限のない認証情報がどれだけあるかを数えます。AWSの認証情報レポートは、全IAMユーザーのパスワード、アクセスキー、MFAの状態をCSVで取得できるレポートです。生成できるのは4時間に1回で、4時間以内のレポートがあればそれが返されます。

# レポートを生成し、CSVとして保存する（出力はbase64で返る）
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csv

# アクセスキー1が有効なユーザーと、最後に使った日・作成日を一覧にする
cut -d, -f1,9,10,11 credential-report.csv | grep -i ",true,"

見る列はaccess_key_1_active、access_key_1_last_rotated、access_key_1_last_used_dateです。有効なのに長く使われていないキーは、どこかのサーバーや設定ファイルに置かれたまま忘れられている候補になります。レポートが扱うのは1ユーザーにつき2本までのアクセスキーで、それを超えるキーやサービス固有の認証情報は載らない点に注意してください。

漏えいが疑われるキーは削除せず無効化してから使用履歴を追う手順

流出が疑われるキーを見つけたら、最初の操作は削除ではなく無効化です。update-access-keyでInactiveにすれば、キーは使えなくなり、調査のための記録は残ります。

# 1. キーを無効化する（削除はしない）
aws iam update-access-key --user-name dev-build --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

# 2. 最後にどのサービス・リージョンで使われたかを見る
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

# 3. そのキーで呼ばれた管理系APIを時刻順に引く（直近90日・リージョン単位）
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --start-time 2026-10-01T00:00:00Z

get-access-key-last-usedは、最後の使用日時、サービス名、リージョンを返します。3つ目のlookup-eventsで引けるのは、直近90日の管理イベントとInsightsイベントです。S3のオブジェクト読み取りのようなデータイベントは対象外で、記録するには証跡でデータイベントを有効にしておく必要があります。「データを取得された」かどうかを後から確かめたいなら、事前の設定が要るということです。Webアプリ側のセッションやトークンまで失効させる手順はセッションハイジャックとはで解説しています。

開発用サーバーとリポジトリに残った鍵をgitleaksで探す

サーバーの中やリポジトリの履歴に鍵が書かれていないかは、gitleaksで探せます。ディレクトリを調べるdirと、Gitの履歴を調べるgitの2つのモードがあります。

# 開発用サーバーのホームディレクトリと設定置き場を調べる
gitleaks dir -v /home/deploy --report-path gitleaks-server.json

# リポジトリの全履歴を調べる（削除済みのコミットに残った鍵も対象）
gitleaks git -v --report-path gitleaks-repo.json ./app-repo

履歴から鍵を消しても、一度コミットされた鍵は複製先に残ります。見つかった鍵は、消す前に無効化と再発行を済ませるのが順番です。なおgitleaksのREADMEは、機能追加を終えて今後はセキュリティ修正のみになると告知しています。後継の扱いを含む使い方はgitleaksとはにまとめました。

開発用サーバーに長期の認証情報を置かない実装｜一時認証情報と実データの分離

開発者のCLIはIAM Identity Centerの一時認証情報に切り替える設定

AWSのIAMのセキュリティのベストプラクティスは、人が使う場合はIDプロバイダとの連携で一時認証情報を使い、ワークロードはIAMロールの一時認証情報を使うよう求めています。開発者の手元やサーバーに~/.aws/credentialsとして長期キーを置く代わりに、IAM Identity Centerの認証を使う設定は次のとおりです。

# ~/.aws/config
[profile dev]
sso_session = corp-sso
sso_account_id = 111122223333
sso_role_name = DeveloperReadOnly
region = ap-northeast-1

[sso-session corp-sso]
sso_region = ap-northeast-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access

aws sso login --profile dev
aws sts get-caller-identity --profile dev
aws sso logout

ログインで得たトークンは~/.aws/sso/cacheに保存されます。期限があるとはいえ、サーバー上に置けば有効な間は使われうるため、共有の開発用サーバーではなく各自の端末でログインする運用が必要です。権限セットの設計はAWS IAM Identity Centerとは、ユーザーとロールの違いはAWS IAMとはで扱っています。

サーバー上のプログラムはロールで動かし、設定ファイルから鍵を消す

EC2やLambdaで動くプログラムには、AWSがIAMロールの一時認証情報を渡します。SDKはそれを自動で見つけて使うため、設定ファイルに鍵を書く必要はありません。AWSの外で動くサーバーやCIでも、IAM Roles AnywhereやOIDCのAssumeRoleWithWebIdentityで一時認証情報を受け取れます。データベースのパスワードのように鍵を残すしかないものは、サーバーのファイルではなくAWS Secrets Managerに置き、ロールで読み出します。

保守用の環境に置く本番データの写しは調査に必要な期限と項目を絞る

今回流出した勤怠記録は、本番とは別の環境に置かれた写しでした。問い合わせ対応や不具合調査は、本番データが必要になることのある場面です。そのときは、調査に要る項目と期間だけを取り出し、氏名やメールアドレスは識別番号に置き換え、調査が終われば消す、という3つを手順として決めておきます。期限と削除の担当が決まっていない写しは、誰も消さないまま残り続けます。

利用企業の対応｜個別連絡の確認・報告の整理・チームスピリットを装う連絡への備え

個別連絡は11月6日から順次、管理者に届かない場合は専用窓口へ確認

チームスピリットは、対象者に流出した項目を個別に連絡するとしており、11月6日から順次始めています。連絡先が確認できない人には、公式発表をもって個別連絡に代えるとされました。管理者が交代していると連絡が届かない可能性があるため、公式発表に記載の「不正アクセス対応窓口」へメールで確かめるのが確実です。

従業員の勤怠記録が含まれた場合に利用企業が整理する報告の当事者

チームスピリット自身は、10月30日付けで個人情報保護委員会に報告しています。利用企業は、従業員の勤怠記録をサービスに預けている立場です。個別連絡で自社の従業員の記録が含まれると分かったら、自社としての報告と本人への通知が必要かを、委託の関係と流出した項目に照らして整理します。対象となる事態の類型と、速報・確報の期限は個人情報保護委員会への報告義務で解説しました。

チームスピリットを装うメール・電話・SMSを見分ける社内向けの規則

同社は、流出した情報を使って同社や従業員を装う不審なメール、電話、SMSが届くおそれがあると注意を呼びかけています。漏れたのは氏名、メールアドレス、ログインIDの組です。「勤怠データの確認が必要です」「アカウントの再設定をお願いします」という連絡は、受け取った人にとって本物に見えます。

• 同社はメールや電話でパスワードなどの認証情報を尋ねないと明記しているため、尋ねる連絡はすべて偽物として扱う
• TeamSpiritへのログインは、メールのリンクではなくブックマークか社内ポータルから行う
• 打刻の修正や給与への影響をほのめかす連絡は、社内の人事担当に転送して確かめる

3つ目は、勤怠記録が漏れた今回ならではの規則です。管理者だけでなく、TeamSpiritで打刻している従業員全員に共有します。偽の連絡の手口はフィッシング詐欺とはで解説しています。

今週中に点検すべき開発環境と次回の定期診断でよい開発環境の線引き

外から到達できる開発用サーバーに期限のないクラウドの鍵があるなら今週中

次の2つが両方当てはまる開発環境は、今週中に点検してください。開発用サーバーにインターネットからログインできること、そのサーバーかリポジトリに期限のないクラウドの認証情報があることです。今回と同じ構造で、開発用サーバー1台の侵入がクラウド上のデータに直結します。本番データの写しを置く保守用の環境がある場合も、同じ扱いにします。

開発環境、クラウドの権限設定、外から到達できるサーバーまでを第三者の目で洗い出したいときは、脆弱性診断・セキュリティ診断で点検できます。APIの認可やトークンの失効まで見直すならAPI不正アクセス対策の実装手順も参考になります。

一時認証情報だけで運用し実データを置かない環境は定期診断で足りる

開発者がIAM Identity Centerなどの一時認証情報だけでクラウドに入り、サーバー上のプログラムがロールで動き、開発環境に本番の個人データを置いていない。この3つが揃っていれば、次回の定期診断で構いません。今回の対策で先に効くのは、高度な検知の追加ではなく、開発用サーバーから期限のない鍵を無くすことです。

よくある質問

TeamSpiritの不正アクセスについて、利用企業の管理者と開発者から出やすい質問をまとめました。

TeamSpiritのパスワードを変える必要はありますか？

11月6日の公式発表で利用企業側の流出項目として挙がっているのは、氏名、メールアドレス、ログインID、識別番号・アカウント情報などで、パスワードは明記されていません。同社は流出が疑われる認証情報の無効化を概ね完了したとしています。変更の要否は個別連絡の案内に従ってください。いずれの場合も、ログインIDとメールアドレスを使った偽のログイン画面への誘導に注意が必要です。

自社が対象かどうかはどうすれば分かりますか？

チームスピリットは11月6日から、対象者へ流出した項目を個別に連絡しています。管理者の交代や退職で連絡が届いていない可能性がある場合は、公式発表に記載の不正アクセス対応窓口にメールで確かめてください。連絡先が確認できない人には、公式発表をもって個別連絡に代えるとされています。

TeamSpiritに入力している勤怠データは本番から漏れたのですか？

公式発表では、本番環境で運用されている勤怠・工数データへの不正アクセスは確認されていません。流出した勤怠記録は、サービスの提供・維持を目的として本番とは別の環境に保管されていた一部です。どの期間・どの従業員の記録が含まれるかは、個別連絡で示されます。

トラスト・ログインの情報漏えいとは何が違いますか？

GMOトラスト・ログインは、公開設定のストレージに置いたファイルを外部から取得できた設定不備の事案で、侵入はありませんでした。TeamSpiritは、開発用サーバーへの不正ログインを起点に、保管されていた認証情報でクラウドからデータが取得された事案です。対策も、公開設定の見直しと認証情報の管理で異なります。トラスト・ログインの経緯はトラスト・ログイン情報漏洩で整理しています。

開発用サーバーの認証情報が漏れたら最初に何をしますか？

最初に認証情報を無効化し、次にその認証情報で何が呼ばれたかを記録から確かめます。削除すると調査に使える手掛かりが減るため、先に行う操作は無効化です。AWSならアクセスキーをInactiveにし、最終使用日時とCloudTrailの管理イベントを確認します。サーバーは停止してから外部との接続経路を断ち、ディスクの保全も必要です。チームスピリットも、同日中のサーバー停止と接続経路の遮断を最初に行っています。

関連記事

• トラスト・ログイン情報漏洩：2,492社・45,030人の原因と利用企業の確認点、公開ストレージを防ぐ実装：同じSaaS事業者側で起きた別の原因の事案
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：認証情報の失効とAPIの認可の実装
• AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説：長期キーを一時認証情報へ置き換える設計
• gitleaksとは？使い方・設定とBetterleaksへの移行判断【v8.30.1で実測】：サーバーとリポジトリに残った鍵の検出
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：利用企業が行う報告の手順