Zarządzanie środowiskami projektowymi aplikacji w strefach docelowych platformy Azure
W tym artykule opisano, jak zespoły platformy w chmurze mogą implementować zabezpieczenia w celu zarządzania środowiskami aplikacji w strefach docelowych platformy Azure. Wyjaśniono również, jak dostosować różne środowiska deweloperskie aplikacji do ich struktury. Kluczowym aspektem tworzenia odpowiedniego środowiska jest umieszczenie subskrypcji w odpowiednich grupach zarządzania.
Ustawianie podstawy
Zespoły programistyczne wymagają możliwości szybkiego iterowania, a zespoły ds. ładu w chmurze i platformy muszą zarządzać ryzykiem organizacyjnym, zgodnością i zabezpieczeniami na dużą skalę. Środowiska aplikacji można prawidłowo zarządzać, koncentrując się na dwóch kluczowych zasadach projektowania strefy docelowej platformy Azure: ładu opartego na zasadach i demokratyzacji subskrypcji. Te zasady zapewniają podstawowe zabezpieczenia i opisują sposób delegowania kontroli do zespołów aplikacji. Zespoły aplikacji używają wskazówek dotyczących platformy Azure Well-Architected Framework do projektowania obciążenia. Wdrażają zasoby strefy docelowej i zarządzają nimi, a zespół platformy kontroluje zasoby, przypisując zasady platformy Azure.
Ważne jest zapewnienie zasobów piaskownicy dla zasobów częściowo zarządzanych , aby zespoły aplikacji mogły eksperymentować z technologiami i możliwościami.
Gdy właściciele aplikacji używają sprzedaż abonamentów lub innych procesów tworzenia subskrypcji, muszą wiedzieć, jak żądać subskrypcji dla wielu środowisk deweloperskich.
W tym artykule opisano strefę docelową platformy Azure, w tym grupy zarządzania, zasady i architekturę platformy udostępnionej oraz strefę docelową obciążenia lub aplikacji.
Uwaga
Wskazówki zawarte w tym artykule dotyczą tylko stref docelowych obciążeń lub aplikacji. Aby uzyskać informacje na temat segregacji środowiska i testowania dla samej platformy strefy docelowej platformy Azure, zobacz Testowanie podejścia do stref docelowych platformy Azure, które opisuje podejście kanarowe.
W praktyce można użyć dowolnej liczby i typu środowiska etapowego. Ten artykuł odwołuje się do następujących środowisk fazowych.
| Environment | opis | Grupa zarządzania |
|---|---|---|
| Piaskownicy | Środowisko, które jest używane do szybkiej innowacji prototypów, ale nie konfiguracji związanych z produkcją | Grupa zarządzania piaskownicą |
| Opracowywanie zawartości | Środowisko używane do tworzenia potencjalnych kandydatów do wydania | Archetyp grupy zarządzania, na przykład corp lub online |
| Test | Środowisko używane do przeprowadzania testów, w tym testowanie jednostkowe, testowanie akceptacyjne użytkowników i testowanie jakości | Archetyp grupy zarządzania, na przykład corp lub online |
| Produkcyjne | Środowisko używane do dostarczania wartości klientom | Archetyp grupy zarządzania, na przykład corp lub online |
Aby uzyskać więcej informacji, zobacz filmy wideo Obsługa środowisk programistycznych, testowych i produkcyjnych dla obciążeń aplikacji oraz Ile subskrypcji należy używać na platformie Azure?
Środowiska, subskrypcje i grupy zarządzania
Aby spełnić wymagania wstępne tej sekcji, zobacz Obszar projektowania organizacji zasobów.
Subskrypcje należy prawidłowo organizować podczas wdrażania praktyk strefy docelowej platformy Azure. Najlepiej, aby każde środowisko aplikacji miało własną subskrypcję. Ta metoda zapewnia mechanizmy kontroli zabezpieczeń i zasad, które zapewniają izolację środowisk. Zawiera potencjalne problemy z jednym środowiskiem.
Oddzielne subskrypcje mają te same zasady na poziomie archetypu. W razie potrzeby właściciele aplikacji mogą przypisywać zasady specyficzne dla subskrypcji w celu wymuszania zachowania aplikacji i środowiska.
Niektóre architektury aplikacji wymagają udostępniania usług między środowiskami. Jeśli tak jest, możesz użyć jednej subskrypcji dla wielu środowisk. Zalecamy, aby właściciele obciążeń pracowali z zespołami platformy w chmurze, aby określić, czy potrzebna jest pojedyncza subskrypcja dla wielu środowisk.
Użyj jednej subskrypcji dla wielu środowisk aplikacji, jeśli:
Środowisk nie można odizolować we własnych subskrypcjach.
Środowiska mają te same zespoły przypisane do ról funkcjonalnych, takich jak operatory sieciowe.
Środowiska mogą używać tych samych zasad.
Jeśli obciążenie aplikacji lub usługi musi znajdować się w jednej subskrypcji i musisz wprowadzić zmiany w zasadach, które mają zastosowanie do każdego środowiska, możesz:
Utwórz nową grupę zarządzania wyrównaną do archetypu pod grupą zarządzania strefami docelowymi. Aby uzyskać więcej informacji, zobacz Hierarchia grup zarządzania w tym artykule.
Użyj subskrypcji piaskownicy na potrzeby działań programistycznych. Piaskownice mają mniej restrykcyjny zestaw zasad.
Użyj zasad stosowanych na poziomie subskrypcji zamiast na poziomie grupy zarządzania. Tagi można dodawać w definicjach zasad, aby ułatwić filtrowanie i stosowanie zasad do poprawnego środowiska. Można również przypisywać zasady do określonych grup zasobów lub je wykluczać.
Zasady można przypisywać podczas procesu tworzenia subskrypcji w ramach sprzedaż abonamentów.
W przypadku zasad, które implementujesz w celu kontrolowania kosztów, zastosuj definicję zasad na poziomie subskrypcji, jeśli jest to wymagane. Możesz też sprawić, aby właściciel strefy docelowej był odpowiedzialny za koszty, co zapewnia prawdziwą autonomię. Aby uzyskać więcej informacji, zobacz Automatyzacja platformy i Metodyka DevOps.
Ostrzeżenie
W przeciwieństwie do zasad i mechanizmów kontroli na poziomie grupy zarządzania zasady i tagi oparte na subskrypcji mogą zostać zmienione przez osoby z podwyższonym poziomem uprawnień do subskrypcji. Administracja istratory z odpowiednimi rolami mogą pominąć te kontrolki, wykluczając zasady, modyfikując zasady lub zmieniając tagi zasobów.
W związku z tym nie należy stosować tagów w definicjach zasad ukierunkowanych na zabezpieczenia. Ponadto nie przypisz uprawnień tak jak zawsze aktywne dla następujących akcji:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Te akcje można kontrolować przy użyciu usługi Privileged Identity Management (PIM).
Hierarchia grup zarządzania
Unikaj skomplikowanych hierarchii grup zarządzania. Mogą wymagać częstej poprawki, nieefektywności skalowania i braku wartości. Aby uniknąć tych potencjalnych problemów, grupy zarządzania strefami docelowymi platformy Azure są dostosowane do archetypu obciążenia. Aby uzyskać więcej informacji, zobacz Zarządzanie grupą i organizacją subskrypcji.
Archetyp wyrównany oznacza, że grupy zarządzania są tworzone tylko dla określonych archetypów obciążenia. Na przykład w architekturze koncepcyjnej grupa zarządzania strefami docelowymi ma grupy zarządzania elementy corp i online podrzędne. Te podrzędne grupy zarządzania są zgodne z różnymi wzorcami archetypu dla obciążeń, które są przechowywane. Podrzędne grupy zarządzania koncentrują się na wymaganiach dotyczących łączności hybrydowej (VPN/Azure ExpressRoute), takich jak tylko wewnętrzne i publiczne aplikacje i usługi.
Wykluczając środowiska piaskownicy, różne środowiska aplikacji powinny używać tego samego archetypu do wdrożenia. Nawet jeśli środowiska są podzielone między kilka subskrypcji, są przechowywane w tej samej pojedynczej grupie zarządzania (corp lub online), na podstawie archetypu grupy zarządzania i wymagań.
Subskrypcje piaskownicy można używać do programowania bez struktury, takich jak laboratoria osobiste lub dla obciążenia, które nie ma archetypu. Zespół ds. obciążeń aplikacji lub usług używa grupy zarządzania piaskownicą do testowania różnych usług platformy Azure w celu określenia, co najlepiej sprawdza się pod kątem ich wymagań. Po podjęciu decyzji o usługach mogą aprowizować strefę docelową (w odpowiedniej grupie zarządzania dostosowanej do obciążenia w hierarchii grup zarządzania stref docelowych) dla zespołu.
Środowiska piaskownicy mogą być używane dla określonych aplikacji lub zespół roboczy może ich używać do eksperymentowania.
Aby uzyskać więcej informacji, zobacz:
- Grupy zarządzania.
- Obszar projektowania organizacji zasobów.
- Dostosuj architekturę strefy docelowej platformy Azure, aby spełnić wymagania.
Wyzwania związane z grupą zarządzania opartą na środowisku
Grupy zarządzania dla środowisk w archetypach mogą dodawać nakłady pracy związane z zarządzaniem i zapewniać minimalną wartość.
Grupa zarządzania strefami docelowymi powinna mieć uniwersalne zasady, które wymuszają zabezpieczenia zarówno dla grup zarządzania jednostki, jak i grup zarządzania podrzędnych online . Firma i online mają unikatowe zasady, które wymuszają wytyczne firmy związane z obciążeniami publicznymi i prywatnymi.
Wiele organizacji tworzy oddzielne grupy zarządzania dla środowisk cyklu tworzenia oprogramowania obciążeń (SDLC) w celu przypisania zasad i mechanizmów kontroli środowiska. W praktyce ta metoda tworzy więcej wyzwań dla zespołów obciążeń, niż rozwiązuje. Środowiska SDLC nie powinny mieć różnych zasad, dlatego nie zalecamy oddzielnych grup zarządzania.
Właściciele aplikacji mogą zmienić topologię lub konfigurację zasobów obciążenia, aby dopasować je do zasad w wielu środowiskach SDLC, za pomocą których jest promowany. Ta metoda zwiększa ryzyko. Reguły specyficzne dla każdego środowiska mogą powodować słabe środowisko programistyczne dla zespołów deweloperów i zespołów zapewniających jakość. Problemy mogą również wystąpić, jeśli aplikacja ma jeden zestaw zasad zabezpieczenia, które działają w jednym środowisku, a aplikacja jest widoczna dla innego zestawu zasad w późniejszym cyklu podwyższania poziomu. W przypadku zmiany kontrolek może być konieczne wprowadzenie zmian w aplikacji.
Aby zapobiec tej dodatkowej pracy, należy utworzyć spójne zasady podczas podwyższania poziomu kodu w środowiskach SDLC. Nie należy tworzyć zasad dla każdego środowiska, ale zamiast tego zapewnić spójny zestaw dla wszystkich środowisk deweloperskich, z wyłączeniem środowisk piaskownicy.
Załóżmy na przykład, że organizacja definiuje zasady, które wymagają skonfigurowania kont magazynu z określonymi regułami zapory, aby uniemożliwić ruch przychodzący z sieci publicznych. Zamiast tego konta magazynu używają prywatnych punktów końcowych wewnątrz sieci strefy docelowej platformy Azure na potrzeby komunikacji. Jeśli środowisko deweloperskie nie ma takich zasad, testowanie obciążenia nie spowoduje błędnej konfiguracji konta magazynu, które zezwala na dostęp publiczny. Wdrożenia testowe działają w środowisku projektowym i są iterowane. Po podwyższeniu poziomu rozwiązania do innego środowiska z zasadami konta magazynu wdrożenie kończy się niepowodzeniem z powodu wymuszonych zasad.
W związku z tym zespół deweloperów aplikacji musi przerobić swoje wdrożenie i architekturę po zainwestowaniu znacznego nakładu pracy. W tym przykładzie pokazano, jak różne zasady w różnych środowiskach mogą powodować problemy.
Uwaga
Poniższe równanie pokazuje, dlaczego oddzielna grupa zarządzania dla każdego środowiska lub obciążenia nie jest skalowana dobrze: N obciążeń x grupy zarządzania Z = łączna liczba grup zarządzania.
Jeśli organizacja ma 30 obciążeń, z których każda wymaga grupy zarządzania i podrzędnej grupy zarządzania na potrzeby środowisk programistycznych, testowych i produkcyjnych, organizacja pozostaje w lewo:
N = liczba obciążeń/aplikacji = 30
Z = liczba grup zarządzania dla obciążenia i środowisk (1 dla obciążenia + 3 dla środowisk) = 4
N (30) x Z (4) = 120 łączna liczba grup zarządzania
Właściciele aplikacji mogą potrzebować zasad, aby zastosować różne zasady w wielu środowiskach. Na przykład właściciele aplikacji mogą wymagać konfiguracji kopii zapasowych dla środowisk produkcyjnych, ale nie w innych środowiskach.
Niektóre zasady można włączyć jako zasady inspekcji na poziomie grupy zarządzania. Zespoły aplikacji określają sposób implementowania kontrolki. Ta metoda nie zapobiega wdrożeniom, ale tworzy świadomość i umożliwia zespołom aplikacji zarządzanie ich unikatowymi potrzebami. Następnie mogą tworzyć zasady poziomu podrzędnego lub uwzględniać te wymagania w swoich modułach wdrażania infrastruktury jako kodu (IaC).
W tym modelu wspólnej odpowiedzialności zespół platformy przeprowadza inspekcję praktyk, a zespół aplikacji zarządza implementacją. Ten model może zwiększyć elastyczność wdrożeń.
Aby zrozumieć ich wymagania, operatorzy platform muszą współpracować z każdym zespołem roboczym aplikacji lub usługi (właścicielami stref docelowych). Operatorzy platformy mogą udostępniać subskrypcje na podstawie wymagań i planów aplikacji. Operatorzy platform mogą również zdecydować się na wyznaczenie linii produktów dla różnych typów obciążeń, aby mogli tworzyć procesy tworzenia subskrypcji i narzędzia na podstawie typowych wymagań zespołów ds. obciążeń aplikacji lub usług.
Scenariusz: obciążenia oparte na maszynie wirtualnej
Wczesne obciążenia w strefach docelowych platformy Azure często składają się z maszyn wirtualnych platformy Azure. Te obciążenia można wdrożyć na platformie Azure lub zmigrować je z istniejących centrów danych.
Zamiast wdrażać maszyny wirtualne w wielu środowiskach w jednej subskrypcji, możesz:
Ustanów subskrypcje dla każdego środowiska aplikacji i umieść je wszystkie w tej samej grupie zarządzania archetypu.
Wdróż sieć wirtualną dla każdego środowiska aplikacji w odpowiedniej subskrypcji. Rozmiar sieci wirtualnej można określić na podstawie rozmiaru środowiska aplikacji.
Wdróż maszyny wirtualne w odpowiedniej subskrypcji. Maszyny wirtualne mogą używać różnych jednostek SKU i różnych konfiguracji dostępności dla każdego środowiska, jeśli jest to konieczne.
Różne zasoby środowiska aplikacji są chronione przez różne mechanizmy kontroli dostępu. W związku z tym, gdy deweloperzy aplikacji konfigurują potoki wdrażania, tożsamość każdego potoku może być ograniczona do środowiska. Ta konfiguracja pomaga chronić środowiska przed przypadkowymi wdrożeniami.
Scenariusz: usługa aplikacja systemu Azure
Obciążenie z subskrypcjami środowiskowymi korzystającymi z usługi App Service może stwarzać wyzwania. Najlepszym rozwiązaniem dla deweloperów aplikacji jest użycie miejsc wdrożenia w celu ułatwienia zarządzania zmianami i aktualizacjami aplikacji internetowej.
Tej funkcji można jednak używać tylko z aplikacją w planie usługi App Service, która może istnieć tylko w ramach jednej subskrypcji. Jeśli operatorzy platformy upoważnią właścicieli aplikacji do korzystania z oddzielnych subskrypcji na potrzeby środowisk deweloperskich, testowych i produkcyjnych, cykl życia wdrażania aplikacji może być trudniejszy do zarządzania.
W tym przykładzie najlepszą opcją jest pojedyncza subskrypcja dla obciążenia aplikacji lub usługi. Właściciele aplikacji mogą używać kontroli dostępu opartej na rolach (RBAC) platformy Azure z usługą PIM na poziomie grupy zasobów w celu zwiększenia bezpieczeństwa.