Praktik terbaik untuk mengaktifkan Kontrol Layanan VPC

Dokumen ini menjelaskan proses yang direkomendasikan untuk mengonfigurasi dan menerapkan perlindungan Kontrol Layanan VPC di organisasi Google Cloud Anda.

Mengaktifkan Kontrol Layanan VPC secara sembarangan dapat menyebabkan masalah pada aplikasi yang ada dan berpotensi menyebabkan pemadaman layanan. Sebaiknya rencanakan pengaktifan dengan cermat dan luangkan waktu yang cukup untuk mengumpulkan data, melakukan pengujian, dan menganalisis log pelanggaran. Pastikan pemangku kepentingan dari tim operasi Kontrol Layanan VPC dan tim aplikasi Anda tersedia untuk tugas tersebut.

Untuk setiap workload atau aplikasi yang Anda aktivasi ke Kontrol Layanan VPC, Anda harus mengulangi proses pengaktifan.

Koordinasi komunikasi

Sering kali, tim keamanan jaringan atau aktivasi cloud memimpin upaya pengaktifan Kontrol Layanan VPC. Sebaiknya Anda memiliki seseorang yang khusus membuat dan melacak rapat lintas fungsi serta mendokumentasikan item tindakan. Tim Anda berkolaborasi terkait hal berikut:

  • Pola akses Google Cloud API
  • Identifikasi pelanggaran perimeter layanan
  • Mengizinkan akses ke perimeter

Sama seperti firewall jaringan konvensional, tujuannya adalah untuk mengidentifikasi dan mengizinkan alur yang diperlukan agar beban kerja bisnis yang sah dapat berfungsi secara efisien.

Mendokumentasikan pola akses dan kasus penggunaan

Untuk memulai proses pengaktifan, identifikasi dan dokumentasikan dengan jelas semua pola akses yang valid. Pola akses adalah jenis interaksi yang dapat diulang antara elemen di luar dan di dalam perimeter. Berikut adalah beberapa pola akses umum:

  • Pola akses data: Layanan di luar perimeter menyimpan atau mengambil data yang berada di dalam perimeter.
  • Pola akses resource:
    • Pengguna mengakses project di perimeter melalui konsol Google Cloud.
    • Alat atau layanan pihak ketiga mengelola dan mengakses resource di dalam perimeter.
    • Layanan atau resource dalam perimeter mengakses Google API.
  • Pola akses endpoint:
    • Pengguna mengakses resource dalam perimeter dari perangkat yang dikelola organisasi Anda.
    • Resource lokal berkomunikasi dengan resource dalam perimeter.

Setelah mengidentifikasi pola akses untuk beban kerja, identifikasi kasus penggunaan Anda dan kategorikan ke dalam salah satu pola akses dalam daftar sebelumnya. Berikut adalah beberapa kasus penggunaan umum:

  • Administrator cloud mengelola project yang merupakan bagian dari perimeter.
  • Layanan otomatisasi seperti Terraform, Jenkins, dan Microsoft Azure DevOps yang berada di luar perimeter mengelola deployment resource di dalam perimeter.
  • Layanan pengelolaan konfigurasi seperti Ansible, Chef, atau Puppet yang berada di luar perimeter mengelola deployment dan konfigurasi software pada resource yang berada di dalam perimeter.
  • Layanan pemantauan dan penegakan keamanan seperti Forseti atau SIEM yang berada di luar perimeter menggunakan data atau menerapkan kebijakan keamanan pada resource yang berada di dalam perimeter.

Untuk setiap kasus penggunaan, dokumentasikan hal berikut:

  • Pola akses
  • Pelaku yang dapat memicu kasus penggunaan
  • Kondisi yang memicu kasus penggunaan
  • Apakah kasus penggunaan adalah pola akses yang valid dan harus diizinkan
  • Asumsi apa pun yang berkaitan dengan kasus penggunaan

Untuk contoh pelacak kasus penggunaan dan pola akses, lihat Template orientasi Kontrol Layanan VPC - kasus penggunaan (PDF).

Melakukan wawancara

Lakukan wawancara dengan tim beban kerja Anda untuk mendiskusikan pola akses dan kasus penggunaan yang Anda kumpulkan dari template komunikasi sebelumnya. Berikut adalah contoh pertanyaan yang dapat Anda ajukan selama wawancara ini:

  • Apakah kasus penggunaan Anda merupakan prioritas pertama yang akan dipertimbangkan untuk pengaktifan Kontrol Layanan VPC? Sebaiknya Anda hanya mempertimbangkan beban kerja prioritas pertama untuk pengaktifan awal, dan melakukan aktivasi beban kerja lain yang kurang penting setelah melindungi resource penting bagi bisnis.

  • Dapatkah Anda menyelesaikan eksekusi komprehensif dari semua kasus penggunaan? Anda melakukannya untuk memicu semua kemungkinan skenario perimeter sehingga Anda dapat menganalisis sepenuhnya dan mengonfirmasi bahwa aplikasi akan berfungsi dengan benar setelah Anda menerapkan perimeter.

  • Berapa lama waktu yang diperlukan untuk menjalankan eksekusi kasus penggunaan?

  • Apakah Anda merencanakan perubahan besar pada workload ini yang mungkin bertentangan dengan pengaktifan VPC Service Controls? Fitur beban kerja harus dalam status stabil sebelum Anda mengaktifkan Kontrol Layanan VPC.

Menyiapkan uji coba

Mode uji coba mengurangi kompleksitas pengujian penerapan Kontrol Layanan VPC dengan mengidentifikasi pelanggaran tanpa mengganggu aplikasi. Anda mengonfigurasi uji coba sebagai perimeter terpisah yang mencatat semua pelanggaran, tetapi tidak melakukan pemblokiran apa pun. Anda dapat menjalankan beban kerja saat berada dalam perimeter uji coba dan membuat log pelanggaran untuk dianalisis.

Untuk menyiapkan lingkungan uji coba, lakukan hal berikut:

  1. Identifikasi semua project yang memenuhi syarat untuk menjadi bagian dari perimeter, dan selesaikan kasus penggunaan dan proses wawancara untuk project tersebut.
  2. Buat perimeter uji coba dan tambahkan semua project.
  3. Di perimeter layanan Kontrol Layanan VPC, di bagian Layanan yang Dibatasi > Layanan yang akan dilindungi, tambahkan semua layanan yang didukung.

  4. Buat sink logging gabungan yang mengirim semua log ke BigQuery, atau buat sink log untuk setiap project yang mengirim log uji coba ke set data BigQuery umum. Untuk membuat kueri pesan log ini dan mengidentifikasi pelanggaran Kontrol Layanan VPC, Anda dapat menggunakan kueri SQL.

    Untuk membuat sink log yang menyertakan semua pesan log Kontrol Layanan VPC yang relevan, gunakan filter berikut:

    logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"

  5. Untuk keamanan maksimum, jangan izinkan akses ke layanan yang tidak didukung. Konfigurasikan perimeter Anda sehingga hanya layanan terbatas yang berfungsi di perimeter. Untuk melakukannya, konfigurasi daftar layanan yang dapat diakses ke RESTRICTED-SERVICES.

  6. Jika Anda sudah memiliki daftar IP publik, identitas, perangkat, project, atau jaringan VPC tepercaya yang diizinkan, tambahkan ke aturan masuk atau tingkat akses seperti yang berlaku di perimeter uji coba. Mengizinkan alur yang sah dan dikenal membantu mengurangi jumlah log pelanggaran dan memungkinkan peninjau berfokus pada peristiwa yang dapat ditindaklanjuti.

  7. Pastikan tidak ada VPC dalam project yang memiliki jalur keluar ke internet atau VIP pribadi.

  8. Pastikan semua VPC memiliki DNS *.googleapis.com yang mengarah ke restricted.googleapis.com.

    Di Detail zona, nama DNS *.googleapis.com memiliki restricted.googleapis.com di kolom Data

Menjalankan kasus penggunaan

Pada waktu yang disepakati, minta tim aplikasi Anda untuk menjalankan beban kerja mereka pada project dalam perimeter uji coba. Pastikan Anda memiliki cakupan penuh untuk semua kode yang mungkin memanggil Google API. Setelah uji coba selesai, tim peninjau yang Anda tetapkan dapat melakukan analisis log pelanggaran.

Menganalisis pelanggaran

Log pelanggaran uji coba berisi sebagian besar informasi yang Anda perlukan untuk menentukan apakah pelanggaran aplikasi memerlukan tindakan apa pun, seperti menambahkan identitas atau alamat IP ke daftar yang diizinkan perimeter. Data pelanggaran disimpan di tabel BigQuery cloudaudit_googleapis_com_policy. Berikut adalah elemen utama untuk menganalisis pelanggaran:

  • Layanan dan metode API yang dilindungi sedang dipanggil.
  • Project di dalam perimeter yang akan memblokir permintaan.
  • Email identitas yang memanggil API yang dilindungi.
  • Alamat IP pemanggil.
  • Jenis pelanggaran.

Contoh berikut adalah kueri BigQuery yang menampilkan semua detail pelanggaran:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
where JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') = "true" #ensure these are dry-run logs

Membuat kueri pelanggaran yang relevan

Strategi berikut dapat membantu Anda mengidentifikasi pelanggaran yang relevan:

  • Tambahkan penentu stempel waktu untuk periode waktu saat setiap aplikasi unik menjalankan kasus penggunaannya:

    WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'

  • Tambahkan filter untuk konvensi penamaan identitas atau project workload:

    WHERE where resource.labels.project_id like '%APPLICATION_NAME%'

Meninjau log pelanggaran

Saat Anda meninjau log pelanggaran, tentukan apakah hal berikut benar:

  • Apakah identitas (email) diharapkan untuk memanggil API yang dilindungi?
  • Apakah pemanggil diizinkan untuk memanggil API dari luar perimeter?

Berdasarkan kriteria sebelumnya, tentukan apakah Anda perlu mengizinkan identitas, perangkat, alamat IP, rentang CIDR, project, atau jaringan untuk mengakses perimeter dari luar.

Beberapa entri mungkin memiliki alamat IP private. Hal ini menunjukkan bahwa panggilan berasal dari jaringan Google, baik oleh layanan Google sendiri maupun oleh VPC dalam project yang berada di luar perimeter. Untuk layanan Google seperti penulis sink log, Anda perlu menambahkan akun layanan Google ke daftar yang diizinkan.

Entri tanpa email disebabkan oleh penerusan Cloud Audit Logs untuk operasi hanya baca yang ditolak karena kurangnya izin IAM. Dalam kasus tersebut, Anda dapat menggunakan alamat IP dan nama resource untuk memahami asal upaya akses. Jenis upaya akses ini mungkin adalah akses yang tidak disengaja oleh pengguna dari luar organisasi Anda. Misalnya, pengguna yang salah mengetik bucket dengan nama yang mirip.

Jika Anda melihat jenis pelanggaran SERVICE_NOT_ALLOWED_FROM_VPC, beban kerja mungkin menggunakan layanan yang didukung oleh Kontrol Layanan VPC, tetapi tidak ditambahkan ke daftar API yang dilindungi. Misalnya, jika IAM menyebabkan pelanggaran tersebut, administrator harus menambahkan IAM ke daftar layanan yang dapat diakses dengan menjalankan perintah Google Cloud CLI berikut:

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Anda dapat membuat dasbor Looker Studio untuk meninjau pelanggaran. Untuk mengetahui informasi selengkapnya, lihat Memantau pelanggaran Kontrol Layanan VPC di organisasi Google Cloud Anda dengan Looker Studio. Looker Studio sebelumnya dikenal sebagai Data Studio.

Langkah selanjutnya