Mënyra e duhur për të paraqitur organizatën tuaj në AWS

Kompanitë janë të ndërlikuara dhe kërkon shumë më shumë konfigurim për të menaxhuar llogaritë AWS të qindra njerëzve. Në këtë artikull, ne diskutojmë praktikat më të mira për menaxhimin e aksesit të sigurt në burimet e organizatës suaj pa i penguar zhvilluesit tuaj me burokraci.

Përdorni Përdoruesit e IAM për llogaritë e punonjësve

Nëse keni përdorur më parë AWS, ndoshta jeni njohur me përdoruesit e IAM. Ato janë në thelb llogari shërbimi që përdoren për të vërtetuar gjërat që funksionojnë në serverë të largët dhe për t'i lejuar ata të aksesojnë burimet AWS që u nevojiten (vendosja e gjërave në një kovë S3, ekzekutimi i funksioneve lambda, etj.) pa dhënë akses të plotë në llogarinë tuaj kryesore. Në këtë mënyrë, nëse serverët tuaj komprometohen (nga një haker ose punonjës mashtrues), ndërhyrësi ka qasje vetëm në lejet që keni dhënë.

Përdoruesit e IAM janë të shkëlqyeshëm dhe janë gjithashtu të dobishëm për t'i dhënë punonjësve akses në shërbimet që u nevojiten. Kur krijoni një përdorues IAM, ju keni mundësinë të aktivizoni aksesin e tastierës së menaxhimit (në krahasim me aksesin CLI/API), i cili ju mundëson t'i jepni llogarinë një punonjësi dhe t'i mundësoni të hyjnë në tastierën e menaxhimit me leje të kufizuara. Mund të aktivizoni madje Autentifikimin me shumë faktorë (MFA) për përdoruesit e IAM me akses në konsolë, duke i bërë ata shumë të sigurt.

Megjithatë, çështja kryesore është se punonjësit që përdorin llogaritë IAM nuk do të jenë në gjendje të krijojnë përdoruesit e tyre IAM pa ndihmën e llogarisë rrënjësore. Nëse keni një menaxher projekti i cili duhet t'i japë akses të sigurt S3 PUT në një aplikacion, ai duhet t'i kërkojë mbajtësit të llogarisë rrënjësore të krijojë një përdorues krejtësisht të ri IAM posaçërisht për atë leje. Duke marrë parasysh që mbajtësi i llogarisë rrënjësore zakonisht është pronari, CTO ose dikush i lartë, është një humbje masive e kohës, veçanërisht nëse nuk po prekni as prodhimin.

Përndryshe, Përdoruesit e IAM janë mënyra më e mirë për të dhënë akses të menaxhuar në shërbime të caktuara. Ju mund të krijoni grupe IAM, të cilat janë të dobishme për të përcaktuar lejet që ka çdo rol në organizatën tuaj. Çfarëdo që të bëni, thjesht mbani mend parimin e Lejet më të vogla - çdo llogari duhet të ketë vetëm lejet që i nevojiten për të kryer punën e saj në mënyrë efektive, asgjë më shumë. Gjithashtu, sigurohuni që të mos i jepni akses IAM përdoruesve të IAM-it, përndryshe ata mund të përshkallëzojnë privilegjet.

Ndarja e mjediseve të zhvillimit dhe prodhimit

Zgjidhja për problemin e sigurisë së ndryshme është Organizatat AWS. Ky shërbim ju mundëson të administroni shumë llogari të ndryshme nën një llogari rrënjësore, të kompletuar me faturim të konsoliduar (përdoruesi kryesor paguan për çdo llogari fëmijësh).

Kufiri i paracaktuar është katër llogari, gjë që i bën organizatat të pamundura për t'u përdorur si llogari individuale të punonjësve. Nuk do të kishte shumë kuptim ta bëni këtë gjithsesi, pasi secila llogari është e ndarë nga të tjerat dhe nuk do të jetë në gjendje të shohë shërbimet ose serverët e nisur në llogari të tjera. Ju mund të kërkoni një rritje kufiri nëse keni nevojë për më shumë mjedise, por AWS dëshiron që ju të përdorni përdoruesit e IAM për punonjësit.

Ajo për të cilën ka për qëllim Organizatat AWS është ndarja e mjediseve të zhvillimit dhe prodhimit. Për çdo mjedis zbatohen rregulla të ndryshme; për shembull, ju mund të dëshironi t'i kufizoni punonjësit nga krijimi i përdoruesve të rinj të IAM-it pa kaluar nëpër të gjitha kanalet e duhura dhe pa u konsultuar me drejtuesit më të lartë, por në zhvillim nevoja për të kaluar nëpër të gjitha këto kontrolle thjesht do të ngadalësonte zhvilluesit. Ju mund të zgjidhni t'u jepni menaxherëve të projektit tuaj qasje në llogarinë e zhvillimit për të mundësuar testimin më të shpejtë.

Për sa i përket hierarkisë, llogaria kryesore vepron si rrënja e pemës dhe merret me krijimin e llogarive të reja. Llogaritë mund të renditen në njësi organizative, të cilat veprojnë si grupe dhe aplikojnë lejet për secilën llogari nën të. Këto mund të futen sipas dëshirës (nëse keni edhe llogari të mjaftueshme për ta bërë këtë).

Rekomandimi i AWS këtu është ndoshta se si duhet të duket organizata juaj. Ju keni llogarinë kryesore të prodhimit, e cila është shumë e sigurt dhe plotësisht e aksesueshme vetëm nga menaxhmenti i sipërm. Mjedisi Test ose Staging funksionon si një pasqyrë e prodhimit dhe është i aksesueshëm nga inxhinierët tuaj cilësorë dhe kushdo tjetër që po bën testimin përpara se të shtyjë ndryshimet në prodhim. Ju mund të zgjidhni t'i ndani këto në dy mjedise të veçanta: testi është për testim të automatizuar me të dhëna të rreme (funksionalisht një zgjerim i zhvillimit, por më i pastër) dhe vendosja në skenë është një pasqyrë e plotë e prodhimit duke përfshirë të dhënat e klientit dhe aksesin në API-të reale publike.

Pastaj ju keni zhvillim, i cili është i aksesueshëm nga menaxherët e projektit tuaj dhe zhvilluesit nën ta. Ky mjedis ka leje shumë më të dobëta, pasi siguria e përgjithshme e tij nuk ka aq rëndësi sa prodhimi. Çdo bazë e të dhënave e krijuar në zhvillim (ose testim, për këtë çështje) nuk duhet të përfshijë të dhënat e klientit.

Shumica e zhvilluesve tuaj ndoshta operojnë nga llogaritë personale IAM në mjedisin e zhvillimit, duke u dhënë atyre akses shumë më të plotë sesa do të merrnin ndryshe në prodhim. Ju ndoshta dëshironi t'u jepni leje zhvilluesve tuaj për të përdorur shumicën e shërbimeve që përdorni në prodhim (thjesht mbani një sy në gjërat për të siguruar që përdorimi është nën kontroll).

Njësitë organizative (OU) ju mundësojnë gjithashtu të kufizoni lejet e çdo llogarie, duke përdorur Politikat e Kontrollit të Shërbimit (SCP). SCP-të janë shumë si politikat e IAM-it, por një nivel më i lartë—ato zbatohen për të gjithë llogarinë nën to. Nëse llogaria e zhvillimit krijonte një përdorues IAM që kishte akses në S3, por S3 nuk ishte i aktivizuar në SCP, ai përdorues IAM nuk do të mund të përdorte S3 në atë llogari. Shërbimet janë refuzuar si parazgjedhje, kështu që ju duhet t'i vendosni manualisht në listën e bardhë për t'i përdorur ato.

Një llogari AWS për OU duhet të jetë e mirë për shumicën e aplikacioneve, por ju keni mundësinë të krijoni më shumë. Nëse dëshironi të keni një mjedis të veçantë zhvillimi për ekipe të ndryshme, mund të krijoni dy ose më shumë llogari zhvillimi nën një OU. Edhe me vetëm një llogari, ju mund të menaxhoni lejet me rregullat e SCP.

Rishikoni rregullisht sigurinë e organizatës suaj

Nëse po krijoni një organizatë në AWS, shpejt do të hasni në çështjen e nevojës për të kryer kontrolle të rregullta sigurie për t'u siguruar që gjithçka është e sigurt. AWS ofron një listë kontrolli sigurie që duhet ta lexoni dhe të siguroheni që jeni në përputhje me gjithçka. Edhe diçka aq e thjeshtë sa të kontrollosh se çdo përdorues është në vendin e duhur është praktikë e mirë.

Nëse dikush largohet nga kompania, duhet të siguroheni që çdo llogari e lidhur IAM të jetë çaktivizuar ose transferuar. Nëse dikush ndryshon rolet, duhet të siguroheni gjithashtu që politikat e llogarisë së tij të pasqyrojnë atë rol dhe që të mos kenë leje të mbetura nga punët e vjetra.

Ju gjithashtu duhet të siguroheni që lejet SCP janë vendosur saktë për çdo OU dhe nuk ndryshojnë shumë me kalimin e kohës. Ju nuk dëshironi që mjedisi i zhvillimit të jetë në gjendje të marrë me qira 20 raste c5d.24xlarge dhe ta çojë faturën tuaj në çati.