View a markdown version of this page

Cara pemilihan patch keamanan - AWS Systems Manager

• AWS Systems Manager CloudWatch Dasbor tidak akan lagi tersedia setelah 30 April 2026. Pelanggan dapat terus menggunakan CloudWatch konsol Amazon untuk melihat, membuat, dan mengelola dasbor Amazon CloudWatch mereka, seperti yang mereka lakukan hari ini. Untuk informasi selengkapnya, lihat dokumentasi CloudWatch Dasbor Amazon.

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

Cara pemilihan patch keamanan

Fokus utama Patch Manager adalah menginstal pembaruan terkait keamanan sistem operasi pada node yang dikelola. Secara default, Patch Manager tidak menginstal semua patch yang tersedia, melainkan serangkaian patch yang lebih kecil yang berfokus pada keamanan.

Secara default, Patch Manager tidak mengganti paket yang telah ditandai sebagai usang dalam repositori paket dengan paket pengganti dengan nama berbeda kecuali penggantian ini diperlukan oleh penginstalan pembaruan paket lain. Sebaliknya, untuk perintah yang memperbarui paket, Patch Manager hanya melaporkan dan menginstal pembaruan yang hilang untuk paket yang diinstal tetapi usang. Ini karena mengganti paket usang biasanya memerlukan menghapus instalasi paket yang ada dan menginstal penggantinya. Mengganti paket usang dapat menyebabkan perubahan merusak atau fungsionalitas tambahan yang tidak Anda inginkan.

Perilaku ini konsisten dengan update-minimal perintah YUM dan DNF, yang berfokus pada pembaruan keamanan daripada peningkatan fitur. Untuk informasi selengkapnya, lihat Cara menginstal patch.

catatan

Saat Anda menggunakan ApproveUntilDate parameter atau ApproveAfterDays parameter dalam aturan dasar patch, evaluasi tanggal ril Patch Manager is patch menggunakan Waktu Universal Terkoordinasi (UTC).

Misalnya, untukApproveUntilDate, jika Anda menentukan tanggal seperti2025-11-16, patch yang dirilis antara 2025-11-16T00:00:00Z dan 2025-11-16T23:59:59Z akan disetujui.

Ketahuilah bahwa tanggal rilis patch yang ditampilkan oleh pengelola paket asli di node terkelola Anda mungkin menunjukkan waktu yang berbeda berdasarkan zona waktu lokal sistem Anda, tetapi Patch Manager selalu menggunakan datetime UTC untuk perhitungan persetujuan. Ini memastikan konsistensi dengan tanggal rilis patch yang diterbitkan di situs web penasihat keamanan resmi.

Untuk jenis sistem Linux-based operasi yang melaporkan tingkat keparahan untuk patch, Patch Manager gunakan tingkat keparahan yang dilaporkan oleh penerbit perangkat lunak untuk pemberitahuan pembaruan atau patch individual. Patch Managertidak memperoleh tingkat keparahan dari sumber pihak ketiga, seperti Com mon Vulnerability Scoring System (CVSS), atau dari metrik yang dirilis oleh National Vulnerability Database (NVD).

catatan

Pada semua Linux-based sistem yang didukung olehPatch Manager, Anda dapat memilih repositori sumber berbeda yang dikonfigurasi untuk node terkelola, biasanya untuk menginstal pembaruan nonkeamanan. Untuk informasi, lihat Cara menentukan repositori sumber patch alternatif (Linux).

Pilih dari tab berikut untuk mempelajari cara Patch Manager memilih patch keamanan untuk sistem operasi Anda.

Amazon Linux 2 and Amazon Linux 2023

Repositori pra-konfigurasi ditangani secara berbeda di Amazon Linux 2 daripada di Amazon Linux 2023.

Di Amazon Linux 2, layanan baseline patch Manajer Sistem menggunakan repositori yang telah dikonfigurasi sebelumnya pada node terkelola. Biasanya ada dua repositori yang telah dikonfigurasi sebelumnya (repo) pada sebuah node:

Di Amazon Linux 2

  • ID repo: amzn2-core/2/architecture

    Nama repo: Amazon Linux 2 core repository

  • ID repo: amzn2extra-docker/2/architecture

    Nama repo: Amazon Extras repo for docker

catatan

architecturebisa x86_64 atau (untuk prosesor Graviton) aarch64.

Saat Anda membuat instans Amazon Linux 2023 (AL2023), itu berisi pembaruan yang tersedia dalam versi AL2023 dan spesifik yang AMI Anda pilih. Instans AL2023 Anda tidak secara otomatis menerima pembaruan keamanan penting dan penting tambahan pada saat peluncuran. Sebaliknya, dengan peningkatan deterministik melalui fitur repositori berversi yang didukung untuk AL2023, yang diaktifkan secara default, Anda dapat menerapkan pembaruan berdasarkan jadwal yang memenuhi kebutuhan spesifik Anda. Untuk informasi selengkapnya, lihat Upgrade Deterministik melalui repositori berversi di Panduan Pengguna Amazon Linux 2023.

Pada AL2023, repositori yang telah dikonfigurasi sebelumnya adalah sebagai berikut:

  • ID repo: amazonlinux

    Nama repo: repositori Amazon Linux 2023

Di Amazon Linux 2023 (rilis pratinjau), repositori yang telah dikonfigurasi sebelumnya terkait dengan versi pembaruan paket yang terkunci. Ketika new Amazon Machine Images (AMIs) untuk AL2023 dirilis, mereka dikunci ke versi tertentu. Untuk pembaruan patch, Patch Manager mengambil versi terkunci terbaru dari repositori pembaruan patch dan kemudian memperbarui paket pada node terkelola berdasarkan konten versi yang terkunci tersebut.

Manajer paket

Node terkelola Amazon Linux 2 menggunakan Yum sebagai manajer paket. Amazon Linux 2023 menggunakan DNF sebagai manajer paket.

Kedua manajer paket menggunakan konsep pemberitahuan pembaruan sebagai file bernamaupdateinfo.xml. Pemberitahuan pembaruan hanyalah sebuah kumpulan paket yang memperbaiki masalah tertentu. Semua paket yang ada dalam pemberitahuan pembaruan dianggap Keamanan olehPatch Manager. Paket individu tidak ditetapkan klasifikasi atau tingkat kepelikan. Untuk alasan iniPatch Manager, menetapkan atribut pemberitahuan pembaruan ke paket terkait.

catatan

Jika Anda memilih kotak centang Ser takan pembaruan non-keamanan di halaman Buat dasar patch, maka paket yang tidak diklasifikasikan dalam updateinfo.xml file (atau paket yang berisi file tanpa nilai Klasifikasi, Tingkat Keparahan, dan Tanggal yang diformat dengan benar) dapat disertakan dalam daftar patch yang telah difilter sebelumnya. Namun, agar patch dapat diterapkan, patch harus tetap memenuhi aturan dasar patch yang ditentukan pengguna.

Untuk informasi selengkapnya tentang opsi Sertakan pembaruan non-keamanan, lihat Cara menginstal patch danCara kerja aturan dasar patch pada Linux-based sistem.

CentOS Streaming

PadaCentOS Stream, layanan baseline patch Manajer Sistem menggunakan repositori (repo) yang telah dikonfigurasi sebelumnya pada node terkelola. Daftar berikut memberikan contoh untuk CentOS fiktif 9.2 Amazon Machine Image (): AMI

  • ID repo: example-centos-9.2-base

    Nama repo: Example CentOS-9.2 - Base

  • ID repo: example-centos-9.2-extras

    Nama repo: Example CentOS-9.2 - Extras

  • ID repo: example-centos-9.2-updates

    Nama repo: Example CentOS-9.2 - Updates

  • ID repo: example-centos-9.x-examplerepo

    Nama repo: Example CentOS-9.x – Example Repo Packages

catatan

Semua pembaruan diunduh dari repo jarak jauh yang dikonfigurasi pada node terkelola. Oleh karena itu, node harus memiliki akses keluar ke internet untuk terhubung ke repo sehingga tambalan dapat dilakukan.

CentOS Streamnode menggunakan DNF sebagai manajer paket. Manajer paket menggunakan konsep pemberitahuan pembaruan. Pemberitahuan pembaruan hanyalah sebuah kumpulan paket yang memperbaiki masalah tertentu.

Namun, repo CentOS Stream default tidak dikonfigurasi dengan pemberitahuan pembaruan. Ini berarti itu Patch Manager tidak mendeteksi paket pada CentOS Stream repo default. Patch ManagerUntuk mengizinkan memproses paket yang tidak terkandung dalam pemberitahuan pembaruan, Anda harus EnableNonSecurity mengaktifkan tanda di aturan dasar patch.

catatan

CentOS StreamPemberitahuan pembaruan didukung. Repo dengan pemberitahuan pembaruan dapat diunduh setelah peluncuran.

Debian Server

Pada Debian Server, layanan dasar patch Systems Manager menggunakan repositori (repo) yang telah dikonfigurasi pada instans. Repo yang telah dikonfigurasi ini digunakan untuk menarik daftar terbaru dari pemutakhiran paket yang tersedia. Untuk ini, Systems Manager melakukan perintah setara sudo apt-get update.

Paket kemudian di-filter dari repo debian-security codename. Ini berarti bahwa pada setiap versiDebian Server, Patch Manager hanya mengidentifikasi peningkatan yang merupakan bagian dari repo terkait untuk versi tersebut, sebagai berikut:

  • Debian Server11: debian-security bullseye

  • Debian Server12: debian-security bookworm

Oracle Linux

PadaOracle Linux, layanan baseline patch Manajer Sistem menggunakan repositori (repo) yang telah dikonfigurasi sebelumnya pada node terkelola. Biasanya ada dua repo yang telah dikonfigurasi sebelumnya pada sebuah node.

Oracle Linux7:

  • ID repo: ol7_UEKR5/x86_64

    Nama repo: Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)

  • ID repo: ol7_latest/x86_64

    Nama repo: Oracle Linux 7Server Latest (x86_64)

Oracle Linux8:

  • ID repo: ol8_baseos_latest

    Nama repo: Oracle Linux 8 BaseOS Latest (x86_64)

  • ID repo: ol8_appstream

    Nama repo: Oracle Linux 8 Application Stream (x86_64)

  • ID repo: ol8_UEKR6

    Nama repo: Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)

Oracle Linux9:

  • ID repo: ol9_baseos_latest

    Nama repo: Oracle Linux 9 BaseOS Latest (x86_64)

  • ID repo: ol9_appstream

    Nama repo: Oracle Linux 9 Application Stream Packages(x86_64)

  • ID repo: ol9_UEKR7

    Nama repo: Oracle Linux UEK Release 7 (x86_64)

catatan

Semua pembaruan diunduh dari repo jarak jauh yang dikonfigurasi pada node terkelola. Oleh karena itu, node harus memiliki akses keluar ke internet untuk terhubung ke repo sehingga tambalan dapat dilakukan.

Oracle Linuxnode yang dikelola menggunakan Yum sebagai manajer paket, dan Yum menggunakan konsep pemberitahuan pembaruan sebagai file bernamaupdateinfo.xml. Pemberitahuan pembaruan hanyalah sebuah kumpulan paket yang memperbaiki masalah tertentu. Paket individu tidak ditetapkan klasifikasi atau tingkat kepelikan. Untuk alasan ini, Patch Manager menetapkan atribut pemberitahuan pembaruan ke paket terkait dan menginstal paket berdasarkan filter Klasifikasi yang ditentukan dalam baseline patch.

catatan

Jika Anda memilih kotak centang Ser takan pembaruan non-keamanan di halaman Buat dasar patch, maka paket yang tidak diklasifikasikan dalam updateinfo.xml file (atau paket yang berisi file tanpa nilai Klasifikasi, Tingkat Keparahan, dan Tanggal yang diformat dengan benar) dapat disertakan dalam daftar patch yang telah difilter sebelumnya. Namun, agar patch dapat diterapkan, patch harus tetap memenuhi aturan dasar patch yang ditentukan pengguna.

AlmaLinux, RHEL, and Linux Rocky

Aktif AlmaLinux,Red Hat Enterprise Linux, dan Rocky Linux layanan baseline patch Manajer Sistem menggunakan repositori (repo) yang telah dikonfigurasi sebelumnya pada node terkelola. Biasanya ada tiga repo yang telah dikonfigurasi sebelumnya pada sebuah node.

Semua pembaruan diunduh dari repo jarak jauh yang dikonfigurasi pada node terkelola. Oleh karena itu, node harus memiliki akses keluar ke internet untuk terhubung ke repo sehingga tambalan dapat dilakukan.

catatan

Jika Anda memilih kotak centang Ser takan pembaruan non-keamanan di halaman Buat dasar patch, maka paket yang tidak diklasifikasikan dalam updateinfo.xml file (atau paket yang berisi file tanpa nilai Klasifikasi, Tingkat Keparahan, dan Tanggal yang diformat dengan benar) dapat disertakan dalam daftar patch yang telah difilter sebelumnya. Namun, agar patch dapat diterapkan, patch harus tetap memenuhi aturan dasar patch yang ditentukan pengguna.

Red Hat Enterprise Linux7 node yang dikelola menggunakan Yum sebagai manajer paket. AlmaLinux, Red Hat Enterprise Linux 8, dan node Rocky Linux terkelola menggunakan DNF sebagai manajer paket. Kedua pengelola paket menggunakan konsep pemberitahuan pembaruan sebagai file bernama updateinfo.xml. Pemberitahuan pembaruan hanyalah sebuah kumpulan paket yang memperbaiki masalah tertentu. Paket individu tidak ditetapkan klasifikasi atau tingkat kepelikan. Untuk alasan ini, Patch Manager menetapkan atribut pemberitahuan pembaruan ke paket terkait dan menginstal paket berdasarkan filter Klasifikasi yang ditentukan dalam baseline patch.

catatan

Pada AlmaLinux dan Rocky Linux, repositori mungkin tidak mempertahankan versi paket yang lebih lama setelah versi yang lebih baru dari nama paket yang sama dirilis. Jika pemberitahuan pembaruan mereferensikan versi yang tidak lagi tersedia di repositori, evaluasi Patch Manager penginstalan versi yang lebih baru menggunakan metadata penasihat yang diterbitkan untuk versi yang tidak lagi tersedia. Ini memastikan bahwa patch yang tertunda diterapkan ketika versi yang tidak tersedia tidak lagi ada di repositori.

Hal ini dapat Patch Manager menyebabkan menginstal versi paket yang lebih baru bahkan jika penasihat terkait dirilis setelah dikonfigurasi ApproveUntilDate atauApproveAfterDays.

RHEL7
catatan

ID repo berikut dikaitkan dengan RHUI 2. RHUI 3 diluncurkan pada bulan Desember 2019 dan memperkenalkan skema penamaan yang berbeda untuk ID repositori Yum. Tergantung dari RHEL-7 AMI mana Anda membuat node terkelola, Anda mungkin perlu memperbarui perintah Anda. Untuk informasi selengkapnya, lihat ID Repositori untuk RHEL 7 di AWS Telah Berubah di Portal Pelanggan Red Hat.

  • ID repo: rhui-REGION-client-config-server-7/x86_64

    Nama repo: Red Hat Update Infrastructure 2.0 Client Configuration Server 7

  • ID repo: rhui-REGION-rhel-server-releases/7Server/x86_64

    Nama repo: Red Hat Enterprise Linux Server 7 (RPMs)

  • ID repo: rhui-REGION-rhel-server-rh-common/7Server/x86_64

    Nama repo: Red Hat Enterprise Linux Server 7 RH Common (RPMs)

AlmaLinux, 8 RHEL 8, dan Rocky Linux 8

  • ID repo: rhel-8-appstream-rhui-rpms

    Nama repo: Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)

  • ID repo: rhel-8-baseos-rhui-rpms

    Nama repo: Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)

  • ID repo: rhui-client-config-server-8

    Nama repo: Red Hat Update Infrastructure 3 Client Configuration Server 8

AlmaLinux 9, RHEL 9, dan Rocky Linux 9

  • ID repo: rhel-9-appstream-rhui-rpms

    Nama repo: Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)

  • ID repo: rhel-9-baseos-rhui-rpms

    Nama repo: Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)

  • ID repo: rhui-client-config-server-9

    Nama repo: Red Hat Enterprise Linux 9 Client Configuration

SLES

Pada node yang dikelola SUSE Linux Enterprise Server (SLES), pustaka ZYPP mendapatkan daftar patch yang tersedia (kumpulan paket) dari lokasi berikut:

  • Daftar repositori: etc/zypp/repos.d/*

  • Informasi paket: /var/cache/zypp/raw/*

SLESnode yang dikelola menggunakan Zypper sebagai manajer paket, dan Zypper menggunakan konsep patch. Patch hanyalah kumpulan paket yang memperbaiki masalah tertentu. Patch Managermenangani semua paket yang direferensikan dalam patch sebagai terkait keamanan. Karena paket individual tidak diberi klasifikasi atau tingkat keparahan, Patch Manager memberikan paket atribut patch yang menjadi miliknya.

Ubuntu Server

PadaUbuntu Server, layanan baseline patch Manajer Sistem menggunakan repositori (repo) yang telah dikonfigurasi sebelumnya pada node terkelola. Repo yang telah dikonfigurasi ini digunakan untuk menarik daftar terbaru dari pemutakhiran paket yang tersedia. Untuk ini, Systems Manager melakukan perintah setara sudo apt-get update.

Paket kemudian disaring dari codename-security repo, di mana nama kode unik untuk versi rilis, seperti plucky untuk 25.04. Ubuntu Server Patch Managerhanya mengidentifikasi peningkatan yang merupakan bagian dari repo ini:

  • Ubuntu Server18.04 LTS: bionic-security

  • Ubuntu Server20.04 LTS: focal-security

  • Ubuntu Server22.04 LTS: jammy-security

  • Ubuntu Server24.04 LTS: noble-security

  • Ubuntu Server25.04: plucky-security

Windows Server

Pada sistem operasi Microsoft Windows, Patch Manager mengambil daftar pembaruan yang tersedia yang diterbitkan Microsoft ke Microsoft Update dan secara otomatis tersedia untuk Layanan Pembaruan Windows Server (WSUS).

catatan

Patch Managerhanya menyediakan patch untuk versi sistem Windows Server operasi yang didukung untukPatch Manager. Misalnya, tidak Patch Manager dapat digunakan untuk menambal Windows RT.

Patch Managerterus memantau pembaruan baru di setiap Wilayah AWS. Daftar pembaruan yang tersedia disegarkan di setiap Region setidaknya sekali per hari. Saat informasi patch dari Microsoft diproses, Patch Manager menghapus pembaruan yang diganti dengan pembaruan selanjutnya dari daftar tambalannya. Oleh karena itu, hanya pembaruan terbaru yang ditampilkan dan tersedia untuk instalasi. Misalnya, jika KB4012214 digantiKB3135456, hanya KB4012214 tersedia sebagai pembaruan diPatch Manager.

Demikian pula, Patch Manager dapat menginstal hanya patch yang tersedia pada node terkelola selama operasi tambalan. Secara default, Windows Server 2019 dan Windows Server 2022 menghapus pembaruan yang diganti dengan pembaruan selanjutnya. Akibatnya, jika Anda menggunakan ApproveUntilDate parameter dalam baseline Windows Server patch, tetapi tanggal yang dipilih dalam ApproveUntilDate parameter adalah sebelum tanggal patch terbaru, maka skenario berikut terjadi:

  • Patch yang diganti dihapus dari node dan oleh karena itu tidak dapat diinstal menggunakan. Patch Manager

  • Patch pengganti terbaru ada di node tetapi belum disetujui untuk pemasangan sesuai tanggal yang ditentukan ApproveUntilDate parameter.

Tambalan yang diganti dapat membuat celah kepatuhan

Node terkelola Anda mungkin dilaporkan sesuai untuk operasi Manajer Sistem meskipun patch penting dari bulan sebelumnya tidak diinstal. Skenario ini juga dapat terjadi dengan ApproveAfterDays parameter.

Karena perilaku patch Microsoft yang digantikan, Anda dapat mengatur ApproveAfterDays nilai (umumnya lebih besar dari 30) sehingga patch untuk Windows Server tidak pernah diinstal jika Microsoft merilis patch terbaru sebelum jumlah hari itu berlalu. Dalam situasi ini, node terkelola Anda mungkin melaporkan sesuai meskipun patch keamanan kritis tidak diinstal.

Misalnya, atur ApproveAfterDays ke 45. Jika Microsoft merilis patch pengganti pada hari ke 30, sistem menghapus patch asli. Patch baru tidak disetujui sampai hari ke-45, meninggalkan jendela 15 hari di mana tidak ada patch yang diinstal.

Perilaku ini tidak berlaku jika Anda telah mengubah pengaturan Objek Kebijakan Grup (GPO) Windows untuk membuat patch yang diganti tersedia di node terkelola Anda.

catatan

Dalam beberapa kasus, Microsoft merilis patch untuk aplikasi yang tidak menentukan tanggal dan waktu yang diperbarui. Dalam kasus ini, tanggal dan waktu yang diperbarui 01/01/1970 disediakan secara default.