Rozbiłem Lustro. Co Teraz Będzie z Moim Kontem AWS? Rozpatrujemy Najczarniejsze Scenariusze

Podobno jeśli zbijesz lustro, czeka Cię 7 lat nieszczęścia. Postanowiłem to przetestować na własnej skórze…

Od lat chowałem w piwnicy niechciane, zapomniane lustro ze szwedzkiego sklepu na „I”. Pewnego dnia coś mnie podkusiło: „Zniszcz je. Sprawdź, jak odmieni to Twoje życie”. Lustro z hukiem przywitało się z posadzką, a ja czekałem na to, co miało nastąpić.

Siedem lat życia w strachu, zaciągnięte żaluzje, przyśpieszone bicie serca…

W międzyczasie odważyłem się założyć konto w Amazon Web Services. Ale byłem przygotowany na najczarniejsze scenariusze. Sytuacje z piekła rodem. Wymyśliłem ich kilka. Oto one:

Admin odszedł do konkurencji

Do tej pory wszystko szło dobrze. Zatrudniłem administratora do swojego konta AWS. Przydzieliłem mu uprawnienia. Początkowo miał być „tylko” Power Userem, ale dobrze mu z oczu patrzyło. Przypisałem mu uprawnienia administratora. Był wszechmogący.

Konkurencja jednak nie śpi. Wszyscy to znamy – kilka telefonów, kilkanaście maili, wcześniejsze wyjścia z pracy i ani się spostrzegłem, jak mojego administratora już ze mną nie było. Zrobił to z dnia na dzień. I nie wiadomo, jakie ma zamiary!

Co robić?

Przede wszystkim nie panikuj.

1. Przejdź do konsoli AWS i wybierz usługę IAM.

2. Wybierz użytkownika, którym posługiwał się Twój administrator:

3. Przejdź do zakładki Security credentials i dezaktywuj Access key ID:

NIE KASUJ TEGO KLUCZA!!!

4. Zmień hasło za pomocą przycisku [Manage]:

Powyższe ustawienia zabezpieczą Cię przed nieuprawnionym dostępem do konsoli AWS oraz poprzez API. Jednak nie do końca…

5. Sprawdź wszystkie zasoby, które nie zostały przez Ciebie stworzone. Zwróć szczególną uwagę na instancje EC2 (także te zatrzymane), obrazy AMI, woluminy EBS oraz ich snapshoty. Jeżeli nie jesteś pewien, do czego dany zasób służy, usuń go.
6. Sprawdź role przydzielone do instancji EC2. Czy wszystkie uprawnienia są im potrzebne? Pamiętaj, że admin może zalogować się na taką maszynę wirtualną i z niej uprzykrzyć Ci życie, jeżeli maszyna będzie miała uprawnienia, które jej na to pozwolą. Kasując zasoby, uważaj, żeby nie usunąć czegoś, co pracuje na produkcji i czego nie da się łatwo i bezpiecznie odtworzyć.

7. W punkcie 3 dezaktywowaliśmy klucz dostępu. Teraz sprawdź, czy wszystkie aplikacje pracują bez problemów. Jeżeli tak, możesz usunąć klucz i utworzyć nowy.

Czy to wystarczy? Tego nie możemy być pewni. W razie wątpliwości możesz skontaktować się z supportem AWS.

*Nie mogę się zalogować na konto AWS!*

Twój były pracownik mógł być jednak bardziej przebiegły i zablokować Ci dostęp do konta. Pozostaje Ci wypełnienie tego formularza i oczekiwanie na pomoc ze strony AWS.

Developer wrzucił klucze na GitHub

Admin adminem, a moja firma nie przestała się rozrastać. Przybywało zamówień. Nowe projekty, nowi pracownicy. Nowi programiści. Czasem pracujemy także z juniorami. Błędy przytrafiają się zresztą każdemu. Chwilę wcześniej zwolniliśmy admina, robota stoi, jeden z developerów dostał spore uprawnienia.

Klient zmienia założenia. Klient chce szybko, dobrze i na wczoraj. Wszyscy się śpieszą. Pracujemy na koncie developerskim, robimy Proof of Concept. Ktoś coś pomylił. No i poszło. A właściwie poszły. Klucze dostępowe developera do konta na GitHub.

Wbrew pozorom zdarza się to dość często.

Co robić?

Jak tylko dowiesz się o takim incydencie, siadaj do konsoli. Nie czekaj ani chwili!

W Internecie pracują boty, które wyszukują takie dane. Twoje konto może zostać „zaatakowane” nawet kilka sekund po fakcie.

1. Ponownie zaloguj się do IAM:

2. Znajdź użytkownika, którego dane wyciekły:

W naszym przypadku chodzi o użytkownika leaked_developer:

3. Wybierz użytkownika i przejdź do jego ustawień bezpieczeństwa:

4. Przy kluczach, które wyciekły, zaznacz opcję Make Inactive:

I już nikt ich nie użyje.

Możesz oczywiście je również skasować oraz utworzyć nowe, dzięki którym developer będzie mógł pracować.

Wszyscy zaglądają do mojego koszyka (S3)

Zdenerwowała mnie ta sytuacja. Zwolniłem wszystkich i sam zacząłem zajmować się całym biznesem. Teraz powinno być dobrze.

Jednak nadmiar obowiązków szybko dał mi się we znaki. Za bardzo zacząłem polegać na tym, że jakoś to będzie. Pewnego słonecznego poranka dostałem od znajomego maila, że pliki z danymi o moich projektach są publicznie dostępne.

JAK TO MOŻLIWE?! Krótkie śledztwo uzmysłowiło mi, że te ściśle tajne dane leżą w jednym z moich koszyków w usłudze S3.

Co robić?

1. Przede wszystkim sprawdź, który bucket jest źródłem „wycieku”. Twoje podejrzenia mogą paść na buckety publiczne, ale to niekoniecznie jest prawda.

2. Po zidentyfikowaniu “sprawcy” wejdź do niego i wybierz zakładkę Permissions. Tutaj możesz zmienić politykę dla całego bucketa i zabezpieczyć się przed wyciekiem danych.

3. Najprościej i najszybciej będzie zastosować politykę, która zabroni wszystkiego wszystkim. Wklej poniższy kod:

 {

    "Version": "2012-10-17",

    "Statement": [

        {

            "Action": "s3:*",

            "Effect": "Deny",

            "Resource": "arn:aws:s3:::leaked-bucket/*",

            "Principal": "*"

        }

    ]

}

Zamień tylko arn na adres swojego koszyka. Jest on widoczny na górze interfejsu:

Pamiętaj też o znakach „/*” na końcu adresu:

"Resource": "arn:aws:s3:::leaked-bucket/*"

Powyższa operacja zabezpieczy Twój bucket. Teraz możesz na spokojnie ustawić odpowiednie uprawnienia. (A jeśli chcesz dowiedzieć się wszystkiego o zabezpieczaniu danych w usłudze S3, zapraszam do przeczytania artykułu na ten temat.)

Ktoś się włamał do mojej EC2

Znowu nieszczęście. Ktoś dostał się do mojej maszyny wirtualnej, na której pracują ważne procesy.

Co robić?

1. Zaloguj się do konsoli AWS i przejdź do serwisu EC2. Wybierz region, w którym znajduje się Twoja Nie usuwaj jej!
2. Wybierz maszynę, która została zaatakowana i zatrzymaj ją:

3. W opisie instancji wyszukaj storage, który jest pod nią podpięty:

4. Kliknij w identyfikator woluminu i po przejściu do listy woluminów wybierz Twój dysk. Wybierz opcję Create Snapshot:

I utwórz snapshot wolumenu:

Jeżeli chcesz, teraz możesz usunąć (terminować) zaatakowaną maszynę.

Po co te wszystkie kroki?

Dlaczego od razu tego nie usunęliśmy maszyny? Dobrze sprawdzić, jak doszło do włamania. Przejrzeć logi. Poprosić specjalistę o pomoc.

Aby bezpiecznie przeanalizować sytuację, najlepiej uruchomić nową maszynę w odizolowanej sieci (VPC). Idealnie w podsieci prywatnej, bez dostępu do Internetu.

1. Utwórz nową maszynę wirtualną i zamontuj do niej wolumin EBS, który będzie utworzony z Twojego snapshota:

2. Gdy maszyna będzie gotowa, możesz podłączyć się do niej z innej instancji, na której możesz umieścić na przykład narzędzie potrzebne do przeprowadzenia śledztwa.

A na sam koniec…

Nie przedstawiłem na pewno wszystkich czarnych scenariuszy, które mogą Cię spotkać przy pracy z chmurami. Pamiętaj jednak, że chmura sama w sobie jest bezpieczna.

Nieważne, czy stłuczesz lustro, czy czarny kot przebiegnie Ci drogę, nawet trzynastego w piątek. Tak naprawdę to Ty jesteś odpowiedzialny za większość spraw związanych z dostępem do naszych zasobów i ich poprawną konfiguracją. Kotów w to lepiej nie mieszać, za to warto pamiętać o Shared Responsibility Model i dobrze żyć z ludźmi. Pomoże to zapobiec przynajmniej części problemów 🙂