Artykuł ukazał się pierwotnie na blogu Chmurowiska.

 

Bardzo popularna, a na pewno ważna usługa AWS. Simple Storage Service. S3. Być może nawet najważniejsza, bo korzystają z niej nie tylko użytkownicy, ale pod maską, także wiele innych usług AWS.

Pomimo ogromnych starań samego Amazona o to, aby nasze dane były bezpieczne i niedostępne dla każdego, co raz częściej słyszy się o wycieku danych z Amazona. Tak naprawdę dane wyciekają nie z AWS, a od użytkowników.

Statystyki na koniec 2017 roku nie były zbyt ciekawe. Ponad 7% bucketów miało ustawiony nieograniczony dostęp do danych dla wszystkich, a tylko 35% danych było zaszyfrowane.

Wycieki danych

Do wycieku danych dochodzi wtedy, gdy jakieś dane przechowywane w chmurze, czyli na przykład w S3, zostają przez przypadek udostępnione światu. Dlaczego przez przypadek? Ponieważ domyślnie, tworząc nowy bucket w S3 i wrzucając do niego dane wszystko jest tak skonfigurowane, że poza nami nikt nie ma dostępu do naszych danych.

Teoretycznie można podzielić użytkowników korzystających z S3 na dwie grupy. Pierwsza tworzy buckety i wrzuca tam dane, nie zastanawiając się co robi. Jeżeli chce komuś później te dane udostępnić, to też się nie zastanawia, tylko udostępnia. Często nie tylko tym, którym chce, ale wszystkim. Grupa druga wie czego chce i zastanawia się po drodze jak to osiągnąć.

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 [Localbox] https://www.theregister.co.uk/2018/04/19/48millionpersonalprofilesleftexposedbydatafirmlocalblox/ Nie posądzam architektów rozwiązań w takich firmach o przynależność do grupy, która nie wie co robi. Co więc może powodować takie wpadki?

Co możemy zrobić źle

Wiele osób boi się chmur publicznych myśląc, że nie są bezpieczne. Nie w tym jest problem. Dane w chmurach są bezpieczne. Jak już wspomniałem nowy bucket jest zawsze ustawiony jako prywatny i bez ingerencji człowieka ten stan się nie zmieni.

Część problemów może wynikać z braku zrozumienia działania czy to usługi S3, czy innych komponentów, z których budujemy rozwiązania:

• może wydawać nam się na przykład, że przecież musimy dać komuś adres do naszego zasobu, żeby mógł go pobrać i ktoś kto go nie ma, nie będzie w stanie tych danych 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 życia podczas wdrożenia, a potem zapominamy o ustawieniu poprawnych uprawnień

Ale przecież są narzędzia, które przeszukują internet pod kątem takich niezabezpieczonych zasobów.

Druga część to błędy popełniane podczas tworzenia bucketa. Już w pierwszym etapie czeka na nas pierwsza pułapka. Możemy zechcieć skopiować ustawienia z już istniejącego koszyka

Co, jeżeli ten koszyk ma ustawiony publiczny dostęp do danych?

Trochę trudniej jest omyłkowo udostępnić dane wybierając opcję

„Grant public read access to this bucket”. Dlaczego trudniej o pomyłkę? Ponieważ AWS dość wyraźnie ostrzeże nas przed zagrożeniem

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

Jak sprawdzić czy nasze koszyki są publiczne

Jak już wspomniałem, Amazon stara się z całych sił pomóc nam w zabezpieczaniu dostępu do naszych danych. Po ostatnich zmianach od razu widać, czy coś z naszych zasobów jest publiczne.

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

Zarządzanie uprawnieniami

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

• bucket (koszyk)
• object (plik)

Nadając uprawnienia dostępne mamy cztery wbudowane grupy:

• my

• autentykowani użytkownicy innych kont AWS

• każdy z dostępem do internetu

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

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

READ

• koszyk – odczyt zawartości koszyka, lista plików
• plik – odczyt jego zawartości i metadanych

WRITE

• koszyk – tworzenie, nadpisywanie i kasowanie plików w koszyku
• plik – nie ma zastosowania

READACP

• koszyk – pozwala czytać ACL dla koszyka
• plik – pozwala czytać ACL dla pliku

WRITEACP

• pozwala zapisywać ACL dla koszyka
• pozwala zapisywać ACL dla pliku

Zasady dostępu możemy ustawić dla każdego z plików stosując tak zwane Access Control Lists (ACLs) lub poprzez politykę (policy) przypisaną koszykowi.

Wyższy priorytet ma polityka. Jeżeli przypniemy więc do bucketa 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/*"
            ]
        }
    ]
}

to obojętnie od tego jakie ustawimy uprawnienia dla samego pliku, będzie on dostępny dla wszystkich.

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

Polityka tak ma jednak zastosowanie na przykład w przypadku gdy z naszego bucketa serwujemy statyczną stronę www. Ciężko by nam było wtedy dbać o to, żeby każdy plik był dostępny dla wszystkich. Żeby niepotrzebnie nie komplikować tematu pomijam w tym momencie użycie CloudFront, czyli amazonowego Content Delivery Network.

Jak żyć?

No dobrze. Ale co począć jeżeli chcemy udostępnić nasze pliki komuś z zewnątrz. 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) okres czasu 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. 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ą oczywiście inne warunki.

Co w trawie piszczy?

Dobra konfiguracja naszych zasobów jest bardzo ważna. Dobrze jest jednak także wiedzieć co dzieje się z naszymi danymi. Monitorowanie zdarzeń związanych z naszymi zasobami S3 umożliwiają 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 naszego koszyka

Po włączeniu ustawiamy koszyk docelowy, dodajemy ewentualnie prefix do naszych danych i powinniśmy dostać logi odnośnie zdarzeń w naszym koszyku. W logu dostępne będą między innymi informacje o źródłowym adresie IP, metodzie, nazwie pliku oraz statusie.

Podsumowując

Nie bójmy się chmury. Nie bójmy się S3. Tworząc nowy koszyk Amazon dba o nas i domyślnie nikt, poza nami nie ma dostępu do naszych danych. Wystarczy stosować się do kilku rozsądnych zasad i nikt niepowołany nie będzie miał dostępu do naszych danych. Jakie to zasady?

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

Mam nadzieję, że bezpieczne korzystanie z usługi S3 stanie się teraz proste. Jeżeli nie zapraszam do skorzystania z pomocy specjalistów Chmurowiska.