Projekt zaufania

Friday, June 28, 2024

Architektura i zasady projektowania bezpieczeństwa

Trzy elementy bezpieczeństwa i zasady projektowania bezpieczeństwa

Integralność
Dostępność
Poufność

Zasada otwartego projektowania

Open Design

Projekt nie powinien być tajemnicą, otwarty projekt jest bezpieczniejszy.
Bezpieczeństwo nie zależy od tajemnicy.

Zasada bezpieczeństwa domyślnego w przypadku awarii

Fail-safe defaults

Decyzje dotyczące dostępu opierają się na “zezwoleniu”, a nie na “odmowie”.
Domyślnie dostęp nie jest dozwolony, mechanizmy ochrony służą jedynie do identyfikowania dozwolonych przypadków dostępu.
Bezpieczeństwo awaryjne: każdy złożony system powinien mieć mechanizm bezpieczeństwa awaryjnego po awarii funkcji, dodatkowo należy uważać na komunikaty o błędach i dzienniki, aby zapobiec wyciekowi informacji.
Bezpieczeństwo domyślne: system w stanie początkowym ma domyślną konfigurację zapewniającą bezpieczeństwo, zapewniając bezpieczeństwo za pomocą minimalnej liczby systemów i usług.

Zasada rozdzielenia uprawnień

Separation of Privilege

Mechanizm ochrony wymagający dwóch kluczy do odblokowania jest bardziej solidny i elastyczny niż mechanizm wymagający jednego klucza.
Cele rozdzielenia uprawnień
Zapobieganie konfliktom interesów, nadużyciom indywidualnej władzy
Rozdzielenie ważnych uprawnień na wiele uprawnień, aby obiekty, które należy chronić, były trudniejsze do nielegalnego uzyskania, a tym samym bezpieczniejsze.
Rozdzielenie obowiązków i uprawnień różnych procesów

System może domyślnie ustawiać 3 role, konta systemowe poszczególnych ról są od siebie niezależne, a obowiązki i uprawnienia są rozdzielone:

Administrator systemu: odpowiada za codzienne zarządzanie użytkownikami i konfiguracją systemu.
Administrator bezpieczeństwa: odpowiada za aktywację i dezaktywację stanu użytkownika i konfiguracji bezpieczeństwa.
Auditor bezpieczeństwa: odpowiada za audyt operacji dwóch powyższych ról oraz posiada uprawnienia do eksportu dzienników, zapewniając możliwość śledzenia wszystkich operacji użytkowników systemu.

Zasada minimalnych uprawnień

Least Privilege

Każdy użytkownik, każdy program w systemie powinien używać minimalnego i niezbędnego zestawu uprawnień do wykonania pracy.
Upewnij się, że aplikacje działają z minimalnymi uprawnieniami.
Należy zwrócić uwagę na konta o minimalnych uprawnieniach do uruchamiania lub łączenia się z różnymi programami użytkowników w systemie, takimi jak bazy danych, serwery WWW itp., nie mogą to być konta o najwyższych uprawnieniach systemowych.
Podczas tworzenia nowego konta domyślnie przydziel najniższą rolę uprawnień.

Zasada oszczędności środków

Economy of Mechanism

Zachowaj projekt systemu i kod jak najprostszy i zwięzły.
Im bardziej złożony jest projekt oprogramowania, tym większe prawdopodobieństwo wystąpienia błędów w kodzie, jeśli projekt będzie jak najbardziej precyzyjny, tym mniejsze prawdopodobieństwo wystąpienia problemów z bezpieczeństwem.
Usuń zbędny kod i moduły funkcjonalne, które nie są potrzebne, pozostawienie tego kodu tylko zwiększy powierzchnię ataku systemu.
Projektuj komponenty przeznaczone do ponownego użytku, aby zmniejszyć nadmiarowy kod.
Oszczędność i przydatność: proste, precyzyjne, modułowe.
Nie projektuj zbyt skomplikowanie

Zasada minimalnej komunalizacji

Least Common Mechanism

Należy unikać sytuacji, w których wiele obiektów współdzieli ten sam zasób, liczba i wykorzystanie współdzielonych zasobów przez obiekty powinny być minimalizowane.
Współdzielone obiekty stanowią potencjalne niebezpieczeństwo kanałów przepływu informacji i niezamierzonego oddziaływania, należy unikać sytuacji, w których wiele obiektów współdzieli ten sam zasób.
Jeśli jeden lub więcej obiektów nie jest zadowolonych z usług oferowanych przez mechanizm współdzielenia, mogą one zdecydować się nie korzystać z mechanizmu współdzielenia, aby uniknąć pośredniego ataku przez błędy innych obiektów.
Minimalizacja współdzielonej pamięci
Minimalizacja powiązań portów
Zmniejszenie liczby połączeń, obrona przed atakami typu DoS

Zasada pełnego pośrednictwa

Complete Mediation

Zasada pełnego pośrednictwa wymaga, aby każdy dostęp do każdego obiektu był poddawany kontroli bezpieczeństwa.
Za każdym razem, gdy podmiot próbuje uzyskać dostęp do obiektu, system sprawdza, czy podmiot ma takie uprawnienia.
Należy jak najbardziej polegać na właścicielu zasobu przy podejmowaniu decyzji dotyczących kontroli dostępu, np. jeśli jest to URL, to serwer wewnętrzny sprawdza, a nie front-end.
Szczególną uwagę należy zwrócić na użycie i sprawdzenie pamięci podręcznej, nie można zagwarantować, że każda informacja w pamięci podręcznej nie została zmodyfikowana przez hakerów. np. oszustwo pamięci podręcznej DNS.

Zasada akceptowalności psychologicznej

Psychological Acceptability

Mechanizmy bezpieczeństwa mogą zwiększyć obciążenie użytkowników systemu, ale obciążenie to musi być minimalne i uzasadnione.
Mechanizmy bezpieczeństwa powinny być jak najbardziej przyjazne dla użytkowników systemu, ułatwiając im korzystanie z systemu i zrozumienie jego działania.
Jeśli metoda konfiguracji jest zbyt złożona i żmudna, administrator systemu może przypadkowo skonfigurować nieprawidłową opcję, co z kolei spowoduje, że system stanie się niebezpieczny.
Ta zasada dotyczy zazwyczaj interakcji człowiek-komputer i interfejsu zgodnego z zasadą UCD (User Centered Design).

Zasada głębokiej obrony

Defense in Depth Głęboka obrona to złożone i bardzo wymagające zasady obrony, które zazwyczaj wymagają od architektów systemów kompleksowego wykorzystania innych różnych zasad projektowania bezpieczeństwa, wykorzystania wielu i wielokrotnych mechanizmów kontroli bezpieczeństwa, a także ogólnej perspektywy bezpieczeństwa systemu na poziomie architektury systemu, a nie polegania tylko na jednym mechanizmie bezpieczeństwa.