Artykuł ukazał się pierwotnie na blogu Chmurowiska.

Podobno, jeżeli zbijesz lustro, czeka Cię 7 lat nieszczęść. Z drugiej strony, też podobno, na każdy zły znak gwiazdy mają swój sposób. Postanowiłem to sprawdzić…

Długo miałem takie jedno, niechciane przez nikogo lustro ze szwedzkiego sklepu i nagle dostałem znak: „Zniszcz je. Sprawdź jak to odmieni Twoje życie”. Taki znak to nie przelewki, więc nie oponowałem i lustro wylądowało na twardej podłodze. Lustro zniknęło, kawałki lustra wylądowały w śmietniku, a ja czekałem. Na co? Na to co miało nastąpić.

Siedem lat strachu, zaciągnięte żaluzje, przyśpieszone bicie serca gdy usłyszałem odgłos kroków na schodach.

I nic. Cały czas żyję.

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

Odszedł admin

Wszystko szło dobrze. Zatrudniłem administratora do swojego konta. Przydzieliłem mu uprawnienia. Początkowo mial być „tylko” Power Userem, ale dobrze mu z oczu patrzyło. Przypisałem do niego uprawnienia administratora. Był wszechmogący.

Konkurencja jadnak nie spała. Najprawdopodobniej kilka telefonów, kilkanaście maili, może jakieś spotkania i mój administrator odszedł. Z dnia na dzień. I nie wiadomo jakie ma zamiary.

Co robić?

Przede wszystkim nie panikować.

1. Siadamy do konsoli AWS i przechodzimy do usługi IAM.

2. Wybieramy użytkownika, którym posługiwał się nasz administrator.

3. Przechodzimy do zakładki Security credentials i dezaktywujemy Access key ID

NIE KASUJEMY TEGO KLUCZA!!!

4. Zmieniamy hasło

W tym momencie jesteśmy zabezpieczenie przed nieuprawnionym dostępem do konsoli AWS oraz poprzez API.

Jednak nie tak do końca…

5. Sprawdzamy wszystkie zasoby, które nie zostały przez nas stworzone. Zwracamy szczególną uwagę na instancje EC2 (także te zatrzymane), obrazy AMI, woluminy EBS oraz ich snapshoty. Jeżeli nie jesteśmy pewni do czego dany zasób służy, usuńmy go.
6. Sprawdzamy role przydzielone do instancji EC2. Czy wszystkie uprawnienia dą im potrzebne. Pamiętajmy, nasz admin może zalogować się na taką maszynę wirtualną i z niej uprzykrzyć nam życie, jeżeli ta maszyna będzie miała uprawnienia, które jej na to pozwolą.

Kasując zasoby uważajmy, żeby nie usunąć czegoś, co pracuje na produkcji i nie da się łatwo i bezpiecznie odtworzyć.

7. W punkcie 3 dezaktywowaliśmy klucz dostępu. Nie usunęliśmy go, ponieważ musimy teraz sprawdzić, czy wszystkie nasze aplikacje pracują bez problemów. Jeżeli tak, możemy klucz usunąć i utworzyć nowy.

Czy to wystarczy? Tego nie możemy być pewni. Jeżeli mamy jakieś wątpliwości możemy skontaktować się jeszcze z supportem AWS.

Gdy nie możemy zalogować się na nasze konto AWS

Nasz były pracownik mógł być jednak bardziej perfidny i zablokował nam dostęp do naszego konta. Pozostaje wypełnienie tego formularza i oczekiwanie na pomoc ze strony AWS.

Developer wrzucił klucze na github

Firma jednak się rozrastała. Przybywało zamówień. Nowe projekty. Nowi pracownicy. Nowi programiści. Nie da się zatrudnić samych gwiazd. Czasem pracujemy także z juniorami. Błędy, nawet te zupełnie bezmyślne, przytrafiają się zresztą każdemu. Zwolniliśmy chwilę wcześniej admina, nie mamy czasu, developer dostał duże uprawnienia.

Klient zmienia założenia. Klient chce na jutro. Wszyscy się śpieszą. Pracujemy na koncie developerskim, robimy proof of concept. Byle szybko. No i poszło. A właściwie poszły. Klucze dostępowe developera do konta. Na GitHub. Zdarza się. Wbrew pozorom dość często. I może boleć.

Co robić?

Jak tylko się o tym fakcie dowiemy, siadamy do konsoli. Nie czekamy ani chwili. W internecie pracują boty, które wyszukują takie dane. Nasze konto może być więc „zaatakowane” nawet kilka sekund po fakcie.

1. Wchodzimy do IAM

2. Szukamy użytkownika, którego dane wyciekły.

W naszym przypadku chodzi o użytkownika leakeddeveloper

3. Wybieramy naszego użytkownika i przechodzimy do Jego ustawień bezpieczeństwa.

4. Przy kluczach, które wyciekły klikamy Make Inactive

I już nikt nie użyje tych kluczy.

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

Wszyscy ciągną dane z mojego koszyka s3

Zwolniłem wszystkich i sam zacząłem zajmować się całym biznesem i rozwojem. Teraz powinno być dobrze. Jednak nadmiar obowiązków zrobił swoje. 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 (nie wiem do dziś czy wszystkich) są dostępne dla każdego.

Jak To Możliwe? Krótkie śledztwo uzmysłowiło mi, że te dane leżą w jednym z moich koszyków w usłudze S3.

Co robić?

1. Przede wszystkim sprawdzić, który to bucket. Podejrzenia mogą paść na buckety publiczne, ale nie koniecznie będzie to taki bucket.

Zainteresowanych zabezpieczaniem swoich danych w usłudze S3 zapraszam do przeczytania artykułu na ten temat.

2. Jeżeli już wiemy, który to bucket wchodzimy do niego i wybieramy zakładkę Permissions. Tutaj możemy 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. Wklejamy poniższą politykę

 {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": "arn:aws:s3:::leaked-bucket/*",
            "Principal": "*"
        }
    ]
}

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

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

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

To zabezpieczy Wasz bucket i możecie teraz na spokojnie ustawić odpowiednie uprawnienia.

Ktoś się włamał do mojej ec2

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

Co robić?

1. Logujemy się do konsoli AWS i przechodzimy do serwisu EC2. Wybieramy region, w którym jest nasz instancja. Nie terminujemy jej.
2. Wybieramy maszynę, która została zaatakowana i zatrzymujemy ją

3. W opisie instancji wyszukujemy storage, które jest pod nią podpięte

4. Klikamy w identyfikator woluminu i po przejściu do listy woluminów, wybieramy nasz dysk

i tworzymy snapshot naszego dysku

Jeżeli chcemy to możemy w tym momencie terminować (usunąć) naszą zaatakowaną maszynę.

Po co te wszystkie kroki?

Dlaczego od razu nie usunęliśmy maszyny? Dobrze by było dowiedzieć się jak doszło do włamania. Przejrzeć logi. Poprosić jakiegoś specjalistę o sprawdzenie.

Aby bezpiecznie to zrobić, najlepiej uruchomić nową maszynę w odizolowanej VPC. Idealnie w podsieci prywatnej, bez dostępu z internetu.

1. Tworzymy nową maszynę wirtualną i montujemy do niej wolumin EBS, który będzie utworzony z naszego snapshota

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

I na koniec…

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

To my tak naprawdę jesteśmy odpowiedzialni za większość spraw związanych z dostępem do naszych zasobów i ich poprawną konfiguracją. Warto pamiętać o Shared Responsibility Model.

I warto dobrze żyć z ludźmi. Zapobiegniemy wtedy przynajmniej części problemów 🙂