Przekłada potrzeby ochrony na projekty obejmujące tożsamość, sieci, obciążenia, aplikacje, dane, płaszczyzny zarządzania, monitorowanie, odporność i zależności od dostawców. Jest to opis architektoniczny i model decyzyjny, a nie produkt ani generyczna lista kontrolna.
Architektura powinna opisywać elementy obsługiwane przez dostawcę i przez klienta we wszystkich wybranych modelach usług i wdrożeń. Łączy konsekwencje biznesowe i wrażliwość danych z konkretnymi punktami egzekwowania, ścieżkami administracyjnymi, granicami kryptograficznymi, telemetrią, mechanizmami odtwarzania i procesami cyklu życia. Wzorce referencyjne trzeba dostosować do systemu i umowy.
Najważniejsze punkty
Zakres i kontekstZidentyfikuj zasoby, usługi, zależności, jurysdykcje, założenia o zagrożeniach, wymagane przepływy danych, potrzeby dostępności oraz konsekwencje kompromitacji lub awarii dostawcy.
Zaufanie i odpowiedzialnośćPokaż, gdzie tożsamości, decyzje polityki, egzekwowanie, klucze, dane i administracja przekraczają granice organizacyjne lub techniczne, i przypisz rozliczalnego właściciela każdej kontroli.
Zapewnienie i ewolucjaRejestruj decyzje projektowe i wyjątki, waliduj istotne właściwości, przeglądaj zmiany dostawcy i aplikacji, testuj odtwarzanie oraz utrzymuj diagramy i modele zagrożeń spójne z wdrożoną infrastrukturą.
Istotne ograniczenieDiagram architektury nie potwierdza, że kontrole istnieją, działają lub pozostają prawidłowo skonfigurowane. Wzorce referencyjne mogą pomijać zachowania specyficzne dla usługi, a projekt ignorujący operacyjne właścicielstwo, obserwowalne dowody, tryby awarii lub logikę aplikacji może tworzyć fałszywe poczucie pewności.