みんなで乗り切ろう Google OAuth利用Appのセキュリティ認定 [CASA更新のための外部セキュリティ診断]
こんにちは某社security teamにいるmarktです。
ここではGoogle OAuthを利用するアプリに必要となる年次のセキュリティ認定(CASA)更新と認定外部ベンダによるセキュリティ診断について書いています。
(大体10分足らずで読めるはずなのでCASAの更新みたいな通知が来たら、流れを思い出すためにざっと読んでもらえると有用なはずです)
端的にはCASAと呼ばれるセキュリティ認定の更新(Tier 2)が 自己申告不可 となり、外部認定ベンダによる認定が必須なったためその対応のまとめです。思ったより時間も手間もかかるので早めに準備する際の参考にしていただければと思います。
セキュリティ認定更新してね、ただし外部認定Lab使ってね連絡が届く
Google OAuth 2.0が使用できる公開アプリとなりめでたし^2となってから一年足らず、恐らく以下のような更新してね通知が届き対応開始となります。
画像はGoogle Cloudのconsole表示ですがメールでも来ます
CASA (カーサ) ... スペイン語で家という意味でその名を冠した雑誌も...
なにか違うな。
要は、
- Google OAuthを利用したアプリを使い続けるにはCASA認定を年次更新する必要がある
- アプリが取り扱う機密性等でTier(階層)が決まり、認定要件も変わる
- Tier 2以上の認定更新にはLetter of Validation (LOV)が必要であり、これはCASA認定Labにより発行されGoogleに提出される
ということなんですがjargonがいっぱいでてきましたね。
CASAとは? Tierとは? LOVとは? そして要件って何?
CASA - Cloud Application Security Assessment (クラウドアプリケーションセキュリティ評価)、のことでセキュリティ審査のframeworkです。この仕組みが気になる方のために詳細は後述しますが、まずはGoogle OAuthを利用するクラウドアプリケーションを持つにはCASAに従い認定されなければならないと理解しておけばokです。
Tier - 階層と訳されるGoogle OAuth利用アプリのレベルです。
- CASAには1-3のTier(階層)があり高いほどセキュリティが保証されている、とみなされる
- 自分たちのアプリがどのTierになるかは利用するAPI等により決まりGoogle Cloud console上でも表示されるよ
https://support.google.com/cloud/answer/13463073
LOV - Letter of Validationで要は認定証です。これはアプリ開発者が自己申告で出すのではなく、LOVを発行できる認定された会社がGoogleに申請します。
およその流れとかかりそうな時間
(https://appdefensealliance.dev/casa/tier-2/tier2-overview より)
実体験(上の4 stepsとは異なります)
1.[Google] -- CASA要請 --> Day 0
2.[アプリ開発者] -- 認定Lab(ベンダ)に診断依頼 --> 契約するので1-4 weeks
3.[認定Lab] -- LOV提出 --> 2-3 weeks
4.[Google] LOVを審査しokならCASAステータスが更新される --> 1-2 weeks
5.[アプリ開発者] 認定されたGoogle OAuth利用アプリが継続利用可能となる
合計が4-9週間となりますが、2ヶ月は見積もっておきたいスピード感です。
セキュリティ診断とは何をするのか?
CASA認定のプロセスでは具体的な診断方法が記載されていましたが、セルフスキャンがTier2では認められなくなったため、「認定Labに診断してもらう」が正式な定義になってしまいました。
というわけで、ここからは認定Labによる実際の診断結果を書きつつ経緯や必要な準備、期間をまとめたいと思います。
認定Labによるセキュリティ診断
今回はTAC Securityを利用しました。
先にまとめると、
- 診断はSASTかDASTか選ぶ
- 比較的安い ($540~)、スキャン方式によって金額は変わらない
- サポートはすべて英語そしてメール
- US西海岸に拠点があるのか時差があり営業日もUSカレンダー
という感じで手頃なサービスです。かつてセルフスキャンでコストがほぼかかっていなかったことを考えると有償にはなってしまいますが、選択の余地はありません。
診断種類 - SASTかDASTか
SAST, DASTとは静的スキャン, 動的スキャンの意味で診断するツールや結果が変わります。TAC Securityでは3種類方法が選べて、
- DAST (動的スキャン) - 対象domainまたはStaging環境へLab側からスキャンしレポート作成する
- SAST/ソースコードスキャン - TAC Securityの管理画面へ対象アプリのsource codeをuploadしTAC Securityにてスキャンし評価する
- SAST/fluid-attacksの結果提供 - 対象アプリに対してfluid-attacksでセルフスキャンを行い、結果をuploadし評価してもらう
どの選択肢が良いかは状況によるかと思いますが、code提供を避けたい場合は1(DAST)または3(fluid-attacks)を選ぶことになるかと思います。
今回は1のDASTを選びました。
fluid-attacksについてここでは記述しませんが、詳細共有されている記事を見かけるので公式or関連記事を見つつ試すのが良いかもしれません。
そしてもう使っているよ、という場合はhigh riskな検出が出ていなければ#3が一番手っ取り早い選択肢になるかもしれませんね。
DASTが早い(と思った)理由
DASTにした理由をいくつか挙げてみます。
- TAC Securityに聞いたらscan toolはZAPだというので安心した
- 事前にZAPでself scanして結果が予想できていた
- サービスの種類と金額からして手動診断はないな、と見切った
- WAFを外さなければいけない制約もなかった
- 最悪stagingでの実施も可能だった
- SASTは余計な検出(開発環境特有で本番には無関係の検出とか)が出るのでtuningや例外申請の手間が増えると思った
決めてはZAPです。ところでツールはZAPなの?と聞いたらyes, と返ってきたので勝ち確だな(何の?)と思いました。
元々がセルフスキャンなのでいきなりシビアなpentestみたいな診断になるわけはなく、業界標準のツールでスキャンする条件を揃えたい、というのが条件を引き上げたGoogle側の思惑かなと。
もちろんZAPマスターみたいな人がLabの中にいてカスタムしまくった最強ZAPでスキャンが来る可能性もなきにしもあらずでしたが、
傍目にはただのZAPでも中身はモンスターエンジン...!!
にはならなかったです...。
DAST/SASTでも事前セルフスキャンは大事
使うツールが判っていてOSSなので自分でも試せます。事前にスキャンしておくとその後の対応を短縮することができるので可能な限り事前にスキャンしておくことをおすすめします。
まずは致命的な検出結果が出ないか、誤検知の正当化が難しそうな検出がないかを見ておくと安心できると思います。
TAC SecurityでのDASTの進み方
さて、診断をpassするまでの手順ですが以下のように進みます(DAST ver.)
- TAC Securityとサービス契約
- 対象アプリの登録とユーザアカウント等必要情報の提供
- スキャン設定 (セルフスキャンではない)
- スキャンレポート作成
- 検出された脆弱性についての誤検出またはリスク該当なしのチケット作成
- TAC Securityにて誤検出チケットの評価、そして再スキャン
- 自己問診票(SAQ)の回答と提出
- TAC Securityにて最終確認、okならLOVの申請提出
認定Labとしてはここまで、後はGoogle側でLOVの審査
ESOFと彼らが呼んでいるCASA認定スキャン用のconsoleは以下のような感じです。
設定が完了するとscan! となるわけですがそのボタンには"Request"と出ます。つまり自分たちでscanをkickできるわけではなく、依頼するボタンです。よってすぐにscanが始まるわけではありません。時間も指定できないので24時間以内のどこかで、というくらいの枠のようです。
(そもそもwest coastとは時差があるのです)
scanの設定自体は前述の通り、素のZAPだと思います。検出結果も想定通りでした(WAFのおかげか少し少ないくらい)。
ZAPそのままなのかSeverity LevelはHigh/Medium/Low/Infoとなっていて、認定LabいわくLOV提出にはInfoは無視して良いとのことでした。
High-Lowのリスクが出た場合は、ticketを作成しclaim(申し立て)を行い、レビューの結果okとなれば修正の必要はなくなります。
パターンとしては、1) 誤検出、2) 検出内容は正しいがリスクは該当しない となるかと思いますので事由を英語で書いてticket作成します。これはすべての検出結果に一つずつ作成するので少し手間です。
そして忙しいのか認定Lab側がこのticketを見ていない様子だったのでメールで問い合わせました。
すると後日ticketのstatusがいきなりcompleteに変わり再スキャンもいきなり進展しました(海外SaaSあるあるですが先方作業の進捗には少し波があるかもしれません)。
結構時間のかかる自己問診票(SAQ)
最後に再スキャンと自己問診票です
再スキャンはこちらが寝ている間に行われ気がついたら全体進捗では完了で、早く自己問診票だせみたいなstatusに移っていました。
自己問診票(Self Assessment Questionnaire, SAQ)は従来と同じ質問なのですが、50問以上あります。また質問内容もapp/SRE/securityにまたがることがあるので関係者に回答を埋めてもらう必要があります。ここも事前準備できると期間圧縮できるポイントですね。次回は生成AIにすべて埋めてもらいたいです。
かくして提出物がすべて出し終わるとTAC Securityによるチェックで、問題なければLetter of Validation (LOV)を出してもらえることになります。
LOV提出とGoogleからの連絡待ち
対応に時差がありすこしyakimokiしつつも週末を経たらLOVが提出したとの連絡になりconsole画面のstatusもLOV submittedになりました。
残るはGoogle側の審査ですが、ここまでくれば基本的に認定更新になるはずです。問題はどのくらいかかるか、で大体1週間くらいと認定Lab側からはコメントをもらいました。認定には期日があるのでギリギリの場合はリスクがありますので期日の延長申請を予め検討しておくのもよいでしょう。
認定おつかれさまでした
かくして対象アプリはGoogle OAuthを使い続けることができます。また来年。
まとめと所感
今回のTier2における外部診断必須化は、Googleとしてはassessmentを標準化したいという思惑だろうと察します。セルフスキャンは任意のレポート過ぎるのでそれなりにベースを整えつつ、認定プロセスすべてをoutsourceしたいGoogleの思いが伝わってくるルール変更ですね。
他の認定系と同様これをもって堅牢なWebアプリと言い切ることは難しいと思いますが、OSSのsecurity toolを推していきたいGoogleとセキュリティ業界の人の思いは分かるな...という気分に一瞬なりました。
また、現状日本語メインでサポートしてくれる認定Labは一部外資系以外なさそうですが、言語や時差を考えると認定される日本のセキュリティ企業がいるとみんな楽なのにな、と思います。はよ。
認定Labリスト:
CASA...
10分だらっと読んだ結果リゾートホテルの画像に脳が乗っ取られてしまった場合は気の毒ですがcasaのことは忘れてセキュリティしなきゃ、と我に返ることを進言します。
最後に隈研吾事務所デザインの由布院のCASAを載せて終わりにしたいと思います。
Discussion