• 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 CloudWatch dasbor Amazon mereka, seperti yang mereka lakukan hari ini. Untuk informasi selengkapnya, lihat [dokumentasi CloudWatch Dasbor Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

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

# AWS Systems Manager Patch Manager
<a name="patch-manager"></a>

Patch Manager, alat di AWS Systems Manager, mengotomatiskan proses menambal node yang dikelola dengan pembaruan terkait keamanan dan jenis pembaruan lainnya.

**catatan**  
Systems Manager menyediakan dukungan untuk *kebijakan tambalan* diQuick Setup, alat di AWS Systems Manager. Menggunakan kebijakan tambalan adalah metode yang disarankan untuk mengonfigurasi operasi penambalan Anda. Dengan menggunakan konfigurasi kebijakan tambalan tunggal, Anda dapat menentukan penambalan untuk semua akun di semua Wilayah di organisasi Anda; hanya untuk akun dan Wilayah yang Anda pilih; atau untuk satu pasangan Account-region. Untuk informasi selengkapnya, lihat [Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).

Anda dapat menggunakan Patch Manager untuk menerapkan tambalan untuk sistem operasi dan aplikasi. (Pada Windows Server, dukungan aplikasi terbatas pada pembaruan untuk aplikasi yang dirilis oleh Microsoft.) Anda dapat menggunakan Patch Manager untuk menginstal Paket Layanan pada node Windows dan melakukan upgrade versi minor pada node Linux. Anda dapat menambal armada instans Amazon Elastic Compute Cloud (Amazon EC2), perangkat edge, server lokal, dan mesin virtual () berdasarkan jenis sistem operasi. VMs Ini termasuk versi yang didukung dari beberapa sistem operasi, seperti yang tercantum dalam[Prasyarat Patch Manager](patch-manager-prerequisites.md). Anda dapat memindai instans untuk melihat laporan patch yang hilang saja, atau Anda dapat memindai dan secara otomatis menginstal semua patch yang hilang. Untuk memulaiPatch Manager, buka [konsol Systems Manager](https://console.aws.amazon.com//systems-manager/patch-manager). Di panel navigasi, pilih **Patch Manager**.

AWS tidak menguji tambalan sebelum membuatnya tersedia diPatch Manager. Selain Patch Manager itu, tidak mendukung peningkatan versi utama sistem operasi, seperti Windows Server 2016 hingga Windows Server 2019, atau Red Hat Enterprise Linux (RHEL) 7.0 hingga RHEL 8.0.

Untuk jenis sistem operasi berbasis Linux yang melaporkan tingkat keparahan 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 [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS), atau dari metrik yang dirilis oleh [National](https://nvd.nist.gov/vuln) Vulnerability Database (NVD).

## Bagaimana bisa Patch Manager menguntungkan organisasi saya?
<a name="how-can-patch-manager-benefit-my-organization"></a>

Patch Managermengotomatiskan proses menambal node terkelola dengan pembaruan terkait keamanan dan jenis pembaruan lainnya. Ini memberikan beberapa manfaat utama:
+ **Kontrol penambalan terpusat** —Dengan menggunakan kebijakan tambalan, Anda dapat menyiapkan operasi penambalan berulang untuk semua akun di semua Wilayah di organisasi, akun dan Wilayah tertentu, atau satu pasangan Account-region.
+ **Operasi penambalan fleksibel** - Anda dapat memilih untuk memindai instance untuk hanya melihat laporan tambalan yang hilang, atau memindai dan secara otomatis menginstal semua tambalan yang hilang.
+ **Pelaporan kepatuhan komprehensif** — Setelah operasi pemindaian, Anda dapat melihat informasi terperinci tentang node terkelola mana yang tidak sesuai dengan patch dan patch mana yang hilang.
+ **Dukungan lintas platform** — Patch Manager mendukung beberapa sistem operasi termasuk berbagai distribusi Linux,macOS, dan. Windows Server
+ **Garis dasar patch kustom** — Anda dapat menentukan apa yang merupakan kepatuhan patch untuk organisasi Anda melalui baseline patch kustom yang menentukan patch mana yang disetujui untuk instalasi.
+ **Integrasi dengan AWS layanan lain** — Patch Manager terintegrasi dengan AWS Organizations, AWS Security Hub CSPM, AWS CloudTrail, dan AWS Config untuk meningkatkan manajemen dan keamanan.
+ **Peningkatan deterministik - Dukungan untuk peningkatan** deterministik melalui repositori berversi untuk sistem operasi seperti Amazon Linux 2023.

## Siapa yang harus menggunakanPatch Manager?
<a name="who-should-use-patch-manager"></a>

Patch Managerdirancang untuk yang berikut:
+ Administrator TI yang perlu mempertahankan kepatuhan patch di seluruh armada node terkelola mereka
+ Manajer operasi yang membutuhkan visibilitas ke status kepatuhan patch di seluruh infrastruktur mereka
+ Arsitek cloud yang ingin menerapkan solusi patching otomatis dalam skala besar
+ DevOps insinyur yang perlu mengintegrasikan patching ke dalam alur kerja operasional mereka
+ Organizations dengan penyebaran Multi-akun/Multi-wilayah yang membutuhkan manajemen patch terpusat
+ Siapa pun yang bertanggung jawab untuk menjaga postur keamanan dan kesehatan operasional node AWS terkelola, perangkat edge, server lokal, dan mesin virtual

## Apa saja fitur utamaPatch Manager?
<a name="what-are-the-main-features-of-patch-manager"></a>

Patch Managermenawarkan beberapa fitur utama:
+ **Kebijakan tambalan** — Konfigurasikan operasi penambalan di beberapa Akun AWS dan Wilayah menggunakan satu kebijakan melalui integrasi dengan AWS Organizations.
+ **Garis dasar patch kustom** - Tentukan aturan untuk patch yang disetujui secara otomatis dalam beberapa hari setelah rilis, bersama dengan daftar tambalan yang disetujui dan ditolak.
+ **Beberapa metode penambalan** — Pilih dari kebijakan tambalan, jendela pemeliharaan, atau operasi “Patch now” sesuai permintaan untuk memenuhi kebutuhan spesifik Anda.
+ **Pelaporan kepatuhan** — Buat laporan terperinci tentang status kepatuhan tambalan yang dapat dikirim ke bucket Amazon S3 dalam format CSV.
+ **Dukungan lintas platform** - Patch baik sistem operasi dan aplikasi di seluruhWindows Server, berbagai distribusi Linux, dan. macOS
+ **Fleksibilitas penjadwalan** - Tetapkan jadwal yang berbeda untuk memindai dan menginstal tambalan menggunakan ekspresi CRON atau Rate kustom.
+ **Lifecycle hooks** — Jalankan skrip kustom sebelum dan sesudah operasi patching menggunakan dokumen Systems Manager.
+ **Fokus keamanan** — Secara default, Patch Manager berfokus pada pembaruan terkait keamanan daripada menginstal semua tambalan yang tersedia.
+ **Kontrol tingkat** - Konfigurasikan ambang konkurensi dan kesalahan untuk operasi penambalan untuk meminimalkan dampak operasional.

## Apa itu kepatuhanPatch Manager?
<a name="patch-manager-definition-of-compliance"></a>

Patokan untuk apa yang merupakan *kepatuhan patch* untuk node terkelola dalam armada Systems Manager Anda tidak ditentukan oleh AWS, oleh vendor sistem operasi (OS), atau oleh pihak ketiga seperti perusahaan konsultan keamanan.

Sebagai gantinya, Anda menentukan apa arti kepatuhan patch untuk node terkelola di organisasi atau akun Anda di *baseline patch*. Patch baseline adalah konfigurasi yang menentukan aturan yang patch harus diinstal pada node terkelola. Node terkelola sesuai dengan patch saat up to date dengan semua patch yang memenuhi kriteria persetujuan yang Anda tentukan di baseline patch. 

*Perhatikan bahwa *sesuai* dengan baseline patch tidak berarti bahwa node terkelola selalu aman.* Compliant berarti bahwa patch yang ditentukan oleh baseline patch yang *tersedia* dan *disetujui* telah diinstal pada node. Keamanan keseluruhan node terkelola ditentukan oleh banyak faktor di luar lingkupPatch Manager. Untuk informasi selengkapnya, lihat [Keamanan di AWS Systems Manager](security.md).

Setiap baseline patch adalah konfigurasi untuk jenis sistem operasi (OS) tertentu yang didukung, seperti Red Hat Enterprise Linux (RHEL)macOS, atau. Windows Server Garis dasar patch dapat menentukan aturan patching untuk semua versi OS yang didukung atau dibatasi hanya untuk yang Anda tentukan, seperti RHEL 7.8. dan 9.3. RHEL

Dalam garis dasar tambalan, Anda dapat menentukan bahwa semua tambalan klasifikasi dan tingkat keparahan tertentu disetujui untuk pemasangan. Misalnya, Anda mungkin menyertakan semua tambalan yang diklasifikasikan sebagai `Security` tetapi mengecualikan klasifikasi lain, seperti `Bugfix` atau. `Enhancement` Dan Anda bisa memasukkan semua tambalan dengan tingkat keparahan `Critical` dan mengecualikan yang lain, seperti `Important` dan`Moderate`.

Anda juga dapat menentukan tambalan secara eksplisit dalam baseline patch dengan menambahkannya IDs ke daftar tambalan tertentu untuk disetujui atau ditolak, seperti untuk atau untuk `KB2736693` Amazon Linux 2023 (). Windows Server `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` AL2023 Anda dapat secara opsional menentukan jumlah hari tertentu untuk menunggu penambalan setelah tambalan tersedia. Untuk Linux danmacOS, Anda memiliki opsi untuk menentukan daftar patch eksternal untuk kepatuhan (daftar Install Override) alih-alih yang ditentukan oleh aturan dasar patch.

Saat operasi penambalan berjalan, Patch Manager bandingkan tambalan yang saat ini diterapkan ke node terkelola dengan yang harus diterapkan sesuai dengan aturan yang diatur di baseline patch atau daftar Install Override. Anda dapat memilih untuk menunjukkan Patch Manager kepada Anda hanya laporan patch yang hilang (`Scan`operasi), atau Anda dapat memilih Patch Manager untuk secara otomatis menginstal semua patch yang ditemukan hilang dari node terkelola (`Scan and install`operasi).

**catatan**  
Data kepatuhan tambalan mewakili point-in-time snapshot dari operasi patching terbaru yang berhasil. Setiap laporan kepatuhan berisi waktu pengambilan yang mengidentifikasi kapan status kepatuhan dihitung. Saat meninjau data kepatuhan, pertimbangkan waktu pengambilan untuk menentukan apakah operasi dijalankan seperti yang diharapkan.

Patch Managermenyediakan baseline patch standar yang dapat Anda gunakan untuk operasi patching Anda; namun, konfigurasi yang telah ditentukan ini disediakan sebagai contoh dan bukan sebagai praktik terbaik yang direkomendasikan. Kami menyarankan Anda membuat baseline patch kustom Anda sendiri untuk melakukan kontrol yang lebih besar atas apa yang merupakan kepatuhan patch untuk armada Anda.

Untuk informasi selengkapnya tentang garis dasar tambalan, lihat topik berikut:
+ [Garis dasar patch yang telah ditentukan dan kustom](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md)
+ [Melihat AWS baseline patch yang telah ditentukan](patch-manager-view-predefined-patch-baselines.md)
+ [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md)
+ [Bekerja dengan laporan kepatuhan tambalan](patch-manager-compliance-reports.md)

## Komponen utama
<a name="primary-components"></a>

Sebelum Anda mulai bekerja dengan Patch Manager alat ini, Anda harus membiasakan diri dengan beberapa komponen dan fitur utama dari operasi penambalan alat.

**Garis dasar patch**  
Patch Managermenggunakan *garis dasar tambalan*, yang mencakup aturan untuk patch yang menyetujui otomatis dalam beberapa hari setelah rilis, selain daftar opsional tambalan yang disetujui dan ditolak. Saat operasi penambalan berjalan, Patch Manager bandingkan tambalan yang saat ini diterapkan ke node terkelola dengan yang harus diterapkan sesuai dengan aturan yang diatur di baseline patch. Anda dapat memilih untuk menunjukkan Patch Manager kepada Anda hanya laporan patch yang hilang (`Scan`operasi), atau Anda dapat memilih Patch Manager untuk secara otomatis menginstal semua patch yang ditemukan hilang dari node terkelola (`Scan and install`operasi).

**Metode operasi penambalan**  
Patch Managersaat ini menawarkan empat metode untuk menjalankan `Scan` dan `Scan and install` operasi:
+ **(Disarankan) Kebijakan tambalan yang dikonfigurasi dalam Quick Setup** — Berdasarkan integrasi dengan AWS Organizations, kebijakan tambalan tunggal dapat menentukan jadwal penambalan dan garis dasar tambalan untuk seluruh organisasi, termasuk beberapa Akun AWS dan semua akun Wilayah AWS tersebut beroperasi. Kebijakan patch juga dapat menargetkan hanya beberapa unit organisasi (OUs) dalam suatu organisasi. Anda dapat menggunakan kebijakan patch tunggal untuk memindai dan menginstal pada jadwal yang berbeda. Untuk informasi selengkapnya, lihat [Mengonfigurasi penambalan untuk instance di organisasi menggunakan kebijakan tambalan Quick Setup](quick-setup-patch-manager.md) dan [Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).
+ **Opsi Manajemen Host yang dikonfigurasi dalam Quick Setup** - Konfigurasi Manajemen Host juga didukung oleh integrasi dengan AWS Organizations, sehingga memungkinkan untuk menjalankan operasi penambalan hingga seluruh Organisasi. Namun, opsi ini terbatas pada pemindaian tambalan yang hilang menggunakan baseline patch default saat ini dan memberikan hasil dalam laporan kepatuhan. Metode operasi ini tidak dapat menginstal tambalan. Untuk informasi selengkapnya, lihat [Siapkan manajemen host Amazon EC2 menggunakan Quick Setup](quick-setup-host-management.md).
+ **Jendela pemeliharaan untuk menjalankan tambalan `Scan` atau `Install` tugas** - Jendela pemeliharaan, yang Anda atur di alat Systems Manager yang disebutMaintenance Windows, dapat dikonfigurasi untuk menjalankan berbagai jenis tugas pada jadwal yang Anda tentukan. Tugas Run Command -type dapat digunakan untuk menjalankan `Scan` atau `Scan and install` tugas sekumpulan node terkelola yang Anda pilih. Setiap tugas jendela pemeliharaan dapat menargetkan node terkelola hanya dalam satu Akun AWSWilayah AWS pasangan. Untuk informasi selengkapnya, lihat [Tutorial: Buat jendela pemeliharaan untuk menambal menggunakan konsol](maintenance-window-tutorial-patching.md).
+ ****Patch sesuai permintaan sekarang** beroperasi di Patch Manager** — Opsi **Patch now** memungkinkan Anda melewati pengaturan jadwal saat Anda perlu menambal node yang dikelola secepat mungkin. Menggunakan **Patch sekarang**, Anda menentukan apakah akan menjalankan `Scan` atau `Scan and install` operasi dan node terkelola mana yang menjalankan operasi. Anda juga dapat memilih untuk menjalankan dokumen Systems Manager (dokumen SSM) sebagai kait siklus hidup selama operasi penambalan. Setiap operasi **Patch sekarang** dapat menargetkan node terkelola hanya dalam satu Akun AWSWilayah AWS pasangan. Untuk informasi selengkapnya, lihat [Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md).

**Pelaporan kepatuhan**  
Setelah `Scan` operasi, Anda dapat menggunakan konsol Systems Manager untuk melihat informasi tentang node terkelola mana yang tidak sesuai dengan patch, dan patch mana yang hilang dari masing-masing node tersebut. Anda juga dapat membuat laporan kepatuhan patch dalam format.csv yang dikirim ke bucket Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3) pilihan Anda. Anda dapat membuat laporan satu kali, atau membuat laporan pada jadwal rutin. Untuk satu node terkelola, laporan menyertakan detail semua tambalan untuk node. Untuk laporan tentang semua node terkelola, hanya ringkasan berapa banyak tambalan yang hilang yang disediakan. Setelah laporan dibuat, Anda dapat menggunakan alat seperti Amazon Quick untuk mengimpor dan menganalisis data. Untuk informasi selengkapnya, lihat [Bekerja dengan laporan kepatuhan tambalan](patch-manager-compliance-reports.md).

**catatan**  
Item kepatuhan yang dihasilkan melalui penggunaan kebijakan tambalan memiliki jenis eksekusi`PatchPolicy`. Item kepatuhan yang tidak dihasilkan dalam operasi kebijakan tambalan memiliki jenis eksekusi`Command`.

**Integrasi**  
Patch Managerterintegrasi dengan yang lain Layanan AWS berikut: 
+ **AWS Identity and Access Management (IAM)** — Gunakan IAM untuk mengontrol pengguna, grup, dan peran mana yang memiliki akses ke Patch Manager operasi. Untuk informasi selengkapnya, lihat [Cara kerja AWS Systems Manager dengan IAM](security_iam_service-with-iam.md) dan [Mengonfigurasi izin instans yang diperlukan untuk Systems Manager](setup-instance-permissions.md). 
+ **AWS CloudTrail**— Gunakan CloudTrail untuk merekam riwayat yang dapat diaudit dari peristiwa operasi penambalan yang diprakarsai oleh pengguna, peran, atau grup. Untuk informasi selengkapnya, lihat [Pencatatan panggilan AWS Systems Manager API dengan AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**— Data kepatuhan Patch dari Patch Manager dapat dikirim ke AWS Security Hub CSPM. Security Hub CSPM memberi Anda pandangan komprehensif tentang peringatan keamanan prioritas tinggi dan status kepatuhan Anda. Hub juga memantau status patching armada Anda. Untuk informasi selengkapnya, lihat [Integrasi dengan Patch Manager AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 
+ **AWS Config**— Siapkan perekaman AWS Config untuk melihat data manajemen instans Amazon EC2 di Dasbor. Patch Manager Lihat informasi yang lebih lengkap di [Melihat ringkasan Patch Dasbor](patch-manager-view-dashboard-summaries.md).

**Topics**
+ [Bagaimana bisa Patch Manager menguntungkan organisasi saya?](#how-can-patch-manager-benefit-my-organization)
+ [Siapa yang harus menggunakanPatch Manager?](#who-should-use-patch-manager)
+ [Apa saja fitur utamaPatch Manager?](#what-are-the-main-features-of-patch-manager)
+ [Apa itu kepatuhanPatch Manager?](#patch-manager-definition-of-compliance)
+ [Komponen utama](#primary-components)
+ [Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md)
+ [Prasyarat Patch Manager](patch-manager-prerequisites.md)
+ [Bagaimana Patch Manager operasi bekerja](patch-manager-patching-operations.md)
+ [Dokumen SSM Command untuk menambal node terkelola](patch-manager-ssm-documents.md)
+ [Garis dasar patch](patch-manager-patch-baselines.md)
+ [Menggunakan node Kernel Live Patching terkelola Amazon Linux 2](patch-manager-kernel-live-patching.md)
+ [Bekerja dengan Patch Manager sumber daya dan kepatuhan menggunakan konsol](patch-manager-console.md)
+ [Bekerja dengan Patch Manager sumber daya menggunakan AWS CLI](patch-manager-cli-commands.md)
+ [AWS Systems ManagerPatch Managertutorial](patch-manager-tutorials.md)
+ [Pemecahan Masalah Patch Manager](patch-manager-troubleshooting.md)

# Konfigurasi kebijakan tambalan di Quick Setup
<a name="patch-manager-policies"></a>

AWS merekomendasikan penggunaan *kebijakan tambalan* untuk mengonfigurasi penambalan untuk organisasi Anda dan Akun AWS. Kebijakan tambalan diperkenalkan Patch Manager pada bulan Desember 2022. 

Kebijakan tambalan adalah konfigurasi yang Anda atur menggunakanQuick Setup, alat di AWS Systems Manager. Kebijakan tambalan memberikan kontrol yang lebih luas dan lebih terpusat atas operasi patching Anda daripada yang tersedia dengan metode konfigurasi patching sebelumnya. Kebijakan patch dapat digunakan dengan [semua sistem operasi yang didukung oleh Patch Manager](patch-manager-prerequisites.md#pm-prereqs), termasuk versi Linux yang didukungmacOS, danWindows Server. Untuk petunjuk cara membuat kebijakan tambalan, lihat[Mengonfigurasi penambalan untuk instance di organisasi menggunakan kebijakan tambalan Quick Setup](quick-setup-patch-manager.md).

## Fitur utama kebijakan tambalan
<a name="patch-policies-about-major-features"></a>

Alih-alih menggunakan metode lain untuk menambal node Anda, gunakan kebijakan tambalan untuk memanfaatkan fitur-fitur utama ini:
+ **Penyiapan tunggal** — Menyiapkan operasi penambalan menggunakan jendela pemeliharaan atau State Manager asosiasi dapat memerlukan banyak tugas di berbagai bagian konsol Systems Manager. Menggunakan kebijakan tambalan, semua operasi penambalan Anda dapat diatur dalam satu wizard.
+ **Dukungan multi-akun/multi-wilayah** — Menggunakan jendela pemeliharaan, State Manager asosiasi, atau fitur **Patch now** diPatch Manager, Anda dibatasi untuk menargetkan node terkelola dalam satu pasangan. Akun AWSWilayah AWS Jika Anda menggunakan beberapa akun dan beberapa Wilayah, tugas penyiapan dan pemeliharaan Anda dapat memerlukan banyak waktu, karena Anda harus melakukan tugas penyiapan di setiap pasangan Account-region. Namun, jika Anda menggunakannya AWS Organizations, Anda dapat menyiapkan satu kebijakan tambalan yang berlaku untuk semua node terkelola Wilayah AWS di semua node Anda Akun AWS. Atau, jika Anda memilih, kebijakan tambalan hanya dapat berlaku untuk beberapa unit organisasi (OUs) di akun dan Wilayah yang Anda pilih. Kebijakan tambalan juga dapat berlaku untuk satu akun lokal, jika Anda mau.
+ **Dukungan instalasi di tingkat organisasi** — Opsi konfigurasi Manajemen Host yang ada di Quick Setup menyediakan dukungan untuk pemindaian harian node terkelola Anda untuk kepatuhan patch. Namun, pemindaian ini dilakukan pada waktu yang telah ditentukan dan hanya menghasilkan informasi kepatuhan tambalan. Tidak ada instalasi patch yang dilakukan. Menggunakan kebijakan tambalan, Anda dapat menentukan jadwal yang berbeda untuk pemindaian dan pemasangan. Anda juga dapat memilih frekuensi dan waktu operasi ini dengan menggunakan ekspresi CRON atau Rate kustom. Misalnya, Anda dapat memindai tambalan yang hilang setiap hari untuk memberi Anda informasi kepatuhan yang diperbarui secara berkala. Tapi, jadwal instalasi Anda bisa hanya seminggu sekali untuk menghindari downtime yang tidak diinginkan.
+ **Pemilihan baseline patch yang disederhanakan** — Kebijakan patch masih menggabungkan baseline patch, dan tidak ada perubahan pada cara baseline patch dikonfigurasi. Namun, saat Anda membuat atau memperbarui kebijakan tambalan, Anda dapat memilih baseline AWS terkelola atau kustom yang ingin Anda gunakan untuk setiap jenis sistem operasi (OS) dalam satu daftar. Tidak perlu menentukan baseline default untuk setiap jenis OS dalam tugas terpisah.

**catatan**  
Saat menambal operasi berdasarkan kebijakan patch dijalankan, mereka menggunakan dokumen `AWS-RunPatchBaseline` SSM. Untuk informasi selengkapnya, lihat [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

**Informasi Terkait**  
[Terapkan operasi patching secara terpusat di seluruh AWS Organisasi Anda menggunakan Systems Manager Quick Setup](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) (AWS Cloud Operations and Migrations Blog)

## Perbedaan lain dengan kebijakan tambalan
<a name="patch-policies-about-other-features"></a>

Berikut adalah beberapa perbedaan lain yang perlu diperhatikan saat menggunakan kebijakan tambalan alih-alih metode konfigurasi tambalan sebelumnya:
+ **Tidak diperlukan grup tambalan** — Dalam operasi penambalan sebelumnya, Anda dapat menandai beberapa node untuk menjadi milik grup tambalan, dan kemudian menentukan garis dasar tambalan yang akan digunakan untuk grup tambalan itu. Jika tidak ada grup tambalan yang ditentukan, instance yang Patch Manager ditambal dengan baseline patch default saat ini untuk jenis OS. Menggunakan kebijakan tambalan, tidak perlu lagi menyiapkan dan memelihara grup tambalan. 
**catatan**  
Fungsionalitas grup tambalan tidak didukung di konsol untuk pasangan wilayah Akun yang belum menggunakan grup tambalan sebelum dukungan kebijakan tambalan dirilis pada 22 Desember 2022. Fungsionalitas grup patch masih tersedia di pasangan Account-region yang mulai menggunakan grup patch sebelum tanggal ini.
+ **Halaman 'Configure patching' dihapus** **— Sebelum rilis kebijakan patch, Anda dapat menentukan default node mana yang akan ditambal, jadwal patching, dan operasi patching pada halaman Patching Configure.** Halaman ini telah dihapus dariPatch Manager. Opsi ini sekarang ditentukan dalam kebijakan tambalan. 
+ **Tidak ada dukungan 'Patch now'** — Kemampuan untuk menambal node sesuai permintaan masih terbatas pada satu Akun AWSWilayah AWS pasangan pada satu waktu. Untuk informasi, lihat [Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md).
+ **Kebijakan tambalan dan informasi kepatuhan** — Saat node terkelola dipindai untuk kepatuhan sesuai dengan konfigurasi kebijakan penambalan, data kepatuhan akan tersedia untuk Anda. Anda dapat melihat dan bekerja dengan data dengan cara yang sama seperti metode pemindaian kepatuhan lainnya. Meskipun Anda dapat menyiapkan kebijakan tambalan untuk seluruh organisasi atau beberapa unit organisasi, informasi kepatuhan dilaporkan secara individual untuk setiap Akun AWSWilayah AWS pasangan. Untuk informasi selengkapnya, lihat [Bekerja dengan laporan kepatuhan tambalan](patch-manager-compliance-reports.md).
+ **Status kepatuhan asosiasi dan kebijakan tambalan** — Status patching untuk node terkelola yang berada di bawah kebijakan Quick Setup tambalan cocok dengan status eksekusi State Manager asosiasi untuk node tersebut. Jika status eksekusi asosiasi adalah`Compliant`, status patching untuk node terkelola juga ditandai`Compliant`. Jika status eksekusi asosiasi adalah`Non-Compliant`, status patching untuk node terkelola juga ditandai`Non-Compliant`. 

## Wilayah AWS didukung untuk kebijakan tambalan
<a name="patch-policies-supported-regions"></a>

Konfigurasi kebijakan tambalan di Quick Setup saat ini didukung di Wilayah berikut:
+ AS Timur (Ohio) (us-east-2)
+ AS Timur (Virginia Utara) (us-east-1)
+ AS Barat (California Utara) (us-west-1)
+ AS Barat (Oregon) (us-west-2)
+ Asia Pacific (Mumbai) (ap-south-1)
+ Asia Pacific (Seoul) (ap-northeast-2)
+ Asia Pasifik (Singapura) (ap-southeast-1)
+ Asia Pacific (Sydney) (ap-southeast-2)
+ Asia Pacific (Tokyo) (ap-northeast-1)
+ Kanada (Pusat) (ca-central-1)
+ Eropa (Frankfurt) (eu-central-1)
+ Eropa (Irlandia) (eu-west-1)
+ Eropa (London) (eu-west-2)
+ Eropa (Paris) (eu-west-3)
+ Eropa (Stockholm) (eu-north-1)
+ Amerika Selatan (Sao Paulo) (sa-east-1)

# Prasyarat Patch Manager
<a name="patch-manager-prerequisites"></a>

Pastikan Anda telah memenuhi prasyarat yang diperlukan sebelum menggunakanPatch Manager, alat di. AWS Systems Manager

**Topics**
+ [Versi SSM Agent](#agent-versions)
+ [Versi Python](#python-version)
+ [Persyaratan paket tambahan](#additional-package-requirements)
+ [Konektivitas ke sumber patch](#source-connectivity)
+ [Akses titik akhir S3](#s3-endpoint-access)
+ [Izin untuk menginstal tambalan secara lokal](#local-installation-permissions)
+ [Sistem operasi yang didukung untuk Patch Manager](#supported-os)

## Versi SSM Agent
<a name="agent-versions"></a>

Versi 2.0.834.0 atau yang lebih baru berjalan pada node SSM Agent terkelola yang ingin Anda kelola. Patch Manager

**catatan**  
Versi terbaru dirilis setiap kali alat baru ditambahkan ke Systems Manager atau pembaruan dibuat ke alat yang ada. SSM Agent Gagal menggunakan agen versi terbaru dapat mencegah node terkelola Anda menggunakan berbagai alat dan fitur Systems Manager. Untuk alasan itu, kami menyarankan Anda mengotomatiskan proses menjaga agar tetap SSM Agent up to date pada mesin Anda. Untuk informasi, lihat [Mengotomatiskan pembaruan ke SSM Agent](ssm-agent-automatic-updates.md). Berlangganan halaman [Catatan SSM Agent Rilis](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) GitHub untuk mendapatkan pemberitahuan tentang SSM Agent pembaruan.

## Versi Python
<a name="python-version"></a>

Untuk macOS dan sebagian besar sistem operasi Linux (OSs), Patch Manager saat ini mendukung Python versi 2.6 - 3.12. The AlmaLinux,Debian Server, dan Ubuntu Server OSs memerlukan versi Python 3 yang didukung (3.0 - 3.12).

## Persyaratan paket tambahan
<a name="additional-package-requirements"></a>

Untuk sistem operasi berbasis DNF, `zstd``xz`, dan `unzip` utilitas mungkin diperlukan untuk mendekompresi informasi repositori dan file patch. Sistem operasi berbasis DNF termasuk Amazon Linux 2023, Red Hat Enterprise Linux 8 dan versi yang lebih baru, 8 dan versi yang lebih baru,,Rocky Linux, AlmaLinux & CentOS Oracle Linux 8 dan versi yang lebih baru. Jika Anda melihat kesalahan yang mirip dengan`No such file or directory: b'zstd'`,`No such file or directory: b'unxz'`, atau kegagalan menambal karena hilang`unzip`, maka Anda perlu menginstal utilitas ini. `zstd`,`xz`, dan `unzip` dapat diinstal dengan menjalankan yang berikut:

```
dnf install zstd xz unzip
```

## Konektivitas ke sumber patch
<a name="source-connectivity"></a>

Jika node terkelola Anda tidak memiliki koneksi langsung ke Internet dan Anda menggunakan Amazon Virtual Private Cloud (Amazon VPC) dengan titik akhir VPC, Anda harus memastikan bahwa node memiliki akses ke repositori patch sumber (repo). Pada node Linux, pembaruan patch biasanya diunduh dari repo jarak jauh yang dikonfigurasi pada node. Oleh karena itu, node harus dapat terhubung ke repo sehingga penambalan dapat dilakukan. Untuk informasi selengkapnya, lihat [Cara pemilihan patch keamanan](patch-manager-selecting-patches.md).

Saat menambal node yang berjalan di lingkungan IPv6 satu-satunya, pastikan node memiliki konektivitas ke sumber patch. Anda dapat memeriksa Run Command output dari eksekusi patching untuk memeriksa peringatan tentang repositori yang tidak dapat diakses. Untuk sistem operasi berbasis DNF, dimungkinkan untuk mengonfigurasi repositori yang tidak tersedia untuk dilewati selama penambalan jika opsi diatur ke bawah. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Sistem operasi berbasis DNF termasuk Amazon Linux 2023, Red Hat Enterprise Linux 8 dan versi yang lebih baru, 8 dan versi yang lebih baru,,Rocky Linux, AlmaLinux & CentOS Oracle Linux 8 dan versi yang lebih baru. Di Amazon Linux 2023, `skip_if_unavailable` opsi diatur ke secara `True` default.

**CentOS Stream: Aktifkan `EnableNonSecurity` bendera**  
CentOS Streamnode menggunakan DNF sebagai manajer paket, yang 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 memungkinkan memproses paket yang tidak terkandung dalam pemberitahuan pembaruan, Anda harus mengaktifkan `EnableNonSecurity` bendera dalam aturan dasar tambalan.

**Windows Server: Pastikan konektivitas ke Katalog Pembaruan Windows atau Layanan Pembaruan Server Windows (WSUS)**  
Windows Servernode yang dikelola harus dapat terhubung ke Katalog Pembaruan Windows atau Layanan Pembaruan Server Windows (WSUS). Konfirmasikan bahwa node Anda memiliki konektivitas ke [Katalog Pembaruan Microsoft](https://www.catalog.update.microsoft.com/home.aspx) melalui gateway internet, gateway NAT, atau instance NAT. Jika Anda menggunakan WSUS, konfirmasikan bahwa node memiliki konektivitas ke server WSUS di lingkungan Anda. Untuk informasi selengkapnya, lihat [Masalah: node terkelola tidak memiliki akses ke Katalog Pembaruan Windows atau WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).

## Akses titik akhir S3
<a name="s3-endpoint-access"></a>

Baik node terkelola Anda beroperasi di jaringan pribadi atau publik, tanpa akses ke bucket Amazon Simple Storage Service (Amazon S3) AWS terkelola yang diperlukan, operasi penambalan gagal. Untuk informasi tentang bucket S3 node terkelola Anda harus dapat mengakses, lihat [SSM Agentkomunikasi dengan bucket S3 AWS terkelola](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) dan. [Meningkatkan keamanan instans EC2 dengan menggunakan titik akhir VPC untuk Systems Manager](setup-create-vpc.md) 

## Izin untuk menginstal tambalan secara lokal
<a name="local-installation-permissions"></a>

Sistem operasi On Windows Server dan Linux, Patch Manager mengasumsikan Administrator dan akun pengguna root, masing-masing, untuk menginstal tambalan.

NamunmacOS, untuk Brew dan Brew Cask, Homebrew tidak mendukung perintahnya yang berjalan di bawah akun pengguna root. Akibatnya, Patch Manager kueri untuk dan menjalankan perintah Homebrew baik sebagai pemilik direktori Homebrew, atau sebagai pengguna valid milik grup pemilik direktori Homebrew. Oleh karena itu, untuk menginstal tambalan, pemilik `homebrew` direktori juga memerlukan izin pemilik rekursif untuk direktori. `/usr/local`

**Tip**  
Perintah berikut memberikan izin ini untuk pengguna yang ditentukan:  

```
sudo chown -R $USER:admin /usr/local
```

## Sistem operasi yang didukung untuk Patch Manager
<a name="supported-os"></a>

Patch ManagerAlat ini mungkin tidak mendukung semua versi sistem operasi yang sama yang didukung oleh alat Systems Manager lainnya. (Untuk daftar lengkap sistem operasi yang didukung oleh Systems Manager, lihat [Sistem operasi yang didukung untuk Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).) Oleh karena itu, pastikan bahwa node terkelola yang Patch Manager ingin Anda gunakan menjalankan salah satu sistem operasi yang tercantum dalam tabel berikut.

**catatan**  
Patch Managerbergantung pada repositori patch yang dikonfigurasi pada node terkelola, seperti Katalog Pembaruan Windows dan Layanan Pembaruan Server Windows untuk Windows, untuk mengambil tambalan yang tersedia untuk diinstal. Oleh karena itu, untuk versi sistem operasi akhir masa pakai (EOL), jika tidak ada pembaruan baru yang tersedia, Patch Manager mungkin tidak dapat melaporkan pembaruan baru. Ini bisa karena tidak ada pembaruan baru yang dirilis oleh pengelola distribusi Linux, Microsoft, atau Apple, atau karena node yang dikelola tidak memiliki lisensi yang tepat untuk mengakses pembaruan baru.  
Kami sangat menyarankan agar Anda menghindari penggunaan versi OS yang telah mencapai End-of-Life (EOL). Vendor OS termasuk AWS biasanya tidak menyediakan patch keamanan atau pembaruan lain untuk versi yang telah mencapai EOL. Terus menggunakan sistem EOL sangat meningkatkan risiko tidak dapat menerapkan peningkatan, termasuk perbaikan keamanan, dan masalah operasional lainnya. AWS tidak menguji fungsionalitas Systems Manager pada versi OS yang telah mencapai EOL.  
Patch Managermelaporkan status kepatuhan terhadap tambalan yang tersedia pada node terkelola. Oleh karena itu, jika sebuah instance menjalankan sistem operasi EOL, dan tidak ada pembaruan yang tersedia, Patch Manager mungkin melaporkan node sebagai Compliant, tergantung pada baseline patch yang dikonfigurasi untuk operasi patching.


| Sistem operasi | Detail | 
| --- | --- | 
|  Linux  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-prerequisites.html)  | 
| macOS |  *macOSdidukung hanya untuk instans Amazon EC2.* 13.0—13.7 (Ventura) *14.x* (Sonoma) 15. *x* (Sequoia)  macOSPembaruan OS Patch Managertidak mendukung pembaruan atau peningkatan sistem operasi (OS) untukmacOS, seperti dari 13.1 hingga 13.2. Untuk melakukan pembaruan versi OSmacOS, kami sarankan untuk menggunakan mekanisme peningkatan OS bawaan Apple. Untuk informasi selengkapnya, lihat [Manajemen Perangkat](https://developer.apple.com/documentation/devicemanagement) di situs web Dokumentasi Pengembang Apple.   Dukungan Homebrew Patch Managermemerlukan Homebrew, sistem manajemen paket perangkat lunak sumber terbuka, untuk diinstal di salah satu lokasi penginstalan default berikut:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-prerequisites.html) Operasi penambalan menggunakan Patch Manager gagal berfungsi dengan benar saat Homebrew tidak diinstal.  Dukungan Wilayah macOStidak didukung sama sekali Wilayah AWS. Untuk informasi selengkapnya tentang dukungan Amazon EC2macOS, lihat instans [Amazon EC2 Mac](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) di Panduan Pengguna Amazon *EC2*.   macOSperangkat tepi SSM Agentuntuk perangkat AWS IoT Greengrass inti tidak didukung padamacOS. Anda tidak dapat menggunakan Patch Manager untuk menambal perangkat macOS tepi.   | 
|  Windows  |  Windows Server2012 hingga Windows Server 2025, termasuk versi R2.  SSM Agentuntuk perangkat AWS IoT Greengrass inti tidak didukung pada Windows 10. Anda tidak dapat menggunakan Patch Manager untuk menambal perangkat Windows 10 edge.   Windows ServerDukungan 2012 dan 2012 R2 Windows Server2012 dan 2012 R2 mencapai akhir dukungan pada 10 Oktober 2023. Untuk menggunakan Patch Manager versi ini, kami sarankan juga menggunakan Pembaruan Keamanan Diperpanjang (ESUs) dari Microsoft. Untuk informasi selengkapnya, lihat [Windows Server2012 dan 2012 R2 mencapai akhir dukungan](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support) di situs web Microsoft.   | 

# Bagaimana Patch Manager operasi bekerja
<a name="patch-manager-patching-operations"></a>

Bagian ini memberikan rincian teknis yang menjelaskan bagaimanaPatch Manager, alat di AWS Systems Manager, menentukan patch mana yang akan diinstal dan bagaimana menginstalnya pada setiap sistem operasi yang didukung. Untuk sistem operasi Linux, ini juga menyediakan informasi tentang menentukan repositori sumber, dalam baseline patch khusus, untuk tambalan selain default yang dikonfigurasi pada node terkelola. Bagian ini juga menyediakan detail tentang cara aturan dasar patch bekerja pada distribusi sistem operasi Linux yang berbeda.

**catatan**  
Informasi dalam topik berikut berlaku tidak peduli metode atau jenis konfigurasi yang Anda gunakan untuk operasi patching Anda:  
Kebijakan tambalan yang dikonfigurasi di Quick Setup
Opsi Manajemen Host yang dikonfigurasi di Quick Setup
Jendela pemeliharaan untuk menjalankan tambalan `Scan` atau `Install` tugas
**Patch sesuai permintaan sekarang beroperasi**

**Topics**
+ [Bagaimana tanggal rilis paket dan tanggal pembaruan dihitung](patch-manager-release-dates.md)
+ [Cara pemilihan patch keamanan](patch-manager-selecting-patches.md)
+ [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md)
+ [Cara menginstal patch](patch-manager-installing-patches.md)
+ [Cara kerja aturan dasar patch pada sistem berbasis Linux](patch-manager-linux-rules.md)
+ [Menambal perbedaan operasi antara Linux dan Windows Server](patch-manager-windows-and-linux-differences.md)

# Bagaimana tanggal rilis paket dan tanggal pembaruan dihitung
<a name="patch-manager-release-dates"></a>

**penting**  
Informasi di halaman ini berlaku untuk sistem operasi (OS) Amazon Linux 2 dan Amazon Linux 2023 untuk instans Amazon Elastic Compute Cloud (Amazon EC2). Paket untuk jenis OS ini dibuat dan dikelola oleh Amazon Web Services. Bagaimana produsen sistem operasi lain mengelola paket dan repositori mereka memengaruhi bagaimana tanggal rilis dan tanggal pembaruan mereka dihitung. Untuk OSs selain Amazon Linux 2 dan Amazon Linux 2023, sepertiRed Hat Enterprise Linux, lihat dokumentasi pabrikan untuk informasi tentang bagaimana paket mereka diperbarui dan dipelihara.

Dalam pengaturan untuk [baseline patch kustom](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) yang Anda buat, untuk sebagian besar jenis OS, Anda dapat menentukan bahwa patch disetujui secara otomatis untuk instalasi setelah beberapa hari tertentu. AWS menyediakan beberapa baseline patch yang telah ditentukan yang mencakup tanggal persetujuan otomatis 7 hari.

*Penundaan persetujuan otomatis* adalah jumlah hari untuk menunggu setelah tambalan dirilis, sebelum tambalan secara otomatis disetujui untuk ditambal. Misalnya, Anda membuat aturan menggunakan `CriticalUpdates` klasifikasi dan mengonfigurasinya selama 7 hari penundaan persetujuan otomatis. Akibatnya, tambalan kritis baru dengan tanggal rilis atau tanggal pembaruan terakhir 7 Juli secara otomatis disetujui pada 14 Juli.

Untuk menghindari hasil yang tidak terduga dengan penundaan persetujuan otomatis di Amazon Linux 2 dan Amazon Linux 2023, penting untuk memahami bagaimana tanggal rilis dan tanggal pembaruan mereka dihitung.

**catatan**  
Jika repositori Amazon Linux 2 atau Amazon Linux 2023 tidak memberikan informasi tanggal rilis untuk paket, Patch Manager gunakan waktu pembuatan paket sebagai tanggal untuk spesifikasi tanggal persetujuan otomatis. Jika waktu pembuatan paket tidak dapat ditentukan, Patch Manager gunakan tanggal default 1 Januari 1970. Ini menghasilkan Patch Manager melewati spesifikasi tanggal persetujuan otomatis apa pun di garis dasar tambalan yang dikonfigurasi untuk menyetujui tambalan untuk tanggal apa pun setelah 1 Januari 1970.

Dalam kebanyakan kasus, waktu tunggu persetujuan otomatis sebelum tambalan diinstal dihitung dari `Updated Date` nilai dalam`updateinfo.xml`, bukan nilai. `Release Date` Berikut ini adalah detail penting tentang perhitungan tanggal ini: 
+ `Release Date`Ini adalah tanggal *pemberitahuan* dirilis. Ini tidak berarti paket tersebut harus tersedia di repositori terkait. 
+ `Update Date`Ini adalah tanggal terakhir pemberitahuan diperbarui. Pembaruan pemberitahuan dapat mewakili sesuatu yang sekecil pembaruan teks atau deskripsi. Ini tidak berarti paket dirilis sejak tanggal tersebut atau harus tersedia di repositori terkait. 

  Ini berarti bahwa sebuah paket dapat memiliki `Update Date` nilai 7 Juli tetapi tidak tersedia untuk instalasi sampai (misalnya) 13 Juli. Misalkan untuk kasus ini bahwa baseline patch yang menentukan penundaan persetujuan otomatis 7 hari berjalan dalam operasi pada 14 Juli. `Install` Karena `Update Date` nilainya 7 hari sebelum tanggal berjalan, tambalan dan pembaruan dalam paket diinstal pada 14 Juli. Instalasi terjadi meskipun hanya 1 hari telah berlalu sejak paket tersedia untuk instalasi yang sebenarnya.
+ Paket yang berisi sistem operasi atau patch aplikasi dapat diperbarui lebih dari satu kali setelah rilis awal.
+ Sebuah paket dapat dirilis ke repositori AWS terkelola tetapi kemudian diputar kembali jika masalah kemudian ditemukan dengannya.

Dalam beberapa operasi penambalan, faktor-faktor ini mungkin tidak penting. Misalnya, jika baseline patch dikonfigurasi untuk menginstal patch dengan nilai keparahan `Low` dan`Medium`, dan klasifikasi, penundaan persetujuan otomatis apa pun mungkin berdampak kecil pada operasi Anda. `Recommended`

Namun, dalam kasus di mana waktu tambalan kritis atau tingkat keparahan tinggi lebih penting, Anda mungkin ingin melakukan kontrol lebih besar saat tambalan dipasang. Metode yang disarankan untuk melakukan ini adalah dengan menggunakan repositori sumber patch alternatif alih-alih repositori default untuk menambal operasi pada node yang dikelola. 

Anda dapat menentukan repositori sumber patch alternatif ketika membuat dasar patch kustom. Di setiap dasar patch kustom, Anda dapat menentukan konfigurasi sumber patch hingga 20 versi sistem operasi Linux yang didukung. Lihat informasi yang lebih lengkap di [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md).

# Cara pemilihan patch keamanan
<a name="patch-manager-selecting-patches"></a>

Fokus utamaPatch Manager, alat di AWS Systems Manager, adalah menginstal pembaruan terkait keamanan sistem operasi pada node yang dikelola. Secara default, Patch Manager tidak menginstal semua tambalan yang tersedia, melainkan serangkaian tambalan 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 yang berbeda nama kecuali penggantian ini diperlukan oleh instalasi pembaruan paket lain. Sebagai gantinya, untuk perintah yang memperbarui paket, Patch Manager hanya melaporkan dan menginstal pembaruan yang hilang untuk paket yang diinstal tetapi sudah usang. Ini karena mengganti paket usang biasanya memerlukan penghapusan paket yang ada dan menginstal penggantinya. Mengganti paket usang dapat menyebabkan perubahan yang melanggar 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](patch-manager-installing-patches.md).

**catatan**  
Saat Anda menggunakan `ApproveUntilDate` parameter atau `ApproveAfterDays` parameter dalam aturan dasar patch, Patch Manager evaluasi tanggal rilis patch menggunakan Coordinated Universal Time (UTC).   
Misalnya, untuk`ApproveUntilDate`, jika Anda menentukan tanggal seperti`2025-11-16`, tambalan yang dirilis antara `2025-11-16T00:00:00Z` dan `2025-11-16T23:59:59Z` akan disetujui.   
Ketahuilah bahwa tanggal rilis tambalan yang ditampilkan oleh pengelola paket asli pada node terkelola Anda mungkin menunjukkan waktu yang berbeda berdasarkan zona waktu lokal sistem Anda, tetapi Patch Manager selalu menggunakan waktu tanggal UTC untuk perhitungan persetujuan. Ini memastikan konsistensi dengan tanggal rilis patch yang dipublikasikan di situs web penasihat keamanan resmi.

Untuk jenis sistem operasi berbasis Linux yang melaporkan tingkat keparahan 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 [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS), atau dari metrik yang dirilis oleh [National](https://nvd.nist.gov/vuln) Vulnerability Database (NVD).

**catatan**  
Pada semua sistem berbasis Linux yang didukung olehPatch Manager, Anda dapat memilih repositori sumber berbeda yang dikonfigurasi untuk node terkelola, biasanya untuk menginstal pembaruan nonsecurity. Untuk informasi, lihat [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md).

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

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Repositori yang telah dikonfigurasi sebelumnya ditangani secara berbeda di Amazon Linux 2 daripada di Amazon Linux 2023.

Di Amazon Linux 2, layanan baseline patch Systems Manager menggunakan repositori yang telah dikonfigurasi sebelumnya pada node terkelola. Biasanya ada dua repositori (repo) yang telah dikonfigurasi sebelumnya 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**  
*architecture*bisa x86\$164 atau (untuk prosesor Graviton) aarch64.

Saat Anda membuat instans Amazon Linux 2023 (AL2023), instans berisi pembaruan yang tersedia dalam versi AL2023 dan spesifik yang AMI Anda pilih. AL2023 Instans Anda tidak secara otomatis menerima pembaruan keamanan penting dan penting tambahan pada waktu peluncuran. Sebagai gantinya, dengan *peningkatan deterministik melalui fitur repositori berversi* yang didukung AL2023, yang diaktifkan secara default, Anda dapat menerapkan pembaruan berdasarkan jadwal yang memenuhi kebutuhan spesifik Anda. Untuk informasi selengkapnya, lihat [Peningkatan deterministik melalui repositori berversi](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) di Panduan Pengguna *Amazon* Linux 2023. 

Aktif AL2023, repositori yang telah dikonfigurasi 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) for AL2023 dirilis, mereka dikunci ke versi tertentu. Untuk pembaruan tambalan, Patch Manager ambil versi terkunci terbaru dari repositori pembaruan tambalan dan kemudian memperbarui paket pada node terkelola berdasarkan konten versi terkunci tersebut.

**Manajer Package**  
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 bernama`updateinfo.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 ini, Patch Manager tetapkan atribut pemberitahuan pembaruan ke paket terkait.

**catatan**  
Jika Anda memilih kotak centang **Sertakan pembaruan non-keamanan** di halaman **dasar Buat tambalan**, 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](patch-manager-installing-patches.md) dan[Cara kerja aturan dasar patch pada sistem berbasis Linux](patch-manager-linux-rules.md).

------
#### [  CentOS Aliran ]

PadaCentOS Stream, layanan baseline patch Systems Manager menggunakan repositori (repo) yang telah dikonfigurasi sebelumnya pada node terkelola. Daftar berikut memberikan contoh untuk CentOS 9.2 () fiktif: 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 penambalan 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 memungkinkan memproses paket yang tidak terkandung dalam pemberitahuan pembaruan, Anda harus mengaktifkan `EnableNonSecurity` bendera dalam aturan dasar tambalan.

**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 Systems Manager 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 penambalan dapat dilakukan.

Oracle Linuxnode terkelola menggunakan Yum sebagai manajer paket, dan Yum 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 tetapkan atribut pemberitahuan pembaruan ke paket terkait dan menginstal paket berdasarkan filter Klasifikasi yang ditentukan dalam baseline patch.

**catatan**  
Jika Anda memilih kotak centang **Sertakan pembaruan non-keamanan** di halaman **dasar Buat tambalan**, 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  ]

Pada AlmaLinux,Red Hat Enterprise Linux, dan Rocky Linux layanan baseline patch Systems Manager 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 penambalan dapat dilakukan.

**catatan**  
Jika Anda memilih kotak centang **Sertakan pembaruan non-keamanan** di halaman **dasar Buat tambalan**, 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 terkelola 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 tetapkan atribut pemberitahuan pembaruan ke paket terkait dan menginstal paket berdasarkan filter Klasifikasi yang ditentukan dalam baseline patch.

RHEL7  
Repo berikut IDs dikaitkan dengan RHUI 2. RHUI 3 diluncurkan pada Desember 2019 dan memperkenalkan skema penamaan yang berbeda untuk repositori Yum. IDs Bergantung pada RHEL-7 tempat AMI Anda membuat node terkelola, Anda mungkin perlu memperbarui perintah Anda. Untuk informasi selengkapnya, lihat [Repositori IDs untuk RHEL 7 di AWS Telah Berubah di Portal](https://access.redhat.com/articles/4599971) *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 terkelola SUSE Linux Enterprise Server (SLES), pustaka ZYPP mendapatkan daftar tambalan yang tersedia (kumpulan paket) dari lokasi berikut:
+ Daftar repositori: `etc/zypp/repos.d/*`
+ Informasi paket: `/var/cache/zypp/raw/*`

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

------
#### [ Ubuntu Server ]

PadaUbuntu Server, layanan baseline patch Systems Manager 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 `trusty` untuk 14. Ubuntu Server Patch Managerhanya mengidentifikasi peningkatan yang merupakan bagian dari repo ini: 
+ Ubuntu Server16.04 LTS: `xenial-security`
+ 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 Windows Server Update Services (WSUS).

**catatan**  
Patch Managerhanya membuat patch yang tersedia 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. Ketika informasi tambalan dari Microsoft diproses, Patch Manager menghapus pembaruan yang digantikan oleh pembaruan selanjutnya dari daftar tambalannya. Oleh karena itu, hanya pembaruan terbaru yang ditampilkan dan tersedia untuk instalasi. Misalnya, jika `KB4012214` menggantikan`KB3135456`, hanya `KB4012214` tersedia sebagai pembaruan diPatch Manager.

Demikian pula, Patch Manager dapat menginstal hanya patch yang tersedia pada node terkelola selama waktu operasi patching. Secara default, Windows Server 2019 dan Windows Server 2022 menghapus pembaruan yang digantikan oleh pembaruan selanjutnya. Akibatnya, jika Anda menggunakan `ApproveUntilDate` parameter dalam baseline Windows Server patch, tetapi tanggal yang dipilih dalam `ApproveUntilDate` parameter *sebelum* tanggal tambalan terbaru, maka skenario berikut terjadi:
+ Patch yang digantikan dihapus dari node dan oleh karena itu tidak dapat diinstal menggunakan. Patch Manager
+ Patch pengganti terbaru ada di node tetapi belum disetujui untuk instalasi sesuai tanggal yang ditentukan `ApproveUntilDate` parameter. 

Ini berarti bahwa node terkelola sesuai dalam hal operasi Systems Manager, meskipun patch kritis dari bulan sebelumnya mungkin tidak diinstal. Skenario yang sama ini dapat terjadi saat menggunakan `ApproveAfterDays` parameter. Karena perilaku patch yang digantikan Microsoft, dimungkinkan untuk menetapkan angka (umumnya lebih besar dari 30 hari) sehingga tambalan untuk Windows Server tidak pernah diinstal jika patch terbaru yang tersedia dari Microsoft dirilis sebelum jumlah hari telah berlalu. `ApproveAfterDays` Perhatikan bahwa perilaku sistem ini tidak berlaku jika Anda telah memodifikasi pengaturan Objek Kebijakan Grup Windows (GPO) 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.

------

# Cara menentukan repositori sumber patch alternatif (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Saat Anda menggunakan repositori default yang dikonfigurasi pada node terkelola untuk operasi penambalan, alat di Patch Manager AWS Systems Manager, memindai atau menginstal tambalan terkait keamanan. Ini adalah perilaku default untukPatch Manager. Untuk informasi selengkapnya tentang cara Patch Manager memilih dan menginstal patch keamanan, lihat. [Cara pemilihan patch keamanan](patch-manager-selecting-patches.md)

Namun, pada sistem Linux, Anda juga dapat menggunakan Patch Manager untuk menginstal tambalan yang tidak terkait dengan keamanan, atau yang berada di repositori sumber yang berbeda dari yang default yang dikonfigurasi pada node terkelola. Anda dapat menentukan repositori sumber patch alternatif ketika membuat dasar patch kustom. Di setiap dasar patch kustom, Anda dapat menentukan konfigurasi sumber patch hingga 20 versi sistem operasi Linux yang didukung. 

Misalnya, misalkan Ubuntu Server armada Anda menyertakan Ubuntu Server 25,04 node terkelola. Dalam kasus ini, Anda dapat menentukan repositori alternatif untuk setiap versi dalam dasar patch kustom yang sama. Untuk setiap versi, Anda memberikan nama, menentukan jenis versi sistem operasi (produk), dan menyediakan konfigurasi repositori. Anda juga dapat menentukan satu repositori sumber alternatif yang berlaku untuk semua versi sistem operasi yang didukung.

**catatan**  
Menjalankan baseline patch khusus yang menentukan repositori patch alternatif untuk node terkelola tidak menjadikannya repositori default baru pada sistem operasi. Setelah operasi patching selesai, repositori yang sebelumnya dikonfigurasi sebagai default untuk sistem operasi node tetap default.

Untuk daftar contoh skenario penggunaan opsi ini, lihat [Contoh penggunaan untuk repositori sumber patch alternatif](#patch-manager-alternative-source-repository-examples) yang tersedia nanti dalam topik ini.

Untuk informasi tentang dasar patch default dan kustom, lihat [Garis dasar patch yang telah ditentukan dan kustom](patch-manager-predefined-and-custom-patch-baselines.md).

**Contoh: Menggunakan konsol**  
Untuk menentukan repositori sumber patch alternatif ketika Anda bekerja di konsol Systems Manager, gunakan bagian **Sumber patch** pada halaman **Buat dasar patch**. Untuk informasi tentang penggunaan opsi **Sumber patch**, lihat [Membuat baseline patch khusus untuk Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**Contoh: Menggunakan AWS CLI**  
Untuk contoh penggunaan opsi `--sources` dengan AWS Command Line Interface (AWS CLI), lihat [Buat dasar patch dengan repositori kustom untuk versi OS yang berbeda](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Pertimbangan penting untuk repositori alternatif](#alt-source-repository-important)
+ [Contoh penggunaan untuk repositori sumber patch alternatif](#patch-manager-alternative-source-repository-examples)

## Pertimbangan penting untuk repositori alternatif
<a name="alt-source-repository-important"></a>

Ingatlah poin-poin berikut saat Anda merencanakan strategi patching Anda menggunakan repositori patch alternatif.

**Menerapkan verifikasi pembaruan repo (YUM dan DNF)**  
Konfigurasi default untuk manajer paket pada distribusi Linux mungkin diatur untuk melewati repositori paket yang tidak dapat dijangkau jika koneksi ke repositori tidak dapat dibuat. Untuk menerapkan verifikasi pembaruan repositori, tambahkan `skip_if_unavailable=False` ke konfigurasi repositori.

Untuk informasi selengkapnya tentang `skip_if_available` opsi, lihat[Konektivitas ke sumber patch](patch-manager-prerequisites.md#source-connectivity).

**Hanya repositori yang ditentukan yang digunakan untuk patching**  
Menentukan repositori alternatif tidak berarti menentukan repositori *tambahan*. Anda dapat memilih untuk menentukan repositori selain yang dikonfigurasi sebagai default pada node terkelola. Namun, Anda juga harus menentukan repositori default sebagai bagian dari konfigurasi sumber patch alternatif jika Anda ingin pembaruan mereka diterapkan.

Misalnya, pada node terkelola Amazon Linux 2, repositori defaultnya adalah `amzn2-core` dan. `amzn2extra-docker` Jika Anda ingin menyertakan repositori Extra Packages for Enterprise Linux (EPEL) di operasi patching Anda, Anda harus menentukan ketiga repositori tersebut sebagai repositori alternatif.

**catatan**  
Menjalankan baseline patch khusus yang menentukan repositori patch alternatif untuk node terkelola tidak menjadikannya repositori default baru pada sistem operasi. Setelah operasi patching selesai, repositori yang sebelumnya dikonfigurasi sebagai default untuk sistem operasi node tetap default.

**Perilaku patching untuk distribusi berbasis YUM bergantung pada manifes updateinfo.xml**  
Saat Anda menentukan repositori patch alternatif untuk distribusi berbasis Yum, seperti Amazon Linux 2, atauRed Hat Enterprise Linux, perilaku patching tergantung pada apakah repositori menyertakan manifes pembaruan dalam bentuk file yang lengkap dan diformat dengan benar. `updateinfo.xml` file ini menentukan tanggal rilis, klasifikasi, dan tingkat kepelikan dari berbagai paket. Salah satu dari hal berikut ini akan mempengaruhi perilaku patching:
+ Jika Anda memfilter **Klasifikasi** dan **Tingkat kepelikan**, tetapi keduanya tidak ditentukan dalam `updateinfo.xml`, paket tidak akan disertakan oleh filter. Ini juga berarti bahwa paket tanpa file `updateinfo.xml` tidak akan disertakan dalam patching.
+ Jika Anda memfilter **ApprovalAfterDays**, tetapi tanggal rilis paket tidak dalam format Unix Epoch (atau tidak memiliki tanggal rilis yang ditentukan), paket tidak akan disertakan oleh filter.
+ Ada pengecualian jika Anda memilih kotak centang **Sertakan pembaruan non-keamanan** di halaman **dasar Buat tambalan**. Dalam hal ini, paket tanpa file `updateinfo.xml` (atau yang berisi file ini tanpa format **Klasifikasi**, **Tingkat kepelikan**, dan nilai **Tanggal** yang benar) *akan* disertakan ke dalam daftar patch pra-filter. (Mereka tetap harus memenuhi persyaratan aturan dasar patch lainnya agar dapat diinstal.)

## Contoh penggunaan untuk repositori sumber patch alternatif
<a name="patch-manager-alternative-source-repository-examples"></a>

**Contoh 1 - Pembaruan Nonsecurity untuk Ubuntu Server**  
Anda sudah menggunakan Patch Manager untuk menginstal patch keamanan pada armada node Ubuntu Server terkelola menggunakan baseline patch yang telah ditentukan AWS-provided. `AWS-UbuntuDefaultPatchBaseline` Anda dapat membuat dasar patch yang didasarkan pada default ini, tapi dalam aturan persetujuan Anda menentukan bahwa Anda ingin turut menginstal pembaruan non-keamanan yang merupakan bagian dari distribusi default. Ketika baseline patch ini dijalankan terhadap node Anda, patch untuk masalah keamanan dan nonsecurity diterapkan. Anda juga dapat memilih untuk menyetujui patch non-keamanan di pengecualian patch yang Anda tentukan untuk dasar.

**Contoh 2 - Personal Package Archives (PPA) untuk Ubuntu Server**  
Node Ubuntu Server terkelola Anda menjalankan perangkat lunak yang didistribusikan melalui [Personal Package Archives (PPA) untuk Ubuntu](https://launchpad.net/ubuntu/+ppas). Dalam hal ini, Anda membuat baseline patch yang menentukan repositori PPA yang telah Anda konfigurasikan pada node terkelola sebagai repositori sumber untuk operasi patching. Kemudian gunakan Run Command untuk menjalankan dokumen baseline patch pada node.

**Contoh 3 - Aplikasi Perusahaan Internal pada versi Amazon Linux yang didukung**  
Anda perlu menjalankan beberapa aplikasi yang diperlukan untuk kepatuhan peraturan industri pada node yang dikelola Amazon Linux Anda. Anda dapat mengkonfigurasi repositori untuk aplikasi ini pada node, menggunakan YUM untuk menginstal aplikasi pada awalnya, dan kemudian memperbarui atau membuat baseline patch baru untuk memasukkan repositori perusahaan baru ini. Setelah ini Anda dapat menggunakan Run Command untuk menjalankan `AWS-RunPatchBaseline` dokumen dengan `Scan` opsi untuk melihat apakah paket perusahaan terdaftar di antara paket yang diinstal dan up to date pada node yang dikelola. Jika belum diperbarui, Anda dapat menjalankan dokumen lagi menggunakan opsi `Install` untuk memperbarui aplikasi. 

# Cara menginstal patch
<a name="patch-manager-installing-patches"></a>

Patch Manager, alat di AWS Systems Manager, menggunakan manajer paket bawaan sistem operasi untuk menginstal pembaruan pada node yang dikelola. Misalnya, ia menggunakan Windows Update API di Windows Server dan `DNF` di Amazon Linux 2023. Patch Manager menghormati manajer paket dan konfigurasi repositori yang ada pada node, termasuk pengaturan seperti status repositori, cermin URLs, verifikasi GPG, dan opsi seperti. `skip_if_unavailable`

Patch Managertidak menginstal paket baru yang menggantikan paket usang yang saat ini diinstal. (Pengecualian: Paket baru adalah ketergantungan dari pembaruan paket lain yang sedang diinstal, atau paket baru memiliki nama yang sama dengan paket usang.) Sebagai gantinya, Patch Manager laporkan dan instal pembaruan yang tersedia untuk paket yang diinstal. Pendekatan ini membantu mencegah perubahan tak terduga pada fungsionalitas sistem Anda yang mungkin terjadi ketika satu paket menggantikan yang lain.

Jika Anda perlu menghapus paket yang telah dibuat usang dan menginstal penggantinya, Anda mungkin perlu menggunakan skrip khusus atau menggunakan perintah manajer paket di luar operasi standarPatch Manager.

Pilih dari tab berikut untuk mempelajari cara Patch Manager menginstal tambalan pada sistem operasi.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Di node terkelola Amazon Linux 2 dan Amazon Linux 2023, alur kerja penginstalan tambalan adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Jika beberapa versi patch disetujui, versi yang terbaru diterapkan.

1. API pembaruan YUM (Amazon Linux 2) atau API pembaruan DNF (Amazon Linux 2023) diterapkan ke tambalan yang disetujui sebagai berikut:
   + Untuk garis dasar patch default yang telah ditentukan yang disediakan oleh AWS, hanya tambalan yang ditentukan dalam yang `updateinfo.xml` diterapkan (hanya pembaruan keamanan). Ini karena kotak centang **Sertakan pembaruan nonkeamanan** tidak dipilih. Garis dasar yang telah ditentukan setara dengan baseline kustom dengan yang berikut:
     + Kotak centang **Sertakan pembaruan nonkeamanan** tidak dipilih
     + Daftar KEPARAHAN `[Critical, Important]`
     + Daftar KLASIFIKASI `[Security, Bugfix]`

     Untuk Amazon Linux 2, perintah yum yang setara untuk alur kerja ini adalah:

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Untuk Amazon Linux 2023, perintah dnf yang setara untuk alur kerja ini adalah:

     ```
     sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```

     Jika kotak centang **Sertakan pembaruan nonkeamanan** dipilih, semua tambalan `updateinfo.xml` dan yang tidak masuk `updateinfo.xml` akan diterapkan (pembaruan keamanan dan nonkeamanan).

     Untuk Amazon Linux 2, jika baseline dengan **Sertakan pembaruan nonsecurity** dipilih, memiliki daftar KEPARAHAN `[Critical, Important]` dan daftar KLASIFIKASI`[Security, Bugfix]`, perintah yum yang setara adalah:

     ```
     sudo yum update --security --sec-severity=Critical,Important --bugfix -y
     ```

     Untuk Amazon Linux 2023, perintah dnf yang setara adalah:

     ```
     sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```
**catatan**  
Paket baru yang menggantikan paket yang sekarang usang dengan nama yang berbeda diinstal jika Anda menjalankan ini `yum` atau `dnf` perintah di luar. Patch Manager Namun, mereka *tidak* diinstal oleh Patch Manager operasi yang setara.

**Detail tambalan tambahan untuk Amazon Linux 2023**  
Support untuk tingkat keparahan 'Tidak Ada'  
Amazon Linux 2023 juga mendukung tingkat keparahan patch`None`, yang diakui oleh manajer paket DNF.   
Support untuk tingkat keparahan 'Medium'  
Untuk Amazon Linux 2023, tingkat keparahan patch `Medium` setara dengan tingkat keparahan `Moderate` yang mungkin ditentukan di beberapa repositori eksternal. Jika Anda menyertakan patch `Medium` keparahan di baseline patch, patch `Moderate` keparahan dari patch eksternal juga diinstal pada instance.  
Saat Anda menanyakan data kepatuhan menggunakan tindakan API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html), pemfilteran untuk tingkat keparahan akan `Medium` melaporkan tambalan dengan tingkat keparahan keduanya `Medium` dan. `Moderate`  
Penanganan ketergantungan transitif untuk Amazon Linux 2023  
Untuk Amazon Linux 2023, Patch Manager mungkin menginstal versi dependensi transitif yang berbeda dari perintah yang setara yang diinstal. `dnf` Dependensi transitif adalah paket yang diinstal secara otomatis untuk memenuhi persyaratan paket lain (dependensi dependensi).   
Misalnya, `dnf upgrade-minimal --security` menginstal versi *minimal* dependensi transitif yang diperlukan untuk menyelesaikan masalah keamanan yang diketahui, sementara Patch Manager menginstal versi ** terbaru yang tersedia dari dependensi transitif yang sama.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**catatan**  
Konfigurasi default untuk manajer paket pada distribusi Linux mungkin diatur untuk melewati repositori paket yang tidak dapat dijangkau tanpa kesalahan. Dalam kasus seperti itu, operasi penambalan terkait berlangsung tanpa menginstal pembaruan dari repositori dan diakhiri dengan sukses. Untuk menerapkan pembaruan repositori, tambahkan `skip_if_unavailable=False` ke konfigurasi repositori.  
Untuk informasi selengkapnya tentang `skip_if_available` opsi, lihat[Konektivitas ke sumber patch](patch-manager-prerequisites.md#source-connectivity).

------
#### [ CentOS Aliran ]

Pada node CentOS Stream terkelola, alur kerja instalasi patch adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

   Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Jika beberapa versi patch disetujui, versi yang terbaru diterapkan.

1. Pembaruan DNF pada CentOS Stream diterapkan ke tambalan yang disetujui.
**catatan**  
UntukCentOS Stream, Patch Manager mungkin menginstal versi dependensi transitif yang berbeda dari perintah yang setara `dnf` yang diinstal. Dependensi transitif adalah paket yang diinstal secara otomatis untuk memenuhi persyaratan paket lain (dependensi dependensi).   
Misalnya, `dnf upgrade-minimal ‐‐security` menginstal versi *minimal* dependensi transitif yang diperlukan untuk menyelesaikan masalah keamanan yang diketahui, sementara Patch Manager menginstal *versi terbaru yang tersedia* dari dependensi transitif yang sama.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Debian Server ]

Pada instans Debian Server, alur kerja instalasi patch adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

1. Jika pembaruan tersedia untuk `python3-apt` (antarmuka pustaka Python ke`libapt`), itu ditingkatkan ke versi terbaru. (Paket nonsecurity ini ditingkatkan meskipun Anda tidak memilih opsi **Sertakan pembaruan nonsecurity**.)

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui. 
**catatan**  
Karena tidak mungkin menentukan tanggal rilis paket pembaruan secara andalDebian Server, opsi persetujuan otomatis tidak didukung untuk sistem operasi ini.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.
**catatan**  
UntukDebian Server, versi kandidat tambalan terbatas pada tambalan yang disertakan di `debian-security` dalamnya.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Pustaka APT digunakan untuk memutakhirkan paket.
**catatan**  
Patch Managertidak mendukung penggunaan `Pin-Priority` opsi APT untuk menetapkan prioritas ke paket. Patch Managermenggabungkan pembaruan yang tersedia dari semua repositori yang diaktifkan dan memilih pembaruan terbaru yang cocok dengan baseline untuk setiap paket yang diinstal.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ macOS ]

Pada node macOS terkelola, alur kerja instalasi patch adalah sebagai berikut:

1. Daftar properti `/Library/Receipts/InstallHistory.plist` adalah catatan perangkat lunak yang telah diinstal dan dimutakhirkan menggunakan pengelola paket `softwareupdate` dan `installer`. Menggunakan alat baris perintah `pkgutil` (untuk `installer`) dan pengelola paket `softwareupdate`, perintah CLI dijalankan untuk mengurai daftar ini. 

   Untuk`installer`, respons terhadap perintah CLI mencakup`package name`,,`version`, `volume``location`, dan `install-time` detail, tetapi hanya `package name` dan `version` digunakan oleh. Patch Manager

   Untuk `softwareupdate`, respon terhadap perintah CLI meliputi nama paket (`display name`), `version`, dan `date`, tetapi hanya nama paket dan versi yang digunakan oleh Patch Manager.

   Untuk Brew dan Brew Cask, Homebrew tidak mendukung perintahnya berjalan dalam kendali pengguna root. Akibatnya, Patch Manager kueri untuk dan menjalankan perintah Homebrew baik sebagai pemilik direktori Homebrew atau sebagai pengguna valid milik grup pemilik direktori Homebrew. Perintahnya mirip dengan `softwareupdate` dan `installer` dan dijalankan melalui sub-proses Python untuk mengumpulkan data paket, dan outputnya diurai untuk mengidentifikasi nama dan versi paket.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Jika beberapa versi patch disetujui, versi yang terbaru diterapkan.

1. Memanggil CLI paket yang sesuai pada node terkelola untuk memproses tambalan yang disetujui sebagai berikut:
**catatan**  
`installer` tidak memiliki fungsi untuk memeriksa dan menginstal pembaruan. Oleh karena itu`installer`, untuk, Patch Manager hanya melaporkan paket mana yang diinstal. Akibatnya, paket `installer` tidak pernah dilaporkan sebagai `Missing`.
   + Untuk baseline patch default yang telah ditentukan sebelumnya yang disediakan oleh AWS, dan untuk baseline patch kustom di mana kotak centang **Sertakan pembaruan non-keamanan** *tidak* dipilih, hanya pembaruan keamanan yang diterapkan.
   + Untuk garis dasar tambalan khusus di mana kotak centang **Sertakan pembaruan non-keamanan** *dipilih*, pembaruan keamanan dan nonkeamanan diterapkan.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Oracle Linux ]

Pada node Oracle Linux terkelola, alur kerja instalasi patch adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Jika beberapa versi patch disetujui, versi yang terbaru diterapkan.

1. Pada node terkelola versi 7, API pembaruan YUM diterapkan ke tambalan yang disetujui sebagai berikut:
   + Untuk baseline patch default yang telah ditentukan yang disediakan oleh AWS, dan untuk baseline patch kustom di mana kotak centang **Sertakan pembaruan non-keamanan** *tidak* dipilih, hanya tambalan yang ditentukan dalam `updateinfo.xml` yang diterapkan (hanya pembaruan keamanan).

     Perintah setara yum untuk alur kerja ini adalah:

     ```
     sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
     ```
   + Untuk baseline patch kustom di mana kotak centang **Sertakan pembaruan non-keamanan** *dipilih*, tambalan yang masuk `updateinfo.xml` dan yang tidak `updateinfo.xml` ada diterapkan (pembaruan keamanan dan nonkeamanan).

     Perintah setara yum untuk alur kerja ini adalah:

     ```
     sudo yum update --security --bugfix -y
     ```

     Pada node terkelola versi 8 dan 9, API pembaruan DNF diterapkan ke tambalan yang disetujui sebagai berikut:
     + Untuk baseline patch default yang telah ditentukan yang disediakan oleh AWS, dan untuk baseline patch kustom di mana kotak centang **Sertakan pembaruan non-keamanan** *tidak* dipilih, hanya tambalan yang ditentukan dalam `updateinfo.xml` yang diterapkan (hanya pembaruan keamanan).

       Perintah setara yum untuk alur kerja ini adalah:

       ```
       sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
       ```
**catatan**  
Untuk Oracle Linux, Patch Manager mungkin menginstal versi dependensi transitif yang berbeda dari perintah yang setara menginstal. `dnf` Dependensi transitif adalah paket yang diinstal secara otomatis untuk memenuhi persyaratan paket lain (dependensi dependensi).   
Misalnya, `dnf upgrade-minimal --security` menginstal versi *minimal* dependensi transitif yang diperlukan untuk menyelesaikan masalah keamanan yang diketahui, sementara Patch Manager menginstal *versi terbaru yang tersedia* dari dependensi transitif yang sama.
     + Untuk baseline patch kustom di mana kotak centang **Sertakan pembaruan non-keamanan** *dipilih*, tambalan yang masuk `updateinfo.xml` dan yang tidak `updateinfo.xml` ada diterapkan (pembaruan keamanan dan nonkeamanan).

       Perintah setara yum untuk alur kerja ini adalah:

       ```
       sudo dnf upgrade --security --bugfix
       ```
**catatan**  
Paket baru yang menggantikan paket yang sekarang usang dengan nama yang berbeda diinstal jika Anda menjalankan ini `yum` atau `dnf` perintah di luar. Patch Manager Namun, mereka *tidak* diinstal oleh Patch Manager operasi yang setara.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**catatan**  
Konfigurasi default untuk manajer paket pada distribusi Linux mungkin diatur untuk melewati repositori paket yang tidak dapat dijangkau tanpa kesalahan. Dalam kasus seperti itu, operasi penambalan terkait berlangsung tanpa menginstal pembaruan dari repositori dan diakhiri dengan sukses. Untuk menerapkan pembaruan repositori, tambahkan `skip_if_unavailable=False` ke konfigurasi repositori.  
Untuk informasi selengkapnya tentang `skip_if_available` opsi, lihat[Konektivitas ke sumber patch](patch-manager-prerequisites.md#source-connectivity).

------
#### [ AlmaLinux, RHEL, and Linux Rocky  ]

Pada AlmaLinux,Red Hat Enterprise Linux, dan node Rocky Linux terkelola, alur kerja instalasi patch adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Jika beberapa versi patch disetujui, versi yang terbaru diterapkan.

1. API pembaruan YUM (pada RHEL 7) atau API pembaruan DNF (pada AlmaLinux 8 dan 9, RHEL 8, 9, dan 10, dan Rocky Linux 8 dan 9) diterapkan pada tambalan yang disetujui sesuai dengan aturan berikut:

    

**Skenario 1: Pembaruan non-keamanan dikecualikan**
   + **Berlaku untuk**: Garis dasar patch default yang telah ditentukan yang disediakan oleh AWS dan baseline patch kustom.
   + **Sertakan kotak centang pembaruan non-keamanan**: *Tidak* dipilih.
   + **Patch diterapkan**: Patch yang ditentukan dalam `updateinfo.xml` (hanya pembaruan keamanan) diterapkan *hanya* jika keduanya cocok dengan konfigurasi baseline patch dan ditemukan di repo yang dikonfigurasi.

     Dalam beberapa kasus, tambalan yang ditentukan `updateinfo.xml` mungkin tidak lagi tersedia di repo yang dikonfigurasi. Repo yang dikonfigurasi biasanya hanya memiliki versi terbaru dari tambalan, yang merupakan roll-up kumulatif dari semua pembaruan sebelumnya, tetapi versi terbaru mungkin tidak cocok dengan aturan dasar tambalan dan dihilangkan dari operasi penambalan.
   + **Perintah**: Untuk RHEL 7, perintah yum yang setara untuk alur kerja ini adalah: 

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     Untuk AlmaLinux, RHEL 8, danRocky Linux, perintah dnf yang setara untuk alur kerja ini adalah:

     ```
     sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
     sudo dnf update-minimal --sec-severity=Important --bugfix -y
     ```
**catatan**  
Untuk AlmaLinux,RHEL, dan Rocky Linux Rocky Linux, Patch Manager mungkin menginstal versi dependensi transitif yang berbeda dari perintah yang setara yang diinstal. `dnf` Dependensi transitif adalah paket yang diinstal secara otomatis untuk memenuhi persyaratan paket lain (dependensi dependensi).   
Misalnya, `dnf upgrade-minimal --security` menginstal versi *minimal* dependensi transitif yang diperlukan untuk menyelesaikan masalah keamanan yang diketahui, sementara Patch Manager menginstal *versi terbaru yang tersedia* dari dependensi transitif yang sama.

**Skenario 2: Pembaruan non-keamanan disertakan**
   + **Apel ke**: Garis dasar tambalan khusus.
   + **Sertakan kotak centang pembaruan non-keamanan**: Dipilih.
   + **Patch diterapkan**: Patch in `updateinfo.xml` *dan* yang tidak masuk `updateinfo.xml` diterapkan (pembaruan keamanan dan nonsecurity).
   + **Perintah**: Untuk RHEL 7, perintah yum yang setara untuk alur kerja ini adalah:

     ```
     sudo yum update --security --bugfix -y
     ```

     Untuk AlmaLinux 8 dan 9, RHEL 8 dan 9, dan Rocky Linux 8 dan 9, perintah dnf setara untuk alur kerja ini adalah:

     ```
     sudo dnf update --security --bugfix -y
     ```
**catatan**  
Paket baru yang menggantikan paket yang sekarang usang dengan nama yang berbeda diinstal jika Anda menjalankan ini `yum` atau `dnf` perintah di luar. Patch Manager Namun, mereka *tidak* diinstal oleh Patch Manager operasi yang setara.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

**catatan**  
Konfigurasi default untuk manajer paket pada distribusi Linux mungkin diatur untuk melewati repositori paket yang tidak dapat dijangkau tanpa kesalahan. Dalam kasus seperti itu, operasi penambalan terkait berlangsung tanpa menginstal pembaruan dari repositori dan diakhiri dengan sukses. Untuk menerapkan pembaruan repositori, tambahkan `skip_if_unavailable=False` ke konfigurasi repositori.  
Untuk informasi selengkapnya tentang `skip_if_available` opsi, lihat[Konektivitas ke sumber patch](patch-manager-prerequisites.md#source-connectivity).

------
#### [ SLES ]

Pada node terkelola SUSE Linux Enterprise Server (SLES), alur kerja instalasi patch adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Jika beberapa versi patch disetujui, versi yang terbaru diterapkan.

1. API pembaruan Zypper diterapkan untuk patch yang disetujui.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Ubuntu Server ]

Pada node Ubuntu Server terkelola, alur kerja instalasi patch adalah sebagai berikut:

1. Jika daftar patch ditentukan menggunakan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) menggunakan parameter `InstallOverrideList` untuk dokumen `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`, patch yang terdaftar diinstal dan langkah 2-7 dilewati.

1. Jika pembaruan tersedia untuk `python3-apt` (antarmuka pustaka Python ke`libapt`), itu ditingkatkan ke versi terbaru. (Paket nonsecurity ini ditingkatkan meskipun Anda tidak memilih opsi **Sertakan pembaruan nonsecurity**.)

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)seperti yang ditentukan dalam baseline patch, hanya menyimpan paket yang memenuhi syarat untuk diproses lebih lanjut. 

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)seperti yang ditentukan dalam baseline patch. Setiap aturan persetujuan dapat menentukan paket sebagai disetujui. 
**catatan**  
Karena tidak mungkin menentukan tanggal rilis paket pembaruan secara andalUbuntu Server, opsi persetujuan otomatis tidak didukung untuk sistem operasi ini.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. 

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

   Namun, aturan persetujuan juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.
**catatan**  
Untuk setiap versiUbuntu Server, versi kandidat tambalan terbatas pada tambalan yang merupakan bagian dari repo terkait untuk versi tersebut, sebagai berikut:  
Ubuntu Server16.04 LTS: `xenial-security`
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`

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)seperti yang ditentukan dalam baseline patch. Tambalan yang disetujui disetujui untuk diperbarui meskipun dibuang oleh [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)atau jika tidak ada aturan persetujuan yang ditentukan dalam [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)memberikan persetujuan.

1. Terapkan [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)seperti yang ditentukan dalam baseline patch. Patch yang ditolak akan dihapus dari daftar patch yang disetujui dan tidak akan diterapkan.

1. Pustaka APT digunakan untuk memutakhirkan paket.
**catatan**  
Patch Managertidak mendukung penggunaan `Pin-Priority` opsi APT untuk menetapkan prioritas ke paket. Patch Managermenggabungkan pembaruan yang tersedia dari semua repositori yang diaktifkan dan memilih pembaruan terbaru yang cocok dengan baseline untuk setiap paket yang diinstal.

1. Node terkelola di-boot ulang jika ada pembaruan yang diinstal. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)

------
#### [ Windows Server ]

Ketika operasi patching dilakukan pada node Windows Server terkelola, node meminta snapshot dari baseline patch yang sesuai dari Systems Manager. snapshot ini berisi daftar semua pembaruan yang tersedia di dasar patch yang disetujui untuk deployment. Daftar pembaruan ini dikirim ke Windows Update API, yang menentukan pembaruan mana yang berlaku untuk node terkelola dan menginstalnya sesuai kebutuhan. Windows hanya mengizinkan versi KB terbaru yang tersedia untuk diinstal. Patch Managermenginstal versi terbaru KB saat KB, atau versi KB sebelumnya, cocok dengan baseline patch yang diterapkan. Jika ada pembaruan yang diinstal, node terkelola akan di-boot ulang setelahnya, sebanyak yang diperlukan untuk menyelesaikan semua tambalan yang diperlukan. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).) Ringkasan operasi penambalan dapat ditemukan di output Run Command permintaan. Log tambahan dapat ditemukan pada node terkelola di `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` folder.

Karena API Pembaruan Windows digunakan untuk mengunduh dan menginstal KBs, semua pengaturan Kebijakan Grup untuk Pembaruan Windows dihormati. Tidak ada pengaturan Kebijakan Grup yang diperlukan untuk digunakanPatch Manager, tetapi pengaturan apa pun yang telah Anda tetapkan akan diterapkan, seperti mengarahkan node terkelola ke server Windows Server Update Services (WSUS).

**catatan**  
Secara default, Windows mengunduh semua KBs dari situs Pembaruan Windows Microsoft karena Patch Manager menggunakan API Pembaruan Windows untuk mendorong unduhan dan penginstalan KBs. Akibatnya, node yang dikelola harus dapat mencapai situs Pembaruan Microsoft Windows atau tambalan akan gagal. Atau, Anda dapat mengonfigurasi server WSUS untuk berfungsi sebagai repositori KB dan mengonfigurasi node terkelola Anda untuk menargetkan server WSUS menggunakan Kebijakan Grup.  
Patch Managermungkin mereferensikan KB IDs saat membuat baseline tambalan khusus untukWindows Server, seperti ketika daftar **tambalan yang Disetujui** atau daftar **tambalan Ditolak** disertakan konfigurasi dasar. Hanya pembaruan yang diberi ID KB di Pembaruan Microsoft Windows atau server WSUS yang diinstal olehPatch Manager. Pembaruan yang tidak memiliki ID KB tidak termasuk dalam operasi penambalan.   
Untuk informasi tentang membuat baseline patch kustom, lihat topik berikut:  
 [Membuat baseline patch khusus untuk Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 [Buat baseline patch (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Format nama paket untuk sistem operasi Windows](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Cara kerja aturan dasar patch pada sistem berbasis Linux
<a name="patch-manager-linux-rules"></a>

Aturan dalam dasar patch untuk distribusi Linux beroperasi dengan cara yang berbeda berdasarkan jenis distribusi. Tidak seperti pembaruan tambalan pada node Windows Server terkelola, aturan dievaluasi pada setiap node untuk mempertimbangkan repo yang dikonfigurasi pada instance. Patch Manager, alat di AWS Systems Manager, menggunakan manajer paket asli untuk mendorong instalasi tambalan yang disetujui oleh baseline patch.

Untuk jenis sistem operasi berbasis Linux yang melaporkan tingkat keparahan 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 [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS), atau dari metrik yang dirilis oleh [National](https://nvd.nist.gov/vuln) Vulnerability Database (NVD).

**Topics**
+ [Cara kerja aturan dasar patch di Amazon Linux 2 dan Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Cara kerja aturan dasar patch pada CentOS Stream](#linux-rules-centos)
+ [Cara kerja aturan dasar patch pada Debian Server](#linux-rules-debian)
+ [Cara kerja aturan dasar patch pada macOS](#linux-rules-macos)
+ [Cara kerja aturan dasar patch pada Oracle Linux](#linux-rules-oracle)
+ [Cara kerja aturan dasar tambalan AlmaLinux,, dan RHEL Rocky Linux](#linux-rules-rhel)
+ [Cara kerja aturan dasar patch pada SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Cara kerja aturan dasar patch pada Ubuntu Server](#linux-rules-ubuntu)

## Cara kerja aturan dasar patch di Amazon Linux 2 dan Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**catatan**  
Amazon Linux 2023 (AL2023) menggunakan repositori berversi yang dapat dikunci ke versi tertentu melalui satu atau beberapa pengaturan sistem. Untuk semua operasi penambalan pada instans AL2023 EC2Patch Manager, gunakan versi repositori terbaru, terlepas dari konfigurasi sistem. Untuk informasi selengkapnya, lihat [Peningkatan deterministik melalui repositori berversi](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) di Panduan Pengguna *Amazon* Linux 2023.

Di Amazon Linux 2 dan Amazon Linux 2023, proses pemilihan tambalan adalah sebagai berikut:

1. Pada node terkelola, perpustakaan YUM (Amazon Linux 2) atau pustaka DNF (Amazon Linux 2023) mengakses `updateinfo.xml` file untuk setiap repo yang dikonfigurasi. 

   **Jika tidak ada `updateinfo.xml` file yang ditemukan, apakah patch diinstal tergantung pada pengaturan untuk **Sertakan pembaruan non-keamanan** dan Persetujuan otomatis.** Sebagai contoh, jika pembaruan non-keamanan diizinkan, pembaruan akan diinstal saat waktu persetujuan otomatis tiba.

1. Setiap pemberitahuan pembaruan di `updateinfo.xml` mencakup beberapa atribut yang menunjukkan properti paket dalam pemberitahuan tersebut, seperti yang dijelaskan di tabel berikut.  
**Atribut pemberitahuan pembaruan**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

1. Produk dari node terkelola ditentukan olehSSM Agent. Atribut ini sesuai dengan nilai atribut kunci Produk dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch.

1. Paket dipilih untuk pembaruan sesuai dengan pedoman berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

## Cara kerja aturan dasar patch pada CentOS Stream
<a name="linux-rules-centos"></a>

Repositori CentOS Stream default tidak menyertakan file`updateinfo.xml`. Namun, repositori khusus yang Anda buat atau gunakan mungkin menyertakan file ini. Dalam topik ini, referensi hanya `updateinfo.xml` berlaku untuk repositori kustom ini.

Pada CentOS Stream, proses pemilihan patch adalah sebagai berikut:

1. Pada node terkelola, pustaka DNF mengakses `updateinfo.xml` file, jika ada di repositori khusus, untuk setiap repo yang dikonfigurasi.

   **Jika tidak `updateinfo.xml` ditemukan, yang selalu menyertakan repo default, apakah tambalan diinstal tergantung pada pengaturan untuk **Sertakan pembaruan non-keamanan** dan Persetujuan otomatis.** Sebagai contoh, jika pembaruan non-keamanan diizinkan, pembaruan akan diinstal saat waktu persetujuan otomatis tiba.

1. Jika `updateinfo.xml` ada, setiap pemberitahuan pembaruan dalam file menyertakan beberapa atribut yang menunjukkan properti paket dalam pemberitahuan, seperti yang dijelaskan dalam tabel berikut.  
**Atribut pemberitahuan pembaruan**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

1. Dalam semua kasus, produk dari node yang dikelola ditentukan olehSSM Agent. Atribut ini sesuai dengan nilai atribut kunci Produk dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch.

1. Paket dipilih untuk pembaruan sesuai dengan pedoman berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

## Cara kerja aturan dasar patch pada Debian Server
<a name="linux-rules-debian"></a>

*PadaDebian Server, layanan baseline patch menawarkan pemfilteran pada bidang *Prioritas dan Bagian*.* Bidang ini biasanya hadir untuk semua Debian Server paket. Untuk menentukan apakah patch dipilih oleh baseline patch, Patch Manager lakukan hal berikut:

1. Pada Debian Server sistem, setara `sudo apt-get update` dijalankan untuk menyegarkan daftar paket yang tersedia. Repo tidak dikonfigurasi dan data ditarik dari repo yang dikonfigurasi dalam daftar `sources`.

1. Jika pembaruan tersedia untuk `python3-apt` (antarmuka pustaka Python ke`libapt`), itu ditingkatkan ke versi terbaru. (Paket nonsecurity ini ditingkatkan meskipun Anda tidak memilih opsi **Sertakan pembaruan nonsecurity**.)

1. Selanjutnya [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)daftar [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)dan diterapkan.
**catatan**  
Karena tidak mungkin menentukan tanggal rilis paket pembaruan secara andalDebian Server, opsi persetujuan otomatis tidak didukung untuk sistem operasi ini.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. Dalam hal ini, untukDebian Server, versi kandidat tambalan terbatas pada tambalan yang disertakan dalam repo berikut:

   Repo ini dinamakan sebagai berikut:
   + Debian Server11: `debian-security bullseye`
   + Debian Server12: `debian-security bookworm`

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

   Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

Untuk melihat konten bidang *Prioritas* dan *Bagian*, jalankan perintah `aptitude` berikut ini: 

**catatan**  
Anda mungkin perlu menginstal Aptitude terlebih dahulu pada Debian Server sistem.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Dalam menanggapi perintah ini, semua paket yang dapat dimutakhirkan dilaporkan dalam format ini: 

```
name, priority, section, archive, candidate version
```

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

## Cara kerja aturan dasar patch pada macOS
<a name="linux-rules-macos"></a>

Pada macOS, proses pemilihan patch adalah sebagai berikut:

1. Pada node terkelola, Patch Manager mengakses konten `InstallHistory.plist` file yang diurai dan mengidentifikasi nama dan versi paket. 

   Untuk detail tentang proses penguraian, lihat tab **macOS** dalam [Cara menginstal patch](patch-manager-installing-patches.md).

1. Produk dari node terkelola ditentukan olehSSM Agent. Atribut ini sesuai dengan nilai atribut kunci Produk dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch.

1. Paket dipilih untuk pembaruan sesuai dengan pedoman berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

## Cara kerja aturan dasar patch pada Oracle Linux
<a name="linux-rules-oracle"></a>

Pada Oracle Linux, proses pemilihan patch adalah sebagai berikut:

1. Pada node terkelola, pustaka YUM mengakses `updateinfo.xml` file untuk setiap repo yang dikonfigurasi.
**catatan**  
file `updateinfo.xml` mungkin tidak tersedia jika repo tidak dikelola oleh Oracle. **Jika tidak `updateinfo.xml` ditemukan, apakah patch diinstal tergantung pada pengaturan untuk **Sertakan pembaruan non-keamanan** dan Persetujuan otomatis.** Sebagai contoh, jika pembaruan non-keamanan diizinkan, pembaruan akan diinstal saat waktu persetujuan otomatis tiba.

1. Setiap pemberitahuan pembaruan di `updateinfo.xml` mencakup beberapa atribut yang menunjukkan properti paket dalam pemberitahuan tersebut, seperti yang dijelaskan di tabel berikut.  
**Atribut pemberitahuan pembaruan**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

1. Produk dari node terkelola ditentukan olehSSM Agent. Atribut ini sesuai dengan nilai atribut kunci Produk dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch.

1. Paket dipilih untuk pembaruan sesuai dengan pedoman berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

## Cara kerja aturan dasar tambalan AlmaLinux,, dan RHEL Rocky Linux
<a name="linux-rules-rhel"></a>

Pada AlmaLinux, Red Hat Enterprise Linux (RHEL), danRocky Linux, proses pemilihan tambalan adalah sebagai berikut:

1. Pada node terkelola, perpustakaan YUM (RHEL7) atau pustaka DNF (AlmaLinux 8 dan 9, RHEL 8, 9, dan 10, dan Rocky Linux 8 dan 9) mengakses `updateinfo.xml` file untuk setiap repo yang dikonfigurasi.
**catatan**  
file `updateinfo.xml` mungkin tidak tersedia jika repo tidak dikelola oleh Red Hat. Jika tidak ada `updateinfo.xml` yang ditemukan, tidak ada patch yang diterapkan.

1. Setiap pemberitahuan pembaruan di `updateinfo.xml` mencakup beberapa atribut yang menunjukkan properti paket dalam pemberitahuan tersebut, seperti yang dijelaskan di tabel berikut.  
**Atribut pemberitahuan pembaruan**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

1. Produk dari node terkelola ditentukan olehSSM Agent. Atribut ini sesuai dengan nilai atribut kunci Produk dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch.

1. Paket dipilih untuk pembaruan sesuai dengan pedoman berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

## Cara kerja aturan dasar patch pada SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

Pada SLES, setiap patch mencakup atribut berikut ini yang menunjukkan properti paket dalam patch tersebut:
+ **Kategori**: Sesuai dengan nilai atribut kunci **Klasifikasi** dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch. Menunjukkan jenis patch yang disertakan dalam pemberitahuan pembaruan.

  Anda dapat melihat daftar nilai yang didukung dengan menggunakan AWS CLI perintah **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** atau operasi API**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Anda juga dapat melihat daftar di area **Aturan persetujuan** pada halaman **Buat dasar patch** atau halaman **Edit dasar patch** di konsol Systems Manager.
+ **Keparahan**: Sesuai dengan nilai atribut kunci **Keparahan** dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch. Menunjukkan tingkat kepelikan patch.

  Anda dapat melihat daftar nilai yang didukung dengan menggunakan AWS CLI perintah **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** atau operasi API**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Anda juga dapat melihat daftar di area **Aturan persetujuan** pada halaman **Buat dasar patch** atau halaman **Edit dasar patch** di konsol Systems Manager.

Produk dari node terkelola ditentukan olehSSM Agent. Atribut ini sesuai dengan nilai atribut kunci **Produk** dalam tipe [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)data baseline patch. 

Untuk setiap patch, dasar patch digunakan sebagai filter, memungkinkan hanya paket yang memenuhi syarat untuk disertakan dalam pembaruan. Jika beberapa paket berlaku setelah menerapkan definisi dasar patch, versi terbaru digunakan. 

Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

## Cara kerja aturan dasar patch pada Ubuntu Server
<a name="linux-rules-ubuntu"></a>

*PadaUbuntu Server, layanan baseline patch menawarkan pemfilteran pada bidang *Prioritas dan Bagian*.* Bidang ini biasanya hadir untuk semua Ubuntu Server paket. Untuk menentukan apakah patch dipilih oleh baseline patch, Patch Manager lakukan hal berikut:

1. Pada Ubuntu Server sistem, setara `sudo apt-get update` dijalankan untuk menyegarkan daftar paket yang tersedia. Repo tidak dikonfigurasi dan data ditarik dari repo yang dikonfigurasi dalam daftar `sources`.

1. Jika pembaruan tersedia untuk `python3-apt` (antarmuka pustaka Python ke`libapt`), itu ditingkatkan ke versi terbaru. (Paket nonsecurity ini ditingkatkan meskipun Anda tidak memilih opsi **Sertakan pembaruan nonsecurity**.)

1. Selanjutnya [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)daftar [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)dan diterapkan.
**catatan**  
Karena tidak mungkin menentukan tanggal rilis paket pembaruan secara andalUbuntu Server, opsi persetujuan otomatis tidak didukung untuk sistem operasi ini.

   Namun, aturan persetujuan, juga tunduk pada apakah kontak centang **Sertakan pembaruan non-keamanan** dipilih saat membuat atau terakhir memperbarui dasar patch.

   Jika pembaruan non-keamanan dikecualikan, diterapkan suatu aturan implisit untuk memilih hanya paket dengan pemutakhiran dalam repo keamanan. Untuk setiap paket, versi kandidat paket (yang biasanya versi terbaru) harus merupakan bagian dari repo keamanan. Dalam hal ini, untukUbuntu Server, versi kandidat tambalan terbatas pada tambalan yang disertakan dalam repo berikut:
   + Ubuntu Server16.04 LTS: `xenial-security`
   + 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`

   Jika pembaruan non-keamanan disertakan, patch dari repositori lain juga dipertimbangkan.

   Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

Untuk melihat konten bidang *Prioritas* dan *Bagian*, jalankan perintah `aptitude` berikut ini: 

**catatan**  
Anda mungkin perlu menginstal Aptitude terlebih dahulu pada Ubuntu Server 16 sistem.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Dalam menanggapi perintah ini, semua paket yang dapat dimutakhirkan dilaporkan dalam format ini: 

```
name, priority, section, archive, candidate version
```

Untuk informasi tentang nilai status kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

# Menambal perbedaan operasi antara Linux dan Windows Server
<a name="patch-manager-windows-and-linux-differences"></a>

Topik ini menjelaskan perbedaan penting antara Linux dan Windows Server patching inPatch Manager, alat di AWS Systems Manager.

**catatan**  
Untuk menambal node yang dikelola Linux, node Anda harus menjalankan SSM Agent versi 2.0.834.0 atau yang lebih baru.  
Versi terbaru dirilis setiap kali alat baru ditambahkan ke Systems Manager atau pembaruan dibuat ke alat yang ada. SSM Agent Gagal menggunakan agen versi terbaru dapat mencegah node terkelola Anda menggunakan berbagai alat dan fitur Systems Manager. Untuk alasan itu, kami menyarankan Anda mengotomatiskan proses menjaga agar tetap SSM Agent up to date pada mesin Anda. Untuk informasi, lihat [Mengotomatiskan pembaruan ke SSM Agent](ssm-agent-automatic-updates.md). Berlangganan halaman [Catatan SSM Agent Rilis](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) GitHub untuk mendapatkan pemberitahuan tentang SSM Agent pembaruan.

## Perbedaan 1: Evaluasi patch
<a name="patch-evaluation_diff"></a>

Patch Managermenggunakan proses yang berbeda pada node yang dikelola Windows dan node yang dikelola Linux untuk mengevaluasi tambalan mana yang harus ada. 

**Linux**  
*Untuk patch Linux, Systems Manager mengevaluasi aturan dasar patch dan daftar patch disetujui dan ditolak pada setiap node terkelola.* Systems Manager harus mengevaluasi patching pada setiap node karena layanan mengambil daftar patch yang diketahui dan update dari repositori yang dikonfigurasi pada node terkelola.

**Windows**  
Untuk patching Windows, Systems Manager mengevaluasi aturan dasar patch dan daftar patch yang disetujui dan ditolak pada *secara langsung dalam layanan*. Hal ini dapat dilakukan karena patch Windows ditarik dari satu repositori (Windows Update).

## Perbedaan 2: patch `Not Applicable`
<a name="not-applicable-diff"></a>

Karena banyaknya paket yang tersedia untuk sistem operasi Linux, Systems Manager tidak melaporkan detail tentang patch yang berstatus *Tidak Berlaku*. Patch `Not Applicable` adalah, sebagai contoh, sebuah patch untuk perangkat lunak Apache ketika instans tidak memiliki Apache yang sudah diinstal. Systems Manager melaporkan jumlah `Not Applicable` tambalan dalam ringkasan, tetapi jika Anda memanggil [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)API untuk node terkelola, data yang dikembalikan tidak menyertakan tambalan dengan status. `Not Applicable` Perilaku ini berbeda dari Windows.

## Perbedaan 3: support dokumen SSM
<a name="document-support-diff"></a>

Dokumen `AWS-ApplyPatchBaseline` Systems Manager (dokumen SSM) tidak mendukung node yang dikelola Linux. Untuk menerapkan baseline patch ke Linux,macOS, dan node Windows Server terkelola, dokumen SSM yang disarankan adalah. `AWS-RunPatchBaseline` Untuk informasi selengkapnya, lihat [Dokumen SSM Command untuk menambal node terkelola](patch-manager-ssm-documents.md) dan [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Perbedaan 4: Patch aplikasi
<a name="application-patches-diff"></a>

Fokus utama Patch Manager adalah menerapkan patch ke sistem operasi. Namun, Anda juga dapat menggunakan Patch Manager untuk menerapkan tambalan ke beberapa aplikasi pada node terkelola Anda.

**Linux**  
Pada sistem operasi Linux, Patch Manager menggunakan repositori yang dikonfigurasi untuk pembaruan, dan tidak membedakan antara sistem operasi dan patch aplikasi. Anda dapat menggunakan Patch Manager untuk menentukan repositori mana untuk mengambil pembaruan dari. Untuk informasi selengkapnya, lihat [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
Pada node Windows Server terkelola, Anda dapat menerapkan aturan persetujuan, serta pengecualian patch yang *Disetujui* dan *Ditolak*, untuk aplikasi yang dirilis oleh Microsoft, seperti Microsoft Word 2016 dan Microsoft Exchange Server 2016. Untuk informasi selengkapnya, lihat [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md).

## Perbedaan 5: Opsi daftar tambalan yang ditolak di baseline patch kustom
<a name="rejected-patches-diff"></a>

Saat Anda membuat baseline patch kustom, Anda dapat menentukan satu atau beberapa tambalan untuk daftar tambalan **Ditolak**. Untuk node yang dikelola Linux, Anda juga dapat memilih untuk mengizinkannya diinstal jika mereka dependensi untuk patch lain yang diizinkan oleh baseline.

Windows Server, bagaimanapun, tidak mendukung konsep dependensi tambalan. Anda dapat menambahkan tambalan ke daftar **tambalan Ditolak** di baseline khusus untukWindows Server, tetapi hasilnya tergantung pada (1) apakah tambalan yang ditolak sudah diinstal pada node terkelola atau tidak, dan (2) opsi mana yang Anda pilih untuk tindakan tambalan **Ditolak**.

Lihat tabel berikut untuk detail tentang opsi tambalan yang ditolakWindows Server.


| Status instalasi | Opsi: “Izinkan sebagai ketergantungan” | Opsi: “Blokir” | 
| --- | --- | --- | 
| Patch sudah diinstal | Status yang dilaporkan: INSTALLED\$1OTHER | Status yang dilaporkan: INSTALLED\$1REJECTED | 
| Patch belum diinstal | Patch dilewati | Patch dilewati | 

Setiap patch untuk Windows Server rilis Microsoft biasanya berisi semua informasi yang diperlukan agar instalasi berhasil. Namun, kadang-kadang, paket prasyarat mungkin diperlukan, yang harus Anda instal secara manual. Patch Managertidak melaporkan informasi tentang prasyarat ini. Untuk informasi terkait, lihat [Pemecahan masalah Pembaruan Windows di situs](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting) web Microsoft.

# Dokumen SSM Command untuk menambal node terkelola
<a name="patch-manager-ssm-documents"></a>

Topik ini menjelaskan sembilan dokumen Systems Manager (dokumen SSM) yang tersedia untuk membantu Anda menjaga node terkelola tetap ditambal dengan pembaruan terkait keamanan terbaru. 

Kami merekomendasikan hanya menggunakan lima dokumen ini dalam operasi patching Anda. Bersama-sama, lima dokumen SSM ini memberi Anda berbagai macam opsi patching menggunakan AWS Systems Manager. Empat dari dokumen-dokumen ini dirilis belakangan daripada empat dokumen SSM warisan yang mereka gantikan dan mewakili ekspansi atau konsolidasi fungsi.

**Dokumen SSM yang direkomendasikan untuk ditambal**  
Sebaiknya gunakan lima dokumen SSM berikut dalam operasi patching Anda.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`

**Dokumen SSM lama untuk ditambal**  
Empat dokumen SSM lama berikut tetap tersedia di beberapa Wilayah AWS tetapi tidak lagi diperbarui atau didukung. Dokumen-dokumen ini tidak dijamin untuk bekerja di IPv6 lingkungan dan dukungan saja IPv4. Mereka tidak dapat dijamin untuk bekerja di semua skenario dan mungkin kehilangan dukungan di masa depan. Kami menyarankan Anda untuk tidak menggunakan dokumen ini untuk operasi patching.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`

Untuk langkah-langkah menyiapkan operasi penambalan di lingkungan yang hanya mendukung, lihat IPv6. [Tutorial: Menambal server di IPv6 satu-satunya lingkungan](patch-manager-server-patching-iPv6-tutorial.md)

Rujuk ke bagian berikut ini untuk informasi selengkapnya tentang menggunakan dokumen SSM ini di operasi patching Anda.

**Topics**
+ [Dokumen SSM direkomendasikan untuk menambal node terkelola](#patch-manager-ssm-documents-recommended)
+ [Dokumen SSM lama untuk menambal node terkelola](#patch-manager-ssm-documents-legacy)
+ [Keterbatasan yang diketahui dari dokumen SSM untuk menambal node terkelola](#patch-manager-ssm-documents-known-limitations)
+ [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Contoh skenario untuk menggunakan InstallOverrideList parameter di `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Menggunakan BaselineOverride parameter](patch-manager-baselineoverride-parameter.md)

## Dokumen SSM direkomendasikan untuk menambal node terkelola
<a name="patch-manager-ssm-documents-recommended"></a>

Lima dokumen SSM berikut direkomendasikan untuk digunakan dalam operasi patching node terkelola Anda.

**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)

### `AWS-ConfigureWindowsUpdate`
<a name="patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate"></a>

Support konfigurasi fungsi Windows Update dasar dan menggunakannya untuk menginstal pembaruan secara otomatis (atau mematikan pembaruan otomatis). Tersedia di semua Wilayah AWS.

Dokumen SSM ini meminta Pembaruan Windows untuk mengunduh dan menginstal pembaruan yang ditentukan dan me-reboot node yang dikelola sesuai kebutuhan. Gunakan dokumen ini denganState Manager, alat di AWS Systems Manager, untuk memastikan Pembaruan Windows mempertahankan konfigurasinya. Anda juga dapat menjalankannya secara manual menggunakanRun Command, alat di AWS Systems Manager, untuk mengubah konfigurasi Pembaruan Windows. 

Parameter yang tersedia dalam support dokumen ini menentukan kategori pembaruan untuk diinstal (atau apakah akan mematikan pembaruan otomatis), serta menentukan hari dan waktu untuk menjalankan operasi patching. Dokumen SSM ini sangat berguna jika Anda tidak memerlukan kendali ketat atas Windows Update dan tidak perlu mengumpulkan informasi kepatuhan. 

**Menggantikan dokumen SSM lama:**
+ *Tidak ada*

### `AWS-InstallWindowsUpdates`
<a name="patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates"></a>

Menginstal pembaruan pada node Windows Server terkelola. Tersedia di semua Wilayah AWS.

Dokumen SSM ini menyediakan fungsi patching dasar dalam kasus ketika Anda ingin menginstal pembaruan tertentu (menggunakan parameter `Include Kbs`), atau ingin menginstal patch dengan klasifikasi atau kategori tertentu tetapi tidak memerlukan informasi kepatuhan patch. 

**Menggantikan dokumen SSM lama:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`

Ketiga dokumen warisan melakukan fungsi yang berbeda, tetapi Anda dapat meraih hasil yang sama dengan menggunakan pengaturan parameter yang berbeda dengan dokumen SSM yang lebih baru `AWS-InstallWindowsUpdates`. Pengaturan parameter ini dijelaskan dalam [Dokumen SSM lama untuk menambal node terkelola](#patch-manager-ssm-documents-legacy).

### `AWS-RunPatchBaseline`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline"></a>

Menginstal patch pada node terkelola atau memindai node untuk menentukan apakah ada patch yang memenuhi syarat yang hilang. Tersedia di semua Wilayah AWS.

`AWS-RunPatchBaseline` memungkinkan Anda untuk mengendalikan persetujuan patch menggunakan dasar patch yang ditetapkan sebagai "default" untuk sebuah jenis sistem operasi. Melaporkan informasi kepatuhan patch yang dapat Anda lihat menggunakan alat Kepatuhan Systems Manager. Alat-alat ini memberi Anda wawasan tentang status kepatuhan patch dari node terkelola Anda, seperti node mana yang tidak memiliki tambalan dan apa tambalan tersebut. Saat Anda menggunakan `AWS-RunPatchBaseline`, informasi kepatuhan patch dicatat menggunakan perintah API `PutInventory`. Untuk sistem operasi Linux, informasi kepatuhan disediakan untuk tambalan dari repositori sumber default yang dikonfigurasi pada node terkelola dan dari repositori sumber alternatif apa pun yang Anda tentukan dalam baseline patch kustom. Untuk informasi selengkapnya tentang repositori sumber alternatif, lihat [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md). Untuk informasi selengkapnya tentang alat Kepatuhan Systems Manager, lihat [AWS Systems Manager Kepatuhan](systems-manager-compliance.md).

 **Menggantikan dokumen lama:**
+ `AWS-ApplyPatchBaseline`

Dokumen lama hanya `AWS-ApplyPatchBaseline` berlaku untuk node Windows Server terkelola, dan tidak memberikan dukungan untuk patching aplikasi. `AWS-RunPatchBaseline` yang lebih baru menyediakan support yang sama untuk sistem Windows dan Linux. Versi 2.0.834.0 atau yang lebih baru SSM Agent diperlukan untuk menggunakan dokumen. `AWS-RunPatchBaseline` 

Untuk informasi lebih lanjut tentang dokumen SSM `AWS-RunPatchBaseline`, lihat [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

### `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation"></a>

Menginstal patch pada instans Anda atau memindai instans untuk menentukan apakah ada patch yang memenuhi syarat yang hilang. Tersedia di semua Wilayah AWS komersial. 

`AWS-RunPatchBaselineAssociation` berbeda dengan `AWS-RunPatchBaseline` dalam beberapa hal penting:
+ `AWS-RunPatchBaselineAssociation`dimaksudkan untuk digunakan terutama dengan State Manager asosiasi yang dibuat menggunakanQuick Setup, alat di AWS Systems Manager. Secara khusus, ketika Anda menggunakan jenis konfigurasi Manajemen Quick Setup Host, jika Anda memilih opsi **Pindai instance untuk tambalan yang hilang setiap hari**, sistem menggunakan `AWS-RunPatchBaselineAssociation` untuk operasi.

  Namun, dalam kebanyakan kasus, saat menyiapkan operasi patching Anda sendiri, Anda harus memilih [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) atau [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) sebagai ganti `AWS-RunPatchBaselineAssociation`. 

  Untuk informasi selengkapnya, lihat topik berikut:
  + [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
  + [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` mendukung penggunaan tag untuk mengidentifikasi dasar patch yang digunakan dengan serangkaian target ketika dijalankan. 
+ Untuk operasi penambalan yang digunakan`AWS-RunPatchBaselineAssociation`, data kepatuhan tambalan dikompilasi dalam hal State Manager asosiasi tertentu. data kepatuhan patch dikumpulkan saat `AWS-RunPatchBaselineAssociation` berjalan dicatat menggunakan perintah API `PutComplianceItems` dan bukan perintah `PutInventory`. Hal ini mencegah data kepatuhan yang tidak terkait dengan asosiasi khusus ini ditimpa.

  Untuk sistem operasi Linux, informasi kepatuhan disediakan untuk patch dari repositori sumber default yang dikonfigurasi pada sebuah instans dan juga dari repositori sumber alternatif lain yang Anda tentukan pada sebuah dasar patch kustom. Untuk informasi selengkapnya tentang repositori sumber alternatif, lihat [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md). Untuk informasi selengkapnya tentang alat Kepatuhan Systems Manager, lihat [AWS Systems Manager Kepatuhan](systems-manager-compliance.md).

 **Menggantikan dokumen lama:**
+ **Tidak ada**

Untuk informasi lebih lanjut tentang dokumen SSM `AWS-RunPatchBaselineAssociation`, lihat [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).

### `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks"></a>

Menginstal patch pada node terkelola atau memindai node untuk menentukan apakah ada patch yang memenuhi syarat yang hilang, dengan kait opsional yang dapat Anda gunakan untuk menjalankan dokumen SSM di tiga titik selama siklus patching. Tersedia di semua Wilayah AWS komersial. Tidak didukung padamacOS.

`AWS-RunPatchBaselineWithHooks` berbeda dengan `AWS-RunPatchBaseline` dalam hal operasi `Install`.

`AWS-RunPatchBaselineWithHooks`mendukung kait siklus hidup yang berjalan pada titik yang ditentukan selama patch node terkelola. Karena instalasi patch kadang-kadang memerlukan node terkelola untuk reboot, operasi patching dibagi menjadi dua peristiwa, dengan total tiga kait yang mendukung fungsionalitas kustom. Kait pertama adalah sebelum operasi `Install with NoReboot`. Kait kedua adalah setelah operasi `Install with NoReboot`. Kait ketiga tersedia setelah reboot node.

 **Menggantikan dokumen lama:**
+ **Tidak ada**

Untuk informasi lebih lanjut tentang dokumen SSM `AWS-RunPatchBaselineWithHooks`, lihat [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).

## Dokumen SSM lama untuk menambal node terkelola
<a name="patch-manager-ssm-documents-legacy"></a>

Empat dokumen SSM berikut masih tersedia di beberapa Wilayah AWS. Namun, mereka tidak lagi diperbarui dan mungkin tidak lagi didukung di masa mendatang, jadi kami tidak merekomendasikan penggunaannya. Sebagai gantinya, gunakan dokumen yang dijelaskan dalam [Dokumen SSM direkomendasikan untuk menambal node terkelola](#patch-manager-ssm-documents-recommended).

**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)

### `AWS-ApplyPatchBaseline`
<a name="patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline"></a>

Mendukung hanya node Windows Server terkelola, tetapi tidak termasuk dukungan untuk menambal aplikasi yang ditemukan dalam penggantinya,`AWS-RunPatchBaseline`. Tidak tersedia di Wilayah AWS diluncurkan setelah Agustus 2017.

**catatan**  
Penggantian untuk dokumen SSM ini,`AWS-RunPatchBaseline`, memerlukan versi 2.0.834.0 atau versi yang lebih baru. SSM Agent Anda dapat menggunakan `AWS-UpdateSSMAgent` dokumen untuk memperbarui node terkelola Anda ke versi terbaru agen. 

### `AWS-FindWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates"></a>

Digantikan oleh `AWS-InstallWindowsUpdates`, yang dapat melakukan semua tindakan yang sama. Tidak tersedia di Wilayah AWS diluncurkan setelah April 2017.

Untuk mencapai hasil yang sama yang biasanya Anda dapatkan dari dokumen SSM warisan ini, gunakan konfigurasi parameter berikut ini dengan dokumen pengganti yang direkomendasikan, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`

### `AWS-InstallMissingWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates"></a>

Digantikan oleh `AWS-InstallWindowsUpdates`, yang dapat melakukan semua tindakan yang sama. Tidak tersedia dalam Wilayah AWS peluncuran apa pun setelah April 2017.

Untuk mencapai hasil yang sama yang biasanya Anda dapatkan dari dokumen SSM warisan ini, gunakan konfigurasi parameter berikut ini dengan dokumen pengganti yang direkomendasikan, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`

### `AWS-InstallSpecificWindowsUpdates`
<a name="patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates"></a>

Digantikan oleh `AWS-InstallWindowsUpdates`, yang dapat melakukan semua tindakan yang sama. Tidak tersedia dalam Wilayah AWS peluncuran apa pun setelah April 2017.

Untuk mencapai hasil yang sama yang biasanya Anda dapatkan dari dokumen SSM warisan ini, gunakan konfigurasi parameter berikut ini dengan dokumen pengganti yang direkomendasikan, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *comma-separated list of KB articles*

## Keterbatasan yang diketahui dari dokumen SSM untuk menambal node terkelola
<a name="patch-manager-ssm-documents-known-limitations"></a>

### Gangguan reboot eksternal
<a name="patch-manager-ssm-documents-known-limitations-external-reboot"></a>

Jika reboot dimulai oleh sistem pada node selama instalasi patch (misalnya, untuk menerapkan pembaruan ke firmware atau fitur seperti SecureBoot), eksekusi dokumen patching dapat terganggu dan ditandai sebagai gagal meskipun patch berhasil diinstal. Hal ini terjadi karena Agen SSM tidak dapat bertahan dan melanjutkan status eksekusi dokumen di seluruh reboot eksternal.

Untuk memverifikasi status instalasi patch setelah eksekusi gagal, jalankan operasi `Scan` patching, lalu periksa data kepatuhan patch di Patch Manager untuk menilai status kepatuhan saat ini.

# Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`
<a name="patch-manager-aws-runpatchbaseline"></a>

AWS Systems Manager mendukung`AWS-RunPatchBaseline`, dokumen Systems Manager (dokumen SSM) untukPatch Manager, alat di AWS Systems Manager. Dokumen SSM ini melakukan operasi penambalan pada node terkelola untuk pembaruan terkait keamanan dan jenis pembaruan lainnya. Ketika dokumen dijalankan, ia menggunakan dasar patch yang ditetapkan sebagai "default" untuk suatu jenis sistem operasi jika tidak ada grup patch yang ditentukan. Jika tidak, ia menggunakan dasar patch yang terkait dengan grup patch. Untuk informasi tentang grup patch, lihat [Grup tambalan](patch-manager-patch-groups.md). 

Anda dapat menggunakan `AWS-RunPatchBaseline` untuk menerapkan patch untuk sistem operasi dan aplikasi. (Pada Windows Server, support aplikasi dibatasi pada pembaruan untuk aplikasi yang dirilis oleh Microsoft.)

Dokumen ini mendukung Linux,macOS, dan node Windows Server terkelola. Dokumen ini akan melakukan tindakan yang sesuai untuk setiap platform. 

**catatan**  
Patch Managerjuga mendukung dokumen SSM lama. `AWS-ApplyPatchBaseline` Namun, dokumen ini mendukung penambalan pada node yang dikelola Windows saja. Kami mendorong Anda untuk menggunakan `AWS-RunPatchBaseline` sebagai gantinya karena mendukung patching di Linux,macOS, dan node Windows Server terkelola. Versi 2.0.834.0 atau yang lebih baru SSM Agent diperlukan untuk menggunakan dokumen. `AWS-RunPatchBaseline`

------
#### [ Windows Server ]

Pada node Windows Server terkelola, `AWS-RunPatchBaseline` dokumen mengunduh dan memanggil PowerShell modul, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node terkelola. snapshot dasar patch ini berisi daftar patch yang disetujui yang dikumpulkan dengan melakukan kueri dasar patch pada server Windows Server Update Services (WSUS). Daftar ini diteruskan ke API Windows Update, yang mengendalikan pengunduhan dan instalasi patch yang disetujui sesuai kebutuhan. 

------
#### [ Linux ]

Pada node yang dikelola Linux, `AWS-RunPatchBaseline` dokumen tersebut memanggil modul Python, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node terkelola. Snapshot dasar tambalan ini menggunakan aturan yang ditentukan dan daftar tambalan yang disetujui dan diblokir untuk mendorong manajer paket yang sesuai untuk setiap jenis node: 
+ Amazon Linux 2,Oracle Linux, dan RHEL 7 node terkelola menggunakan YUM. Untuk operasi YUM, Patch Manager membutuhkan `Python 2.6` atau versi yang didukung yang lebih baru (2.6 - 3.12). Amazon Linux 2023 menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi yang didukung dari `Python 2` atau `Python 3` (2.6 - 3.12).
+ RHEL8 node terkelola menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi yang didukung dari `Python 2` atau `Python 3` (2.6 - 3.12). (Tidak ada versi yang diinstal secara default pada RHEL 8. Anda harus menginstal satu atau yang lain secara manual.)
+ Debian Server, dan Ubuntu Server contoh menggunakan APT. Untuk operasi APT, Patch Manager memerlukan versi yang didukung `Python 3` (3.0 - 3.12).

------
#### [ macOS ]

Pada node macOS terkelola, `AWS-RunPatchBaseline` dokumen memanggil modul Python, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node terkelola. Selanjutnya, subproses Python memanggil AWS Command Line Interface (AWS CLI) pada node untuk mengambil instalasi dan memperbarui informasi untuk manajer paket tertentu dan untuk mendorong manajer paket yang sesuai untuk setiap paket pembaruan.

------

Setiap snapshot khusus untuk, grup patch Akun AWS, sistem operasi, dan ID snapshot. Snapshot dikirimkan melalui URL Amazon Simple Storage Service (Amazon S3) yang telah ditandatangani sebelumnya, yang kedaluwarsa 24 jam setelah snapshot dibuat. Namun, setelah URL kedaluwarsa, jika Anda ingin menerapkan konten snapshot yang sama ke node terkelola lainnya, Anda dapat membuat URL Amazon S3 yang telah ditetapkan sebelumnya hingga 3 hari setelah snapshot dibuat. Untuk melakukannya, gunakan perintah [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). 

Setelah semua pembaruan yang disetujui dan berlaku telah diinstal, dengan reboot dilakukan seperlunya, informasi kepatuhan tambalan dihasilkan pada node yang dikelola dan dilaporkan kembali kePatch Manager. 

**catatan**  
Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi selengkapnya, lihat [Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).

Untuk informasi tentang melihat data kepatuhan patch, lihat [Tentang kepatuhan patch](compliance-about.md#compliance-monitor-patch). 

## Parameter `AWS-RunPatchBaseline`
<a name="patch-manager-aws-runpatchbaseline-parameters"></a>

`AWS-RunPatchBaseline` support enam parameter. parameter `Operation` diperlukan. `RebootOption`Parameter `InstallOverrideList``BaselineOverride`,, dan bersifat opsional. `Snapshot-ID`secara teknis opsional, tetapi kami menyarankan Anda memberikan nilai khusus untuk itu ketika Anda menjalankan `AWS-RunPatchBaseline` di luar jendela pemeliharaan. Patch Managerdapat memberikan nilai kustom secara otomatis ketika dokumen dijalankan sebagai bagian dari operasi jendela pemeliharaan.

**Topics**
+ [Nama parameter: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nama parameter: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nama parameter: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nama parameter: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nama parameter: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nama parameter: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)

### Nama parameter: `Operation`
<a name="patch-manager-aws-runpatchbaseline-parameters-operation"></a>

**Penggunaan**: Wajib.

**Opsi**: `Scan` \$1 `Install`. 

Pemindaian  
Saat Anda memilih `Scan` opsi, `AWS-RunPatchBaseline` tentukan status kepatuhan patch dari node terkelola dan laporkan informasi ini kembali kePatch Manager. `Scan`tidak meminta pembaruan untuk diinstal atau node yang dikelola untuk di-boot ulang. Sebaliknya, operasi mengidentifikasi di mana pembaruan hilang yang disetujui dan berlaku untuk node. 

Menginstal  
Ketika Anda memilih `Install` opsi, `AWS-RunPatchBaseline` mencoba untuk menginstal pembaruan yang disetujui dan berlaku yang hilang dari node terkelola. Informasi kepatuhan patch yang dihasilkan sebagai bagian operasi `Install` tidak mencantumkan pembaruan yang hilang, tetapi mungkin melaporkan pembaruan yang berstatus gagal jika instalasi pembaruan tidak berhasil karena alasan apa pun. Setiap kali pembaruan diinstal pada node terkelola, node di-reboot untuk memastikan pembaruan diinstal dan aktif. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaseline` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)  
Jika patch yang ditentukan oleh aturan dasar diinstal *sebelum* Patch Manager memperbarui node terkelola, sistem mungkin tidak reboot seperti yang diharapkan. Hal ini dapat terjadi ketika patch diinstal secara manual oleh pengguna atau diinstal secara otomatis oleh program lain, seperti `unattended-upgrades` paket aktifUbuntu Server.

### Nama parameter: `AssociationId`
<a name="patch-manager-aws-runpatchbaseline-parameters-association-id"></a>

**Penggunaan**: Opsional.

`AssociationId`adalah ID dari asosiasi yang ada diState Manager, alat di AWS Systems Manager. Ini digunakan oleh Patch Manager untuk menambahkan data kepatuhan ke asosiasi tertentu. Asosiasi ini terkait dengan operasi penambalan yang [diatur dalam kebijakan tambalan di Quick Setup](quick-setup-patch-manager.md). 

**catatan**  
Dengan`AWS-RunPatchBaseline`, jika `AssociationId` nilai diberikan bersama dengan penggantian dasar kebijakan tambalan, penambalan dilakukan sebagai `PatchPolicy` operasi dan `ExecutionType` nilai yang dilaporkan juga. `AWS:ComplianceItem` `PatchPolicy` Jika tidak ada `AssociationId` nilai yang diberikan, penambalan dilakukan sebagai `Command` operasi dan laporan `ExecutionType` nilai pada yang `AWS:ComplianceItem` diserahkan juga`Command`. 

Jika Anda belum memiliki asosiasi yang ingin Anda gunakan, Anda dapat membuatnya dengan menjalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)perintah. 

### Nama parameter: `Snapshot ID`
<a name="patch-manager-aws-runpatchbaseline-parameters-snapshot-id"></a>

**Penggunaan**: Opsional.

`Snapshot ID`adalah ID unik (GUID) yang digunakan oleh Patch Manager untuk memastikan bahwa satu set node terkelola yang ditambal dalam satu operasi semuanya memiliki set patch yang disetujui yang sama persis. Meskipun parameter didefinisikan sebagai opsional, rekomendasi praktik terbaik kami bergantung pada apakah Anda menjalankan `AWS-RunPatchBaseline` atau tidak di jendela pemeliharaan, seperti yang dijelaskan dalam tabel berikut.


**Praktik terbaik `AWS-RunPatchBaseline`**  

| Mode | Praktik terbaik | Detail | 
| --- | --- | --- | 
| Menjalankan AWS-RunPatchBaseline di dalam jendela pemeliharaan | Jangan berikan ID Snapshot. Patch Managerakan memasoknya untuk Anda. |  Jika Anda menggunakan jendela pemeliharaan untuk menjalankan`AWS-RunPatchBaseline`, Anda seharusnya tidak memberikan ID Snapshot yang dibuat sendiri. Dalam skenario ini, Systems Manager menyediakan nilai GUID berdasarkan ID eksekusi jendela pemeliharaan. Hal ini memastikan bahwa digunakan ID yang benar untuk semua pemanggilan `AWS-RunPatchBaseline` dalam jendela pemeliharaan tersebut.  Jika Anda menentukan nilai dalam skenario ini, perhatikan bahwa snapshot dari baseline patch mungkin tidak tetap di tempatnya selama lebih dari 3 hari. Setelah itu, snapshot baru akan dihasilkan bahkan jika Anda menentukan ID yang sama setelah snapshot berakhir.   | 
| Menjalankan AWS-RunPatchBaseline di luar jendela pemeliharaan | Menghasilkan dan menentukan nilai GUID kustom untuk ID Snapshot.¹ |  Bila Anda tidak menggunakan jendela pemeliharaan untuk menjalankan`AWS-RunPatchBaseline`, kami sarankan Anda membuat dan menentukan ID Snapshot unik untuk setiap baseline patch, terutama jika Anda menjalankan `AWS-RunPatchBaseline` dokumen pada beberapa node terkelola dalam operasi yang sama. Jika Anda tidak menentukan ID dalam skenario ini, Systems Manager akan menghasilkan ID Snapshot yang berbeda untuk setiap node terkelola tempat perintah dikirim. Hal ini dapat mengakibatkan berbagai set patch yang ditentukan di antara node terkelola. Misalnya, katakan bahwa Anda menjalankan `AWS-RunPatchBaseline` dokumen secara langsung melaluiRun Command, alat di AWS Systems Manager, dan menargetkan sekelompok 50 node terkelola. Menentukan ID Snapshot kustom menghasilkan pembuatan snapshot dasar tunggal yang digunakan untuk mengevaluasi dan menambal semua node, memastikan bahwa mereka berakhir dalam keadaan konsisten.   | 
|  ¹ Anda dapat menggunakan alat yang mampu menghasilkan GUID untuk menghasilkan nilai untuk parameter ID Snapshot. Misalnya, di PowerShell, Anda dapat menggunakan `New-Guid` cmdlet untuk menghasilkan GUID dalam format. `12345699-9405-4f69-bc5e-9315aEXAMPLE`  | 

### Nama parameter: `InstallOverrideList`
<a name="patch-manager-aws-runpatchbaseline-parameters-installoverridelist"></a>

**Penggunaan**: Opsional.

Dengan menggunakan `InstallOverrideList`, Anda menentukan URL https atau URL ala jalur Amazon S3 ke daftar patch yang akan diinstal. Daftar instalasi patch ini, yang Anda pertahankan dalam format YAML, menggantikan patch yang ditentukan oleh dasar patch default saat ini. Ini memberi Anda kontrol yang lebih terperinci atas tambalan mana yang diinstal pada node terkelola Anda. 

**penting**  
Nama `InstallOverrideList` file tidak dapat berisi karakter berikut: backtick (`), kutipan tunggal ('), kutipan ganda (“), dan tanda dolar (\$1).

Perilaku operasi patching saat menggunakan `InstallOverrideList` parameter berbeda antara Linux & node macOS terkelola dan node Windows Server terkelola. Di Linux &macOS, Patch Manager upaya untuk menerapkan tambalan yang disertakan dalam daftar `InstallOverrideList` tambalan yang ada di repositori apa pun yang diaktifkan pada node, apakah tambalan cocok dengan aturan dasar tambalan atau tidak. Namun, pada Windows Server node, tambalan dalam daftar `InstallOverrideList` tambalan diterapkan *hanya* jika mereka juga cocok dengan aturan dasar patch.

Sadarilah bahwa laporan kepatuhan mencerminkan status patch berdasarkan apa yang ditentukan dalam dasar patch, bukan apa yang Anda tentukan dalam daftar patch `InstallOverrideList`. Dengan kata lain, operasi Pemindaian mengabaikan parameter `InstallOverrideList`. Hal ini untuk memastikan bahwa laporan kepatuhan secara konsisten mencerminkan keadaan patch berdasarkan kebijakan daripada apa yang disetujui untuk operasi patching tertentu. 

**catatan**  
Saat Anda menambal node yang hanya menggunakan IPv6, pastikan URL yang disediakan dapat dijangkau dari node. Jika opsi SSM Agent konfigurasi `UseDualStackEndpoint` disetel ke`true`, maka klien S3 dualstack digunakan saat URL S3 disediakan. Lihat [Tutorial: Menambal server di IPv6 satu-satunya lingkungan](patch-manager-server-patching-iPv6-tutorial.md) untuk informasi selengkapnya tentang mengonfigurasi agen untuk menggunakan dualstack.

Untuk penjelasan tentang cara Anda dapat menggunakan parameter `InstallOverrideList` untuk menerapkan berbagai jenis patch berbeda ke sebuah grup target, pada jadwal jendela pemeliharaan yang berbeda, sembari tetap menggunakan dasar patch tunggal, lihat [Contoh skenario untuk menggunakan InstallOverrideList parameter di `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).

**Format URL yang valid**

**catatan**  
Jika file Anda disimpan dalam bucket yang tersedia secara publik, Anda dapat menentukan format URL https atau URL ala jalur Amazon S3. Jika file Anda disimpan dalam bucket privat, Anda harus menentukan URL ala jalur Amazon S3.
+ **format URL https**:

  ```
  https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```
+ **URL ala jalur Amazon S3**:

  ```
  s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```

**Format konten YAMM yang valid**

Format yang Anda gunakan untuk menentukan tambalan dalam daftar Anda bergantung pada sistem operasi node terkelola Anda. Namun, format yang umum adalah seperti berikut ini:

```
patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}
```

Meskipun Anda dapat memberikan bidang tambahan dalam file YAML Anda, mereka diabaikan selama operasi patch.

Selain itu, kami merekomendasikan untuk memverifikasi bahwa format file YAML Anda valid sebelum menambahkan atau memperbarui daftar di bucket S3 Anda. Untuk informasi lebih lanjut tentang format YAML, lihat [yaml.org](http://www.yaml.org). Untuk pilihan alat validasi, lakukan pencarian web untuk "validator format yaml".

------
#### [ Linux ]

**id**  
Bidang **id** wajib diisi. Gunakan untuk menentukan patch menggunakan nama paket dan arsitektur. Sebagai contoh: `'dhclient.x86_64'`. Anda dapat menggunakan wildcard dalam id untuk menunjukkan lebih dari satu paket. Sebagai contoh: `'dhcp*'` dan `'dhcp*1.*'`.

**judul**  
Bidang **judul** bersifat opsional, tetapi pada sistem Linux bidang tersebut memberikan kemampuan filter tambahan. Jika Anda menggunakan **judul**, sebaiknya berisi informasi versi paket dalam salah satu format berikut:

YUM/SUSE Linux Enterprise Server (SLES):

```
{name}.{architecture}:{epoch}:{version}-{release}
```

APT

```
{name}.{architecture}:{version}
```

Untuk judul patch Linux, Anda dapat menggunakan satu atau lebih wildcard di posisi apa pun untuk memperluas jumlah kecocokan paket. Sebagai contoh: `'*32:9.8.2-0.*.rc1.57.amzn1'`. 

Contoh: 
+ paket apt versi 1.2.25 saat ini diinstal pada node terkelola Anda, tetapi versi 1.2.27 sekarang tersedia. 
+ Anda menambahkan apt.amd64 versi 1.2.27 ke daftar patch. Hal ini tergantung pada apt utils.amd64 versi 1.2.27, tapi apt-utils.amd64 versi 1.2.25 ditentukan dalam daftar. 

Dalam hal ini, apt versi 1.2.27 akan diblokir dari instalasi dan dilaporkan sebagai “Gagal-.” NonCompliant

------
#### [ Windows Server ]

**id**  
Bidang **id** wajib diisi. Gunakan untuk menentukan patch menggunakan Microsoft Knowledge Base IDs (misalnya, KB2736693) dan Microsoft Security Bulletin IDs (misalnya, MS17 -023). 

Bidang lain yang ingin Anda berikan dalam daftar patch untuk Windows bersifat opsional dan hanya digunakan sebagai informasi Anda sendiri. Anda dapat menggunakan bidang tambahan seperti **judul**, **klasifikasi**, **Tingkat kepelikan**, atau yang lainnya untuk memberikan informasi lebih detail tentang patch yang ditentukan.

------
#### [ macOS ]

**id**  
Bidang **id** wajib diisi. Nilai untuk bidang **id** dapat diberikan menggunakan format `{package-name}.{package-version}` atau format \$1nama\$1paket\$1.

------

**Contoh daftar tambalan**
+ **Amazon Linux 2**

  ```
  patches:
      -
          id: 'kernel.x86_64'
      -
          id: 'bind*.x86_64'
          title: '39.11.4-26.P2.amzn2.5.2'
  
          id: 'glibc*'
      -
          id: 'dhclient*'
          title: '*4.2.5-58.amzn2'
      -
          id: 'dhcp*'
          title: '*4.2.5-77.amzn2'
  ```
+ **Debian Server**

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **macOS**

  ```
  patches:
      -
          id: 'XProtectPlistConfigData'
      -
          id: 'MRTConfigData.1.61'
      -
          id: 'Command Line Tools for Xcode.11.5'
      -
          id: 'Gatekeeper Configuration Data'
  ```
+ **Oracle Linux**

  ```
  patches:
      -
          id: 'audit-libs.x86_64'
          title: '*2.8.5-4.el7'
      -
          id: 'curl.x86_64'
          title: '*.el7'
      -
          id: 'grub2.x86_64'
          title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
      -
          id: 'grub2.x86_64'
          title: 'grub2.x86_64:1:*-0.81.0.1.el7'
  ```
+ **Red Hat Enterprise Linux (RHEL)**

  ```
  patches:
      -
          id: 'NetworkManager.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'NetworkManager-*.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'audit.x86_64'
          title: '*0:2.8.1-3.el7'
      -
          id: 'dhclient.x86_64'
          title: '*.el7_5.1'
      -
          id: 'dhcp*.x86_64'
          title: '*12:5.2.5-68.el7'
  ```
+ **SUSE Linux Enterprise Server (SLES)**

  ```
  patches:
      -
          id: 'amazon-ssm-agent.x86_64'
      -
          id: 'binutils'
          title: '*0:2.26.1-9.12.1'
      -
          id: 'glibc*.x86_64'
          title: '*2.19*'
      -
          id: 'dhcp*'
          title: '0:4.3.3-9.1'
      -
          id: 'lib*'
  ```
+ **Ubuntu Server **

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```

### Nama parameter: `RebootOption`
<a name="patch-manager-aws-runpatchbaseline-parameters-norebootoption"></a>

**Penggunaan**: Opsional.

**Pilihan**: `RebootIfNeeded` \$1 `NoReboot` 

**Default**: `RebootIfNeeded`

**Awas**  
Opsi default-nya adalah `RebootIfNeeded`. Pastikan untuk memilih opsi yang benar untuk kasus penggunaan Anda. Misalnya, jika node terkelola Anda harus segera reboot untuk menyelesaikan proses konfigurasi, pilih`RebootIfNeeded`. Atau, jika Anda perlu mempertahankan ketersediaan node terkelola hingga waktu reboot yang dijadwalkan, pilih`NoReboot`.

**penting**  
Kami tidak menyarankan penggunaan Patch Manager untuk menambal instance cluster di Amazon EMR (sebelumnya disebut Amazon Elastic). MapReduce Secara khusus, jangan pilih `RebootIfNeeded` opsi untuk `RebootOption` parameter. (Opsi ini tersedia dalam dokumen Perintah SSM untuk ditambal`AWS-RunPatchBaseline`,`AWS-RunPatchBaselineAssociation`, dan`AWS-RunPatchBaselineWithHooks`.)  
Perintah yang mendasari untuk menambal menggunakan Patch Manager penggunaan `yum` dan `dnf` perintah. Oleh karena itu, operasi mengakibatkan ketidakcocokan karena bagaimana paket diinstal. Untuk informasi tentang metode yang disukai untuk memperbarui perangkat lunak di klaster EMR Amazon, lihat [Menggunakan default untuk AMI Amazon EMR di Panduan Manajemen EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) *Amazon*.

RebootIfNeeded  
Saat Anda memilih `RebootIfNeeded` opsi, node terkelola di-boot ulang dalam salah satu kasus berikut:   
+ Patch Managermemasang satu atau lebih tambalan. 

  Patch Managertidak mengevaluasi apakah reboot *diperlukan* oleh tambalan. Sistem di-boot ulang bahkan jika tambalan tidak memerlukan reboot.
+ Patch Managermendeteksi satu atau lebih tambalan dengan status `INSTALLED_PENDING_REBOOT` selama operasi. `Install` 

  `INSTALLED_PENDING_REBOOT`Status dapat berarti bahwa opsi `NoReboot` dipilih saat terakhir kali `Install` operasi dijalankan, atau tambalan dipasang di luar Patch Manager sejak terakhir kali node terkelola di-boot ulang.
Mem-boot ulang node terkelola dalam dua kasus ini memastikan bahwa paket yang diperbarui dikeluarkan dari memori dan menjaga perilaku patching dan reboot tetap konsisten di semua sistem operasi.

NoReboot  
Ketika Anda memilih `NoReboot` opsi, Patch Manager tidak me-reboot node terkelola bahkan jika itu menginstal tambalan selama `Install` operasi. Opsi ini berguna jika Anda tahu bahwa node terkelola Anda tidak memerlukan reboot setelah tambalan diterapkan, atau Anda memiliki aplikasi atau proses yang berjalan pada node yang seharusnya tidak terganggu oleh reboot operasi patching. Ini juga berguna ketika Anda ingin lebih banyak kontrol atas waktu reboot node terkelola, seperti dengan menggunakan jendela pemeliharaan.  
Jika Anda memilih opsi `NoReboot` dan sebuah patch diinstal, patch diberikan status `InstalledPendingReboot`. Node yang dikelola itu sendiri, bagaimanapun, ditandai sebagai`Non-Compliant`. Setelah reboot terjadi dan `Scan` operasi dijalankan, status node terkelola diperbarui ke`Compliant`.  
`NoReboot`Opsi ini hanya mencegah restart tingkat sistem operasi. Restart tingkat layanan masih dapat terjadi sebagai bagian dari proses patching. Misalnya, ketika Docker diperbarui, layanan dependen seperti Amazon Elastic Container Service mungkin secara otomatis dimulai ulang bahkan dengan `NoReboot` diaktifkan. Jika Anda memiliki layanan penting yang tidak boleh diganggu, pertimbangkan langkah-langkah tambahan seperti menghapus sementara instance dari layanan atau menjadwalkan penambalan selama jendela pemeliharaan.

**File pelacakan instalasi patch**: Untuk melacak instalasi patch, terutama patch yang diinstal sejak reboot sistem terakhir, Systems Manager memelihara file pada node terkelola.

**penting**  
Jangan menghapus atau memodifikasi file pelacakan. Jika file ini dihapus atau rusak, laporan kepatuhan patch untuk node terkelola tidak akurat. Jika ini terjadi, reboot node dan jalankan operasi Pindai tambalan untuk memulihkan file.

File pelacakan ini disimpan di lokasi berikut pada node terkelola Anda:
+ Sistem operasi Linux: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Sistem operasi Windows Server:
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

### Nama parameter: `BaselineOverride`
<a name="patch-manager-aws-runpatchbaseline-parameters-baselineoverride"></a>

**Penggunaan**: Opsional.

Anda dapat menentukan preferensi patching pada saat runtime menggunakan parameter `BaselineOverride`. Baseline override ini disimpan sebagai objek JSON dalam bucket S3. Ini memastikan operasi patching menggunakan dasar yang disediakan yang cocok dengan sistem operasi host bukannya menerapkan aturan dari dasar patch default

**penting**  
Nama `BaselineOverride` file tidak dapat berisi karakter berikut: backtick (`), kutipan tunggal ('), kutipan ganda (“), dan tanda dolar (\$1).

Untuk informasi selengkapnya tentang cara menggunakan `BaselineOverride` parameter, lihat [Menggunakan BaselineOverride parameter](patch-manager-baselineoverride-parameter.md).

### Nama parameter: `StepTimeoutSeconds`
<a name="patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds"></a>

**Penggunaan**: Wajib.

Waktu dalam detik—antara 1 dan 36000 detik (10 jam) —untuk sebuah perintah diselesaikan sebelum dianggap gagal.

# Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-aws-runpatchbaselineassociation"></a>

Seperti dokumen `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` melakukan operasi patching pada instans untuk jenis pembaruan terkait keamanan dan jenis pembaruan lainnya. Anda juga dapat menggunakan dokumen `AWS-RunPatchBaselineAssociation` untuk menerapkan patch untuk sistem operasi dan aplikasi. (Pada Windows Server, support aplikasi dibatasi pada pembaruan untuk aplikasi yang dirilis oleh Microsoft.)

Dokumen ini mendukung instans Amazon Elastic Compute Cloud (Amazon EC2) untuk Linux, macOS, dan Windows Server. Ini tidak mendukung node non-EC2 di lingkungan [hybrid dan multicloud](operating-systems-and-machine-types.md#supported-machine-types). Dokumen akan melakukan tindakan yang sesuai untuk setiap platform, menjalankan modul Python di Linux macOS dan instance, dan PowerShell modul pada instance Windows.

Namun, `AWS-RunPatchBaselineAssociation` berbeda dari `AWS-RunPatchBaseline` dengan cara berikut: 
+ `AWS-RunPatchBaselineAssociation`dimaksudkan untuk digunakan terutama dengan State Manager asosiasi yang dibuat menggunakan [Quick Setup](systems-manager-quick-setup.md), alat di AWS Systems Manager. Secara khusus, ketika Anda menggunakan jenis konfigurasi Manajemen Quick Setup Host, jika Anda memilih opsi **Pindai instance untuk tambalan yang hilang setiap hari**, sistem menggunakan `AWS-RunPatchBaselineAssociation` untuk operasi.

  Namun, dalam kebanyakan kasus, saat menyiapkan operasi patching Anda sendiri, Anda harus memilih [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) atau [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) sebagai ganti `AWS-RunPatchBaselineAssociation`.
+ Saat Anda menggunakan dokumen `AWS-RunPatchBaselineAssociation`, Anda dapat menentukan pasangan kunci tag dalam bidang parameter `BaselineTags` pada dokumen. Jika baseline patch kustom di Anda Akun AWS membagikan tag ini, alat di Patch Manager AWS Systems Manager, menggunakan baseline yang diberi tag saat berjalan pada instance target alih-alih baseline patch “default” yang saat ini ditentukan untuk jenis sistem operasi.
**catatan**  
Jika Anda memilih untuk menggunakan `AWS-RunPatchBaselineAssociation` dalam operasi penambalan selain yang disiapkan menggunakanQuick Setup, dan Anda ingin menggunakan `BaselineTags` parameter opsionalnya, Anda harus memberikan beberapa izin tambahan ke [profil instans untuk instans](setup-instance-permissions.md) Amazon Elastic Compute Cloud (Amazon EC2). Untuk informasi selengkapnya, lihat [Nama parameter: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).

  Kedua format berikut ini valid untuk parameter `BaselineTags` Anda:

  `Key=tag-key,Values=tag-value`

  `Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**penting**  
Kunci dan nilai tag tidak dapat berisi karakter berikut: backtick (`), kutipan tunggal ('), kutipan ganda (“), dan tanda dolar (\$1).
+ Saat `AWS-RunPatchBaselineAssociation` berjalan, data kepatuhan patch yang dikumpulkan dicatat menggunakan perintah API `PutComplianceItems` bukannya perintah `PutInventory`, yang digunakan oleh `AWS-RunPatchBaseline`. Perbedaan ini berarti bahwa informasi kepatuhan patch yang disimpan dan dilaporkan per *asosiasi* spesifik. data kepatuhan patch yang dihasilkan di luar asosiasi ini tidak ditimpa.
+ Informasi kepatuhan patch yang dilaporkan setelah menjalankan `AWS-RunPatchBaselineAssociation`menunjukkan apakah suatu instans patuh atau tidak. Itu tidak termasuk detail tingkat tambalan, seperti yang ditunjukkan oleh output dari perintah AWS Command Line Interface (AWS CLI) berikut. Filter perintah pada `Association` sebagai tipe kepatuhan:

  ```
  aws ssm list-compliance-items \
      --resource-ids "i-02573cafcfEXAMPLE" \
      --resource-types "ManagedInstance" \
      --filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
      --region us-east-2
  ```

  Sistem mengembalikan informasi seperti berikut ini.

  ```
  {
      "ComplianceItems": [
          {
              "Status": "NON_COMPLIANT", 
              "Severity": "UNSPECIFIED", 
              "Title": "MyPatchAssociation", 
              "ResourceType": "ManagedInstance", 
              "ResourceId": "i-02573cafcfEXAMPLE", 
              "ComplianceType": "Association", 
              "Details": {
                  "DocumentName": "AWS-RunPatchBaselineAssociation", 
                  "PatchBaselineId": "pb-0c10e65780EXAMPLE", 
                  "DocumentVersion": "1"
              }, 
              "ExecutionSummary": {
                  "ExecutionTime": 1590698771.0
              }, 
              "Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
          }
      ]
  }
  ```

Jika nilai key pair tag telah ditentukan sebagai parameter untuk `AWS-RunPatchBaselineAssociation` dokumen, Patch Manager mencari baseline patch kustom yang cocok dengan jenis sistem operasi dan telah ditandai dengan pasangan tag-key yang sama. Pencarian ini tidak terbatas pada dasar patch default yang ditetapkan saat ini atau dasar yang ditetapkan ke grup patch. Jika tidak ada garis dasar yang ditemukan dengan tag yang ditentukan, Patch Manager selanjutnya mencari grup tambalan, jika salah satu ditentukan dalam perintah yang berjalan. `AWS-RunPatchBaselineAssociation` Jika tidak ada grup patch yang cocok, Patch Manager kembali ke baseline patch default saat ini untuk akun sistem operasi. 

Jika lebih dari satu baseline patch ditemukan dengan tag yang ditentukan dalam `AWS-RunPatchBaselineAssociation` dokumen, Patch Manager mengembalikan pesan kesalahan yang menunjukkan bahwa hanya satu baseline patch yang dapat ditandai dengan pasangan kunci-nilai agar operasi dapat dilanjutkan.

**catatan**  
Pada node Linux, manajer paket yang sesuai untuk setiap jenis node digunakan untuk menginstal paket:   
Amazon Linux 2,Oracle Linux, dan RHEL instans menggunakan YUM. Untuk operasi YUM, Patch Manager membutuhkan `Python 2.6` atau versi yang didukung yang lebih baru (2.6 - 3.12). Amazon Linux 2023 menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi `Python 2` atau yang didukung `Python 3` (2.6 - 3.12)
Debian Serverdan Ubuntu Server contoh menggunakan APT. Untuk operasi APT, Patch Manager memerlukan versi yang didukung `Python 3` (3.0 - 3.12).

Setelah pemindaian selesai, atau setelah semua pembaruan yang disetujui dan berlaku telah diinstal, dengan reboot dilakukan seperlunya, informasi kepatuhan patch dihasilkan pada sebuah instans dan dilaporkan kembali ke layanan Patch Manager. 

**catatan**  
Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaselineAssociation` dokumen, instance tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi selengkapnya, lihat [Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).

Untuk informasi tentang melihat data kepatuhan patch, lihat [Tentang kepatuhan patch](compliance-about.md#compliance-monitor-patch). 

## Parameter `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters"></a>

`AWS-RunPatchBaselineAssociation` support lima parameter. Parameter `Operation` dan `AssociationId` diperlukan. Parameter `InstallOverrideList`, `RebootOption`, dan `BaselineTags` bersifat opsional. 

**Topics**
+ [Nama parameter: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nama parameter: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nama parameter: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nama parameter: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)

### Nama parameter: `Operation`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-operation"></a>

**Penggunaan**: Wajib.

**Opsi**: `Scan` \$1 `Install`. 

Pemindaian  
Saat Anda memilih `Scan` opsi, `AWS-RunPatchBaselineAssociation` tentukan status kepatuhan patch dari instance dan laporkan informasi ini kembali kePatch Manager. `Scan`tidak meminta pembaruan untuk diinstal atau instance untuk di-boot ulang. Sebaliknya, operasi ini mengidentifikasi keberadaan pembaruan hilang yang disetujui dan dapat diterapkan ke instans tersebut. 

Pasang  
Saat Anda memilih opsi `Install`, `AWS-RunPatchBaselineAssociation` mencoba untuk menginstal pembaruan yang disetujui dan dapat diterapkan yang hilang dari instans tersebut. Informasi kepatuhan patch yang dihasilkan sebagai bagian operasi `Install` tidak mencantumkan pembaruan yang hilang, tetapi mungkin melaporkan pembaruan yang berstatus gagal jika instalasi pembaruan tidak berhasil karena alasan apa pun. Setiap kali pembaruan diinstal pada sebuah instans, instans tersebut di-reboot untuk memastikan pembaruan telah terinstal dan aktif. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaselineAssociation` dokumen, instance tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).)  
Jika tambalan yang ditentukan oleh aturan dasar diinstal *sebelum* Patch Manager memperbarui instance, sistem mungkin tidak reboot seperti yang diharapkan. Hal ini dapat terjadi ketika patch diinstal secara manual oleh pengguna atau diinstal secara otomatis oleh program lain, seperti `unattended-upgrades` paket aktifUbuntu Server.

### Nama parameter: `BaselineTags`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags"></a>

**Penggunaan**: Opsional. 

`BaselineTags` adalah pasangan nilai kunci tag unik yang Anda pilih dan tetapkan ke dasar patch kustom individu. Anda dapat menentukan satu atau lebih nilai untuk parameter ini. Kedua format berikut ini valid:

`Key=tag-key,Values=tag-value`

`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`

**penting**  
Kunci dan nilai tag tidak dapat berisi karakter berikut: backtick (`), kutipan tunggal ('), kutipan ganda (“), dan tanda dolar (\$1).

`BaselineTags`Nilai ini digunakan oleh Patch Manager untuk memastikan bahwa satu set instance yang ditambal dalam satu operasi semuanya memiliki set patch yang disetujui yang sama persis. Saat operasi penambalan berjalan, Patch Manager periksa untuk melihat apakah garis dasar tambalan untuk jenis sistem operasi ditandai dengan pasangan nilai kunci yang sama yang Anda tentukan. `BaselineTags` Jika ada kecocokan, dasar patch kustom ini digunakan. Jika tidak ada kecocokan, dasar patch diidentifikasi menurut grup patch yang ditentukan untuk operasi patching tersebut. Jika tidak ada, baseline patch standar AWS terkelola untuk sistem operasi itu digunakan. 

**Persyaratan izin tambahan**  
Jika Anda menggunakan `AWS-RunPatchBaselineAssociation` dalam operasi penambalan selain yang disiapkan menggunakanQuick Setup, dan Anda ingin menggunakan `BaselineTags` parameter opsional, Anda harus menambahkan izin berikut ke [profil instans untuk instans](setup-instance-permissions.md) Amazon Elastic Compute Cloud (Amazon EC2).

**catatan**  
Quick Setupdan `AWS-RunPatchBaselineAssociation` tidak mendukung server lokal dan mesin virtual (VMs).

```
{
    "Effect": "Allow",
    "Action": [
        "ssm:DescribePatchBaselines",
        "tag:GetResources"
    ],
    "Resource": "*"
},
{
    "Effect": "Allow",
    "Action": [
        "ssm:GetPatchBaseline",
        "ssm:DescribeEffectivePatchesForPatchBaseline"
    ],
    "Resource": "patch-baseline-arn"
}
```

Ganti *patch-baseline-arn* dengan Amazon Resource Name (ARN) dari baseline patch yang ingin Anda berikan akses, dalam format. `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`

### Nama parameter: `AssociationId`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-association-id"></a>

**Penggunaan**: Wajib.

`AssociationId`adalah ID dari asosiasi yang ada diState Manager, alat di AWS Systems Manager. Ini digunakan oleh Patch Manager untuk menambahkan data kepatuhan ke asosiasi tertentu. Asosiasi ini terkait dengan `Scan` operasi tambalan yang diaktifkan dalam [konfigurasi Manajemen Host yang dibuat di Quick Setup](quick-setup-host-management.md). Dengan mengirimkan hasil penambalan sebagai data kepatuhan asosiasi alih-alih data kepatuhan inventaris, informasi kepatuhan inventaris yang ada untuk instans Anda tidak ditimpa setelah operasi penambalan, atau untuk asosiasi lainnya. IDs Jika Anda belum memiliki asosiasi yang ingin Anda gunakan, Anda dapat membuatnya dengan menjalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)perintah. Contoh:

------
#### [ Linux & macOS ]

```
aws ssm create-association \
    --name "AWS-RunPatchBaselineAssociation" \
    --association-name "MyPatchHostConfigAssociation" \
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
    --parameters "Operation=Scan" \
    --schedule-expression "cron(0 */30 * * * ? *)" \
    --sync-compliance "MANUAL" \
    --region us-east-2
```

------
#### [ Windows Server ]

```
aws ssm create-association ^
    --name "AWS-RunPatchBaselineAssociation" ^
    --association-name "MyPatchHostConfigAssociation" ^
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
    --parameters "Operation=Scan" ^
    --schedule-expression "cron(0 */30 * * * ? *)" ^
    --sync-compliance "MANUAL" ^
    --region us-east-2
```

------

### Nama parameter: `InstallOverrideList`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist"></a>

**Penggunaan**: Opsional.

Dengan menggunakan `InstallOverrideList`, Anda menentukan URL https atau URL ala jalur Amazon Simple Storage Service (Amazon S3) ke daftar patch yang akan diinstal. Daftar instalasi patch ini, yang Anda pertahankan dalam format YAML, menggantikan patch yang ditentukan oleh dasar patch default saat ini. Hal ini memberikan Anda kendali yang lebih terperinci atas patch apa yang diinstal pada instans Anda.

**penting**  
Nama `InstallOverrideList` file tidak dapat berisi karakter berikut: backtick (`), kutipan tunggal ('), kutipan ganda (“), dan tanda dolar (\$1).

Perilaku operasi patching saat menggunakan `InstallOverrideList` parameter berbeda antara Linux & node macOS terkelola dan node Windows Server terkelola. Di Linux &macOS, Patch Manager upaya untuk menerapkan tambalan yang disertakan dalam daftar `InstallOverrideList` tambalan yang ada di repositori apa pun yang diaktifkan pada node, apakah tambalan cocok dengan aturan dasar tambalan atau tidak. Namun, pada Windows Server node, tambalan dalam daftar `InstallOverrideList` tambalan diterapkan *hanya* jika mereka juga cocok dengan aturan dasar patch.

Sadarilah bahwa laporan kepatuhan mencerminkan status patch berdasarkan apa yang ditentukan dalam dasar patch, bukan apa yang Anda tentukan dalam daftar patch `InstallOverrideList`. Dengan kata lain, operasi Pemindaian mengabaikan parameter `InstallOverrideList`. Hal ini untuk memastikan bahwa laporan kepatuhan secara konsisten mencerminkan keadaan patch berdasarkan kebijakan daripada apa yang disetujui untuk operasi patching tertentu. 

**Format URL yang valid**

**catatan**  
Jika file Anda disimpan dalam bucket yang tersedia secara publik, Anda dapat menentukan format URL https atau URL ala jalur Amazon S3. Jika file Anda disimpan dalam bucket privat, Anda harus menentukan URL ala jalur Amazon S3.
+ **Contoh format URL https**:

  ```
  https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```
+ Contoh URL gaya jalur **Amazon S3:**

  ```
  s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
  ```

**Format konten YAMM yang valid**

Format yang Anda gunakan untuk menentukan patch dalam daftar Anda tergantung pada sistem operasi instans Anda. Namun, format yang umum adalah seperti berikut ini:

```
patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}
```

Meskipun Anda dapat memberikan bidang tambahan dalam file YAML Anda, mereka diabaikan selama operasi patch.

Selain itu, kami merekomendasikan untuk memverifikasi bahwa format file YAML Anda valid sebelum menambahkan atau memperbarui daftar di bucket S3 Anda. Untuk informasi lebih lanjut tentang format YAML, lihat [yaml.org](http://www.yaml.org). Untuk pilihan alat validasi, lakukan pencarian web untuk "validator format yaml".
+ Microsoft Windows

**id**  
Bidang **id** wajib diisi. Gunakan untuk menentukan patch menggunakan Microsoft Knowledge Base IDs (misalnya, KB2736693) dan Microsoft Security Bulletin IDs (misalnya, MS17 -023). 

  Bidang lain yang ingin Anda berikan dalam daftar patch untuk Windows bersifat opsional dan hanya digunakan sebagai informasi Anda sendiri. Anda dapat menggunakan bidang tambahan seperti **judul**, **klasifikasi**, **Tingkat kepelikan**, atau yang lainnya untuk memberikan informasi lebih detail tentang patch yang ditentukan.
+ Linux

**id**  
Bidang **id** wajib diisi. Gunakan untuk menentukan patch menggunakan nama paket dan arsitektur. Sebagai contoh: `'dhclient.x86_64'`. Anda dapat menggunakan wildcard dalam id untuk menunjukkan lebih dari satu paket. Sebagai contoh: `'dhcp*'` dan `'dhcp*1.*'`.

**title**  
Bidang **judul** bersifat opsional, tetapi pada sistem Linux bidang tersebut memberikan kemampuan filter tambahan. Jika Anda menggunakan **judul**, sebaiknya berisi informasi versi paket dalam salah satu format berikut:

  YUM/Red Hat Enterprise Linux (RHEL):

  ```
  {name}.{architecture}:{epoch}:{version}-{release}
  ```

  APT

  ```
  {name}.{architecture}:{version}
  ```

  Untuk judul patch Linux, Anda dapat menggunakan satu atau lebih wildcard di posisi apa pun untuk memperluas jumlah kecocokan paket. Sebagai contoh: `'*32:9.8.2-0.*.rc1.57.amzn1'`. 

  Sebagai contoh: 
  + Paket apt versi 1.2.25 saat ini telah diinstal pada instans Anda, tetapi versi 1.2.27 sekarang telah tersedia. 
  + Anda menambahkan apt.amd64 versi 1.2.27 ke daftar patch. Hal ini tergantung pada apt utils.amd64 versi 1.2.27, tapi apt-utils.amd64 versi 1.2.25 ditentukan dalam daftar. 

  Dalam hal ini, apt versi 1.2.27 akan diblokir dari instalasi dan dilaporkan sebagai “Gagal-.” NonCompliant

**Bidang Lainnya**  
Bidang lain yang ingin Anda berikan dalam daftar patch untuk Linux bersifat opsional dan hanya digunakan sebagai informasi Anda sendiri. Anda dapat menggunakan bidang tambahan seperti **klasifikasi**, **tingkat kepelikan**, atau yang lainnya untuk memberikan informasi lebih detail tentang patch yang ditentukan.

**Contoh daftar tambalan**
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```
+ **APT**

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Amazon Linux 2**

  ```
  patches:
      -
          id: 'kernel.x86_64'
      -
          id: 'bind*.x86_64'
          title: '39.11.4-26.P2.amzn2.5.2'
  
          id: 'glibc*'
      -
          id: 'dhclient*'
          title: '*4.2.5-58.amzn2'
      -
          id: 'dhcp*'
          title: '*4.2.5-77.amzn2'
  ```
+ **Red Hat Enterprise Linux (RHEL)**

  ```
  patches:
      -
          id: 'NetworkManager.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'NetworkManager-*.x86_64'
          title: '*1:1.10.2-14.el7_5'
      -
          id: 'audit.x86_64'
          title: '*0:2.8.1-3.el7'
      -
          id: 'dhclient.x86_64'
          title: '*.el7_5.1'
      -
          id: 'dhcp*.x86_64'
          title: '*12:5.2.5-68.el7'
  ```
+ **SUSE Linux Enterprise Server (SLES)**

  ```
  patches:
      -
          id: 'amazon-ssm-agent.x86_64'
      -
          id: 'binutils'
          title: '*0:2.26.1-9.12.1'
      -
          id: 'glibc*.x86_64'
          title: '*2.19*'
      -
          id: 'dhcp*'
          title: '0:4.3.3-9.1'
      -
          id: 'lib*'
  ```
+ **Ubuntu Server **

  ```
  patches:
      -
          id: 'apparmor.amd64'
          title: '2.10.95-0ubuntu2.9'
      -
          id: 'cryptsetup.amd64'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'cryptsetup-bin.*'
          title: '*2:1.6.6-5ubuntu2.1'
      -
          id: 'apt.amd64'
          title: '*1.2.27'
      -
          id: 'apt-utils.amd64'
          title: '*1.2.25'
  ```
+ **Windows**

  ```
  patches:
      -
          id: 'KB4284819'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
      -
          id: 'KB4284833'
      -
          id: 'KB4284835'
          title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
      -
          id: 'KB4284880'
      -
          id: 'KB4338814'
  ```

### Nama parameter: `RebootOption`
<a name="patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption"></a>

**Penggunaan**: Opsional.

**Pilihan**: `RebootIfNeeded` \$1 `NoReboot` 

**Default**: `RebootIfNeeded`

**Awas**  
Opsi default-nya adalah `RebootIfNeeded`. Pastikan untuk memilih opsi yang benar untuk kasus penggunaan Anda. Misalnya, jika instance Anda harus segera reboot untuk menyelesaikan proses konfigurasi, pilih`RebootIfNeeded`. Atau, jika Anda perlu mempertahankan ketersediaan instance hingga waktu reboot yang dijadwalkan, pilih`NoReboot`.

**penting**  
`NoReboot`Opsi ini hanya mencegah restart tingkat sistem operasi. Restart tingkat layanan masih dapat terjadi sebagai bagian dari proses patching. Misalnya, ketika Docker diperbarui, layanan dependen seperti Amazon Elastic Container Service mungkin secara otomatis dimulai ulang bahkan dengan `NoReboot` diaktifkan. Jika Anda memiliki layanan penting yang tidak boleh diganggu, pertimbangkan langkah-langkah tambahan seperti menghapus sementara instance dari layanan atau menjadwalkan penambalan selama jendela pemeliharaan.

**penting**  
Kami tidak menyarankan penggunaan Patch Manager untuk menambal instance cluster di Amazon EMR (sebelumnya disebut Amazon Elastic). MapReduce Secara khusus, jangan pilih `RebootIfNeeded` opsi untuk `RebootOption` parameter. (Opsi ini tersedia di dokumen Perintah SSM untuk ditambal`AWS-RunPatchBaseline`,`AWS-RunPatchBaselineAssociation`, dan`AWS-RunPatchBaselineWithHooks`.)  
Perintah yang mendasari untuk menambal menggunakan Patch Manager penggunaan `yum` dan `dnf` perintah. Oleh karena itu, operasi mengakibatkan ketidakcocokan karena bagaimana paket diinstal. Untuk informasi tentang metode yang disukai untuk memperbarui perangkat lunak di klaster EMR Amazon, lihat [Menggunakan default untuk AMI Amazon EMR di Panduan Manajemen EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) *Amazon*.

RebootIfNeeded  
Saat Anda memilih `RebootIfNeeded` opsi, instance di-boot ulang dalam salah satu kasus berikut:   
+ Patch Managermemasang satu atau lebih tambalan. 

  Patch Managertidak mengevaluasi apakah reboot *diperlukan* oleh tambalan. Sistem di-boot ulang bahkan jika tambalan tidak memerlukan reboot.
+ Patch Managermendeteksi satu atau lebih tambalan dengan status `INSTALLED_PENDING_REBOOT` selama operasi. `Install` 

  `INSTALLED_PENDING_REBOOT`Status dapat berarti bahwa opsi `NoReboot` dipilih saat terakhir kali `Install` operasi dijalankan, atau tambalan dipasang di luar Patch Manager sejak terakhir kali node terkelola di-boot ulang.
Mem-boot ulang instance dalam dua kasus ini memastikan bahwa paket yang diperbarui dikeluarkan dari memori dan menjaga perilaku patching dan reboot tetap konsisten di semua sistem operasi.

NoReboot  
Ketika Anda memilih `NoReboot` opsi, Patch Manager tidak me-reboot sebuah instance bahkan jika itu menginstal patch selama `Install` operasi. Opsi ini berguna jika Anda tahu bahwa instans Anda tidak memerlukan reboot setelah patch diterapkan, atau Anda memiliki aplikasi atau proses yang berjalan pada instans yang seharusnya tidak terganggu oleh reboot operasi patching. Hal ini juga berguna ketika Anda ingin memiliki kendali lebih besar atas waktu reboot instans, seperti dengan menggunakan jendela pemeliharaan.

**File pelacakan instalasi patch**: Untuk melacak instalasi patch, terutama patch yang telah diinstal sejak reboot sistem terakhir kali, Systems Manager mempertahankan file pada instans terkelola.

**penting**  
Jangan menghapus atau memodifikasi file pelacakan. Jika file ini dihapus atau rusak, laporan kepatuhan patch untuk instans tidak akurat. Jika ini terjadi, reboot instans dan jalankan patch operasi Pemindaian untuk memulihkan file tersebut.

file pelacakan ini disimpan di lokasi-lokasi berikut ini pada instans terkelola Anda:
+ Sistem operasi Linux: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Sistem operasi Windows Server:
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

# Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-aws-runpatchbaselinewithhooks"></a>

AWS Systems Manager mendukung`AWS-RunPatchBaselineWithHooks`, dokumen Systems Manager (dokumen SSM) untukPatch Manager, alat di AWS Systems Manager. Dokumen SSM ini melakukan operasi penambalan pada node terkelola untuk pembaruan terkait keamanan dan jenis pembaruan lainnya. 

`AWS-RunPatchBaselineWithHooks` berbeda dari `AWS-RunPatchBaseline` dengan cara berikut:
+ **Dokumen pembungkus** – `AWS-RunPatchBaselineWithHooks` adalah pembungkus untuk `AWS-RunPatchBaseline` dan bergantung pada `AWS-RunPatchBaseline` untuk beberapa operasinya.
+ **`Install`Operasi** — `AWS-RunPatchBaselineWithHooks` mendukung kait siklus hidup yang berjalan pada titik yang ditentukan selama patch node terkelola. Karena instalasi patch kadang-kadang memerlukan node terkelola untuk reboot, operasi patching dibagi menjadi dua peristiwa, dengan total tiga kait yang mendukung fungsionalitas kustom. Kait pertama adalah sebelum operasi `Install with NoReboot`. Kait kedua adalah setelah operasi `Install with NoReboot`. Kait ketiga tersedia setelah reboot dari node terkelola.
+ **Tidak ada support daftar patch kustom** – `AWS-RunPatchBaselineWithHooks` tidak support parameter `InstallOverrideList`.
+ **SSM Agentdukungan** - `AWS-RunPatchBaselineWithHooks` mengharuskan SSM Agent 3.0.502 atau yang lebih baru diinstal pada node yang dikelola untuk menambal.

Saat dokumen dijalankan, ia menggunakan dasar patch yang ditentukan saat ini sebagai "default" untuk suatu jenis sistem operasi jika tidak ada grup patch yang ditentukan. Jika tidak, ia menggunakan dasar patch yang terkait dengan grup patch. Untuk informasi tentang grup patch, lihat [Grup tambalan](patch-manager-patch-groups.md). 

Anda dapat menggunakan `AWS-RunPatchBaselineWithHooks` untuk menerapkan patch untuk sistem operasi dan aplikasi. (Pada Windows Server, support aplikasi dibatasi pada pembaruan untuk aplikasi yang dirilis oleh Microsoft.)

Dokumen ini mendukung Linux dan node Windows Server terkelola. Dokumen ini akan melakukan tindakan yang sesuai untuk setiap platform.

**catatan**  
`AWS-RunPatchBaselineWithHooks`tidak didukung padamacOS.

------
#### [ Linux ]

Pada node yang dikelola Linux, `AWS-RunPatchBaselineWithHooks` dokumen tersebut memanggil modul Python, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node terkelola. Snapshot dasar tambalan ini menggunakan aturan yang ditentukan dan daftar tambalan yang disetujui dan diblokir untuk mendorong manajer paket yang sesuai untuk setiap jenis node: 
+ Amazon Linux 2,Oracle Linux, dan RHEL 7 node terkelola menggunakan YUM. Untuk operasi YUM, Patch Manager membutuhkan `Python 2.6` atau versi yang didukung yang lebih baru (2.6 - 3.12). Amazon Linux 2023 menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi yang didukung dari `Python 2` atau `Python 3` (2.6 - 3.12).
+ RHEL8 node terkelola menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi yang didukung dari `Python 2` atau `Python 3` (2.6 - 3.12). (Tidak ada versi yang diinstal secara default pada RHEL 8. Anda harus menginstal satu atau yang lain secara manual.)
+ Debian Serverdan Ubuntu Server contoh menggunakan APT. Untuk operasi APT, Patch Manager memerlukan versi yang didukung `Python 3` (3.0 - 3.12).

------
#### [ Windows Server ]

Pada node Windows Server terkelola, `AWS-RunPatchBaselineWithHooks` dokumen mengunduh dan memanggil PowerShell modul, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node terkelola. snapshot dasar patch ini berisi daftar patch yang disetujui yang dikumpulkan dengan melakukan kueri dasar patch pada server Windows Server Update Services (WSUS). Daftar ini diteruskan ke API Windows Update, yang mengendalikan pengunduhan dan instalasi patch yang disetujui sesuai kebutuhan. 

------

Setiap snapshot khusus untuk, grup patch Akun AWS, sistem operasi, dan ID snapshot. Snapshot dikirimkan melalui URL Amazon Simple Storage Service (Amazon S3) yang telah ditandatangani sebelumnya, yang kedaluwarsa 24 jam setelah snapshot dibuat. Namun, setelah URL kedaluwarsa, jika Anda ingin menerapkan konten snapshot yang sama ke node terkelola lainnya, Anda dapat membuat URL Amazon S3 yang telah ditetapkan sebelumnya hingga tiga hari setelah snapshot dibuat. Untuk melakukannya, gunakan perintah [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). 

Setelah semua pembaruan yang disetujui dan berlaku telah diinstal, dengan reboot dilakukan seperlunya, informasi kepatuhan tambalan dihasilkan pada node yang dikelola dan dilaporkan kembali kePatch Manager. 

Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaselineWithHooks` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi selengkapnya, lihat [Nama parameter: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).

**penting**  
Meskipun `NoReboot` opsi mencegah restart sistem operasi, itu tidak mencegah restart tingkat layanan yang mungkin terjadi ketika paket tertentu diperbarui. Misalnya, memperbarui paket seperti Docker dapat memicu restart otomatis layanan dependen (seperti layanan orkestrasi kontainer) bahkan ketika ditentukan. `NoReboot`

Untuk informasi tentang melihat data kepatuhan patch, lihat [Tentang kepatuhan patch](compliance-about.md#compliance-monitor-patch).

## Langkah-langkah operasional `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-aws-runpatchbaselinewithhooks-steps"></a>

Saat `AWS-RunPatchBaselineWithHooks` berjalan, langkah-langkah berikut dilakukan:

1. **Pindai** - `Scan` Operasi yang `AWS-RunPatchBaseline` digunakan dijalankan pada node terkelola, dan laporan kepatuhan dibuat dan diunggah. 

1. **Verifikasi status patch lokal** - Script dijalankan untuk menentukan langkah-langkah apa yang akan dilakukan berdasarkan operasi yang dipilih dan hasil `Scan` dari Langkah 1. 

   1. Jika operasi yang dipilih adalah `Scan`, operasi ditandai selesai. Operasi berakhir. 

   1. Jika operasi yang dipilih adalah`Install`, Patch Manager mengevaluasi `Scan` hasil dari Langkah 1 untuk menentukan apa yang akan dijalankan selanjutnya: 

      1. Jika tidak terdeteksi ada patch yang hilang, dan tidak perlu reboot tertunda, operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati. 

      1. Jika tidak terdeteksi ada patch yang hilang, tapi ada reboot tertunda yang diperlukan dan opsi reboot yang dipilih adalah `NoReboot`, operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati. 

      1. Jika tidak, operasi dilanjutkan ke langkah berikutnya.

1. **Operasi kait pra-tambalan** - Dokumen SSM yang telah Anda sediakan untuk hook siklus hidup pertama,`PreInstallHookDocName`, dijalankan pada node terkelola. 

1. **Instal dengan NoReboot** - `Install` Operasi dengan opsi reboot untuk `NoReboot` menggunakan `AWS-RunPatchBaseline` dijalankan pada node yang dikelola, dan laporan kepatuhan dibuat dan diunggah. 

1. **Operasi kait pasca-instal** - Dokumen SSM yang telah Anda sediakan untuk hook siklus hidup kedua,`PostInstallHookDocName`, dijalankan pada node terkelola.

1. **Verifikasi reboot** - Skrip berjalan untuk menentukan apakah reboot diperlukan untuk node terkelola dan langkah-langkah apa yang harus dijalankan:

   1. Jika opsi reboot yang dipilih adalah `NoReboot`, operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati. 

   1. Jika opsi reboot yang dipilih adalah`RebootIfNeeded`, Patch Manager periksa apakah ada reboot tertunda yang diperlukan dari inventaris yang dikumpulkan di Langkah 4. Ini berarti bahwa operasi berlanjut ke Langkah 7 dan node terkelola di-boot ulang dalam salah satu kasus berikut:

      1. Patch Managermemasang satu atau lebih tambalan. (Patch Managertidak mengevaluasi apakah reboot diperlukan oleh tambalan. Sistem di-boot ulang bahkan jika tambalan tidak memerlukan reboot.)

      1. Patch Managermendeteksi satu atau lebih tambalan dengan status `INSTALLED_PENDING_REBOOT` selama operasi Instal. `INSTALLED_PENDING_REBOOT`Status dapat berarti bahwa opsi `NoReboot` dipilih saat terakhir kali operasi Instal dijalankan, atau tambalan dipasang di luar Patch Manager sejak terakhir kali node terkelola di-boot ulang. 

      Jika tidak ada patch yang memenuhi kriteria ini ditemukan, operasi patch node terkelola selesai, dan operasi berlanjut langsung ke langkah terakhir (Langkah 8), yang mencakup hook yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati.

1. **Reboot dan laporkan** - Operasi instalasi dengan opsi reboot `RebootIfNeeded` berjalan pada node terkelola menggunakan`AWS-RunPatchBaseline`, dan laporan kepatuhan dibuat dan diunggah. 

1. **Operasi kait pasca-reboot** - Dokumen SSM yang telah Anda sediakan untuk hook siklus hidup ketiga,`OnExitHookDocName`, dijalankan pada node terkelola. 

Untuk operasi `Scan`, jika Langkah 1 gagal, proses menjalankan dokumen berhenti dan langkah tersebut dilaporkan gagal, meskipun langkah-langkah berikutnya dilaporkan sebagai sukses. 

 Untuk operasi `Install`, jika salah satu langkah `aws:runDocument` gagal selama operasi, langkah-langkah tersebut dilaporkan gagal, dan operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati. Langkah ini dilaporkan gagal, langkah terakhir melaporkan status hasil operasi, dan semua langkah di antaranya dilaporkan sebagai sukses.

## Parameter `AWS-RunPatchBaselineWithHooks`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters"></a>

`AWS-RunPatchBaselineWithHooks` support enam parameter. 

parameter `Operation` diperlukan. 

Parameter `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName`, dan `OnExitHookDocName` bersifat opsional. 

`Snapshot-ID` secara teknis opsional, tetapi kami merekomendasikan Anda untuk menyediakan nilai kustom untuknya ketika Anda menjalankan `AWS-RunPatchBaselineWithHooks` di luar jendela pemeliharaan. Biarkan Patch Manager memberikan nilai secara otomatis ketika dokumen dijalankan sebagai bagian dari operasi jendela pemeliharaan.

**Topics**
+ [Nama parameter: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nama parameter: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nama parameter: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nama parameter: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nama parameter: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)

### Nama parameter: `Operation`
<a name="patch-manager-aws-runpatchbaseline-parameters-operation"></a>

**Penggunaan**: Wajib.

**Opsi**: `Scan` \$1 `Install`. 

Pemindaian  
Ketika Anda memilih `Scan` opsi, sistem menggunakan `AWS-RunPatchBaseline` dokumen untuk menentukan status kepatuhan patch dari node terkelola dan melaporkan informasi ini kembali kePatch Manager. `Scan`tidak meminta pembaruan untuk diinstal atau node yang dikelola untuk di-boot ulang. Sebaliknya, operasi mengidentifikasi di mana pembaruan hilang yang disetujui dan berlaku untuk node. 

Menginstal  
Ketika Anda memilih `Install` opsi, `AWS-RunPatchBaselineWithHooks` mencoba untuk menginstal pembaruan yang disetujui dan berlaku yang hilang dari node terkelola. Informasi kepatuhan patch yang dihasilkan sebagai bagian operasi `Install` tidak mencantumkan pembaruan yang hilang, tetapi mungkin melaporkan pembaruan yang berstatus gagal jika instalasi pembaruan tidak berhasil karena alasan apa pun. Setiap kali pembaruan diinstal pada node terkelola, node di-reboot untuk memastikan pembaruan diinstal dan aktif. (Pengecualian: Jika `RebootOption` parameter disetel ke `NoReboot` dalam `AWS-RunPatchBaselineWithHooks` dokumen, node terkelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihat[Nama parameter: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption).)  
Jika patch yang ditentukan oleh aturan dasar diinstal *sebelum* Patch Manager memperbarui node terkelola, sistem mungkin tidak reboot seperti yang diharapkan. Hal ini dapat terjadi ketika patch diinstal secara manual oleh pengguna atau diinstal secara otomatis oleh program lain, seperti `unattended-upgrades` paket aktifUbuntu Server.

### Nama parameter: `Snapshot ID`
<a name="patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id"></a>

**Penggunaan**: Opsional.

`Snapshot ID`adalah ID unik (GUID) yang digunakan oleh Patch Manager untuk memastikan bahwa satu set node terkelola yang ditambal dalam satu operasi semuanya memiliki set patch yang disetujui yang sama persis. Meskipun parameter didefinisikan sebagai opsional, rekomendasi praktik terbaik kami bergantung pada apakah Anda menjalankan `AWS-RunPatchBaselineWithHooks` atau tidak di jendela pemeliharaan, seperti yang dijelaskan dalam tabel berikut.


**Praktik terbaik `AWS-RunPatchBaselineWithHooks`**  

| Mode | Praktik terbaik | Detail | 
| --- | --- | --- | 
| Menjalankan AWS-RunPatchBaselineWithHooks di dalam jendela pemeliharaan | Jangan berikan ID Snapshot. Patch Managerakan memasoknya untuk Anda. |  Jika Anda menggunakan jendela pemeliharaan untuk menjalankan`AWS-RunPatchBaselineWithHooks`, Anda seharusnya tidak memberikan ID Snapshot yang dibuat sendiri. Dalam skenario ini, Systems Manager menyediakan nilai GUID berdasarkan ID eksekusi jendela pemeliharaan. Hal ini memastikan bahwa digunakan ID yang benar untuk semua pemanggilan `AWS-RunPatchBaselineWithHooks` dalam jendela pemeliharaan tersebut.  Jika Anda menentukan nilai dalam skenario ini, perhatikan bahwa snapshot dari baseline patch mungkin tidak tetap di tempatnya selama lebih dari 3 hari. Setelah itu, snapshot baru akan dihasilkan bahkan jika Anda menentukan ID yang sama setelah snapshot berakhir.   | 
| Menjalankan AWS-RunPatchBaselineWithHooks di luar jendela pemeliharaan | Menghasilkan dan menentukan nilai GUID kustom untuk ID Snapshot.¹ |  Bila Anda tidak menggunakan jendela pemeliharaan untuk menjalankan`AWS-RunPatchBaselineWithHooks`, kami sarankan Anda membuat dan menentukan ID Snapshot unik untuk setiap baseline patch, terutama jika Anda menjalankan `AWS-RunPatchBaselineWithHooks` dokumen pada beberapa node terkelola dalam operasi yang sama. Jika Anda tidak menentukan ID dalam skenario ini, Systems Manager akan menghasilkan ID Snapshot yang berbeda untuk setiap node terkelola tempat perintah dikirim. Hal ini dapat mengakibatkan berbagai set patch yang ditentukan di antara node. Misalnya, katakan bahwa Anda menjalankan `AWS-RunPatchBaselineWithHooks` dokumen secara langsung, alat di Run CommandAWS Systems Manager, dan menargetkan sekelompok 50 node terkelola. Menentukan ID Snapshot kustom menghasilkan pembuatan snapshot dasar tunggal yang digunakan untuk mengevaluasi dan menambal semua node yang dikelola, memastikan bahwa mereka berakhir dalam status konsisten.   | 
|  ¹ Anda dapat menggunakan alat yang mampu menghasilkan GUID untuk menghasilkan nilai untuk parameter ID Snapshot. Misalnya, di PowerShell, Anda dapat menggunakan `New-Guid` cmdlet untuk menghasilkan GUID dalam format. `12345699-9405-4f69-bc5e-9315aEXAMPLE`  | 

### Nama parameter: `RebootOption`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption"></a>

**Penggunaan**: Opsional.

**Pilihan**: `RebootIfNeeded` \$1 `NoReboot` 

**Default**: `RebootIfNeeded`

**Awas**  
Opsi default-nya adalah `RebootIfNeeded`. Pastikan untuk memilih opsi yang benar untuk kasus penggunaan Anda. Misalnya, jika node terkelola Anda harus segera reboot untuk menyelesaikan proses konfigurasi, pilih`RebootIfNeeded`. Atau, jika Anda perlu mempertahankan ketersediaan node terkelola hingga waktu reboot yang dijadwalkan, pilih`NoReboot`.

**penting**  
Kami tidak menyarankan penggunaan Patch Manager untuk menambal instance cluster di Amazon EMR (sebelumnya disebut Amazon Elastic). MapReduce Secara khusus, jangan pilih `RebootIfNeeded` opsi untuk `RebootOption` parameter. (Opsi ini tersedia dalam dokumen Perintah SSM untuk ditambal`AWS-RunPatchBaseline`,`AWS-RunPatchBaselineAssociation`, dan`AWS-RunPatchBaselineWithHooks`.)  
Perintah yang mendasari untuk menambal menggunakan Patch Manager penggunaan `yum` dan `dnf` perintah. Oleh karena itu, operasi mengakibatkan ketidakcocokan karena bagaimana paket diinstal. Untuk informasi tentang metode yang disukai untuk memperbarui perangkat lunak di klaster EMR Amazon, lihat [Menggunakan default untuk AMI Amazon EMR di Panduan Manajemen EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) *Amazon*.

RebootIfNeeded  
Saat Anda memilih `RebootIfNeeded` opsi, node terkelola di-boot ulang dalam salah satu kasus berikut:   
+ Patch Managermemasang satu atau lebih tambalan. 

  Patch Managertidak mengevaluasi apakah reboot *diperlukan* oleh tambalan. Sistem di-boot ulang bahkan jika tambalan tidak memerlukan reboot.
+ Patch Managermendeteksi satu atau lebih tambalan dengan status `INSTALLED_PENDING_REBOOT` selama operasi. `Install` 

  `INSTALLED_PENDING_REBOOT`Status dapat berarti bahwa opsi `NoReboot` dipilih saat terakhir kali `Install` operasi dijalankan, atau tambalan dipasang di luar Patch Manager sejak terakhir kali node terkelola di-boot ulang.
Mem-boot ulang node terkelola dalam dua kasus ini memastikan bahwa paket yang diperbarui dikeluarkan dari memori dan menjaga perilaku patching dan reboot tetap konsisten di semua sistem operasi.

NoReboot  
Ketika Anda memilih `NoReboot` opsi, Patch Manager tidak me-reboot node terkelola bahkan jika itu menginstal tambalan selama `Install` operasi. Opsi ini berguna jika Anda tahu bahwa node terkelola Anda tidak memerlukan reboot setelah tambalan diterapkan, atau Anda memiliki aplikasi atau proses yang berjalan pada node yang seharusnya tidak terganggu oleh reboot operasi patching. Ini juga berguna ketika Anda ingin lebih banyak kontrol atas waktu reboot node terkelola, seperti dengan menggunakan jendela pemeliharaan.  
Jika Anda memilih opsi `NoReboot` dan sebuah patch diinstal, patch diberikan status `InstalledPendingReboot`. Node yang dikelola itu sendiri, bagaimanapun, ditandai sebagai`Non-Compliant`. Setelah reboot terjadi dan `Scan` operasi dijalankan, status node diperbarui ke`Compliant`.

**File pelacakan instalasi patch**: Untuk melacak instalasi patch, terutama patch yang diinstal sejak reboot sistem terakhir, Systems Manager memelihara file pada node terkelola.

**penting**  
Jangan menghapus atau memodifikasi file pelacakan. Jika file ini dihapus atau rusak, laporan kepatuhan patch untuk node terkelola tidak akurat. Jika ini terjadi, reboot node dan jalankan operasi Pindai tambalan untuk memulihkan file.

File pelacakan ini disimpan di lokasi berikut pada node terkelola Anda:
+ Sistem operasi Linux: 
  + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
  + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Sistem operasi Windows Server:
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
  + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`

### Nama parameter: `PreInstallHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname"></a>

**Penggunaan**: Opsional.

**Default**: `AWS-Noop`. 

Nilai untuk disediakan untuk parameter `PreInstallHookDocName` adalah nama atau Amazon Resource Name (ARN) dari dokumen SSM pilihan Anda. Anda dapat memberikan nama dokumen AWS terkelola atau nama atau ARN dari dokumen SSM khusus yang telah Anda buat atau yang telah dibagikan dengan Anda. (Untuk dokumen SSM yang telah dibagikan dengan Anda dari yang berbeda Akun AWS, Anda harus menentukan ARN sumber daya lengkap, seperti`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)

Dokumen SSM yang Anda tentukan dijalankan sebelum `Install` operasi dan melakukan tindakan apa pun yang didukungSSM Agent, seperti skrip shell untuk memeriksa pemeriksaan kesehatan aplikasi sebelum penambalan dilakukan pada node terkelola. (Untuk daftar tindakan, lihat [Referensi plugin dokumen perintah](documents-command-ssm-plugin-reference.md)). Nama dokumen SSM default adalah`AWS-Noop`, yang tidak melakukan operasi apa pun pada node terkelola. 

Untuk informasi tentang membuat dokumen SSM kustom, lihat [Membuat konten dokumen SSM](documents-creating-content.md). 

### Nama parameter: `PostInstallHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname"></a>

**Penggunaan**: Opsional.

**Default**: `AWS-Noop`. 

Nilai untuk disediakan untuk parameter `PostInstallHookDocName` adalah nama atau Amazon Resource Name (ARN) dari dokumen SSM pilihan Anda. Anda dapat memberikan nama dokumen AWS terkelola atau nama atau ARN dari dokumen SSM khusus yang telah Anda buat atau yang telah dibagikan dengan Anda. (Untuk dokumen SSM yang telah dibagikan dengan Anda dari yang berbeda Akun AWS, Anda harus menentukan ARN sumber daya lengkap, seperti`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)

Dokumen SSM yang Anda tentukan dijalankan setelah `Install with NoReboot` operasi dan melakukan tindakan apa pun yang didukung olehSSM Agent, seperti skrip shell untuk menginstal pembaruan pihak ketiga sebelum reboot. (Untuk daftar tindakan, lihat [Referensi plugin dokumen perintah](documents-command-ssm-plugin-reference.md)). Nama dokumen SSM default adalah`AWS-Noop`, yang tidak melakukan operasi apa pun pada node terkelola. 

Untuk informasi tentang membuat dokumen SSM kustom, lihat [Membuat konten dokumen SSM](documents-creating-content.md). 

### Nama parameter: `OnExitHookDocName`
<a name="patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname"></a>

**Penggunaan**: Opsional.

**Default**: `AWS-Noop`. 

Nilai untuk disediakan untuk parameter `OnExitHookDocName` adalah nama atau Amazon Resource Name (ARN) dari dokumen SSM pilihan Anda. Anda dapat memberikan nama dokumen AWS terkelola atau nama atau ARN dari dokumen SSM khusus yang telah Anda buat atau yang telah dibagikan dengan Anda. (Untuk dokumen SSM yang telah dibagikan dengan Anda dari Akun AWS berbeda, Anda harus menentukan ARN sumber daya lengkap, seperti `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)

Dokumen SSM yang Anda tentukan dijalankan setelah operasi reboot node terkelola dan melakukan tindakan apa pun yang didukungSSM Agent, seperti skrip shell untuk memverifikasi kesehatan node setelah operasi patching selesai. (Untuk daftar tindakan, lihat [Referensi plugin dokumen perintah](documents-command-ssm-plugin-reference.md)). Nama dokumen SSM default adalah`AWS-Noop`, yang tidak melakukan operasi apa pun pada node terkelola. 

Untuk informasi tentang membuat dokumen SSM kustom, lihat [Membuat konten dokumen SSM](documents-creating-content.md). 

# Contoh skenario untuk menggunakan InstallOverrideList parameter di `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation`
<a name="patch-manager-override-lists"></a>

Anda dapat menggunakan `InstallOverrideList` parameter saat Anda ingin mengganti tambalan yang ditentukan oleh baseline patch default saat iniPatch Manager, alat di. AWS Systems Manager Topik ini memberikan contoh yang menunjukkan cara menggunakan parameter ini untuk mencapai hal berikut:
+ Menerapkan set patch yang berbeda ke kelompok target node terkelola.
+ Menerapkan set patch ini pada frekuensi yang berbeda.
+ Menggunakan dasar patch yang sama untuk kedua operasi.

Katakanlah Anda ingin menginstal dua kategori tambalan yang berbeda di node terkelola Amazon Linux 2 Anda. Anda ingin menginstal patch ini pada jadwal yang berbeda menggunakan jendela pemeliharaan. Anda ingin satu jendela pemeliharaan berjalan setiap minggu dan menginstal semua patch `Security`. Anda ingin jendela pemeliharaan lain untuk berjalan sebulan sekali dan menginstal semua patch yang tersedia, atau kategori patch selain `Security`. 

Namun, hanya satu dasar patch yang dapat didefinisikan sebagai default untuk sistem operasi pada satu waktu. Persyaratan ini membantu menghindari situasi ketika satu dasar patch menyetujui sebuah patch sedangkan yang lain memblokirnya, yang dapat menyebabkan masalah antara versi yang bertentangan.

Dengan strategi berikut ini, Anda menggunakan parameter `InstallOverrideList` untuk menerapkan jenis patch yang berbeda ke grup target, pada jadwal yang berbeda, sambil tetap menggunakan dasar patch yang sama:

1. Dalam dasar patch default, pastikan bahwa hanya pembaruan `Security` yang ditentukan.

1. Buat jendela pemeliharaan yang menjalankan `AWS-RunPatchBaseline` atau `AWS-RunPatchBaselineAssociation` setiap minggu. Jangan tentukan daftar override.

1. Buat daftar override patch dari semua jenis yang ingin Anda terapkan setiap bulan dan simpan di bucket Amazon Simple Storage Service (Amazon S3). 

1. Buat jendela pemeliharaan kedua yang berjalan sebulan sekali. Namun, untuk Run Command tugas yang Anda daftarkan untuk jendela pemeliharaan ini, tentukan lokasi daftar penggantian Anda.

Hasilnya: Hanya patch `Security`, seperti yang didefinisikan dalam dasar patch default Anda, yang diinstal setiap minggu. Semua patch yang tersedia, atau subset patch lain yang Anda tentukan, diinstal setiap bulan.

**catatan**  
Saat Anda menambal node yang hanya menggunakan IPv6, pastikan URL yang disediakan dapat dijangkau dari node. Jika opsi SSM Agent konfigurasi `UseDualStackEndpoint` disetel ke`true`, maka klien S3 dualstack digunakan saat URL S3 disediakan. Lihat [Tutorial: Menambal server di IPv6 satu-satunya lingkungan](patch-manager-server-patching-iPv6-tutorial.md) untuk informasi selengkapnya tentang mengonfigurasi agen untuk menggunakan dualstack.

Untuk informasi selengkapnya dan daftar sampel, lihat[Nama parameter: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).

# Menggunakan BaselineOverride parameter
<a name="patch-manager-baselineoverride-parameter"></a>

Anda dapat menentukan preferensi patching saat runtime menggunakan fitur baseline override di, alat diPatch Manager. AWS Systems Manager Lakukan ini dengan menentukan bucket Amazon Simple Storage Service (Amazon S3) yang berisi objek JSON dengan daftar dasar patch. Operasi patching menggunakan baseline yang disediakan dalam objek JSON yang cocok dengan sistem operasi host bukannya menerapkan aturan dari dasar patch default.

**penting**  
Nama `BaselineOverride` file tidak dapat berisi karakter berikut: backtick (`), kutipan tunggal ('), kutipan ganda (“), dan tanda dolar (\$1).

Kecuali jika operasi penambalan menggunakan kebijakan tambalan, penggunaan `BaselineOverride` parameter tidak menimpa kepatuhan patch dari baseline yang disediakan dalam parameter. Hasil output dicatat dalam log Stdout dariRun Command, alat di. AWS Systems Manager Hasil hanya mencetak paket yang ditandai sebagai `NON_COMPLIANT`. Ini berarti paket ditandai sebagai `Missing`, `Failed`, `InstalledRejected`, atau `InstalledPendingReboot`.

Namun, ketika operasi tambalan menggunakan kebijakan tambalan, sistem meneruskan parameter override dari bucket S3 terkait, dan nilai kepatuhan diperbarui untuk node terkelola. Untuk informasi selengkapnya tentang perilaku kebijakan tambalan, lihat[Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).

**catatan**  
Saat Anda menambal node yang hanya menggunakan IPv6, pastikan URL yang disediakan dapat dijangkau dari node. Jika opsi SSM Agent konfigurasi `UseDualStackEndpoint` disetel ke`true`, maka klien S3 dualstack digunakan saat URL S3 disediakan. Lihat [Tutorial: Menambal server di IPv6 satu-satunya lingkungan](patch-manager-server-patching-iPv6-tutorial.md) untuk informasi lebih lanjut tentang mengonfigurasi agen untuk menggunakan dualstack.

## Menggunakan override dasar patch dengan parameter Snapshot Id atau Install Override List
<a name="patch-manager-baselineoverride-parameter-other-parameters"></a>

Ada dua kasus ketika override dasar patch memiliki perilaku yang patut diperhatikan.

**Menggunakan baseline override dan Snapshot Id pada saat yang sama**  
Id Snapshot memastikan bahwa semua node yang dikelola dalam perintah patching tertentu semuanya menerapkan hal yang sama. Misalnya, jika Anda menambal 1.000 node sekaligus, tambalan akan sama.

Saat menggunakan Snapshot Id dan override dasar patch, Snapshot Id lebih diutamakan dari override dasar patch. Aturan baseline override masih akan digunakan, tetapi hanya akan dievaluasi sekali. Dalam contoh sebelumnya, tambalan di 1.000 node terkelola Anda akan tetap selalu sama. Jika, di tengah operasi patching, Anda mengubah file JSON di bucket S3 yang direferensikan menjadi sesuatu yang berbeda, patch yang diterapkan akan tetap sama. Hal ini karena Snapshot Id telah disediakan.

**Menggunakan baseline override dan Install Override List pada saat yang sama**  
Anda tidak dapat menggunakan dua parameter ini pada saat yang sama. Dokumen patching gagal jika kedua parameter disediakan, dan tidak melakukan pemindaian atau penginstalan apa pun pada node terkelola.

## Contoh kode
<a name="patch-manager-baselineoverride-parameter-code"></a>

Contoh kode berikut ini untuk Python menunjukkan cara menghasilkan override dasar patch.

```
import boto3
import json

ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']

baseline_overrides = []
for baseline_id in baseline_ids_to_export:
    baseline_overrides.append(ssm.get_patch_baseline(
        BaselineId=baseline_id
    ))

json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```

Ini menghasilkan override dasar patch seperti berikut ini.

```
[
    {
        "ApprovalRules": {
            "PatchRules": [
                {
                    "ApproveAfterDays": 0, 
                    "ComplianceLevel": "UNSPECIFIED", 
                    "EnableNonSecurity": false, 
                    "PatchFilterGroup": {
                        "PatchFilters": [
                            {
                                "Key": "PRODUCT", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "CLASSIFICATION", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "SEVERITY", 
                                "Values": [
                                    "*"
                                ]
                            }
                        ]
                    }
                }
            ]
        }, 
        "ApprovedPatches": [], 
        "ApprovedPatchesComplianceLevel": "UNSPECIFIED", 
        "ApprovedPatchesEnableNonSecurity": false, 
        "GlobalFilters": {
            "PatchFilters": []
        }, 
        "OperatingSystem": "AMAZON_LINUX_2", 
        "RejectedPatches": [], 
        "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", 
        "Sources": []
    }, 
    {
        "ApprovalRules": {
            "PatchRules": [
                {
                    "ApproveUntilDate": "2021-01-06", 
                    "ComplianceLevel": "UNSPECIFIED", 
                    "EnableNonSecurity": true, 
                    "PatchFilterGroup": {
                        "PatchFilters": [
                            {
                                "Key": "PRODUCT", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "CLASSIFICATION", 
                                "Values": [
                                    "*"
                                ]
                            }, 
                            {
                                "Key": "SEVERITY", 
                                "Values": [
                                    "*"
                                ]
                            }
                        ]
                    }
                }
            ]
        }, 
        "ApprovedPatches": [
            "open-ssl*"
        ], 
        "ApprovedPatchesComplianceLevel": "UNSPECIFIED", 
        "ApprovedPatchesEnableNonSecurity": false, 
        "GlobalFilters": {
            "PatchFilters": []
        }, 
        "OperatingSystem": "SUSE", 
        "RejectedPatches": [
            "python*"
        ], 
        "RejectedPatchesAction": "ALLOW_AS_DEPENDENCY", 
        "Sources": []
    }
]
```

# Garis dasar patch
<a name="patch-manager-patch-baselines"></a>

Topik di bagian ini memberikan informasi tentang cara kerja baseline patch Patch Manager, alat di AWS Systems Manager, ketika Anda menjalankan `Scan` atau `Install` operasi pada node terkelola Anda.

**Topics**
+ [Garis dasar patch yang telah ditentukan dan kustom](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md)
+ [Grup tambalan](patch-manager-patch-groups.md)
+ [Aplikasi patching yang dirilis oleh Microsoft pada Windows Server](patch-manager-patching-windows-applications.md)

# Garis dasar patch yang telah ditentukan dan kustom
<a name="patch-manager-predefined-and-custom-patch-baselines"></a>

Patch Manager, alat di AWS Systems Manager, menyediakan garis dasar patch yang telah ditentukan untuk masing-masing sistem operasi yang didukung oleh. Patch Manager Anda dapat menggunakan baseline ini karena mereka saat ini telah dikonfigurasi (Anda tidak dapat menyesuaikannya) atau Anda dapat membuat dasar patch kustom Anda sendiri. Dasar patch kustom memungkinkan Anda untuk memiliki kendali yang lebih besar atas patch yang disetujui atau ditolak untuk lingkungan Anda. Selain itu, baseline yang telah ditetapkan akan menetapkan tingkat kepatuhan `Unspecified` ke semua patch yang diinstal menggunakan baseline tersebut. Agar nilai kepatuhan ditetapkan, Anda dapat membuat salinan dari baseline yang telah ditetapkan dan menentukan nilai kepatuhan yang ingin Anda tetapkan ke patch. Untuk informasi selengkapnya, lihat [Garis dasar kustom](#patch-manager-baselines-custom) dan [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md).

**catatan**  
Informasi dalam topik ini berlaku tidak peduli metode atau jenis konfigurasi yang Anda gunakan untuk operasi penambalan Anda:  
Kebijakan tambalan yang dikonfigurasi di Quick Setup
Opsi Manajemen Host yang dikonfigurasi di Quick Setup
Jendela pemeliharaan untuk menjalankan tambalan `Scan` atau `Install` tugas
**Patch sesuai permintaan sekarang beroperasi**

**Topics**
+ [Garis dasar yang telah ditentukan](#patch-manager-baselines-pre-defined)
+ [Garis dasar kustom](#patch-manager-baselines-custom)

## Garis dasar yang telah ditentukan
<a name="patch-manager-baselines-pre-defined"></a>

Tabel berikut menjelaskan garis dasar patch yang telah ditentukan yang disediakan. Patch Manager

Untuk informasi tentang versi mana dari masing-masing sistem operasi yang Patch Manager didukung, lihat[Prasyarat Patch Manager](patch-manager-prerequisites.md).


****  

| Nama | Sistem operasi yang didukung | Detail | 
| --- | --- | --- | 
|  `AWS-AlmaLinuxDefaultPatchBaseline`  |  AlmaLinux  |  Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan yang memiliki tingkat kepelikan "Kritis" atau "Penting". Juga menyetujui semua tambalan yang diklasifikasikan sebagai “Bugfix”. Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.¹  | 
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan yang memiliki tingkat kepelikan "Kritis" atau "Penting". Juga menyetujui semua tambalan dengan klasifikasi “Bugfix”. Patch disetujui secara otomatis 7 hari setelah rilis.¹ | 
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 |  Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan yang memiliki tingkat kepelikan "Kritis" atau "Penting". Patch disetujui secara otomatis tujuh hari setelah rilis. Juga menyetujui semua patch dengan klasifikasi "Bugfix" tujuh hari setelah rilis.  | 
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Menyetujui semua pembaruan 7 hari setelah tersedia, termasuk pembaruan non-keamanan. | 
| AWS-DebianDefaultPatchBaseline | Debian Server | Segera menyetujui semua patch terkait keamanan sistem operasi yang memiliki prioritas "Wajib", "Penting", "Standar", "Opsional", atau "Ekstra." Tidak perlu menunggu sebelum persetujuan karena tanggal rilis yang andal tidak tersedia di repositori. | 
| AWS-MacOSDefaultPatchBaseline | macOS | Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan". Juga menyetujui semua paket dengan pembaruan saat ini. | 
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan yang memiliki tingkat kepelikan "Penting" atau "Sedang". Juga menyetujui semua tambalan yang diklasifikasikan sebagai “Bugfix” 7 hari setelah rilis. Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.¹ | 
|  `AWS-RedHatDefaultPatchBaseline`  |  Red Hat Enterprise Linux (RHEL)   |  Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan yang memiliki tingkat kepelikan "Kritis" atau "Penting". Juga menyetujui semua tambalan yang diklasifikasikan sebagai “Bugfix”. Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.¹  | 
|  `AWS-RockyLinuxDefaultPatchBaseline`  |  Rocky Linux  |  Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan yang memiliki tingkat kepelikan "Kritis" atau "Penting". Juga menyetujui semua tambalan yang diklasifikasikan sebagai “Bugfix”. Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.¹  | 
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Menyetujui semua patch sistem operasi yang diklasifikasikan sebagai "Keamanan" dan dengan kepelikan "Kritis" atau "Penting". Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.¹ | 
|  `AWS-UbuntuDefaultPatchBaseline`  |  Ubuntu Server  |  Segera menyetujui semua patch terkait keamanan sistem operasi yang memiliki prioritas "Wajib", "Penting", "Standar", "Opsional", atau "Ekstra." Tidak perlu menunggu sebelum persetujuan karena tanggal rilis yang andal tidak tersedia di repositori.  | 
| AWS-DefaultPatchBaseline |  Windows Server  |  Menyetujui semua tambalan sistem Windows Server operasi yang diklasifikasikan sebagai "" atau CriticalUpdates "SecurityUpdates" dan yang memiliki tingkat keparahan MSRC “Kritis” atau “Penting”. Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.²  | 
| AWS-WindowsPredefinedPatchBaseline-OS |  Windows Server  |  Menyetujui semua tambalan sistem Windows Server operasi yang diklasifikasikan sebagai "" atau CriticalUpdates "SecurityUpdates" dan yang memiliki tingkat keparahan MSRC “Kritis” atau “Penting”. Patch disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.²  | 
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Untuk sistem Windows Server operasi, setujui semua tambalan yang diklasifikasikan sebagai "" atau "CriticalUpdatesSecurityUpdates" dan yang memiliki tingkat keparahan MSRC “Kritis” atau “Penting”. Untuk aplikasi yang dirilis oleh Microsoft, menyetujui semua patch. Patch untuk OS dan aplikasi disetujui secara otomatis 7 hari setelah dirilis atau diperbarui.² | 

¹ Untuk Amazon Linux 2, penantian 7 hari sebelum patch disetujui secara otomatis dihitung dari `Updated Date` nilai masuk`updateinfo.xml`, bukan nilai. `Release Date` Berbagai faktor dapat mempengaruhi `Updated Date` nilai. Sistem operasi lain menangani tanggal rilis dan pembaruan secara berbeda. Untuk informasi yang membantu Anda menghindari hasil yang tidak terduga dengan penundaan persetujuan otomatis, lihat. [Bagaimana tanggal rilis paket dan tanggal pembaruan dihitung](patch-manager-release-dates.md)

² UntukWindows Server, baseline default mencakup penundaan persetujuan otomatis 7 hari. Untuk menginstal patch dalam 7 hari setelah rilis, Anda harus membuat baseline kustom.

## Garis dasar kustom
<a name="patch-manager-baselines-custom"></a>

Gunakan informasi berikut untuk membantu Anda membuat baseline patch kustom untuk memenuhi tujuan patching Anda.

**Topics**
+ [Menggunakan persetujuan otomatis di baseline kustom](#baselines-auto-approvals)
+ [Informasi tambahan untuk membuat baseline patch](#baseline-additional-info)

### Menggunakan persetujuan otomatis di baseline kustom
<a name="baselines-auto-approvals"></a>

Jika Anda membuat dasar patch Anda sendiri, Anda dapat memilih patch mana yang akan disetujui secara otomatis dengan menggunakan kategori berikut.
+ **Sistem operasi**: Versi yang didukung dariWindows Server, Amazon LinuxUbuntu Server, dan sebagainya.
+ **Nama produk** (untuk sistem operasi): Misalnya, RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, 2012 R2, dan seterusnya. Windows Server
+ **Nama produk** (untuk aplikasi yang dirilis oleh Microsoft Windows Server hanya): Misalnya, Word 2016, BizTalk Server, dan sebagainya.
+ **Klasifikasi**: Misalnya, Pembaruan kritis, Pembaruan keamanan, dan sebagainya.
+ **Keparahan**: Misalnya, Kritis, Penting, dan sebagainya.

Untuk setiap aturan persetujuan yang Anda buat, Anda dapat memilih untuk menentukan penundaan persetujuan otomatis atau menentukan tanggal cutoff persetujuan patch. 

**catatan**  
Karena tidak mungkin menentukan tanggal rilis paket pembaruan secara andalUbuntu Server, opsi persetujuan otomatis tidak didukung untuk sistem operasi ini.

Penundaan persetujuan otomatis adalah jumlah hari untuk menunggu setelah tambalan dirilis atau terakhir diperbarui, sebelum tambalan secara otomatis disetujui untuk ditambal. Misalnya, jika Anda membuat aturan menggunakan `CriticalUpdates` klasifikasi dan mengonfigurasinya selama 7 hari penundaan persetujuan otomatis, maka patch kritis baru yang dirilis pada 7 Juli secara otomatis disetujui pada 14 Juli.

Jika repositori Linux tidak memberikan informasi tanggal rilis untuk paket, Patch Manager gunakan waktu pembuatan paket sebagai tanggal untuk spesifikasi tanggal persetujuan otomatis untuk Amazon Linux 2, Amazon Linux 2023, dan (). Red Hat Enterprise Linux RHEL Jika waktu pembuatan paket tidak dapat ditentukan, Patch Manager gunakan tanggal default 1 Januari 1970. Ini menghasilkan Patch Manager melewati spesifikasi tanggal persetujuan otomatis apa pun di garis dasar tambalan yang dikonfigurasi untuk menyetujui tambalan untuk tanggal apa pun setelah 1 Januari 1970.

Saat Anda menentukan tanggal batas persetujuan otomatis, Patch Manager secara otomatis menerapkan semua tambalan yang dirilis atau terakhir diperbarui pada atau sebelum tanggal tersebut. Misalnya, jika Anda menentukan 7 Juli 2023 sebagai tanggal cutoff, tidak ada tambalan yang dirilis atau terakhir diperbarui pada atau setelah 8 Juli 2023 yang diinstal secara otomatis.

Saat membuat baseline patch kustom, Anda dapat menentukan tingkat keparahan kepatuhan untuk tambalan yang disetujui oleh baseline patch tersebut, seperti atau. `Critical` `High` Jika status tambalan dari tambalan yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan keseluruhan baseline patch yang dilaporkan adalah tingkat keparahan yang Anda tentukan.

### Informasi tambahan untuk membuat baseline patch
<a name="baseline-additional-info"></a>

Ingatlah hal-hal berikut ini saat Anda membuat dasar patch:
+ Patch Managermenyediakan satu baseline patch yang telah ditentukan untuk setiap sistem operasi yang didukung. Dasar patch yang telah ditetapkan ini digunakan sebagai dasar patch default untuk setiap jenis sistem operasi kecuali Anda membuat dasar patch Anda sendiri dan menunjuknya sebagai default untuk jenis sistem operasi yang sesuai. 
**catatan**  
Untuk Windows Server, disediakan tiga dasar patch yang telah ditetapkan. Garis dasar patch `AWS-DefaultPatchBaseline` dan hanya `AWS-WindowsPredefinedPatchBaseline-OS` mendukung pembaruan sistem operasi pada sistem operasi Windows itu sendiri. `AWS-DefaultPatchBaseline`digunakan sebagai baseline patch default untuk node Windows Server terkelola kecuali Anda menentukan baseline patch yang berbeda. Pengaturan konfigurasi di dua dasar patch ini sama. Yang lebih baru dari keduanya, `AWS-WindowsPredefinedPatchBaseline-OS`, dibuat untuk membedakannya dari dasar patch ketiga yang telah ditetapkan untuk Windows Server. Dasar patch tersebut, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, dapat digunakan untuk menerapkan patch ke ke sistem operasi Windows Server dan aplikasi yang didukung yang dirilis oleh Microsoft.
+ Secara default, Windows Server 2019 dan Windows Server 2022 menghapus pembaruan yang digantikan oleh 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 patch baru tidak diinstal saat operasi patching berjalan. Untuk informasi selengkapnya tentang aturan Windows Server penambalan, lihat Windows Server tab di[Cara pemilihan patch keamanan](patch-manager-selecting-patches.md).

  Ini berarti bahwa node terkelola sesuai dalam hal operasi Systems Manager, meskipun patch kritis dari bulan sebelumnya mungkin tidak diinstal. Skenario yang sama ini dapat terjadi saat menggunakan `ApproveAfterDays` parameter. Karena perilaku patch yang digantikan Microsoft, dimungkinkan untuk menetapkan angka (umumnya lebih besar dari 30 hari) sehingga tambalan untuk Windows Server tidak pernah diinstal jika patch terbaru yang tersedia dari Microsoft dirilis sebelum jumlah hari telah berlalu. `ApproveAfterDays` 
+ Windows ServerHanya saja, patch pembaruan keamanan yang tersedia yang tidak disetujui oleh baseline patch dapat memiliki nilai kepatuhan `Compliant` atau`Non-Compliant`, seperti yang didefinisikan dalam baseline patch kustom. 

  Saat Anda membuat atau memperbarui baseline patch, Anda memilih status yang ingin Anda tetapkan ke patch keamanan yang tersedia tetapi tidak disetujui karena tidak memenuhi kriteria instalasi yang ditentukan dalam baseline patch. Misalnya, patch keamanan yang mungkin ingin Anda instal dapat dilewati jika Anda telah menentukan jangka waktu yang lama untuk menunggu setelah patch dirilis sebelum instalasi. Jika pembaruan pada tambalan dirilis selama masa tunggu yang Anda tentukan, masa tunggu untuk menginstal tambalan dimulai lagi. Jika masa tunggu terlalu lama, beberapa versi patch dapat dirilis tetapi tidak pernah diinstal.

  Menggunakan konsol untuk membuat atau memperbarui garis dasar tambalan, Anda menentukan opsi ini di bidang **Status kepatuhan pembaruan keamanan yang tersedia**. Menggunakan AWS CLI untuk menjalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)perintah [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)or, Anda menentukan opsi ini dalam `available-security-updates-compliance-status` parameter. 
+ Untuk server lokal dan mesin virtual (VMs), Patch Manager mencoba menggunakan baseline patch default kustom Anda. Jika tidak tersedia dasar patch default kustom, sistem menggunakan dasar patch yang telah ditetapkan untuk sistem operasi yang sesuai.
+ Jika sebuah patch terdaftar sebagai disetujui dan ditolak dalam dasar patch yang sama, patch ditolak.
+ Node terkelola hanya dapat memiliki satu baseline patch yang ditentukan untuknya.
+ Format nama paket yang dapat Anda tambahkan ke daftar patch yang disetujui dan patch yang ditolak untuk dasar patch tergantung pada jenis sistem operasi yang Anda patching.

  Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
+ Jika Anda menggunakan [konfigurasi kebijakan tambalan](patch-manager-policies.md)Quick Setup, pembaruan yang Anda buat ke baseline patch kustom disinkronkan dengan Quick Setup satu jam sekali. 

  Jika baseline patch kustom yang direferensikan dalam kebijakan tambalan dihapus, spanduk akan ditampilkan di halaman **Detail Quick Setup konfigurasi** untuk kebijakan tambalan Anda. Spanduk memberi tahu Anda bahwa kebijakan tambalan mereferensikan baseline tambalan yang tidak ada lagi, dan operasi penambalan berikutnya akan gagal. Dalam hal ini, kembali ke halaman Quick Setup **Konfigurasi**, pilih Patch Manager konfigurasi, dan pilih **Tindakan**, **Edit konfigurasi**. Nama dasar patch yang dihapus disorot, dan Anda harus memilih baseline patch baru untuk sistem operasi yang terpengaruh.
+ Saat Anda membuat aturan persetujuan dengan beberapa `Classification` dan `Severity` nilai, tambalan disetujui berdasarkan atribut yang tersedia. Paket dengan keduanya `Classification` dan `Severity` atribut akan cocok dengan nilai dasar yang dipilih untuk kedua bidang. Paket dengan `Classification` atribut hanya dicocokkan dengan nilai dasar `Classification` yang dipilih. Persyaratan keparahan dalam aturan yang sama diabaikan untuk paket yang tidak memiliki `Severity` atribut. 

Untuk informasi tentang membuat dasar patch, lihat [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md) dan [Tutorial: Menambal lingkungan server menggunakan AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).

# Format nama paket untuk daftar patch yang disetujui dan ditolak
<a name="patch-manager-approved-rejected-package-name-formats"></a>

Format nama paket yang dapat Anda tambahkan ke daftar patch yang disetujui dan patch yang ditolak tergantung pada jenis sistem operasi yang Anda patching.

## Format nama paket untuk sistem operasi Linux
<a name="patch-manager-approved-rejected-package-name-formats-linux"></a>

Format yang dapat Anda tentukan untuk patch yang disetujui dan ditolak di dasar patch Anda bervariasi berdasarkan jenis Linux. Secara lebih spesifik, format yang didukung bergantung pada pengelola paket yang digunakan oleh jenis sistem operasi Linux.

**Topics**
+ [Amazon Linux 2, Amazon Linux 2023,Oracle Linux, dan Red Hat Enterprise Linux () RHEL](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server dan Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)

### Amazon Linux 2, Amazon Linux 2023,Oracle Linux, dan Red Hat Enterprise Linux () RHEL
<a name="patch-manager-approved-rejected-package-name-formats-standard"></a>

**Package manager**: YUM, kecuali Amazon Linux 2023, dan RHEL 8, yang menggunakan DNF sebagai manajer paket.

**Patch yang disetujui**: Untuk patch yang disetujui, Anda dapat menentukan salah satu dari berikut:
+ Bugzilla IDs, dalam format `1234567` (Sistem memproses string hanya nomor sebagai Bugzilla.) IDs
+ CVE IDs, dalam format `CVE-2018-1234567`
+ Penasihat IDs, dalam format seperti dan `RHSA-2017:0864` `ALAS-2018-123`
+ Nama Package yang dibangun menggunakan satu atau lebih komponen yang tersedia untuk penamaan paket. Untuk mengilustrasikan, untuk paket bernama`dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, komponennya adalah sebagai berikut: 
  + `name`: `dbus`
  + `architecture`: `x86_64`
  + `epoch`: `1`
  + `version`: `1.12.28`
  + `release`: `1.amzn2023.0.1`

  Nama Package dengan konstruksi berikut didukung:
  + `name`
  + `name.arch`
  + `name-version`
  + `name-version-release`
  + `name-version-release.arch`
  + `version`
  + `version-release`
  + `epoch:version-release`
  + `name-epoch:version-release`
  + `name-epoch:version-release.arch`
  + `epoch:name-version-release.arch`
  + `name.arch:epoch:version-release`

  Beberapa contoh:
  + `dbus.x86_64`
  + `dbus-1.12.28`
  + `dbus-1.12.28-1.amzn2023.0.1`
  + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Kami juga mendukung komponen nama paket dengan kartu liar tunggal dalam format di atas, seperti berikut ini:
  + `dbus*` 
  + `dbus-1.12.2*`
  + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`

**Patch yang ditolak**: Untuk patch yang ditolak, Anda dapat menentukan salah satu dari berikut:
+ Nama Package yang dibangun menggunakan satu atau lebih komponen yang tersedia untuk penamaan paket. Untuk mengilustrasikan, untuk paket bernama`dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, komponennya adalah sebagai berikut: 
  + `name`: `dbus`
  + `architecture`; `x86_64`
  + `epoch`: `1`
  + `version`: `1.12.28`
  + `release`: `1.amzn2023.0.1`

  Nama Package dengan konstruksi berikut didukung:
  + `name`
  + `name.arch`
  + `name-version`
  + `name-version-release`
  + `name-version-release.arch`
  + `version`
  + `version-release`
  + `epoch:version-release`
  + `name-epoch:version-release`
  + `name-epoch:version-release.arch`
  + `epoch:name-version-release.arch`
  + `name.arch:epoch:version-release`

  Beberapa contoh:
  + `dbus.x86_64`
  + `dbus-1.12.28`
  + `dbus-1.12.28-1.amzn2023.0.1`
  + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` 
+ Kami juga mendukung komponen nama paket dengan kartu liar tunggal dalam format di atas, seperti berikut ini:
  + `dbus*` 
  + `dbus-1.12.2*`
  + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`

### Debian Server dan Ubuntu Server
<a name="patch-manager-approved-rejected-package-name-formats-ubuntu"></a>

**Pengelola paket**: APT

**Patch yang disetujui** dan **patch yang ditolak**: Untuk patch yang disetujui dan ditolak, tentukan hal berikut:
+ Nama paket, dalam format `ExamplePkg33`
**catatan**  
Untuk Debian Server daftar, dan Ubuntu Server daftar, jangan sertakan elemen seperti arsitektur atau versi. Sebagai contoh, Anda menentukan nama paket `ExamplePkg33` untuk menyertakan semua hal berikut dalam daftar patch:  
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`

### SUSE Linux Enterprise Server (SLES)
<a name="patch-manager-approved-rejected-package-name-formats-sles"></a>

**Pengelola paket**: Zypper

**Patch yang disetujui** dan **patch yang ditolak**: Untuk daftar patch yang disetujui dan ditolak, Anda dapat menentukan salah satu hal berikut:
+ Nama paket lengkap, dalam format seperti:
  + `SUSE-SLE-Example-Package-15-2023-123`
  + `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Nama-paket dengan satu wildcard, seperti:
  + `SUSE-SLE-Example-Package-15-2023-*`
  + `example-pkg-2023.15.4-46.17.1.*.rpm`

## Format nama paket untuk macOS
<a name="patch-manager-approved-rejected-package-name-formats-macos"></a>

**Pengelola paket yang didukung**: softwareupdate, installer, Brew, Brew Cask

**Patch yang disetujui** dan **patch yang ditolak**: Untuk daftar patch yang disetujui dan ditolak, Anda menentukan nama paket lengkap, dalam format seperti:
+ `XProtectPlistConfigData`
+ `MRTConfigData`

Wildcard tidak didukung dalam daftar patch yang disetujui dan ditolak untuk macOS.

## Format nama paket untuk sistem operasi Windows
<a name="patch-manager-approved-rejected-package-name-formats-windows"></a>

Untuk sistem operasi Windows, tentukan patch menggunakan Microsoft Knowledge Base IDs dan Microsoft Security Bulletin IDs; misalnya:

```
KB2032276,KB2124261,MS10-048
```

# Grup tambalan
<a name="patch-manager-patch-groups"></a>

**catatan**  
Grup tambalan tidak digunakan dalam operasi penambalan yang didasarkan pada *kebijakan tambalan*. Untuk informasi tentang bekerja dengan kebijakan tambalan, lihat[Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).  
Fungsionalitas grup tambalan tidak didukung di konsol untuk pasangan wilayah Akun yang belum menggunakan grup tambalan sebelum dukungan kebijakan tambalan dirilis pada 22 Desember 2022. Fungsionalitas grup patch masih tersedia di pasangan Account-region yang mulai menggunakan grup patch sebelum tanggal ini.

Anda dapat menggunakan *grup tambalan* untuk mengaitkan node terkelola dengan baseline patch tertentu di Patch Manager, alat di AWS Systems Manager. Grup tambalan membantu memastikan bahwa Anda menerapkan tambalan yang sesuai, berdasarkan aturan dasar tambalan terkait, ke kumpulan node yang benar. Grup patch juga dapat membantu Anda menghindari men-deploy patch sebelum diuji secara memadai. Sebagai contoh, Anda dapat membuat grup patch untuk lingkungan yang berbeda (seperti pengembangan, pengujian, dan produksi) dan mendaftarkan setiap grup patch ke dasar patch yang sesuai. 

Saat Anda menjalankan `AWS-RunPatchBaseline` atau dokumen Perintah SSM lainnya untuk ditambal, Anda dapat menargetkan node terkelola menggunakan ID atau tag mereka. SSM Agent and Patch Manager kemudian evaluasi baseline patch mana yang akan digunakan berdasarkan nilai grup patch yang Anda tambahkan ke node terkelola.

## Menggunakan tag untuk menentukan grup tambalan
<a name="patch-group-tags"></a>

Anda membuat grup tambalan menggunakan tag yang diterapkan ke instans Amazon Elastic Compute Cloud (Amazon EC2) dan EC2 non-node di lingkungan [hybrid dan multicloud](operating-systems-and-machine-types.md#supported-machine-types). Perhatikan detail berikut tentang penggunaan tag untuk grup tambalan:
+ 

  Grup patch harus didefinisikan menggunakan kunci tag `Patch Group` atau `PatchGroup` diterapkan ke node terkelola Anda. Saat mendaftarkan grup tambalan untuk garis dasar tambalan, *nilai* identik apa pun yang ditentukan untuk kedua kunci ini ditafsirkan sebagai bagian dari grup yang sama. Misalnya, katakan bahwa Anda telah menandai lima node dengan yang pertama dari pasangan kunci-nilai berikut, dan lima dengan yang kedua:
  + `key=PatchGroup,value=DEV` 
  + `key=Patch Group,value=DEV`

  Bagian Patch Manager perintah untuk membuat baseline menggabungkan 10 node terkelola ini ke dalam satu grup berdasarkan nilai. `DEV` AWS CLI Setara dengan perintah untuk membuat baseline patch untuk grup patch adalah sebagai berikut:

  ```
  aws ssm register-patch-baseline-for-patch-group \
      --baseline-id pb-0c10e65780EXAMPLE \
      --patch-group DEV
  ```

  Menggabungkan nilai-nilai dari kunci yang berbeda ke dalam satu target adalah unik untuk ini Patch Manager perintah untuk membuat grup patch baru dan tidak didukung oleh tindakan API lainnya. Misalnya, jika Anda menjalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)tindakan menggunakan `PatchGroup` dan `Patch Group` kunci dengan nilai yang sama, Anda menargetkan dua set node yang sama sekali berbeda:

  ```
  aws ssm send-command \
      --document-name AWS-RunPatchBaseline \
      --targets "Key=tag:PatchGroup,Values=DEV"
  ```

  ```
  aws ssm send-command \
      --document-name AWS-RunPatchBaseline \
      --targets "Key=tag:Patch Group,Values=DEV"
  ```
+ Ada batasan pada penargetan berbasis tag. Setiap array target untuk `SendCommand` dapat berisi maksimal lima pasangan kunci-nilai.
+ Kami menyarankan Anda memilih hanya satu dari konvensi kunci tag ini, baik `PatchGroup` (tanpa spasi) atau `Patch Group` (dengan spasi). Namun, jika Anda telah [mengizinkan tag dalam metadata EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS) pada sebuah instance, Anda harus menggunakannya. `PatchGroup`
+ Kunci ini peka terhadap huruf besar-kecil. Anda dapat menentukan *nilai* apa pun untuk membantu Anda mengidentifikasi dan menargetkan sumber daya dalam grup itu, misalnya “server web” atau “US-EAST-PROD”, tetapi kuncinya harus atau. `Patch Group` `PatchGroup`

Setelah Anda membuat grup patch dan menandai node terkelola, Anda dapat mendaftarkan grup patch dengan baseline patch. Mendaftarkan grup patch dengan baseline patch memastikan bahwa node dalam grup patch menggunakan aturan yang ditentukan dalam baseline patch terkait. 

Untuk informasi selengkapnya tentang cara membuat grup patch dan mengaitkan grup patch ke dasar patch, lihat [Membuat dan mengelola grup patch](patch-manager-tag-a-patch-group.md) dan [Menambahkan grup patch ke dasar patch](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).

Untuk melihat contoh membuat dasar patch dan grup patch dengan menggunakan AWS Command Line Interface (AWS CLI), lihat [Tutorial: Menambal lingkungan server menggunakan AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Untuk informasi selengkapnya tentang EC2 tag Amazon, lihat [Menandai EC2 sumber daya Amazon Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) *di Panduan EC2 Pengguna Amazon*.

## Cara kerjanya
<a name="how-it-works-patch-groups"></a>

Ketika sistem menjalankan tugas untuk menerapkan baseline patch ke node terkelola, SSM Agent memverifikasi bahwa nilai grup patch didefinisikan untuk node. Jika node ditugaskan ke grup patch, Patch Manager kemudian memverifikasi baseline patch mana yang terdaftar ke grup itu. Jika garis dasar tambalan ditemukan untuk grup itu, Patch Manager mengabari SSM Agent untuk menggunakan baseline patch terkait. Jika node tidak dikonfigurasi untuk grup tambalan, Patch Manager secara otomatis memberi tahu SSM Agent untuk menggunakan baseline patch default yang saat ini dikonfigurasi.

**penting**  
Node terkelola hanya dapat berada dalam satu grup patch.  
Suatu grup patch hanya dapat didaftarkan dengan satu dasar patch untuk setiap jenis sistem operasi.  
Anda tidak dapat menerapkan `Patch Group` tag (dengan spasi) ke EC2 instance Amazon jika opsi **metadata Izinkan tag dalam instance** diaktifkan pada instance. Mengizinkan tag dalam metadata instance mencegah nama kunci tag berisi spasi. Jika Anda telah [mengizinkan tag dalam metadata EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), Anda harus menggunakan kunci tag `PatchGroup` (tanpa spasi).

**Diagram 1: Contoh umum aliran proses operasi penambalan**

Ilustrasi berikut menunjukkan contoh umum dari proses yang dilakukan Systems Manager saat mengirim Run Command tugas ke armada server Anda untuk menambal menggunakan Patch Manager. Proses ini menentukan garis dasar tambalan mana yang akan digunakan dalam operasi penambalan. (Proses serupa digunakan ketika jendela pemeliharaan dikonfigurasi untuk mengirim perintah untuk menambal menggunakan Patch Manager.)

Proses lengkapnya dijelaskan di bawah ilustrasi.

![\[Patch Manager alur kerja untuk menentukan baseline patch mana yang akan digunakan saat melakukan operasi patching.\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)


Dalam contoh ini, kita memiliki tiga kelompok EC2 contoh untuk Windows Server dengan tag berikut diterapkan:


****  

| EC2 kelompok contoh | Tanda | 
| --- | --- | 
|  Grup 1  |  `key=OS,value=Windows` `key=PatchGroup,value=DEV`  | 
|  Grup 2  |  `key=OS,value=Windows`  | 
|  Grup 3  |  `key=OS,value=Windows` `key=PatchGroup,value=QA`  | 

Untuk contoh ini, kami juga memiliki dua Windows Server garis dasar tambalan:


****  

| ID dasar patch | Default | Grup patch terkait | 
| --- | --- | --- | 
|  `pb-0123456789abcdef0`  |  Ya  |  `Default`  | 
|  `pb-9876543210abcdef0`  |  Tidak  |  `DEV`  | 

Proses umum untuk memindai atau menginstal tambalan menggunakan Run Command, alat di AWS Systems Manager, dan Patch Manager adalah sebagai berikut:

1. **Mengirim perintah untuk menambal**: Gunakan konsol Systems Manager, SDK, AWS Command Line Interface (AWS CLI), atau AWS Tools for Windows PowerShell untuk mengirim Run Command tugas menggunakan dokumen`AWS-RunPatchBaseline`. Diagram menunjukkan Run Command tugas untuk menambal instance terkelola dengan menargetkan tag. `key=OS,value=Windows`

1. **Penentuan dasar tambalan**: SSM Agent memverifikasi tag grup tambalan yang diterapkan pada EC2 instance dan kueri Patch Manager untuk baseline patch yang sesuai.
   + **Mencocokkan nilai grup tambalan yang terkait dengan baseline patch:**

     1. SSM Agent, yang diinstal pada EC2 instance di grup satu, menerima perintah yang dikeluarkan pada Langkah 1 untuk memulai operasi penambalan. SSM Agent memvalidasi bahwa EC2 instance memiliki nilai tag grup tambalan yang diterapkan dan kueri `DEV` Patch Manager untuk baseline patch terkait.

     1. Patch Manager memverifikasi bahwa baseline tambalan `pb-9876543210abcdef0` memiliki grup `DEV` tambalan yang terkait dan memberi tahu SSM Agent.

     1. SSM Agent mengambil snapshot baseline patch dari Patch Manager berdasarkan aturan persetujuan dan pengecualian yang dikonfigurasi `pb-9876543210abcdef0` dan dilanjutkan ke langkah berikutnya.
   + **Tidak ada tag grup tambalan yang ditambahkan ke instance:**

     1. SSM Agent, yang diinstal pada EC2 instance di grup dua, menerima perintah yang dikeluarkan pada Langkah 1 untuk memulai operasi penambalan. SSM Agent memvalidasi bahwa EC2 instance tidak memiliki `PatchGroup` tag `Patch Group` atau diterapkan dan sebagai hasilnya, SSM Agent pertanyaan Patch Manager untuk baseline patch Windows default.

     1. Patch Manager memverifikasi bahwa default Windows Server patch baseline adalah `pb-0123456789abcdef0` dan memberi tahu SSM Agent.

     1. SSM Agent mengambil snapshot baseline patch dari Patch Manager berdasarkan aturan persetujuan dan pengecualian yang dikonfigurasi dalam baseline patch default `pb-0123456789abcdef0` dan melanjutkan ke langkah berikutnya.
   + **Tidak ada nilai grup patch yang cocok yang terkait dengan baseline patch:**

     1. SSM Agent, yang diinstal pada EC2 instance di grup tiga, menerima perintah yang dikeluarkan pada Langkah 1 untuk memulai operasi penambalan. SSM Agent memvalidasi bahwa EC2 instance memiliki nilai tag grup tambalan yang diterapkan dan kueri `QA` Patch Manager untuk baseline patch terkait.

     1. Patch Manager tidak menemukan garis dasar tambalan yang terkait dengan grup `QA` tambalan.

     1. Patch Manager mengabari SSM Agent untuk menggunakan `pb-0123456789abcdef0` baseline patch Windows default.

     1. SSM Agent mengambil snapshot baseline patch dari Patch Manager berdasarkan aturan persetujuan dan pengecualian yang dikonfigurasi dalam baseline patch default `pb-0123456789abcdef0` dan melanjutkan ke langkah berikutnya.

1. **Patch scan atau install**: Setelah menentukan baseline patch yang sesuai untuk digunakan, SSM Agent mulai memindai atau menginstal tambalan berdasarkan nilai operasi yang ditentukan dalam Langkah 1. Patch yang dipindai atau diinstal ditentukan oleh aturan persetujuan dan pengecualian tambalan yang ditentukan dalam snapshot dasar patch yang disediakan oleh Patch Manager.

**Info lebih lanjut**  
+ [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md)

# Aplikasi patching yang dirilis oleh Microsoft pada Windows Server
<a name="patch-manager-patching-windows-applications"></a>

Gunakan informasi dalam topik ini untuk membantu Anda mempersiapkan untuk menambal aplikasi saat Windows Server menggunakanPatch Manager, alat di AWS Systems Manager.

**Patching aplikasi Microsoft**  
Menambal dukungan untuk aplikasi pada node Windows Server terkelola terbatas pada aplikasi yang dirilis oleh Microsoft.

**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.

**Dasar patch untuk patching aplikasi yang dirilis oleh Microsoft**  
Untuk Windows Server, disediakan tiga dasar patch yang telah ditetapkan. Garis dasar patch `AWS-DefaultPatchBaseline` dan hanya `AWS-WindowsPredefinedPatchBaseline-OS` mendukung pembaruan sistem operasi pada sistem operasi Windows itu sendiri. `AWS-DefaultPatchBaseline`digunakan sebagai baseline patch default untuk node Windows Server terkelola kecuali Anda menentukan baseline patch yang berbeda. Pengaturan konfigurasi di dua dasar patch ini sama. Yang lebih baru dari keduanya, `AWS-WindowsPredefinedPatchBaseline-OS`, dibuat untuk membedakannya dari dasar patch ketiga yang telah ditetapkan untuk Windows Server. Dasar patch tersebut, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, dapat digunakan untuk menerapkan patch ke ke sistem operasi Windows Server dan aplikasi yang didukung yang dirilis oleh Microsoft.

Anda juga dapat membuat dasar patch kustom untuk memperbarui aplikasi yang dirilis oleh Microsoft pada mesin Windows Server.

**Support untuk menambal aplikasi yang dirilis oleh Microsoft di server lokal, perangkat edge, VM, dan node non-EC2 lainnya**  
Untuk menambal aplikasi yang dirilis oleh Microsoft pada mesin virtual (VM) dan node terkelola non-EC2 lainnya, Anda harus mengaktifkan tingkat instance lanjutan. Biaya dikenakan untuk menggunakan tingkat instans lanjutan. **Namun, tidak ada biaya tambahan untuk menambal aplikasi yang dirilis oleh Microsoft di instans Amazon Elastic Compute Cloud (Amazon EC2).** Untuk informasi selengkapnya, lihat [Mengonfigurasi tingkat instans](fleet-manager-configure-instance-tiers.md).

**Opsi Windows Update untuk "produk Microsoft lainnya"**  
Agar dapat Patch Manager menambal aplikasi yang dirilis oleh Microsoft pada node Windows Server terkelola Anda, opsi Pembaruan Windows **Beri saya pembaruan untuk produk Microsoft lainnya ketika saya memperbarui Windows** harus diaktifkan pada node yang dikelola. 

Untuk informasi tentang mengizinkan opsi ini pada satu node terkelola, lihat [Memperbarui Office dengan Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) di situs web Dukungan Microsoft.

Untuk armada node terkelola yang menjalankan Windows Server 2016 dan yang lebih baru, Anda dapat menggunakan Objek Kebijakan Grup (GPO) untuk mengaktifkan pengaturan. Di Editor Pengelolaan Kebijakan Grup, buka **Konfigurasi Komputer**, **Templat Administratif**, **Komponen Windows**, **Windows Update**, dan pilih **Instal pembaruan untuk produk Microsoft lainnya**. Kami juga merekomendasikan untuk mengonfigurasi GPO dengan parameter tambahan yang mencegah pembaruan otomatis yang tidak direncanakan dan reboot di luar. Patch Manager Untuk informasi selengkapnya, lihat [Mengonfigurasi Pembaruan Otomatis di Lingkungan Direktori Non-Aktif](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) di situs web dokumentasi teknis Microsoft.

Untuk armada node terkelola yang menjalankan Windows Server 2012 atau 2012 R2, Anda dapat mengaktifkan opsi dengan menggunakan skrip, seperti yang dijelaskan dalam [Mengaktifkan dan Menonaktifkan Pembaruan Microsoft di Windows 7 melalui Script di situs web](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) Microsoft Docs Blog. Sebagai contoh, Anda dapat melakukan hal berikut:

1. Simpan script dari posting blog dalam sebuah file.

1. Unggah file ke bucket Amazon Simple Storage Service (Amazon S3) atau lokasi lain yang dapat diakses.

1. GunakanRun Command, alat di AWS Systems Manager, untuk menjalankan skrip pada node terkelola Anda menggunakan dokumen Systems Manager (dokumen SSM) `AWS-RunPowerShellScript` dengan perintah yang mirip dengan berikut ini.

   ```
   Invoke-WebRequest `
       -Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
       -Outfile "C:\script.vbs" cscript c:\script.vbs
   ```

**Persyaratan parameter minimum**  
Untuk menyertakan aplikasi yang dirilis oleh Microsoft di dasar patch kustom Anda, Anda harus, minimal, menentukan produk yang ingin Anda patch. Perintah berikut AWS Command Line Interface (AWS CLI) menunjukkan persyaratan minimal untuk menambal produk, seperti Microsoft Office 2016.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "My-Windows-App-Baseline" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "My-Windows-App-Baseline" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------

Jika Anda menentukan keluarga produk aplikasi Microsoft, setiap produk yang Anda tentukan harus menjadi anggota yang didukung dari keluarga produk yang dipilih. Sebagai contoh, untuk mem-patch produk "Active Directory Rights Management Services Client 2.0," Anda harus menentukan keluarga produk sebagai "Active Directory" dan bukan, misalnya, "Office" atau "SQL Server." AWS CLI Perintah berikut menunjukkan pasangan yang cocok dari keluarga produk dan produk.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "My-Windows-App-Baseline" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "My-Windows-App-Baseline" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```

------

**catatan**  
Jika Anda menerima pesan kesalahan tentang pasangan produk dan keluarga yang tidak cocok, lihat [Masalah: pasangan produk yang tidak cocok family/product](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) untuk membantu menyelesaikan masalah ini.

# Menggunakan node Kernel Live Patching terkelola Amazon Linux 2
<a name="patch-manager-kernel-live-patching"></a>

Kernel Live Patchinguntuk Amazon Linux 2 memungkinkan Anda menerapkan kerentanan keamanan dan patch bug kritis ke kernel Linux yang sedang berjalan tanpa reboot atau gangguan pada aplikasi yang sedang berjalan. Ini memungkinkan Anda mendapatkan keuntungan dari peningkatan ketersediaan layanan dan aplikasi, sambil menjaga infrastruktur Anda tetap aman dan mutakhir. Kernel Live Patchingdidukung pada instans Amazon EC2, perangkat AWS IoT Greengrass inti, dan [mesin virtual lokal yang menjalankan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html) Amazon Linux 2.

Untuk informasi umum tentangKernel Live Patching, lihat [Kernel Live Patching AL2di](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html) *Panduan Pengguna Amazon Linux 2*.

Setelah Anda mengaktifkan node terkelola Amazon Linux 2, Anda dapat menggunakanPatch Manager, alat di AWS Systems Manager, untuk menerapkan patch langsung kernel ke node terkelola. Kernel Live Patching Menggunakan Patch Manager adalah alternatif untuk menggunakan alur kerja yum yang ada di node untuk menerapkan pembaruan.

**Sebelum Anda mulai**  
Patch ManagerUntuk menerapkan tambalan langsung kernel ke node terkelola Amazon Linux 2 Anda, pastikan node Anda didasarkan pada arsitektur dan versi kernel yang benar. *Untuk selengkapnya, lihat [Konfigurasi dan prasyarat yang didukung di](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) Panduan Pengguna Amazon EC2.*

**Topics**
+ [Kernel Live Patchingmenggunakan Patch Manager](#about-klp)
+ [Cara Kernel Live Patching menggunakan Patch Manager karya](#how-klp-works)
+ [Menghidupkan Kernel Live Patching memakai Run Command](enable-klp.md)
+ [Menerapkan tambalan langsung kernel menggunakan Run Command](install-klp.md)
+ [Mematikan Kernel Live Patching memakai Run Command](disable-klp.md)

## Kernel Live Patchingmenggunakan Patch Manager
<a name="about-klp"></a>

Memperbarui versi kernel  
Anda tidak perlu me-reboot node terkelola setelah menerapkan pembaruan patch langsung kernel. Namun, AWS menyediakan tambalan langsung kernel untuk versi kernel Amazon Linux 2 hingga tiga bulan setelah dirilis. Setelah periode tiga bulan, Anda harus memperbarui ke versi kernel berikutnya untuk terus menerima patch live kernel. Sebaiknya gunakan jendela pemeliharaan untuk menjadwalkan reboot node Anda setidaknya sekali setiap tiga bulan untuk meminta pembaruan versi kernel.

Menghapus instalasi patch live kernel  
Patch langsung kernel tidak dapat dihapus menggunakan. Patch Manager Sebagai gantinya, Anda dapat mematikanKernel Live Patching, yang menghapus paket RPM untuk patch live kernel yang diterapkan. Untuk informasi selengkapnya, lihat [Mematikan Kernel Live Patching memakai Run Command](disable-klp.md).

Kepatuhan kernel  
Dalam beberapa kasus, menginstal semua perbaikan CVE dari patch live untuk versi kernel saat ini dapat membawa kernel tersebut ke dalam keadaan kepatuhan yang sama dengan versi kernel yang lebih baru. Ketika itu terjadi, versi yang lebih baru dilaporkan sebagai`Installed`, dan node terkelola dilaporkan sebagai`Compliant`. Namun, tidak ada waktu instalasi yang dilaporkan untuk versi kernel yang lebih baru.

Satu tambalan langsung kernel, banyak CVEs  
Jika tambalan langsung kernel menangani beberapa CVEs, dan itu CVEs memiliki berbagai nilai klasifikasi dan tingkat keparahan, hanya klasifikasi dan tingkat keparahan tertinggi dari antara CVEs yang dilaporkan untuk tambalan. 

Sisa bagian ini menjelaskan cara menggunakan untuk menerapkan patch langsung kernel Patch Manager ke node terkelola yang memenuhi persyaratan ini.

## Cara Kernel Live Patching menggunakan Patch Manager karya
<a name="how-klp-works"></a>

AWS merilis dua jenis tambalan langsung kernel untuk Amazon Linux 2: pembaruan keamanan dan perbaikan bug. Untuk menerapkan kedua jenis patch tersebut, Anda menggunakan dokumen dasar patch yang menargetkan hanya klasifikasi dan kepelikan yang tercantum dalam tabel berikut.


| Klasifikasi | Kepelikan | 
| --- | --- | 
| Security | Critical, Important | 
| Bugfix | All | 

Anda dapat membuat dasar patch kustom yang menargetkan hanya patch ini, atau menggunakan dasar patch `AWS-AmazonLinux2DefaultPatchBaseline` yang telah ditentukan. Dengan kata lain, Anda dapat menggunakan `AWS-AmazonLinux2DefaultPatchBaseline` dengan node terkelola Amazon Linux 2 yang Kernel Live Patching dihidupkan, dan pembaruan langsung kernel akan diterapkan.

**catatan**  
`AWS-AmazonLinux2DefaultPatchBaseline`Konfigurasi menentukan masa tunggu 7 hari setelah patch dirilis atau terakhir diperbarui sebelum diinstal secara otomatis. Jika Anda tidak ingin menunggu 7 hari agar tambalan langsung kernel disetujui secara otomatis, Anda dapat membuat dan menggunakan baseline patch khusus. Di dasar patch Anda, Anda dapat menentukan tidak ada periode tunggu persetujuan otomatis, atau menentukan waktu yang lebih pendek atau lebih lama. Untuk informasi selengkapnya, lihat [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md).

Kami merekomendasikan strategi berikut untuk menambal node terkelola Anda dengan pembaruan langsung kernel:

1. Kernel Live PatchingNyalakan node terkelola Amazon Linux 2 Anda.

1. GunakanRun Command, alat di AWS Systems Manager, untuk menjalankan `Scan` operasi pada node terkelola Anda menggunakan baseline patch yang telah ditentukan `AWS-AmazonLinux2DefaultPatchBaseline` atau kustom yang juga menargetkan hanya `Security` pembaruan dengan tingkat keparahan yang diklasifikasikan sebagai `Critical` dan`Important`, dan tingkat keparahan`Bugfix`. `All` 

1. Gunakan Kepatuhan, alat di AWS Systems Manager, untuk meninjau apakah ketidakpatuhan untuk patching dilaporkan untuk salah satu node terkelola yang dipindai. Jika demikian, lihat detail kepatuhan node untuk menentukan apakah patch langsung kernel hilang dari node terkelola.

1. Untuk menginstal patch live kernel yang hilang, gunakan Run Command dengan baseline patch yang sama yang Anda tentukan sebelumnya, tetapi kali ini jalankan `Install` operasi alih-alih operasi. `Scan`

   Karena patch live kernel diinstal tanpa perlu reboot, Anda dapat memilih opsi reboot `NoReboot` untuk operasi ini. 
**catatan**  
Anda masih dapat me-reboot node terkelola jika diperlukan untuk jenis tambalan lain yang diinstal di dalamnya, atau jika Anda ingin memperbarui ke kernel yang lebih baru. Dalam kasus ini, pilih opsi reboot `RebootIfNeeded` sebagai gantinya.

1. Kembali ke Kepatuhan untuk memverifikasi bahwa patch live kernel telah diinstal.

# Menghidupkan Kernel Live Patching memakai Run Command
<a name="enable-klp"></a>

Untuk menghidupkan Kernel Live Patching, Anda dapat menjalankan `yum` perintah pada node terkelola atau menggunakan Run Command dan dokumen Systems Manager kustom (dokumen SSM) yang Anda buat.

Untuk informasi tentang menyalakan Kernel Live Patching dengan menjalankan `yum` perintah langsung pada node terkelola, lihat [ Aktifkan Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)di *Panduan EC2 Pengguna Amazon*.

**catatan**  
Ketika Anda mengaktifkan Kernel Live Patching, jika kernel yang sudah berjalan pada node terkelola lebih *awal* dari `kernel-4.14.165-131.185.amzn2.x86_64` (versi minimum yang didukung), proses menginstal versi kernel terbaru yang tersedia dan me-reboot node terkelola. Jika node sudah berjalan `kernel-4.14.165-131.185.amzn2.x86_64` atau lebih baru, proses tidak menginstal versi yang lebih baru dan tidak me-reboot node.

**Untuk menghidupkan Kernel Live Patching memakai Run Command (konsol)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Run Command**.

1. Pilih **Jalankan perintah**.

1. Di daftar **Dokumen perintah**, pilih dokumen SSM kustom `AWS-ConfigureKernelLivePatching`.

1. Di bagian **Command parameters**, tentukan apakah Anda ingin node terkelola reboot sebagai bagian dari operasi ini.

1. Untuk informasi tentang bekerja dengan kontrol lainnya di halaman ini, lihat [Menjalankan perintah dari konsol](running-commands-console.md).

1. Pilih **Jalankan**.

**Untuk menghidupkan Kernel Live Patching (AWS CLI)**
+ Jalankan perintah berikut di mesin lokal Anda.

------
#### [ Linux & macOS ]

  ```
  aws ssm send-command \
      --document-name "AWS-ConfigureKernelLivePatching" \
      --parameters "EnableOrDisable=Enable" \
      --targets "Key=instanceids,Values=instance-id"
  ```

------
#### [ Windows Server ]

  ```
  aws ssm send-command ^
      --document-name "AWS-ConfigureKernelLivePatching" ^
      --parameters "EnableOrDisable=Enable" ^
      --targets "Key=instanceids,Values=instance-id"
  ```

------

  Ganti *instance-id* dengan ID node terkelola Amazon Linux 2 tempat Anda ingin mengaktifkan fitur, seperti i-02573CAFCFExample. Untuk mengaktifkan fitur pada beberapa node terkelola, Anda dapat menggunakan salah satu dari format berikut.
  + `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
  + `--targets "Key=tag:tag-key,Values=tag-value"`

  Untuk informasi tentang opsi lain yang dapat Anda gunakan dalam perintah, lihat [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)pada *AWS CLI Command Reference*.

# Menerapkan tambalan langsung kernel menggunakan Run Command
<a name="install-klp"></a>

Untuk menerapkan tambalan langsung kernel, Anda dapat menjalankan `yum` perintah pada node terkelola atau menggunakan Run Command dan dokumen `AWS-RunPatchBaseline` SSM. 

Untuk informasi tentang menerapkan patch langsung kernel dengan menjalankan `yum` perintah langsung di node terkelola, lihat [Menerapkan patch langsung kernel](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) di * EC2 Panduan Pengguna Amazon*.

**Untuk menerapkan tambalan langsung kernel menggunakan Run Command (konsol)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Run Command**.

1. Pilih **Jalankan perintah**.

1. Di daftar **Dokumen perintah**, pilih dokumen SSM `AWS-RunPatchBaseline`.

1. Di bagian **Parameter perintah**, lakukan salah satu hal berikut:
   + Jika Anda memeriksa apakah patch live kernel yang baru tersedia, untuk **Operasi**, pilih `Scan`. Untuk **Opsi Reboot**, jika tidak ingin node terkelola Anda reboot setelah operasi ini, pilih`NoReboot`. Setelah operasi selesai, Anda dapat memeriksa patch baru dan status kepatuhan dalam Kepatuhan.
   + Jika Anda sudah memeriksa kepatuhan patch dan siap untuk menerapkan patch live kernel yang tersedia, untuk **Operasi**, pilih `Install`. Untuk **Opsi Reboot**, jika Anda tidak ingin node terkelola Anda reboot setelah operasi ini, pilih`NoReboot`.

1. Untuk informasi tentang bekerja dengan kontrol lainnya di halaman ini, lihat [Menjalankan perintah dari konsol](running-commands-console.md).

1. Pilih **Jalankan**.

**Untuk menerapkan tambalan langsung kernel menggunakan Run Command (AWS CLI)**

1. Untuk melakukan operasi `Scan` sebelum memeriksa hasil Anda di Kepatuhan, jalankan perintah berikut dari mesin lokal Anda.

------
#### [ Linux & macOS ]

   ```
   aws ssm send-command \
       --document-name "AWS-RunPatchBaseline" \
       --targets "Key=InstanceIds,Values=instance-id" \
       --parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
   ```

------
#### [ Windows Server ]

   ```
   aws ssm send-command ^
       --document-name "AWS-RunPatchBaseline" ^
       --targets "Key=InstanceIds,Values=instance-id" ^
       --parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
   ```

------

   Untuk informasi tentang opsi lain yang dapat Anda gunakan dalam perintah, lihat [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)dalam *AWS CLI Command Reference*.

1. Untuk melakukan operasi `Install` setelah memeriksa hasil Anda di Kepatuhan, jalankan perintah berikut dari mesin lokal Anda.

------
#### [ Linux & macOS ]

   ```
   aws ssm send-command \
       --document-name "AWS-RunPatchBaseline" \
       --targets "Key=InstanceIds,Values=instance-id" \
       --parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
   ```

------
#### [ Windows Server ]

   ```
   aws ssm send-command ^
       --document-name "AWS-RunPatchBaseline" ^
       --targets "Key=InstanceIds,Values=instance-id" ^
       --parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
   ```

------

Di kedua perintah sebelumnya, ganti *instance-id* dengan ID node terkelola Amazon Linux 2 tempat Anda ingin menerapkan patch live kernel, seperti i-02573CAFCFExample. Untuk mengaktifkan fitur pada beberapa node terkelola, Anda dapat menggunakan salah satu dari format berikut.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`

Untuk informasi tentang opsi lain yang dapat Anda gunakan dalam perintah ini, lihat [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)dalam *AWS CLI Command Reference*.

# Mematikan Kernel Live Patching memakai Run Command
<a name="disable-klp"></a>

Untuk mematikan Kernel Live Patching, Anda dapat menjalankan `yum` perintah pada node terkelola atau menggunakan Run Command dan dokumen `AWS-ConfigureKernelLivePatching` SSM khusus.

**catatan**  
Jika Anda tidak perlu lagi menggunakan Kernel Live Patching, Anda dapat menonaktifkannya kapan saja. Dalam kebanyakan kasus, Anda tidak perlu menonaktifkan fitur.

Untuk informasi tentang mematikan Kernel Live Patching dengan menjalankan `yum` perintah langsung pada node terkelola, lihat [ Aktifkan Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable)di *Panduan EC2 Pengguna Amazon*.

**catatan**  
Saat Anda mematikan Kernel Live Patching, proses menghapus instalasi Kernel Live Patching plugin dan kemudian reboot node terkelola.

**Untuk mematikan Kernel Live Patching memakai Run Command (konsol)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Run Command**.

1. Pilih **Jalankan perintah**.

1. Di daftar **Dokumen perintah**, pilih dokumen SSM `AWS-ConfigureKernelLivePatching`.

1. Di bagian **Parameter perintah**, tentukan nilai untuk parameter yang diperlukan.

1. Untuk informasi tentang bekerja dengan kontrol lainnya di halaman ini, lihat [Menjalankan perintah dari konsol](running-commands-console.md).

1. Pilih **Jalankan**.

**Untuk mematikan Kernel Live Patching (AWS CLI)**
+ Jalankan perintah yang serupa dengan yang berikut ini.

------
#### [ Linux & macOS ]

  ```
  aws ssm send-command \
      --document-name "AWS-ConfigureKernelLivePatching" \
      --targets "Key=instanceIds,Values=instance-id" \
      --parameters "EnableOrDisable=Disable"
  ```

------
#### [ Windows Server ]

  ```
  aws ssm send-command ^
      --document-name "AWS-ConfigureKernelLivePatching" ^
      --targets "Key=instanceIds,Values=instance-id" ^
      --parameters "EnableOrDisable=Disable"
  ```

------

  Ganti *instance-id* dengan ID node terkelola Amazon Linux 2 tempat Anda ingin mematikan fitur, seperti i-02573CAFCFExample. Untuk mematikan fitur pada beberapa node terkelola, Anda dapat menggunakan salah satu format berikut.
  + `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
  + `--targets "Key=tag:tag-key,Values=tag-value"`

  Untuk informasi tentang opsi lain yang dapat Anda gunakan dalam perintah, lihat [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)pada *AWS CLI Command Reference*.

# Bekerja dengan Patch Manager sumber daya dan kepatuhan menggunakan konsol
<a name="patch-manager-console"></a>

Untuk menggunakanPatch Manager, alat di AWS Systems Manager, selesaikan tugas-tugas berikut. Tugas-tugas ini diterangkan dengan lebih detail dalam bagian ini.

1. Verifikasi bahwa baseline patch yang AWS telah ditentukan untuk setiap jenis sistem operasi yang Anda gunakan memenuhi kebutuhan Anda. Jika tidak, buat baseline patch yang mendefinisikan kumpulan patch standar untuk tipe node terkelola itu dan tetapkan sebagai default.

1. Atur node terkelola ke dalam grup tambalan menggunakan tag Amazon Elastic Compute Cloud (Amazon EC2) (opsional, tetapi disarankan).

1. Lakukan salah satu tindakan berikut:
   + (Disarankan) Konfigurasikan kebijakan tambalan diQuick Setup, alat di Systems Manager, yang memungkinkan Anda menginstal tambalan yang hilang pada jadwal untuk seluruh organisasi, subset unit organisasi, atau satu. Akun AWS Untuk informasi selengkapnya, lihat [Mengonfigurasi penambalan untuk instance di organisasi menggunakan kebijakan tambalan Quick Setup](quick-setup-patch-manager.md).
   + Buat jendela pemeliharaan yang menggunakan dokumen Systems Manager (dokumen SSM) `AWS-RunPatchBaseline` dalam tipe Run Command tugas. Untuk informasi selengkapnya, lihat [Tutorial: Buat jendela pemeliharaan untuk menambal menggunakan konsol](maintenance-window-tutorial-patching.md).
   + Jalankan secara manual `AWS-RunPatchBaseline` dalam suatu Run Command operasi. Untuk informasi selengkapnya, lihat [Menjalankan perintah dari konsol](running-commands-console.md).
   + Patch node secara manual sesuai permintaan menggunakan fitur **Patch now**. Untuk informasi selengkapnya, lihat [Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md).

1. Pantau patching untuk memverifikasi kepatuhan dan menyelidiki kegagalan.

**Topics**
+ [Membuat kebijakan tambalan](patch-manager-create-a-patch-policy.md)
+ [Melihat ringkasan Patch Dasbor](patch-manager-view-dashboard-summaries.md)
+ [Bekerja dengan laporan kepatuhan tambalan](patch-manager-compliance-reports.md)
+ [Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md)
+ [Bekerja dengan baseline patch](patch-manager-create-a-patch-baseline.md)
+ [Melihat metrik yang tersedia](patch-manager-view-available-patches.md)
+ [Membuat dan mengelola grup patch](patch-manager-tag-a-patch-group.md)
+ [Integrasi dengan Patch Manager AWS Security Hub CSPM](patch-manager-security-hub-integration.md)

# Membuat kebijakan tambalan
<a name="patch-manager-create-a-patch-policy"></a>

Kebijakan tambalan adalah konfigurasi yang Anda atur menggunakanQuick Setup, alat di AWS Systems Manager. Kebijakan patch memberikan kontrol yang lebih luas dan lebih terpusat atas operasi patching Anda daripada yang tersedia dengan metode lain untuk mengonfigurasi patching. Kebijakan patch menentukan jadwal dan baseline yang akan digunakan saat menambal node dan aplikasi Anda secara otomatis.

Untuk informasi selengkapnya, lihat topik berikut:
+ [Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md)
+ [Mengonfigurasi penambalan untuk instance di organisasi menggunakan kebijakan tambalan Quick Setup](quick-setup-patch-manager.md)

# Melihat ringkasan Patch Dasbor
<a name="patch-manager-view-dashboard-summaries"></a>

Tab **Dasbor** di Patch Manager memberi Anda tampilan ringkasan di konsol yang dapat Anda gunakan untuk memantau operasi penambalan Anda dalam tampilan gabungan. Patch Manageradalah alat di AWS Systems Manager. Pada tab **Dashboard**, Anda dapat melihat yang berikut:
+ Cuplikan tentang berapa banyak node terkelola yang sesuai dan tidak sesuai dengan aturan penambalan.
+ Cuplikan usia hasil kepatuhan patch untuk node terkelola Anda.
+ Hitungan terkait berapa banyak node terkelola yang tidak patuh yang ada untuk masing-masing alasan paling umum untuk ketidakpatuhan.
+ Daftar tertaut dari operasi penambalan terbaru.
+ Daftar tertaut dari tugas patching berulang yang telah disiapkan.

**Untuk melihat ringkasan Patch Dasbor**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Dasbor**.

1. Gulir ke bagian yang berisi data ringkasan yang ingin Anda lihat:
   + **Manajemen instans Amazon EC2**
   + **Ringkasan kepatuhan**
   + **Ketidakpatuhan diperhitungkan**
   + **Laporan kepatuhan**
   + **Operasi berbasis kebijakan non-patch**
   + **Tugas berulang berbasis kebijakan non-patch**

# Bekerja dengan laporan kepatuhan tambalan
<a name="patch-manager-compliance-reports"></a>

Gunakan informasi dalam topik berikut untuk membantu Anda menghasilkan dan bekerja dengan laporan kepatuhan tambalan diPatch Manager, alat di AWS Systems Manager.

Informasi dalam topik berikut berlaku, apa pun metode atau jenis konfigurasi yang Anda gunakan untuk operasi penambalan Anda: 
+ Kebijakan tambalan yang dikonfigurasi di Quick Setup
+ Opsi Manajemen Host yang dikonfigurasi di Quick Setup
+ Jendela pemeliharaan untuk menjalankan tambalan `Scan` atau `Install` tugas
+ **Patch sesuai permintaan sekarang beroperasi**

**penting**  
Laporan kepatuhan tambalan adalah point-in-time snapshot yang dihasilkan hanya oleh operasi penambalan yang berhasil. Setiap laporan berisi waktu pengambilan yang mengidentifikasi kapan status kepatuhan dihitung.  
Jika Anda memiliki beberapa jenis operasi untuk memindai instans Anda untuk kepatuhan patch, perhatikan bahwa setiap pemindaian menimpa data kepatuhan patch dari pemindaian sebelumnya. Akibatnya, Anda mungkin berakhir dengan hasil yang tidak terduga dalam data kepatuhan patch Anda. Untuk informasi selengkapnya, lihat [Mengidentifikasi eksekusi yang membuat data kepatuhan patch](patch-manager-compliance-data-overwrites.md).  
**Untuk memverifikasi baseline patch mana yang digunakan untuk menghasilkan informasi kepatuhan terbaru, buka tab **Pelaporan kepatuhan** diPatch Manager, cari baris untuk node terkelola yang ingin Anda informasikan, lalu pilih ID dasar di kolom ID Baseline yang digunakan.**

**Topics**
+ [Melihat hasil kepatuhan patch](patch-manager-view-compliance-results.md)
+ [Menghasilkan laporan kepatuhan patch .csv](patch-manager-store-compliance-results-in-s3.md)
+ [Memediasi node terkelola yang tidak sesuai dengan Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Mengidentifikasi eksekusi yang membuat data kepatuhan patch](patch-manager-compliance-data-overwrites.md)

# Melihat hasil kepatuhan patch
<a name="patch-manager-view-compliance-results"></a>

Gunakan prosedur ini untuk melihat informasi kepatuhan tambalan tentang node terkelola Anda.

Prosedur ini berlaku untuk operasi patch yang menggunakan dokumen `AWS-RunPatchBaseline`. Untuk informasi tentang melihat informasi kepatuhan patch untuk operasi patch yang menggunakan dokumen `AWS-RunPatchBaselineAssociation`, lihat [Mengidentifikasi node terkelola yang tidak sesuai](patch-manager-find-noncompliant-nodes.md).

**catatan**  
Operasi pemindaian patch untuk Quick Setup dan Explorer menggunakan `AWS-RunPatchBaselineAssociation` dokumen. Quick Setupdan Explorer keduanya merupakan alat di AWS Systems Manager.

**Identifikasi solusi patch untuk masalah CVE tertentu (Linux)**  
Untuk banyak sistem operasi berbasis Linux, hasil kepatuhan patch menunjukkan masalah buletin Common Vulnerabilities and Exposure (CVE) apa yang diselesaikan oleh patch tertentu. Informasi ini dapat membantu Anda menentukan seberapa mendesak Anda perlu menginstal patch yang hilang atau gagal.

Detail CVE disertakan untuk versi yang didukung dari jenis sistem operasi berikut:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux

**catatan**  
Secara default, CentOS Stream tidak memberikan informasi CVE tentang pembaruan. Namun, Anda dapat mengizinkan support ini dengan menggunakan repositori pihak ketiga seperti repositori Extra Packages for Enterprise Linux (EPEL) yang diterbitkan oleh Fedora. Untuk informasi, lihat [EPEL](https://fedoraproject.org/wiki/EPEL) di Fedora Wiki.  
Saat ini, nilai ID CVE dilaporkan hanya untuk tambalan dengan status atau. `Missing` `Failed`

Anda juga dapat menambahkan CVE IDs ke daftar tambalan yang disetujui atau ditolak di garis dasar tambalan Anda, seperti yang diperlukan oleh situasi dan tujuan penambalan Anda.

Untuk informasi tentang bekerja dengan daftar patch yang disetujui dan ditolak, lihat topik berikut:
+ [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md)
+ [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md)
+ [Cara kerja aturan dasar patch pada sistem berbasis Linux](patch-manager-linux-rules.md)
+ [Cara menginstal patch](patch-manager-installing-patches.md)

**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.

## Melihat hasil patching compliance
<a name="viewing-patch-compliance-results-console"></a>

Gunakan prosedur berikut ini untuk melihat hasil kepatuhan patch di konsol AWS Systems Manager . 

**catatan**  
Untuk informasi tentang menghasilkan laporan kepatuhan patch yang diunduh ke bucket Amazon Simple Storage Service (Amazon S3), lihat [Menghasilkan laporan kepatuhan patch .csv](patch-manager-store-compliance-results-in-s3.md).

**Untuk melihat hasil kepatuhan patch**

1. Lakukan salah satu hal berikut ini.

   **Opsi 1** (disarankan) - Navigasi dariPatch Manager, alat di AWS Systems Manager:
   + Di panel navigasi, pilih **Patch Manager**.
   + Pilih tab **Pelaporan kepatuhan**.
   + Di area **detail penambalan Node**, pilih ID node dari node terkelola yang ingin Anda tinjau hasil kepatuhan tambalan. Node yang sedang `stopped` atau tidak `terminated` akan ditampilkan di sini.
   + Di area **Detail**, dalam daftar **Properti**, pilih **Patch**.

   **Opsi 2** — Navigasi dari Kepatuhan, alat di AWS Systems Manager:
   + Di panel navigasi, pilih **Kepatuhan**.
   + Untuk **Ringkasan sumber daya kepatuhan**, pilih nomor di kolom untuk jenis sumber daya patch yang ingin Anda tinjau, seperti **Sumber daya yang tidak patuh**.
   + Di bawah ini, dalam daftar **Sumber Daya**, pilih ID node terkelola yang ingin Anda tinjau hasil kepatuhan tambalan.
   + Di area **Detail**, dalam daftar **Properti**, pilih **Patch**.

   **Opsi 3** - Navigasi dariFleet Manager, alat masuk AWS Systems Manager.
   + Di panel navigasi, pilih **Fleet Manager**.
   + Di area **Instans terkelola**, pilih ID node terkelola yang ingin Anda tinjau hasil kepatuhan tambalan.
   + Di area **Detail**, dalam daftar **Properti**, pilih **Patch**.

1. (Opsional) Di kotak pencarian (![\[The Search icon\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/images/search-icon.png)), pilih dari filter yang tersedia.

   Sebagai contoh, untuk Red Hat Enterprise Linux (RHEL), pilih dari yang berikut ini:
   + Nama
   + Klasifikasi
   + Keadaan
   + Kepelikan

    Untuk Windows Server, pilih dari yang berikut ini:
   + KB
   + Klasifikasi
   + Keadaan
   + Kepelikan

1. Pilih salah satu nilai yang tersedia untuk jenis filter yang Anda pilih. Misalnya, jika Anda memilih **Negara**, sekarang pilih status kepatuhan seperti **InstalledPendingReboot**, **Gagal** atau **Hilang**.
**catatan**  
Saat ini, nilai ID CVE dilaporkan hanya untuk tambalan dengan status atau. `Missing` `Failed`

1. Bergantung pada status kepatuhan node terkelola, Anda dapat memilih tindakan apa yang harus diambil untuk memperbaiki node yang tidak patuh.

   Misalnya, Anda dapat memilih untuk segera menambal node terkelola yang tidak sesuai. Untuk informasi tentang menambal node terkelola sesuai permintaan, lihat[Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md).

   Untuk informasi tentang nilai keadaan kepatuhan patch, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md).

# Menghasilkan laporan kepatuhan patch .csv
<a name="patch-manager-store-compliance-results-in-s3"></a>

Anda dapat menggunakan AWS Systems Manager konsol untuk menghasilkan laporan kepatuhan patch yang disimpan sebagai file.csv ke bucket Amazon Simple Storage Service (Amazon S3) pilihan Anda. Anda dapat membuat laporan sesuai permintaan tunggal atau menentukan jadwal untuk menghasilkan laporan secara otomatis. 

Laporan dapat dibuat untuk satu node terkelola atau untuk semua node terkelola di yang Anda pilih Akun AWS dan Wilayah AWS. Untuk satu node, laporan berisi detail komprehensif, termasuk IDs tambalan yang terkait dengan node yang tidak sesuai. Untuk laporan tentang semua node terkelola, hanya informasi ringkasan dan jumlah patch node yang tidak sesuai yang disediakan.

Setelah laporan dibuat, Anda dapat menggunakan alat seperti Amazon Quick untuk mengimpor dan menganalisis data. Quick adalah layanan intelijen bisnis (BI) yang dapat Anda gunakan untuk mengeksplorasi dan menafsirkan informasi dalam lingkungan visual yang interaktif. Untuk informasi selengkapnya, lihat [Panduan Pengguna Cepat Amazon](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).

**catatan**  
Saat membuat baseline patch kustom, Anda dapat menentukan tingkat keparahan kepatuhan untuk tambalan yang disetujui oleh baseline patch tersebut, seperti atau. `Critical` `High` Jika status tambalan dari tambalan yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan keseluruhan baseline patch yang dilaporkan adalah tingkat keparahan yang Anda tentukan.

Anda juga dapat menentukan topik Amazon Simple Notification Service (Amazon SNS) yang digunakan untuk mengirim notifikasi ketika laporan dibuat.

**Peran layanan untuk membuat laporan kepatuhan patch**  
Saat pertama kali membuat laporan, Systems Manager membuat peran Automation asumsi bernama `AWS-SystemsManager-PatchSummaryExportRole` untuk digunakan untuk proses ekspor ke S3.

**catatan**  
Jika Anda mengekspor data kepatuhan ke bucket S3 terenkripsi, Anda harus memperbarui kebijakan AWS KMS kunci terkait untuk memberikan izin yang diperlukan. `AWS-SystemsManager-PatchSummaryExportRole` Misalnya, tambahkan izin yang serupa dengan ini ke AWS KMS kebijakan bucket S3 Anda:  

```
{
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey"
    ],
    "Resource": "role-arn"
}
```
Ganti *role-arn* dengan Nama Sumber Daya Amazon (ARN) yang dibuat di akun Anda, dalam format. `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`  
Untuk informasi selengkapnya, lihat [Kebijakan kunci di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) di *Panduan Developer AWS Key Management Service *.

Pertama kali Anda membuat laporan pada jadwal, Systems Manager membuat peran layanan lain bernama`AWS-EventBridge-Start-SSMAutomationRole`, bersama dengan peran layanan `AWS-SystemsManager-PatchSummaryExportRole` (jika belum dibuat) untuk digunakan untuk proses ekspor. `AWS-EventBridge-Start-SSMAutomationRole`memungkinkan Amazon EventBridge untuk memulai otomatisasi menggunakan runbook [AWS- ExportPatchReportTo S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).

Kami merekomendasikan agar tidak mencoba mengubah kebijakan dan peran ini. Melakukan hal itu dapat menyebabkan pembuatan laporan kepatuhan patch gagal. Untuk informasi selengkapnya, lihat [Memecahkan masalah pembuatan laporan kepatuhan patch](#patch-compliance-reports-troubleshooting).

**Topics**
+ [Apa yang ada dalam laporan kepatuhan patch yang dibuat?](#patch-compliance-reports-to-s3-examples)
+ [Membuat laporan kepatuhan tambalan untuk satu node terkelola](#patch-compliance-reports-to-s3-one-instance)
+ [Membuat laporan kepatuhan tambalan untuk semua node terkelola](#patch-compliance-reports-to-s3-all-instances)
+ [Melihat riwayat pelaporan kepatuhan patch](#patch-compliance-reporting-history)
+ [Melihat jadwal pelaporan kepatuhan patch](#patch-compliance-reporting-schedules)
+ [Memecahkan masalah pembuatan laporan kepatuhan patch](#patch-compliance-reports-troubleshooting)

## Apa yang ada dalam laporan kepatuhan patch yang dibuat?
<a name="patch-compliance-reports-to-s3-examples"></a>

Topik ini menyediakan informasi tentang jenis konten yang disertakan dalam laporan kepatuhan patch yang dihasilkan dan diunduh ke bucket S3 tertentu.

### Format laporan untuk satu node terkelola
<a name="patch-compliance-reports-to-s3-examples-single-instance"></a>

Laporan yang dihasilkan untuk satu node terkelola memberikan ringkasan dan informasi rinci.

[Unduh laporan sampel (simpul tunggal)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)

Informasi ringkasan untuk satu node terkelola mencakup yang berikut:
+ Indeks
+ ID instans
+ Nama instans
+ IP instans
+ Nama platform
+ Versi Platform
+ Versi SSM Agent
+ Dasar patch
+ Grup patch
+ Status kepatuhan
+ Kepelikan kepatuhan
+ Jumlah patch dengan kepelikan Kritis yang tidak patuh
+ Jumlah patch dengan kepelikan Tinggi yang tidak patuh
+ Jumlah patch dengan kepelikan Medium yang tidak patuh
+ Jumlah patch dengan kepelikan Rendah yang tidak patuh
+ Jumlah patch dengan kepelikan Informasional yang tidak patuh
+ Jumlah patch dengan kepelikan Tidak Ditentukan yang tidak patuh

Informasi terperinci untuk satu node terkelola mencakup yang berikut:
+ Indeks
+ ID instans
+ Nama instans
+ Nama patch
+  ID/Patch ID KB
+ Keadaan patch
+ Waktu laporan terakhir
+ Tingkat kepatuhan
+ Kepelikan patch
+ Klasifikasi patch
+ ID CVE
+ Dasar patch
+ URL Log
+ IP instans
+ Nama platform
+ Versi Platform
+ Versi SSM Agent

**catatan**  
Saat membuat baseline patch kustom, Anda dapat menentukan tingkat keparahan kepatuhan untuk tambalan yang disetujui oleh baseline patch tersebut, seperti atau. `Critical` `High` Jika status tambalan dari tambalan yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan keseluruhan baseline patch yang dilaporkan adalah tingkat keparahan yang Anda tentukan.

### Format laporan untuk semua node terkelola
<a name="patch-compliance-reports-to-s3-examples-all-instances"></a>

Laporan yang dibuat untuk semua node terkelola hanya menyediakan informasi ringkasan.

[Unduh contoh laporan (semua node terkelola)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)

Informasi ringkasan untuk semua node terkelola mencakup yang berikut:
+ Indeks
+ ID instans
+ Nama instans
+ IP instans
+ Nama platform
+ Versi Platform
+ Versi SSM Agent
+ Dasar patch
+ Grup patch
+ Status kepatuhan
+ Kepelikan kepatuhan
+ Jumlah patch dengan kepelikan Kritis yang tidak patuh
+ Jumlah patch dengan kepelikan Tinggi yang tidak patuh
+ Jumlah patch dengan kepelikan Medium yang tidak patuh
+ Jumlah patch dengan kepelikan Rendah yang tidak patuh
+ Jumlah patch dengan kepelikan Informasional yang tidak patuh
+ Jumlah patch dengan kepelikan Tidak Ditentukan yang tidak patuh

## Membuat laporan kepatuhan tambalan untuk satu node terkelola
<a name="patch-compliance-reports-to-s3-one-instance"></a>

Gunakan prosedur berikut untuk menghasilkan laporan ringkasan tambalan untuk satu node terkelola di Anda Akun AWS. Laporan untuk satu node terkelola memberikan detail tentang setiap tambalan yang tidak sesuai, termasuk nama tambalan dan IDs. 

**Untuk menghasilkan laporan kepatuhan tambalan untuk satu node terkelola**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Pelaporan kepatuhan**.

1. Pilih tombol untuk baris node terkelola yang ingin Anda hasilkan laporannya, lalu pilih **Lihat detail**.

1. Di bagian **Ringkasan tambalan**, pilih **Ekspor ke S3**.

1. Untuk **Nama laporan**, masukkan nama untuk membantu Anda mengidentifikasi laporan nanti.

1. Untuk **Frekuensi pelaporan**, pilih salah satu hal berikut:
   + **Sesuai permintaan** — Buat laporan satu kali. Lewati ke Langkah 9.
   + **Sesuai jadwal** — Tentukan jadwal berulang untuk membuat laporan secara otomatis. Lanjutkan ke Langkah 8.

1. Untuk **Jenis jadwal**, tentukan ekspresi rate, seperti setiap 3 hari, atau berikan ekspresi cron untuk mengatur frekuensi laporan.

   Untuk informasi tentang ekspresi cron, lihat [Referensi: Ekspresi cron dan rate untuk Systems Manager](reference-cron-and-rate-expressions.md).

1. Untuk **Nama bucket**, pilih nama bucket S3 tempat Anda ingin menyimpan file laporan .csv.
**penting**  
Jika Anda bekerja di sebuah Wilayah AWS yang diluncurkan setelah 20 Maret 2019, Anda harus memilih bucket S3 di Wilayah yang sama. Region yang diluncurkan setelah tanggal tersebut dimatikan secara default. Untuk informasi selengkapnya dan daftar Wilayah ini, lihat [Mengaktifkan Wilayah](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) di. *Referensi Umum Amazon Web Services*

1. (Opsional) Untuk mengirim pemberitahuan saat laporan dibuat, keluarkan bagian **topik SNS, lalu pilih topik** Amazon SNS yang ada dari **topik SNS Nama Sumber Daya Amazon** (ARN).

1. Pilih **Kirim**.

Untuk informasi tentang melihat riwayat laporan yang dibuat, lihat [Melihat riwayat pelaporan kepatuhan patch](#patch-compliance-reporting-history).

Untuk informasi tentang melihat detail jadwal pelaporan yang telah Anda buat, lihat [Melihat jadwal pelaporan kepatuhan patch](#patch-compliance-reporting-schedules).

## Membuat laporan kepatuhan tambalan untuk semua node terkelola
<a name="patch-compliance-reports-to-s3-all-instances"></a>

Gunakan prosedur berikut untuk menghasilkan laporan ringkasan tambalan untuk semua node terkelola di Anda Akun AWS. Laporan untuk semua node terkelola menunjukkan node mana yang tidak sesuai dan jumlah tambalan yang tidak sesuai. Ini tidak memberikan nama atau pengidentifikasi lain dari patch. Untuk detail tambahan ini, Anda dapat membuat laporan kepatuhan patch untuk satu node terkelola. Untuk informasi, lihat [Membuat laporan kepatuhan tambalan untuk satu node terkelola](#patch-compliance-reports-to-s3-one-instance) sebelumnya dalam topik ini. 

**Untuk menghasilkan laporan kepatuhan tambalan untuk semua node terkelola**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Pelaporan kepatuhan**.

1. Pilih **Ekspor ke S3**. (Jangan pilih ID node terlebih dahulu.)

1. Untuk **Nama laporan**, masukkan nama untuk membantu Anda mengidentifikasi laporan nanti.

1. Untuk **Frekuensi pelaporan**, pilih salah satu hal berikut:
   + **Sesuai permintaan** — Buat laporan satu kali. Lewati ke Langkah 8.
   + **Sesuai jadwal** — Tentukan jadwal berulang untuk membuat laporan secara otomatis. Lanjutkan ke Langkah 7.

1. Untuk **Jenis jadwal**, tentukan ekspresi rate, seperti setiap 3 hari, atau berikan ekspresi cron untuk mengatur frekuensi laporan.

   Untuk informasi tentang ekspresi cron, lihat [Referensi: Ekspresi cron dan rate untuk Systems Manager](reference-cron-and-rate-expressions.md).

1. Untuk **Nama bucket**, pilih nama bucket S3 tempat Anda ingin menyimpan file laporan .csv.
**penting**  
Jika Anda bekerja di sebuah Wilayah AWS yang diluncurkan setelah 20 Maret 2019, Anda harus memilih bucket S3 di Wilayah yang sama. Region yang diluncurkan setelah tanggal tersebut dimatikan secara default. Untuk informasi selengkapnya dan daftar Wilayah ini, lihat [Mengaktifkan Wilayah](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) di. *Referensi Umum Amazon Web Services*

1. (Opsional) Untuk mengirim pemberitahuan saat laporan dibuat, keluarkan bagian **topik SNS, lalu pilih topik** Amazon SNS yang ada dari **topik SNS Nama Sumber Daya Amazon** (ARN).

1. Pilih **Kirim**.

Untuk informasi tentang melihat riwayat laporan yang dibuat, lihat [Melihat riwayat pelaporan kepatuhan patch](#patch-compliance-reporting-history).

Untuk informasi tentang melihat detail jadwal pelaporan yang telah Anda buat, lihat [Melihat jadwal pelaporan kepatuhan patch](#patch-compliance-reporting-schedules).

## Melihat riwayat pelaporan kepatuhan patch
<a name="patch-compliance-reporting-history"></a>

Gunakan informasi dalam topik ini untuk membantu Anda melihat detail tentang laporan kepatuhan tambalan yang dihasilkan di Anda Akun AWS.

**Untuk melihat riwayat pelaporan kepatuhan patch**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Pelaporan kepatuhan**.

1. Pilih **Lihat semua ekspor S3**, lalu pilih tab **Riwayat ekspor**.

## Melihat jadwal pelaporan kepatuhan patch
<a name="patch-compliance-reporting-schedules"></a>

Gunakan informasi dalam topik ini untuk membantu Anda melihat detail tentang jadwal pelaporan kepatuhan tambalan yang dibuat di situs Anda Akun AWS.

**Untuk melihat riwayat pelaporan kepatuhan patch**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Pelaporan kepatuhan**.

1. Pilih **Lihat semua ekspor S3**, lalu pilih tab **Aturan jadwal laporan**.

## Memecahkan masalah pembuatan laporan kepatuhan patch
<a name="patch-compliance-reports-troubleshooting"></a>

Gunakan informasi berikut untuk membantu Anda memecahkan masalah dengan menghasilkan pembuatan laporan kepatuhan tambalan diPatch Manager, alat di. AWS Systems Manager

**Topics**
+ [Pesan melaporkan bahwa kebijakan `AWS-SystemsManager-PatchManagerExportRolePolicy` rusak](#patch-compliance-reports-troubleshooting-1)
+ [Setelah menghapus kebijakan atau peran kepatuhan patch, laporan terjadwal tidak berhasil dibuat](#patch-compliance-reports-troubleshooting-2)

### Pesan melaporkan bahwa kebijakan `AWS-SystemsManager-PatchManagerExportRolePolicy` rusak
<a name="patch-compliance-reports-troubleshooting-1"></a>

**Masalah**: Anda menerima pesan kesalahan yang serupa dengan berikut ini, menunjukkan `AWS-SystemsManager-PatchManagerExportRolePolicy` rusak:

```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any 
role that uses it, then try again. Systems Manager recreates the roles and policies 
you have deleted.
```
+ **Solusi**: Gunakan Patch Manager konsol atau AWS CLI untuk menghapus peran dan kebijakan yang terpengaruh sebelum membuat laporan kepatuhan patch baru.

**Untuk menghapus kebijakan korup menggunakan konsol**

  1. Buka konsol IAM di [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

  1. Lakukan salah satu tindakan berikut:

     **Laporan sesuai permintaan** — Jika masalah terjadi saat membuat laporan sesuai permintaan satu kali, di navigasi sebelah kiri, pilih **Kebijakan**, cari `AWS-SystemsManager-PatchManagerExportRolePolicy`, lalu hapus kebijakan tersebut. Selanjutnya, pilih **Peran**, cari `AWS-SystemsManager-PatchSummaryExportRole`, lalu hapus peran tersebut.

     **Laporan terjadwal** — Jika masalah terjadi saat membuat laporan sesuai jadwal, di navigasi kiri, pilih **Kebijakan**, cari satu per satu`AWS-SystemsManager-PatchManagerExportRolePolicy`, `AWS-EventBridge-Start-SSMAutomationRolePolicy` dan hapus setiap kebijakan. Selanjutnya, pilih **Peran**, cari satu per satu untuk `AWS-EventBridge-Start-SSMAutomationRole` dan `AWS-SystemsManager-PatchSummaryExportRole`, dan hapus masing-masing peran.

**Untuk menghapus kebijakan korup menggunakan AWS CLI**

  Ganti *placeholder values* dengan ID akun Anda.
  + Jika masalah terjadi saat membuat laporan on-demand satu kali, jalankan perintah berikut:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

    Jika masalah terjadi saat membuat laporan pada jadwal, jalankan perintah berikut:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
    ```

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

  Setelah menyelesaikan salah satu prosedur, ikuti langkah-langkah untuk membuat atau menjadwalkan laporan kepatuhan patch baru.

### Setelah menghapus kebijakan atau peran kepatuhan patch, laporan terjadwal tidak berhasil dibuat
<a name="patch-compliance-reports-troubleshooting-2"></a>

**Masalah**: Pertama kali Anda membuat laporan, Systems Manager membuat peran layanan dan kebijakan untuk digunakan untuk proses ekspor (`AWS-SystemsManager-PatchSummaryExportRole` dan `AWS-SystemsManager-PatchManagerExportRolePolicy`). Pertama kali Anda membuat laporan terjadwal, Systems Manager membuat peran layanan lain dan kebijakan (`AWS-EventBridge-Start-SSMAutomationRole` dan `AWS-EventBridge-Start-SSMAutomationRolePolicy`). Ini memungkinkan Amazon EventBridge memulai otomatisasi menggunakan runbook [AWS- ExportPatchReportTo S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).

Jika Anda menghapus salah satu kebijakan atau peran ini, hubungan antara jadwal Anda dan bucket S3 yang ditentukan dan topik Amazon SNS mungkin hilang. 
+ **Solusi**: Untuk mengatasi masalah ini, kami merekomendasikan untuk menghapus jadwal sebelumnya dan membuat jadwal baru untuk menggantikan jadwal yang mengalami masalah.

# Memediasi node terkelola yang tidak sesuai dengan Patch Manager
<a name="patch-manager-noncompliant-nodes"></a>

Topik di bagian ini memberikan ikhtisar tentang cara mengidentifikasi node terkelola yang tidak sesuai dengan patch dan bagaimana membawa node ke dalam kepatuhan.

**Topics**
+ [Mengidentifikasi node terkelola yang tidak sesuai](patch-manager-find-noncompliant-nodes.md)
+ [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md)
+ [Menambal node terkelola yang tidak sesuai](patch-manager-compliance-remediation.md)

# Mengidentifikasi node terkelola yang tidak sesuai
<a name="patch-manager-find-noncompliant-nodes"></a>

Out-of-compliance node terkelola diidentifikasi ketika salah satu dari dua AWS Systems Manager dokumen (dokumen SSM) dijalankan. Dokumen SSM ini mereferensikan baseline patch yang sesuai untuk setiap node terkelola diPatch Manager, sebuah alat di. AWS Systems Manager Mereka kemudian mengevaluasi status patch dari node terkelola dan kemudian membuat hasil kepatuhan tersedia untuk Anda.

Ada dua dokumen SSM yang digunakan untuk mengidentifikasi atau memperbarui node terkelola yang tidak sesuai: dan. `AWS-RunPatchBaseline` `AWS-RunPatchBaselineAssociation` Masing-masing digunakan oleh proses yang berbeda, dan hasil kepatuhan mereka tersedia melalui saluran yang berbeda. Tabel berikut ini menguraikan perbedaan antara dokumen-dokumen ini.

**catatan**  
Data kepatuhan tambalan dari Patch Manager dapat dikirim ke AWS Security Hub CSPM. Security Hub CSPM memberi Anda pandangan komprehensif tentang peringatan keamanan prioritas tinggi dan status kepatuhan Anda. Hub juga memantau status patching armada Anda. Untuk informasi selengkapnya, lihat [Integrasi dengan Patch Manager AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 


|  | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` | 
| --- | --- | --- | 
| Proses yang menggunakan dokumen |  **Patch on demand** - Anda dapat memindai atau menambal node yang dikelola sesuai permintaan menggunakan opsi **Patch now**. Untuk informasi, lihat [Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md). **Kebijakan Quick Setup patch Systems Manager** — Anda dapat membuat konfigurasi tambalanQuick Setup, alat di AWS Systems Manager, yang dapat memindai atau menginstal tambalan yang hilang pada jadwal terpisah untuk seluruh organisasi, subset unit organisasi, atau satu. Akun AWS Untuk informasi, lihat [Mengonfigurasi penambalan untuk instance di organisasi menggunakan kebijakan tambalan Quick Setup](quick-setup-patch-manager.md). **Jalankan perintah** - Anda dapat menjalankan `AWS-RunPatchBaseline` secara manual dalam operasi diRun Command, alat di AWS Systems Manager. Untuk informasi, lihat [Menjalankan perintah dari konsol](running-commands-console.md). **Jendela pemeliharaan** - Anda dapat membuat jendela pemeliharaan yang menggunakan dokumen SSM `AWS-RunPatchBaseline` dalam tipe Run Command tugas. Untuk informasi, lihat [Tutorial: Buat jendela pemeliharaan untuk menambal menggunakan konsol](maintenance-window-tutorial-patching.md).  |  **Manajemen Quick Setup Host Systems Manager** — Anda dapat mengaktifkan opsi konfigurasi Manajemen Host Quick Setup untuk memindai instans terkelola untuk kepatuhan patch setiap hari. Untuk informasi, lihat [Siapkan manajemen host Amazon EC2 menggunakan Quick Setup](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)**— Bila Anda mengizinkanExplorer, alat masuk AWS Systems Manager, alat ini secara teratur memindai instans terkelola Anda untuk kepatuhan tambalan dan hasil laporan di dasbor. Explorer  | 
| Format data hasil pemindaian patch |  Setelah `AWS-RunPatchBaseline` berjalan, Patch Manager mengirim `AWS:PatchSummary` objek ke Inventory, alat di AWS Systems Manager. Laporan ini dihasilkan hanya oleh operasi penambalan yang berhasil dan mencakup waktu pengambilan yang mengidentifikasi kapan status kepatuhan dihitung.  |  Setelah `AWS-RunPatchBaselineAssociation` berjalan, Patch Manager mengirimkan `AWS:ComplianceItem` objek ke Systems Manager Inventory.  | 
| Melihat laporan kepatuhan patch di konsol |  Anda dapat melihat informasi kepatuhan patch untuk proses yang menggunakan `AWS-RunPatchBaseline` dalam [Kepatuhan Konfigurasi Systems Manager](systems-manager-compliance.md) dan [Bekerja dengan node terkelola](fleet-manager-managed-nodes.md). Untuk informasi selengkapnya, lihat [Melihat hasil kepatuhan patch](patch-manager-view-compliance-results.md).  |  Jika digunakan Quick Setup untuk memindai instans terkelola untuk kepatuhan tambalan, Anda dapat melihat laporan kepatuhan di [Systems Manager Fleet Manager](fleet-manager.md). Di Fleet Manager konsol, pilih ID node dari node terkelola Anda. Di menu **Umum**, pilih **Kepatuhan konfigurasi**. Jika digunakan Explorer untuk memindai instans terkelola untuk kepatuhan tambalan, Anda dapat melihat laporan kepatuhan di keduanya Explorer dan [Systems Manager OpsCenter](OpsCenter.md).  | 
| AWS CLI perintah untuk melihat hasil kepatuhan patch |  Untuk proses yang digunakan`AWS-RunPatchBaseline`, Anda dapat menggunakan AWS CLI perintah berikut untuk melihat informasi ringkasan tentang tambalan pada node terkelola. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  |  Untuk proses yang digunakan`AWS-RunPatchBaselineAssociation`, Anda dapat menggunakan AWS CLI perintah berikut untuk melihat informasi ringkasan tentang tambalan pada sebuah instance. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  | 
| Operasi patching |  Untuk proses yang menggunakan `AWS-RunPatchBaseline`, Anda menentukan apakah Anda ingin operasi untuk menjalankan operasi `Scan` saja, atau operasi `Scan and install`. Jika tujuan Anda adalah mengidentifikasi node terkelola yang tidak sesuai dan tidak memperbaikinya, jalankan hanya operasi. `Scan`  | Quick Setupdan Explorer proses, yang menggunakanAWS-RunPatchBaselineAssociation, hanya menjalankan Scan operasi. | 
| Info selengkapnya |  [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)  |  [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)  | 

Untuk informasi tentang berbagai keadaan kepatuhan patch yang mungkin Anda lihat dilaporkan, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md)

Untuk informasi tentang remediasi node terkelola yang tidak sesuai dengan patch, lihat[Menambal node terkelola yang tidak sesuai](patch-manager-compliance-remediation.md).

# Nilai status kepatuhan tambalan
<a name="patch-manager-compliance-states"></a>

Informasi tentang patch untuk node terkelola mencakup laporan status, atau status, dari setiap patch individu.

**Tip**  
Jika Anda ingin menetapkan status kepatuhan patch tertentu ke node terkelola, Anda dapat menggunakan perintah [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) atau operasi [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API. Penetapan keadaan kepatuhan tidak di-support di konsol.

Gunakan informasi dalam tabel berikut untuk membantu Anda mengidentifikasi mengapa node terkelola mungkin tidak sesuai dengan patch.

## Nilai kepatuhan tambalan untuk Debian Server dan Ubuntu Server
<a name="patch-compliance-values-ubuntu"></a>

Untuk Debian Server danUbuntu Server, aturan untuk klasifikasi paket ke dalam negara kepatuhan yang berbeda dijelaskan dalam tabel berikut.

**catatan**  
Ingatlah hal berikut saat mengevaluasi`INSTALLED`,`INSTALLED_OTHER`, dan nilai `MISSING` status: Jika Anda tidak memilih kotak centang **Sertakan pembaruan nonkeamanan** saat membuat atau memperbarui baseline tambalan, versi kandidat tambalan terbatas pada tambalan di repositori berikut:.   
Ubuntu Server16.04 LTS: `xenial-security`
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`
`debian-security` (Debian Server)
Jika Anda memilih kotak centang **Sertakan pembaruan non-keamanan**, patch dari repositori lain turut dipertimbangkan.


| Keadaan patch | Deskripsi | Status kepatuhan | 
| --- | --- | --- | 
|  **`INSTALLED`**  |  Patch terdaftar di baseline patch dan diinstal pada node terkelola. Itu bisa diinstal baik secara manual oleh individu atau secara otomatis Patch Manager ketika `AWS-RunPatchBaseline` dokumen dijalankan pada node yang dikelola.  | Patuh | 
|  **`INSTALLED_OTHER`**  |  Patch tidak disertakan dalam baseline atau tidak disetujui oleh baseline tetapi diinstal pada node terkelola. Patch mungkin telah diinstal secara manual, paket bisa menjadi ketergantungan yang diperlukan dari patch lain yang disetujui, atau patch mungkin telah disertakan dalam InstallOverrideList operasi. Jika Anda tidak menentukan `Block` sebagai tindakan **Patch ditolak**, patch `INSTALLED_OTHER` juga mencakup patch yang terinstal tetapi ditolak.   | Patuh | 
|  **`INSTALLED_PENDING_REBOOT`**  |  `INSTALLED_PENDING_REBOOT`dapat berarti salah satu dari dua hal: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-compliance-states.html) Dalam kedua kasus itu tidak berarti bahwa tambalan dengan status ini *memerlukan* reboot, hanya saja node belum di-boot ulang sejak tambalan diinstal.  | Tidak Patuh | 
|  **`INSTALLED_REJECTED`**  |  Patch diinstal pada node terkelola tetapi ditentukan dalam daftar **tambalan Ditolak**. Ini biasanya berarti patch telah diinstal sebelum ditambahkan ke daftar patch yang ditolak.  | Tidak Patuh | 
|  **`MISSING`**  |  Patch disetujui di baseline, tetapi tidak diinstal pada node terkelola. Jika Anda mengonfigurasi tugas dokumen `AWS-RunPatchBaseline` untuk memindai (bukan menginstal), sistem melaporkan status ini untuk patch yang diletakkan selama pemindaian tetapi belum diinstal.  | Tidak Patuh | 
|  **`FAILED`**  |  patch disetujui dalam baseline, tapi tidak dapat diinstal. Untuk memecahkan masalah situasi ini, tinjau output perintah untuk informasi yang mungkin membantu Anda memahami masalah.  | Tidak Patuh | 

## Nilai kepatuhan patch untuk sistem operasi lain
<a name="patch-compliance-values"></a>

Untuk semua sistem operasi selain Debian Server danUbuntu Server, aturan untuk klasifikasi paket ke dalam status kepatuhan yang berbeda dijelaskan dalam tabel berikut. 


|  Keadaan patch | Deskripsi | Nilai kepatuhan | 
| --- | --- | --- | 
|  **`INSTALLED`**  |  Patch terdaftar di baseline patch dan diinstal pada node terkelola. Itu bisa diinstal baik secara manual oleh individu atau secara otomatis Patch Manager ketika `AWS-RunPatchBaseline` dokumen dijalankan pada node.  | Patuh | 
|  **`INSTALLED_OTHER`**¹  |  Patch tidak ada di baseline, tetapi diinstal pada node terkelola. Ada dua kemungkinan alasan untuk ini: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-compliance-states.html)  | Patuh | 
|  **`INSTALLED_REJECTED`**  |  Patch diinstal pada node terkelola tetapi ditentukan dalam daftar tambalan yang ditolak. Ini biasanya berarti patch telah diinstal sebelum ditambahkan ke daftar patch yang ditolak.  | Tidak Patuh | 
|  **`INSTALLED_PENDING_REBOOT`**  |  `INSTALLED_PENDING_REBOOT`dapat berarti salah satu dari dua hal: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/patch-manager-compliance-states.html) Dalam kedua kasus itu tidak berarti bahwa tambalan dengan status ini *memerlukan* reboot, hanya saja node belum di-boot ulang sejak tambalan diinstal.  | Tidak Patuh | 
|  **`MISSING`**  |  Patch disetujui di baseline, tetapi tidak diinstal pada node terkelola. Jika Anda mengonfigurasi tugas dokumen `AWS-RunPatchBaseline` untuk memindai (bukan menginstal), sistem melaporkan status ini untuk patch yang diletakkan selama pemindaian tetapi belum diinstal.  | Tidak Patuh | 
|  **`FAILED`**  |  patch disetujui dalam baseline, tapi tidak dapat diinstal. Untuk memecahkan masalah situasi ini, tinjau output perintah untuk informasi yang mungkin membantu Anda memahami masalah.  | Tidak Patuh | 
|  **`NOT_APPLICABLE`**¹  |  *Status kepatuhan ini dilaporkan hanya untuk sistem Windows Server operasi.* Patch disetujui di baseline, tetapi layanan atau fitur yang menggunakan tambalan tidak diinstal pada node terkelola. Misalnya, patch untuk layanan server web seperti Internet Information Services (IIS) akan menunjukkan `NOT_APPLICABLE` apakah itu disetujui di baseline, tetapi layanan web tidak diinstal pada node terkelola. Sebuah patch juga dapat ditandai `NOT_APPLICABLE` jika telah digantikan oleh pembaruan berikutnya. Ini berarti bahwa pembaruan yang setelahnya diinstal dan pembaruan `NOT_APPLICABLE` tidak lagi diperlukan.  | Tidak berlaku | 
| AVAILABLE\$1SECURITY\$1UPDATES |  *Status kepatuhan ini dilaporkan hanya untuk sistem Windows Server operasi.* Patch pembaruan keamanan yang tersedia yang tidak disetujui oleh baseline patch dapat memiliki nilai kepatuhan `Compliant` atau`Non-Compliant`, seperti yang didefinisikan dalam baseline patch kustom. Saat Anda membuat atau memperbarui baseline patch, Anda memilih status yang ingin Anda tetapkan ke patch keamanan yang tersedia tetapi tidak disetujui karena tidak memenuhi kriteria instalasi yang ditentukan dalam baseline patch. Misalnya, patch keamanan yang mungkin ingin Anda instal dapat dilewati jika Anda telah menentukan jangka waktu yang lama untuk menunggu setelah patch dirilis sebelum instalasi. Jika pembaruan pada tambalan dirilis selama masa tunggu yang Anda tentukan, masa tunggu untuk menginstal tambalan dimulai lagi. Jika masa tunggu terlalu lama, beberapa versi patch dapat dirilis tetapi tidak pernah diinstal. Untuk hitungan ringkasan tambalan, ketika tambalan dilaporkan sebagai`AvailableSecurityUpdate`, itu akan selalu disertakan. `AvailableSecurityUpdateCount` Jika baseline dikonfigurasi untuk melaporkan patch ini sebagai`NonCompliant`, itu juga termasuk dalam. `SecurityNonCompliantCount` Jika baseline dikonfigurasi untuk melaporkan patch ini sebagai`Compliant`, mereka tidak termasuk dalam. `SecurityNonCompliantCount` Tambalan ini selalu dilaporkan dengan tingkat keparahan yang tidak ditentukan dan tidak pernah disertakan dalam. `CriticalNonCompliantCount`  |  Compliant atau Non-Compliant, tergantung pada opsi yang dipilih untuk pembaruan keamanan yang tersedia.  Menggunakan konsol untuk membuat atau memperbarui garis dasar tambalan, Anda menentukan opsi ini di bidang **Status kepatuhan pembaruan keamanan yang tersedia**. Menggunakan AWS CLI untuk menjalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)perintah [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)or, Anda menentukan opsi ini dalam `available-security-updates-compliance-status` parameter.   | 

¹ Untuk tambalan dengan status `INSTALLED_OTHER` dan`NOT_APPLICABLE`, Patch Manager menghilangkan beberapa data dari hasil kueri berdasarkan [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html)perintah, seperti nilai untuk `Classification` dan. `Severity` Hal ini dilakukan untuk membantu mencegah melebihi batas data untuk node individu di Inventory, alat di AWS Systems Manager. Untuk melihat semua detail tambalan, Anda dapat menggunakan [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html)perintah. 

# Menambal node terkelola yang tidak sesuai
<a name="patch-manager-compliance-remediation"></a>

Banyak AWS Systems Manager alat dan proses yang sama yang dapat Anda gunakan untuk memeriksa node terkelola untuk kepatuhan patch dapat digunakan untuk membuat node sesuai dengan aturan tambalan yang saat ini berlaku untuk mereka. Untuk membawa node terkelola ke dalam kepatuhan patchPatch Manager,, alat di AWS Systems Manager, harus menjalankan `Scan and install` operasi. (Jika tujuan Anda hanya untuk mengidentifikasi node terkelola yang tidak sesuai dan tidak memperbaikinya, jalankan operasi sebagai `Scan` gantinya. Untuk informasi lebih lanjut, lihat[Mengidentifikasi node terkelola yang tidak sesuai](patch-manager-find-noncompliant-nodes.md).)

**Instal patch menggunakan Systems Manager**  
Anda dapat memilih dari beberapa alat untuk menjalankan operasi `Scan and install`:
+ (Disarankan) Konfigurasikan kebijakan tambalan diQuick Setup, alat di Systems Manager, yang memungkinkan Anda menginstal tambalan yang hilang pada jadwal untuk seluruh organisasi, subset unit organisasi, atau satu. Akun AWS Untuk informasi selengkapnya, lihat [Mengonfigurasi penambalan untuk instance di organisasi menggunakan kebijakan tambalan Quick Setup](quick-setup-patch-manager.md).
+ Buat jendela pemeliharaan yang menggunakan dokumen Systems Manager (dokumen SSM) `AWS-RunPatchBaseline` dalam tipe Run Command tugas. Untuk informasi, lihat [Tutorial: Buat jendela pemeliharaan untuk menambal menggunakan konsol](maintenance-window-tutorial-patching.md).
+ Jalankan secara manual `AWS-RunPatchBaseline` dalam suatu Run Command operasi. Untuk informasi, lihat [Menjalankan perintah dari konsol](running-commands-console.md).
+ Instal patch sesuai permintaan menggunakan opsi **Patch sekarang**. Untuk informasi, lihat [Menambal node terkelola sesuai permintaan](patch-manager-patch-now-on-demand.md).

# Mengidentifikasi eksekusi yang membuat data kepatuhan patch
<a name="patch-manager-compliance-data-overwrites"></a>

Data kepatuhan tambalan mewakili point-in-time snapshot dari operasi patching terbaru yang berhasil. Setiap laporan kepatuhan mencakup ID eksekusi dan waktu pengambilan yang membantu Anda mengidentifikasi operasi mana yang membuat data kepatuhan dan kapan dibuat.

Jika Anda memiliki beberapa jenis operasi untuk memindai instans Anda untuk kepatuhan patch, setiap pemindaian menimpa data kepatuhan patch dari pemindaian sebelumnya. Akibatnya, Anda mungkin berakhir dengan hasil yang tidak terduga dalam data kepatuhan patch Anda.

Misalnya, Anda membuat kebijakan tambalan yang memindai kepatuhan patch setiap hari pada pukul 2 pagi waktu setempat. Kebijakan tambalan itu menggunakan garis dasar tambalan yang menargetkan tambalan dengan tingkat keparahan yang ditandai sebagai`Critical`,, `Important` dan. `Moderate` Garis dasar tambalan ini juga menentukan beberapa tambalan yang ditolak secara khusus. 

Juga misalkan Anda sudah memiliki jendela pemeliharaan yang disiapkan untuk memindai kumpulan node terkelola yang sama setiap hari pada pukul 4 pagi waktu setempat, yang tidak Anda hapus atau nonaktifkan. Tugas jendela pemeliharaan itu menggunakan baseline tambalan yang berbeda, tugas yang hanya menargetkan tambalan dengan `Critical` tingkat keparahan dan tidak mengecualikan tambalan tertentu. 

Ketika pemindaian kedua ini dilakukan oleh jendela pemeliharaan, data kepatuhan patch dari pemindaian pertama dihapus dan diganti dengan kepatuhan patch dari pemindaian kedua. 

Oleh karena itu, kami sangat menyarankan hanya menggunakan satu metode otomatis untuk memindai dan menginstal dalam operasi penambalan Anda. Jika Anda menyiapkan kebijakan tambalan, Anda harus menghapus atau menonaktifkan metode pemindaian lain untuk kepatuhan tambalan. Untuk informasi selengkapnya, lihat topik berikut: 
+ Untuk menghapus tugas operasi tambalan dari jendela pemeliharaan - [Memperbarui atau membatalkan pendaftaran tugas jendela pemeliharaan menggunakan konsol](sysman-maintenance-update.md#sysman-maintenance-update-tasks) 
+ Untuk menghapus State Manager asosiasi —[Menghapus asosiasi](systems-manager-state-manager-delete-association.md).

Untuk menonaktifkan pemindaian kepatuhan patch harian dalam konfigurasi Manajemen Host, lakukan hal berikut di: Quick Setup

1. Di panel navigasi, pilih **Quick Setup**.

1. Pilih konfigurasi Manajemen Host untuk diperbarui.

1. Pilih **Tindakan, Edit konfigurasi**.

1. Kosongkan kotak centang **instance Pindai untuk patch yang hilang setiap hari**.

1. Pilih **Perbarui**.

**catatan**  
Menggunakan opsi **Patch now** untuk memindai node terkelola untuk kepatuhan juga menghasilkan penimpaan data kepatuhan patch. 

# Menambal node terkelola sesuai permintaan
<a name="patch-manager-patch-now-on-demand"></a>

Menggunakan opsi **Patch now** diPatch Manager, alat di AWS Systems Manager, Anda dapat menjalankan operasi patching sesuai permintaan dari konsol Systems Manager. Ini berarti Anda tidak perlu membuat jadwal untuk memperbarui status kepatuhan node terkelola Anda atau untuk menginstal tambalan pada node yang tidak sesuai. Anda juga tidak perlu mengganti konsol Systems Manager antara Patch Manager danMaintenance Windows, alat di AWS Systems Manager, untuk mengatur atau memodifikasi jendela patching terjadwal.

**Patch sekarang** sangat berguna ketika Anda harus menerapkan pembaruan zero-day atau menginstal patch penting lainnya pada node terkelola Anda sesegera mungkin.

**catatan**  
Penambalan sesuai permintaan didukung untuk satu Akun AWSWilayah AWS pasangan sekaligus. Itu tidak dapat digunakan dengan operasi penambalan yang didasarkan pada *kebijakan tambalan*. Sebaiknya gunakan kebijakan tambalan untuk menjaga agar semua node terkelola tetap sesuai. Untuk informasi selengkapnya tentang bekerja dengan kebijakan tambalan, lihat[Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).

**Topics**
+ [Cara kerja 'Patch sekarang'](#patch-on-demand-how-it-works)
+ [Menjalankan 'Patch sekarang'](#run-patch-now)

## Cara kerja 'Patch sekarang'
<a name="patch-on-demand-how-it-works"></a>

Untuk menjalankan **Patch sekarang**, Anda hanya menentukan dua pengaturan yang diperlukan:
+ Apakah akan memindai patch yang hilang saja, atau untuk memindai *dan* menginstal tambalan pada node terkelola Anda
+ Yang mengelola node untuk menjalankan operasi pada

Ketika operasi **Patch sekarang** berjalan, ini menentukan baseline patch mana yang akan digunakan dengan cara yang sama yang dipilih untuk operasi patching lainnya. Jika node terkelola dikaitkan dengan grup tambalan, baseline patch yang ditentukan untuk grup tersebut akan digunakan. Jika node terkelola tidak terkait dengan grup patch, operasi menggunakan baseline patch yang saat ini ditetapkan sebagai default untuk jenis sistem operasi dari node terkelola. Ini bisa berupa baseline yang telah ditentukan sebelumnya, atau baseline kustom yang telah Anda tetapkan sebagai default. Untuk informasi lebih lanjut tentang pemilihan dasar tambalan, lihat. [Grup tambalan](patch-manager-patch-groups.md) 

Opsi yang dapat Anda tentukan untuk **Patch sekarang** termasuk memilih kapan, atau apakah, untuk me-reboot node terkelola setelah menambal, menentukan bucket Amazon Simple Storage Service (Amazon S3) untuk menyimpan data log untuk operasi penambalan, dan menjalankan dokumen Systems Manager (dokumen SSM) sebagai kait siklus hidup selama penambalan.

### Ambang batas konkurensi dan kesalahan untuk 'Patch sekarang'
<a name="patch-on-demand-concurrency"></a>

Untuk operasi **Patch now**, opsi konkurensi dan ambang kesalahan ditangani oleh. Patch Manager Anda tidak perlu menentukan berapa banyak node terkelola untuk ditambal sekaligus, atau berapa banyak kesalahan yang diizinkan sebelum operasi gagal. Patch Managermenerapkan pengaturan ambang konkurensi dan kesalahan yang dijelaskan dalam tabel berikut saat Anda menambal sesuai permintaan.

**penting**  
Ambang batas berikut hanya berlaku untuk `Scan and install` operasi. Untuk `Scan` operasi, Patch Manager mencoba memindai hingga 1.000 node secara bersamaan, dan lanjutkan pemindaian hingga mengalami hingga 1.000 kesalahan.


**Konkurensi: Instal operasi**  

| Jumlah total node terkelola dalam operasi **Patch sekarang** | Jumlah node terkelola yang dipindai atau ditambal pada suatu waktu | 
| --- | --- | 
| Kurang dari 25 | 1 | 
| 25-100 | 5% | 
| 101 hingga 1.000 | 8% | 
| Lebih dari 1.000 | 10% | 


**Ambang kesalahan: Instal operasi**  

| Jumlah total node terkelola dalam operasi **Patch sekarang** | Jumlah kesalahan yang diizinkan sebelum operasi gagal | 
| --- | --- | 
| Kurang dari 25 | 1 | 
| 25-100 | 5 | 
| 101 hingga 1.000 | 10 | 
| Lebih dari 1.000 | 10 | 

### Menggunakan kait siklus hidup 'Patch sekarang'
<a name="patch-on-demand-hooks"></a>

**Patch sekarang** memberi Anda kemampuan untuk menjalankan dokumen Perintah SSM sebagai kait siklus hidup selama operasi penambalan. `Install` Anda dapat menggunakan kait ini untuk tugas-tugas seperti mematikan aplikasi sebelum menambal atau menjalankan pemeriksaan kesehatan pada aplikasi Anda setelah menambal atau setelah reboot. 

Untuk informasi selengkapnya tentang penggunaan kait siklus hidup, lihat. [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)

Tabel berikut mencantumkan kait siklus hidup yang tersedia untuk masing-masing dari tiga opsi **Patch now** reboot, selain penggunaan sampel untuk setiap hook.


**Kait siklus hidup dan penggunaan sampel**  

| Opsi reboot | Hook: Sebelum instalasi | Hook: Setelah instalasi | Hook: Saat keluar | Hook: Setelah dijadwalkan reboot | 
| --- | --- | --- | --- | --- | 
| Reboot jika diperlukan |  Jalankan dokumen SSM sebelum penambalan dimulai. Contoh penggunaan: Matikan aplikasi dengan aman sebelum proses patching dimulai.   |  Jalankan dokumen SSM di akhir operasi patching dan sebelum reboot node terkelola. Contoh penggunaan: Jalankan operasi seperti menginstal aplikasi pihak ketiga sebelum reboot potensial.  |  Jalankan dokumen SSM setelah operasi patching selesai dan instance di-reboot. Contoh penggunaan: Pastikan aplikasi berjalan seperti yang diharapkan setelah patch.  | Tidak tersedia | 
| Jangan reboot instance saya | Sama seperti di atas. |  Jalankan dokumen SSM di akhir operasi patching. Contoh penggunaan: Pastikan aplikasi berjalan seperti yang diharapkan setelah patch.  |  *Tidak tersedia*   |  *Tidak tersedia*   | 
| Jadwalkan waktu reboot | Sama seperti di atas. | Sama seperti untuk Jangan reboot instance saya. | Tidak tersedia |  Jalankan dokumen SSM segera setelah reboot terjadwal selesai. Contoh penggunaan: Pastikan aplikasi berjalan seperti yang diharapkan setelah reboot.  | 

## Menjalankan 'Patch sekarang'
<a name="run-patch-now"></a>

Gunakan prosedur berikut untuk menambal node terkelola Anda sesuai permintaan.

**Untuk menjalankan 'Patch sekarang'**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih **Patch sekarang**.

1. Untuk **Operasi patching**, pilih salah satu hal berikut:
   + **Pindai**: Patch Manager menemukan tambalan mana yang hilang dari node terkelola Anda tetapi tidak menginstalnya. Anda dapat melihat hasil di dasbor **Kepatuhan** atau alat lain yang Anda gunakan untuk melihat kepatuhan patch.
   + **Pindai dan instal**: Patch Manager menemukan tambalan mana yang hilang dari node terkelola Anda dan menginstalnya.

1. Gunakan langkah ini hanya jika Anda memilih **Pindai dan instal** pada langkah sebelumnya. Untuk **Opsi reboot**, pilih salah satu hal berikut:
   + **Reboot jika diperlukan**: Setelah instalasi, Patch Manager reboot node terkelola hanya jika diperlukan untuk menyelesaikan instalasi patch.
   + **Jangan reboot instance saya**: Setelah instalasi, Patch Manager tidak me-reboot node yang dikelola. Anda dapat me-reboot node secara manual ketika Anda memilih atau mengelola reboot di luar. Patch Manager
   + **Jadwalkan waktu reboot**: Tentukan tanggal, waktu, dan zona waktu UTC Patch Manager untuk me-reboot node terkelola Anda. Setelah Anda menjalankan operasi **Patch now**, reboot terjadwal terdaftar sebagai asosiasi State Manager dengan nama`AWS-PatchRebootAssociation`.
**penting**  
Jika Anda membatalkan operasi penambalan utama setelah dimulai, `AWS-PatchRebootAssociation` asosiasi di State Manager TIDAK dibatalkan secara otomatis. Untuk mencegah reboot yang tidak terduga, Anda harus menghapus `AWS-PatchRebootAssociation` secara manual State Manager jika Anda tidak lagi ingin reboot terjadwal terjadi. Kegagalan untuk melakukannya dapat mengakibatkan reboot sistem yang tidak direncanakan yang dapat memengaruhi beban kerja produksi. Anda dapat menemukan asosiasi ini di konsol Systems Manager di bawah **State Manager**> **Associations**.

1. Untuk **Instans untuk di-patch**, pilih salah satu hal berikut:
   + **Patch semua instance**: Patch Manager menjalankan operasi yang ditentukan pada semua node terkelola Akun AWS di Anda saat ini Wilayah AWS.
   + **Hanya menambal instance target yang saya tentukan**: Anda menentukan node terkelola mana yang akan ditargetkan pada langkah berikutnya.

1. Gunakan langkah ini hanya jika Anda memilih **Patch instans target yang saya tentukan saja** di langkah sebelumnya. Di bagian **Pemilihan target**, identifikasi node tempat Anda ingin menjalankan operasi ini dengan menentukan tag, memilih node secara manual, atau menentukan grup sumber daya.
**catatan**  
Jika node terkelola yang Anda harapkan tidak terdaftar, lihat [Memecahkan masalah ketersediaan node terkelola](fleet-manager-troubleshooting-managed-nodes.md) untuk tips pemecahan masalah.  
Jika Anda memilih untuk menargetkan grup sumber daya, perhatikan bahwa grup sumber daya yang didasarkan pada AWS CloudFormation tumpukan harus tetap ditandai dengan `aws:cloudformation:stack-id` tag default. Jika telah dihapus, Patch Manager mungkin tidak dapat menentukan node terkelola mana yang termasuk dalam grup sumber daya.

1. (Opsional) Untuk **Penyimpanan log patching**, jika Anda ingin membuat dan menyimpan log dari operasi patching ini, pilih bucket S3 untuk menyimpan log.
**catatan**  
Izin S3 yang memberikan kemampuan untuk menulis data ke bucket S3 adalah izin profil instans (untuk instans EC2) atau peran layanan IAM (mesin yang diaktifkan hibrida) yang ditetapkan ke instance, bukan milik pengguna IAM yang melakukan tugas ini. Untuk informasi selengkapnya, lihat [Mengonfigurasi izin instans yang diperlukan untuk Systems Manager](setup-instance-permissions.md) atau [Membuat peran layanan IAM yang diperlukan untuk Systems Manager di lingkungan hybrid dan multicloud](hybrid-multicloud-service-role.md). Selain itu, jika bucket S3 yang ditentukan berbeda Akun AWS, pastikan bahwa profil instance atau peran layanan IAM yang terkait dengan node terkelola memiliki izin yang diperlukan untuk menulis ke bucket tersebut.

1. (Opsional) Jika Anda ingin menjalankan dokumen SSM sebagai kait siklus hidup selama titik tertentu dari operasi patching, lakukan hal berikut:
   + Pilih **Gunakan kait siklus hidup**.
   + Untuk setiap kait yang tersedia, pilih dokumen SSM untuk dijalankan pada titik operasi yang ditentukan:
     + Sebelum instalasi
     + Setelah instalasi
     + Saat keluar
     + Setelah reboot terjadwal
**catatan**  
Dokumen default, `AWS-Noop`, tidak menjalankan operasi apa pun.

1. Pilih **Patch sekarang**.

   Halaman **Ringkasan eksekusi asosiasi** terbuka. (Patch sekarang menggunakan asosiasi diState Manager, alat di AWS Systems Manager, untuk operasinya.) Di area **ringkasan Operasi**, Anda dapat memantau status pemindaian atau penambalan pada node terkelola yang Anda tentukan.

# Bekerja dengan baseline patch
<a name="patch-manager-create-a-patch-baseline"></a>

Sebuah patch baseline inPatch Manager, alat di AWS Systems Manager, mendefinisikan patch mana yang disetujui untuk instalasi pada node terkelola Anda. Anda dapat menentukan patch yang disetujui atau ditolak satu per satu. Anda juga dapat membuat aturan persetujuan otomatis untuk menentukan bahwa jenis pembaruan tertentu (misalnya, pembaruan penting) harus disetujui secara otomatis. Daftar yang ditolak menggantikan aturan dan daftar persetujuan. Untuk menggunakan daftar patch yang disetujui untuk menginstal paket tertentu, pertama-tama Anda menghapus semua aturan persetujuan otomatis. Jika Anda secara eksplisit mengidentifikasi patch sebagai ditolak, patch tidak akan disetujui atau diinstal, bahkan jika cocok dengan semua kriteria dalam aturan persetujuan otomatis. Juga, tambalan diinstal pada node terkelola hanya jika itu berlaku untuk perangkat lunak pada node, bahkan jika patch tersebut telah disetujui untuk node terkelola.

**Topics**
+ [Melihat AWS baseline patch yang telah ditentukan](patch-manager-view-predefined-patch-baselines.md)
+ [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md)
+ [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md)

**Info lebih lanjut**  
+ [Garis dasar patch](patch-manager-patch-baselines.md)

# Melihat AWS baseline patch yang telah ditentukan
<a name="patch-manager-view-predefined-patch-baselines"></a>

Patch Manager, alat di AWS Systems Manager, termasuk baseline patch yang telah ditentukan untuk setiap sistem operasi yang didukung oleh. Patch Manager Anda dapat menggunakan dasar patch ini (Anda tidak dapat menyesuaikannya), atau Anda dapat membuat milik Anda sendiri. Prosedur berikut ini menjelaskan cara melihat dasar patch yang telah ditetapkan untuk melihat apakah memenuhi kebutuhan Anda. Untuk mempelajari selengkapnya tentang dasar patch, lihat [Garis dasar patch yang telah ditentukan dan kustom](patch-manager-predefined-and-custom-patch-baselines.md).

**Untuk melihat garis dasar AWS tambalan yang telah ditentukan**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Dalam daftar dasar patch, pilih ID baseline dari salah satu dasar patch yang telah ditetapkan.

   -atau-

   Jika Anda mengakses Patch Manager untuk pertama kalinya saat ini Wilayah AWS, pilih **Mulai dengan ikhtisar**, pilih tab **Garis dasar Patch, lalu pilih ID dasar** dari salah satu garis dasar tambalan yang telah ditentukan.
**catatan**  
Untuk Windows Server, disediakan tiga dasar patch yang telah ditetapkan. Garis dasar patch `AWS-DefaultPatchBaseline` dan hanya `AWS-WindowsPredefinedPatchBaseline-OS` mendukung pembaruan sistem operasi pada sistem operasi Windows itu sendiri. `AWS-DefaultPatchBaseline`digunakan sebagai baseline patch default untuk node Windows Server terkelola kecuali Anda menentukan baseline patch yang berbeda. Pengaturan konfigurasi di dua dasar patch ini sama. Yang lebih baru dari keduanya, `AWS-WindowsPredefinedPatchBaseline-OS`, dibuat untuk membedakannya dari dasar patch ketiga yang telah ditetapkan untuk Windows Server. Dasar patch tersebut, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, dapat digunakan untuk menerapkan patch ke ke sistem operasi Windows Server dan aplikasi yang didukung yang dirilis oleh Microsoft.  
Untuk informasi selengkapnya, lihat [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md).

1. Di bagian **Aturan persetujuan**, tinjau konfigurasi baseline patch.

1. Jika konfigurasi dapat diterima untuk node terkelola Anda, Anda dapat langsung melanjutkan ke prosedur[Membuat dan mengelola grup patch](patch-manager-tag-a-patch-group.md). 

   -atau-

   Untuk membuat dasar patch default Anda sendiri, lanjutkan ke topik [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md).

# Bekerja dengan dasar patch kustom
<a name="patch-manager-manage-patch-baselines"></a>

Patch Manager, alat di AWS Systems Manager, termasuk baseline patch yang telah ditentukan untuk setiap sistem operasi yang didukung oleh. Patch Manager Anda dapat menggunakan dasar patch ini (Anda tidak dapat menyesuaikannya), atau Anda dapat membuat milik Anda sendiri. 

Prosedur berikut ini menjelaskan cara membuat, memperbarui, dan menghapus dasar patch kustom Anda sendiri. Untuk mempelajari selengkapnya tentang dasar patch, lihat [Garis dasar patch yang telah ditentukan dan kustom](patch-manager-predefined-and-custom-patch-baselines.md).

**Topics**
+ [Membuat baseline patch khusus untuk Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Membuat baseline patch khusus untuk macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Membuat baseline patch khusus untuk Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Memperbarui atau menghapus baseline patch kustom](patch-manager-update-or-delete-a-patch-baseline.md)

# Membuat baseline patch khusus untuk Linux
<a name="patch-manager-create-a-patch-baseline-for-linux"></a>

Gunakan prosedur berikut untuk membuat baseline patch khusus untuk node yang dikelola Linux diPatch Manager, alat di. AWS Systems Manager

Untuk informasi tentang membuat baseline patch untuk node macOS terkelola, lihat. [Membuat baseline patch khusus untuk macOS](patch-manager-create-a-patch-baseline-for-macos.md) Untuk informasi tentang membuat baseline patch untuk node terkelola Windows, lihat. [Membuat baseline patch khusus untuk Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)

**Untuk membuat baseline patch khusus untuk node yang dikelola Linux**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch baseline**, lalu pilih **Create patch** baseline.

   -atau-

   Jika Anda mengakses Patch Manager untuk pertama kalinya saat ini Wilayah AWS, pilih **Mulai dengan ikhtisar**, pilih tab **Garis dasar Patch, lalu pilih **Buat** baseline** patch.

1. Untuk **Nama**, masukkan nama untuk dasar patch baru Anda, misalnya, `MyRHELPatchBaseline`.

1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk dasar patch ini.

1. Untuk **Sistem operasi**, pilih suatu sistem operasi, misalnya, `Red Hat Enterprise Linux`.

1. Jika Anda ingin mulai menggunakan baseline patch ini sebagai default untuk sistem operasi yang dipilih segera setelah Anda membuatnya, centang kotak di sebelah **Setel baseline patch ini sebagai baseline patch default** untuk instance. *operating system name*
**catatan**  
Opsi ini hanya tersedia jika Anda pertama kali mengakses Patch Manager sebelum [kebijakan tambalan](patch-manager-policies.md) dirilis pada 22 Desember 2022.  
Untuk informasi tentang mengatur dasar patch yang ada sebagai default, lihat [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md).

1. Di bagian **Aturan persetujuan untuk sistem operasi**, gunakan bidang tersebut untuk membuat satu atau lebih aturan persetujuan otomatis.
   + **Produk**: Versi sistem operasi yang berlaku untuk aturan persetujuan, seperti`RedhatEnterpriseLinux7.4`. Pilihan default adalah `All`.
   + **Klasifikasi**: Jenis patch yang diberlakukan aturan persetujuan, seperti `Security` atau `Enhancement`. Pilihan default adalah `All`. 
**Tip**  
Anda dapat mengonfigurasi baseline patch untuk mengontrol apakah upgrade versi minor untuk Linux diinstal, seperti 7.8. RHEL Upgrade versi minor dapat diinstal secara otomatis dengan Patch Manager asalkan pembaruan tersedia di repositori yang sesuai.  
Untuk sistem operasi Linux, pemutakhiran versi minor tidak diklasifikasikan secara konsisten. Mereka dapat diklasifikasikan sebagai perbaikan bug atau pembaruan keamanan, atau tidak diklasifikasikan, bahkan dalam versi kernel yang sama. Berikut ini adalah beberapa pilihan untuk mengendalikan apakah dasar patch menginstalnya.   
**Opsi 1**: Aturan persetujuan terluas untuk memastikan pemutakhiran versi minor diinstal ketika tersedia adalah dengan menentukan **Klasifikasi** sebagai `All` (\$1) dan pilih opsi **Sertakan pembaruan non-keamanan**.
**Opsi 2**: Untuk memastikan patch untuk versi sistem operasi diinstal, Anda dapat menggunakan wildcard (\$1) untuk menentukan format kernel di bagian **Pengecualian patch** dari baseline. Sebagai contoh, format kernel untuk RHEL 7.\$1 adalah `kernel-3.10.0-*.el7.x86_64`.  
Masukkan `kernel-3.10.0-*.el7.x86_64` daftar **Patch yang disetujui** di baseline patch Anda untuk memastikan semua tambalan, termasuk peningkatan versi minor, diterapkan ke node terkelola 7.\$1 Anda. RHEL (Jika Anda tahu persis nama paket dari patch versi minor, Anda dapat memasukkan itu sebagai gantinya.)
**Opsi 3**: Anda dapat memiliki kontrol paling besar atas tambalan mana yang diterapkan ke node terkelola Anda, termasuk peningkatan versi minor, dengan menggunakan [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)parameter dalam dokumen. `AWS-RunPatchBaseline` Untuk informasi selengkapnya, lihat [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
   + **Kepelikan**: Nilai kepelikan patch yang diberlakukan aturan, seperti `Critical`. Pilihan default adalah `All`. 
   + **Persetujuan otomatis**: Metode untuk memilih patch untuk persetujuan otomatis.
**catatan**  
Karena tidak mungkin menentukan tanggal rilis paket pembaruan secara andalUbuntu Server, opsi persetujuan otomatis tidak didukung untuk sistem operasi ini.
     + **Menyetujui patch setelah beberapa hari tertentu**: Jumlah hari Patch Manager untuk menunggu setelah patch dirilis atau terakhir diperbarui sebelum patch secara otomatis disetujui. Anda dapat memasukkan bilangan bulat apa saja dari nol (0) sampai 360. Untuk sebagian besar skenario, kami merekomendasikan untuk menunggu tidak lebih dari 100 hari.
     + **Menyetujui patch yang dirilis hingga tanggal tertentu: Tanggal** rilis patch yang Patch Manager secara otomatis menerapkan semua patch yang dirilis atau diperbarui pada atau sebelum tanggal tersebut. Misalnya, jika Anda menentukan 7 Juli 2023, tidak ada tambalan yang dirilis atau terakhir diperbarui pada atau setelah 8 Juli 2023, yang diinstal secara otomatis.
   + (Opsional) **Pelaporan kepatuhan**: Tingkat keparahan yang ingin Anda tetapkan ke tambalan yang disetujui oleh baseline, seperti atau. `Critical` `High`
**catatan**  
Jika Anda menentukan tingkat pelaporan kepatuhan dan status patch dari setiap patch yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan yang dilaporkan secara keseluruhan baseline patch adalah tingkat keparahan yang Anda tentukan.
   + **Sertakan pembaruan non-keamanan**: Pilih kotak centang untuk menginstal patch sistem operasi Linux non-keamanan yang tersedia di repositori sumber, selain patch terkait keamanan. 

   Untuk informasi selengkapnya tentang bekerja dengan aturan persetujuan di dasar patch kustom, lihat [Garis dasar kustom](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. Jika Anda ingin secara eksplisit menyetujui patch lain selain yang memenuhi aturan persetujuan Anda, lakukan hal berikut di bagian **Pengecualian patch**:
   + Untuk **Patch yang disetujui**, masukkan daftar patch yang dipisahkan koma yang ingin Anda setujui.

     Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
   + (Opsional) Untuk **Tingkat kepatuhan patch yang disetujui**, tetapkan tingkat kepatuhan pada patch dalam daftar.
   + Jika ada patch yang disetujui yang Anda tentukan tidak terkait dengan keamanan, pilih kotak centang **Sertakan pembaruan non-keamanan** untuk tambalan ini yang akan diinstal pada sistem operasi Linux Anda juga.

1. Jika Anda ingin secara eksplisit menolak patch lain selain yang memenuhi aturan persetujuan Anda, lakukan hal berikut di bagian **Pengecualian patch**:
   + Untuk **Patch yang ditolak**, masukkan daftar patch yang dipisahkan koma yang ingin Anda tolak.

     Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
   + Untuk **tindakan tambalan Ditolak**, pilih tindakan yang akan diambil pada tambalan yang disertakan dalam daftar tambalan **Ditolak**. Patch Manager
     + **Diizinkan sebagai dependensi**: Sebuah paket di daftar **Patch yang ditolak** diinstal hanya jika merupakan dependensi dari paket lain. Ini dianggap sesuai dengan baseline patch dan statusnya dilaporkan sebagai. *InstalledOther* Ini adalah tindakan default jika tidak ada pilihan yang ditentukan.
     + **Blokir**: Paket dalam daftar **tambalan Ditolak**, dan paket yang menyertakannya sebagai dependensi, tidak diinstal dalam Patch Manager keadaan apa pun. Jika sebuah paket diinstal sebelum ditambahkan ke daftar **tambalan Ditolak**, atau diinstal di luar Patch Manager sesudahnya, paket tersebut dianggap tidak sesuai dengan garis dasar tambalan dan statusnya dilaporkan sebagai. *InstalledRejected*
**catatan**  
Patch Managermencari dependensi tambalan secara rekursif.

1. **(Opsional) Jika Anda ingin menentukan repositori patch alternatif untuk versi sistem operasi yang berbeda, seperti *AmazonLinux2016.03 dan *AmazonLinux2017.09**, lakukan hal berikut untuk setiap produk di bagian Sumber Patch:**
   + Di **Nama**, masukkan nama untuk membantu Anda mengidentifikasi konfigurasi sumber.
   + Di **Produk**, pilih versi sistem operasi yang digunakan untuk repositori sumber patch, seperti `RedhatEnterpriseLinux7.4`.
   + Dalam **Konfigurasi**, masukkan nilai konfigurasi repositori untuk digunakan dalam format yang sesuai:

------
#### [  Example for yum repositories  ]

     ```
     [main]
     name=MyCustomRepository
     baseurl=https://my-custom-repository
     enabled=1
     ```

**Tip**  
Untuk informasi tentang opsi lain yang tersedia untuk konfigurasi repositori yum Anda, lihat [dnf.conf (5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).

------
#### [  Examples for Ubuntu Server and Debian Server ]

      `deb http://security.ubuntu.com/ubuntu jammy main` 

      `deb https://site.example.com/debian distribution component1 component2 component3` 

     Informasi repo untuk Ubuntu Server repositori harus ditentukan dalam satu baris. [https://wiki.debian.org/SourcesList#sources.list_format](https://wiki.debian.org/SourcesList#sources.list_format)

------

     Pilih **Tambah sumber lain** untuk menentukan repositori sumber untuk setiap versi sistem operasi tambahan, hingga maksimum 20.

     Untuk informasi selengkapnya tentang repositori patch sumber alternatif, lihat [Cara menentukan repositori sumber patch alternatif (Linux)](patch-manager-alternative-source-repository.md).

1. (Opsional) Untuk **Kelola tag**, terapkan satu atau beberapa name/value pasangan kunci tag ke baseline patch.

   Tanda adalah metadata opsional yang Anda tetapkan ke sumber daya. Tag memungkinkan Anda untuk mengkategorikan sumber daya dengan berbagai cara, seperti berdasarkan tujuan, pemilik, atau lingkungan. Sebagai contoh, Anda mungkin ingin menandai dasar patch untuk mengidentifikasi tingkat kepelikan patch yang ditentukannya, keluarga sistem operasi tempat patch diterapkan, dan jenis lingkungan. Dalam hal ini, Anda dapat menentukan tag yang mirip dengan name/value pasangan kunci berikut:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Pilih **Buat dasar patch**.

# Membuat baseline patch khusus untuk macOS
<a name="patch-manager-create-a-patch-baseline-for-macos"></a>

Gunakan prosedur berikut untuk membuat baseline patch khusus untuk node macOS terkelola diPatch Manager, alat di. AWS Systems Manager

Untuk informasi tentang membuat baseline patch untuk node Windows Server terkelola, lihat. [Membuat baseline patch khusus untuk Windows Server](patch-manager-create-a-patch-baseline-for-windows.md) Untuk informasi tentang membuat baseline patch untuk node terkelola Linux, lihat. [Membuat baseline patch khusus untuk Linux](patch-manager-create-a-patch-baseline-for-linux.md) 

**catatan**  
macOStidak didukung sama sekali Wilayah AWS. Untuk informasi selengkapnya tentang dukungan Amazon EC2macOS, lihat instans [Amazon EC2 Mac](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) di Panduan Pengguna Amazon *EC2*.

**Untuk membuat baseline patch kustom untuk macOS node terkelola**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch baseline**, lalu pilih **Create patch** baseline.

   -atau-

   Jika Anda mengakses Patch Manager untuk pertama kalinya saat ini Wilayah AWS, pilih **Mulai dengan ikhtisar**, pilih tab **Garis dasar Patch, lalu pilih **Buat** baseline** patch.

1. Untuk **Nama**, masukkan nama untuk dasar patch baru Anda, misalnya, `MymacOSPatchBaseline`.

1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk dasar patch ini.

1. Untuk **Sistem operasi**, pilih macOS.

1. Jika Anda ingin mulai menggunakan dasar patch ini sebagai default untuk macOS segera setelah Anda membuatnya, centang kotak di sebelah **Atur dasar patch ini sebagai dasar patch default untuk instans macOS**.
**catatan**  
Opsi ini hanya tersedia jika Anda pertama kali mengakses Patch Manager sebelum [kebijakan tambalan](patch-manager-policies.md) dirilis pada 22 Desember 2022.  
Untuk informasi tentang mengatur dasar patch yang ada sebagai default, lihat [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md).

1. Di bagian **Aturan persetujuan untuk sistem operasi**, gunakan bidang tersebut untuk membuat satu atau lebih aturan persetujuan otomatis.
   + **Produk**: Versi sistem operasi yang berlaku untuk aturan persetujuan, seperti `BigSur11.3.1` atau`Ventura13.7`. Pilihan default adalah `All`.
   + **Klasifikasi**: Pengelola paket atau beberapa pengelola paket yang Anda ingin terapkan paket selama proses patching. Anda memilih dari yang berikut ini:
     + softwareupdate
     + installer
     + brew
     + brew cask

     Pilihan default adalah `All`. 
   + (Opsional) **Pelaporan kepatuhan**: Tingkat keparahan yang ingin Anda tetapkan ke tambalan yang disetujui oleh baseline, seperti atau. `Critical` `High`
**catatan**  
Jika Anda menentukan tingkat pelaporan kepatuhan dan status patch dari setiap patch yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan yang dilaporkan secara keseluruhan baseline patch adalah tingkat keparahan yang Anda tentukan.

   Untuk informasi selengkapnya tentang bekerja dengan aturan persetujuan di dasar patch kustom, lihat [Garis dasar kustom](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. Jika Anda ingin secara eksplisit menyetujui patch lain selain yang memenuhi aturan persetujuan Anda, lakukan hal berikut di bagian **Pengecualian patch**:
   + Untuk **Patch yang disetujui**, masukkan daftar patch yang dipisahkan koma yang ingin Anda setujui.

     Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
   + (Opsional) Untuk **Tingkat kepatuhan patch yang disetujui**, tetapkan tingkat kepatuhan pada patch dalam daftar.

1. Jika Anda ingin secara eksplisit menolak patch lain selain yang memenuhi aturan persetujuan Anda, lakukan hal berikut di bagian **Pengecualian patch**:
   + Untuk **Patch yang ditolak**, masukkan daftar patch yang dipisahkan koma yang ingin Anda tolak.

     Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
   + Untuk **tindakan tambalan Ditolak**, pilih tindakan yang akan diambil pada tambalan yang disertakan dalam daftar tambalan **Ditolak**. Patch Manager
     + **Diizinkan sebagai dependensi**: Sebuah paket di daftar **Patch yang ditolak** diinstal hanya jika merupakan dependensi dari paket lain. Ini dianggap sesuai dengan baseline patch dan statusnya dilaporkan sebagai. *InstalledOther* Ini adalah tindakan default jika tidak ada pilihan yang ditentukan.
     + **Blokir**: Paket dalam daftar **tambalan Ditolak**, dan paket yang menyertakannya sebagai dependensi, tidak diinstal dalam Patch Manager keadaan apa pun. Jika sebuah paket diinstal sebelum ditambahkan ke daftar **tambalan Ditolak**, atau diinstal di luar Patch Manager sesudahnya, paket tersebut dianggap tidak sesuai dengan garis dasar tambalan dan statusnya dilaporkan sebagai. *InstalledRejected*

1. (Opsional) Untuk **Kelola tag**, terapkan satu atau beberapa name/value pasangan kunci tag ke baseline patch.

   Tanda adalah metadata opsional yang Anda tetapkan ke sumber daya. Tag memungkinkan Anda untuk mengkategorikan sumber daya dengan berbagai cara, seperti berdasarkan tujuan, pemilik, atau lingkungan. Sebagai contoh, Anda mungkin ingin menandai dasar patch untuk mengidentifikasi tingkat kepelikan patch yang ditentukannya, pengelola paket tempat patch diterapkan, dan jenis lingkungan. Dalam hal ini, Anda dapat menentukan tag yang mirip dengan name/value pasangan kunci berikut:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=PackageManager,Value=softwareupdate`
   + `Key=Environment,Value=Production`

1. Pilih **Buat dasar patch**.

# Membuat baseline patch khusus untuk Windows Server
<a name="patch-manager-create-a-patch-baseline-for-windows"></a>

Gunakan prosedur berikut untuk membuat baseline patch khusus untuk node yang dikelola Windows diPatch Manager, alat di. AWS Systems Manager

Untuk informasi tentang membuat baseline patch untuk node terkelola Linux, lihat. [Membuat baseline patch khusus untuk Linux](patch-manager-create-a-patch-baseline-for-linux.md) Untuk informasi tentang membuat baseline patch untuk node macOS terkelola, lihat. [Membuat baseline patch khusus untuk macOS](patch-manager-create-a-patch-baseline-for-macos.md)

Untuk contoh membuat dasar patch yang terbatas untuk menginstal Windows Service Pack saja, lihat [Tutorial: Buat baseline patch untuk menginstal Paket Layanan Windows menggunakan konsol](patch-manager-windows-service-pack-patch-baseline-tutorial.md).

**Untuk membuat dasar patch kustom (Windows)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch baseline**, lalu pilih **Create patch** baseline. 

   -atau-

   Jika Anda mengakses Patch Manager untuk pertama kalinya saat ini Wilayah AWS, pilih **Mulai dengan ikhtisar**, pilih tab **Garis dasar Patch, lalu pilih **Buat** baseline** patch.

1. Untuk **Nama**, masukkan nama untuk dasar patch baru Anda, misalnya, `MyWindowsPatchBaseline`.

1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk dasar patch ini.

1. Untuk **Sistem operasi**, pilih `Windows`.

1. ****Untuk **status kepatuhan pembaruan keamanan yang tersedia**, pilih status yang ingin Anda tetapkan ke patch keamanan yang tersedia tetapi tidak disetujui karena tidak memenuhi kriteria penginstalan yang ditentukan dalam baseline patch, Non-Compliant atau Compliant.****

   Contoh skenario: Patch keamanan yang mungkin ingin Anda instal dapat dilewati jika Anda telah menentukan jangka waktu yang lama untuk menunggu setelah patch dirilis sebelum instalasi. Jika pembaruan tambalan dirilis selama masa tunggu yang Anda tentukan, masa tunggu untuk menginstal tambalan dimulai lagi. Jika masa tunggu terlalu lama, beberapa versi patch dapat dirilis tetapi tidak pernah diinstal.

1. Jika Anda ingin mulai menggunakan dasar patch ini sebagai default untuk Windows segera setelah Anda membuatnya, pilih **Atur dasar patch ini sebagai dasar patch default untuk instans Windows Server**.
**catatan**  
Opsi ini hanya tersedia jika Anda pertama kali mengakses Patch Manager sebelum [kebijakan tambalan](patch-manager-policies.md) dirilis pada 22 Desember 2022.  
Untuk informasi tentang mengatur dasar patch yang ada sebagai default, lihat [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md).

1. Di bagian **Aturan persetujuan untuk sistem operasi**, gunakan bidang tersebut untuk membuat satu atau lebih aturan persetujuan otomatis.
   + **Produk**: Versi sistem operasi yang berlaku untuk aturan persetujuan, seperti`WindowsServer2012`. Pilihan default adalah `All`.
   + **Klasifikasi**: Jenis patch yang diberlakukan aturan persetujuan, seperti `CriticalUpdates`, `Drivers`, dan `Tools`. Pilihan default adalah `All`. 
**Tip**  
Anda dapat menyertakan instalasi Windows Service Pack dalam aturan persetujuan Anda dengan menyertakan `ServicePacks` atau dengan memilih `All` di daftar **Klasifikasi** Anda. Sebagai contoh, lihat [Tutorial: Buat baseline patch untuk menginstal Paket Layanan Windows menggunakan konsol](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
   + **Kepelikan**: Nilai kepelikan patch yang diberlakukan aturan, seperti `Critical`. Pilihan default adalah `All`. 
   + **Persetujuan otomatis**: Metode untuk memilih patch untuk persetujuan otomatis.
     + **Menyetujui patch setelah beberapa hari tertentu**: Jumlah hari Patch Manager untuk menunggu setelah patch dirilis atau diperbarui sebelum patch secara otomatis disetujui. Anda dapat memasukkan bilangan bulat apa saja dari nol (0) sampai 360. Untuk sebagian besar skenario, kami merekomendasikan untuk menunggu tidak lebih dari 100 hari.
     + **Menyetujui patch yang dirilis hingga tanggal tertentu: Tanggal** rilis patch yang Patch Manager secara otomatis menerapkan semua patch yang dirilis atau diperbarui pada atau sebelum tanggal tersebut. Misalnya, jika Anda menentukan 7 Juli 2023, tidak ada tambalan yang dirilis atau terakhir diperbarui pada atau setelah 8 Juli 2023, yang diinstal secara otomatis.
   + (Opsional) **Laporan kepatuhan**: Tingkat kepelikan yang ingin Anda tetapkan untuk patch yang disetujui oleh baseline, seperti `High`.
**catatan**  
Jika Anda menentukan tingkat pelaporan kepatuhan dan status patch dari setiap patch yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan yang dilaporkan secara keseluruhan baseline patch adalah tingkat keparahan yang Anda tentukan.

1. (Opsional) Di bagian **Aturan persetujuan untuk sistem operasi**, gunakan bidang tersebut untuk membuat satu atau lebih aturan persetujuan otomatis.
**catatan**  
Alih-alih menentukan aturan persetujuan, Anda dapat menentukan daftar patch yang disetujui dan ditolak sebagai pengecualian patch. Lihat langkah 10 dan 11. 
   + **Keluarga produk**: Keluarga produk Microsoft umum yang Anda ingin tentukan aturan, seperti `Office` atau `Exchange Server`.
   + **Produk**: Versi aplikasi yang berlaku untuk aturan persetujuan, seperti `Office 2016` atau`Active Directory Rights Management Services Client 2.0 2016`. Pilihan default adalah `All`.
   + **Klasifikasi**: Jenis patch yang diberlakukan aturan persetujuan, seperti `CriticalUpdates`. Pilihan default adalah `All`. 
   + **Kepelikan**: Nilai kepelikan patch yang diberlakukan aturan, seperti `Critical`. Pilihan default adalah `All`. 
   + **Persetujuan otomatis**: Metode untuk memilih patch untuk persetujuan otomatis.
     + **Menyetujui patch setelah beberapa hari tertentu**: Jumlah hari Patch Manager untuk menunggu setelah patch dirilis atau diperbarui sebelum patch secara otomatis disetujui. Anda dapat memasukkan bilangan bulat apa saja dari nol (0) sampai 360. Untuk sebagian besar skenario, kami merekomendasikan untuk menunggu tidak lebih dari 100 hari.
     + **Menyetujui patch yang dirilis hingga tanggal tertentu: Tanggal** rilis patch yang Patch Manager secara otomatis menerapkan semua patch yang dirilis atau diperbarui pada atau sebelum tanggal tersebut. Misalnya, jika Anda menentukan 7 Juli 2023, tidak ada tambalan yang dirilis atau terakhir diperbarui pada atau setelah 8 Juli 2023, yang diinstal secara otomatis.
   + (Opsional) **Pelaporan kepatuhan**: Tingkat keparahan yang ingin Anda tetapkan ke tambalan yang disetujui oleh baseline, seperti atau. `Critical` `High`
**catatan**  
Jika Anda menentukan tingkat pelaporan kepatuhan dan status patch dari setiap patch yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan yang dilaporkan secara keseluruhan baseline patch adalah tingkat keparahan yang Anda tentukan.

1. (Opsional) Jika Anda ingin secara eksplisit menyetujui patch apa saja dan bukan membiarkan patch dipilih sesuai dengan aturan persetujuan, lakukan hal berikut di bagian **Pengecualian patch**:
   + Untuk **Patch yang disetujui**, masukkan daftar patch yang dipisahkan koma yang ingin Anda setujui.

     Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
   + (Opsional) Untuk **Tingkat kepatuhan patch yang disetujui**, tetapkan tingkat kepatuhan pada patch dalam daftar.

1. Jika Anda ingin secara eksplisit menolak patch lain selain yang memenuhi aturan persetujuan Anda, lakukan hal berikut di bagian **Pengecualian patch**:
   + Untuk **Patch yang ditolak**, masukkan daftar patch yang dipisahkan koma yang ingin Anda tolak.

     Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).
   + Untuk **tindakan tambalan Ditolak**, pilih tindakan yang akan diambil pada tambalan yang disertakan dalam daftar tambalan **Ditolak**. Patch Manager
     + **Izinkan sebagai ketergantungan**: Windows Server tidak mendukung konsep dependensi paket. Jika sebuah paket dalam daftar **tambalan Ditolak** dan sudah diinstal pada node, statusnya dilaporkan sebagai`INSTALLED_OTHER`. Paket apa pun yang belum diinstal pada node dilewati. 
     + **Blokir**: Paket dalam daftar **tambalan Ditolak** tidak diinstal oleh dalam Patch Manager keadaan apa pun. Jika sebuah paket diinstal sebelum ditambahkan ke daftar **tambalan Ditolak**, atau diinstal di luar Patch Manager sesudahnya, paket tersebut dianggap tidak sesuai dengan garis dasar tambalan dan statusnya dilaporkan sebagai. `INSTALLED_REJECTED`

     Untuk informasi selengkapnya tentang tindakan paket yang ditolak, lihat [Opsi daftar tambalan yang ditolak di garis dasar tambalan kustom](patch-manager-windows-and-linux-differences.md#rejected-patches-diff). 

1. (Opsional) Untuk **Kelola tag**, terapkan satu atau beberapa name/value pasangan kunci tag ke baseline patch.

   Tanda adalah metadata opsional yang Anda tetapkan ke sumber daya. Tag memungkinkan Anda untuk mengkategorikan sumber daya dengan berbagai cara, seperti berdasarkan tujuan, pemilik, atau lingkungan. Sebagai contoh, Anda mungkin ingin menandai dasar patch untuk mengidentifikasi tingkat kepelikan patch yang ditentukannya, keluarga sistem operasi tempat patch diterapkan, dan jenis lingkungan. Dalam hal ini, Anda dapat menentukan tag yang mirip dengan name/value pasangan kunci berikut:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Pilih **Buat dasar patch**.

# Memperbarui atau menghapus baseline patch kustom
<a name="patch-manager-update-or-delete-a-patch-baseline"></a>

Anda dapat memperbarui atau menghapus baseline patch kustom yang telah Anda buatPatch Manager, alat di. AWS Systems Manager Ketika Anda memperbarui dasar patch, Anda dapat mengubah nama atau deskripsi, aturan persetujuan, dan pengecualian untuk patch yang disetujui dan ditolak. Anda juga dapat memperbarui tag yang diterapkan ke dasar patch. Anda tidak dapat mengubah jenis sistem operasi yang telah dibuat untuk baseline patch, dan Anda tidak dapat membuat perubahan pada baseline patch yang telah ditentukan sebelumnya yang disediakan oleh. AWS

## Memperbarui atau menghapus baseline patch
<a name="sysman-maintenance-update-mw"></a>

Ikuti langkah-langkah berikut ini untuk memperbarui atau menghapus dasar patch.

**penting**  
 Berhati-hatilah saat menghapus baseline patch kustom yang mungkin digunakan oleh konfigurasi kebijakan tambalan di. Quick Setup  
Jika Anda menggunakan [konfigurasi kebijakan tambalan](patch-manager-policies.md) diQuick Setup, pembaruan yang Anda buat ke baseline patch kustom disinkronkan dengan Quick Setup satu jam sekali.   
Jika baseline patch kustom yang direferensikan dalam kebijakan tambalan dihapus, spanduk akan ditampilkan di halaman **Detail Quick Setup konfigurasi** untuk kebijakan tambalan Anda. Spanduk memberi tahu Anda bahwa kebijakan tambalan mereferensikan baseline tambalan yang tidak ada lagi, dan operasi penambalan berikutnya akan gagal. Dalam hal ini, kembali ke halaman Quick Setup **Konfigurasi**, pilih Patch Manager konfigurasi, dan pilih **Tindakan**, **Edit konfigurasi**. Nama dasar patch yang dihapus disorot, dan Anda harus memilih baseline patch baru untuk sistem operasi yang terpengaruh.

**Untuk memperbarui atau menghapus baseline patch**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih dasar patch yang ingin Anda perbarui atau hapus, lalu lakukan salah satu hal berikut:
   + **Untuk menghapus baseline patch dari Anda Akun AWS, pilih Hapus.** Sistem meminta Anda untuk mengonfirmasi tindakan Anda. 
   + Untuk membuat perubahan pada nama atau deskripsi, aturan persetujuan, atau pengecualian patch untuk dasar patch tersebut, pilih **Edit**. Pada halaman **Edit dasar patch**, ubah nilai dan pilihan yang Anda inginkan, lalu pilih **Simpan perubahan**. 
   + Untuk menambah, mengubah, atau menghapus tag yang diterapkan ke dasar patch, pilih tab **Tag**, dan kemudian pilih **Edit tag**. Pada halaman **Edit tag dasar patch**, buat pembaruan ke tag dasar patch, lalu pilih **Simpan perubahan**. 

   Untuk informasi tentang pilihan konfigurasi yang dapat Anda buat, lihat [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md).

# Mengatur dasar patch yang ada sebagai default
<a name="patch-manager-default-patch-baseline"></a>

**penting**  
Setiap pilihan dasar tambalan default yang Anda buat di sini tidak berlaku untuk operasi penambalan yang didasarkan pada kebijakan tambalan. Kebijakan patch menggunakan spesifikasi dasar patch mereka sendiri. Untuk informasi selengkapnya tentang kebijakan tambalan, lihat[Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).

Saat Anda membuat baseline patch kustom diPatch Manager, alat di AWS Systems Manager, Anda dapat mengatur baseline sebagai default untuk jenis sistem operasi terkait segera setelah Anda membuatnya. Untuk informasi, lihat [Bekerja dengan dasar patch kustom](patch-manager-manage-patch-baselines.md).

Anda juga dapat mengatur dasar patch yang ada sebagai default untuk sebuah jenis sistem operasi.

**catatan**  
Langkah-langkah yang Anda ikuti bergantung pada apakah Anda pertama kali mengakses Patch Manager sebelum atau setelah rilis kebijakan tambalan pada 22 Desember 2022. Jika Anda menggunakan Patch Manager sebelum tanggal itu, Anda dapat menggunakan prosedur konsol. Jika tidak, gunakan AWS CLI prosedurnya. Menu **Tindakan** yang direferensikan dalam prosedur konsol tidak ditampilkan di Wilayah yang Patch Manager tidak digunakan sebelum rilis kebijakan tambalan.

**Untuk mengatur dasar patch yang ada sebagai default**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Dasar patch**.

1. Dalam daftar dasar patch, pilih tombol dasar patch yang saat ini tidak diatur sebagai default untuk suatu jenis sistem operasi.

   Kolom **Baseline default** menunjukkan baseline apa yang saat ini diatur sebagai default.

1. Di menu **Tindakan**, pilih **Atur dasar patch default**.
**penting**  
Menu **Tindakan** tidak tersedia jika Anda tidak bekerja dengan Patch Manager saat ini Akun AWS dan Wilayah sebelum 22 Desember 2022. Lihat **Catatan** sebelumnya dalam topik ini untuk informasi lebih lanjut.

1. Di kotak dialog konfirmasi, pilih **Atur default**.

**Untuk mengatur baseline patch sebagai default ()AWS CLI**

1. Jalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html)perintah untuk melihat daftar baseline patch yang tersedia dan mereka dan IDs Amazon Resource Names ()ARNs.

   ```
   aws ssm describe-patch-baselines
   ```

1. Jalankan [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html)perintah untuk menetapkan garis dasar sebagai default untuk sistem operasi yang terkait dengannya. Ganti *baseline-id-or-ARN* dengan ID baseline patch kustom atau baseline yang telah ditentukan untuk digunakan. 

------
#### [ Linux & macOS ]

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id baseline-id-or-ARN
   ```

   Berikut ini adalah contoh pengaturan baseline kustom sebagai default.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   Berikut ini adalah contoh pengaturan garis dasar yang telah ditentukan yang dikelola oleh AWS sebagai default.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id baseline-id-or-ARN
   ```

   Berikut ini adalah contoh pengaturan baseline kustom sebagai default.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   Berikut ini adalah contoh pengaturan garis dasar yang telah ditentukan yang dikelola oleh AWS sebagai default.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
   ```

------

# Melihat metrik yang tersedia
<a name="patch-manager-view-available-patches"></a>

DenganPatch Manager, alat di AWS Systems Manager, Anda dapat melihat semua tambalan yang tersedia untuk sistem operasi tertentu dan, secara opsional, versi sistem operasi tertentu.

**Tip**  
Untuk menghasilkan daftar tambalan yang tersedia dan menyimpannya ke file, Anda dapat menggunakan [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html)perintah dan menentukan [output](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html) pilihan Anda.

**Untuk melihat patch yang tersedia**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch**.

   -atau-

   Jika Anda mengakses Patch Manager untuk pertama kalinya saat ini Wilayah AWS, pilih **Mulai dengan ikhtisar**, lalu pilih tab **Patch**.
**catatan**  
UntukWindows Server, tab **Patch** menampilkan pembaruan yang tersedia dari Windows Server Update Service (WSUS).

1. Untuk **Sistem operasi**, pilih sistem operasi yang ingin Anda lihat patch yang tersedia, seperti `Windows` atau `Amazon Linux`.

1. (Opsional) Untuk **Produk**, pilih versi OS, seperti `WindowsServer2019` atau `AmazonLinux2018.03`.

1. (Opsional) Untuk menambah atau menghapus kolom informasi untuk hasil Anda, pilih tombol konfigurasikan (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/images/configure-button.png)) di kanan atas daftar **Patch**. (Secara default, tab **Patch** menampilkan kolom untuk hanya beberapa metadata patch yang tersedia.)

   Untuk informasi tentang jenis metadata yang dapat Anda tambahkan ke tampilan Anda, lihat [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) dalam *Referensi API AWS Systems Manager *.

# Membuat dan mengelola grup patch
<a name="patch-manager-tag-a-patch-group"></a>

Jika Anda *tidak* menggunakan kebijakan tambalan dalam operasi Anda, Anda dapat mengatur upaya penambalan Anda dengan menambahkan node terkelola ke grup tambalan dengan menggunakan tag.

**catatan**  
Grup tambalan tidak digunakan dalam operasi penambalan yang didasarkan pada *kebijakan tambalan*. Untuk informasi tentang bekerja dengan kebijakan tambalan, lihat[Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).  
Fungsionalitas grup tambalan tidak didukung di konsol untuk pasangan wilayah Akun yang belum menggunakan grup tambalan sebelum dukungan kebijakan tambalan dirilis pada 22 Desember 2022. Fungsionalitas grup patch masih tersedia di pasangan Account-region yang mulai menggunakan grup patch sebelum tanggal ini.

Untuk menggunakan tag dalam operasi penambalan, Anda harus menerapkan kunci tag `Patch Group` atau `PatchGroup` ke node terkelola Anda. Anda juga harus menentukan nama yang ingin Anda berikan pada grup tambalan sebagai nilai tag. Anda dapat menentukan nilai tag apa pun, tetapi kunci tag harus `Patch Group` atau`PatchGroup`.

`PatchGroup`(tanpa spasi) diperlukan jika Anda [mengizinkan tag dalam metadata instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS). 

Setelah mengelompokkan node terkelola menggunakan tag, Anda menambahkan nilai grup patch ke baseline patch. Dengan mendaftarkan grup patch dengan dasar patch, Anda memastikan bahwa patch yang benar diinstal selama operasi patching. Untuk informasi selengkapnya tentang grup patch, lihat [Grup tambalan](patch-manager-patch-groups.md).

Selesaikan tugas dalam topik ini untuk mempersiapkan node terkelola Anda untuk ditambal menggunakan tag dengan node dan patch baseline Anda. Tugas 1 hanya diperlukan jika Anda menambal instans Amazon EC2. Tugas 2 hanya diperlukan jika Anda menambal instans non-EC2 di lingkungan [hybrid](operating-systems-and-machine-types.md#supported-machine-types) dan multicloud. Tugas 3 diperlukan untuk semua node yang dikelola.

**Tip**  
Anda juga dapat menambahkan tag ke node terkelola menggunakan AWS CLI perintah `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` atau operasi Systems Manager API ssm-agent-minimum-s `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)` 3-permissions-required.

**Topics**
+ [Tugas 1: Tambahkan instans EC2 ke grup patch menggunakan tag](#sysman-patch-group-tagging-ec2)
+ [Tugas 2: Tambahkan node terkelola ke grup tambalan menggunakan tag](#sysman-patch-group-tagging-managed)
+ [Tugas 3: Tambahkan grup patch ke dasar patch](#sysman-patch-group-patchbaseline)

## Tugas 1: Tambahkan instans EC2 ke grup patch menggunakan tag
<a name="sysman-patch-group-tagging-ec2"></a>

Anda dapat menambahkan tag ke instans EC2 menggunakan konsol Systems Manager atau konsol Amazon EC2. Tugas ini hanya diperlukan jika Anda menambal instans Amazon EC2.

**penting**  
Anda tidak dapat menerapkan `Patch Group` tag (dengan spasi) ke instans Amazon EC2 jika opsi **Izinkan tag dalam metadata instans diaktifkan pada instance**. Mengizinkan tag dalam metadata instance mencegah nama kunci tag berisi spasi. Jika Anda telah [mengizinkan tag dalam metadata instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), Anda harus menggunakan kunci tag `PatchGroup` (tanpa spasi).

**Opsi 1: Untuk menambahkan instans EC2 ke grup patch (konsol Systems Manager)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Fleet Manager**.

1. Dalam daftar **Managed nodes**, pilih ID dari instans EC2 terkelola yang ingin Anda konfigurasikan untuk ditambal. ID node untuk instans EC2 dimulai dengan. `i-`
**catatan**  
Saat menggunakan konsol Amazon EC2 dan AWS CLI, Anda dapat menerapkan `Key = Patch Group` atau memberi `Key = PatchGroup` tag ke instance yang belum dikonfigurasi untuk digunakan dengan Systems Manager.  
Jika node terkelola yang Anda harapkan tidak terdaftar, lihat [Memecahkan masalah ketersediaan node terkelola](fleet-manager-troubleshooting-managed-nodes.md) untuk tips pemecahan masalah.

1. Pilih tab **Tag**, lalu pilih **Edit**.

1. Di kolom kiri, masukkan **Patch Group** atau**PatchGroup**. Jika Anda telah [mengizinkan tag dalam metadata instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), Anda harus menggunakan `PatchGroup` (tanpa spasi).

1. Di kolom kanan, masukkan nilai tag untuk dijadikan nama untuk grup tambalan.

1. Pilih **Simpan**.

1. Ulangi prosedur ini untuk menambahkan instance EC2 lainnya ke grup patch yang sama.

**Opsi 2: Untuk menambahkan instans EC2 ke grup tambalan (konsol Amazon EC2)**

1. Buka [konsol Amazon EC2](https://console.aws.amazon.com/ec2/), lalu pilih **Instans** di panel navigasi. 

1. Di daftar instans terkelola, pilih instans yang ingin Anda konfigurasikan untuk patching.

1. Di menu **Tindakan**, pilih **Pengaturan instans**, **Kelola tag**.

1. Pilih **Tambahkan tag baru**.

1. Untuk **Kunci**, masukkan **Patch Group** atau**PatchGroup**. Jika Anda telah [mengizinkan tag dalam metadata instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), Anda harus menggunakan `PatchGroup` (tanpa spasi).

1. Untuk **Nilai**, masukkan nilai untuk dijadikan nama untuk grup patch.

1. Pilih **Simpan**.

1. Ulangi prosedur ini untuk menambahkan instans lainnya ke grup patch yang sama.

## Tugas 2: Tambahkan node terkelola ke grup tambalan menggunakan tag
<a name="sysman-patch-group-tagging-managed"></a>

Ikuti langkah-langkah dalam topik ini untuk menambahkan tag ke perangkat AWS IoT Greengrass inti dan node terkelola yang diaktifkan hibrida non-EC2 (mi-\$1). Tugas ini hanya diperlukan jika Anda menambal instans non-EC2 di lingkungan hybrid dan multicloud.

**catatan**  
Anda tidak dapat menambahkan tag untuk node terkelola non-EC2 menggunakan konsol Amazon EC2.

**Untuk menambahkan node terkelola non-EC2 ke grup patch (konsol Systems Manager)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Fleet Manager**.

1. Dalam daftar **Managed nodes**, pilih nama node terkelola yang ingin Anda konfigurasikan untuk ditambal.
**catatan**  
Jika node terkelola yang Anda harapkan tidak terdaftar, lihat [Memecahkan masalah ketersediaan node terkelola](fleet-manager-troubleshooting-managed-nodes.md) untuk tips pemecahan masalah.

1. Pilih tab **Tag**, lalu pilih **Edit**.

1. Di kolom kiri, masukkan **Patch Group** atau**PatchGroup**. Jika Anda telah [mengizinkan tag dalam metadata instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), Anda harus menggunakan `PatchGroup` (tanpa spasi).

1. Di kolom kanan, masukkan nilai tag untuk dijadikan nama untuk grup tambalan.

1. Pilih **Simpan**.

1. Ulangi prosedur ini untuk menambahkan node terkelola lainnya ke grup patch yang sama.

## Tugas 3: Tambahkan grup patch ke dasar patch
<a name="sysman-patch-group-patchbaseline"></a>

Untuk mengaitkan baseline patch tertentu dengan node terkelola Anda, Anda harus menambahkan nilai grup patch ke baseline patch. Dengan mendaftarkan grup patch dengan dasar patch, Anda memastikan bahwa patch yang benar diinstal selama operasi patching. Tugas ini diperlukan apakah Anda menambal instans EC2, node terkelola non-EC2, atau keduanya.

Untuk informasi selengkapnya tentang grup patch, lihat [Grup tambalan](patch-manager-patch-groups.md).

**catatan**  
Langkah-langkah yang Anda ikuti bergantung pada apakah Anda pertama kali mengakses Patch Manager sebelum atau setelah rilis [kebijakan tambalan](patch-manager-policies.md) pada 22 Desember 2022.

**Untuk menambahkan grup patch ke baseline patch (konsol Systems Manager)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Jika Anda mengakses Patch Manager untuk pertama kalinya di saat ini Wilayah AWS dan halaman Patch Manager awal terbuka, pilih **Mulai dengan ikhtisar**.

1. Pilih tab **Patch baselines**, dan kemudian di daftar **garis dasar Patch, pilih nama baseline** patch yang ingin Anda konfigurasikan untuk grup patch Anda.

   Jika Anda tidak mengakses terlebih dahulu Patch Manager hingga setelah rilis kebijakan tambalan, Anda harus memilih baseline khusus yang telah Anda buat.

1. Jika halaman detail **ID Baseline** menyertakan menu **Tindakan**, lakukan hal berikut: 
   + Pilih **Tindakan**, kemudian **Modifikasi grup patch**.
   + Masukkan *nilai* tag yang Anda tambahkan ke node terkelola[Tugas 2: Tambahkan node terkelola ke grup tambalan menggunakan tag](#sysman-patch-group-tagging-managed), lalu pilih **Tambah**.

   Jika halaman detail **ID Dasar** *tidak* menyertakan menu **Tindakan**, grup tambalan tidak dapat dikonfigurasi di konsol. Sebagai gantinya, Anda dapat melakukan salah satu dari hal berikut:
   + (Disarankan) Siapkan kebijakan tambalan diQuick Setup, alat di AWS Systems Manager, untuk memetakan baseline tambalan ke satu atau beberapa instans EC2.

     Untuk informasi selengkapnya, lihat [Menggunakan kebijakan Quick Setup tambalan](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) dan [Mengotomatiskan penambalan di seluruh organisasi menggunakan kebijakan tambalan](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html). Quick Setup
   + Gunakan [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)perintah di AWS Command Line Interface (AWS CLI) untuk mengkonfigurasi grup patch.

# Integrasi dengan Patch Manager AWS Security Hub CSPM
<a name="patch-manager-security-hub-integration"></a>

[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)memberi Anda pandangan komprehensif tentang keadaan keamanan Anda di AWS. Security Hub CSPM mengumpulkan data keamanan dari seluruh Akun AWS Layanan AWS, dan mendukung produk mitra pihak ketiga. Dengan Security Hub CSPM, Anda dapat memeriksa lingkungan Anda terhadap standar industri keamanan dan praktik terbaik. Security Hub CSPM membantu Anda menganalisis tren keamanan dan mengidentifikasi masalah keamanan prioritas tertinggi.

Dengan menggunakan integrasi antaraPatch Manager, alat di, dan Security Hub CSPM AWS Systems Manager, Anda dapat mengirim temuan tentang node yang tidak sesuai dari ke Security Patch Manager Hub CSPM. Temuan adalah catatan yang dapat diamati dari pemeriksaan keamanan atau deteksi terkait keamanan. Security Hub CSPM kemudian dapat menyertakan temuan terkait tambalan tersebut dalam analisisnya tentang postur keamanan Anda.

Informasi dalam topik berikut berlaku tidak peduli metode atau jenis konfigurasi yang Anda gunakan untuk operasi patching Anda:
+ Kebijakan tambalan yang dikonfigurasi di Quick Setup
+ Opsi Manajemen Host yang dikonfigurasi di Quick Setup
+ Jendela pemeliharaan untuk menjalankan tambalan `Scan` atau `Install` tugas
+ **Patch sesuai permintaan sekarang beroperasi**

**Contents**
+ [Cara Patch Manager mengirimkan temuan ke Security Hub CSPM](#securityhub-integration-sending-findings)
  + [Jenis temuan yang dikirim Patch Manager](#securityhub-integration-finding-types)
  + [Latensi untuk mengirim temuan](#securityhub-integration-finding-latency)
  + [Mencoba lagi saat CSPM Security Hub tidak tersedia](#securityhub-integration-retry-send)
  + [Melihat temuan di Security Hub CSPM](#securityhub-integration-view-findings)
+ [Temuan standar dari Patch Manager](#securityhub-integration-finding-example)
+ [Mengaktifkan dan mengonfigurasikan integrasi](#securityhub-integration-enable)
+ [Bagaimana cara menghentikan pengiriman temuan](#securityhub-integration-disable)

## Cara Patch Manager mengirimkan temuan ke Security Hub CSPM
<a name="securityhub-integration-sending-findings"></a>

Di Security Hub CSPM, masalah keamanan dilacak sebagai temuan. Beberapa temuan berasal dari masalah yang terdeteksi oleh pihak lain Layanan AWS atau oleh mitra pihak ketiga. Security Hub CSPM juga memiliki seperangkat aturan yang digunakan untuk mendeteksi masalah keamanan dan menghasilkan temuan.

 Patch Manageradalah salah satu alat Systems Manager yang mengirimkan temuan ke Security Hub CSPM. Setelah Anda melakukan operasi penambalan dengan menjalankan dokumen SSM (`AWS-RunPatchBaseline`,, atau`AWS-RunPatchBaselineWithHooks`)`AWS-RunPatchBaselineAssociation`, informasi penambalan dikirim ke Inventaris atau Kepatuhan, alat di AWS Systems Manager, atau keduanya. Setelah Inventaris, Kepatuhan, atau keduanya menerima data, Patch Manager menerima pemberitahuan. Kemudian, Patch Manager mengevaluasi data untuk akurasi, pemformatan, dan kepatuhan. Jika semua kondisi terpenuhi, Patch Manager teruskan data ke Security Hub CSPM.

Security Hub CSPM menyediakan alat untuk mengelola temuan dari seluruh sumber ini. Anda dapat melihat dan mem-filter daftar temuan dan melihat detail suatu temuan. Untuk informasi lebih lanjut, lihat [Melihat temuan](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) dalam *Panduan Pengguna AWS Security Hub *. Anda juga dapat melacak status penyelidikan temuan. Untuk informasi lebih lanjut, lihat [Mengambil tindakan pada temuan](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) dalam *Panduan Pengguna AWS Security Hub *.

Semua temuan di Security Hub CSPM menggunakan format JSON standar yang disebut AWS Security Finding Format (ASFF). ASFF mencakup detail tentang sumber masalah, sumber daya yang terpengaruh, dan status temuan saat ini. Untuk informasi lebih lanjut, lihat [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) di *Panduan Pengguna AWS Security Hub *.

### Jenis temuan yang dikirim Patch Manager
<a name="securityhub-integration-finding-types"></a>

Patch Managermengirimkan temuan ke Security Hub CSPM menggunakan [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html). Dalam ASFF, bidang `Types` menyediakan jenis temuan. Temuan dari Patch Manager memiliki nilai sebagai berikut untuk`Types`:
+  Checks/Patch Manajemen Perangkat Lunak dan Konfigurasi

 Patch Managermengirimkan satu temuan per node terkelola yang tidak sesuai. Temuan ini dilaporkan dengan tipe sumber daya [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)sehingga temuan dapat dikorelasikan dengan integrasi CSPM Security Hub lainnya yang melaporkan jenis sumber daya. `AwsEc2Instance` Patch Managerhanya meneruskan temuan ke Security Hub CSPM jika operasi menemukan node yang dikelola tidak sesuai. Temuan ini mencakup hasil Ringkasan Patch. 

**catatan**  
Setelah melaporkan node yang tidak sesuai ke Security Hub CSPM. Patch Managertidak mengirim pembaruan ke Security Hub CSPM setelah node dibuat sesuai. Anda dapat menyelesaikan temuan secara manual di Security Hub CSPM setelah patch yang diperlukan diterapkan ke node terkelola.

Untuk informasi selengkapnya tentang definisi kepatuhan, lihat [Nilai status kepatuhan tambalan](patch-manager-compliance-states.md). Untuk informasi selengkapnya`PatchSummary`, lihat [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)di *Referensi AWS Security Hub API*.

### Latensi untuk mengirim temuan
<a name="securityhub-integration-finding-latency"></a>

Saat Patch Manager membuat temuan baru, biasanya dikirim ke Security Hub CSPM dalam beberapa detik hingga 2 jam. Kecepatan ini bergantung pada lalu lintas dalam Wilayah AWS yang sedang diproses pada saat itu.

### Mencoba lagi saat CSPM Security Hub tidak tersedia
<a name="securityhub-integration-retry-send"></a>

Jika ada pemadaman layanan, AWS Lambda fungsi dijalankan untuk mengembalikan pesan ke antrian utama setelah layanan berjalan lagi. Setelah pesan berada di antrean utama, coba lagi berjalan secara otomatis.

Jika Security Hub CSPM tidak tersedia, Patch Manager coba lagi mengirimkan temuan sampai diterima.

### Melihat temuan di Security Hub CSPM
<a name="securityhub-integration-view-findings"></a>

Prosedur ini menjelaskan cara melihat temuan di Security Hub CSPM tentang node terkelola di armada Anda yang tidak sesuai dengan patch.

**Untuk meninjau temuan CSPM Security Hub untuk kepatuhan patch**

1. Masuk ke Konsol Manajemen AWS dan buka AWS Security Hub CSPM konsol di [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/).

1. Di panel navigasi, pilih **Temuan**.

1. Pilih kotak **Tambahkan filter** (![\[The Search icon\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/images/search-icon.png)).

1. Di menu, di bawah **Filter**, pilih **Nama produk**.

1. Di kotak dialog yang terbuka, pilih **ada** di bidang pertama dan kemudian masukkan **Systems Manager Patch Manager** di bidang kedua.

1. Pilih **Terapkan**.

1. Tambahkan filter tambahan yang Anda inginkan untuk membantu mempersempit hasil Anda.

1. Dalam daftar hasil, pilih judul temuan yang Anda inginkan informasi lebih lanjut.

   Panel terbuka di sisi kanan layar dengan detail lebih lanjut tentang sumber daya, masalah yang ditemukan, dan perbaikan yang disarankan.
**penting**  
Pada saat ini, Security Hub CSPM melaporkan jenis sumber daya dari semua node yang dikelola sebagai. `EC2 Instance` Ini termasuk server lokal dan mesin virtual (VMs) yang telah Anda daftarkan untuk digunakan dengan Systems Manager.

**Klasifikasi keparahan**  
Daftar temuan untuk **Systems Manager Patch Manager** mencakup laporan tingkat keparahan temuan. **Tingkat keparahan** meliputi yang berikut, dari terendah ke tertinggi:
+ **INFORMASI** - Tidak ada masalah yang ditemukan.
+ **RENDAH** — Masalah ini tidak memerlukan remediasi.
+ **MEDIUM** — Masalah ini harus ditangani tetapi tidak mendesak.
+ **TINGGI** — Masalah ini harus ditangani sebagai prioritas.
+ **KRITIS** — Masalah ini harus segera diperbaiki untuk menghindari eskalasi.

Tingkat keparahan ditentukan oleh paket noncompliant yang paling parah pada sebuah instance. Karena Anda dapat memiliki beberapa garis dasar tambalan dengan beberapa tingkat keparahan, tingkat keparahan tertinggi dilaporkan dari semua paket yang tidak sesuai. Misalnya, Anda memiliki dua paket yang tidak sesuai di mana tingkat keparahan paket A adalah “Kritis” dan tingkat keparahan paket B adalah “Rendah”. “Kritis” akan dilaporkan sebagai tingkat keparahan.

Perhatikan bahwa bidang keparahan berkorelasi langsung dengan bidang. Patch Manager `Compliance` Ini adalah bidang yang Anda tetapkan tetapkan ke tambalan individual yang cocok dengan aturan. Karena `Compliance` bidang ini ditetapkan ke tambalan individual, itu tidak tercermin pada tingkat Ringkasan Patch.

**Konten terkait**
+ [Temuan](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) dalam *Panduan AWS Security Hub Pengguna*
+ [Kepatuhan patch Multi-Akun Patch Manager dan Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) di Blog *AWS Manajemen & Tata Kelola*

## Temuan standar dari Patch Manager
<a name="securityhub-integration-finding-example"></a>

Patch Managermengirimkan temuan ke Security Hub CSPM menggunakan [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html).

Berikut adalah contoh temuan Patch Manager.

```
{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
  "GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "AwsAccountId": "111122223333",
  "Types": [
    "Software & Configuration Checks/Patch Management/Compliance"
  ],
  "CreatedAt": "2021-11-11T22:05:25Z",
  "UpdatedAt": "2021-11-11T22:05:25Z",
  "Severity": {
    "Label": "INFORMATIONAL",
    "Normalized": 0
  },
  "Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
  "Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
  "Remediation": {
    "Recommendation": {
      "Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
      "Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
    }
  },
  "SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
  "ProductFields": {
    "aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
    "aws/securityhub/ProductName": "Systems Manager Patch Manager",
    "aws/securityhub/CompanyName": "AWS"
  },
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "i-02573cafcfEXAMPLE",
      "Partition": "aws",
      "Region": "us-east-2"
    }
  ],
  "WorkflowState": "NEW",
  "Workflow": {
    "Status": "NEW"
  },
  "RecordState": "ACTIVE",
  "PatchSummary": {
    "Id": "pb-0c10e65780EXAMPLE",
    "InstalledCount": 45,
    "MissingCount": 2,
    "FailedCount": 0,
    "InstalledOtherCount": 396,
    "InstalledRejectedCount": 0,
    "InstalledPendingReboot": 0,
    "OperationStartTime": "2021-11-11T22:05:06Z",
    "OperationEndTime": "2021-11-11T22:05:25Z",
    "RebootOption": "NoReboot",
    "Operation": "SCAN"
  }
}
```

## Mengaktifkan dan mengonfigurasikan integrasi
<a name="securityhub-integration-enable"></a>

Untuk menggunakan Patch Manager integrasi dengan Security Hub CSPM, Anda harus mengaktifkan Security Hub CSPM. *Untuk informasi tentang cara mengaktifkan CSPM Security Hub, lihat [Menyiapkan CSPM Security Hub di Panduan Pengguna](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html).AWS Security Hub *

Prosedur berikut menjelaskan cara mengintegrasikan Patch Manager dan Security Hub CSPM ketika Security Hub CSPM sudah aktif tetapi Patch Manager integrasi dimatikan. Anda hanya perlu menyelesaikan prosedur ini jika integrasi dinonaktifkan secara manual.

**Patch ManagerUntuk menambah integrasi CSPM Security Hub**

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Pengaturan**.

   -atau-

   Jika Anda mengakses Patch Manager untuk pertama kalinya saat ini Wilayah AWS, pilih **Mulai dengan ikhtisar**, lalu pilih tab **Pengaturan**.

1. **Di bagian **CSPM Ekspor ke Security Hub**, di sebelah kanan **temuan kepatuhan Patch tidak diekspor ke Security Hub**, pilih Aktifkan.**

## Bagaimana cara menghentikan pengiriman temuan
<a name="securityhub-integration-disable"></a>

Untuk menghentikan pengiriman temuan ke Security Hub CSPM, Anda dapat menggunakan konsol CSPM Security Hub atau API.

Untuk informasi selengkapnya, lihat topik berikut di *Panduan Pengguna AWS Security Hub *:
+ [Menonaktifkan dan mengaktifkan aliran temuan dari integrasi (konsol)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Menonaktifkan alur temuan dari integrasi (Security Hub CSPM API,) AWS CLI](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)

# Bekerja dengan Patch Manager sumber daya menggunakan AWS CLI
<a name="patch-manager-cli-commands"></a>

Bagian ini mencakup contoh perintah AWS Command Line Interface (AWS CLI) yang dapat Anda gunakan untuk melakukan tugas konfigurasiPatch Manager, alat di AWS Systems Manager.

Untuk ilustrasi penggunaan AWS CLI untuk menambal lingkungan server dengan menggunakan baseline patch kustom, lihat. [Tutorial: Menambal lingkungan server menggunakan AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)

Untuk informasi selengkapnya tentang penggunaan AWS CLI for AWS Systems Manager task, lihat [AWS Systems Manager bagian Referensi AWS CLI Perintah](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).

**Topics**
+ [AWS CLI perintah untuk baseline patch](#patch-baseline-cli-commands)
+ [AWS CLI perintah untuk grup tambalan](#patch-group-cli-commands)
+ [AWS CLI perintah untuk melihat ringkasan dan detail tambalan](#patch-details-cli-commands)
+ [AWS CLI perintah untuk memindai dan menambal node yang dikelola](#patch-operations-cli-commands)

## AWS CLI perintah untuk baseline patch
<a name="patch-baseline-cli-commands"></a>

**Topics**
+ [Membuat dasar patch](#patch-manager-cli-commands-create-patch-baseline)
+ [Buat dasar patch dengan repositori kustom untuk versi OS yang berbeda](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [Perbarui dasar patch](#patch-manager-cli-commands-update-patch-baseline)
+ [Ubah nama dasar patch](#patch-manager-cli-commands-rename-patch-baseline)
+ [Hapus dasar patch](#patch-manager-cli-commands-delete-patch-baseline)
+ [Cantumkan semua dasar patch](#patch-manager-cli-commands-describe-patch-baselines)
+ [Buat daftar semua AWS baseline patch yang disediakan](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Cantumkan dasar patch saya](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Tampilkan dasar patch](#patch-manager-cli-commands-get-patch-baseline)
+ [Dapatkan dasar patch default](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Atur dasar patch kustom sebagai default](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Setel ulang baseline AWS patch sebagai default](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Tandai dasar patch](#patch-manager-cli-commands-add-tags-to-resource)
+ [Cantumkan tag untuk dasar patch](#patch-manager-cli-commands-list-tags-for-resource)
+ [Hapus tag dari dasar patch](#patch-manager-cli-commands-remove-tags-from-resource)

### Membuat dasar patch
<a name="patch-manager-cli-commands-create-patch-baseline"></a>

Perintah berikut membuat baseline patch yang menyetujui semua pembaruan keamanan penting dan penting untuk Windows Server 2012 R2 5 hari setelah dirilis. Patch juga telah ditentukan untuk daftar patch yang Disetujui dan Ditolak. Selain itu, dasar patch telah ditandai untuk menunjukkan bahwa itu untuk lingkungan produksi.

------
#### [ Linux & macOS ]

```
aws ssm create-patch-baseline \
    --name "Windows-Server-2012R2" \
    --tags "Key=Environment,Value=Production" \
    --description "Windows Server 2012 R2, Important and Critical security updates" \
    --approved-patches "KB2032276,MS10-048" \
    --rejected-patches "KB2124261" \
    --rejected-patches-action "ALLOW_AS_DEPENDENCY" \
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```

------
#### [ Windows Server ]

```
aws ssm create-patch-baseline ^
    --name "Windows-Server-2012R2" ^
    --tags "Key=Environment,Value=Production" ^
    --description "Windows Server 2012 R2, Important and Critical security updates" ^
    --approved-patches "KB2032276,MS10-048" ^
    --rejected-patches "KB2124261" ^
    --rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
    --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Buat dasar patch dengan repositori kustom untuk versi OS yang berbeda
<a name="patch-manager-cli-commands-create-patch-baseline-mult-sources"></a>

Berlaku untuk node yang dikelola Linux saja. Perintah berikut ini menunjukkan cara menentukan repositori patch yang akan digunakan untuk versi sistem operasi Amazon Linux tertentu. Sampel ini menggunakan repositori sumber yang diizinkan secara default di Amazon Linux 2017.09, tetapi dapat disesuaikan dengan repositori sumber berbeda yang telah Anda konfigurasi untuk node terkelola.

**catatan**  
Untuk memperlihatkan perintah yang lebih kompleks ini secara lebih baik, kami menggunakan opsi `--cli-input-json` dengan opsi tambahan yang disimpan di file JSON eksternal.

1. Buat file JSON dengan nama seperti `my-patch-repository.json` dan tambahkan konten berikut ke file tersebut.

   ```
   {
       "Description": "My patch repository for Amazon Linux 2",
       "Name": "Amazon-Linux-2",
       "OperatingSystem": "AMAZON_LINUX_2",
       "ApprovalRules": {
           "PatchRules": [
               {
                   "ApproveAfterDays": 7,
                   "EnableNonSecurity": true,
                   "PatchFilterGroup": {
                       "PatchFilters": [
                           {
                               "Key": "SEVERITY",
                               "Values": [
                                   "Important",
                                   "Critical"
                               ]
                           },
                           {
                               "Key": "CLASSIFICATION",
                               "Values": [
                                   "Security",
                                   "Bugfix"
                               ]
                           },
                           {
                               "Key": "PRODUCT",
                               "Values": [
                                   "AmazonLinux2"
                               ]
                           }
                       ]
                   }
               }
           ]
       },
       "Sources": [
           {
               "Name": "My-AL2",
               "Products": [
                   "AmazonLinux2"
               ],
               "Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
           }
       ]
   }
   ```

1. Di direktori tempat Anda menyimpan file, jalankan perintah berikut.

   ```
   aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
   ```

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
       "BaselineId": "pb-0c10e65780EXAMPLE"
   }
   ```

### Perbarui dasar patch
<a name="patch-manager-cli-commands-update-patch-baseline"></a>

Perintah berikut ini menambahkan dua patch sebagai yang ditolak dan satu patch yang disetujui ke dasar patch yang ada.

Untuk informasi tentang format yang diterima untuk daftar patch yang disetujui dan patch yang ditolak, lihat [Format nama paket untuk daftar patch yang disetujui dan ditolak](patch-manager-approved-rejected-package-name-formats.md).

------
#### [ Linux & macOS ]

```
aws ssm update-patch-baseline \
    --baseline-id pb-0c10e65780EXAMPLE \
    --rejected-patches "KB2032276" "MS10-048" \
    --approved-patches "KB2124261"
```

------
#### [ Windows Server ]

```
aws ssm update-patch-baseline ^
    --baseline-id pb-0c10e65780EXAMPLE ^
    --rejected-patches "KB2032276" "MS10-048" ^
    --approved-patches "KB2124261"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012R2",
   "RejectedPatches":[
      "KB2032276",
      "MS10-048"
   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1481001494.035,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[
      "KB2124261"
   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Ubah nama dasar patch
<a name="patch-manager-cli-commands-rename-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm update-patch-baseline \
    --baseline-id pb-0c10e65780EXAMPLE \
    --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```

------
#### [ Windows Server ]

```
aws ssm update-patch-baseline ^
    --baseline-id pb-0c10e65780EXAMPLE ^
    --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
   "RejectedPatches":[
      "KB2032276",
      "MS10-048"
   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1481001795.287,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[
      "KB2124261"
   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Hapus dasar patch
<a name="patch-manager-cli-commands-delete-patch-baseline"></a>

```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Cantumkan semua dasar patch
<a name="patch-manager-cli-commands-describe-patch-baselines"></a>

```
aws ssm describe-patch-baselines
```

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      },
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

Berikut ini adalah perintah lain yang mencantumkan semua dasar patch dalam sebuah Wilayah AWS.

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[All]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[All]"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      },
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Buat daftar semua AWS baseline patch yang disediakan
<a name="patch-manager-cli-commands-describe-patch-baselines-aws"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[AWS]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[AWS]"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"AWS-DefaultPatchBaseline",
         "DefaultBaseline":true,
         "BaselineDescription":"Default Patch Baseline Provided by AWS.",
         "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Cantumkan dasar patch saya
<a name="patch-manager-cli-commands-describe-patch-baselines-custom"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-patch-baselines \
    --region us-east-2 \
    --filters "Key=OWNER,Values=[Self]"
```

------
#### [ Windows Server ]

```
aws ssm describe-patch-baselines ^
    --region us-east-2 ^
    --filters "Key=OWNER,Values=[Self]"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineIdentities":[
      {
         "BaselineName":"Windows-Server-2012R2",
         "DefaultBaseline":false,
         "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
         "BaselineId":"pb-0c10e65780EXAMPLE"
      }
   ]
}
```

### Tampilkan dasar patch
<a name="patch-manager-cli-commands-get-patch-baseline"></a>

```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```

**catatan**  
Untuk dasar patch kustom, Anda dapat menentukan ID dasar patch atau Amazon Resource Name (ARN) lengkap. Untuk baseline patch AWS-provided, Anda harus menentukan ARN lengkap. Misalnya, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE",
   "Name":"Windows-Server-2012R2",
   "PatchGroups":[
      "Web Servers"
   ],
   "RejectedPatches":[

   ],
   "GlobalFilters":{
      "PatchFilters":[

      ]
   },
   "ApprovalRules":{
      "PatchRules":[
         {
            "PatchFilterGroup":{
               "PatchFilters":[
                  {
                     "Values":[
                        "Important",
                        "Critical"
                     ],
                     "Key":"MSRC_SEVERITY"
                  },
                  {
                     "Values":[
                        "SecurityUpdates"
                     ],
                     "Key":"CLASSIFICATION"
                  },
                  {
                     "Values":[
                        "WindowsServer2012R2"
                     ],
                     "Key":"PRODUCT"
                  }
               ]
            },
            "ApproveAfterDays":5
         }
      ]
   },
   "ModifiedDate":1480997823.81,
   "CreatedDate":1480997823.81,
   "ApprovedPatches":[

   ],
   "Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```

### Dapatkan dasar patch default
<a name="patch-manager-cli-commands-get-default-patch-baseline"></a>

```
aws ssm get-default-patch-baseline --region us-east-2
```

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

### Atur dasar patch kustom sebagai default
<a name="patch-manager-cli-commands-register-default-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-default-patch-baseline \
    --region us-east-2 \
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm register-default-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Setel ulang baseline AWS patch sebagai default
<a name="patch-manager-cli-commands-register-aws-patch-baseline"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-default-patch-baseline \
    --region us-east-2 \
    --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm register-default-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Tandai dasar patch
<a name="patch-manager-cli-commands-add-tags-to-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm add-tags-to-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE" \
    --tags "Key=Project,Value=Testing"
```

------
#### [ Windows Server ]

```
aws ssm add-tags-to-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE" ^
    --tags "Key=Project,Value=Testing"
```

------

### Cantumkan tag untuk dasar patch
<a name="patch-manager-cli-commands-list-tags-for-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm list-tags-for-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm list-tags-for-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE"
```

------

### Hapus tag dari dasar patch
<a name="patch-manager-cli-commands-remove-tags-from-resource"></a>

------
#### [ Linux & macOS ]

```
aws ssm remove-tags-from-resource \
    --resource-type "PatchBaseline" \
    --resource-id "pb-0c10e65780EXAMPLE" \
    --tag-keys "Project"
```

------
#### [ Windows Server ]

```
aws ssm remove-tags-from-resource ^
    --resource-type "PatchBaseline" ^
    --resource-id "pb-0c10e65780EXAMPLE" ^
    --tag-keys "Project"
```

------

## AWS CLI perintah untuk grup tambalan
<a name="patch-group-cli-commands"></a>

**Topics**
+ [Buat grup patch](#patch-manager-cli-commands-create-patch-group)
+ [Daftarkan grup patch "server web" dengan dasar patch](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Daftarkan grup tambalan “Backend” dengan baseline patch AWS yang disediakan](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Tampilkan pendaftaran grup patch](#patch-manager-cli-commands-describe-patch-groups)
+ [Batalkan pendaftaran grup patch dari dasar patch](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)

### Buat grup patch
<a name="patch-manager-cli-commands-create-patch-group"></a>

**catatan**  
Grup patch tidak digunakan dalam operasi patching yang didasarkan pada *kebijakan patch*. Untuk informasi tentang bekerja dengan kebijakan tambalan, lihat[Konfigurasi kebijakan tambalan di Quick Setup](patch-manager-policies.md).

Untuk membantu Anda mengatur upaya penambalan, kami sarankan Anda menambahkan node terkelola ke grup tambalan dengan menggunakan tag. Grup patch memerlukan penggunaan kunci tag `Patch Group` atau`PatchGroup`. Jika Anda telah [mengizinkan tag dalam metadata instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), Anda harus menggunakan `PatchGroup` (tanpa spasi). Anda dapat menentukan nilai tag apa pun, tetapi kunci tag harus `Patch Group` atau`PatchGroup`. Untuk informasi selengkapnya tentang grup patch, lihat [Grup tambalan](patch-manager-patch-groups.md).

Setelah mengelompokkan node terkelola menggunakan tag, Anda menambahkan nilai grup patch ke baseline patch. Dengan mendaftarkan grup patch dengan dasar patch, Anda memastikan bahwa patch yang benar diinstal selama operasi patching.

#### Tugas 1: Tambahkan instans EC2 ke grup patch menggunakan tag
<a name="create-patch-group-cli-1"></a>

**catatan**  
Saat menggunakan konsol Amazon Elastic Compute Cloud (Amazon EC2) AWS CLI dan, dimungkinkan untuk `Key = Patch Group` menerapkan `Key = PatchGroup` atau memberi tag ke instance yang belum dikonfigurasi untuk digunakan dengan Systems Manager. Jika instans EC2 yang Anda harapkan untuk dilihat Patch Manager tidak terdaftar setelah menerapkan `Key = PatchGroup` tag `Patch Group` atau, lihat [Memecahkan masalah ketersediaan node terkelola](fleet-manager-troubleshooting-managed-nodes.md) untuk tips pemecahan masalah.

Jalankan perintah berikut ini untuk menambahkan tag `PatchGroup` ke sebuah instans EC2.

```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```

#### Tugas 2: Tambahkan node terkelola ke grup tambalan menggunakan tag
<a name="create-patch-group-cli-2"></a>

Jalankan perintah berikut untuk menambahkan `PatchGroup` tag ke node terkelola.

------
#### [ Linux & macOS ]

```
aws ssm add-tags-to-resource \
    --resource-type "ManagedInstance" \
    --resource-id "mi-0123456789abcdefg" \
    --tags "Key=PatchGroup,Value=GroupValue"
```

------
#### [ Windows Server ]

```
aws ssm add-tags-to-resource ^
    --resource-type "ManagedInstance" ^
    --resource-id "mi-0123456789abcdefg" ^
    --tags "Key=PatchGroup,Value=GroupValue"
```

------

#### Tugas 3: Tambahkan grup patch ke dasar patch
<a name="create-patch-group-cli-3"></a>

Jalankan perintah berikut untuk mengaitkan nilai tag `PatchGroup` ke dasar patch yang ditentukan.

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --baseline-id "pb-0c10e65780EXAMPLE" \
    --patch-group "Development"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --baseline-id "pb-0c10e65780EXAMPLE" ^
    --patch-group "Development"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
  "PatchGroup": "Development",
  "BaselineId": "pb-0c10e65780EXAMPLE"
}
```

### Daftarkan grup patch "server web" dengan dasar patch
<a name="patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --baseline-id "pb-0c10e65780EXAMPLE" \
    --patch-group "Web Servers"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --baseline-id "pb-0c10e65780EXAMPLE" ^
    --patch-group "Web Servers"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "PatchGroup":"Web Servers",
   "BaselineId":"pb-0c10e65780EXAMPLE"
}
```

### Daftarkan grup tambalan “Backend” dengan baseline patch AWS yang disediakan
<a name="patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend"></a>

------
#### [ Linux & macOS ]

```
aws ssm register-patch-baseline-for-patch-group \
    --region us-east-2 \
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
    --patch-group "Backend"
```

------
#### [ Windows Server ]

```
aws ssm register-patch-baseline-for-patch-group ^
    --region us-east-2 ^
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
    --patch-group "Backend"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "PatchGroup":"Backend",
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

### Tampilkan pendaftaran grup patch
<a name="patch-manager-cli-commands-describe-patch-groups"></a>

```
aws ssm describe-patch-groups --region us-east-2
```

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "PatchGroupPatchBaselineMappings":[
      {
         "PatchGroup":"Backend",
         "BaselineIdentity":{
            "BaselineName":"AWS-DefaultPatchBaseline",
            "DefaultBaseline":false,
            "BaselineDescription":"Default Patch Baseline Provided by AWS.",
            "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
         }
      },
      {
         "PatchGroup":"Web Servers",
         "BaselineIdentity":{
            "BaselineName":"Windows-Server-2012R2",
            "DefaultBaseline":true,
            "BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
            "BaselineId":"pb-0c10e65780EXAMPLE"
         }
      }
   ]
}
```

### Batalkan pendaftaran grup patch dari dasar patch
<a name="patch-manager-cli-commands-deregister-patch-baseline-for-patch-group"></a>

------
#### [ Linux & macOS ]

```
aws ssm deregister-patch-baseline-for-patch-group \
    --region us-east-2 \
    --patch-group "Production" \
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm deregister-patch-baseline-for-patch-group ^
    --region us-east-2 ^
    --patch-group "Production" ^
    --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "PatchGroup":"Production",
   "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```

## AWS CLI perintah untuk melihat ringkasan dan detail tambalan
<a name="patch-details-cli-commands"></a>

**Topics**
+ [Dapatkan semua patch yang didefinisikan oleh dasar patch](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Dapatkan semua patch untuk AmazonLinux 2018.03 yang memiliki Klasifikasi `SECURITY` dan Tingkat Keparahan `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Dapatkan semua patch untuk Windows Server 2012 yang memiliki kepelikan MSRC `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [Dapatkan semua patch yang tersedia](#patch-manager-cli-commands-describe-available-patches)
+ [Dapatkan status ringkasan tambalan per node yang dikelola](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Dapatkan detail kepatuhan tambalan untuk node terkelola](#patch-manager-cli-commands-describe-instance-patches)
+ [Melihat hasil kepatuhan patching (AWS CLI)](#viewing-patch-compliance-results-cli)

### Dapatkan semua patch yang didefinisikan oleh dasar patch
<a name="patch-manager-cli-commands-describe-effective-patches-for-patch-baseline"></a>

**catatan**  
Perintah ini hanya didukung untuk dasar patch Windows Server.

------
#### [ Linux & macOS ]

```
aws ssm describe-effective-patches-for-patch-baseline \
    --region us-east-2 \
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------
#### [ Windows Server ]

```
aws ssm describe-effective-patches-for-patch-baseline ^
    --region us-east-2 ^
    --baseline-id "pb-0c10e65780EXAMPLE"
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "NextToken":"--token string truncated--",
   "EffectivePatches":[
      {
         "PatchStatus":{
            "ApprovalDate":1384711200.0,
            "DeploymentStatus":"APPROVED"
         },
         "Patch":{
            "ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
            "ProductFamily":"Windows",
            "Product":"WindowsServer2012R2",
            "Vendor":"Microsoft",
            "Description":"A security issue has been identified in a Microsoft software 
               product that could affect your system. You can help protect your system 
               by installing this update from Microsoft. For a complete listing of the 
               issues that are included in this update, see the associated Microsoft 
               Knowledge Base article. After you install this update, you may have to 
               restart your system.",
            "Classification":"SecurityUpdates",
            "Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
            "ReleaseDate":1384279200.0,
            "MsrcClassification":"Critical",
            "Language":"All",
            "KbNumber":"KB2876331",
            "MsrcNumber":"MS13-089",
            "Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
         }
      },
      {
         "PatchStatus":{
            "ApprovalDate":1428858000.0,
            "DeploymentStatus":"APPROVED"
         },
         "Patch":{
            "ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
            "ProductFamily":"Windows",
            "Product":"WindowsServer2012R2",
            "Vendor":"Microsoft",
            "Description":"Windows Server 2012 R2 Update is a cumulative 
               set of security updates, critical updates and updates. You 
               must install Windows Server 2012 R2 Update to ensure that 
               your computer can continue to receive future Windows Updates, 
               including security updates. For a complete listing of the 
               issues that are included in this update, see the associated 
               Microsoft Knowledge Base article for more information. After 
               you install this item, you may have to restart your computer.",
            "Classification":"SecurityUpdates",
            "Title":"Windows Server 2012 R2 Update (KB2919355)",
            "ReleaseDate":1428426000.0,
            "MsrcClassification":"Critical",
            "Language":"All",
            "KbNumber":"KB2919355",
            "MsrcNumber":"MS14-018",
            "Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
         }
      }
     ---output truncated---
```

### Dapatkan semua patch untuk AmazonLinux 2018.03 yang memiliki Klasifikasi `SECURITY` dan Tingkat Keparahan `Critical`
<a name="patch-manager-cli-commands-describe-available-patches-linux"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-available-patches \
    --region us-east-2 \
    --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```

------
#### [ Windows Server ]

```
aws ssm describe-available-patches ^
    --region us-east-2 ^
    --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
    "Patches": [
        {
            "AdvisoryIds": ["ALAS-2011-1"],
            "BugzillaIds": [ "1234567" ],
            "Classification": "SECURITY",
            "CVEIds": [ "CVE-2011-3192"],
            "Name": "zziplib",
            "Epoch": "0",
            "Version": "2.71",
            "Release": "1.3.amzn1",
            "Arch": "i686",
            "Product": "AmazonLinux2018.03",
            "ReleaseDate": 1590519815,
            "Severity": "CRITICAL"
        }
    ]
}     
---output truncated---
```

### Dapatkan semua patch untuk Windows Server 2012 yang memiliki kepelikan MSRC `Critical`
<a name="patch-manager-cli-commands-describe-available-patches"></a>

------
#### [ Linux & macOS ]

```
aws ssm describe-available-patches \
    --region us-east-2 \
    --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```

------
#### [ Windows Server ]

```
aws ssm describe-available-patches ^
    --region us-east-2 ^
    --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "Patches":[
      {
         "ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
         "ProductFamily":"Windows",
         "Product":"WindowsServer2012",
         "Vendor":"Microsoft",
         "Description":"A security issue has been identified that could 
           allow an unauthenticated remote attacker to compromise your 
           system and gain control over it. You can help protect your 
           system by installing this update from Microsoft. After you 
           install this update, you may have to restart your system.",
         "Classification":"SecurityUpdates",
         "Title":"Security Update for Windows Server 2012 (KB2727528)",
         "ReleaseDate":1352829600.0,
         "MsrcClassification":"Critical",
         "Language":"All",
         "KbNumber":"KB2727528",
         "MsrcNumber":"MS12-072",
         "Id":"1eb507be-2040-4eeb-803d-abc55700b715"
      },
      {
         "ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
         "ProductFamily":"Windows",
         "Product":"WindowsServer2012",
         "Vendor":"Microsoft",
         "Description":"A security issue has been identified that could 
           allow an unauthenticated remote attacker to compromise your 
           system and gain control over it. You can help protect your 
           system by installing this update from Microsoft. After you 
           install this update, you may have to restart your system.",
         "Classification":"SecurityUpdates",
         "Title":"Security Update for Microsoft .NET Framework 3.5 on 
           Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
         "ReleaseDate":1352829600.0,
         "MsrcClassification":"Critical",
         "Language":"All",
         "KbNumber":"KB2729462",
         "MsrcNumber":"MS12-074",
         "Id":"af873760-c97c-4088-ab7e-5219e120eab4"
      }
     
---output truncated---
```

### Dapatkan semua patch yang tersedia
<a name="patch-manager-cli-commands-describe-available-patches"></a>

```
aws ssm describe-available-patches --region us-east-2
```

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "NextToken":"--token string truncated--",
   "Patches":[
      {
            "Classification": "SecurityUpdates",
            "ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
            "Description": "A security issue has been identified in a Microsoft software 
            product that could affect your system. You can help protect your system by 
            installing this update from Microsoft. For a complete listing of the issues 
            that are included in this update, see the associated Microsoft Knowledge Base 
            article. After you install this update, you may have to restart your system.",
            "Id": "11adea10-0701-430e-954f-9471595ae246",
            "KbNumber": "KB4074588",
            "Language": "All",
            "MsrcNumber": "",
            "MsrcSeverity": "Critical",
            "Product": "WindowsServer2016",
            "ProductFamily": "Windows",
            "ReleaseDate": 1518548400,
            "Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based 
            Systems (KB4074588)",
            "Vendor": "Microsoft"
        },
        {
            "Classification": "SecurityUpdates",
            "ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
            "Description": "A security issue has been identified in a Microsoft software 
            product that could affect your system. You can help protect your system by 
            installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
            "KbNumber": "KB4074590",
            "Language": "All",
            "MsrcNumber": "",
            "MsrcSeverity": "Critical",
            "Product": "WindowsServer2016",
            "ProductFamily": "Windows",
            "ReleaseDate": 1518544805,
            "Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based 
            Systems (KB4074590)",
            "Vendor": "Microsoft"
        }
      ---output truncated---
```

### Dapatkan status ringkasan tambalan per node yang dikelola
<a name="patch-manager-cli-commands-describe-instance-patch-states"></a>

Ringkasan simpul per-kelola memberi Anda jumlah tambalan dalam status berikut per node: "NotApplicable“, “Hilang”, “Gagal”, "InstalledOther" dan “Dipasang”. 

------
#### [ Linux & macOS ]

```
aws ssm describe-instance-patch-states \
    --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```

------
#### [ Windows Server ]

```
aws ssm describe-instance-patch-states ^
    --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "InstancePatchStates":[
      {
            "InstanceId": "i-08ee91c0b17045407",
            "PatchGroup": "",
            "BaselineId": "pb-0c10e65780EXAMPLE",
            "SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
            "InstalledCount": 50,
            "InstalledOtherCount": 353,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 0,
            "FailedCount": 0,
            "UnreportedNotApplicableCount": -1,
            "NotApplicableCount": 671,
            "OperationStartTime": "2020-01-24T12:37:56-08:00",
            "OperationEndTime": "2020-01-24T12:37:59-08:00",
            "Operation": "Scan",
            "RebootOption": "NoReboot"
        },
        {
            "InstanceId": "i-09a618aec652973a9",
            "PatchGroup": "",
            "BaselineId": "pb-0c10e65780EXAMPLE",
            "SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
            "InstalledCount": 36,
            "InstalledOtherCount": 396,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 3,
            "FailedCount": 0,
            "UnreportedNotApplicableCount": -1,
            "NotApplicableCount": 420,
            "OperationStartTime": "2020-01-24T12:37:34-08:00",
            "OperationEndTime": "2020-01-24T12:37:37-08:00",
            "Operation": "Scan",
            "RebootOption": "NoReboot"
        }
     ---output truncated---
```

### Dapatkan detail kepatuhan tambalan untuk node terkelola
<a name="patch-manager-cli-commands-describe-instance-patches"></a>

```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```

Sistem mengembalikan informasi seperti berikut ini.

```
{
   "NextToken":"--token string truncated--",
   "Patches":[
      {
            "Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
            "KBId": "bind-libs.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:24-07:00"
        },
        {
            "Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
            "KBId": "bind-utils.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:32-07:00"
        },
        {
            "Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
            "KBId": "dhclient.x86_64",
            "Classification": "Security",
            "Severity": "Important",
            "State": "Installed",
            "InstalledTime": "2019-08-26T11:05:31-07:00"
        },
    ---output truncated---
```

### Melihat hasil kepatuhan patching (AWS CLI)
<a name="viewing-patch-compliance-results-cli"></a>

**Untuk melihat hasil kepatuhan tambalan untuk satu node terkelola**

Jalankan perintah berikut di AWS Command Line Interface (AWS CLI) untuk melihat hasil kepatuhan patch untuk satu node terkelola.

```
aws ssm describe-instance-patch-states --instance-id instance-id
```

Ganti *instance-id* dengan ID node terkelola yang ingin Anda lihat hasilnya, dalam format `i-02573cafcfEXAMPLE` atau`mi-0282f7c436EXAMPLE`.

Sistem mengembalikan informasi seperti berikut ini.

```
{
    "InstancePatchStates": [
        {
            "InstanceId": "i-02573cafcfEXAMPLE",
            "PatchGroup": "mypatchgroup",
            "BaselineId": "pb-0c10e65780EXAMPLE",            
            "SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
            "CriticalNonCompliantCount": 2,
            "SecurityNonCompliantCount": 2,
            "OtherNonCompliantCount": 1,
            "InstalledCount": 123,
            "InstalledOtherCount": 334,
            "InstalledPendingRebootCount": 0,
            "InstalledRejectedCount": 0,
            "MissingCount": 1,
            "FailedCount": 2,
            "UnreportedNotApplicableCount": 11,
            "NotApplicableCount": 2063,
            "OperationStartTime": "2021-05-03T11:00:56-07:00",
            "OperationEndTime": "2021-05-03T11:01:09-07:00",
            "Operation": "Scan",
            "LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
            "RebootOption": "RebootIfNeeded"
        }
    ]
}
```

**Untuk melihat ringkasan jumlah tambalan untuk semua instans EC2 di Wilayah**

`describe-instance-patch-states` mendukung mengambil hasil untuk satu instans terkelola saja dalam satu waktu. Namun, menggunakan script kustom dengan perintah `describe-instance-patch-states`, Anda dapat membuat laporan yang lebih terperinci.

Sebagai contoh, jika [alat filter jq](https://stedolan.github.io/jq/download/) diinstal pada mesin lokal Anda, Anda dapat menjalankan perintah berikut ini untuk mengidentifikasi instans EC2 apa yang ada di Wilayah AWS tertentu yang berstatus `InstalledPendingReboot`.

```
aws ssm describe-instance-patch-states \
    --instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
    --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```

*region*mewakili pengenal untuk Wilayah AWS didukung oleh AWS Systems Manager, seperti `us-east-2` untuk Wilayah AS Timur (Ohio). Untuk daftar *region* nilai yang didukung, lihat kolom **Region** di [titik akhir layanan Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) di *Referensi Umum Amazon Web Services*.

Contoh:

```
aws ssm describe-instance-patch-states \
    --instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
    --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```

Sistem mengembalikan informasi seperti berikut ini.

```
1       i-02573cafcfEXAMPLE
0       i-0471e04240EXAMPLE
3       i-07782c72faEXAMPLE
6       i-083b678d37EXAMPLE
0       i-03a530a2d4EXAMPLE
1       i-01f68df0d0EXAMPLE
0       i-0a39c0f214EXAMPLE
7       i-0903a5101eEXAMPLE
7       i-03823c2fedEXAMPLE
```

Selain `InstalledPendingRebootCount`, daftar jenis jumlah yang dapat Anda cari termasuk yang berikut:
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`

## AWS CLI perintah untuk memindai dan menambal node yang dikelola
<a name="patch-operations-cli-commands"></a>

Setelah menjalankan perintah berikut ini untuk memindai kepatuhan patch atau menginstal patch, Anda dapat menggunakan perintah di bagian [AWS CLI perintah untuk melihat ringkasan dan detail tambalan](#patch-details-cli-commands) untuk melihat informasi tentang status dan kepatuhan patch.

**Topics**
+ [Pindai node terkelola untuk kepatuhan patch (AWS CLI)](#patch-operations-scan)
+ [Instal tambalan pada node terkelola ()AWS CLI](#patch-operations-install-cli)

### Pindai node terkelola untuk kepatuhan patch (AWS CLI)
<a name="patch-operations-scan"></a>

**Untuk memindai node terkelola tertentu untuk kepatuhan patch**

Jalankan perintah berikut.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
    --parameters 'Operation=Scan' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
    --parameters "Operation=Scan" ^
    --timeout-seconds 600
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
    "Command": {
        "CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621974475.267,
        "Parameters": {
            "Operation": [
                "Scan"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "InstanceIds",
                "Values": [
                    "i-02573cafcfEXAMPLE,
                     i-0471e04240EXAMPLE"
                ]
            }
        ],
        "RequestedDateTime": 1621952275.267,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

**Untuk memindai node terkelola untuk kepatuhan patch dengan tag grup patch**

Jalankan perintah berikut.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key='tag:PatchGroup',Values='Web servers' \
    --parameters 'Operation=Scan' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key="tag:PatchGroup",Values="Web servers" ^
    --parameters "Operation=Scan" ^
    --timeout-seconds 600
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
    "Command": {
        "CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621974983.128,
        "Parameters": {
            "Operation": [
                "Scan"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:PatchGroup",
                "Values": [
                    "Web servers"
                ]
            }
        ],
        "RequestedDateTime": 1621952783.128,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

### Instal tambalan pada node terkelola ()AWS CLI
<a name="patch-operations-install-cli"></a>

**Untuk menginstal patch pada node terkelola tertentu**

Jalankan perintah berikut. 

**catatan**  
Node terkelola target reboot sesuai kebutuhan untuk menyelesaikan instalasi patch. Untuk informasi selengkapnya, lihat [Dokumen SSM Command untuk menambal: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
    --parameters 'Operation=Install' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
    --parameters "Operation=Install" ^
    --timeout-seconds 600
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
    "Command": {
        "CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621975301.791,
        "Parameters": {
            "Operation": [
                "Install"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "InstanceIds",
                "Values": [
                    "i-02573cafcfEXAMPLE,
                     i-0471e04240EXAMPLE"
                ]
            }
        ],
        "RequestedDateTime": 1621953101.791,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

**Untuk menginstal patch pada node terkelola dalam grup patch tertentu**

Jalankan perintah berikut.

------
#### [ Linux & macOS ]

```
aws ssm send-command \
    --document-name 'AWS-RunPatchBaseline' \
    --targets Key='tag:PatchGroup',Values='Web servers' \
    -parameters 'Operation=Install' \
    --timeout-seconds 600
```

------
#### [ Windows Server ]

```
aws ssm send-command ^
    --document-name "AWS-RunPatchBaseline" ^
    --targets Key="tag:PatchGroup",Values="Web servers" ^
    --parameters "Operation=Install" ^
    --timeout-seconds 600
```

------

Sistem mengembalikan informasi seperti berikut ini.

```
{
    "Command": {
        "CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
        "DocumentName": "AWS-RunPatchBaseline",
        "DocumentVersion": "$DEFAULT",
        "Comment": "",
        "ExpiresAfter": 1621975407.865,
        "Parameters": {
            "Operation": [
                "Install"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:PatchGroup",
                "Values": [
                    "Web servers"
                ]
            }
        ],
        "RequestedDateTime": 1621953207.865,
        "Status": "Pending",
        "StatusDetails": "Pending",
        "TimeoutSeconds": 600,

    ---output truncated---

    }
}
```

# AWS Systems ManagerPatch Managertutorial
<a name="patch-manager-tutorials"></a>

Tutorial di bagian ini menunjukkan cara menggunakanPatch Manager, alat di AWS Systems Manager, untuk beberapa skenario penambalan.

**Topics**
+ [Tutorial: Menambal server di IPv6 satu-satunya lingkungan](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutorial: Buat baseline patch untuk menginstal Paket Layanan Windows menggunakan konsol](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: Perbarui dependensi aplikasi, tambal node terkelola, dan lakukan pemeriksaan kesehatan khusus aplikasi menggunakan konsol](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: Menambal lingkungan server menggunakan AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)

# Tutorial: Menambal server di IPv6 satu-satunya lingkungan
<a name="patch-manager-server-patching-iPv6-tutorial"></a>

Patch Managermendukung penambalan node di lingkungan yang hanya memiliki IPv6. Dengan memperbarui SSM Agent konfigurasi, operasi patching dapat dikonfigurasi untuk hanya melakukan panggilan ke titik akhir IPv6 layanan.

**Untuk menambal server di IPv6 satu-satunya lingkungan**

1. Pastikan bahwa SSM Agent versi 3.3270.0 atau yang lebih baru diinstal pada node terkelola.

1. Pada node terkelola, navigasikan ke file SSM Agent konfigurasi. Anda dapat menemukan `amazon-ssm-agent.json` file di direktori berikut:
   + Linux: `/etc/amazon/ssm/`
   + macOS: `/opt/aws/ssm/`
   + Windows Server: `C:\Program Files\Amazon\SSM`

   Jika `amazon-ssm-agent.json` belum ada, salin isi di `amazon-ssm-agent.json.template` bawah direktori yang sama ke`amazon-ssm-agent.json`.

1. Perbarui entri berikut untuk mengatur Wilayah yang benar dan atur `UseDualStackEndpoint` ke`true`:

   ```
   {
    --------
       "Agent": {
           "Region": "region",
           "UseDualStackEndpoint": true
       },
   --------
   }
   ```

1. Mulai ulang SSM Agent layanan menggunakan perintah yang sesuai untuk sistem operasi Anda:
   + Linux: `sudo systemctl restart amazon-ssm-agent`
   + Ubuntu Servermenggunakan Snap: `sudo snap restart amazon-ssm-agent`
   + macOS: `sudo launchctl stop com.amazon.aws.ssm` diikuti oleh `sudo launchctl start com.amazon.aws.ssm`
   + Windows Server: `Stop-Service AmazonSSMAgent` diikuti oleh `Start-Service AmazonSSMAgent`

   Untuk daftar lengkap perintah per sistem operasi, lihat[Memeriksa SSM Agent status dan memulai agen](ssm-agent-status-and-restart.md).

1. Jalankan operasi penambalan apa pun untuk memverifikasi operasi penambalan berhasil di lingkungan IPv6 -only Anda. Pastikan node yang ditambal memiliki konektivitas ke sumber patch. Anda dapat memeriksa Run Command output dari eksekusi patching untuk memeriksa peringatan tentang repositori yang tidak dapat diakses. Saat menambal node yang berjalan di lingkungan IPv6 satu-satunya, pastikan bahwa node memiliki konektivitas ke sumber patch. Anda dapat memeriksa Run Command output dari eksekusi patching untuk memeriksa peringatan tentang repositori yang tidak dapat diakses. Untuk sistem operasi berbasis DNF, dimungkinkan untuk mengonfigurasi repositori yang tidak tersedia untuk dilewati selama penambalan jika opsi diatur ke bawah. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Sistem operasi berbasis DNF termasuk Amazon Linux 2023, Red Hat Enterprise Linux 8 dan versi yang lebih baru, 8 dan versi yang lebih baru,,Rocky Linux, AlmaLinux & CentOS Oracle Linux 8 dan versi yang lebih baru. Di Amazon Linux 2023, `skip_if_unavailable` opsi diatur ke secara `True` default.
**catatan**  
 Saat menggunakan fitur Install Override List atau Baseline Override, pastikan URL yang disediakan dapat dijangkau dari node. Jika opsi SSM Agent konfigurasi `UseDualStackEndpoint` disetel ke`true`, maka klien S3 dualstack digunakan saat URL S3 disediakan.

# Tutorial: Buat baseline patch untuk menginstal Paket Layanan Windows menggunakan konsol
<a name="patch-manager-windows-service-pack-patch-baseline-tutorial"></a>

Ketika Anda membuat dasar patch kustom, Anda dapat menentukan bahwa semua, beberapa, atau hanya satu jenis patch yang didukung telah diinstal.

Di dasar patch untuk Windows, Anda dapat memilih `ServicePacks` sebagai satu-satunya opsi **Klasifikasi** untuk membatasi pembaruan patching hanya untuk Service Packs. Paket Layanan dapat diinstal secara otomatis olehPatch Manager, alat di AWS Systems Manager, asalkan pembaruan tersedia di Windows Update atau Windows Server Update Services (WSUS).

Anda dapat mengkonfigurasi dasar patch untuk mengendalikan apakah Service Packs untuk semua versi Windows diinstal, atau hanya untuk versi tertentu, seperti Windows 7 atau Windows Server 2016. 

Gunakan prosedur berikut untuk membuat baseline patch kustom untuk digunakan secara eksklusif untuk menginstal semua Paket Layanan pada node terkelola Windows Anda. 

**Untuk membuat baseline patch untuk menginstal Windows Service Packs (konsol)**

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch baseline**, lalu pilih **Create patch** baseline. 

1. Untuk **Nama**, masukkan nama untuk dasar patch baru Anda, misalnya, `MyWindowsServicePackPatchBaseline`.

1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk dasar patch ini.

1. Untuk **Sistem operasi**, pilih `Windows`.

1. Jika Anda ingin mulai menggunakan dasar patch ini sebagai default untuk Windows segera setelah Anda membuatnya, pilih **Atur dasar patch ini sebagai dasar patch default untuk instans Windows Server**.
**catatan**  
Opsi ini hanya tersedia jika Anda pertama kali mengakses Patch Manager sebelum [kebijakan tambalan](patch-manager-policies.md) dirilis pada 22 Desember 2022.  
Untuk informasi tentang mengatur dasar patch yang ada sebagai default, lihat [Mengatur dasar patch yang ada sebagai default](patch-manager-default-patch-baseline.md).

1. Di bagian **Aturan persetujuan untuk sistem operasi**, gunakan bidang tersebut untuk membuat satu atau lebih aturan persetujuan otomatis.
   + **Produk**: Versi sistem operasi yang berlaku untuk aturan persetujuan, seperti`WindowsServer2012`. Anda dapat memilih satu, lebih dari satu, atau semua versi Windows yang didukung. Pilihan default adalah `All`.
   + **Klasifikasi**: Pilih `ServicePacks`. 
   + **Kepelikan**: Nilai kepelikan patch yang diberlakukan aturan. Untuk memastikan bahwa semua Service Packs disertakan oleh aturan, pilih `All`. 
   + **Persetujuan otomatis**: Metode untuk memilih patch untuk persetujuan otomatis.
     + **Menyetujui patch setelah beberapa hari tertentu**: Jumlah hari Patch Manager untuk menunggu setelah patch dirilis atau diperbarui sebelum patch secara otomatis disetujui. Anda dapat memasukkan bilangan bulat apa saja dari nol (0) sampai 360. Untuk sebagian besar skenario, kami merekomendasikan untuk menunggu tidak lebih dari 100 hari.
     + **Menyetujui patch yang dirilis hingga tanggal tertentu: Tanggal** rilis patch yang Patch Manager secara otomatis menerapkan semua patch yang dirilis atau diperbarui pada atau sebelum tanggal tersebut. Misalnya, jika Anda menentukan 7 Juli 2023, tidak ada tambalan yang dirilis atau terakhir diperbarui pada atau setelah 8 Juli 2023, yang diinstal secara otomatis.
   + (Opsional) **Laporan kepatuhan**: Tingkat kepelikan yang ingin Anda tetapkan untuk Service Packs yang disetujui oleh baseline, seperti `High`.
**catatan**  
Jika Anda menentukan tingkat pelaporan kepatuhan dan status patch dari Paket Layanan yang disetujui dilaporkan sebagai`Missing`, maka tingkat keparahan kepatuhan yang dilaporkan secara keseluruhan baseline patch adalah tingkat keparahan yang Anda tentukan.

1. (Opsional) Untuk **Kelola tag**, terapkan satu atau beberapa name/value pasangan kunci tag ke baseline patch.

   Tanda adalah metadata opsional yang Anda tetapkan ke sumber daya. Tag memungkinkan Anda untuk mengkategorikan sumber daya dengan berbagai cara, seperti berdasarkan tujuan, pemilik, atau lingkungan. Untuk dasar patch ini yang didedikasikan untuk memperbarui Service Packs, Anda dapat menentukan pasangan kunci-nilai seperti berikut:
   + `Key=OS,Value=Windows`
   + `Key=Classification,Value=ServicePacks`

1. Pilih **Buat dasar patch**.

# Tutorial: Perbarui dependensi aplikasi, tambal node terkelola, dan lakukan pemeriksaan kesehatan khusus aplikasi menggunakan konsol
<a name="aws-runpatchbaselinewithhooks-tutorial"></a>

Dalam banyak kasus, node terkelola harus di-boot ulang setelah ditambal dengan pembaruan perangkat lunak terbaru. Namun, me-reboot node dalam produksi tanpa perlindungan di tempat dapat menyebabkan beberapa masalah, seperti memanggil alarm, merekam data metrik yang salah, dan mengganggu sinkronisasi data.

Tutorial ini menunjukkan bagaimana menghindari masalah seperti ini dengan menggunakan AWS Systems Manager dokumen (dokumen SSM) `AWS-RunPatchBaselineWithHooks` untuk mencapai operasi penambalan multi-langkah yang kompleks yang menyelesaikan hal berikut:

1. Mencegah koneksi baru ke aplikasi

1. Menginstal pembaruan sistem operasi

1. Memperbarui dependensi paket aplikasi

1. Memulai ulang sistem

1. Melakukan pemeriksaan kesehatan khusus aplikasi

Untuk contoh ini, kami telah menyiapkan infrastruktur kami dengan cara ini:
+ Mesin virtual yang ditargetkan terdaftar sebagai node terkelola dengan Systems Manager.
+ `Iptables` digunakan sebagai firewall lokal.
+ Aplikasi yang di-host pada node terkelola berjalan pada port 443.
+ Aplikasi yang di-host pada node yang dikelola adalah `nodeJS` aplikasi.
+ Aplikasi yang di-host pada node yang dikelola dikelola oleh manajer proses pm2.
+ Aplikasi ini sudah memiliki titik akhir pemeriksaan kesehatan yang ditentukan.
+ Titik akhir pemeriksaan kesehatan aplikasi tidak memerlukan autentikasi pengguna akhir. Titik akhir memungkinkan dilakukannya pemeriksaan kesehatan yang memenuhi persyaratan organisasi dalam menetapkan ketersediaan. (Di lingkungan Anda, mungkin cukup untuk memastikan bahwa `nodeJS` aplikasi berjalan dan dapat mendengarkan permintaan. Dalam kasus lain, Anda mungkin ingin juga memverifikasi bahwa koneksi ke lapisan caching atau lapisan database telah dibuat.)

Contoh dalam tutorial ini adalah untuk tujuan demonstrasi saja dan tidak dimaksudkan untuk diimplementasikan apa adanya ke dalam lingkungan produksi. Juga, perlu diingat bahwa fitur kait siklus hidup, alat di Systems ManagerPatch Manager, dengan `AWS-RunPatchBaselineWithHooks` dokumen dapat mendukung banyak skenario lainnya. Berikut adalah beberapa contoh tanda.
+ Hentikan agen pelaporan metrik sebelum menambal dan memulai ulang setelah node terkelola reboot.
+ Lepaskan node terkelola dari cluster CRM atau PCS sebelum menambal dan memasang kembali setelah node reboot.
+ Perbarui perangkat lunak pihak ketiga (misalnya, Java, Tomcat, aplikasi Adobe, dan sebagainya) pada Windows Server mesin setelah pembaruan sistem operasi (OS) diterapkan, tetapi sebelum node yang dikelola reboot.

**Untuk memperbarui dependensi aplikasi, tambal node terkelola, dan lakukan pemeriksaan kesehatan khusus aplikasi**

1. Buat dokumen SSM untuk script pra-instalasi Anda dengan konten berikut ini dan berikan nama `NodeJSAppPrePatch`. Ganti *your\$1application* dengan nama aplikasi Anda.

   Script ini segera memblokir permintaan masuk baru dan menyediakan lima detik untuk permintaan yang sudah aktif agar diselesaikan sebelum memulai operasi patching. Untuk opsi `sleep`, tentukan jumlah detik lebih besar daripada yang biasanya diperlukan untuk permintaan masuk diselesaikan.

   ```
   # exit on error
   set -e
   # set up rule to block incoming traffic
   iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
   # wait for current connections to end. Set timeout appropriate to your application's latency
   sleep 5 
   # Stop your application
   pm2 stop your_application
   ```

   Untuk informasi tentang membuat dokumen SSM, lihat [Membuat konten dokumen SSM](documents-creating-content.md).

1. Buat dokumen SSM lain dengan konten berikut ini untuk script pasca instalasi Anda untuk memperbarui dependensi aplikasi Anda dan berikan nama `NodeJSAppPostPatch`. Ganti */your/application/path* dengan jalur ke aplikasi Anda.

   ```
   cd /your/application/path
   npm update 
   # you can use npm-check-updates if you want to upgrade major versions
   ```

1. Buat dokumen SSM lain dengan konten berikut ini untuk script `onExit` Anda untuk menyalakan kembali aplikasi Anda dan melakukan pemeriksaan kesehatan. Namakan dokumen SSM ini `NodeJSAppOnExitPatch`. Ganti *your\$1application* dengan nama aplikasi Anda.

   ```
   # exit on error
   set -e
   # restart nodeJs application
   pm2 start your_application
   # sleep while your application starts and to allow for a crash
   sleep 10
   # check with pm2 to see if your application is running
   pm2 pid your_application
   # re-enable incoming connections
   iptables -D INPUT -j DROP -p tcp --syn --destination-port 
   # perform health check
   /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
   ```

1. Buat asosiasi diState Manager, alat di AWS Systems Manager, untuk mengeluarkan operasi dengan melakukan langkah-langkah berikut:

   1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

   1. Di panel navigasi, pilih **State Manager**, lalu pilih **Buat asosiasi**.

   1. Untuk **Nama**, berikan nama untuk membantu mengidentifikasi tujuan asosiasi.

   1. Di daftar **Dokumen**, pilih `AWS-RunPatchBaselineWithHooks`.

   1. Untuk **Operasi**, pilih **Instal**.

   1. (Opsional) Untuk **Snapshot Id**, berikan GUID yang Anda buat untuk membantu mempercepat operasi dan memastikan konsistensi. Nilai GUID dapat sesederhana `00000000-0000-0000-0000-111122223333`.

   1. Untuk **Pre Install Hook Doc Name**, masukkan `NodeJSAppPrePatch`. 

   1. Untuk **Post Install Hook Doc Name**, masukkan `NodeJSAppPostPatch`. 

   1. Untuk **On ExitHook Doc Name**, masukkan`NodeJSAppOnExitPatch`. 

1. Untuk **Target**, identifikasi node terkelola Anda dengan menentukan tag, memilih node secara manual, memilih grup sumber daya, atau memilih semua node terkelola.

1. Untuk **Tentukan jadwal**, tentukan seberapa sering untuk menjalankan asosiasi. Untuk patch node terkelola, seminggu sekali adalah irama umum.

1. Di bagian **Rate control**, pilih opsi untuk mengontrol bagaimana asosiasi berjalan pada beberapa node terkelola. Pastikan bahwa hanya sebagian dari node terkelola yang diperbarui pada suatu waktu. Jika tidak, semua atau sebagian besar armada Anda dapat dijadikan offline sekaligus. Untuk informasi lebih lanjut tentang menggunakan kontrol rate, lihat [Memahami target dan kontrol tingkat dalam State Manager asosiasi](systems-manager-state-manager-targets-and-rate-controls.md).

1. (Opsional) Untuk **Pilihan output**, untuk menyimpan output perintah ke file, pilih kotak **Aktifkan output penulisan ke S3**. Masukkan nama bucket dan prefiks (folder) di dalam kotak.
**catatan**  
Izin S3 yang memberikan kemampuan untuk menulis data ke bucket S3 adalah izin dari profil instance yang ditetapkan ke node terkelola, bukan izin pengguna IAM yang melakukan tugas ini. Untuk informasi selengkapnya, lihat [Mengonfigurasi izin instans yang diperlukan untuk Systems Manager](setup-instance-permissions.md) atau [Membuat peran layanan IAM untuk lingkungan hibrid](hybrid-multicloud-service-role.md). Selain itu, jika bucket S3 yang ditentukan berbeda Akun AWS, verifikasi bahwa profil instance atau peran layanan IAM yang terkait dengan node terkelola memiliki izin yang diperlukan untuk menulis ke bucket tersebut.

1. Pilih **Buat Asosiasi**.

# Tutorial: Menambal lingkungan server menggunakan AWS CLI
<a name="patch-manager-patch-servers-using-the-aws-cli"></a>

Prosedur berikut ini menjelaskan cara melakukan patching untuk lingkungan server dengan menggunakan dasar patch kustom, grup patch, dan jendela pemeliharaan.

**Sebelum Anda mulai**
+ Instal atau perbarui SSM Agent pada node terkelola Anda. Untuk menambal node yang dikelola Linux, node Anda harus menjalankan SSM Agent versi 2.0.834.0 atau yang lebih baru. Untuk informasi selengkapnya, lihat [Memperbarui SSM Agent penggunaan Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Konfigurasikan peran dan izin untukMaintenance Windows, alat di AWS Systems Manager. Untuk informasi selengkapnya, lihat [Menyiapkan Maintenance Windows](setting-up-maintenance-windows.md).
+ Instal dan konfigurasikan AWS Command Line Interface (AWS CLI), jika Anda belum melakukannya.

  Untuk selengkapnya, lihat [Menginstal atau memperbarui versi terbaru AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Untuk mengkonfigurasi Patch Manager dan menambal node yang dikelola (baris perintah)**

1. Jalankan perintah berikut ini untuk membuat dasar patch untuk Windows yang bernama `Production-Baseline`. Garis dasar tambalan ini menyetujui tambalan untuk lingkungan produksi 7 hari setelah dirilis atau terakhir diperbarui. Artinya, kami menandai dasar patch untuk menunjukkan bahwa itu untuk lingkungan produksi.
**catatan**  
`OperatingSystem`Parameter dan `PatchFilters` bervariasi tergantung pada sistem operasi node terkelola target yang berlaku untuk patch baseline. Untuk informasi selengkapnya, lihat [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) dan [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).

------
#### [ Linux & macOS ]

   ```
   aws ssm create-patch-baseline \
       --name "Production-Baseline" \
       --operating-system "WINDOWS" \
       --tags "Key=Environment,Value=Production" \
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
       --description "Baseline containing all updates approved for production systems"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-patch-baseline ^
       --name "Production-Baseline" ^
       --operating-system "WINDOWS" ^
       --tags "Key=Environment,Value=Production" ^
       --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
       --description "Baseline containing all updates approved for production systems"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendaftarkan dasar patch "Production-Baseline" untuk dua grup patch. Grup tersebut bernama "Database Servers" dan "Front-End Servers".

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Database Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "PatchGroup":"Database Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-patch-baseline-for-patch-group \
       --baseline-id pb-0c10e65780EXAMPLE \
       --patch-group "Front-End Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-patch-baseline-for-patch-group ^
       --baseline-id pb-0c10e65780EXAMPLE ^
       --patch-group "Front-End Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "PatchGroup":"Front-End Servers",
      "BaselineId":"pb-0c10e65780EXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk membuat dua jendela pemeliharaan untuk server produksi. Jendela pertama berjalan setiap hari Selasa pukul 10 malam. Jendela kedua berjalan setiap hari Sabtu pukul 10 malam. Selain itu, jendela pemeliharaan telah ditandai untuk menunjukkan bahwa itu untuk lingkungan produksi.

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Tuesdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * TUE *)" \
       --duration 1 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Tuesdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * TUE *)" ^
       --duration 1 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "WindowId":"mw-0c50858d01EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm create-maintenance-window \
       --name "Production-Saturdays" \
       --tags "Key=Environment,Value=Production" \
       --schedule "cron(0 0 22 ? * SAT *)" \
       --duration 2 \
       --cutoff 0 \
       --no-allow-unassociated-targets
   ```

------
#### [ Windows Server ]

   ```
   aws ssm create-maintenance-window ^
       --name "Production-Saturdays" ^
       --tags "Key=Environment,Value=Production" ^
       --schedule "cron(0 0 22 ? * SAT *)" ^
       --duration 2 ^
       --cutoff 0 ^
       --no-allow-unassociated-targets
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "WindowId":"mw-9a8b7c6d5eEXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendaftarkan grup patch server `Database` dan `Front-End` dengan jendela pemeliharaan masing-masing.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=tag:PatchGroup,Values=Database Servers" \
       --owner-information "Database Servers" \
       --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Database Servers" ^
       --owner-information "Database Servers" ^
       --resource-type "INSTANCE"
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-target-with-maintenance-window \
   --window-id mw-9a8b7c6d5eEXAMPLE \
   --targets "Key=tag:PatchGroup,Values=Front-End Servers" \
   --owner-information "Front-End Servers" \
   --resource-type "INSTANCE"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-target-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
       --owner-information "Front-End Servers" ^
       --resource-type "INSTANCE"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendaftarkan sebuah tugas patch yang menginstal pembaruan yang hilang pada server `Database` dan `Front-End` selama jendela pemeliharaan masing-masing.

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-0c50858d01EXAMPLE \
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-0c50858d01EXAMPLE ^
       --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   Sistem mengembalikan informasi seperti berikut.

   ```
   {
      "WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
   }
   ```

------
#### [ Linux & macOS ]

   ```
   aws ssm register-task-with-maintenance-window \
       --window-id mw-9a8b7c6d5eEXAMPLE \
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
       --task-arn "AWS-RunPatchBaseline" \
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
       --task-type "RUN_COMMAND" \
       --max-concurrency 2 \
       --max-errors 1 \
       --priority 1 \
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-task-with-maintenance-window ^
       --window-id mw-9a8b7c6d5eEXAMPLE ^
       --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
       --task-arn "AWS-RunPatchBaseline" ^
       --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
       --task-type "RUN_COMMAND" ^
       --max-concurrency 2 ^
       --max-errors 1 ^
       --priority 1 ^
       --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
   }
   ```

1. Jalankan perintah berikut ini untuk mendapatkan ringkasan kepatuhan patch tingkat tinggi untuk grup patch. Ringkasan kepatuhan patch tingkat tinggi mencakup jumlah node terkelola dengan tambalan di masing-masing status patch.
**catatan**  
Diharapkan melihat nol untuk jumlah node terkelola dalam ringkasan hingga tugas tambalan berjalan selama jendela pemeliharaan pertama.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-patch-group-state \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-patch-group-state ^
       --patch-group "Database Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "Instances": number,
      "InstancesWithFailedPatches": number,
      "InstancesWithInstalledOtherPatches": number,
      "InstancesWithInstalledPatches": number,
      "InstancesWithInstalledPendingRebootPatches": number,
      "InstancesWithInstalledRejectedPatches": number,
      "InstancesWithMissingPatches": number,
      "InstancesWithNotApplicablePatches": number,
      "InstancesWithUnreportedNotApplicablePatches": number
   }
   ```

1. Jalankan perintah berikut untuk mendapatkan status ringkasan tambalan per node yang dikelola untuk grup tambalan. Ringkasan node per terkelola mencakup sejumlah tambalan di masing-masing status patch per node terkelola untuk grup patch.

------
#### [ Linux & macOS ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group \
       --patch-group "Database Servers"
   ```

------
#### [ Windows Server ]

   ```
   aws ssm describe-instance-patch-states-for-patch-group ^
       --patch-group "Database Servers"
   ```

------

   Sistem mengembalikan informasi seperti berikut ini.

   ```
   {
      "InstancePatchStates": [ 
         { 
            "BaselineId": "string",
            "FailedCount": number,
            "InstalledCount": number,
            "InstalledOtherCount": number,
            "InstalledPendingRebootCount": number,
            "InstalledRejectedCount": number,
            "InstallOverrideList": "string",
            "InstanceId": "string",
            "LastNoRebootInstallOperationTime": number,
            "MissingCount": number,
            "NotApplicableCount": number,
            "Operation": "string",
            "OperationEndTime": number,
            "OperationStartTime": number,
            "OwnerInformation": "string",
            "PatchGroup": "string",
            "RebootOption": "string",
            "SnapshotId": "string",
            "UnreportedNotApplicableCount": number
         }
      ]
   }
   ```

Untuk contoh AWS CLI perintah lain yang dapat Anda gunakan untuk tugas Patch Manager konfigurasi Anda, lihat[Bekerja dengan Patch Manager sumber daya menggunakan AWS CLI](patch-manager-cli-commands.md).

# Pemecahan Masalah Patch Manager
<a name="patch-manager-troubleshooting"></a>

Gunakan informasi berikut untuk membantu Anda memecahkan masalah denganPatch Manager, alat di. AWS Systems Manager

**Topics**
+ [Masalah: Kesalahan “Invoke-PatchBaselineOperation : Akses Ditolak” atau kesalahan “Tidak dapat mengunduh file dari S3" untuk `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Masalah: Penambalan gagal tanpa penyebab atau pesan kesalahan yang jelas](#race-condition-conflict)
+ [Masalah: Hasil kepatuhan tambalan yang tidak terduga](#patch-manager-troubleshooting-compliance)
+ [Kesalahan saat menjalankan `AWS-RunPatchBaseline` pada Linux](#patch-manager-troubleshooting-linux)
+ [Kesalahan saat menjalankan `AWS-RunPatchBaseline` pada Windows Server](#patch-manager-troubleshooting-windows)
+ [Kesalahan saat berjalan `AWS-RunPatchBaseline` di macOS](#patch-manager-troubleshooting-macos)
+ [Menggunakan AWS Dukungan runbook Otomasi](#patch-manager-troubleshooting-using-support-runbooks)
+ [Menghubungi AWS Dukungan](#patch-manager-troubleshooting-contact-support)

## Masalah: Kesalahan “Invoke-PatchBaselineOperation : Akses Ditolak” atau kesalahan “Tidak dapat mengunduh file dari S3" untuk `baseline_overrides.json`
<a name="patch-manager-troubleshooting-patch-policy-baseline-overrides"></a>

**Masalah**: Saat operasi penambalan yang ditentukan oleh kebijakan tambalan Anda berjalan, Anda menerima kesalahan yang mirip dengan contoh berikut. 

------
#### [ Example error on Windows Server ]

```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```

------
#### [ Example error on Linux ]

```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```

------

**Penyebab**: Anda membuat kebijakan tambalan diQuick Setup, dan beberapa node terkelola Anda sudah memiliki profil instance yang dilampirkan (untuk instans EC2) atau peran layanan yang dilampirkan (untuk mesin non-EC2). 

Namun, seperti yang ditunjukkan pada gambar berikut, Anda tidak memilih kotak centang **Tambahkan kebijakan IAM yang diperlukan ke profil instans yang ada yang dilampirkan ke instance Anda**.

![\[\]](http://docs.aws.amazon.com/id_id/systems-manager/latest/userguide/images/QS-instance-profile-option.png)


Saat Anda membuat kebijakan tambalan, bucket Amazon S3 juga dibuat untuk menyimpan file konfigurasi `baseline_overrides.json` kebijakan. Jika Anda tidak memilih kotak centang **Tambahkan kebijakan IAM yang diperlukan ke profil instans yang ada yang dilampirkan ke instans** saat membuat kebijakan, kebijakan IAM dan tag sumber daya yang diperlukan untuk mengakses `baseline_overrides.json` di bucket S3 tidak secara otomatis ditambahkan ke profil instans IAM dan peran layanan yang ada.

**Solusi 1**: Hapus konfigurasi kebijakan tambalan yang ada, lalu buat pengganti, pastikan untuk memilih kotak centang **Tambahkan kebijakan IAM yang diperlukan ke profil instans yang ada yang dilampirkan ke instance Anda**. Pilihan ini menerapkan kebijakan IAM yang dibuat oleh Quick Setup konfigurasi ini ke node yang sudah memiliki profil instance atau peran layanan yang dilampirkan. (Secara default, Quick Setup menambahkan kebijakan yang diperlukan ke instance dan node yang *belum* memiliki profil instance atau peran layanan.) Untuk informasi selengkapnya, lihat [Mengotomatiskan penambalan di seluruh organisasi menggunakan kebijakan tambalan](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html). Quick Setup 

**Solusi 2**: Tambahkan izin dan tag yang diperlukan secara manual ke setiap profil instans IAM dan peran layanan IAM yang Anda gunakan. Quick Setup Untuk petunjuk, lihat [Izin untuk bucket S3 kebijakan patch](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).

## Masalah: Penambalan gagal tanpa penyebab atau pesan kesalahan yang jelas
<a name="race-condition-conflict"></a>

**Masalah**: Operasi patching gagal tanpa mengembalikan pesan kesalahan.

**Kemungkinan penyebabnya**: Saat menambal node yang dikelola, eksekusi dokumen dapat terganggu dan ditandai sebagai gagal meskipun tambalan berhasil diinstal. Ini dapat terjadi jika sistem memulai reboot yang tidak terduga selama operasi patching (misalnya, untuk menerapkan pembaruan ke firmware atau fitur seperti SecureBoot). Agen SSM tidak dapat bertahan dan melanjutkan status eksekusi dokumen di seluruh reboot eksternal, sehingga eksekusi dilaporkan gagal. 

**Solusi**: Untuk memverifikasi status instalasi patch setelah eksekusi gagal, jalankan operasi `Scan` patching, lalu periksa data kepatuhan patch di Patch Manager untuk menilai status kepatuhan saat ini.

Jika Anda menentukan bahwa reboot eksternal bukan penyebab kegagalan dalam skenario ini, kami sarankan untuk menghubungi. [AWS Dukungan](#patch-manager-troubleshooting-contact-support)

## Masalah: Hasil kepatuhan tambalan yang tidak terduga
<a name="patch-manager-troubleshooting-compliance"></a>

**Masalah**: Saat meninjau detail kepatuhan penambalan yang dihasilkan setelah `Scan` operasi, hasilnya menyertakan informasi yang tidak mencerminkan aturan yang ditetapkan di baseline patch Anda. Misalnya, pengecualian yang Anda tambahkan ke daftar **tambalan Ditolak** di baseline patch terdaftar sebagai. `Missing` Atau tambalan yang diklasifikasikan sebagai `Important` terdaftar sebagai hilang meskipun baseline patch Anda hanya menentukan `Critical` tambalan.

**Penyebab**: Patch Manager saat ini mendukung beberapa metode menjalankan `Scan` operasi:
+ Kebijakan tambalan yang dikonfigurasi di Quick Setup
+ Opsi Manajemen Host yang dikonfigurasi di Quick Setup
+ Jendela pemeliharaan untuk menjalankan tambalan `Scan` atau `Install` tugas
+ **Patch sesuai permintaan sekarang beroperasi**

Ketika `Scan` operasi berjalan, itu menimpa detail kepatuhan dari pemindaian terbaru. Jika Anda memiliki lebih dari satu metode yang disiapkan untuk menjalankan `Scan` operasi, dan mereka menggunakan baseline patch yang berbeda dengan aturan yang berbeda, mereka akan menghasilkan hasil kepatuhan patch yang berbeda. 

**Solusi**: Untuk menghindari hasil kepatuhan patch yang tidak terduga, sebaiknya gunakan hanya satu metode pada satu waktu untuk menjalankan Patch Manager `Scan` operasi. Untuk informasi selengkapnya, lihat [Mengidentifikasi eksekusi yang membuat data kepatuhan patch](patch-manager-compliance-data-overwrites.md).

## Kesalahan saat menjalankan `AWS-RunPatchBaseline` pada Linux
<a name="patch-manager-troubleshooting-linux"></a>

**Topics**
+ [Masalah: Kesalahan 'Tidak ada file atau direktori tersebut”](#patch-manager-troubleshooting-linux-1)
+ [Masalah: kesalahan 'proses lain telah mengakuisisi yum lock'](#patch-manager-troubleshooting-linux-2)
+ [Masalah: kesalahan 'Izin ditolak / gagal menjalankan perintah'](#patch-manager-troubleshooting-linux-3)
+ [Masalah: kesalahan 'Tidak dapat mengunduh muatan'](#patch-manager-troubleshooting-linux-4)
+ [Masalah: kesalahan 'kombinasi pengelola paket dan versi python yang tidak didukung’](#patch-manager-troubleshooting-linux-5)
+ [Masalah: Patch Manager tidak menerapkan aturan yang ditentukan untuk mengecualikan paket tertentu](#patch-manager-troubleshooting-linux-6)
+ [Masalah: Penambalan gagal dan Patch Manager melaporkan bahwa ekstensi Indikasi Nama Server ke TLS tidak tersedia](#patch-manager-troubleshooting-linux-7)
+ [Masalah: Patch Manager melaporkan 'Tidak ada lagi cermin untuk dicoba'](#patch-manager-troubleshooting-linux-8)
+ [Masalah: Penambalan gagal dengan 'Kode kesalahan yang dikembalikan dari curl adalah 23'](#patch-manager-troubleshooting-linux-9)
+ [Masalah: Penambalan gagal dengan pesan 'Kesalahan membongkar paket rpm... '](#error-unpacking-rpm)
+ [Masalah: Penambalan gagal dengan 'Temui kesalahan sisi layanan saat mengunggah inventaris'](#inventory-upload-error)
+ [Masalah: Penambalan gagal dengan pesan 'Kesalahan ditemui saat mengunduh paket'](#errors-while-downloading)
+ [Masalah: Penambalan gagal dengan kesalahan kehabisan memori (OOM)](#patch-manager-troubleshooting-linux-oom)
+ [Masalah: Penambalan gagal dengan pesan bahwa 'Tanda tangan berikut tidak dapat diverifikasi karena kunci publik tidak tersedia'](#public-key-unavailable)
+ [Masalah: Penambalan gagal dengan pesan 'NoMoreMirrorsRepoError'](#no-more-mirrors-repo-error)
+ [Masalah: Penambalan gagal dengan pesan 'Tidak dapat mengunduh payload'](#payload-download-error)
+ [Masalah: Penambalan gagal dengan pesan 'kesalahan instal: dpkg: kesalahan: frontend dpkg dikunci oleh proses lain'](#dpkg-frontend-locked)
+ [Masalah: Penambalan Ubuntu Server gagal dengan kesalahan 'dpkg terganggu'](#dpkg-interrupted)
+ [Masalah: Utilitas manajer paket tidak dapat menyelesaikan ketergantungan paket](#unresolved-dependency)
+ [Masalah: Kegagalan ketergantungan kunci paket Zypper pada node yang dikelola SLES](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Masalah: Tidak dapat memperoleh kunci. Operasi penambalan lainnya sedang berlangsung.](#patch-manager-troubleshooting-linux-concurrent-lock)

### Masalah: Kesalahan 'Tidak ada file atau direktori tersebut”
<a name="patch-manager-troubleshooting-linux-1"></a>

**Masalah**: Ketika Anda menjalankan `AWS-RunPatchBaseline`, patching gagal dengan salah satu kesalahan berikut.

```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```

```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```

```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```

**Penyebab 1**: Dua perintah untuk `AWS-RunPatchBaseline` dijalankan berjalan pada saat yang sama pada node terkelola yang sama. Hal ini menciptakan kondisi balapan yang menyebabkan `file patch-baseline-operations*` sementara tidak dibuat atau diakses dengan benar.

**Penyebab 2**: Ruang penyimpanan yang tersisa tidak cukup dalam direktori `/var`. 

**Solusi 1**: Pastikan tidak ada jendela pemeliharaan yang memiliki dua atau lebih Run Command tugas yang berjalan `AWS-RunPatchBaseline` dengan tingkat Prioritas yang sama dan berjalan pada target yang sama IDs. Jika ini masalahnya, susun ulang prioritasnya. Run Commandadalah alat di AWS Systems Manager.

**Solusi 2**: Pastikan bahwa hanya satu jendela pemeliharaan pada satu waktu yang menjalankan Run Command tugas yang digunakan `AWS-RunPatchBaseline` pada target yang sama dan pada jadwal yang sama. Jika demikian, ubah jadwalnya.

**Solusi 3**: Pastikan hanya satu State Manager asosiasi yang berjalan `AWS-RunPatchBaseline` pada jadwal yang sama dan menargetkan node terkelola yang sama. State Manageradalah alat di AWS Systems Manager.

**Solusi 4**: Bebaskan ruang penyimpanan yang cukup dalam direktori `/var` untuk paket pembaruan.

### Masalah: kesalahan 'proses lain telah mengakuisisi yum lock'
<a name="patch-manager-troubleshooting-linux-2"></a>

**Masalah**: Ketika Anda menjalankan `AWS-RunPatchBaseline`, patching gagal dengan kesalahan berikut.

```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```

**Penyebab**: `AWS-RunPatchBaseline` Dokumen telah mulai berjalan pada node terkelola di mana ia sudah berjalan di operasi lain dan telah memperoleh `yum` proses manajer paket.

**Solusi**: Pastikan tidak ada State Manager asosiasi, tugas jendela pemeliharaan, atau konfigurasi lain yang berjalan sesuai `AWS-RunPatchBaseline` jadwal yang menargetkan node terkelola yang sama sekitar waktu yang sama.

### Masalah: kesalahan 'Izin ditolak / gagal menjalankan perintah'
<a name="patch-manager-troubleshooting-linux-3"></a>

**Masalah**: Ketika Anda menjalankan `AWS-RunPatchBaseline`, patching gagal dengan kesalahan berikut.

```
sh: 
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```

**Penyebab**: `/var/lib/amazon/` mungkin dipasang dengan izin `noexec`. Ini adalah masalah karena SSM Agent mengunduh skrip payload ke `/var/lib/amazon/ssm` dan menjalankannya dari lokasi itu.

**Solusi**: Pastikan Anda telah mengonfigurasi partisi eksklusif ke `/var/log/amazon` dan`/var/lib/amazon`, dan bahwa partisi tersebut dipasang dengan `exec` izin.

### Masalah: kesalahan 'Tidak dapat mengunduh muatan'
<a name="patch-manager-troubleshooting-linux-4"></a>

**Masalah**: Ketika Anda menjalankan `AWS-RunPatchBaseline`, patching gagal dengan kesalahan berikut.

```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```

**Penyebab**: Node terkelola tidak memiliki izin yang diperlukan untuk mengakses bucket Amazon Simple Storage Service (Amazon S3) yang ditentukan.

**Solusi**: Perbarui konfigurasi jaringan Anda sehingga titik akhir S3 dapat dijangkau. Untuk detail selengkapnya, lihat informasi tentang akses yang diperlukan ke bucket S3 untuk Patch Manager masuk. [SSM Agentkomunikasi dengan bucket S3 AWS terkelola](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)

### Masalah: kesalahan 'kombinasi pengelola paket dan versi python yang tidak didukung’
<a name="patch-manager-troubleshooting-linux-5"></a>

**Masalah**: Ketika Anda menjalankan `AWS-RunPatchBaseline`, patching gagal dengan kesalahan berikut.

```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```

**Penyebab**: Versi python3 yang didukung tidak diinstal pada instance atau. Debian Server Ubuntu Server

**Solusi**: Instal versi python3 yang didukung (3.0 - 3.12) di server, yang diperlukan untuk Debian Server dan mengelola node. Ubuntu Server

### Masalah: Patch Manager tidak menerapkan aturan yang ditentukan untuk mengecualikan paket tertentu
<a name="patch-manager-troubleshooting-linux-6"></a>

**Masalah**: Anda telah mencoba untuk mengecualikan paket-paket tertentu dengan menentukannya dalam `/etc/yum.conf` file, dalam format`exclude=package-name`, tetapi mereka tidak dikecualikan selama operasi. Patch Manager `Install`

**Penyebab**: Patch Manager tidak memasukkan pengecualian yang ditentukan dalam `/etc/yum.conf` file.

**Solusi**: Untuk mengecualikan paket tertentu, buat dasar patch kustom dan buat aturan untuk mengecualikan paket yang tidak ingin diinstal.

### Masalah: Penambalan gagal dan Patch Manager melaporkan bahwa ekstensi Indikasi Nama Server ke TLS tidak tersedia
<a name="patch-manager-troubleshooting-linux-7"></a>

**Masalah**: Operasi patching mengeluarkan pesan berikut ini.

```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369: 
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS 
certificate, which can cause validation failures. You can upgrade to a newer version of Python 
to solve this. 
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```

**Penyebab**: Pesan ini tidak menunjukkan kesalahan. Sebaliknya, ini adalah peringatan bahwa versi lama Python yang didistribusikan dengan sistem operasi tidak mendukung Server Name Indication (SNI) TLS. Skrip payload patch Systems Manager mengeluarkan peringatan ini saat menghubungkan ke SNI dukungan AWS APIs tersebut.

**Solusi**: Untuk memecahkan masalah kegagalan patch ketika pesan ini dilaporkan, tinjau konten file `stdout` dan `stderr`. Jika Anda belum mengonfigurasi baseline patch untuk menyimpan file-file ini di bucket S3 atau di Amazon CloudWatch Logs, Anda dapat menemukan file di lokasi berikut di node terkelola Linux Anda. 

`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`

### Masalah: Patch Manager melaporkan 'Tidak ada lagi cermin untuk dicoba'
<a name="patch-manager-troubleshooting-linux-8"></a>

**Masalah**: Operasi patching mengeluarkan pesan berikut ini.

```
[Errno 256] No more mirrors to try.
```

**Penyebab**: Repositori yang dikonfigurasi pada node terkelola tidak berfungsi dengan benar. Kemungkinan penyebab untuk hal ini meliputi:
+ Cache `yum` rusak.
+ URL repositori tidak dapat dijangkau karena masalah terkait jaringan.

**Solusi**: Patch Manager menggunakan manajer paket default node terkelola untuk melakukan operasi penambalan. Periksa kembali bahwa repositori dikonfigurasi dan beroperasi dengan benar.

### Masalah: Penambalan gagal dengan 'Kode kesalahan yang dikembalikan dari curl adalah 23'
<a name="patch-manager-troubleshooting-linux-9"></a>

**Masalah**: Operasi patching yang menggunakan `AWS-RunPatchBaseline` gagal dengan kesalahan yang mirip dengan berikut ini:

```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```

**Penyebab**: Alat curl yang digunakan pada sistem Anda tidak memiliki izin yang diperlukan untuk menulis ke sistem file. Ini dapat terjadi ketika jika alat curl default manajer paket digantikan oleh versi yang berbeda, seperti yang diinstal dengan snap.

**Solusi**: Jika versi curl yang disediakan oleh manajer paket dihapus saat versi yang berbeda diinstal, instal ulang.

Jika Anda perlu menginstal beberapa versi curl, pastikan bahwa versi yang terkait dengan manajer paket ada di direktori pertama yang tercantum dalam `PATH` variabel. Anda dapat memeriksa ini dengan menjalankan perintah `echo $PATH` untuk melihat urutan direktori saat ini yang diperiksa untuk file yang dapat dieksekusi pada sistem Anda.

### Masalah: Penambalan gagal dengan pesan 'Kesalahan membongkar paket rpm... '
<a name="error-unpacking-rpm"></a>

**Masalah**: Operasi penambalan gagal dengan kesalahan yang mirip dengan yang berikut ini:

```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```

**Penyebab 1**: Ketika paket tertentu hadir di beberapa installer paket, seperti keduanya `pip` dan `yum` atau`dnf`, konflik dapat terjadi ketika menggunakan manajer paket default.

Contoh umum terjadi dengan `urllib3` paket, yang ditemukan di`pip`,`yum`, dan`dnf`.

**Penyebab 2**: `python-urllib3` Paket rusak. Hal ini dapat terjadi jika file paket diinstal atau diperbarui oleh `pip` setelah paket `rpm` itu sebelumnya diinstal oleh `yum` atau`dnf`.

**Solusi**: Hapus `python-urllib3` paket dari pip dengan menjalankan perintah`sudo pip uninstall urllib3`, simpan paket hanya di manajer paket default (`yum`atau`dnf`). 

### Masalah: Penambalan gagal dengan 'Temui kesalahan sisi layanan saat mengunggah inventaris'
<a name="inventory-upload-error"></a>

**Masalah**: Saat menjalankan `AWS-RunPatchBaseline` dokumen, Anda menerima pesan galat berikut:

```
Encounter service side error when uploading the inventory
```

**Penyebab**: Dua perintah untuk `AWS-RunPatchBaseline` dijalankan berjalan pada saat yang sama pada node terkelola yang sama. Ini menciptakan kondisi balapan saat menginisialisasi klien boto3 selama operasi penambalan.

**Solusi**: Pastikan tidak ada State Manager asosiasi, tugas jendela pemeliharaan, atau konfigurasi lain yang berjalan sesuai `AWS-RunPatchBaseline` jadwal yang menargetkan node terkelola yang sama sekitar waktu yang sama.

### Masalah: Penambalan gagal dengan pesan 'Kesalahan ditemui saat mengunduh paket'
<a name="errors-while-downloading"></a>

**Masalah**: Selama menambal, Anda menerima kesalahan yang mirip dengan yang berikut ini:

```
YumDownloadError: [u'Errors were encountered while downloading 
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12] 
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5] 
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory',
```

**Penyebab**: Kesalahan ini dapat terjadi ketika memori tidak cukup tersedia pada node terkelola.

**Solusi**: Konfigurasikan memori swap, atau tingkatkan instance ke jenis yang berbeda untuk meningkatkan dukungan memori. Kemudian mulailah operasi penambalan baru.

### Masalah: Penambalan gagal dengan kesalahan kehabisan memori (OOM)
<a name="patch-manager-troubleshooting-linux-oom"></a>

**Masalah**: Saat Anda menjalankan`AWS-RunPatchBaseline`, operasi penambalan gagal karena memori yang tidak mencukupi pada node yang dikelola. Anda mungkin melihat kesalahan seperti`Cannot allocate memory`, `Killed` (dari pembunuh Linux OOM), atau operasi gagal secara tak terduga. Kesalahan ini lebih mungkin terjadi pada instance dengan RAM kurang dari 1 GB, tetapi juga dapat memengaruhi instance dengan lebih banyak memori ketika sejumlah besar pembaruan tersedia.

**Penyebab**: Patch Manager menjalankan operasi patching menggunakan manajer paket asli pada node terkelola. Memori yang diperlukan selama operasi penambalan tergantung pada beberapa faktor, termasuk:
+ Jumlah paket yang diinstal dan pembaruan yang tersedia pada node terkelola.
+ Manajer paket yang digunakan dan karakteristik memorinya.
+ Proses lain yang berjalan pada node terkelola pada saat operasi patching.

Node yang dikelola dengan sejumlah besar paket yang diinstal atau sejumlah besar pembaruan yang tersedia memerlukan lebih banyak memori selama operasi penambalan. Ketika memori yang tersedia tidak mencukupi, proses patching akan gagal dan keluar dengan kesalahan. Sistem operasi juga dapat menghentikan proses patching.

**Solusi**: Coba satu atau beberapa hal berikut:
+ Jadwalkan operasi patching selama periode aktivitas beban kerja rendah pada node terkelola, seperti dengan menggunakan jendela pemeliharaan.
+ Tingkatkan instance ke tipe dengan lebih banyak memori.
+ Konfigurasikan memori swap pada node yang dikelola. Perhatikan bahwa pada instans dengan throughput EBS terbatas, penggunaan swap yang berat dapat menyebabkan penurunan kinerja.
+ Tinjau dan kurangi jumlah proses yang berjalan pada node terkelola selama operasi patching.

### Masalah: Penambalan gagal dengan pesan bahwa 'Tanda tangan berikut tidak dapat diverifikasi karena kunci publik tidak tersedia'
<a name="public-key-unavailable"></a>

**Masalah**: Penambalan gagal Ubuntu Server dengan kesalahan yang mirip dengan berikut ini:

```
02/17/2022 21:08:43 root [ERROR]: W:GPG error: 
http://repo.mysql.com/apt/ubuntu  bionic InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```

**Penyebab**: Kunci GNU Privacy Guard (GPG) telah kedaluwarsa atau hilang.

**Solusi**: Segarkan kembali tombol GPG, atau tambahkan kunci lagi.

Misalnya, menggunakan kesalahan yang ditunjukkan sebelumnya, kita melihat bahwa `467B942D3A79BD29` kuncinya hilang dan harus ditambahkan. Untuk melakukannya, jalankan salah satu dari perintah berikut:

```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```

```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```

Atau, untuk menyegarkan semua tombol, jalankan perintah berikut:

```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```

Jika kesalahan berulang setelah ini, kami sarankan untuk melaporkan masalah ke organisasi yang memelihara repositori. Sampai perbaikan tersedia, Anda dapat mengedit `/etc/apt/sources.list` file untuk menghilangkan repositori selama proses patching.

Untuk melakukannya, buka `sources.list` file untuk diedit, cari baris untuk repositori, dan masukkan `#` karakter di awal baris untuk mengomentarinya. Kemudian simpan dan tutup file.

### Masalah: Penambalan gagal dengan pesan 'NoMoreMirrorsRepoError'
<a name="no-more-mirrors-repo-error"></a>

**Masalah**: Anda menerima kesalahan yang mirip dengan berikut ini:

```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```

**Penyebab**: Ada kesalahan dalam repositori sumber.

**Solusi**: Kami merekomendasikan pelaporan masalah ke organisasi yang memelihara repositori. Sampai kesalahan diperbaiki, Anda dapat menonaktifkan repositori di tingkat sistem operasi. Untuk melakukannya, jalankan perintah berikut, ganti nilai untuk *repo-name* dengan nama repositori Anda:

```
yum-config-manager --disable repo-name
```

Berikut adalah contohnya.

```
yum-config-manager --disable pgdg94
```

Setelah Anda menjalankan perintah ini, jalankan operasi patching lain.

### Masalah: Penambalan gagal dengan pesan 'Tidak dapat mengunduh payload'
<a name="payload-download-error"></a>

**Masalah**: Anda menerima kesalahan yang mirip dengan berikut ini:

```
Unable to download payload: 
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed  to run commands: exit status 156
```

**Penyebab**: Konfigurasi node terkelola berisi kesalahan atau tidak lengkap.

**Solusi**: Pastikan node terkelola dikonfigurasi dengan yang berikut:
+ Aturan TCP 443 keluar dalam grup keamanan.
+ Aturan keluar TCP 443 di NACL.
+ Aturan Ingress TCP 1024-65535 di NACL.
+ NAT/IGW dalam tabel rute untuk menyediakan konektivitas ke titik akhir S3. Jika instans tidak memiliki akses internet, berikan konektivitas dengan titik akhir S3. Untuk melakukan itu, tambahkan titik akhir gateway S3 di VPC dan integrasikan dengan tabel rute node terkelola.

### Masalah: Penambalan gagal dengan pesan 'kesalahan instal: dpkg: kesalahan: frontend dpkg dikunci oleh proses lain'
<a name="dpkg-frontend-locked"></a>

**Masalah**: Penambalan gagal dengan kesalahan yang mirip dengan berikut ini:

```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```

**Penyebab**: Manajer paket sudah menjalankan proses lain pada node terkelola di tingkat sistem operasi. Jika proses lain itu membutuhkan waktu lama untuk diselesaikan, operasi Patch Manager penambalan dapat habis waktu dan gagal.

**Solusi**: Setelah proses lain yang menggunakan manajer paket selesai, jalankan operasi penambalan baru.

### Masalah: Penambalan Ubuntu Server gagal dengan kesalahan 'dpkg terganggu'
<a name="dpkg-interrupted"></a>

**Masalah**: AktifUbuntu Server, penambalan gagal dengan kesalahan yang mirip dengan yang berikut ini:

```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```

**Penyebab**: Satu atau lebih paket salah dikonfigurasi.

**Solusi**: Lakukan langkah-langkah berikut:

1. Periksa untuk melihat paket mana yang terpengaruh, dan apa masalahnya dengan setiap paket dengan menjalankan perintah berikut, satu per satu:

   ```
   sudo apt-get check
   ```

   ```
   sudo dpkg -C
   ```

   ```
   dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
   ```

1. Perbaiki paket dengan masalah dengan menjalankan perintah berikut:

   ```
   sudo dpkg --configure -a
   ```

1. Jika perintah sebelumnya tidak sepenuhnya menyelesaikan masalah, jalankan perintah berikut:

   ```
   sudo apt --fix-broken install
   ```

### Masalah: Utilitas manajer paket tidak dapat menyelesaikan ketergantungan paket
<a name="unresolved-dependency"></a>

**Masalah**: Manajer paket asli pada node terkelola tidak dapat menyelesaikan ketergantungan paket dan tambalan gagal. Contoh pesan kesalahan berikut menunjukkan jenis kegagalan pada sistem operasi yang digunakan `yum` sebagai manajer paket.

```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1, 
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3', 
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```

**Penyebab**: Pada sistem operasi Linux, Patch Manager menggunakan manajer paket asli pada mesin untuk menjalankan operasi patching. seperti`yum`,,`dnf`, `apt` dan. `zypper` Aplikasi secara otomatis mendeteksi, menginstal, memperbarui, atau menghapus paket dependen sesuai kebutuhan. Namun, beberapa kondisi dapat mengakibatkan manajer paket tidak dapat menyelesaikan operasi ketergantungan, seperti:
+ Beberapa repositori yang saling bertentangan dikonfigurasi pada sistem operasi.
+ URL repositori jarak jauh tidak dapat diakses karena masalah terkait jaringan.
+ Paket untuk arsitektur yang salah ditemukan di repositori.

**Solusi**: Patching mungkin gagal karena masalah ketergantungan karena berbagai alasan. Oleh karena itu, kami menyarankan Anda menghubungi AWS Dukungan untuk membantu pemecahan masalah.

### Masalah: Kegagalan ketergantungan kunci paket Zypper pada node yang dikelola SLES
<a name="patch-manager-troubleshooting-linux-zypper-locks"></a>

**Masalah**: Saat Anda menjalankan `AWS-RunPatchBaseline` `Install` operasi pada SUSE Linux Enterprise Server instance, penambalan gagal dengan kesalahan pemeriksaan ketergantungan yang terkait dengan kunci paket. Anda mungkin melihat pesan kesalahan yang mirip dengan berikut ini:

```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
  uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
 Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c): c
```

Dalam contoh ini, paket `mock-pkg-standalone` terkunci, yang dapat Anda verifikasi dengan menjalankan `sudo zypper locks` dan mencari nama paket ini di output.

Atau Anda mungkin melihat entri log yang menunjukkan kegagalan pemeriksaan ketergantungan:

```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```

**catatan**  
Masalah ini hanya terjadi selama `Install` operasi. `Scan`operasi tidak menerapkan kunci paket dan tidak terpengaruh oleh kunci yang ada.”

**Penyebab**: Kesalahan ini terjadi ketika kunci paket zypper mencegah instalasi atau pembaruan paket karena konflik ketergantungan. Package locks dapat hadir karena beberapa alasan:
+ **Kunci yang diterapkan pelanggan**: Anda atau administrator sistem Anda secara manual mengunci paket menggunakan perintah zypper seperti. `zypper addlock`
+ **Patch Manager menolak tambalan**: Patch Manager secara otomatis menerapkan kunci paket saat Anda menentukan paket dalam daftar **tambalan Ditolak** dari baseline tambalan Anda untuk mencegah pemasangannya.
+ **Kunci sisa dari operasi yang terputus**: Dalam kasus yang jarang terjadi, jika operasi tambalan terputus (seperti oleh reboot sistem) sebelum Patch Manager dapat membersihkan kunci sementara, kunci paket sisa mungkin tetap ada di node terkelola Anda.

**Solusi**: Untuk mengatasi masalah kunci paket zypper, ikuti langkah-langkah berikut berdasarkan penyebabnya:

**Langkah 1: Identifikasi paket yang terkunci**

Hubungkan ke node SLES terkelola Anda dan jalankan perintah berikut untuk mencantumkan semua paket yang saat ini terkunci:

```
sudo zypper locks
```

**Langkah 2: Tentukan sumber kunci**
+ Jika paket yang terkunci adalah paket yang sengaja Anda kunci untuk stabilitas sistem, pertimbangkan apakah paket tersebut perlu tetap terkunci atau apakah paket tersebut dapat dibuka sementara untuk ditambal.
+ Jika paket yang terkunci cocok dengan entri dalam daftar tambalan **Ditolak baseline tambalan Anda, ini kemungkinan merupakan kunci sisa dari operasi tambalan** yang terputus. Selama operasi normal, Patch Manager terapkan kunci ini sementara dan lepaskan secara otomatis saat operasi selesai. Anda dapat menghapus paket dari daftar yang ditolak atau memodifikasi aturan dasar tambalan Anda.
+ Jika Anda tidak mengenali paket yang terkunci dan mereka tidak sengaja dikunci, mereka mungkin merupakan kunci sisa dari operasi patch yang terputus sebelumnya.

**Langkah 3: Hapus kunci yang sesuai**

Untuk menghapus kunci paket tertentu, gunakan perintah berikut:

```
sudo zypper removelock package-name
```

Untuk menghapus semua kunci paket (gunakan dengan hati-hati), jalankan:

```
sudo zypper cleanlocks
```

**Langkah 4: Perbarui baseline patch Anda (jika ada)**

Jika kunci disebabkan oleh tambalan yang ditolak di baseline tambalan Anda:

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Patch Manager**.

1. Pilih tab **Patch baselines**, lalu pilih baseline patch kustom Anda.

1. Pilih **Tindakan**, **Ubah baseline patch**.

1. Di bagian **Tambalan yang ditolak**, tinjau paket yang terdaftar dan hapus semua yang diizinkan untuk diinstal.

1. Pilih **Simpan perubahan**.

**Langkah 5: Coba lagi operasi patch**

Setelah menghapus kunci bermasalah dan memperbarui baseline patch Anda jika perlu, jalankan `AWS-RunPatchBaseline` dokumen lagi.

**catatan**  
Saat Patch Manager menerapkan kunci untuk tambalan yang ditolak selama `Install` operasi, ini dirancang untuk membersihkan kunci ini secara otomatis setelah operasi tambalan selesai. Jika Anda melihat kunci ini saat berjalan`sudo zypper locks`, ini menunjukkan operasi tambalan sebelumnya terganggu sebelum pembersihan dapat terjadi. Namun, jika operasi patch terganggu, pembersihan manual mungkin diperlukan seperti yang dijelaskan dalam prosedur ini.

**Pencegahan**: Untuk menghindari konflik kunci zypper di masa depan:
+ Tinjau dengan cermat daftar tambalan yang ditolak baseline patch Anda untuk memastikannya hanya menyertakan paket yang benar-benar ingin Anda kecualikan.
+ Hindari penguncian paket secara manual yang mungkin diperlukan sebagai dependensi untuk pembaruan keamanan.
+ Jika Anda harus mengunci paket secara manual, dokumentasikan alasannya dan tinjau kunci secara berkala.
+ Pastikan operasi patch berhasil diselesaikan dan tidak terganggu oleh reboot sistem atau faktor lainnya.
+ Pantau operasi tambalan hingga selesai dan hindari menyela dengan reboot sistem atau tindakan lain yang dapat mencegah pembersihan kunci sementara yang tepat.

### Masalah: Tidak dapat memperoleh kunci. Operasi penambalan lainnya sedang berlangsung.
<a name="patch-manager-troubleshooting-linux-concurrent-lock"></a>

**Masalah**: Saat Anda menjalankan`AWS-RunPatchBaseline`, tambalan gagal dengan kode kesalahan 4 dan pesan kesalahan berikut.

```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Penyebab**: Kesalahan ini terjadi ketika beberapa operasi penambalan mencoba berjalan pada node terkelola yang sama pada saat yang bersamaan. File kunci mencegah operasi penambalan bersamaan untuk menghindari konflik dan memastikan stabilitas sistem.

**Solusi**: Pastikan bahwa operasi patching tidak dijadwalkan untuk berjalan pada saat yang sama pada node terkelola yang sama. Tinjau konfigurasi berikut untuk mengidentifikasi dan menyelesaikan konflik penjadwalan:
+ **Patch policies**: Periksa konfigurasi kebijakan patch Quick Setup Anda untuk memastikan tidak tumpang tindih dengan jadwal patching lainnya.
+ **Jendela pemeliharaan**: Tinjau asosiasi jendela pemeliharaan Anda untuk memverifikasi bahwa beberapa jendela tidak menargetkan node terkelola yang sama dengan tugas penambalan pada waktu yang tumpang tindih.
+ **Operasi Patch Manual sekarang**: Hindari memulai operasi **Patch manual sekarang** saat patching terjadwal sedang berlangsung.

## Kesalahan saat menjalankan `AWS-RunPatchBaseline` pada Windows Server
<a name="patch-manager-troubleshooting-windows"></a>

**Topics**
+ [Masalah: pasangan produk yang tidak cocok family/product](#patch-manager-troubleshooting-product-family-mismatch)
+ [Masalah: Output `AWS-RunPatchBaseline` mengembalikan sebuah `HRESULT` (Windows Server)](#patch-manager-troubleshooting-hresult)
+ [Masalah: node terkelola tidak memiliki akses ke Katalog Pembaruan Windows atau WSUS](#patch-manager-troubleshooting-instance-access)
+ [Masalah: PatchBaselineOperations PowerShell modul tidak dapat diunduh](#patch-manager-troubleshooting-module-not-downloadable)
+ [Masalah: patch yang hilang](#patch-manager-troubleshooting-missing-patches)
+ [Masalah: Tidak dapat memperoleh kunci. Operasi penambalan lainnya sedang berlangsung.](#patch-manager-troubleshooting-windows-concurrent-lock)

### Masalah: pasangan produk yang tidak cocok family/product
<a name="patch-manager-troubleshooting-product-family-mismatch"></a>

**Masalah**: Ketika Anda membuat dasar patch di konsol Systems Manager, Anda menentukan keluarga produk dan produk. Sebagai contoh, Anda dapat memilih:
+ **Keluarga produk**: `Office`

  **Produk**: `Office 2016`

**Penyebab**: Jika Anda mencoba membuat baseline patch dengan family/product pasangan produk yang tidak cocok, pesan kesalahan akan ditampilkan. Berikut ini adalah beberapa alasan mengapa hal ini terjadi:
+ Anda memilih pasangan keluarga produk dan produk yang valid tetapi kemudian menghapus pilihan keluarga produk.
+ Anda memilih produk dari sub-daftar **Pilihan usang atau tidak cocok** bukan dari sub-daftar **Pilihan yang tersedia dan cocok**. 

  Item dalam sublis **opsi usang atau tidak cocok** produk mungkin telah dimasukkan secara error melalui perintah SDK atau (). AWS Command Line Interface AWS CLI`create-patch-baseline` Ini bisa berarti adanya kesalahan pengetikan atau produk ditugaskan ke keluarga produk yang salah. Sebuah produk juga disertakan dalam sub-daftar **Pilihan usang atau tidak cocok** jika ditentukan untuk dasar patch sebelumnya tetapi tidak memiliki patch yang tersedia dari Microsoft. 

**Solusi**: Untuk menghindari masalah ini di konsol, selalu pilih opsi dari sub-daftar **Pilihan yang tersedia saat ini**.

Anda juga dapat melihat produk yang memiliki patch yang tersedia dengan menggunakan perintah `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` di AWS CLI atau perintah API `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)`.

### Masalah: Output `AWS-RunPatchBaseline` mengembalikan sebuah `HRESULT` (Windows Server)
<a name="patch-manager-troubleshooting-hresult"></a>

**Masalah**: Anda menerima kesalahan seperti berikut ini.

```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when 
attempting to search Windows Update.
Exception Level 1:
 Error Message: Exception from HRESULT: 0x80240437
 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```

**Penyebab**: Output ini menunjukkan bahwa Pembaruan Windows asli APIs tidak dapat menjalankan operasi penambalan.

**Solusi**: Periksa `HResult` kode dalam topik microsoft.com berikut untuk mengidentifikasi langkah-langkah pemecahan masalah untuk menyelesaikan kesalahan:
+ [Kode kesalahan Pembaruan Windows berdasarkan komponen](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference) 
+ [Windows Update kesalahan umum dan mitigasi](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors) 

### Masalah: node terkelola tidak memiliki akses ke Katalog Pembaruan Windows atau WSUS
<a name="patch-manager-troubleshooting-instance-access"></a>

**Masalah**: Anda menerima kesalahan seperti berikut ini.

```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.

Extracting PatchBaselineOperations zip file contents to temporary folder.

Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.

Successfully downloaded and installed the PatchBaselineOperations PowerShell module.

Patch Summary for

PatchGroup :

BaselineId :

Baseline : null

SnapshotId :

RebootOption : RebootIfNeeded

OwnerInformation :

OperationType : Scan

OperationStartTime : 1970-01-01T00:00:00.0000000Z

OperationEndTime : 1970-01-01T00:00:00.0000000Z

InstalledCount : -1

InstalledRejectedCount : -1

InstalledPendingRebootCount : -1

InstalledOtherCount : -1

FailedCount : -1

MissingCount : -1

NotApplicableCount : -1

UnreportedNotApplicableCount : -1

EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169

----------ERROR-------

Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String

searchCriteria)

At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58

e3\PatchWindows\_script.ps1:230 char:13

+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv

oke-PatchBaselineOperation], Exception

+ FullyQualifiedErrorId : Exception Level 1:

Error Message: Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc

---Error truncated----
```

**Penyebab**: Kesalahan ini dapat berhubungan dengan komponen Windows Update, atau tidak adanya konektivitas ke Katalog Windows Update atau Windows Server Update Services (WSUS).

**Solusi**: Konfirmasikan bahwa node terkelola memiliki konektivitas ke [Katalog Pembaruan Microsoft](https://www.catalog.update.microsoft.com/home.aspx) melalui gateway internet, gateway NAT, atau instance NAT. Jika Anda menggunakan WSUS, konfirmasikan bahwa node yang dikelola memiliki konektivitas ke server WSUS di lingkungan Anda. Jika konektivitas tersedia untuk tujuan yang dimaksudkan, periksa dokumentasi Microsoft untuk potensi penyebab `HResult 0x80072EE2`. Ini mungkin menunjukkan masalah tingkat sistem operasi. 

### Masalah: PatchBaselineOperations PowerShell modul tidak dapat diunduh
<a name="patch-manager-troubleshooting-module-not-downloadable"></a>

**Masalah:** Anda menerima pesan kesalahan seperti berikut ini.

```
Preparing to download PatchBaselineOperations PowerShell module from S3.
                    
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------

C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\

PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException

+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1

failed to run commands: exit status 4294967295
```

**Solusi**: Periksa konektivitas node terkelola dan izin ke Amazon Simple Storage Service (Amazon S3). Peran node terkelola AWS Identity and Access Management (IAM) harus menggunakan izin minimum yang dikutip. [SSM Agentkomunikasi dengan bucket S3 AWS terkelola](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) Node harus berkomunikasi dengan titik akhir Amazon S3 melalui titik akhir gateway Amazon S3, gateway NAT, atau gateway internet. Untuk informasi selengkapnya tentang persyaratan Titik Akhir VPC untuk AWS Systems Manager SSM Agent (SSM Agent), lihat. [Meningkatkan keamanan instans EC2 dengan menggunakan titik akhir VPC untuk Systems Manager](setup-create-vpc.md) 

### Masalah: patch yang hilang
<a name="patch-manager-troubleshooting-missing-patches"></a>

**Masalah**: `AWS-RunPatchbaseline` berhasil diselesaikan, tetapi ada beberapa patch yang hilang.

Berikut ini adalah beberapa penyebab umum dan solusinya.

**Penyebab 1**: Baseline tidak efektif.

**Solusi 1**: Untuk memeriksa apakah ini penyebabnya, gunakan prosedur berikut.

1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Di panel navigasi, pilih **Run Command**.

1. Pilih tab **Riwayat perintah** lalu pilih perintah yang baseline-nya ingin Anda periksa.

1. Pilih node terkelola yang memiliki tambalan yang hilang.

1. Pilih **Langkah 1 - Output** dan temukan nilai `BaselineId`.

1. Periksa [konfigurasi dasar patch](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) yang ditetapkan, yaitu, sistem operasi, nama produk, klasifikasi, dan kepelikan untuk dasar patch.

1. Buka [Katalog Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx).

1. Cari artikel Pangkalan Pengetahuan Microsoft (KB) IDs (misalnya, KB3216916).

1. Verifikasi bahwa nilai di bawah **Produk** cocok dengan node terkelola Anda dan pilih **Judul** yang sesuai. Jendela **Detail Pembaruan** baru akan terbuka.

1. Di tab **Gambaran Umum**, **klasifikasi** dan **Kepelikan MSRC** harus cocok dengan konfigurasi dasar patch yang Anda temukan sebelumnya.

**Penyebab 2**: patch diganti.

**Solusi 2**: Untuk memeriksa apakah ini benar, gunakan prosedur berikut.

1. Buka [Katalog Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx).

1. Cari artikel Pangkalan Pengetahuan Microsoft (KB) IDs (misalnya, KB3216916).

1. Verifikasi bahwa nilai di bawah **Produk** cocok dengan node terkelola Anda dan pilih **Judul** yang sesuai. Jendela **Detail Pembaruan** baru akan terbuka.

1. Buka tab **Detail paket**. Cari entri di bawah tajuk **Pembaruan ini telah digantikan oleh pembaruan berikut:**.

**Penyebab 3**: patch yang sama mungkin memiliki nomor KB yang berbeda karena pembaruan online WSUS dan Windows ditangani Release Channels berbeda oleh Microsoft.

**Solusi 3**: Periksa kelayakan patch. Jika paket tidak tersedia di bawah WSUS, instal [OS Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Jika paket tersedia untuk semua build sistem operasi, instal [OS Build 18362.1256 dan 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).

### Masalah: Tidak dapat memperoleh kunci. Operasi penambalan lainnya sedang berlangsung.
<a name="patch-manager-troubleshooting-windows-concurrent-lock"></a>

**Masalah**: Saat Anda menjalankan`AWS-RunPatchBaseline`, tambalan gagal dengan kode kesalahan 4 dan pesan kesalahan berikut.

```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Penyebab**: Kesalahan ini terjadi ketika beberapa operasi penambalan mencoba berjalan pada node terkelola yang sama pada saat yang bersamaan. File kunci mencegah operasi penambalan bersamaan untuk menghindari konflik dan memastikan stabilitas sistem.

**Solusi**: Pastikan bahwa operasi patching tidak dijadwalkan untuk berjalan pada saat yang sama pada node terkelola yang sama. Tinjau konfigurasi berikut untuk mengidentifikasi dan menyelesaikan konflik penjadwalan:
+ **Patch policies**: Periksa konfigurasi kebijakan patch Quick Setup Anda untuk memastikan tidak tumpang tindih dengan jadwal patching lainnya.
+ **Jendela pemeliharaan**: Tinjau asosiasi jendela pemeliharaan Anda untuk memverifikasi bahwa beberapa jendela tidak menargetkan node terkelola yang sama dengan tugas penambalan pada waktu yang tumpang tindih.
+ **Operasi Patch Manual sekarang**: Hindari memulai operasi **Patch manual sekarang** saat patching terjadwal sedang berlangsung.

## Kesalahan saat berjalan `AWS-RunPatchBaseline` di macOS
<a name="patch-manager-troubleshooting-macos"></a>

**Topics**
+ [Masalah: Tidak dapat memperoleh kunci. Operasi penambalan lainnya sedang berlangsung.](#patch-manager-troubleshooting-macos-concurrent-lock)

### Masalah: Tidak dapat memperoleh kunci. Operasi penambalan lainnya sedang berlangsung.
<a name="patch-manager-troubleshooting-macos-concurrent-lock"></a>

**Masalah**: Saat Anda menjalankan`AWS-RunPatchBaseline`, tambalan gagal dengan kode kesalahan 4 dan pesan kesalahan berikut.

```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```

**Penyebab**: Kesalahan ini terjadi ketika beberapa operasi penambalan mencoba berjalan pada node terkelola yang sama pada saat yang bersamaan. File kunci mencegah operasi penambalan bersamaan untuk menghindari konflik dan memastikan stabilitas sistem.

**Solusi**: Pastikan bahwa operasi patching tidak dijadwalkan untuk berjalan pada saat yang sama pada node terkelola yang sama. Tinjau konfigurasi berikut untuk mengidentifikasi dan menyelesaikan konflik penjadwalan:
+ **Patch policies**: Periksa konfigurasi kebijakan patch Quick Setup Anda untuk memastikan tidak tumpang tindih dengan jadwal patching lainnya.
+ **Jendela pemeliharaan**: Tinjau asosiasi jendela pemeliharaan Anda untuk memverifikasi bahwa beberapa jendela tidak menargetkan node terkelola yang sama dengan tugas penambalan pada waktu yang tumpang tindih.
+ **Operasi Patch Manual sekarang**: Hindari memulai operasi **Patch manual sekarang** saat patching terjadwal sedang berlangsung.

## Menggunakan AWS Dukungan runbook Otomasi
<a name="patch-manager-troubleshooting-using-support-runbooks"></a>

AWS Dukungan menyediakan dua runbook Otomasi yang dapat Anda gunakan untuk memecahkan masalah tertentu yang terkait dengan penambalan.
+ `AWSSupport-TroubleshootWindowsUpdate`— [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html)Runbook digunakan untuk mengidentifikasi masalah yang dapat gagal dalam Windows Server pembaruan untuk instans Amazon Elastic Compute Cloud (Amazon EC2). Windows Server
+ `AWSSupport-TroubleshootPatchManagerLinux`— [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html)Runbook memecahkan masalah umum yang dapat menyebabkan kegagalan patch pada node terkelola berbasis Linux yang menggunakan. Patch Manager Tujuan utama dari runbook ini adalah untuk mengidentifikasi akar penyebab kegagalan perintah patch dan menyarankan rencana remediasi.

**catatan**  
Ada biaya untuk menjalankan runbook Otomasi. Untuk selengkapnya, lihat [AWS Systems Manager Harga untuk Otomatisasi](https://aws.amazon.com/systems-manager/pricing/#Automation).

## Menghubungi AWS Dukungan
<a name="patch-manager-troubleshooting-contact-support"></a>

Jika Anda tidak dapat menemukan solusi pemecahan masalah di bagian ini atau di masalah Systems Manager di [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager), dan Anda memiliki [Dukungan paket Pengembang, Bisnis, atau Perusahaan](https://aws.amazon.com/premiumsupport/plans), Anda dapat membuat kasus dukungan teknis di. [AWS Dukungan](https://aws.amazon.com/premiumsupport/)

Sebelum Anda menghubungi Dukungan, kumpulkan item berikut:
+ [Log agen SSM](ssm-agent-logs.md)
+ Run CommandID perintah, ID jendela pemeliharaan, atau ID eksekusi Otomasi
+ Untuk node Windows Server terkelola, kumpulkan juga yang berikut ini:
  + `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` seperti yang dijelaskan pada tab **Windows** pada [Cara menginstal patch](patch-manager-installing-patches.md)
  + Log pembaruan Windows: Untuk Windows Server 2012 R2 dan yang sebelumnya, gunakan `%windir%/WindowsUpdate.log`. Untuk Windows Server 2016 dan yang lebih baru, jalankan PowerShell perintah terlebih dahulu [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)sebelum menggunakan `%windir%/WindowsUpdate.log`
+ Untuk node yang dikelola Linux, kumpulkan juga yang berikut ini:
  + Isi direktori `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`