Ukrywanie poufnych informacji w plikach dziennika

Jak ukryć poufne informacje przed przechodzeniem do plików dziennika? Tak, możesz świadomie zrezygnować z rejestrowania wrażliwych bitów informacji w pierwszej kolejności, ale mogą istnieć ogólne przypadki, w których ślepo logujesz komunikaty o błędach w przypadku awarii lub wiadomości śledzenia podczas badania problemu itp., A kończysz na poufnych informacjach lądujących w twoim pliki dziennika.Ukrywanie poufnych informacji w plikach dziennika

Na przykład można próbować wstawić do bazy danych rekord zamówienia zawierający numer karty kredytowej klienta. Po awarii bazy danych może być konieczne zalogowanie właśnie wykonanej instrukcji SQL. W ten sposób otrzymasz numer karty kredytowej klienta w pliku dziennika.

Czy istnieje paradygmat projektowania, który można zastosować, aby "oznaczyć" określone fragmenty informacji jako wrażliwe, aby ogólny układ rejestrowania mógł je odfiltrować?

Źródło

2009-09-23 Ates Goral

Na zalecenie, aby przenieść to pytanie serverfault.com: Nie jest to pytanie z perspektywy oprogramowania. Chcesz, aby Twoje oprogramowanie było wystarczająco inteligentne, aby pomóc użytkownikom zamaskować poufne informacje. Jest to w istocie rzeczywisty wymóg, który widziałem od prawdziwych klientów. –

* jesteś -> twój (po 7 latach) –

Moja obecna praktyka w omawianej sprawie polega na rejestrowaniu mieszania takich poufnych informacji. To pozwala nam identyfikować zapisy dziennika, które należą do konkretnego roszczenia (na przykład konkretny numer karty kredytowej), ale nie daje nikomu uprawnień do chwytania dzienników i wykorzystywania wrażliwych informacji do ich złych celów.

Oczywiście robi to konsekwentnie z dobrymi praktykami kodowania. Zwykle rejestruję wszystkie obiekty, używając przeciążenia toString (w Javie lub .NET), które serializują wartość mieszającą dla pól oznaczonych przy użyciu atrybutu Sensitive.

Oczywiście, łańcuchy SQL są bardziej problematyczne, ale bardziej polegamy na ORM dla trwałości danych i logujemy stan systemu na różnych etapach, a następnie logujemy zapytania SQL, w związku z czym staje się on problemem.

Źródło

2010-01-02 14:50:32 paracycle

Podoba mi się pomysł przesłonięcia toSource; w ten sposób kod rejestracyjny nie musi przejmować się tym, co jest rejestrowane. Chociaż nie rozwiązuje problemu ze zrzutami pamięci, przyjmuję to jako najlepszą odpowiedź, ponieważ bezpośrednio odpowiada na oryginalne pytanie. Dzięki! –

Sama osobiście uważałabym pliki dziennika za poufne i zapewniam ograniczenie dostępu do nich.

Źródło

2009-09-23 15:56:51

Prawda! Mam na myśli przypadki, w których jesteś sprzedawcą oprogramowania i proszą klientów o przesłanie plików dziennika z ich systemu w celu zdiagnozowania awarii systemu itp. Czy na kliencie powinien najpierw wyczyścić swoje pliki dziennika? Wrażliwa informacja? Czy nie byłoby miło, gdyby twój system miał sposób, aby klienci mogli to dostać za darmo? –

"Ograniczanie dostępu" nie jest wystarczająco szczegółowe, aby zapewnić wystarczającą ochronę danych karty kredytowej. Dzienniki muszą być zaszyfrowane, a dostęp do kluczy odszyfrowywania musi być zapisany w polityce bezpieczeństwa. – erickson

W twoim przykładzie powinieneś szyfrować numer karty kredytowej lub, jeszcze lepiej, nawet nie przechowywać go w pierwszej kolejności.

Jeśli, na przykład, rejestrowałeś coś innego, np. Login, możesz jawnie zamienić hasło na *****.

Jednak to udaje się starannie uniknąć odpowiedzi na postawione pytanie. Ogólnie rzecz biorąc, przy przetwarzaniu poufnych informacji, powinien być zaszyfrowany w drodze do dowolnej formy trwałego przechowywania, czy to pliku bazy danych, czy pliku dziennika. Załóżmy, że Bad Guy również będzie w stanie dostać się w swoje ręce i odpowiednio zabezpieczyć informacje.

Źródło

2009-09-23 15:56:54

Myślę, że szyfrowanie może być odpowiedzią: gdy tylko poufne informacje wejdą do twojego systemu, zostaną zaszyfrowane i będą szyfrowane. Tak więc, jeśli logujesz się na niskim poziomie (agnostyk semantyczny) lub nawet robisz zrzut pamięci, informacje będą rozsądnie bezpieczne. Myślę, że podoba mi się pomysł szyfrowania informacji zamiast całego pliku dziennika, co sugerują inne odpowiedzi. –

Jeśli wiesz, co próbujesz filtrować, możesz uruchomić zapisywanie danych wyjściowych za pomocą wyrażeń czyszczących Regex, zanim się zalogujesz.

Źródło

2009-09-23 15:57:24

Tak, myślałem o tym. W rzeczywistości może to być realne rozwiązanie, ponieważ zawsze znajdzie się dyskretna liczba różnych typów "wrażliwych" łańcuchów, które można zidentyfikować w wyrażeniach regularnych. –

Logowanie numeru karty kredytowej może być naruszeniem PCI. A jeśli nie jesteś zgodny z PCI, zostaniesz obciążony wyższymi opłatami za przetwarzanie kart. Albo nie rejestruj wrażliwych informacji, ani nie szyfruj wszystkich plików dziennika.

Twój pomysł "oznaczania" poufnych informacji jest intrygujący. Możesz mieć specjalny typ danych dla informacji Sensitive, który zawijał prawdziwy, bazowy typ danych. Kiedy ten obiekt jest renderowany jako ciąg znaków, po prostu zwraca "***" lub cokolwiek innego.

Może to jednak wymagać szeroko zakrojonych zmian w kodowaniu i wymaga takiego poziomu czujności, jaki jest potrzebny do uniknięcia rejestrowania poufnych informacji.

Źródło

2009-09-23 15:59:23 erickson

Jeśli chodzi o instrukcje SQL, jeśli twój język je obsługuje, powinieneś używać parametrów zamiast umieszczać wartości w samej instrukcji. Innymi słowy:

select * from customers where credit_card = ?

Następnie ustaw parametr na numer karty kredytowej.

Oczywiście, jeśli planujesz logować instrukcje SQL z wypełnionymi parametrami, potrzebujesz innego sposobu odfiltrowania poufnych danych.

Źródło

2009-09-23 16:03:28

Prawda. Ale obejmuje to tylko instrukcje SQL. –

Dlatego poprzedzałem go słowem "Dotyczy konkretnie instrukcji SQL". To nie miało być w 100% ogólne. –

Noted. Szukałem raczej rozwiązania z srebrną kulą zamiast analizy pojedynczych przypadków, ale dziękuję za tę odpowiedź! –

Skorzystaj z tego narzędzia, stworzonego właśnie dla tego przypadku użycia.

Jeśli chcesz zamaskować tylko wybrane pole, podczas rejestrowania i zachowaj inne wartości pola bez zmian. możesz spróbować tego.

https://github.com/senthilaru/sp-util

<dependency> 
    <groupId>com.immibytes</groupId> 
    <artifactId>sp-utils</artifactId> 
    <version>1.0.0-RELEASE</version> 
</dependency>

Źródło

2016-02-23 19:45:27

Ukrywanie poufnych informacji w plikach dziennika

Odpowiedz

Powiązane problemy