Как Мы Проходили Проверку Безопасности Google

Чтобы обеспечить безопасность пользовательских данных, Google тщательно проверяет все приложения, которые используют ограниченные области API и имеют доступ к пользовательским данным Google. Не так давно мы в Snov.io прошли процедуру проверки и получили одобрение от Google, которым хотим поделиться.



Новые правила подачи заявок

9 октября 2018 г.

Google объявила о новых правилах для приложений, использующих области API с ограниченным доступом Google. Они включали 2 этапа проверки:

  • Проверка соответствия вашего приложения политике пользовательских данных Google API.
  • Проверка соответствия минимальным требованиям безопасности
Проверка приложения с ограниченной областью действия проверяет соответствие Политике пользовательских данных API Google и дополнительному набору политик, изложенным в разделе «Дополнительные требования для конкретных областей действия API».

Сначала ваше приложение будет проверено на соответствие Службам API Google: Политика пользовательских данных.

После этого у вас будет оставшаяся часть 2019 года, чтобы продемонстрировать соблюдение требований безопасного обращения.

Проверка соблюдения минимальных требований безопасности стоила дорого: от 15 000 до 75 000 долларов.

Оценка будет проводиться сторонним оценщиком, назначенным Google, ее стоимость может составлять от 15 000 до 75 000 долларов США (или более) в зависимости от сложности приложения, и она будет оплачиваться разработчиком.

Этот сбор может потребоваться независимо от того, пройдет ли ваше приложение оценку.

.

Уже 9 января 2019 г.

Google ужесточил правила для приложений, которые планируют использовать Google API. Для приложений, которые ранее использовали Google API, необходимо подать заявку на проверку перед 15 февраля .

В противном случае доступ к приложению будет закрыт для новых пользователей, начиная с 22 февраля , и существующие пользователи не смогут использовать приложение с 31 марта .

Последствия такого развития событий будут неприятными.

Это связано с тем, что значительное количество наших пользователей (а их более 100 тысяч) используют Gmail. Следовательно, мы просто потеряем этих клиентов.

Для проектов, требующих действий, вы должны отправить приложения на проверку до 15 февраля 2019 г.

Если вы этого не сделаете, доступ для новых пользователей будет отключен 22 февраля 2019 г.

, а существующие гранты для потребительских аккаунтов будут отменены 31 марта.

2019.



Как все было до обновлений

Наша платформа Снов.

ио использует Google API с 2017 года.

Наше приложение использовало несколько ограниченных возможностей: для чтения входящей почты и для работы с черновиками.

Google уже проверял приложения, использующие Google API. Чтобы применить новую область API, необходимо было добавить ее в консоль и указать, для чего именно она будет использоваться.

Пока сотрудники Google проверяли приложение, пользователи увидели на своих экранах уведомление «Это приложение не проверено»:

Как мы проходили проверку безопасности Google

Обычно эта проверка занимала у нас 2-3 рабочих дня (хотя в письме от Google было указано, что процесс может занять до 7 дней) и всегда проходила без проблем.

Мы подождали, пока Google проверит наше приложение, и только после этого загрузили эту функцию в продукт, чтобы пользователи не видели уведомление «Это приложение не проверено».



Прохождение первого этапа

Для начала мы решили сосредоточиться на первом этапе проверки, а именно на соответствии нашего приложения политике пользовательских данных Google API. 16 января в Google Console появилась кнопка Отправить на проверку и мы отправили заявку.

Перед отправкой мы убедились, что соблюдаем все пункты политики Google API в отношении пользовательских данных.

Мы внесли изменения в нашу политику конфиденциальности, в том числе добавили раздел «Данные пользователя Google», в котором подробно описано, какие данные мы храним из Google API, как мы их используем и когда мы их удаляем.

12 февраля Мы получили ответ на вашу поданную заявку.

Нас попросили записать видео и показать, как мы используем запрошенные ограниченные области API. В результате нам пришлось отказаться от двух наших проектов в Google Cloud и объединить их в один.

Мы отказались от первого проекта тестового сервера, который работал в тестовом режиме, и использовали для тестирования тот же проект, что и в продакшене.

Также мы удалили второй проект для авторизации в системе через Google и вместо него использовали проект, требующий верификации для входа.

Представители Google ответили на наши письма примерно через 2 недели.

Вместо прямых ответов на вопросы мы получили цитаты.

Нам показалось, что у них есть специальный скрипт, по которому они проверяют заявки.

Например, нам сказали, что мы используем приложение с одним идентификатором для входа в систему, а приложение с другим идентификатором при подключении учетной записи электронной почты.

Мы сделали это специально, так как это две совершенно разные функции.

Приложение для входа не требовало никакой проверки, и мы не хотели, чтобы сбой приложения с ограниченными областями API приводил к отключению приложения проверки.



Как мы проходили проверку безопасности Google

20 апреля Наконец-то мы прошли первый этап тестирования на соответствие Политике данных Google!

Прохождение второго этапа



Шаг 1. Выбор компании для прохождения проверки

Для второго этапа тестирования нашего приложения Google прислал на выбор контакты двух компаний — Бишоп Фокс И Левиафан Безопасность .

Сдать анализы можно было только у них.

Срок был указан заранее 31 декабря .

20 мая Мы отправили письма двум независимым экспертам для проверки.

Бишоп Фокс и компания Leviathan Security прислали опросники с вопросами о нашем заявлении.

Нужно было ответить, какие данные Google мы используем, сколько строк кода написано для каждого языка программирования, а также вопросы о нашей инфраструктуре, процессе развертывания программного обеспечения и хостинг-провайдере.

Мы все заполнили и стали ждать предложения с ценой.



Как мы проходили проверку безопасности Google

В ходе подготовки и предварительного общения с представителями компании мы узнали, что хостинг, на котором расположены наши сервера, не соответствует требованиям СОК2 .

И чтобы успешно пройти тест, нам нужно было перейти в соответствующий SOC2-хостинг .

Мы думали о переезде в Амазонка , поэтому мы начали процесс перемещения одновременно.

Также мы узнали, что нам нужна программа Награда за ошибки , предлагаемый многими веб-сайтами и разработчиками программного обеспечения.

С его помощью люди могут получить признание и вознаграждение за обнаружение ошибок, особенно связанных с эксплойтами и уязвимостями.

В сентябре у нас было два завершенных контракта с Bishop Fox и Leviathan Security. Нам нужно было решить, с кем заключить контракт. Мы не знали, по каким критериям выбирать эксперта, но контракт с Leviathan Security показался нам более прозрачным, несмотря на то, что стоил он несколько дороже.



Шаг 2. Подписание договора и подготовка к проверке

8 октября мы подписали соглашение с Leviathan Security. На момент подписания договора мы еще не завершили процесс переезда на Amazon. Поэтому в нашем договоре был пробел в графе «хостинг» и нам пришлось его ввести позже.

Также мы узнали, что будет включать в себя проверка:

  • Тест на проникновение во внешнюю сеть
  • Тестирование на проникновение приложений
  • Обзор развертывания
  • Обзор политики и процедур
И следующие шаги:
  • Подготовка
  • Оценка
  • Верификация и валидация
  • Заключительный отчет
Проверка длится примерно месяц.

В его стоимость входит время на устранение найденных уязвимостей.

После чего проводится повторная проверка.

В результате проверки мы должны были получить Письмо об оценке (LOA), которое затем нужно было отправить представителям Google. Но эксперт не гарантирует получение LOA как 100% результата оценки.

23 октября Компания Leviathan Security прислала анкету для самооценки (SAQ).

Наряду с этим мы также предоставили наши политики, необходимые для прохождения аудита:

  • План реагирования на инциденты: устанавливает роли, обязанности и действия при возникновении инцидента.

  • Политика управления рисками: выявляет, уменьшает и предотвращает нежелательные инциденты или результаты.

  • Политика раскрытия уязвимостей: предоставляет внешним сторонам возможность сообщать об уязвимостях.

  • Политика информационной безопасности: гарантирует, что все пользователи соблюдают правила и рекомендации, касающиеся безопасности информации, хранящейся в цифровом виде, в любой точке сети.

  • Политика конфиденциальности: гарантирует, что пользователи могут удалять свои учетные записи и связанные с ними пользовательские данные, демонстрируя удаление учетной записи, если это необходимо.

8 ноября Состоялась Внешняя координационная встреча, на которой мы обсудили все организационные вопросы и определили мессенджера для общения ( Слабый ) и кратко рассказал о нашем приложении.

Нас предупредили, что нужно будет предоставить доступ к исходному коду — для нас это не было проблемой.

На встрече мы узнали, что нам нужно шифровать токены Oauth с помощью КМС , то, чего мы еще не делали.

Мы также обсудили примерное время нашей проверки.

Нас заверили, что если оно запланировано на конец года и мы не успеем его завершить, Leviathan Security проведет переговоры с Google о продлении срока.

14 ноября Мы получили информацию о планируемом начале нашей проверки: конец декабря или начало января.

А компания Leviathan Security предупредила Google, что мы можем предоставить LOA позже установленного срока.

16 ноября Мы получили подтверждение от Google о том, что срок перенесен на 31 марта.



Шаг 3: Проверьте

13 декабря мы получили письмо, в котором нас уведомляли, что проверка начнется 2 января, и просили выполнить следующие требования: 1. Подтвердить возможность проведения проверки.

2. Введите необходимую информацию еще раз.

Документы нужно было загрузить в общую папку на OneDrive за неделю до проверки — до 26 декабря .

Никаких дополнительных документов, кроме необходимых, мы не предоставили:

  • План реагирования на инциденты
  • Политика управления рисками
  • Политика раскрытия уязвимостей
  • Политика информационной безопасности
  • политика конфиденциальности
  • Сопроводительная документация по конфиденциальности
  • Условия и положения
  • Анкета для самооценки (SAQ)
  • документация для внешних методов API
  • тестовые аккаунты для приложения
  • список внешних URL-адресов
  • Диаграмма высокого уровня нашей архитектуры
  • список основных компонентов IP
3. Обеспечить доступ к исходному коду.

4. Пригласите в Slack конкретных людей.

5. Укажите номер телефона и подробную информацию для эскалации проекта.

6. Предоставьте информацию о том, как нам следует выставлять счета.

7. Сообщите командам внутренней безопасности, CDN и хостинг-провайдерам, что проверка будет проходить со 2 по 27 января.

8. Создайте общую папку в OneDrive. 9. Прочтите часто задаваемые вопросы вопросы Гугл проверяет. 30 декабря Состоялась стартовая встреча, на которой практически все было так же, как и в первой встрече.

Мы представились, описали продукт с набором технологий и подтвердили, что наша система стабильна и что в ходе оценки продукта не будет выпускаться никаких крупных релизов.

Все закончилось вопросами и комментариями.

2 января Проверка безопасности началась.

Отметим, что оно прошло без особых трудностей.

Иногда это было неудобно из-за разницы часовых поясов — все звонки и общение мы проводили в Slack в нерабочее время.

Мы нашли довольно много уязвимостей — высоких и критических.

Такие уязвимости обязательно нужно было исправить.

Уязвимости среднего уровня и ниже могут быть исправлены по вашему усмотрению.

На исправление было дано 30 дней.

Но мы их исправили буквально на следующий день.

Уязвимости в основном были связаны с устаревшими методами шифрования пользовательских данных и недостаточным протоколированием.

К нашим программным документам претензий не было.

Политический отдел Leviathan Security задал несколько дополнительных вопросов и сказал, что они выглядят солидно.

Недостатка в общении не было.

Все неясные вопросы мы могли уточнить на статусных встречах или в Slack. Отчеты об уязвимостях были хорошо описаны, а также содержали рекомендации по исправлению.

В последний день нашей оценки все критические, высокие, а также некоторые средние и низкие уязвимости были исправлены и проверены.

31 января мы получили LOA и отправили его представителям Google. 11 февраля получил подтверждение проверки от Google.

Как мы проходили проверку безопасности Google

Для нас самым трудным было неизвестность.

Что ожидать? Как все будет происходить? Мы чувствовали себя первооткрывателями.

Нигде не было информации о том, как другие компании прошли эту проверку, что побудило нас поделиться информацией о Security Checkup с другими.

Для тех, кто только собирается пройти такое испытание, хотим сказать, что это не так страшно, как может показаться.

Да, процесс трудоемкий, но времени на исправление всех уязвимостей хватит. Несмотря на то, что на прохождение проверки безопасности Google у нас ушел год, время не было потрачено зря.

Мы можем продолжать использовать жизненно важный для нас API Google, а также закрыть уязвимости, которые впоследствии могут снова преследовать нас или наших клиентов.

Есть компании, например Context.io, которые решили не проходить проверку и закрылись.

Есть такие, которые продолжают работать без доступа к API, но при этом теряют свою репутацию в глазах пользователей.

Каждому бизнесу, которому необходимо пройти проверку, конечно, придется самостоятельно взвесить все «за» и «против».

Сложнее всего придется совсем молодым компаниям, у которых еще нет прибыли.

Но если у бизнеса есть ресурсы для прохождения проверки, то это определенно стоит сделать.

Надеемся, что наш опыт поможет Вам в этом! Теги: #облачные сервисы #Google API #проверка безопасности Google #проверка API oauth

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.