Keselamatan Awan: Mengesan Salah Konfigurasi di AWS, Azure dan GCP
Pemindahan beban kerja ke awan AWS, Azure dan GCP telah meningkatkan kelajuan tetapi juga memperkenalkan kategori kerentanan baharu yang tidak wujud dalam pusat data tradisional. Kebanyakan pelanggaran awan di Malaysia berpunca daripada salah konfigurasi, bukan eksploitasi sifar-hari. Panduan ini menerangkan shared responsibility model, kesilapan konfigurasi paling lazim, perbezaan antara CSPM dan pentest awan, dan keperluan baseline RMiT untuk beban kerja awan. Sasaran: pasukan platform dan keselamatan yang mengurus infrastruktur awan untuk perniagaan Malaysia.
Shared responsibility model: apa yang Anda sebenarnya kawal
Salah faham paling biasa tentang awan ialah pengguna menganggap penyedia (AWS, Azure, GCP) bertanggungjawab untuk 'keselamatan'. Realitinya jauh lebih bernuansa. Penyedia bertanggungjawab untuk keselamatan AWAN — infrastruktur fizikal, hypervisor, dan rangkaian asas. Anda bertanggungjawab untuk keselamatan DI DALAM awan — konfigurasi, IAM, kawalan akses, data Anda dan kod Anda.
Untuk IaaS (EC2, VM), Anda bertanggungjawab untuk OS, patching dan keselamatan aplikasi. Untuk PaaS (RDS, App Service, Cloud SQL), penyedia menguruskan OS tetapi Anda masih bertanggungjawab untuk skema database, kawalan akses, dan kod aplikasi. Untuk SaaS (M365, Workspace), Anda bertanggungjawab untuk konfigurasi tenant dan data.
Garis pembahagian ini selalunya samar dalam praktik. Tidak ada penyedia yang akan membetulkan IAM policy yang membenarkan akses awam ke bucket Anda — itu adalah konfigurasi Anda. Begitu juga, kebocoran kunci API dalam GitHub Anda bukan tanggungjawab penyedia.
Kesilapan konfigurasi yang paling lazim
Daripada engagement awan yang kami jalankan, beberapa corak salah konfigurasi muncul dengan frekuensi tinggi. Mengetahui corak ini adalah langkah pertama untuk mengurangkannya.
S3 bucket terdedah secara awam atau membenarkan listing. Banyak kebocoran data Malaysia bermula dari bucket yang dikonfigurasi untuk 'sementara' membenarkan akses awam dan kemudian dilupakan. AWS telah memperkenalkan Block Public Access dan kawalan default yang lebih ketat, tetapi konfigurasi lama masih wujud.
IAM role atau service principal dengan keizinan terlalu luas. 'AdministratorAccess' diberikan kepada CI/CD, Lambda atau VM yang sepatutnya hanya memerlukan beberapa keizinan. Apabila kredensial bocor, penyerang mendapat kuasa penuh.
Kunci dikodkan keras dalam kod, container image, atau pembolehubah persekitaran yang dijejak ke version control. Salah satu cara penyerang paling cepat mendapat akses ke alam sekitar awan ialah secara meluas mengimbas repositori awam untuk pola kunci API.
- Storage publik (S3, Blob, GCS) tanpa kawalan akses yang betul.
- IAM/role over-privileged yang melanggar prinsip least privilege.
- Kunci API dikodkan keras dalam repo atau image.
- Logging dan monitoring tidak diaktifkan (CloudTrail, Activity Log, Audit Logs).
- Security group / NSG / firewall rules yang membenarkan 0.0.0.0/0 untuk RDP/SSH.
- Default credentials masih wujud dalam pangkalan data atau perkhidmatan terurus.
- Penyulitan data at-rest atau in-transit tidak dilaksanakan.
- Tiada pemisahan beban kerja (single account/subscription untuk dev dan prod).
CSPM vs pentest awan: perbezaan dan komplementariti
Cloud Security Posture Management (CSPM) adalah alat automatik yang berterusan menyemak konfigurasi awan Anda terhadap baseline. Contoh termasuk AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center, dan alat pihak ketiga seperti Wiz, Lacework atau Prisma Cloud.
CSPM bagus untuk menangkap konfigurasi yang tidak betul: bucket awam, encryption tidak aktif, IAM keizinan luas. Ia mengimbas secara berterusan dan menghasilkan dashboard. Tetapi CSPM tidak mengeksploitasi — ia tidak menunjukkan jika kerentanan A boleh dirangkai dengan B untuk menyebabkan eksfiltrasi sebenar.
Pentest awan adalah aktiviti manusia berpandukan objektif. Penguji bermula daripada satu titik (mungkin kredensial bocor, akses pengguna terhad, atau hanya internet) dan cuba bergerak secara lateral untuk mencapai matlamat — biasanya akses kepada data sensitif atau pengambilalihan akaun root. Ia mendedahkan rantai eksploitasi yang CSPM tidak boleh kesan.
Strategi matang menggunakan kedua-duanya: CSPM untuk hygiene berterusan, pentest awan tahunan untuk mendedahkan kelemahan kontekstual.
Perbandingan AWS, Azure dan GCP
Walaupun konsep keselamatan adalah sama, setiap platform mempunyai nomenclature dan jebakan khusus. Jadual berikut meringkaskan masalah konfigurasi yang paling kerap menyebabkan insiden.
| Kategori | AWS | Azure | GCP |
|---|---|---|---|
| Storan publik | S3 bucket public ACL | Blob container 'public' access | GCS bucket allUsers |
| Identiti terlalu luas | IAM AdministratorAccess pada role | Owner pada subscription | roles/owner pada projek |
| Network terbuka | SG 0.0.0.0/0 SSH/RDP | NSG Any-Any inbound | Firewall rule 0.0.0.0/0 SSH |
| Audit log tidak aktif | CloudTrail tidak multi-region | Activity Log tidak diekspot | Audit Logs Data Access tidak aktif |
| Kunci tidak dirotasi | Access key umur > 90 hari | Service principal secret kekal | Service account key tidak dirotasi |
| Penyulitan tidak konsisten | EBS volume tanpa encryption | Disk tanpa Azure Disk Encryption | Persistent Disk tanpa CMEK |
| MFA tidak dikuatkuasakan | Root account tanpa MFA | Global Admin tanpa MFA | Org admin tanpa MFA |
Konteks BNM RMiT dan cloud baseline
RMiT memperuntukkan jangkaan eksplisit untuk penggunaan awan dalam institusi kewangan: penilaian risiko, due diligence vendor, perjanjian pemprosesan data, lokasi data, dan kawalan teknikal. Pentest awan adalah cara praktikal untuk memberi bukti kepada juruaudit bahawa kawalan ini diuji, bukan sekadar didokumentasikan.
Bagi bank dan insurans, BNM sering bertanya tentang pemisahan beban kerja (account/subscription berasingan untuk production, development, dan vendor), kawalan kunci enkripsi (BYOK atau HYOK untuk data sensitif), dan logging berpusat yang tidak boleh diubah suai oleh operator awan.
Bagi fintech yang ingin mendapatkan lesen BNM atau bekerjasama dengan bank berlesen, kebanyakan disebabkan oleh permintaan untuk laporan pentest awan dan SOC 2 / ISO 27001 sebagai prasyarat. Pelaburan dalam baseline awan yang ketat sejak hari pertama menjimatkan kos remediation kemudian.
Pendekatan praktikal untuk pasukan platform
Tidak semua organisasi mempunyai bajet untuk pentest awan tahunan dengan firma luar. Pendekatan praktikal yang kami syorkan untuk pasukan platform pertengahan: pertama, aktifkan dan tune CSPM (samada native atau pihak ketiga) supaya isu konfigurasi tertangkap dalam masa minit, bukan bulan.
Kedua, laksanakan Infrastructure-as-Code (Terraform, CloudFormation, Bicep, Pulumi) dengan policy-as-code (OPA, Checkov, tfsec) supaya pelanggaran baseline tidak boleh di-deploy ke dalam produksi. Ini memindahkan keselamatan ke kiri dalam pipeline.
Ketiga, jalankan pentest awan sekali setahun atau selepas perubahan major (migrasi besar, akuisisi). Untuk organisasi dengan beban kerja sensitif yang sangat dinamik, model continuous testing dengan PTaaS adalah pilihan yang munasabah.
Bacaan Lanjut & Khidmat nCrypt
Soalan Lazim
Adakah kami perlu pentest awan jika kami sudah ada SOC 2 vendor?
Ya. SOC 2 yang dihasilkan oleh vendor Anda (AWS, Azure, GCP) hanya mencakupi keselamatan platform mereka — bukan konfigurasi Anda. Anda boleh mempunyai vendor SOC 2 Type II yang sempurna dan masih bocor data kerana S3 bucket Anda awam. Pentest awan menguji konfigurasi DAN data Anda. Bagi keperluan pematuhan, juruaudit hampir selalu meminta laporan pentest yang merangkumi alam sekitar awan tertentu Anda, bukan sekadar sijil platform.
Bagaimana pentest awan mengelakkan kerosakan kepada beban kerja produksi?
Rules of engagement yang jelas. Pentest awan biasanya dijalankan dalam mod 'authorized assumed breach' — penguji diberi akses terhad dan cuba bergerak secara lateral, tanpa melakukan tindakan merosakkan seperti memadam sumber atau mengeksfiltrasi data sebenar. Penguji bekerja dalam tetingkap masa yang ditetapkan, dengan komunikasi langsung dengan pasukan ops Anda. Penyedia awan (AWS, Azure, GCP) mempunyai dasar pentest yang membenarkan ujian terhadap akaun Anda tanpa pemberitahuan terlebih dahulu, tetapi penguji yang baik akan tetap menyelaras dengan pasukan platform.
Apakah perbezaan antara pentest awan dan red team?
Pentest awan biasanya menumpukan pada satu cloud account/subscription dengan objektif teknikal yang jelas (contohnya menguji semua S3 buckets dan IAM roles). Red team adalah lebih luas — penguji bermula dari sifar (mungkin hanya nama syarikat) dan boleh menggabungkan phishing, OSINT, eksploitasi web, dan akhirnya bergerak ke alam sekitar awan. Untuk organisasi yang baru pertama kali menguji awan mereka, pentest awan adalah lebih tepat sasaran. Untuk organisasi matang yang ingin menguji program keselamatan secara keseluruhan, red team adalah lebih bermakna.
Bincang dengan Pasukan nCrypt
Pasukan CREST-aligned kami membantu institusi kewangan, agensi kerajaan dan PKS Malaysia merancang ujian penembusan, pematuhan dan respons insiden. Dapatkan sebut harga atau tempah perbincangan percuma hari ini.