Sådan giver du adgang til private filer ved hjælp af forunderskrevne URL'er på AWS

Lever privat indhold gennem S3 og CloudFront

Foto af Dayne Topkin på Unsplash

Når vi prøver at designe en løsningsarkitektur, hvor applikationen kan generere og gemme private filer på en lagringsindstilling som S3, og tillade muligheden for, at specifikke brugere får adgang til disse filer i en vis periode og stadig forbliver private, kunne vi følg to forskellige tilgange baseret på et scenario med reel brug.

Lad os skrive ned nogle brugssager og se, hvordan vi kan nærme os den bedste løsning:

  1. Et program, der konverterer lydfiler fra et format til et andet, så brugeren kan downloade den konverterede fil via et link, der udløber efter fem minutter.
  2. En applikation, der kun serverer premium-indhold (forskningsindsigt, dokumenter, videoer osv.) Til tilmeldte brugere i en begrænset periode.
  3. En applikation, der giver adgang til privat indhold til specifikke brugere, der hører til et specifikt IP-adresseinterval.

I alle disse forskellige scenarier kan vi vælge at gemme premiumindholdet via en lagerindstilling som S3 og levere det direkte eller fra en HTTP-server.

Men for at begrænse adgangen til indholdet kan vi bruge to forskellige tilgange.

S3 forunderskrevne webadresser

Antag, at vores applikation vil tjene en privat fil, gemt i en privat spand på S3, til specifikke brugere. Dette kan gøres ved at give brugerne en forunderskrevet URL, som kan genereres af den IAM-bruger, der har adgang til den private spand.

Jeg viser en hurtig demo, der er kodet i Python ved hjælp af Boto 3-biblioteket til interaktion med AWS-tjenesterne. Til at begynde med skulle du oprette en IAM-bruger, der mindst har GetObject- og ListBucket-tilladelser til den private spand, hvor disse private filer er gemt.

Sørg derefter for at generere adgangstaster til denne bruger og konfigurere den lokale CLI med disse legitimationsoplysninger for at være i stand til at interagere med tjenesterne gennem Boto 3-biblioteket.

For at gå videre til den faktiske generation af en forunderskrevet URL viser følgende kode genereringen af ​​en forunderskrevet URL til download af en privat fil (kaldet s3.png) i en privat spand.

Det viser også genereringen af ​​forunderskrevne webadresser til upload af en fil til en privat spand, men vi kommer til det om et øjeblik.

Lige nu, efter at den forunderskrevne URL er genereret, kan brugeren med den URL downloade filen i en begrænset tidsramme (f.eks. Inden for fem minutter efter oprettelsen).

Lad os dykke dybere og forstå, hvad der sker i baggrunden. Den genererede URL ligner følgende:

https://BUCKET_NAME.s3.amazonaws.com/s3.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXXXXXXXXX%2F20200305%2Feu-central-1%2Fs3%2Faws4_request&X-Amz-Date= 20200305T220655Z & X-AMZ-Udløber = 3600 & X-AMZ-SignedHeaders = vært & X-AMZ-Signature = 53deb5df885a8fc00e02cc88076206f50b093ae5a305cbbeab5620e3a776641e

Fra en oversigt på højt niveau giver denne URL tilladelse til den bruger, der bruger den, til at anmode om den private fil på vegne af den faktiske bruger, der har genereret den URL. (Derfor skal brugeren, der opretter den forunderskrevne URL, have tilladelser til at få adgang til spanden og filerne inden i).

Hvis vi ser på URL-spørgsmålets forespørgselsparametre, er nøgleparameteren X-Amz-Credential, som faktisk inkluderer ejerens adgangsnøgle, genereringsdato (20200305), spandens region (eu-central-1), og AWS-tjenesten (S3).

Derudover kan vi se en anden vigtig parameter, X-Amz-Expires, som giver det samlede antal sekunder for URL-gyldigheden.

De andre parametre er relateret til signaturalgoritmer og kryptering, men da dette indlæg ikke er beregnet til at uddybe sikkerhedsdelen, kan du læse mere i Amazon AWS-dokumenter.

Normalt, da en applikation er i stand til at give sine brugere muligheden for at være i stand til at downloade private filer i en vis periode, skal den i flere brugstilfælde kunne give sine brugere muligheden for at uploade filer direkte til den private spand uden mellemled.

Dette kunne også gøres ved at generere en forunderskrevet URL med POST aktiveret.

Ovenstående kodeeksempel viser, hvordan man genererer en forunderskrevet POST-URL til filnøglen s3-post.png, og viser også filoverførselsprocessen.

Der er flere ting at bemærke her:

  • Den genererede POST-forunderskrevne URL ville se sådan ud: https://BUCKET_NAME.s3.amazonaws.com/
  • Sammen med POST-URL'en returnerer genereringsmetoden flere parametre (ligesom forespørgselseparametrene til GET-eksemplet), der giver brugeren med URL'en og parametrene mulighed for at udføre en POST-anmodning (dvs. uploade en fil), der handler på vegne af bruger, der genererede URL'en.
  • Ps: Sørg for at tildele IAM-brugerens putObject-tilladelser.

I ovenstående kodeeksempel udføres filoverførselsprocessen automatisk ved at angive parametrene og filen som POST-anmodningsorganet.

Hvis du skulle udføre POST-anmodningen manuelt, skal du f.eks. ved hjælp af Postman skal du sørge for at placere URL-parametrene i anmodningsorganet på en ordnet måde som vist på følgende billede.

Indtil videre har vi fundet ud af en måde at oprette et program, der giver brugerne mulighed for at få adgang til private filer, der er gemt på S3 i en vis periode ved at generere forunderskrevne URL-adresser.

Bemærk, at generering af forunderskrevne URL'er er en funktion i S3, men hvad ville der ske, hvis vi ville give begrænset adgang til en sti eller en IP-adresse i stedet for en fil? CloudFront underskrevne URL'er til redning.

CloudFront-underskrevne webadresser

En hurtig note om CloudFront vil beskrive det som et indholdsleveringsnetværk, der forbedrer adgangsydelsen ved at cache indhold til kantsteder, der findes overalt i verden.

For at fremskynde levering af indholdet til vores applikation, bruger vi normalt CloudFront. Du kan læse mere om det i AWS-dokumenter.

Lad os nu se, hvordan det kan hjælpe os med at løse ovennævnte leveringsproblemer.

CloudFront leverer underskrevne URL'er med henblik på at tjene privat indhold, der enten kan gemmes i en S3-spand, på EC2 (gennem dets IP), ELB og endda på din egen HTTP-server.

For at demonstrere dette, ville jeg oprette en hurtig demodistribution på CloudFront, der ville tjene filer fra min private spand ved først at begrænse adgangen til S3 ved hjælp af en Origin Access Access Identity.

Det er temmelig ligetil at indstille dette, mens du opretter distributionen, ved kun at kontrollere Restrict Bucket Access og oprette en ny Access Identity. Dette betyder, at brugerne kun kan få adgang til S3-filer ved hjælp af CloudFront-URL'er i stedet for S3-URL-adresser.

Dernæst har vi brug for et CloudFront-nøglepar for at oprette en underskrevet URL.

Gå over til Mine sikkerhedsoplysninger i konto-menuen, og vælg CloudFront-nøglepar. Opret et nyt par (eller upload dit eget ved først at oprette det manuelt, for eksempel ved hjælp af OpenSSL) og download den private nøgle, der ville blive brugt til at underskrive URL’erne.

For den underskrevne URL kan vi ud over andre ting angive et tidsinterval, når denne URL kan fås. URL-specifikationerne, efter at anmodningen er foretaget på CloudFront, matches med en politik, der oprindeligt er oprettet, og kan enten være en dåse- eller en tilpasset politik.

For at holde tingene enkle demonstrerer følgende kode genereringen af ​​den underskrevne URL ved at oprette en brugerdefineret metode, der indlæser den private nøgle og bruger denne nøgle til at underskrive ressource-URL'en, hvilket producerer en underskrevet URL på denne måde.

Den resulterende URL vil se ud som følger, hvor vi kan notere underskriften som en forespørgselsparameter, som vil blive kontrolleret mod adgangspolitikken, når ressourcen anmodes om:

http://XXXXXXXXXX.cloudfront.net/s3.png?Expires=1583492400&Signature=P7hD6lrJ3Gqh2UgyqvYMiCALbv91WN7mvlDNBMRzOXJOiHwGe0Yh4HuOwvUDGstGx~c64nGNpU1n1TbUloc6WLUfkYtxEBOUQSaMGb4BM~Dd9p4i1pRPp7gCz3c8cHcnuRGTEdpJzDMN835y8Op6~V-FWvjJHCkcPNsIll-sv9oZ2oRJLSoqVbTh-1sXaJ4LAq11MCFf8zGaBvj65P5Wc4SYv5Vg63~CXc67xAQuwt7CClgyaIby6ooehKGddokL9m0XwRFIMr6SCx1HxQcA4jYEdgixnyYd6X2gc1WnEuYdv-Fxna5n3TBocoNbPAlcX8KV5j~HB1eFRAf2I3lQiQ__&Key-Pair-Id=XXXXXXXXXXXXXX

Resumé

For at opsummere det, kan adgang til privat indhold gives i en begrænset periode gennem en CloudFront-distribution ved hjælp af underskrevne URL-adresser. Det indhold, der kan beskyttes og serveres, kan være en sti eller en IP-adresse.

Endelig, hvis vi ønskede at servere flere private filer via CloudFront i stedet for kun en, ville den rigtige løsning være at bruge underskrevne cookies, som er et varmt emne for et fremtidig indlæg.

Tak for din tid, jeg håber du fandt dette en behagelig læsning.

Pas på.

Ressourcer

  • CloudFront privat indhold - AWS
  • Opgaver med privat indhold - AWS
  • Underskrevne URL'er - AWS
  • CloudFront-eksempler - Boto 3