Machine-to-machine manajemen identitas - AWS Bimbingan Preskriptif
EC2profil contohPemberian kredensi klien Amazon Cognitom TLS koneksiIAMPeran Di Mana Saja

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Machine-to-machine manajemen identitas

Machine-to-machine Autentikasi (M2M) memungkinkan layanan dan aplikasi yang berjalan AWS untuk berkomunikasi dengan aman satu sama lain untuk mengakses sumber daya dan data. Alih-alih menggunakan kredensil statis jangka panjang, sistem otentikasi mesin mengeluarkan kredensi 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 alat berat yang dirancang dengan baik membantu meningkatkan postur keamanan Anda dengan membatasi eksposur kredensi 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 (TLSm) yang saling TLS diautentikasi, dan Peran Di Mana Saja. IAM Bagian ini memberikan panduan tentang penerapan alur otentikasi M2M yang aman dan dapat diskalakan. AWS

EC2profil contoh

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

Diagram berikut menggambarkan skenario ini.

Menggunakan profil EC2 instance untuk manajemen machine-to-machine identitas

  1. Aplikasi pada EC2 instance yang perlu memanggil AWS API mengambil kredenal 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 AWS API permintaan.

  3. Aplikasi memanggil file AWSAPI. Jika peran memungkinkan API tindakan, permintaan berhasil.

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

Keuntungan

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

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

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

  • Rotasi. AWSsecara otomatis memutar kredensyal sementara untuk mengurangi risiko dari kredensyal 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 IAM peran hak istimewa paling sedikit. Tetapkan hanya izin yang diperlukan aplikasi Anda untuk IAM peran profil instance. Mulailah dengan izin minimum dan tambahkan lebih banyak izin nanti jika diperlukan. 

  • Gunakan IAM kondisi 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 sebuah EC2 instance berbagi profil yang sama dan memiliki AWS izin 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 API panggilan yang menggunakan kredenal profil instance. Perhatikan aktivitas yang tidak biasa yang dapat menunjukkan kredensil yang dikompromikan. 

  • Hapus kredensi yang tidak dibutuhkan. Hapus penetapan peran dari profil instans yang tidak digunakan untuk mencegah penggunaan kredensil. Anda dapat menggunakan penasihat IAM akses 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 AWS akun, pertimbangkan bagaimana EC2 instance dalam satu akun mungkin perlu mengakses sumber daya di akun lain. Gunakan peran lintas akun dengan tepat untuk memastikan akses aman tanpa harus menanamkan kredensi keamanan jangka panjangAWS.

  • 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 instance. Ini dapat dilakukan pada waktu peluncuran, atau setelah instance berjalan.

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

  • Merupakan praktik yang baik untuk menggunakan VPC titik akhir untuk terhubung secara pribadi ke AWS layanan 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 kredensil klien. Hibah ini memungkinkan aplikasi untuk secara langsung mengambil AWS kredensi sementara untuk mengakses layanan. AWS Kredensi klien Amazon Cognito adalah cara aman untuk memberikan AWS izin 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 mengautentikasi 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.

Menggunakan kredensi klien Amazon Cognito untuk manajemen identitas machine-to-machine

  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 mengotentikasi 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.

  • OAuth2dukungan. Metode ini mengurangi inkonsistensi dan membantu pengembangan aplikasi karena mengikuti standar yang ditetapkanOAuth2.

  • Keamanan yang ditingkatkan. Menggunakan hibah kredensi klien memberikan keamanan yang ditingkatkan, karena ID klien dan rahasia klien tidak ditransfer ke server sumber daya, tidak seperti mekanisme otorisasi API kunci. 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 itu 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 kredensil. 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 kredensi 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 mempermudah konfigurasi dan audit. Namun, pastikan untuk merencanakan skala dan mempertimbangkan kuota layanan Amazon Cognito.

    • Gabungkan tanggung jawab kredensil 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.

m TLS koneksi

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

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

m TLS otentikasi untuk aplikasi yang berjalan pada sebuah instance EC2

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

  2. ACMmenghasilkan sertifikat dari otoritas sertifikat (CA).

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

  4. APIGateway memeriksa bucket toko kepercayaan Amazon S3 yang telah Anda buat. Bucket ini berisi sertifikat X.509 yang Anda percayai untuk mengaksesnya. API 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. APITindakan 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. TLSenkripsi melindungi data dalam perjalanan antar layanan. Komunikasi tidak dapat dibaca atau diubah oleh pihak ketiga. 

  • Integrasi mudah. TLS dukungan m dibangun ke dalam bahasa pemrograman utama dan kerangka kerja. Layanan dapat mengaktifkan m TLS 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 Anda API dengan menggunakan execute-api titik akhir yang dihasilkan API Gateway untuk AndaAPI. Untuk memastikan bahwa klien API hanya dapat mengakses Anda dengan menggunakan nama domain kustom dengan mTLS, nonaktifkan titik akhir default ini. Untuk mempelajari selengkapnya, lihat Menonaktifkan titik akhir default untuk dokumentasi REST API Gateway. API

    • APIGateway tidak memverifikasi apakah sertifikat telah dicabut.

    • Untuk mengonfigurasi m TLS untuk a RESTAPI, Anda harus menggunakan nama domain kustom Regional untuk AndaAPI, dengan TLS versi minimum 1.2. m TLS tidak didukung untuk pribadiAPIs.

  • 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 API gateway, 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. Bagikan 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 menggunakannya AWS CloudFormation untuk meminta sertifikat publik dan pribadi secara terprogram.

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

IAMPeran Di Mana Saja

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

Diagram berikut menunjukkan bagaimana Anda dapat menggunakan IAM Peran Di Mana Saja untuk terhubung AWS dengan sumber daya eksternal.

Menggunakan IAM Peran Di Mana Saja untuk manajemen machine-to-machine identitas

  1. Anda membuat jangkar kepercayaan untuk membangun kepercayaan antara AWS akun 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 AWSPrivate Certificate Authority dan kelola denganACM. Dalam contoh ini, kami menggunakanACM.

  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 AWSSecurity Token Service (). AWS STS

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

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

Keuntungan

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

  • Akses berbutir halus. Kebijakan menentukan IAM peran 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 menggunakanACM, 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.