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.

Pengaktifan Kontrol Layanan VPC yang tidak hati-hati dapat menyebabkan masalah pada aplikasi yang ada dan berpotensi menyebabkan gangguan. Sebaiknya rencanakan pengaktifan dengan cermat dan berikan 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 ini.

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

Mengoordinasikan komunikasi

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

  • Pola akses APIGoogle Cloud
  • 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.

Pola akses dokumen 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 yang umum:

  • Pola akses data: Layanan di luar perimeter menyimpan atau mengambil data yang berada di dalam perimeter.
  • Pola akses resource:
    • Pengguna mengakses project dalam perimeter melaluiGoogle Cloud konsol.
    • 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 oleh organisasi Anda.
    • Resource lokal berkomunikasi dengan resource dalam perimeter.

Setelah mengidentifikasi pola akses untuk beban kerja, identifikasi kasus penggunaan Anda dan kategorikan berdasarkan 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 manajemen 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 penerapan 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
  • Aktor yang dapat memicu kasus penggunaan
  • Kondisi yang memicu kasus penggunaan
  • Verifikasi bahwa kasus penggunaan adalah pola akses yang valid dan harus diizinkan
  • Asumsi apa pun yang berkaitan dengan kasus penggunaan

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

Melakukan wawancara

Lakukan wawancara dengan tim workload 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 menjadi prioritas pertama untuk dipertimbangkan dalam pengaktifan Kontrol Layanan VPC? Sebaiknya hanya mempertimbangkan workload prioritas pertama untuk pengaktifan awal, dan mengaktifkan workload lain yang kurang penting setelah melindungi resource penting bisnis.

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

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

  • Apakah Anda merencanakan perubahan besar untuk workload ini yang mungkin bertentangan dengan pengaktifan Kontrol Layanan VPC? Fitur beban kerja harus dalam kondisi 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 workload saat berada di 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 serta proses wawancara untuk project tersebut.
  2. Buat perimeter uji coba dan tambahkan semua project.
  3. Di perimeter layanan VPC Service Controls, di bagian Restricted Services > Services to protect, 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 mencakup 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, konfigurasikan daftar layanan yang dapat diakses ke RESTRICTED-SERVICES.

  6. Jika Anda sudah memiliki daftar IP publik, identitas, perangkat tepercaya, project, atau jaringan VPC yang diizinkan, tambahkan ke aturan ingress atau tingkat akses sesuai yang berlaku di perimeter uji coba. Dengan mengizinkan alur yang diketahui sah, bisa mengurangi jumlah log pelanggaran dan memungkinkan peninjau berfokus pada peristiwa yang dapat ditindaklanjuti.

  7. Pastikan tidak ada VPC di project yang memiliki jalur egress 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 menjalankan workload mereka di project dalam perimeter uji coba. Pastikan Anda memiliki cakupan penuh semua kode yang mungkin memanggil Google API. Setelah uji coba selesai, tim peninjau yang Anda tunjuk 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, seperti menambahkan identitas atau alamat IP ke daftar yang diizinkan perimeter. Data pelanggaran disimpan dalam tabel BigQuery cloudaudit_googleapis_com_policy. Berikut adalah elemen utama untuk menganalisis pelanggaran:

  • Layanan dan metode API yang dilindungi yang 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 jangka 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 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 Cloud Audit Logs yang disamarkan untuk operasi hanya baca yang ditolak karena kurangnya izin IAM. Bila terjadi hal semacam itu, Anda dapat menggunakan alamat IP dan nama resource untuk memahami asal upaya akses. Upaya akses semacam ini mungkin merupakan 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, workload 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 berikutnya