Używanie presigned URL do identyfikowania użycia Amazon S3 przez żądającego

Wiele ofert produktów typu oprogramowanie jako usługa (SaaS) posiada model cenowy z płatnością zgodnie z rzeczywistym użyciem, naliczając klientom opłaty tylko za zużyte zasoby. Jednak cena płatności zgodnie z rzeczywistym użyciem jest opłacalna tylko wtedy, gdy można dokładnie śledzić wykorzystanie zasobów przez każdego klienta, takich jak pojemność obliczeniowa, pamięć masowa i przepustowość sieci. Bez tych danych dostawcy SaaS nie mają wglądu w zużycie zasobów każdego klienta i nie są w stanie naliczać opłat na podstawie ich wykorzystania. To tylko jeden przykład, w którym możliwość dokładnego śledzenia zużycia podobnych zasobów może okazać się krytyczną potrzebą.

W tym artykule autorzy opisują, jak śledzić, kto pobrał obiekty z Twoich zasobników Amazon Simple Storage Service (S3). W szczególności śledzone są pobrania za pomocą predefiniowanych adresów URL. Twórcy robią to, generując wstępnie podpisany adres URL z niestandardowym parametrem przy użyciu procesu Signature Version 4 (SigV4), a następnie wysyłając zapytanie do dzienników dostępu do serwera S3 za pomocą Amazon Athena, aby zidentyfikować, kto wykonał żądania. Dołączając parametr niestandardowy do wstępnie podpisanego adresu URL, właściciele zasobników S3 mogą śledzić jego użycie, używając parametru niestandardowego jako identyfikatora. Dzięki temu właściciele zasobników mogą naliczać użytkownikom opłaty na podstawie częstotliwości i ilości danych pobieranych przez użytkowników ze swoich środowisk.

Uprawnienia wymagane do utworzenia presigned URL

Tworząc presigned URL, należy pamiętać o jak najmniejszych uprawnieniach. Osoba z prawidłowym podpisanym adresem URL może uzyskiwać dostęp do obiektów tak, jakby była oryginalnym użytkownikiem podpisującym, co sprawia, że ważne jest zablokowanie uprawnień podmiotu tworzącego presigned URL. Tworzenie presigned URL dla obiektu S3 wymaga, aby użytkownik tworzący miał wyraźne uprawnienia do wykonania określonej akcji. Na przykład, aby utworzyć presigned URL dla żądania GET, użytkownik podpisujący musiałby mieć uprawnienia do odczytu obiektu S3. Mając to na uwadze, zaleca się nadawanie podpisującemu tylko niezbędnych uprawnień w celu ograniczenia dostępu do pożądanego poziomu.

Tworzenie presigned URL z niestandardowym parametrem

W tej sekcji autorzy zademonstrują, jak wygenerować presigned URL z niestandardowym parametrem dla obiektu w prywatnym zasobniku S3. Aby to zrobić, musisz napisać kod, który podpisze żądanie za pomocą procesu SigV4. Ten krok jest niezbędny do podania w żądaniu informacji uwierzytelniających. Autorzy użyją próbki kodu Java dostarczonej w dokumentacji referencyjnej API Amazon S3 jako punktu odniesienia dla procesu obliczania podpisu i dokonają drobnych zmian w kodzie, aby wygenerować presigned URL z niestandardowymi parametrami.

Wykonaj następujące kroki, aby pobrać i przejść do dostarczonego przykładowego kodu.

1. 1. Pobierz Java sample code.
2. 2. Wyodrębnij plik .zip.
3. 3. Przejdź do com/amazonaws/services/s3/sample.

Po dotarciu do folderu z kodem wystarczy wprowadzić zmiany w trzech plikach:

RunAllSamples.java and PresignedUrlSample.java w sample folder i AWS4SignerForQueryParameterAuth.java w sample/auth folder.

Aby uzyskać szybki przegląd plików:

• RunAllSamples.java: ten plik po prostu uruchamia cztery przykładowe fragmenty kodu podane w dokumentacji.
• PresignedUrlSample.java: Ten plik jest odpowiedzialny za zbieranie odpowiednich parametrów, obliczanie podpisu przy użyciu parametrów i generowanie końcowego, presigned URL. Plik jest obecnie zakodowany na stałe w celu wygenerowania presigned URL dla obiektu ExampleObject.txt. Możesz później zmienić tę nazwę obiektu w pliku, aby dopasować ją do swoich potrzeb.
• AWS4SignerForQueryParameterAuth.java: ten plik zawiera kod, który oblicza podpis przy użyciu parametrów ciągu zapytania. Jest to wykorzystywane w PresignedUrlSample.java.

Plik RunAllSamples.java wymaga czterech zmiennych: awsAccessKey, awsSecretKey, bucketName i regionName niezbędnych do uruchomienia skryptu. W celach demonstracyjnych autorzy wykorzystują istniejący kod z dokumentacji, który używa poświadczeń statycznych, ale w przypadku implementacji produkcyjnej zalecane jest przekazywanie poświadczeń tymczasowych jako najlepsze rozwiązanie. Może to zapobiec przypadkowemu przekazaniu zakodowanych na stałe kluczy dostępu i tajnych kluczy AWS do repozytorium kodu.

Po wypełnieniu czterech zmiennych (awsAccessKey, awsSecretKey, bucketName i regionName) w RunAllSamples.java skompiluj i uruchom kod zgodnie z instrukcjami zawartymi w dokumentacji referencyjnej interfejsu API Amazon S3. Powinno to uruchomić cztery próbki kodu, w tym kod generujący wstępnie podpisany adres URL dla pliku ExampleObject.txt w określonym zasobniku S3.

Aby dołączyć parametr niestandardowy do wstępnie podpisanego adresu URL, musisz wprowadzić następujące zmiany w Java code sample.

1. Zmień wiersze 30 i 32 w java z ExampleObject.txt na nazwę obiektu, która istnieje w Twoim zasobniku S3.
2. W wierszu 44 w java dodaj dodatkowy parametr zapytania. To będzie Twój niestandardowy parametr, który zostanie dodany do wcześniej podpisanego adresu URL. Możesz również dodać wiele parametrów. W przykładzie autorzy dodali imię/johndoe jako przykładową parę klucz-wartość.
3. W java musisz dodać kolejny wiersz dla parametru zapytania dodanego w kroku 3, aby został dodany do wcześniej podpisanego adresu URL.

Po wykonaniu powyższych kroków możesz postępować zgodnie z tymi samymi instrukcjami w dokumentacji referencyjnej interfejsu API Amazon S3, aby skompilować i uruchomić kod generujący wstępnie podpisany adres URL.

Dodany wcześniej parametr niestandardowy name=johndoe jest teraz dołączany na końcu wcześniej podpisanego adresu URL. Możesz teraz pobrać obiekt z presigned URL.

Kwestionowanie dzienników dostępu do serwera S3 w celu określenia wzorców użytkowania

Teraz, gdy już wygenerowałeś presigned URL z parametrem niestandardowym, następnym krokiem jest śledzenie użycia adresu URL. Najpierw jednak musisz włączyć dzienniki dostępu do serwera S3 dla zasobnika S3. Gdy to zrobisz, możesz wysłać zapytanie do dzienników dostępu do serwera, aby zidentyfikować osoby żądające. Istnieje wiele sposobów wysyłania zapytań do dzienników dostępu do serwera przechowywanych w zasobniku S3. Na przykład możesz analizować logi dostępu do serwera, przesyłając strumieniowo logi do usługi Amazon OpenSearch Service przez AWS Lambda lub używając Pandas with AWS SDK for Python. W tym artykule autorzy używają Amazon Athena do wysyłania zapytań do dzienników dostępu do serwera S3 i identyfikowania żądań za pomocą parametru niestandardowego. Możesz wykonać następujące kroki, aby utworzyć tabelę Athena. Gdy to zrobisz, możesz rozpocząć sprawdzanie dzienników dostępu do serwera S3.

Uruchamianie przykładowych zapytań

Najpierw uruchom następujące zapytanie, aby zobaczyć, jakie informacje są rejestrowane.

SQL

SELECT * FROM s3_access_logs_db.mybucket_logs limit 10;

Poprzednie zapytanie powinno zwrócić 24 kolumny, w tym nazwę zasobnika, status http, adres IP zgłaszającego i wiele innych. Parametr niestandardowy dodany w powyższym ćwiczeniu pojawi się pod request_uri. Jeśli miałbyś obciążać klientów na podstawie ilości danych, które pobrali z Twojego zasobnika S3, możesz uruchomić zapytanie wyszukujące logi dostępu, które zwracają tylko parametr niestandardowy w request_uri i bajtach udanego żądania GET.

SQL

SELECT SPLIT_PART(SPLIT_PART(request_uri,'name=',2),' ',1), bytessent FROM s3_access_logs_db.mybucket_logs WHERE httpstatus='200' AND operation='REST.GET.OBJECT' AND request_uri LIKE '%name=%';

Powyższy zrzut ekranu pokazuje wartość nazwy klienta johndoe pojawiającą się w dziennikach dostępu do serwera S3 po zapytaniu przez Athena. Wiedząc o tym, możesz użyć przykładowego kodu, aby wygenerować presigned URL dedykowane każdemu z Twoich klientów i śledzić, w jaki sposób są one używane.

Porządkowanie

Jedynymi opłatami bieżącymi z tego ćwiczenia są koszty przechowywania plików w S3. Jeśli nie chcesz ponosić dalszych opłat, usuń pliki S3, które zostały utworzone na potrzeby testów.

Wnioski

Na podstawie tego artykułu autorzy omówili sposób identyfikowania użycia Amazon S3 na żądanie. Pokrywają wprowadzanie modyfikacji do istniejącego przykładowego kodu w celu dodania niestandardowego parametru do wstępnie podpisanego adresu URL oraz odpytywanie dzienników dostępu do serwera S3 w celu zidentyfikowania żądania za pomocą dodanego niestandardowego parametru. Dzięki tym informacjom nie musisz już odgadywać ruchu „per-customer” w swoim zasobniku S3 i możesz oferować swoim klientom dostęp do obiektów S3 w modelu cenowym typu „pay-as-you-go”. Wzorce dostępu do danych użytkownika mogą być dalej wykorzystywane do wnioskowania o potrzebach użytkowników i mogą pomóc w tworzeniu nowych i ulepszonych ofert dla klientów.

Źródło: AWS