Kto Ma Dostęp do Moich Informacji? Czyli Jak Bezpiecznie Przechowywać Dane w Amazon S3

Dane to złoto XXI wieku. Wytwarzamy je wszyscy, wszyscy musimy je gdzieś przechowywać. Każdemu z nas zależy na tym, aby je należycie chronić.

AWS S3 – Simple Storage Service, czyli chmurowy nośnik danych od Amazona, jest jedną z najpopularniejszych usług producenta. Korzystają z niej nie tylko bezpośredni użytkownicy, ale także inne usługi, dlatego w hierarchii produktów AWS zajmuje szczególne miejsce.

Jeżeli przechowujecie dane w AWS S3, warto sprawdzić, czy na pewno jesteście jedynymi osobami, które mają do nich dostęp. A jeśli dopiero macie zamiar skorzystać z usługi, przekonajcie się, jak właściwie zabezpieczyć Wasze zasoby.

Czy moje dane w AWS są bezpieczne?

Pod koniec 2017 roku statystyki dotyczące bezpieczeństwa danych nie dawały Amazonowi wiele powodów do zadowolenia. Według badań przeprowadzonych przez Skyhigh Networks, ponad 7% tzw. bucketów danych w AWS S3 miało ustawiony nieograniczony dostęp! Każdy mógł sobie je obejrzeć. Tylko 35% bucketów zostało zaszyfrowane, podlegając prawidłowej ochronie.

Pomimo ogromnych starań Amazona, aby nasze dane były bezpieczne i niedostępne dla niepowołanych osób, coraz częściej słyszy się o wycieku danych z chmury. Tak naprawdę jednak dane wyciekają nie z winy AWS, a użytkowników.

Czym jest wyciek danych z chmury?

Do wycieku dochodzi wtedy, gdy dane przechowywane w chmurze, czyli na przykład w S3, zostają przez przypadek udostępnione światu. Dlaczego przez przypadek?

Ponieważ kiedy tworzymy nowy zbiór danych (tzw. bucket) w S3 i wrzucamy do niego dane, wszystko jest tak domyślnie skonfigurowane, że poza nami nikt nie ma do nich dostępu. Problem zaczyna się tam, gdzie kończy się świadome działanie.

Niestety, często zdarza się, że użytkownicy korzystający z S3 wrzucają dane bez żadnego planu i celu. Tworzą bucket, nie zastanawiając się, jakie informacje tam umieszczą, komu będą one w przyszłości potrzebne i co się później z nimi może stać. To damo dotyczy później udostępniania. Niejednokrotnie zdarza się, że takie osoby przez pomyłkę dają prawo dostępu do swoich danych nie tylko wybranej grupie, ale wszystkim.

Tymczasem zarządzając danymi w chmurze, zawsze należy wiedzieć, jakie jest ich przeznaczenie, co i w jaki sposób chcemy osiągnąć, udostępniając je osobom trzecim, i kto może mieć dostęp do jakiego zakresu danych.

Zastanawiałem się jednak, skąd mogą się brać wycieki danych w takich firmach jak

• Verizon (http://money.cnn.com/2017/07/12/technology/verizon-data-leaked-online/index.html),
• Accenture (https://www.engadget.com/2017/10/10/accenture-four-servers-sensitive-data-unprotected/),
• czy ostatnio LocalBlox (https://www.geekwire.com/2018/data-leak-exposes-48m-user-profiles-scraped-facebook-zillow-sites-researcher-says/).

Nie posądzam architektów rozwiązań w tych korporacjach o masową niefrasobliwość. Co więc może powodować podobne wpadki?

Bezpieczeństwo danych – co prawdopodobnie robisz źle?

Wiele osób boi się chmur publicznych, myśląc, że nie są bezpieczne. Nie w tym sęk.

Chmura gwarantuje nam bezpieczeństwo.

Jak już wspomniałem, nowy bucket jest zawsze ustawiony jako prywatny i bez ingerencji człowieka ten stan się sam nie zmieni.

Część problemów z bezpieczeństwem danych może wynikać z braku zrozumienia działania usługi S3 lub innych komponentów, z których budujemy nasze rozwiązania. Oto kilka przykładów:

• Może nam się niesłusznie wydawać, że musimy udostępnić komuś adres do naszego zasobu, aby mógł go pobrać.
• Możemy myśleć, że dostęp do plików zabezpieczymy w aplikacji klienckiej, a sam bucket S3 może być dostępny publicznie.
• Możemy ustawić dostęp publiczny dla celów testowych, dla ułatwienia sobie pracy podczas wdrożenia, a potem zapominamy przywrócić poprawne uprawnienia.

A przecież istnieją narzędzia, które przeszukują Internet pod kątem takich niezabezpieczonych zasobów!

Wniosek: Wycieki danych wynikają bardzo często z niewystarczającej wiedzy lub błędnych założeń na temat rozwiązań chmurowych.

Drugą częstą przyczyną utraty bezpieczeństwa danych są błędy popełniane podczas tworzenia bucketów.

Już na pierwszym etapie czyha na nas pułapka – możemy zechcieć skopiować ustawienia z już istniejącego bucketa:

Jeżeli wybierzemy tę opcję, przez przypadek, czy nie, AWS wyraźnie ostrzeże nas przed zagrożeniem:

Najlepiej przed ostatecznym utworzeniem bucketa sprawdzić ustawienia w podsumowaniu, które prezentuje nam usługa:

Jak sprawdzić czy Twoje zbiory danych (buckets) są publiczne?

Jak już wspomniałem, Amazon stara się z całych sił pomóc nam w zabezpieczaniu dostępu do naszych danych. Ostatnio firma wprowadziła wyraźne oznaczenie publicznych danych, które nie pozostawia żadnych wątpliwości, co do statusu danego zasobu.

Także na liście bucketów widzimy, czy są one publiczne, czy też nie:

Konfiguracja uprawnień w Amazon S3

Korzystając z usługi S3, w uproszczeniu używamy dwóch rodzajów zasobów:

• bucket (zbiór, rodzaj folderu)
• object (plik)

Nadając uprawnienia, mamy do dyspozycji cztery domyślne grupy:

• my

• uwierzytelnieni użytkownicy innych kont AWS

• każdy użytkownik z dostępem do Internetu

• grupa użytkowników zapisująca w naszym zbiorze danych logi.

Każdej z tych grup możemy przydzielić uprawnienia do odczytu, zapisu oraz ewentualnie do edycji list dostępu (Access Control List – ACL), czyli zmiany uprawnień. Poniżej wyjaśniam, jaki skutek mają poszczególne uprawnienia zarówno dla plików, jak i koszyka.

Rodzaje uprawnień

READ

• bucket – odczyt zawartości zbioru, lista plików
• plik – odczyt zawartości i metadanych pliku

WRITE

• bucket – tworzenie, nadpisywanie i kasowanie plików w zbiorze
• plik – nie ma zastosowania

READACP

• bucket – pozwala czytać ACL dla zbioru
• plik – pozwala czytać ACL dla pliku

WRITEACP

• bucket – pozwala zapisywać ACL dla zbioru
• plik – pozwala zapisywać ACL dla pliku

Zasady dostępu możemy ustawić dla każdego z plików, stosując wspomniane wyżej listy kontroli dostępu, Access Control Lists (ACLs), lub poprzez politykę (policy) przypisaną danemu zbiorowi, gdzie polityka ma wyższy priorytet.

Zobaczmy to na przykładzie. Do zbioru przypiszemy następującą politykę pozwalającą wszystkim na pobieranie plików:

{

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

    "Statement": [

        {

            "Sid": "PublicRead",

            "Effect": "Allow",

            "Principal": "*",

            "Action": [

                "s3:GetObject"

            ],

            "Resource": [

                "arn:aws:s3:::nazwa-koszyka/*"

            ]

        }

    ]

}

Teraz obojętnie, jakie ustawimy uprawnienia dla samego pliku, i tak będzie on dostępny dla wszystkich.

Przypadkowe zastosowanie polityki jest trudne, gdyż AWS także w tym przypadku ostrzega nas przed konsekwencjami:

Polityka taka ma zastosowanie na przykład w przypadku, gdy z naszego zbioru serwujemy statyczną stronę www. Ciężko by nam było wtedy dopilnować, żeby każdy plik był dostępny dla wszystkich.

Uprawnienia. Zabierać czy dawać? Jak żyć?

No dobrze. Ale co począć, jeżeli chcemy udostępnić nasze pliki komuś z zewnątrz. Przecież nie wszystkie dane przechowujemy tylko dla naszych oczu.

Jest na to kilka sposobów.

Możemy na przykład wygenerować signed url dla naszego pliku. Będzie to url, który przez pewien (ustawiony przez nas) czas będzie pozwalał na pobranie takiego pliku.

Możemy także zastosować trochę bardziej skomplikowane polityki, w których zastosujemy warunki. Jeżeli chcemy udostępnić pliki naszemu innemu serwerowi o znanym adresie IP, przykładowa polityka może wyglądać następująco:

{

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

  "Id": "S3PolicyId1",

  "Statement": [

    {

      "Sid": "IPAddressAllow",

      "Effect": "Allow",

      "Principal": "*",

      "Action": ["s3:GetObject"],

      "Resource": "arn:aws:s3:::nazwa-koszyka/*",

      "Condition": {

         "IpAddress": {"aws:SourceIp": "192.168.1.0/32"}

      }

    }

  ]

}

Możemy też udostępnić pliki wszystkim w naszej sieci za wyjątkiem kolegi, którego nie lubimy, bo zjadł nam pączka. Wtedy warunek przyjmie mniej więcej taką postać:

{

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

    "Id": "S3PolicyId1",

    "Statement": [

        {

            "Sid": "IPAddressFiltered",

            "Effect": "Allow",

            "Principal": "*",

            "Action":["s3:GetObject"]  ,

            "Resource": "arn:aws:s3:::nazwa-koszyka/*",

            "Condition" : {

                "IpAddress" : {

                    "aws:SourceIp": "192.168.1.0/24"

                },

                "NotIpAddress" : {

                    "aws:SourceIp": "192.168.102.188/32"

                }

            }

        }

    ]

}

Dostępne są też oczywiście inne warunki.

Co w trawie piszczy, czyli monitorowanie zdarzeń

Poprawna konfiguracja zasobów jest bardzo ważna dla bezpieczeństwa naszych danych. Równie istotne jest ich późniejsze monitorowanie. Kontrolę nad statusem naszych danych oferują nam dwie usługi.

Pierwszą z nich jest CloudTrail, który zawsze warto mieć włączony i skonfigurowany. Samo S3 umożliwia także śledzenie zdarzeń za pomocą Server Access Logging. Ustawienie to dostępne jest w zakładce Properties danego zbioru.

Po włączeniu ustawiamy docelowy zbiór danych, dodajemy ewentualnie prefiks do naszych danych i powinniśmy dostać logi dotyczące zdarzeń w naszym zbiorze. Odczytamy z nich między innymi informacje o źródłowym adresie IP, metodzie, nazwie pliku oraz jego statusie.

Nie taka chmura straszna!

Podsumowując, nie bójmy się chmury. Nie bójmy się AWS S3! Sama usługa jest bezpieczna, a Amazon dba o nasze dane. Wybierając domyślne ustawienia, mamy pewność, że nikt poza nami nie otrzyma dostępu do naszych cennych informacji.

A jeśli chcemy udostępnić nasze dane, to również możemy to zrobić w bezpieczny sposób. Wystarczy zastosować się do kilku rozsądnych zasad. Jakie to zasady?

1. Nie włączamy publicznego dostępu dla odczytu i zapisu zawartości zbioru danych.
2. Nie włączamy publicznego dostępu do edycji list uprawnień (ACL).
3. W polityce zdefiniowanej dla zbioru danych nie ustawiamy uprawnień pozwalających wszystkim na odczyt.
4. Jeżeli chcemy komuś udostępnić dane z naszych zbiorów, stosujemy polityki z warunkami lub używamy signed URLs.

Mam nadzieję, że przekonałem Was, że bezpieczne korzystanie z usługi Amazon S3 nie jest takie straszne, jak je malują. A jeżeli wolelibyście powierzyć bezpieczeństwo swoich danych w chmurze specjalistom, zapraszam do skorzystania z pomocy ekspertów Chmurowiska?