Bagikan melalui


Memecahkan masalah konektor AWS S3

Konektor Amazon Web Services (AWS) S3 memungkinkan Anda menyerap log layanan AWS, yang dikumpulkan dalam wadah AWS S3, ke Microsoft Sentinel. Jenis log yang saat ini kami dukung adalah AWS CloudTrail, VPC Flow Logs, dan AWS GuardDuty.

Artikel ini menjelaskan cara mengidentifikasi penyebab masalah yang terjadi dengan konektor AWS S3 dengan cepat sehingga Anda dapat menemukan langkah-langkah yang diperlukan untuk mengatasi masalah tersebut.

Pelajari cara menyambungkan Microsoft Sentinel ke Amazon Web Services untuk menyerap data log layanan AWS.

Microsoft Azure Sentinel tidak menerima data dari konektor Amazon Web Services S3 atau salah satu jenis datanya

Log untuk konektor AWS S3 (atau salah satu jenis datanya) tidak terlihat di ruang kerja Microsoft Azure Sentinel selama lebih dari 30 menit setelah konektor tersambung.

Sebelum Anda mencari penyebab dan solusi, tinjau pertimbangan berikut:

  • Dibutuhkan waktu sekitar 20-30 menit sejak konektor tersambung hingga data diserap ke ruang kerja.
  • Status koneksi konektor menunjukkan bahwa aturan koleksi ada, ini tidak menunjukkan bahwa data diserap. Jika status konektor Amazon Web Services S3 berwarna hijau, ada aturan pengumpulan untuk salah satu jenis data, tetapi masih tidak ada data.

Tentukan penyebab masalah Anda

Di bagian ini, kami membahas penyebab-penyebab ini:

  1. Kebijakan izin konektor AWS S3 tidak diatur dengan benar.
  2. Data tidak diserap ke wadah S3 di AWS.
  3. Amazon Simple Queue Service (SQS) di cloud AWS tidak menerima pemberitahuan dari wadah S3.
  4. Data tidak dapat dibaca dari SQS/S3 di AWS cloud. Dengan log GuardDuty, masalah ini disebabkan oleh izin KMS yang salah.

Penyebab 1: Kebijakan izin konektor AWS S3 tidak diatur dengan benar

Masalah ini disebabkan oleh izin yang salah di lingkungan AWS.

Membuat kebijakan izin

Anda memerlukan kebijakan izin untuk menyebarkan konektor data AWS S3. Tinjau izin yang diperlukan dan atur izin yang relevan.

Penyebab 2: Data yang relevan tidak ada di wadah S3

Log yang relevan tidak ada di wadah S3.

Solusi: Cari log dan ekspor log jika diperlukan

  1. Di AWS, buka wadah S3, cari folder yang relevan sesuai dengan log yang diperlukan, dan periksa apakah ada file log di dalam folder.
  2. Jika data tidak ada, ada masalah dengan konfigurasi AWS. Dalam hal ini, Anda perlu mengonfigurasi layanan AWS untuk mengekspor log ke wadah S3.

Penyebab 3: Data S3 tidak tiba di SQS

Data tidak berhasil ditransfer dari S3 ke SQS.

Solusi: Verifikasi bahwa data tiba dan konfigurasikan pemberitahuan peristiwa

  1. Di AWS, buka SQS yang relevan.
  2. Di tab Pemantauan, Anda akan melihat lalu lintas di widget Jumlah Pesan Terkirim. Jika tidak ada lalu lintas di SQS, berarti ada masalah konfigurasi AWS.
  3. Pastikan definisi notifikasi peristiwa untuk SQS menyertakan filter data yang benar (awalan dan akhiran).
    1. Untuk melihat pemberitahuan acara, di keranjang S3, pilih tab Properti, dan cari bagian Pemberitahuan acara.
    2. Jika Anda tidak dapat melihat bagian ini, buatlah.
    3. Pastikan bahwa SQS memiliki kebijakan yang relevan untuk mendapatkan data dari wadah S3. SQS harus berisi kebijakan ini di tab Kebijakan akses.

Penyebab 4: SQS tidak membaca data

SQS tidak berhasil membaca data S3.

Solusi: Verifikasi bahwa SQS membaca data

  1. Di AWS, buka SQS yang relevan.

  2. Di tab Pemantauan, Anda akan melihat lalu lintas di widget Jumlah Pesan Yang Dihapus dan Jumlah Pesan yang Diterima.

  3. Satu lonjakan data tidaklah cukup. Tunggu hingga ada cukup data (beberapa lonjakan), lalu periksa masalah.

  4. Jika setidaknya salah satu widget kosong, periksa log kesehatan dengan menjalankan kueri ini:

    SentinelHealth 
    | where TimeGenerated > ago(1d)
    | where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
    | where OperationName == 'Data fetch failure summary'
    | mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
    | extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
    | extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
    | project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedProperties
    
  5. Pastikan fitur kesehatan diaktifkan:

    SentinelHealth 
    | take 20
    
  6. Jika fitur kesehatan tidak diaktifkan, aktifkan.

Data dari konektor AWS S3 (atau salah satu jenis datanya) terlihat di Microsoft Azure Sentinel dengan penundaan lebih dari 30 menit

Masalah ini biasanya terjadi ketika Microsoft tidak dapat membaca file di folder S3. Microsoft tidak dapat membaca file karena file dienkripsi atau dalam format yang salah. Dalam kasus ini, banyak percobaan ulang akhirnya menyebabkan penundaan penyerapan.

Tentukan penyebab masalah Anda

Di bagian ini, kami membahas penyebab-penyebab ini:

  • Enkripsi log tidak disiapkan dengan benar
  • Pemberitahuan peristiwa tidak ditentukan dengan benar
  • Kesalahan kesehatan atau kesehatan dinonaktifkan

Penyebab 1: Enkripsi log tidak disiapkan dengan benar

Jika log dienkripsi sepenuhnya atau sebagian oleh Key Management Service (KMS), Microsoft Azure Sentinel mungkin tidak memiliki izin bagi KMS ini untuk mendekripsi file.

Solusi: Periksa enkripsi log

Pastikan Microsoft Azure Sentinel memiliki izin untuk KMS ini untuk mendekripsi file. Tinjau izin KMS yang diperlukan untuk log GuardDuty dan CloudTrail.

Penyebab 2: Pemberitahuan peristiwa tidak dikonfigurasi dengan benar

Saat mengonfigurasi pemberitahuan peristiwa Amazon S3, Anda harus menentukan jenis peristiwa mana yang didukung amazon S3 yang harus mengirim pemberitahuan. Jika jenis peristiwa yang tidak Anda tentukan ada di wadah Amazon S3 Anda, Amazon S3 tidak mengirim pemberitahuan.

Solusi: Verifikasi bahwa pemberitahuan peristiwa ditentukan dengan benar

Untuk memverifikasi bahwa pemberitahuan peristiwa dari S3 ke SQS ditentukan dengan benar, periksa apakah:

  • Pemberitahuan didefinisikan dari folder tertentu yang menyertakan log, dan bukan dari folder utama yang berisi wadah.
  • Pemberitahuan didefinisikan dengan akhiran .gz . Contohnya:

Penyebab 3: Kesalahan kesehatan atau kesehatan dinonaktifkan

Mungkin ada kesalahan dalam log kesehatan, atau fitur kesehatan mungkin tidak diaktifkan.

Solusi: Verifikasi bahwa tidak ada kesalahan dalam log kesehatan dan aktifkan kesehatan

  1. Verifikasi bahwa tidak ada kesalahan dalam log kesehatan dengan menjalankan kueri ini:

    SentinelHealth
    | where TimeGenerated between (ago(startTime)..ago(endTime))
    | where SentinelResourceKind  == "AmazonWebServicesS3"
    | where Status != "Success"
    | distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description
    
  2. Pastikan fitur kesehatan diaktifkan:

    SentinelHealth 
    | take 20
    
  3. Jika fitur kesehatan tidak diaktifkan, aktifkan.

Langkah berikutnya

Dalam artikel ini, Anda mempelajari cara mengidentifikasi penyebab dengan cepat dan menyelesaikan masalah umum dengan konektor AWS S3.

Kami menyambut umpan balik, saran, permintaan fitur, laporan bug, atau peningkatan dan penambahan. Buka Repositori GitHub Microsoft Sentinel untuk membuat masalah atau fork dan mengunggah kontribusi.