Video: Introduction to Amazon Web Services by Leo Zhadanovsky 2024
Hier is een voor de hand liggende vraag bij het omgaan met proxy's van derden: als deze hulpmiddelen voor u werken, weet Amazon Web Services (AWS) dan dat de persoon namens wie zij handelen is het in feite ? Met andere woorden, hoe kan AWS uw identiteit verifiëren om ervoor te zorgen dat de opdrachten die het ontvangt van u zijn? In feite is dezelfde vraag ook geldig als u rechtstreeks met de AWS API communiceert. Hoe kan AWS uw identiteit valideren om ervoor te zorgen dat het alleen opdrachten voor u uitvoert?
In plaats van te vertrouwen op een gebruikersnaam en wachtwoord, vertrouwt het op twee andere ID's om de API-serviceaanvragen te verifiëren: de toegangssleutel en de geheime toegangssleutel. Het gebruikt deze sleutels in serviceaanvragen om beveiliging te implementeren op een manier die veel veiliger is dan alleen het gebruik van uw gebruikersnaam en wachtwoord.
De manier waarop de twee toetsen worden gebruikt, is conceptueel eenvoudig, hoewel enigszins uitdagend in detail.
In principe doet u voor elk servicegesprek dat u wilt uitvoeren (of een hulpprogramma dat voor u werkt) het volgende:
De payload voor de serviceaanvraag maken.
-
Dit zijn de gegevens die u naar AWS moet verzenden. Het kan een object zijn dat u in S3 wilt opslaan of de afbeelding-ID van een afbeelding die u wilt starten. (U voegt ook andere gegevens toe aan de payload, maar omdat deze verschillen op basis van de details van de serviceaanroep, worden ze hier niet vermeld. Eén gegeven is de huidige tijd.)
De payload versleutelen met behulp van de geheime toegangssleutel.
-
Als u dat doet, kan niemand de payload bekijken en ontdekken wat erin zit.
Scan de gecodeerde payload digitaal door de geheime toegangssleutel toe te voegen aan de gecodeerde payload en een proces voor digitale handtekeningen uit te voeren met behulp van de geheime toegangssleutel.
-
Geheime toegangstoetsen zijn langer en meer willekeurig dan standaardgebruikerswachtwoorden; de lange geheime toegangssleutel maakt de versleuteling veiliger dan het zou zijn als het zou worden uitgevoerd met een typisch gebruikerswachtwoord.
Verzend de totale gecodeerde payload samen met uw toegangssleutel naar AWS via een serviceaanvraag.
-
Amazon gebruikt de toegangssleutel om uw geheime toegangssleutel op te zoeken, die wordt gebruikt om de payload te decoderen. Als de gedecodeerde payload leesbare tekst vertegenwoordigt die kan worden uitgevoerd, voert AWS de serviceaanroep uit. Anders wordt geconcludeerd dat er iets mis is met de serviceaanroep (misschien is dit door een kwaadwillende actor genoemd) en voert het serviceverzoek niet uit.
Naast de zojuist beschreven codering heeft AWS nog twee andere methoden die worden gebruikt om de legitimiteit van de serviceaanroep te waarborgen:
De eerste is gebaseerd op de datuminformatie bij de payload van de serviceaanvraag, die wordt gebruikt om te bepalen of de tijd behorend bij het maken van de serviceaanvraag geschikt is; als de datum in de serviceaanroep heel anders is dan zou moeten zijn (veel eerder of later dan de huidige tijd, met andere woorden), concludeert AWS dat het geen legitieme serviceaanvraag is en gooit het weg.
-
De tweede extra beveiligingsmaatregel betreft een controlesom die u voor de payload berekent. (Een
-
controlesom is een getal dat de inhoud van een bericht vertegenwoordigt.) AWS berekent een controlesom voor de payload; als de controlesom niet overeenkomt met de jouwe, wordt de serviceaanvraag niet toegestaan en niet uitgevoerd. Deze controlesombenadering zorgt ervoor dat niemand de inhoud van een bericht beschadigt en voorkomt dat een kwaadwillende acteur een legitieme serviceaanroep onderschept en deze wijzigt om een onaanvaardbare actie uit te voeren. Als iemand het bericht saboteert, als AWS een controlesom berekent, komt die controlesom niet meer overeen met die in het bericht en weigert AWS de serviceaanvraag uit te voeren.
Als u, zoals de meeste AWS-gebruikers, een proxy-methode gebruikt om te communiceren met AWS - de AWS-beheerconsole, een taalbibliotheek of een hulpmiddel van derden - moet u uw toegangssleutel en geheime toegangssleutel tot de proxy opgeven. Wanneer de proxy AWS-serviceaanvragen namens u uitvoert, bevat deze de toegangssleutel in de aanroep en gebruikt de geheime toegangssleutel om de payload-codering uit te voeren.
Vanwege de cruciale rol die deze sleutels vervullen in AWS, moet u deze
alleen delen met entiteiten die u vertrouwt. Als u een nieuwe tool van een derde partij wilt uitproberen en u weet niet veel over het bedrijf, stel dan een AWS-testaccount in voor de proef in plaats van de inloggegevens van uw productie AWS-account te gebruiken. Op die manier kunt u, als u besluit om niet verder te gaan met de tool, deze laten vallen, het test-AWS-account beëindigen en verder gaan, zonder zich zorgen te maken over mogelijke beveiligingskwetsbaarheden in uw belangrijkste productieaccounts. Natuurlijk kunt u altijd nieuwe toegangssleutels en geheime toegangssleutels maken, maar het gebruik van uw productietoetsen voor tests en het wijzigen van de toetsen levert veel werk op, omdat u elke plaats moet bijwerken die verwijst naar uw bestaande sleutels. Als je net als veel andere AWS-gebruikers bent, gebruik je een aantal hulpprogramma's en bibliotheken en het is lastig om ze opnieuw te gebruiken om je sleutels bij te werken. U kunt beter niet-productiegerelateerde accounts gebruiken om nieuwe tools te testen.
