Konfiguracja zaawansowana dla programu MSP

Podczas pracy z protokołem MSP (Metadata Security Protocol) możesz opcjonalnie zdefiniować niestandardowe listy dozwolonych kontroli dostępu opartej na rolach (RBAC) dla punktów końcowych usługi metadanych dla poszczególnych użytkowników i/lub poszczególnych procesów. Nowy typ zasobu w galerii obliczeń platformy Azure, InVMAccessControlProfile, umożliwia te listy dozwolonych.

Motywacja

Tradycyjnie usługi metadanych traktują całą maszynę wirtualną jako granicę zaufania i zezwalają na dostęp do nich oprogramowania działającego na gościu. Ten dostęp jest zbyt permisywny, zwłaszcza jeśli obciążenie robocze nie jest dokładnie wdrożone z użyciem nowoczesnej architektury natywnej dla chmury. Centrum zabezpieczeń firmy Microsoft (MSRC) stwierdziło, że większość ataków zabezpieczeń może być zapobiegana, jeśli organizacje ograniczają dostęp tylko do niezbędnego oprogramowania.

Typ InVMAccessControlProfile zasobu umożliwia zdefiniowanie bardziej szczegółowej kontroli nad aplikacjami lub użytkownikami, którzy mogą uzyskiwać dostęp do punktów końcowych. Można go użyć do pisania reguł, takich jak te przykłady:

• Tylko Agent Proxy Gościa (GPA) i SQL Server mogą uzyskać dostęp do konfiguracji sieci.
• Tylko rozszerzenie monitorowania może uzyskiwać dostęp do tokenów dla tożsamości zarządzanych.

Nowy typ zasobu ułatwia zarządzanie tymi konfiguracjami na dużą skalę. Reguły, które są odpowiednie dla maszyny wirtualnej, zależą od oprogramowania, które jest uruchomione. Możesz użyć InVMAccessControlProfile polecenia , aby zdefiniować konfigurację raz i połączyć ją ze wszystkimi odpowiednimi maszynami wirtualnymi.

Właściwości

Pojęcia dotyczące listy dozwolonych msp (RBAC)

Pierwszym krokiem kontroli dostępu jest zweryfikowanie tożsamości klienta. Zwykle weryfikacja tożsamości używa pewnego typu poświadczeń. Program MSP został zaprojektowany tak, aby uniknąć wprowadzania zmian niezgodnych dla klientów, aby zapewnić maksymalną zgodność i ułatwić wdrożenie. Ponadto, po uaktualnieniu klientów przy użyciu poświadczeń, wprowadzono kolejną warstwę problemów związanych z mechanizmami zaufania do rozwiązania.

Zamiast tego program MSP obsługuje definiowanie tożsamości wirtualnych względem istniejącego systemu operacyjnego i metadanych procesów. Jądro maszyny wirtualnej śledzi, do którego konta użytkownika należy proces, oprócz innych metadanych dotyczących jego wywołania. GpA może zidentyfikować, który proces wykonał żądanie HTTP. W związku z tym GPA może uzyskać dostęp do tych metadanych w celu określenia tożsamości dzwoniącego i podejmowania decyzji dotyczących uprawnień.

Role

Role służą do grupowania wielu uprawnień w nazwanej jednostce wielokrotnego użytku. Grupowanie uprawnień w rolach ułatwia organizację i poprawia czytelność.

Przypisania ról

Przypisania ról łączą tożsamość z rolą. Żądania pochodzące z procesu, który odpowiada tożsamości, posiadają wszystkie uprawnienia związane z daną rolą.

Tożsamości

Za pomocą programu MSP można zdefiniować zestaw warunków, które mogą zostać ocenione na podstawie zbioru właściwości metadanych procesu. Jeśli wszystkie warunki są zgodne, uznaje się, że proces należy do tej tożsamości i otrzymuje uprawnienia.

Plik GPA obsługuje pisanie reguł dokładnego dopasowania względem tych elementów metadanych:

Idealnym sposobem skonfigurowania obciążenia jest uruchomienie każdej aplikacji na dedykowanym koncie użytkownika z unikatowymi grupami o określonym zakresie, a następnie napisanie reguł tylko dla tych właściwości. Nie można sfałszować identyfikatora użytkownika i nie trzeba się martwić o dopasowanie wzorców. Jednak ponieważ ta metoda nie jest praktyczna we wszystkich obciążeniach, oferujemy inne właściwości.

Jeśli określisz wiele właściwości, dopasowanie jest wykonywane jako logiczne AND. Rozważmy na przykład tę definicję tożsamości:

{
    "name": "WebServer",
    "exePath": "/usr/sbin/apache2",
    "processName": "apache2",
    "groupName": "www-data"
}

Definicja wygenerowałaby następującą walidację:

bool isWebServerIdentity = properties["exePath"] == "/usr/sbin/apache2"
    && properties["exePath"] == "apache2"
    && properties["groups"].contains("www-data");

Uprawnienia

Uprawnienia udzielają dostępu do określonych punktów końcowych. Niektóre punkty końcowe działają zgodnie z architekturą REST i mogą być przedstawione wyłącznie jako ścieżka. Inne mają wpływ na parametry zapytania.

Uprawnienia są definiowane z wartością name , wartością path i opcjonalnym zestawem queryParameters wartości:

"privileges": [
    {
        "name": "GoalState",
        "path": "/machine",
        "queryParameters": {"comp": "goalstate"}
    },
    {
        "name": "config",
        "path": "/machine",
        "queryParameters": {"comp": "config"}
    }
]

Reguły porównania

• Dopasowywanie ciągów jest niezależne od wielkości liter.
• Jeśli nie określono parametrów zapytania, uprawnienie przyznaje dostęp do wszystkich możliwych wartości w tej ścieżce.

Domyślne reguły dostępu

Możesz użyć domyślnych trybów dostępu (defaultAccess), aby powoli blokować obciążenie. Można ich również użyć do uproszczenia tworzenia reguł, gdy chcesz ograniczyć dostęp tylko do określonych punktów końcowych.

• Jeśli podano parametry zapytania, pytanie "Czy zdefiniowano uprawnienie?" do określenia, czy defaultAccess ma zastosowanie, staje się: "Czy jakakolwiek reguła jest zgodna z tą ścieżką + każdy określony parametr zapytania w regule jest obecny + pasuje do żądania?". Dodatkowe parametry zapytania są ignorowane w tej ocenie.
• Żądanie jest odrzucane, jeśli zduplikowane klucze parametrów zapytania w żądaniu są nieprawidłowe.

Pisanie reguł

Określenie listy dozwolonych przez reguły RBAC jest opcjonalne. Ale jeśli go określisz, musisz podać wszystkie pola. Jeśli na przykład nie masz żadnych roles wartości do zdefiniowania, nadal udostępnisz pustą tablicę.

Najprostszym sposobem generowania reguł jest najpierw uruchomienie programu MSP w Audit trybie. Następnie użyj dzienników inspekcji, aby wygenerować reguły.

Następujące pełne rozszerzenie schematu usługi Azure Instance Metadata Service zawiera przykład rules podsekcji:

{
  "defaultAccess": "allow",
  "mode": "enforce",
  "rules": {
    "privileges": [
      {
        "name": "Msi",
        "path": "/metadata/identity/oauth2/token"
      }
    ],
    "roles": [
      {
        "name": "MyWebApp",
        "privileges": [
          "Msi"
        ]
      }
    ],
    "identities": [
      {
        "name":"MyWebApp1",
        "processName":"WebApp1"
      }
    ],
    "roleAssignments": [
      {
        "role": "MyWebApp",
        "identities": [
          "MyWebApp1"
        ]
      }
    ]
  },
  "id": "D/uTRPye9b9xSUCRIgfRDF41zeY="
}

Następujące pełne rozszerzenie schematu WireServer przedstawia przykład rules podsekcji:

{
  "defaultAccess": "allow",
  "mode": "enforce",
  "rules": {
    "privileges": [
      {
        "name": "GoalState",
        "path": "/machine",
        "queryParameters": {
          "comp": "goalstate"
        }
      }
    ],
    "roles": [
      {
        "name": "Provisioning",
        "privileges": [
          "GoalState"
        ]
      }
    ],
    "identities": [
      {
        "name": "WinPA",
        "exePath": "C:\\Windows\\OEM\\Unattend.wsf.exe",
        "processName": "winpa.exe",
        "userName": "SYSTEM"
      }
    ],
    "roleAssignments": [
      {
        "role": "Provisioning",
        "identities": [
          "WinPA"
        ]
      }
    ]
  },
  "id": "D/uTRPye9b9xSUCRIgfRDF41zeY="
}

Konfiguracje niejawne i domyślne

Następująca definicja RBAC jest stosowana jako domyślne zachowanie dla reguł dostępu w ramach obrony w głąb, które istniały przed MSP.

{
    "imds": {
        "defaultAccess": "Allow",
        "mode": "Disabled",
    },
    "wireServer": {
        "defaultAccess": "Allow",
        "mode": "Enforce",
    }
}

Pamiętaj, że serwer WireServer zezwala tylko na dostęp z poziomu procesów administratora lub głównego. Wartość defaultAccess jest nadal Allow tutaj, ponieważ ta reguła nie jest konfigurowalna przez użytkownika. Jest to część GPA. GpA sprawdza, czy klient jest użytkownikiem administratora przed oceną reguł RBAC dla żądania WireServer. Jeśli klient nie jest użytkownikiem administratora, żądanie zostanie natychmiast odrzucone.