デジタル庁が運営委託を行っていたWebサイト制作プラットフォームのクラウドが第三者による不正アクセスを受け、登録者アカウントや外部サービスのAPIキー、顧客サイトのフォーム送信内容などが外部へ流出した可能性があることが報じられました。このセキュリティインシデントにより、多数の民間企業や自治体を含む広範な組織が影響を受け、公的機関への報告や対応に追われる事態となりました。被害を受けた組織や利用者に対しては、不審な連絡への警戒や、漏洩した可能性のある認証情報の更新などの対策が強く呼びかけられています。SaaSやクラウドサービスが提供する利便性の裏側に潜むセキュリティの盲点、今回被害が拡大した4つの原因、そして運用は委託できても、顧客データを預かる責任までは委譲できないことについて解説します。
1. セキュリティインシデントの全貌と問題提起
ノーコードWeb制作プラットフォームとして、デジタル庁を始め多くの企業・自治体に導入されているＳ社において、大規模な不正アクセスに伴う情報流出の可能性が表面化しました。現代のシステム設計において、開発スピードの加速や運用リソースの最適化を目的としたサードパーティSaaSおよびノーコード基盤の活用は不可欠な戦略的選択肢となっています。しかし本インシデントは、単一プラットフォームのセキュリティ不備にとどまらず、それを利用する企業、スタートアップ、そして行政機関を巻き込んだサプライチェーン全体のセキュリティリスク（サプライチェーン侵害）として、極めて重要な技術的・構造的教訓を突きつけています。クラウド基盤が提供する「開発の利便性」の裏側に潜むアーキテクチャ上の盲点を客観的かつ理論的に分析し、堅牢なシステム設計へと還元することがセキュリティアーキテクトに求められています。
インシデント概要と対応タイムラインの整理
本インシデントは、第三者がS社の提供する一部機能の脆弱性を悪用し、同社が運用するクラウド環境へ不正アクセスを実行したことに起因します。侵入者はクラウド環境内に格納されていた各種データおよび暗号化データの復号鍵へアクセスし、外部から取得可能な状態を形成していました。公表された一次情報および報道に基づく主要なタイムラインと影響規模は以下の通りです。
- 侵入発生期間: 2026年9月30日〜10月1日（日本時間）
- 社内検知: 2026年10月13日（社内調査により不正アクセスを確認）
- 封じ込め・修正対応: 2026年10月13日〜14日（脆弱性修正および侵入経路の遮断を完了。10月14日02:30頃に安全確保のため全ログインユーザーの強制ログアウトを実施、Googleスプレッドシート連携の接続鍵を無効化・更新）
- 第一報の公表: 2026年10月16日（10:11に公式Xおよび公式サイトにて発表。該当機能を利用するプロジェクトオーナーへ個別通知を送付）
- 暗号鍵刷新・PPC要請対応: 2026年10月17日（復号に必要な暗号鍵を新鍵へ刷新し、旧データの再暗号化を開始。同日、顧客企業に対し個人情報保護委員会（PPC）への個別報告の一時保留を案内）
本事案の影響スケールは、SaaSインシデントとしては国内最大級の範囲に及んでいます。S社が過去に公表したデータによると、全登録ユーザー数は推定90万人超、導入企業数は3万社以上に達しており、プラットフォームの仕様上、全登録顧客のアカウント情報および保存データが潜在的な流出対象となり得る状態でした。さらに、デジタル庁をはじめとする行政機関や地方自治体、上場企業、スタートアップなど、190を超える公表組織・自治体が自社Webサイトのフォーム送信データ等への影響を自力で調査・公表する事態へと拡大しました。
サプライチェーンリスクとしての問題提起
本インシデントの本質は、単一ベンダーの脆弱性問題にとどまらず、「利便性を追求して導入したノーコード/SaaS基盤の構造的欠陥が、利用企業のサプライチェーン全体を揺るがした象徴的事例」である点にあります。自社のコアインフラやWebサーバーが直接攻撃を受けていなくとも、フロントエンドやマーケティング用途で組み込んだ外部SaaSが侵害されれば、そこに蓄積された顧客の個人情報やサードパーティAPIの認証情報が一挙に危態化します。
クラウド基盤の利便性の裏に潜むこのような構造的脆弱性を正しく評価するため、次節では侵入から表面化に至る時系列のメカニズムと、被害が広範囲へ波及した構造的要因について深掘りしていきます。
2. タイムラインと被害拡大のメカニズム
本インシデントにおいて被害拡大の一因となった構造的要素の一つが、攻撃の発生（9月30日〜10月1日）から社内検知（10月13日）に至るまでに発生した約2週間のタイムラグ（潜伏期間）です。この期間中、クラウド環境内の機密データが外部から取得可能な状態に置かれ続けたことが、二次被害リスクの高まりと顧客企業による公表・調査対応の遅れを引き起こしました。
詳細タイムライン
| 年月日 / 時間 | 発生事象・対応内容 |
| 2026年9月30日〜10月1日 | 第三者がS社の一部機能の脆弱性を悪用し、クラウド環境へ不正アクセスを実行。環境内の機密データが外部から取得可能な状態となる。 |
| 2026年10月13日 | 社内調査により不正アクセスを検知。脆弱性の修正および侵入経路の遮断対応を開始。 |
| 2026年10月14日（02:30頃） | 脆弱性修正と経路遮断を完了。全ログインユーザーの強制ログアウトを実施し、流出した可能性のあるGoogleスプレッドシート連携の接続鍵を更新・無効化。 |
| 2026年10月16日（10:11頃） | 公式Webサイトおよび公式Xにて第一報「不正アクセスによる情報流出に関するお詫びとお願い」を公表。利用機能に応じた個別メールを送付。顧客企業による自主公表が相次いで開始。 |
| 2026年10月17日 | フォーム送信内容やAPIキー等を暗号化する暗号鍵を新鍵へ刷新。旧鍵データの再暗号化を開始。PPC（個人情報保護委員会）からの要請を受け、顧客企業へ個別PPC報告の一時保留を依頼。 |
| 2026年10月20日 | PPCとの協議完了に伴い、顧客企業に対し個別のPPC報告、またはS社が取りまとめる「連名報告（Joint Report）」の選択肢を提供開始。 |
主要顧客および影響の波及範囲の分析
S社のプラットフォーム上で作成された問い合わせフォームやAPI連携機能が侵害されたことで、極めて広範な組織において自社顧客データの漏洩リスクが開示されました。
- デジタル庁: 最大13,323件のフォーム送信データ（一般的なご意見・ご要望: 最大8,833件、COVID-19接種証明書アプリ問い合わせ: 3,661件、ワークショップ等: 462件、採用関連: 250件、マイナちゃん着ぐるみ借用問い合わせ: 117件）および職員・委託従事者のS社アカウント35件（対象期間：2021年5月〜2023年3月）
- LUUP: 21,368件（ポート設置リクエスト、道路交通法改正に関する問い合わせ等の旧Webフォーム送信データ）
- Ubie: 最大16,005件（コーポレートサイト等の問い合わせフォームデータ）
- Voicy: 15,088件（パーソナリティ応募フォーム等の送信情報）
- クラウドワークス: 12,131件（設置された4つのフォーム合計）
- Link-Uグループ: 7,663件（グループコーポレートサイトの問い合わせフォーム）
- ラクスル: 6,412件（サービス情報サイトの見積もり・問い合わせフォーム等）
これらの行政機関や大手スタートアップが相次いで被害に巻き込まれた背景には、フロントエンドのWeb制作やマーケティングページの構築をSaaSに依存し、フォーム送信データがプラットフォーム側のストレージに暗黙的に蓄積され続けていた運用構造が存在します。
認証情報流出による実被害の証拠：Finatextホールディングスのケース
本インシデントの影響は、S社内にデータを直接保存していなかった企業にも及びました。金融ITを展開するFinatextホールディングスは、S社のデータベース上にはフォーム回答データを保存しない運用をとっていましたが、外部連携機能としてGoogleスプレッドシート連携（全7,241件）を利用していました。 アクセスログの解析結果によると、S社側から漏洩した連携認証情報を悪用し、第三者が同社のGoogleスプレッドシートへ直接アクセスを実行。全データのうち最大約18%のデータが不正に閲覧されたことが実証されました。これは単なる「潜在的な流出リスク」にとどまらず、SaaS側で保持されていたサードパーティ認証情報が奪取され、二次被害としての外部システム侵害が現実化したことを示す強固な技術的証拠です。
個人情報保護委員会「連名報告（Joint Report）」の特例措置と責任の分断
法的な報告プロセスにおいては、10月20日に個人情報保護委員会（PPC：Personal Information Protection Commission）との協議により提示された「連名報告」が大きな注目を集めました。通常、個人情報保護法に基づく漏洩報告は各事業者が個別に行う必要がありますが、本件ではプラットフォーム侵害に伴う大量報告の混乱を避けるため、本件に限り速報期限を過ぎても遅延として扱わない特例措置が適用されました。 しかし、連名報告によって取りまとめられるのは「行政機関（PPC）への報告」のみであり、影響を受けたエンドユーザー（本人）に対する通知責任や公表対応は免除されず、各利用企業の個別の責務として残るという責任の分断構造が明確になりました。
被害が表面化したプロセスと法制度上の複雑さを整理したところで、次節では本インシデントにおいて被害を壊滅的な規模へと拡大させたシステムアーキテクチャ上の4つの根本原因について深掘りしていきます。
3. 被害を拡大させた4つの根本原因について
セキュリティアーキテクチャの観点から本事案を紐解くと、暗号鍵管理、権限設計、データライフサイクル、マルチテナント隔離の4領域において重大な設計上の欠陥が存在していたことが分かります。プラットフォーム内部で何が発生していたのか、技術的・構造的観点からその根本原因を評価します。
原因1：暗号化と復号鍵の同一環境保管（「鍵の同居」問題）
S社では、顧客が入力したフォームデータや外部APIキーなどの機密情報をデータストアに保管する際、暗号化処理（At-Rest Encryption）を施していました。しかしながら、攻撃者がクラウド環境へ侵入した際、暗号化データストアのみならず「復号に必要な暗号鍵」も同一の実行環境・権限境界内から同時に読み出されたという致命的な構造的欠陥が存在していました。
多くのクラウド設計において、ストレージやデータベースの標準暗号化機能のみに頼り、「静止データの暗号化（Encryption At-Rest）」を行っていることで安全であると誤認されるケースが後を絶ちません。しかし、アプリケーションが稼働する実行環境（In-Use）や権限境界内に平文の復号鍵が存在、あるいは容易にアクセスできる状態であれば、実行環境自体が侵害（Runtime Compromise）された際に暗号データと復号鍵が同時に持ち出されます。これにより、暗号化による多層防御機能は完全に無力化されました。
【「鍵の同居」による暗号化無力化の構造】
[ 攻撃者の侵入 ] ──> [ アプリ実行環境 / クラウド環境 ]
│
├──> [ 暗号化データストア ] (暗号化データ取得)
│
└──> [ 同一環境内の鍵ストア/メモリ ] (復号鍵取得)
│
└─> 【結果】平文化（暗号化の無意味化）
原因2：外部連携トークン・APIキーの過大権限設計
流出した情報の対象範囲は、ユーザーのアカウント情報（ユーザー名、メールアドレス、ハッシュ化パスワード）やフォーム送信内容にとどまらず、システム連携のために保持されていた高度な各種技術情報・認証情報に及んでいます。
- サードパーティ認証情報: 外部サービスのAPIキー・トークン（Headless CMS連携等）、Googleスプレッドシート連携認証情報、カスタムプロキシキー、Slack等のWebhook URL
- システム保護・検証情報: Google reCAPTCHA v3の設定情報、パスワード保護ページのハッシュ化パスワード
- 未公開コンテンツ情報: 公開前ページを閲覧可能にするライブプレビューURL（知られていれば誰でも未公開コンテンツを閲覧可能な状態となるリスク）
- 非会員を含む個人情報: S社のAI（旧Auto）先行利用申込者（2022年12月〜2023年8月）のメールアドレス・ユーザー名・居住国データ（S社のアカウント未作成者も含む）
特に深刻な設計ミスは、奪取されたGoogleスプレッドシートやAPI連携の認証情報に本来不要な「書き換え権限（Write Permissions）」まで付与されていた点です。実際のログ解析ではS社内部データの改ざん・削除ログは確認されなかったものの、Finatextの事例が示す通り、攻撃者は連携先の外部ストレージやCRMに対してデータを改ざん・消去できる広大な「被害影響半径（Blast Radius）」を保持していました。最小権限の原則（PoLP: Principle of Least Privilege）が未適用であったことが被害潜在リスクを膨らませました。
原因3：データ最小化原則（Data Minimization）の欠如と放置データ
データライフサイクル管理において、「不必要なデータをシステム内に残さない」というデータ最小化原則が機能していなかったことも、波及被害を拡大させた大きな主因です。プラットフォーム上に、過去の不要なデータが削除されずに長期間放置されていました。
本インシデントにおける具象例として、デジタル庁では侵害発生から3年以上前である2021年5月〜2023年3月の過去データ（最大13,323件）がDB内に残存しており、LUUPにおいても2022年時点の旧フォーム回答データが保存され続けていました。 一方で、S社の仕様上、「9月30日以前にダッシュボードから完全に削除されていたデータ」や「フォーム結果の保存機能を最初から無効化していたデータ」は今回の侵害対象から除外されました。この対比は、「削除されずにDBへ放置されたデータは、将来の侵害事故においてすべて攻撃者のリスク資産（標的）へ変貌する」という残酷な現実を論理的に実証しています。
原因4：ID管理とマルチテナント隔離境界の不備
マルチテナントWebアプリケーションにおける最重要防壁は、テナント間の論理的・物理的な隔離境界（Tenant Isolation）です。しかし本事案では、S社の一部機能に存在した単一の脆弱性（Exploit Public-Facing Application）から侵入を許した結果、プラットフォーム全体および全顧客のマルチテナントデータへのアクセスが網羅的に可能となりました。
単一のアプリケーション層の欠陥から、インフラ権限の水平昇格（Lateral Movement）を許し、テナント境界を越えて全顧客データの一括取得へ波及したことは、クラウドセキュリティにおける「多層防御（Depth in Defense）」および「ゼロトラストアーキテクチャ（Zero Trust Architecture）」の境界設計が崩壊していたことを意味します。
これら4つの根本原因から得られた強烈な反省材料をベースに、次にプロダクト開発者やSRE、インフラ・セキュリティエンジニアが自社システムへ即座に適用すべき具体的なアーキテクチャパターンを提示します。
4. エンジニア・プロダクトマネージャーが実践すべきアーキテクチャと実装の教訓
S社の事案を他山の石とし、エンジニア、SRE、プロダクトマネージャー、Webディレクター、インフラ・セキュリティエンジニアは、自社プロダクトのアーキテクチャ設計および外部SaaSの選定・運用において、即座に以下のセキュリティパターンを実装する必要があります。
教訓1：暗号鍵の物理・権限隔離（KMS/HSMとエンベロープ暗号化）
データストアの静的暗号化だけに頼らず、鍵管理サービス（AWS KMS、GCP KMS、Azure Key Vault等）を活用し、暗号鍵のライフサイクルと権限をアプリケーション実行環境から物理的・論理的に完全隔離します。
具体的には、データ自体をデータ暗号化鍵（DEK: Data Encryption Key）で暗号化し、そのDEKをKMS内部のマスターキー（CMK: Customer Master Key）で暗号化して保管する「エンベロープ暗号化（Envelope Encryption）」を実装します。アプリケーション実行環境（ECS/EKS、EC2、Cloud Run等）に与えるIAMロールには、kms:GenerateDataKeyやkms:DecryptのAPI実行権限のみを許可し、マスターキーそのものを外部へ抽出（Export）できない仕様とします。
【推奨されるKMSエンベロープ暗号化アーキテクチャ】
[ アプリケーション実行環境 ] [ 専用 KMS / HSM ]
(IAM Role: Decrypt権限のみ) (マスターキー CMK を保持)
│ │
│ 1. 暗号化されたDEKを送信 │ ※ CMKはKMS外部へ
├──────────────────────>│ 物理的に抽出不可
│ 2. KMS内部でCMKを用いてDEKを復号 │
│<──────────────────────┤
│ │
│ 3. 平文DEKをメモリ上でのみ一時保持 └─ 監査ログ(CloudTrail等)に
├─> [データ復号処理] アクセス履歴を全件記録
└─> 完了後、平文DEKを即座にメモリ消去
この構成により、万が一アプリケーション実行環境がRCE（リモートコード実行）等で完全に侵害された場合でも、攻撃者はKMS APIを介した個別の復号リクエストしか行えず、暗号鍵自体の大量引き抜きや一括平文データベースダンプの作成を遮断（Blast Radiusの限定）できます。
教訓2：最小権限の原則（PoLP）に基づくAPIトークン設計
サードパーティ連携において発行する認証情報・APIキーは、必要最少限のスコープに制限し、被害発生時の影響を最小化します。
- Read-Only Scopeの徹底: 外部サービスへ付与するAPIトークンには、更新・削除権限（
write,delete）を排し、閲覧権限（read-only）のみを割り当てます。Google Sheets連携等においてはOAuth 2.0スコープをhttps://www.googleapis.com/auth/spreadsheets.readonlyに制限します。 - 短寿命トークン（Short-lived Tokens）とSTS/OIDCの活用: 永続的な静的APIキーの保持を廃止し、有効期限が数分〜数時間程度の短寿命トークン（AWS STSやGCP Workload Identity）へ移行します。
- 自動ローテーション機構: 外部連携キーの定期的かつ非破壊的な自動ローテーション（Secrets Manager連携等）をパイプライン化します。
教訓3：「個人情報をDBに残さない」セキュアなフォーム設計
ノーコードCMSやWebサイト制作基盤の内部データベースに個人情報を蓄積させない「ステートレス・フォーム」パターンを採用します。
- 即時パージ（Stateless Delivery）: Webフォームが受け取った入力データは、DBへ永続化せずにメモリ上で暗号化し、即座に目的のCRM（HubSpot、Salesforce等）や内部バックエンドへSecure HTTPS API経由で転送します。受領応答（HTTP 200 OK）を確認後、Webサーバー側のローカルストレージおよびDBから即座にデータをパージ（消去）します。
- 責務分離: 汎用CMSプラットフォームに個人情報管理の責務を持たせず、高度なセキュリティガバナンスが担保された専用フォームサービスやHubSpot / Googleフォーム等を埋め込み利用する構成へ分離します。
教訓4：データライフサイクル管理（TTL・自動パージポリシー）
データ最小化原則を人間系の運用に頼らず、データベースおよびストレージエンジンの標準機能を用いて機械的・自動的に実行します。
- DynamoDB TTL属性 / MongoDB TTLインデックス: レコードごとに
ttlタイムスタンプ（例: 作成日時 + 30日）を付与し、DBエンジン側に自動バックグラウンド削除を行わせます。 - Amazon S3 Lifecycle Rule: フォーム添付ファイル等のオブジェクトストレージに対し、30日経過後の自動削除ルールを設定します。
- Scheduled Event (Lambda/Cron): 期限切れデータを物理削除する自動パージスクリプトを定期実行します。
以下は、システム内に適用すべきデータパージポリシーの環境定義構文例（設計メモレベル）です。
{
"PolicyName": "FormSubmissionDataMinimizationPolicy",
"Version": "2026-11-01",
"TargetResource": "FormSubmissions",
"DataRetentionRules": {
"RetentionPeriodDays": 30,
"ActionOnExpiry": "PERMANENT_HARD_DELETE",
"Scope": "AllCompletedSubmissions",
"ExclusionFilter": "MarkedForLegalHold == true"
},
"AutomationEngine": {
"Type": "DynamoDB_TTL_Or_ScheduledLambda",
"ScheduleCron": "0 2 * * ? *",
"ExecutionTimeoutSeconds": 300
},
"AuditLogging": {
"Enabled": true,
"Destination": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/sp/security-audit"
}
}
技術的な教訓の実装論を整理した上で、最終節ではSaaS利用における組織的ガバナンスと責任共有モデルの本質について総括します。
5. まとめ：利便性とセキュリティのトレードオフを超えて
ノーコードプラットフォームやサードパーティSaaSの導入は、開発スピードの爆発的な向上とエンジニアリングリソースの最適化をもたらします。しかし、外部サービスを利用することでベンダーへ委譲されるのは「システム運用の労力」であり、顧客データを預かる事業者としての「法的責任および社会的責任」まで委譲されるわけではありません。
責任共有モデル（Shared Responsibility Model）の再確認
クラウドセキュリティにおける責任共有モデルの観点から、SaaSを利用する企業側も「プラットフォーム側が安全を担保している」という盲目的な前提を排除しなければなりません。「何を預け、どのように連携し、万が一の侵害事故の際にどう自社影響を局限化するか」という当事者意識（データ保持・運用の自己責任）をシステム構成レベルで表現することが求められます。
自社システムおよび利用SaaSのセキュリティ健全性評価チェックリスト
エンジニア、SRE、Webディレクターが自律的に自社環境や利用SaaSの健全性を評価するためのチェックリストを以下に提示します。
- APIキー・トークンの権限スコープ制限: 外部SaaSやAPI連携に発行している認証情報に、不要な書き込み（Write）や削除（Delete）権限が含まれず、閲覧（Read-Only）に限定されているか。
- 保管データの自動消去（TTL）設定: データベースやストレージ内に過去の不要データやテストデータが残存しておらず、TTLや自動パージルールにより機械的に削除されているか。
- 暗号鍵の物理・権限隔離（KMS分離）: 自社開発システムにおいて暗号化データと復号鍵が同一環境に「同居」しておらず、KMS/HSMを用いてアプリケーション権限から鍵の抽出が不可能な設計になっているか。
- フォーム運用のステートレス化検討: SaaS/ノーコードツールのフォーム機能を利用する際、プラットフォーム側DBへのデータ保存をオフにし、専用CRMへの即時転送・パージ構造が取られているか。
- 緊急時の全鍵一括ローテーション体制: 利用中のサードパーティSaaSで侵害が発生した際、連携中のAPIキー、Webhook、OAuthトークンを数時間以内に全件再発行・即時無効化できる運用台帳と手順が確立されているか。
開発スピードとセキュリティは二者択一のトレードオフではありません。構造的なアーキテクチャ見直しとデータ最小化をDevSecOpsのプロセスとして組み込み続けることこそが、デジタル社会における顧客の信頼に応えるプロフェッショナルなエンジニアリングのあり方です。
今回はSaaSサービスですが、SCSKでは、フロンティアAI時代においてはゼロトラストの原則である「侵入は避けられない（Assume Breach）」を前提としたサイバーレジリエンスが重要だと考えています。フロンティアAIレディの「3層防御モデル」、境界型防御が破綻した今、「多層防御（Depth in Defense）」と「ゼロトラストアーキテクチャ（Zero Trust Architecture）」の実装が必須となっています。特にランサムウェア被害で大きな課題となっているラテラルムーブメント（横移動）を阻止する具体的なソリューションとして 次世代マイクロセグメンテーション Zero Networks をお勧めしております。
すでに多くの引き合いをいただいておりますが、Zero Networks に興味をもたれた方は、ぜひ当社までお問い合わせください。
最後に、2026年11月11日 今回ご紹介した Zero Networks とマイクロセグメンテーションと組み合わせることで完全なゼロトラストを実現する SASE（Secure Access Service Edge、サッシー）、これまでのウィルス対策ソフト・EDRと異なり、AI ディープラーニング（深層学習）にて非常に高い検知率を誇る次世代エンドポイントソリューション、そして攻撃者が侵入後に真っ先に狙うバックアップデータを保護し、確実な復旧を実現するためのゼロトラストデータ保護ソリューションなど、多層防御とゼロトラストを実現する4つのベスト・オブ・ブリードのセキュリティソリューションをご紹介するオンラインセミナー（無料）を開催しますので、ぜひご参加ください。
最後までお読みいただき、ありがとうございました。