Systemy HR mogą wysyłać wiadomości, które wyglądają jak poczta wewnętrzna, ale pochodzą z platform rekrutacyjnych, dostawców usług płacowych i aplikacji do obsługi pracowników. Pierwszym zadaniem jest identyfikacja faktycznego konta organizacji i właściciela każdej trasy. Rozpoznawalna marka dostawcy nie jest dowodem na to, że e-mail lub powiadomienie o płacach konkretnego kandydata zostało autoryzowane przez pracodawcę.
Przed zmianą zasad podziel własność
Przypisz powiadomienia o rekrutacji do właściciela operacji rekrutacyjnych, powiadomienia o płacach do właściciela usługi płacowej, a aktualizacje dotyczące pracowników do właściciela operacji kadrowych. Dostawca rekordów najemca, cel, z tożsamości, domena koperty, DKIM domena podpisująca i selektor, przekierowanie odpowiedzi i zatwierdzony kontakt z pomocą techniczną. Jeśli dostawca obsługuje kilka spółek zależnych, zapisz podmiot prawny i domenę, z której ma korzystać każde konto, zamiast traktować grupę jako jednego niezróżnicowanego nadawcę.
Spis powinien zawierać metadane operacyjne, a nie życiorysy kandydatów, szczegóły dotyczące wynagrodzeń czy identyfikatory pracowników. Przechowuj wszelkie niezbędne zastrzeżone dowody pod odpowiednią kontrolą dostępu i przechowywania. Debugowanie uwierzytelniające nie oznacza pozwolenia na kopiowanie danych personelu do ogólnego zgłoszenia rozwiązywania problemów z pocztą.
Zrozum, co oznacza wynik
RFC 9989 ocenia uwierzytelnione użycie domeny. Nie świadczy to o tym, że oferta jest aktualna, czy korekta płacowa jest prawidłowa, czy też osoba rekrutująca jest uprawniona do podjęcia zobowiązania. Trzymaj decyzje dotyczące zatrudnienia i zmiany danych bankowych w ramach własnych procesów weryfikacji. Zatwierdzone konto, które zostało przejęte, może nadal wysyłać uwierzytelnione treści wprowadzające w błąd.
Użyj wyników i nagłówków zaufanego systemu odbierającego, aby porównać widoczną tożsamość From z tożsamością uwierzytelnioną. Nie polegaj na zrzucie ekranu zawierającym logo dostawcy lub niezaufany nagłówek wstawiony przez nadawcę. Zapytaj dostawcę o jego aktualną procedurę dotyczącą domeny niestandardowej specyficznej dla konta i zachowaj dowody konfiguracji bez ujawniania poświadczeń.
Sprawdź zawiadomienie pracownika bez pożyczania dowodów płacowych
Załóżmy, że powiadomienia o kandydatach i płacach korzystają z domen podpisujących odpowiadających ich domenom From, podczas gdy employees.hr.example pojawiają się w powiadomieniach o pracownikach, a provider.example.net jest ich domeną DKIM d=. Nawet zakładając, że podpis weryfikuje, nie spełnia rygorystycznego DKIM wyrównanie. Są to tożsamości hipotetyczne, a nie podpisane okazy ani rzeczywiste kontrole kryptograficzne. Wynik listy płac nie może zamknąć oddzielnej niezgodności w zawiadomieniu pracownika.
RFC 9989 sekcje 4.4 i 5.3.5 wymagają uwzględnienia innych odpowiednich wyrównanych ścieżek w celu uzyskania pełnego DMARC wynik. Dla p=reject wdrożenia, sekcje 7.4 i 8 wymagają raczej prawidłowego DKIM SPF sam. Oddzielnie odpowiedź kandydata może trafić do niewłaściwej kolejki rekrutacyjnej pomimo przejścia wiadomości wychodzącej. Zweryfikuj zatwierdzone miejsce docelowe odpowiedzi, korzystając z fikcyjnych rejestrów i kontrolowanych kont, a nie prawdziwych wnioskodawców lub danych osobowych.
Przetestuj rzeczywiste podróże pracowników i kandydatów
Użyj zatwierdzonego fikcyjnego konta kandydata i pracownika w obsługiwanym środowisku testowym. Wywołaj potwierdzenie aplikacji, nieszkodliwe powiadomienie o płacach i aktualizację pracowników poprzez ich rzeczywiste przepływy pracy. Potwierdź kontrolowany odbiór, uwierzytelnienie i przekierowanie odpowiedzi. Sprawdź, czy odpowiedź kandydata dotarła do oczekiwanej kolejki rekrutacyjnej, nie ujawniając danych innego kandydata. Traktuj dostęp do dokumentów i poprawność treści jako osobne kryteria akceptacji.
Jeśli dostawca oferuje tylko własną tożsamość From, właściciel firmy powinien zdecydować, czy wyraźnie przedstawiony obsługiwany adres spełnia potrzeby przepływu pracy. Nie fałszuj tożsamości pracodawcy poprzez nieobsługiwaną konfigurację ani nie dodawaj reguł obejścia szerokiego tylko po to, aby test wyglądał na pomyślny. Przetestuj ponownie obsługiwane zmiany i udokumentuj wszelkie pozostałe ograniczenia.
Zachowaj połączenie offboardingu z zarządzaniem nadawcami
Przeglądaj uprawnienia, gdy kończy się umowa agencyjna, zmienia się dostawca usług kadrowo-płacowych lub odchodzi administrator HR. Potwierdź przepływ pracy następcy przed wycofaniem kluczy lub zależności DNS . Zachowaj nazwanego właściciela odzyskiwania dla wrażliwych na czas wiadomości dotyczących kandydatów i płac. Oznacz trasę jako zaakceptowaną dopiero po zatwierdzeniu przez właściciela usługi aktualnego dowodu z badań; ani rekord DNS , ani przepustka uwierzytelniająca nie stanowią certyfikatu dotyczącego zatrudnienia, prywatności ani zgodności z przepisami.