Keselamatan Awan: Mengesan Kesilapan Konfigurasi di AWS, Azure dan GCP
Pemindahan beban kerja ke awan AWS, Azure dan GCP telah meningkatkan kelajuan, tetapi turut memperkenalkan kategori kerentanan baharu yang tidak wujud dalam pusat data tradisional. Kebanyakan pelanggaran awan di Malaysia berpunca daripada kesilapan konfigurasi, bukan eksploitasi hari sifar (zero-day). Panduan ini menerangkan model tanggungjawab bersama (shared responsibility model), kesilapan konfigurasi yang paling lazim, perbezaan antara pengurusan postur keselamatan awan (CSPM) dengan pentest awan serta keperluan garis dasar RMiT untuk beban kerja awan. Panduan ini ditujukan kepada pasukan platform dan keselamatan yang mengurus infrastruktur awan bagi perniagaan di Malaysia.
Model Tanggungjawab Bersama: Perkara yang Sebenarnya Anda Kawal
Salah faham yang paling biasa tentang awan ialah pengguna menganggap pembekal (AWS, Azure, GCP) bertanggungjawab atas 'keselamatan'. Hakikatnya jauh lebih rumit. Pembekal bertanggungjawab atas keselamatan awan itu sendiri, iaitu infrastruktur fizikal, hipervisor dan rangkaian asas. Anda pula bertanggungjawab atas keselamatan di dalam awan, iaitu konfigurasi, IAM, kawalan akses, data anda dan kod anda.
Bagi IaaS (EC2, VM), anda bertanggungjawab atas sistem pengendalian (OS), penampalan dan keselamatan aplikasi. Bagi PaaS (RDS, App Service, Cloud SQL), pembekal menguruskan OS, tetapi anda masih bertanggungjawab atas skema pangkalan data, kawalan akses dan kod aplikasi. Bagi SaaS (M365, Workspace), anda bertanggungjawab atas konfigurasi penyewa (tenant) dan data.
Garis pembahagian ini selalunya samar dalam amalan. Tiada pembekal yang akan membetulkan dasar IAM yang membenarkan akses awam ke baldi anda kerana itu ialah konfigurasi anda. Begitu juga, kebocoran kunci API dalam repositori GitHub anda bukan tanggungjawab pembekal.
Kesilapan Konfigurasi yang Paling Lazim
Berdasarkan tugasan awan yang kami jalankan, beberapa corak kesilapan konfigurasi muncul dengan kekerapan yang tinggi. Mengetahui corak ini ialah langkah pertama untuk mengurangkannya.
Masalah pertama ialah baldi S3 yang terdedah secara awam atau yang membenarkan penyenaraian kandungan. Banyak kebocoran data di Malaysia bermula daripada baldi yang dikonfigurasikan supaya membenarkan akses awam secara 'sementara', kemudian dilupakan. AWS telah memperkenalkan Block Public Access dan kawalan lalai yang lebih ketat, tetapi konfigurasi lama masih wujud.
Masalah kedua ialah peranan IAM atau prinsipal perkhidmatan (service principal) yang mempunyai keizinan terlalu luas. 'AdministratorAccess' diberikan kepada CI/CD, Lambda atau VM yang sepatutnya hanya memerlukan beberapa keizinan. Apabila kredensial bocor, penyerang mendapat kuasa penuh.
Masalah ketiga ialah kunci yang ditanam terus dalam kod (hardcoded), imej kontena atau pemboleh ubah persekitaran yang dijejaki dalam kawalan versi. Salah satu cara terpantas penyerang mendapat akses ke persekitaran awan ialah dengan mengimbas repositori awam secara meluas untuk mencari pola kunci API.
- Storan awam (S3, Blob, GCS) tanpa kawalan akses yang betul.
- Peranan IAM dengan keistimewaan berlebihan yang melanggar prinsip keistimewaan minimum (least privilege).
- Kunci API ditanam terus dalam repositori atau imej.
- Pengelogan dan pemantauan tidak diaktifkan (CloudTrail, Activity Log, Audit Logs).
- Peraturan kumpulan keselamatan, NSG atau tembok api yang membenarkan 0.0.0.0/0 untuk RDP/SSH.
- Kredensial lalai masih wujud dalam pangkalan data atau perkhidmatan terurus.
- Penyulitan data semasa disimpan (at-rest) atau semasa dihantar (in-transit) tidak dilaksanakan.
- Tiada pemisahan beban kerja (satu akaun atau langganan sahaja untuk pembangunan dan produksi).
CSPM dan Pentest Awan: Perbezaan dan Sifat Saling Melengkapi
Pengurusan Postur Keselamatan Awan (Cloud Security Posture Management, CSPM) ialah alat automatik yang menyemak konfigurasi awan anda secara berterusan berdasarkan garis dasar. Contohnya termasuk AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center serta alat pihak ketiga seperti Wiz, Lacework atau Prisma Cloud.
CSPM sangat berguna untuk mengesan konfigurasi yang tidak betul: baldi awam, penyulitan tidak aktif dan keizinan IAM yang luas. Alat ini mengimbas secara berterusan dan menghasilkan papan pemuka. Namun, CSPM tidak mengeksploitasi kelemahan, jadi ia tidak menunjukkan sama ada kerentanan A boleh dirangkaikan dengan kerentanan B sehingga menyebabkan data sebenar dicuri keluar.
Pentest awan ialah aktiviti manusia yang dipandu oleh objektif. Penguji bermula daripada satu titik (mungkin kredensial yang bocor, akses pengguna yang terhad atau hanya sambungan internet) dan cuba bergerak secara lateral untuk mencapai matlamat, biasanya akses kepada data sensitif atau pengambilalihan akaun root. Pentest ini mendedahkan rantaian eksploitasi yang tidak dapat dikesan oleh CSPM.
Strategi yang matang menggunakan kedua-duanya: CSPM untuk kebersihan konfigurasi secara berterusan dan pentest awan tahunan untuk mendedahkan kelemahan kontekstual.
Perbandingan AWS, Azure dan GCP
Walaupun konsep keselamatannya sama, setiap platform mempunyai istilah dan perangkap yang tersendiri. Jadual berikut meringkaskan masalah konfigurasi yang paling kerap menyebabkan insiden.
| Kategori | AWS | Azure | GCP |
|---|---|---|---|
| Storan awam | Baldi S3 dengan ACL awam | Akses 'public' pada kontena Blob | Baldi GCS dengan allUsers |
| Identiti terlalu luas | IAM AdministratorAccess pada peranan | Owner pada langganan | roles/owner pada projek |
| Rangkaian terbuka | Kumpulan keselamatan 0.0.0.0/0 untuk SSH/RDP | Peraturan masuk NSG Any-Any | Peraturan tembok api 0.0.0.0/0 untuk SSH |
| Log audit tidak aktif | CloudTrail tidak meliputi semua wilayah | Activity Log tidak dieksport | Audit Logs Data Access tidak aktif |
| Kunci tidak dirotasikan | Kunci akses berumur lebih daripada 90 hari | Rahsia prinsipal perkhidmatan yang tidak pernah tamat tempoh | Kunci akaun perkhidmatan tidak dirotasikan |
| Penyulitan tidak konsisten | Volum EBS tanpa penyulitan | Cakera tanpa Azure Disk Encryption | Persistent Disk tanpa CMEK |
| MFA tidak dikuatkuasakan | Akaun root tanpa MFA | Global Admin tanpa MFA | Pentadbir organisasi tanpa MFA |
Konteks BNM RMiT dan Garis Dasar Awan
RMiT menetapkan jangkaan yang jelas bagi penggunaan awan dalam institusi kewangan: penilaian risiko, usaha wajar terhadap pembekal, perjanjian pemprosesan data, lokasi data dan kawalan teknikal. Pentest awan ialah cara praktikal untuk memberikan bukti kepada juruaudit bahawa kawalan ini diuji, bukan sekadar didokumentasikan.
Bagi bank dan syarikat insurans, BNM sering bertanya tentang pemisahan beban kerja (akaun atau langganan yang berasingan untuk produksi, pembangunan dan pembekal), kawalan kunci penyulitan (BYOK atau HYOK untuk data sensitif), dan pengelogan berpusat yang tidak boleh diubah suai oleh pengendali awan.
Bagi syarikat teknologi kewangan (fintech) yang ingin mendapatkan lesen BNM atau bekerjasama dengan bank berlesen, permintaan laporan pentest awan serta SOC 2 atau ISO 27001 sebagai prasyarat ialah pendorong utama. Pelaburan dalam garis dasar awan yang ketat sejak hari pertama menjimatkan kos pemulihan pada kemudian hari.
Pendekatan Praktikal untuk Pasukan Platform
Tidak semua organisasi mempunyai belanjawan untuk pentest awan tahunan oleh firma luar. Pendekatan praktikal yang kami syorkan untuk pasukan platform bersaiz sederhana ialah seperti berikut. Pertama, aktifkan dan laraskan CSPM (sama ada alat terbina dalam platform atau alat pihak ketiga) supaya isu konfigurasi dapat dikesan dalam masa beberapa minit, bukan beberapa bulan.
Kedua, laksanakan infrastruktur sebagai kod (Infrastructure-as-Code: Terraform, CloudFormation, Bicep, Pulumi) bersama dasar sebagai kod (policy-as-code: OPA, Checkov, tfsec) supaya pelanggaran garis dasar tidak boleh dilancarkan ke dalam produksi. Langkah ini memindahkan keselamatan ke peringkat lebih awal dalam saluran paip pembangunan.
Ketiga, jalankan pentest awan sekali setahun atau selepas perubahan besar (migrasi besar atau akuisisi). Bagi organisasi yang mempunyai beban kerja sensitif yang sangat dinamik, model ujian berterusan melalui PTaaS ialah pilihan yang munasabah.
Bacaan Lanjut dan Perkhidmatan nCrypt
Soalan Lazim
Adakah kami perlu melakukan pentest awan jika kami sudah mempunyai SOC 2 daripada pembekal?
Ya. SOC 2 yang dihasilkan oleh pembekal anda (AWS, Azure, GCP) hanya meliputi keselamatan platform mereka, bukan konfigurasi anda. Anda boleh mempunyai pembekal dengan SOC 2 Type II yang sempurna, tetapi data masih bocor kerana baldi S3 anda bersifat awam. Pentest awan menguji konfigurasi dan data anda. Bagi keperluan pematuhan, juruaudit hampir selalu meminta laporan pentest yang merangkumi persekitaran awan anda yang tertentu, bukan sekadar sijil platform.
Bagaimanakah pentest awan mengelakkan kerosakan kepada beban kerja produksi?
Melalui peraturan penglibatan yang jelas. Pentest awan biasanya dijalankan dalam mod 'andaian pelanggaran yang dibenarkan' (authorized assumed breach), iaitu penguji diberi akses yang terhad dan cuba bergerak secara lateral tanpa melakukan tindakan yang merosakkan, seperti memadam sumber atau mencuri keluar data yang sebenar. Penguji bekerja dalam tempoh masa yang ditetapkan dan berhubung secara langsung dengan pasukan operasi anda. Pembekal awan (AWS, Azure, GCP) mempunyai dasar pentest yang membenarkan ujian terhadap akaun anda tanpa pemberitahuan terlebih dahulu, tetapi penguji yang baik tetap akan menyelaraskan ujian dengan pasukan platform.
Apakah perbezaan antara pentest awan dengan pasukan merah (red team)?
Pentest awan biasanya menumpukan perhatian kepada satu akaun atau langganan awan dengan objektif teknikal yang jelas (contohnya menguji semua baldi S3 dan peranan IAM). Pasukan merah pula lebih luas: penguji bermula tanpa sebarang akses (mungkin hanya berbekalkan nama syarikat) dan boleh menggabungkan pancingan data (phishing), risikan sumber terbuka (OSINT) dan eksploitasi web sebelum akhirnya bergerak ke persekitaran awan. Bagi organisasi yang baru pertama kali menguji awan mereka, pentest awan lebih tepat sasaran. Bagi organisasi yang matang dan ingin menguji program keselamatan secara keseluruhan, pasukan merah lebih bermakna.
Berbincang dengan Pasukan nCrypt
Pasukan kami yang sejajar dengan CREST membantu institusi kewangan, agensi kerajaan dan PKS Malaysia merancang ujian penembusan, pematuhan dan respons insiden. Dapatkan sebut harga atau tempah perbincangan percuma hari ini.