Wie haben wir die Google-Sicherheitsüberprüfung durchgeführt?

Um die Sicherheit der Nutzerdaten zu gewährleisten, überprüft Google sorgfältig alle Anwendungen, die eingeschränkte API-Bereiche verwenden und Zugriff auf Google-Nutzerdaten haben. Vor nicht allzu langer Zeit haben wir bei Snov.io den Überprüfungsprozess durchlaufen und die Genehmigung von Google erhalten, mit der wir teilen möchten.

Neue Regeln für Anwendungen


Am 9. Oktober 2018 kündigte Google neue Regeln für Anwendungen an, die die eingeschränkten API-Bereiche von Google verwenden. Sie umfassten zwei Überprüfungsstufen:

  • Stellen Sie sicher, dass Ihre Anwendung den Richtlinien für Google API-Benutzerdaten entspricht
  • Überprüfen Sie die Mindestsicherheitsanforderungen

Durch die Überprüfung der App mit eingeschränktem Gültigkeitsbereich wird die Einhaltung der Google API-Benutzerdatenrichtlinie und eines zusätzlichen Satzes von Richtlinien überprüft, die unter Zusätzliche Anforderungen für bestimmte API-Bereiche aufgeführt sind. Zunächst wird Ihre Anwendung auf Übereinstimmung mit den Google API Services: User Data Policy überprüft. Danach haben Sie den Rest des Jahres 2019 Zeit, um die Einhaltung der Anforderungen für die sichere Handhabung nachzuweisen.

Die Überprüfung der Einhaltung der Mindestsicherheitsanforderungen kostet viel Geld - von 15.000 bis 75.000 US-Dollar.
Die Bewertungen werden von einem von Google benannten externen Prüfer durchgeführt, können je nach Komplexität der Anwendung zwischen 15.000 und 75.000 USD (oder mehr) kosten und sind vom Entwickler zu zahlen. Diese Gebühr kann erforderlich sein, unabhängig davon, ob Ihre App die Bewertung besteht oder nicht .

Bereits am 9. Januar 2019 hat Google die Regeln für Anwendungen verschärft, die die Google-API verwenden möchten. Für Anwendungen, die früher die Google-API verwendeten, musste vor dem 15. Februar ein Antrag zur Überprüfung eingereicht werden . Andernfalls wäre der Zugriff auf die Anwendung ab dem 22. Februar für neue Benutzer gesperrt , und vorhandene Benutzer könnten die Anwendung ab dem 31. März nicht mehr verwenden .

Die Folgen einer solchen Entwicklung wären unangenehm. Dies liegt an der Tatsache, dass eine erhebliche Anzahl unserer Nutzer (und es gibt mehr als 100.000) Google Mail verwenden. Daher würden wir diese Kunden einfach verlieren.

Für Projekte, für die Maßnahmen erforderlich sind, müssen Sie Apps vor dem 15. Februar 2019 zur Überprüfung einreichen. Andernfalls wird der Zugriff für neue Benutzer am 22. Februar 2019 deaktiviert und bestehende Zuschüsse für Verbraucherkonten werden am 31. März widerrufen. 2019.

Wie ist alles vor den Updates passiert?


Unsere Snov.io- Plattform verwendet seit 2017 die Google-API. Unsere Anwendung verwendete mehrere eingeschränkte Bereiche: zum Lesen eingehender E-Mails und zum Arbeiten mit Entwürfen. 

Google hat zuvor Anwendungen getestet, die die Google-API verwenden. Um den neuen API-Bereich anzuwenden, musste er der Konsole hinzugefügt und angegeben werden, wofür er verwendet werden soll. Während Google-Mitarbeiter die Anwendung überprüften, wurde auf ihren Bildschirmen die Benachrichtigung "Diese App wird nicht überprüft" angezeigt: 



Normalerweise dauerte diese Überprüfung 2-3 Werktage (obwohl in einem Brief von Google angegeben wurde, dass der Prozess bis zu 7 Tage dauern kann) und bestand immer ohne Probleme. Wir haben gewartet, bis Google unsere Anwendung überprüft und erst dann die Funktion auf das Produkt übertragen hat, damit die Benutzer die Benachrichtigung "Diese App wird nicht überprüft" nicht sehen. 

Passage der ersten Etappe


Zunächst haben wir uns auf die erste Phase der Überprüfung konzentriert, nämlich die Konformität unserer Anwendung mit der Google API-Richtlinie für Benutzerdaten. 

Am 16. Januar wurde in der Google-Konsole die Schaltfläche Zur Überprüfung senden angezeigt, und wir haben eine Bewerbung gesendet. Vor der Abreise haben wir sichergestellt, dass wir alle Punkte in der Google API-Richtlinie für Benutzerdaten einhalten. Wir haben Änderungen an unserer Datenschutzrichtlinie vorgenommen, insbesondere den Abschnitt "Google-Benutzerdaten" hinzugefügt, in dem ausführlich beschrieben wurde, welche Daten von der von uns gespeicherten Google-API empfangen wurden, wie wir sie verwenden und wann wir sie löschen. 

Am 12. Februar erhielten wir eine Antwort auf den eingereichten Antrag. Wir wurden gebeten, Videos aufzunehmen und zu zeigen, wie wir die angeforderten eingeschränkten API-Bereiche verwenden. 

Infolgedessen mussten wir unsere beiden Projekte in Google Cloud aufgeben und zu einem zusammenführen. Wir haben das erste Projekt für den Testserver abgebrochen, das im Testmodus funktioniert hat, und für den Test dasselbe Projekt wie für das Produkt verwendet. Wir haben auch das zweite Projekt für die Autorisierung im System über Google gelöscht und stattdessen das Projekt verwendet, für dessen Anmeldung eine Überprüfung erforderlich war. 

Vertreter von Google beantworteten unsere Briefe irgendwo nach 2 Wochen. Für Fragen erhielten wir anstelle direkter Antworten Angebote. Es schien uns, dass sie ein spezielles Skript haben, mit dem sie Anwendungen überprüfen. 

Wir wurden beispielsweise daran erinnert, dass wir eine Anwendung mit einer ID verwenden, um in das System einzutreten, und beim Verbinden eines E-Mail-Kontos eine Anwendung mit einer anderen ID. Wir haben dies absichtlich gemacht, da dies zwei völlig unterschiedliche Funktionen sind. Die Anmeldeanwendung erforderte keine Überprüfungen, und wir wollten nicht, dass der Fehler beim Bestehen der Anwendungsüberprüfung mit eingeschränkten API-Bereichen die Überprüfungsanwendung deaktiviert.



Am 20. April haben wir endlich die erste Phase des Google Data Policy Compliance Check bestanden!

Passage der zweiten Stufe 


Schritt 1. Auswahl eines Unternehmens zum Bestehen des Audits


In der zweiten Phase des Testens unserer Anwendung schickte Google Kontakte von zwei Unternehmen zur Auswahl - Bishop Fox und Leviathan Security . Der Scheck konnte nur mit ihnen bestanden werden. Die Frist wurde bis zum 31. Dezember angegeben .

Am 20. Mai haben wir zwei unabhängige Experten um das Bestehen des Audits gebeten. Bischof Fox und Leviathan Security schickten Fragebögen mit Fragen zu unserer Bewerbung. Es musste beantwortet werden, welche Art von Google-Daten wir verwenden, wie viele Codezeilen für jede Programmiersprache geschrieben werden sowie Fragen zu unserer Infrastruktur, dem Prozess der Softwarebereitstellung und dem Hosting-Anbieter. Wir füllten alles aus und warteten auf das Preisangebot.



Während der Vorbereitung und vorläufigen Kommunikation mit Unternehmensvertretern haben wir festgestellt , dass das Hosting, auf dem sich unsere Server befinden, nicht mit SOC2 übereinstimmt . Und für eine erfolgreiche Überprüfung mussten wir auf das entsprechende SOC2-Hosting umsteigen . Wir haben lange darüber nachgedacht, zu Amazon zu wechseln , und haben daher begonnen, parallel zu wechseln. 

Wir haben auch erfahren, dass wir das Bug Bounty- Programm benötigen, das von vielen Websites und Softwareentwicklern angeboten wird. Damit können Menschen Anerkennung und Belohnung für das Auffinden von Fehlern erhalten, insbesondere im Zusammenhang mit Exploits und Schwachstellen. 

Im September hatten wir zwei vorgefertigte Verträge von Bischof Fox und Leviathan Security. Wir mussten uns entscheiden, mit wem wir einen Vertrag abschließen wollten. Wir wussten nicht, für welche Kriterien wir einen Experten auswählen sollten, aber die Vereinbarung mit Leviathan Security schien uns transparenter zu sein, obwohl sie etwas mehr kostete.

Schritt 2. Unterzeichnung des Vertrags und Vorbereitung der Überprüfung


Am 8. Oktober haben wir eine Vereinbarung mit Leviathan Security unterzeichnet. Zum Zeitpunkt der Vertragsunterzeichnung haben wir den Umzug zu Amazon noch nicht abgeschlossen. Daher gab es in unserem Vertrag in der Spalte "Hosting" eine Lücke, die wir später eingeben mussten.

Wir haben auch erfahren, welche Überprüfung Folgendes umfasst:

  • Externer Netzwerk-Penetrationstest 
  • Prüfung der Anwendungspenetration 
  • Bereitstellungsüberprüfung 
  • Überprüfung von Richtlinien und Verfahren 

Und die folgenden Schritte:

  • Vorbereitung 
  • Bewertung
  • Überprüfung und Validierung
  • Abschlussbericht

Die Überprüfung dauert etwa einen Monat. Der Preis beinhaltet die Zeit, um die gefundenen Schwachstellen zu beseitigen. Dann wird eine zweite Prüfung durchgeführt. Als Ergebnis der Überprüfung hätten wir ein Letter of Assessment (LOA) erhalten müssen, das dann an Google-Vertreter gesendet werden muss. Der Experte garantiert jedoch nicht den Erhalt der LOA als 100% iges Ergebnis der Bewertung. 

Am 23. Oktober sandte Leviathan Security einen Fragebogen zur Selbsteinschätzung (Self-Assessment Questionnaire, SAQ). Zusammen mit ihr stellten wir auch unsere Richtlinien zur Verfügung, die zum Bestehen des Audits erforderlich waren:

  • Incident Response Plan: Legt Rollen, Verantwortlichkeiten und Aktionen fest, wenn ein Incident auftritt
  • Risikomanagementrichtlinie: Identifiziert, reduziert und verhindert unerwünschte Vorfälle oder Ergebnisse
  • Offenlegungsrichtlinie für Sicherheitslücken: Bietet externen Parteien die Möglichkeit, Sicherheitslücken zu melden
  • 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

Am 8. November fand ein externes Ausrichtungstreffen statt, bei dem wir alle organisatorischen Fragen diskutierten, einen Kommunikationsboten ( Slack ) identifizierten und kurz über unsere Anwendung sprachen. Wir wurden gewarnt, dass der Zugriff auf den Quellcode erforderlich sein würde - dies war für uns kein Problem. 

Bei der Rallye haben wir gelernt, dass wir Oauth-Token mit KMS verschlüsseln müssen , was wir vorher nicht getan haben. Wir haben auch den ungefähren Zeitpunkt unserer Prüfung besprochen. Wir waren uns sicher, dass Leviathan Security mit Google verhandeln wird, um die Frist für uns zu verlängern, wenn sie Ende des Jahres ernannt wurde und wir keine Zeit hatten, dies durchzugehen.

14. NovemberWir haben Informationen über den geplanten Beginn unserer Inspektion erhalten: Ende Dezember oder Anfang Januar. Und Leviathan Security warnte Google, dass wir LOA später als die Frist bereitstellen könnten. 

Am 16. November erhielten wir von Google die Bestätigung, dass die Frist auf den 31. März verschoben wurde.

Schritt 3. Überprüfung


Am 13. Dezember erhielten wir ein Schreiben, in dem wir über den Beginn der Prüfung informiert wurden - am 2. Januar - und gebeten wurden, die folgenden Anforderungen zu erfüllen: 

1. Bestätigen Sie die Möglichkeit einer Prüfung.

2. Geben Sie erneut die erforderlichen Informationen ein. 

Dokumente mussten eine Woche vor dem Scan - bis zum 26. Dezember - in den freigegebenen Ordner auf OneDrive hochgeladen werden . Wir haben keine zusätzlichen Dokumente zur Verfügung gestellt, außer den erforderlichen: 

  • Incident Response Plan
  • Risikomanagementpolitik
  • Vulnerability Disclosure Policy
  • Information Security Policy
  • Privacy Policy
  • Supporting Privacy Documentation
  • Terms and Conditions
  • Self Assessment Questionnaire (SAQ)
  • API
  • URL-
  • IP


3. Stellen Sie den Zugriff auf den Quellcode bereit.

4. Laden Sie bestimmte Personen zum Slack Messenger ein.

5. Geben Sie die Telefonnummer und Details für die Eskalation des Projekts an.

6. Geben Sie an, wie wir abgerechnet werden sollen.

7. Informieren Sie die internen Sicherheitsteams, CDN- und Hosting-Anbieter darüber, dass die Überprüfung vom 2. bis 27. Januar stattfindet.

8. Erstellen Sie einen freigegebenen Ordner auf OneDrive.

9. Schauen Sie sich die häufig gestellten Fragen zu Google Checkout an

30. DezemberEs fand ein Kick-off-Meeting statt, bei dem fast alles so war wie bei der ersten Rallye. Wir haben uns vorgestellt, das Produkt mit einer Reihe von Technologien beschrieben und bestätigt, dass unser System stabil ist und dass während der Produktbewertung keine größeren Releases veröffentlicht werden. Es endete mit Fragen und Kommentaren. 

Am 2. Januar begann eine Sicherheitskontrolle. Beachten Sie, dass es ohne große Schwierigkeiten stattfand. Manchmal war es wegen der unterschiedlichen Zeitzonen unpraktisch - all die Anrufe und die Kommunikation in Slack, die wir bereits außerhalb der Geschäftszeiten hatten. 

Wir haben viele Schwachstellen gefunden - hohe und kritische Ebene (hoch und kritisch). Solche Schwachstellen mussten behoben werden. Sicherheitslücken der mittleren Ebene und darunter können nach eigenem Ermessen behoben werden. Die Korrektur erfolgte 30 Tage. Aber wir haben sie buchstäblich am nächsten Tag repariert. 

Die Sicherheitslücken waren hauptsächlich auf veraltete Methoden zur Verschlüsselung von Benutzerdaten und unzureichende Protokollierung zurückzuführen. Es gab keine Beschwerden gegen unsere Richtliniendokumente. Die Abteilung für Sicherheitspolitik von Leviathan stellte einige klärende Fragen und sagte, dass sie solide aussahen.

An Kommunikation mangelte es nicht. Wir könnten alle obskuren Fragen beim Status von Kundgebungen oder bei Slack klären. Schwachstellenberichte waren gut dokumentiert und enthielten auch Empfehlungen zur Behebung. Am letzten Tag unserer Bewertung wurden alle kritischen, hohen sowie einige mittlere und niedrige Schwachstellen behoben und überprüft. 

Am 31. Januar haben wir die LOA erhalten und an Google-Vertreter gesendet.  

Der 11. Februar erhielt eine Bestätigung der Bestätigung von Google.



Das Schwierigste für uns war das Unbekannte. Was zu erwarten ist? Wie wird alles passieren? Wir fühlten uns wie Pioniere. Nirgendwo gab es Informationen darüber, wie andere Unternehmen diesen Test bestanden haben, was uns dazu veranlasste, Informationen über die Sicherheitsüberprüfung mit anderen zu teilen.

Wir möchten denen sagen, denen eine solche Prüfung noch bevorsteht, dass sie nicht so beängstigend ist, wie es scheinen mag. Ja, der Vorgang ist zeitaufwändig, aber es wird eine gute Zeitspanne geben, um alle Schwachstellen zu beheben. Trotz der Tatsache, dass wir ein Jahr gebraucht haben, um die Google-Sicherheitsüberprüfung durchzuführen, wurde diese Zeit nicht verschwendet. Wir können weiterhin die für uns wichtige Google-API verwenden und auch Sicherheitslücken schließen, die später für uns oder unsere Kunden seitwärts auftreten können.

Es gibt Unternehmen wie Context.io, die beschlossen haben, das Audit nicht zu bestehen, und die geschlossen haben. Es gibt diejenigen, die weiterhin ohne Zugriff auf die API arbeiten, aber gleichzeitig ihren Ruf in den Augen der Benutzer verlieren. Jedes Unternehmen, das getestet werden muss, muss natürlich die Vor- und Nachteile unabhängig voneinander abwägen. Das Schwierigste wird für sehr junge Unternehmen sein, die noch keinen Gewinn haben. Aber wenn das Unternehmen über die Ressourcen verfügt, um den Test zu bestehen, lohnt es sich auf jeden Fall.

Wir hoffen, dass unsere Erfahrung Ihnen dabei helfen wird!

All Articles