Problemy z zabezpieczeniami i przydatne porady dotyczące śledzenia
W tym temacie opisano sposób ochrony poufnych informacji przed uwidocznieniem, a także przydatnych wskazówek podczas korzystania z hosta internetowego.
Używanie niestandardowego odbiornika śledzenia z WebHost
Jeśli piszesz własny odbiornik śledzenia, należy pamiętać o możliwości utraty śladów w przypadku usługi hostowanej w sieci Web. Podczas recyklingu WebHost zamyka działający proces, podczas gdy duplikat go przejmuje. Jednak dwa procesy muszą mieć dostęp do tego samego zasobu przez jakiś czas, który jest zależny od typu odbiornika. W takim przypadku XmlWriterTraceListener tworzy nowy plik śledzenia dla drugiego procesu; funkcja śledzenia zdarzeń systemu Windows zarządza wieloma procesami w ramach tej samej sesji i zapewnia dostęp do tego samego pliku. Jeśli twój własny odbiornik nie udostępnia podobnych funkcji, ślady mogą zostać utracone, gdy plik zostanie zablokowany przez dwa procesy.
Należy również pamiętać, że niestandardowy odbiornik śledzenia może wysyłać ślady i komunikaty na przewodach, na przykład do zdalnej bazy danych. Jako osoba wdrażająca aplikacje, powinieneś skonfigurować niestandardowych nasłuchiwaczy z odpowiednią kontrolą dostępu. Należy również zastosować kontrolę zabezpieczeń na wszelkie dane osobowe, które mogą być widoczne w lokalizacji zdalnej.
Rejestrowanie informacji poufnych
Ślady zawierają nagłówki komunikatów, gdy komunikat znajduje się w zakresie. Po włączeniu śledzenia informacje osobiste w nagłówkach specyficznych dla aplikacji, takie jak ciąg zapytania, oraz informacje o treści, takie jak numer karty kredytowej, mogą stać się widoczne w dziennikach. Narzędzie do wdrażania aplikacji jest odpowiedzialne za wymuszanie kontroli dostępu do plików konfiguracji i śledzenia. Jeśli nie chcesz, aby takie informacje były widoczne, należy wyłączyć śledzenie lub odfiltrować część danych, jeśli chcesz udostępnić dzienniki śledzenia.
Poniższe porady mogą pomóc zapobiec przypadkowemu ujawnieniu zawartości pliku śledzenia:
Upewnij się, że pliki dziennika są chronione przez listy kontroli dostępu (ACL) zarówno w scenariuszach WebHost, jak i self-host.
Wybierz rozszerzenie pliku, którego nie można łatwo obsłużyć przy użyciu żądania sieci Web. Na przykład rozszerzenie .xml pliku nie jest bezpiecznym wyborem. Możesz zapoznać się z przewodnikiem administrowania usługami IIS, aby wyświetlić listę rozszerzeń, które mogą być obsługiwane.
Określ ścieżkę bezwzględną dla lokalizacji pliku dziennika, która powinna znajdować się poza katalogiem publicznym vroot webhost, aby uniemożliwić dostęp do niego przez stronę zewnętrzną przy użyciu przeglądarki sieci Web.
Domyślnie klucze i dane osobowe, takie jak nazwa użytkownika i hasło, nie są rejestrowane w śladach i zarejestrowanych komunikatach. Administrator komputera może jednak użyć atrybutu enableLoggingKnownPII w machineSettings elementu pliku Machine.config, aby umożliwić aplikacjom działającym na maszynie rejestrowanie znanych danych osobowych w następujący sposób:
<configuration>
<system.ServiceModel>
<machineSettings enableLoggingKnownPii="Boolean"/>
</system.ServiceModel>
</configuration>
Wdrożeniowiec aplikacji może następnie użyć atrybutu logKnownPii w pliku App.config lub Web.config w celu włączenia rejestrowania danych osobowych (PII) w następujący sposób:
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging"
logKnownPii="true">
<listeners>
<add name="messages"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\logs\messages.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
Tylko gdy oba ustawienia są true, rejestrowanie PII jest włączone. Kombinacja dwóch przełączników umożliwia elastyczne rejestrowanie znanych danych PII dla każdej aplikacji.
Należy pamiętać, że jeśli określisz co najmniej dwa źródła niestandardowe w pliku konfiguracji, odczytywane są tylko atrybuty pierwszego źródła. Pozostałe są ignorowane. Oznacza to, że w przypadku następującego pliku App.config, PII nie jest rejestrowane dla obu źródeł, mimo że rejestrowanie danych osobowych jest jawnie włączone dla drugiego źródła.
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging"
logKnownPii="false">
<listeners>
<add name="messages"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\logs\messages.svclog" />
</listeners>
</source>
<source name="System.ServiceModel"
logKnownPii="true">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
</system.diagnostics>
Jeśli element <machineSettings enableLoggingKnownPii="Boolean"/> istnieje poza plikiem Machine.config, system zgłasza ConfigurationErrorsException.
Zmiany są skuteczne tylko wtedy, gdy aplikacja zostanie uruchomiona lub uruchomiona ponownie. Zdarzenie jest rejestrowane podczas uruchamiania, gdy oba atrybuty są ustawione na true. Zdarzenie jest również rejestrowane, jeśli logKnownPii jest ustawiona na true, ale enableLoggingKnownPii jest false.
Aby uzyskać więcej informacji na temat rejestrowania danych osobowych, zobacz przykład PII Security Lockdown.
Administrator maszyny i narzędzie do wdrażania aplikacji powinny zachować szczególną ostrożność podczas korzystania z tych dwóch przełączników. Jeśli rejestrowanie PII jest włączone, klucze zabezpieczeń i dane osobowe są rejestrowane. Jeśli są wyłączone, poufne i dane specyficzne dla aplikacji są nadal rejestrowane w nagłówkach i treściach komunikatów. Aby uzyskać bardziej szczegółową dyskusję na temat prywatności i ochrony danych osobowych przed ujawnieniem, zobacz Prywatność użytkowników.
Ponadto adres IP nadawcy komunikatów jest rejestrowany raz na połączenie dla transportów zorientowanych na połączenie i raz na wiadomość wysłaną w innych przypadkach. Odbywa się to bez zgody nadawcy. Jednak rejestrowanie odbywa się tylko na poziomach śledzenia Informacyjnym lub Szczegółowym, które nie są domyślnymi ani zalecanymi poziomami śledzenia w środowisku produkcyjnym, z wyjątkiem debugowania na żywo.