>
>
公開日
サードパーティ製アプリの棚卸しを担当する情シス向けに、ConnectWise Cloud Backup事案で示された連携アプリの停止・再認可・ログ調査の論点と、Microsoft 365／Entra ID、Google Workspaceで管理する台帳項目を整理します。
サードパーティ製アプリの棚卸しとは
サードパーティ製アプリの棚卸しとは、自社テナントに許可した連携アプリの権限・管理者・利用目的・停止手順を一覧にする作業です。
情報の基準日：2026年10月30日
本記事のポイント
棚卸しの対象は許可済みの連携アプリです。
権限と利用目的を対にして記録します。
事故時の停止担当者と手順を台帳に残します。
対象読者は、企業の情報システム部門（情シス）の担当者・管理者です。契約やライセンスの費用削減、物品の在庫管理ではなく、事故時に何を誰が止めるかを特定するために整理します。対象には、アクセス権限を許可してサービスをつなぐOAuth連携も含めます。
ConnectWiseは2026年10月に、Cloud Backup（旧SkyKick）に関連するアプリケーション資格情報への不正アクセスを公表し、影響する接続を無効のまま維持すること、復旧時には新しいアプリを用いた再認可が必要になる旨を案内しています。本記事では、この公表内容を特定事案の前提としつつ、個別のテナントで必要になる停止・調査・再認可の判断を台帳で管理する方法を扱います。
ConnectWise Cloud Backupの事案と対応の時系列
ConnectWise Cloud Backup（旧SkyKick）の事案は、経過とベンダーが案内した対応を分け、サービス停止・アプリ無効化・再認可・調査を別々に整理することで把握します。
ConnectWiseの「Product and Services Status」とTrust Centerの案内では、Cloud Backupに関連するアプリケーション資格情報への不正アクセスを受け、影響するアプリケーション接続を無効のまま維持するよう案内しています。Cloud Backupだけでなく、同製品と統合されるSaaS SecurityおよびCloud Managementについても、同社は予防措置として提供を停止したと公表しています。
時系列は、ベンダーの公表日時と自社テナントで実施した操作日時を同じ表に混在させず、UTCと日本時間のどちらで記録したかを明示します。ConnectWiseの公表内容と、自社で確認したテナント内の変更・ログ・業務影響は別の記録として保持します。
発生・公表日時 | 発信元 | 確認された内容 | 顧客側の対応 |
|---|---|---|---|
2026年10月16日 17:47 UTC | ConnectWise | Trust Centerにアドバイザリの初版を掲載しました。Cloud Backupのバックアップと復元が止まっています。 | 自社がCloud Backup（旧SkyKick）を使っているかを、連携台帳と契約で確かめます。 |
2026年10月16日 | Huntress | 10月16日19:00 UTC時点で、162テナントで不正なサインインを確認したと公表しました。悪用された資格情報はベンダー側のテナントにあると説明しています。 | サービスプリンシパルのサインインログと監査ログを、消える前に保存します。 |
2026年10月17日 | ConnectWise | ConnectWiseは、Cloud Backupに関連するアプリケーション資格情報への不正アクセスへの保護措置として、複数のアプリケーションIDを無効化したと公表しています。 | 自社の連携台帳で対象アプリの識別情報を照合し、一致する接続はベンダーの復旧案内が出るまで無効状態を維持します。 |
2026年10月17日以降 | ConnectWise | ConnectWiseは、Cloud Backupと統合されるSaaS Security、Cloud Managementを予防措置として停止したと案内しています。 | バックアップ、監視、利用者・ライセンス管理のどの業務が停止対象となるかを分け、代替手段と復旧優先度を記録します。 |
2026年10月28日から | ConnectWise | ConnectWiseは、Microsoft 365のバックアップと復元から段階的な復旧を始め、新しい「ConnectWise Cloud Backup for M365」アプリで各テナントを再認可するよう案内しています。 | 再認可の前に対象テナント、実行者、必要な権限、業務再開の承認者を台帳で特定します。 |
2026年10月29日 20:45 UTC（日本時間10月30日 5:45） | ConnectWise | アドバイザリを更新し、再認可は調査手順の代わりにならないこと、正規の資格情報に替えても攻撃者が追加した資格情報・ロール・同意は消えないことを明記しました。 | 再認可と調査を別の作業として記録し、追加された資格情報・ロール・同意を確かめます。 |
ConnectWiseは、同社の調査だけでは個別のパートナー・顧客のMicrosoft 365テナントに不正な活動があったかを判定できないと説明しています。そのため、ベンダー側の復旧案内と、自社テナントに対するログ調査は並行して管理します。
再認可を調査完了の根拠にはしません。初期侵入経路、国内被害、メール閲覧やデータ持ち出しの有無は推測せず、ログ確認で把握できた操作と確認できた期間を記録します。サードパーティ製アプリの棚卸しでは、停止・再認可の状態と調査状況を別項目にすることで、業務再開と安全性の確認を混同せずに管理できます。
顧客側の操作なしに悪用される連携の信頼関係
サードパーティ製アプリの棚卸しでは、アプリ自身の認証に使う資格情報の管理場所と、顧客テナントに残る同意を分けて整理します。利用者のログイン管理だけで連携の安全性を判断せず、アプリ側の認証と顧客側の権限を別の確認対象にします。
Huntressの調査によると、悪用された資格情報はクライアントアサーションと呼ばれる種類で、ベンダー自身のテナントにありました。同社は、顧客が自社の環境で行った操作からこの資格情報が生まれることはないとし、アプリが同意されたすべてのテナントで使える状態だったと説明しています。Huntressは、10月16日19:00 UTC時点で162テナントの不正なサインインを確認しました。10月17日の追記では、攻撃元からのサインイン試行は約1,000テナント、成功は300テナント超としています。
Huntressの観測では、約50テナントでConnectWiseのサービスプリンシパルが自分自身にディレクトリロールを割り当てていました。1テナントではGlobal Administratorの付与と、別のアプリへのシークレットの追加もありました。Kudelski Securityも、資格情報はベンダーのテナントにあり、顧客側で資格情報を更新しても解決しないと説明しています。
Microsoft Learnの説明では、アプリケーションオブジェクト（アプリ登録）と資格情報は、アプリを登録したホームテナントに1つだけあります。アプリに同意した各テナントには、サービスプリンシパルが作られます。台帳では、アプリ登録に関する情報と、テナント内のエンタープライズアプリケーションまたはサービスプリンシパルに関する情報を別々の行または別列で記録します。
連携アプリの台帳では、管理画面に表示されるアプリ名、アプリケーションID、オブジェクトID、発行元、付与権限、同意の種類、利用部門を対応付けます。認可イベントの日付は同意または設定変更の履歴であり、アプリが現在も業務で利用されていることを単独で示す情報としては扱いません。
資格情報の管理主体が分かる場合は、その主体をアプリ側の確認先として記録します。
顧客側に認可が見つかった場合は、付与権限と付与ユーザーを記録し、利用者の資格情報変更だけを対応完了の条件にしません。
OAuthの基礎はSAMLとOAuthの違い、攻撃全体の背景はサプライチェーン攻撃の解説で扱っています。
▲ アプリ自身の認証情報と顧客テナントに残る同意関係を分けて管理する構成。
該当アプリ利用時のログ調査と停止対応
該当アプリへの対応は、サインインの停止、証拠の保持、アクセスを維持するための変更の調査、サービス再認可を分けて管理します。サードパーティ製アプリの棚卸しで対象が見つかっても、削除と再認可を一続きの操作にしない運用にします。
対象アプリと記録の特定
対象は表示名だけで判断せず、アプリの識別情報と利用環境を突き合わせて特定します。
対象候補が見つかった場合は、アプリケーションID、テナント内の対象オブジェクト、付与権限、業務担当者を対応記録にまとめます。
ConnectWiseの案内は同社が指定する停止対象・復旧条件を確認する資料として、Huntressの案内は同社が公表する調査対象・調査観点を確認する資料として、別々に管理します。ConnectWiseの案内に記載された対象アプリ、対象テナント、再認可に用いるアプリ名を台帳の識別情報と照合できれば、その行を対応対象とします。一致しない場合は候補として記録し、表示名だけを根拠に停止しません。
サインインと変更履歴の調査
調査は通常のユーザーのサインインだけで終えず、アプリ側の認証記録と権限・設定の変更履歴まで対象にします。
Microsoft Learnの「Service principal sign-in logs」は、サービスプリンシパルのサインインがユーザーを介さないアプリやサービスプリンシパルによる認証であることを説明しています。Microsoft Entra管理センターで取得できるログの開始日・終了日を対応記録に残し、対象アプリの識別情報、IPアドレス、リソース、成否、時刻を確認します。必要な期間のログを取得できればその範囲を調査し、保持範囲より前の活動を判定できない場合は、調査範囲の外として切り分けます。
Microsoft Learnの「View Activity logs of application permissions」では、Entra IDのエンタープライズアプリケーションから監査ログを開き、アプリ権限の付与・取り消しに関するイベントを確認する手順を案内しています。追加調査では、エンタープライズアプリケーションとアプリ登録について、追加された資格情報、ディレクトリロール、追加同意を確認対象にします。資格情報はアプリの認証に使う秘密情報や証明書、ディレクトリロールは管理操作の権限です。メール転送と受信トレイルールも対象に含めますが、本事案で悪用されたという意味ではありません。
停止状態と再認可の管理
停止操作は対象と目的を記録し、再認可は調査とは別の承認作業として扱います。
操作 | 対象と目的 | 判断条件 |
|---|---|---|
無効化 | 対象アプリのサインインを止めるための操作です。 | ConnectWiseの案内で対象アプリと停止条件が一致すれば、対象・実行者・実施時刻を記録して無効化します。一致しなければ候補として隔離し、識別情報の照合を続けます。 |
同意の取り消し | アプリへ付与した権限を撤回するための操作です。 | 付与権限と承認経緯を保存したうえで、停止指示と調査結果から実施対象を判断します。 |
削除 | 対象オブジェクトを除去するための操作です。 | 初動では削除前の設定・識別情報・ログを保存し、復旧手順や調査記録に必要な情報を保持できた段階で判断します。 |
再認可 | サービス利用に必要な権限を改めて承認する操作です。 | ConnectWiseの案内で対象と復旧条件を確認できた場合に、社内承認を経て進めます。旧アプリの再有効化とは分けます。 |
ConnectWiseは、以前に発行されたアクセストークンが、有効期限を迎えるか別途無効化されるまで利用可能な場合があると案内しています。そのため、無効化や同意の取り消しを実施した時刻と、停止後に確認したアクセス記録を別々に残します。
対象特定：識別情報が一致すれば対応対象にし、一致しなければ候補として保留します。
ログ保存：取得できれば期間と取得日時を記録して保存し、保持期間外は調査範囲から分けて記録します。
指定に沿った停止：正式な指示と対象が一致すれば実施し、一致しなければ社内の緊急対応責任者へ判断を引き継ぎます。
追加変更の調査：不審な変更があれば関連する主体や操作へ調査を広げ、見つからなければ調べた範囲を記録します。
調査結果の記録：停止状態、確認済み事項、調査範囲、再認可の承認状況を分けて残し、残作業には担当者を割り当てます。
▲ 該当アプリ利用時における停止対応と調査の実施手順。
Entra IDとGoogle Workspaceの連携アプリ台帳
サードパーティ製アプリの棚卸しでは、許可済みアプリの一覧に権限・社内管理者・利用目的・停止手順を結び付け、継続と停止を判断できる台帳を作ります。特定のアプリを利用しているかどうかにかかわらず、Entra IDとGoogle Workspaceを同じ記録軸で整理し、管理画面から得る技術情報と、社内への聞き取りで補う業務情報を分けます。
確認画面と操作範囲の比較
両環境は、アプリ・権限・利用者を共通の確認軸にし、制御操作だけを環境別に記録します。名称が似ている設定でも、同じ範囲に作用すると判断してはいけません。
台帳へ転記する画面名、権限、利用者、認可履歴は、各管理画面とMicrosoft Learn、Google Workspace管理者ヘルプの表示を基準にします。
対象・提供状況：Microsoft Entra IDでは、Microsoft Learnの「View Activity logs of application permissions」に従い、Entra ID > Enterprise apps > Activity > Audit logsから、アプリ権限の付与・取り消しに関する監査イベントを確認できます。Google Workspaceでは、管理コンソールのAPI controlsでサードパーティ製アプリのアクセスを管理します。利用可能な項目、表示までの時間、組織部門またはグループごとの適用範囲は、管理コンソールの対象設定画面で確認します。
環境 | 確認画面 | 権限の確認対象 | 制御操作 | 社内で補う情報 |
|---|---|---|---|---|
Microsoft 365／Entra ID | Microsoft Entra管理センターのEntra ID > Enterprise appsで対象アプリを開き、Activity > Audit logsで権限付与・取り消しの履歴を確認します。 | 付与権限と付与対象を記録し、管理者による同意とユーザーによる同意を区別する欄を設けます。 | 無効化、同意の取り消し、削除は別の操作として記録します。対象オブジェクト、操作担当者、操作時刻、業務影響を同じ行に残します。 | 社内管理者、利用目的、依存業務、停止の承認者を聞き取ります。 |
Google Workspace | Google管理コンソールのSecurity > Access and data control > API controlsで、サードパーティ製アプリのアクセス管理を確認します。 | 表示されるアプリ、OAuthスコープ、利用者または適用対象を記録対象にします。 | 信頼・制限・ブロックなどの設定は、管理画面に表示された設定名のまま制御内容として記録し、各設定が作用するサービスと適用対象も同じ行に残します。 | 社内管理者、利用目的、依存業務、停止の承認者を聞き取ります。 |
Entra IDの確認項目
Entra IDでは、対象アプリの権限情報と同意の種類を別々に記録し、誰に影響する変更なのかを整理します。管理者の同意とユーザーの同意を一つの「許可済み」欄にまとめない構成にします。
管理画面から情報を取得できる場合は、表示された権限名、付与対象、同意の区分を転記します。区分を表示から判別できない場合は、管理者の同意だと推測して埋めず、追加調査の対象として担当者と確認先を記録します。また、アプリ上の管理情報とは別に、社内で利用判断と停止連絡を担う人を特定します。
Microsoft Learnの「アプリケーションに付与されたアクセス許可を確認する」では、Microsoft Entra管理センターのエンタープライズ アプリケーションで対象アプリを開き、「アクセス許可」の「管理者の同意」と「ユーザーの同意」のタブから、付与済みの権限を確認・取り消しできると説明しています。ユーザーの同意はポータルからは取り消せず、PowerShellかMicrosoft Graphを使います。権限を取り消しても、利用者が再び同意することは防げません。
停止を検討する場合は、「どの同意・権限を対象にするか」「誰が操作するか」「どの業務への影響を調べるか」を記録します。対象を切り分けられない場合は、調査担当と期限を決めます。
Google Workspaceの確認項目
Google Workspaceでは、アプリとOAuthスコープを対応付け、Entra IDの同意区分とは分けて整理します。共通台帳を使う場合でも、異なる管理方式を同じ名称に置き換えません。
取得したスコープ情報は原文を残し、社内への聞き取りで「そのアクセス範囲を何の業務に使うか」を補います。権限の情報だけでは利用目的を説明できない場合は、利用部門への調査対象にします。アプリ名が一致するという理由だけで、用途まで同一と判断しない運用にします。
信頼・制限・ブロックの設定を台帳に記録する場合は、設定名と適用対象を別欄に残します。管理コンソールで設定の適用対象と既存の認可への影響を確かめてから、停止手順へ転記します。Entra IDの管理者同意・ユーザー同意という区分が適用されない記録には「対象外」を使い、不明を意味する空欄と区別します。
台帳と判断の記録
台帳は、技術情報と業務情報を結び付ける8項目を基本にし、判断履歴を追記できる形にします。次のテンプレートをアプリごとにコピーすれば、取得できた情報と聞き取りが必要な情報を分けて管理できます。
項目 | 取得・確認先 | 記入欄 |
|---|---|---|
アプリ名 | 管理画面 | ［表示名を記入］ |
発行元 | 取得したアプリ情報 | ［発行元／未取得］ |
付与された権限 | 管理画面 | ［権限名・スコープ・付与対象］ |
同意の種類 | 環境別の同意情報 | ［管理者の同意／ユーザーの同意／対象外／調査中］ |
社内の管理者 | 利用部門への聞き取り | ［氏名または担当部署・連絡先］ |
利用目的 | 利用部門への聞き取り | ［業務名・必要な連携内容］ |
最終利用 | 取得可能な利用記録・聞き取り | ［日時・情報源／未取得］ |
止めるときの手順 | 技術担当と利用部門の調整 | ［対象・操作担当・承認者・影響確認・復旧方法］ |
空欄は未利用の証拠にしません。利用記録を取得できなければ「未取得」とし、聞き取りで補った場合は、その情報源も残します。
利用目的と社内管理者を特定できた場合は、付与権限と業務上の必要性を照らし合わせ、継続判断へ進みます。
どちらかを特定できない場合は、未利用と決めず、影響調査の担当者・期限・調査先を判断欄に記録します。
停止対象を決めた場合は、対象権限、実行担当、承認、停止後の業務確認を記録してから操作へ進みます。
委託先が管理や運用に関わる場合は、委託先台帳の該当記録と関連付け、問い合わせ先と役割分担を残します。この台帳で停止候補と担当者を特定できれば、個別の停止対応に進む際にも判断の根拠を引き継げます。
▲ Entra IDとGoogle Workspaceにおける連携アプリ台帳の確認項目の比較。
マネーフォワード Adminaで補える範囲
マネーフォワード Adminaは、Google WorkspaceやMicrosoft 365／Entra IDと連携すると、社員が会社アカウントのGoogleログイン・Microsoftログインで使っているSaaSをシャドーITとして検知し、サービスごとの利用者と最終アクセスを一覧で確認できます。Microsoft側の検知には、Entra ID P1またはP2のライセンスが必要です。Entra IDに登録したSSOアプリは、ユーザーの割り当てと解除をAdminaから操作できます。
OAuthアプリに付与した権限の確認と取り消しは、Microsoft Entra管理センターやGoogle管理コンソールで行います。台帳の「利用者」「最終利用」を埋める材料としてどこまで使えるかは、デモで自社の環境に合わせて確認できます。
同意の入口と高権限アプリの継続管理
サードパーティ製アプリの棚卸しでは、新規同意の制御と既存アプリの権限レビューを別の作業として管理します。新たな連携を受け付ける条件、現在の権限を継続する判断、その判断に責任を持つ担当者を分けて設計します。
新規同意の受付条件
新規同意の受付では、設定の変更と社内の利用承認を分けて記録します。利用申請を受け付けるなら、業務目的、扱う情報、要求する権限、利用部門の責任者を申請内容に含めます。
業務上の必要性は利用部門が説明し、権限や連携方法の確認は管理担当が担う設計にします。目的と権限の対応を説明できない申請は差し戻します。確認済みの発行元という表示だけを、安全性の保証や承認の根拠にはしません。
Microsoft Learnの「ユーザーの同意を構成する」によると、ユーザー同意を確認済みの発行元のアプリに限る設定に変えても、既存の同意は残ります。新規同意の設定変更とは別に、既存分のレビューと取り消しを作業として残します。
既存同意と高権限の確認
既存アプリの継続判断では、現在の業務目的と付与済み権限を照合します。新規申請の受付条件に合うかだけでなく、その権限を今も使う理由が説明できるかを判断材料にします。
継続・変更・停止の判断では、各アプリの管理画面に表示される権限、利用部門が説明する業務目的、管理者が確認する影響範囲を同じ判断記録に残します。
Microsoft Learnの「Microsoft Entra security operations for applications」は、アプリケーション資格情報の追加、サービスプリンシパルへのロール付与、アプリ権限の変更を監査ログで追跡する観点を示しています。Application Administratorの付与先や条件付きアクセスの除外を確認する場合も、対象設定、付与または除外の理由、承認責任者をアプリ台帳とは別の管理記録に残します。管理者ロール自体の棚卸しは特権ID管理の記事で扱っています。
変更時の台帳更新
台帳は、利用目的や担当者などに変更が生じた時点で、継続判断とセットで更新します。固定の見直し周期を根拠なく置くのではなく、変更を受け付けた担当者が判断責任者へ引き継げる形にします。
変更の条件 | 台帳と判断の更新内容 |
|---|---|
利用目的の変更 | 新しい目的と必要な権限を照合し、継続・変更・停止の判断理由を記録します。 |
担当者の異動 | 後任と承認責任者を登録します。引き継ぎが完了しなければ、継続承認を保留します。 |
連携の終了 | 停止対象、対応担当者、実施結果を記録し、未完了の作業を残します。 |
変更受付後は、業務上の必要性の判断、権限への対応、台帳更新の順で処理します。設定を変更しただけで対応済みにしないことが、この運用の注意点です。判断者と対応結果まで記録すれば、次の棚卸しでも継続理由をたどれます。
通常の連携終了とインシデント対応は分けて扱います。不要になった連携の後始末はSaaS解約時の後始末チェックリストで整理しています。
まとめ
サードパーティ製アプリの棚卸しで目指すのは、アプリ数の集計ではなく、事故時に停止対象・担当者・手順を特定できる台帳です。
着手する際は、自社が利用する管理画面で許可済みアプリと付与権限を一覧にし、担当者と利用目的が不明な行を抽出します。不明な項目があれば確認対象として残し、各アプリに社内管理者と利用目的を対応付けます。
ConnectWise Cloud Backup事案では、ConnectWiseが案内する対象アプリの無効化、新しいアプリによる再認可、テナント側のログ調査を別々に記録します。事故に備えるなら、調査対象のログと確認方法、停止の判断・操作手順も記録し、一覧の作成だけで終わらせない運用にします。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
