Now in REALITY Tech #85 データ保護評価やりました
こんにちは、久しぶりの投稿となりますサーバエンジニアのゆーしです。
本日は、REALITYで初めて実施したMeta社の『データ保護評価』について書かせていただこうと思います。
データ保護評価とは
REALITYではログイン連携先のSNSの1つとしてFacebookを利用しており、そのためFacebookのUser ID、Facebookの登録名、そしてFacebook上でのREALITYアプリを利用している友達のUser ID一覧をFacebookのAPIを通じて取得しています。
『データ保護評価』はそのようなFacebookから入手したデータを開発者がどのように使用・共有・保護しているかを評価することを目的として、年に1度アンケート形式での回答と、その内容によってはその証拠となる資料の提出を求められます。
REALITYでは昨年初めて提出を求められ、その後何度も追加の回答の再提出を行い、やっと先日『データ保護評価』を完了しました。
『データ保護評価』への対応
『データ保護評価』は、主に4つの分野に対しての回答を求められます。
データの使用
データの共有
データの削除
データセキュリティ
1つ目の"データの使用"に関しては、MetaのプラットフォームデータをREALITYアプリ内で特定の属性のユーザを不利な立場に置く、雇用や保険、在留資格などの決定に用いる目的で利用したり、監視に関連するアクティビティにプラットフォームデータを含んでいないかの回答が求められます。
REALITYではFacebookのUserIDと名前、友達のUserIDのみをFacebookから取得しており、その利用方法もREALITYのIDとの連携やREALITY内でFacebookの友達を探す際のサジェスト、REALITYに登録した際の初期の名前にセットするといった目的にのみ使用しており、この項目については問題ありませんでした。
2つ目の"データの共有"に関しては、Metaのプラットフォームデータをさらに別のサービスプロバイダ(第三者)に提供しているかどうかの回答が求められます。
REALITYではFacebookから取得したデータを、別の第三者に提供することは行っていないのでこの項目も問題ありませんでした。
3つ目の"データの削除"に関しては、Metaのプラットフォームデータの削除ポリシーについて回答が求められます。
REALITYではユーザがFacebookとの連携を解除した際、及びREALITYを退会して30日経過した際にFacebookのデータを削除しており、この項目も問題ありませんでした。
4つ目の"データセキュリティ"に関しては、Metaのプラットフォームデータを扱っているREALITY側のサービスのセキュリティ面に関しての回答が求められます。
今回、最初の回答時に提出した証拠の資料がMeta社の要求に沿ってない点が多かったため、この分野において数多くの再提出を求められることとなりました。
REALITYで再回答を求められた内容は以下の6つで、どれも証拠資料の不備によるものでした。
REALITYでは、サービスで利用しているGoogle Cloud Platformやその他ツール(githubなど)アカウント管理をグリーグループ全体で利用しているG Suiteのアカウントをベースに行なっております。その上でREALITY運用上の様々な権限をGoogle Cloud PlatformのIAM(Identity and Access Management)に連携させていて、REALITY事業に配属された際のチームに応じて必要な権限が付与される仕組みをとっています。
今回提出した資料における手順書が、Meta社の要求する項目を全て満たしていなかったため、今回それらの項目を満たすとともに、英語版を作成して提出し、解決しました。
REALITYでは障害/不正アクセスがあった際など緊急時の対応ドキュメントを用意しており、またグリーグループとしてセキュリティインシデント発生時の対応フローが整備されております。
また、グループ全体で定期的にe-learningによる研修や、不定期な標的型メール訓練などのトレーニングも実施しております。
今回、そのうちのREALITYにおける対応ドキュメントを提出したのですが、これには実際に12ヶ月に1回以上対応ドキュメントに準じたテストが行われている結果も必須であり再提出を求められました。
そのため、不正アクセスが発生したと仮定した状況下で、対応ドキュメントに従った模擬訓練を行い、その実施報告書を作成して提出し、解決しました。
グリーグループの共通部門に存在するセキュリティ部という専門のチームの方々によって、REALITYでは年に1回程度セキュリティ(脆弱性)診断を実施しています。
今回、その直近の結果を証拠資料として提出したのですが、Meta社の要求する項目に足りなかったため、改めてREALITYの開発チームで利用しているクラウドサービス(Google Cloud Platform) と golangで書かれたサーバアプリケーションコードの脆弱性診断を実施しました。
クラウドサービスの診断にはNCC Scout Suite を、ソースコードの脆弱性診断にはgosec を利用してその結果を提出し、解決しました。
REALITYが利用しているGoogle Cloud Platformでは、内部でのデータ保存時やデータの転送時など標準で暗号化されています。
これらを改めて丁寧に説明したり、英語の資料を添付するなどして解決しました。
これが最も漠然としていて、どこまで証拠資料を揃えるか大変だった項目です。
当初はGoogle Cloud Platformにおける各種ハードウェアが自動的にアップデートされる状態になっている旨の資料を提出したのですが、それだけでは足りず、アプリケーションではdependabotやRenovateを使って脆弱性の検出やパッケージの維持管理を行なっていることや、Golangのバージョンのアップデートポリシーといった、多数のポリシーに関する資料を用意して提出することで、解決しました。
初回に回答を提出した後こそ、再提出の連絡が来るまで5ヶ月くらいかかりましたが、その後はMeta社の担当の方も割と早く返信していただけたので、あとは証拠資料に関するガイドを良く読んだり、担当者の方からのメッセージを参考に地道に対応していけばきちんと解決できるのかなと思いました。
あとは注意すべきこととして、日本語で書かれた資料を提出すると"Please provide the evidence in the English language."のメッセージとともに再提出が求められます。初回の提出時は日本語で書かれた資料をそのまま添付して出したケースも多かったため、それも再提出の項目が多かった原因の1つでした。
最後に
実はこの『データ保護評価』、Metaのプラットフォームデータを取り扱っていればどの会社も必ず実施しているわけではないようで、社内でも知見がほとんどありませんでした。
そして何度もMeta社から再提出を求められる中で、NewsPicksの高山さんや YOUTRUSTのzooさんの記事は大変助かりました。
実際、今回Meta社に回答した内容は重要なことであり、データの取り扱い方や、それを扱う環境のセキュリティ、アップデートポリシーなどを改めて把握し直す良い機会になったと思います。
実際今回、脆弱性の検知に利用したgosecは、一部サービスのCI/CDに組み込んだりもするようにしました。
このような取り組みを通して、REALITYをより安心して使っていただけるようなサービスにしていければと思っています。