Jakie informacje nigdy nie mogą pojawiać się w logach? [Zamknięte]

Mam zamiar napisać wytyczne firmy dotyczące tego, co nigdy nie może pojawić się w logach (ślad aplikacji). W rzeczywistości niektórzy programiści starają się dołączyć do śledzenia jak najwięcej informacji, co powoduje, że przechowywanie tych dzienników jest ryzykowne, a ich przesyłanie jest wyjątkowo niebezpieczne , zwłaszcza gdy klient nie wie, że te informacje są przechowywane, ponieważ nigdy o to nie dbała i nigdy nie czytaj dokumentacji i / lub komunikatów ostrzegawczych.

Na przykład, mając do czynienia z plikami, niektórzy programiści mają pokusę, aby prześledzić nazwy plików . Na przykład przed dołączeniem nazwy pliku do katalogu, jeśli prześledzimy wszystko przez pomyłkę, łatwo będzie zauważyć na przykład, że dołączona nazwa jest za długa i że błąd w kodzie polegał na zapomnieniu sprawdzenia długości konkatenowany ciąg. Jest to pomocne, ale są to dane wrażliwe i nigdy nie mogą pojawiać się w logach .

W ten sam sposób:

• Hasła ,
• Adresy IP i informacje o sieci (adres MAC, nazwa hosta itp.) ¹,
• Dostęp do bazy danych,
• Bezpośrednie wprowadzanie danych użytkownika i przechowywanych danych biznesowych

nie może nigdy pojawić się w śladzie.

Jakie inne rodzaje informacji należy usunąć z dzienników? Czy są już jakieś wytyczne, których mogę użyć?

^{¹ Oczywiście nie mówię o takich rzeczach, jak dzienniki IIS lub Apache. Mówię o rodzaju informacji, które są gromadzone wyłącznie w celu debugowania samej aplikacji, a nie śledzenia aktywności niezaufanych podmiotów.}

Edycja: Dziękujemy za odpowiedzi i komentarze. Ponieważ moje pytanie nie jest zbyt precyzyjne, postaram się odpowiedzieć na pytania zadane w komentarzach:

• Co robię z dziennikami?

Dzienniki aplikacji mogą być przechowywane w pamięci, co oznacza albo w postaci zwykłej na dysku twardym na komputerze lokalnym, w bazie danych, ponownie w postaci zwykłej lub w zdarzeniach systemu Windows. W każdym przypadku chodzi o to, że źródła te mogą nie być wystarczająco bezpieczne. Na przykład, gdy klient uruchamia aplikację, a ta aplikacja przechowuje dzienniki w postaci pliku tekstowego w katalogu tymczasowym, każdy, kto ma fizyczny dostęp do komputera, może odczytać te dzienniki.

Dzienniki aplikacji można również przesyłać przez Internet. Na przykład, jeśli klient ma problem z aplikacją, możemy poprosić ją o uruchomienie tej aplikacji w trybie pełnego śledzenia i przesłanie nam pliku dziennika. Ponadto niektóre aplikacje mogą automatycznie wysyłać nam raporty o awariach (a nawet jeśli istnieją ostrzeżenia dotyczące poufnych danych, w większości przypadków klienci ich nie czytają).

• Czy mówię o konkretnych dziedzinach?

Nie. Pracuję tylko nad ogólnymi aplikacjami biznesowymi, więc jedynymi wrażliwymi danymi są dane biznesowe. Nie ma nic związanego ze zdrowiem lub innymi dziedzinami objętymi szczegółowymi przepisami. Ale dziękuję za rozmowę na ten temat, prawdopodobnie powinienem zapoznać się z tymi polami, aby uzyskać wskazówki na temat tego, co mogę zawrzeć w wytycznych.

• Czy nie jest łatwiej zaszyfrować dane?

Nie. Sprawiłoby to, że każda aplikacja byłaby znacznie trudniejsza, szczególnie jeśli chcemy użyć diagnostyki C # i TraceSource. Wymagałoby to również zarządzania autoryzacjami, co nie jest najłatwiejszym rozwiązaniem. Wreszcie, jeśli mówimy o dziennikach przesłanych do nas przez klienta, musimy być w stanie odczytać dzienniki, ale bez dostępu do poufnych danych. Z technicznego punktu widzenia łatwiej jest nigdy w ogóle nie zawierać poufnych informacji w dziennikach i nigdy nie dbać o to, jak i gdzie są one przechowywane.

Uważam, że najlepszym sposobem na poradzenie sobie z tym jest traktowanie plików dziennika jako kolejnego interfejsu użytkownika aplikacji. Fakt, że informacje są przechowywane w plikach tekstowych, nie odróżnia treści od informacji wyświetlanych na zwykłych ekranach interfejsu użytkownika.

Zastanów się, jak chroniłbyś te same informacje, gdyby były wyświetlane w zwykłym interfejsie użytkownika. Musisz określić, kim był użytkownik, a następnie ujawnić tylko informacje, które ten użytkownik miał prawo zobaczyć.

Informacje w plikach dziennika należy traktować w ten sam sposób. Najpierw musisz dokładnie odpowiedzieć, kto powinien być uprawniony do przeglądania pliku dziennika i jakie informacje powinni mieć dostęp.

Przekazywanie źle zaprojektowanych plików dziennika stanowi ogromne zagrożenie bezpieczeństwa. Nie sądzę, aby uzyskać dobre rozwiązanie tego problemu, umieszczając na czarnej liście dane. Lepszą strategią jest umieszczenie na białej liście tego, co może się znaleźć w każdym pliku dziennika i zaprojektowanie plików dziennika od dołu.

Informacje o karcie kredytowej nigdy nie powinny być rejestrowane.

Numery identyfikacyjne (takie jak SSN w USA lub Teudat Zehut # w Izraelu).

Nazwy komputerów w sieci, ścieżki udziału sieciowego.

Dane osobowe, które można zidentyfikować, objęte Ustawą o przenośności i rozliczalności ubezpieczeń zdrowotnych z 1996 r. (HIPAA). W tym artykule wymieniono następujące przykłady:

• Roszczenia zdrowotne lub informacje o spotkaniach medycznych, takie jak dokumentacja wizyt lekarskich oraz notatki lekarzy i innych pracowników świadczących usługi;
• Doradztwo w zakresie płatności i przekazów zdrowotnych;
• Koordynacja świadczeń opieki zdrowotnej;
• Status roszczenia zdrowotnego;
• Zapisywanie i wyrejestrowywanie w planie zdrowotnym;
• Kwalifikowalność do planu zdrowotnego;
• Płatności z tytułu ubezpieczenia zdrowotnego;
• Certyfikaty i autoryzacje za polecenie;
• Pierwsze zgłoszenie szkody;
• Załączniki do oświadczeń zdrowotnych.

jeśli bezpieczeństwo stanowi problem, zaszyfruj plik dziennika

Z czubka mojej głowy ....

Informacje o karcie kredytowej nie powinny znajdować się w dziennikach. Dane SSN (lub SIN) nie powinny znajdować się w logach.

... oczywiście są wyjątki, jeśli zdarzy Ci się pracować dla jakiegoś centralnego magazynu danych dla firmy obsługującej karty kredytowe lub agencji rządowej zarządzającej danymi SIN, być może będziesz musiał je zalogować, ponieważ jest to główne mięso tego, co masz przetwarza / zarządza.

Tak ale.

Do debugowania niektórych problemów potrzebujesz prawdziwych danych.

Musisz więc zagrać w grę równowagi: w rzeczywistości musisz omówić i uzgodnić z głównymi klientami, co uważają za poufne lub wrażliwe dane, a co nie. Jeśli kilku klientów się nie zgadza, weź najgorszy scenariusz dla każdego aspektu, chyba że możesz uzasadnić to tym klientom, którzy mogą przesadzić w oznaczaniu wszystkiego, co wrażliwe.

Pracowałem w kontroli ruchu lotniczego, finansach i bankowości. W każdej sytuacji są dane wrażliwe. Są zadania, w przypadku których nie można uniknąć przetwarzania poufnych danych, w takich przypadkach musisz mieć pewność, że możesz pracować z zaufanymi ludźmi. Ryzyko to można w pewnym stopniu ograniczyć dzięki klauzulom prawnym, które należy uzgodnić przed uzyskaniem dostępu do takich danych (umowy o nieujawnianiu, wykorzystanie danych wyłącznie z ważnych powodów biznesowych, ograniczony dostęp do danych, sankcje karne za nieprzestrzeganie lub egzekwowanie umów ...) - i odpowiednie procesy, które umożliwiają śledzenie tych rzeczy.

Jeśli dane są krytyczne, musisz zapłacić cenę za konfigurację systemów, które chronią integralność, spójność i bezpieczeństwo tych danych.

To powiedziawszy, masz rację, zadając pytanie „które dane”. Naprawdę sam na to odpowiadasz: większość jest związana z biznesem. Zapytaj więc swoich klientów, czy nie możesz odpowiedzieć sobie sam - mając na uwadze powyższe i zachowując sposób na identyfikację i naprawę problemów, które mogą się pojawić.

Powiedziałbym, że loguj wiadomości, które wydają się śmieszne, kiedy piszesz. Nie znajdziesz ich w zabawny sposób, a oni będą tam na zawsze - tak jak ten niedoinformowany post na blogu / facebook / twiter!

Trzymaj wiadomości dziennika nudne :)