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 pemadaman layanan. Sebaiknya rencanakan pengaktifan dengan cermat dan luangkan waktu untuk mengumpulkan data, melakukan pengujian, dan menganalisis log pelanggaran. Pastikan bahwa pemangku kepentingan dari tim operasi Kontrol Layanan VPC dan tim aplikasi Anda siap untuk tugas tersebut.

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

Mengoordinasikan komunikasi

Sering kali, tim keamanan jaringan atau pengaktifan cloud memimpin upaya pengaktifan Kontrol Layanan VPC. Sebaiknya Anda memiliki orang khusus yang 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 perimeter.
  • Pola akses resource:
    • Pengguna mengakses project di perimeter melalui Google Cloud Console.
    • Layanan atau alat 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 di dalam perimeter.

Setelah mengidentifikasi pola akses untuk workload, identifikasi kasus penggunaan Anda dan kategorikan 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.
  • Pemantauan dan penerapan keamanan layanan seperti Forseti atau SIEM yang berada di luar perimeter akan memakai 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 pola akses dan pelacak kasus penggunaan, lihat Template orientasi Kontrol Layanan VPC - kasus penggunaan (PDF).

Lakukan wawancara

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

  • Apakah kasus penggunaan Anda menjadi prioritas utama yang harus dipertimbangkan untuk pengaktifan Kontrol Layanan VPC? Sebaiknya Anda hanya mempertimbangkan beban kerja prioritas pertama untuk pengaktifan awal, dan mengaktivasi beban kerja lain yang kurang penting setelah melindungi resource bisnis yang penting.

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

  • Berapa lama waktu yang diperlukan untuk menjalankan kasus penggunaan?

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

Menyiapkan uji coba

Mode uji coba mengurangi kompleksitas penerapan Kontrol Layanan VPC pengujian dengan mengidentifikasi pelanggaran tanpa gangguan pada 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 menghasilkan log pelanggaran untuk dianalisis.

Untuk menyiapkan lingkungan uji coba, lakukan hal berikut:

  1. Identifikasi semua project yang memenuhi syarat untuk menjadi bagian dari perimeter, serta selesaikan kasus penggunaan dan proses wawancara untuk project tersebut.
  2. Buat perimeter uji coba dan tambahkan semua project.
  3. Pada perimeter layanan Kontrol Layanan VPC, di bagian Layanan Terbatas > 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 mengirimkan 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, larang akses ke layanan yang tidak didukung. Konfigurasikan perimeter Anda sehingga hanya fungsi layanan yang dibatasi dalam perimeter. Untuk melakukannya, konfigurasikan daftar layanan yang dapat diakses ke RESTRICTED-SERVICES.

  6. Jika Anda sudah memiliki daftar IP publik, identitas, perangkat, project, atau jaringan VPC tepercaya, tambahkan ke aturan ingress atau level akses sebagaimana berlaku di perimeter uji coba. Mengizinkan alur sah yang diketahui akan 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 mengeksekusi beban kerja mereka di project di perimeter uji coba. Pastikan Anda memiliki cakupan penuh untuk semua kode yang mungkin memanggil Google API. Setelah uji coba selesai, tim peninjau yang ditetapkan dapat melakukan analisis log pelanggaran.

Menganalisis pelanggaran

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

  • Layanan dilindungi dan metode API 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

Pelanggaran terkait kueri

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 beban kerja:

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

Tinjau log pelanggaran

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

  • Apakah identitas (email) diharapkan untuk memanggil API yang dilindungi?
  • Haruskah 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 penyuntingan Log Audit Cloud 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. Upaya akses semacam ini dapat berupa akses yang tidak disengaja oleh pengguna dari luar organisasi Anda. Misalnya, pengguna yang salah mengetik bucket dengan nama serupa.

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 semacam itu, 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