0 / 0
Go back to the English version of the documentation
Monitorowanie dostępu do danych za pomocą narzędzia kontroli Db2 w programie Watson Query
Last updated: 07 cze 2023
Monitorowanie dostępu do danych za pomocą strategii kontroli w programie Watson Query

Aby zarządzać dostępem do poufnych danych, można użyć mechanizmów uwierzytelniania i kontroli dostępu w celu ustanowienia reguł i elementów sterujących dostępem do danych. Aby jednak chronić i wykrywać nieznane lub niedopuszczalne zachowania, dostęp do danych można monitorować za pomocą narzędzia kontroli Db2® .

Skuteczne monitorowanie niepożądanego dostępu do danych i późniejszej analizy może prowadzić do poprawy kontroli dostępu do danych oraz ostatecznego zapobiegania szkodliwemu dostępowi do danych przez nieuprawnionego lub niestrudzonego nieuprawnionego dostępu. Monitorowanie aplikacji i indywidualnego dostępu użytkowników, w tym czynności administrowania systemem, może udostępniać historyczny rekord działania w systemach baz danych.

Za pomocą narzędzia kontroli Db2 można generować i obsługiwać zapis kontrolny dla serii predefiniowanych zdarzeń bazy danych. Dla każdej kategorii zdarzeń, która jest dostępna do kontroli, do identyfikacji typu kategorii po nazwie kategorii jest używane słowo kluczowe jedno słowo. W przypadku kontroli dostępne są następujące kategorie zdarzeń:
Kontrola (AUDIT)
Generuje rekordy, gdy ustawienia kontroli są zmieniane lub gdy dostęp do dziennika kontroli jest uzyskiwany.
Sprawdzanie autoryzacji (CHECKING)
Generuje rekordy podczas sprawdzania autoryzacji prób dostępu do obiektów lub funkcji bazy danych Db2 lub manipulowania nimi.
Konserwacja obiektów (OBJMAINT)
Generuje rekordy podczas tworzenia lub usuwania obiektów danych, a także podczas zmieniania określonych obiektów.
Konserwacja zabezpieczeń (SECMAINT)
Generuje rekordy dla następujących warunków:
  • Nadawanie lub odbieranie uprawnień do obiektów lub uprawnień do bazy danych.
  • Nadawanie lub odbieranie etykiet bezpieczeństwa lub wyłączeń.
  • Zmiana autoryzacji grupy, autoryzacja roli lub nadpisanie lub ograniczenie atrybutów strategii bezpieczeństwa LBAC.
  • Nadawanie lub odwoływanie uprawnienia SETSESSIONUSER.
  • Modyfikowanie dowolnej z parametrów konfiguracyjnych SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP lub SYSMON_GROUP.
Administrowanie systemem (SYSADMIN)
Generuje rekordy, gdy wykonywane są operacje wymagające uprawnień SYSADM, SYSMAINT lub SYSCTRL.
Sprawdzanie poprawności użytkownika (VALIDATE)
Generuje rekordy podczas uwierzytelniania użytkowników lub pobierania informacji o zabezpieczeniach systemu.
Kontekst operacji (CONTEXT)
Generuje rekordy w celu wyświetlenia kontekstu operacji, gdy wykonywana jest operacja bazy danych. Ta kategoria umożliwia lepszą interpretację pliku dziennika kontroli. W przypadku użycia z polem korelatora zdarzeń dziennika, grupa zdarzeń może być powiązana z pojedynczą operacją bazy danych. Na przykład: instrukcja zapytania dla zapytań dynamicznych, identyfikator pakietu dla zapytań statycznych lub indykator typu wykonywanej operacji, takiej jak CONNECT, mogą zapewnić wymagany kontekst podczas analizowania wyników kontroli.
Wykonaj (EXECUTE)
Generuje rekordy podczas wykonywania instrukcji SQL.

W przypadku dowolnej z wymienionych kategorii można kontrolować niepowodzenia, sukcesy lub obie te wartości.

Wszystkie operacje na serwerze bazy danych mogą generować kilka rekordów. Rzeczywista liczba rekordów wygenerowanych w dzienniku kontroli zależy od liczby kategorii zdarzeń, które mają zostać zarejestrowane zgodnie z konfiguracją narzędzia kontroli. Zależy ona również od tego, czy kontrolowane są sukcesy, niepowodzenia czy oba te elementy. Ważne jest, aby być selektywnym, aby zdarzenia były kontrolowane.

Rekordy wygenerowane z tego narzędzia można wyświetlić z zestawu tabel AUDIT, w których każda tabela odpowiada każdej kategorii. Analiza tych rekordów może ujawnić wzorce użycia, które mogą identyfikować nieprawidłowe użycie systemu. W przypadku zidentyfikowania niewłaściwego użycia działania mogą zostać podjęte w celu zredukowania lub wyeliminowania niewłaściwego użycia systemu.

Narzędzie kontroli umożliwia kontrolowanie na poziomie bazy danych. Każdy członek grupy administratorów może skonfigurować strategię kontroli, która ma być sterowana podczas gromadzenia takich informacji, takich jak monitorowanie identyfikatorów autoryzowanych użytkowników, uprawnienia do bazy danych, konteksty zaufane lub konkretne tabele.

Szybki start

  • AUDIT_ALL to predefiniowana strategia, która jest skonfigurowana podczas wdrażania. Ta strategia kontroluje wszystkie sukcesy i niepowodzenia dla każdej kategorii rekordów kontroli. Zaleca się utworzenie niestandardowej strategii pasującej do potrzeb użytkownika.
  • AUDIT_UPDATE jest predefiniowaną procedurą, która wyodrębnia i ładuje rekordy kontroli do AUDIT.* decyzyjnych.
  • Instrukcje AUDIT wymagają, aby użytkownicy posiadali uprawnienia SECADM. Aby wyświetlić dane w formacie AUDIT.* tabele, użytkownicy, którym nadano uprawnienie SELECT do tych tabel, mają dostęp do tych tabel.
Ważne: Gdy strategia kontroli jest włączona, a zadanie kontroli jest zaplanowane, AUDIT.* tabele kumulują się w systemie. Użytkownik musi zarządzać pamięcią masową używaną przez AUDIT.* decyzyjnych. Należy okresowo wyeksportować dane kontroli, aby zapisać je w trybie bez połączenia i wyczyścić dane w AUDIT*. decyzyjnych.
Aby włączyć funkcję AUDIT w celu przechwycenia wszystkich zdarzeń w usłudze dla każdej roli
AUDIT ROLE DV_ADMIN USING POLICY AUDIT_ALL;
AUDIT ROLE DV_ENGINEER USING POLICY AUDIT_ALL;
AUDIT ROLE DV_STEWARD USING POLICY AUDIT_ALL;
AUDIT ROLE DV_WORKER USING POLICY AUDIT_ALL;
Aby utworzyć zaplanowane zadanie aktualizacji kontroli w celu pobrania najnowszych rekordów kontroli do tabel kontroli co 15 minut (minimalny odstęp czasu między aktualizacjami)
CALL SYSPROC.ADMIN_TASK_ADD( 'AUDIT_UPDATE', NULL, NULL, NULL, '*/15 * * * *', 'AUDIT', 'UPDATE', NULL, NULL, 'Periodically update to audit tables' );
Aby wyświetlić rekordy kontroli z 8 kategorii zdarzeń kontrolowanych
select * from AUDIT.AUDIT;
select * from AUDIT.CHECKING;
select * from AUDIT.CONTEXT;
select * from AUDIT.EXCUTE;
select * from AUDIT.OBJMAINT;
select * from AUDIT.SECMAINT;
select * from AUDIT.SYSADMIN;
select * from AUDIT.VALIDATE;

Więcej informacji na ten temat zawiera sekcja Strategie kontroli.

  • CREATE AUDIT POLICY policy_name CATEGORIES category or ALL STATUS status ERROR TYPE NORMAL;

    Więcej informacji na ten temat zawiera sekcja CREATE AUDIT POLICY statement.

    Nazwy strategii kontroli
    Upewnij się, że nazwa jest unikalna, a jej cel jest łatwy do zidentyfikowania, na przykład AUDIT_SOC2_COMPLIANCE lub AUDIT_LOGIN_ONLY. Nazwy z SYS nie należy rozpoczynać, ponieważ jest ona zarezerwowana dla wewnętrznych nazw systemów w bazie danych.
    Kategorie do kontroli
    Strategia określa, które kategorie mają być kontrolowane. Ta strategia może być stosowana do innych obiektów bazy danych w celu określenia sposobu, w jaki mają być kontrolowane korzystanie z tych obiektów. Istnieje osiem dostępnych kategorii do kontroli. Im więcej kategorii jest skonfigurowanych, tym więcej informacji jest kontrolowany i gromadzi się w buforze kontroli, który zajmuje obszar obliczeniowy. Zrozumienie tego, co jest potrzebne w twoim celu, jest ważne, aby zapobiec przeciążanie przestrzeni obliczeniowych systemu. Podsumowanie opisuje każdą dostępną kategorię. Jeśli wartość ALL jest określona jako opcja kategorii, nie można określić żadnej innej kategorii.
    Aby zapewnić zgodność z większością standardów bezpieczeństwa, zalecane kategorie z poniższej listy będą adresować kontrolę dostępu, uwierzytelnianie i monitorowanie dostępu uprzywilejowanego. Skonfigurowanie strategii z tymi kategoriami zapewni minimalny narzut związany z utrzymaniem bezpieczeństwa.
    • EXECUTE WITHOUT DATA -Kontrola dostępu
    • VALIDATE -Uwierzytelnianie
    • SECMAINT -Monitorowanie dostępu uprzywilejowanego
    Ponadto w przypadku każdej kategorii należy kontrolować zarówno scenariusze powodzenia, jak i niepowodzenia, a typ błędu powinien rejestrować tylko błędy kodu SQL.
    • STATUS BOTH
    • ERROR TYPE NORMAL
  • AUDIT database_entity USING POLICY policy_name;

    Więcej informacji na ten temat zawiera sekcja Instrukcja AUDIT.

  • Dostosowaną strategię kontroli można skonfigurować w taki sposób, aby przechwytywać żądania uwierzytelniania i pomyślnie wykonywać komendy SQL i włączać je.

    CREATE AUDIT POLICY AUDIT_VALIDATE_EXECUTE CATEGORIES VALIDATE STATUS BOTH, EXECUTE STATUS SUCCESS ERROR TYPE NORMAL;
    Obiekty bazy danych do kontroli
    Kontrolowanie całej bazy danych spowoduje przeciążenie obszaru obliczeniowego. Zaleceniem jest identyfikowanie, do której tabeli i powiązanej zmaterializowanej tabeli zapytania (MQT), która ma być stosowana, strategia.
    Uwaga: Strategia kontroli, która odnosi się do tabeli, nie ma zastosowania do zmaterializowanej tabeli zapytania (MQT) opartej na tej tabeli. Jeśli strategia kontroli zostanie powiązana z tabelą, zaleca się powiązanie tej strategii z dowolną zmaterializowana tabela zapytania (MQT) w oparciu o tę tabelę. Kompilator może automatycznie używać zmaterializowanego tabeli zapytania (MQT), nawet jeśli instrukcja SQL odwołuje się do tabeli podstawowej. Jednak strategia kontroli używana dla tabeli podstawowej nadal będzie obowiązywać.

    Inną zalecaną konfiguracją jest zastosowanie strategii do grupy lub roli. Za pomocą tej konfiguracji można monitorować użytkowników, w których grupa i rola wykonują nieoczekiwane działania. Jeśli zostanie wybrana opcja zastosowania strategii dla całej bazy danych, należy upewnić się, że strategia nie zachowa rekordu wszystkich kategorii.

    Włącz strategię kontroli dla tabeli
    AUDIT TABLE CUSTOMTABLE USING POLICY AUDIT_VALIDATE_EXECUTE;

    Można również skonfigurować dostosowaną strategię kontroli tak, aby przechwytywać tylko żądania uwierzytelniania (zarówno powodzenia, jak i niepowodzenia), a następnie włączyć je.

    CREATE AUDIT POLICY AUDIT_VALIDATE_ONLY CATEGORIES VALIDATE STATUS BOTH ERROR TYPE NORMAL;
  • select * from SYSCAT.AUDITPOLICIES;
    Poniżej przedstawiono przykładowe dane wyjściowe, które są wynikiem uruchomienia poprzedniej instrukcji SELECT:
    
    AUDITPOLICYNAME              AUDITPOLICYID CREATE_TIME                ALTER_TIME                 AUDITSTATUS CONTEXTSTATUS VALIDATESTATUS CHECKINGSTATUS SECMAINTSTATUS OBJMAINTSTATUS SYSADMINSTATUS EXECUTESTATUS EXECUTEWITHDATA ERRORTYPE REMARKS
    
    ---------------------------- ------------- -------------------------- -------------------------- ----------- ------------- -------------- -------------- -------------- -------------- -------------- ------------- --------------- --------- -------
    
    AUDIT_VALIDATE_ONLY                    108 2018-07-23-21.00.57.024758 2018-07-23-21.00.57.024758 N           N             B              N              N              N              N              N             N               N         -
    
    AUDIT_ALL                              106 2018-07-23-20.51.18.017062 2018-07-23-20.51.18.017062 B           B             B              B              B              B              B              B             N               N         -
    
      2 record(s) selected.
    
  • select * from SYSCAT.AUDITUSE;
    Poniżej przedstawiono przykładowe dane wyjściowe, które są wynikiem uruchomienia poprzedniej instrukcji SELECT:
    
    AUDITPOLICYNAME           AUDITPOLICYID OBJECTTYPE SUBOBJECTTYPE OBJECTSCHEMA  OBJECTNAME        AUDITEXCEPTIONENABLED
    
    ------------------------- ------------- ---------- ------------- ------------- ----------------- ---------------------
    
    AUDIT_VALIDATE_ONLY                 108                          -             CURRENT SERVER    N
    
      1 record(s) selected.
    
  • Aby zatrzymać kontrolę nad jednostką bazy danych, strategia musi zostać usunięta.

    AUDIT database_entity REMOVE POLICY;

    Więcej informacji na ten temat zawiera sekcja Instrukcja AUDIT.

  • AUDIT GROUP BLUUSERS REMOVE POLICY;
  • Więcej informacji na ten temat zawiera sekcja Procedura ADMIN_TASK_ADD-planowanie nowego zadania.

    Aby utworzyć zaplanowane zadanie aktualizacji kontroli, aby pobrać najnowsze rekordy kontroli do tabel kontroli co 20 minut:
    CALL SYSPROC.ADMIN_TASK_ADD( 'AUDIT_UPDATE', NULL, NULL, NULL, '*/20 * * * *', 'AUDIT', 'UPDATE', NULL, NULL, 'Periodically update to audit tables' );
    Więcej informacji na ten temat zawiera sekcja Format programu cron UNIX w formacie harmonogramu.
    Częstotliwość planowania
    Częstotliwość uruchamiania predefiniowanego zadania, które archiwizuje dzienniki kontroli, jest poza zasięgiem tego testu, ale warto zwrócić uwagę na rekomendacje, które są zbierane z sytuacji klienta w czasie rzeczywistym. W przypadku większych baz danych zaleca się uruchamianie zadania archiwizacji co dzień przez 15 minut. Dzięki temu baza danych może zostać odzyskana w przypadku wystąpienia nieoczekiwanych problemów z wydajnością. Jeśli strategie są skonfigurowane zgodnie z zaleceniami, bufory kontroli powinny być w stanie zawierać obciążenie w danym przedziale czasu. Jak pokazały testy wydajności, jeśli skomplikowane zapytania uruchamiają się współbieżnie z archiwum rekordów kontroli, występują problemy z wydajnością.
  • select * from SYSTOOLS.ADMIN_TASK_STATUS;
    Poniżej przedstawiono przykładowe dane wyjściowe, które są wynikiem uruchomienia poprzedniej instrukcji SELECT:
    
      NAME          TASKID  STATUS     AGENT_ID     INVOCATION  BEGIN_TIME                 END_TIME                   SQLCODE  SQLSTATE SQLERRMC RC
      ------------- ------- ---------- ------------ ----------- -------------------------- -------------------------- -------- -------- -------- -----
      AUDIT_UPDATE        1 COMPLETE          16433           1 2018-07-23-21.50.00.135211 2018-07-23-21.50.10.584127        0          x''          0
      AUDIT_UPDATE        1 RUNNING           16448           2 2018-07-23-21.55.00.608060 -                                 - -        -            -
    
        2 record(s) selected.
      
  • CALL AUDIT.UPDATE();
    Uwaga: Po uruchomieniu tego wywołania procedury może pojawić się następujący komunikat:
    SQL1307N Wystąpił błąd podczas wywoływania funkcji kontroli zabezpieczeń.  Kod przyczyny: "9".

    Ten komunikat wskazuje, że nie było żadnych działań od czasu ostatniego załadowania tabel kontroli z danymi. Nie wskazuje to na błąd systemowy.

Generative AI search and answer
These answers are generated by a large language model in watsonx.ai based on content from the product documentation. Learn more