AppSheetは安全？PHPの脆弱性から考える、企業が確認すべき4つの設定

PHPの脆弱性に関するニュースを見て、「社内で使っているAppSheetやGoogle Apps Script（GAS）は大丈夫だろうか」と感じたことはありませんか。

AppSheetやGASでは、自社で実行基盤を用意して更新する負担をGoogleに任せられます。

一方、元データの共有、アプリを使える人、GASの公開範囲、Googleアカウントの管理は、自分たちで設定・確認する必要があります。

ここでは、AppSheetやGASを「Googleが管理するマンション」に例えて解説していきます。建物の保守を任せられても、部屋の鍵は自分で閉める。その考え方から、企業が確認したい4つの設定を整理していきましょう。

PHPの脆弱性を見て、まず考えたいのは「誰が更新するか」

自社でPHPの実行環境を管理するシステムなら、脆弱性の影響を調べ、必要な更新を行い、既存のプログラムが動くか確認する担当が必要です。

作った人がいない、保守の依頼先が決まっていない、といった状態では、修正が必要と分かっても対応しにくくなります。

ただし、PHPはプログラミング言語であり、AppSheetはアプリを作成・運用するサービスです。

PHPを使うシステムでも、ホスティング事業者や保守会社が更新を担う契約はあります。

違いは言語の優劣ではなく、どこまでを誰が管理する構成・契約なのかにあります。

AppSheet・GASは「Googleが管理するマンション」

AppSheetの利点は、サーバーを自社で運用し、実行基盤へパッチを当てる作業を抱えずに、業務アプリを使えることです。

GASも、Googleが提供するクラウド上のJavaScript実行環境です。

今までAppSheetアプリを作ってきたなかで、サーバー保守に時間はとられていません。これは、当社が実感している運用上のメリットです。

役割を分けると、次のように整理できます。

確認する対象	自社で実行基盤を管理するシステム	AppSheet・GAS
サーバー・実行基盤の保守	自社または契約先が担当	Googleの提供基盤に任せる
アプリ独自の処理・業務ルール	自社または開発・保守担当が確認	自社または開発・保守担当が確認
利用者・閲覧範囲の設定	利用企業側で要件を決めて管理	利用企業側で要件を決めて管理
アカウントの追加・停止	利用企業側で運用	利用企業側で運用

ただし、AppSheetを使うための専用サーバーを別途運用する負担は減らせますが、アプリの設定や連携処理の保守まで不要になるわけではありません。

また、専用サーバーの運用が不要なことと、ライセンスなどを含めた総費用が無料であることは別です。

企業が確認すべき4つの「鍵」

ここでご紹介したい鍵とは次の４つです。

・元データ
・アプリ利用者
・GASの公開範囲
・Googleアカウント

「社内で使っている」という運用上の認識に加えて、実際に外部からアクセスできない設定になっているかを確認する必要があります。

1. スプレッドシートの共有範囲

AppSheetでスプレッドシートをデータ元として使う場合、アプリの設定だけでなく、元のシートの共有範囲も確認します。

機密情報を含むシートが「リンクを知っている全員」に共有されていれば、アプリを経由せずに情報へアクセスされる入口になり得ます。

Google公式ヘルプでも、この設定ではリンクを持つ人がGoogleアカウントへサインインせずにファイルを利用できると説明されています。（出典：Googleドライブでファイルを共有する）

まず確認は、スプレッドシートの「共有」から行います。

基本は「制限付き」で必要な相手に付与し、業務上必要な場合に組織内の共有を検討します。

組織内限定でも全社員に見せる必要がない情報はあるため、必要最小限の範囲にします。

アプリのデータアクセス方式によって、利用者本人に元データの権限が必要かどうかも変わります。

動かないからといって、シートを全員に公開して解決しないようにしてください。

2. AppSheetを使える人

社内データを扱うアプリでは、サインインを必須にしたうえで、利用を許可する人や組織を限定します。

サインイン必須という設定だけでは、社内の必要な人だけに限定したことにはなりません。

Google公式では、利用者の認証と、アプリを使える人の指定を分けて説明しています。

「Allow all signed-in users」を有効にすると、指定した社員だけの利用にはなりません。

次に確認するのは、認証設定と共有ユーザー一覧です。

退職者や契約が終わった外注先が残っていないか、共同編集者の権限まで必要以上に渡していないかを見直します。

さらに、利用者ごとに閲覧できる行を分ける場合は、データアクセスの制御も必要です。

画面を非表示にしたり、Sliceで表示を絞ったりすることだけを、データの保護と同一視しないでください。

Google公式は、Security filterとSliceでは、端末へ送るデータの扱いが異なると説明しています。

Security filterの利用にはプラン条件があります。自社の契約で使える機能を確認し、データ元の権限も合わせて設計します。（出典：Security filterの基本と利用条件）

3. GASのWebアプリの公開範囲と実行権限

GASで入力フォームや社内向け画面をWebアプリとして作っている場合は、デプロイの設定を確認します。

確認したいのは、「誰がアクセスできるか」と「誰の権限で動くか」の2点です。

Google公式の設定では、アクセス範囲には本人のみ、同一ドメイン、ログインしたユーザー、匿名を含むユーザーなどの区別があります。

選べる範囲は利用環境の制約も確認してください。

社内専用なら、必要な組織・利用者へ絞るのが基本です。

また、「自分として実行する」構成では、アクセスした人にかかわらず、所有者・デプロイ者側の権限で処理が動きます。

公開範囲に加え、その権限でどのデータを読み書きできるかも確認して、パスワードやAPIキーをコードに直接書かないように気をつけてください。

コードの閲覧・共有先と秘密情報の保管先を確認し、APIキーやトークンをブラウザーへ送る画面やレスポンスに含めないようにしておきましょう。

4. Googleアカウントの管理

シートやアプリの設定を整えても、それらを管理するアカウントを第三者に使われれば影響は大きくなります。

2段階認証を有効にし、利用可能な環境ではパスキーも検討します。

Googleは、パスキーにはフィッシングなどの脅威に対する保護を強める利点があると説明しています。導入は組織の認証ポリシーや端末管理と合わせて進めていきましょう。

退職・契約終了時には、業務データやスクリプトの引き継ぎを行い、決めた手順で速やかにアクセスを止めます。

アカウントを放置せず、AppSheetの利用者一覧、シート共有、GASのデプロイ・定期実行の管理者も確認対象にします。

導入時に設定して終わりにしない

前述の『鍵を閉める』という考え方を知っておくと、Googleに任せることと、自社で管理することの違いが分かりやすくなります。

ただ、組織やアプリは変わっていきます。

社員の異動、外注先の変更、テーブルやGAS連携の追加があれば、必要なアクセス範囲も変わるので、初期設定に加え、変更時と定期的な確認の担当を決めておくことをおすすめします。

運用上の確認表は次のとおりです。

確認する鍵	最初に見る場所	見直すきっかけの例
元データ	シート・フォルダの共有設定	データ追加、共有先変更
アプリ利用者	サインイン設定、ユーザー一覧、データ制限	入退社、異動、外注契約終了
GAS	アクセス範囲、実行主体、秘密情報の扱い	再デプロイ、機能・連携先追加
Googleアカウント	認証設定、在籍状況、管理者	退職、端末変更、管理担当交代

4つの鍵は点検の入口であり、すべてのリスクをなくす保証ではありません。

利用端末や外部連携、独自の処理も、扱う情報に応じて確認していきましょう。

よくある質問 

PHPの脆弱性があると、AppSheetも更新しないといけませんか？

自社管理のPHP環境と、Googleが提供するAppSheetの実行基盤は別に考えます。

AppSheet側の基盤の保守を利用者がPHPの更新として行うわけではありません。

ただし、AppSheetが外部のPHPシステムと連携しているなら、その外部システムへの影響は確認が必要です。

AppSheetなら、セキュリティ対策は不要ですか？

不要にはなりません。

基盤の運用負担を減らせる一方で、共有範囲、認証、利用者ごとのデータ制限、アカウントの管理は利用企業側で行います。

シートを組織内限定にすれば十分ですか？

情報の機密性によります。

組織内の全員には見せられない情報なら、特定の利用者・グループに絞ります。

AppSheet側の閲覧範囲とは別に、元データへのアクセスも確認してください。

GASのURLを社内にしか配っていなければ安全ですか？

URLの配布先と、設定上アクセスできる人は別です。

デプロイ時のアクセス範囲と実行権限を確認し、URLを知っているだけで利用できる状態を意図せず作らないようにします。

保守の負担を減らし、設定の管理に集中する

AppSheetのメリットは、基盤の保守をGoogleに任せながら、業務アプリを運用できることです。

その利点を生かすために、自社で担う「鍵の管理」を明確にします。

まずは元データの共有、アプリ利用者、GASの公開範囲、Googleアカウントの4点を確認し、今後も見直せるように担当者と手順を準備してください。

古い社内システムやExcel管理をAppSheetへ移せるか検討している方は、AppSheet Magicの導入・業務改善支援をご覧ください。

既存SaaSから必要な業務を移す考え方は、Google Workspace・AppSheet・GASでSaaSを置き換える方法でも紹介していますので、ご活用ください！