Prasyarat untuk dukungan instans Amazon EC2 - Amazon GuardDuty
Membuat EC2 instans SSM dikelola (hanya untuk agen otomatis)Validasi persyaratan arsitekturMemvalidasi kebijakan kontrol layanan organisasi Anda di lingkungan multi-akunSaat menggunakan konfigurasi agen otomatisCPU dan batas memoriLangkah berikutnya

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 instans SSM dikelola (hanya untuk konfigurasi agen otomatis)

GuardDuty menggunakan AWS Systems Manager (SSM) untuk secara otomatis menyebarkan, menginstal, dan mengelola agen keamanan pada instans Anda. Jika Anda berencana untuk menginstal dan mengelola GuardDuty agen secara manual, SSM tidak diperlukan.

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

Validasi 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:

  • Dukungan kernel termasukeBPF, Tracepoints danKprobe. Untuk arsitektur CPU, Runtime Monitoring mendukung AMD64 (x64) dan ARM64 (Graviton2 dan di atasnya). 1

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

    Distribusi OS 2 Versi kernel 3
    Amazon Linux 2

    5.4 4, 5.10, 5.15 4
    Amazon Linux 2023

    5.4 4, 5.10, 5.15 4, 6.1, 6.5, 6.8, 6.12
    Ubuntu 20.04 dan Ubuntu 22.04

    5.4 4, 5.10, 5.15 4, 6.1, 6.5, 6.8
    Ubuntu 24.04

    6.8
    Debian 11 dan Debian 12

    5.4 4, 5.10, 5.15 4, 6.1, 6.5, 6.8
    RedHat 9.4

    5.14
    Fedora 34.0

    5.11, 5.17
    Fedora 40

    6.8
    Fedora 41

    6.12
    CentOS Aliran 9

    5.14
    Oracle Linux 8.9

    5.15
    Oracle Linux 9.3

    5.15
    Rocky Linux 9.5

    5.14

    1. Runtime Monitoring untuk EC2 sumber daya Amazon tidak mendukung instans Graviton generasi pertama seperti jenis instans A1.

    2. Support untuk berbagai sistem operasi - GuardDuty telah memverifikasi dukungan Runtime Monitoring untuk distribusi operasi yang tercantum dalam tabel sebelumnya. Sementara agen GuardDuty keamanan dapat berjalan pada sistem operasi yang tidak tercantum dalam tabel sebelumnya, GuardDuty tim tidak dapat menjamin nilai keamanan yang diharapkan.

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

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

  • 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 memodifikasi 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 tersebut 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 di lingkungan multi-akun

Jika Anda telah menyiapkan kebijakan kontrol layanan (SCP) untuk mengelola izin di organisasi Anda, validasi batas izin yang memungkinkan tindakan tersebut. 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.

    • Aktifkan Izinkan tag dalam pengaturan metadata untuk instance Anda. Pengaturan ini diperlukan karena GuardDuty perlu membaca tag pengecualian dari layanan metadata instance (IMDS) untuk menentukan apakah harus mengecualikan instance dari instalasi agen. Untuk informasi selengkapnya, lihat Mengaktifkan akses ke tag dalam metadata instans di EC2 Panduan Pengguna Amazon.

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 berikutnya

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