Zadawaj pytania, na które można odpowiedzieć dowodami
Kwestionariusz uwierzytelniania przedsiębiorstwa powinien łączyć wymagania biznesowe ze wspieranym zachowaniem, odpowiedzialnością operacyjną i dowodami akceptacji. Długa lista pytań dotyczących funkcji typu „tak” lub „nie” może ukrywać ważne ograniczenia: dostawca może obsługiwać szeroką kategorię, nie obsługując konkretnego najemcy, cyklu życia lub zachowania wdrożeniowego, jakiego potrzebuje kupujący. W ankiecie należy zatem zadać pytanie, co jest obsługiwane, w jakiej konfiguracji, kto to obsługuje i w jaki sposób można zweryfikować odpowiedź.
W tym artykule zaproponowano strukturę kwestionariusza i nie stwierdzono, że EmailAuth implementuje jakąkolwiek wymienioną funkcję. Nie skontaktowano się z żadnym dostawcą ani nie uzyskano odpowiedzi na kwestionariusz. Wskazówki dotyczące wspólnej odpowiedzialności firmy Microsoft I Wskazówki dotyczące tożsamości wielodostępnej platformy Azure dostarczają oficjalnych przykładów wyróżnień, które mają znaczenie, ale nie mogą zastąpić aktualnych dowodów pochodzących z ocenianego produktu.
Zacznij od zakresu i własności decyzji
Zapisz proponowaną populację klientów, domeny, przepływy pracy wysyłania, opcje wdrożenia, wymagane integracje i planowanych administratorów. Określ, które wymagania są obowiązkowe, które są preferencjami, a które wymagają wykwalifikowanego recenzenta prawnego, bezpieczeństwa lub handlowego. Kwestionariusz bez określonego zakresu może dać odpowiedzi, które są technicznie prawdziwe dla innego wydania lub środowiska. Zachowaj wersję produktu i przy każdej odpowiedzi umieść odnośnik do oferty.
Poproś dostawcę o rozróżnienie wsparcia wdrożonego, wsparcia zależnego od konfiguracji, prac planowanych i wymagań nieobsługiwanych. Nie przekształcaj daty planu działania w aktualne możliwości. Jeżeli odpowiedź zależy od innej usługi, określ tę zależność i stronę odpowiedzialną. Kupujący powinien udokumentować także swoje własne zobowiązania; dostawca nie może wykazać pełnego przepływu pracy, jeśli wymagane DNS klienta, decyzje dotyczące tożsamości lub dostępu pozostają niezdefiniowane.
Uwzględnij tożsamość, role i granice najemców
Zapytaj, w jaki sposób użytkownicy uwierzytelniają się, w jaki sposób tożsamości są powiązane z dzierżawcami i w jaki sposób przypisywane są uprawnienia do domen, raportów, eksportów i operacji administracyjnych. Wskazówki dotyczące tożsamości platformy Azure odróżniają uwierzytelnianie od autoryzacji opartej na rolach lub zasobach oraz uprawnień komercyjnych. Odzwierciedlaj te rozróżnienia w osobnych pytaniach. Oświadczenie, że SSO jest obsługiwane, nie oznacza izolacji klienta ani efektu redukcji roli w istniejącej sesji.
Dołącz pytania dotyczące tożsamości usług, cyklu życia użytkownika, dostępu do wsparcia dostawcy i dowodów audytu. Wymagaj bieżącego wyjaśnienia zachowań związanych z wyłączaniem i unieważnianiem, zamiast zakładać, że integracja udostępniania obsługuje każdą ścieżkę dostępu. Poproś o autoryzowane syntetyczne testy negatywne wykazujące, że jeden najemca nie może czytać, eksportować ani zmieniać zasobów innego dzierżawcy. Sam zrzut ekranu produktu lub lista ról nie dostarczają takiego dowodu.
Zapytaj, w jaki sposób uzyskuje się obserwacje uwierzytelniające
Dokumentuj źródła, z których korzysta platforma, opis ich zasięgu oraz sposób przedstawiania nieobsługiwanych lub brakujących obserwacji. RFC 9990 definiuje DMARC raportowanie zbiorcze, które ma własny proces wyszukiwania i dostarczania raportów. Zdolność platformy do analizowania raportów nie gwarantuje, że każdy odbiorca je wyśle lub że każdy legalny nadawca będzie reprezentowany w danym okresie.
Zapytaj, w jaki sposób produkt zachowuje oryginalne pochodzenie raportu, radzi sobie z duplikatami i wyjaśnia granice interpretacji. Jeśli łączy zdarzenia dostarczenia przez dostawcę z raportami uwierzytelniania, zapytaj, jakie identyfikatory pozwalają na powiązanie i czy wnioski dotyczą poziomu wiadomości czy strumienia. Nie żądaj uniwersalnej gwarancji dostawy na podstawie danych uwierzytelniających. Kwestionariusz powinien raczej ukazywać granice obserwacji produktu, a nie zachęcać do nieuzasadnionych twierdzeń o całkowitym pokryciu.
Wyjaśnij obowiązki wdrożeniowe i operacyjne
Zapytaj, które opcje wdrażania są obecnie obsługiwane i co każda z nich obejmuje. Określ, kto łata infrastrukturę, aktualizuje aplikację, zarządza tożsamościami, monitoruje pozyskiwanie, przeprowadza odzyskiwanie i obsługuje incydenty. Ramy wspólnej odpowiedzialności firmy Microsoft ilustrują, dlaczego obowiązki różnią się w zależności od modelu usługi, ale rzeczywisty dostawca musi zapewnić własny obsługiwany przydział. Odpowiedź oznaczona jako udostępniona powinna opisywać właściciela przekazania i weryfikacji, a nie tylko dzielić pole wyboru między dwiema stronami.
W przypadku opcji prywatnych lub dedykowanych zapytaj osobno o ścieżki sieciowe, obsługę danych, dostęp do pomocy technicznej i zależności zewnętrzne. Nie wnioskuj o izolacji na podstawie etykiety architektury. Wymagaj dowodów dotyczących odpowiednich granic i przejrzystych założeń dotyczących obciążenia pracą przy ustalaniu rozmiaru. Sam kwestionariusz nie powinien zezwalać na wdrożenie, zmianę zapory ogniowej ani transfer danych; działania te wymagają odrębnych, zatwierdzonych prac wdrożeniowych.
Uwzględnij wymagania dotyczące obsługi danych i audytu
Zapytaj, jakie dane są przechowywane, gdzie są umieszczane w obsługiwanych konfiguracjach, kto może uzyskać do nich dostęp i jak działa przechowywanie, usuwanie i eksportowanie. Rozróżniaj dane pierwotne, dzienniki, kopie zapasowe i artefakty wsparcia. Artykuł ten nie określa zgodności z prawem ani nie potwierdza zachowania dostawcy w zakresie miejsca zamieszkania. Odpowiedni wykwalifikowany właściciel powinien dokonać przeglądu wymogów umownych i regulacyjnych, korzystając z aktualnych dowodów.
Aby zapewnić możliwość kontroli, zapytaj, które działania są rejestrowane, czy uwzględniane są odmowy prób, w jaki sposób aktor i kontekst dzierżawy są reprezentowane oraz kto może eksportować lub zmieniać ustawienia przechowywania. Dokumentacja dziennika audytu Microsoft Entra to przykład oficjalnego opisu dziennika aktywności, a nie dowód zasięgu innego produktu. Wymagaj próbek i limitów specyficznych dla produktu, zamiast akceptować słowo audyt jako pełną odpowiedź.
Zapewnij przejrzystość nakładu pracy i założeń komercyjnych
Określ oczekiwane domeny, dzierżawców, użytkowników, liczbę raportów, tempo przechowywania i integracji, korzystając z zatwierdzonych danych wejściowych organizacji. Wyraźnie zaznaczaj szacunki i niewiadome. Częściowy miesiąc obserwacji może nie umożliwiać dokładnej prognozy rocznego obciążenia pracą. Zapytaj dostawcę, które zmienne wpływają na wycenę i w jaki sposób liczone są zmiany, ale nie wnioskuj o cenach ani zawartości pakietów na podstawie dokumentacji technicznej.
Należy oddzielić włączenie komercyjne od akceptacji technicznej. Funkcja może być zawarta w ofercie, ale nadal wymaga konfiguracji i dowodów; zademonstrowana funkcja może wykraczać poza proponowany pakiet. Rejestruj ważność, zakres i wykluczenia oferty tylko wtedy, gdy istnieje zatwierdzona oferta. W tym manuskrypcie nie przedstawiono żadnej ceny, rabatu, modelu kosztów ani zaleceń dotyczących zakupów.
Arkusz wymagań i dowodów
Twórz kolumny dla wymagań, powodów biznesowych, priorytetów, obsługiwanej konfiguracji, odpowiedzi dostawcy, źródła dowodów, recenzenta, testu akceptacyjnego, ograniczeń i decyzji. Dodaj rejestr założeń z danymi wejściowymi, źródłem, datą, pewnością i wpływem, jeśli jest błędny. Połącz każde obowiązkowe wymaganie z konkretnym dowodem, a nie z obszerną stroną marketingową. Zachowaj pytania bez odpowiedzi jako luki, zamiast interpretować ciszę jako wsparcie.
W przypadku testowalnych kontroli opisz autoryzowane urządzenie i oczekiwany wynik. W przypadku zobowiązań umownych należy wskazać odpowiednią zatwierdzoną umowę. W przypadku obowiązków operacyjnych należy zidentyfikować nazwanego właściciela i przekazać. Te rodzaje dowodów mogą się uzupełniać, ale nie należy ich bezkrytycznie zastępować. Umowa może przypisać odpowiedzialność bez wykazywania testu technicznego; pomyślny test może wykazać zachowanie bez tworzenia zobowiązania do wsparcia.
Fikcyjna diagnoza: kompletnie wyglądający kwestionariusz
Fikcyjny nabywca otrzymuje pozytywne odpowiedzi dotyczące logowania jednokrotnego, eksportu, wdrożeń prywatnych i dzienników audytu. Przegląd początkowo oznacza ukończenie kwestionariusza. Drugi recenzent pyta, która edycja obsługuje te funkcje, czy eksport zachowuje granice dzierżawców i co dzieje się z aktywną sesją po wyłączeniu. Oryginalne odpowiedzi nie rozwiązują tych pytań, ponieważ opisują kategorie, a nie wyniki.
Proponowana odpowiedź polega na zażądaniu dowodów o określonym zakresie i pozostawieniu wymagań, których to dotyczy, otwartych do czasu ich przeglądu. Kupujący nie musi oskarżać dostawcy o wprowadzenie w błąd; kwestionariusz mógł być po prostu zbyt niejasny. Ten scenariusz jest fikcyjny i nie opisuje żadnej rzeczywistej reakcji dostawcy ani luki w produkcie. Nie przeprowadzono żadnej komunikacji zewnętrznej ani testu.
Opublikuj luki wraz z rekomendacją
Przydatna ocena identyfikuje obsługiwane wymagania, zaakceptowane ograniczenia, nierozwiązane dowody i założenia dotyczące obciążenia pracą, które mogą zmienić decyzję. Powinien być czytelny zarówno dla właścicieli technicznych, jak i biznesowych, bez zawijania ich różnych obowiązków. Unikaj punktacji liczbowej, która sugeruje precyzję wykraczającą poza dowody, chyba że jej metoda i ograniczenia są wyraźnie zatwierdzone.
Katalog wymaga macierzy wymagań i dowodów oraz przejrzystych założeń dotyczących nakładu pracy lub kosztów. Te oryginalne artefakty pozostają otwarte. Otwarte pozostają także przegląd specjalistów, możliwość zastosowania źródeł, trasy produkcji, dostępność i zezwolenie właściciela. Ta wersja robocza zapewnia ramy i fikcyjne ćwiczenia, a nie ukończoną analizę due diligence dostawcy ani potwierdzenie możliwości usługi EmailAuth .