Czy można wymagać włączenia uwierzytelniania wieloskładnikowego (MFA) dla określonych / wszystkich kont IAM w Amazon Web Services?
Istnieją opcje wymagań dotyczących hasła i jasne jest, w jaki sposób można je dodać do swojego konta, ale nie jest jasne, czy istnieje opcja zmuszenia użytkowników do posiadania MFA.
Odpowiedzi:
Odpowiedź brzmi: tak, jest. Za pomocą warunku. Na przykład dla kont administratora:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition":
{
"Null":{"aws:MultiFactorAuthAge":"false"}
}
}
]
}Wymusi MFA zarówno dla uwierzytelnienia hasłem, jak i uwierzytelnienia opartego na tokenach za pomocą interfejsu API.
Po krótkim rozejrzeniu się wydaje się, że odpowiedź brzmi „w pewnym sensie”. W IAM administrator może skonfigurować MFA dla innego użytkownika IAM. Chociaż może to być nieco trudne, jeśli konfigurujesz wirtualne MSZ, jest to możliwe. Następnie, jeśli użytkownik nie uzyskał uprawnień do aktualizacji / usuwania swojego MFA, jest to skutecznie wymagane.
Chociaż nie określiłem jeszcze pełnej listy działań, których należy odmówić (lub po prostu nie przyznać), ten post wydaje się zawierać informacje i zaktualizuję tę odpowiedź po jej przetestowaniu.
[Aktualizacja]
Byłem w stanie skonfigurować użytkowników jako zaawansowanych użytkowników (tym samym nie przyznając im dostępu do funkcji IAM, chociaż jestem pewien, że możesz uzyskać bardziej szczegółowy) i zaimplementować z nimi ich MFA. Przy użyciu tej metodologii nie będą mogli jej wyłączyć.
Tak, możesz wymagać MFA dla kont IAM zarówno dla konsoli internetowej, jak i awscliwiersza poleceń. W rzeczywistości nie jest możliwe niezawodne wymaganie MFA dla konsoli internetowej, nie wymagając go w awscliwierszu poleceń, ponieważ oba uderzają w te same interfejsy API. Mówię „niezawodnie”, ponieważ przy złożonej polityce IAM możliwe jest zezwolenie na niektóre awsclioperacje bez MFA przy wymuszaniu MFA dla konsoli internetowej. Jednak wyniki są nieco nieprzewidywalne, a poza tym klucze IAM są równie, jeśli nie bardziej niebezpieczne, niezabezpieczone. Radzę, aby wymagać tego od obu, a następnie być może stworzyć niechronione klucze do specjalnych zastosowań, w których MFA jest absolutnie przeciwwskazane. W przypadku procesów zautomatyzowanych role byłyby ogólnie lepszym wyborem.
Aby ułatwić operacje MFA w wierszu poleceń, stworzyłem zestaw skryptów bash i dokładnie spreparowany przykład zasad egzekwowania MFA, które ułatwiają dołączanie / odłączanie vMFAd oraz uruchamianie i zarządzanie sesjami MFA. Działają na wariantach macOS i Linux, ale prawdopodobnie nie na Windows (nie testowane).
Najwyraźniej nie. Wygląda na to, że MFA dla kont IAM jest opcjonalny, chociaż najlepiej posta się na forach wsparcia AWS, by uzyskać wiarygodną odpowiedź.
Udokumentowaliśmy kilka uwag dotyczących wieloskładnikowego interfejsu API AWS ogólnie (gdzie dodać warunki, jakie są implikacje itp.) W dokumentacji niektórych niestandardowych narzędzi ( https://github.com/kreuzwerker/awsu ) opracowanych do korzystania z Yubikeys jako źródło tokenów TOTP. Dzięki temu praca z rolami i poświadczeniami długoterminowymi + tokeny sesji jest bardzo łatwa.
Przyjęta odpowiedź nie jest już ważna AFAICT. AWS udokumentował, jak to zrobić, w swoim artykule z samouczka:
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html
Śledziłem to w przypadku mojego nowego konta i zespołu AWS i działało to świetnie.