EN
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.
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
W ramach listy dostępnych playbook’ów znalazłem ten realizujący aktualne potrzeby
- Sprawdź czy istnieje Watchlist o podanej nazwie i jeśli nie istniej utwórz.
- 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.
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.
Pomimo tego nadal element ten nie wykonywal się poprawnie, pojawiał się błąd uwierzytelnienia w Azure AD.
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.
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:
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.