Dampak autentikasi multifaktor pada Azure PowerShell dalam skenario otomatisasi

Artikel ini mengeksplorasi bagaimana autentikasi multifaktor (MFA) memengaruhi tugas otomatisasi yang menggunakan identitas pengguna Microsoft Entra dan memberikan panduan tentang pendekatan alternatif untuk otomatisasi tanpa gangguan.

Important

Tindakan diperlukan jika Anda menggunakan identitas pengguna Microsoft Entra untuk otomatisasi.

Persyaratan MFA mencegah Anda menggunakan identitas pengguna Microsoft Entra untuk autentikasi dalam skenario otomatisasi. Organisasi harus beralih ke metode autentikasi yang dirancang untuk otomatisasi, seperti identitas terkelola atau perwakilan layanan, yang mendukung kasus penggunaan otomatisasi non-interaktif.

Batasan identitas pengguna dengan MFA dalam otomatisasi

Note

Anda mungkin menemukan pesan kesalahan: Autentikasi interaktif diperlukan saat menggunakan identitas pengguna dengan otomatisasi.

  • Autentikasi interaktif: MFA dipicu selama masuk interaktif saat menggunakan identitas pengguna Microsoft Entra. Untuk skrip otomatisasi yang mengandalkan identitas pengguna, MFA mengganggu proses karena memerlukan langkah-langkah verifikasi tambahan. Misalnya, aplikasi pengautentikasi, panggilan telepon, dll., yang tidak dapat Anda otomatiskan. Verifikasi ini mencegah otomatisasi berjalan kecuali autentikasi ditangani dengan cara yang tidak interaktif, seperti dengan identitas terkelola atau perwakilan layanan.

  • Scripted kegagalan masuk: Dalam skenario otomatisasi seperti menjalankan skrip Azure PowerShell tanpa pengawasan, identitas pengguna yang mengaktifkan MFA menyebabkan skrip gagal saat mencoba mengautentikasi. Karena MFA memerlukan interaksi pengguna, MFA tidak kompatibel dengan skrip non-interaktif. Ini berarti Anda harus beralih ke identitas terkelola atau perwakilan layanan, yang keduanya menggunakan autentikasi non-interaktif.

  • Pertimbangan keamanan: Meskipun MFA menambahkan lapisan keamanan tambahan, MFA dapat membatasi fleksibilitas otomatisasi, terutama di lingkungan produksi di mana otomatisasi harus berjalan tanpa intervensi manual. Beralih ke identitas terkelola, perwakilan layanan, atau identitas federasi, yang dirancang untuk tujuan otomatisasi dan tidak memerlukan MFA, lebih praktis dan aman di lingkungan tersebut.

Skenario yang memerlukan pembaruan

Daftar berikut ini menyediakan contoh skenario di mana pelanggan mungkin menggunakan identitas pengguna Microsoft Entra untuk otomatisasi dengan Azure PowerShell. Daftar ini tidak lengkap dari semua skenario.

Peringatan

Skenario otomatisasi apa pun yang menggunakan identitas pengguna Microsoft Entra memerlukan pembaruan.

  • Personalisasi atau izin tertentu: Tugas otomatisasi yang memerlukan izin khusus pengguna, seperti tindakan yang terkait dengan peran individu atau atribut Microsoft Entra ID tertentu.

  • Alur ROPC OAuth 2.0: Alur pemberian token OAuth 2.0 Resource Owner Password Credentials (ROPC) tidak kompatibel dengan MFA. Skenario automasi menggunakan ROPC untuk autentikasi gagal saat MFA diperlukan, karena MFA tidak dapat diselesaikan dalam alur non-interaktif.

  • Akses ke sumber daya eksternal Azure: Skenario automasi yang memerlukan akses ke sumber daya Microsoft 365. Misalnya, SharePoint, Exchange, atau layanan cloud lainnya yang terkait dengan akun Microsoft pengguna individu.

  • Akun layanan yang disinkronkan dari Direktori Aktif ke Microsoft Entra ID: Organisasi yang menggunakan akun layanan yang disinkronkan dari Direktori Aktif (AD) ke Microsoft Entra ID. Penting untuk dicatat bahwa akun-akun ini juga tunduk pada persyaratan MFA dan memicu masalah yang sama dengan identitas pengguna lainnya.

  • Konteks pengguna untuk audit atau kepatuhan: Kasus di mana tindakan perlu diaudit pada tingkat pengguna individual karena alasan kepatuhan.

  • Konfigurasi sederhana untuk otomatisasi skala kecil atau berisiko rendah: Untuk tugas otomatisasi skala kecil atau berisiko rendah. Misalnya, skrip yang mengelola beberapa sumber daya.

  • Otomatisasi berbasis pengguna di lingkungan nonproduksi: Jika otomatisasi ditujukan untuk lingkungan pribadi atau nonproduksi di mana pengguna individu bertanggung jawab atas tugas.

  • Automasi dalam langganan Azure pengguna sendiri: Jika pengguna perlu mengotomatiskan tugas dalam langganan Azure mereka sendiri di mana mereka sudah memiliki izin yang cukup.

Beralih ke identitas terkelola atau perwakilan layanan diperlukan untuk skenario otomatisasi karena penerapan MFA wajib untuk identitas pengguna Microsoft Entra.

Cara memulai

Untuk memigrasikan skrip Azure PowerShell Anda dari menggunakan Connect-AzAccount dengan akun pengguna dan kata sandi manusia Microsoft Entra ID, ikuti langkah-langkah berikut:

  1. Tentukan identitas beban kerja mana yang terbaik untuk Anda.

    • Perwakilan layanan
    • Identitas yang dikelola
    • Identitas gabungan

  2. Dapatkan izin yang diperlukan untuk membuat identitas beban kerja baru, atau hubungi administrator Azure Anda untuk mendapatkan bantuan.

  3. Buat identitas beban kerja.

  4. Tetapkan peran untuk identitas baru. Untuk informasi selengkapnya tentang penetapan peran Azure, lihat Steps untuk menetapkan peran Azure. Untuk menetapkan peran menggunakan Azure PowerShell, lihat Assign Azure roles using Azure PowerShell.

  5. Perbarui skrip Azure PowerShell Anda untuk masuk dengan perwakilan layanan atau identitas terkelola.

Konsep kunci prinsipal layanan

  • Identitas non-manusia yang dapat mengakses beberapa sumber daya Azure. Entitas layanan digunakan oleh banyak sumber daya Azure dan tidak terkait dengan satu sumber daya Azure.
  • Anda dapat mengubah properti dan kredensial perwakilan layanan sesuai kebutuhan.
  • Ideal untuk aplikasi yang perlu mengakses beberapa sumber daya Azure di berbagai langganan.
  • Dianggap lebih fleksibel daripada identitas terkelola tetapi kurang aman.
  • Sering disebut sebagai "objek aplikasi" di penyewa Azure atau direktori Microsoft Entra ID.

Untuk mempelajari lebih lanjut tentang prinsipal layanan, lihat:

Untuk mempelajari cara masuk ke Azure menggunakan Azure PowerShell dan perwakilan layanan, lihat Sign ke Azure dengan perwakilan layanan menggunakan Azure PowerShell

Konsep kunci identitas terkelola

  • Terkait dengan sumber daya Azure tertentu yang memungkinkan sumber daya tunggal tersebut mengakses aplikasi Azure lainnya.
  • Kredensial tidak terlihat oleh Anda. Azure menangani rahasia, kredensial, sertifikat, dan kunci.
  • Ideal untuk sumber daya Azure yang perlu mengakses sumber daya Azure lainnya dalam satu langganan.
  • Dianggap kurang fleksibel dibandingkan dengan prinsipal layanan namun lebih aman.
  • Ada dua jenis identitas terkelola:
    • System yang ditetapkan: Jenis ini adalah tautan akses 1:1 (satu hingga satu) antara dua sumber daya Azure.
    • Pengguna yang ditetapkan: Jenis ini memiliki hubungan 1:M (satu hingga banyak) di mana identitas terkelola dapat mengakses beberapa sumber daya Azure.

Untuk mempelajari selengkapnya tentang identitas terkelola, lihat Identitas terkelola untuk sumber daya Azure.

Untuk mempelajari cara masuk ke Azure menggunakan Azure PowerShell dan identitas terkelola, lihat Sign ke Azure dengan identitas terkelola menggunakan Azure PowerShell

Konsep kunci identitas federasi

  • Identitas federatif memungkinkan prinsipal layanan (pendaftaran aplikasi) dan identitas terkelola yang ditetapkan oleh pengguna untuk mempercayai token dari penyedia identitas eksternal, seperti GitHub atau Google.
  • Setelah hubungan kepercayaan dibuat, beban kerja perangkat lunak eksternal Anda bertukar token tepercaya dari IdP eksternal untuk token akses dari platform identitas Microsoft.
  • Beban kerja perangkat lunak Anda menggunakan token akses tersebut untuk mengakses sumber daya yang dilindungi Microsoft Entra tempat beban kerja diberikan akses.
  • Identitas federasi sering kali merupakan solusi terbaik untuk skenario berikut:
    • Beban kerja yang berjalan pada klaster Kubernetes apa pun
    • GitHub Actions
    • Beban kerja yang berjalan di platform komputasi Azure menggunakan identitas aplikasi
    • Google Cloud
    • Amazon Web Services (AWS)
    • Beban kerja yang berjalan di platform komputasi di luar Azure

Untuk mempelajari selengkapnya tentang identitas federasi, lihat:

Pelajari selengkapnya tentang autentikasi multifaktor

Situs dokumentasi Microsoft Entra ID menawarkan detail lebih lanjut tentang MFA.

Baca juga

  • Last updated on