Get best of the week

Bagaimana kami melakukan pemeriksaan keamanan google

Untuk memastikan keamanan data pengguna, Google dengan hati-hati memeriksa semua aplikasi yang menggunakan cakupan API terbatas dan memiliki akses ke Data Pengguna Google. Belum lama ini, kami di Snov.io menjalani proses verifikasi dan menerima persetujuan Google, yang ingin kami bagikan.

Aturan baru untuk aplikasi


Pada 9 Oktober 2018, Google mengumumkan aturan baru untuk aplikasi yang menggunakan cakupan API terbatas Google. Itu termasuk 2 tahap verifikasi:

  • Verifikasi bahwa aplikasi Anda mematuhi kebijakan Data Pengguna Google API
  • Verifikasi persyaratan keamanan minimum

Verifikasi aplikasi lingkup terbatas memverifikasi kepatuhan dengan Kebijakan Data Pengguna Google API dan serangkaian kebijakan tambahan yang diuraikan dalam Persyaratan Tambahan untuk Lingkup API Tertentu. Pertama, aplikasi Anda akan ditinjau untuk kepatuhan dengan Layanan Google API: Kebijakan Data Pengguna. Setelah itu, Anda akan memiliki sisa tahun 2019 untuk menunjukkan kepatuhan dengan persyaratan penanganan yang aman.

Verifikasi kepatuhan dengan persyaratan keamanan minimum menghabiskan banyak uang - dari $ 15.000 hingga $ 75.000.
Penilaian akan dilakukan oleh penilai pihak ketiga yang ditunjuk Google, mungkin berharga antara $ 15.000 dan $ 75.000 (atau lebih) tergantung pada kompleksitas aplikasi, dan akan dibayarkan oleh pengembang. Biaya ini mungkin diperlukan apakah aplikasi Anda lulus penilaian atau tidak .

Pada 9 Januari 2019, Google memperketat aturan untuk aplikasi yang berencana menggunakan Google API. Untuk aplikasi yang menggunakan Google API sebelumnya, ada persyaratan untuk mengirimkan aplikasi untuk verifikasi sebelum 15 Februari . Jika tidak, akses ke aplikasi akan ditutup untuk pengguna baru mulai 22 Februari , dan pengguna yang sudah ada tidak dapat menggunakan aplikasi mulai 31 Maret .

Konsekuensi dari perkembangan seperti itu tidak menyenangkan. Ini disebabkan oleh fakta bahwa sejumlah besar pengguna kami (dan ada lebih dari 100 ribu) menggunakan Gmail. Karena itu, kami hanya akan kehilangan pelanggan ini.

Untuk proyek yang memerlukan tindakan, Anda harus mengirimkan aplikasi untuk verifikasi sebelum 15 Februari 2019. Jika tidak, akses untuk pengguna baru akan dinonaktifkan pada 22 Februari 2019, dan hibah yang ada untuk akun konsumen akan dicabut pada 31 Maret, 2019.

Bagaimana semuanya terjadi sebelum pembaruan?


Platform Snov.io kami telah menggunakan Google API sejak 2017. Aplikasi kami menggunakan beberapa cakupan terbatas: untuk membaca surat masuk dan untuk bekerja dengan konsep. 

Google sebelumnya telah menguji aplikasi yang menggunakan Google API. Untuk menerapkan ruang lingkup API baru, perlu menambahkannya ke konsol dan menunjukkan apa yang akan digunakan. Saat karyawan Google memeriksa aplikasi, pengguna melihat pemberitahuan "Aplikasi ini tidak diverifikasi" di layar mereka: 



Biasanya pemeriksaan ini memakan waktu 2-3 hari kerja (meskipun, dalam surat dari Google, ini menunjukkan bahwa prosesnya bisa bertahan hingga 7 hari) dan selalu berlalu tanpa masalah. Kami menunggu sampai Google memeriksa aplikasi kami dan hanya kemudian menuangkan fitur pada prod sehingga pengguna tidak akan melihat pemberitahuan "Aplikasi ini tidak diverifikasi". 

Lewat tahap pertama


Untuk mulai dengan, kami memutuskan untuk fokus pada tahap pertama verifikasi, yaitu, kepatuhan aplikasi kami dengan kebijakan Data Pengguna Google API. 

Pada 16 Januari, tombol Kirim untuk Verifikasi muncul di konsol Google dan kami mengirim aplikasi. Sebelum berangkat, kami memastikan bahwa kami mematuhi semua poin dalam kebijakan Data Pengguna Google API. Kami membuat perubahan pada kebijakan privasi kami, khususnya, menambahkan bagian Data Pengguna Google, yang menjelaskan secara rinci data apa yang diterima dari Google API yang kami simpan, bagaimana kami menggunakannya dan kapan kami menghapusnya. 

12 Februari, kami menerima tanggapan terhadap aplikasi yang diajukan. Kami diminta merekam video dan menunjukkan bagaimana kami menggunakan cakupan API terbatas yang diminta. 

Akibatnya, kami harus meninggalkan dua proyek kami di Google Cloud dan menggabungkannya menjadi satu. Kami meninggalkan proyek pertama untuk server uji, yang bekerja dalam mode uji, dan menggunakan proyek yang sama untuk pengujian seperti pada prod. Kami juga menghapus proyek kedua untuk otorisasi ke dalam sistem melalui Google dan sebagai gantinya menggunakan proyek yang memerlukan verifikasi untuk masuk. 

Perwakilan Google menjawab surat kami di suatu tempat setelah 2 minggu. Untuk pertanyaan, alih-alih jawaban langsung, kami menerima penawaran. Bagi kami, mereka memiliki skrip khusus untuk memeriksa aplikasi. 

Misalnya, kami diingatkan bahwa kami menggunakan aplikasi dengan satu ID untuk memasuki sistem, dan saat menghubungkan akun email, aplikasi dengan ID yang berbeda. Kami melakukan ini dengan sengaja, karena ini adalah dua fungsi yang sangat berbeda. Aplikasi masuk tidak memerlukan pemeriksaan apa pun dan kami tidak ingin kegagalan lulus verifikasi aplikasi dengan cakupan API terbatas untuk menonaktifkan aplikasi verifikasi.



Pada 20 April, kami akhirnya melewati tahap pertama Pemeriksaan Kepatuhan Kebijakan Data Google!

Lewat tahap kedua 


Langkah 1. Memilih perusahaan untuk lulus audit


Pada tahap kedua menguji aplikasi kami, Google mengirim kontak dari dua perusahaan untuk dipilih - Uskup Fox dan Leviathan Security . Itu mungkin untuk lulus hanya dengan mereka. Batas waktu diberikan hingga 31 Desember .

Pada 20 Mei, kami mengirim surat ke dua ahli independen untuk lulus audit. Uskup Fox dan Leviathan Security mengirim kuesioner dengan pertanyaan tentang aplikasi kami. Penting untuk menjawab data Google seperti apa yang kami gunakan, berapa baris kode yang ditulis untuk setiap bahasa pemrograman, serta pertanyaan tentang infrastruktur kami, proses penyebaran perangkat lunak, dan penyedia hosting. Kami mengisi semuanya dan mulai menunggu penawaran harga.



Selama persiapan dan komunikasi awal dengan perwakilan perusahaan, kami mengetahui bahwa hosting di mana server kami berada tidak sesuai dengan SOC2 . Dan untuk verifikasi yang berhasil, kami harus pindah ke hosting SOC2 yang sesuai . Kami telah lama berpikir untuk pindah ke Amazon , jadi kami memulai proses perpindahan secara paralel. 

Kami juga mengetahui bahwa kami memerlukan program Bug Bounty yang ditawarkan oleh banyak situs web dan pengembang perangkat lunak. Dengan itu, orang dapat menerima pengakuan dan penghargaan untuk menemukan bug, terutama yang terkait dengan eksploitasi dan kerentanan. 

Pada bulan September, kami memiliki dua kontrak siap pakai dari Uskup Fox dan Leviathan Security. Kami harus memutuskan dengan siapa untuk menyimpulkan kontrak. Kami tidak tahu kriteria untuk memilih seorang ahli, tetapi perjanjian dengan Leviathan Security tampak lebih transparan bagi kami, meskipun faktanya sedikit lebih mahal.

Langkah 2. Menandatangani kontrak dan mempersiapkan verifikasi


Pada 8 Oktober, kami menandatangani perjanjian dengan Leviathan Security. Pada saat menandatangani kontrak, kami belum menyelesaikan proses pemindahan ke Amazon. Karena itu, dalam kontrak kami di kolom "hosting" ada celah dan kami harus memasukkannya nanti.

Kami juga mempelajari verifikasi apa yang akan mencakup:

  • Uji Penetrasi Jaringan Eksternal 
  • Pengujian penetrasi aplikasi 
  • Ulasan Penerapan 
  • Tinjauan Kebijakan & Prosedur 

Dan langkah-langkah berikut:

  • Persiapan 
  • Penilaian
  • Verifikasi & validasi
  • Laporan terakhir

Cek berlangsung sekitar sebulan. Harganya termasuk waktu untuk menghilangkan kerentanan yang ditemukan. Kemudian pemeriksaan kedua dilakukan. Sebagai hasil dari verifikasi, kami seharusnya telah menerima Letter of Assessment (LOA), yang kemudian harus dikirim ke perwakilan Google. Tetapi ahli tidak menjamin penerimaan LOA sebagai hasil penilaian 100%. 

Pada 23 Oktober, Leviathan Security mengirim Self-Assessment Questionnaire (SAQ). Bersama dengannya, kami juga memberikan kebijakan yang diperlukan untuk lulus audit:

  • Rencana Tanggap Insiden: Menetapkan peran, tanggung jawab, dan tindakan saat insiden terjadi
  • Kebijakan Manajemen Risiko: Mengidentifikasi, mengurangi, dan mencegah insiden atau hasil yang tidak diinginkan
  • Kebijakan Pengungkapan Kerentanan: Menyediakan sarana bagi pihak eksternal untuk melaporkan kerentanan
  • 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

Pada 8 November, Rapat Penyelarasan Eksternal berlangsung, di mana kami membahas semua masalah organisasi, mengidentifikasi seorang pembawa pesan untuk komunikasi ( Slack ) dan secara singkat berbicara tentang aplikasi kami. Kami diperingatkan bahwa akan diperlukan untuk memberikan akses ke kode sumber - ini bukan masalah bagi kami. 

Pada rapat umum tersebut, kami mengetahui bahwa kami perlu mengenkripsi token Oauth menggunakan KMS , yang sebelumnya tidak kami lakukan. Kami juga membahas perkiraan waktu pemeriksaan kami. Kami yakin bahwa jika dia ditunjuk pada akhir tahun dan kami tidak punya waktu untuk melewatinya, Leviathan Security akan bernegosiasi dengan Google untuk memperpanjang batas waktu bagi kami.

14 NovemberKami menerima informasi tentang rencana awal inspeksi kami: akhir Desember atau awal Januari. Dan Leviathan Security memperingatkan Google bahwa kami dapat menyediakan LOA lebih lambat dari batas waktu. 

Pada 16 November, kami menerima konfirmasi dari Google bahwa batas waktu ditunda hingga 31 Maret.

Langkah 3. Verifikasi


Pada tanggal 13 Desember, kami menerima surat di mana kami diberitahu tentang awal audit - pada 2 Januari, dan diminta untuk memenuhi persyaratan berikut: 

1. Konfirmasikan kemungkinan audit.

2. Sekali lagi berikan informasi yang diperlukan. 

Dokumen harus diunggah ke folder bersama di OneDrive seminggu sebelum pemindaian - hingga 26 Desember . Kami tidak memberikan dokumen tambahan apa pun kecuali yang diperlukan: 

  • Rencana Tanggap Insiden
  • Kebijakan manajemen risiko
  • Vulnerability Disclosure Policy
  • Information Security Policy
  • Privacy Policy
  • Supporting Privacy Documentation
  • Terms and Conditions
  • Self Assessment Questionnaire (SAQ)
  • API
  • URL-
  • IP


3. Berikan akses ke kode sumber.

4. Undang orang tertentu ke messenger Slack.

5. Tunjukkan nomor telepon dan detail untuk peningkatan proyek.

6. Berikan informasi tentang bagaimana kita harus ditagih.

7. Beri tahu tim keamanan internal, CDN, dan penyedia hosting bahwa verifikasi akan berlangsung dari 2 Januari hingga 27 Januari.

8. Buat folder bersama di OneDrive.

9. Periksa Google Checkout Sering Diajukan Pertanyaan . 

30 Desemberpertemuan kick-off berlangsung, di mana hampir semuanya sama seperti pada rapat umum pertama. Kami memperkenalkan diri, mendeskripsikan produk dengan serangkaian teknologi dan mengkonfirmasi bahwa sistem kami stabil dan tidak ada rilis besar yang akan dirilis selama evaluasi produk. Itu berakhir dengan pertanyaan dan komentar. 

Pada 2 Januari, pemeriksaan keamanan dimulai. Perhatikan bahwa itu terjadi tanpa banyak kesulitan. Kadang-kadang itu tidak nyaman karena perbedaan zona waktu - semua panggilan dan komunikasi di Slack sudah kami miliki selama jam non-kerja untuk kami. 

Kami telah menemukan banyak kerentanan - tingkat tinggi dan kritis (tinggi dan kritis). Kerentanan seperti itu perlu diperbaiki. Kerentanan tingkat menengah dan bawah dapat dikoreksi atas kebijakan seseorang. Koreksi diberikan 30 hari. Tapi kami memperbaikinya secara harfiah pada hari berikutnya. 

Kerentanan tersebut terutama terkait dengan metode lama mengenkripsi data pengguna dan pencatatan yang tidak mencukupi. Tidak ada keluhan terhadap dokumen kebijakan kami. Departemen Kebijakan Keamanan Leviathan mengajukan beberapa pertanyaan klarifikasi dan mengatakan bahwa mereka tampak solid.

Tidak ada kekurangan komunikasi. Kita bisa mengklarifikasi semua masalah yang tidak jelas pada status demonstrasi atau di Slack. Laporan kerentanan didokumentasikan dengan baik dan juga menyertakan rekomendasi untuk memperbaiki. Pada hari terakhir penilaian kami, semua kerentanan kritis, tinggi, serta beberapa kerentanan sedang dan rendah telah diperbaiki dan diperiksa. 

31 Januari, kami menerima LOA dan mengirimkannya ke perwakilan Google.  

11 Februari menerima konfirmasi verifikasi dari Google.



Hal yang paling sulit bagi kami adalah hal yang tidak diketahui. Apa yang diharapkan? Bagaimana semuanya akan terjadi? Kami merasa seperti perintis. Tidak ada informasi tentang bagaimana perusahaan lain lulus dari tes ini, yang mendorong kami untuk berbagi informasi tentang Pemeriksaan Keamanan dengan yang lain.

Kami ingin mengatakan kepada mereka yang belum datang pemeriksaan seperti itu, bahwa hal itu tidak seseram kelihatannya. Ya, prosesnya memakan waktu, tetapi akan ada margin waktu yang baik untuk memperbaiki semua kerentanan. Terlepas dari kenyataan bahwa kami butuh satu tahun untuk menjalani Pemeriksaan Keamanan Google, kali ini tidak sia-sia. Kami dapat terus menggunakan Google API, yang sangat penting bagi kami, dan juga kerentanan tertutup yang selanjutnya bisa keluar ke samping bagi kami atau pelanggan kami.

Ada perusahaan, seperti Context.io, yang telah memutuskan untuk tidak lulus audit dan telah ditutup. Ada orang yang terus bekerja tanpa akses ke API, tetapi pada saat yang sama kehilangan reputasi mereka di mata pengguna. Setiap bisnis yang perlu diuji, tentu saja, harus secara independen menimbang pro dan kontra. Hal tersulit adalah bagi perusahaan yang sangat muda yang belum memiliki untung. Tetapi jika bisnis memiliki sumber daya untuk lulus ujian, maka itu pasti layak dilakukan.

Kami berharap pengalaman kami akan membantu Anda dalam hal ini!

More articles:


All Articles