Jednoznaczna tożsamość
Zakładana zasada bezpieczeństwa i architektury; konkretne mechanizmy kontroli muszą być udokumentowane osobno.
Zaufanie BLUETRIX
Bezpieczeństwo dzięki jasnym granicom i mechanizmom możliwym do prześledzenia.
Zasady architektury określają, co należy ocenić i udokumentować, bez deklarowania niepotwierdzonych zabezpieczeń.
Zasady bezpieczeństwa
Zasady architektury, a nie ogólne deklaracje wdrożenia.
Minimalne uprawnienia
Zakładana zasada bezpieczeństwa i architektury; konkretne mechanizmy kontroli muszą być udokumentowane osobno.
Rozdzielenie obowiązków
Zakładana zasada bezpieczeństwa i architektury; konkretne mechanizmy kontroli muszą być udokumentowane osobno.
Wielowarstwowa ochrona
Zakładana zasada bezpieczeństwa i architektury; konkretne mechanizmy kontroli muszą być udokumentowane osobno.
Bezpieczne ustawienia domyślne
Zakładana zasada bezpieczeństwa i architektury; konkretne mechanizmy kontroli muszą być udokumentowane osobno.
Możliwość prześledzenia
Zakładana zasada bezpieczeństwa i architektury; konkretne mechanizmy kontroli muszą być udokumentowane osobno.
Tożsamość i dostęp
Autoryzacja uwzględnia kontekst biznesowy.
Samo udane logowanie nie autoryzuje automatycznie każdego działania.
- Tożsamość uczestnika
- Kontekst przestrzeni roboczej lub organizacji
- Rola i członkostwo
- Zasób, którego dotyczy działanie
- Żądane działanie
- Odpowiedzialność biznesowa
- Status procesu
- Klasyfikacja danych
- Delegowane uprawnienia
- Wymagane zatwierdzenia
Granice organizacyjne
Granice przestrzeni roboczych i organizacji.
Zasady przeznaczone do oceny lub planowane; nie stanowią obietnicy pełnej izolacji tenantów.
- Jednoznaczne przypisanie przestrzeni roboczej
- Kontrolowane udostępnianie zasobów
- Sprawdzenie autoryzacji
- Zdefiniowane członkostwa
- Role administracyjne
- Możliwe do prześledzenia zmiany praw dostępu
Techniczne obszary ochrony
Obszary wymagające oceny i dokumentacji.
Mechanizmy bez potwierdzenia nie są przedstawiane jako wdrożone.
- Ochrona danych podczas przesyłania
- Ochrona przechowywanych danych
- Dostęp produkcyjny
- Zarządzanie sekretami i danymi uwierzytelniającymi
- Kopie zapasowe i odzyskiwanie
- Logowanie i monitorowanie
- Usuwanie danych
- Bezpieczny eksport
- Rozdzielenie środowisk
Bezpieczne interfejsy i rozwój
Wymagania dotyczące rozwoju i eksploatacji.
- Uwierzytelnianie i autoryzacja
- Walidacja danych wejściowych
- Limity zapytań i ochrona przed ponownym odtworzeniem
- Weryfikacja pochodzenia i idempotencja
- Obsługa błędów i logowanie
- Przegląd kodu i zarządzanie zależnościami
- Zarządzanie podatnościami
- Kontrolowane wydania i ustalenia
Audyt
Możliwość prześledzenia działań istotnych dla bezpieczeństwa.
Oś czasu interakcji, logowanie techniczne i audyt bezpieczeństwa są odrębnymi obszarami informacji.
- Kto zainicjował działanie?
- W której przestrzeni roboczej?
- Którego zasobu dotyczyło działanie?
- Którego uprawnienia użyto?
- Jaka zmiana stanu nastąpiła?
- Która automatyzacja lub który agent uczestniczył?
- Jakie zatwierdzenie było dostępne?
- Jakie kolejne zdarzenia nastąpiły?
Gotowość na incydenty
Proces bez wymyślonych SLA.
- 1Wykrycie i zgłoszenie
- 2Klasyfikacja
- 3Ograniczenie skutków
- 4Analiza
- 5Usunięcie problemu
- 6Odzyskiwanie
- 7Wymagana komunikacja
- 8Działania następcze
Status bezpieczeństwa
Status wymaga rzeczywistych danych.
Wdrożone mechanizmy kontroli, usprawnienia, środki, oceny, dowody, ograniczenia i aktualizacje muszą być dokumentowane przy użyciu rzeczywistych danych o statusie. Ta strona nie tworzy fikcyjnych statusów.
Pytania o bezpieczeństwo wymagają konkretnych odpowiedzi.
Poproś o aktualnie dostępne informacje o architekturze, mechanizmach kontroli i odpowiedzialności.