はじめに
この記事はGoogle APIの制限付きスコープのGoogle審査 体験談 ~CASAセキュリティ検証 Tier2編~ の続きの記事です。 この記事では制限付きスコープを使用する場合に必要なCASAセキュリティ検証の手順についてご紹介します。[1]
Google APIのスコープとはアプリがユーザーのデータにアクセスする範囲と権限です。 制限付きスコープではユーザーの個人情報を含む機微なデータに強い権限をもってアクセスします。
CASA セキュリティ検証 Tier3について
CASA セキュリティ検証は、Google APIのうち制限付きスコープを使用するアプリが受ける必要のある審査で、毎年1回対応が必要になるものです。
と、前回ご紹介しましたが、Tier3はそのセキュリティ検証の中でも一番上のレベルのもので、認定機関がアプリを包括的に検証するものになります。
年次再検証(毎年のセキュリティ審査)にてTierが上がることはあっても、下がることはないと明記されています。
Tier2の体験談ブログは多くはないもののいくつか見つかっていたのですが、Tier3については体験談を全く見つけられず、手探りで開始することになりました。
セキュリティ検証のはじめかた(Tier3)
Tier2と同様に、Googleからのセキュリティ検証のリクエストメールが届きます。
メールには期日とCASA認定の検証ラボの案内とともに、なるべく早く検証を開始するようにという注意が記載されていました。 このメールは後々セキュリティ審査の認定機関にも提出する必要があるので、大切に保管しておきます。
Tier2を先に申し込んでいたので、同じ依頼先に申し込みました。
アプリの検証
依頼した審査機関では、Tier3の場合は専任のアカウントマネージャーがついてサポートしてくれる体制になっていました。 そのため、Tier2の開発者自身がダッシュボードでスキャンを進めるフローとは異なるフローで進んでいきました。
まず、アカウントマネージャーとのやりとりで、以下のものをリクエストされて準備しました。
- URL of the application
- Source code access
- Walkthrough/Demo link of the application
- Architecture Diagram
URL of the application(アプリケーションのURL)
Chrome拡張機能を限定公開にして、そのURLを提供しました。 また、動作確認用環境も提供しました。
Source code access(ソースコード)
拡張機能のソースコードディレクトリをzip化してメールに添付して提供しました。 このとき、Tier2で受けていた指摘箇所はあらかじめ修正しておきました。 GitHubやGitLabを利用しても良いようでした。
Walkthrough/Demo link of the application(アプリケーションの説明書またはデモリンク)
どの程度の説明やデモが求められているのかわかりませんでしたが、以下に記載の内容をまとめて、英語に翻訳しPDF化したものを提供しました。 (この対応がベストであったかどうかはわかりませんが、特に指摘がなかったので問題はなかったようです)
- 審査するChrome拡張機能の名称と提供するサービス名が異なることから、同一サービスの一部となるアプリケーションであるという説明
- アプリケーションの概要(目的)
- 機能の一覧とその機能のGoogle APIの使用有無
- アプリケーションの起動とGoogleユーザー認証からはじまる操作のフローをGoogle APIの使用方法を含めて説明
- 画面キャプチャと簡単な操作説明、Google APIを使用する箇所の詳細な説明
また、前々回の記事でご紹介したOAuthアプリのGoogle審査時に提出したOAuthデモ動画のYouTubeリンクのURLを提供しました。
Architecture Diagram(アプリケーションの構成図)
システム構成図を英語に翻訳しPDF化したものを提供しました。
以上をメールに添付し、送信しました。 リクエストメールが届いてから、上記の準備を実施してメールを送信するまで2週間ほどかかりました。 どれくらいの精度を求められるのか不明だったため、スピード重視で回答し追加の質問をいただいたら都度対応する方針で進めました。
1週間ほどして、アカウントマネージャーから「脆弱性はみつかりませんでした。次にセキュリティに関する自己評価アンケート(SAQ)に回答してください」とSAQのエクセルが送られてきたので、Tier2で提出していたアプリで受け取ったSAQとほぼ同じ内容だったこともあり、同じ内容を回答しました。
エビデンスの提出
次に、SAQのエビデンスと、Googleユーザーデータを保存している場合は暗号化方式とDBの画面キャプチャを送ってください(Tier2と同じ)とリクエストされました。
SAQのエビデンスは23項目の内、3項目のみのリクエストでした。 英文を翻訳・要約すると以下のような内容でした。
- 暗号化、完全性、保持、プライバシーなどの保護要件の有無と、アーキテクチャへの適用
- 信頼できないソースからのファイルの対策
- アプリケーションや構成、依存関係の自動デプロイと復元
対応
エクセルにそれぞれの番号のシートを作成し、1の保存しているデータの分類やポリシー、2の部分的なソースコード、3のデプロイの手順やテンプレートを準備して送りました。 どの程度の精度を求められているか不明でしたので、こちらも審査機関とのやり取りを前提に速やかに対応する方針で進めました。
結果
指摘なしでした。
その後の流れはTier2と同じで、プロジェクト情報をリクエストされ回答し、認定機関によってGoogleへLOVが提出され、Googleから承認メールが届きました。 プロジェクト側も「検証済み」ステータスになっていました。
おわりに
Tier3審査は資料作成など含めトータル1ヵ月でした。今回のアプリはChrome拡張機能で、そこまでボリュームのあるソースコードでもなく脆弱性も見つからなかったので スムーズに完了しました。ソースコードのボリューム次第ではさらに+2週間ほどかかってもおかしくはなさそうです。
同じ審査機関にてセキュリティ審査を実施した際のTier2とTier3の違いは以下でした。
Tier2 | Tier3 | |
---|---|---|
アプリケーションの検証 | ダッシュボードで開発者がアプリをスキャンして検証 | ソースコードと動作環境・ドキュメントを提供して審査機関が検証 |
SAQのエビデンス | SAQのエビデンスは求められない | SAQのエビデンスを求められる |
今回一連のGoogle審査とCASAセキュリティ審査を対応してみての所感です。 ・今回依頼した審査機関ではセキュリティ検証のアカウントマネージャーのレスポンスは基本的にとてもはやく、翌日くらいには連絡が来ました。例外として検証の際は時間がかかっていました。 ・資料は求められた要点に対して、誤解を招かない内容を記載すればよさそうです。過度な完成度は求められませんでした。
2025年7月現在、年次セキュリティ検証のリクエストのメールがGoogleから届きました。 期限はちょうど昨年Googleから承認メールが届いた日付から1年後でした。 今年も無事完了できるように対応していきます。
Google OAuth 検証関連のブログは以上となります。最後までお読みくださりありがとうございました。
本記事の情報は2024年9月の申請時点の情報です。レギュレーションは都度見直しされている可能性がありますので、実際に対応される際は最新の情報をご確認ください。 ↩︎