Introducere în securitatea AWS

Securitatea AWS pentru dezvoltatori

Rahul Singh

Technical Product Manager

Cerințe preliminare ale cursului

Cunoștințe de bază despre securitatea AWS
Înțelegerea conceptelor de cloud computing
Concepte de securitate AWS și gestionare a costurilor

Pagina de titlu a cursului Concepte de securitate AWS și gestionare a costurilor

Obiectivele cursului

Identitate: cine face apelul
Autorizare: la ce poate ajunge
Secrete și criptare: protejarea datelor
Dovezi: ce s-a întâmplat, ulterior

Patru benzi numerotate așezate vertical, câte una pentru fiecare domeniu acoperit de curs. Banda unu, Identitate, marcată Capitolul 1. Banda doi, Autorizare, marcată Capitolul 2. Banda trei, Secrete și criptare, marcată Capitolele 2 și 3. Banda patru, Dovezi, marcată Capitolul 3. O săgeată portocalie în stânga, etichetată acest videoclip, indică banda unu.

Codul tău ajunge la destinație printr-un pipeline

Un flux de la stânga la dreapta. Pasul unu, o casetă etichetată Pipeline-ul tău conținând trei etape în ordine: Build, Test, Deploy. Pasul doi, o săgeată etichetată git push care intră în ea dintr-o casetă etichetată Tu. Pasul trei, o insignă portocalie atârnată sub pipeline, etichetată propria identitate. O săgeată continuă de la pipeline la o casetă etichetată AWS.

Mai întâi, un termen important

Un pipeline este automatizarea care construiește, testează și implementează codul tău
Rulează la fiecare push, fără intervenție umană

Un deploy care eșuează din motivul greșit

La o modificare de cod, permisiunile cui sunt verificate de fapt?

Faci push la o modificare

Pasul unu al unui flux vertical. O casetă etichetată Tu, făcând push la o modificare de cod.

Un deploy care eșuează din motivul greșit

La o modificare de cod, permisiunile cui sunt verificate de fapt?

Faci push la o modificare
Pipeline-ul tău rulează

Un flux vertical. Pasul unu, Tu, făcând push la o modificare de cod. O săgeată duce în jos la pasul doi, pipeline-ul tău, care execută deploy-ul.

Un deploy care eșuează din motivul greșit

La o modificare de cod, permisiunile cui sunt verificate de fapt?

Faci push la o modificare
Pipeline-ul tău rulează
Deploy-ul se oprește: AccessDenied

Primul instinct: "Hai să-mi verific propriile permisiuni."

Un flux vertical. Pasul unu, Tu, făcând push la o modificare de cod. Pasul doi, pipeline-ul tău execută deploy-ul. Pasul trei, AWS evaluează cererea și returnează AccessDenied.

Ce s-a întâmplat de fapt

Pasul unu al unui flux de la stânga la dreapta. O casetă etichetată Tu, a cărei implicare se încheie aici.

Faci push. Implicarea ta se încheie aici

Ce s-a întâmplat de fapt

Un flux de la stânga la dreapta. O casetă etichetată Tu, cu o săgeată către o casetă etichetată Pipeline-ul tău. O insignă etichetată deploy-role atârnă sub pipeline.

Faci push. Implicarea ta se încheie aici
Pipeline-ul face deploy, rulând ca un rol creat de echipa ta

Ce s-a întâmplat de fapt

Un flux de la stânga la dreapta de la Tu, la Pipeline-ul tău, la AWS. O insignă etichetată deploy-role atârnă sub pipeline, iar o săgeată punctată etichetată verifică pornește de la AWS înapoi către acea insignă, nu înapoi către Tu.

Faci push. Implicarea ta se încheie aici
Pipeline-ul face deploy, rulând ca un rol creat de echipa ta
AWS evaluează acel rol

Actor și principal

Actor

Cel care a pus lucrul în mișcare.

Aici: tu.

O pictogramă cu o figură umană care reprezintă un actor ce pune lucrul în mișcare.

Actor și principal

Actor

Cel care a pus lucrul în mișcare.

Aici: tu.

Principal

Identitatea pe care AWS o evaluează la primirea cererii.

Aici: rolul pipeline-ului.

O pictogramă cu o figură umană care reprezintă un actor ce pune lucrul în mișcare.

O pictogramă care reprezintă principalul.

Actor și principal

Actor

Cel care a pus lucrul în mișcare.

Aici: tu.

Principal

Identitatea pe care AWS o evaluează la primirea cererii.

Aici: rolul pipeline-ului.

Lambda: rol de execuție. ECS: rol de task. Nume nou, același principal
Excepție: o cheie de lungă durată în terminalul tău, caz în care utilizatorul IAM este principalul

O pictogramă cu o figură umană care reprezintă un actor ce pune lucrul în mișcare.

O pictogramă care arată AWS verificând principalul, nu actorul.

Același deploy, două roluri

Rolul A (Forma politicii AdministratorAccess)

Citește orice bucket
Folosește orice cheie
Actualizează orice funcție

Rolul B

Citește un bucket
Folosește o cheie
Actualizează o funcție

Prefix: o cale asemănătoare unui folder în interiorul unui bucket

O imagine care arată un rol cu acces total, cu acces la șase politici diferite.

O imagine care arată un rol cu acces restrâns, cu acces la o singură politică.

Raza de impact

Rol larg

Dacă este compromis: ajunge la orice bucket, prefix și obiect din cont.

Rol restrâns

Dacă este compromis: ajunge la un singur prefix, dintr-un singur bucket. Nimic mai mult.

Inele concentrice ilustrând un rol larg care ajunge la fiecare parte din întregul cont.

Inele concentrice ilustrând că un rol restrâns ajunge doar la inelele interioare de obiect și prefix, lăsând celelalte părți neatinse.

Privilegiul minim, în practică

Un rol trebuie să facă exact ce cere sarcina lui, și foarte puțin în plus.

Gestionate de AWS, precum AmazonS3ReadOnlyAccess: orice bucket. Gestionate de client: ale tale, până la un singur prefix
Limitează acoperirea și durata de viață: credențiale de scurtă durată, nu chei de lungă durată
AWS securizează infrastructura
Cât de largi sunt rolurile tale este decizia ta, și se reflectă în repository-ul tău

Exemplu: un rol de citire pentru reports-bucket Două permisiuni allow. Nimic altceva acordat.

Nimic legat de IAM, serviciul care decide cine ce poate face

Lista de permisiuni a unui rol, cu trei permisiuni în exces tăiate cu roșu și două permisiuni necesare păstrate cu verde.

Hai să exersăm!

Securitatea AWS pentru dezvoltatori