Projekt bez tytułu(7)

Azure Sentinel pozwala na tworzenie automatyzacji w oparciu o Azure Logic Apps, które użyte w ramach Azure Sentinel są nazywane Playbooks. Sytuacja taka powoduje, że mamy dostęp do bardzo szerokiego spektrum elementów, z  których  możemy zbudować działania automatyzacji. Jednocześnie dla administratora Azure Sentinel, najczęściej niebędącego na co dzień DEVOPS-em. To bogactwo oraz dynamika rozwoju i zmian Azure Sentinel jak i Azure Logic Apps, powoduje, że znalezienie pomocy w rozwiązaniu opisywanego problemu bywa dość trudne.

Moim celem było rozbudowanie automatyzacji o korzystanie z jednego z najnowszych elementów jakie ostatnio zostały udostępnione w Azure Sentinel – Watchlist. Jest to definiowany i edytowalny po utworzeniu słownik, pozwalający unikać „hardkodowania”

w zapytaniach analitycznych quasi statycznych danych jak np.: list adresów IP,  nazw wrażliwych kont itp. Watchlist jest przechowywany jako element obszaru roboczego Log Analytics, w którym został dodany (enabled) Azure Sentinel.

MENU WATCHLIST W AZURE SENTINEL

Pomimo bogactwa funkcji, moduł Azure Logic Apps z elementami dedykowanymi dla Azure Sentinel, do niedawna nie oferował funkcjonalności zarządzania Watchlist. W Azure Portal można było dodać lub usunąć Watchlist, edytowanie jego zawartości nie było możliwe,

a także Azure Logic Apps nie dawały tej możliwości (w momencie pisania tego tekstu – te możliwości są już znacznie rozbudowane). Jedynym mechanizmem wspierającym automatyzację działań w tym zakresie był Azure REST API i z niego postanowiłem skorzystać. Ponieważ nie miałem wcześniej doświadczenia w korzystaniu z REST API

w ramach Logic Apps, postanowiłem skorzystać z pomocy społeczności Azure Sentinel.

          Aby ułatwić życie osobom zajmującym się Azure Sentinel i pozwolić na wymianę doświadczeń, Microsoft stworzył społeczność na GitHub. Zagubiony administrator poszukujący rozwiązania swojego problemu bardzo często może go tu znaleźć. Do portalu społeczności można dostać się z menu Azure Sentinel lub wchodząc na stronę https://github.com/Azure/Azure-Sentinel

mo2
MENU COMMUNITY W AZURE SENTINEL
mo3
AZURE SENTINEL GITHUB COMMUNITY

W ramach listy dostępnych playbook’ów znalazłem ten realizujący aktualne potrzeby

 

  1. Sprawdź czy istnieje Watchlist o podanej nazwie i jeśli nie istniej utwórz.
  2. Dodaj do Watchlist element zgodny z jego strukturą, w tym przypadku para: adres_IP_serwera i nazwa_serwera.

Adres playbook’a:

https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Watchlist-Add-IPToWatchList

Zaimportowałem playbook bezpośrednio ze strony za pomocą przycisku „Deploy to Azure”, podając niezbędne parametry importu, wymagane przez playbook. Następnie zgodnie

z wymaganiami Azure Logic Apps skonfigurowałem połączenia API dla wymagających tego elementów playbook’a. Problem pojawił się przy elementach realizujących główne zadania playbook’a, a korzystających z REST API, ponieważ wymagały użycia do uwierzytelnienia Managed Identity.

mo4
UWIERZYTELNIENIE DLA ELEMENTU ZAPYTANIA REST API

Zgodnie z zaleceniami autora playbook’a dla Azure Logic App została utworzona poprawnie Managed Identity w Azure AD z poziomu Logic App i zweryfikowana w Azure AD.

mo5
WŁĄCZENIE SYSTEM ASSIGNED MANAGED IDENTITY DLA LOGIC APP

Pomimo tego nadal element ten nie wykonywal się poprawnie, pojawiał się błąd uwierzytelnienia w Azure AD.

mo6
BŁĄD UWIERZYTELNIENIA ELEMENTÓW ZAPYTAŃ REST API PLAYBOOK’A

Zweryfikowałem zarówno ID tenanta, jak i resource principal, ale wszystko się pozornie zgadzało. Managed Identity było zarejestrowane poprawnie, playbook był widoczny w Azure AD oraz miał nadane niezbędne uprawnienia na Resource Group, w której znajdował się obszar roboczy Log Analytics z Azure Sentinel. Znalazłem kilka wpisów na blogach dotyczących mojego problemu w pewnym zakresie, ale albo były już nieaktualne z powodów zmian w Azure. Zmiany wprowadzone na podstwie tych wpisów nie dawały żadnego efektu. Jedyną, ale bardzo istotną wiedzą jaką wyniosłem z lektury tych blogów, była informacja

o konieczności skupienia się na polu Audience. Audience jest wartością identyfikującą „aplikację” w Azure, wobec, której Azure Logic App jest uwierzytelniany w AD

i autoryzowany. Zacząłem szukać jak określić identyfikator, który należy podać w polu Audience. W blogach za każdym razem był to identyfikator typu GUID. Niestety był to mylny trop, gdyż nie była to aplikacja zarejestrowana w np. w Enterprise Applications,

a systemowy serwis REST API Azure dostępny za pomocą systemowego identyfikatora.



mo7
ZAPYTANIE REST API W LOGIC APP

Watchlist jest elementem zapisanym w zasobie Azure, jakim jest obszar roboczy Log Analytics, dostępny poprzez Resource Manager, odwołanie się do niego za pomocą REST API, tworzy właśnie z Resource Manager’a Audience dla naszego playbook’a.

Na stronie https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities#azure-services-that-support-azure-ad-authentication znajdziecie listę serwisów Azure wspierających autentykację za pomocą Managed Identity.

Natomiast na stronie https://docs.microsoft.com/en-us/azure/logic-apps/create-managed-service-identity#authenticate-access-with-managed-identity znajdziecie dodatkowe materiały do definiowania autentykacji w Azure Logic Apps za pomocą Managed Identity.

 

 

Ostatecznie element Azure Logic Apps zawierający zapytanie do Log Analytics zawierający Watchlist:

mo8
ZAPYTANIE REST API Z AUTENTYKACJĄ MANAGED IDENTITY

Podsumowując wszystkie podjęte działania, można dojść do wniosków:

  • W pracy z Azure Sentinel musi istnieć ścisła współpraca pomiędzy inżynierami bezpieczeństwa konfigurującymi ten produkt a osobami posiadającymi wiedzę z zakresu DevOps,
  • Bardzo dynamiczne zmiany jakie zachodzą w Azure, mające oczywiście wg. Microsoft służyć rozwojowi platformy, mogą być Waszymi przyjaciółmi lub największymi wrogami. Jeśli jesteście z Azure na bieżąco, śledzicie newslettery i informacje o zmianach – raczej sobie poradzicie, jeśli nie – znalezione w sieci porady mogą Was sprowadzić na manowce,
  • Korzystajcie z Managed Identities, bo nadacie aplikacjom konkretne prawa do konkretnych zasobów i zminimalizujecie konieczność pilnowania zmiany haseł dla kont, co zawsze jest problemem. Azure Sentinel bardzo dobrze po ostatnich zmianach w konektorze Azure AD radzi sobie ze śledzeniem takich logowań aplikacji w Azure, dlatego łatwo jest wykryć anomalie, które mogą być zagrożeniem. A o konektorze Azure AD i innych elementach zapewne będziecie mogli poczytać na kolejnych wpisach na blogu ISCG.

Autor: Mariusz Orkisz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *