Checklista wdrożeń na AWS, część 1: sekrety i dane uwierzytelniające
Na początku tego tygodnia Vercel potwierdził, że atakujący dostali się do ich wewnętrznych systemów. Ktoś podający się za ShinyHunters wystawił na sprzedaż kod źródłowy, klucze API, tokeny NPM i tokeny GitHub. Rada Vercel dla klientów: przejrzyjcie zmienne środowiskowe.
Rada słuszna. Tyle że dla firm, które trzymały tam credentials do produkcyjnej bazy, klucze Stripe i sekrety OAuth — spóźniona. Te dane są potencjalnie już w cudzych rękach.
Ale włamanie do Vercel uwypukliło wzorzec, który widzimy w niemal każdym środowisku AWS, które audytujemy: sekrety porozrzucane po platformach, credentials z nadmiernymi uprawnieniami, brak planu rotacji i brak jasnego obrazu, co jest wystawione na ryzyko, jeśli którekolwiek ogniwo w łańcuchu pęknie.
To pierwsza część naszej checklisty wdrożeń AWS. Zaczynamy od sekretów, bo to one najczęściej decydują o różnicy między „słyszeliśmy o breach" a „to my byliśmy tym breachem".
1. Przestań trzymać sekrety produkcyjne w zmiennych środowiskowych platformy
Zmienne środowiskowe w platformie deploymentowej — Vercel, Netlify, GitHub Actions, cokolwiek — są wygodne. Są też jednym punktem kompromitacji. Kiedy tę platformę zhackują, każdy sekret w każdej zmiennej jest potencjalnie ujawniony.
Do wszystkiego, co ma znaczenie, używaj AWS Secrets Manager lub Systems Manager Parameter Store. Credentials do bazy, klucze API, klucze szyfrowania, tokeny serwisów — to należy do menedżera sekretów z logowaniem dostępu, nie do pola tekstowego w panelu platformy.
Narzut jest minimalny. Aplikacja czyta z Secrets Managera przy starcie zamiast z process.env. Różnica w bezpieczeństwie — ogromna.
2. Oddziel credentials per środowisko — naprawdę oddziel
Większość zespołów ma osobne zmienne dla dev, staging i produkcji. Spora część tych zespołów używa tych samych credentials do bazy na stagingu i produkcji, tego samego klucza Stripe albo tego samego tokena GitHub z tymi samymi uprawnieniami.
Jeśli Twój deployment preview ma credential, który sięga do danych produkcyjnych — Twoje środowisko preview jest powierzchnią ataku na produkcję. Breach, źle skonfigurowany branch, atak na supply chain w zależności buildu preview — każda z tych rzeczy staje się incydentem produkcyjnym.
Inne credentials per środowisko. Inni użytkownicy bazy. Inne klucze API. Bez wyjątków.
3. MFA na root. IAM users do codziennej pracy. Żadnych współdzielonych kont.
To powinno być oczywiste, ale wciąż to widzimy: zespoły używające root do codziennej pracy, dzielące jednego IAM usera między kilka osób, IAM users bez MFA.
Root: MFA włączone, credentials schowane, używany wyłącznie do bilingu i operacji na poziomie konta. Codzienna praca: indywidualni IAM users, każdy z MFA, każdy z uprawnieniami ograniczonymi do tego, czego faktycznie potrzebuje. Współdzielony user „deploy", do którego hasło znają trzy osoby: usuń go.
Jeśli nie możesz powiązać akcji w CloudTrail z konkretną osobą — Twoja kontrola dostępu jest zepsuta.
4. Ogranicz każdy credential do niezbędnego minimum
Token GitHub podpięty do CI/CD — ma uprawnienia zapisu do każdego repozytorium w organizacji? IAM user obsługujący deploymenty — ma AdministratorAccess? Connection string do bazy — korzysta z użytkownika root?
Odpowiedź na wszystkie trzy pytania zwykle brzmi tak. A powinna brzmieć nie.
Każdy credential powinien mieć minimalne uprawnienia wymagane do swojego konkretnego zadania. Pipeline deploymentowy potrzebuje uprawnień do aktualizacji konkretnych serwisów, nie admina do całego konta AWS. Połączenie bazodanowe webówki potrzebuje read/write na swoich tabelach, nie GRANT ALL.
Poprawienie tego zajmuje jedno popołudnie i drastycznie zmniejsza promień rażenia, kiedy — nie jeśli — credential zostanie skompromitowany.
5. Włącz CloudTrail i faktycznie na niego patrz
CloudTrail loguje każde wywołanie API na Twoim koncie AWS. To różnica między „ktoś się włamał i nie wiemy co się stało" a „ktoś się włamał i wiemy dokładnie, które credentials zostały użyte, co zostało odczytane i kiedy".
Włącz go. Logi do S3. Trail pokrywający wszystkie regiony, nie tylko ten, którego używasz. CloudTrail Insights, jeśli chcesz detekcję anomalii bez budowania jej samemu.
I — tu większość zespołów odpada — faktycznie go przeglądaj. Ustaw alarmy CloudWatch na podejrzane wzorce: użycie konta root, logowania z konsoli z nieoczekiwanych lokalizacji, wywołania API z nieznanych zakresów IP. Te alerty nie kosztują nic w konfiguracji i są bezcenne, kiedy się uruchomią.
6. Zautomatyzuj rotację credentials
Ręczna rotacja credentials oznacza rotację, która się nie odbywa. Hasło do bazy ustawione dwa lata temu, które siedzi w czterech plikach konfiguracyjnych w trzech środowiskach — to jest credential, który zostanie skompromitowany.
Secrets Manager obsługuje automatyczną rotację credentials RDS od razu po wyjęciu z pudełka. Dla innych sekretów zbuduj Lambdę rotacyjną albo użyj zaplanowanego pipeline'u. Cel: żaden credential nie żyje dłużej niż 90 dni, a jego rotacja nie wymaga deploymentu ani restartu.
Jeśli automatyczna rotacja to na razie za dużo — zacznij od przypomnienia w kalendarzu i udokumentowanej procedury. To nie jest tak dobre, ale nieskończenie lepsze niż „kiedyś się za to zabierzemy".
7. Znaj swój promień rażenia
Jeśli ktoś teraz zdobędzie credentials z Twojej platformy deploymentowej — do czego ma dostęp? Jeśli ktoś przejmie sekrety z pipeline'u CI/CD — do czego sięgnie? Jeśli laptop dewelopera zostanie skompromitowany — jakie credentials są na nim lokalnie?
Narysuj diagram. Dla każdego sekretu, którym zarządzasz, odpowiedz: gdzie jest przechowywany, kto ma dostęp, do czego daje dostęp, kiedy był ostatnio rotowany.
Jeśli odpowiedź na „co dostaje atakujący?" brzmi „wszystko" — masz ryzyko koncentracji, którym trzeba się zająć zanim nadejdzie kolejny Vercel, kolejny SolarWinds, kolejny CodeCov.
8. Miej plan reakcji na kompromitację credentials
Nie ogólny plan reagowania na incydenty. Konkretna, udokumentowana odpowiedź na pytanie: „Platforma, z której korzystamy, została zhackowana i nasze credentials mogą być ujawnione. Co robimy w ciągu najbliższej godziny?"
Plan powinien zawierać: listę każdego credentiala przechowywanego w każdej platformie, sposób rotacji każdego z nich, osobę odpowiedzialną za każdą rotację, serwisy wymagające restartu i osoby do powiadomienia.
Kiedy w tym tygodniu pojawiła się informacja o Vercel, dobrze przygotowane zespoły otworzyły dokument, przeszły listę i miały wszystko zrotowane w ciągu godziny. Reszta wciąż się zastanawia.
To pierwsza część naszej serii checklisty wdrożeń AWS. Następna: zabezpieczenia kosztowe i higiena billingowa — jak sprawić, żeby AWS nie zaskoczył Cię rachunkiem trzy razy wyższym niż oczekiwany.
W Otocolobus audytujemy środowiska AWS pod kątem dokładnie takich problemów — rozsypane sekrety, nadmiarowe uprawnienia, brak polityk rotacji. Chcesz wiedzieć, gdzie masz luki, zanim ktoś inny je znajdzie — odezwij się.