Dziennik phishingu e-mail

Ten raport to dziennik phishingu na poziomie zdarzeń: jeden wiersz na każdą zaobserwowaną interakcję w symulacji (data, akcja, adres e-mail odbiorcy, temat, nadawca, poziom trudności). Pozostaje w formie długiej — nie scala historii danej osoby w jeden wynik. Zapytanie obejmuje ostatnie 12 miesięcy kalendarzowych w occurred_after (północ UTC tego samego dnia miesiąca dwanaście miesięcy wcześniej — nie okres 365 dni). Konfiguracja, poświadczenia, stronicowanie i ponawianie po przekroczeniu limitu żądań są takie same jak w przewodniku łączności z Power BI / Excel. Najpierw dodaj wspólne zapytanie Fn_FetchAll; ten raport wywołuje je po nazwie.

​

Wymagane zakresy klucza

Klucz z uprawnieniem wyłącznie simulation:read nie może wywołać punktu końcowego zdarzeń raportowania (API zwraca 403). Zobacz wybór właściwego poziomu szczegółowości.

​

Źródłowe punkty końcowe

Dozwolone filtry na liście zdarzeń (każdy inny zwraca 400): limit, page_token, simulation, entity, event_type, occurred_after. Ta rodzina raportowania jest zestawem danych w wersji zapoznawczej. Schemat zestawu danych i zasady dotyczące danych możesz sprawdzić pod adresami GET /v1/reporting/datasets i GET /v1/reporting/datasets/simulation_events.

​

Poziom szczegółowości

Jeden wiersz na zdarzenie symulacji raportowania. Osoba, która otworzyła, a następnie kliknęła tę samą wiadomość, generuje dwa wiersze. Zdarzenia z wartością null w entity_id (brak uczestnika będącego aktorem / odbiorcą / celem) również są uwzględniane — email ma wtedy wartość null. Okno API jest poszerzone o jedną minutę; dokładna granica occurred_at >= WindowStart jest ponownie stosowana lokalnie, aby ostatni rok nie zależał od tego, czy serwer traktuje occurred_after jako włączny, czy wyłączny. Budżet żądań: jedno stronicowane przejście przez zdarzenia w oknie oraz jedno przejście przez encje. Zawsze ustawiaj limit = "500".

​

Mapowanie kolumn

Nazwy starszych kolumn pochodzą z eksportu poprzedniego dostawcy. Pola /v1 to publiczne nazwy API; zapytanie nadaje niektórym z nich aliasy na potrzeby raportu.

​

Tokeny akcji

action to zamknięty token raportowania. Starsze „Email Sent” odpowiada simulation.delivered (delivered to publiczny czasownik; token przesyłany w sieci to simulation.delivered). Dodatkowe pola zachowane, ponieważ udostępnia je API: sender_domain, full_name, event_id, entity_id, simulation_id, occurred_at oraz entity_type i entity_status z dołączenia encji.

​

Różnice względem starszego eksportu

• Surowy adres IP nigdy nie jest dostępny. /v1 nie udostępni surowego adresu IP klienta — wynika to z zasady ochrony prywatności już w fazie projektowania, a nie z oczekującego mapowania. Zapytanie nie dodaje kolumny zastępczej z adresem IP.
• Typ urządzenia jest pochodny, a nie surowy. device_type to pochodna klasa urządzenia dla zdarzeń kliknięcia, przesłania i zgłoszenia. Obserwowane tokeny obejmują desktop, mobile, tablet i unknown, ale emiter zapisuje dowolny ciąg znaków — traktuj go jako tekst otwarty, a nie zamknięte wyliczenie. Ma wartość null, gdy zdarzenie nie ma klasy pochodnej, a surowy ciąg user_agent pozostaje prywatny.
• „Email Sent” to simulation.delivered. Używaj tego tokenu podczas filtrowania lub liczenia wysłanych wiadomości. Nie szukaj starszego ciągu email_sent.
• Adres e-mail odbiorcy jest dołączany, a nie jest polem zdarzenia. Zdarzenie raportowania pomija adres e-mail; zapytanie przechodzi przez /entities, aby go uzupełnić.
• Ostatnie 12 miesięcy kalendarzowych, a nie okres 365 dni ani pełna historia.
• Forma długa, bez scalania. Jeden wiersz na interakcję, a nie jeden wynik na osobę.

​

Dalsze kroki