Udostępnij przez

Wpływ uwierzytelniania wieloskładnikowego na program Azure PowerShell w scenariuszach automatyzacji

W tym artykule opisano, jak uwierzytelnianie wieloskładnikowe (MFA) wpływa na zadania automatyzacji, które korzystają z tożsamości użytkowników firmy Microsoft Entra i zawiera wskazówki dotyczące alternatywnych metod nieprzerwanej automatyzacji.

Ważne

Jeśli do automatyzacji używasz tożsamości użytkowników firmy Microsoft Entra, wymagana jest akcja.

Wymagania uwierzytelniania wieloskładnikowego uniemożliwiają korzystanie z tożsamości użytkowników firmy Microsoft entra na potrzeby uwierzytelniania w scenariuszach automatyzacji. Organizacje muszą przełączyć się na metody uwierzytelniania przeznaczone do automatyzacji, takie jak tożsamości zarządzane lub jednostki usługi, które obsługują przypadki użycia automatyzacji nieinterakcyjnej.

Ograniczenia tożsamości użytkowników z uwierzytelnianiem wieloskładnikowym w automatyzacji

Uwaga / Notatka

Może wystąpić komunikat o błędzie: Uwierzytelnianie interakcyjne jest wymagane w przypadku korzystania z tożsamości użytkownika z automatyzacją.

  • Uwierzytelnianie interakcyjne: uwierzytelnianie wieloskładnikowe jest wyzwalane podczas logowania interakcyjnego podczas korzystania z tożsamości użytkownika firmy Microsoft Entra. W przypadku skryptów automatyzacji opartych na tożsamości użytkownika uwierzytelnianie wieloskładnikowe zakłóca proces, ponieważ wymaga dodatkowych kroków weryfikacji. Na przykład aplikacja wystawcy uwierzytelniania, połączenie telefoniczne itp., których nie można zautomatyzować. Ta weryfikacja uniemożliwia uruchomienie automatyzacji, chyba że uwierzytelnianie jest obsługiwane w sposób nieinterakcyjny, taki jak tożsamość zarządzana lub jednostka usługi.

  • Błędy logowania skryptów: w scenariuszach automatyzacji, takich jak uruchamianie skryptów programu Azure PowerShell nienadzorowanych, tożsamość użytkownika z obsługą uwierzytelniania wieloskładnikowego powoduje niepowodzenie skryptu podczas próby uwierzytelnienia. Ponieważ uwierzytelnianie wieloskładnikowe wymaga interakcji z użytkownikiem, jest niezgodne ze skryptami nieinterakcyjnymi. Oznacza to, że musisz przełączyć się na tożsamość zarządzaną lub jednostkę usługi, z których oba korzystają z uwierzytelniania nieinterakcyjnego.

  • Zagadnienia dotyczące zabezpieczeń: Chociaż uwierzytelnianie wieloskładnikowe dodaje dodatkową warstwę zabezpieczeń, może ograniczyć elastyczność automatyzacji, szczególnie w środowiskach produkcyjnych, w których automatyzacja musi działać bez ręcznej interwencji. Przejście do tożsamości zarządzanych, jednostek usługi lub tożsamości federacyjnych, które są przeznaczone do celów automatyzacji i nie wymagają uwierzytelniania wieloskładnikowego, jest bardziej praktyczne i bezpieczne w takich środowiskach.

Scenariusze wymagające aktualizacji

Poniższa lista zawiera przykładowe scenariusze, w których klienci mogą używać tożsamości użytkownika firmy Microsoft Entra do automatyzacji za pomocą programu Azure PowerShell. Ta lista nie jest wyczerpująca we wszystkich scenariuszach.

Ostrzeżenie

Każdy scenariusz automatyzacji korzystający z tożsamości użytkownika entra firmy Microsoft wymaga aktualizacji.

  • Spersonalizowane lub określone uprawnienia: zadania automatyzacji wymagające uprawnień specyficznych dla użytkownika, takie jak akcje powiązane z rolą osoby lub określone atrybuty identyfikatora Entra firmy Microsoft.

  • Przepływ ROPC protokołu OAuth 2.0: przepływ przyznawania tokenów właściciela zasobu (ROPC) właściciela zasobu OAuth 2.0 jest niezgodny z uwierzytelnianiem wieloskładnikowym. Scenariusze automatyzacji korzystające z uwierzytelniania ROPC kończą się niepowodzeniem, gdy uwierzytelnianie wieloskładnikowe jest wymagane, ponieważ nie można ukończyć uwierzytelniania wielointerakcyjnego.

  • Dostęp do zasobów zewnętrznych do platformy Azure: scenariusze usługi Automation, które wymagają dostępu do zasobów platformy Microsoft 365. Na przykład programy SharePoint, Exchange lub inne usługi w chmurze powiązane z kontem Microsoft pojedynczego użytkownika.

  • Konta usług synchronizowane z usługi Active Directory do identyfikatora entra firmy Microsoft: organizacje korzystające z kont usług synchronizowanych z usługi Active Directory (AD) z identyfikatorem Entra firmy Microsoft. Należy pamiętać, że te konta podlegają również wymaganiom uwierzytelniania wieloskładnikowego i wyzwalają te same problemy co inne tożsamości użytkowników.

  • Kontekst użytkownika na potrzeby inspekcji lub zgodności: przypadki, w których akcje potrzebne do inspekcji na poziomie poszczególnych użytkowników ze względów zgodności.

  • Prosta konfiguracja automatyzacji o małym lub niskim ryzyku: w przypadku zadań automatyzacji o małym lub niskim ryzyku. Na przykład skrypt, który zarządza kilkoma zasobami.

  • Automatyzacja sterowana przez użytkownika w środowiskach nieprodukcyjnych: jeśli automatyzacja jest przeznaczona dla środowisk osobistych lub nieprodukcyjnych, w których indywidualny użytkownik jest odpowiedzialny za zadanie.

  • Automatyzacja w ramach własnej subskrypcji platformy Azure użytkownika: jeśli użytkownik musi zautomatyzować zadania w ramach własnej subskrypcji platformy Azure, w której użytkownik ma już wystarczające uprawnienia.

Przejście do tożsamości zarządzanej lub jednostki usługi jest wymagane w scenariuszach automatyzacji ze względu na obowiązkowe wymuszanie uwierzytelniania wieloskładnikowego dla tożsamości użytkowników firmy Microsoft Entra.

Jak rozpocząć

Aby przeprowadzić migrację skryptów programu Azure PowerShell z używania przy użyciu Connect-AzAccount konta użytkownika i hasła użytkownika ludzkiego identyfikatora firmy Microsoft, wykonaj następujące kroki:

  1. Określ, która tożsamość obciążenia jest dla Ciebie najlepsza.

    • Główna usługa
    • Tożsamość zarządzana
    • Tożsamość federacyjna

  2. Uzyskaj wymagane uprawnienia do utworzenia nowej tożsamości obciążenia lub skontaktuj się z administratorem platformy Azure, aby uzyskać pomoc.

  3. Utwórz tożsamość obciążenia.

  4. Przypisz role do nowej tożsamości. Aby uzyskać więcej informacji na temat przypisań ról platformy Azure, zobacz Kroki przypisywania roli platformy Azure. Aby przypisać role przy użyciu programu Azure PowerShell, zobacz Przypisywanie ról platformy Azure przy użyciu programu Azure PowerShell.

  5. Zaktualizuj skrypty programu Azure PowerShell, aby zalogować się przy użyciu jednostki usługi lub tożsamości zarządzanej.

Kluczowe pojęcia dotyczące jednostki usługi

  • Nieludzkia tożsamość, która może uzyskiwać dostęp do wielu zasobów platformy Azure. Jednostka usługi jest używana przez wiele zasobów platformy Azure i nie jest powiązana z pojedynczym zasobem platformy Azure.
  • W razie potrzeby można zmienić właściwości i poświadczenia jednostki usługi.
  • Idealne rozwiązanie dla aplikacji, które muszą uzyskiwać dostęp do wielu zasobów platformy Azure w różnych subskrypcjach.
  • Uważane za bardziej elastyczne niż tożsamości zarządzane, ale mniej bezpieczne.
  • Często określany jako "obiekt aplikacji" w dzierżawie platformy Azure lub katalogu Microsoft Entra ID.

Aby dowiedzieć się więcej o jednostkach usługi, zobacz:

Aby dowiedzieć się, jak zalogować się do platformy Azure przy użyciu programu Azure PowerShell i jednostki usługi, zobacz Logowanie się do platformy Azure przy użyciu jednostki usługi przy użyciu programu Azure PowerShell

Kluczowe pojęcia dotyczące tożsamości zarządzanej

  • Powiązane z określonym zasobem platformy Azure, dzięki czemu pojedynczy zasób może uzyskiwać dostęp do innych aplikacji platformy Azure.
  • Poświadczenia nie są widoczne dla Ciebie. Platforma Azure obsługuje wpisy tajne, poświadczenia, certyfikaty i klucze.
  • Idealne rozwiązanie dla zasobów platformy Azure, które muszą uzyskiwać dostęp do innych zasobów platformy Azure w ramach jednej subskrypcji.
  • Uważane za mniej elastyczne niż jednostki usługi, ale bezpieczniejsze.
  • Istnieją dwa typy tożsamości zarządzanych:
    • Przypisany system: ten typ jest połączeniem dostępu 1:1 (jeden do jednego) między dwoma zasobami platformy Azure.
    • Przypisany przez użytkownika: ten typ ma relację 1:M (od jednej do wielu), w której tożsamość zarządzana może uzyskiwać dostęp do wielu zasobów platformy Azure.

Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

Aby dowiedzieć się, jak zalogować się do platformy Azure przy użyciu programu Azure PowerShell i tożsamości zarządzanej, zobacz Logowanie się do platformy Azure przy użyciu tożsamości zarządzanej przy użyciu programu Azure PowerShell

Kluczowe pojęcia dotyczące tożsamości federacyjnej

  • Tożsamość federacyjna umożliwia jednostkom usługi (rejestracjom aplikacji) i tożsamościom zarządzanym przypisanym przez użytkownika tokeny zaufania od zewnętrznego dostawcy tożsamości, takiego jak GitHub lub Google.
  • Po utworzeniu relacji zaufania zewnętrzne obciążenie oprogramowania wymienia zaufane tokeny z zewnętrznego dostawcy tożsamości na potrzeby tokenów dostępu z platformy tożsamości firmy Microsoft.
  • Obciążenie oprogramowania używa tego tokenu dostępu w celu uzyskania dostępu do chronionych zasobów firmy Microsoft, do których przydzielono obciążenie.
  • Tożsamości federacyjne są często najlepszym rozwiązaniem w następujących scenariuszach:
    • Obciążenie uruchomione w dowolnym klastrze Kubernetes
    • GitHub Actions
    • Obciążenie uruchomione na platformach obliczeniowych platformy Azure przy użyciu tożsamości aplikacji
    • Google Cloud
    • Amazon Web Services (AWS)
    • Obciążenie uruchomione na platformach obliczeniowych spoza platformy Azure

Aby dowiedzieć się więcej o tożsamościach federacyjnych, zobacz:

Dowiedz się więcej na temat uwierzytelniania wieloskładnikowego

Witryna dokumentacji microsoft Entra ID zawiera więcej szczegółów na temat uwierzytelniania wieloskładnikowego.

Zobacz także

  • Last updated on