Чтобы обеспечить безопасность пользовательских данных, Google тщательно проверяет все приложения, которые используют restricted API scopes и имеют доступ к Google User Data. Не так давно мы в Snov.io прошли через процесс проверки и получили одобрение Google, с чем и хотим поделиться.
Новые правила для приложений
9 октября 2018 года Google анонсировал новые правила для приложений, которые используют Google restricted API scopes. Они включали в себя 2 этапа проверки:
- Проверка соответствия приложения политике Google API User Data
- Проверка соблюдения минимальных требований безопасности
The restricted scope app verification verifies compliance with the Google API User Data Policy and an additional set of policies outlined in Additional Requirements for Specific API Scopes. First, your application will be reviewed for compliance with the Google API Services: User Data Policy. Thereafter, you will have the remainder of 2019 to demonstrate compliance with the secure handling requirements.
Проверка соблюдения минимальных требований безопасности стоила немалых средств — от $15,000 до $75,000.
Assessments will be conducted by a Google-designated third-party assessor, may cost between $15,000 and $75,000 (or more) depending on the complexity of the application, and will be payable by the developer. This fee may be required whether or not your app passes the assessment.
Уже 9 января 2019 года Google ужесточил правила для приложений, которые планируют использовать Google API. Для приложений, которые использовали Google API ранее, появилось требование подать заявку на верификацию до 15 февраля. В противном случае доступ к приложению был бы закрыт для новых пользователей начиная с 22 февраля, а действующие пользователи не смогли бы использовать приложение с 31 марта.
Последствия такого развития событий были бы малоприятными. Связано это с тем, что значительное количество наших пользователей (а их больше 100 тысяч) используют Gmail. Следовательно, мы бы просто потеряли этих клиентов.
For projects that require action, you must submit apps for verification before Feb 15th, 2019. If you don't, access for new users will be disabled on February 22nd, 2019, and existing grants for consumer accounts will be revoked on March 31st, 2019.
Как у нас всё происходило до обновлений
Наша платформа Snov.io использует Google API с 2017 года. Наше приложение использовало несколько restricted scopes: для чтения входящей почты и для работы с черновиками.
Google и раньше проверял приложения, которые используют Google API. Для того, чтобы применить новый API scope, нужно было добавить его в консоли и указать, для чего именно он будет использован. Пока сотрудники Google проверяли заявку, пользователи видели на своих экранах уведомление «This app isn’t verified»:
Обычно данная проверка занимала у нас 2-3 рабочих дня (хотя, в письме от Google было указано, что процесс может длится до 7 дней) и всегда проходила без проблем. Мы дожидались пока Google проверит нашу заявку и только потом заливали фичу на прод для того, чтобы пользователи не видели уведомление «This app isn’t verified».
Прохождение первого этапа
Для начала мы решили сосредоточиться на первом этапе проверки, а именно — соответствии нашего приложения политике Google API User Data.
16 января в Google консоли появилась кнопка Подать на верификацию и мы отправили заявку. Перед отправлением мы удостоверились, что соответствуем всем пунктам политике Google API User Data. Мы внесли изменения в нашу политику конфиденциальности, в частности, добавили раздел Google User Data, где подробно описали, какие данные, полученные от Google API, мы храним, как их используем и когда удаляем.
12 февраля мы получили ответ на отправленную заявку. Нас просили записывать видео и показывать, как мы используем запрашиваемые restricted API scopes.
В итоге, нам пришлось отказаться от двух наших проектов на Google Cloud и объединить их в один. Мы отказались от первого проекта для тестового сервера, который работал в тестовом режиме, и использовали для теста тот же проект, что и на проде. Второй проект для авторизации в систему через Google мы также удалили и вместо него использовали для входа тот проект, который требовал верификацию.
Отвечали представители Google на наши письма где-то через 2 недели. На вопросы, вместо прямых ответов, мы получали цитаты. Нам казалось, что у них есть специальный скрипт, по которому они проверяют приложения.
Нам, например, сделали замечание, что мы используем для входа в систему приложение с одним ID, а при подключении email аккаунта — приложение с другим ID. Мы сделали это намеренно, так как это две совсем разные функции. Приложение для входа в систему не требовало никаких проверок и мы не хотели, чтобы непрохождение проверки приложения с restricted API scopes привело к отключению приложения для верификации.
20 апреля мы наконец-то прошли первый этап проверки на соответствие Google Data Policy!
Прохождение второго этапа
Шаг 1. Выбор компании для прохождения проверки
Ко второму этапу проверки нашего приложения Google прислал контакты двух компаний на выбор — Bishop Fox и Leviathan Security. Пройти проверку можно было только у них. Дедлайн был дан до 31 декабря.
20 мая мы отправили письма двум независимым экспертам для прохождения проверки. Bishop Fox и Leviathan Security прислали анкеты с вопросами о нашем приложении. Нужно было ответить, какие Google данные мы используем, какое количество строк кода прописано для каждого языка программирования, а также на вопросы о нашей инфраструктуре, процессе развертывания ПО и провайдере. Мы всё заполнили и начали ждать предложения с ценой.
В ходе подготовки и предварительного общения с представителями компаний мы узнали, что , на котором размещены наши сервера, не соответствует SOC2. И для успешного прохождения проверки нам нужно было переехать на соответствующий SOC2 . Мы уже давно думали о переезде на Amazon, поэтому параллельно начали процесс переезда.
Мы также узнали, что нужна программа Bug Bounty, предлагаемая многими веб-сайтами и разработчиками ПО. С её помощью люди могут получить признание и вознаграждение за поиск ошибок, в особенности тех, которые касаются эксплойтов и уязвимостей.
В сентябре у нас было два готовых контракта от Bishop Fox и Leviathan Security. Мы должны были определиться, с кем заключать контракт. По каким критериям выбирать эксперта мы не знали, но договор с Leviathan Security показался нам более прозрачным, несмотря на то, что стоил он незначительно дороже.
Шаг 2. Подписание договора и подготовка к проверке
8 октября мы подписали договор с Leviathan Security. На момент подписания договора мы еще не завершили процесс переезда на Amazon. Поэтому в нашем договоре в графе «хостинг» остался пробел и мы должны были вписать его позже.
Также мы узнали, что будет включать в себя проверка:
- External Network Penetration Test
- Application Penetration Testing
- Deployment Review
- Policy & Procedure Review
И следующие этапы:
- Preparation
- Assessment
- Verification & Validation
- Final Report
Длится проверка приблизительно месяц. В ее стоимость входит время для устранения найденных уязвимостей. После чего совершается повторная проверка. В результате проверки мы должны были получить Letter of Assessment (LOA), которое потом нужно отправить Google представителям. Но эксперт не гарантирует получение LOA как 100% результат оценки.
23 октября Leviathan Security прислал анкету Self-Assessment Questionnaire (SAQ). Вместе с ней мы также предоставили наши политики, которые нужны были для прохождения проверки:
- Incident Response Plan: Establishes roles, responsibilities, and actions when an incident occurs
- Risk Management Policy: Identifies, reduces, and prevents undesirable incidents or outcomes
- Vulnerability Disclosure Policy: Provides a means for external parties to report vulnerabilities
- Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
- Privacy Policy: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant
8 ноября состоялся External Alignment Meeting, на котором мы обсудили все организационные вопросы, определили мессенджер для коммуникации (Slack) и коротко рассказали о нашем приложении. Нас предупредили, что потребуется предоставить доступ к исходному коду — для нас это не было проблемой.
На митинге мы узнали, что нам необходимо шифровать Oauth токены с помощью KMS, чего мы до этого не делали. Также мы обсудили приблизительное время нашей проверки. Нас заверили, что если ее назначат на конец года и мы не будем успевать пройти ее, Leviathan Security будет вести переговоры с Google, чтобы нам продлили дедлайн.
14 ноября мы получили информацию о планируемом старте нашей проверки: поздний декабрь или ранний январь. И Leviathan Security предупредил Google, что мы можем предоставить LOA позднее дедлайна.
16 ноября мы получили подтверждение от Google о переносе дедлайна до 31 марта.
Шаг 3. Проверка
13 декабря мы получили письмо, в котором нас оповестили о начале проверки — 2 января, и попросили выполнить следующие требования:
1. Подтвердить возможность проведения проверки.
2. Еще раз предоставить необходимую информацию.
Документы нужно было загрузить в общую папку на OneDrive за неделю до проверки — до 26 декабря. Мы не предоставляли никаких дополнительных документов кроме обязательных:
- Incident Response Plan
- Risk Management Policy
- Vulnerability Disclosure Policy
- Information Security Policy
- Privacy Policy
- Supporting Privacy Documentation
- Terms and Conditions
- Self Assessment Questionnaire (SAQ)
- документация к внешним API методам
- тестовые аккаунты для приложения
- список внешних URL-адресов
- высокоуровневая диаграмма нашей архитектуры
- список IP основных компонентов
3. Предоставить доступ к исходному коду.
4. Пригласить определенных людей в мессенджер Slack.
5. Указать номер телефона и детали для эскалации проекта.
6. Предоставить информацию о том, как нам должны выставить счет.
7. Сообщить командам внутренней безопасности, CDN и провайдерам, что проверка состоится с 2 января по 27 января.
8. Создать общую папку на OneDrive.
9. Ознакомиться с часто задаваемыми вопросами Google проверки.
30 декабря состоялась кик-офф встреча, на которой было почти всё то же самое, что и на первом митинге. Мы представились, описали продукт с комплектом технологий и подтвердили, что наша система стабильная, и что во время оценивания продукта никаких крупных релизов выходить не будет. Закончилось всё вопросами и комментариями.
2 января началась проверка безопасности. Отметим, что проходила она без особых трудностей. Иногда было неудобно из-за разницы в часовых поясах — все созвоны и общение в Slack мы проводили уже в нерабочее для нас время.
У нас было найдено немало уязвимостей — высокого и критического уровня (high and critical). Такие уязвимости обязательно нужно было исправить. Уязвимости среднего уровня и ниже можно было исправлять на свое усмотрение. На исправление давалось 30 дней. Но мы фиксили их буквально на следующий день.
В основном уязвимости были связаны с устаревшими методами шифрования пользовательских данных и недостаточным логированием. К нашим документам по политике претензий не было. Отдел политики Leviathan Security задал несколько уточняющих вопросов и сказал, что выглядят они солидно.
Недостатка в общении не было. Все неясные вопросы мы могли прояснить на статус митингах или в Slack. Репорты об уязвимостях были хорошо описаны, а также содержали рекомендации к исправлению. В последний день нашего оценивания все критичные, высокие, а также некоторые средние и низкие уязвимости были исправлены и проверены.
31 января мы получили LOA и отправили его Google представителям.
11 февраля получили подтверждение прохождения проверки от Google.
Для нас самым сложным была неизвестность. Чего ожидать? Как все будет происходить? Мы чувствовали себя первопроходцами. Нигде не было никакой информации о том, как другие компании проходили эту проверку, что и подтолкнуло нас к тому, чтобы поделиться информацией о Security Checkup с другими.
Тем, кому такая проверка только предстоит, хотим сказать, что она не так страшна как может казаться. Да, процесс — трудоемкий, но на исправление всех уязвимостей будет хороший запас времени. Несмотря на то, что прохождение Google Security Checkup заняло у нас год, это время не было потрачено зря. Мы можем продолжать использовать жизненно важное для нас Google API, а также закрыли уязвимости, которые впоследствии могли бы вылезти боком для нас или наших клиентов.
Есть компании, например Context.io, которые приняли решение не проходить проверку и закрылись. Есть те, которые продолжают работать без доступа к API, но при этом теряют репутацию в глазах юзеров. Каждому бизнесу, которому необходимо пройти проверку, конечно придется самостоятельно взвешивать все за и против. Сложнее всего будет совсем молодым компаниям, у которых еще нет прибыли. Но если у бизнеса есть ресурсы чтобы проверку пройти, то это однозначно стоит делать.
Надеемся, что наш опыт вам в этом поможет!
Автор: tzhostka
