Przyjmij kluczowe zasady planowania bezpiecznego wytwarzania oprogramowania

W tym artykule zdefiniowano kluczowe imperatywy dotyczące integrowania zabezpieczeń z praktykami programistycznymi w ramach dziedziny Zabezpieczenia programowania.

Nowoczesne organizacje polegają na szybkim tworzeniu oprogramowania w celu dostarczania innowacji, spełnienia wymagań biznesowych, utrzymania przewagi konkurencyjnej i reagowania na zmieniające się potrzeby biznesowe. Chociaż metodyka DevOps zapewnia tę elastyczność, wprowadza również nowe zagrożenia bezpieczeństwa, ponieważ procesy kodu, infrastruktury i wdrażania ewoluują szybciej.

Aby bezpiecznie wdrożyć rozwiązania DevOps, organizacje muszą zintegrować zabezpieczenia ze strategią programowania, przepływami pracy i procesami dostarczania oraz wdrożyć praktyki DevSecOps, które zabezpieczają dostarczanie aplikacji w całym cyklu życia.

Wyniki

Przyjęcie imperatywów planowania w tym artykule umożliwia organizacjom:

• Zmniejsz wprowadzanie słabych stron zabezpieczeń w obciążeniach produkcyjnych.
• Zwiększ spójność decyzji dotyczących gotowości produkcyjnej.
• Zmniejsz tarcie między programowaniem, zabezpieczeniami i operacjami.
• Zwiększanie odporności aplikacji i infrastruktury dostarczania.
• Utrzymaj szybkość innowacji podczas zarządzania ryzykiem bezpieczeństwa i działania.

Rozpoznawanie zakresu zabezpieczeń programowania

Zabezpieczenia programistyczne mają zastosowanie do więcej niż kodu aplikacji. Organizacje powinny definiować wymagania i działania dotyczące zabezpieczeń we wszystkich składnikach związanych z projektowaniem, tworzeniem, wdrażaniem i obciążeniami operacyjnymi.

Organizacje muszą uwzględniać zagrożenia bezpieczeństwa w ramach:

• Logika aplikacji i usługi
• Automatyzacja infrastruktury/Wdrożenia infrastruktury jako kodu (IaC)
• Potoki kompilacji i wydania
• Konfiguracje wdrożenia i skrypty operacyjne
• Środowiska deweloperskie i tożsamości usług
• Zależności innych firm i składniki łańcucha dostaw

Rozpoznawanie tego pełnego zakresu pomaga organizacjom definiować wymagania dotyczące zabezpieczeń, które odzwierciedlają sposób dostarczania nowoczesnych obciążeń, zamiast ograniczać zabezpieczenia do przeglądu kodu aplikacji pod koniec cyklu życia.

Uwzględnianie kluczowych czynników ryzyka

Organizacje powinny jawnie uwzględniać następujące zagrożenia podczas definiowania wymagań:

Te czynniki ryzyka bezpośrednio informują o imperatywach planowania zdefiniowanych w tym artykule i muszą zostać rozwiązane za pomocą decyzji dotyczących projektowania, procesu i ładu.

Te zagrożenia wpływają zarówno na obciążenia aplikacji, jak i infrastrukturę używaną do ich kompilowania i obsługi.

Integrowanie zabezpieczeń ze strategią/cyklem życia

Zabezpieczenia muszą być włączone do strategii programowania, a nie stosowane jako kontrola po wydaniu.

Organizacje muszą definiować wymagania dotyczące zabezpieczeń wraz z wymaganiami funkcjonalnymi i dostosowywać je do:

• Strategia programowania
• Planowanie architektury
• Przepływy pracy dostarczania
• Modele obsługi operacyjnej

Wyniki zabezpieczeń to wspólne obowiązki należące do ról inżynieryjnych i operacyjnych, wspierane przez specjalistów ds. zabezpieczeń.

Bezpieczeństwo umożliwia innowacje, nie jest to brama stosowana po dostarczeniu.

Organizacje muszą przyjąć podejście do ciągłego bezpiecznego programowania (SDL), które obejmuje:

• Definiowanie wymagań dotyczących zabezpieczeń na wczesnym etapie projektowania.
• Dostosowanie wymagań dotyczących zabezpieczeń do architektury i implementacji.
• Integrowanie zabezpieczeń z automatyzacją infrastruktury.
• Przeprowadzanie ciągłej weryfikacji zabezpieczeń.
• Śledzenie wyników zabezpieczeń.
• Ustalanie priorytetów korygowania.
• Wykorzystywanie ustaleń dotyczących bezpieczeństwa przy podejmowaniu decyzji o gotowości do wydania, tak aby kwestie bezpieczeństwa były w razie potrzeby traktowane jako czynniki blokujące wdrożenie produkcyjne.

Zabezpieczenia muszą być stale oceniane i ulepszane w miarę rozwoju architektur aplikacji, czynników ryzyka i modeli dostarczania.

Definiowanie minimalnych kryteriów rentowności produkcji

Obciążenia robocze muszą spełniać minimalne kryteria dopuszczenia przed wdrożeniem produkcyjnym. Te kryteria określają, czy obciążenie jest bezpieczne, zgodne i operacyjne gotowe do użycia w środowisku produkcyjnym w trzech wymiarach:

• Programowanie (deweloperskie): Uczestnicy projektu definiują minimalne wymagania funkcjonalne niezbędne do spełnienia wymagań biznesowych i wartości klienta/użytkownika.
• Bezpieczeństwo (sec): Interesariusze ds. bezpieczeństwa określają minimalne wymagania niezbędne do spełnienia wymogów regulacyjnych, utrzymania poziomu bezpieczeństwa organizacji oraz wspierania wykrywania i reagowania na aktywne zagrożenia.
• Operacje (ops): Uczestnicy projektu operacji definiują minimalne wymagania dotyczące wydajności, jakości i możliwości obsługi niezbędne do niezawodnego działania obciążenia w środowiskach produkcyjnych.

Kryteria rentowności produkcji:

• Upewnij się, że obciążenia są bezpieczne do wdrożenia i działania w środowiskach produkcyjnych.
• Stanowić podstawę do podejmowania decyzji o wydaniu i muszą być konsekwentnie egzekwowane we wszystkich procesach rozwojowych.

Kryteria opłacalności produkcji zmieniają się w zależności od zmian w:

• Modele dostarczania aplikacji.
• Warunki zagrożenia.
• Tolerancja ryzyka organizacyjnego.
• Wymagania dotyczące zgodności.

Integrowanie zabezpieczeń z przepływami pracy programowania

Zabezpieczenia muszą być osadzone bezpośrednio w procesach tworzenia i dostarczania. Organizacje powinny:

• Definiowanie wymagań dotyczących zabezpieczeń w ramach przepływów pracy programowania.
• Integrowanie działań zabezpieczeń z:
  • Procesy projektowania
  • Procesy budowy
  • Przepływy wdrażania (CI/CD)
• Zaimplementuj mechanizmy weryfikacji zabezpieczeń, takie jak:
  • Skanowanie kodu
  • Walidacja zależności
  • Testy konfiguracji

Wyniki zabezpieczeń muszą być traktowane tak samo jak wady produkcyjne i uwzględniane w decyzjach dotyczących wydania.

Weryfikacja bezpieczeństwa powinna odbywać się w sposób ciągły w całym procesie dostarczania, a nie tylko na etapach kontrolnych wydania.

Wymagania dotyczące równowagi i zharmonizowania

Organizacje muszą definiować, w jaki sposób wymagania programistyczne, bezpieczeństwa i operacyjne są zrównoważone w decyzjach dotyczących dostarczania oprogramowania. Obciążenia produkcyjne muszą spełniać wymagania w następujących obszarach:

• Funkcje biznesowe.
• Odporność na zabezpieczenia.
• Szybkość innowacji.
• Niezawodność i wydajność operacyjna.

Organizacje muszą definiować wspólne cele dostarczania i metryki wydajności, które:

• Dopasowuje się do wspólnych celów wydajności i dostarczania w ramach programowania, zabezpieczeń i operacji.
• Unikaj dominacji przez jedną domenę.
• Określanie priorytetów wyników na podstawie:
  • Tolerancja ryzyka organizacyjnego.
  • Obowiązki regulacyjne.
  • Odpowiedzialność biznesowa.

Równowaga musi dostosowywać się w miarę rozwoju warunków zagrożenia, zmiany modeli dostarczania i zmiany priorytetów organizacyjnych.

Ustanawianie wspólnej odpowiedzialności

Efektywna metoda DevSecOps wymaga współużytkowania własności między zespołami deweloperów, zabezpieczeń i operacji w celu:

• Uzgodnienie odpowiedzialności za kryteria wykonalności produkcji.
• Ujednolicanie celów realizacji między różnymi dziedzinami.
• Zmniejszenie silosów i niezdrowych tarć, które tworzą luki w zabezpieczeniach, opóźnienia dostarczania i niestabilność operacyjną.

Stosowanie mechanizmów zabezpieczających opartych na zasadach

Bariery ochronne oparte na zasadach powinny wymuszać mechanizmy kontroli bez wprowadzania nadmiernych tarć. Zabezpieczenia powinny obejmować następujące elementy:

• Wymagania dotyczące tożsamości i dostępu.
• Standardy konfiguracji i zgodności.
• Kontrolki wdrażania i wydawania.

Zabezpieczenia powinny być:

• Zintegrowane z fundamentami platformy (na przykład landing zones).
• Osadzone w przepływach pracy programowania/wdrażania.
• Wymuszane automatycznie, gdy jest to możliwe.

Takie podejście zapewnia spójne stosowanie wymagań dotyczących zabezpieczeń przy zachowaniu szybkości dostarczania.

Aby uzyskać zrównoważone podejście do bezpieczeństwa i szybkości innowacji, zapoznaj się z wdrażaniem przy użyciu mechanizmów zabezpieczających opartych na zasadach.

Podtrzymanie i ulepszanie

Zabezpieczenia nie pozostają skuteczne jako statyczny zestaw mechanizmów kontroli i muszą ewoluować wraz z upływem czasu.

Organizacje muszą stale oceniać i aktualizować praktyki zabezpieczeń programowania w odpowiedzi na zmiany w:

• Warunki zagrożenia i zachowanie osoby atakującej.
• Architektury aplikacji i modele dostarczania.
• Obowiązki regulacyjne.
• Tolerancja ryzyka organizacyjnego.
• Kryteria rentowności produkcji.
• Procesy dostarczania oprogramowania.
• Praktyki ładu bezpieczeństwa.

Rozwiązania w zakresie zabezpieczeń muszą ewoluować wraz z systemami, które chronią.

Techniki wyrównywania

Zespoły muszą być zgodne z:

• Określ wspólne cele: Liderzy ds. rozwoju, bezpieczeństwa i operacji powinni wspólnie określić cele wdrażania oraz mierniki efektywności procesu wdrażania obciążeń roboczych, aby wspierać spójne planowanie wydań.
• Zapobieganie dominacji decyzji o pojedynczej domenie: decyzje dotyczące dostarczania powinny uwzględniać wymagania programistyczne, bezpieczeństwa i operacyjne, aby uniknąć dysproporcji, które mogą negatywnie wpłynąć na niezawodność, zgodność lub funkcjonalność biznesową obciążeń.
• Przedkładaj ciągłe doskonalenie nad sztywne kryteria wydania: praktyki bezpieczeństwa w procesie tworzenia oprogramowania powinny być iteracyjnie doskonalone w miarę upływu czasu, wraz ze zmianami modeli dostarczania aplikacji, krajobrazu zagrożeń i priorytetów organizacyjnych.
• Ustanowienie wspólnego kontekstu dostarczania wśród ról interesariuszy: zespoły programistyczne, bezpieczeństwa i operacyjne powinny mieć wspólne rozumienie następujących kwestii:
  • Pilność biznesowa i harmonogramy dostarczania
  • Odpowiednie warunki zagrożenia i narażenie na ryzyko
  • Wymagania dotyczące dostępności operacyjnej i możliwości obsługi
• Monitorowanie problemów z dostarczaniem wprowadzonych przez wymagania dotyczące zabezpieczeń: Wymagania dotyczące zabezpieczeń mogą powodować problemy z dostarczaniem. Liderzy powinni ocenić, czy to tarcie przyczynia się do zmniejszenia ryzyka (na przykład poprzez włączenie wcześniejszej identyfikacji luk w zabezpieczeniach) lub niepotrzebnie opóźnia dostarczanie obciążeń bez znacznego zwiększenia odporności produkcyjnej.
• Uwzględnij zabezpieczenia programowania w planowaniu i alokacji zasobów: wymagania dotyczące zabezpieczeń obciążeń aplikacji powinny zostać włączone do planowania programowania i alokacji zasobów wraz z wymaganiami dotyczącymi funkcjonalności i obsługi operacyjnej.
• Zdefiniuj wspólne cele wydajności procesów dostarczania: mierniki wydajności i sukcesu dla obciążeń aplikacji powinny odzwierciedlać rezultaty procesów programistycznych, bezpieczeństwa i operacyjnych.

Dopasowywanie przepływów pracy do wymagań dotyczących zabezpieczeń

Bezpieczeństwo musi być wdrażane w ramach procesów tworzenia oprogramowania. Organizacje muszą definiować i dostosowywać przepływy pracy dla:

• Działania związane z projektowaniem architektury.
• Procesy kompilacji i wdrażania.
• Przepływy pracy związane ze śledzeniem i usuwaniem problemów.

Wyniki zabezpieczeń muszą być następujące:

• Traktowane priorytetowo i śledzone.
• Zarządzane wraz z defektami produkcyjnymi.
• Włączone do decyzji dotyczących gotowości do wydania.

Dopasowanie przepływu pracy gwarantuje, że wymagania dotyczące zabezpieczeń są stale wymuszane w całym dostarczaniu.

Następne kroki

Dowiedz się więcej o tworzeniu oprogramowania w oparciu o zasady Zero Trust