Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Keamanan OU - Akun Arsip Log
| Mempengaruhi masa depan AWS Security Reference Architecture (AWSSRA) dengan mengambil survei singkat |
Diagram berikut menggambarkan layanan keamanan AWS yang dikonfigurasi di akun Arsip Log.
Akun Arsip Log didedikasikan untuk menelan dan mengarsipkan semua log dan cadangan terkait keamanan. Dengan log terpusat, Anda dapat memantau, mengaudit, dan memberi tahu akses objek Amazon S3, aktivitas tidak sah berdasarkan identitas, perubahan kebijakan IAM, dan aktivitas penting lainnya yang dilakukan pada sumber daya sensitif. Tujuan keamanan sangat mudah: Ini harus penyimpanan yang tidak dapat diubah, diakses hanya dengan mekanisme terkontrol, otomatis, dan dipantau, dan dibangun untuk daya tahan (misalnya, dengan menggunakan proses replikasi dan arsip yang sesuai). Kontrol dapat diimplementasikan secara mendalam untuk melindungi integritas dan ketersediaan log dan proses manajemen log. Selain kontrol pencegahan, seperti menetapkan peran hak istimewa paling sedikit untuk digunakan untuk mengakses dan mengenkripsi log dengan kunci AWS KMS yang dikontrol, gunakan kontrol detektif seperti AWS Config untuk memantau (dan memperingatkan dan memulihkan) kumpulan izin ini untuk perubahan yang tidak terduga.
Pertimbangan desain
-
Data log operasional yang digunakan oleh tim infrastruktur, operasi, dan beban kerja Anda sering tumpang tindih dengan data log yang digunakan oleh tim keamanan, audit, dan kepatuhan. Kami menyarankan Anda untuk mengkonsolidasikan data log operasional Anda ke akun Arsip Log. Berdasarkan persyaratan keamanan dan tata kelola spesifik Anda, Anda mungkin perlu memfilter data log operasional yang disimpan ke akun ini. Anda mungkin juga perlu menentukan siapa yang memiliki akses ke data log operasional di akun Arsip Log.
Jenis log
Log utama yang ditampilkan di AWS SRA meliputi CloudTrail (jejak organisasi), log aliran Amazon VPC, log akses dari CloudFront Amazon dan AWS WAF, dan log DNS dari Amazon Route 53. Log ini menyediakan audit atas tindakan yang diambil (atau dicoba) oleh pengguna, peran, layanan AWS, atau entitas jaringan (diidentifikasi, misalnya, oleh alamat IP). Jenis log lainnya (misalnya, log aplikasi atau log database) dapat ditangkap dan diarsipkan juga. Untuk informasi selengkapnya tentang sumber log dan praktik terbaik pencatatan, lihat dokumentasi keamanan untuk setiap layanan.
Amazon S3 sebagai toko log pusat
Banyak layanan AWS mencatat informasi di Amazon S3—baik secara default maupun eksklusif. AWS CloudTrail, Amazon VPC Flow Logs, AWS Config, dan Elastic Load Balancing adalah beberapa contoh layanan yang mencatat informasi di Amazon S3. Ini berarti bahwa integritas log dicapai melalui integritas objek S3; kerahasiaan log dicapai melalui kontrol akses objek S3; dan ketersediaan log dicapai melalui S3 Object Lock, versi objek S3, dan aturan Siklus Hidup S3. Dengan mencatat informasi di bucket S3 khusus dan terpusat yang berada di akun khusus, Anda dapat mengelola log ini hanya dalam beberapa bucket dan menerapkan kontrol keamanan, akses, dan pemisahan tugas yang ketat.
Di AWS SRA, log utama yang disimpan di Amazon S3 CloudTrail berasal, jadi bagian ini menjelaskan cara melindungi objek tersebut. Panduan ini juga berlaku untuk objek S3 lain yang dibuat baik oleh aplikasi Anda sendiri atau oleh layanan AWS lainnya. Terapkan pola ini setiap kali Anda memiliki data di Amazon S3 yang membutuhkan integritas tinggi, kontrol akses yang kuat, serta retensi atau penghancuran otomatis.
Semua objek baru (termasuk CloudTrail log) yang diunggah ke bucket S3 dienkripsi secara default dengan menggunakan enkripsi sisi server Amazon dengan kunci enkripsi yang dikelola Amazon S3 (SSE-S3). Ini membantu melindungi data saat istirahat, tetapi kontrol akses dikendalikan secara eksklusif oleh kebijakan IAM. Untuk menyediakan lapisan keamanan terkelola tambahan, Anda dapat menggunakan enkripsi sisi server dengan kunci AWS KMS yang Anda kelola (SSE-KMS) di semua bucket S3 keamanan. Ini menambahkan kontrol akses tingkat kedua. Untuk membaca file log, pengguna harus memiliki izin baca Amazon S3 untuk objek S3 dan kebijakan atau peran IAM yang diterapkan yang memungkinkan mereka untuk mendekripsi oleh kebijakan kunci terkait.
Dua opsi membantu Anda melindungi atau memverifikasi integritas objek CloudTrail log yang disimpan di Amazon S3. CloudTrail menyediakan validasi integritas file log untuk menentukan apakah file log diubah atau dihapus setelah CloudTrail dikirimkan. Pilihan lainnya adalah S3 Object Lock.
Selain melindungi bucket S3 itu sendiri, Anda dapat mematuhi prinsip hak istimewa paling sedikit untuk layanan logging (misalnya, CloudTrail) dan akun Arsip Log. Misalnya, pengguna dengan izin yang diberikan oleh kebijakan IAM terkelola AWS AWSCloudTrail_FullAccess dapat menonaktifkan atau mengonfigurasi ulang fungsi audit yang paling sensitif dan penting di akun AWS mereka. Batasi penerapan kebijakan IAM ini kepada sesedikit mungkin individu.
Gunakan kontrol detektif, seperti yang dikirimkan oleh AWS Config dan AWS IAM Access Analyzer, untuk memantau (dan memperingatkan dan memulihkan) kumpulan kontrol pencegahan yang lebih luas ini untuk perubahan yang tidak terduga.
Untuk diskusi lebih dalam tentang praktik terbaik keamanan untuk bucket S3, lihat dokumentasi Amazon S3, pembicaraan teknologi online,
Contoh implementasi
Pustaka kode AWS SRA
Danau Keamanan Amazon
AWS SRA merekomendasikan agar Anda menggunakan akun Arsip Log sebagai akun administrator yang didelegasikan untuk Amazon Security Lake. Saat Anda melakukan ini, Security Lake mengumpulkan log yang didukung di bucket S3 khusus di akun yang sama dengan log keamanan yang direkomendasikan SRA lainnya.
Untuk melindungi ketersediaan log dan proses manajemen log, bucket S3 untuk Security Lake harus diakses hanya oleh layanan Security Lake atau oleh peran IAM yang dikelola oleh Security Lake untuk sumber atau pelanggan. Selain menggunakan kontrol pencegahan—seperti menetapkan peran dengan hak istimewa paling sedikit untuk akses, dan mengenkripsi log dengan kunci AWS Key Management Services (AWS KMS) yang terkontrol—gunakan kontrol detektif seperti AWS Config untuk memantau (dan memperingatkan dan memulihkan) kumpulan izin ini untuk perubahan yang tidak terduga.
Administrator Security Lake dapat mengaktifkan pengumpulan log di seluruh organisasi AWS Anda. Log ini disimpan dalam bucket S3 regional di akun Arsip Log. Selain itu, untuk memusatkan log dan memfasilitasi penyimpanan dan analisis yang lebih mudah, administrator Security Lake dapat memilih satu atau lebih Wilayah rollup di mana log dari semua bucket S3 regional dikonsolidasikan dan disimpan. Log dari layanan AWS yang didukung secara otomatis diubah menjadi skema sumber terbuka standar yang disebut Open Cybersecurity Schema Framework (OCSF) dan disimpan dalam format Apache Parquet di bucket Security Lake S3. Dengan dukungan OCSF, Security Lake secara efisien menormalkan dan mengkonsolidasikan data keamanan dari AWS dan sumber keamanan perusahaan lainnya untuk membuat repositori informasi terkait keamanan yang terpadu dan andal.
Security Lake dapat mengumpulkan log yang terkait dengan peristiwa CloudTrail manajemen AWS dan peristiwa CloudTrail data untuk Amazon S3 dan AWS Lambda. Untuk mengumpulkan acara CloudTrail manajemen di Security Lake, Anda harus memiliki setidaknya satu jejak organisasi CloudTrail Multi-wilayah yang mengumpulkan acara CloudTrail manajemen baca dan tulis. Logging harus diaktifkan untuk jejak. Jejak multi-wilayah mengirimkan file log dari beberapa Wilayah ke satu bucket S3 untuk satu akun AWS. Jika Wilayah berada di negara yang berbeda, pertimbangkan persyaratan ekspor data untuk menentukan apakah jalur Multi-wilayah dapat diaktifkan.
AWS Security Hub adalah sumber data asli yang didukung di Security Lake, dan Anda harus menambahkan temuan Security Hub ke Security Lake. Security Hub menghasilkan temuan dari berbagai layanan AWS dan integrasi pihak ketiga. Temuan ini membantu Anda mendapatkan gambaran umum tentang postur kepatuhan Anda dan apakah Anda mengikuti rekomendasi keamanan untuk solusi AWS dan AWS Partner.
Untuk mendapatkan visibilitas dan wawasan yang dapat ditindaklanjuti dari log dan peristiwa, Anda dapat melakukan kueri data dengan menggunakan alat seperti Amazon Athena, Amazon OpenSearch Service, Amazon Quicksight, dan solusi pihak ketiga. Pengguna yang memerlukan akses ke data log Security Lake tidak boleh mengakses akun Arsip Log secara langsung. Mereka harus mengakses data hanya dari akun Security Tooling. Atau mereka dapat menggunakan akun AWS lain atau lokasi lokal yang menyediakan alat analitik seperti OpenSearch Layanan QuickSight, atau alat pihak ketiga seperti informasi keamanan dan alat manajemen peristiwa (SIEM). Untuk menyediakan akses ke data, administrator harus mengkonfigurasi pelanggan Security Lake di akun Arsip Log dan mengkonfigurasi akun yang memerlukan akses ke data sebagai pelanggan akses kueri. Untuk informasi selengkapnya, lihat Amazon Security Lake di bagian Security OU — Security Tooling account pada panduan ini.
Security Lake menyediakan kebijakan terkelola AWS untuk membantu Anda mengelola akses administrator ke layanan. Untuk informasi selengkapnya, lihat Panduan Pengguna Security Lake. Sebagai praktik terbaik, kami menyarankan Anda membatasi konfigurasi Security Lake melalui pipeline pengembangan dan mencegah perubahan konfigurasi melalui konsol AWS atau AWS Command Line Interface (AWS CLI). Selain itu, Anda harus menyiapkan kebijakan IAM yang ketat dan kebijakan kontrol layanan (SCP) untuk hanya memberikan izin yang diperlukan untuk mengelola Security Lake. Anda dapat mengonfigurasi notifikasi untuk mendeteksi akses langsung ke bucket S3 ini.
