Jak zbudować bezpieczną i niezawodną architekturę chmury AWS bez utraty zmysłów?

Wprowadzenie

Jeśli kiedykolwiek próbowałeś zaprojektować architekturę chmury w AWS od zera, prawdopodobnie już wiesz: to w równym stopniu wolność i chaos. Istnieje tysiąc sposobów na zbudowanie czegoś i tyle samo sposobów na spieprzenie tego.

Krótkie spojrzenie na dokumentację AWS może sprawić, że pomyślisz: "Fajnie, po prostu będziemy przestrzegać najlepszych praktyk". Ale w rzeczywistych środowiskach międzynarodowych, najlepsze praktyki często nie są w pierwszym kontakcie z rzeczywistymi potrzebami przedsiębiorstw komercyjnych, ograniczeniami cenowymi lub błędami ludzkimi. Dlatego wczesna współpraca z profesjonalistami, takimi jak perfsys, może zapobiec późniejszemu hazardowi z dziurami w zabezpieczeniach i komplikacjami związanymi ze skalowaniem.

Celem nie jest po prostu uzyskanie czegoś, co działa. Celem jest zbudowanie systemu, który nie przewróci się, gdy ruch wzrośnie lub region wyłączy się - i nie pozostawi szeroko otwartych drzwi wejściowych do Internetu.

Zacznijmy od oczywistości: AWS to bestia

Za pomocą AWS można zbudować praktycznie wszystko. Od dwuosobowych startupów po rozległe platformy korporacyjne, wszystkie bloki konstrukcyjne są dostępne - EC2, Lambda, RDS, S3, IAM, VPC, lista jest długa. Haczyk? Im więcej masz opcji, tym łatwiej jest stworzyć poplątany bałagan.

Nie chodzi o to, że AWS jest źle zaprojektowany. Po prostu trzeba go odpowiednio zaprojektować. W przeciwnym razie otrzymasz to, co niektóre zespoły nazywają "spaghetti w chmurze": współzależne usługi, zakodowane sekrety, brak tagowania, brak logowania i absolutnie nie wiadomo, co ile kosztuje.

Niezawodność i bezpieczeństwo nie należą do rzeczy przyjemnych

Kuszące jest traktowanie bezpieczeństwa i niezawodności jako przyszłego problemu. "Zabezpieczymy to po uruchomieniu". "Dodamy monitorowanie w następnym sprincie". Ale zapytaj każdego, kto miał do czynienia z naruszeniem danych lub wielogodzinną awarią - pomijanie tych kroków kończy się całonocnymi nocami.

Co naprawdę oznacza niezawodność

Nie chodzi tu o gwarancje dostępności na slajdach. Chodzi o inżynierię na wypadek awarii. Usługi przestają działać. Dyski zawodzą. Interfejsy API przestają działać. Liczy się to, czy system nadal działa, gdy coś się zepsuje.

Czy masz redundancję w strefach dostępności? Czy system może tolerować awarię węzła bazy danych bez utraty danych lub błędów? Czy krytyczne obciążenia są uruchamiane w jednym regionie, ponieważ "tak było najłatwiej"? Są to pytania, które oddzielają działające systemy od tych odpornych.

A bezpieczeństwo? To nie tylko IAM

Tak, zarządzanie tożsamością i dostępem (IAM) to pierwsza ściana. Ale bezpieczeństwo wykracza daleko poza to. Publicznie dostępne wiadra S3. Role z nadmiernymi uprawnieniami. Sekrety zakodowane na stałe w funkcjach Lambda. Logowanie wyłączone "w celu obniżenia kosztów". Wszystko to są bomby zegarowe.

Korzystanie z dobrze zaprojektowanej architektury aws może pomóc zidentyfikować te problemy, zanim wybuchną. Rozbija architekturę na pięć kluczowych obszarów - bezpieczeństwo, niezawodność, doskonałość operacyjną, wydajność i optymalizację kosztów - i zmusza zespoły do uczciwej oceny każdego z nich. Nie jest to srebrna kula, ale zmusza do zadawania trudnych pytań.

Elementy składowe, które faktycznie mają znaczenie

W porządku, przejdźmy do sedna sprawy. Oto, co ma znaczenie podczas budowania bezpiecznej, niezawodnej architektury w AWS - i gdzie zespoły najczęściej popełniają błędy.

Używaj ról IAM we właściwy sposób (tak, naprawdę)

Role IAM są potężne. Czasami nawet zbyt potężne. Zbyt łatwo jest założyć "AdministratorAccess", ponieważ coś nie działa, obiecać, że naprawi się to później... a potem nigdy tego nie naprawić.

Trzeba to wcześnie zablokować. Zasada najmniejszych uprawnień to nie tylko najlepsza praktyka - to jedyny rozsądny sposób działania. To znaczy:

• Role podzielone na usługi

• Unikanie symboli wieloznacznych w uprawnieniach

• Krótkotrwałe poświadczenia

• Obowiązkowe uwierzytelnianie wieloskładnikowe dla użytkowników

Brzmi jak ból? To prawda. Ale tak samo jak wyjaśnianie szefowi, dlaczego ktoś wyprowadził dane klientów z błędnie skonfigurowanej Lambdy.

Oddziel swoją sieć tak, jak chcesz

To kolejny obszar, w którym skróty przynoszą odwrotny skutek. Nie potrzebujesz super złożonej konfiguracji sieci, ale pewne podstawy mogą się przydać:

• Podsieci publiczne tylko dla rzeczy, które muszą mieć dostęp do Internetu (np. ALB)

• Podsieci prywatne dla całej reszty

• Bramy NAT dla kontrolowanego dostępu wychodzącego

• Punkty końcowe VPC dla ruchu usług AWS bez wchodzenia do publicznego Internetu.

Płaski VPC ze wszystkim w tej samej podsieci może wydawać się łatwy. Dopóki coś się nie zepsuje i nie zabierze wszystkiego ze sobą.

Rejestrowanie i monitorowanie: Nie możesz naprawić tego, czego nie widzisz

To nie powinno być już nawet przedmiotem debaty. Rejestrowanie nie jest opcjonalne. Jeśli nie przechwytujesz CloudTrail, metryk CloudWatch i dzienników przepływu VPC, lecisz na ślepo.

Ale tu jest haczyk - samo rejestrowanie nie wystarczy. Musisz faktycznie przeglądać dzienniki. Tworzyć alerty dla rzeczy, które mają znaczenie. Odfiltrować szum. I upewnić się, że dzienniki są scentralizowane na różnych kontach i w różnych regionach. Fragmentaryczna widoczność to brak widoczności.

Szyfruj wszystko (bez wyjątków)

Używaj KMS dla danych w spoczynku. Używaj TLS dla danych w tranzycie. Rotacja kluczy. Monitoruj dostęp. Jest to jeden z tych obszarów, w których bycie leniwym teraz staje się bardzo kosztowne później.

Nie zapominaj też o takich rzeczach jak szyfrowanie RDS, ustawienia wolumenów EBS i egzekwowanie TLS API Gateway. Te drobne szczegóły się kumulują.

Infrastruktura jako kod lub porażka

Nadal wdrażasz, klikając w konsoli AWS? To dobre dla deweloperów, niebezpieczne dla prod.

Użyj Terraform, CloudFormation lub CDK. Cokolwiek preferuje Twój zespół - po prostu wybierz jedno i trzymaj się go. Kontroluj wersje swoich szablonów. Używaj CI/CD do wdrażania. Zautomatyzuj wycofywanie. Ręczne wdrożenia to otwarte zaproszenie do błędów.

Ponadto: oznaczaj wszystko. Zasoby bez tagów są jak kable bez etykiet - nikt nie wie, do czego służą i każdy boi się ich dotknąć.

Skalowanie bez zatapiania

Postawmy sprawę jasno: AWS uwielbia nadmiar zasobów. Ty dostajesz "wydajność", oni dostają twoje pieniądze. Efektywne skalowanie polega na znajomości wzorców - i planowaniu ich.

Używaj grup automatycznego skalowania, instancji punktowych (ostrożnie) i warstw buforowania. Ale co ważniejsze: testuj pod obciążeniem. Ostatnią rzeczą, jakiej chcesz, jest odkrycie, że twoja instancja RDS topi się pod rzeczywistym ruchem dwa dni po uruchomieniu.

Ponadto rezerwuj pojemność, gdy ma to sens. Oszczędza to pieniądze i zapobiega niespodziewanym awariom provisioningu.

Plany odzyskiwania po awarii nie są opcjonalne

Co się stanie, jeśli region ulegnie awarii? Co jeśli podstawowa baza danych zostanie uszkodzona? Jeśli odpowiedź brzmi "hmm... mielibyśmy kłopoty", to nadszedł czas, aby przerobić swoją strategię DR.

Nie oznacza to budowania identycznej kopii infrastruktury w innym regionie. Oznacza to wiedzę:

• Co można przywrócić

• Jak długo to potrwa

• Jakie dane zostaną utracone (jeśli w ogóle)

• Kto jest odpowiedzialny za co podczas przełączania awaryjnego

I tak - powinieneś przetestować swój plan odzyskiwania. W przeciwnym razie to tylko fikcja.

Powszechne antywzorce, których należy unikać

Przeanalizujmy kilka nie-nie, które pojawiają się zbyt często:

• Jedno duże konto do wszystkiego: użyj AWS Organizations. Oddzielne prod, dev, staging itp.

• Pozostawienie domyślnych VPC i grup zabezpieczeń nietkniętych: zablokuj je.

• Nadmierne poleganie na instancjach t2.micro "do testowania" - ostatecznie trafią one do prod.

• Nieuwzględnianie w budżecie kosztów CloudWatch: tak, logowanie kosztuje. Brak logowania kosztuje więcej.

• Udzielanie dostępu do "po prostu napraw to szybko": zamiast tego napraw swój proces.

Ostatnie słowa? Zachowaj elastyczność, zachowaj zdrowy rozsądek

Architektura chmury nie polega na znalezieniu idealnej konfiguracji. Chodzi o zbudowanie czegoś, co jest elastyczne, solidne i zrozumiałe nie tylko dla osoby, która je napisała.

Nigdy tak naprawdę nie jesteś "skończony" - i to jest w porządku. Liczy się intencjonalność. Wczesne zadawanie trudnych pytań. Częste przeprowadzanie audytów. Automatyzacja tam, gdzie ma to znaczenie. I wiedzieć, kiedy wezwać pomoc.

Bo bądźmy szczerzy - AWS jest potężny, ale łatwo się w nim zgubić. Praca z doświadczonymi inżynierami, którzy żyją i oddychają architekturą chmury, może stanowić różnicę między "to działa, w większości przypadków" a "śpimy w nocy".

A to jest warte budowania.