2011-02-01 18 views
6

Używam programu NServiceBus z usługą MSMQ między moją aplikacją internetową a usługą i muszę mieć możliwość szyfrowania ładunku wiadomości, tak aby w przypadku wiadomości umieszczonej w kolejce lokalnie na serwerze sieci Web (host usługi nie działa), dane wrażliwe nie mogą być oglądane.Gdzie umieścisz klucz szyfrowania na publicznym serwerze?

Ponieważ serwer WWW jest dostępny publicznie, nie tylko wymagane jest szyfrowanie danych, które mogą być serializowane na dysku, ale także nie mogę przechowywać klucza szyfrowania na serwerze WWW.

Rozważałem użycie DPAPI do przechowywania klucza, ale ponieważ klucz byłby przechowywany na hoście, nie wiem jeszcze, czy to nie spełnia wymagań. Inną rozważaną przeze mnie opcją jest to, że po uruchomieniu aplikacji internetowej może zażądać klucza od usługi i przechowywać ją w pamięci przez cały okres istnienia puli aplikacji.

Nie musiałem już pracować z tym poziomem wymagań dotyczących szyfrowania i chciałbym dowiedzieć się, co robią inni, i uzyskać informacje zwrotne na temat wspomnianych wyżej pomysłów.

+4

Cokolwiek robisz, zatrudnij konsultanta ds. Bezpieczeństwa, aby zweryfikować skuteczność swojego projektu/wdrożenia. Jeśli nie jesteś ekspertem w tej dziedzinie, łatwo jest popełnić błąd, a koszty tego błędu mogą być olbrzymie w porównaniu do kosztów płacenia komuś, kto pomoże ci to naprawić. cf. Systemy płatnicze Heartland. – jason

+1

Nie wydaje mi się to problemem, który rozwiązuje asymetryczna kryptografia. – rook

+0

Klucz asymetryczny zmniejszyłby co najmniej prawdopodobieństwo, że obserwator odczyta istniejący stan z dysku. Jednak z asymetrycznym kluczem w ręku obserwator mógłby użyć tego, by rozpocząć atak siłami brutalnymi. – stephbu

Odpowiedz

0

Możesz zmienić źródło, z którego NServiceBus ciągnie swój klucz szyfrujący - to jest opisane tutaj docs: http://docs.particular.net/nservicebus/security/encryption

W ten sposób można uniknąć tej informacji poufnych przebywania na DMZ.

+0

Dzięki! Nie wiedziałem, że to była opcja. Po rozmowie z naszym dyrektorem ds. Bezpieczeństwa poprosimy o klucz z serwera niepublicznego i zapiszemy go w pamięci. –

7

Czy można użyć szyfrowania klucza publicznego/prywatnego? Następnie musisz tylko klucz publiczny na serwerze, a dane są odszyfrowane za pomocą klucza prywatnego w innym miejscu.

+0

Warto zauważyć, że szyfrowanie publiczno-prywatne może wymagać dużej ilości kryptograficznie bezpiecznej entropii (dla kluczy wiadomości, IV i dopełnienia) - może to być problem przy dużej przepustowości. – bdonlan

+0

Tak, zgadzam się - klucze asymetryczne bardzo by pomogły.Osiągnięcie wystarczająco silnego szyfrowania może wymagać poważnej mocy w systemie o dużej przepustowości. Zwróciliśmy się do krypto-sprzętu w jednym z naszych scenariuszy - drogie, trudne do zintegrowania, warte tego ". – stephbu

+0

brzmi świetnie, ale nie jestem pewien, czy uda mi się uzyskać zatwierdzenie kosztów. Tak jak powiedziałeś bez dedykowanego sprzętu, asymetryczne szyfrowanie zmniejszy przepustowość. Rozważałem użycie asymetrycznego tylko dla klucza, ale klucz do odszyfrowania klucza musiałby być przechowywany tam, gdzie aplikacja internetowa mogłaby uzyskać do niego dostęp. –

0

Najlepsze miejsce na encrypt is at the queue level. Robisz to przez sending private messages i tworząc kolejki, które akceptują tylko prywatne wiadomości. Chociaż można ustawić poziom prywatności kolejki podczas tworzenia kolejki w czasie tworzenia, nie jestem pewien, czy można skonfigurować program NServiceBus do wysyłania prywatnych wiadomości.

+0

Tak, przyjrzałem się temu, ale zgodnie z dokumentami w linkach: "Gdy wysyłane są prywatne wiadomości, Usługa kolejkowania wiadomości zapewnia, że ​​treść wiadomości jest szyfrowana od momentu, w którym odejdą od źródłowego menedżera kolejek do chwili docierają do docelowego menedżera kolejek. " Potrzebuję wiadomości zaszyfrowanej, gdy jest ona w kolejce, a MSMQ nie obsługuje tego natywnie. –

1

"Ponieważ serwer WWW jest dostępny publicznie, nie tylko wymagane jest szyfrowanie danych, które mogą być serializowane na dysku, ale także nie mogę przechowywać klucza szyfrowania na serwerze internetowym."

Wygląda na to, że jedynym ograniczeniem, na którym należy się skupić, jest sprawdzenie, czy jest to prawdziwe na początek. Wyklucza to podejście DPAPI + lokalnych sklepów z kluczami.

Możliwe jest dostarczenie klucza według usługi, ale usługa ta musi jeszcze uwierzytelnić dzwoniącego. Jeśli Twój serwer jest zagrożony, podszywając się pod prawowitego dzwoniącego, obserwowanie połączenia itp. Jest możliwe. Ponadto, jeśli klucz przechowywany jest tylko w pamięci, to pamięć jest nadal wykrywalna w debugerze lub zrzucie pamięci, podwyższonym procesie przywileju itp.

Sprzętowe karty szyfrowania to jedyny sposób na pokonanie tych ostatnich scenariuszy.

+0

Myślę, że masz rację, jeśli chodzi o dostarczanie klucza według usługi. Chociaż powiedziano mi, że nie możemy przechowywać klucza na serwerze internetowym, wątpię, czy dostanę zatwierdzenie karty sprzętowej. Patrzyłem raczej na DPAPI i być może uda mi się uzyskać zatwierdzenie, jeśli używam zakresu użytkownika zamiast zakresu maszyny. Mój menedżer jest na spotkaniach przez cały dzień, więc do tego czasu będę musiał czekać na zatwierdzenie. –

Powiązane problemy