Skanowanie IaC: fantastyczna, przeoczona okazja do nauki

Wszystko, co czytasz na temat infrastruktury jako kodu (IaC), koncentruje się na tym, jak ona działa lub dlaczego chcesz się upewnić, że faktycznie buduje się tak, jak chcesz.

To są obszary krytyczne. Ale czy wystarczająco myślimy o tym, jak zastosować to podejście w naszej organizacji?

As Melinda Marks z raportu ESG wynika, że ​​„83% organizacji odnotowało wzrost liczby błędnych konfiguracji szablonów IaC” w miarę dalszego wdrażania tej technologii.

Wiemy z pracy wykonanej przez Cloud Security Alliance („Najważniejsze zagrożenia dla przetwarzania w chmurze: rażąca jedenaście„) i innych, błędne konfiguracje nadal stanowią największe ryzyko w chmurze.

Obsługiwany jest IaC zmniejszyć
błędnych konfiguracji poprzez usystematyzowanie tworzenia infrastruktury, dodanie poziomu rygoru i procesu, który gwarantuje, że zespoły budują to, czego chcą i tylko to, czego chcą. Jeśli około 83% zespołów tego nie widzi, oznacza to, że problem leży w głębszym kontekście.

Ma to sens w mniejszych zespołach, w których elementy filozofii DevOps i DevOps są ze sobą połączone. IaC pozwala tym małym zespołom używać tego samego języka – kodu – do opisu wszystkiego, co robią.

Właśnie dlatego widzimy w nim abstrakcje jeszcze wyższego poziomu niż narzędzia takie jak Terraform czy AWS CloudFormation CDK AWS i projekty takie jak CDK8s. Te abstrakcje wysokiego poziomu są wygodniejsze dla programistów.

Perspektywa ops/SRE/platformy usługi w chmurze będzie znacznie odmienna od perspektywy programisty tej samej usługi. Programista przyjrzy się usłudze kolejkowania i zagłębi się w jej interfejs — prosty punkt końcowy do dodania i jeden do odczytania? Sprzedany. To łatwa integracja.

Ta perspektywa operacyjna ma na celu znalezienie krawędzi. Kiedy zatem ta kolejka osiąga swój limit? Czy wydajność jest stała, czy zmienia się radykalnie pod obciążeniem?

Tak, istnieją nakładające się obawy. I tak, jest to uproszczony pogląd. Ale pomysł jest aktualny. IaC rozwiązuje wiele problemów, ale może również powodować i wzmacniać rozdźwięk między zespołami. Co ważniejsze, może uwypuklić rozbieżność między intencją tego, co próbujesz zbudować, a rzeczywistością tego, co zbudowałeś.

W rezultacie w tym miejscu często nasilają się obawy dotyczące bezpieczeństwa.

Większość narzędzi — komercyjnych lub open source — koncentruje się na identyfikowaniu błędów w szablonach infrastruktury. To zdjęcie
to dobry konstrukt. Zrobienie to
byłoby źle. Narzędzia te mają na celu generowanie tych wyników w ramach procesu ciągłej integracji/ciągłego dostarczania (CI/CD).

To świetny początek. Ale powtarza ten sam problem językowy.

Kto mówi, a kto słucha?

Kiedy narzędzie IaC zwróci uwagę na problem, kto się nim zajmie? Jeśli jest to zespół programistów, czy ma wystarczające informacje, aby wiedzieć, dlaczego oznaczono to jako problem? Jeśli jest to zespół operacyjny, czy w raporcie przedstawiono konsekwencje problemu?

W przypadku programistów często zdarza się, że po prostu dostosowują konfigurację, aby testy IaC przebiegły pomyślnie.

W przypadku operacji zazwyczaj chodzi o to, czy testy wypadną pomyślnie. Jeśli tak, przejdź do następnego zadania. To nie jest cios dla żadnej drużyny; raczej podkreśla rozbieżność oczekiwań i rzeczywistości.

Potrzebny jest kontekst. Narzędzia bezpieczeństwa IaC zapewniają wgląd w to, co (miejmy nadzieję) zostanie wkrótce zbudowane. Celem jest zatrzymanie problemów zanim trafiają do produkcji.

Dzisiejsze narzędzia bezpieczeństwa IaC podkreślają rzeczywiste problemy, którymi należy się zająć. Wykorzystywanie wyników tych narzędzi i wzbogacanie ich o dodatkowy kontekst specyficzny dla zespołu odpowiedzialnego za kod to doskonała okazja do niestandardowej automatyzacji.

Pomoże to również wypełnić lukę językową. Dane wyjściowe narzędzi są zasadniczo w trzecim języku — żeby jeszcze bardziej skomplikować sprawę — i należy je przekazać w sposób zrozumiały zarówno dla odbiorców zajmujących się rozwojem, jak i operacjami. Często oba.

Na przykład, gdy skanowanie wskazuje, że reguła grupy zabezpieczeń nie ma opisu, jakie to ma znaczenie? Samo otrzymanie alertu z informacją „Dodaj opis kontekstu” nie pomoże nikomu w lepszym tworzeniu.

Tego typu flaga to świetna okazja do edukacji zespołów budujących w chmurze. Dodanie wyjaśnienia, że ​​reguły grupy zabezpieczeń powinny być jak najbardziej szczegółowe, zmniejsza ryzyko złośliwych ataków. Podaj odniesienia do przykładów silnych reguł. Wywołaj to, nie znając intencji, a inne zespoły nie będą mogły przetestować ważności potwierdzenia bezpieczeństwa.

Bezpieczeństwo jest obowiązkiem każdego, więc uznanie luki językowej pomiędzy programistami a operacjami uwypukli takie możliwości, jak dodanie prostych automatyzacji, które zapewnią wgląd Twoim zespołom. Pomoże to ulepszyć to, co opracowują, i w rezultacie zapewni lepsze wyniki w zakresie bezpieczeństwa.

O autorze

Jestem kryminalistą, mówcą i analitykiem technologii, który stara się pomóc Ci zrozumieć cyfrowy świat i jego wpływ na nas. Dla zwykłych użytkowników moja praca pomaga wyjaśnić wyzwania stojące przed cyfrowym światem. Jak duży wpływ na Twoją prywatność ma korzystanie z mediów społecznościowych? Co to znaczy, że w naszych społecznościach zaczynają być stosowane technologie takie jak rozpoznawanie twarzy? Pomagam odpowiedzieć na tego typu pytania i nie tylko. Osobom tworzącym technologię pomagam im zastosować w pracy perspektywę bezpieczeństwa i prywatności, aby umożliwić użytkownikom podejmowanie jaśniejszych decyzji dotyczących ich informacji i zachowania. Jeśli chodzi o prywatność i bezpieczeństwo, panuje mnóstwo zamieszania. Nie powinno być. Sprawiam, że bezpieczeństwo i prywatność są łatwiejsze do zrozumienia.