Podczas jednego z ostatnich wdrożeń przeprowadziliśmy warsztaty dla klienta, w trakcie których wielokrotnie poruszano temat bezpieczeństwa w chmurze. Nic dziwnego, w końcu jest to jedna z najbardziej kluczowych kwestii dla przedsiębiorstw, które decydują się na migrację do chmury.

W związku z tym, dzisiaj chcieliśmy przybliżyć Wam usługę Identity Access Management, która pomaga zadbać o bezpieczny dostęp do Waszych zasobów.

Usługa AWS Identity Access Management

Identity Access Management (IAM) pozwala na bezpieczne zarządzanie użytkownikami i ich uprawnieniami w AWS. Usługa ta umożliwia między innymi:

• scentralizowaną kontrolę nad kontem AWS,
• przydzielanie granularnych uprawnień użytkownikom i usługom,
• Identity Federation, czyli połączenie zewnętrznych użytkowników (np. Active Directory, Facebook) z naszym kontem,
• wielostopniową autentykację (MFA),
• przydzielanie tymczasowego dostępu dla użytkowników lub urządzeń,
• ustawianie własnej polityki haseł.

IAM jest zintegrowana praktycznie ze wszystkimi usługami w AWS.

Identity Access Management – kluczowe pojęcia

Zanim przejdziemy do szczegółów zarządzania bezpieczeństwem w AWS, warto poznać kilka kluczowych pojęć związanych z pracą z AWS:

• user – użytkownik, czyli człowiek pracujący z usługami,
• group – grupa ludzi posiadająca takie same uprawnienia,
• role – rola, taki użytkownik, tylko nie dla ludzi. Przypinamy ją do usług i zasobów w AWS,
• policy – dokument definiujący uprawnienia.

Czym są polityki IAM (IAM policies)?

Jak wspomniałem wyżej, polityka (policy) to dokument. Dokument napisany w JSON-ie, który definiuje uprawnienia, czyli to, co użytkownik lub grupa może zrobić w AWS. Politykę przypinamy do użytkowników, grup lub ról, które otrzymują zdefiniowane w niej uprawnienia.

Polityka, w przeciwieństwie do większości usług w AWS, dostępna jest globalnie. Raz utworzona, może być używana w każdym regionie.

Gdy tworzymy nowe konto w AWS, zawsze definiowany jest użytkownik root, którego polityka wygląda następująco:

{
     "Version": "2012-10-17",
     "Statement": [
          {
                "Effect": "Allow",
                "Action": "*",
                "Resource": "*"
          }
     ]
}

Deklaracja składa się z trzech kluczy:

• Effect – Allow lub Deny, określa czy uprawnienia są udzielone czy zakazane,
• Action – lista akcji, które polityka pozwala wykonać lub nie,
• Resource – lista zasobów, których dana deklaracja dotyczy.

Jak widać, root może zrobić (”Effect” : „Allow”) wszystko (”Action” : ”*”) z każdą usługą lub zasobem (”Resource” : „*”) w AWS.

Uprawnienia możemy jednak przydzielać o wiele bardziej szczegółowo. Dla przykładu, polityka pozwalająca na odczyt z koszyków S3 będzie wyglądała tak:

{
     "Version": "2012-10-17",
     "Statement": [
          {
                "Effect": "Allow",
                "Action": [
                     "s3:Get*",
                     "s3:List*"
                ],
                "Resource": "*"
          }
     ]
}

W takim dokumencie mogą występować także inne klucze. Na przykład w kluczu Condition możemy określić adres IP, z którego użytkownik musi się połączyć, aby dana zasada bezpieczeństwa mogła mieć zastosowanie.

Pełna lista możliwości to:

• Version – wersja języka, którego używamy w polityce. Najlepiej używać ostatniej dostępnej, „2012-10-17”.
• Statement – Główny element polityki. Może ich być więcej niż jeden. Kontener dla poniższych elementów:
  • Sid – opcjonalny identyfikator,
  • Effect – Allow lub Deny – dajemy bądź odbieramy uprawnienia,
  • Principal – Konto, rola, użytkownik, któremu przypisujemy politykę. Jeżeli tworzymy politykę przypisaną np. do użytkownika lub roli, nie możemy użyć tego klucza.
  • Action – lista czynności (lista metod API), na które pozwalamy lub których zabraniamy,
  • Resource – lista zasobów, których polityka dotyczy,
  • Condition – opcjonalne warunki, po spełnieniu których polityka udziela uprawnień bądź nie.

Sejm, sejmik, rada nadzorcza – rodzaje polityk AWS

Tak jak w życiu mamy różne rodzaje prawa, tak i Amazon pozwala nam na ustanawianie uprawnień na różnych poziomach. Dostępne rodzaje polityk to:

• AWS Managed Policies
• Customer Managed Policies
• Inline Policies

AWS Managed Policies

To polityki tworzone i zarządzane przez Amazona. Są dostępne dla wszystkich i dla każdego są takie same. Co jest ważne? Te polityki mogą się zmienić!!!

Co prawda Amazon na pewno uważa na to, co robi i raczej nie będzie chciał odebrać ważnych uprawnień i spowodować katastrofy, ale trzeba o tym pamiętać. Polityki zarządzane przez Amazona oznaczone są żółtymi sześcianami:

Customer Managed Policies

Są to polityki zarządzane przez nas. Sami je tworzymy, zmieniamy i kasujemy. Przypisujemy je do różnych obiektów (użytkowników i ról) i w ten sposób przydzielamy im uprawnienia.

Inline policies

Te polityki są szczególnie przydatne, gdy chcemy powiązać daną politykę z konkretnym obiektem. Jeżeli na przykład chcemy, aby jakieś uprawnienia należały tylko do jednego użytkownika, to możemy je zdefiniować bezpośrednio bez ryzyka, że ktoś, przez przypadek, przydzieli je komuś innemu.

Przeglądanie polityk

Przeglądając polityki, możemy je wygodnie filtrować w zależności od typu.

Często korzystam z tej opcji.

Po co nam oddzielni użytkownicy w AWS?

Praca na jednym koncie, dodatkowo z pełnymi uprawnieniami, nie jest czymś, co powinniśmy robić. Zawsze należy przydzielać każdemu użytkownikowi tylko takie uprawnienia, których naprawdę potrzebuje, aby wykonać swoją pracę. Amazon tak radzi i naprawdę powinniśmy się tego trzymać. Warto.

Załóżmy więc, że zatrudniliśmy kogoś, kto ma się zajmować naszymi relacyjnymi bazami danych. Administratora naszych usług RDS, który powinien mieć do nich pełny dostęp. Ale raczej tylko do nich. Nie potrzebuje on przecież tworzyć maszyn wirtualnych czy funkcji Lambda.

Powinniśmy mu więc przydzielić pełne (prawdopodobnie) uprawnienia do usługi RDS i… tylko do tego. Jeżeli okaże się, że będzie potrzebował kiedyś dodatkowych uprawnień, zawsze możemy mu je przydzielić.

Pamiętajmy jednak, że mamy szansę na rozwój naszej firmy i w przyszłości będziemy potrzebowali na pewno więcej administratorów dla naszych baz danych. Ale nie chcemy przecież w momencie zatrudnienia drugiego admina RDS robić wszystkiego od nowa. Stworzymy więc grupę dla użytkowników administrujących naszymi bazami danych.

Jak stworzyć grupę IAM?

Przechodzimy do usługi IAM i wybieramy grupy.

Klikamy na [Create New Group].

Wpisujemy nazwę grupy, klikamy [Next Step] i otwiera się ekran, na którym możemy przypisać do naszej grupy politykę z uprawnieniami.

Nie będziemy w tej chwili tworzyli własnej polityki z uprawnieniami, sprawdzimy co oferuje nam Amazon, jeżeli chodzi o uprawnienia do usługi RDS. Przefiltrujmy sobie dostępne polityki:

Jako że mamy do czynienia z administratorem, do którego musimy mieć zaufanie, przydzielamy mu pełne uprawnienia do usługi. Klikamy kilka razy na niebieski przycisk i tworzymy grupę dla naszych administratorów baz danych.

W tej chwili nie mamy żadnego użytkownika. Musimy jakiegoś stworzyć.

Jak stworzyć nowego użytkownika w AWS?

Tym razem przechodzimy w menu do Users, klikamy Add user i wypełniamy niezbędne dane:

Na następnym ekranie mamy możliwość przydzielenia naszemu nowemu użytkownikowi uprawnień.

Jak widać, możemy dodać użytkownika do grupy, skopiować uprawnienia od innego użytkownika lub przypisać bezpośrednio istniejącą politykę.

My dodamy naszego nowego administratora do grupy RDSAdministrators. Zaznaczamy pole wyboru przy wybranej grupie, klikamy dwa razy [Next] i gotowe!

Najpierw testy!

Zanim prześlemy nowe poświadczenia naszemu nowemu pracownikowi, sprawdźmy, co tak naprawdę będzie mógł zrobić dzięki nadanym uprawnieniom.

Zalogujmy się na jego konto i poklikamy trochę po różnych usługach.

Spróbujmy na przykład utworzyć nową kolejkę w usłudze SQS:

O to chodziło!

Dla pewności możemy sprawdzić inne usługi, a na koniec przejdźmy do RDS i zobaczmy, czy uda się utworzyć nową instancję MySQL na naszym koncie.

Kilka minut później widzimy, że wszystko poszło dobrze.

Jeden do zera dla nas.

Tworzenie nowej polityki

Czas mija. Zatrudniliśmy drugiego administratora baz danych, rozpoczęliśmy realizację projektów dla klientów zewnętrznych. Nasza firma dostała prośbę o wykonanie wyceny nowej usługi, która związana jest z bazami danych. Cała dokumentacja do tego projektu leży w koszyku S3, a nasz administrator musi się z nią zapoznać. Musimy mu więc pozwolić na dostęp do tych dokumentów.

Nie możemy jednak dać mu dostępu do całej usługi S3. W niektórych bucketach są przecież tajne dane odnośnie innego projektu, dotyczącego naszego planowanego lotu w kosmos 😉 Nie chcemy także, aby niedawno zatrudniony drugi admin miał do niego dostęp. Jest jeszcze na okresie próbnym.

Przy naszych założeniach nie możemy dodać kolejnej gotowej polityki do grupy administratorów baz danych. Musimy utworzyć nową politykę i przypisać ją użytkownikowi.

Zmieniamy uprawnienia

Przechodzimy więc do naszego użytkownika i klikamy przycisk [Add permissions], aby zarządzać jego uprawnieniami.

Chcemy podpiąć bezpośrednio politykę, która będzie pozwalała na dostęp do koszyka o nazwie secret-docs. Wybieramy więc Attach existing policies directly i Create policy. Tworzymy politykę dla naszego admina w postaci:

{
     "Version": "2012-10-17",
     "Statement": [
          {
                "Effect": "Allow",
                "Action": [
                     "s3:GetObject",
                     "s3:ListBucket"
                ],
                "Resource": [
                     "arn:aws:s3:::secret-docs/*",
                     "arn:aws:s3:::secret-docs"
                ]
          },
          {
                "Effect": "Allow",
                "Action": "s3:ListAllMyBuckets",
                "Resource": "*"
          }
     ]
}

Nazywamy ją np.: RDSAdmin1-secret-docs-policy i dodajemy do użytkownika.

Poza dostępem do naszego tajnego koszyka, dodaliśmy także możliwość wylistowania wszystkich bucketów:

          {
                "Effect": "Allow",
                "Action": "s3:ListAllMyBuckets",
                "Resource": "*"
          }

Czy jest to konieczne? Nie.

Bez tej deklaracji nasz administrator baz danych nie mógłby wejść po prostu do koszyka poprzez listę. Musielibyśmy podać mu bezpośredni adres URL bucketa, np.: https://s3.console.aws.amazon.com/s3/buckets/secret-docs/ .

W tym momencie nasz administrator poza dostępem do baz danych ma także możliwość zapoznania się z dokumentacją do naszego projektu.

Jak widać, przynależność do grupy i bezpośrednio dodana polityka w niczym sobie nie przeszkadzają. Przynajmniej w tym przypadku 🙂

Polityki dla zasobów

Dość często zastosowanie polityk IAM jest nieefektywne lub nawet niemożliwe.

Załóżmy, że mamy setki użytkowników, dziesiątki grup i ról. Dodajemy bucket S3 i edytujemy uprawnienia dla każdego? Pracochłonne. Ponadto wielkość polityk dla użytkowników, grup i ról jest ograniczona. Nie możemy rozbudowywać ich w nieskończoność.

Tu z pomocą przychodzą Resource policies. Pisałem już o nich jakiś czas temu w związku z bezpieczeństwem danych w S3. W skrócie są to polityki, które określają, kto może wykonać jakie działania na obiekcie lub zasobie, do którego są podpięte.

Jaka jest różnica w stosunku do IAM Policies? Wyobraźmy sobie, że wchodzimy jako użytkownik do restauracji. Politykę IAM będziemy trzymali na kartce w kieszeni i na tej kartce będzie napisane, co możemy, a czego nie możemy zjeść. Drugi rodzaj polityki to będą kartki przypięte do poszczególnych potraw. Na każdej z takich kartek będzie wyszczególnione, kto może, a kto nie może danej potrawy zjeść.

Wróćmy do naszego przykładu z administratorem baz danych i koszykiem S3. Pamiętamy, że admin ma mieć dostęp tylko do tego koszyka i do dokumentów w nim zawartych. Zamiast dodawać uprawnienia bezpośrednio dla użytkownika, możemy więc stworzyć odpowiednią politykę dla naszego koszyka, w której określimy, kto i co może z nim zrobić.

Do stworzenia polityki zasobów wygodnie jest użyć generatora. Znajdziemy go w zakładce Bucket policies dla naszego koszyka. Wpisujemy ARN naszego użytkownika jako Principal i ANR bucketu jako Resource.

Wybieramy uprawnienia, które chcemy przydzielić i możemy wygenerować politykę. Musimy ją niestety sami przekleić w docelowe miejsce, generator nie jest podłączony bezpośrednio pod ekran, na którym określamy politykę dla koszyka.

Niestety wygenerowany JSON nie jest do końca poprawny i nie uda nam się zapisać naszych zmian bez wprowadzenia drobnej poprawki:

Zamiast:

"Resource": "arn:aws:s3:::secret-docs",

Powinno być:

"Resource": "arn:aws:s3:::secret-docs/*",

Trzeba o tym pamiętać.

W ten sposób pozwoliliśmy naszemu użytkownikowi na pobieranie plików z koszyka, nie zmieniając jego bezpośrednich uprawnień.

Polityki, wybory, konflikty…

Mamy więc dwa rodzaje polityk. W S3 dochodzą jeszcze Access Listy na poziomie plików. Co się zatem stanie, jeżeli jedna polityka będzie nam pozwalała na daną operację, a druga nie? Dobre pytanie.

Spróbujcie w naszej polityce przypiętej do koszyka…

{
     "Id": "Policy1531734719694",
     "Version": "2012-10-17",
     "Statement": [
          {
                "Sid": "Stmt1531734689872",
                "Action": [
                     "s3:GetObject"
                ],
                "Effect": "Allow",
                "Resource": "arn:aws:s3:::secret-docs/*",
                "Principal": {
                     "AWS": [
                          "arn:aws:iam::094104221953:user/RDSAdmin1"
                     ]
                }
          }
     ]
}

zmienić linię:

"Effect": "Allow",

na

"Effect": "Deny",

Jeżeli robicie wszystko tak jak ja, to w tym momencie polityka dla administratora baz danych będzie pozwalała mu na pobranie pliku, a polityka dla koszyka będzie mu tego zabraniała. I co?

I nie pobierze pliku.

Jak to działa? Zrozumienie tego nie jest trudne. Ale za to bardzo ważne.

Ewaluacja uprawnień polityk IAM

Proces ewaluacji uprawnień w naszym przypadku wygląda następująco:

1. Domyślnie każda decyzja to Deny. Użytkownik nie ma uprawnień do zasobu.
2. Wszystkie polityki łączone są w całość. Coś jak Union all w języku SQL.
3. Jeżeli gdziekolwiek występuje wyraźne Deny, użytkownik nie ma prawa do zasobu.
4. Jeżeli gdziekolwiek występuje wyraźne Allow użytkownik ma prawo do zasobu.
5. Użytkownik nie ma prawa do zasobu, ponieważ tak jest domyślnie.

Czasem nawet w jednej polityce możemy mieć przeczące sobie wpisy. Niezależnie od przypadku, zawsze górę weźmie wyraźnie wyspecyfikowane Deny.

Przykłady

Mamy dwa dokumenty. Dla S3:

{
  "Version": "2012-10-17",
  "Statement": [
     {
       "Action": [
          "s3:DeleteObject"
       ],
       "Effect": "Deny",
       "Resource": "arn:aws:s3:::secret-docs/*",
       "Principal": {
          "AWS": [
            "arn:aws:iam::094104221953:user/S3User"
          ]
       }
     }
  ]
}

i dla użytkownika S3User

{
     "Version": "2012-10-17",
     "Statement": [
          {
                "Effect": "Allow",
                "Action": "s3:*",
                "Resource": "*"
          }
     ]
}

Użytkownik ma pełne prawa do bucketów S3 oraz do plików w nich umieszczonych. Jednocześnie polityka dla koszyka secret-docs zakazuje mu kasowania plików w tym koszyku. Będzie on więc mógł zrobić wszystko we wszystkich koszykach, poza kasowaniem plików w tym koszyku.

O ile… użytkownik sam nie zmieni polityk, do czego ma uprawnienia.

I ponownie. Dla S3 mamy:

{
  "Version": "2012-10-17",
  "Statement": [
     {
       "Action": [
          "s3:PutObject"
       ],
       "Effect": "Allow",
       "Resource": "arn:aws:s3:::secret-docs",
       "Principal": {
          "AWS": [
            "arn:aws:iam::094104221953:user/S3User"
          ]
       }
     },
     {
       "Sid": "Stmt1531745706400",
       "Action": [
          "s3:DeleteObject"
       ],
       "Effect": "Deny",
       "Resource": "arn:aws:s3:::secret-docs",
       "Principal": {
          "AWS": [
            "arn:aws:iam::094104221953:user/S3User"
          ]
       }
     }
  ]
}

a dla naszego użytkownika:

{
     "Version": "2012-10-17",
     "Statement": [
          {
                "Effect": "Allow",
                "Action": [
                     "s3:DeleteObject",
                     "s3:GetObject"
                ],
                "Resource": "*"
          }
     ]
}

Przyjrzyjmy się obu politykom. Po przejściu przez zasady zawarte w obu dokumentach widać, że S3User będzie mógł do naszego koszyka zapisywać pliki. Będzie je także mógł odczytywać. Nie będzie jednak mógł ich kasować. Deny z polityki dla koszyka jest ważniejsze niż allow z uprawnień S3User.

Ograniczone zaufanie, bezpieczna chmura

Zabezpieczenie dostępu do danych i ich ochrona to jeden z najważniejszych aspektów korzystania z rozwiązań w chmurze. Dostawcy chmury dokładają wszelkich starań, aby zapewnić poziom bezpieczeństwa porównywalny lub przewyższający ten w tradycyjnych centrach danych. Jednak tak jak w wypadku tradycyjnych rozwiązań, i w chmurze część odpowiedzialności za bezpieczeństwo spoczywa na naszych barkach. Dlatego tak istotne jest, aby zrozumieć mechanizmy działania usług związanych z dostępem i bezpieczeństwem i nauczyć się mądrze nimi zarządzać.

Jedna z najważniejszych zasad, jaką należy się tutaj kierować, to przydzielanie jak najmniejszych uprawnień. Dajmy użytkownikom tylko tyle władzy, ile naprawdę potrzebują, żeby wykonywać swoje obowiązki. Oni będą wdzięczni za jasno zdefiniowane zadania, a my nie będziemy się martwić, że nasze dane wpadną w niepowołane ręce.