---
title: "ユニリタの不正アクセス：SaaS文書管理から漏れた顧客の認証情報と回す手順"
url: "https://www.issoh.co.jp/tech/details/18213/"
published: 2026-10-09
updated: 2026-10-09
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ユニリタの不正アクセス：SaaS文書管理から漏れた顧客の認証情報と回す手順

東証スタンダード上場のITベンダー、ユニリタは2026年10月9日の開示で、9月28日に判明した不正アクセスの被害が特定のSaaS型文書管理システムに限られ、顧客のシステム認証情報や契約書、顧客の従業員の個人情報が漏えいしたと公表しました。本記事では9月29日のお知らせと10月9日の開示を突き合わせて確定した事実と未公表の点を分け、ランサムウェアグループEverestの主張とも区別して整理します。そのうえで、委託先に認証情報を渡していた企業が利用状況を確かめて回すAWS CLIの手順、ベンダー側が文書に残った認証情報を洗い出すPython、シークレット管理へ移す判断までを扱います。

## まとめ：ユニリタの不正アクセスで確定した事実と顧客企業・委託先の対処

確定しているのは、社内の文書管理システムに第三者が不正にアクセスし、一部のデータが窃取されたことです。10月9日の開示で、被害は特定のSaaS型文書管理システムに限られ、改ざんや欠損は確認されていないとされました。発覚のきっかけは社内の監視ではなく、9月28日13時30分頃に確認した、外部のWebサイト上の「情報を窃取した」という公表です。侵入経路、使われた製品、攻撃者は10月9日時点で公表されていません。

ユニリタに認証情報を渡していた顧客企業がまず行うのは、その認証情報の利用履歴を確かめ、新しいものに替えることです。個別の連絡を待つ必要はありません。顧客環境の認証情報を預かる側のベンダーは、文書管理やファイル共有に置いたパスワードや鍵を洗い出し、シークレット管理の仕組みへ移します。

| 項目         | 公表されている内容                 |
| ---------- | ------------------------- |
| 判明         | 9月28日13時30分頃・外部サイトの窃取主張確認 |
| 被害範囲       | 特定のSaaS型文書管理システムに限定       |
| 漏えいを確認した情報 | 契約書・顧客のシステム認証情報・個人情報など7項目 |
| 改ざん・業務影響   | 改ざん・欠損なし／システム障害なし         |
| 二次被害       | 10月9日時点で確認なし              |
| 未公表        | 侵入経路・製品名・攻撃者・再発防止策        |

## 公表文で確認する経過：9月28日の窃取主張の確認から10月9日の開示まで

### 9月28日13時30分頃に外部サイトの窃取主張で発覚した経緯と翌日のお知らせ

[ユニリタの会社概要](https://www.unirita.co.jp/corporate/about/profile.html)によると、同社は企業向けのデータ利用とシステム運用に関する製品・サービスの開発と販売、周辺システムの開発、コンサルティングを手がけています。[9月29日のお知らせ](https://www.unirita.co.jp/news/2026/media%5F20260929.html)では、28日午後に社内システムからの情報漏えいの疑いを確認したと公表しました。この時点で、不正アクセスと情報の窃取を確認できたのは特定の社内文書管理システムに限られる、としています。

同社はアクセス遮断などの措置を直ちに取り、外部専門家の協力を得て流出経路と被害の調査に入りました。改ざんや欠損は確認されず、システム障害も業務への支障も出ていない、という説明です。暗号化による業務停止を伴わず、データの持ち出しだけが表に出た事案になります。

### 10月9日の開示で特定されたSaaS型文書管理システムと漏えい7項目

[10月9日の開示](https://www.unirita.co.jp/dcms%5Fmedia/other/261009%5Fkaiji001.pdf)で、被害を受けたのは「特定のSaaS型文書管理システム」だと絞り込まれました。漏えいが確認された情報として挙がったのは次の7項目です。

- お客様、取引先との契約書
- お客様のシステム認証情報
- お客様の従業員、社外関係者の個人情報（特定個人情報を含まない）
- その他お客様からお預かりしている重要な情報
- 社内のシステム認証情報
- 社員の個人情報（特定個人情報を含まない）
- その他の社内の重要な情報

対応として、情報セキュリティ対策本部を置いたこと、システム認証情報が漏えいした顧客には個別に知らせてパスワードの変更などを依頼すること、社内システムのパスワード変更と認証方式の強化を実施していることが書かれています。個人情報については個人情報保護委員会へ報告し、対象者への個別通知を順次進めるとしています。警察にも相談済みです。再発防止策は続報で公表する予定で、業績への影響は現時点で不明としています。

### Everestが主張する約128GB・15万9,901ファイルと公式発表の差

[セキュリティ対策Labの記事](https://rocket-boys.co.jp/security-measures-lab/unirita-data-breach-everest-127g/)によると、ランサムウェアグループEverestは9月30日までにリークサイトへユニリタを載せ、127.964GB、15万9,901ファイル、2万2,338フォルダの取得を主張しています。これは攻撃者側の主張を二次情報が伝えたものです。ユニリタは攻撃者の名前も、窃取された容量やファイル数も公表していません。

10月9日の開示は、取得されたおそれのある情報がインターネット上に公開された事実や、二次被害、不正利用は現時点で確認されていないとしています。「持ち出された」ことと「公開された」ことは別に扱われています。顧客側が備えるのは、持ち出された時点で使われうる認証情報です。公開を待つ理由はありません。

## 文書に置かれた認証情報の危うさ：契約書と接続情報が同じ場所にある構造

### 「お客様のシステム認証情報」が文書管理にあったことが示す保管の実態

漏えい項目に「お客様のシステム認証情報」があるということは、顧客の環境へ接続するための情報が、文書管理システムのファイルとして保管されていたと読めます。どのシステムの、どの種類の認証情報か、件数がどれだけかは公表されていません。

導入支援や保守の現場では、接続先のホスト名、管理者アカウント、初期パスワードを「接続情報.xlsx」や手順書の一節に書いて、案件フォルダで共有する運用がよく見られます。契約書や設計書と同じ場所に置くと、文書管理の権限設計がそのまま認証情報の権限設計になる構造です。案件メンバー全員が閲覧できるフォルダなら、そのうち1人のアカウントが乗っ取られた時点で、全顧客分の接続情報が持ち出しの対象に入ります。

### 改ざんなし・業務支障なしでも認証情報の漏えいだけで残る不正ログインの窓

今回、ユニリタの業務は止まっていません。ただ、漏えいした情報の性質で見ると、認証情報だけは他の項目とは異なる扱いが必要です。契約書や個人情報は持ち出された後に取り戻せませんが、認証情報は変更すれば無効にできます。逆に、変更するまでの間は顧客環境への入口として働き続けます。

窓が開いている期間は、窃取された日から顧客が変更を終える日までです。ユニリタが判明したのは9月28日で、個別の連絡はその後に順次届きます。連絡を受けてから動くと、その分だけ窓が長くなります。ユニリタと保守や導入の取引がある企業は、連絡の有無にかかわらず、渡した認証情報を自分たちの側で洗い出して変更を始めてください。

## 顧客企業の手順：委託先に渡した認証情報の利用確認とローテーション

ここで例にするのは、委託先にAWSのIAMユーザーのアクセスキーを渡していた場合です。[AWSの識別子の説明](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference%5Fidentifiers.html)のとおり、長期のアクセスキーIDは`AKIA`で始まり、STSの一時認証情報は`ASIA`で始まります。委託先に渡したのが`AKIA`のキーなら、有効期限がないため、変更しない限り使われ続けます。

### アクセスキーの最終利用とCloudTrailの呼び出し元IPを確かめるAWS CLI

最初に、そのキーが最後にいつ、どのサービスで使われたかを[get-access-key-last-used](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)で見ます。一度も使われていなければ、返される値は`LastUsedDate`がnull、`ServiceName`が`N/A`です。次に[cloudtrail lookup-events](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html)をアクセスキーIDで絞り込み、呼び出し元のIPアドレスを並べます。

```
# 委託先に渡したアクセスキーの最終利用と、9月以降の呼び出し元IPを確かめる（AWS CLI v2・jqが必要）
KEY_ID="AKIA0000000000000000"     # 委託先に払い出したアクセスキーIDに置き換える
REGION="ap-northeast-1"           # キーで操作していたリージョンごとに繰り返す

aws iam get-access-key-last-used --access-key-id "$KEY_ID"

aws cloudtrail lookup-events \
  --region "$REGION" \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue="$KEY_ID" \
  --start-time 2026-09-01T00:00:00Z \
  --output json |
jq -r '.Events[] | (.CloudTrailEvent | fromjson) | [.eventTime, .eventName, .sourceIPAddress, .userAgent] | @tsv' |
sort > key_usage_${KEY_ID}.tsv
```

出力のIPアドレスが委託先の作業拠点や自社のジョブ実行環境と一致するかを確かめます。lookup-eventsが返すのはリージョンごとの直近90日の管理イベントで、S3のオブジェクト読み出しのようなデータイベントは含みません。データイベントを記録する証跡を設定していない場合、ここで何も出なくても「読まれていない」とは言えない点に注意してください。呼び出しは1アカウント・1リージョンあたり毎秒2回までに制限されています。

### 新しい鍵を先に渡し旧鍵を無効化してから削除する順番と止める条件

[AWSのアクセスキー更新の手順](https://docs.aws.amazon.com/IAM/latest/UserGuide/id-credentials-access-keys-update.html)は、新しいキーを作って利用側を切り替え、古いキーの最終利用を確かめてから`Inactive`にし、問題が出ないことを見届けてから削除する順番です。いきなり削除しないのは、古いキーを使い続けているジョブを見つけたときに、`Active`へ戻せるようにするためです。

この順番を崩してよい条件は1つです。前の手順で、委託先とも自社とも一致しないIPアドレスからの呼び出しが見つかったら、ジョブが止まることを受け入れてその場で`Inactive`にします。新しいキーは、メールや文書管理のファイルではなく、有効期限つきで共有できるシークレット管理の仕組みで渡してください。委託先が長期のキーを持たずに済む構成、つまりIAMロールの引き受けやIAM Identity Centerへ移せるなら、この機会に移します。人ではなくジョブが使う認証情報の管理は[ノンヒューマンアイデンティティ（NHI）の守り方](https://www.issoh.co.jp/tech/details/13616/)で整理しています。

## 委託先の手順：文書管理から書き出したファイルに残る認証情報の検出

### パスワード記載・AWSキー・秘密鍵・接続文字列を探すPythonスクリプト

顧客の認証情報を預かるベンダーの側で行うのは、文書管理やファイル共有に置かれたままの認証情報の洗い出しです。次の例は、文書管理から書き出したフォルダを順に見て、テキスト、設定ファイル、Word・Excel・PowerPointの中から4種類の認証情報を探します。Office文書はZIP形式なので、標準ライブラリの[zipfile](https://docs.python.org/3/library/zipfile.html)で中のXMLを読み、[re](https://docs.python.org/3/library/re.html)の正規表現で照合します。追加のライブラリは要りません。

```
# 文書管理から書き出したファイル群に残った認証情報を洗い出す（Python 3.9以上・標準ライブラリのみ）
import re
import sys
import zipfile
from pathlib import Path

RULES = [
    ("AWSアクセスキー", re.compile(r"\b(AKIA|ASIA)[0-9A-Z]{16}\b")),
    ("秘密鍵", re.compile(r"-----BEGIN (RSA |EC |OPENSSH |DSA )?PRIVATE KEY-----")),
    ("接続文字列", re.compile(r"\b[a-z][a-z0-9+]*://[^\s:@/]+:[^\s@/]+@[\w.-]+", re.I)),
    ("パスワード記載", re.compile(r"(パスワード|password|passwd|pwd)\s*[:：=＝]\s*\S{4,}", re.I)),
]
TEXT_EXT = {".txt", ".csv", ".tsv", ".md", ".ini", ".conf", ".env", ".json", ".yml", ".yaml", ".pem"}
OFFICE_EXT = {".docx", ".xlsx", ".pptx"}

def read_text(path: Path) -> str:
    if path.suffix.lower() in OFFICE_EXT:
        with zipfile.ZipFile(path) as z:
            parts = [n for n in z.namelist() if n.endswith(".xml")]
            xml = " ".join(z.read(n).decode("utf-8", "replace") for n in parts)
        return re.sub(r"<[^>]+>", "", xml)
    raw = path.read_bytes()[:2_000_000]
    for enc in ("utf-8-sig", "cp932"):
        try:
            return raw.decode(enc)
        except UnicodeDecodeError:
            continue
    return raw.decode("utf-8", "replace")

def mask(s: str) -> str:
    return s[:6] + "****" if len(s) > 6 else "****"

def scan(root: Path) -> int:
    hits = 0
    for path in sorted(root.rglob("*")):
        ext = path.suffix.lower()
        if not path.is_file() or ext not in TEXT_EXT | OFFICE_EXT:
            continue
        try:
            text = read_text(path)
        except (OSError, zipfile.BadZipFile) as e:
            print(f"{path.relative_to(root)}: 読み取り不可（{type(e).__name__}）")
            continue
        for label, rule in RULES:
            for m in rule.finditer(text):
                hits += 1
                print(f"{path.relative_to(root)}: {label} {mask(m.group(0))}")
    return hits

if __name__ == "__main__":
    sys.exit(1 if scan(Path(sys.argv[1])) else 0)
```

検出した値は先頭6文字だけを出し、残りを伏せます。結果のログ自体が新しい認証情報の置き場にならないようにするためです。

### 模擬データの5件検出と結果を認証情報の台帳とローテーションにつなぐ方法

架空の値だけで作った3フォルダ・5ファイル（接続情報のテキスト、デプロイ用の.env、保守手順書のWord、SSHの秘密鍵、社内の議事録）に対して、`python secret_scan.py 書き出し先のフォルダ`で実行した結果です（Python 3.14.6・Windows）。

```
customer_a\project\deploy.env: AWSアクセスキー AKIAIO****
customer_a\project\deploy.env: 接続文字列 postgr****
customer_a\project\接続情報.txt: パスワード記載 パスワード:****
customer_b\server.pem: 秘密鍵 -----B****
customer_b\保守手順書.docx: パスワード記載 passwo****
```

5件を顧客フォルダ名つきで検出し、終了コードは1でした。「パスワードの定期変更について議論した」と書いただけの議事録は、区切り記号と値が無いため通過しています。議事録のフォルダだけを指定すると終了コードは0です。Excelの表で「パスワード」の見出しと値が別のセルに入っている場合はこの規則では拾えないため、列名で判定する[両毛システムズの事例で示した残存ファイルの検出](https://www.issoh.co.jp/tech/details/18211/)と組み合わせて回してください。

検出したものは、顧客名、認証情報の種類、置き場所、変更した日を1行にした台帳に移し、ファイルからは消します。台帳があれば、今回のような事案が起きたときに「どの顧客の、どの認証情報を、いつまでに変えてもらうか」を初日に連絡できます。

## 認証情報を文書に置かない判断：シークレット管理へ移す条件と残す条件

### 顧客環境の認証情報を文書管理に置かずシークレット管理へ移すと決める条件

判断は言い切れます。顧客の本番環境に入れる認証情報、つまり管理者アカウントのパスワード、クラウドのアクセスキー、SSHの秘密鍵、データベースの接続文字列は、文書管理にもファイル共有にも置きません。[AWS Secrets Manager](https://www.issoh.co.jp/tech/details/15888/)や[HashiCorp Vault](https://www.issoh.co.jp/tech/details/15580/)のような、取り出しの記録が残り、権限を案件と人の単位で切れる仕組みに移します。取り出すたびに記録が残るので、漏えいの疑いが出たときに「誰が、いつ、どの顧客の認証情報を見たか」を答えられます。

文書に残してよいのは、接続先のホスト名、アカウント名、認証方式、それに「認証情報はどこにあるか」という参照先までです。値そのものは書きません。逆に、検証用の使い捨て環境で、案件終了と同時に環境ごと消すものまでシークレット管理に載せるのは過剰です。人が使う管理者アカウントには、パスワードの置き場所を変えるだけでなく[多要素認証](https://www.issoh.co.jp/tech/details/13314/)を掛けてください。パスワードの長さや変更頻度の考え方は[パスワード管理のベストプラクティス](https://www.issoh.co.jp/column/details/13508/)にまとめています。

### 犯行声明で知る前に気づくためのSaaS監査ログと大量ダウンロードの監視

ユニリタが事案を把握したのは、外部サイトの窃取主張を確認した9月28日です。社内の監視で先に気づけたかどうかは公表されていません。文書管理SaaSを使う企業が自分で確かめられるのは、管理画面から監査ログを取り出せるか、その保存期間は何日か、ダウンロードやエクスポートの操作が記録の対象に入っているか、の3点です。

そのうえで、1人のアカウントが1時間に数百ファイルを落とす、普段触らない顧客フォルダを一括で開く、といった操作を通知の条件にします。通常の業務で1日に数十ファイルしか扱わない組織なら、閾値は日々の件数の数倍で十分です。文書管理をクラウドへ移すときの権限設計と移行の判断は[文書管理をクラウド化する判断基準](https://www.issoh.co.jp/column/details/15613/)で扱っています。委託先のデータベースで同じ考え方の監視を組む例は[旭化成ファーマの事例での委託先DBの監視設計](https://www.issoh.co.jp/tech/details/18166/)にあります。

## 委託元と委託先の報告と通知：個人情報保護法26条と顧客への個別連絡

### 顧客の従業員や社外関係者の個人情報で委託元が数える速報期限の起点

[個人情報保護法](https://laws.e-gov.go.jp/law/415AC0000000057)26条1項は、漏えい等が起きたとき個人情報保護委員会への報告を義務付け、ただし書で、委託を受けた事業者が委託元にその事態を通知したときは委託先の報告義務を外しています。ユニリタが漏えいを確認した「お客様の従業員、社外関係者の個人情報」が、顧客から委託を受けて扱っていたものであれば、報告と本人への通知の主体は顧客側になります。

[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、速報は事態を知った日から3〜5日以内、確報は30日以内、不正の目的によるおそれがある場合は60日以内です。顧客企業にとっての起点は、ユニリタから個別の通知を受けた日です。通知が届いたら、自社が委託元としての報告を求められる立場かどうかを最初に確かめてください。報告の書式と段取りは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。

### 委託契約で確かめる認証情報の受け渡し方法と漏えい時の連絡期限

今回の件で委託元が契約に足すのは2点です。認証情報を渡す方法と保管場所を指定すること、そして委託先で漏えいの疑いが出たときに何日以内に誰へ連絡するかを決めることです。個人データの委託先の監督だけでなく、認証情報の受け渡しも委託先管理の対象に入れます。

委託先を起点にした攻撃の全体像は[サプライチェーン攻撃とは](https://www.issoh.co.jp/column/details/13184/)で整理しています。委託先に渡している認証情報の棚卸し、文書管理やファイル共有の権限設定、外部から見える入口までをまとめて第三者の目で確かめるなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で点検できます。

## よくある質問

ユニリタの不正アクセスについて、取引先の企業とシステム担当者から出やすい質問をまとめました。

### ユニリタの不正アクセスでどんな情報が漏えいしたのですか？

10月9日の開示では、顧客や取引先との契約書、顧客のシステム認証情報、顧客の従業員や社外関係者の個人情報（特定個人情報を含まない）、顧客から預かっている重要な情報、社内のシステム認証情報、社員の個人情報（特定個人情報を含まない）、その他の社内の重要な情報の7項目を挙げています。件数や対象の顧客名は公表されていません。

### ユニリタはランサムウェアの被害を受けたのですか？

ユニリタの公式発表は、文書管理システムへの不正アクセスとデータの窃取を認めていますが、ランサムウェアによる暗号化や攻撃者の名前には触れていません。改ざんや欠損、システム障害も確認されていないとしています。Everestがリークサイトで約128GBの取得を主張していると報じられていますが、これは攻撃者側の主張です。

### 侵入経路は分かっていますか？

10月9日時点で侵入経路は公表されていません。分かっているのは、被害が特定のSaaS型文書管理システムに限られていることと、社内システムのパスワード変更と認証方式の強化を実施したことです。どの製品か、どのアカウントが使われたかも明らかにされていません。再発防止策は続報で公表される予定です。

### ユニリタの製品を使っている企業は何を確認すればよいですか？

製品を使っていること自体より、導入や保守のためにユニリタへ自社システムの認証情報を渡したことがあるかを確認してください。渡していれば、その認証情報の最終利用日と接続元を確かめ、個別の連絡を待たずに変更します。契約書や打ち合わせ資料に自社の構成情報が書かれていた場合は、その情報が外に出た前提で、外部から見える入口を点検します。

### ユニリタからの連絡を装ったメールに注意は必要ですか？

必要です。漏えいした契約書や個人情報には、取引の担当者名や連絡先が含まれる可能性があります。ユニリタを名乗って認証情報の再登録やファイルの開封を求める連絡が来ても、メール内のリンクからは操作せず、普段の窓口か同社の公式サイトに載った専用窓口から確認してください。

## 関連記事

- [両毛システムズのランサムウェア被害：VPNアカウント悪用と委託元に残ったファイルの点検](https://www.issoh.co.jp/tech/details/18211/)：委託先の社内に残った委託元の作業ファイルが漏れた事例
- [旭化成ファーマのサイバー攻撃：Pharma DIGITAL会員51.4万人の漏えいと委託先DBの監視設計](https://www.issoh.co.jp/tech/details/18166/)：委託先が運用するDBでの大量読み出しの監視
- [IDCFクラウドの不正アクセスとランサムウェア被害｜利用者の初動と別基盤への復旧手順](https://www.issoh.co.jp/tech/details/18199/)：委託先の基盤が止まったときに利用企業が取る初動
- [AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】](https://www.issoh.co.jp/tech/details/15888/)：文書から外した認証情報の移し先とローテーション
- [サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位](https://www.issoh.co.jp/column/details/13184/)：委託先を起点にした攻撃の全体像

---

出典: [ユニリタの不正アクセス：SaaS文書管理から漏れた顧客の認証情報と回す手順](<https://www.issoh.co.jp/tech/details/18213/>)（株式会社一創）