Prasyarat untuk dukungan instans Amazon EC2 - Amazon GuardDuty
Membuat EC2 instance SSM dikelolaMemvalidasi persyaratan arsitekturMemvalidasi kebijakan kontrol layanan organisasi AndaSaat menggunakan konfigurasi agen otomatisCPU dan batas memoriLangkah selanjutnya

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

Prasyarat untuk dukungan instans Amazon EC2

Bagian ini mencakup prasyarat untuk memantau perilaku runtime instans Amazon Anda. EC2 Setelah prasyarat ini terpenuhi, lihat. Mengaktifkan GuardDuty Runtime Monitoring

Membuat EC2 instance SSM dikelola

EC2 Instans Amazon yang GuardDuty ingin Anda pantau peristiwa runtime harus dikelola AWS Systems Manager (SSM). Ini terlepas dari apakah Anda menggunakan GuardDuty untuk mengelola agen keamanan secara otomatis, atau mengelolanya secara manual. Namun, ketika Anda mengelola agen secara manual dengan menggunakan manualMetode 2 - Menggunakan Linux Package Managers, EC2 instans Anda tidak perlu dikelola SSM.

Untuk mengelola EC2 instans Amazon Anda AWS Systems Manager, lihat Menyiapkan Systems Manager untuk EC2 instans Amazon di AWS Systems Manager Panduan Pengguna.

Catatan untuk instance berbasis Fedora EC2

AWS Systems Manager tidak mendukung distribusi Fedora OS. Setelah mengaktifkan Runtime Monitoring, gunakan metode manual (Metode 2 - Menggunakan Linux Package Managers) untuk menginstal agen keamanan dalam instance berbasis EC2 Fedora.

Untuk informasi tentang platform yang didukung, lihat Platform dan arsitektur paket yang didukung di Panduan AWS Systems Manager Pengguna.

Memvalidasi persyaratan arsitektur

Arsitektur distribusi OS Anda dapat memengaruhi perilaku agen GuardDuty keamanan. Anda harus memenuhi persyaratan berikut sebelum menggunakan Runtime Monitoring untuk EC2 instans Amazon:

  • Tabel berikut menunjukkan distribusi OS yang telah diverifikasi untuk mendukung agen GuardDuty keamanan untuk EC2 instans Amazon.

    Distribusi OS 1 Versi kernel 2 Dukungan kernel Arsitektur CPU
    x64 () AMD64 Graviton () ARM64

    AL2 dan AL2 023

    Ubuntu 20.04 dan Ubuntu 22.04

    Debian 11 dan Debian 12

    5.4 3, 5.10, 5.15 3, 6.1, 6.5, 6.8

    eBPF, Tracepoints, Kprobe

    Didukung

    Didukung

    Ubuntu 24.04

    		 6.8

    RedHat 9.4

    5.14

    Fedora 34.0 4

    5.11, 5.17

    CentOS Aliran 9

    5.14

    1. Support untuk berbagai sistem operasi - GuardDuty telah memverifikasi dukungan untuk menggunakan Runtime Monitoring pada sistem operasi yang tercantum dalam tabel sebelumnya. Saat menggunakan sistem operasi yang berbeda, Anda mungkin mendapatkan semua nilai keamanan yang diharapkan yang GuardDuty telah diverifikasi untuk diberikan pada distribusi OS yang terdaftar.

    2. Untuk versi kernel apa pun, Anda harus menyetel CONFIG_DEBUG_INFO_BTF flag ke y (artinya true). Ini diperlukan agar agen GuardDuty keamanan dapat berjalan seperti yang diharapkan.

    3. Untuk kernel versi 5.10 dan sebelumnya, agen GuardDuty keamanan menggunakan memori terkunci di RAM (RLIMIT_MEMLOCK) berfungsi seperti yang diharapkan. Jika RLIMIT_MEMLOCK nilai sistem Anda disetel terlalu rendah, GuardDuty rekomendasikan pengaturan batas keras dan lunak setidaknya 32 MB. Untuk informasi tentang memverifikasi dan memodifikasi RLIMIT_MEMLOCK nilai default, lihatMelihat dan memperbarui RLIMIT_MEMLOCK nilai.

    4. Fedora bukan platform yang didukung untuk konfigurasi agen otomatis. Anda dapat menyebarkan agen GuardDuty keamanan di Fedora dengan menggunakan. Metode 2 - Menggunakan Linux Package Managers

  • Persyaratan tambahan - Hanya jika Anda memiliki Amazon ECS/Amazon EC2

    Untuk Amazon ECS/Amazon EC2, kami menyarankan Anda menggunakan Amazon ECS terbaru yang dioptimalkan AMIs (tertanggal 29 September 2023 atau lebih baru), atau menggunakan agen Amazon ECS versi v1.77.0.

Melihat dan memperbarui RLIMIT_MEMLOCK nilai

Ketika RLIMIT_MEMLOCK batas sistem Anda ditetapkan terlalu rendah, agen GuardDuty keamanan mungkin tidak berfungsi seperti yang dirancang. GuardDuty merekomendasikan bahwa batas keras dan lunak harus setidaknya 32 MB. Jika Anda tidak memperbarui batas, tidak GuardDuty akan dapat memantau peristiwa runtime untuk sumber daya Anda. Ketika RLIMIT_MEMLOCK berada di atas batas minimum yang dinyatakan, itu menjadi opsional bagi Anda untuk memperbarui batas ini.

Anda dapat mengubah RLIMIT_MEMLOCK nilai default baik sebelum atau setelah menginstal agen GuardDuty keamanan.

Untuk melihat RLIMIT_MEMLOCK nilai

  1. Jalankan ps aux | grep guardduty. Ini akan menampilkan ID proses (pid).

  2. Salin ID proses (pid) dari output dari perintah sebelumnya.

  3. Jalankan grep "Max locked memory" /proc/pid/limits setelah mengganti pid dengan ID proses yang disalin dari langkah sebelumnya.

    Ini akan menampilkan memori terkunci maksimum untuk menjalankan agen GuardDuty keamanan.

Untuk memperbarui RLIMIT_MEMLOCK nilai

  1. Jika /etc/systemd/system.conf.d/NUMBER-limits.conf file ada, maka komentari baris DefaultLimitMEMLOCK dari file ini. File ini menetapkan default RLIMIT_MEMLOCK dengan prioritas tinggi, yang menimpa pengaturan Anda dalam /etc/systemd/system.conf file.

  2. Buka /etc/systemd/system.conf file dan hapus komentar pada baris yang ada#DefaultLimitMEMLOCK=.

  3. Perbarui nilai default dengan memberikan RLIMIT_MEMLOCK batas keras dan lunak setidaknya 32MB. Pembaruan akan terlihat seperti ini:DefaultLimitMEMLOCK=32M:32M. Formatnya adalah soft-limit:hard-limit.

  4. Jalankan sudo reboot.

Memvalidasi kebijakan kontrol layanan organisasi Anda

Jika Anda telah menyiapkan kebijakan kontrol layanan (SCP) untuk mengelola izin di organisasi Anda, validasi bahwa batas izin tidak membatasi. guardduty:SendSecurityTelemetry Hal ini diperlukan GuardDuty untuk mendukung Runtime Monitoring di berbagai jenis sumber daya.

Jika Anda adalah akun anggota, sambungkan dengan administrator yang didelegasikan terkait. Untuk informasi tentang mengelola SCPs organisasi Anda, lihat Kebijakan kontrol layanan (SCPs).

Saat menggunakan konfigurasi agen otomatis

UntukGunakan konfigurasi agen otomatis (disarankan), Anda Akun AWS harus memenuhi prasyarat berikut:

  • Saat menggunakan tag inklusi dengan konfigurasi agen otomatis, GuardDuty untuk membuat asosiasi SSM untuk instance baru, pastikan instans baru dikelola SSM dan muncul di bawah Fleet Manager di https://console.aws.amazon.com/systems-manager/konsol.

  • Saat menggunakan tag pengecualian dengan konfigurasi agen otomatis:

    • Tambahkan false tagGuardDutyManaged: sebelum mengonfigurasi agen GuardDuty otomatis untuk akun Anda.

      Pastikan Anda menambahkan tag pengecualian ke EC2 instans Amazon sebelum meluncurkannya. Setelah Anda mengaktifkan konfigurasi agen otomatis untuk Amazon EC2, EC2 instans apa pun yang diluncurkan tanpa tag pengecualian akan tercakup dalam konfigurasi agen GuardDuty otomatis.

    • Agar tag pengecualian berfungsi, perbarui konfigurasi instance sehingga dokumen identitas instance tersedia di layanan metadata instance (IMDS). Prosedur untuk melakukan langkah ini sudah menjadi bagian dari Mengaktifkan Runtime Monitoring akun Anda.

CPU dan batas memori untuk GuardDuty agen

Batas CPU

Batas CPU maksimum untuk agen GuardDuty keamanan yang terkait dengan EC2 instans Amazon adalah 10 persen dari total inti vCPU. Misalnya, jika EC2 instans Anda memiliki 4 core vCPU, maka agen keamanan dapat menggunakan maksimum 40 persen dari total 400 persen yang tersedia.

Batas memori

Dari memori yang terkait dengan EC2 instans Amazon Anda, ada memori terbatas yang dapat digunakan agen GuardDuty keamanan.

Tabel berikut menunjukkan batas memori.

Memori EC2 instance Amazon

Memori maksimum untuk GuardDuty agen

Kurang dari 8 GB

128 MB

Kurang dari 32 GB

270 MB

Lebih dari atau sama dengan 32 GB

1 GB

Langkah selanjutnya

Langkah selanjutnya adalah mengkonfigurasi Runtime Monitoring dan juga mengelola agen keamanan (secara otomatis atau manual).