Sejf, który możesz przeanalizować, razem z jego granicami

Pytania, które usłyszysz

Większość pracy nad bezpieczeństwem sekretów to odpowiadanie na pytania. Kto może odczytać production? Kto faktycznie to zrobił? Co ujawniłoby włamanie do hostingu? Co się zmieniło po odejściu kogoś z zespołu?

Zadanie polega na tym, żeby mieć te odpowiedzi w postaci, którą można pokazać audytorowi, klientowi lub zarządowi.

Co możesz zadeklarować i na czym to się opiera

• Serwer nie może odczytać wartości. Szyfrowanie odbywa się tylko w przeglądarce i w agencie crunu. Serwer przechowuje zaszyfrowane dane, klucze publiczne i podpisane dokumenty i na żadnym etapie protokołu nie ma klucza do odszyfrowania.
• Skradziona baza danych nie otwiera wartości. Klucz konta jest wyprowadzany przez PBKDF2-SHA256 z 1 000 000 iteracji z hasła i Secret Key o długości około 128 bitów, a ani hasło, ani Secret Key nie trafiają na serwer. Pełna kopia bazy danych nie pomaga w zgadywaniu.
• Serwer nie może sam przyznać sobie dostępu. Listy dostępu i każda wersja są podpisane. Aplikacje klienckie i agenci sprawdzają podpisy i odrzucają stany starsze niż najnowszy, jaki widzieli. Urządzenie, które nigdy nie widziało nowszego stanu, nie wykryje cofnięcia.
• Role egzekwują klucze. Członek zespołu z dostępem do development nie ma klucza production. Osoba z rolą Operator rejestruje maszyny, nie widząc żadnych wartości.
• Dziennik pokazuje ingerencję. Dziennik audytu to łańcuch skrótów: edycja, usunięcie lub wstawienie wpisu wychodzi na jaw przy weryfikacji. Zweryfikuj go jednym kliknięciem albo wyeksportuj JSONL i sprawdź poza Crunu.
• Wyświetlanie i kopiowanie też są zapisywane. Gdy ktoś odsłania, kopiuje lub eksportuje wartość, zdarzenie jest zapisywane z podpisem tej osoby i oznaczane jako zgłoszone przez aplikację kliencką.
• Odejścia zostawiają zapis. Usunięcie członka zespołu tworzy raport ekspozycji: które wersje których środowisk ta osoba otrzymała, kiedy i z jakiego adresu.
• Możesz sprawdzić aplikację, której używasz. Wydania są podpisane Ed25519, klient webowy buduje się powtarzalnie, a aplikacja przy każdym wczytaniu sprawdza własną kompilację względem podpisanego wydania.
• Logowanie ma limity prób. 10 nieudanych prób na adres i 5 na konto w ciągu 15 minut, a „brak konta” wygląda tak samo jak „błędne hasło”. Sesja wygasa po 12 godzinach bezczynności i trwa najwyżej 7 dni, a bez hasła i Secret Key nie może zmienić hasła ani usunąć konta.
• Drugi składnik na każdym koncie. Kody z aplikacji uwierzytelniającej i klucze dostępu w przeglądarce; w terminalu kod z aplikacji lub zatwierdzenie z innego zalogowanego urządzenia.

Algorytmy: AES-256-GCM dla wartości, X25519 do szyfrowania kluczy dla odbiorcy, Ed25519 do podpisów, HKDF-SHA256 do wyprowadzania kluczy. Model bezpieczeństwa wyjaśnia, jak się łączą.

Gdy coś wygląda podejrzanie

• Alerty uruchamiają się przy logowaniu z nowego urządzenia, ponownie użytym kodzie rejestracji, maszynie pod nowym adresem, ponownie użytym tokenie CI, serii odmów, wygasłej dzierżawie, logowaniu kodem odzyskiwania, wygasających certyfikatach, niedostarczonych kluczach i zdarzeniach sieciowych, takich jak złagodzona reguła lub dostęp awaryjny. Trafiają do webhooka podpisanego HMAC albo na e-mail.
• Ograniczenia sieciowe wydają production tylko dozwolonym zakresom adresów. Złagodzenie reguły czeka 15 minut z alertem i możliwością cofnięcia; dostęp awaryjny właściciela trwa najwyżej 60 minut, wymaga podania powodu i wywołuje alert.
• Opcja Device compromised wymienia klucze konta osoby, wylogowuje jej pozostałe urządzenia i wymienia klucze każdego środowiska, do którego miała klucz.
• Przechowywanie pod twoją kontrolą. Dziennik audytu jest domyślnie przechowywany 365 dni, a organizacja może ten okres tylko wydłużyć, do 36 500 dni lub bezterminowo. Przycinanie zostawia punkt kontrolny, więc łańcuch nadal przechodzi weryfikację.

Czego Crunu nie może ochronić

• Zmodyfikowany klient webowy to główne pozostałe ryzyko, jak w każdym sejfie działającym w przeglądarce: strona wysłana przez przejęty serwer mogłaby przechwycić hasło i Secret Key przy logowaniu. Obroną są podpisany manifest, względem którego aplikacja sprawdza samą siebie przy każdym wczytaniu, oraz polityka Content Security Policy z Subresource Integrity, która blokuje skrypty stron trzecich. Ta samokontrola działa na tej samej stronie, dlatego nie wykryje serwera, który zmieni jedno i drugie. Podpisy opierają się na kluczu wydania, więc nie chronią przed tym, kto ma ten klucz.
• Wartości, które ktoś już widział, nie da się odebrać. Rotacja chroni nowe wersje. Same wartości wygeneruj ponownie u każdego dostawcy.
• Serwer widzi metadane: nazwy organizacji, projektów, środowisk i maszyn, adresy e-mail, dziennik audytu oraz rozmiary i czasy wersji.
• Serwer może odmówić obsługi lub odrzucić zapisy. Obroną są eksporty, kopie offline, a przy własnym hostingu – kopie zapasowe.
• Złośliwe oprogramowanie na urządzeniu, na którym klucze są odszyfrowywane (keylogger, rozszerzenie przeglądarki, root na maszynie), może odczytać to, co może odczytać to urządzenie.
• Kod odzyskiwania otwiera konto po okresie oczekiwania bez drugiego składnika. Okres oczekiwania egzekwuje serwer, więc przejęty serwer mógłby go pominąć.
• Ograniczenia sieciowe egzekwuje serwer, nie szyfrowanie.
• Właściciele i administratorzy mają dostęp do każdego wspólnego środowiska przez klucz odzyskiwania organizacji.
• Przejęty serwer działający razem z usuniętym członkiem zespołu mógłby utrzymywać nowe urządzenie na starszym stanie organizacji. Pełne zamknięcie tej luki wymagałoby zewnętrznego dziennika przejrzystości.
• Jeśli baza danych serwera wycieknie razem z jego własnym kluczem, kody z aplikacji uwierzytelniających słabną jako drugi składnik.
• Brak logowania jednokrotnego (SSO) i SCIM.

Każde ograniczenie wraz z tym, co z nim zrobić, opisuje strona ograniczeń.

Chcesz zgłosić problem?

Napisz na security@crunu.com. Nasz plik security.txt jest pod adresem /.well-known/security.txt.

Powiązana dokumentacja

• Jak działa szyfrowanie
• Co widzi serwer
• Ograniczenia
• Dziennik audytu
• Alerty
• Reguły sieciowe
• Offboarding członka zespołu