Udostępnij za pośrednictwem

Zalecenia dotyczące zabezpieczania cyklu życia projektowania

  • Artykuł

Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej zabezpieczeń o dobrze zaprojektowanej architekturze:

SE:02 Utrzymywanie bezpiecznego cyklu życia projektowania przy użyciu sypkich, w większości zautomatyzowanych i sprawdzanego oprogramowania, które można poddać inspekcji. Bezpieczne projektowanie można wykorzystać przy użyciu modelowania zagrożeń w celu zabezpieczenia przed implementacjami korzystającymi z zabezpieczeń.

W tym przewodniku opisano zalecenia dotyczące zabezpieczania kodu i środowiska projektowego przez stosowanie najlepszych praktyk w zakresie zabezpieczeń w całym cyklu projektowym.

Na początku obciążenia znajdują się składniki implementują logikę biznesową. Te składniki mogą być kombinacją elementów niskiego kodu, takich jak aplikacje kanw i przepływy, oraz elementy kodu, takie jak dodatków plug-in. Aby zapewnić ich poufność, integralność i dostępność, wszystkie składniki składowe w tym zakresie muszą być wolne od zabezpieczeń.

Zabezpieczanie infrastruktury za pomocą formantów tożsamości i sieci jest ważne, ale nie wystarczy. Zapobieganie implementacji prac Power Platform i naruszonych zabezpieczeń w tych obciążeniach w celu zwiększenia ogólnej pozycji zabezpieczeń. Proces integracji zabezpieczeń z cyklem życia projektowania jest procesem jego opracowywania. Podobnie jak w przypadku tworzenia zasobów, tworzenie kodu jest także kontekstem. Fokus znajduje się na zabezpieczeniach przed zdjęciami, a nie na wymaganiach funkcjonalnych aplikacji.

Definicje

Termin Definicja
Cykl rozwoju bezpieczeństwa (SDL) Zestaw rozwiązań udostępnianych przez Microsoft ten program obsługuje wymagania dotyczące zapewniania zabezpieczeń i zgodności.
Cykl rozwoju oprogramowania (SDLC) Wieloetapowy, systematyczne proces tworzenia systemów oprogramowania.

Kluczowe strategie projektowania

Miary zabezpieczeń powinny być zintegrowane w wielu punktach w istniejącym cyklu życia projektowania oprogramowania (SDK), aby:

  • Wybory projektu nie mogą powodować luk w zabezpieczeniach.
  • Składniki z niskokodowe i najpierw z kodem oraz konfiguracja nie tworzą luk w zabezpieczeniach z powodu implementacji, które można wykorzystać i nieprawidłowych praktyk kodowych.
  • Nie są modyfikowane składniki kodu niskiego i pierwszego kodu oraz procesy wdrażania.
  • Luki w zabezpieczeniach ujawniane podczas zdarzeń są minimalizowane.
  • Nie naruszono ani nie zmniejszono wymagań zgodności.
  • Rejestrowanie inspekcji jest zaimplementowane we wszystkich środowiskach.

W poniższych sekcjach przedstawiono strategie zabezpieczeń dla najczęściej stosowanych etapów SDLC.

Faza wymogów

Celem etapu wymagań jest gromadzenie i analizowanie wymagań funkcjonalnych i nieakcjonalnych dla obciążenia lub nowej funkcji obciążenia. Ten etap jest ważny, ponieważ ułatwia tworzenie nowych rozwiązań dostosowanych do celów obciążenia. Ochrona danych i integralności obciążenia powinna być podstawowym wymaganiem na każdym etapie cyklu projektowania.

Na przykład można rozważyć obciążenia, w którym użytkownicy będą wprowadzać i modyfikować dane w aplikacji. Wybór projektu zabezpieczeń powinien zapewniać użytkownikowi interakcję z danymi, na przykład uwierzytelnianie i tworzenie tożsamości użytkownika, a także pozwalać na zezwalanie użytkownikowi na dozwolone działania w zakresie danych. Wymagania nieakcjowe obejmują dostępność, dostępność i konserwację. Dostępne opcje zabezpieczeń powinny obejmować granice segmentacji, ruch przychodzący i wychodzący za zaporę oraz inne ograniczenie zabezpieczeń.

Wszystkie te decyzje powinny dobrze określać bezpieczeństwo prac. Należy dokumentować wymagania zabezpieczeń w uzgodnionej specyfikacji i odzwierciedlać je w backlogu. W dokumencie należy jawnie określić bezpieczeństwo oraz zasady zabezpieczeń oraz określić, czy firma nie zostanie zaakceptowana przez interesariuszy. Można na przykład dokumentować konieczność używania zapory IP w środowiskach Power Platform w celu ochrony danych organizacyjnych przez ograniczenie dostępu do Dataverse tylko dozwolonych lokalizacji IP. Jeśli udziałowcy biznesowi nie mogą ponosić dodatkowego kosztu używania rozwiązania, takiego jak środowisko zarządzane, muszą być gotowi zaakceptować ryzyko, że zasoby organizacyjne zostaną dostępne z lokalizacji publicznych, takich jak bar kawowy. Załóżmy też, że w innym przykładzie aplikacja musi się połączyć z innym źródło danych. Program Power Platform może mieć gotowy łącznik, ale może on nie obsługiwać wymagań dotyczących uwierzytelniania zatwierdzonych przez zespoły zabezpieczeń. W takim przypadku udziałowcy zabezpieczeń mogą nie zaakceptować ryzyka użycia niezatwierdzonych metod uwierzytelniania. Alternatywnie można użyć łącznika niestandardowego, a korzyści ze zwiększonego czasu projektowania i potencjalnej opóźnienie projektu.

Zbieranie wymagań zabezpieczeń to kluczowy element tego etapu. Bez tego nakładu pracy etapy projektowania i implementacji będą oparte na nieskonsekwowanych możliwościach, co może spowodować zmianę zabezpieczeń lub zmianę wymagań, co spowoduje zwiększenie czasu projektowania. Może wystąpić konieczność późniejszej zmiany w implementacji, aby zapewnić bezpieczeństwo.

Faza projektu

Na tym etapie wymagania zabezpieczeń są konwertowane na wymagania techniczne. W specyfikacji technicznej należy dokumentować wszystkie decyzje dotyczące projektu, aby uniknąć dwuznaczności podczas implementacji. Oto kilka typowych zadań:

  • Zdefiniuj rozmiar zabezpieczeń architektury. Steruje architekturą za pomocą formantów zabezpieczeń. Na przykład są praktyczne formanty poza granicą izolacji sieciowej, typy tożsamości i metody uwierzytelniania potrzebne dla składników obciążenia i typy metod szyfrowania, które należy stosować.

  • Ocenianie informacji o przechowaniach na platformie. Ważne jest, aby zrozumieć podział odpowiedzialności między to użytkownikami Power Platform. Należy unikać nakładania się na siebie lub powtarzania się działań w macierzystych kontrolkach zabezpieczeń Power Platform. Poprawisz zakres zabezpieczeń i będziesz mieć możliwość realokacji zasobów projektowych do potrzeb aplikacji.

    Na przykład zamiast tworzyć niestandardową logikę, która reakcyjnie identyfikuje i alerty dotyczące niezatwierdzonych wzorców użycia w aplikacjach i przepływach, do sklasyfikowania sposobu korzystania z łączników należy użyć zasad ochrony przed utratą danych.

    Wybieraj tylko zaufane implementacje referencyjne, szablony, składniki kodu, skrypty i biblioteki. Projekt powinien także określać bezpieczną kontrolę wersji. Zależności aplikacji powinny być źródła od zaufanych stron. Dostawcy zewnętrzni powinni być w stanie spełnić Twoje wymagania dotyczące bezpieczeństwa i udostępnić swój plan odpowiedzialnego ujawniania informacji. Wszelkie zdarzenia zabezpieczeń należy zgłaszać w sposób monitowy, aby użytkownik miał możliwość podjęcia niezbędnych działań. Ponadto niektóre biblioteki lub implementacje odwołania mogą być zakazane przez organizację. Na przykład nawet jeśli jest bezpieczny i wolny od luk w zabezpieczeniach, może to spowodować dysonowanie z powodu tego, że są w nim używane funkcje, które nie zostały jeszcze zatwierdzone przez organizację, ograniczenia licencjonowania lub model pomocy technicznej implementacji odwołania.

    Aby upewnić się, że te wskazówki są stosowane, należy utrzymywać listę zatwierdzonych i/lub niezatwierdzonych struktur, bibliotek i dostawców, a także upewnić się, że twórcy programu są zaznajomieni z tą listą. Jeśli jest to możliwe, należy umieścić ewentualne potoki projektowe w celu ich obsługi. W miarę możliwości zautomatyzuj korzystanie z narzędzi do skanowania zależności w celu wychowania luk w zabezpieczeniach.

  • Przechowywane tajne dane aplikacji są bezpieczne. Należy bezpieczne zaimplementować korzystanie z tajnych danych aplikacji oraz wstępnie udostępnionych kluczy, które są używane przez aplikację. Poświadczenia i tajne aplikacje nigdy nie powinny być przechowywane w kodzie źródłowym obciążenia (aplikacji lub przepływu). Użyj zasobów zewnętrznych, takich jak usługa Azure Key Vault, aby zapewnić, że jeśli kod źródłowy stanie się dostępny dla potencjalnego potencjalnego użytkownika, nie będzie można uzyskać żadnych dodatkowych dostępu.

  • Połącz bezpiecznie ze swoimi danymi. Należy korzystać z funkcji zabezpieczeń, które Microsoft Dataverse oferuje do zabezpieczenia danych, takich jak zabezpieczenia oparte na rolach i kolumnach. W przypadku innych źródeł danych należy użyć łączników z metodami bezpiecznego uwierzytelniania. Należy unikać kwerend w postaci zwykłego tekstu, w których jest zapisywana nazwa użytkownika i hasło. Należy unikać protokołu HTTP podczas tworzenia łączników niestandardowych.

  • Określ, w jaki sposób użytkownicy końcowi będą pracować z obciążeniem i danymi. Należy rozważyć, czy użytkownicy będą mieli bezpośredni dostęp do danych, jaki poziom dostępu są dla nich wymagany i skąd będą mieli dostęp do tych danych. Pomyśl, w jaki sposób aplikacje będą udostępniane użytkownikom końcowych. Upewnij się, że tylko osoby, które chcą mieć dostęp do aplikacji i danych, będą mieć dostęp. Należy unikać złożonych modeli zabezpieczeń, które zachęcać do stosowania obejść w celu uniknięcia blokowania zabezpieczeń.

  • Należy unikać twardego pisania kodu. Należy unikać twardego pisania kodu adresów URL i kluczy. Na przykład należy unikać pisania kodu twardego w akcji HTTP Power Automate, czyli adresu URL lub klucza do usługi zaplecza. Zamiast tego można użyć łącznika niestandardowego lub zmiennej środowiska dla adresu URL oraz magazynu kluczy Azure Key Vault dla klucza interfejsu API.

  • Definiować plany testowe. Zdefiniuj wyczyść sprawy testowe dla wymagań bezpieczeństwa. Należy określić, czy te testy mogą zostać zautomatyzowane w potokach. Jeśli zespół dysponuje procesami testowania ręcznego, należy uwzględnić wymagania bezpieczeństwa dotyczące tych testów.

Uwaga

Na tym etapie należy przeprowadzić modelowanie zagrożeń. Modelowanie zagrożeń może potwierdzić, że opcje projektu są wyrównane z wymaganiami zabezpieczeń i uwidocznić problemy, które należy zawężać. Jeśli w obciążeniach są przetwarzane bardzo poufne dane, specjaliści ds. zabezpieczeń mogą pomóc w modelowaniu zagrożeń.

Początkowe modelowanie zagrożeń powinno nastąpić na etapie projektowania, kiedy zdefiniowana jest architektura oprogramowania oraz projekt wysokiego poziomu. To zrobić na tym etapie pomaga w identyfikowaniu potencjalnych problemów z bezpieczeństwem, zanim zostaną one uwzględnione w strukturze systemu. To ćwiczenie nie jest jednak działaniem tylko raz. Jest to proces ciągły, który powinien trwać cały czas w całej historii oprogramowania.

Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące analizy zagrożeń.

Etap projektowania i testowania

Na tym etapie celem jest zapobieganie wadom zabezpieczeń i wdrażania programu i zapobiegania tworzenia i wdrażania.

Należy dobrze przeszkolić w zakresie bezpiecznego kodu

Zespół projektowy powinien przećwiczyć szkolenie w zakresie bezpiecznego kodowania. Na przykład deweloperzy powinni zaznajomić się z pojęciami zabezpieczeń w Microsoft Dataverse wdrażając model zabezpieczeń o najmniejszych uprawnieniach, zasady zabezpieczeń zawartości w aplikacjach opartych na modelu, aby ograniczyć proces osadzenia do zaufanych domen oraz metody uwierzytelniania łącznika/lokalnego portalu.

Deweloperzy powinni ukończyć to szkolenie przed rozpoczęciem pracy nad pracą Power Platform.

Przekonywuj wewnętrzne przeglądy kodu równorzędnego w celu promowania ciągłych edytujących ników.

Korzystanie z narzędzi do analizy kodu

Dla zasobów Power Platform należy używać Sprawdzania rozwiązania. Można też sprawdzić kod źródłowy dowolnego tradycyjnego kodu pod kątem potencjalnego bezpieczeństwa, np. obecności poświadczeń w kodzie. Zidentyfikuj możliwe wystąpienia poświadczeń i poświadczenia w plikach kodu źródłowego i plikach konfiguracyjnych. Na tę okres warto przejrzeć sposób obsługi poświadczeń połączenia w środowisku produkcyjnym.

Przeprowadzanie testów rozmytych

Źle sformułowane i nieoczekiwane dane można użyć do sprawdzania luk w zabezpieczeniach i sprawdzania poprawności obsługi błędów, co jest szczególnie ważne w przypadku takich rozwiązań uwzględniających Power Pages.

Pisanie wystarczy kodu

Zmniejszenie liczby kodów zmniejsza również prawdopodobieństwo, że zostanie zrzuty zabezpieczeń. Ponowne użycie kodu i bibliotek, które są już używane i przeszły weryfikację zabezpieczeń, zamiast duplikowania kodu. Wykrywanie oprogramowania open-source i sprawdzanie wersji, luk w zabezpieczeniach i zobowiązania prawne. Zasoby Power Platform typu open-source rosną, więc nie należy o tym pamiętać. Jeśli jest to możliwe, należy to omówić na etapie projektowania, aby uniknąć ewentualnych problemów.

Ochrona środowisk deweloperskich

Aby zapobiec utracie danych przez deweloperów, należy je chronić za pomocą silnych kontrolek sieci i tożsamości. Należy upewnić się, że aktualizacje zabezpieczeń są stosowane sumiennie.

Repozytorium kodu źródłowego również musi być zabezpieczone . Aby uniknąć ataków, należy przyznać dostęp do repozytoriów kodu zgodnie z potrzebami i zmniejszyć liczbę luk w zabezpieczeniach. Przeprowadź dokładny proces przeglądania kodu pod kątem luk w zabezpieczeniach. W tym celu należy użyć grup zabezpieczeń i zaimplementować proces zatwierdzania oparty na zależnościach od danych biznesowych.

Bezpieczne wdrożenia kodu

Nie wystarczy tylko do bezpiecznego kodu. Jeśli jest ona uruchomiona w potokach, które można wykorzystać, wszystkie działania bezpieczeństwa są niekompletne i nie są możliwe do wykorzystania. Środowiska kompilacji i wydania muszą być również chronione , ponieważ chcesz uniemożliwić złym aktorom uruchamianie złośliwego kodu w potoku.

Utrzymywanie aktualnych zapasów wszystkich składników zintegrowanych z aplikacją

Każdy nowy składnik zintegrowany z aplikacją zwiększa poziom atak. Aby zapewnić odpowiednią odpowiedzialność i alerty po dodaniu lub zaktualizowaniu nowych składników, należy posiadać zapasy tych składników. Na regularnie należy sprawdzać, czy ten manifest odpowiada tym, co dzieje się w procesie tworzenia. Pomaga to zagwarantować, że nie zostaną dodane nieoczekiwanie żadne nowe składniki zawierające szkodliwe oprogramowanie lub szkodliwe oprogramowanie.

Zaleca się użycie Potoków dla Power Platform dla wdrożeń. Rozszerzanie potoków przy użyciu usługi GitHub Actions. Jeśli używasz przepływów pracy usługi GitHub, preferowane Microsoft są zadania utworzone. Należy też sprawdzić poprawność zadań, które są wykonywane w kontekście zabezpieczeń potoku.

Zapoznaj się z użyciem głównych jednostki usługi na przykład do wdrożenia.

Etap produkcyjny

Na tym etapie produkcji jest prezentna ostatnia odpowiedzialna szansa sprzedaży, która ma poprawić bezpieczeństwo. Zachowanie rekordu obrazów, które mają być wydane w środowisku produkcyjnym.

Zachowanie artefaktów o wersji

Zachowanie katalogu wszystkich wdrożonych zasobów i ich wersji. Te informacje są przydatne podczas trymingu zdarzeń, problemy i powrotu systemu do stanu roboczego. Zasoby wersji można porównywać z opublikowanymi informacjami o typowych lukach i zabezpieczeniach (CVE). Do przeprowadzenia tych porównań należy użyć automatyzacji.

Poprawki poprawek

Zautomatyzowane projektowanie potoku powinno zapewnić elastyczność , tak aby zapewnić obsługę zwykłych i cyklicznych wdrożeń. Ta elastyczność jest ważna w celu zapewnienia szybkiego i odpowiedzialnych poprawek zabezpieczeń.

Wydanie jest zwykle związane z wieloma zatwierdzeniemi. Rozważ utworzenie procesu, który przyspieszy naprawę zabezpieczeń. Proces może obejmować komunikację między zespołami. Potok powinien umożliwić szybkie wdrożenie ze względów roll-forward i rollback, które rozwiązano problemy z zabezpieczeniami, krytyczne aktualizacje kodu i oprogramowania, które występują poza zwykłym cyklem wdrażania.

Uwaga

Poprawki zabezpieczeń zawsze mają priorytet dla wygody użytkowników. Poprawka zabezpieczeń nie powinna wprowadzić błędu lub błędu. Aby przyspieszyć rozwiązanie problemu przez proces potoku, należy się zastanowić, które zautomatyzowane testy można pominąć. Ocenianie wartości poszczególnych testów w stosunku do czasu wykonywania. Na przykład testy jednostek zazwyczaj są zakończone szybko. Testy integracji lub kompleksowe testy mogą trwać długo.

Poszczególne środowiska należy oddzielać

Danych produkcyjnych nie należy używać w niższych środowiskach**, ponieważ środowiska te mogą nie mieć kontrolek zabezpieczeń używanych przez środowiska produkcyjne. Należy unikać łączenia się między aplikacją nieprodukcyjną a produkcyjną bazą danych oraz unikać łączenia składników nieproduktowych z sieciami produkcyjnymi.

Użyj postępowego wykorzystania

Użyj postępującego środowiska w celu wydania funkcji dla podzbioru użytkowników na podstawie wybranych kryteriów. W przypadku problemów wpływ jest zminimalizowany dla tych użytkowników. Takie podejście stanowi często strategię oceny bezpieczeństwa związanego z ryzykiem, ponieważ zmniejsza obszar jej obszaru. Ponieważ funkcja jest dostępna tylko dla osób, które mają więcej zaufania do zapewnienia bezpieczeństwa, można zwolnić tę funkcję, co jest bardziej zaawansowane dla większej liczby użytkowników.

Faza konserwacji

Celem tego etapu jest upewnienie się, że wpis zabezpieczeń nie jest w tym czasie zmieniany. SDLC to bieżący proces zawsze aktualnego. Pojęcia objęte poprzednimi etapami dotyczą tego etapu, ponieważ wymagania zmieniają się w czasie.

Ciągłe doskonalenie. Stale oceniaj i poprawiaj bezpieczeństwo procesu projektowania oprogramowania, uwzględniając przeglądy kodu, opinie, wyciągnięte wnioski i zmieniające się zagrożenia, a także nowe funkcje dostępne dla użytkownika przez Power Platform.

Likwidowanie starszych zasobów , które są przestarzałe lub nie są już używane. W ten sposób zmniejszy się obszar tabletu aplikacji.

Konserwacja obejmuje również naprawy zdarzeń. Jeśli problemy zostaną znalezione w środowiskach produkcyjnych, należy je szybko zintegrować z procesem, aby nie powtarzały się.

Stale ulepszaj metody bezpiecznego kodowania, aby nadązać za poziomem zagrożeń.

SDL w Microsoft Power Platform

Power Platform jest zbudowana na kulturze i metodologii bezpiecznego projektowania. Zarówno kultura, jak i metodologia są stale wzmacniane dzięki Microsoft wiodącym w branży praktykom w zakresie cyklu życia rozwoju zabezpieczeń (SDL) i modelowania zagrożeń.

Proces przeglądu modelowania zagrożeń zapewnia, że zagrożenia są identyfikowane w fazie projektowania, łagodzone i zatwierdzane, aby upewnić się, że zostały zniwelowane.

Modelowanie zagrożeń uwzględnia także wszystkie zmiany w usługach, które już działają, dzięki ciągłym, regularnym przeglądom. Bazowanie na modelu STRIDE pomaga rozwiązać najczęstsze problemy związane z niezabezpieczonym projektowaniem.

MicrosoftSDL jest odpowiednikiem modelu dojrzałości OWASP Software Assurance Maturity Model (SAMM). Oba są zbudowane w oparciu o założenie, że bezpieczny projekt jest integralną częścią bezpieczeństwa aplikacji internetowych. Aby uzyskać więcej informacji, zobacz temat OWASP, 10 największych zagrożeń w Power Platform

Ułatwienia Power Platform

Microsoft Cykl projektowania zabezpieczeń (SDL) zaleca bezpieczne rozwiązania, które można zastosować do cyklu życia programowania. Aby uzyskać więcej informacji, zobacz Microsoft Cykl tworzenia zabezpieczeń.

Struktury dla narzędzi DevOps i SAST (Static Application Security Testing) są elementem zaawansowanego zabezpieczeń GitHub i Azure DevOps. Narzędzia te mogą ułatwić śledzenie wyników zabezpieczeń dla organizacji.

Dzięki funkcji sprawdzania rozwiązania możesz przeprowadzać bogate analizy statyczne na rozwiązaniach dla zestawu reguł najlepszych metod postępowania i szybko określać te problematyczne wzorce. Zobacz Użyj modułu sprawdzanie rozwiązań, aby sprawdzić poprawność rozwiązania.

Lista kontrolna zabezpieczeń

Zapoznaj się z kompletną zestawem zaleceń.

Lista kontrolna zabezpieczeń