Amazon Web Services on BigDataPassion

Poświadczenia i ogólne zasady bezpieczeństwa w AWS - wstęp

Fri, 19 Jul 2019 00:00:00 +0000

Poświadczenie

Poświadczenie to pewien zestaw uprawnień obiektu, który legitymuje się przy dostępie do wybranych zasobów. Najprostszy scenariusz to przypisanie pewnemu użytkownikowi takich uprawnień, które pozwolą mu wykonać pewne operacje na pewnych zasobach.

Poświadczenia bezpieczeństwa w AWS

Dla możliwości zarządzania Amazon Web Services należy uwierzytelnić się za pomocą:

nazwa użytkownika i hasło (do konsoli zarządzania)
klucze dostępu do AWS API lub AWS CLI

Pierwsza metoda jest dostępna przy pierwszym logowaniu. Po poprawnym zalogowaniu można rozpocząć zabezpieczanie konta i używać innych sposobów logowania. Prócz wspomnianego wyżej pierwszego sposobu (e-mail/hasło) istnieje też dostęp po kluczach do interfejsu zarządzania. Wygenerowane klucze moża dopisać do konfiguracji takich narzędzi jak np. Ansible (wraz z boto/boto2/boto3), dzięki czemu powstaje fajnie zautomatyzowane całe środowisko :).

Przykładem dla Ansible może być zakładanie nowej instancji EC2 za pomocą poniższego playbooka:

- ec2:
    key_name: marcin_gnulinux_public_key
    instance_type: t2.micro
    image: ami-numerek
    group: webserver
    wait: yes
    count: 4
    vpc_subnet_id: subnet-319fc37a
    assign_public_ip: yes

Należy zwrócić uwagę na dbałość tzn. o bezpieczne przetrzymywanie kluczy, jeśli zapomni się lub straci dane uwierzytelniające, nie można ich już odzyskać. Nie można ich odzyskać, ale można je ponownie wygenerować :).

Poświadczenie użytkownika root konta AWS jest inne niż uzyskanie poświadczenia użytkownika IAM.

dla konta root uzyskasz poświadczenia z Security Credentials w AWS Management Console
dla kont IAM uzyskasz poświadczenia z IAM

Typy poświadczeń

Adres e-mail i hasło

Tożsamość tworzona jest przy pierwszym dostępie do konsoli AWS - podczas tworzenia konta. Tożsamość ma pełny dostęp do wszystkich usług AWS i zasobów na koncie. Nosi nazwę Root User.

Zalecane jest nie używanie tego konta do prac administracyjnych na co dzień. Do tego celu należy utworzyć nowe konto z uprawnieniami administratora w IAM (Identity and Access Management). Po utworzeniu nowego użytkownika należy zabezpieczyć konto root tak, aby korzystać z niego tylko w zarządzaniu kontem i usługami.

Użytkownik root posiada najwyższy poziom dokonywania zmian na koncie AWS:

Zarządzanie Root User
Zmiana planu AWS
Edycja sposobów płatności
Sprawdzanie bilingu
Zgłaszanie zapytań dot. finansów
Wyłączenie konta
Logowanie do GovCloud
Konfiguracja Reverse DNS dla EC2
Tworzenie pary kluczy CloudFront
Zmiana ID dla instancji EC2
Konfiguracja MFA dla koszyków S3
Edycja/usuwanie koszyków S3 dla VPC ID lub VPC endpoint ID
Żądanie przeprowadzenia pentestów
Wyłączenie ograniczenia ruchu na 25/tcp dla EC2
Pokazanie w kanonicznej postaci nasz ID
Przywracanie uprawnień użytkownika IAM
Zmiana danych kontaktowych, waluty

Ciekawe jest, że jako nie-root (jako użytkownik IAM) też można zażądać przeprowadzenie testów penetracyjnych, ale za pomocą e-maila. Konto root potrafi to zrobić dodatkowo za pomocą web form.

Użytkownicy IAM podają swoje nazwy użytkowników i hasła, gdy logują się do:

konsoli AWS Management Console
forum dyskusyjnego AWS
centrum wsparcia AWS

W niektórych przypadkach nazwa użytkownika i hasło IAM są wymagane do korzystania z usługi, takiej jak wysyłanie wiadomości e-mail za pomocą SMTP za pomocą usługi Amazon Simple Email Service (Amazon SES).

Użytkownik IAM nie może dokonać zmiany hasła, chyba że otrzymał poświadczenia.

Multi-Factor Authentication (MFA)

Wieloetapowe uwierzytelnianie (MFA) zapewnia dodatkowy poziom bezpieczeństwa, który można zastosować (dodać) do konta AWS. Aby zapewnić dodatkowe bezpieczeństwo, zaleca się wymaganie dostępu MFA do poświadczeń użytkownika root konta AWS i wysoce uprzywilejowanych użytkowników IAM.

Po włączeniu MFA, po zalogowaniu się na stronie AWS pojawi się monit o podanie nazwy użytkownika i hasła oraz kodu uwierzytelniającego z urządzenia MFA co zapewnia większe bezpieczeństwo ustawień konta AWS i zasobów. Domyślnie MFA nie jest włączone.

Limit na ilość urządzeń MFA na dla użytkownika IAM i konto root wynosi: 1

Access Keys (Access Key ID and Secret Access Key)

Klucze dostępu składają się z dwóch części:

identyfikator klucza dostępu (na przykład AKIAIOSFODNN7EXAMPLE)
tajny klucz dostępu (na przykład wJalrXUtnFEMI / K7MDENG / bPxRfiCYEXAMPLEKEY)

Używamy ich do:

podpisywania żądań programowych komend AWS CLI (używając SDK)
autoryzacji przy korzystaniu z interfejsu AWS API

Do Uwierzytelnienia żądań należy użyć:

identyfikatora klucza dostępu
tajnego klucza dostępu

Podczas tworzenia kluczy dostępu tworzymy zestaw składający się z:

identyfikator klucza dostępu
tajny klucz dostępu

Tylko przy tworzeniu mamy możliwość pobrania części klucza dostępu (tajnego klucza dostępu). Nie ma możliwości ponownego zobaczenia tych danych, wtedy należy ponownie wygenerować zestaw kluczy dostępu.

W przypadku zagubienia tych informacji też tworzymy ponownie zestaw kluczy. Nowo utworzony klucz ma status aktywny tj. można z niego korzystać a więc posługiwać się nim w komunikacji z AWS API lub za pomocą AWS CLI.

Dla głównego użytkownika root można przypisać maksymalnie dwa klucze. Nawet wyłączony (nieaktywny) klucz wlicza się do limitu.

Istnieją tymczasowe klucze dostępu - tymczasowe poświadczenia bezpieczeństwa. Oprócz identyfikatora klucza dostępu i tajnego klucza dostępu tymczasowe poświadczenia bezpieczeństwa obejmują token bezpieczeństwa, który należy wysłać do AWS podczas korzystania z tymczasowych poświadczeń bezpieczeństwa.

Zaletą tymczasowych poświadczeń bezpieczeństwa jest to, że są one krótkoterminowe. Po wygaśnięciu nie są już ważne. Można używać tymczasowych kluczy dostępu w mniej bezpiecznych środowiskach lub rozpowszechniać je, aby zapewnić użytkownikom tymczasowy dostęp do zasobów na koncie AWS.

Key Pairs

Pary kluczy nie są powiązane z kluczami dostępu. Składają się z klucza publicznego i klucza prywatnego.

Do utworzenia podpisu cyfrowego używamy klucza prywatnego, a następnie AWS używa odpowiedniego klucza publicznego do sprawdzenia poprawności podpisu.

Pary kluczy są używane tylko dla:

Amazon EC2
Amazon CloudFront

Dla EC2 używamy do dostępu do instancji po SSH.

Dla CloudFront do tworzenia podpisanych adresów URL dla treści prywatnych. Dla przykładu gdy chcemy rozpowszechniać treść, za którą ktoś zapłacił.

AWS nie udostępnia par kluczy dla naszego konta - musimy je stworzyć. Tylko użytkownik root konta AWS może tworzyć pary kluczy CloudFront.

Testowy klaster obliczeniowy - Amazon Web Services i CentOS 7

Tue, 20 Jun 2017 12:59:11 +0200

Publiczne chmury obliczeniowe cieszą się coraz większym zainteresowaniem. Jedną z najbardziej popularnych rozwiązań tego typu jest zdecydowanie Amazon Web Services. W poniższym krótkim tutorialu pokażę jak szybko zbudować mini klaster testowy do zastosowań Big Data, na którym będziemy mogli wdrożyć na przykład platformę HDP (instalacji poświęcony został inny tutorial).

Założenie konta

Nasz proces musimy zacząć od założenia konta w serwisie (https://aws.amazon.com/console/) wybierając opcję “Sign in to the Console” a następnie wybranie opcji “I am a new user” i wypełnienie formularza.

Rejestracja jest dość prosta, jedynym utrudnieniem może się okazać konieczność podania karty kredytowej z której będą dokonywane płatności za comiesięczny rachunek około trzeciego dnia następnego miesiąca. Dodatkowo w momencie rejestracji, w celu potwierdzenia karty kredytowej, zostanie pobrana opłata w wysokości jednego dolara.

Planowanie kosztów

Amazon udostępnia możliwość tworzenia maszyn na życzenie (on demand) za które płacimy zgodnie z wykorzystaniem (płatność za godzinę użycia). Aktualny cennik możemy znaleźć pod adresem: https://aws.amazon.com/ec2/pricing/on-demand/. Należy zwrócić uwagę, że ceny zależą od lokalizacji w której będziemy tworzyć maszyny (najtaniej jest w USA, np. Oregon lub Virginia) oraz dostępność wersji maszyn także zależy od kolokacji. Dla przykładu za maszynę m4.xlarge (4 CPU, 16 GB RAM) w Oregon zapłacimy 0.2 $ za godzinę użycia (włącozna maszyna). Dodatkowo naliczane są ceny za wykorzystane powierzchnie dyskowe. Całość naszego wdrożenia, najlepiej sprawdzić za pomocą kalkulatora: https://calculator.s3.amazonaws.com/index.html wybierając w zakładce EC2 odpowiednie maszyny, ich ilość i planowane wykorzystanie przestrzeni dyskowej.

Tworzenie klastra maszyn na AWS

Poniżej kolejne kroki w celu uzyskania kompletnego klastra obliczeniowego na Amazon Web Services.

Całość zaczynamy od wejścia na stronę: https://console.aws.amazon.com/console/ a następnie z menu usług wybieramy “EC2”. Powinniśmy zobaczyć ekran jak niżej:

Na górze widzimy podsumowanie statusu w ramach aktualnie wybranej lokalizacji którą możemy zmienić w prawym górnych rogu (w moim przypadku jest to Virginia w USA).

Jeśli klikniemy menu “Running Instances” zobaczymy listę maszyn dostępnych w tej lokalizacji (w tym przypadku pustą).

Aby stworzyć nowe maszyny klikamy “Launch Instances”. W wyniku dostajemy listę obrazów systemów do załadowania.

W prezentowanej liście brakuje systemu CentOS którego chcemy użyć, dlatego skorzystamy z marketu (AWS Marketplace w menu po lewej) i wbudowanej wyszukiwarki. Wybieramy interesującą nas wersję i klikamy “Select”

Po wybraniu odpowiedniego obrazu otrzymujemy jego podsumowanie. Warto przejrzeć zawarte tam informacje, gdyż możemy się dowiedzieć na przykład jak będzie się nazywał domyślny użytkownik na którego mamy się połączyć po SSH oraz czy obraz jest płatny

Następnie przechodzimy do wybrania typu maszyny. Do naszego klastra testowego skorzystamy z maszyn typu “m4.xlarge” (4 CPU, 16GB RAM)

W kolejnym oknie możemy zdefiniować liczbę maszyn wybranego typu oraz ustawić dodatkowe opcj. Ustawiam 7 maszyn

W następnym oknie definiujemy przestrzeń dyskową dla naszych maszyn. W poniższym przykładzie wybrałem dyski magnetyczne o pojemności 100 GB

Kolejny krok możemy pominąć, umożliwia on dodanie dodatkowych tagów do maszyn

AWS promuje wykorzystanie droższych dysków SSD, więc musimy potwierdzić swój wybór dysków HDD (lub wybrać jednak dyski SSD)

W kolejnym kroku definiujemy konfigurację zabezpieczeń (firewall) poprzez stworzenie nowej grupy. Z racji tworzenia klastra testowego otworzę cały ruch do tych maszyn (uwaga, w żadnym wypadku nie należy tego robić produkcyjnie, gdyż każdy będzie miał dostęp do naszych maszyn i usług na wszystkich portach)

W ostatnim kroku dostajemy podsumowanie naszej stworzonej konfiguracji wraz z ostrzeżeniem że nasza konfiguracja będzie płatna (przez pierwszy rok korzystania z AWS dostajemy tak zwany “free tier” czyli pewien limit użycia za który nie musimy płacić). Klikamy “Launch” by potwierdzić naszą konfigurację.

Domyślny użytkownik systemów na AWS nie ma możliwości logowania się hasłem, dlatego w kolejnym kroku jesteśmy proszeni o stworzenie odpowiedniego klucza który posłuży nam do zalogowania się na niego. Ten klucz musimy zapisać na swoim komputerze oraz nikomu go nie udostępniać.

Ostatecznie tworzą się nasze maszyny

i na koniec dostajemy podsumowanie

Klikając “View Instances” możemy zobaczyć listę naszych maszyn