Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Serang pengurangan permukaan
Pertimbangan penting lainnya ketika merancang AWS solusi adalah membatasi peluang penyerang untuk menargetkan aplikasi Anda. Konsep ini dikenal sebagai *pengurangan permukaan* serangan. Sumber daya yang tidak terpapar ke internet lebih sulit diserang, yang membatasi opsi yang dimiliki penyerang untuk menargetkan ketersediaan aplikasi Anda.
Misalnya, jika Anda tidak mengharapkan pengguna untuk berinteraksi langsung dengan sumber daya tertentu, pastikan bahwa sumber daya tersebut tidak dapat diakses dari internet. Demikian pula, jangan menerima lalu lintas dari pengguna atau aplikasi eksternal pada port atau protokol yang tidak diperlukan untuk komunikasi.
Di bagian berikut, AWS berikan praktik terbaik untuk memandu Anda dalam mengurangi permukaan serangan dan membatasi eksposur internet aplikasi Anda.
# Mengaburkan AWS sumber daya (,,) BP1 BP4 BP5
Biasanya, pengguna dapat dengan cepat dan mudah menggunakan aplikasi tanpa mengharuskan AWS sumber daya sepenuhnya terpapar ke internet.
# Grup keamanan dan jaringan ACLs (BP5)
Amazon Virtual Private Cloud (AmazonVPC) memungkinkan Anda untuk menyediakan bagian yang terisolasi secara logis AWS Cloud di mana Anda dapat meluncurkan AWS sumber daya di jaringan virtual yang Anda tentukan.
Grup keamanan dan jaringan ACLs serupa karena memungkinkan Anda mengontrol akses ke AWS sumber daya di dalam AndaVPC. Tetapi grup keamanan memungkinkan Anda untuk mengontrol lalu lintas masuk dan keluar pada tingkat instans, sementara jaringan ACLs menawarkan kemampuan serupa di tingkat VPC subnet. Tidak ada biaya tambahan untuk menggunakan grup keamanan atau jaringanACLs.
Anda dapat memilih apakah akan menentukan grup keamanan saat meluncurkan instance atau mengaitkan instance dengan grup keamanan di lain waktu. *Semua lalu lintas internet ke grup keamanan secara implisit ditolak kecuali Anda membuat aturan izin untuk mengizinkan lalu lintas.*
Misalnya, jika Anda memiliki EC2 instans Amazon di belakang Elastic Load Balancer, instans itu sendiri tidak perlu diakses publik dan hanya bersifat pribadi. IPs Sebagai gantinya, Anda dapat memberikan akses Elastic Load Balancer ke port pendengar target yang diperlukan menggunakan aturan Grup Keamanan yang memungkinkan akses ke 0.0.0.0/0 (untuk menghindari masalah pelacakan koneksi — lihat catatan di bawah) bersamaan dengan Daftar Kontrol Akses Jaringan (NACL) pada subnet grup target untuk mengizinkan hanya rentang IP Elastic Load Balancing untuk berkomunikasi dengan instance. Ini memastikan bahwa lalu lintas internet tidak dapat berkomunikasi secara langsung dengan EC2 instans Amazon Anda, yang membuatnya lebih sulit bagi penyerang untuk mempelajari dan memengaruhi aplikasi Anda.
Saat Anda membuat jaringanACLs, Anda dapat menentukan aturan izinkan dan tolak. Ini berguna jika Anda ingin secara eksplisit menolak jenis lalu lintas tertentu ke aplikasi Anda. Misalnya, Anda dapat menentukan alamat IP (sebagai CIDR rentang), protokol, dan port tujuan yang ditolak akses ke seluruh subnet. Jika aplikasi Anda hanya digunakan untuk TCP lalu lintas, Anda dapat membuat aturan untuk menolak semua UDP lalu lintas, atau sebaliknya. Opsi ini berguna saat merespons DDoS serangan karena memungkinkan Anda membuat aturan sendiri untuk mengurangi serangan ketika Anda mengetahui sumber IPs atau tanda tangan lainnya.
Jika Anda berlangganan AWS Shield Advanced, Anda dapat mendaftarkan alamat IP Elastis sebagai sumber daya yang dilindungi. DDoSserangan terhadap alamat IP Elastic yang telah terdaftar sebagai sumber daya yang dilindungi terdeteksi lebih cepat, yang dapat menghasilkan waktu yang lebih cepat untuk mengurangi. Ketika serangan terdeteksi, sistem DDoS mitigasi membaca jaringan ACL yang sesuai dengan alamat IP Elastis yang ditargetkan dan menegakkannya di perbatasan AWS jaringan, bukan di tingkat subnet. Ini secara signifikan mengurangi risiko dampak dari sejumlah DDoS serangan lapisan infrastruktur.
Untuk informasi selengkapnya tentang mengonfigurasi grup keamanan dan jaringan ACLs untuk mengoptimalkan DDoS ketahanan, lihat [Cara Membantu Mempersiapkan DDoS Serangan dengan Mengurangi Permukaan Serangan Anda](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/).
Untuk informasi selengkapnya tentang penggunaan Shield Advanced dengan alamat IP Elastic sebagai sumber daya yang dilindungi, lihat langkah-langkah [untuk Berlangganan AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html).
# Melindungi asal Anda (BP1,BP5)
Jika Anda menggunakan Amazon CloudFront dengan asal yang ada di dalam AndaVPC, Anda mungkin ingin memastikan bahwa hanya CloudFront distribusi Anda yang dapat meneruskan permintaan ke asal Anda. Dengan Header Permintaan Edge-to-Origin, Anda dapat menambahkan atau mengganti nilai header permintaan yang ada saat CloudFront meneruskan permintaan ke asal Anda. Anda dapat menggunakan *Header Kustom Asal*, misalnya, `X-Shared-Secret` header, untuk membantu memvalidasi bahwa permintaan yang dibuat ke asal Anda dikirim. CloudFront
Untuk informasi selengkapnya tentang melindungi asal Anda dengan *Header Kustom Asal, lihat [Menambahkan](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) header* [khusus ke permintaan asal dan [Membatasi akses ke Application](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) Load Balancers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html).
Untuk panduan tentang penerapan solusi sampel untuk secara otomatis memutar nilai *Header Kustom Asal* untuk pembatasan akses asal, lihat [Cara meningkatkan keamanan CloudFront asal Amazon dengan AWS WAF dan Secrets Manager](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/).
Atau, Anda dapat menggunakan [AWS Lambda](https://aws.amazon.com/lambda/)fungsi untuk memperbarui aturan grup keamanan secara otomatis agar hanya mengizinkan CloudFront lalu lintas. Ini meningkatkan keamanan asal Anda dengan membantu memastikan bahwa pengguna jahat tidak dapat melewati CloudFront dan AWS WAF saat mengakses aplikasi web Anda.
Untuk informasi selengkapnya tentang cara melindungi asal Anda dengan memperbarui grup keamanan secara otomatis, dan `X-Shared-Secret` tajuknya, lihat [Cara Memperbarui Grup Keamanan Anda secara Otomatis untuk Amazon CloudFront dan AWS WAF Menggunakan AWS Lambda](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/).
Namun, solusinya melibatkan konfigurasi tambahan dan biaya menjalankan fungsi Lambda. Untuk menyederhanakan ini, kami sekarang telah memperkenalkan [daftar awalan AWS-managed untuk](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) membatasi inboundHTTP/HTTPStraffic CloudFront ke asal Anda hanya dari alamat IP yang menghadap asal. CloudFront AWS Daftar awalan yang dikelola dibuat dan dikelola oleh AWS dan tersedia untuk digunakan tanpa biaya tambahan. Anda dapat mereferensikan daftar awalan terkelola CloudFront dalam aturan grup keamanan (AmazonVPC), tabel rute subnet, aturan grup keamanan umum dengan AWS Firewall Manager, dan AWS sumber daya lain yang dapat menggunakan daftar [awalan terkelola](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html).
Untuk informasi selengkapnya tentang menggunakan daftar awalan AWS-managed untuk Amazon CloudFront, lihat [Batasi akses ke asal Anda menggunakan daftar awalan AWS-managed](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/) untuk Amazon. CloudFront
**catatan**
Seperti yang dibahas di bagian lain dari dokumen ini, mengandalkan kelompok keamanan untuk melindungi asal Anda dapat menambahkan [pelacakan koneksi grup keamanan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) sebagai potensi bottle-neck selama permintaan banjir. Kecuali Anda dapat memfilter permintaan berbahaya saat CloudFront menggunakan kebijakan caching yang memungkinkan caching, mungkin lebih baik mengandalkan *Header Kustom Asal*, yang dibahas sebelumnya, untuk membantu memvalidasi bahwa permintaan yang dibuat ke asal Anda dikirim CloudFront, daripada menggunakan grup keamanan. Menggunakan header permintaan kustom dengan aturan pendengar Application Load Balancer mencegah pembatasan karena batas pelacakan yang dapat memengaruhi pembuatan koneksi baru ke penyeimbang beban, sehingga memungkinkan Application Load Balancer untuk menskalakan berdasarkan peningkatan lalu lintas jika terjadi serangan. DDoS
# Melindungi API titik akhir () BP4
Ketika Anda harus mengekspos API ke publik, ada risiko bahwa API frontend dapat ditargetkan oleh serangan. DDoS Untuk membantu mengurangi risiko, Anda dapat menggunakan [Amazon API Gateway sebagai pintu](https://aws.amazon.com/api-gateway/) masuk ke aplikasi yang berjalan di Amazon EC2 AWS Lambda, atau di tempat lain. Dengan menggunakan Amazon API Gateway, Anda tidak memerlukan server Anda sendiri untuk API frontend dan Anda dapat mengaburkan komponen lain dari aplikasi Anda. Dengan mempersulit mendeteksi komponen aplikasi Anda, Anda dapat membantu mencegah AWS sumber daya tersebut ditargetkan oleh DDoS serangan.
Saat Anda menggunakan Amazon API Gateway, Anda dapat memilih dari dua jenis API titik akhir. Yang pertama adalah opsi default: API titik akhir yang dioptimalkan tepi yang diakses melalui distribusi Amazon. CloudFront Distribusi dibuat dan dikelola oleh API Gateway, sehingga Anda tidak memiliki kendali atasnya. Opsi kedua adalah menggunakan API titik akhir regional yang diakses dari titik yang sama Wilayah AWS di mana Anda REST API digunakan. AWS merekomendasikan agar Anda menggunakan jenis endpoint kedua dan mengaitkannya dengan CloudFront distribusi Amazon Anda sendiri. Ini memberi Anda kontrol atas CloudFront distribusi Amazon dan kemampuan untuk digunakan AWS WAF untuk perlindungan lapisan aplikasi. Mode ini memberi Anda akses ke kapasitas DDoS mitigasi skala di seluruh jaringan edge AWS global.
Saat menggunakan Amazon CloudFront dan AWS WAF dengan Amazon API Gateway, konfigurasikan opsi berikut:
+ Konfigurasikan perilaku cache untuk distribusi Anda untuk meneruskan semua header ke titik akhir regional API Gateway. Dengan melakukan ini, CloudFront akan memperlakukan konten sebagai dinamis dan melewatkan caching konten.
+ Lindungi API Gateway Anda dari akses langsung dengan mengonfigurasi distribusi untuk menyertakan header kustom asal x-api-key, dengan menetapkan nilai [APIkunci](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) di API Gateway.
+ Lindungi backend dari kelebihan lalu lintas dengan mengonfigurasi batas standar atau burst rate untuk setiap metode di Anda. REST APIs
Untuk informasi selengkapnya tentang membuat APIs dengan Amazon API Gateway, lihat [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [Memulai](https://aws.amazon.com/api-gateway/getting-started/).