AWS Security Agent, MFA Email, dan Risiko Otomasi Penetration Testing

Pada 6 Agustus 2026, AWS mengumumkan bahwa AWS Security Agent mendukung MFA berbasis email untuk penetration testing. Dalam pengumuman tersebut, AWS menyatakan bahwa agent dapat menggunakan MFA berbasis email dan membuat alamat forwarding unik untuk setiap credential.

Bagi programmer, Head of Software Engineering, manager SDLC, dan calon CTO, kabar ini menarik karena menyentuh area yang sering menjadi bottleneck dalam security testing: bagaimana menguji sistem yang dilindungi MFA tanpa membuat prosesnya sepenuhnya manual.

Namun ada poin penting yang tidak boleh hilang: otomatisasi security testing tidak menghapus tanggung jawab authorization dan perlindungan credential. Semakin mudah sebuah agent melewati alur MFA yang sah untuk kebutuhan pengujian, semakin kuat pula governance yang harus disiapkan.

Apa yang diumumkan AWS

Fakta utama dari pengumuman AWS adalah:

• AWS Security Agent kini mendukung MFA berbasis email untuk penetration testing.
• Agent dapat membuat alamat forwarding unik untuk setiap credential.
• Fitur ini ditujukan untuk mendukung aktivitas penetration testing.

Saya membaca pengumuman ini sebagai peningkatan dukungan terhadap skenario testing yang lebih realistis. Banyak aplikasi internal dan eksternal memakai MFA berbasis email sebagai lapisan keamanan tambahan. Jika penetration testing dilakukan secara otomatis, MFA sering menjadi titik friksi karena membutuhkan akses ke kode, link, atau instruksi verifikasi yang dikirim ke email.

Dengan dukungan forwarding unik per credential, proses testing bisa dibuat lebih terstruktur. Tetapi struktur teknis saja tidak cukup. Tim tetap perlu memastikan siapa yang berwenang menjalankan test, akun mana yang boleh dipakai, target mana yang masuk scope, dan bagaimana akses email forwarding tersebut diaudit.

Kenapa MFA otomatis perlu governance ketat

MFA biasanya diposisikan sebagai kontrol untuk mengurangi risiko penyalahgunaan credential. Ketika kita mengotomatisasi sebagian alur MFA untuk penetration testing, kita sedang membuat jalur operasional khusus yang memang dirancang agar agent bisa menyelesaikan login atau alur verifikasi tertentu.

Itu sah jika dilakukan dalam scope yang jelas. Tetapi berbahaya jika dibiarkan tanpa batasan.

Risiko yang perlu diperhatikan antara lain:

1. Credential testing berubah menjadi credential operasional
   Akun yang awalnya dibuat untuk pentest bisa dipakai ulang di luar kebutuhan pengujian jika tidak dibatasi masa aktif, permission, dan ownership-nya.

2. Forwarding email menjadi titik lemah baru
   Alamat forwarding unik membantu isolasi, tetapi tetap perlu diperlakukan sebagai bagian dari secret handling. Jika forwarding disalahkonfigurasi, kode MFA atau link verifikasi bisa terekspos.

3. Scope test melebar tanpa disadari
   Agent yang berjalan otomatis bisa menyentuh endpoint, tenant, akun, atau environment yang tidak termasuk izin tertulis jika allowlist tidak ketat.

4. Audit sulit jika semua memakai akun bersama
   Penetration testing yang memakai shared account, shared mailbox, atau credential generik akan menyulitkan investigasi saat terjadi anomali.

5. Otomasi dianggap sebagai pengganti approval
   Ini jebakan umum. Karena tooling makin canggih, sebagian tim menganggap proses bisa langsung dijalankan. Padahal otorisasi tertulis tetap menjadi fondasi.

Prinsip yang saya pakai: automation with boundaries

Dalam konteks security automation, saya lebih nyaman memakai prinsip automation with boundaries. Artinya, automation boleh membantu eksekusi, tetapi batasan legal, bisnis, dan teknis harus didefinisikan sebelum agent berjalan.

Untuk fitur seperti MFA email dalam penetration testing, batasan minimal yang saya harapkan adalah:

• Scope tertulis.
• Target allowlist.
• Credential khusus untuk testing.
• Secret isolation.
• Forwarding email terpisah untuk setiap credential.
• Approval sebelum eksekusi.
• Audit log yang bisa ditelusuri.
• Rate limit.
• Kill switch.
• Pengujian hanya pada environment yang berizin.

Kontrol ini bukan formalitas. Kontrol inilah yang membedakan security testing yang profesional dari aktivitas yang berisiko melanggar izin atau merusak sistem.

Checklist sebelum mengaktifkan MFA email untuk pentest

Berikut checklist praktis yang bisa dipakai tim engineering dan security sebelum menjalankan automation semacam ini.

1. Pastikan scope tertulis dan disetujui

Sebelum agent berjalan, harus ada dokumen scope yang menyebutkan:

• Sistem yang boleh diuji.
• Environment yang boleh diuji, misalnya staging, pre-production, atau production jika memang disetujui.
• Rentang waktu pengujian.
• Jenis aktivitas yang diizinkan.
• Batasan eksplisit, termasuk sistem yang tidak boleh disentuh.
• Pemilik approval dari sisi bisnis dan engineering.

Saya tidak menyarankan menjalankan penetration testing pada sistem pihak lain, customer tenant, production workload, atau aset eksternal apa pun tanpa izin tertulis yang jelas.

2. Gunakan target allowlist, bukan blocklist

Untuk agent otomatis, allowlist jauh lebih aman dibanding blocklist. Daftar target yang boleh diuji sebaiknya dibuat eksplisit, misalnya domain, subdomain, IP, akun AWS, tenant, endpoint, atau aplikasi tertentu.

Jika target tidak ada di allowlist, agent harus berhenti. Jangan mengandalkan asumsi seperti “masih satu organisasi” atau “masih satu VPC”. Dalam pentest, batas teknis dan batas izin tidak selalu sama.

3. Buat credential khusus untuk testing

Credential yang dipakai agent sebaiknya bukan credential personal engineer dan bukan akun operasional. Gunakan credential khusus dengan prinsip least privilege.

Beberapa praktik yang saya anggap penting:

• Permission dibatasi hanya untuk kebutuhan skenario test.
• Masa berlaku credential dibatasi.
• Credential diberi label atau tag yang jelas.
• Credential tidak dipakai ulang untuk aktivitas non-testing.
• Credential dinonaktifkan setelah pengujian selesai.

Jika credential khusus ini dikompromikan, blast radius harus kecil.

4. Isolasi secret dan forwarding email

Karena AWS menyebut pembuatan alamat forwarding unik untuk setiap credential, tim perlu memperlakukan forwarding tersebut sebagai bagian dari rantai keamanan credential.

Praktiknya:

• Jangan gunakan mailbox bersama tanpa audit.
• Jangan campur forwarding pentest dengan email operasional.
• Simpan konfigurasi forwarding sebagai secret atau konfigurasi sensitif.
• Batasi siapa yang bisa membaca, mengubah, atau menghapus forwarding.
• Pastikan log akses tersedia.

Alamat forwarding unik membantu pemetaan antara credential dan alur MFA, tetapi manfaatnya hilang jika semua orang bisa mengakses hasil forwarding tanpa kontrol.

5. Wajib ada approval sebelum eksekusi

Approval bukan sekadar tanda tangan. Approval harus menjawab pertanyaan berikut:

• Siapa yang menjalankan test?
• Untuk tujuan apa?
• Kapan test dimulai dan berakhir?
• Apa dampak yang bisa terjadi?
• Siapa yang harus dihubungi jika ada insiden?
• Bagaimana rollback atau penghentian dilakukan?

Untuk organisasi yang lebih matang, approval bisa dihubungkan ke change management atau release governance. Untuk tim kecil, minimal gunakan issue tracker yang mencatat scope, approver, waktu, dan hasil.

6. Siapkan audit log yang bisa dipakai investigasi

Security testing otomatis harus meninggalkan jejak yang rapi. Log yang dibutuhkan biasanya mencakup:

• Credential yang dipakai.
• Target yang diakses.
• Timestamp aktivitas.
• Hasil utama dari skenario test.
• Event MFA atau email forwarding yang relevan.
• Operator atau pipeline yang memicu eksekusi.
• Perubahan konfigurasi sebelum dan sesudah test.

Audit log harus cukup detail untuk menjawab pertanyaan “apa yang terjadi”, bukan hanya “test berhasil atau gagal”.

7. Terapkan rate limit dan kill switch

Agent otomatis bisa menjalankan banyak request dalam waktu singkat. Jika rate limit tidak disiapkan, test bisa terlihat seperti abuse atau bahkan mengganggu layanan.

Minimal siapkan:

• Batas request per menit.
• Batas percobaan login.
• Batas percobaan MFA.
• Batas concurrency.
• Alarm saat pola traffic melewati ambang aman.
• Kill switch yang bisa menghentikan test dengan cepat.

Kill switch sebaiknya mudah diakses oleh penanggung jawab operasional, bukan hanya oleh engineer yang menulis script.

Dampaknya untuk SDLC dan kepemimpinan engineering

Untuk manager SDLC dan calon CTO, fitur seperti ini adalah pengingat bahwa security testing makin dekat dengan automation pipeline. Ini bagus, tetapi hanya jika governance ikut naik kelas.

Saya akan menempatkan MFA-aware penetration testing sebagai bagian dari proses yang lebih luas:

• Threat modeling sebelum implementasi fitur sensitif.
• Security test plan sebelum release besar.
• Credential dan secret management yang konsisten.
• Approval workflow untuk test yang berpotensi berdampak.
• Post-test review untuk memperbaiki kontrol.

Jangan jadikan automation sebagai alasan untuk mengurangi komunikasi dengan owner bisnis. Justru karena agent bisa bergerak cepat, owner bisnis perlu tahu kapan pengujian berjalan, apa risikonya, dan siapa yang bertanggung jawab jika terjadi efek samping.

Kesimpulan

Dukungan MFA berbasis email di AWS Security Agent dapat membantu penetration testing menjadi lebih realistis dan lebih mudah diotomatisasi, terutama pada aplikasi yang memakai email sebagai faktor verifikasi.

Tetapi manfaat tersebut harus dibarengi dengan governance yang kuat. Scope tertulis, allowlist, credential khusus, secret isolation, forwarding terpisah, approval, audit log, rate limit, kill switch, dan pengujian hanya pada environment berizin adalah baseline yang tidak boleh dinegosiasikan.

Bagi saya, pesan utamanya sederhana: security automation mempercepat eksekusi, bukan memindahkan tanggung jawab. Otorisasi, perlindungan credential, dan batasan pengujian tetap harus dikelola manusia dengan disiplin.

Referensi

• AWS Security Agent now supports email-based MFA for penetration testing