AWS IAM - Identity-based i Resource-based policy


Kontynuując zagadenia dotyczące definiowania policy w serwisie AWS Identity and Access Management (IAM) skupimy się na dwóch sposobach określania uprawnień dostępu do zasobu. W zależoności od tego, do kogo lub do czgo przypisujemy policy wyróżniamy Identity-based policy oraz Resource-based policy. W pierwszym przypadku użytkownik, któremu jest przydzielone Identity-based policy ma prawo wykonać wyszczególnione akacje na określonych zasobach. Z kolei przypisując Resource-based policy do zasobu określamy, którzy użytkownicy mogą z danego zasobu skorzystać.

Na potrzeby dalszego wywodu załóżmy, że w ramach konta AWS mamy zdefiowane następujące obiekty: * kubełek S3 o nazwie moje-dokumenty, * funkcja Lambda o nazwie pobierz-plik, * użytkownicy IAM: Tomek oraz Magda.

Identity-based policy

Identity-based policy przypisujemy do użytkownika lub roli, by wskazać że mają uprawnienia do wykonania pewnej akcji na określonym zasobie. Przykładami tego typu policy byłaby zgoda na uruchomienie funkcji pobierz-pliki przez użytkownika Tomek albo odczytanie dodanie pliku do kubełka moje-dokumenty przez użytkownika Magda.

Przykład: Zgoda na wywołanie funkcji pobierz-pliki

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "UruchomFunkcje",
            "Effect": "Allow",
            "Action": "lambda:InvokeFunction",
            "Resource": "arn:aws:lambda:::function:pobierz-pliki"
        }
    ]
}

Przykład: Zgoda na dodanie pliku do kubełka moje-dokumenty

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DodajPlik",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::moje-dokumenty"
        }
    ]
}

Resource-based policy

W zależoności od wymagań Resource-based policy może okazać się lepszym wyborem niż Identity-based. Najlepszą analogią dla tego sposobu określania uprawnień będą czarne i białe listy, w których domyślnie wszystko jest zakazane i wskazujemy jawnie co jest dozwolone (biała lista) lub wszystko jest dozwolone i jawnie zakazujemy określonych akcji. W serwisach AWS koncepcja białej listy będzie bardziej naturalna w związku z tym, że domyślnie wszystko jest zakazane. Drugą okolicznością, która powoduje, że powinniśmy rozważyć ten typ policy jest udostępnianie zasobów między różnymi kontami. Stosowanie Resource-based policy jest ograniczone do określonych serwisów.

Definicje Resource-based policy jest co do zasady bardzo zbliżona do Identity-based. Określamy dozwolonę akcję i identyfikator zasobu, a dodoatkowo określamy, jakie obiekty (użytkownicy, role) mogą akcję wykonać.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DodajPlik",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::moje-dokumenty",
            "Principal": {"AWS": "arn:aws:iam::11112222333:user/Tomek"}
        }
    ]
}

W powyższym przykładzie użytkownik Tomek (uwag wielkość liter jest istotna - w ramach konta mogą istnieć trzej różni użytkownicy o nazwie Tomek, tomek i TOMEK) zdefiniowany w ramach konta 111122223333 ma zgodę na dodawanie obiektów do kubełka moje-dokumenty.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DodajPlik",
            "Effect": "Allow",
            "Action": "lambda:InvokeFunction",
            "Resource": "arn:aws:lambda:::function:pobierz-pliki",
            "Principal": {"AWS": ["arn:aws:iam::11112222333:root", "123412341234"}
        }
    ]
}

W drugim przykładzie użytkownicy zdefiniowani w kontach 11112222333 i 123412341234 mają prawo wywołać funkcję Lambda pobierz-pliki. Użyliśmy tutaj dwa różne sposoby określania konta AWS - pełnym identyfikatorem ARN i skrócony, w którym podaje się tylko numer konta.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DodajPlik",
            "Effect": "Allow",
            "Action": "lambda:InvokeFunction",
            "Resource": "arn:aws:lambda:::function:pobierz-pliki",
            "Principal": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

W kolejnym przykładzie zezwalamy na wywołanie funkcji wszystkim użytkownikom pod warunkiem, że są zalogowani przy pomocy metody dwuskładnikowej.

Podsumowanie

Zastosowanie każdego z typu zależy od przypadku, który musimy rozwiązać. Dla jednego zasobu można stosować zarówno jeden jak i drugi typ, ale w takim przypadku trzeba pamiętać, że jeżeli policy zdefiniowane dla zasobu i policy zdefiniowane dla użytkownika się wykluczają (jedno pozwala na wykonanie akcji a drugie zabrania), to dostęp do zasobu zostanie zabroniony.

Zobacz też