View a markdown version of this page

Perbarui solusinya - Respon Keamanan Otomatis di AWS
Upgrade dari versi sebelum v1.4Upgrade dari v1.4 dan yang lebih baruUpgrade dari v2.0.xUpgrade dari v2.1.4 atau sebelumnyaUpgrade dari v2.x ke v4.0.0 atau yang lebih baru

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perbarui solusinya

penting

  • Memutakhirkan ke v4.0.0 atau yang lebih baru: Solusi mempertahankan pengaturan remediasi otomatis yang ada di seluruh pemutakhiran. Jika Anda memutakhirkan dari v2.x, solusi secara otomatis memigrasikan pengaturan remediasi otomatis dari EventBridge aturan v2 Anda ke DynamoDB-backed konfigurasi baru selama pembaruan tumpukan. Kontrol yang Anda aktifkan remediasi otomatis di v2 tetap diaktifkan di v4, dan kontrol tanpa setara v3+ dilewati dan dicantumkan dalam log Amazon migrasi fungsi AWS Lambda. CloudWatch Jika Anda memutakhirkan dari v3.x, pengaturan remediasi otomatis Anda sudah berada di DynamoDB-backed konfigurasi dan terbawa tidak berubah, jadi tidak diperlukan migrasi. Jika migrasi mengalami kegagalan per kontrol atau dibatalkan sebelum kontrol apa pun ditulis, fungsi SO0111-ASR-MigrationAutoRemediation Lambda menerbitkan pemberitahuan Amazon SNS ke yang sudah ada. SO0111-ASR_Topic Untuk menerima pemberitahuan itu, Anda harus memiliki langganan yang dikonfirmasi SO0111-ASR_Topic sebelum memulai pembaruan tumpukan v4. Lihat Upgrade dari v2.x ke v4.0.0 atau yang lebih baru.

  • Memutakhirkan ke v3.x dari v2.x: aturan remediasi Re-enable otomatis secara manual di akun Admin setelah pembaruan tumpukan. Lihat Aktifkan remedi asi sepenuhnya otomatis.

  • Jika Anda menggunakan Reuse Orchestrator Log Group parameter untuk menyimpan log, pastikan parameter tersebut disetel dengan tepat selama pembaruan tumpukan untuk menghindari rekreasi grup log atau hilangnya pengaturan retensi log. Lihat Men yebarkan solusi. Jika Anda melakukan pembaruan tumpukan ke v2.3.0+ dari versi sebelumnya pilih “tidak”

Upgrade dari versi sebelum v1.4

Jika sebelumnya Anda telah menerapkan solusi sebelum v1.4.x, hapus instalan, lalu instal versi terbaru:

  1. Copot pemasangan solusi yang digunakan sebelumnya. Lihat Mengh apus instalasi solusi.

  2. Luncurkan template terbaru. Lihat Men yebarkan solusi.

    catatan

    Jika Anda memutakhirkan dari v1.2.1 atau sebelumnya ke v1.3.0 atau yang lebih baru, set Reuse Orchestrator Log Group el ke. No Jika Anda menginstal ulang v1.3.0 atau yang lebih baru, Anda dapat memilih Yes untuk opsi ini. Opsi ini memungkinkan Anda untuk terus log ke Grup Log yang sama untuk Fungsi Langkah Orchestrator.

Upgrade dari v1.4 dan yang lebih baru

Jika Anda memutakhirkan dari v1.4.x, perbarui semua tumpukan atau sebagai berikut: StackSets

  1. Perbarui tumpukan di akun admin Hub Keamanan menggunakan template terbaru.

  2. Di setiap akun anggota, perbarui izin dari template terbaru.

  3. Di setiap akun anggota di semua Wilayah yang saat ini digunakan, perbarui tumpukan anggota dari template terbaru.

  4. Jika UI Web diaktifkan dan Anda memperbarui parameter sepertiTicketGenFunctionName, membatalkan CloudFront cache untuk mencerminkan perubahan segera:

    aws cloudfront create-invalidation \
  --distribution-id <distribution-id> \
  --paths "/aws-exports.json"

Upgrade dari v2.0.x

Jika Anda memutakhirkan dari v2.0.x, tingkatkan ke v2.3.0 terlebih dahulu. Memperbarui ke v2.1.0—2.1.1 gagal. CloudFormation

Upgrade dari v2.1.4 atau sebelumnya

Jika Anda memutakhirkan dari v2.1.4 atau sebelumnya, Anda harus meningkatkan ke v2.3.0 sebelum memutakhirkan ke versi apa pun yang lebih tinggi dari v2.3.0. Jika tidak, operasi pembaruan tumpukan akan gagal. Atau, Anda dapat menghapus dan menerapkan kembali tumpukan solusi daripada melakukan pembaruan tumpukan.

Upgrade dari v2.x ke v4.0.0 atau yang lebih baru

Mulai dari v4.0.0, solusi mempertahankan pengaturan remediasi otomatis Anda di seluruh upgrade v2 ke v4. Di v2, EventBridge aturan Amazon per kontrol menyimpan status remediasi otomatis. Di v3 dan yang lebih baru, solusi menyimpannya di tabel Konfigurasi Remediasi Amazon DynamoDB di akun admin. Selama pembaruan tumpukan v4, sumber daya khusus memindai _AutoTrigger aturan v2 yang ada, menerjemahkan ID kontrol khusus standar masing-masing aturan ke ID kontrol keamanan yang sesuai, dan menulis kontrol yang diaktifkan sebelumnya ke tabel DynamoDB.

Migrasi mencakup semua lima playbook v2:

  • SC(Kontrol keamanan AWS Service-managed Security Hub) — ID kontrol ditulis ke DynamoDB tanpa perubahan.

  • AFSBP(Praktik Terbaik Keamanan Dasar AWS) — ID kontrol ditulis ke DynamoDB tanpa perubahan.

  • NIST80053R5(NIST 800-53 Revisi 5) — ID kontrol ditulis ke DynamoDB tidak berubah.

  • PCI(PCI DSS v3.2.1) — PCI. awalan utama dihapus (misalnya, PCI.S3.5 menjadi). S3.5

  • CIS(CIS AWS Foundations Benchmark v1.2.0, v1.4.0, dan v3.0.0) — setiap ID kontrol CIS dipetakan ke kontrol keamanan yang ditargetkan dokumen remediasi SSM v2 yang ditargetkan.

Hasil migrasi:

  • Kontrol yang berhasil dimigrasi tidak memerlukan tindakan - mereka mengaktifkan remediasi otomatis di v4 dengan cara yang sama seperti di v2.

  • Kontrol bahwa lompatan migrasi terbagi dalam dua kategori: aturan CIS tanpa remediasi ASR di v2, dan kontrol v3+ tidak dikirimkan. Kontrol yang dilewati tercantum dalam SO0111-ASR-MigrationAutoRemediation log Amazon CloudWatch fungsi AWS Lambda.

  • Jika migrasi mengalami kegagalan per kontrol (misalnya, kesalahan pelambatan sementara selama pembaruan DynamoDB) atau dibatalkan sebelum kontrol apa pun ditulis, SO0111-ASR-MigrationAutoRemediation menerbitkan pemberitahuan Amazon SNS ke topik yang ada. SO0111-ASR_Topic Badan notifikasi mencantumkan ID kontrol yang terpengaruh dan diawali dengan[ASR v2 → v3/v4 migration].

  • Sumber daya khusus hanya berjalan selama pembaruan v3/v4 tumpukan awal. Pembaruan tumpukan berikutnya tidak menjalankan kembali migrasi.

catatan

Berlangganan topik SNS sebelum memutakhirkan. Pemberitahuan kegagalan migrasi dipublikasikan ke topik SO0111-ASR_Topic Amazon SNS solusi yang ada. Jika Anda tidak memiliki langganan yang dikonfirmasi pada topik tersebut sebelum peningkatan, pemberitahuan kegagalan tidak sampai kepada Anda. Dalam hal ini, Anda hanya melihat kegagalan di CloudWatch log Amazon fungsi SO0111-ASR-MigrationAutoRemediation AWS Lambda. Untuk berlangganan titik akhir, ambil topik ARN dari AWS Systems Manager Parameter Store di /Solutions/SO0111/SNS_Topic_ARN dan tambahkan langganan SNS (email, SQS, fungsi AWS Lambda, atau protokol lain yang didukung) sebelum memulai pembaruan tumpukan v4. Konfirmasikan langganan email apa pun melalui email konfirmasi AWS sehingga topik siap dikirimkan sebelum migrasi berjalan.

Jika migrasi tidak dapat menulis kontrol yang ingin diperbaiki secara otomatis di v4, aktifkan secara manual di tabel DynamoDB Konfigurasi Remediasi. Lihat Aktifkan remedi asi sepenuhnya otomatis.