

• 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.

# 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.