Beban Kerja OU - Akun aplikasi

Mempengaruhi masa depan AWS Security Reference Architecture (AWSSRA) dengan mengambil survei singkat.

Diagram berikut menggambarkan layanan keamanan AWS yang dikonfigurasi di akun Aplikasi (bersama dengan aplikasi itu sendiri).

Akun Aplikasi menghosting infrastruktur dan layanan utama untuk menjalankan dan memelihara aplikasi perusahaan. Akun Aplikasi dan Beban Kerja OU melayani beberapa tujuan keamanan utama. Pertama, Anda membuat akun terpisah untuk setiap aplikasi untuk memberikan batasan dan kontrol antar beban kerja sehingga Anda dapat menghindari masalah peran, izin, data, dan kunci enkripsi yang akan datang. Anda ingin menyediakan wadah akun terpisah di mana tim aplikasi dapat diberikan hak luas untuk mengelola infrastruktur mereka sendiri tanpa mempengaruhi orang lain. Selanjutnya, Anda menambahkan lapisan perlindungan dengan menyediakan mekanisme bagi tim operasi keamanan untuk memantau dan mengumpulkan data keamanan. Gunakan jejak organisasi dan penerapan lokal layanan keamanan akun (Amazon, AWS GuardDuty Config, AWS Security Hub, Amazon, AWS IAM Access Analyzer), EventBridge yang dikonfigurasi dan dipantau oleh tim keamanan. Terakhir, Anda memungkinkan perusahaan Anda untuk mengatur kontrol secara terpusat. Anda menyelaraskan akun aplikasi ke struktur keamanan yang lebih luas dengan menjadikannya anggota Workloads OU yang melaluinya mewarisi izin layanan, kendala, dan pagar pembatas yang sesuai.

Pertimbangan desain

• Di organisasi Anda, Anda cenderung memiliki lebih dari satu aplikasi bisnis. Beban Kerja OU dimaksudkan untuk menampung sebagian besar beban kerja spesifik bisnis Anda, termasuk lingkungan produksi dan non-produksi. Beban kerja ini dapat berupa campuran aplikasi komersial off-the-shelf (COTS) dan aplikasi kustom dan layanan data Anda sendiri yang dikembangkan secara internal. Ada beberapa pola untuk mengatur aplikasi bisnis yang berbeda bersama dengan lingkungan pengembangannya. Salah satu polanya adalah memiliki beberapa OU anak berdasarkan lingkungan pengembangan Anda, seperti produksi, pementasan, pengujian, dan pengembangan, dan menggunakan akun AWS anak terpisah di bawah OU yang berkaitan dengan aplikasi yang berbeda. Pola umum lainnya adalah memiliki OU anak terpisah per aplikasi dan kemudian menggunakan akun AWS anak terpisah untuk lingkungan pengembangan individu. Struktur OU dan akun yang tepat tergantung pada desain aplikasi Anda dan tim yang mengelola aplikasi tersebut. Pertimbangkan kontrol keamanan yang ingin Anda terapkan, apakah itu khusus lingkungan atau khusus aplikasi, karena lebih mudah untuk menerapkan kontrol tersebut sebagai SCP di OU. Untuk pertimbangan lebih lanjut tentang mengatur OU yang berorientasi pada beban kerja, lihat bagian Mengatur OU yang berorientasi beban kerja pada whitepaper AWS Mengatur Lingkungan AWS Anda Menggunakan Beberapa Akun.

Aplikasi VPC

Virtual private cloud (VPC) di akun Aplikasi memerlukan akses masuk (untuk layanan web sederhana yang Anda modelkan) dan akses keluar (untuk kebutuhan aplikasi atau kebutuhan layanan AWS). Secara default, sumber daya di dalam VPC dapat dirutekan satu sama lain. Ada dua subnet pribadi: satu untuk meng-host instance EC2 (lapisan aplikasi) dan yang lainnya untuk Amazon Aurora (lapisan basis data). Segmentasi jaringan antara tingkatan yang berbeda, seperti tingkat aplikasi dan tingkat basis data, dilakukan melalui grup keamanan VPC, yang membatasi lalu lintas di tingkat instans. Untuk ketahanan, beban kerja mencakup dua atau lebih Availability Zone dan menggunakan dua subnet per zona.

Pertimbangan desain

• Anda dapat menggunakan Traffic Mirroring untuk menyalin lalu lintas jaringan dari elastic network interface instans EC2. Anda kemudian dapat mengirim lalu lintas ke peralatan out-of-band keamanan dan pemantauan untuk pemeriksaan konten, pemantauan ancaman, atau pemecahan masalah. Misalnya, Anda mungkin ingin memantau lalu lintas yang meninggalkan VPC Anda atau lalu lintas yang sumbernya berada di luar VPC Anda. Dalam hal ini, Anda akan mencerminkan semua lalu lintas kecuali lalu lintas yang lewat dalam VPC Anda dan mengirimkannya ke satu alat pemantauan. Log aliran VPC Amazon tidak menangkap lalu lintas cermin; mereka umumnya menangkap informasi dari header paket saja. Traffic Mirroring memberikan wawasan yang lebih dalam tentang lalu lintas jaringan dengan memungkinkan Anda menganalisis konten lalu lintas aktual, termasuk payload. Aktifkan Traffic Mirroring hanya untuk elastic network interface dari instans EC2 yang mungkin beroperasi sebagai bagian dari beban kerja sensitif atau yang Anda harapkan memerlukan diagnostik terperinci jika terjadi masalah.

VPC endpoint

Titik akhir VPC menyediakan lapisan kontrol keamanan lain serta skalabilitas dan keandalan. Gunakan ini untuk menghubungkan VPC aplikasi Anda ke layanan AWS lainnya. (Di akun Aplikasi, AWS SRA menggunakan titik akhir VPC untuk AWS KMS, AWS Systems Manager, dan Amazon S3.) Endpoint adalah perangkat virtual. Mereka merupakan komponen VPC skala horizontal, redundan, dan sangat tersedia. Mereka memungkinkan komunikasi antara instance di VPC dan layanan Anda tanpa memaksakan risiko ketersediaan atau kendala bandwidth pada lalu lintas jaringan Anda. Anda dapat menggunakan titik akhir VPC untuk menghubungkan VPC Anda secara pribadi ke layanan AWS yang didukung dan layanan titik akhir VPC yang didukung oleh AWS PrivateLink tanpa memerlukan gateway internet, perangkat NAT, koneksi VPN, atau koneksi AWS Direct Connect. Instans di VPC Anda tidak memerlukan alamat IP publik untuk berkomunikasi dengan layanan AWS lainnya. Lalu lintas antara VPC Anda dan layanan AWS lainnya tidak meninggalkan jaringan Amazon. 

Manfaat lain menggunakan titik akhir VPC adalah mengaktifkan konfigurasi kebijakan titik akhir. Kebijakan VPC endpoint adalah kebijakan sumber daya IAM yang Anda lampirkan ke titik akhir ketika membuat atau mengubah titik akhir. Jika Anda tidak melampirkan kebijakan IAM saat membuat titik akhir, AWS melampirkan kebijakan IAM default untuk Anda yang memungkinkan akses penuh ke layanan. Kebijakan endpoint tidak mengesampingkan atau mengganti kebijakan IAM atau kebijakan khusus layanan (seperti kebijakan bucket S3). Ini adalah kebijakan IAM terpisah untuk mengontrol akses dari titik akhir ke layanan yang ditentukan. Dengan cara ini, ia menambahkan lapisan kontrol lain di mana prinsipal AWS dapat berkomunikasi dengan sumber daya atau layanan.

Amazon EC2

Instans Amazon EC2 yang menyusun aplikasi kami menggunakan Layanan Metadata Instans versi 2 (IMDSv2). IMDSv2 menambahkan perlindungan untuk empat jenis kerentanan yang dapat digunakan untuk mencoba mengakses IMDS: firewall aplikasi situs web, proxy terbalik terbuka, kerentanan pemalsuan permintaan sisi server (SSRF), firewall lapisan 3 terbuka, dan NAT. Untuk informasi selengkapnya, lihat posting blog Tambahkan pertahanan secara mendalam terhadap firewall terbuka, proxy terbalik, dan kerentanan SSRF dengan penyempurnaan pada Layanan Metadata Instans EC2.

Gunakan VPC terpisah (sebagai bagian dari batas akun) untuk mengisolasi infrastruktur berdasarkan segmen beban kerja. Gunakan subnet untuk melakukan isolasi terhadap jenjang-jenjang aplikasi Anda (misalnya web, aplikasi, dan basis data) dalam satu VPC. Gunakan subnet pribadi untuk instans Anda jika tidak dapat diakses secara langsung dari internet. Untuk memanggil Amazon EC2 API dari subnet pribadi Anda tanpa menggunakan gateway internet, gunakan AWS. PrivateLink Batasi akses ke instans Anda dengan menggunakan grup keamanan. Gunakan Log Aliran VPC untuk memonitor lalu lintas yang menjangkau instans Anda. Gunakan Session Manager, kemampuan AWS Systems Manager, untuk mengakses instans Anda dari jarak jauh alih-alih membuka port SSH masuk dan mengelola kunci SSH. Gunakan volume Amazon Elastic Block Store (Amazon EBS) terpisah untuk sistem operasi dan data Anda. Anda dapat mengonfigurasi akun AWS Anda untuk menerapkan enkripsi volume EBS baru dan salinan snapshot yang Anda buat. 

Contoh implementasi

Pustaka kode AWS SRA menyediakan contoh implementasi enkripsi Amazon EBS default di Amazon EC2. Ini menunjukkan bagaimana Anda dapat mengaktifkan enkripsi Amazon EBS default tingkat akun dalam setiap akun AWS dan Wilayah AWS di organisasi AWS.

Application Load Balancer

Application Load Balancer mendistribusikan lalu lintas aplikasi yang masuk ke beberapa target, seperti instans EC2, di beberapa Availability Zone. Di AWS SRA, grup target untuk penyeimbang beban adalah instans EC2 aplikasi. AWS SRA menggunakan pendengar HTTPS untuk memastikan bahwa saluran komunikasi dienkripsi. Application Load Balancer menggunakan sertifikat server untuk mengakhiri koneksi front-end, dan kemudian mendekripsi permintaan dari klien sebelum mengirimnya ke target.

AWS Certificate Manager (ACM) terintegrasi secara native dengan Application Load Balancers, dan AWS SRA menggunakan ACM untuk menghasilkan dan mengelola sertifikat publik X.509 (server TLS) yang diperlukan. Anda dapat menerapkan TLS 1.2 dan cipher yang kuat untuk koneksi front-end melalui kebijakan keamanan Application Load Balancer. Untuk informasi lebih lanjut, lihat Dokumentasi Penyeimbangan Beban Elastis. 

Pertimbangan desain

• Untuk skenario umum seperti aplikasi internal ketat yang memerlukan sertifikat TLS pribadi pada Application Load Balancer, Anda dapat menggunakan ACM dalam akun ini untuk menghasilkan sertifikat pribadi dari. AWS Private CA Di AWS SRA, root ACM Private CA dihosting di akun Security Tooling dan dapat dibagikan dengan seluruh organisasi AWS atau dengan akun AWS tertentu untuk menerbitkan sertifikat entitas akhir, seperti yang dijelaskan sebelumnya di bagian akun Security Tooling. 

• Untuk sertifikat publik, Anda dapat menggunakan ACM untuk menghasilkan sertifikat tersebut dan mengelolanya, termasuk rotasi otomatis. Atau, Anda dapat membuat sertifikat Anda sendiri dengan menggunakan alat SSL/TLS untuk membuat permintaan penandatanganan sertifikat (CSR), mendapatkan CSR yang ditandatangani oleh otoritas sertifikat (CA) untuk menghasilkan sertifikat, dan kemudian mengimpor sertifikat ke ACM atau mengunggah sertifikat ke IAM untuk digunakan dengan Application Load Balancer. Jika Anda mengimpor sertifikat ke ACM, Anda harus memantau tanggal kedaluwarsa sertifikat dan memperbaruinya sebelum kedaluwarsa. 

• Untuk lapisan pertahanan tambahan, Anda dapat menerapkan kebijakan AWS WAF untuk melindungi Application Load Balancer. Memiliki kebijakan tepi, kebijakan aplikasi, dan bahkan lapisan penegakan kebijakan pribadi atau internal menambah visibilitas permintaan komunikasi dan menyediakan penegakan kebijakan terpadu. Untuk informasi selengkapnya, lihat posting blog Menerapkan pertahanan secara mendalam menggunakan Aturan Terkelola AWS untuk AWS WAF.

AWS Private CA

AWS Private Certificate Authority(AWS Private CA) digunakan dalam akun Aplikasi untuk menghasilkan sertifikat pribadi yang akan digunakan dengan Application Load Balancer. Ini adalah skenario umum untuk Application Load Balancers untuk menyajikan konten aman melalui TLS. Ini membutuhkan sertifikat TLS untuk diinstal pada Application Load Balancer. Untuk aplikasi yang benar-benar internal, sertifikat TLS pribadi dapat menyediakan saluran aman.

Di AWS SRA, AWS Private CA di-host di akun Security Tooling dan dibagikan ke akun Aplikasi dengan menggunakan AWS RAM. Hal ini memungkinkan pengembang di akun Aplikasi untuk meminta sertifikat dari CA pribadi bersama. Berbagi CA di seluruh organisasi Anda atau di seluruh akun AWS membantu mengurangi biaya dan kompleksitas pembuatan dan pengelolaan CA duplikat di semua akun AWS Anda. Saat Anda menggunakan ACM untuk menerbitkan sertifikat pribadi dari CA bersama, sertifikat dibuat secara lokal di akun yang meminta, dan ACM menyediakan manajemen dan perpanjangan siklus hidup penuh.

Amazon Inspector

AWS SRA menggunakan Amazon Inspector untuk secara otomatis menemukan dan memindai instans EC2 dan gambar kontainer yang berada di Amazon Elastic Container Registry (Amazon ECR) untuk mengetahui kerentanan perangkat lunak dan paparan jaringan yang tidak diinginkan.

Amazon Inspector ditempatkan di akun Aplikasi, karena menyediakan layanan manajemen kerentanan untuk instans EC2 di akun ini. Selain itu, Amazon Inspector melaporkan jalur jaringan yang tidak diinginkan ke dan dari instans EC2.

Amazon Inspector di akun anggota dikelola secara terpusat oleh akun administrator yang didelegasikan. Di AWS SRA, akun Security Tooling adalah akun administrator yang didelegasikan. Akun administrator yang didelegasikan dapat mengelola data temuan dan pengaturan tertentu untuk anggota organisasi. Ini termasuk melihat rincian temuan agregat untuk semua akun anggota, mengaktifkan atau menonaktifkan pemindaian untuk akun anggota, dan meninjau sumber daya yang dipindai dalam organisasi AWS. 

Pertimbangan desain

• Anda dapat menggunakan Patch Manager, kemampuan AWS Systems Manager, untuk memicu patching sesuai permintaan guna memulihkan Amazon Inspector zero-day atau kerentanan keamanan kritis lainnya. Patch Manager membantu Anda menambal kerentanan tersebut tanpa harus menunggu jadwal patching normal Anda. Remediasi dilakukan dengan menggunakan runbook Systems Manager Automation. Untuk informasi selengkapnya, lihat dua bagian seri blog Mengotomatiskan manajemen kerentanan dan remediasi di AWS menggunakan Amazon Inspector dan AWS Systems Manager.

Amazon Systems Manager

AWS Systems Manager adalah layanan AWS yang dapat Anda gunakan untuk melihat data operasional dari beberapa layanan AWS dan mengotomatiskan tugas operasional di seluruh sumber daya AWS Anda. Dengan alur kerja dan runbook persetujuan otomatis, Anda dapat bekerja untuk mengurangi kesalahan manusia dan menyederhanakan tugas pemeliharaan dan penerapan pada sumber daya AWS.

Selain kemampuan otomatisasi umum ini, Systems Manager mendukung sejumlah fitur keamanan preventif, detektif, dan responsif. AWS Systems Manager Agent (SSM Agent) adalah perangkat lunak Amazon yang dapat diinstal dan dikonfigurasi pada instans EC2, server lokal, atau mesin virtual (VM). SSM Agent memungkinkan Systems Manager untuk memperbarui, mengelola, dan mengonfigurasi sumber daya ini. Systems Manager membantu Anda menjaga keamanan dan kepatuhan dengan memindai instans dan pelaporan terkelola ini (atau mengambil tindakan korektif) pada setiap pelanggaran yang terdeteksi dalam patch, konfigurasi, dan kebijakan kustom Anda. 

AWS SRA menggunakan Session Manager, kemampuan Systems Manager, untuk memberikan pengalaman CLI dan shell berbasis browser yang interaktif. Ini menyediakan manajemen instans yang aman dan dapat diaudit tanpa perlu membuka port masuk, memelihara host bastion, atau mengelola kunci SSH. AWS SRA menggunakan Patch Manager, kemampuan Systems Manager, untuk menerapkan tambalan ke instans EC2 untuk sistem operasi dan aplikasi. 

AWS SRA juga menggunakan Automation, kemampuan Systems Manager, untuk menyederhanakan tugas pemeliharaan dan penerapan umum instans Amazon EC2 dan sumber daya AWS lainnya. Otomatisasi dapat menyederhanakan tugas-tugas TI umum seperti mengubah status satu atau lebih node (menggunakan otomatisasi persetujuan) dan mengelola status node sesuai dengan jadwal. Systems Manager menyertakan fitur yang membantu Anda menargetkan grup besar instance dengan menggunakan tag, dan kontrol kecepatan yang membantu Anda meluncurkan perubahan sesuai dengan batas yang Anda tentukan. Automation menawarkan otomatisasi sekali klik untuk menyederhanakan tugas-tugas kompleks seperti membuat Amazon Machine Images (AMI) emas dan memulihkan instans EC2 yang tidak terjangkau. Selain itu, Anda dapat meningkatkan keamanan operasional dengan memberikan akses peran IAM ke runbook tertentu untuk menjalankan fungsi tertentu, tanpa secara langsung memberikan izin ke peran tersebut. Misalnya, jika Anda ingin peran IAM memiliki izin untuk memulai ulang instans EC2 tertentu setelah pembaruan tambalan, tetapi Anda tidak ingin memberikan izin langsung ke peran itu, Anda dapat membuat runbook Otomasi dan memberikan izin peran untuk hanya menjalankan runbook.

Pertimbangan desain

• Systems Manager bergantung pada metadata instans EC2 untuk berfungsi dengan benar. Systems Manager dapat mengakses metadata instans dengan menggunakan versi 1 atau versi 2 dari Layanan Metadata Instance (IMDSv1 dan IMDSv2). 

• Agen SSM harus berkomunikasi dengan berbagai layanan dan sumber daya AWS seperti pesan Amazon EC2, Systems Manager, dan Amazon S3. Agar komunikasi ini terjadi, subnet memerlukan konektivitas internet keluar atau penyediaan titik akhir VPC yang sesuai. AWS SRA menggunakan titik akhir VPC untuk Agen SSM untuk membuat jalur jaringan pribadi ke berbagai layanan AWS. 

• Dengan menggunakan otomatisasi, Anda dapat berbagi praktik terbaik dengan seluruh organisasi Anda. Anda dapat membuat praktik terbaik untuk pengelolaan sumber daya di runbook dan membagikan runbook di seluruh Wilayah dan grup AWS. Anda juga dapat membatasi nilai yang diizinkan untuk parameter runbook. Untuk kasus penggunaan ini, Anda mungkin harus membuat runbook Otomasi di akun pusat seperti Perkakas Keamanan atau Layanan Bersama dan membagikannya dengan organisasi AWS lainnya. Kasus penggunaan umum termasuk kemampuan untuk menerapkan patching dan pembaruan keamanan secara terpusat, memulihkan penyimpangan pada konfigurasi VPC atau kebijakan bucket S3, dan mengelola instans EC2 dalam skala besar. Untuk detail implementasi, lihat dokumentasi Systems Manager.

Amazon Aurora

Di AWS SRA, Amazon Aurora dan Amazon S3 membentuk tingkat data logis. Aurora adalah mesin basis data relasional yang dikelola sepenuhnya dan kompatibel dengan MySQL dan PostgreSQL. Aplikasi yang berjalan pada instans EC2 berkomunikasi dengan Aurora dan Amazon S3 sesuai kebutuhan. Aurora dikonfigurasi dengan cluster database di dalam grup subnet DB. 

Pertimbangan desain

• Seperti dalam banyak layanan database, keamanan untuk Aurora dikelola pada tiga tingkatan. Untuk mengontrol siapa yang dapat melakukan tindakan pengelolaan Amazon Relational Database Service (Amazon RDS) pada cluster DB Aurora dan instans DB, Anda menggunakan IAM. Untuk mengontrol perangkat dan instans EC2 mana yang dapat membuka koneksi ke titik akhir cluster dan port instans DB untuk cluster Aurora DB di VPC, Anda menggunakan grup keamanan VPC. Untuk mengautentikasi login dan izin untuk cluster Aurora DB, Anda dapat mengambil pendekatan yang sama seperti dengan instance DB MySQL atau PostgreSQL yang berdiri sendiri, atau Anda dapat menggunakan otentikasi database IAM untuk Aurora MySQL Edisi yang kompatibel dengan MySQL. Dengan pendekatan terakhir ini, Anda mengautentikasi ke cluster DB yang kompatibel dengan Aurora MySQL Anda dengan menggunakan peran IAM dan token otentikasi.

Amazon S3

Amazon S3 adalah layanan penyimpanan objek yang menawarkan skalabilitas, ketersediaan data, keamanan, dan kinerja terdepan di industri. Ini adalah tulang punggung data dari banyak aplikasi yang dibangun di AWS, dan izin serta kontrol keamanan yang sesuai sangat penting untuk melindungi data sensitif. Untuk praktik terbaik keamanan yang direkomendasikan untuk Amazon S3, lihat dokumentasi, pembicaraan teknologi online, dan penyelaman lebih dalam di posting blog. Praktik terbaik yang paling penting adalah memblokir akses yang terlalu permisif (terutama akses publik) ke bucket S3.

AWS KMS

AWS SRA mengilustrasikan model distribusi yang direkomendasikan untuk manajemen kunci, di mana kunci KMS berada dalam akun AWS yang sama dengan sumber daya yang akan dienkripsi. Untuk alasan ini, AWS KMS digunakan di akun Aplikasi selain disertakan dalam akun Security Tooling. Di akun Aplikasi, AWS KMS digunakan untuk mengelola kunci yang khusus untuk sumber daya aplikasi. Anda dapat menerapkan pemisahan tugas dengan menggunakan kebijakan utama untuk memberikan izin penggunaan kunci ke peran aplikasi lokal dan untuk membatasi izin pengelolaan dan pemantauan kepada kustodian utama Anda. 

Pertimbangan desain

• Dalam model terdistribusi, tanggung jawab manajemen kunci AWS KMS berada pada tim aplikasi. Namun, tim keamanan pusat Anda dapat bertanggung jawab atas tata kelola dan pemantauan peristiwa kriptografi penting seperti berikut:

  • Materi kunci yang diimpor dalam kunci KMS mendekati tanggal kedaluwarsanya.

  • Materi kunci dalam kunci KMS diputar secara otomatis.

  • Kunci KMS telah dihapus.

  • Ada tingkat kegagalan dekripsi yang tinggi.

AWS CloudHSM

AWS CloudHSM menyediakan modul keamanan perangkat keras terkelola (HSM) di AWS Cloud. Ini memungkinkan Anda untuk membuat dan menggunakan kunci enkripsi Anda sendiri di AWS dengan menggunakan HSM tervalidasi FIPS 140-2 level 3 yang Anda kontrol aksesnya. Anda dapat menggunakan CloudHSM untuk membongkar pemrosesan SSL/TLS untuk server web Anda. Ini mengurangi beban pada server web dan memberikan keamanan ekstra dengan menyimpan kunci pribadi server web di CloudHSM. Anda juga dapat menerapkan HSM dari CloudHSM di VPC masuk di akun Jaringan untuk menyimpan kunci pribadi Anda dan menandatangani permintaan sertifikat jika Anda perlu bertindak sebagai otoritas sertifikat penerbit. 

Pertimbangan desain

• Jika Anda memiliki persyaratan sulit untuk FIPS 140-2 level 3, Anda juga dapat memilih untuk mengonfigurasi AWS KMS untuk menggunakan klaster CloudHSM sebagai penyimpanan kunci khusus daripada menggunakan penyimpanan kunci KMS asli. Dengan melakukan ini, Anda mendapat manfaat dari integrasi antara AWS KMS dan layanan AWS yang mengenkripsi data Anda, sekaligus bertanggung jawab atas HSM yang melindungi kunci KMS Anda. Ini menggabungkan HSM penyewa tunggal di bawah kendali Anda dengan kemudahan penggunaan dan integrasi AWS KMS. Untuk mengelola infrastruktur CloudHSM Anda, Anda harus menggunakan infrastruktur kunci publik (PKI) dan memiliki tim yang memiliki pengalaman mengelola HSM.

AWS Secrets Manager

AWS Secrets Manager membantu Anda melindungi kredensi (rahasia) yang Anda perlukan untuk mengakses aplikasi, layanan, dan sumber daya TI Anda. Layanan ini memungkinkan Anda untuk secara efisien memutar, mengelola, dan mengambil kredenal database, kunci API, dan rahasia lainnya sepanjang siklus hidupnya. Anda dapat mengganti kredensi hardcode dalam kode Anda dengan panggilan API ke Secrets Manager untuk mengambil rahasia secara terprogram. Ini membantu memastikan bahwa rahasia tidak dapat dikompromikan oleh seseorang yang memeriksa kode Anda, karena rahasia tidak lagi ada dalam kode. Selain itu, Secrets Manager membantu Anda memindahkan aplikasi antar lingkungan (pengembangan, pra-produksi, produksi). Alih-alih mengubah kode, Anda dapat memastikan bahwa rahasia yang diberi nama dan direferensikan dengan tepat tersedia di lingkungan. Ini mempromosikan konsistensi dan kegunaan kembali kode aplikasi di lingkungan yang berbeda, sementara membutuhkan lebih sedikit perubahan dan interaksi manusia setelah kode diuji. 

Dengan Secrets Manager, Anda dapat mengelola akses ke rahasia dengan menggunakan kebijakan IAM berbutir halus dan kebijakan berbasis sumber daya. Anda dapat membantu mengamankan rahasia dengan mengenkripsinya dengan kunci enkripsi yang Anda kelola dengan menggunakan AWS KMS. Secrets Manager juga terintegrasi dengan layanan pencatatan dan pemantauan AWS untuk audit terpusat. 

Secrets Manager menggunakan enkripsi amplop dengan kunci AWS KMS dan kunci data untuk melindungi setiap nilai rahasia. Saat membuat rahasia, Anda dapat memilih kunci terkelola pelanggan simetris apa pun di akun AWS dan Wilayah, atau Anda dapat menggunakan kunci terkelola AWS untuk Secrets Manager. 

Sebagai praktik terbaik, Anda dapat memantau rahasia Anda untuk mencatat perubahan apa pun padanya. Ini membantu Anda memastikan bahwa penggunaan atau perubahan yang tidak terduga dapat diselidiki. Perubahan yang tidak diinginkan dapat digulung kembali. Secrets Manager saat ini mendukung dua layanan AWS yang memungkinkan Anda memantau organisasi dan aktivitas Anda: AWS CloudTrail dan AWS Config. CloudTrail menangkap semua panggilan API untuk Secrets Manager sebagai peristiwa, termasuk panggilan dari konsol Secrets Manager dan dari panggilan kode ke Secrets Manager API. Selain itu, CloudTrail menangkap peristiwa terkait (non-API) lainnya yang mungkin memiliki dampak keamanan atau kepatuhan pada akun AWS Anda atau mungkin membantu Anda memecahkan masalah operasional. Ini termasuk peristiwa rotasi rahasia tertentu dan penghapusan versi rahasia. AWS Config dapat menyediakan kontrol detektif dengan melacak dan memantau perubahan rahasia di Secrets Manager. Perubahan ini mencakup deskripsi rahasia, konfigurasi rotasi, tag, dan hubungan dengan sumber AWS lainnya seperti kunci enkripsi KMS atau fungsi AWS Lambda yang digunakan untuk rotasi rahasia. Anda juga dapat mengonfigurasi Amazon EventBridge, yang menerima pemberitahuan perubahan konfigurasi dan kepatuhan dari AWS Config, untuk merutekan peristiwa rahasia tertentu untuk tindakan pemberitahuan atau remediasi. 

Di AWS SRA, Secrets Manager terletak di akun Aplikasi untuk mendukung kasus penggunaan aplikasi lokal dan untuk mengelola rahasia yang dekat dengan penggunaannya. Di sini, profil instance dilampirkan ke instans EC2 di akun Aplikasi. Rahasia terpisah kemudian dapat dikonfigurasi di Secrets Manager untuk memungkinkan profil instans tersebut mengambil rahasia—misalnya, untuk bergabung dengan Active Directory atau domain LDAP yang sesuai dan untuk mengakses database Aurora. Secrets Manager terintegrasi dengan Amazon RDS untuk mengelola kredensional pengguna saat Anda membuat, memodifikasi, atau memulihkan instans Amazon RDS DB atau cluster DB multi-AZ. Ini membantu Anda mengelola pembuatan dan rotasi kunci dan mengganti kredensi hardcode dalam kode Anda dengan panggilan API terprogram ke Secrets Manager.

Pertimbangan desain

• Secara umum, konfigurasikan dan kelola Secrets Manager di akun yang paling dekat dengan tempat rahasia akan digunakan. Pendekatan ini memanfaatkan pengetahuan lokal tentang kasus penggunaan dan memberikan kecepatan dan fleksibilitas kepada tim pengembangan aplikasi. Untuk informasi yang dikontrol ketat di mana lapisan kontrol tambahan mungkin sesuai, rahasia dapat dikelola secara terpusat oleh Secrets Manager di akun Security Tooling.

Amazon Cognito

Amazon Cognito memungkinkan Anda menambahkan pendaftaran pengguna, masuk, dan kontrol akses ke web dan aplikasi seluler Anda dengan cepat dan efisien. Amazon Cognito menskalakan jutaan pengguna dan mendukung proses masuk dengan penyedia identitas sosial, seperti Apple, Facebook, Google, dan Amazon, serta penyedia identitas perusahaan melalui SAMP 2.0 dan OpenID Connect. Dua komponen utama Amazon Cognito adalah kumpulan pengguna dan kumpulan identitas. Kumpulan pengguna adalah direktori pengguna yang menyediakan opsi pendaftaran dan masuk untuk pengguna aplikasi Anda. Kumpulan identitas memungkinkan Anda memberi pengguna Anda akses ke layanan AWS lainnya. Anda dapat menggunakan kolam identitas dan kolam pengguna secara terpisah atau bersama-sama. Untuk skenario penggunaan umum, lihat dokumentasi Amazon Cognito.

Amazon Cognito menyediakan UI bawaan dan dapat disesuaikan untuk pendaftaran dan masuk pengguna. Anda dapat menggunakan Android, iOS, dan JavaScript SDK untuk Amazon Cognito untuk menambahkan halaman pendaftaran dan login pengguna ke aplikasi Anda. Amazon Cognito Sync adalah layanan AWS dan pustaka klien yang memungkinkan sinkronisasi lintas perangkat data pengguna terkait aplikasi.  

Amazon Cognito mendukung otentikasi multi-faktor dan enkripsi data saat istirahat dan data dalam perjalanan. Kumpulan pengguna Amazon Cognito menyediakan fitur keamanan canggih untuk membantu melindungi akses ke akun di aplikasi Anda. Fitur keamanan canggih ini memberikan otentikasi adaptif berbasis risiko dan perlindungan dari penggunaan kredensyal yang dikompromikan.  

Pertimbangan desain

• Anda dapat membuat fungsi AWS Lambda dan kemudian memicu fungsi tersebut selama operasi kumpulan pengguna seperti pendaftaran pengguna, konfirmasi, dan masuk (autentikasi) dengan pemicu AWS Lambda. Anda dapat menambahkan tantangan autentikasi, memigrasikan pengguna, dan menyesuaikan pesan verifikasi. Untuk operasi umum dan alur pengguna, lihat dokumentasi Amazon Cognito. Amazon Cognito memanggil fungsi Lambda secara sinkron. 

• Anda dapat menggunakan kumpulan pengguna Amazon Cognito untuk mengamankan aplikasi kecil multi-penyewa. Kasus penggunaan umum desain multi-tenant adalah menjalankan beban kerja untuk mendukung pengujian beberapa versi aplikasi. Desain multi-penyewa juga berguna untuk menguji aplikasi tunggal dengan set data yang berbeda, yang memungkinkan penggunaan penuh sumber daya klaster Anda. Namun, pastikan bahwa jumlah penyewa dan volume yang diharapkan selaras dengan kuota layanan Amazon Cognito terkait. Kuota ini dibagi di semua penyewa di dalam aplikasi Anda.

Izin Terverifikasi Amazon

Izin Terverifikasi Amazon adalah manajemen izin yang dapat diskalakan dan layanan otorisasi berbutir halus untuk aplikasi yang Anda buat. Pengembang dan administrator dapat menggunakan Cedar, bahasa kebijakan sumber terbuka yang dibuat khusus dan mengutamakan keamanan, dengan peran dan atribut untuk menentukan kontrol akses berbasis kebijakan yang lebih terperinci, sadar konteks, dan berbasis kebijakan. Pengembang dapat membangun aplikasi yang lebih aman lebih cepat dengan mengeksternalisasi otorisasi dan memusatkan manajemen dan administrasi kebijakan. Izin Terverifikasi mencakup definisi skema, tata bahasa pernyataan kebijakan, dan penalaran otomatis yang menskalakan jutaan izin, sehingga Anda dapat menerapkan prinsip penolakan default dan hak istimewa terkecil. Layanan ini juga mencakup alat simulator evaluasi untuk membantu Anda menguji keputusan otorisasi dan kebijakan penulis Anda. Fitur-fitur ini memfasilitasi penerapan model otorisasi yang mendalam dan berbutir halus untuk mendukung tujuan zero-trust Anda. Izin Terverifikasi memusatkan izin di toko kebijakan dan membantu pengembang menggunakan izin tersebut untuk mengotorisasi tindakan pengguna dalam aplikasi mereka.

Anda dapat menghubungkan aplikasi Anda ke layanan melalui API untuk mengotorisasi permintaan akses pengguna. Untuk setiap permintaan otorisasi, layanan mengambil kebijakan yang relevan dan mengevaluasi kebijakan tersebut untuk menentukan apakah pengguna diizinkan untuk mengambil tindakan pada sumber daya, berdasarkan masukan konteks seperti pengguna, peran, keanggotaan grup, dan atribut. Anda dapat mengonfigurasi dan menghubungkan Izin Terverifikasi untuk mengirim log manajemen dan otorisasi kebijakan Anda ke AWS. CloudTrail Jika Anda menggunakan Amazon Cognito sebagai penyimpanan identitas, Anda dapat mengintegrasikan dengan Izin Terverifikasi dan menggunakan ID dan token akses yang dikembalikan Amazon Cognito dalam keputusan otorisasi dalam aplikasi Anda. Anda memberikan token Amazon Cognito ke Izin Terverifikasi, yang menggunakan atribut yang terkandung dalam token untuk mewakili prinsipal dan mengidentifikasi hak prinsipal. Untuk informasi selengkapnya tentang integrasi ini, lihat postingan blog AWS Menyederhanakan otorisasi halus dengan Izin Terverifikasi Amazon dan Amazon Cognito.

Izin Terverifikasi membantu Anda menentukan kontrol akses berbasis kebijakan (PBAC). PBAC adalah model kontrol akses yang menggunakan izin yang dinyatakan sebagai kebijakan untuk menentukan siapa yang dapat mengakses sumber daya dalam aplikasi. PBAC menyatukan kontrol akses berbasis peran (RBAC) dan kontrol akses berbasis atribut (ABAC), menghasilkan model kontrol akses yang lebih kuat dan fleksibel. Untuk mempelajari lebih lanjut tentang PBAC dan cara mendesain model otorisasi menggunakan Izin Terverifikasi, lihat postingan blog AWS Kontrol akses berbasis kebijakan dalam pengembangan aplikasi dengan Izin Terverifikasi Amazon.

Di AWS SRA, Izin Terverifikasi terletak di akun Aplikasi untuk mendukung manajemen izin untuk aplikasi melalui integrasinya dengan Amazon Cognito.

Pertahanan berlapis

Akun Aplikasi memberikan kesempatan untuk mengilustrasikan prinsip pertahanan berlapis yang diaktifkan AWS. Pertimbangkan keamanan instans EC2 yang merupakan inti dari contoh aplikasi sederhana yang diwakili dalam AWS SRA dan Anda dapat melihat cara layanan AWS bekerja sama dalam pertahanan berlapis. Pendekatan ini sejalan dengan tampilan struktural layanan keamanan AWS, seperti yang dijelaskan di bagian Menerapkan layanan keamanan di seluruh organisasi AWS Anda sebelumnya dalam panduan ini.

• Lapisan terdalam adalah instans EC2. Seperti disebutkan sebelumnya, instans EC2 mencakup banyak fitur keamanan asli baik secara default atau sebagai opsi. Contohnya termasuk IMDSv2, sistem Nitro, dan enkripsi penyimpanan Amazon EBS.

• Lapisan perlindungan kedua berfokus pada sistem operasi dan perangkat lunak yang berjalan pada instans EC2. Layanan seperti Amazon Inspector dan AWS Systems Manager memungkinkan Anda memantau, melaporkan, dan mengambil tindakan korektif pada konfigurasi ini. Inspector memantau kerentanan perangkat lunak Anda dan Systems Manager membantu Anda menjaga keamanan dan kepatuhan dengan memindai instans terkelola untuk status patch dan konfigurasi mereka, lalu melaporkan dan mengambil tindakan korektif apa pun yang Anda tentukan.

• Instans, dan perangkat lunak yang berjalan pada instans ini, sesuai dengan infrastruktur jaringan AWS Anda. Selain menggunakan fitur keamanan Amazon VPC, AWS SRA juga memanfaatkan titik akhir VPC untuk menyediakan konektivitas pribadi antara VPC dan layanan AWS yang didukung, dan untuk menyediakan mekanisme untuk menempatkan kebijakan akses pada batas jaringan.

• Aktivitas dan konfigurasi instans EC2, perangkat lunak, jaringan, dan peran serta sumber daya IAM dipantau lebih lanjut oleh layanan yang berfokus pada akun AWS seperti AWS Security Hub, Amazon, AWS, AWS CloudTrail Config, GuardDuty AWS IAM Access Analyzer, dan Amazon Macie.

• Terakhir, di luar akun Aplikasi, AWS RAM membantu mengontrol sumber daya mana yang dibagikan dengan akun lain, dan kebijakan kontrol layanan IAM membantu Anda menerapkan izin yang konsisten di seluruh organisasi AWS.