Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memvalidasi Anda Respons Insiden Keamanan AWS konfigurasi
Setelah menyelesaikan orientasi, Anda dapat memvalidasi bahwa pendaftaran, sumber deteksi, izin AWS Identity and Access Management (IAM), penahanan, dan pemberitahuan dikonfigurasi dengan benar sebelum peristiwa keamanan nyata terjadi. Bagian ini menyediakan prosedur verifikasi langkah demi langkah menggunakan CLI AWS Management Console dan AWS CLI.
Topik
Sebelum Anda memvalidasi
Prasyarat untuk memvalidasi konfigurasi Respons Insiden Keamanan Anda
Untuk menyelesaikan langkah-langkah validasi ini, pastikan Anda memiliki yang berikut:
Konsol atau AWS Command Line Interface (AWS CLI) akses ke akun administrator yang didelegasikan (akun yang Anda tunjuk saat orientasi)
Wilayah AWS Tempat Anda mengaktifkan langganan
ID keanggotaan Anda (jika memvalidasi menggunakan) AWS CLI
Konfirmasikan kesiapan log
Respons Insiden Keamanan AWS tidak mengaktifkan sumber log atas nama Anda. Selama penyelidikan, insinyur mengandalkan log yang sudah ada di lingkungan Anda. Sebelum memvalidasi penyiapan Anda, konfirmasikan bahwa log berikut diaktifkan di semua akun yang tercakup dan Wilayah AWS. Tanpa log ini, insinyur Security Incident Response memiliki visibilitas terbatas selama penyelidikan. Aktifkan mereka sebelum melanjutkan.
AWS CloudTrail: jejak acara manajemen (wajib)
Log Aliran VPC Amazon (disarankan)
Pencatatan akses server Amazon S3 untuk bucket sensitif (disarankan)
Pencatatan kueri DNS Amazon Route 53 Resolver (disarankan)
Verifikasi GuardDuty diaktifkan
Gunakan perintah berikut untuk memverifikasi bahwa Amazon GuardDuty aktif di akun Anda:
aws guardduty list-detectors
Konfirmasi respons yang tidak kosong GuardDuty diaktifkan di saat ini Wilayah AWS. Ulangi langkah ini untuk setiap Wilayah aktif, atau verifikasi di seluruh organisasi Anda melalui akun administrator yang GuardDuty didelegasikan.
catatan
Respons Insiden Keamanan AWS Biaya tidak termasuk biaya GuardDuty penggunaan. Lihat halaman GuardDuty harga
Langkah 1: Verifikasi pendaftaran dan keanggotaan
Menggunakan Respons Insiden Keamanan AWS konsol
Masuk ke akun administrator yang didelegasikan.
Konfirmasikan bahwa status keanggotaan Anda menunjukkan Aktif. Status Pending menunjukkan orientasi tidak lengkap.
Di bawah cakupan Akun, verifikasi bahwa OU yang ingin Anda cakup terdaftar. Cakupan dipilih pada tingkat unit organisasi (OU), bukan pada tingkat akun individu. Semua akun dalam OU yang dipilih (termasuk OU anak) tercakup.
Konfirmasikan bahwa Wilayah yang terdaftar cocok dengan tempat beban kerja Anda berjalan. Pemilihan wilayah dikunci saat pendaftaran dan tidak dapat diubah setelah penyiapan.
Menggunakan AWS CLI
Jalankan perintah berikut dari akun administrator yang didelegasikan:
aws security-ir list-memberships
Perintah sebelumnya mengembalikan ID dan status keanggotaan Anda.
Untuk mendapatkan detail keanggotaan lengkap termasuk konfigurasi tim respons insiden Anda, jalankan perintah berikut:
aws security-ir get-membership --membership-idmembership-id
Gunakan output perintah untuk memverifikasi informasi berikut.
Status keanggotaan adalah
ActiveAnggota tim respons insiden yang terdaftar cocok dengan pemangku kepentingan yang Anda tuju
Setidaknya dua anggota tim respons insiden dikonfigurasi (wajib)
Verifikasi administrator yang didelegasikan
Untuk mengonfirmasi bahwa akun yang benar terdaftar sebagai administrator yang didelegasikan untuk Respons Insiden Keamanan, jalankan perintah berikut:
aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com
catatan
Praktik terbaik: Gunakan akun administrator yang didelegasikan sama dengan yang Anda tetapkan untuk layanan AWS keamanan lainnya (seperti AWS Security Hub CSPM dan GuardDuty). Arsitektur Referensi AWS Keamanan merekomendasikan penggunaan akun Security Tooling.
Langkah 2: Verifikasi sumber deteksi dan triase
Respons Insiden Keamanan AWS memantau temuan keamanan dari GuardDuty dan alat pihak ketiga melalui Security Hub CSPM. Layanan ini menggunakan peran terkait layanan untuk menyerap temuan melalui EventBridge aturan Amazon yang diterapkan ke akun Anda selama orientasi.
Verifikasi peran terkait layanan Triage
Peran AWSServiceRoleForSecurityIncidentResponse_Triage terkait layanan harus ada di akun manajemen Anda dan semua akun anggota dalam cakupan.
Untuk memverifikasi, jalankan perintah berikut di akun manajemen dan anggota dalam lingkup:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Tanggapan yang berhasil menegaskan peran itu ada. Jika Anda menerima NoSuchEntity kesalahan, lakukan salah satu hal berikut:
Jika Anda onboard menggunakan konsol: Peran seharusnya dibuat secara otomatis. Kontak AWS Dukungan.
Jika Anda melakukan onboard menggunakan API atau AWS CLI: Lihat Aktifkan Respons Insiden Keamanan menggunakan petunjuk API/CLI untuk membuat peran secara manual.
Verifikasi peran utama terkait layanan
AWSServiceRoleForSecurityIncidentResponsePeran juga harus ada di akun administrator yang didelegasikan. Untuk memverifikasi bahwa peran itu ada, jalankan perintah berikut:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse
Verifikasi respons dan EventBridge aturan proaktif
Di Respons Insiden Keamanan AWS konsol, konfirmasikan bahwa Respons proaktif ditampilkan sebagai diaktifkan. Saat diaktifkan, layanan melakukan hal berikut:
Menyerap temuan dari GuardDuty dan Security Hub CSPM melalui aturan EventBridge
Secara otomatis melakukan triase temuan menggunakan konteks khusus pelanggan (IP yang diketahui, entitas IAM yang diharapkan)
Membuat kasus investigasi proaktif ketika masalah keamanan yang dikonfirmasi diidentifikasi
GuardDuty Temuan arsip ditentukan jinak (dapat dilihat di GuardDuty konsol di bawah Temuan yang diarsipkan)
EventBridge Aturan verifikasi diterapkan di akun anggota
Untuk memverifikasi bahwa EventBridge aturan diterapkan di akun anggota, selesaikan langkah-langkah berikut.
Buka EventBridge konsol Amazon di akun anggota tertutup.
Pilih Aturan.
Konfirmasikan bahwa aturan dengan
SecurityIncidentResponsenamanya ada dan Diaktifkan.
Jika aturan tidak ada, jalankan kembali pengaturan respons proaktif dari konsol atau kontak Security Incident Response. AWS Dukungan
Verifikasi integrasi pihak ketiga (jika ada)
Jika Anda menggunakan alat deteksi pihak ketiga (seperti CrowdStrike Falcon, Trend Micro Cloud One, atau Fortinet Lacework ForticNApp), verifikasi bahwa temuan mereka mengalir melalui Security Hub CSPM:
Pergi ke Integrasi.
Konfirmasikan integrasi vendor pihak ketiga Anda ditampilkan sebagai Menerima temuan.
catatan
Anda tidak perlu mengaktifkan standar atau kontrol CSPM Security Hub. Hanya integrasi vendor yang diperlukan untuk Respons Insiden Keamanan untuk menelan temuan pihak ketiga.
Langkah 3: Verifikasi pipa pencarian otomatis
Langkah ini menegaskan bahwa EventBridge pipa aktif dan temuan mencapai triase otomatis.
Tentang temuan GuardDuty sampel
GuardDutyfitur Hasilkan temuan sampel bawaan menghasilkan temuan yang ditandai sebagai sampel. Triase otomatis menyaring temuan sampel untuk mencegah kebisingan; mereka tidak mengalir melalui pipa triase penuh dan tidak dapat digunakan untuk memvalidasi konfigurasi Respons Insiden Keamanan Anda. Jangan menggunakannya untuk langkah ini.
Validasi dengan domain GuardDuty uji
GuardDuty Dokumentasi menyediakan domain uji (guarddutyc2activityb.com) yang menghasilkan temuan nyata tanpa memerlukan peristiwa keamanan dunia nyata. Menanyakan domain ini dari instans Amazon EC2 di akun tertutup menghasilkan temuan bahwa Security Incident Response menyerap dan memproses.
Untuk menghasilkan temuan tes:
Connect ke instans Amazon EC2 di akun tertutup menggunakan Systems Manager Session Manager atau SSH.
-
Jalankan perintah berikut:
dig guarddutyc2activityb.com Buka GuardDuty konsol, lalu pilih Temuan. Temuan ini muncul dalam waktu sekitar 5 menit.
Apa yang diharapkan:
Triase otomatis memproses temuan dan menentukan itu bukan indikasi peristiwa keamanan asli.
Temuan ini diarsipkan di GuardDuty. Untuk melihatnya, pilih Diarsipkan dari filter Status.
Jika Anda menggunakan Security Hub CSPM, status alur kerja temuan akan berubah menjadi.
SUPPRESSEDTidak ada kasus proaktif yang dibuat: ini adalah perilaku yang benar. Kasus hanya dibuka ketika triase otomatis mengidentifikasi aktivitas yang menjamin penyelidikan manusia.
catatan
Jika temuan pengujian tidak muncul dalam daftar yang GuardDuty diarsipkan dalam waktu 15 menit, lihatPemecahan masalah. Jika tidak ada instans Amazon EC2 yang tersedia, lanjutkan ke Langkah 4 dan kembali ke pengujian ini saat lingkungan Anda siap.
Langkah 4: Verifikasi pemberitahuan dan tim respons insiden
Verifikasi tim respons insiden Anda
Di konsol Respons Insiden Keamanan, tinjau anggota tim respons insiden yang dikonfigurasi. Setiap anggota menerima pemberitahuan email langsung saat kasus dibuat.
Atau, jalankan perintah berikut untuk memverifikasi menggunakan AWS CLI:
aws security-ir get-membership --membership-idmembership-id
Konfirmasikan bahwa:
Semua pemangku kepentingan yang dimaksud terdaftar
Alamat email sudah benar
Preferensi komunikasi setiap anggota ditetapkan dengan tepat (semua opsi komunikasi diaktifkan secara default — jika anggota tidak menerima pemberitahuan, verifikasi preferensi mereka belum dihapus)
Memahami pengamat kasus
Pengamat kasus adalah pemangku kepentingan yang diberikan akses untuk melihat kasus tertentu. Detail kunci:
Pengamat adalah per kasus, bukan per akun. Menambahkan pengamat ke satu kasing tidak memberi mereka akses ke kasus lain. Anda harus secara eksplisit menambahkan pengamat ke setiap kasus di mana Anda ingin mereka memiliki visibilitas.
Pengamat memiliki akses hanya lihat. Mereka dapat melihat detail kasus dan menerima pemberitahuan untuk pembaruan kasus, tetapi tidak dapat melakukan tindakan penahanan atau perbaikan pada sumber daya.
Hingga 30 pemangku kepentingan dapat ditambahkan per kasus individu.
Setiap kasus mencakup kebijakan IAM pra-cakupan yang memberikan akses hanya untuk kasus tertentu, mempertahankan akses hak istimewa paling sedikit.
Pelingkupan per kasus ini sangat penting ketika memberikan akses ke pihak eksternal seperti mitra deteksi dan respons terkelola (MDR) atau tim investigasi pihak ketiga yang seharusnya hanya melihat kasus spesifik yang mereka libatkan.
Verifikasi pengiriman pemberitahuan dengan kasus uji
Cara paling efektif untuk memvalidasi alur notifikasi ujung ke ujung adalah dengan membuat kasus uji reaktif (dikelola sendiri):
Di konsol Security Incident Response, buat kasus baru yang dikelola sendiri.
Dalam judul dan deskripsi kasus, nyatakan dengan jelas: “Ini adalah tes validasi konfigurasi, tidak ada peristiwa keamanan nyata.”
Verifikasi bahwa semua anggota tim respons insiden yang dikonfigurasi menerima pemberitahuan email.
Tutup kasing setelah konfirmasi pemberitahuan diterima.
penting
Membuat kasus uji dapat memicu respons dari teknisi Respons Insiden Keamanan jika Anda meminta keterlibatan yang AWS didukung. Tandai kasus Anda dengan jelas sebagai ujian untuk menghindari eskalasi yang tidak perlu. Gunakan langkah ini sekali untuk mengonfirmasi saluran berfungsi, lalu tutup kasing segera.
Apa yang diharapkan dari pemberitahuan kasus
Ketika kasus dibuat (baik secara proaktif oleh layanan atau secara reaktif oleh tim Anda), semua anggota tim respons insiden yang dikonfigurasi menerima pemberitahuan email yang berisi detail kasus.
Verifikasi EventBridge integrasi (jika dikonfigurasi)
Jika Anda mengonfigurasi EventBridge untuk merutekan peristiwa kasus ke platform pihak ketiga (seperti ServiceNow, Jira, Slack, atau PagerDuty), verifikasi bahwa kasus uji Anda memicu pemberitahuan yang diharapkan dalam sistem tersebut.
Langkah 5: Verifikasi kesiapan penahanan (opsional)
catatan
Penahanan bersifat opsional dan tidak diaktifkan secara default. Infrastruktur penahanan yang dijelaskan dalam bagian ini hanya diperlukan jika Anda memilih untuk mengaktifkan penahanan; tidak diperlukan Security Incident Response untuk memantau lingkungan Anda, menyelidiki temuan, atau membuka kasus.
Jika Anda belum mengaktifkan penahanan
Tidak ada yang bisa divalidasi di sini. Security Incident Response memberikan panduan dan investigasi selama peristiwa keamanan tetapi tidak mengambil tindakan penahanan otomatis kecuali Anda secara eksplisit mengizinkannya.
Jika Anda telah mengaktifkan penahanan
Periksa status penahanan di konsol. Verifikasi apakah tindakan penahanan ditampilkan sebagai Diotorisasi. Tindakan penahanan yang didukung termasuk runbook untuk:
Ember Amazon S3 yang terpengaruh
Instans Amazon EC2 yang terpengaruh
Prinsipal IAM yang terpengaruh
Verifikasi CloudFormation StackSet yang digunakan. Penahanan memerlukan peran IAM (AWSSecurityIncidentResponseContainmentdanAWSSecurityIncidentResponseContainmentExecution) di akun tercakup Anda:
Buka AWS CloudFormation di akun manajemen Anda.
Pilih StackSets.
Konfirmasikan penahanan Respons Insiden Keamanan StackSet ditampilkan
SUCCEEDEDdi semua akun target.
Jika StackSet tidak diterapkan, otorisasi penahanan di konsol tidak mengakibatkan tindakan penahanan aktual diambil.
Konfirmasikan preferensi penahanan Anda. Security Incident Response mendukung tiga tingkat penahanan:
Persetujuan Diperlukan (default): tidak ada tindakan penahanan tanpa otorisasi kasus per kasus eksplisit Anda.
Berisi Dikonfirmasi: penahanan proaktif sumber daya dikonfirmasi sebagai terpengaruh.
Mengandung Diduga: penahanan sumber daya secara proaktif dengan kemungkinan besar terpengaruh.
Untuk mengirimkan atau memperbarui preferensi Anda, buat AWS Dukungan kasus dengan tipe kasus Teknis: Layanan Respons Insiden Keamanan/Lainnya.
Jika Anda ingin EC2 Triage: Menyebarkan Containment dengan template EC2 Triage. CloudFormation Hal ini memungkinkan teknisi Security Incident Response untuk mengumpulkan data investigasi dari instans Amazon EC2 menggunakan. AWS Systems Manager
Langkah 6: Konfirmasikan operasi yang sedang berlangsung
Setelah menyelesaikan validasi awal, gunakan indikator ini untuk mengonfirmasi bahwa Security Incident Response terus beroperasi seperti yang diharapkan.
Tidak adanya kasus adalah normal
Security Incident Response menciptakan kasus proaktif hanya ketika triase otomatis mengidentifikasi aktivitas yang menjamin penyelidikan manusia. Ketika triase menentukan temuan itu jinak, ia mengarsipkan temuan tanpa membuat kasus atau menghubungi tim Anda. Penyebaran tanpa kasus terbuka dan aliran GuardDuty temuan arsip yang konsisten beroperasi sebagaimana dimaksud.
Jika Anda tidak melihat kasus dan tidak ada temuan yang diarsipkan setelah lingkungan Anda aktif selama beberapa hari, pipeline mungkin tidak terhubung; verifikasi Langkah 2 dan 3.
catatan
Kasus proaktif tanpa respons pelanggan selama 5 hari ditutup secara otomatis.
Temuan yang diarsipkan dan aturan penekanan sebagai sinyal kesehatan
Saat Security Incident Response memproses temuan dari waktu ke waktu, ia menciptakan dua artefak yang dapat diamati:
Temuan yang diarsipkan: temuan bahwa triase otomatis ditentukan jinak. Ini terakumulasi dari waktu ke waktu dan terlihat di GuardDuty konsol di bawah Temuan, lalu pilih Diarsipkan.
GuardDuty aturan penekanan: untuk menemukan tipe yang dikonfirmasi sebagai aktivitas yang diharapkan di lingkungan Anda, Security Incident Response menerapkan aturan penekanan bernama (diawali dengan).
SIRTriage-Ini adalah sinyal berkelanjutan paling jelas bahwa triase otomatis bekerja secara aktif. Lihat mereka di GuardDuty konsol di bawah aturan Suppression.
Tim respons insiden Anda diberi tahu saat aturan penindasan dibuat. Jika aturan dibuat karena kesalahan, hubungi AWS Dukungan untuk meminta rollback. Temuan yang diarsipkan dipertahankan GuardDuty selama 90 hari.
Laporan kegiatan bulanan
Security Incident Response mengirimkan laporan aktivitas bulanan ke tim respons insiden Anda yang merangkum temuan yang diproses, hasil triase, dan kasus apa pun yang dibuka. Jika tim Anda belum menerima laporan setelah bulan kalender penuh pertama Anda beroperasi, verifikasi bahwa anggota tim respons insiden telah mengaktifkan komunikasi. Untuk masalah lain yang terkait dengan laporan bulanan, hubungi Tim Akun Anda atau buka Support Case dengan tipe kasus: Teknis: Layanan Respons Insiden Keamanan/Lainnya dan sertakan informasi berikut:
Nama organisasi Anda
Pelaporan yang month/year Anda harapkan (misalnya, “Mei 2026")
ID Keanggotaan Respons Insiden Keamanan Anda jika diketahui
ID akun yang dicakup oleh keanggotaan Security Incident Response Anda
Apa yang diharapkan dari insinyur Security Incident Response
Saat Anda membuat casing yang AWS didukung atau layanan secara proaktif membuatnya, teknisi Security Incident Response mengakui kasus baru dalam waktu 15 menit. SLO pengakuan 15 menit ini berlaku untuk semua jenis kasus yang AWS didukung; baik peristiwa keamanan aktif maupun investigasi. Pengakuan awal mengonfirmasi kasus Anda sedang ditinjau; garis waktu penilaian lengkap dapat bervariasi berdasarkan tingkat keparahan dan kompleksitas kasus.
Untuk kasus proaktif (dibuat secara otomatis saat layanan triase mengidentifikasi masalah keamanan yang dikonfirmasi), layanan membuat kasus setelah triase otomatis mengonfirmasi masalah tersebut, dan tim respons insiden Anda diberi tahu saat kasus dibuka.
Daftar periksa validasi
Gunakan daftar periksa ini untuk mengonfirmasi konfigurasi Anda selesai:
Sumber log diaktifkan: peristiwa CloudTrail manajemen (wajib), Log Aliran VPC Amazon, pencatatan akses Amazon S3, pencatatan kueri DNS (disarankan)
GuardDuty diaktifkan di semua akun dan Wilayah aktif
Status keanggotaan Aktif di konsol Security Incident Response
Wilayah sudah benar (terkunci saat pendaftaran)
Akun administrator yang didelegasikan sudah benar (disarankan akun Security Tooling)
Lingkup akun mencakup OU yang dimaksudkan
AWSServiceRoleForSecurityIncidentResponse_Triageada di akun manajemenAWSServiceRoleForSecurityIncidentResponse_Triageada di akun anggota dalam ruang lingkupAWSServiceRoleForSecurityIncidentResponseada di akun administrator yang didelegasikanThird-party integrasi (jika ada) ditampilkan sebagai penerimaan temuan di Security Hub CSPM
EventBridge aturan
SecurityIncidentResponsedengan nama ada dan diaktifkan di akun anggotaAnggota tim respons insiden dikonfigurasi dengan informasi kontak dan komunikasi yang benar diaktifkan
Kasus uji dibuat dan pemberitahuan email diterima oleh semua anggota tim
Uji temuan domain (
guarddutyc2activityb.com) diarsipkan dalam waktu 15 menitPenahanan berhasil StackSet diterapkan (jika penahanan diaktifkan)
Preferensi penahanan dikirimkan (jika penahanan diaktifkan)
EventBridge integrasi (jika dikonfigurasi) mengirimkan acara ke platform pihak ketiga
Temuan yang diarsipkan terlihat GuardDuty setelah minggu pertama operasi
Verifikasi penagihan
Pelanggan Enterprise Support dan Unified Operations: Security Incident Response disertakan tanpa biaya tambahan sebagai bagian dari paket dukungan Anda. Anda tidak melihat biaya Respons Insiden Keamanan di AWS Cost Explorer atau Laporan AWS Biaya dan Penggunaan.
Semua pelanggan lain: Harga didasarkan pada jumlah temuan keamanan yang dicerna. 10.000 temuan pertama per bulan gratis. Untuk detailnya, lihat Respons Insiden Keamanan AWS harga
Pemecahan masalah
| Gejala | Kemungkinan penyebabnya | Resolusi |
|---|---|---|
| Status keanggotaan Tertunda | Orientasi tidak selesai | Selesaikan semua langkah pengaturan. Lihat Memulai. |
list-membershipsmengembalikan kosong |
Wilayah CLI tidak cocok dengan Wilayah langganan | Tentukan Wilayah tempat Anda mengaktifkan: --region |
| Triage SLR tidak ditemukan di akun manajemen | Onboard via API/CLI tanpa membuatnya | Buat secara manual: aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Akun anggota hilang dari cakupan | SLR tidak dikerahkan ke akun anggota | Re-run pengaturan respons proaktif dari konsol Security Incident Response |
| EventBridge aturan yang tidak ada di akun | Pengaturan respons proaktif tidak lengkap | Re-run mengatur atau memeriksa StackSet kegagalan di CloudFormation |
| GuardDuty Temuan sampel tidak diproses | Temuan sampel disaring oleh triase otomatis (diharapkan) | Periksa temuan yang diarsipkan di GuardDuty |
| Uji temuan domain tidak diarsipkan setelah 15 menit | EventBridge aturan hilang atau dinonaktifkan; GuardDuty tidak diaktifkan | Verifikasi Langkah 2 dan 3 |
| Tidak ada kasus setelah periode yang diperpanjang | Semua temuan diarsipkan berdasarkan triase (diharapkan), atau pipa tidak terhubung | Periksa temuan yang diarsipkan di GuardDuty. Jika tidak ada, verifikasi EventBridge aturan dan respons proaktif. |
| Tidak ada GuardDuty temuan yang diprioritaskan | GuardDuty tidak diaktifkan atau tidak menghasilkan temuan | Verifikasi GuardDuty diaktifkan: aws guardduty list-detectors |
| Layanan tidak memproses temuan | Triase otomatis menentukan bahwa aktivitas yang terdeteksi diharapkan | Tinjau Temuan GuardDuty yang diarsipkan dan temuan SUPPRESSED CSPM Security Hub |
| Anggota tim tidak menerima notifikasi | Email yang salah, komunikasi dinonaktifkan, atau email dalam spam | Verifikasi alamat email dan preferensi komunikasi; periksa folder spam |
| Tindakan penahanan tidak mengeksekusi | StackSet tidak dikerahkan atau preferensi tidak dikirimkan | Verifikasi StackSet status CloudFormation dan konfirmasi preferensi yang dikirimkan melalui AWS Dukungan |
Sumber daya terkait
