Machine-to-machine manajemen identitas

Machine-to-machine Autentikasi (M2M) memungkinkan layanan dan aplikasi yang berjalan di AWS untuk berkomunikasi dengan aman satu sama lain untuk mengakses sumber daya dan data. Alih-alih menggunakan kredensyal statis jangka panjang, sistem otentikasi mesin mengeluarkan kredensyal atau token sementara untuk mengidentifikasi mesin tepercaya. Mereka memungkinkan kontrol yang tepat atas mesin mana yang dapat mengakses bagian lingkungan tertentu tanpa campur tangan manusia. Otentikasi mesin yang dirancang dengan baik membantu meningkatkan postur keamanan Anda dengan membatasi eksposur kredensyal yang luas, memungkinkan pencabutan izin secara dinamis, dan menyederhanakan rotasi kredensi. Metode umum untuk otentikasi mesin termasuk profil EC2 instans, pemberian kredensyal klien Amazon Cognito, koneksi TLS (mTL) yang saling diautentikasi, dan Peran IAM Di Mana Saja. Bagian ini memberikan panduan tentang penerapan alur autentikasi M2M yang aman dan dapat diskalakan di AWS.

EC2 profil contoh

Untuk skenario di mana Anda memiliki aplikasi atau layanan yang berjalan di Amazon Elastic Compute Cloud (Amazon EC2) yang perlu memanggil AWS APIs, pertimbangkan untuk menggunakan profil EC2 instans. Profil instans memungkinkan aplikasi yang berjalan pada EC2 instans untuk mengakses layanan AWS lainnya dengan aman tanpa memerlukan kunci akses IAM statis yang berumur panjang. Sebagai gantinya, Anda harus menetapkan peran IAM ke instans Anda untuk memberikan izin yang diperlukan melalui profil instance. EC2 Instans kemudian dapat secara otomatis memperoleh kredensil keamanan sementara dari profil instans untuk mengakses layanan AWS lainnya. 

Diagram berikut menggambarkan skenario ini.

1. Aplikasi pada EC2 instance yang perlu memanggil AWS API mengambil kredensyal keamanan yang disediakan oleh peran dari item metadata instance. iam/security-credentials/<role-name> 

2. Aplikasi menerimaAccessKeyId,SecretAccessKey, dan token rahasia yang dapat digunakan untuk menandatangani permintaan AWS API.

3. Aplikasi ini memanggil AWS API. Jika peran mengizinkan tindakan API, permintaan berhasil.

Untuk mempelajari selengkapnya tentang penggunaan kredensyal sementara dengan sumber daya AWS, lihat Menggunakan kredensyal sementara dengan sumber daya AWS dalam dokumentasi IAM.

Keuntungan

• Peningkatan keamanan. Metode ini menghindari distribusi kredensyal jangka panjang ke instance. EC2 Kredensyal disediakan sementara melalui profil instance. 

• Integrasi yang mudah. Aplikasi yang berjalan pada instance dapat secara otomatis memperoleh kredensil tanpa pengkodean atau konfigurasi tambahan. AWS SDKs secara otomatis menggunakan kredensyal profil instans.

• Izin dinamis. Anda dapat mengubah izin yang tersedia untuk instans dengan memperbarui peran IAM yang ditetapkan ke profil instance. Kredensyal baru yang mencerminkan izin yang diperbarui diperoleh secara otomatis. 

• Rotasi. AWS secara otomatis memutar kredensil sementara untuk mengurangi risiko dari kredensi yang dikompromikan. 

• Pencabutan. Anda dapat segera mencabut kredensialnya dengan menghapus penetapan peran dari profil instance.

Pertimbangan desain

• Sebuah EC2 instance hanya dapat memiliki satu profil instance terlampir.

• Gunakan peran IAM dengan hak istimewa paling sedikit. Tetapkan hanya izin yang diperlukan aplikasi Anda ke peran IAM untuk profil instance. Mulailah dengan izin minimum dan tambahkan lebih banyak izin nanti jika diperlukan. 

• Gunakan kondisi IAM dalam kebijakan peran untuk membatasi izin berdasarkan tag, rentang alamat IP, waktu hari, dan sebagainya. Ini membatasi layanan dan sumber daya yang dapat diakses aplikasi.

• Pertimbangkan berapa banyak contoh profil yang Anda butuhkan. Semua aplikasi yang berjalan pada EC2 instans berbagi profil yang sama dan memiliki izin AWS yang sama. Anda dapat menerapkan profil instans yang sama ke beberapa EC2 instance, sehingga Anda dapat mengurangi overhead administratif dengan menggunakan kembali profil instans jika sesuai.

• Pantau aktivitas. Gunakan alat seperti AWS CloudTrail untuk memantau panggilan API yang menggunakan kredensyal profil instans. Perhatikan aktivitas yang tidak biasa yang dapat menunjukkan kredensyal yang dikompromikan. 

• Hapus kredensi yang tidak dibutuhkan. Hapus penetapan peran dari profil instance yang tidak digunakan untuk mencegah penggunaan kredensyal. Anda dapat menggunakan penasihat akses IAM untuk mengidentifikasi peran yang tidak digunakan. 

• Gunakan PassRole izin untuk membatasi peran mana yang dapat diteruskan pengguna ke EC2 instance saat mereka meluncurkan instance. Ini mencegah pengguna menjalankan aplikasi yang memiliki lebih banyak izin daripada yang diberikan pengguna.

• Jika arsitektur Anda mencakup beberapa akun AWS, pertimbangkan bagaimana EC2 instans dalam satu akun mungkin perlu mengakses sumber daya di akun lain. Gunakan peran lintas akun dengan tepat untuk memastikan akses aman tanpa harus menyematkan kredensyal keamanan AWS jangka panjang.

• Untuk mengelola profil instans dalam skala besar, Anda dapat menggunakan salah satu opsi berikut:

  • Gunakan runbook AWS Systems Manager Automation untuk mengotomatiskan asosiasi profil instans ke EC2 instans. Ini dapat dilakukan pada waktu peluncuran, atau setelah sebuah instance berjalan.

  • Gunakan AWS CloudFormation untuk menerapkan profil instans ke EC2 instance secara terprogram pada waktu pembuatan, alih-alih mengonfigurasinya melalui konsol AWS.

• Adalah praktik yang baik untuk menggunakan titik akhir VPC untuk terhubung secara pribadi ke layanan AWS yang didukung seperti Amazon S3 dan Amazon DynamoDB dari aplikasi yang berjalan pada instance. EC2 

Pemberian kredensi klien Amazon Cognito

Amazon Cognito adalah identitas pelanggan terkelola dan layanan manajemen akses. Amazon Cognito menyediakan alur autentikasi OAuth yang sesuai, termasuk kemampuan untuk mengautentikasi mesin atau aplikasi alih-alih pengguna melalui jenis hibah kredensyal klien. Hibah ini memungkinkan aplikasi untuk secara langsung mengambil kredensil AWS sementara untuk mengakses layanan AWS. Kredensi klien Amazon Cognito adalah cara aman untuk memberikan izin AWS ke aplikasi tanpa interaksi pengguna manusia. Aplikasi menyajikan ID klien dan rahasia klien mereka ke titik akhir token Amazon Cognito. Sebagai imbalannya, mereka menerima token akses, yang dapat mereka gunakan untuk mengotentikasi permintaan berikutnya ke berbagai sumber daya dan layanan. Ruang lingkup akses ini ditentukan oleh izin yang terkait dengan ID klien. Aplikasi yang menerima permintaan harus memvalidasi token dengan memeriksa tanda tangan, stempel waktu kedaluwarsa, dan audiens. Setelah pemeriksaan ini, aplikasi memverifikasi bahwa tindakan yang diminta diizinkan dengan memvalidasi klaim dalam token.

Diagram berikut menggambarkan metode ini.

1. Aplikasi (App Client) yang ingin meminta sumber daya dari server (Resource Server) meminta token dari Amazon Cognito.

2. Kumpulan pengguna Amazon Cognito mengembalikan token akses.

3. App Client mengirimkan permintaan ke Resource Server dan menyertakan token akses.

4. Server Sumber Daya memvalidasi token dengan Amazon Cognito.

5. Jika validasi berhasil dan tindakan yang diminta diizinkan, Resource Server merespons dengan sumber daya yang diminta.

Keuntungan

• Otentikasi mesin. Metode ini tidak memerlukan konteks pengguna atau login. Aplikasi mengautentikasi langsung dengan token.

• Kredensi jangka pendek. Aplikasi dapat memperoleh token akses terlebih dahulu dari Amazon Cognito dan kemudian menggunakan token akses terikat waktu untuk mengakses data dari server sumber daya.

• OAuth2 dukungan. Metode ini mengurangi inkonsistensi dan membantu pengembangan aplikasi karena mengikuti standar yang ditetapkan OAuth2 .

• Keamanan yang ditingkatkan. Menggunakan hibah kredensyal klien memberikan keamanan yang ditingkatkan, karena ID klien dan rahasia klien tidak ditransfer ke server sumber daya, tidak seperti mekanisme otorisasi kunci API. ID klien dan rahasia dibagikan dan digunakan hanya saat melakukan panggilan ke Amazon Cognito untuk mendapatkan token akses terikat waktu.

• Kontrol akses berbutir halus melalui cakupan. Aplikasi dapat menentukan dan meminta cakupan dan klaim tambahan untuk membatasi akses hanya ke sumber daya tertentu.

• Jejak audit. Anda dapat menggunakan informasi yang dikumpulkan oleh CloudTrail untuk menentukan permintaan yang dibuat ke Amazon Cognito, alamat IP dari mana permintaan dibuat, siapa yang membuat permintaan, kapan dibuat, dan detail tambahan. 

Pertimbangan desain

• Hati-hati menentukan dan membatasi ruang lingkup akses untuk setiap ID klien ke minimum yang diperlukan. Cakupan yang ketat membantu mengurangi potensi kerentanan dan memastikan bahwa layanan hanya memiliki akses ke sumber daya yang diperlukan. 

• Lindungi klien IDs dan rahasia dengan menggunakan layanan penyimpanan aman seperti AWS Secrets Manager untuk menyimpan kredensyal. Jangan periksa kredensialnya ke dalam kode sumber.

• Memantau dan mengaudit permintaan token dan penggunaan dengan alat-alat seperti CloudTrail dan CloudWatch. Perhatikan pola aktivitas tak terduga yang dapat menunjukkan masalah. 

• Otomatiskan rotasi rahasia klien pada jadwal reguler. Dengan setiap rotasi, buat klien aplikasi baru, hapus klien lama, dan perbarui ID klien dan rahasia. Memfasilitasi rotasi ini tanpa mengganggu komunikasi layanan. 

• Menegakkan batas tarif pada permintaan titik akhir token untuk membantu mencegah serangan penyalahgunaan dan penolakan layanan (DoS). 

• Siapkan strategi untuk mencabut token jika terjadi pelanggaran keamanan. Meskipun token berumur pendek, token yang dikompromikan harus segera dibatalkan.

• Gunakan AWS CloudFormation untuk membuat kumpulan pengguna Amazon Cognito secara terprogram dan klien aplikasi yang mewakili mesin yang perlu mengautentikasi ke layanan lain.

• Jika sesuai, token cache untuk memberikan efisiensi kinerja dan pengoptimalan biaya.

• Pastikan bahwa kedaluwarsa token akses sejalan dengan postur keamanan organisasi Anda.

• Jika Anda menggunakan server sumber daya khusus, selalu verifikasi token akses untuk memastikan bahwa tanda tangan valid, token belum kedaluwarsa, dan cakupan yang benar ada. Verifikasi klaim tambahan sesuai kebutuhan.

• Untuk mengelola kredensyal klien dalam skala besar, Anda dapat menggunakan salah satu opsi ini:

  • Pusatkan pengelolaan semua kredensional klien dalam satu instance Amazon Cognito terpusat. Ini dapat mengurangi overhead manajemen beberapa instans Amazon Cognito, dan dapat membuat konfigurasi dan audit lebih sederhana. Namun, pastikan untuk merencanakan skala dan mempertimbangkan kuota layanan Amazon Cognito.

  • Gabungkan tanggung jawab kredensyal klien ke akun beban kerja dan izinkan beberapa instans Amazon Cognito. Opsi ini mempromosikan fleksibilitas tetapi dapat meningkatkan overhead dan kompleksitas keseluruhan dibandingkan dengan opsi terpusat.

Koneksi mTLS

Otentikasi Mutual TLS (MtLS) adalah mekanisme yang memungkinkan klien dan server untuk mengautentikasi satu sama lain sebelum mereka berkomunikasi dengan menggunakan sertifikat dengan TLS. Kasus penggunaan umum untuk MTL termasuk industri dengan peraturan tinggi, aplikasi Internet of Things (IoT), business-to-business dan aplikasi (B2B). Amazon API Gateway saat ini mendukung mTL selain opsi otorisasi yang ada. Anda dapat mengaktifkan mTL pada domain khusus untuk mengautentikasi terhadap REST Regional dan HTTP. APIs Permintaan dapat diotorisasi dengan menggunakan Bearer, JSON Web Tokens (JWTs), atau menandatangani permintaan dengan otorisasi berbasis IAM. 

Diagram berikut menunjukkan alur otentikasi mTLS untuk aplikasi yang berjalan pada EC2 instance dan API yang disiapkan di Amazon API Gateway.

1. API Gateway meminta sertifikat tepercaya publik langsung dari AWS Certificate Manager (ACM).

2. ACM menghasilkan sertifikat dari otoritas sertifikat (CA).

3. Klien yang memanggil API menyajikan sertifikat dengan permintaan API.

4. API Gateway memeriksa bucket store kepercayaan Amazon S3 yang telah Anda buat. Bucket ini berisi sertifikat X.509 yang Anda percayai untuk mengakses API Anda. Agar API Gateway dapat melanjutkan permintaan, penerbit sertifikat dan rantai kepercayaan lengkap hingga sertifikat CA root harus ada di toko kepercayaan Anda.

5. Jika sertifikat klien dipercaya, API Gateway menyetujui permintaan dan memanggil metode tersebut.

6. Tindakan API terkait (dalam hal ini, fungsi AWS Lambda) memproses permintaan dan mengembalikan respons yang dikirim ke pemohon.

Keuntungan

• Otentikasi M2M. Layanan mengautentikasi satu sama lain secara langsung alih-alih menggunakan rahasia atau token bersama. Ini menghilangkan kebutuhan untuk menyimpan dan mengelola kredensyal statis.

• Perlindungan tamper. Enkripsi TLS melindungi data dalam perjalanan antar layanan. Komunikasi tidak dapat dibaca atau diubah oleh pihak ketiga. 

• Integrasi mudah. Dukungan mTLS dibangun ke dalam bahasa pemrograman utama dan kerangka kerja. Layanan dapat mengaktifkan mTL dengan perubahan kode minimal. 

• Izin granular. Layanan hanya mempercayai sertifikat tertentu, yang memungkinkan kontrol halus atas penelepon yang diizinkan. 

• Pencabutan. Sertifikat yang dikompromikan dapat segera dicabut sehingga tidak lagi dipercaya, mencegah akses lebih lanjut. 

Pertimbangan desain

• Saat Anda menggunakan API Gateway:

  • Secara default, klien dapat memanggil API Anda dengan menggunakan execute-api titik akhir yang dihasilkan API Gateway untuk API Anda. Untuk memastikan bahwa klien dapat mengakses API Anda hanya dengan menggunakan nama domain khusus dengan mTL, nonaktifkan titik akhir default ini. Untuk mempelajari lebih lanjut, lihat Menonaktifkan titik akhir default untuk REST API dalam dokumentasi API Gateway.

  • API Gateway tidak memverifikasi apakah sertifikat telah dicabut.

  • Untuk mengonfigurasi mTL untuk REST API, Anda harus menggunakan nama domain kustom Regional untuk API Anda, dengan versi TLS minimum 1.2. mTL tidak didukung untuk pribadi. APIs

• Anda dapat menerbitkan sertifikat untuk API Gateway dari CA Anda sendiri atau mengimpornya dari AWS Private Certificate Authority.

• Buat proses untuk menerbitkan, mendistribusikan, memperbarui, dan mencabut sertifikat layanan dengan aman. Otomatiskan penerbitan dan pembaruan jika memungkinkan. Jika satu sisi komunikasi M2M Anda adalah gateway API, Anda dapat berintegrasi dengan AWS Private CA.

• Lindungi akses ke CA pribadi. Mengkompromikan CA membahayakan kepercayaan pada semua sertifikat yang dikeluarkan.

• Simpan kunci pribadi dengan aman dan terpisah dari sertifikat. Putar tombol secara berkala untuk membatasi dampak jika dikompromikan.

• Cabut sertifikat segera ketika mereka tidak lagi diperlukan atau jika mereka dikompromikan. Mendistribusikan daftar pencabutan sertifikat ke layanan. 

• Jika memungkinkan, terbitkan sertifikat yang ditujukan hanya untuk tujuan atau sumber daya tertentu untuk membatasi utilitas mereka jika disusupi.

• Memiliki rencana darurat untuk kedaluwarsa sertifikat dan pemadaman infrastruktur CA atau daftar pencabutan sertifikat (CRL). 

• Pantau sistem Anda untuk kegagalan dan pemadaman sertifikat. Perhatikan lonjakan kegagalan yang dapat mengindikasikan masalah.

• Jika Anda menggunakan AWS Certificate Manager (ACM) dengan AWS Private CA, Anda dapat menggunakan AWS CloudFormation untuk meminta sertifikat publik dan pribadi secara terprogram.

• Jika Anda menggunakan ACM, gunakan AWS Resource Access Manager (AWS RAM) untuk membagikan sertifikat dari akun keamanan ke akun beban kerja.

IAM Roles Anywhere

Kami menyarankan Anda menggunakan Peran IAM Di Mana Saja untuk manajemen identitas M2M saat mesin atau sistem perlu terhubung ke layanan AWS tetapi tidak mendukung peran IAM. IAM Roles Anywhere adalah perpanjangan dari IAM yang menggunakan infrastruktur kunci publik (PKI) untuk memberikan akses ke beban kerja dengan menggunakan kredensyal keamanan sementara. Anda dapat menggunakan sertifikat X.509, yang dapat diterbitkan baik melalui CA atau AWS Private CA, untuk membangun jangkar kepercayaan antara CA dan IAM Roles Anywhere. Seperti halnya peran IAM, beban kerja dapat mengakses layanan AWS berdasarkan kebijakan izinnya, yang dilampirkan pada peran tersebut. 

Diagram berikut menunjukkan bagaimana Anda dapat menggunakan IAM Roles Anywhere untuk menghubungkan AWS dengan sumber daya eksternal.

1. Anda membuat jangkar kepercayaan untuk membangun kepercayaan antara akun AWS Anda dan CA yang mengeluarkan sertifikat ke beban kerja lokal Anda. Sertifikat dikeluarkan oleh CA yang Anda daftarkan sebagai jangkar kepercayaan (root of trust) di IAM Roles Anywhere. CA dapat menjadi bagian dari sistem infrastruktur kunci publik (PKI) yang ada, atau dapat berupa CA yang Anda buat dengan AWS Private Certificate Authority dan kelola dengan ACM. Dalam contoh ini, kita menggunakan ACM.

2. Aplikasi Anda membuat permintaan otentikasi ke IAM Roles Anywhere, dan mengirimkan kunci publiknya (dikodekan dalam sertifikat) dan tanda tangan yang ditandatangani oleh kunci pribadi yang sesuai. Aplikasi Anda juga menentukan peran yang akan diambil dalam permintaan.

3. Ketika IAM Roles Anywhere menerima permintaan, pertama-tama ia memvalidasi tanda tangan dengan kunci publik, dan kemudian memvalidasi bahwa sertifikat dikeluarkan oleh jangkar kepercayaan. Setelah kedua validasi berhasil, aplikasi Anda diautentikasi dan IAM Roles Anywhere membuat sesi peran baru untuk peran yang ditentukan dalam permintaan dengan memanggil AWS Security Token Service (AWS STS).

4. Anda menggunakan alat bantu kredensyal yang disediakan IAM Roles Anywhere untuk mengelola proses pembuatan tanda tangan dengan sertifikat dan memanggil titik akhir untuk mendapatkan kredensyal sesi. Alat ini mengembalikan kredensyal ke proses panggilan dalam format JSON standar.

5. Dengan menggunakan model kepercayaan yang dijembatani antara IAM dan PKI ini, beban kerja lokal menggunakan kredensil sementara ini (kunci akses, kunci rahasia, dan token sesi) untuk mengambil peran IAM untuk berinteraksi dengan sumber daya AWS tanpa memerlukan kredensil jangka panjang. Anda juga dapat mengonfigurasi kredensyal ini dengan menggunakan AWS CLI atau AWS. SDKs

Keuntungan

• Tidak ada kredensi permanen. Aplikasi tidak memerlukan kunci akses AWS jangka panjang dengan izin luas. 

• Akses berbutir halus. Kebijakan menentukan peran IAM mana yang dapat diasumsikan untuk entitas tertentu. 

• Peran sadar konteks. Peran dapat disesuaikan berdasarkan rincian entitas yang diautentikasi.

• Pencabutan. Mencabut izin kepercayaan segera memblokir entitas dari mengambil peran.

Pertimbangan desain

• Server harus dapat mendukung otentikasi berbasis sertifikat. 

• Merupakan praktik yang baik untuk mengunci kebijakan kepercayaan untuk digunakan aws:SourceArn atau aws:SourceAccount untuk akun tempat jangkar kepercayaan telah dikonfigurasi. 

• Tag utama dibawa ke depan dari rincian sertifikat. Ini termasuk nama umum (CN), nama alternatif subjek (SAN), subjek, dan penerbit.

• Jika Anda menggunakan ACM, gunakan AWS RAM untuk membagikan sertifikat dari akun keamanan ke akun beban kerja.

• Gunakan izin sistem file sistem operasi (OS) untuk membatasi akses baca ke pengguna yang memiliki.

• Jangan pernah memeriksa kunci ke kontrol sumber. Simpan secara terpisah dari kode sumber untuk mengurangi risiko secara tidak sengaja memasukkannya ke dalam set perubahan. Jika memungkinkan, pertimbangkan untuk menggunakan mekanisme penyimpanan yang aman.

• Pastikan Anda memiliki proses untuk memutar dan mencabut sertifikat.